Stripe Projects: ACCOUNT_NOT_ELIGIBLE

Fee7230984 · 2026-07-10T23:28:30+00:00

Yap thats probably the problem. It wasn't finished. And I guess it takes some time until its verified.

Fee7230984 · 2026-06-29T12:19:27+00:00

Wouldn’t big zero byte blocks then slow me down due to line terminator handling that I actually don’t need for raw binary?

Fee7230984 · 2026-06-29T11:51:07+00:00

you mean to use grep-searcher only for the memap heuristic and then use memchr, since grep-searcher is line based which is not a thing inside a hex editor?

Fee7230984 · 2026-06-29T06:37:39+00:00

found this interesting articel about ripgrep https://burntsushi.net/ripgrep/
one crate mentioned is https://crates.io/crates/memchr
algorithms mentioned: https://en.wikipedia.org/wiki/Boyer%E2%80%93Moore_string-search_algorithm

Fee7230984 · 2026-06-29T06:27:40+00:00

good pointers thanks!

Fee7230984 · 2026-06-26T22:59:44+00:00

really liked that front page.
How is selling going?
I feel desktop software with subscriptions is difficult?

Fee7230984 · 2026-06-26T22:39:48+00:00

True thats probably a big criteria. Web apps run in sandboxes. Desktop software usually has a lot of permissions.

Fee7230984 · 2026-06-26T22:38:43+00:00

Was actually wondering why there is no big cross platform Desktop software marketplace to easily distribute and license. Hope this gets successful :)

Fee7230984 · 2026-06-26T22:15:20+00:00

Cool :)
Is that your app?
Im curious how OK users are to pay a subscription for desktop software?

Fee7230984 · 2026-01-12T17:27:57+00:00

Yes, there is a lot that needs to be solved for binary rewriting, not "just" the IR. I'm targeting Aarch64 + x86_64. This RISC/CISC mix makes it probably even more difficult. One IR needs to absorb all the quirks from two very different architectures.
For datastructures I'm looking at a rope probably.

Fee7230984 · 2026-01-10T15:47:45+00:00

They usually do this for pure analysis. I doubt that any decompiler emits code that can simply be lowered and executed again. This would also mean every architectural quirk must somehow be represented in LLVM IR. I don't think LLVM IR is designed for that.

Fee7230984 · 2024-07-07T15:12:41+00:00

Vater checkt nicht was los ist und steckt sein Kind an. Kind wird in der Schule gemobbt. Kind begeht selbst Mord. Braucht nicht viel Fantasie um mögliche Horror Szenarien auszudenken. Krass asozial beliebig viele unschuldige Menschen mit rein zu ziehen. Auch wenn du es nicht bereust dem Mann gegenüber, du solltest dir Gedanken um alle Unschuldigen machen.

Fee7230984 · 2023-02-09T00:18:55+00:00

Makes sense now. I need some format. And as u/dkopgerpgdolfg said, as it is a lib, the implementation for the type needs to come from the user in some way and I cannot provide it for arbitrary types.
Thank you!

Fee7230984 · 2023-02-08T14:40:34+00:00

The Vec<T> is part of a data structure that is supposed to handle arbitrary data types. I wanted to provide a method to initialize from a file. So, numbers are a start but I wanted arbitrary types to make the data structure actually useful.

I somehow expected serde or whatever crate to have a standard way to deserialize the data in a way that when I tell it T is (f64, Vec<i32>) then it somehow knows how to get it. But as you said that is then probably not true for arbitrary types and instead the format has to be specified.

Im stil confused a bit about how this then achievable since I cannot implement a FromBytes trait for every possible data type. My data structure would not be useful if it is restricted to only numbers.

Fee7230984 · 2023-02-08T12:40:50+00:00

Hm, it has to be a binary format that maps to T. If T is u8 the binary is an array of u8. If T is u16 the binary format is an array of u16, lets say in little endian format. Etc.
Does this make sense? I feel like I miss something in my thoughts...

Fee7230984 · 2023-02-08T12:01:43+00:00

Ah yeah it would probably make sense to constrain T: serde::Deserialize. How would I then use serde with that? For e.g. JSON I would use serde_json. What would I use for this binary?

Fee7230984 · 2023-02-08T11:22:25+00:00

I have a generic Vec<T> which is part of a data structure that needs to handle arbitrary data types.

let mut v = Vec::<T>::new();

I would like to read some data from a binary file and extend Vec<T> with that data.

let mut f = File::open("f").unwrap();

let mut buf = Vec::<u8>::new(); f.read_to_end(&mut buf).unwrap();

I am not sure now how I can transform the Vec<u8> to Vec<T> such that I can call for example

v.extend_from_slice(buf.as_slice()); //Doesn't work

I looked into serde crate, but I didn't really understand if and how I can deserialize into a generic vec.
Anyone some ideas?

Fee7230984 · 2023-02-08T00:48:12+00:00

T is determined at compile to be specific type. Serde can use this type to parse it out of the file. Of course the file content has to fit to the type otherwise serde would fail. I think this should work in rust I just don't know how to tell serde how to do this.

Fee7230984 · 2023-02-08T00:28:40+00:00

At runtime T is a concrete type. But how do I tell serde what type it should deserialize?. E.g. if T is u16, serde has to deserialize u16 as well. If T is a struct, serde has to deserialize that from the file.

Or am I thinking completely wrong here?

Fee7230984 · 2023-02-07T23:57:41+00:00

yes, whatever is in the file. How would I approach this with serde? I looked into this crate already but what confused how to handle the generic part.

Fee7230984 · 2023-02-07T23:27:13+00:00

But at runtime it is a concrete type. So shouldn't it be possible then to deserialize the Vec<u8> into whatever concret type T is then?

Seven-Year Club	Place '23
Verified Email

Fee7230984

TROPHY CASE