Oh my, a wild Solar has appeared!
Solar wrote:
onlyonemac wrote:
Or you could write your own...
The whole idea of PDCLib was to make this kind of repeatedly inventing the wheel unnecessary. That's why I designed PDCLib to be
just what the standard says,
exactly what the standard says, and did slap the CC0 license on it so you would
not have to "write your own" anymore.
I am confident Owen did continue to work in a similar direction.
And believe me, some of these things are
not simple. The stdio part took me three complete rewrites to get anywhere near "working" -- and you have to make damn sure you get the modularization right so you don't end up tying the implementation to a specific underlying OS API (a.k.a. POSIX).
@Owen:
The project seems to suffer from being "smeared" over several locations. I find
http://pdclib.e43.eu/, which links to a non-existent source location
http://hg.pdclib.e43.eu/pdclib. I find
https://bitbucket.org/pdclib/pdclib (via search engine, not linked from the first domain), and I find
https://github.com/blanham/PDCLib, not connected to the other two either AFAICT, and behind the bitbucket repo by a year or so. Perhaps some cleanup would be nice.
Argh. The hg.pdclib.e43.eu link pointed to the BitBucket URL using a feature that BitBucket recently discontinued, and they didn't provide any redirection for old URLs or such
. I've fixed the link to point to the right location. blanham's repository on GitHub is completely unrelated to me and I have no control over that.
The BitBucket mercurial repository is the canonical source. That said, I've been strongly considering moving the code to Git, because it's quite clear that Git has won by a large margin (far greater than there was at the time I picked Mercurial), and by far more people are familiar with it. I'd probably shuffle the source over to GitHub also, because, well, that's where people go looking for such things these days...
(If you've used any of the new-frangled DVCS thingies since you handed the project off, I'd be interested to hear your thoughts
. I work in hardware engineering - famed for using "old" and "unfashionable" things like tcsh, Perl and Tcl, and even we now use Git, so it seems the number of places which are still "SVN holdouts" is getting less and less)
Solar wrote:
And, unrelated, I had a discussion about the fine print of the standard lately. All the "memory" functions, i.e. memcpy() / memmove() etc., need to cast their void * arguments to unsigned char *, not plain char *. Doesn't make much of a difference with 8-bit two's-complement machines, but only unsigned char is guaranteed to not cause CPU traps.
Ugh. That subtlety
Quote:
I'd be happy to join in with a patch or two every now and then; how do I sign up again? (If you'd have me, that is.)
I think the obvious answer would be to send any contributions as a Bitbucket (or maybe in the future GitHub) pull request, though I'm not a fan of the pull request system either provides (there's just too much overhead there: make your own fork, push to that, create pull request, etc). If you have any other thoughts, please feel free to send me them (I guess I could alternatively just give you commit access. I have no good reason not to
)
With the above said, thanks for the prod. I'll get to work on the legal clearance I need to push changes to PDCLib on Monday. (I see no reason it should pose any problems - its just that because of some overlap with our business area it does need to go through legal, and I haven't gotten around to that yet partially because until a few days ago I hadn't figured out what the process was). I also need to give the web presence a bit of a tidy up and all that.