Dan Sugalski wrote: > At 8:53 PM +0200 9/1/03, Christian Renz wrote: > >Clemens, > > > >>"classpath" > > > >I guess the proper term would be class library. The path is only where > >you look for the libraries :). > > > >It doesn't seem to be the Perl way to limit yourself to one option > >only ("There's more than one way to do it"). > > I'd worry less about the Perl way to do it, since we're more > concerned with the Parrot way to do it, and that's when we have one > way that's good enough we ship it, so people don't have to re-invent > the bikeshed, or choose from a half-dozen identically shaped but > different colored sheds. Which means that we ship a core that's as > small as feasable, and an add-on pack (which we'll likely also ship > with the core for an all-in-one install) with the best things we can > find that are cross-platform enough to be useful. > > That means we'll shoot for a good set of networking modules for the > various RFC protocols, a generic SQL database front-end, an (ick :) > XML parser, a variety of cross-platform tools (filename conversions > and whatnot), a set of xDBM interface modules, and some other stuff.
Do you imagine that the stock XML parser or xDBM will be written in a parrot language or will it be a c lib used through NCI? > > Don't forget there is an issue of us wanting to be a good core for > more than just perl. The Python parrot package would have Python's > standard module set, the Ruby package would have ruby's modules, and > the Perl package would have the perl modules. There's a fair amount > of overlap and I expect people both want their modules and *don't* > want two or three alternate versions of the same modules installed. I > could be wrong, of course. Is one of the advantages of a multi-language interp not to combine the libraries of each language, to capitalize on the strength found in one language for the benefit of the other? And would a unification of those libraries be outside the scope of parrot or would it fit right in? > > GUI stuff's a massive pain, as you either get cross-platform which is > ugly and awkward everywhere, or platform-specfic and useless anywhere > but on the platform in question. And I'm pretty sure that, no matter > *how* Insanely Great the OS X Cocoa interface modules are, they're > not going to do MSWin folks much good. :) > > As for sound... Yeesh. There's a swamp I don't have enough castles for. > > However, since we have a good native interface it should mean that > many modules that now require a compiler for can be done entirely in > parrot bytecode, which should mean that it's far easier for people to > install and reduce a lot of the pain. Also we've a fair amount of > experience in the perl world with network module installation > systems--we know some things that do work, and some things that > don't, and I expect we should be able to leverage that to make a > system better than what we have now. (Which, honestly, is pretty > darned good, especially given the limited information it has > available to work with) I want to ask for clarification here. You mean that the design of NCI will allow c libs to be wrapped using just parrot code instead of additional c code as in XS? I agree that the perl system is pretty darned good. But I don't know if our admins (who make there lives very difficult with lack of user policy vision) would agree. I believe they would says it's the best of the other languages they work with except for c/c++. I also would agree that the libtool/autoconf system is more reliable then some of the XS code available from CPAN. And although this does not bother me because I enjoy working with perl. They really don't care what the boxes do as long as the boxes are doing it. Also building a mysql/apache/mod_perl/libxml/ environment is very challenging WRT customers and clients. In very few instances would I expect a low level admin to accomplish such a task in a reasonable amount of time. Knowing very little about this stuff I have always wondered why I need to rely so heavily on certain features of the installed system. I would like to compile byte code that includes the byte code for modules I am using. I realize that creates a certain undesired coupling. But in some instances especially WRT to client/customer apps it would prevent upgrading modules outside of your control. > -- > Dan > > --------------------------------------"it's like this"------------------- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even > teddy bears get drunk -- Be nice I'm new Damien Hogan