Re: Parrot - 100% Gnu.NET ?
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
Re: Parrot - 100% Gnu.NET ?
At 8:06 PM +0200 9/1/03, Clemens Eisserer wrote: Hi there! I´m a java programmer and I´m not really experienced with perl. But I´ve searched a long time for a system like .NET that can´t be controlled by Microsoft through Patents. Do be aware that Microsoft may still hold patents that affect Parrot, as might IBM, HP, and whoever owns what used to be Bell Labs these days. Amongst others. Independent development is *no* protection against patents. Just ask the other guys who independently invented the telephone. (Remember them? No? Neither does anyone else :) I really like languages which are deployed compiled to bytecode, no problems with ABI-changes or with compiliers, once compiled link everywhere. Thats the reason why I linke Java really much, but there are some points, which are really showstoppers: *Java isnt free, *Swing is t slow to be useful. Erm--bytecode doesn I think that parrot could be the Gnu-version of .NET and could be a realy benefit for the whole opensource-world. No 20 runtimes need to be installed on a system - parrot would do the job better than each could alone (Because if many apps rely on parrot the JIT will be tuned by guys from IBM ;-) ). We thought the same about Java when it came out. Alas you'll find a half-dozen different JVMs installed on some systems. (Not, mind, that I want to do the same, but it is possible that it'll happen) But in my opinion parrot needs a more complete classpath that perl5 currently has. Hrm? I'm completely lost here. Library search functionality should be at least as good, if not better, than perl 5, and it's been my experience that perl 5's library search capabilities were better than any Java I've had the misfortunte to deal with. Might just have had some bad experiences. So, my question: Is it planned to include a complete classpath into parrot, including gui, network, db, sound functionality No. Networking yes, probably some DB functionality (at least DBI and xDBM style access, though unlikely no actual SQL DB drivers. Possibly flat file SQL access, we'll see), but no sound or GUI stuff. That's all very platform-specific, or really really ugly. Not to say that there won't be good cross-platform libraries--I'd be thrilled if there was a good Tk or wXwindows library for Parrot, but we're not going to ship with them. Please let me know what you think about the idea to include a complete classpath into parrot. If you want a complete *library* shipping with Parrot, you're going to be rather disappointed I'm afraid. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot - 100% Gnu.NET ?
At 1:04 PM -0600 9/1/03, Luke Palmer wrote: Clemens Eisserer writes: Hi there! Ië¾m a java programmer Uh oh :-) and Ië¾m not really experienced with perl. [...] I think that parrot could be the Gnu-version of .NET and could be a realy benefit for the whole opensource-world. No 20 runtimes need to be installed on a system - parrot would do the job better than each could alone (Because if many apps rely on parrot the JIT will be tuned by guys from IBM ;-) ). But in my opinion parrot needs a more complete classpath that perl5 currently has. There is a big problem with that: it kinda precludes the whole community thing that made everyone love Perl 5. In particular, CPAN. The plan for Perl 6, at least, is to include almost nothing in the base distribution, so administrators are forced to install some stuff from CPAN order for Perl to be useful at all[1]. Not entirely true. There's going to be a decoupling between the core distribution, mainly parrot and its supporting stuff, and perl (and python, and ruby) but there'll be an all-in-one install for them all, so a trip to CPAN won't actually be necessary. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot - 100% Gnu.NET ?
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). Of course we wouldn't want five different implementations of Unicode, and it makes sense to ship _one_. However, people might want to use different GUIs -- e.g. wxWindows, TK, native Windows GUI, Aqua, ... Basic network classes, on the other hand, might be something that might be shipped with Parrot. Sound is a whole different beast -- implementations vary wildly across systems, and I'm not sure whether it is possible to have a high-performance cross-platform implementation that satisifes 90% of users. On the other hand, I don't think we only have the choice between shipping all libraries like Java and having a complicated install system (for the average GUI-loving end user) like CPAN. There's a couple of middle options: For bytecode based packages: - Parrot bytecode executables might be packages that contain the necessary libraries in bytecode format (e.g. wxWindows). - Installers might include libraries (in bytecode) and install them if needed (install = simple copy) For binary (platform-dependant) packages: Usually, people just ship these statically linked against those libs that can't be typically expected to be installed on the system. So I guess for Parrot apps distributed in binary, there's not much of a problem. For apps shipped as bytecode, it still needs to be discussed what is going to be provided: - Preferably a small package ( 5 - 10 MB) that lets people use Parrot apps quickly. - A huge package complete with Perl/Python/PHP/Befunge/hq9+/... support so that everybody will have 95% of everything they are ever gonna need - Or both? Liebe Grüße, Christian (since you started the German greetings thingie ;-)) -- [EMAIL PROTECTED] - http://www.web42.com/crenz/ - http://www.web42.com/ Surely what a man does when he is taken off his guard is the best evidence for what sort of man he is. -- C.S. Lewis, Mere Christianity
Re: Parrot - 100% Gnu.NET ?
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. 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. 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) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Parrot - 100% Gnu.NET ?
Hi there! I´m a java programmer and I´m not really experienced with perl. But I´ve searched a long time for a system like .NET that can´t be controlled by Microsoft through Patents. Imagine 10.000 apps need the .NET api ruuning on mono, and microsoft permits cloning the .NET api. Maybe 5000 of these 10.000 apps are unmaintained, and even using these apps with an older version of mono would not be legal. The other 5.000 will need weeks to create a patent-free version of there software, till MS finds another point which could be destroyed using patents. And, after the fist change Mono wont be compatinble to .NET at all, so why dont create a patent-free .NET from the beginning. I searched a long time for such a project, and after all I found it where I never expected it: Perl ;-) I really like languages which are deployed compiled to bytecode, no problems with ABI-changes or with compiliers, once compiled link everywhere. Thats the reason why I linke Java really much, but there are some points, which are really showstoppers: *Java isnt free, *Swing is t slow to be useful. In my opinion runtimes only make sence when they dont need to rely on native code. It doesnt make sence that parrot is platform independent and I need to link against native libraries through bindings, because perl´s classpath lacks e.g. GUI functionality. Mono solves this problem like Java - they just include every class which could be useful. Maybe this design is to heavyweight Hmm, I talked a too long time to myself, I know ;-) So, heres my question: I think that parrot could be the Gnu-version of .NET and could be a realy benefit for the whole opensource-world. No 20 runtimes need to be installed on a system - parrot would do the job better than each could alone (Because if many apps rely on parrot the JIT will be tuned by guys from IBM ;-) ). But in my opinion parrot needs a more complete classpath that perl5 currently has. Parrot is another level like perl5, perl5 was fine for scripting and even bigger apps worked great, bt it never tried to be a complete framework for many languages. Parrot is in my eyes a way to go away from C to higher level languages. So, my question: Is it planned to include a complete classpath into parrot, including gui, network, db, sound functionality or will it have only the really needed things like perl5 had? I know that everything is already available for perl5 installing bindings, but in my eyes this doesnt solve the problem. Many users dont want to install seperat libraries, they simply want to use parrot based apps with nice frontends, etc. I hope I didnt make you angry, and please dont missunderstand me, I think what you do is great! Please let me know what you think about the idea to include a complete classpath into parrot. lg Clemens
Re: Parrot - 100% Gnu.NET ?
Clemens Eisserer writes: (B Hi there! (B (B I$BB4(Bm a java programmer (B (BUh oh :-) (B (B and I$BB4(Bm not really experienced with perl. (B (B [...] (B (B I think that parrot could be the Gnu-version of .NET and could be a (B realy benefit for the whole opensource-world. No 20 runtimes need to be (B installed on a system - parrot would do the job better than each could (B alone (Because if many apps rely on parrot the JIT will be tuned by guys (B from IBM ;-) ). (B (B But in my opinion parrot needs a more complete "classpath" that perl5 (B currently has. (B (BThere is a big problem with that: it kinda precludes the whole (B"community" thing that made everyone love Perl 5. In particular, CPAN. (B (BThe plan for Perl 6, at least, is to include almost nothing in the base (Bdistribution, so administrators are forced to install some stuff from (BCPAN order for Perl to be useful at all[1]. (B (BWe need to harness the community work force of CPAN, for one because we (Bdon't have the work force ourselves to put together such a library. But (Bthe bigger reason is to enable the community to write modules, so we (Balways have forward progress on the language. (B (B Parrot is another level like perl5, perl5 was fine for scripting and (B even bigger apps worked great, bt it never tried to be a complete (B framework for many languages. (B Parrot is in my eyes a way to go away from C to higher level languages. (B (B So, my question: Is it planned to include a complete classpath into (B parrot, including gui, (B (Bmaybe (B (B network, (B (Byes (B (B db, (B (Bno (B (B sound functionality (B (Bno (B (B or will it have only the "really needed" things like perl5 had? (B I know that everything is already available for perl5 installing (B bindings, but in my eyes this doesnt solve the problem (B Many users dont want to install seperat libraries, they simply want to (B use parrot based apps with nice frontends, etc. (B (BAhh, I see what you mean. You want to distribute your app and parrot (Band have it Just Work. You can always include the needed modules in (Byour distribution and install them when you get there... but that kills (Bthe platform independence thing. You could tell parrot to install them (Bwhen you get there off the CPAN automatically, but from a commercial (Bstandpoint, that puts all your users in the hands of a -- possibly (Bmischievous -- module author (though I don't know any authors who would (Bdo such a thing, it's still a concern). (B (BThere will be a solution to the commercial thing. One of the (smaller) (Bgoals of Perl 6 is to be used commercially to some extent. (B (BA bigger goal, though, is to keep the open source support we already (Bhave. Including a big default classpath makes people feel like (Beverything is "easy enough," which, ironically, isn't easy enough. It (Bdoesn't motivate people to write/install modules. (B (BSo there you go, we're including everything we need to make the Easy (BThings Possible, and the community will worry about making them Easy. (B (BLuke (B (B (B I hope I didnt make you angry, and please dont missunderstand me, I (B think what you do is great! (B (B Please let me know what you think about the idea to include a "complete" (B classpath into parrot. (B (B lg Clemens (B (B (B (B[1] This was a big problem in Perl 5: admins would install Perl, and (Bassume that it's ready because it already comes with, like, 40 modules. (BAnd then nobody could use it, because there were no good modules (Binstalled.
