Ok, I noticed the following inconsistency.
Stdio.is_dir() <=> Stdio.Stat->isdir Stdio.is_file() <=> Stdio.Stat->isfile
etc. Wouldn't it be logical if these were named the same rather? I vote for is_dir etc since that is generally the naming convention used in Pike.
isdir etc would have to stay for compatibility, and I don't think it gets any prettier if duplicate names for all of them are added.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-06 21:14: Subject: Inconsistency.
Ok, I noticed the following inconsistency.
Stdio.is_dir() <=> Stdio.Stat->isdir Stdio.is_file() <=> Stdio.Stat->isfile
etc. Wouldn't it be logical if these were named the same rather? I vote for is_dir etc since that is generally the naming convention used in Pike.
/ David Hedbor
Yes, it is. It's one among many small uglinesses that only gets worse if one tries to fix them. Maybe we could start a very unofficial and experimental fork where we fix all such inconsistencies and other design mistakes that have been made during the years. Eventually, when everything is so neat, flawless and shiny that we gotta wear shades around it, we could release it as a descendant of Pike (with a shiny new name too, of course).
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-06 21:47: Subject: Inconsistency.
Understood yes. It's unfortunate IMHO.
/ David Hedbor
On Mon, Jan 06, 2003 at 10:00:02PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Yes, it is. It's one among many small uglinesses that only gets worse if one tries to fix them. Maybe we could start a very unofficial and experimental fork where we fix all such inconsistencies and other design mistakes that have been made during the years.
how about pragma "consistent" that one can turn on if desired just like turning on backwards compatibility...
greetings, martin.
That doesn't address the central issue, which is that there will be two slightly different languages that have the same name. We can device any amount of pragmas and fancy compatibility systems, but every time we do we also invariably add complexity which makes everything more confusing for users. I.e. it gets harder to understand what is meant with the language "Pike".
I think it only could be worth the added confusion if all these ugly spots are fixed in one go, where "fixed" implies that there are no compatibility kludges. This gives a language that is close to but not quite Pike, and the best way then to limit the confusion is to call it something else.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-06 22:10: Subject: Re: Inconsistency.
On Mon, Jan 06, 2003 at 10:00:02PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Yes, it is. It's one among many small uglinesses that only gets worse if one tries to fix them. Maybe we could start a very unofficial and experimental fork where we fix all such inconsistencies and other design mistakes that have been made during the years.
how about pragma "consistent" that one can turn on if desired just like turning on backwards compatibility...
greetings, martin.
/ Brevbäraren
That would have to be one huge massive kludge of uggly to justify something as drastic as a change of name.
Sure, the problem might be solved temporarilly. The same problem will come back in due time. In the meantime, the language previously known as pike will loose momentum and in the third or fourth incarnation it will probably be dead outside of the core. Just look at what happened to bash and bash2. Sure, some people use bash2 for the added features - most people still havent bothered even though it is their most used application. It's just not worth the PITA to upgrade.
I'd vore for every now and then (with a major release?) dropping backwardscompability. Perhaps there should be some sort of hefty penalty for commiting code that doesn't follow the official pike naming conventions (which BTW is something that I've completetly failed to get any sort of grips on).
/ Peter Lundqvist (disjunkt)
Previous text:
2003-01-06 22:31: Subject: Re: Inconsistency.
That doesn't address the central issue, which is that there will be two slightly different languages that have the same name. We can device any amount of pragmas and fancy compatibility systems, but every time we do we also invariably add complexity which makes everything more confusing for users. I.e. it gets harder to understand what is meant with the language "Pike".
I think it only could be worth the added confusion if all these ugly spots are fixed in one go, where "fixed" implies that there are no compatibility kludges. This gives a language that is close to but not quite Pike, and the best way then to limit the confusion is to call it something else.
/ Martin Stjernholm, Roxen IS
On Mon, Jan 06, 2003 at 10:50:01PM +0100, Peter Lundqvist (disjunkt) @ Pike (-) developers forum wrote:
Just look at what happened to bash and bash2. Sure, some people use bash2 for the added features - most people still havent bothered even though it is their most used application. It's just not worth the PITA to upgrade.
hmm? most people will use what ever their distribution provides, and that IS bash2 i don't see your point. those people that would have to upgrade don't because there is only so much of features a shell can provide.
compare to pike with improves drasticly with every release.
I'd vore for every now and then (with a major release?) dropping backwardscompability.
that is done. you don't get backwards compatibility unless you turn it on specificly.
greetings, martin.
hmm? most people will use what ever their distribution provides, and that IS bash2 i don't see your point. those people that would have to upgrade don't because there is only so much of features a shell can provide.
Modern systems? When they work and are patched everywhere needed? Jesus, I'm currently writing code on a machine that originally was a RedHat 5.2 (but /etc/issue file is not the oldest, it has probably suffered an upgrade).
Everytime when I come here I plea for a kernel uppgrade so that OpenSSH can compile with privelege separation. But that won't happen. The server has been up for replacement the last two years... (Ok, initially my complaint wasn't OpenSSH, I forgot what).
I'd vore for every now and then (with a major release?) dropping backwardscompability.
that is done. you don't get backwards compatibility unless you turn it on specificly.
Well, cool then. Just shuffle the ugglyness away in the 7.4 corner.
/ Peter Lundqvist (disjunkt)
Previous text:
2003-01-06 23:01: Subject: Re: Inconsistency.
On Mon, Jan 06, 2003 at 10:50:01PM +0100, Peter Lundqvist (disjunkt) @ Pike (-) developers forum wrote:
Just look at what happened to bash and bash2. Sure, some people use bash2 for the added features - most people still havent bothered even though it is their most used application. It's just not worth the PITA to upgrade.
hmm? most people will use what ever their distribution provides, and that IS bash2 i don't see your point. those people that would have to upgrade don't because there is only so much of features a shell can provide.
compare to pike with improves drasticly with every release.
I'd vore for every now and then (with a major release?) dropping backwardscompability.
that is done. you don't get backwards compatibility unless you turn it on specificly.
greetings, martin.
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 csl-gmbh.net open-steam.org (www.archlab|(www|db).hb2).tuwien.ac.at unix bahai.or.at iaeste.(tuwien.ac|or).at systemadministrator (stuts|black.linux-m68k).org is.(schon.org|root.at) Martin Bähr http://www.iaeste.or.at/~mbaehr/
/ Brevbäraren
I don't think the effect would only be temporary. A number of core issues could be fixed, and very detailed guidelines for the libraries could (and should) be written and enacted. The amount of ugliness that still could creep in after that would be a lot less. I'm pretty sure it would not ever become even a tenth of the current amount.
But you're entirely right that yet another language is anything but wanted today. The comparison with bash doesn't quite hold, though; the difference is that bash already has a large user base whereas Pike do not. I.e. there is comparatively little momentum to loose. Also, the users are probably more concerned with the compatibility aspects than the name since it's the incompatibilities that would make a transfer difficult.
Even so, a considerable effort has went into the branding of the name "Pike" so we must of course consider very carefully whether to release this new language under a new name, or perhaps the same name with "incompatible" printed all over it, or at all. That's why I thought it should only be very unofficial fork(*) for the time being. Just a toy that we can play with, to see how it turns out. Only when it starts to get very good we might begin to ponder how to release it.
*) With "fork" I mean "cvs fork", not "project fork" with its own web site etc.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-06 22:45: Subject: Re: Inconsistency.
That would have to be one huge massive kludge of uggly to justify something as drastic as a change of name.
Sure, the problem might be solved temporarilly. The same problem will come back in due time. In the meantime, the language previously known as pike will loose momentum and in the third or fourth incarnation it will probably be dead outside of the core. Just look at what happened to bash and bash2. Sure, some people use bash2 for the added features - most people still havent bothered even though it is their most used application. It's just not worth the PITA to upgrade.
I'd vore for every now and then (with a major release?) dropping backwardscompability. Perhaps there should be some sort of hefty penalty for commiting code that doesn't follow the official pike naming conventions (which BTW is something that I've completetly failed to get any sort of grips on).
/ Peter Lundqvist (disjunkt)
iPike? It fits quite well in speech though... *burns in hell*
/ Peter Lundqvist (disjunkt)
Previous text:
2003-01-06 23:21: Subject: Re: Inconsistency.
I don't think the effect would only be temporary. A number of core issues could be fixed, and very detailed guidelines for the libraries could (and should) be written and enacted. The amount of ugliness that still could creep in after that would be a lot less. I'm pretty sure it would not ever become even a tenth of the current amount.
But you're entirely right that yet another language is anything but wanted today. The comparison with bash doesn't quite hold, though; the difference is that bash already has a large user base whereas Pike do not. I.e. there is comparatively little momentum to loose. Also, the users are probably more concerned with the compatibility aspects than the name since it's the incompatibilities that would make a transfer difficult.
Even so, a considerable effort has went into the branding of the name "Pike" so we must of course consider very carefully whether to release this new language under a new name, or perhaps the same name with "incompatible" printed all over it, or at all. That's why I thought it should only be very unofficial fork(*) for the time being. Just a toy that we can play with, to see how it turns out. Only when it starts to get very good we might begin to ponder how to release it.
*) With "fork" I mean "cvs fork", not "project fork" with its own web site etc.
/ Martin Stjernholm, Roxen IS
I think changing the name and/or forking Pike now or in the future would be very bad - I actually start running into unrelated people online that actually use and/or know of and like Pike. Changing the name would undermine that.
/ David Hedbor
Previous text:
2003-01-06 23:21: Subject: Re: Inconsistency.
I don't think the effect would only be temporary. A number of core issues could be fixed, and very detailed guidelines for the libraries could (and should) be written and enacted. The amount of ugliness that still could creep in after that would be a lot less. I'm pretty sure it would not ever become even a tenth of the current amount.
But you're entirely right that yet another language is anything but wanted today. The comparison with bash doesn't quite hold, though; the difference is that bash already has a large user base whereas Pike do not. I.e. there is comparatively little momentum to loose. Also, the users are probably more concerned with the compatibility aspects than the name since it's the incompatibilities that would make a transfer difficult.
Even so, a considerable effort has went into the branding of the name "Pike" so we must of course consider very carefully whether to release this new language under a new name, or perhaps the same name with "incompatible" printed all over it, or at all. That's why I thought it should only be very unofficial fork(*) for the time being. Just a toy that we can play with, to see how it turns out. Only when it starts to get very good we might begin to ponder how to release it.
*) With "fork" I mean "cvs fork", not "project fork" with its own web site etc.
/ Martin Stjernholm, Roxen IS
That said, I still maintain that a Pike 8 branch, similar to the whole Perl 6 thing, would make sense. However I don't think we should have TWO development trees - having a total of 3 active trees probably would be a bad idea.
/ David Hedbor
Previous text:
2003-01-06 23:25: Subject: Re: Inconsistency.
I think changing the name and/or forking Pike now or in the future would be very bad - I actually start running into unrelated people online that actually use and/or know of and like Pike. Changing the name would undermine that.
/ David Hedbor
Yes, it's a good idea to call the new language "Pike 8". That'd avoid throwing out much of the branding investment in the name "Pike". We'd then have the two languages "Pike 7" and "Pike 8". The drawback is that the name "Pike" would become even more ambiguous.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-06 23:27: Subject: Re: Inconsistency.
That said, I still maintain that a Pike 8 branch, similar to the whole Perl 6 thing, would make sense. However I don't think we should have TWO development trees - having a total of 3 active trees probably would be a bad idea.
/ David Hedbor
Well, it would make sense to people. We have Emacs 18, 19, 20 and 21. Everyone knows that it's in essence the same program but that something written for 21 won't work in 19 (most lilely) and quite possibly the other way around. Ditty with Perl 4 and Perl 5 - I don't know perl but afaik those have many incompatibilites.
Also, it's really not different from what we already have - Pike 0.5, 0.6, 7.0, 7.2, 7.4 - they are often very incompatible (especially backwards - try porting a modern Pike 7.4 program to Pike 0.5 or even 0.6).
Just because we are considered "stable" (which one can argue pike 0.5 and 0.6 were not I guess), doesn't mean we can't change.
/ David Hedbor
Previous text:
2003-01-06 23:39: Subject: Re: Inconsistency.
Yes, it's a good idea to call the new language "Pike 8". That'd avoid throwing out much of the branding investment in the name "Pike". We'd then have the two languages "Pike 7" and "Pike 8". The drawback is that the name "Pike" would become even more ambiguous.
/ Martin Stjernholm, Roxen IS
On Mon, Jan 06, 2003 at 11:50:01PM +0100, David Hedbor @ Pike developers forum wrote:
Ditty with Perl 4 and Perl 5 - I don't know perl but afaik those have many incompatibilites.
yup, and just wait until perl 6 comes around, which is a rewrite from scratch. php3/4 also comes to mind.
Of course, Pike is much better off to begin with so we're doing fine. :) Pike doesn't need as major of a rewrite as some... other languages have had in the past. :-)
/ David Hedbor
Previous text:
2003-01-07 00:00: Subject: Re: Inconsistency.
On Mon, Jan 06, 2003 at 11:50:01PM +0100, David Hedbor @ Pike developers forum wrote:
Ditty with Perl 4 and Perl 5 - I don't know perl but afaik those have many incompatibilites.
yup, and just wait until perl 6 comes around, which is a rewrite from scratch. php3/4 also comes to mind.
/ Brevbäraren
On Tue, Jan 07, 2003 at 12:05:01AM +0100, David Hedbor @ Pike developers forum wrote:
Of course, Pike is much better off to begin with so we're doing fine. :) Pike doesn't need as major of a rewrite as some... other languages have had in the past. :-)
well, pike had its rewrite time too, didn't it? if not, you can definetly count lpc4 -> ulpc as a rewrite
I don't think lpc4->µLPC really counts but in a sense I guess it is a rewrite. After that though, major things have changed but the code has never been rewritten from scratch in general.
/ David Hedbor
Previous text:
2003-01-07 00:11: Subject: Re: Inconsistency.
On Tue, Jan 07, 2003 at 12:05:01AM +0100, David Hedbor @ Pike developers forum wrote:
Of course, Pike is much better off to begin with so we're doing fine. :) Pike doesn't need as major of a rewrite as some... other languages have had in the past. :-)
well, pike had its rewrite time too, didn't it? if not, you can definetly count lpc4 -> ulpc as a rewrite
/ Brevbäraren
On Tue, Jan 07, 2003 at 12:15:04AM +0100, David Hedbor @ Pike developers forum wrote:
I don't think lpc4->µLPC really counts but in a sense I guess it is a rewrite. After that though, major things have changed but the code has never been rewritten from scratch in general.
well it counts because pike is a redesign of lpc, and a lot was learned from it. contrary to other languages which start with nothing.
when people ask me about pike, i tell them it was invented in 1988 (or thereabouts) and therefore is a lot older than php or python.
greetings, martin.
try porting a modern Pike 7.4 program to Pike 0.5 or even 0.6).
That's forward compatibility to me, and that's something I merrily ignore in all circumstances with the single exception of the format in encode_value strings.
I consider all backward compatibility problems since the introduction of #pike to be bugs. (Of course, there's always the question whether a certain change is a compatibility issue or merely a bugfix.)
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-06 23:45: Subject: Re: Inconsistency.
Well, it would make sense to people. We have Emacs 18, 19, 20 and 21. Everyone knows that it's in essence the same program but that something written for 21 won't work in 19 (most lilely) and quite possibly the other way around. Ditty with Perl 4 and Perl 5 - I don't know perl but afaik those have many incompatibilites.
Also, it's really not different from what we already have - Pike 0.5, 0.6, 7.0, 7.2, 7.4 - they are often very incompatible (especially backwards - try porting a modern Pike 7.4 program to Pike 0.5 or even 0.6).
Just because we are considered "stable" (which one can argue pike 0.5 and 0.6 were not I guess), doesn't mean we can't change.
/ David Hedbor
I actually meet more people that knows what µLPC is. Scary.
/ Peter Lundqvist (disjunkt)
Previous text:
2003-01-06 23:25: Subject: Re: Inconsistency.
I think changing the name and/or forking Pike now or in the future would be very bad - I actually start running into unrelated people online that actually use and/or know of and like Pike. Changing the name would undermine that.
/ David Hedbor
It's surprising actually. Mostly it's people who are senior programmers who has some knowledge of spinner, and not that surprislingly, MUD. Last summer I had a really interresting conversation with a person who was verry happy to know that the language has evolved. The thing that finally made him, sadly, drop his interrest was the lack of win32-widget support which he for some unknown reason prefered.
Although last time I saw him he had a Pike-Hilfe icon on his quickstart bar =)
BTW, is there a manual on hilfe somewhere (on the pike site perhaps)?
/ Peter Lundqvist (disjunkt)
Previous text:
2003-01-06 23:42: Subject: Re: Inconsistency.
Now THAT scares me greatly! :)
/ David Hedbor
win32-widget support which he for some unknown reason prefered.
Preferred over GTK or preferred over no GUI? Personally I'd like to see Qt-support since Qt actually is the nicer of GTK/Qt when it comes to programming API and widget set. Of course I wouldn't want to be the one writing the API - C++ and Pike => no fun (not to mention it's a large API :-).
Of course, GTK has Glade which is nice because of libglade (while in Qt you have .ui files that get converted to C++ - not so useful for a wrapper).
Although last time I saw him he had a Pike-Hilfe icon on his quickstart bar =)
BTW, is there a manual on hilfe somewhere (on the pike site perhaps)?
'help' within hilfe?
/ David Hedbor
Previous text:
2003-01-06 23:51: Subject: Re: Inconsistency.
It's surprising actually. Mostly it's people who are senior programmers who has some knowledge of spinner, and not that surprislingly, MUD. Last summer I had a really interresting conversation with a person who was verry happy to know that the language has evolved. The thing that finally made him, sadly, drop his interrest was the lack of win32-widget support which he for some unknown reason prefered.
Although last time I saw him he had a Pike-Hilfe icon on his quickstart bar =)
BTW, is there a manual on hilfe somewhere (on the pike site perhaps)?
/ Peter Lundqvist (disjunkt)
I only end up cursing using Qt. But better object orientation with GTK would be nice. Haven't played at all with gtkX.X_mm but it seems to move along.
/ Peter Lundqvist (disjunkt)
Previous text:
2003-01-06 23:55: Subject: Re: Inconsistency.
win32-widget support which he for some unknown reason prefered.
Preferred over GTK or preferred over no GUI? Personally I'd like to see Qt-support since Qt actually is the nicer of GTK/Qt when it comes to programming API and widget set. Of course I wouldn't want to be the one writing the API - C++ and Pike => no fun (not to mention it's a large API :-).
Of course, GTK has Glade which is nice because of libglade (while in Qt you have .ui files that get converted to C++ - not so useful for a wrapper).
Although last time I saw him he had a Pike-Hilfe icon on his quickstart bar =)
BTW, is there a manual on hilfe somewhere (on the pike site perhaps)?
'help' within hilfe?
/ David Hedbor
How so? I find Qt a very consistent and nice API with a good designer tool (that is, designer for Qt3 at least). GTK in Pike is very nicely object oriented btw. Never really used it from C (where it's quite horrid) or C++.
/ David Hedbor
Previous text:
2003-01-07 00:01: Subject: Re: Inconsistency.
I only end up cursing using Qt. But better object orientation with GTK would be nice. Haven't played at all with gtkX.X_mm but it seems to move along.
/ Peter Lundqvist (disjunkt)
Well. The most I've used GTK in pike is to produce alertboxes =) That will probably change if I can find the time.
The problems that I've had with Qt are mostly their horrid preprocessors and macros not doing what I would expect (since they aren't really C++). I did some modifications to make corporate ICQ work with a newer Qt (it was som russian clone of it that I found).
One thing that I adore in Qt though is their documentation (and that's shockingly awfull in GTK-land if you compare).
My main reason for staying with GTK though is that I like a lot of Gnome-software (over similar KDE apps) and I just refuse to install evereything and then some on my box.
/ Peter Lundqvist (disjunkt)
Previous text:
2003-01-07 00:04: Subject: Re: Inconsistency.
How so? I find Qt a very consistent and nice API with a good designer tool (that is, designer for Qt3 at least). GTK in Pike is very nicely object oriented btw. Never really used it from C (where it's quite horrid) or C++.
/ David Hedbor
The signals/slots are kind of magic but once I understood how they work, I pretty much was ok with it. I can definitely see it being a common issue one would have with Qt.
As for documentation - yes, Qt is so much better in this department. I guess that is a typical example of Commercial vs pure opensource - people that are paid to write documentation...
And yes, funnily enough I tend to prefer GTK apps over Qt apps, but I'm guessing it's not necessarily Qt's fault...
/ David Hedbor
Previous text:
2003-01-07 00:31: Subject: Re: Inconsistency.
Well. The most I've used GTK in pike is to produce alertboxes =) That will probably change if I can find the time.
The problems that I've had with Qt are mostly their horrid preprocessors and macros not doing what I would expect (since they aren't really C++). I did some modifications to make corporate ICQ work with a newer Qt (it was som russian clone of it that I found).
One thing that I adore in Qt though is their documentation (and that's shockingly awfull in GTK-land if you compare).
My main reason for staying with GTK though is that I like a lot of Gnome-software (over similar KDE apps) and I just refuse to install evereything and then some on my box.
/ Peter Lundqvist (disjunkt)
Besides, I don't think it's ugly. (And there is no isfile in Stat.) I rather have similar naming to the C/posix usage, even if ugly, then pike-style inserted underscores, for things that are a direct translation of C/posix conventions.
It might be misfortunate that there are similar/related functions that have different naming conventions, though.
/ Mirar
Previous text:
2003-01-06 21:59: Subject: Inconsistency.
Yes, it is. It's one among many small uglinesses that only gets worse if one tries to fix them. Maybe we could start a very unofficial and experimental fork where we fix all such inconsistencies and other design mistakes that have been made during the years. Eventually, when everything is so neat, flawless and shiny that we gotta wear shades around it, we could release it as a descendant of Pike (with a shiny new name too, of course).
/ Martin Stjernholm, Roxen IS
Ok, is_file was a mistake. The point is still there - there is no reason for them to have different naming. I'm sure there's other examples too though.
In either case, I don't like the idea of a silent fork to fix these issues to later release a "new" Pike. Rather I'd like to see a Pike 8 or what not which might not necessarily be backwards compatible - it's nothing wrong with that per se - major version number == possibly incompatible API with previous versions.
Iff incompatible changes were well documented I think it'd be great in the long run (note, this isn't so different from the stronger type checking and disallowing of equally named local variables - that change broke A LOT of code (just about any larger piece of Pike code I've used has at least one issue like this).
So my vote is that pike 7.5 (ir 7.7) will become Pike 8 where inconsistencies like this can be fixed and documented. Also it should probably include a lot of cleaning up (i.e modules using old module API's updated to use new ones, or even the cmod API and other such things (removing the 'spider' module is something that comes to mind too :-)).
/ David Hedbor
Previous text:
2003-01-06 22:16: Subject: Inconsistency.
Besides, I don't think it's ugly. (And there is no isfile in Stat.) I rather have similar naming to the C/posix usage, even if ugly, then pike-style inserted underscores, for things that are a direct translation of C/posix conventions.
It might be misfortunate that there are similar/related functions that have different naming conventions, though.
/ Mirar
That said, is there a roadmap for what the future Pike 7.6 will be? I.e any plans, ideas, TODO's for Pike 7.5 before the next stable branch?
/ David Hedbor
Previous text:
2003-01-06 22:58: Subject: Inconsistency.
Ok, is_file was a mistake. The point is still there - there is no reason for them to have different naming. I'm sure there's other examples too though.
In either case, I don't like the idea of a silent fork to fix these issues to later release a "new" Pike. Rather I'd like to see a Pike 8 or what not which might not necessarily be backwards compatible - it's nothing wrong with that per se - major version number == possibly incompatible API with previous versions.
Iff incompatible changes were well documented I think it'd be great in the long run (note, this isn't so different from the stronger type checking and disallowing of equally named local variables - that change broke A LOT of code (just about any larger piece of Pike code I've used has at least one issue like this).
So my vote is that pike 7.5 (ir 7.7) will become Pike 8 where inconsistencies like this can be fixed and documented. Also it should probably include a lot of cleaning up (i.e modules using old module API's updated to use new ones, or even the cmod API and other such things (removing the 'spider' module is something that comes to mind too :-)).
/ David Hedbor
That would be really fun to know. Was there a plan to rewrite the backend for the XML parser? Any chance of seeing support for parsing XSLT/XPATH in pike (not that I'd use it)?
This would be cool information too have on the website. It sort of gives an illusion of moving forwards...
//Peter - runs off in every direction to avoid buttkicking developers
/ Peter Lundqvist (disjunkt)
Previous text:
2003-01-06 23:00: Subject: Inconsistency.
That said, is there a roadmap for what the future Pike 7.6 will be? I.e any plans, ideas, TODO's for Pike 7.5 before the next stable branch?
/ David Hedbor
I was writing on something like that before christmas:
With Pike 7.4 bottled, what new flavours and colours might the Pike product dept. have planned for Pike 7.6? Planned is perhaps not quite the word when we don't intend to do the acutal work for most action points. Wishlist is more correct, and not without a slight seasonal touch.
- Replace the Crypto module with Nettle. Niels Möller has done some attempts and should be encouraged to continue.
- Rewrite the I/O stuff. Per Hedbor has some architectural ideas that he hopefully will share in a digestable form that will be inspiring enough for some people to dig into this big and delicate task. Unfortunately I'm not that hopeful that it will happen though.
- GTK 2 support. Per Hedbor has begun a rewrite of PiGTK and since the API deprecation pace of GTK isn't as high as it used to be, it might be ready while it still is possible to link to a recent GTK.
- IPv6 support made a quick appearance in Pike 7.3 but caused to much breakage on AutoBuild machines. With Xenofarm it should be much easier to diagnose and fix these problems. Note that all code that deals with IP numbers, sunch as protocol modules, will have to be reviewed and updated before we can say Pike is IPv6 compliant.
Then I had a train to catch... (And I didn't check with Per if he really had a rewrite idea for the I/O, but he hinted it half a year ago or so). I can dicrectly add that a well thought through system for external modules should be added before Pike 7.6 is released.
Looking at Pike management the single most wanted issue is to install an issue tracker on the Pike site. I don't have time for it, but unless Johan Sundström has a hidden agenda (pun intended) he should be able to pull it off before February.
/ Martin Nilsson (bygger parser
Previous text:
2003-01-06 23:00: Subject: Inconsistency.
That said, is there a roadmap for what the future Pike 7.6 will be? I.e any plans, ideas, TODO's for Pike 7.5 before the next stable branch?
/ David Hedbor
On Tue, Jan 07, 2003 at 01:20:03AM +0100, Martin Nilsson (bygger parser @ Pike (-) developers forum wrote:
Looking at Pike management the single most wanted issue is to install an issue tracker on the Pike site. I don't have time for it, but unless Johan Sundström has a hidden agenda (pun intended) he should be able to pull it off before February.
hmm, how much different from a bug tracker is that?or are you talking about a new bugtracker independent from RIS (thats the one still in use, right?)
greetings, martin.
I am talking about a new bugtracker, independent from RIS. I think that using Bugzilla would do. Bugzillas visualization sucks, but since we can read the mysql we can make our own "export" into pages like "Most wanted new feature".
We should also try to make an effort getting the Special Interest Groups up and running. The problem is that you should really have quite a bit of content before you divide it into special groups, and then we risk getting the community.roxen.com-problem again, where only I was writing a lot of articles.
/ Martin Nilsson (bygger parser
Previous text:
2003-01-07 01:32: Subject: Re: Inconsistency.
On Tue, Jan 07, 2003 at 01:20:03AM +0100, Martin Nilsson (bygger parser @ Pike (-) developers forum wrote:
Looking at Pike management the single most wanted issue is to install an issue tracker on the Pike site. I don't have time for it, but unless Johan Sundström has a hidden agenda (pun intended) he should be able to pull it off before February.
hmm, how much different from a bug tracker is that?or are you talking about a new bugtracker independent from RIS (thats the one still in use, right?)
greetings, martin.
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 csl-gmbh.net open-steam.org (www.archlab|(www|db).hb2).tuwien.ac.at unix bahai.or.at iaeste.(tuwien.ac|or).at systemadministrator (stuts|black.linux-m68k).org is.(schon.org|root.at) Martin Bähr http://www.iaeste.or.at/~mbaehr/
/ Brevbäraren
On Tue, Jan 07, 2003 at 01:40:01AM +0100, Martin Nilsson (bygger parser @ Pike (-) developers forum wrote:
We should also try to make an effort getting the Special Interest Groups up and running. The problem is that you should really have quite a bit of content before you divide it into special groups, and then we risk getting the community.roxen.com-problem again, where only I was writing a lot of articles.
yes, true, sigs should only be set up one at a time, as the need comes around.
greetings, martin.
The problem is that you can't do it like that initially. Besides the fact that it would look silly to just have one SIG, you would also have to redesign the layout, structure and stuff quite often when you add new SIGs. One should preferably start with a few good ones (Web applications, System administration tools, Graphics programming, Pike core development) and make them look good and interesting. Then release and hope it grows. Though, we should probably have a SIG-master assigned for each SIG if we are to expect any resemblance of activity... Getting unprovoked activity (or even provoked one) is the hardest. There are 25 accounts that have write permission on the pike site. Essentially only mine and Johans are used.
/ Martin Nilsson (bygger parser
Previous text:
2003-01-07 01:47: Subject: Re: Inconsistency.
On Tue, Jan 07, 2003 at 01:40:01AM +0100, Martin Nilsson (bygger parser @ Pike (-) developers forum wrote:
We should also try to make an effort getting the Special Interest Groups up and running. The problem is that you should really have quite a bit of content before you divide it into special groups, and then we risk getting the community.roxen.com-problem again, where only I was writing a lot of articles.
yes, true, sigs should only be set up one at a time, as the need comes around.
greetings, martin.
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 csl-gmbh.net open-steam.org (www.archlab|(www|db).hb2).tuwien.ac.at unix bahai.or.at iaeste.(tuwien.ac|or).at systemadministrator (stuts|black.linux-m68k).org is.(schon.org|root.at) Martin Bähr http://www.iaeste.or.at/~mbaehr/
/ Brevbäraren
The AbiWord project has something that might be useful. In their newsletters (and I suspect elsewhere) they have something called POWs, an achronym for Project Of the Week, that are basicly of the form (text after '<--' is my own added comment):
Name: 4465 <-- this is a bug nr. (not necessarily) Description: This bug contains a compilation of numerous spelling-related bugs. Interested parties can do simple work, like Q&A to see what's still there, to more complex work, like dialogue fixin' and locale conversion If you have a current Abi and some time, you, too, can help Advertisement: My spelring dilog isn nt ther Recommended Outline: Whatever's easiest for you Comments: All in all, there's something for everyone in there. System: Any and every OS. AbiVersion: Current (1.0.3, I would guess, dev and cvs releases may occur as well) Challenge level: Variable Current Heros: First week available <-- a sort of history
It might be useful to have a special type of bug of this sort just to get people started. My own problem usually is that my time is verry limited therefore I forget interresting little jobs that I might, with or without some help, be able to do.
The problem with writing these sort of bugs is that you tend to fix them yourself (I've been using this for a project I'm handing over to someone else), but if you really focus att setting the bar low and *not* doing them yourself it may really pay off.
I dunno. It's just a simple suggestion.
/ Peter Lundqvist (disjunkt)
Previous text:
2003-01-07 01:59: Subject: Re: Inconsistency.
The problem is that you can't do it like that initially. Besides the fact that it would look silly to just have one SIG, you would also have to redesign the layout, structure and stuff quite often when you add new SIGs. One should preferably start with a few good ones (Web applications, System administration tools, Graphics programming, Pike core development) and make them look good and interesting. Then release and hope it grows. Though, we should probably have a SIG-master assigned for each SIG if we are to expect any resemblance of activity... Getting unprovoked activity (or even provoked one) is the hardest. There are 25 accounts that have write permission on the pike site. Essentially only mine and Johans are used.
/ Martin Nilsson (bygger parser
Yep. Giving out small assignments and pretending that you need help with them is probably a good idea, but it makes you feel like a kindergarten teacher cheating children into doing something.
Speaking of small assignments... I've made a lot of notes for new chapters in the manual. I don't have time to do anything with them now, but if someone wants to be a real hero and help Pike where it is currently weakest, then please do.
<chapter title="Preprocessor">
<section title="Predefined defines"> <!-- <insert-move entity="define::"/> --> </section>
<!--
ANSI/DEC escape sequences will be treated as white spaces. Format supported: <ESC>[\040-\077]+[\100-\177] and <CSI>[\040-\077]*[\100-\177]
Six "<" in a row will generate an "CVS conflict detected." error.
#if defined(X) efun(X) constant(X)
#! #line, 0-9 #" " #string #include " " < > #ifdef #ifndef #endif #else #elseif #elif #error #define ... varargs maxargs=255 #define A(x,y,z) x##y##z #undef #undefine #charset #pragma all_inline all_nomask strict_types save_parent dont_save_parent #pike
Initial charset heuristic:
Index 0 | Index 1 | Interpretation --------+---------+------------------------------------------ 0 | 0 | 32bit wide string. 0 | >0 | 16bit Unicode string. >0 | 0 | 16bit Unicode string reverse byte order. 0xfe | 0xff | 16bit Unicode string. 0xff | 0xfe | 16bit Unicode string reverse byte order. 0x7b | 0x83 | EBCDIC-US ("#c"). 0x7b | 0x40 | EBCDIC-US ("# "). 0x7b | 0x09 | EBCDIC-US ("#\t"). --------+---------+------------------------------------------ Other | Other | 8bit standard string.
The file must be an multiple of 4 or 2 bytes in order to be correctly decoded as 32bit or 16bit wide string.
It's an error for a program written in EBCDIC not to start with a #charset directive.
* * Obfuscation note: * * * This still allows the rest of the file to be written in * another encoding than EBCDIC.
-->
</chapter>
<chapter title="Using Pike">
<section title="Running Pike">
<subsection title="Command line arguments">
<matrix> <r><c>-V #, --compat #</c><c>compat_version #=%d.%d</c></r> <r><c>-v --version</c><c>version</c></r> <r><c>-h --help</c><c>help</c></r> <r><c>--features</c><c>features</c></r> <r><c>--info</c><c>info</c></r> <r><c>-e #, --execute #</c><c>execute</c></r> <r><c>--debug-without #</c><c>debug_without #=x,x,...</c></r> <r><c>-E #, --preprocess #</c><c>preprocess</c></r> <r><c>-M #, --module-path #</c><c>modpath</c></r> <r><c>-I #, --include-path #</c><c>ipath</c></r> <r><c>-P #, --program-path #</c><c>ppath</c></r> <r><c>--show-paths</c><c>showpaths</c></r> <r><c>-w, --warnings</c><c>warnings (warnings++)</c></r> <r><c>-W, --woff, --no-warnings</c><c>nowarnings (warnings--)</c></r> <r><c>--autoreload</c><c>autoreload (autoreload_on++)</c></r> <r><c>-m #</c><c>master</c></r> <r><c>--compiler-trace</c><c>compiler_trace</c></r> <r><c>--assembler-debug (#)</c><c>assembler_debug #=%d</c></r> <r><c>--optimizer-debug (#)</c><c>optimizer_debug #=%d</c></r> <r><c>--debug (#)</c><c>debug #=%d</c></r> <r><c>--trace (#)</c><c>trace #=%d (trace+=#)</c></r> <r><c>-Dqdatplrs</c><c>ignore</c></r> </matrix>
<!-- from argument parsing in main.c D # add_predefine m # master file ss # thread_stack_size s # Pike_stack_size (>= 256) q # instructions before quit d # debug [0-9] d_flag+=# c yydebug++ s debug signals t no tail recursion g gc reset dmalloc p no peep optimizing d d_flag++
r # runtime t runtime check types T runtime strict types
a [0-9] a_flag+=# a a_flag++ t [0-9} t_flag+=# t t_flag++ p # s sample stack [0-9] p_flag+=# p p_flag++ l [0-9] l_flag+=# l l_flag++ -->
<p>Debug without: "ttf" (_Image_TTF), "zlib" (Gz), "unisys" (_Image_GIF, _Image_ TIFF), "threads" (Thread, thread_create). Any other blocks the resolver.</p>
</subsection>
<subsection title="Environment variables">
<matrix> <r><c>PIKE_INCLUDE_PATH</c><c>p/":"</c></r> <r><c>PIKE_PROGRAM_PATH</c><c>p/":"</c></r> <r><c>PIKE_MODULE_PATH</c><c>p/":"</c></r> </matrix>
</subsection>
</section>
<section title="Using Hilfe"/>
<p>$HOME or $USERPROFILE 512 lines of history .hilfe_history .hilfe_history~ (chmod 0600) .hilferc
compile error "file:line:error" -:1:parse error, expecting `','' or `')''
commands ".\n"
</p>
</chapter>
/ Martin Nilsson (bygger parser
Previous text:
2003-01-07 02:26: Subject: Re: Inconsistency.
The AbiWord project has something that might be useful. In their newsletters (and I suspect elsewhere) they have something called POWs, an achronym for Project Of the Week, that are basicly of the form (text after '<--' is my own added comment):
Name: 4465 <-- this is a bug nr. (not necessarily) Description: This bug contains a compilation of numerous spelling-related bugs. Interested parties can do simple work, like Q&A to see what's still there, to more complex work, like dialogue fixin' and locale conversion If you have a current Abi and some time, you, too, can help Advertisement: My spelring dilog isn nt ther Recommended Outline: Whatever's easiest for you Comments: All in all, there's something for everyone in there. System: Any and every OS. AbiVersion: Current (1.0.3, I would guess, dev and cvs releases may occur as well) Challenge level: Variable Current Heros: First week available <-- a sort of history
It might be useful to have a special type of bug of this sort just to get people started. My own problem usually is that my time is verry limited therefore I forget interresting little jobs that I might, with or without some help, be able to do.
The problem with writing these sort of bugs is that you tend to fix them yourself (I've been using this for a project I'm handing over to someone else), but if you really focus att setting the bar low and *not* doing them yourself it may really pay off.
I dunno. It's just a simple suggestion.
/ Peter Lundqvist (disjunkt)
As for GTK2 - I assume that it would be a new module in parallell to GTK1 rather than replacing GTK1?
How about something to add C++ module support? I.e able to at least compile files including all relevant Pike include files using a C++ compiler (of course using extern "C" though)? Also I'd personally like to see a Game API using SDL and/or GL (perhaps a widget set using either GL or SDL etc).
Pike would probably be quite well suited for hobbyist game development. :)
/ David Hedbor
Previous text:
2003-01-07 01:17: Subject: Inconsistency.
I was writing on something like that before christmas:
With Pike 7.4 bottled, what new flavours and colours might the Pike product dept. have planned for Pike 7.6? Planned is perhaps not quite the word when we don't intend to do the acutal work for most action points. Wishlist is more correct, and not without a slight seasonal touch.
Replace the Crypto module with Nettle. Niels Möller has done some attempts and should be encouraged to continue.
Rewrite the I/O stuff. Per Hedbor has some architectural ideas that he hopefully will share in a digestable form that will be inspiring enough for some people to dig into this big and delicate task. Unfortunately I'm not that hopeful that it will happen though.
GTK 2 support. Per Hedbor has begun a rewrite of PiGTK and since the API deprecation pace of GTK isn't as high as it used to be, it might be ready while it still is possible to link to a recent GTK.
IPv6 support made a quick appearance in Pike 7.3 but caused to much breakage on AutoBuild machines. With Xenofarm it should be much easier to diagnose and fix these problems. Note that all code that deals with IP numbers, sunch as protocol modules, will have to be reviewed and updated before we can say Pike is IPv6 compliant.
Then I had a train to catch... (And I didn't check with Per if he really had a rewrite idea for the I/O, but he hinted it half a year ago or so). I can dicrectly add that a well thought through system for external modules should be added before Pike 7.6 is released.
Looking at Pike management the single most wanted issue is to install an issue tracker on the Pike site. I don't have time for it, but unless Johan Sundström has a hidden agenda (pun intended) he should be able to pull it off before February.
/ Martin Nilsson (bygger parser
Sounds like as good focus as any.
/ Martin Nilsson (bygger parser
Previous text:
2003-01-07 02:06: Subject: Inconsistency.
As for GTK2 - I assume that it would be a new module in parallell to GTK1 rather than replacing GTK1?
How about something to add C++ module support? I.e able to at least compile files including all relevant Pike include files using a C++ compiler (of course using extern "C" though)? Also I'd personally like to see a Game API using SDL and/or GL (perhaps a widget set using either GL or SDL etc).
Pike would probably be quite well suited for hobbyist game development. :)
/ David Hedbor
I'd like to add a very old wish list item:
- A well designed exception hierarchy. (Common Lisp and emacs are the best examples I'm aware of, but there may be others. Don't know if Java gets this right).
/ Niels Möller ()
Previous text:
2003-01-07 01:17: Subject: Inconsistency.
I was writing on something like that before christmas:
With Pike 7.4 bottled, what new flavours and colours might the Pike product dept. have planned for Pike 7.6? Planned is perhaps not quite the word when we don't intend to do the acutal work for most action points. Wishlist is more correct, and not without a slight seasonal touch.
Replace the Crypto module with Nettle. Niels Möller has done some attempts and should be encouraged to continue.
Rewrite the I/O stuff. Per Hedbor has some architectural ideas that he hopefully will share in a digestable form that will be inspiring enough for some people to dig into this big and delicate task. Unfortunately I'm not that hopeful that it will happen though.
GTK 2 support. Per Hedbor has begun a rewrite of PiGTK and since the API deprecation pace of GTK isn't as high as it used to be, it might be ready while it still is possible to link to a recent GTK.
IPv6 support made a quick appearance in Pike 7.3 but caused to much breakage on AutoBuild machines. With Xenofarm it should be much easier to diagnose and fix these problems. Note that all code that deals with IP numbers, sunch as protocol modules, will have to be reviewed and updated before we can say Pike is IPv6 compliant.
Then I had a train to catch... (And I didn't check with Per if he really had a rewrite idea for the I/O, but he hinted it half a year ago or so). I can dicrectly add that a well thought through system for external modules should be added before Pike 7.6 is released.
Looking at Pike management the single most wanted issue is to install an issue tracker on the Pike site. I don't have time for it, but unless Johan Sundström has a hidden agenda (pun intended) he should be able to pull it off before February.
/ Martin Nilsson (bygger parser
/.../ (note, this isn't so different from the stronger type checking and disallowing of equally named local variables - that change broke A LOT of code /.../
On the contrary, they are very different. The difference lies in the benefits and not in the effort to keep old code working. I think the improved error checking is vastly more useful than the avoided dismay over the inconsistency between "is_dir" and "isdir" (or similar naming issues).
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-06 22:58: Subject: Inconsistency.
Ok, is_file was a mistake. The point is still there - there is no reason for them to have different naming. I'm sure there's other examples too though.
In either case, I don't like the idea of a silent fork to fix these issues to later release a "new" Pike. Rather I'd like to see a Pike 8 or what not which might not necessarily be backwards compatible - it's nothing wrong with that per se - major version number == possibly incompatible API with previous versions.
Iff incompatible changes were well documented I think it'd be great in the long run (note, this isn't so different from the stronger type checking and disallowing of equally named local variables - that change broke A LOT of code (just about any larger piece of Pike code I've used has at least one issue like this).
So my vote is that pike 7.5 (ir 7.7) will become Pike 8 where inconsistencies like this can be fixed and documented. Also it should probably include a lot of cleaning up (i.e modules using old module API's updated to use new ones, or even the cmod API and other such things (removing the 'spider' module is something that comes to mind too :-)).
/ David Hedbor
Perhaps, but there's also a lot of other things that COULD be fixed, if it was noted that it might not be entirely backwards compatible.
Actually, this is exactly what RXML in Roxen 2.0 did to RXML. Granted, I didn't like the lack of backwards compatibility but the one major difference is that it's a lot harder to fix broken RXML than it is to fix broken code (which breaks in obvious ways when compiling).
That said, a #version pragma could possibly maintain compatibility too. In either case I think it would more of an efford to update modules to cmods if applicable or at least to use new API's where they don't (and at the same time writing docs for these perhaps :-).
/ David Hedbor
Previous text:
2003-01-06 23:30: Subject: Inconsistency.
/.../ (note, this isn't so different from the stronger type checking and disallowing of equally named local variables - that change broke A LOT of code /.../
On the contrary, they are very different. The difference lies in the benefits and not in the effort to keep old code working. I think the improved error checking is vastly more useful than the avoided dismay over the inconsistency between "is_dir" and "isdir" (or similar naming issues).
/ Martin Stjernholm, Roxen IS
For starters I think that making a list of changes we'd like to do is good.
/ Martin Nilsson (bygger parser
Previous text:
2003-01-06 21:59: Subject: Inconsistency.
Yes, it is. It's one among many small uglinesses that only gets worse if one tries to fix them. Maybe we could start a very unofficial and experimental fork where we fix all such inconsistencies and other design mistakes that have been made during the years. Eventually, when everything is so neat, flawless and shiny that we gotta wear shades around it, we could release it as a descendant of Pike (with a shiny new name too, of course).
/ Martin Stjernholm, Roxen IS
is_dir is a function whereas isdir is not, so one would go from one problem to another. One could add a is_dir function though.
/ Martin Nilsson (bygger parser
Previous text:
2003-01-06 21:14: Subject: Inconsistency.
Ok, I noticed the following inconsistency.
Stdio.is_dir() <=> Stdio.Stat->isdir Stdio.is_file() <=> Stdio.Stat->isfile
etc. Wouldn't it be logical if these were named the same rather? I vote for is_dir etc since that is generally the naming convention used in Pike.
/ David Hedbor
pike-devel@lists.lysator.liu.se
-
David Hedbor ＠ Pike developers forum -
Martin Baehr -
Martin Nilsson (bygger parser ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Niels M�ller () ＠ Pike (-) developers forum
-
Peter Lundqvist (disjunkt) ＠ Pike (-) developers forum