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)
Previous text:
2003-02-27 04:02: Subject: Re: 64 bit ints
On Thu, Feb 27, 2003 at 03:40:01AM +0100, Martin Nilsson (har bott i google) @ Pike (-) developers forum wrote:
knowledge. I am happy to enlight interested newcomers, but I have better things to do than reciting Pike internals to someone who just entertains himself with finding syntactical flaws in the presentation.
Well, I'll make my point clear - I want to know what to expect from Pike development in the future. I like it (the language), but I want some features implemented. Some I can do on my own, of course, but I want to know what to expect from the Pike team - are they willing to accept something that they (personally) don't need? Are they open-minded? Are they will try to convince me that I don't need "unsigned int" or just accept (for instance) my own version of this type for inclusion in future versions? And so on...
In the past, I heard something like "The PCRE is not good enough for Pike, that's why it will never be included into distribution", but now it seems to be a less strict. So - I just want to know, nothing more.
I hope it is clear (and fair) enough? :)
Regards, /Al
/ Brevbäraren