pdd19_pir.pod: See C<docs/imcc/macros.pod>
Reini Urban
It would be nice if this documents shows up somewhere, as I found nothing
more about macros, besides the section in pdd19_pir.pod
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Klaas-Jan Stol
information available on macros, currently
kjs
Will Coleda
Removed reference to obsolete doc in r30540.
--
Will "Coke" Coleda
Moritz Lenz
> pdd19_pir.pod references the not-existing docs/imcc/macros.pod.
>
> It would be nice if this documents shows up somewhere, as I found nothing
> more about macros, besides the section in pdd19_pir.pod
Actually I stumbled over quite a lot of dangling references in the docs.
Including, but not limited to, references to PDDS that still live in
draft/, but are references to be in docs/pdds/ directly.
What should we do with all these?
You can automatically check if the file exists, but youll get some false
negatives.
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Will Coleda
Links to files should be valid: If the file isn't where we are
pointing, the link should be updated (or removed, if necessary).
(Another way to fix the PDD issues is to eliminate the draft directory
and just mark PDDs that are still considered in DRAFT with some
decorative POD; that has my vote)
--
Will "Coke" Coleda
Allison Randal
> Moritz Lenz wrote:
>> Reini Urban wrote:
>> Actually I stumbled over quite a lot of dangling references in the docs.
>> Including, but not limited to, references to PDDS that still live in
>> draft/, but are references to be in docs/pdds/ directly.
>>
>> What should we do with all these?
>>
>> You can automatically check if the file exists, but youll get some false
>> negatives.
>
> pointing, the link should be updated (or removed, if necessary).
An automatic test is a very good idea. Don't run it as part of 'make
test' yet, but it'll give us a good baseline for going through and
fixing the broken links. We should change the links for any PDDs in
draft/ to say they're in draft/. Then the test will tell me all the
files that need to be updated after I move the PDD out of draft.
> (Another way to fix the PDD issues is to eliminate the draft directory
> and just mark PDDs that are still considered in DRAFT with some
> decorative POD; that has my vote)
I'm almost done with the PDDs in the draft directory. It's very helpful
to be able to look at that directory and know exactly how many PDDs are
still suffering from severe bit-rot.
So, yes, agreed on eliminating the docs/pdds/draft/ directory, but not
until we launch the final few PDDs out of it in a comprehensible form.
Allison
Allison Randal
>
> I have one more draft.
> chromatic told me write up such a thing, but it's not finished yet.
> It could go to the cygwin070patches branch which is really a
> parrot_install branch, but also to HEAD.
>
> This needs some technical review because but I'm still a beginner
> in what is possible and what not.
Thanks, applied to trunk in r30616. I gave it a quick read-through, but
haven't edited it yet. (Have added it to my Hiveminder todo list.)
All input from other parroteers welcome.
Allison
Moritz Lenz
> +=head1 DESCRIPTION
> +
> +Parrot installation mechanisms are more powerful than perl5's.
> +MANIFEST contains also the end location, tools/dev/install_files.pl is driven
> +by this definition.
To me it's not clear what the "end location" is - care to elaborate?
Reini Urban
>> +=head1 DESCRIPTION
>> +
>> +Parrot installation mechanisms are more powerful than perl5's.
>> +MANIFEST contains also the end location, tools/dev/install_files.pl is driven
>> +by this definition.
>
> To me it's not clear what the "end location" is - care to elaborate?
The end location by make install is a string concatation of
* the $(DESTDIR) as defined per Makefile argument,
* plus the respective Configure defined directoy (prefix,bin_dir, lib_dir,
include_dir, mandir, doc_dir, ...)
where the directores are defined by default to follow the FHS convention
and optional Configure.pl arguments,
and the files as defined in one of the three MANIFEST files in the format
<filename> \t [<package>]lib,doc,include,bin
- files from the [library] package go to prefix/lib_dir and either
dynext, library or include,
* plus the filename as defined by the three MANIFEST files.
There's additional logic in the tools/dev/install_files.pl script.
prefix defaults to "/usr/local" and packages define them as "/usr"
lib_dir defaults to prefix + "/lib"
and libraries go to parrot/dynext for shared libs (flat)
parrot/library for pbc files (structured
according to the namespace)
parrot/include for pir and pasm files (flat)
bin_dir to prefix + "/bin"
doc_dir to prefix + "/share/doc/parrot"
mandir to prefix + "/man", but it should be prefix + "/share/man"
according to the FHS
include_dir to prefix + "/include/parrot"
pkgconfig_dir to prefix + "/lib/pkgconfig"
What is missing is the end location of language pbc's and installable exe's.
The convention by fedora and cygwin for parrot-language installables is
$(DESTDIR)@bin_dir@/parrot-$(LANG)@exe@
Open problem:
For language pbc's a new dir like script_dir or lib_dir/parrot/bin
would be required.
They could also pollute $(DESTDIR)@lib_dir@/parrot/library where the other
pbc's are.
The language group and op shared libs go to $(DESTDIR)@lib_dir@/parrot/dynext
for sure.
e.g. tclsh.pbc, APL.pbc, ...
Moritz Lenz
> 2008/8/28 Moritz Lenz <mor...@casella.verplant.org>:
>>> +=head1 DESCRIPTION
>>> +
>>> +Parrot installation mechanisms are more powerful than perl5's.
>>> +MANIFEST contains also the end location, tools/dev/install_files.pl is driven
>>> +by this definition.
>>
>> To me it's not clear what the "end location" is - care to elaborate?
>
> The end location by make install is a string concatation of
[...]
so it's basically the individual, final destination path for that file?
Thanks for the explanation. My point is (and I admit that I wasn't
very clear about it) that IMHO the term "end location" is ambigous
(unless it's some kind of technical term with which I'm not familiar),
and thus should be changed in the pdd.
Cheers,
Reini Urban
> Reini Urban wrote:
>> 2008/8/28 Moritz Lenz <mor...@casella.verplant.org>:
>>>> +=head1 DESCRIPTION
>>>> +
>>>> +Parrot installation mechanisms are more powerful than perl5's.
>>>> +MANIFEST contains also the end location, tools/dev/install_files.pl is driven
>>>> +by this definition.
>>>
>>> To me it's not clear what the "end location" is - care to elaborate?
>>
>> The end location by make install is a string concatation of
>
> [...]
>
> so it's basically the individual, final destination path for that file?
"final destination path" is of course much better.
Someone might be tempted to look for the PC game or the movie.
> Thanks for the explanation. My point is (and I admit that I wasn't
> very clear about it) that IMHO the term "end location" is ambigous
> (unless it's some kind of technical term with which I'm not familiar),
> and thus should be changed in the pdd.
My draft is very rough, and needs some more days.
I've also put into the parrot wiki, so that you can easily can change
things. I'll pick it up then.
http://www.perlfoundation.org/parrot/index.cgi?parrot_installation
Patrick R. Michaud
> Open problem:
> For language pbc's a new dir like script_dir or lib_dir/parrot/bin
> would be required.
> They could also pollute $(DESTDIR)@lib_dir@/parrot/library where the other
> pbc's are.
> The language group and op shared libs go to $(DESTDIR)@lib_dir@/parrot/dynext
> for sure.
> e.g. tclsh.pbc, APL.pbc, ...
I'd be a bit surprised if the .pbc files went into dynext/ -- that doesn't
seem to match what currently exists there (which is all .so files on
my system).
At the moment I'm planning for language pbcs to go into
.../parrot/library/ so they can be easily accessed via
load_bytecode. I've found that in a dynamic environment like
Parrot there's very little difference between a language and
a library [1]. :-)
Also, I wonder if any of this relates to RT #47992 ("'parrot foo'
automatically finds and invokes foo.pbc")?
Pm
[1] "CPAN is my programming language of choice; the rest is just syntax."
--Audrey Tang
Reini Urban
> On Thu, Aug 28, 2008 at 02:10:27PM +0200, Reini Urban wrote:
>> Open problem:
>> For language pbc's a new dir like script_dir or lib_dir/parrot/bin
>> would be required.
>> They could also pollute $(DESTDIR)@lib_dir@/parrot/library where the other
>> pbc's are.
>> The language group and op shared libs go to $(DESTDIR)@lib_dir@/parrot/dynext
>> for sure.
>> e.g. tclsh.pbc, APL.pbc, ...
>
> I'd be a bit surprised if the .pbc files went into dynext/ -- that doesn't
> seem to match what currently exists there (which is all .so files on
> my system).
Sure.
My comment about the tclsh.pbc, APL.pbc, ... was referring to the
language pbc's, not to the group and op shared libs.
> At the moment I'm planning for language pbcs to go into
> .../parrot/library/ so they can be easily accessed via
> load_bytecode. I've found that in a dynamic environment like
> Parrot there's very little difference between a language and
> a library [1]. :-)
That's probably the best, but we can also think of not installing that at all,
and only install executables. But then the new pddxx_language_interop.pod
at http://nopaste.snit.ch/13890 will have problems. exe cannot loaded
from other languages, only pbc's.
So each language will need its root namespace reserved for it's <lang>.pbc.
We could thing of symlinking it to runtime/parrot/library
at make languages, so language_interop can be tested.
> Also, I wonder if any of this relates to RT #47992 ("'parrot foo'
> automatically finds and invokes foo.pbc")?
If foo.pbc is in parrot/library/foo.pbc then it will be found.
The pbc library searchpath is only "." and "@lib_dir@/parrot/library".
Also PARROT_RUNTIME can be defined in ENV to override
the runtime prefix and therefore the library search path..
Will Coleda
Right. We have to (eventually) install the pbcs, no matter if we also
install the exes for convenience.
> So each language will need its root namespace reserved for it's <lang>.pbc.
While it would help, there's no guarantee that namespace in PBC
matches path on filesystem.
> We could thing of symlinking it to runtime/parrot/library
> at make languages, so language_interop can be tested.
Are symlinks usable wherever we might install?
>> Also, I wonder if any of this relates to RT #47992 ("'parrot foo'
>> automatically finds and invokes foo.pbc")?
>
> If foo.pbc is in parrot/library/foo.pbc then it will be found.
>
> The pbc library searchpath is only "." and "@lib_dir@/parrot/library".
>
> Also PARROT_RUNTIME can be defined in ENV to override
> the runtime prefix and therefore the library search path..
I had always thought that the compiler/compreg opcode would eventually
be extended to load the library we needed for language interop; If
not, I'm not sure there's much point in keeping the ability to
register compilers, is there? If someone wants to use the tcl
compiler, they need to know to load the bytecode first anyway.
> --
> Reini Urban
> http://phpwiki.org/ http://murbreak.at/
>
--
Will "Coke" Coleda
Reini Urban
> On Thu, Aug 28, 2008 at 11:09 AM, Reini Urban <rur...@x-ray.at> wrote:
>> We could thing of symlinking it to runtime/parrot/library
>> at make languages, so language_interop can be tested.
>
> Are symlinks usable wherever we might install?
True, there's no perl -MExtUtils::Command -e ln_s
But we have LN_S = @lns@
Andy Dougherty
> Will Coleda schrieb:
> > On Thu, Aug 28, 2008 at 11:09 AM, Reini Urban <rur...@x-ray.at> wrote:
> > > We could thing of symlinking it to runtime/parrot/library
> > > at make languages, so language_interop can be tested.
> >
> > Are symlinks usable wherever we might install?
>
> True, there's no perl -MExtUtils::Command -e ln_s
> But we have LN_S = @lns@
But that's not necessarily a symbolic link. It was originally intended
only for use with files, not directories. If symlinks aren't available on
Unix, it falls back to a plain 'ln'. On Win32 versions of perl, lns is
usually defined as 'copy'.
So the short answer is that, at the moment, without additional
Configure.pl work, you can't assume $Config{lns} can be used to make
symbolic links for directories.
--
Andy Dougherty doug...@lafayette.edu
Reini Urban
I only wanted to link the language pbc files from
languages/<lang>/<lang>.pbc to runtime/parrot/library/<lang>.pbc
And only if someone needs it for hll interop testing.
Allison Randal
>>
>>> At the moment I'm planning for language pbcs to go into
>>> .../parrot/library/ so they can be easily accessed via
>>> load_bytecode. I've found that in a dynamic environment like
>>> Parrot there's very little difference between a language and
>>> a library [1]. :-)
>> That's probably the best, but we can also think of not installing that at all,
>> and only install executables. But then the new pddxx_language_interop.pod
>> at http://nopaste.snit.ch/13890 will have problems. exe cannot loaded
>> from other languages, only pbc's.
>
> Right. We have to (eventually) install the pbcs, no matter if we also
> install the exes for convenience.
Yes. And the exes (or aliases to the parrot exe) should go in the same
bin directory as parrot.
>> So each language will need its root namespace reserved for it's <lang>.pbc.
>
> While it would help, there's no guarantee that namespace in PBC
> matches path on filesystem.
The fundamental principle is that language implementations are like CPAN
modules. You can install them as a separate package, and they add
functionality. Just like a CPAN module, there's a default search path
where the module name matches the filesystem path, possibly with some
prefix path, and with the HLL namespace treated as part of the full name
of the module (/usr/lib/parrot/lang/python/my/module.pbc or whatever).
There also need be ways to change the default path when compiling
Parrot, and to change the searched paths at runtime.
>> We could thing of symlinking it to runtime/parrot/library
>> at make languages, so language_interop can be tested.
>
> Are symlinks usable wherever we might install?
No. And not necessary as long as search paths are configurable, which
they have to be anyway.
> I had always thought that the compiler/compreg opcode would eventually
> be extended to load the library we needed for language interop; If
> not, I'm not sure there's much point in keeping the ability to
> register compilers, is there? If someone wants to use the tcl
> compiler, they need to know to load the bytecode first anyway.
That's backwards. Loading the language module is what registers the
compiler. The user never needs to access the compiler object for a
particular language directly unless they're compiling code from a string.
Allison
Allison Randal
> On Thu, Aug 28, 2008 at 11:10:47PM +0200, Allison Randal wrote:
>> That's backwards. Loading the language module is what registers the
>> compiler. The user never needs to access the compiler object for a
>> particular language directly unless they're compiling code from a string.
>
> HLL's rules, obtain a namespace from another HLL, or load a library
> associated with a different HLL. (See pdd21 - namespaces.)
I've always assumed that those behaviors would be hidden behind methods
on the namespace PMC, which would delegate them to the appropriate
compiler PMC.
Allison
Patrick R. Michaud
> compiler. The user never needs to access the compiler object for a
> particular language directly unless they're compiling code from a string.
...or if they want to parse a namespace string according to another
HLL's rules, obtain a namespace from another HLL, or load a library
associated with a different HLL. (See pdd21 - namespaces.)
Pm
Reini Urban
whole time]
Allison Randal schrieb:
> Will Coleda wrote:
>>>> At the moment I'm planning for language pbcs to go into
>>>> .../parrot/library/ so they can be easily accessed via
>>>> load_bytecode. I've found that in a dynamic environment like
>>>> Parrot there's very little difference between a language and
>>>> a library [1]. :-)
>>> That's probably the best, but we can also think of not installing
>>> that at all,
>>> and only install executables. But then the new
>>> pddxx_language_interop.pod
>>> at http://nopaste.snit.ch/13890 will have problems. exe cannot loaded
>>> from other languages, only pbc's.
>>
>> Right. We have to (eventually) install the pbcs, no matter if we also
>> install the exes for convenience.
>
> Yes. And the exes (or aliases to the parrot exe) should go in the same
> bin directory as parrot.
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.
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.
Current exceptions for the "parrot-" prefix:
perl6
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.
Allison Randal
> 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
Reini Urban
> 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.
Will Coleda
> 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
Allison Randal
>
> 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
Allison Randal
>>
>> 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
Patrick R. Michaud
> 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
Allison Randal
> On Fri, Aug 29, 2008 at 06:10:21PM +0200, Reini Urban wrote:
>> 2008/8/29 Allison Randal:
>>> user could also easily create their own 'ln -s' aliases.
>
> 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
Reini Urban
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/.
Allison Randal
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