Hi,
Still experimenting with long* types, found one problem (so far): --- opcodes.c:367 --- case T_INT: sprintf(buf, "%ld", (long)sp[-1].u.integer); break;
case T_FLOAT: sprintf(buf, "%f", (double)sp[-1].u.float_number); break; --- snip ---
As you can see, it won't work correctly in case when long long ints or long doubles are in use. Testsuite is also a bit unprepared for this case (several errors, most of them due to this bug). Regards, /Al
There are numerous fixes for that in 7.5 so I suggest you continue your hunt there. I doubt it's feasible to backport all that to make longer ints and doubles work flawlessly in 7.4.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-19 06:39: Subject: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
Hi,
Still experimenting with long* types, found one problem (so far):
--- opcodes.c:367 --- case T_INT: sprintf(buf, "%ld", (long)sp[-1].u.integer); break;
case T_FLOAT: sprintf(buf, "%f", (double)sp[-1].u.float_number); break; --- snip ---
As you can see, it won't work correctly in case when long long ints or long doubles are in use. Testsuite is also a bit unprepared for this case (several errors, most of them due to this bug).
Regards, /Al
/ Brevbäraren
On Fri, Sep 19, 2003 at 02:40:04PM +0200, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
There are numerous fixes for that in 7.5 so I suggest you continue your hunt there. I doubt it's feasible to backport all that to make longer ints and doubles work flawlessly in 7.4.
Why not in 7.4? It may take ages before 7.5 (7.6?) will be considered as stable as 7.4, while fixing this stuff seems not to be too difficult.
Finally I managed to compile 7.5, there are no problems with long long type (at least tests are OK), but as for me it would be nice to have it in 7.4-stable (I am a bit in doubt to use 7.5 in production environment).
Regards, /Al
I thought it to be a bit too many changes all over the place, that's all. Afterall, the development version is for development work while the released one is ostensibly only for bug fixes (and I don't think work on experimental and by default disabled features really count as bug fixes).
Guess it could be ok if we look them through carefully, though; inserting a few PRINTPIKEINT and PRINTPIKEFLOAT here and there isn't exactly rocket science.
Besides, it's probably a bit of work to collect and backport the various fixes for this that has accumulated in 7.5 over time.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-20 00:52: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
On Fri, Sep 19, 2003 at 02:40:04PM +0200, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
There are numerous fixes for that in 7.5 so I suggest you continue your hunt there. I doubt it's feasible to backport all that to make longer ints and doubles work flawlessly in 7.4.
Why not in 7.4? It may take ages before 7.5 (7.6?) will be considered as stable as 7.4, while fixing this stuff seems not to be too difficult.
Finally I managed to compile 7.5, there are no problems with long long type (at least tests are OK), but as for me it would be nice to have it in 7.4-stable (I am a bit in doubt to use 7.5 in production environment).
Regards, /Al
/ Brevbäraren
Why not in 7.4? It may take ages before 7.5 (7.6?) will be considered as stable as 7.4, while fixing this stuff seems not to be too difficult.
Because 7.4 is stable and, to quote Martin Stjernholm "I doubt it's feasible to backport all that to make longer ints and doubles work flawlessly in 7.4". Are you of another opinion, and if so, why?
/ Martin Nilsson (saturator)
Previous text:
2003-09-20 00:52: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
On Fri, Sep 19, 2003 at 02:40:04PM +0200, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
There are numerous fixes for that in 7.5 so I suggest you continue your hunt there. I doubt it's feasible to backport all that to make longer ints and doubles work flawlessly in 7.4.
Why not in 7.4? It may take ages before 7.5 (7.6?) will be considered as stable as 7.4, while fixing this stuff seems not to be too difficult.
Finally I managed to compile 7.5, there are no problems with long long type (at least tests are OK), but as for me it would be nice to have it in 7.4-stable (I am a bit in doubt to use 7.5 in production environment).
Regards, /Al
/ Brevbäraren
On Sat, Sep 20, 2003 at 01:05:02AM +0200, Martin Nilsson (saturator) @ Pike (-) developers forum wrote:
feasible to backport all that to make longer ints and doubles work flawlessly in 7.4". Are you of another opinion, and if so, why?
Well... Currently, so far all the problems with long longs are related to testsuite, which is, in turn, dependent on casting to string.
64 bits int are useful in many apps which otherwise would require Gmp - it includes byte counters, etc. May be it is a bit specific to my projects (log processing, traffic accounting in particular), but I see no real problems to fix all this stuff in 7.4 too, and I don't think that this feature might be as unstable as something more sophisticated (on some architectures native int size is 64 bits anyway, or this arch support isn't planned/available in 7.4?).
BTW, it would be nice to have some... uhm... preprocessor constant (or anything else) to determine native int size (and perhaps float size). I couldn't find how to do this (except of hack with sprintf("%u", ~0) - but this is ugly, IMHO).
Regards, /Al
BTW, it would be nice to have some... uhm... preprocessor constant (or anything else) to determine native int size (and perhaps float size).
SIZEOF_INT and SIZEOF_FLOAT?
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-20 01:42: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
On Sat, Sep 20, 2003 at 01:05:02AM +0200, Martin Nilsson (saturator) @ Pike (-) developers forum wrote:
feasible to backport all that to make longer ints and doubles work flawlessly in 7.4". Are you of another opinion, and if so, why?
Well... Currently, so far all the problems with long longs are related to testsuite, which is, in turn, dependent on casting to string.
64 bits int are useful in many apps which otherwise would require Gmp - it includes byte counters, etc. May be it is a bit specific to my projects (log processing, traffic accounting in particular), but I see no real problems to fix all this stuff in 7.4 too, and I don't think that this feature might be as unstable as something more sophisticated (on some architectures native int size is 64 bits anyway, or this arch support isn't planned/available in 7.4?).
BTW, it would be nice to have some... uhm... preprocessor constant (or anything else) to determine native int size (and perhaps float size). I couldn't find how to do this (except of hack with sprintf("%u", ~0) - but this is ugly, IMHO).
Regards, /Al
/ Brevbäraren
Fine with me. I'll make a checkin.
/ Martin Nilsson (saturator)
Previous text:
2003-09-20 01:49: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
BTW, it would be nice to have some... uhm... preprocessor constant (or anything else) to determine native int size (and perhaps float size).
SIZEOF_INT and SIZEOF_FLOAT?
/ Martin Stjernholm, Roxen IS
If the changes truely are easy to review and fairly contained I have no objections in fixing this in 7.4. Care to make a patch tar?
BTW, it would be nice to have some... uhm... preprocessor constant (or anything else) to determine native int size (and perhaps float size). I couldn't find how to do this (except of hack with sprintf("%u", ~0)
- but this is ugly, IMHO).
I totally agree. You should be able to fix it by adding a new preprocessor symbol in cpp.c.
/ Martin Nilsson (saturator)
Previous text:
2003-09-20 01:42: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
On Sat, Sep 20, 2003 at 01:05:02AM +0200, Martin Nilsson (saturator) @ Pike (-) developers forum wrote:
feasible to backport all that to make longer ints and doubles work flawlessly in 7.4". Are you of another opinion, and if so, why?
Well... Currently, so far all the problems with long longs are related to testsuite, which is, in turn, dependent on casting to string.
64 bits int are useful in many apps which otherwise would require Gmp - it includes byte counters, etc. May be it is a bit specific to my projects (log processing, traffic accounting in particular), but I see no real problems to fix all this stuff in 7.4 too, and I don't think that this feature might be as unstable as something more sophisticated (on some architectures native int size is 64 bits anyway, or this arch support isn't planned/available in 7.4?).
BTW, it would be nice to have some... uhm... preprocessor constant (or anything else) to determine native int size (and perhaps float size). I couldn't find how to do this (except of hack with sprintf("%u", ~0) - but this is ugly, IMHO).
Regards, /Al
/ Brevbäraren
Any development consumes time, and we are disproportionally busy with an on-going discussion about random bits of this and that on the Pike development list at the moment. We might get back to coding some day.
/ Johan Sundström, Lysator
Previous text:
2003-09-20 00:52: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
On Fri, Sep 19, 2003 at 02:40:04PM +0200, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
There are numerous fixes for that in 7.5 so I suggest you continue your hunt there. I doubt it's feasible to backport all that to make longer ints and doubles work flawlessly in 7.4.
Why not in 7.4? It may take ages before 7.5 (7.6?) will be considered as stable as 7.4, while fixing this stuff seems not to be too difficult.
Finally I managed to compile 7.5, there are no problems with long long type (at least tests are OK), but as for me it would be nice to have it in 7.4-stable (I am a bit in doubt to use 7.5 in production environment).
Regards, /Al
/ Brevbäraren
I did many of those changes, and I don't work in stable versions.
You might as well conclude that "long long int" isn't fully functional in 7.4.
The solution to that problem would be to release 7.6 RSN, in my opinion, not to backport everything to 7.4.
/ Mirar
Previous text:
2003-09-20 00:52: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
On Fri, Sep 19, 2003 at 02:40:04PM +0200, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
There are numerous fixes for that in 7.5 so I suggest you continue your hunt there. I doubt it's feasible to backport all that to make longer ints and doubles work flawlessly in 7.4.
Why not in 7.4? It may take ages before 7.5 (7.6?) will be considered as stable as 7.4, while fixing this stuff seems not to be too difficult.
Finally I managed to compile 7.5, there are no problems with long long type (at least tests are OK), but as for me it would be nice to have it in 7.4-stable (I am a bit in doubt to use 7.5 in production environment).
Regards, /Al
/ Brevbäraren
I was hoping for a roadmap for a release before the conference, but it doesn't seem to want to happen. :)
In any case, 7.5 from CVS is quite stable enough to use as your normal Pike, at least if you avoid the bumps on the road, but that's easy enough checked by just running make verify before installing...
/ Mirar
Previous text:
2003-09-20 09:08: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
On Sat, Sep 20, 2003 at 08:20:01AM +0200, Mirar @ Pike developers forum wrote:
The solution to that problem would be to release 7.6 RSN, in my opinion, not to backport everything to 7.4.
OK, let's hope that it won't take too long... This year isn't too optimistic? :)
Regards, /Al
/ Brevbäraren
I think a roadmap can only be determined by features, not dates. Before 7.6 is released I'd like
- _Crypto fully replaced with Nettle. - mast talked about the codec rewriting not beging finished, so I'd like it to be. - Regexp.PCRE implemented.
/ Martin Nilsson (saturator)
Previous text:
2003-09-20 09:14: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
I was hoping for a roadmap for a release before the conference, but it doesn't seem to want to happen. :)
In any case, 7.5 from CVS is quite stable enough to use as your normal Pike, at least if you avoid the bumps on the road, but that's easy enough checked by just running make verify before installing...
/ Mirar
Yes, the resolver is a major problem. Both in the compiler and in the codec, but mostly in the codec right now. I suspect many of you have seen odd dumping errors such as "Value mismatch for num_inherits" or "Encoding of efuns is not supported yet" or similar unintelligible message. A thorough cleanup of the whole mess becomes more and more unavoidable. :P
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-20 15:01: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
I think a roadmap can only be determined by features, not dates. Before 7.6 is released I'd like
- _Crypto fully replaced with Nettle.
- mast talked about the codec rewriting not beging finished, so I'd like it to be.
- Regexp.PCRE implemented.
/ Martin Nilsson (saturator)
I meant a roadmap before the conference, not the actual release. :)
How far is those? Who is working on it?
Is there a PCRE module ready to be inserted, or is it an implementation from scratch?
/ Mirar
Previous text:
2003-09-20 15:01: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
I think a roadmap can only be determined by features, not dates. Before 7.6 is released I'd like
- _Crypto fully replaced with Nettle.
- mast talked about the codec rewriting not beging finished, so I'd like it to be.
- Regexp.PCRE implemented.
/ Martin Nilsson (saturator)
How far is those? Who is working on it?
Myself and Niels has been working on the Nettle stuff. A glue has to be written against des, 3des and cbc. Nettle has to be extended to support weak crypto keys. IDEA and the NT stuff is to be moved into the Nettle module. I'm not sure about pipe. Either it is also moved into the Nettle module or it is reimplemented in Pike.
But I shelved the project a while to work on pike security instead.
Is there a PCRE module ready to be inserted, or is it an implementation from scratch?
Well, there is a PCRE PExt module, but I didn't look at it when I did a try to make a PCRE glue.
/ Martin Nilsson (saturator)
Previous text:
2003-09-20 15:57: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
I meant a roadmap before the conference, not the actual release. :)
How far is those? Who is working on it?
Is there a PCRE module ready to be inserted, or is it an implementation from scratch?
/ Mirar
Is there anything checked in on PCRE? Otherwise I can do it, since I have absolutely nothing against reinventing the wheel... :)
/ Mirar
Previous text:
2003-09-20 16:11: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
How far is those? Who is working on it?
Myself and Niels has been working on the Nettle stuff. A glue has to be written against des, 3des and cbc. Nettle has to be extended to support weak crypto keys. IDEA and the NT stuff is to be moved into the Nettle module. I'm not sure about pipe. Either it is also moved into the Nettle module or it is reimplemented in Pike.
But I shelved the project a while to work on pike security instead.
Is there a PCRE module ready to be inserted, or is it an implementation from scratch?
Well, there is a PCRE PExt module, but I didn't look at it when I did a try to make a PCRE glue.
/ Martin Nilsson (saturator)
No. The only thing done in CVS is to make room for a Regexp.PCRE class in the Regexp module. Please go ahead. Implementationwise, the only thing I did after reading the PCRE manual was to make a few non-working configure tests (make sure PCRE is built with PCRE_CONFIG_UTF8 and make sure PCRE_CONFIG_NEWLINE is 10).
/ Martin Nilsson (saturator)
Previous text:
2003-09-20 16:15: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
Is there anything checked in on PCRE? Otherwise I can do it, since I have absolutely nothing against reinventing the wheel... :)
/ Mirar
I'll see if I can throw something together then. :-)
/ Mirar
Previous text:
2003-09-20 16:20: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
No. The only thing done in CVS is to make room for a Regexp.PCRE class in the Regexp module. Please go ahead. Implementationwise, the only thing I did after reading the PCRE manual was to make a few non-working configure tests (make sure PCRE is built with PCRE_CONFIG_UTF8 and make sure PCRE_CONFIG_NEWLINE is 10).
/ Martin Nilsson (saturator)
_Regexp_PCRE._pcre("([a-c]+).*([a-c]+)")->exec("zzajiobjio2");
(7) Result: ({ /* 6 elements */ 2, 7, 2, 3, 6, 7 })
Well, it's something... Now to make a more useful glue. :)
/ Mirar
Previous text:
2003-09-20 16:21: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
I'll see if I can throw something together then. :-)
/ Mirar
On Sat, Sep 20, 2003 at 04:20:02PM +0200, Mirar @ Pike developers forum wrote:
Is there anything checked in on PCRE? Otherwise I can do it, since I have absolutely nothing against reinventing the wheel... :)
I can offer my module. It lacks autoconf support, but generally works (at least in 7.4).
Regards, /Al
Does it have UTF8 and character tables support?
/ Mirar
Previous text:
2003-09-20 16:49: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
On Sat, Sep 20, 2003 at 04:20:02PM +0200, Mirar @ Pike developers forum wrote:
Is there anything checked in on PCRE? Otherwise I can do it, since I have absolutely nothing against reinventing the wheel... :)
I can offer my module. It lacks autoconf support, but generally works (at least in 7.4).
Regards, /Al
/ Brevbäraren
On Sat, Sep 20, 2003 at 06:55:01PM +0200, Mirar @ Pike developers forum wrote:
Does it have UTF8 and character tables support?
It is simply a glue to PCRE. There are some places which might be not UTF-8 clean, though (I am not sure). And no, there is no character tables support (yet).
Anyway, the source: http://aldem.net/pike/pcre-0.9.1-pmod.tar.bz2 (5k)
It compiles almost cleanly on 7.4.28, didn't tried on 7.5.
If it fits, let me know (I can do some more work and I can maintain it, but I might need help with autoconf - never used it).
Regards, /Al
I'm a bit far with my code now... But maybe you can send it to me so I can steal ideas and maybe some code from it? :)
/ Mirar
Previous text:
2003-09-20 21:05: Subject: Re: PCRE module
On Sat, Sep 20, 2003 at 06:55:01PM +0200, Mirar @ Pike developers forum wrote:
Does it have UTF8 and character tables support?
It is simply a glue to PCRE. There are some places which might be not UTF-8 clean, though (I am not sure). And no, there is no character tables support (yet).
Anyway, the source: http://aldem.net/pike/pcre-0.9.1-pmod.tar.bz2 (5k)
It compiles almost cleanly on 7.4.28, didn't tried on 7.5.
If it fits, let me know (I can do some more work and I can maintain it, but I might need help with autoconf - never used it).
Regards, /Al
/ Brevbäraren
So that make 3 glues for the same lib in Pike since there is also the Pexts one...
Mirar @ Pike developers forum wrote:
I'm a bit far with my code now... But maybe you can send it to me so I can steal ideas and maybe some code from it? :)
/ Mirar
Previous text:
2003-09-20 21:05: Subject: Re: PCRE module
Yes, isn't it nice? :)
/ Mirar
Previous text:
2003-09-20 21:24: Subject: Re: PCRE module
So that make 3 glues for the same lib in Pike since there is also the Pexts one...
Mirar @ Pike developers forum wrote:
I'm a bit far with my code now... But maybe you can send it to me so I can steal ideas and maybe some code from it? :)
/ Mirar
Previous text:
2003-09-20 21:05: Subject: Re: PCRE module
/ Brevbäraren
I don't think that "friction free" is a desriable property for either glue or wheels (makes it a bit difficult to steer)... :-)
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-09-20 21:27: Subject: Re: PCRE module
One of there days someone is bound to come up with a nice friction free round one. :-)
/ Peter Bortas
Unless you are aiming for Practice Effect trains.
/ Peter Bortas
Previous text:
2003-09-21 22:48: Subject: Re: PCRE module
I don't think that "friction free" is a desriable property for either glue or wheels (makes it a bit difficult to steer)... :-)
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
On Sat, Sep 20, 2003 at 09:10:02PM +0200, Mirar @ Pike developers forum wrote:
I'm a bit far with my code now... But maybe you can send it to me so I can steal ideas and maybe some code from it? :)
Sorry... Send what? :) I posted a link :) Or do you prefer email? :)
Regards, /Al
Sorry, I'm just absent-minded. :)
/ Mirar
Previous text:
2003-09-20 21:28: Subject: Re: PCRE module
On Sat, Sep 20, 2003 at 09:10:02PM +0200, Mirar @ Pike developers forum wrote:
I'm a bit far with my code now... But maybe you can send it to me so I can steal ideas and maybe some code from it? :)
Sorry... Send what? :) I posted a link :) Or do you prefer email? :)
Regards, /Al
/ Brevbäraren
Is there a PCRE module ready to be inserted, or is it an implementation from scratch?
Well, there is a PCRE PExt module, but I didn't look at it when I did a try to make a PCRE glue.
Why? It works well IMHO and is, API-wise, compatible with the normal regexp module (of course the regexps themselves aren't 100% compatible)... Ah well, lets all redo the work once more (third time's a charm, I've heard).
/ David Hedbor
Previous text:
2003-09-20 16:11: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
How far is those? Who is working on it?
Myself and Niels has been working on the Nettle stuff. A glue has to be written against des, 3des and cbc. Nettle has to be extended to support weak crypto keys. IDEA and the NT stuff is to be moved into the Nettle module. I'm not sure about pipe. Either it is also moved into the Nettle module or it is reimplemented in Pike.
But I shelved the project a while to work on pike security instead.
Is there a PCRE module ready to be inserted, or is it an implementation from scratch?
Well, there is a PCRE PExt module, but I didn't look at it when I did a try to make a PCRE glue.
/ Martin Nilsson (saturator)
PCRE glue implemented (not callback functionality or character tables, though, but that can wait until someone needs it),
now what's left?
- _Crypto fully replaced with Nettle.
- mast talked about the codec rewriting not beging finished, so I'd like it to be.
How much is left? 90% or 10%?
/ Mirar
Previous text:
2003-09-20 15:01: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
I think a roadmap can only be determined by features, not dates. Before 7.6 is released I'd like
- _Crypto fully replaced with Nettle.
- mast talked about the codec rewriting not beging finished, so I'd like it to be.
- Regexp.PCRE implemented.
/ Martin Nilsson (saturator)
Hard to say. I know that the codec/resolver stuff needs a lot of work. A lot of it has to be refactored.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-26 11:49: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
PCRE glue implemented (not callback functionality or character tables, though, but that can wait until someone needs it),
now what's left?
- _Crypto fully replaced with Nettle.
- mast talked about the codec rewriting not beging finished, so I'd like it to be.
How much is left? 90% or 10%?
/ Mirar
this will be the topic of this mornings session at the conference (see the updated timetable: http://steam.upb.de/conferences/pike2003/timetable.xml )
if you have any suggestions to make that you want us to discuss, please share them...
greetings, martin.
I don't know, it looks like the blocker is projects that can only be finished by a handful of people... Will these be at the Pike conference?
But a roadmap is certainly interesting to discuss on the conference - that would be not just of 7.6.
/ Mirar
Previous text:
2003-09-27 08:17: Subject: the future of pike
this will be the topic of this mornings session at the conference (see the updated timetable: http://steam.upb.de/conferences/pike2003/timetable.xml )
if you have any suggestions to make that you want us to discuss, please share them...
greetings, martin.
Pike Conference 2003 - Sep 25-27 - http://pike.ida.liu.se/conferences/2003/
interested in doing pike programming, sTeam/caudium/pike/roxen training, sTeam/caudium/roxen and/or unix system administration anywhere in the world. -- pike programmer working in europe open-steam.org unix system- bahai.or.at iaeste.(tuwien.ac|or).at administrator (stuts|black.linux-m68k).org is.(schon.org|root.at) Martin Bähr http://www.iaeste.or.at/~mbaehr/
/ Brevbäraren
On Sat, Sep 27, 2003 at 08:30:01AM +0200, Mirar @ Pike developers forum wrote:
Will these be at the Pike conference?
the people or the projects? and which projects do you mean?
the roadmap is certainly going beyond 7.6 (depending on what issues are brought up)
greetings, martin.
These people:
- _Crypto fully replaced with Nettle.
- mast talked about the codec rewriting not beging finished, so I'd like it to be.
:-)
/ Mirar
Previous text:
2003-09-27 10:55: Subject: Re: the future of pike
On Sat, Sep 27, 2003 at 08:30:01AM +0200, Mirar @ Pike developers forum wrote:
Will these be at the Pike conference?
the people or the projects? and which projects do you mean?
the roadmap is certainly going beyond 7.6 (depending on what issues are brought up)
greetings, martin.
/ Brevbäraren
nilsson also suggest pike security, at least as far as maybe necessary changes that would break compatibility are concerned, so that they are out of the way as soon as possible.
greetings, martin.
beyond 7.6:
overloading (variant) new compiler new regexp engine (mast) gtk2 add module repository and trim core new windows build procedure
i am displaying messages or chat to the wall, so you can send messages to the conference.
current topic is pike embeddability
greetings, martin.
I have a little list in 10718200.
/ Martin Nilsson (saturator)
Previous text:
2003-09-26 11:49: Subject: Re: bug: casts to string for long double and long long int are incorrect (7.4.28 rel)
PCRE glue implemented (not callback functionality or character tables, though, but that can wait until someone needs it),
now what's left?
- _Crypto fully replaced with Nettle.
- mast talked about the codec rewriting not beging finished, so I'd like it to be.
How much is left? 90% or 10%?
/ Mirar
pike-devel@lists.lysator.liu.se
-
Alexander Demenshin -
David Gourdelier -
David Hedbor ＠ Pike developers forum -
Johan Sundstr�m, Lysator ＠ Pike developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Baehr -
Martin Nilsson (saturator) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Peter Bortas ＠ Pike developers forum