Similar case here where I work. There's a Delphi 3 application with an access database that has been in use for an unknown number of years. Last update to it was in 2002 or 2003 and it's been in read-only mode since 2005.
If you want to get money from donations you need publicity because most people who visit your website will never donate. If you are someone who releases/has lots tools I would recommend setting up a single domain with dedicated pages for each tool (e.g. tool.domain.com or domain.com/tool) and setting up a Patreon in addition to the donation button.
Honestly I would put ads on the extractemailaddress.com website and work on improving it's position on the search results. In addition to that localization to one or two other languages would probably be nice to boost the views. That "make a small donation" button really put me off.
Besides VCS unfriendly, the storage space for all the additional space characters provides little utility. For the most part, computers are reading CSV, not humans (though we might scan them).
I presume the parent means changing the data s.t. the max length of strings in a column changes; this would cause the padding after that column to change, so as to keep subsequent columns aligned & looking nice. This doesn't play well w/ VCS diffs, as a bunch of data that isn't changing semantically is now changing syntactically, and a simplistic textual diff reflects now that syntactic change, whereas a human reader would want to see the semantic change.
Now… most diff tools also have options to ignore whitespace changes, for cases like this.
* No comments/documentation about the hardware or the challenges the author has gone through.
* Github repository has just CHANGELOG.md and README.md.
* Some how the author managed to get a popular game running flawlessly in a short time.
It looks more like another emulation scam than an actual product, but it could be one of those projects the author is just dreaming about making an emulator. Is that you, vgturtle?
> * Great Libraries ( Everything and a kitchen sink )
This is a must for me. I often give up on compiled languages because libfoobar isn't yet available on the language and I have no interest in writing (and maintaining) language bindings for third party libraries I use.
My dream is that one day I'll be able to do something like:
Foobar = link_cimport({"headers": ["foobar.h"], "packages": [ "foobar" ], "prefix": "foobar_"});
Foobar.do_something(); // would call foobar_do_something();
Foobar.hidden_function(); // would call hidden_function();
and the compiler will give me an executable that was linked against `foobar` instead of dlopen()ing it at runtime. Something like:
Foobar = loadable_cimport({"headers": ["foobar.h"]});
foo = Foobar.load("/path/to/foo.so");
bar = Foobar.load("/path/to/bar.so");
would also be nice because I often have to load libraries that implement the same API/ABI.
It converts C headers to a Rust module containing the relevant type/function/etc. definitions. On stable you need to either pregenerate the module (not too bad if you're pinning particular versions of libraries anyway) or add a build script to autogenerate it. On nightly, there's also a compiler plugin that does all the work for you, and looks not-too-dissimilar to what you wanted. The only thing it lacks is the prefix removal stuff.
