Re: CPP Namespace pollution
Bryan C. Warnock [EMAIL PROTECTED] wrote: I count 86 violations of 8.3 in the tree. 8.3-friendly doesn't appear to be a concern. The files themselves don't have to be 8.3; however, they should be unique in lc( substr($base,0,8) . '.' . substr($suffix,0,3) ) Under that rule, I make it four: duplicate: ./include/parrot/register.h - ./include/parrot/register_funcs.h duplicate: ./languages/miniperl/Miniperl - ./languages/miniperl/miniperlc duplicate: ./t/op/pmc_perlarray.t - ./t/op/pmc_perlhash.t duplicate: ./t/op/pmc_perlarray.t - ./t/op/pmc_perlstring.t
Re: CPP Namespace pollution
On Mon, Jan 28, 2002 at 11:57:25AM +, Dave Mitchell wrote: duplicate: ./include/parrot/register.h - ./include/parrot/register_funcs.h This should be regfuncs.h duplicate: ./languages/miniperl/Miniperl - ./languages/miniperl/miniperlc Urgh. mpc? duplicate: ./t/op/pmc_perlarray.t - ./t/op/pmc_perlhash.t duplicate: ./t/op/pmc_perlarray.t - ./t/op/pmc_perlstring.t These should move to t/op/pmc/ Similarly, I'd like Parrot/ to move to lib/ But doesn't this require much CVS hackery to keep the revision history? -- The problem with big-fish-little-pond situations is that you have to put up with all these fscking minnows everywhere. -- Rich Lafferty
Re: CPP Namespace pollution
Simon Cozens wrote in perl.perl6.internals: Similarly, I'd like Parrot/ to move to lib/ And Test/, while you're at it. But doesn't this require much CVS hackery to keep the revision history? Don't be the slave of your tools ;-) -- Rafael Garcia-Suarez
Re: CPP Namespace pollution
At 4:25 PM + 1/28/02, Rafael Garcia-Suarez wrote: Simon Cozens wrote in perl.perl6.internals: Similarly, I'd like Parrot/ to move to lib/ And Test/, while you're at it. But doesn't this require much CVS hackery to keep the revision history? Don't be the slave of your tools ;-) I'm pretty sure that we can do this and preserve the revision history, though it needs to be done on the CVS machine itself. I'll see if we can find out what needs to be done, then prevail on Ask to fix us up here. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: CPP Namespace pollution
On Mon, 28 Jan 2002, Dan Sugalski wrote: At 4:25 PM + 1/28/02, Rafael Garcia-Suarez wrote: Simon Cozens wrote in perl.perl6.internals: Similarly, I'd like Parrot/ to move to lib/ And Test/, while you're at it. But doesn't this require much CVS hackery to keep the revision history? Don't be the slave of your tools ;-) I'm pretty sure that we can do this and preserve the revision history, though it needs to be done on the CVS machine itself. I'll see if we can find out what needs to be done, then prevail on Ask to fix us up here. You just need someone with a shell on the CVS (and the appropriate permissions :) server to move the files to the new layout ... /J\ -- Jonathan Stowe | http://www.gellyfish.com | This space for rent |
Re: CPP Namespace pollution
On Mon, Jan 28, 2002 at 10:04:43PM +, Jonathan Stowe wrote: On Mon, 28 Jan 2002, Dan Sugalski wrote: At 4:25 PM + 1/28/02, Rafael Garcia-Suarez wrote: Simon Cozens wrote in perl.perl6.internals: Similarly, I'd like Parrot/ to move to lib/ And Test/, while you're at it. But doesn't this require much CVS hackery to keep the revision history? Don't be the slave of your tools ;-) I'm pretty sure that we can do this and preserve the revision history, though it needs to be done on the CVS machine itself. I'll see if we can find out what needs to be done, then prevail on Ask to fix us up here. You just need someone with a shell on the CVS (and the appropriate permissions :) server to move the files to the new layout ... And warn everyone beforehand because we'll all have to check out a fresh copy afterwards.
Re: CPP Namespace pollution
On Fri, 25 Jan 2002, Melvin Smith wrote: Hm, the FAQ would be not linked from either of dev.perl.org or www.parrotcode.org. That's a bummer. Ask, could we move this to dev.perl.org please? Dare I suggest we check it into the repository and have a script update the site from the repository. At least then we can tell people to check the FAQ in your parrot distribution. That sounds good to me. - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: Comm. Unity - (was Re: CPP Namespace pollution)
On Friday 25 January 2002 18:55, Simon Cozens wrote: On Fri, Jan 25, 2002 at 01:56:20PM -0500, Bryan C. Warnock wrote: If anything, it's largely our fault, for allowing, through our silence, Simon to speak on our behalf in those situations. Hey, if my speaking on behalf of Perl 6 is such a problem, someone else is very welcome to this maintainer's hat... ...in those situations... If we've a concern, we can pipe up. Brevity of answer is sometimes good. Answers that provide exactly the right amount of information are better. Contextual or personality clues are often needed to decide how much is enough, which is tough to do with folks that provide neither. No one wants to read through any of my diatribes when a simple you can find an entry here will suffice. (This occasionally happens to me with things that have changed in recent versions of Perl. I *have* read the manuals, and if you didn't have so many of them, I'd read them all again.) Simon, (occasionally referred to as the Tom Christiansen for a New Generation :-) Heh. I'm not sure whether that's a complement or an insult. :) Smiley aside, neither. It's just commentary. Tom provides (provided?) spiciness to the Perl community. Sometimes a slap upside the head is *exactly* what's needed. (If nothing else, as refreshment to those that *do* patiently explain the Way Things Are while secretly wishing that a kill file could contain more than just email.) But you're right - like Tom, I'm bigly in favour of people doing their own research before blustering in. We're not, for instance, going to be writing parts of Parrot in C++, as a study of the FAQ (which I honestly did not know was not very well publicised[1]) or the mailing list archives would confirm. Suggestions that we could or ought to just convince me that the questioner has not done his homework, and this makes me less disposed to giving him anything more than terse answers. A perfectly valid response. I'm not saying that *you* should be more cautious in what you say and how you say it - I'm saying that the community should feel free to add their own responses if they're not happy with the phraseology of yours. After all, without Read the FAQ, it wouldn't have become clear that the FAQ hadn't been imported yet. [1] Even though on the other hand, it is relatively easy to find via Google. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: CPP Namespace pollution
At 4:55 PM -0500 1/25/02, Andy Dougherty wrote: Sounds like a good plan. Perhaps something like the following patch is in order then, more as a reminder for the future than anything actually useful for now? (Note the changed file names: parrot/parrot_e*.h is apparently redundant and definitely isn't 8.3-friendly, but perhaps you were guarding against the VMS #include problem I vaguely recall where the directory name parrot in parrot/foo.h could sometimes get ignored?) I was watching out for both the VMS case and the case where someone just ups and throws extend.h and embed.h into a global directory somewhere even though they shouldn't. VMS should be OK, and if people toss files around without paying attention they probably should expect problems. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
CPP Namespace pollution
One problem noted recently on the p5p list is that if you do #include perl.h in your program, it exposes a *lot* of CPP #defines to your program, whether you want them or not. This is particularly a problem if you wish to embed perl or use it with an extensive 3rd-party library. For parrot, we'd ideally like to make it a lot safer to #include parrot/parrot.h Here's a status check on where we are currently: #include parrot/parrot.h currently #defines 198 global CPP symbols. If you take away the autoconf-ish HAS_HEADER_* and the proabably-quite-safe PARROT_* entries, that leaves 107 entries. Although it's impossible to predict what vendors and third-party software writers will do with the CPP namespace, the following 5 entries seem particularly likely to cause mischief at some point somewhere: Very general names: UNUSED INVALID_CHARACTER IO_ERROR KEY_NOT_FOUND Possible conflict with system headers: SSIZE_MAX This is #defined in parrot/io.h as 8192, but it's also possibly defined in the system headers as the maximum size of the Posix ssize_t type, typically INT_MAX or LONG_MAX. Since it's not used in parrot, I'm unsure of the intent. I don't have a specific proposal at the moment, but would invite others to think creatively about ways to minimize cpp pollution while still keeping the source readable and maintainable. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: CPP Namespace pollution
On Fri, 25 Jan 2002, Andy Dougherty wrote: One problem noted recently on the p5p list is that if you do #include perl.h in your program, it exposes a *lot* of CPP #defines to your program, whether you want them or not. This is particularly a problem if you wish to embed perl or use it with an extensive 3rd-party library. For parrot, we'd ideally like to make it a lot safer to #include parrot/parrot.h Here's a status check on where we are currently: #include parrot/parrot.h currently #defines 198 global CPP symbols. If you take away the autoconf-ish HAS_HEADER_* and the proabably-quite-safe PARROT_* entries, that leaves 107 entries. Although it's impossible to predict what vendors and third-party software writers will do with the CPP namespace, the following 5 entries seem particularly likely to cause mischief at some point somewhere: Very general names: UNUSED INVALID_CHARACTER IO_ERROR KEY_NOT_FOUND Possible conflict with system headers: SSIZE_MAX This is #defined in parrot/io.h as 8192, but it's also possibly defined in the system headers as the maximum size of the Posix ssize_t type, typically INT_MAX or LONG_MAX. Since it's not used in parrot, I'm unsure of the intent. I don't have a specific proposal at the moment, but would invite others to think creatively about ways to minimize cpp pollution while still keeping the source readable and maintainable. We could define those as PARROT_UNUSED, PARROT_IO_ERROR, etc. Then, we could have a parrot/aliases.h header that will define an aliases for them: #define UNUSED PARROT_UNUSED. The recommended use of this header would only be internally, and it won't be included by any of the headers that the library would require. Of course, PARROT can be replaced with PRT or with any other prefix. Regards, Shlomi Fish -- -- Shlomi Fish[EMAIL PROTECTED] Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: [EMAIL PROTECTED] He who re-invents the wheel, understands much better how a wheel works.
Re: CPP Namespace pollution
I don't have a specific proposal at the moment, but would invite
others to think creatively about ways to minimize cpp pollution while
still keeping the source readable and maintainable.
One possibility would be to change code like this
#define XYZ 123
to this...
namespace _PARROT
{
const int XYZ = 123;
}
By placing code in namespaces and not using CPP at all, name clashes are
completely avoided.
This requires the use of C++, rather than C. Also, where the CPP #define is
nothing more than text substitution done at compile time, use of constants
in C++ consumes runtine stack space.
Dave
Andy Dougherty
doughera@lafa To: Perl6 Internals
[EMAIL PROTECTED]
yette.edu cc:
Subject: CPP Namespace pollution
01/25/02 10:14
AM
One problem noted recently on the p5p list is that if you do
#include perl.h
in your program, it exposes a *lot* of CPP #defines to your program,
whether you want them or not. This is particularly a problem if you wish
to embed perl or use it with an extensive 3rd-party library.
For parrot, we'd ideally like to make it a lot safer to
#include parrot/parrot.h
Here's a status check on where we are currently:
#include parrot/parrot.h currently #defines 198 global CPP symbols.
If you take away the autoconf-ish HAS_HEADER_* and the
proabably-quite-safe PARROT_* entries, that leaves 107 entries.
Although it's impossible to predict what vendors and third-party
software writers will do with the CPP namespace, the following 5
entries seem particularly likely to cause mischief at some point
somewhere:
Very general names:
UNUSED
INVALID_CHARACTER
IO_ERROR
KEY_NOT_FOUND
Possible conflict with system headers:
SSIZE_MAX
This is #defined in parrot/io.h as 8192, but it's also
possibly defined in the system headers as the maximum size of
the Posix ssize_t type, typically INT_MAX or LONG_MAX.
Since it's not used in parrot, I'm unsure of the intent.
I don't have a specific proposal at the moment, but would invite
others to think creatively about ways to minimize cpp pollution while
still keeping the source readable and maintainable.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: CPP Namespace pollution
On Fri, Jan 25, 2002 at 10:30:01AM -0500, [EMAIL PROTECTED] wrote: This requires the use of C++, rather than C. See the FAQ. -- The most effective debugging tool is still careful thought, coupled with judiciously placed print statements. -Kernighan, 1978
Re: CPP Namespace pollution
This requires the use of C++, rather than C. See the FAQ. Where would the FAQ be? Dave Simon Cozens simon@netthin To: [EMAIL PROTECTED] k.co.uk cc: Perl6 Internals [EMAIL PROTECTED] Subject: Re: CPP Namespace pollution 01/25/02 10:52 AM On Fri, Jan 25, 2002 at 10:30:01AM -0500, [EMAIL PROTECTED] wrote: This requires the use of C++, rather than C. See the FAQ. -- The most effective debugging tool is still careful thought, coupled with judiciously placed print statements. -Kernighan, 1978
RE: CPP Namespace pollution
See the FAQ. This really isn't a very good answer for several reasons (I know the answer, but that doesn't matter): 1. There is no link to the FAQ on the Perl6 page (that I could find anyway). (http://www.panix.com/~ziggy/parrot.html - I think this it) 2. See the FAQ for what? Not using CPP? Not asking stupid questions? Why? There were a lot of complaints about this in the past regarding the newbie community, and we really need to make an extra effort to ensure that parrot doesn't get bad press by repeating the same mistakes. RTFM is often just the lazy man's answer (even if it is often the right answer - Is it plugged in?). Grant M.
Re: CPP Namespace pollution
On Fri, Jan 25, 2002 at 11:15:15AM -0500, [EMAIL PROTECTED] wrote: See the FAQ. Where would the FAQ be? Hm, the FAQ would be not linked from either of dev.perl.org or www.parrotcode.org. That's a bummer. Thankfully, a quick google for Parrot FAQ (once you get past the avine entries ;) gets you: http://www.panix.com/~ziggy/parrot.html Ask, could we move this to dev.perl.org please? -- The Write Many, Read Never drive. For those people that don't know their system has a /dev/null already. - Rik Steenwinkel on Exabyte drives, ASR
Comm. Unity - (was Re: CPP Namespace pollution)
On Friday 25 January 2002 14:19, Wizard wrote: See the FAQ. This really isn't a very good answer for several reasons (I know the answer, but that doesn't matter): 1. There is no link to the FAQ on the Perl6 page (that I could find anyway). (http://www.panix.com/~ziggy/parrot.html - I think this it) 2. See the FAQ for what? Not using CPP? Not asking stupid questions? Why? There were a lot of complaints about this in the past regarding the newbie community, and we really need to make an extra effort to ensure that parrot doesn't get bad press by repeating the same mistakes. RTFM is often just the lazy man's answer (even if it is often the right answer - Is it plugged in?). It's also very Simon-esqe. That's not to praise or condemn his rhetoric, but just to acknowledge it. Now, certainly, someone new to the community won't recognize that, and may even believe that the community is one robotic army of Simons. That, too, isn't necessarily Simon's fault. If anything, it's largely our fault, for allowing, through our silence, Simon to speak on our behalf in those situations. Not only are different viewpoints necessary for a community, but oftentimes different expressions of the same viewpoint are necessary to exude the character of the community, and it's up to the community members to ensure that that is done. Many of the main characters on p5p and p6* have distinctly different styles that mostly complement each other. (Which is a far cry from some other mailing lists, which exemplify violent agreement) Simon, (occasionally referred to as the Tom Christiansen for a New Generation :-), constantly trying to do 48 hours of stuff a day, is terse and dismissive - I don't have time for pleasantries, background information, or explanations. Here's the cut-and-dry; if you need more, someone else can provide that. Dan is cleverly aloof in is answers. There's not many folks who flippantly hand-wave and still come across as knowing exactly what he's talking about. Larry is quietly charismatic. He's one of the few folks that can get away with answering a question by not actually addressing the answer or the question. (I'd probably through Jarkko into this category, too.) Most folks, when they do that, just come across as idiots. Damian is a master craftsman. He can provide an overwhelming, highly detailed, completely unintelligible answer that leaves you, at the end, out of breath but in complete understanding of what was said, even if you didn't understand any particular part of it. Some folks are good at explaining things simply without being condescending. Some folks are good at explaining things complexly without being confusing. And other folks just leave you wondering. It's that mix that makes our community. You learn who's got what styles, and who fits best for you. Sometimes RTFM *is* the right answer, but other times an explanation of the manual is needed. Most languages have a personality - simple and one-dimensional. Perl is different. Perl, as the glue language, has a complex and multi-dimensional personality, simultaneuosly reflecting its disparate roots and influences. The Perl community, by nature of Perl herself, is also built on disparate roots and influences, and it's that complexity to our personality that defines us. Oh, yes, the reputation. The reputation was largely gained by matching the wrong faces with the wrong forums. Any time you open yourself up to questions, you need to expect the type of questions that you'd expect given the nature of what is being questioned about. The reputation was largely started in c.l.p.m, at the time, the only real public forum for asking questions about Perl. The mongers hanging out there wanted questions along the lines of How can I save the world with Perl in 5 lines or less? Instead, they received questions along the lines of What's the difference between 'for' and 'foreach'? When you provide a language that can be used by beginners, and enough documentation to satisfy any experienced programmer, what kind of questions do you expect to get? It's almost a Catch-22 - if they knew how to RTFM, they wouldn't need to have asked the question in the first place. The p5p and p6* lists are slightly different. We're not for beginners. We're not anywhere close for being for beginners. The occasional newbie that stumbles in unawares may indeed stumble out again feeling slighted - the importantance of never allowing just one greeter at the door [1]. Most everyone else at least will understand group dynamics enough to weather the storm until it's clear where they fit in the puzzle. p6i has been extremely tolerant of new blood. Much more than p5p has, I believe. (That's mostly based on p5p reaction to p6l. p5p is very welcome to newcomers in p5p, *if* you come bearing patches.) So is there a point to all this? Probably. (My style, it seems, is
Re: CPP Namespace pollution
At 10:14 AM -0500 1/25/02, Andy Dougherty wrote: One problem noted recently on the p5p list is that if you do #include perl.h in your program, it exposes a *lot* of CPP #defines to your program, whether you want them or not. This is particularly a problem if you wish to embed perl or use it with an extensive 3rd-party library. For parrot, we'd ideally like to make it a lot safer to #include parrot/parrot.h Nope--we'd ideally like to smack anyone writing non-core code that does that. :) Embedders will include parrot/parrot_embed.h, while extension folks will include parrot/parrot_extend.h. Neither will include parrot/parrot.h--not safe. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: CPP Namespace pollution
At 11:19 AM -0800 1/25/02, Wizard wrote: See the FAQ. This really isn't a very good answer for several reasons (I know the answer, but that doesn't matter): 1. There is no link to the FAQ on the Perl6 page (that I could find anyway). (http://www.panix.com/~ziggy/parrot.html - I think this it) 2. See the FAQ for what? Not using CPP? Not asking stupid questions? Why? There were a lot of complaints about this in the past regarding the newbie community, and we really need to make an extra effort to ensure that parrot doesn't get bad press by repeating the same mistakes. RTFM is often just the lazy man's answer (even if it is often the right answer - Is it plugged in?). This is a good point. We can fix the FAQ link, and we should put it into the repository, but I think we should avoid the really terse go check the FAQ sorts of answers. Mostly terse Why we don't do X is answered in the FAQ is OK as there's at least a little context there. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Comm. Unity - (was Re: CPP Namespace pollution)
On Fri, Jan 25, 2002 at 01:56:20PM -0500, Bryan C. Warnock wrote: [ rather interesting ramble about people, Perl, and personality ] Someone needs to add this stuff to http://dev.perl.org/perl6/people or perhaps start a Perl6-personality guidebook :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Comm. Unity - (was Re: CPP Namespace pollution)
At 1:56 PM -0500 1/25/02, Bryan C. Warnock wrote: Dan is cleverly aloof in is answers. There's not many folks who flippantly hand-wave and still come across as knowing exactly what he's talking about. I really do need to work on the flippant bit when I'm not in front of a roomful of Lisp folks... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
regarding cpp namespace pollution
I think the following would work. * At the beginning of each parrot source code file there must be at least two Parrot-specific defines, e.g. #define PARROT_SOURCE #define PARROT_SOURCE_REGEXEC_C These would declare both being part of Parrot, and being a particular file. If some kind of clear component architecture emerges, then a third define may be in order #define PARROT_SOURCE #define PARROT_SOURCE_GC #define PARROT_SOURCE_BOEHM_C * The parrot header files should be anal-retentively sorted into (at least) three categories: * Private to Parrot (intra-source-file protypes, for example). * Visible to friends of Parrot (XS, in Perl-5-talk) * Public. This should be kept to minimum, and to prototypes and constants. No dark scary ifdef forests, no hackish things mattering only to the Parrot implementation. There should be no (accidental) way for things external to Parrot to get at the category one: the way to do this would be to use the PARROT_SOURCE* defines. It requires some discipline, yes, but wasn't that the whole idea of this...? -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: CPP Namespace pollution
On Fri, 25 Jan 2002, Dan Sugalski wrote: At 10:14 AM -0500 1/25/02, Andy Dougherty wrote: For parrot, we'd ideally like to make it a lot safer to #include parrot/parrot.h Nope--we'd ideally like to smack anyone writing non-core code that does that. :) Embedders will include parrot/parrot_embed.h, while extension folks will include parrot/parrot_extend.h. Neither will include parrot/parrot.h--not safe. Sounds like a good plan. Perhaps something like the following patch is in order then, more as a reminder for the future than anything actually useful for now? (Note the changed file names: parrot/parrot_e*.h is apparently redundant and definitely isn't 8.3-friendly, but perhaps you were guarding against the VMS #include problem I vaguely recall where the directory name parrot in parrot/foo.h could sometimes get ignored?) diff -r -u parrot-orig/include/parrot/parrot.h parrot-andy/include/parrot/parrot.h --- parrot-orig/include/parrot/parrot.h Mon Jan 14 15:04:29 2002 +++ parrot-andy/include/parrot/parrot.h Fri Jan 25 16:52:14 2002 @@ -10,6 +10,11 @@ * References: */ +/* Only parrot core files should include this file. + Extensions should include parrot/extend.h. + Programs embedding parrot should include parrot/embed.h. +*/ + #if !defined(PARROT_PARROT_H_GUARD) #define PARROT_PARROT_H_GUARD -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: CPP Namespace pollution
On Friday 25 January 2002 16:55, Andy Dougherty wrote: Sounds like a good plan. Perhaps something like the following patch is in order then, more as a reminder for the future than anything actually useful for now? (Note the changed file names: parrot/parrot_e*.h is apparently redundant and definitely isn't 8.3-friendly, I count 86 violations of 8.3 in the tree. 8.3-friendly doesn't appear to be a concern. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Comm. Unity - (was Re: CPP Namespace pollution)
-Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984 Dan Sugalski [EMAIL PROTECTED] To: [EMAIL PROTECTED], Perl6 Internals [EMAIL PROTECTED] cc: 01/25/2002 03:44 Subject: Re: Comm. Unity - (was Re: CPP Namespace pollution) PM At 1:56 PM -0500 1/25/02, Bryan C. Warnock wrote: Dan is cleverly aloof in is answers. There's not many folks who flippantly hand-wave and still come across as knowing exactly what he's talking about. I really do need to work on the flippant bit when I'm not in front of a roomful of Lisp folks... *cackle* I also read the Dr Dobbs article, you must have stolen the author's parking spot or something. Actually I enjoyed it because it was classic DDJ, all the talk about academic point of view. Rarely do I ever see academics doing much to help the rest of the community. Technically I'm an academic (although a poor one) so this statement isn't prejudiced. I also could care less about reinventing the wheel, if I get to own my own wheel and put my name on it.. and paint it yellow... -Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984
Re: Comm. Unity - (was Re: CPP Namespace pollution)
Melvin Smith [EMAIL PROTECTED] writes: I also could care less about reinventing the wheel, if I get to own my own wheel and put my name on it.. and paint it yellow... No mate, you want to paint it purple. You know it makes sense. -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Re: Comm. Unity - (was Re: CPP Namespace pollution)
At 10:21 PM + 1/25/02, Piers Cawley wrote: Melvin Smith [EMAIL PROTECTED] writes: I also could care less about reinventing the wheel, if I get to own my own wheel and put my name on it.. and paint it yellow... No mate, you want to paint it purple. You know it makes sense. Just as long as no bikesheds are involved... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Comm. Unity - (was Re: CPP Namespace pollution)
At 5:01 PM -0500 1/25/02, Melvin Smith wrote: At 1:56 PM -0500 1/25/02, Bryan C. Warnock wrote: Dan is cleverly aloof in is answers. There's not many folks who flippantly hand-wave and still come across as knowing exactly what he's talking about. I really do need to work on the flippant bit when I'm not in front of a roomful of Lisp folks... *cackle* I also read the Dr Dobbs article, you must have stolen the author's parking spot or something. Apparently so. Judging from the pictures, Shriram and I both did something unpleasant to the art director too. Actually I enjoyed it because it was classic DDJ, all the talk about academic point of view. Rarely do I ever see academics doing much to help the rest of the community. Apparently producing solid, useable stuff doesn't get you tenure, which I can see could be a big disincentive. OTOH, the workshop was really useful in a number of ways, so it's not like no exchange is going on. Hopefully we can have more in the future. (Greg, the guy who arranged the conference, passed on some really interesting ideas for optimization Technically I'm an academic (although a poor one) so this statement isn't prejudiced. Well, we weren't alone in getting shot at. The very first paragraph was a good smack at Greg, which wasn't at all fair. I also could care less about reinventing the wheel, if I get to own my own wheel and put my name on it.. and paint it yellow... Works for me. Whatever gets me a wheel fastest... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Comm. Unity - (was Re: CPP Namespace pollution)
On Fri, Jan 25, 2002 at 01:56:20PM -0500, Bryan C. Warnock wrote: If anything, it's largely our fault, for allowing, through our silence, Simon to speak on our behalf in those situations. Hey, if my speaking on behalf of Perl 6 is such a problem, someone else is very welcome to this maintainer's hat... Simon, (occasionally referred to as the Tom Christiansen for a New Generation :-) Heh. I'm not sure whether that's a complement or an insult. :) But you're right - like Tom, I'm bigly in favour of people doing their own research before blustering in. We're not, for instance, going to be writing parts of Parrot in C++, as a study of the FAQ (which I honestly did not know was not very well publicised[1]) or the mailing list archives would confirm. Suggestions that we could or ought to just convince me that the questioner has not done his homework, and this makes me less disposed to giving him anything more than terse answers. [1] Even though on the other hand, it is relatively easy to find via Google. -- #define struct union /* Great space saver */
Re: Comm. Unity - (was Re: CPP Namespace pollution)
At 11:55 PM 1/25/2002 +, Simon Cozens wrote: On Fri, Jan 25, 2002 at 01:56:20PM -0500, Bryan C. Warnock wrote: If anything, it's largely our fault, for allowing, through our silence, Simon to speak on our behalf in those situations. Hey, if my speaking on behalf of Perl 6 is such a problem, someone else is very welcome to this maintainer's hat... Your doing fine in my book, I think everyone should pitch in and make info and documentation more readily available such as on the website and in the distribution. -Melvin
