[svn:parrot-pdd] r30616 - trunk/docs/pdds/draft
Author: allison Date: Thu Aug 28 02:02:51 2008 New Revision: 30616 Added: trunk/docs/pdds/draft/pdd30_install.pod Log: [pdd] Adding a draft installation PDD, thanks to Reini Urban. Added: trunk/docs/pdds/draft/pdd30_install.pod == --- (empty file) +++ trunk/docs/pdds/draft/pdd30_install.pod Thu Aug 28 02:02:51 2008 @@ -0,0 +1,213 @@ +# Copyright (C) 2008, The Perl Foundation. +# $Id: pdd30_install.pod 30255 2008-08-23 12:15:46Z rurban $ + +=head1 NAME + +docs/pdds/draft/pdd30_install.pod - Parrot Installation + +=head1 ABSTRACT + +This PDD defines Parrot's installation details. The goal is to provide binary +packages, a working Cmake install for parrot, the installables, FHS compliant +search paths for the installables and solving the problem of not accessing +installed source-only files and the optimization of config bootstrapping +if a frozen config_hash is already linked. + +=head1 VERSION + +$Revision: 30459 $ + +=head1 SYNOPSIS + + make install + make test-installable -C language/lang + make installable -C language/lang + make install -C language/lang DESTDIR=inst + +=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. +The three runtime paths for include, library for load_bytecode and dynext +for loadlib should end up in the $prefix/lib/parrot paths. +See #56996-fhs-runtime.patch + +Contrary to perl5, parrot and its language implementions on top of parrot may +be installed as self-hosting single-file executables, with the help of merged +pbc's and pbc2exe --install. + +Bootstrapping the config hash should not read a config file when the hash is +already contained in the pmc or executable. See #57418 [TODO] optimize +_config to omit .include library/config.pir on installables. + +The same problem is for every .include, .loadlib and .load_bytecode statement +in installed files where the target is not installed. This could be solved with +a module system or with pbc_merge removing not needed .load_bytecode statements. + +Test executables are binary different to installable executables because of +this embedded config hash. Test executables contain config hash with +the prefix to the build_dir, installables to the given prefix from Configure.pl. + +There are's also a long-standing conflict in building parrot with an already +installed shared libparrot.so. See #39742-installed-conflict.patch which adds +the blib/lib path to PATH resp. LD_RUN_PATH. + +=head1 DEFINITIONS + +An Binstallable is a pbc or exe which must not access the build_dir +paths. The build_dir is not available in a binary package. This is solved by +generating and linking a special Finstall_config.fpmc. Custom python modules +have a similar packaging problem, which they haven't solved yet. + +Bbuild_dir is the full path where parrot was built. It is defined in the +config hash. When building from source build_dir is also the PARROT_RUNTIME prefix. + +BDESTDIR is the end location of the parrot tree in front of the prefix +(/usr or /usr/local). This allows packaging by installing into a seperate +install tree and do a tar cf there. + +The Bconfig hash is the return value of the global function C_config(), +generated in Fconfig_lib.pasm, and either defined in Flibrary/config.pir, or +as frozen pmc embedded in the test executable (Fconfig.fpmc), the installable +executable (Finstall_config.fpmc) or empty for miniparrot (Fnull_config.fpmc). + +=head1 IMPLEMENTATION + +=head2 make install + +The parrot build system is optimized for building and testing in the +build_dir, but not for building with an already installed parrot due to simple +build system bugs, and not optimized to build and test installables, which should +not access the libraries in the build_dir, but in the DESTDIR. + +The goal is to make install work for parrot, the utils, and all the languages. +For parrot and its utils the install actions are defined in the main Makefile, +for the languages the install actions should be defined in its Makefiles and +is implemented in #56554-make-install-lang.patch. + +Cmake install currently does not work with an already installed shared +libparrot.so on most platforms. There's a patch at #39742. + +make install actions for a language lang: + + copy installables to DESTDIR/bin_dir as parrot-lang + optionally copy lang.pbc to DESTDIR/script_dir (/usr/lib/parrot/bin/ ?) + copy libraries to DESTDIR/lib_dir/parrot/dynext/ + optionally copy pbc's to DESTDIR/lib_dir/parrot/library/ (only php_ext) + optionally copy include pasm and pirs to DESTDIR/lib_dir/parrot/include/ (not yet) + copy docs to DESTDIR/doc_dir/ + generate a man(1) page and copy to DESTDIR/man_dir/ + optionally generate html and copy to DESTDIR/html_dir/lang/ + +=head2 make installable -C languages/lang + +This creates a pbc or exe linked to
pdd30_install.pod (was Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod)
Reini Urban wrote: 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
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
Reini Urban wrote: +=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? Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: struct and pointer to pointer in ATTR
NotFound wrote:
Hello.
The current grammar for ATTR in pmc2c allows declarations of the form:
type * varname
In the perl6multisub pmc we have the attribute candidates_sorted whose
intended type is candidate_info **, having two problems:
The current grammar allows a single pointer, not a pointer to a
pointer. This can be easily solved.
candidate_info is a struct declared in the pmc file (as typedef struct
candidate_info { ... } candidate_info), then his declaration is not
viewable at the point of inclusion of the generated h file. This can
be solved by declaring the ATTR with type struct candidate_info
instead of candidate_info, but the grammar for ATTR does not allow it.
I think that allowing struct in ATTR is the simpler solution to the
second problem, because the intended usage is for struct used
internally in the pmc, not for his documented interface.
The attached patch changes the ATTR grammar and uses the changes to
clean the workarounds currently used in perl6multsub pmc. It passes
all coretest on my system, both building with C or with C++.
Approved for application. But, keep in mind that ATTRs other than
INTVAL, FLOATVAL, STRING *, and PMC * cannot have automatic
GET_ATTR/SET_ATTR accessor macros generated for them, and any C PMCs
with these low-level ATTRs cannot be subclassed from PIR/HLLs.
Allison
[svn:parrot-pdd] r30604 - in trunk: docs/pdds/draft src
Author: Whiteknight Date: Wed Aug 27 16:25:00 2008 New Revision: 30604 Modified: trunk/docs/pdds/draft/pdd11_extending.pod Changes in other areas also in this revision: Modified: trunk/src/extend.c trunk/src/inter_run.c Log: [DOCS] Document Parrot_call_method as per RT#36243. Also, document a function that is a dependency of this one. Modified: trunk/docs/pdds/draft/pdd11_extending.pod == --- trunk/docs/pdds/draft/pdd11_extending.pod (original) +++ trunk/docs/pdds/draft/pdd11_extending.pod Wed Aug 27 16:25:00 2008 @@ -283,11 +283,13 @@ up Parrot's registers in line with the Parrot calling conventions; see Lpdd03_calling_conventions.pod for more details. -=item CParrot_call_method(interp, -Parrot_PMC sub, Parrot_String method, Parrot_Int argcount, ...) +=item CParrot_call_method(PARROT_INTERP, Parrot_PMC sub, Parrot_PMC obj, +Parrot_String method, ARGIN(const char *signature), ...) -Calls a Parrot method named Cmethod with Cargcount PMC parameters. NB. -This is not yet implemented and may change. +Call the parrot subroutine Csub as a method on PMC object Cobj. The method +should have the name Cmethod as a Parrot_string, and should have a function +signature Csignature. Any arguments to the method can be passed at the end +as a variadic argument list. =back
[perl #46823] [TODO] [Pir] Rewrite Resizeable*Array tests properly when exceptions are implemented
On Thu Oct 25 00:49:38 2007, pcoch wrote: To be totally honest I wish I knew. I'm just going through converting the todo items in code into RT tickets and sometimes the todo comments aren't necessarily all that clear as to what needs to be done. I'm also (unfortunately) not familiar enough with pir to see in the code of the tests what needs fixing otherwise I might have been able to expand a little in the ticket. I'm really sorry I can't be of more help here! Paul Most of these test wouldn't throw an exception anyway, since assigning to a positive out-of-bounds element simply resizes the array. (This excludes nonsensically large positive indicies, which should probably tested for.) I added exception handling for oob indicies to the one fixed array test in r30610, which still passes. I deleted the other references to this ticket. It's possible that out-of-bounds refers to negative indicies. I added some tests with exception handlers for those cases in r30611. If there are no objections, I'll mark this resolved after the weekend. Christoph
[perl #58414] [TODO] review calling conventions
# New Ticket Created by Allison Randal # Please include the string: [perl #58414] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58414 Briefly discussed in a phone call with Patrick, Jerry, and chromatic: Our calling conventions have grown in an organic fashion over the past few years, and they're showing some signs of cruft. The current design and implementation could use a consistency review. Among the topics for review: - VTABLE_invoke is inconsistent between different sub-like PMCs. For most subs it simply sets up the environment for invocation, and selects the first opcode instruction of the sub as the next 'opcode_t *' for 'runops'. For NCI subs it actually invokes the function pointer. The disjoint means that NCI subs can't be invoked from C argument lists the same way as all the other subs (because the regular C argument list passing can only happen *after* VTABLE_invoke has been called to set up the environment, but NCI requires the arguments to be passed *before* the call to VTABLE_invoke). - Also, VTABLE_invoke can't really be overridden from PIR, because it requires direct access to low-level interpreter data structures. - Standardize on PCC-style signature description strings throughout the system (instead of different signature description strings for NCI, PCC, and regular subs). - Refactor to remove code duplication between the various dispatch systems. - Optimize PCC dispatch (refactor to slim down the code). - Enable dispatching by CallSignature PMC everywhere. Some of these elements may be post-1.0 features. Consider this ticket a collection point for calling convention issues, and link in related tickets. Allison
[perl #58410] [TODO] Deprecate n_* variants of the math opcodes
# New Ticket Created by Allison Randal # Please include the string: [perl #58410] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58410 Briefly discussed on the phone with Patrick, Jerry, and chromatic: The versions of the math opcodes that modify an existing destination PMC instead of creating a new destination PMC are not useful to HLLs, because they make assumptions about assignment semantics that don't hold true for all (or possibly even any) HLLs. Code generated from PCT takes the result of the math op as a temporary result value, and then performs a separate assignment operation to the HLL result variable, following the HLLs semantics for assignment. The plan is to make the regular variants (like 'add') create a new destination PMC, and then deprecate the old n_* variants (like 'n_add'). Allison
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
2008/8/28 Moritz Lenz [EMAIL PROTECTED]: +=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, ... -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: struct and pointer to pointer in ATTR
On Thu, Aug 28, 2008 at 11:33 AM, Allison Randal [EMAIL PROTECTED] wrote: Approved for application. But, keep in mind that ATTRs other than INTVAL, FLOATVAL, STRING *, and PMC * cannot have automatic GET_ATTR/SET_ATTR accessor macros generated for them, and any C PMCs with these low-level ATTRs cannot be subclassed from PIR/HLLs. Applied in r30617 the pmc2c part and in r30618 the perl6multisub part. -- Salu2
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
Reini Urban wrote: 2008/8/28 Moritz Lenz [EMAIL PROTECTED]: +=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, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
2008/8/28 Moritz Lenz [EMAIL PROTECTED]: Reini Urban wrote: 2008/8/28 Moritz Lenz [EMAIL PROTECTED]: +=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 -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
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).
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
Re: [perl #58076] Configure tests fail with Can't store CODE items
On Tue, 26 Aug 2008, James Keenan via RT wrote: Patched two subs in Parrot::Configure and adjusted test files in r30583. Tested with triggers in hints files on Linux and Darwin. Thanks. That closes this ticket and just leaves us with the old familiar: t/steps/auto_warnings-01.Compilation failed with 'cc' # Looks like you planned 56 tests but only ran 15. dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 16-56 Failed 41/56 tests, 26.79% okay where I've told Configure.pl to use gcc, but the test still falls back on using the incorrect value of 'cc' that perl5 was built with. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #58414] [TODO] review calling conventions
Two other items that ought to be taken into consideration: - We need an implementation of the :lookahead flag for Rakudo. (See discussion thread at [1].) - Per a conversation with Allison and Jonathan at YAPC::EU, it might be useful to have a :capture flag on parameters and return values to capture all arguments into a single (Capture) PMC. [1] http://groups.google.com/group/perl.perl6.internals/browse_thread/thread/fce44e38aa856be9/96417ed37799cd37 Pm
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
2008/8/28 Patrick R. Michaud [EMAIL PROTECTED]:
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..
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
[svn:parrot-pdd] r30620 - trunk/docs/pdds/draft
Author: allison
Date: Thu Aug 28 09:09:48 2008
New Revision: 30620
Added:
trunk/docs/pdds/draft/pdd31_hll_interop.pod
Log:
[pdd] Adding an early draft PDD for HLL interoperability, from Bob Rogers.
Added: trunk/docs/pdds/draft/pdd31_hll_interop.pod
==
--- (empty file)
+++ trunk/docs/pdds/draft/pdd31_hll_interop.pod Thu Aug 28 09:09:48 2008
@@ -0,0 +1,466 @@
+# Copyright (C) 2008, The Perl Foundation.
+# $Id: $
+
+=head1 NAME
+
+docs/pdds/pddxx_language_interop.pod - Inter-language calling
+
+=head1 VERSION
+
+$Revision: 28231 $
+
+=head1 ABSTRACT
+
+This PDD describes Parrot's conventions and support for communication between
+high-level languages (HLLs). It is focused mostly on what implementors should
+do in order to provide this capability to their users.
+
+=head1 DESCRIPTION
+
+The ability to mix different high-level languages at runtime has always been
+an important design goal of Parrot. Another important goal, that of
+supporting all dynamic languages, makes language interoperability especially
+interesting -- where interesting means the same as it does in the Chinese
+curse, May you live in interesting times. It is expected that language
+implementers, package authors, and package users will have to be aware of
+language boundaries when writing their code. It is hoped that this will not
+become too burdensome.
+
+None of what follows is binding on language implementors, who may do whatever
+they please. Nevertheless, we hope they will at least follow the spirit of
+this document so that the code they produce can be used by the rest of the
+Parrot community, and save the fancy footwork for intra-language calling.
+However, this PDD Bis binding on Parrot implementors, who must provide a
+stable platform for language interoperability to the language implementors.
+
+=head2 Ground rules
+
+In order to avoid N**2 complexity and the resulting coordination headaches,
+each language compiler provides an interface as a target for other languages
+that should be designed to require a minimum of translation. In the general
+case, some translation may be required by both the calling language and the
+called language:
+
+|
+ |
+|Calling sub
+| |
+| Language X|
+| V
+|Calling stub
++ |
+ |
+ plain Parrot |
+ |
++ |
+|V
+| Called wrapper
+| |
+| |
+| Language YV
+| Called sub
+ |
+
+Where necessary, a language may need to provide a wrapper sub to interface
+external calls to the language's internal calling and data representation
+requirements. Such wrappers are free to do whatever translation is required.
+
+Similarly, the caller may need to emit a stub that converts an internal call
+into something more generic.
+
+{{ Of course, stub is really too close to sub, so we should find a better
+word. Doesn't the C community call these bounce routines? Or something?
+-- rgr, 31-Jul-08. }}
+
+{{ I am discovering that there are five different viewpoints here,
+corresponding to the five layers (including plain Parrot) of the diagram
+above. I need to make these viewpoints clearer, and describe the
+responsibilities of each of these parties to each other. -- rgr,
+31-Jul-08. }}
+
+Languages are free to implement the stub and wrapper layers (collectively
+called glue) as they see fit. In particular, they may be inlined in the
+caller, or integral to the callee.
+
+Ideally, of course, the plain Parrot layer will be close enough to the
+semantics of both languages that glue code is unnecesary, and the call can be
+made directly. Language implementors are encouraged to dispense with glue
+whenever possible, even if glue is sometimes required for the general case.
+
+In summary:
+
+=over 4
+
+=item *
+
+Each HLL gets its own namespace subtree, within which Cget_hll_global and
+Cset_hll_global operate. In order to make external calls, the HLL must
+provide a means of identifying the language, the function, and enough
+information about the arguments and return values for the calling language to
+generate the call correctly. This is necessarily language-dependent, and is
+beyond the scope of this document.
+
+=item *
+
+When calling across languages, both the caller and the callee should try to
+use plain Parrot semantics to the extent possible. This is explained in
+more detail below, but essentially means to use the simplest calling
+conventions and PMC classes possible.
Re: [svn:parrot-pdd] r30620 - trunk/docs/pdds/draft
[EMAIL PROTECTED] wrote:
+{{ Is the term unimethod acceptable here? -- rgr, 29-Jul-08. }}
I think for dispatch the term is single dispatch, and unimethod
could thus be single method.
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: [perl #58410] [TODO] Deprecate n_* variants of the math opcodes
On Thu, 2008-08-28 at 00:03 -0700, Allison Randal wrote: Briefly discussed on the phone with Patrick, Jerry, and chromatic: The versions of the math opcodes that modify an existing destination PMC instead of creating a new destination PMC are not useful to HLLs, because they make assumptions about assignment semantics that don't hold true for all (or possibly even any) HLLs. Code generated from PCT takes the result of the math op as a temporary result value, and then performs a separate assignment operation to the HLL result variable, following the HLLs semantics for assignment. The plan is to make the regular variants (like 'add') create a new destination PMC, and then deprecate the old n_* variants (like 'n_add'). What is the replacement for the old regular variants that use a pre-existing destination? A few years ago when I was doing copious Perl 5 PDL work, I found that in certain loops I would get bottlenecked entirely by creation and destruction of temporaries. I might be doing several dozen math operations per iteration, but I as the programmer knew that I only needed a handful of temporaries, and these could be created outside the loop. The vast majority of the object cycling was quite obviously wasted. In some cases, I could work around this by considerably uglifying the code and/or reaching through several layers of abstraction, but sometimes there was no recourse except to drop to PDL::PP (specially preprocessed C) or even C itself. I'd like to be able to write decently-performing math libraries in PIR, instead of having to drop down all the way to C. Being forced to create and destroy loads of temporaries I don't need will make this nigh impossible, let alone putting a major strain on the GC subsystem. Will there be some way to stay in PIR and still optimize away temporary cycling? -'f
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
On Thu, Aug 28, 2008 at 11:09 AM, Reini Urban [EMAIL PROTECTED] wrote:
2008/8/28 Patrick R. Michaud [EMAIL PROTECTED]:
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.
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
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
Will Coleda schrieb:
On Thu, Aug 28, 2008 at 11:09 AM, Reini Urban [EMAIL PROTECTED] 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@
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/
Re: gsoc_nci merge
François Perrad schrieb: The following patch adds NCIGEN in the documentation (HTML generated). Note : needs a better title than 'Native Call Interface Generator'. Why? I find it perfect. It makes sense and it even matches the abbrevation. Java: Java native interface code generator www.freepatentsonline.com/6066181.html Native Call Stub Generator
Re: [perl #57190] HLL Interoperation
Bob Rogers wrote: OK, here's my straw-man proposal for a language interoperability framework; my apologies for sitting on it so long. It's still pretty messy, but I'm sure it will benefit more from other viewpoints at this stage than from polishing. Thanks, added to trunk as pdd31_hll_interop.pod in r30620. I gave it a quick review, but haven't edited it yet. Allison
[PATCH] more packages
Will Coleda schrieb: On Sun, Aug 24, 2008 at 12:26 PM, Moritz Lenz [EMAIL PROTECTED] wrote: Reini Urban wrote: 2008/8/23 François Perrad [EMAIL PROTECTED]: 2008/8/23 Allison Randal [EMAIL PROTECTED]: Moritz Lenz wrote: On #perl6 somebody just asked if there were up-to-date windows builds of parrot somewhere, he had googled for 'parrot windows'. The parrotwin32 project didn't show up in his search (but it's first for 'parrot win32'). I think we should improve that situation. Suggestions: 1) A link on http://www.parrotcode.org/source.html Sure. Already done since 2-3 months, see http://www.parrotcode.org/source.html#Packages, but with the word Win32, not Windows. Cygwin is missing there: a href=http://cygwin.com/;Cygwin/a Attached patch adds that. I don't see the source for the webpage, so I can only do the next ones like this: lia href=http://alioth.debian.org/projects/pkg-parrot/;Debian Packages/a/li + lia href=http://www.gentoo-portage.com/dev-lang/parrot;Gentoo/a/li + lia href=http://www.freebsd.org/cgi/ports.cgi?query=parrot;Freebsd/a/li lia href=http://sourceforge.net/project/showfiles.php?group_id=211372;Windows (Win32)/a/li lia href=http://cygwin.com/;Cygwin/a/li -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
On Thu, 28 Aug 2008, Reini Urban wrote:
Will Coleda schrieb:
On Thu, Aug 28, 2008 at 11:09 AM, Reini Urban [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: [PATCH] more packages
On Thu, Aug 28, 2008 at 2:37 PM, Reini Urban [EMAIL PROTECTED] wrote: Will Coleda schrieb: On Sun, Aug 24, 2008 at 12:26 PM, Moritz Lenz [EMAIL PROTECTED] wrote: Reini Urban wrote: 2008/8/23 François Perrad [EMAIL PROTECTED]: 2008/8/23 Allison Randal [EMAIL PROTECTED]: Moritz Lenz wrote: On #perl6 somebody just asked if there were up-to-date windows builds of parrot somewhere, he had googled for 'parrot windows'. The parrotwin32 project didn't show up in his search (but it's first for 'parrot win32'). I think we should improve that situation. Suggestions: 1) A link on http://www.parrotcode.org/source.html Sure. Already done since 2-3 months, see http://www.parrotcode.org/source.html#Packages, but with the word Win32, not Windows. Cygwin is missing there: a href=http://cygwin.com/;Cygwin/a Attached patch adds that. I don't see the source for the webpage, so I can only do the next ones like this: lia href=http://alioth.debian.org/projects/pkg-parrot/;Debian Packages/a/li + lia href=http://www.gentoo-portage.com/dev-lang/parrot;Gentoo/a/li + lia href=http://www.freebsd.org/cgi/ports.cgi?query=parrot;Freebsd/a/li lia href=http://sourceforge.net/project/showfiles.php?group_id=211372;Windows (Win32)/a/li lia href=http://cygwin.com/;Cygwin/a/li -- Reini Urban http://phpwiki.org/ http://murbreak.at/ https://svn.perl.org/perl.org/docs/live/parrotcode Applied, thanks! -- Will Coke Coleda
Re: [perl #57190] HLL Interoperation
Allison Randal wrote: Bob Rogers wrote: OK, here's my straw-man proposal for a language interoperability framework; my apologies for sitting on it so long. It's still pretty messy, but I'm sure it will benefit more from other viewpoints at this stage than from polishing. Thanks, added to trunk as pdd31_hll_interop.pod in r30620. I gave it a quick review, but haven't edited it yet. I've added a series of inline comments to help guide further discussion. Thanks for raising key points to get the discussion started. Allison
[svn:parrot-pdd] r30622 - trunk/docs/pdds/draft
Author: allison
Date: Thu Aug 28 12:43:19 2008
New Revision: 30622
Modified:
trunk/docs/pdds/draft/pdd31_hll_interop.pod
Log:
[pdd] Adding a series of architectural comments to the HLL Interop PDD.
Modified: trunk/docs/pdds/draft/pdd31_hll_interop.pod
==
--- trunk/docs/pdds/draft/pdd31_hll_interop.pod (original)
+++ trunk/docs/pdds/draft/pdd31_hll_interop.pod Thu Aug 28 12:43:19 2008
@@ -41,6 +41,13 @@
case, some translation may be required by both the calling language and the
called language:
+{{ There seems to be an implied basic assumption here that language
+interoperability is the responsibility of the language implementor. It is not.
+We cannot require that language implementors design and implement their
+languages according to some global specification. Any interoperability
+infrastructure must be provide by Parrot, and must work for all languages.
+--allison }}
+
|
|
|Calling sub
@@ -70,7 +77,13 @@
{{ Of course, stub is really too close to sub, so we should find a better
word. Doesn't the C community call these bounce routines? Or something?
--- rgr, 31-Jul-08. }}
+-- rgr, 31-Jul-08.
+
+The language will never provide a wrapper for its subs. For the most part,
+wrappers will be unnecessary. Where a wrapper is desired to make a library from
+some other language act more like a native library, the person who desires
+the native behavior can implement the wrapper and make it publically available.
+--allison }}
{{ I am discovering that there are five different viewpoints here,
corresponding to the five layers (including plain Parrot) of the diagram
@@ -109,6 +122,8 @@
are provided by a bare Parrot (i.e. one without any HLL runtime code), then
it should be possible to use this API from any other language.
+{{ This is unnecessarily restrictive --allison }}
+
=item *
It is acceptable for languages to define subs for internal calling that are
@@ -117,6 +132,8 @@
call intra-language subs, they should be very sure they understand that
language's calling conventions.
+{{ It's not possible to define a sub that can't be called externally --allison
}}
+
=back
=head1 HALF-BAKED IDEAS
@@ -139,13 +156,22 @@
access the module API (though it may need additional hints). Of course, that
also requires a PIR API for accessing this metainformation . . .
+{{ Exporting is very much a Perl idea, not much applicability for exporting
+outside of Perl. --allison}}
+
Crazy idea: This is more or less the same information (typing) required for
multimethods. If we encourage the export of multisubs, then the exporting
language could provide multiple interfaces, and the calling compiler could
query the set of methods for the one most suitable.
+{{ Proposal rejected, because we aren't going with external and internal
+subroutine variants, so it's not needed. --allison }}
+
=head2 More namespace complexity?
+{{ Proposal rejected, because we aren't going with external and internal
+subroutine variants, so it's not needed. --allison }}
+
It might be good to have some way for HLLs to define a separate external
definition for a given sub (i.e. one that provides the wrapper) that can be
done without too much namespace hair. I.e.
@@ -175,6 +201,10 @@
functions, i.e. a method defined for CVECTOR must be considered when passed
a string as a parameter.
+{{ Common Lisp (for example) will have its own set of type relationships,
+because it will have its own set of types. There will be no remapping of core
+types --allison }}
+
The language that owns the multisub gets to define the type hierarchy and
dispatch rules used when it gets called. In order to handle objects from
foreign languages, the owning language must decide where to graft the
@@ -184,10 +214,16 @@
only have to include CObject in order to incorporate objects from all other
conforming languages. -- rgr, 26-Aug-08. }}
+{{ The language that owns the multisub does get to define the dispatch rules
+for the multisub. But, it doesn't get to alter the type hierarchy of objects
+from other languages. --allison }}
+
Note that common Parrot classes will in general appear in different places in
different languages' dispatch hierarchies, so it is important to bear in mind
which language owns the dispatch.
+{{ Absolutely not true. --allison }}
+
=head1 DEFINITIONS
{{ Collect definitions of new jargon words here, once we figure out what they
@@ -220,6 +256,10 @@
the particular case of integer division, which differs significantly between
languages.
+{{ No, this is completely backwards. Languages are heartily encouraged to
+create their own PMCs for any and all common variable types found in the
+language. --allison }}
+
In Tcl, the integer three divided by the integer five produces the integer
value 0.
@@ -235,6 +275,12 @@
floating-point result from Common Lisp code that happens to
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
[EMAIL PROTECTED] wrote: Opcode names are not reserved words in PIR, and may be used as variable names. For example, you can define a local variable named Cprint. [See RT #24251] +Note that by using an opcode name as a local variable name, the variable will +Ihide the opcode name, effectively making the opcode unusable. Opcode names +used as subroutine identifiers, on the other hand, will Ihide that opcode. -PIR keywords, on the other hand, Iare reserved, and cannot be used as +In contrast to opcode names, PIR keywords Iare reserved, and cannot be used as identifiers. Some opcode names (Cif, Cunless) are, in fact, PIR keywords, which therefore cannot be used as identifiers. This is another one of those muddy cases in PIR where words conflict when they shouldn't. I can't think of any way that it's actually useful to have a variable named 'add' prevent you from using the opcode 'add'. Call it a bug, or at least a misfeature caused by limited parsing. Allison
Re: [svn:parrot-pdd] r30620 - trunk/docs/pdds/draft
Moritz Lenz wrote:
[EMAIL PROTECTED] wrote:
+{{ Is the term unimethod acceptable here? -- rgr, 29-Jul-08. }}
I think for dispatch the term is single dispatch, and unimethod
could thus be single method.
Just single dispatch. A method that's single dispatched, is... a method.
Allison
[PATCH] cygwin070patches_6.patch
Reini Urban schrieb: Moritz Lenz schrieb: Reini Urban wrote: My latest patch against the cygwin070patches branch r30596. And one more. pdd30_install.pod, silence Parrot/Configure/Compiler.pm, more testcases, parrot_config, $(SHRPENV) $(MINIPARROT) for the last missing build problem. Add cardinal arrays and Nil from trunk. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ cygwin070patches_6.patch.gz Description: GNU Zip compressed data
Re: [svn:parrot-pdd] r30568 - trunk/docs/pdds
[EMAIL PROTECTED] wrote: +PIR keywords, on the other hand, Iare reserved, and cannot be used as +identifiers. Some opcode names (Cif, Cunless) are, in fact, PIR keywords, +which therefore cannot be used as identifiers. If the PDD says the keywords are reserved, it also needs to say what the keywords are. Allison
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
Andy Dougherty schrieb:
On Thu, 28 Aug 2008, Reini Urban wrote:
Will Coleda schrieb:
On Thu, Aug 28, 2008 at 11:09 AM, Reini Urban [EMAIL PROTECTED] 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.
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.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Re: [PATCH] cygwin070patches_4.patch
Reini Urban wrote: A new idea: === #IF(darwin): #ALSO:# MACOSX_DEPLOYMENT_TARGET must be defined for OS X #ALSO:export MACOSX_DEPLOYMENT_TARGET := @osx_version@ Just a little too much complexity, for not enough benefit. The POD for this change: Looks good. For legacy the old syntax #CONDITIONED_LINE(var): and #INVERSE_CONDITIONED_LINE(var): is also supported. Mention that this syntax will be deprecated. For lispers the well-known reader-macro syntax #+(and key1 (not key2)): is also supported, #+ #- with and, or and not, or being the default for multiple keys without operator. But note the ending C:. This syntax is not supported. The primary reason for rejecting the syntax is because it's too much of a burden on maintainers. If we keep the feature someone will certainly use it, and some poor P-language programmer is going to get stuck trying to decipher it. * or a key=value expression, which checks for the config key, Note that values may contain no spaces here. Quotes in values are not supported. Seems like a sensible addition, though very limited. Make it '==' instead of '='. A key must only consist of word characters, and is checked case-sensitively against the config key or the platform name. Explicitly say what you mean by word characters, because different languages treat different characters as word forming. If you mean A-Z, a-z, and 0-9, say so. Allison
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
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. 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
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
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. ...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
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
Patrick R. Michaud wrote: 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. ..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.) 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
Re: [svn:parrot-pdd] r30620 - trunk/docs/pdds/draft
From: Allison Randal [EMAIL PROTECTED]
Date: Thu, 28 Aug 2008 22:14:08 +0200
Moritz Lenz wrote:
[EMAIL PROTECTED] wrote:
+{{ Is the term unimethod acceptable here? -- rgr, 29-Jul-08. }}
I think for dispatch the term is single dispatch, and unimethod
could thus be single method.
Just single dispatch. A method that's single dispatched, is... a method.
Allison
True. Nevertheless, the two kinds of method are treated quite
differently by Parrot, both when being defined and when being called.
That is why it is awkward not to have concise names for both kinds.
-- Bob
[perl #47503] [RFC] Remove config::init::defaults From configure tests
This dependence has been eliminated from 20 of the 76 current configuration step tests. More to come. kid51
[perl #58076] Configure tests fail with Can't store CODE items
Marking ticket resolved.
[perl #57884] [PATCH] file_type option for Parrot::Configure::Compiler-genfile
No complaints in five days. No smolder test failures. Marking ticket resolved.
[perl #44315] [TODO] Enable scripting of an entire configuration session
No objections so far. If I hear none, I will apply this patch this weekend.
