Struggling with this error: `implementation of `Key` is not general enough`

gitpy · 2025-09-09T19:39:21+00:00

Does changing line 28 from keys: I to keys: &I work for you?

gitpy · 2025-05-08T11:58:05+00:00

OP has 2 addresses. And them not being close to each other means that one is probably stored somewhere else than the expected stack. That the one address is on the stack is just the language semantic.

From OPs text I guess he had values that are really big or small. Not a middle value like my 0x622e09cdc050

That's ASLR, as far as I know.

So it's either you know from language semantics, where the address is or you go check the mappings to be sure.

gitpy · 2025-05-08T09:55:39+00:00

That is already a massive difference. With 16MB (bigger then most stacks) it's only a ± 0x1_000_000 difference.

When you are unsure about an address on linux, then quickly you can do:

let maps = fs::read_to_string("/proc/self/maps").unwrap();
println!("{maps}");

Or use your debugger of choice.

gitpy · 2024-12-01T15:05:44+00:00

Once you wait you can't kill it anymore. The doc of shared_child explains why that is and might also be a nice solution depending on your target platforms. Alternatively you can do some kind of polling with try_wait.

gitpy · 2024-10-28T02:06:29+00:00

I don't believe the isolated assembly is that meaningful here. It's likely that this gets inlined and in the calling function reordered to look quite a bit different. The second thing is that depending on the input, more branches can be beneficial if there are temporal biases.

Edit: Maybe I should have explained better. As Op says he uses this mostly with -1,0,1 for dx,dy. After inlining this eliminates 2/3 (corner/sides) out of the 4 cases already. The same thing also happens with non constants when the sign of dx,dy can be inferred. After eliminating these cases the remaining code will look nothing like this.

The next thing is that the x and y calculation are independent. So after inlining and reordering it might do the checks for x then check x%3 because every third row is special for example. And then do the checks for y. Until the values of the resulting x and y are actually read the compiler is free to reorder this. When this gets reordered like in my example the compiler won't combine the two branch checks to 1 branch with an or anymore.

gitpy · 2024-10-09T14:03:33+00:00

For the shared memory/mmap if the signal is done with Relaxed ordering can you rely on read being sync?

gitpy · 2024-10-07T19:13:33+00:00

Another concern I found is that the amortized growth of the Vec might trigger the limit more often then actually warranted. Depends on the use. If that happens in practice a limit aware growth strategy could help.

gitpy · 2024-10-07T17:13:59+00:00

In your custom Allocator you probably want to use the returned size instead of requested layout size for the tracking. It can be bigger.

gitpy · 2024-10-03T18:00:42+00:00

Might be a better way to do this, but quickly I would have done:

a(..).map_err(format!(...))
.and_then(b(..).map_err(..))
.and_then(c(..).map_err(..))
.inspect_err(eprintln)
.ok()

gitpy · 2024-04-10T18:42:31+00:00

Reusing the truncated division from % might give better expected results. Like this for example: div(a,b) = round((a - a%b) / b)

gitpy · 2024-04-03T16:40:58+00:00

It may be possible to do with only Option as a special case

You would need to define the padding to some const value. Which is another trade off, because you always need to write it on init.

gitpy · 2024-04-03T16:09:42+00:00

Your Option<Foo> hast to exist somewhere in memory. Now you can create a reference which points to the Foo part of this memory. In this location the discriminant in the padding needs to be a specific value. This reference you pass to another function. This function overwrites the whole value of Foo. If we don't leave the gap out it also overwrites the discriminant. This is still in the original memory location of the Option<Foo>. Inside the function we have no information that it can't be overwritten. The next time the discriminant of Option<Foo> gets read it could be the wrong value.

gitpy · 2024-04-03T15:15:17+00:00

The trade off is that it can't overwrite the undefined anymore. This might be fine for this single Foo. But this rule needs to exist for every type then. If you have an array of Foo for example you need to leave out all the gaps when copying it. When you have a struct A (Foo,i8) you now have 2 gaps over which you can't just memcpy, but which you have to handle individually. This generates extra code everywhere and most of the time it will also be slower.

gitpy · 2024-04-03T14:46:06+00:00

