> he was a large contributing factor to the previous SolveSpace lead maintainer quitting
If you look at https://github.com/solvespace/solvespace/issues/714, it refers to "a few people [who] behave in a way that is unconstructive and directly leads to maintainer burnout [...] have not encountered this level of entitlement and persistence when working on any other OSS, of which I maintain plenty, and I do not wish to encounter it ever again.". That's this guy. At the time I chose not to name him publicly nor to ban him from the organization; the latter was clearly a mistake.
(The unfortunate incident with Aleksey was the proverbial straw. I regret that it happened, since Aleksey has done a lot of good work for the project; if memory serves, at the time I was looking for other ways to fund his work.)
> who near converted SolveSpace to doble-licensed open-source, far away from its inital GPLv3.[3]
This happened after I spent several months paying Aleksey Egorov (Evil-Spirit), who did some of the best and most important work on SolveSpace, a competitive salary out of my own pocket, and it has been done in coordination with Jonathan Westhues. (You'll see his name on the CLA.) SolveSpace had a commercial licensing option before the initial open-source release, which provided a (small, but useful) revenue stream, and that seemed like a good option to continue using.
Knowing this, you can also see why Aleksey's unfortunate statement about gender felt so painful. All I wanted was to keep developing a great FOSS CAD!
process_vm_read and its equivalents allow you to read data whose layout you already know. unfork allows you to read data whose layout you don't know or that is partially generated by calling the accessors that the application already has for that data instead of reverse-engineering them and doing the transformation yourself.
Also I got pinged by like a dozen different HN bots, because each time any of them tweets a link, Twitter thinks it's a quote-tweet and sends a notification. Annoying.
At the time when I started working on smoltcp, there were a few Rust libraries for working with TCP/IP on the wire level, and they heavily used metaprogramming. Unfortunately, the task of implementing a generic binary protocol serializer/deserializer that can handle TCP/IP is not small, and as far as I could tell, it overtook implementing anything beyond that.
So I made the decision to do the simplest possible thing: write the packet serializers/deserializers entirely by hand. It took very little time and adding any new features was easy and predictable. I believe it was the right decision as it allowed me to focus on the hard parts of a TCP/IP stack.
I designed smoltcp (and wrote most of the code currently in it). The original TCP/IP RFC (RFC 793) contains several ambiguous requirements, and as a result they do not specify a well-defined system. There are also some outright incorrect statements. There are a few follow up RFCs (e.g. RFC 1122) that clarify these issues, and there are more RFCs (e.g. RFC 7414) that describe the TCP features that you should avoid using.
By using this collection of TCP/IP RFCs that grew over the years, it is indeed possible to implement a stack from first principles and have it interoperate with other existing stacks without much trouble. (At least so long as you don't put the same bugs in your test suite as you do in your stack... which you will.)
However, being able to transmit some bytes reliably, and having a high-performance stack that works well in real world conditions are different. You might be able to do the former from RFCs, but the latter absolutely requires a nontrivial amount of tribal knowledge that you have to collect crumb by crumb, and often quite painfully, too.
Smoltcp is somewhere halfway between. It's pretty reliable, but I am sure there is much to be improved in its operation in adverse conditions, with obscure peers, and so on.
Does it work reliably on the open internet? AIUI, it's interoperability with all the edge cases of badly implemented protocols that leads to statements like GPs.
The "smol" in "smoltcp" is mostly talking about the internal architecture and exposed API. For example, it will never support true zero-copy sockets, because the API burden due to restricting itself to safe Rust is too high.
I don't think any TCP/IP implementation is going to be "haiku-like", the protocol stack is way too messy.
> MSVC compiler doesn't do SROA, as far as I know.
In the future, consider verifying your extraordinary claims. Of course it does, and it took me about two minutes to demonstrate that: https://godbolt.org/g/9kT1NP
"As far as I know" implies that I might not know, so that's not an extraordinary claim.
You haven't actually verified SROA. The scalar replacement didn't kick in for the non-inlined method, so this could be a result of loop-specific optimizations. The code is also far from optimal, but that's besides your point of course.
Zoxc has repeatedly refused reasonable requests to alter the patch to fit the standards of upstream. Because of this (and because I am rather tired of not having stack probes, with my embedded system not having functional guard pages), I'll make a hostile fork of their patch soon and get it through the pipeline. Stay tuned.
Late comment, but aren't stack probes entirely predicated on having working guard pages? I.e. they only exist to guarantee that the guard page is accessed before anything else, when a frame is larger than the page.
SolveSpace is indeed similar to FreeCAD's Part Design module. One major difference is that SolveSpace uses the same solver for constraints in 2D and 3D, as well as for sketches and assemblies, whereas in FreeCAD the Assembly module is separate.
> he was a large contributing factor to the previous SolveSpace lead maintainer quitting
If you look at https://github.com/solvespace/solvespace/issues/714, it refers to "a few people [who] behave in a way that is unconstructive and directly leads to maintainer burnout [...] have not encountered this level of entitlement and persistence when working on any other OSS, of which I maintain plenty, and I do not wish to encounter it ever again.". That's this guy. At the time I chose not to name him publicly nor to ban him from the organization; the latter was clearly a mistake.
(The unfortunate incident with Aleksey was the proverbial straw. I regret that it happened, since Aleksey has done a lot of good work for the project; if memory serves, at the time I was looking for other ways to fund his work.)
> who near converted SolveSpace to doble-licensed open-source, far away from its inital GPLv3.[3]
This happened after I spent several months paying Aleksey Egorov (Evil-Spirit), who did some of the best and most important work on SolveSpace, a competitive salary out of my own pocket, and it has been done in coordination with Jonathan Westhues. (You'll see his name on the CLA.) SolveSpace had a commercial licensing option before the initial open-source release, which provided a (small, but useful) revenue stream, and that seemed like a good option to continue using.
Knowing this, you can also see why Aleksey's unfortunate statement about gender felt so painful. All I wanted was to keep developing a great FOSS CAD!