Re: pdd30_install
I've just committed an initial pass on the Installation PDD. It's looking good, definitely a good start. I've included some comments to seed further discussion and development of the draft. Also, we'll need to include more details on the installation of Parrot itself (the draft leans pretty heavily toward language installation, because that's the current problem). Thanks, Reini, for putting this together. It's much easier to talk about the architectural decisions and the reasons behind them when we abstract away to a design document. Allison
Re: pdd30_install
Allison Randal schrieb: Will Coleda wrote: It's important to keep in mind that for the most part, at least on unix-related operating systems, executables for a particular language will simply be an 'ln -s' to /usr/bin/parrot (taking advantage of the $0 executable name information to set up certain configuration for the runtime environment). I'm curious how you envision languages registering themselves for this special treatment? I'm assuming that when a language module is installed, it will not only store its libraries in a lib directory, and its executables in a bin directory, but also a small config file in some directory like /etc/parrot/languages/. That would give the name of the language, a few relevant paths, and probably some meta-information like the license of the language module. I don't like this idea of another language configuration file. We can do without. The name of the startup .pir/.pbc module is the same as registered via compreg, which must be the same as the name of the language directory. I want to call that now HLLNAME. TODO: only unl There are certain HLL's with multiple executables or different names. tcl wants to be named tclsh, so it will be /usr/bin/parrot-tclsh. Either symlinked to /usr/lib/parrot/library/tcl.pbc or as installable via pbc_to_exe --install linked to install_config.fpmc. bf has bf.pbc, bfc.pbc and bfco.pbc and parrot-bf, parrot-bfc and parrot-bfco installables. WMLScript has wmls2pir, wmls2pbc, wmlsd, wmlsi with its pbc's, but there's also the main WMLScript.pbc. Just the load_bytecode 'languages/WMLScript/src/WMLScript.pbc' is forbidden in the wmls* scripts. It must be load_bytecode 'WMLScript.pbc' and 'WMLScript.pbc' must be generated to runtime/parrot/library/, not in src. This load_bytecode 'languages/..' problem is in eclectus, forth, lua, PIR, tcl and WMLScript. I'll fix that by generating these pbc's directly to runtime/parrot/library/. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: pdd30_install
Reini Urban wrote: Problem: Most packages will not accept packages with /usr/bin/scheme, /usr/bin/lisp, /usr/bin/forth, /usr/bin/lua, /usr/bin/tclsh were these are the parrot implementations. Of course we don't want to hijack existing language executables in the distribution packages. But, it should be an easy compilation option in case, for example, someone is setting up a tiny embedded linux and wants to run Parrot in place of a whole collection of languages. It's important to keep in mind that for the most part, at least on unix-related operating systems, executables for a particular language will simply be an 'ln -s' to /usr/bin/parrot (taking advantage of the $0 executable name information to set up certain configuration for the runtime environment). So most packages use the parrot- prefix for all language installables, the pbc is without this prefix. With fedora and cygwin, the rest does not install language installables yet. And really, it's not only polite packaging practice, we *want* the parrot- prefix, it's good marketing for the virtual machine. The pbc files are not executables, and should be installed in a library directory, not in /usr/bin/. Current exceptions for the parrot- prefix: perl6 Actually, that probably won't be an exception to the parrot- prefix on the package name, since there are multiple implementations of Perl 6. Future possible exceptions: cardinal, chitchat, cola, eclectus, pheme, pynie, punie, squaak (wise choice in the names) For consistency I would suggest to introduce no such exceptions, besides perl6. But this is just a personal favor. Again, it should be a configuration option to install aliases for executables with the language nicknames. Not a requirement for the packaged versions, but the $0 handling will be built in to Parrot, so the user could also easily create their own 'ln -s' aliases. Allison
Re: pdd30_install
2008/8/29 Allison Randal: Reini Urban wrote: Current exceptions for the parrot- prefix: perl6 Actually, that probably won't be an exception to the parrot- prefix on the package name, since there are multiple implementations of Perl 6. Ok, so there will be pugs, perl -Mv6 and rakudo | parrot-perl6 Maybe both /usr/bin/rakudo and /usr/bin/perl6 should be symlinked to /usr/bin/parrot-perl6 then. Currently there's only a /usr/bin/perl6 being installed. This really should be made ready for the September release. Again, it should be a configuration option to install aliases for executables with the language nicknames. Not a requirement for the packaged versions, but the $0 handling will be built in to Parrot, so the user could also easily create their own 'ln -s' aliases. Good idea. Within the PCT::HLLCompiler I assume. So the few languages which are not based upon PCT::HLLCompiler will need some minor trickery. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: pdd30_install
On Fri, Aug 29, 2008 at 10:55 AM, Allison Randal [EMAIL PROTECTED] wrote: Reini Urban wrote: Problem: Most packages will not accept packages with /usr/bin/scheme, /usr/bin/lisp, /usr/bin/forth, /usr/bin/lua, /usr/bin/tclsh were these are the parrot implementations. Of course we don't want to hijack existing language executables in the distribution packages. But, it should be an easy compilation option in case, for example, someone is setting up a tiny embedded linux and wants to run Parrot in place of a whole collection of languages. It's important to keep in mind that for the most part, at least on unix-related operating systems, executables for a particular language will simply be an 'ln -s' to /usr/bin/parrot (taking advantage of the $0 executable name information to set up certain configuration for the runtime environment). I'm curious how you envision languages registering themselves for this special treatment? -- Will Coke Coleda
Re: pdd30_install
Reini Urban wrote: Ok, so there will be pugs, perl -Mv6 and rakudo | parrot-perl6 Maybe both /usr/bin/rakudo and /usr/bin/perl6 should be symlinked to /usr/bin/parrot-perl6 then. Currently there's only a /usr/bin/perl6 being installed. This really should be made ready for the September release. /usr/bin/perl6 is probably fine for now. Good idea. Within the PCT::HLLCompiler I assume. So the few languages which are not based upon PCT::HLLCompiler will need some minor trickery. In fact, in the Parrot interpreter itself. See src/main.c, the C function 'main'. We capture the name of the executable, but aren't currently doing much with it. The configuration file for each language will need to specify a .pbc/.pir module to load when starting up the language, then Parrot will start by running the :main PIR function from that module. So, using PCT::HLLCompiler won't be a requirement for using the feature. Allison
Re: pdd30_install
Will Coleda wrote: It's important to keep in mind that for the most part, at least on unix-related operating systems, executables for a particular language will simply be an 'ln -s' to /usr/bin/parrot (taking advantage of the $0 executable name information to set up certain configuration for the runtime environment). I'm curious how you envision languages registering themselves for this special treatment? I'm assuming that when a language module is installed, it will not only store its libraries in a lib directory, and its executables in a bin directory, but also a small config file in some directory like /etc/parrot/languages/. That would give the name of the language, a few relevant paths, and probably some meta-information like the license of the language module. Allison
Re: pdd30_install
On Fri, Aug 29, 2008 at 06:10:21PM +0200, Reini Urban wrote: 2008/8/29 Allison Randal: Reini Urban wrote: Current exceptions for the parrot- prefix: perl6 Actually, that probably won't be an exception to the parrot- prefix on the package name, since there are multiple implementations of Perl 6. Ok, so there will be pugs, perl -Mv6 and rakudo | parrot-perl6 Maybe both /usr/bin/rakudo and /usr/bin/perl6 should be symlinked to /usr/bin/parrot-perl6 then. Currently there's only a /usr/bin/perl6 being installed. This really should be made ready for the September release. Again, it should be a configuration option to install aliases for executables with the language nicknames. Not a requirement for the packaged versions, but the $0 handling will be built in to Parrot, so the user could also easily create their own 'ln -s' aliases. Good idea. Within the PCT::HLLCompiler I assume. PCT::HLLCompiler can't do it alone -- it will have to be part of the Parrot invocation in order to work. Thus my earlier comment/question [1] about this thread being related to the comments in RT #47992. [1] http://groups.google.com/group/perl.perl6.internals/msg/d9c8af92ed2ab04d Pm
Re: pdd30_install
Patrick R. Michaud wrote: On Fri, Aug 29, 2008 at 06:10:21PM +0200, Reini Urban wrote: 2008/8/29 Allison Randal: ... the $0 handling will be built in to Parrot, so the user could also easily create their own 'ln -s' aliases. Within the PCT::HLLCompiler I assume. PCT::HLLCompiler can't do it alone -- it will have to be part of the Parrot invocation in order to work. Thus my earlier comment/question [1] about this thread being related to the comments in RT #47992. Yes it is related. See my response to RT #47992 in RT #49168. Allison