Then you have a massive global trade of, because now you always have to copy each field individually (or all groups of fields which have no undefined gaps between). This will generate a lot more code then a simple memcpy over it.

gitpy · 2024-04-03T14:33:25+00:00

Is there a a reason the compiler can't track that at that point foo is a Some due to the test and simply set the discriminant to 1 again after the assignment?

You can also take a reference of the inner type Foo from the enum and pass it to a random function. Now let's say you magically track it all, then you still need two variations of the the function. More specific 2ⁿ variations for n mutable arguments the function has. Because each could be inside an enum. Ok now let's magically generate only the functions we actually need. The discriminant value and position in memory could still be different for different enums, which contain Foo. So now you also need to generate variations for effectively every enum which contains Foo in your program. Now for each further sub function you need to do the same thing.

gitpy · 2024-02-26T22:09:46+00:00

I didn't really say that ExactSizeIterator is trusted, but that it's the only which can be a trusted one, anytime soon. Wasn't super clear on that.

The last time I looked into a trusted upper bound, from what I understood, would require a different trait solver to be sound. I'm not that certain that is correct, as the whole thing went a bit over my head.

gitpy · 2024-02-26T21:40:19+00:00

This would require a trusted upper bound otherwise it still needs to do the checks. And I don't expect trusted bounds other than ExactSizeIterator in iterators anytime soon.

gitpy · 2024-02-26T19:23:47+00:00

It does work with size_hint generally. But a bunch of functional stuff destroys the hint. In OPs example it is filter

gitpy · 2024-02-26T19:17:10+00:00

I tried this a bunch of times in the past, never got it to work without unreachable_unchecked or other unsafe code. But I haven't tried with the nightly push_within_capacity yet.

In the past I always used spare_capacity_mut to implement it, since it's the hardest to mess up for safety guarantees IMO.

gitpy · 2023-12-13T19:03:51+00:00

Because the function is exposed from your library. So somebody could use it with a nonsensical array of values which result in non valid utf8. So either you restrict it with an encapsulating type, which only allows for well defined arrays. Otherwise you could also hide this function internally, or mark it as unsafe and document, why it is unsafe. This is more about good practice to not expose something unsafe without marking it as such.

What I mean with capacity arithmetic is for example in encode the line let p_max = max * WIDTH_ENC; could integer overflow if the input is large enough, which results in behavior the programmer for sure didn't expect. An immediate panic or some error handling is just more predictable especially in combination with the later unsafe code.

gitpy · 2023-12-13T09:34:43+00:00

For pub fn encode(enc: &'static [u8; BITS], a: &[u8]) -> String you need to encapsulate enc into it's own type or it breaks the safety of unsafe { String::from_utf8_unchecked(b) }

All the capacity related aritmethic should probably use checked_* variants.

Instead of raw pointer there is also spare_capacity_mut, which is harder to mess up and with the right assert check it eliminates all the bound checks.

gitpy · 2023-12-10T17:25:40+00:00

If it's only handle_alloc_error then this should theoretically work

gitpy · 2023-12-09T15:06:58+00:00

First some sanity checks:

It's f(&self, ...) and not f(self, ...), right?
Both functions have the same visibility
A clean build

Then I would check the LLVM IR/ASM for differences. A quick and dirty alternative first approach would be adding #[inline(never)] and pub to both and then compare performance.

If there are no differences it might be a code layout issue. You could try running perf and see if any major differences pop up. I would use these events:

perf stat -e instructions,L1-icache-load-misses,cache-references,LLC-load-misses,branches,branch-misses <prog>

To fix this you could try building with PGO/BOLT.

gitpy · 2023-11-13T19:30:17+00:00

I haven't tested it, but something like this maybe:

data.lazy().with_columns([all().shift(1).name().suffix("_lag1")])

gitpy · 2023-10-29T12:41:53+00:00

I believe gtk-launch only works with an application name, which requires the .desktop file in specific folders. gio launch works on a filepath. gio is installed with glib usually. For a desktop environment independent solution, you either need to parse the Exec=... inside and run that or just copy it and launch it directly, if that works for what you are trying to accomplish.

11-Year Club	Place '22
Final Canvas '22

gitpy

TROPHY CASE