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.
Wether it's a must for pike core or not I will refrain to comment on. However, Alexander is free to write a class for handling signed integers. Sure - it is a lot of overhead, but if it is designed to primarily work on blocks of unsigned integers it might be of some value (did something similar half a year back).
/ Peter Lundqvist (disjunkt)
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)