Regarding Bz2 (mentioned in an earlier message) the implementation of the Pike module Bz2 is not an ignorant act of code duplication. [...] The module is only a by product, chosen for its small API, while the real work was to evaluate the C module API.
And document, non the less. The results of that is available on the pike site since yesterday - see the PDFs and perhaps the tarball at http://pike.ida.liu.se/projects/docs/cmods/downloads.xml for the full story. Some parts of the APIs are still undocumented, but the general situation has much improved.
/ Johan Sundström (a hugging punishment!)
Previous text:
2003-02-27 04:50: Subject: Re: 64 bit ints
No, I don't think you'll be able to find someone willing to rewrite the entire Pike code to facilitate a unsigned int type. Pike still hasn't recovered fully from the automatic int-bignum conversion rewrite. And that extenstion had a functional purpose, which unsigned int doesn't have. But you shouldn't use this specific issue as a lithmus test for Pike development. Just because we don't want to change the most fundamental data type in the langauge throughout the entire core and all modules so that we get a slight memory gain that will be eaten up by the additional code and degrade the overall performance of the language doesn't mean that we aren't up to the next idea.
I'm not saying that we would actually implement it, since we doesn't even have time to realize our own ideas, but we don't forbid changes (as in this case) without evaluating them.
Regarding the PCRE issue the problem has not been that we don't want PCRE. While Pike was governed by Roxen the policy was that the Regexp engine should not be replaced with anything that couldn't handle wide strings. That was first only used to "prevent" internal replacements of the Regexp engine ("If we are to pay you for updating the Regexp engine we want wide string support"), but it was later used to protect the repository from what was percieved as badly designed and badly implemented code. I myself has neither seen the code nor the Pike API for the PCRE PExt, so I don't know if it is true today or ever was.
Regarding Bz2 (mentioned in an earlier message) the implementation of the Pike module Bz2 is not an ignorant act of code duplication. The Bz2 PExt was reviewed before implementation and Andreas Finnman made _two_ additional implementations as part of his thesis work. The module is only a by product, chosen for its small API, while the real work was to evaluate the C module API.
/ Martin Nilsson (har bott i google)