Re: [perl #58410] [TODO] Deprecate n_* variants of the math opcodes
Geoffrey Broadwell via RT wrote: 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? Compared to the cost of the multiple dispatch that all the math ops do, the cost of creating a temporary variable to hold the result is very minor. That said, the semantics of whether the destination PMC is modified or replaced by a new one is determined by the particular sub selected by multiple dispatch. It's even possible (or will be once the MMD branch is merged back in) to define a non-multi vtable function in a particular PMC, to optimize away the cost of multiple dispatch. Allison
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
On Thu, Aug 28, 2008 at 10:07 PM, Allison Randal [EMAIL PROTECTED] wrote: [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 I see what you mean, but being able to do what you would like, would be very complex to implement and IMHO not worth the effort (probably something like setting flags like and lexer code such as: 'if (strcmp(yytext, add) expect_math_op) return TK_ADD;'. No fun. Having a rule that says that any local variable declared, hides any other object by the same name in the current scope, is not too hard to understand. In any case, having a local id called 'add' would be a bad practice any way, IMHO. kjs
Re: [svn:parrot-pdd] r30620 - trunk/docs/pdds/draft
Bob Rogers wrote: Just single dispatch. A method that's single dispatched, is... a method. 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. We have vtable functions, subs, methods, and multis. A multi is neither a sub nor a method nor a vtable function, though it may substitute for any of them. Allison
[svn:parrot-pdd] r30632 - trunk/docs/pdds
Author: kjs
Date: Fri Aug 29 02:22:05 2008
New Revision: 30632
Modified:
trunk/docs/pdds/pdd19_pir.pod
Log:
[pdd19] list all PIR reserved words.
Modified: trunk/docs/pdds/pdd19_pir.pod
==
--- trunk/docs/pdds/pdd19_pir.pod (original)
+++ trunk/docs/pdds/pdd19_pir.pod Fri Aug 29 02:22:05 2008
@@ -67,8 +67,14 @@
used as subroutine identifiers, on the other hand, will Ihide that opcode.
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.
+identifiers. Some opcode names are, in fact, PIR keywords, which therefore
+cannot be used as identifiers.
+
+The following are PIR keywords, and cannot be used as identifiers:
+
+ goto if int null
+ num pmc string unless
+
{{ NOTE: The use of C:: in identifiers is deprecated. [See RT #48735] }}
[svn:parrot-pdd] r30633 - trunk/docs/pdds
Author: kjs Date: Fri Aug 29 03:13:05 2008 New Revision: 30633 Modified: trunk/docs/pdds/pdd19_pir.pod Log: [pdd19] remove a previously added line of mine which I no longer understand myself. Something about subroutine identifiers and hiding opnames. Modified: trunk/docs/pdds/pdd19_pir.pod == --- trunk/docs/pdds/pdd19_pir.pod (original) +++ trunk/docs/pdds/pdd19_pir.pod Fri Aug 29 03:13:05 2008 @@ -63,8 +63,7 @@ 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. +Ihide the opcode name, effectively making the opcode unusable. In contrast to opcode names, PIR keywords Iare reserved, and cannot be used as identifiers. Some opcode names are, in fact, PIR keywords, which therefore
[perl #46119] [TODO] Handle resume opcodes in PDB_next()
PDB_next no longer executes opcodes by himself, now is done in the debugger runloop. Closing ticket.
[PGE][BUG][PATCH] Apostrophes in optables are compiled to broken pir
While writing something like a LISP reader I found this bug. To replicate it
this is enough:
proto prefix:' is looser('term:') { ... }
The problem is that the ' in the name of the operators aren't escaped.
The patch I attached uses library/Data/Escape.pbc to escape the names. The only
modified file is
runtime/parrot/library/PGE/Perl6Grammar.pir
Index: runtime/parrot/library/PGE/Perl6Grammar.pir
===
--- runtime/parrot/library/PGE/Perl6Grammar.pir (revision 30618)
+++ runtime/parrot/library/PGE/Perl6Grammar.pir (working copy)
@@ -73,7 +73,8 @@
load_bytecode 'PGE/Text.pbc'
load_bytecode 'PGE/Util.pbc'
load_bytecode 'PCT/HLLCompiler.pbc'
-
+load_bytecode 'library/Data/Escape.pbc'
+
.local pmc p6regex
p6regex = compreg 'PGE::Perl6Regex'
@@ -339,6 +340,9 @@
$P0 = nstable[namespace]
optable = $P0['optable']
+## Escape function
+.local pmc esc
+esc = find_global Data::Escape, String
## build the list of traits
.local pmc iter
.local string traitlist
@@ -366,8 +370,10 @@
goto trait_sub
trait_arg:
if trait == 'parsed' goto trait_sub
-arg = concat ', arg
-arg = concat arg, '
+## Escape the arg
+arg = esc (arg)
+arg = concat '', arg
+arg = concat arg, ''
goto trait_arg_done
trait_sub:
optable.emit( $P0 = get_hll_global ['%0'], '%1', namespace, arg)
@@ -382,7 +388,10 @@
concat traitlist, arg
goto trait_loop
trait_end:
-optable.emit( optable.newtok('%0'%1), name, traitlist)
+## Escape the name
+$P0 = find_global Data::Escape, String
+name = $P0(name, '')
+optable.emit( optable.newtok(\%0\%1), name, traitlist)
.return ()
.end
[perl #58424] Named regex, token and rule don't work outside of a grammar
# New Ticket Created by Carl Mäsak
# Please include the string: [perl #58424]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58424
r30590:
$ ./perl6 -e 'regex a { b }; b ~~ a'
too few arguments passed (0) - 2 params expected
[...]
I've also added tests for this in t/spec/S05-metasyntax/regex.t.
(S05 is not entirely clear as to whether this should actually work.
IMHO, there's noreason for it not to. Storing anonymous regexes in
scalar variables already works.)
$ ./perl6 -e 'my $a = regex { b }; say b ~~ $a'
b
Re: [PGE][BUG][PATCH] Apostrophes in optables are compiled to broken pir
Forwarding to [EMAIL PROTECTED] to open a ticket.
After applying the patch all tests except a codingstd test (trailing
whitespace) still pass, but since I'm not familiar with PGE I wait for
somebody else (Patrick?) to apply it. Instead I attached a version of
the patch without the trailing whitespace ;-)
Marcelo Serra Castilhos wrote:
While writing something like a LISP reader I found this bug. To replicate it
this is enough:
proto prefix:' is looser('term:') { ... }
The problem is that the ' in the name of the operators aren't escaped.
The patch I attached uses library/Data/Escape.pbc to escape the names. The
only modified file is
runtime/parrot/library/PGE/Perl6Grammar.pir
A test for that would be nice.
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Index: runtime/parrot/library/PGE/Perl6Grammar.pir
===
--- runtime/parrot/library/PGE/Perl6Grammar.pir (revision 30633)
+++ runtime/parrot/library/PGE/Perl6Grammar.pir (working copy)
@@ -73,6 +73,7 @@
load_bytecode 'PGE/Text.pbc'
load_bytecode 'PGE/Util.pbc'
load_bytecode 'PCT/HLLCompiler.pbc'
+load_bytecode 'library/Data/Escape.pbc'
.local pmc p6regex
p6regex = compreg 'PGE::Perl6Regex'
@@ -339,6 +340,9 @@
$P0 = nstable[namespace]
optable = $P0['optable']
+## Escape function
+.local pmc esc
+esc = find_global Data::Escape, String
## build the list of traits
.local pmc iter
.local string traitlist
@@ -366,8 +370,10 @@
goto trait_sub
trait_arg:
if trait == 'parsed' goto trait_sub
-arg = concat ', arg
-arg = concat arg, '
+## Escape the arg
+arg = esc (arg)
+arg = concat '', arg
+arg = concat arg, ''
goto trait_arg_done
trait_sub:
optable.emit( $P0 = get_hll_global ['%0'], '%1', namespace, arg)
@@ -382,7 +388,10 @@
concat traitlist, arg
goto trait_loop
trait_end:
-optable.emit( optable.newtok('%0'%1), name, traitlist)
+## Escape the name
+$P0 = find_global Data::Escape, String
+name = $P0(name, '')
+optable.emit( optable.newtok(\%0\%1), name, traitlist)
.return ()
.end
Re: [svn:parrot-pdd] r30620 - trunk/docs/pdds/draft
From: Allison Randal [EMAIL PROTECTED] Date: Fri, 29 Aug 2008 11:19:37 +0200 Bob Rogers wrote: Just single dispatch. A method that's single dispatched, is... a method. 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. We have vtable functions, subs, methods, and multis. So you prefer the plain term method for method that is not a multimethod? That seems prone to confusion. What do you suggest for the generic term? A multi is neither a sub nor a method nor a vtable function, though it may substitute for any of them. Allison By multi do you mean multisub or multimethod? Either way, it seems there is something missing from your enumeration above. -- Bob
[perl #58438] [PATCH] nci can't pass NULL string arguments
# New Ticket Created by NotFound
# Please include the string: [perl #58438]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58438
I was doing a simple test of NCI calls with the xlib function
XDisplayName, and found that nci can't handle a NULL string argument.
Passing a NULL Parrot String segfaults.
The attached patch passes a NULL char * when a NULL Parrot String is
used. Don't know if this is the desired behaviour, I expect comments.
--
Salu2
Index: tools/build/nativecall.pl
===
--- tools/build/nativecall.pl (revision 30618)
+++ tools/build/nativecall.pl (working copy)
@@ -505,8 +505,8 @@
/t/ do {
push @{$temps_ref}, char *t_$temp_num;;
push @{$extra_preamble_ref},
-t_$temp_num = string_to_cstring(interp, GET_NCI_S($reg_num));;
-push @{$extra_postamble_ref}, string_cstring_free(t_$temp_num);;
+{STRING * s= GET_NCI_S($reg_num); t_$temp_num = s ? string_to_cstring(interp, s) : (char *) NULL;};
+push @{$extra_postamble_ref}, do { if (t_$temp_num) string_cstring_free(t_$temp_num); } while (0);;
return t_$temp_num;
};
/b/ do {
Re: [svn:parrot-pdd] r30620 - trunk/docs/pdds/draft
Bob Rogers wrote: So you prefer the plain term method for method that is not a multimethod? That seems prone to confusion. What do you suggest for the generic term? It's not prone to confusion. By definition, a method is a invoked on a single invocant (an instance of the class that contains the method). By multi do you mean multisub or multimethod? Either way, it seems there is something missing from your enumeration above. A multi (that is a MultiSub PMC) can be invoked as either a sub or a method. There is no distinction between a multisub and a multimethod. There are only multis, which are dispatched based on an evaluation of multiple invocants. Allison
Re: [perl #58424] Named regex, token and rule don't work outside of a grammar
On Thu, Aug 28, 2008 at 08:32:41AM -0700, Carl Mäsak wrote:
r30590:
$ ./perl6 -e 'regex a { b }; b ~~ a'
too few arguments passed (0) - 2 params expected
[...]
I've also added tests for this in t/spec/S05-metasyntax/regex.t.
(S05 is not entirely clear as to whether this should actually work.
IMHO, there's noreason for it not to. Storing anonymous regexes in
scalar variables already works.)
$ ./perl6 -e 'my $a = regex { b }; say b ~~ $a'
b
For now I'm going to claim that Rakudo has this one correct. The
difference between the first and second examples above is that in
the scalar variable example, the $a variable passed to infix:~~
contains the regex sub itself, whereas in the first example the
a regex is being invoked as a 0-argument listop prior to calling
the smart match.
In other words, the correct syntax is to use a, as in:
$ ./parrot perl6.pbc -e 'regex a { b }; say b ~~ a;'
b
By way of analogy:
sub foo($x) { $x eq 'b' }
say b ~~ foo; # wrong, sub foo called as 0-arg listop
say b ~~ foo;# right, sub foo passed to infix:~~
Pm
Re: [PATCH] cygwin070patches_6+7.patch
Allison Randal schrieb: 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. I hope you know that this #+() syntax is the only existing syntax. It is widely used since about 20 years. The rest is something new we came up with. I deleted it. Sigh. * 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. Ok, the cygwin070patches_7.patch includes all of these suggestions. There's still a parser problem with some obscure logic, which I have to fix. See the TODO tests. First I want cygwin070patches_6.patch to be applied, then this patch cygwin070patches_7.patch. ChangeLog for 7. For 6 see other mail: applied Allisons suggestions for key==value, doc improvements, removed lisp-style, more tests, and detected some TODO cases. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ cygwin070patches_6.patch.gz Description: GNU Zip compressed data cygwin070patches_7.patch.gz Description: GNU Zip compressed data
pdd30_install
[Subject changed to pdd30_install, as we are talking about this the 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. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #58424] Named regex, token and rule don't work outside of a grammar
Patrick (), Carl ():
r30590:
$ ./perl6 -e 'regex a { b }; b ~~ a'
too few arguments passed (0) - 2 params expected
[...]
I've also added tests for this in t/spec/S05-metasyntax/regex.t.
(S05 is not entirely clear as to whether this should actually work.
IMHO, there's noreason for it not to. Storing anonymous regexes in
scalar variables already works.)
$ ./perl6 -e 'my $a = regex { b }; say b ~~ $a'
b
For now I'm going to claim that Rakudo has this one correct. The
difference between the first and second examples above is that in
the scalar variable example, the $a variable passed to infix:~~
contains the regex sub itself, whereas in the first example the
a regex is being invoked as a 0-argument listop prior to calling
the smart match.
In other words, the correct syntax is to use a, as in:
$ ./parrot perl6.pbc -e 'regex a { b }; say b ~~ a;'
b
By way of analogy:
sub foo($x) { $x eq 'b' }
say b ~~ foo; # wrong, sub foo called as 0-arg listop
say b ~~ foo;# right, sub foo passed to infix:~~
That does make sense. Thank you.
// Carl
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: [PATCH] cygwin070patches_6+7.patch
Reini Urban wrote: I hope you know that this #+() syntax is the only existing syntax. It is widely used since about 20 years. The rest is something new we came up with. It's high time for a little progress. Sheesh, in 1988 we were excited by computers with 1 MB of RAM. ;) 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: [PATCH] cygwin070patches_6+7.patch
On Fri, Aug 29, 2008 at 11:56 AM, Allison Randal [EMAIL PROTECTED] wrote: Reini Urban wrote: I hope you know that this #+() syntax is the only existing syntax. It is widely used since about 20 years. The rest is something new we came up with. It's high time for a little progress. Sheesh, in 1988 we were excited by computers with 1 MB of RAM. ;) Allison Progress is nice, but there is no need for us to re-invent *every* wheel for this project. -- Will Coke Coleda
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
[perl #44315] [TODO] Enable scripting of an entire configuration session
On Fri Aug 29 09:11:37 2008, coke wrote: If I want to run my config based on the contents of a file, how do I get the ordered lists of steps to run? Can I assume a sane default or must I be explicit? In this first version of file-based configuration, you have to be explicit, i.e., you copy-and-paste the list of steps from lib/Parrot/Configure/Step/List.pm and edit to suit your taste. If the file/list is coming from a configure run, is there a way to cope with the order of steps changing between various versions of Configure? or will I have to manually re-apply my changes if that happens? (easier to avoid if there are sane defaults) In a subsequent version of file-based configuration (and different RT), we can explore some way of telling the user/editor of a particular config file, Hey! Since you last edited this file, the canonical list of config steps in P::C::Step::List has changed. But that would be a new requirement and involve considerable new code. My recommendation is to offer people this version for now and see how real-world use shapes our future needs. HTH Thank you very much. kid51
general rant over older days
2008/8/29 Will Coleda [EMAIL PROTECTED]: On Fri, Aug 29, 2008 at 11:56 AM, Allison Randal [EMAIL PROTECTED] wrote: Reini Urban wrote: I hope you know that this #+() syntax is the only existing syntax. It is widely used since about 20 years. The rest is something new we came up with. It's high time for a little progress. Sheesh, in 1988 we were excited by computers with 1 MB of RAM. ;) Allison Progress is nice, but there is no need for us to re-invent *every* wheel for this project. And I'm tempted to add: Actually even the 1984 version of lisps are still technically and syntax-wise far advanced over the perl and parrot state of today. I see not much of a progress. perl5 even lost undump around that time and the perl compiler was axed last year. Even then I could connect to my life and running lisp image, inspect the variables with all its state and type, and not just staring at hexdumps or intermediate VM ops, test and fix a bug, recompile a function on the fly and saving away an image while the whole image was still running. Zero downtime. Others are now profiling their dynamic compilers [1] and optimizers[2], we are still and again struggling with the basics. At least we have a tri-color generational GC (from 1975 [3]) and not Mark Sweep soon, but I'm not sure if the GC with external objects (nci) is solvable when live PMCs will be allowed to move. Just to make it faster. http://www.memorymanagement.org/news/history.html Nevertheless I do prefer the dirty state of today over the perfect state from ancient times. CPU get faster and cheaper. HDs get bigger. And MSVC supports now almost dynamic recompilation and the stabs can be dumped away. Great. Almost back in the 80-ies. Footnotes: [1] Java and .NET slowly doing now what LISP did in the 90ies. [2] http://hg.mozilla.org/tracemonkey (optimize loops dynamically, nice) [3] http://www.memorymanagement.org/bib/f.html#dlmss76 -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: general rant over older days
On Friday 29 August 2008 10:04:44 Reini Urban wrote: perl5 even lost undump around that time and the perl compiler was axed last year. Economic realities often trump idealism. I'd like to see a working Perl 5 compiler suite as well, but I don't have the time to do it, and no one seems to want to fund it. That state of affairs does not fill me with glee. -- c
Re: general rant over older days
2008/8/29 chromatic [EMAIL PROTECTED]: On Friday 29 August 2008 10:04:44 Reini Urban wrote: perl5 even lost undump around that time and the perl compiler was axed last year. Economic realities often trump idealism. I'd like to see a working Perl 5 compiler suite as well, but I don't have the time to do it, and no one seems to want to fund it. That state of affairs does not fill me with glee. Works without funds also: http://search.cpan.org/dist/B-C/ Just a few hairy bugs need to be fixed. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
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
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
On Fri, Aug 29, 2008 at 11:06 AM, Klaas-Jan Stol [EMAIL PROTECTED]wrote: On Thu, Aug 28, 2008 at 10:07 PM, Allison Randal [EMAIL PROTECTED] wrote: [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 I see what you mean, but being able to do what you would like, would be very complex to implement and IMHO not worth the effort (probably something like setting flags like and lexer code such as: 'if (strcmp(yytext, add) expect_math_op) return TK_ADD;'. No fun. Having a rule that says that any local variable declared, hides any other object by the same name in the current scope, is not too hard to understand. In any case, having a local id called 'add' would be a bad practice any way, IMHO. kjs ... but of course, I don't want to exclude it. If it is really felt that these 'muddy' cases should be resolved, it shouldn't be too hard to implement (I tried some 30 min. hacking in pirc, and results seemed promising). kjs
how much detail can I get from caller.want?
Lets say I want to find the 5th smallest element in an array. I might write: @array.sort.[4]; How does the implementation of the sort function know that I just want to 5th item (and thus choose an appropriate optimization)? Obviously the function could be told that it's caller wants 5 values in list context, but is there a way to get more info than that?
[perl #58452] Re: [PGE][BUG][PATCH] Apostrophes in optables are compiled to broken pir
Correct that this is a bug, but the patch using Data/Escape.pbc is
a bit problematic. Data/Escape.pbc is woefully out of date, and also
has problems in that it doesn't correctly generate PIR constants for
unicode strings, as would be the case with:
proto prefix:« { ... }
So, the solution is to use the 'escape' method of the CodeString PMC,
which is what other parts of PGE and PCT use when they need to
generate PIR constant literals from string values (including
unicode and binary strings). For reference I've copied the resulting
patch below.
Problem fixed in r., many thanks for the report and patch, both
of which made it very easy to see what needed to be fixed.
Pm
===
--- runtime/parrot/library/PGE/Perl6Grammar.pir (revision 30633)
+++ runtime/parrot/library/PGE/Perl6Grammar.pir (working copy)
@@ -366,8 +366,7 @@
goto trait_sub
trait_arg:
if trait == 'parsed' goto trait_sub
-arg = concat ', arg
-arg = concat arg, '
+arg = optable.'escape'(arg)
goto trait_arg_done
trait_sub:
optable.emit( $P0 = get_hll_global ['%0'], '%1',
namespace, arg)
@@ -382,7 +381,8 @@
concat traitlist, arg
goto trait_loop
trait_end:
-optable.emit( optable.newtok('%0'%1), name, traitlist)
+name = optable.'escape'(name)
+optable.emit( optable.newtok(%0%1), name, traitlist)
.return ()
.end
[perl #58452] Re: [PGE][BUG][PATCH] Apostrophes in optables are compiled to broken pir
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #58452]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58452
Forwarding to [EMAIL PROTECTED] to open a ticket.
After applying the patch all tests except a codingstd test (trailing
whitespace) still pass, but since I'm not familiar with PGE I wait for
somebody else (Patrick?) to apply it. Instead I attached a version of
the patch without the trailing whitespace ;-)
Marcelo Serra Castilhos wrote:
While writing something like a LISP reader I found this bug. To replicate it
this is enough:
proto prefix:' is looser('term:') { ... }
The problem is that the ' in the name of the operators aren't escaped.
The patch I attached uses library/Data/Escape.pbc to escape the names. The
only modified file is
runtime/parrot/library/PGE/Perl6Grammar.pir
A test for that would be nice.
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Index: runtime/parrot/library/PGE/Perl6Grammar.pir
===
--- runtime/parrot/library/PGE/Perl6Grammar.pir (revision 30633)
+++ runtime/parrot/library/PGE/Perl6Grammar.pir (working copy)
@@ -73,6 +73,7 @@
load_bytecode 'PGE/Text.pbc'
load_bytecode 'PGE/Util.pbc'
load_bytecode 'PCT/HLLCompiler.pbc'
+load_bytecode 'library/Data/Escape.pbc'
.local pmc p6regex
p6regex = compreg 'PGE::Perl6Regex'
@@ -339,6 +340,9 @@
$P0 = nstable[namespace]
optable = $P0['optable']
+## Escape function
+.local pmc esc
+esc = find_global Data::Escape, String
## build the list of traits
.local pmc iter
.local string traitlist
@@ -366,8 +370,10 @@
goto trait_sub
trait_arg:
if trait == 'parsed' goto trait_sub
-arg = concat ', arg
-arg = concat arg, '
+## Escape the arg
+arg = esc (arg)
+arg = concat '', arg
+arg = concat arg, ''
goto trait_arg_done
trait_sub:
optable.emit( $P0 = get_hll_global ['%0'], '%1', namespace, arg)
@@ -382,7 +388,10 @@
concat traitlist, arg
goto trait_loop
trait_end:
-optable.emit( optable.newtok('%0'%1), name, traitlist)
+## Escape the name
+$P0 = find_global Data::Escape, String
+name = $P0(name, '')
+optable.emit( optable.newtok(\%0\%1), name, traitlist)
.return ()
.end
Re: [perl #47503] [RFC] Remove config::init::defaults From configure tests
2008/8/29 James Keenan via RT [EMAIL PROTECTED]:
This dependence has been eliminated from 20 of the 76 current
configuration step tests. More to come.
On MinGW32 (ie gcc on Win32), there are new failure since r30361
D:\fperrad\Parrot\trunkperl t\steps\auto_msvc-01.t
1..39
ok 1 - use config::auto::msvc;
ok 2 - auto::msvc constructor returned defined value
ok 3 - The object isa auto::msvc
ok 4 - auto::msvc has description
C compiler failed (see test_1508.cco) at
lib/Parrot/Configure/Compiler.pm line 101
Parrot::Configure::Compiler::cc_build('Parrot::Configure=HASH(0x1e18ffc)')
called at config/auto/msvc.pm line 45
auto::msvc::_probe_for_msvc('Parrot::Configure=HASH(0x1e18ffc)')
called at config/auto/msvc.pm line 35
auto::msvc::runstep('auto::msvc=HASH(0x15d629c)',
'Parrot::Configure=HASH(0x1e18ffc)') called at t\steps\auto_msvc-01.t
line 39
# Looks like you planned 39 tests but only ran 4.
# Looks like your test died just after 4.
previously, all was fine :
D:\fperrad\Parrot\trunkperl t\steps\auto_msvc-01.t
1..44
ok 1 - use config::init::defaults;
ok 2 - use config::auto::msvc;
ok 3 - init::defaults constructor returned defined value
ok 4 - The object isa init::defaults
ok 5 - init::defaults has description
Set up gcc environment - 3.4.5 (mingw special)
ok 6 - init::defaults runstep() returned defined value
ok 7 - auto::msvc constructor returned defined value
ok 8 - The object isa auto::msvc
ok 9 - auto::msvc has description
ok 10 - runstep() returned true value
ok 11 - auto::msvc constructor returned defined value
ok 12 - The object isa auto::msvc
ok 13 - auto::msvc has description
ok 14 - _evaluate_msvc returned true value
ok 15 - Got expected result
ok 16 - Got expected msvc version string
ok 17 - auto::msvc constructor returned defined value
ok 18 - The object isa auto::msvc
ok 19 - auto::msvc has description
ok 20 - _evaluate_msvc returned true value
ok 21 - Got expected result
ok 22 - Got expected msvc version string
ok 23 - ccflags appropriately adjusted given MSVC version
ok 24 - auto::msvc constructor returned defined value
ok 25 - The object isa auto::msvc
ok 26 - auto::msvc has description
ok 27 - sub return value, as expected, not yet set
ok 28 - result, as expected, not yet set
ok 29 - sub return value, as expected, set to true value
ok 30 - Got expected result
ok 31 - msvcversion is undef, as expected
ok 32 - sub return value, as expected, set to true value
ok 33 - Got expected result
ok 34 - msvcversion is undef, as expected
ok 35 - sub return value, as expected, set to true value
ok 36 - Got expected result
ok 37 - msvcversion is undef, as expected
ok 38 - Got expected verbose output
ok 39 - Got expected MSVC version
ok 40 - Got expected result
ok 41 - Got expected MSVC version
ok 42 - Got expected result
ok 43 - Got expected verbose output
ok 44 - Completed all tests in t\steps\auto_msvc-01.t
kid51
[perl #47503] [RFC] Remove config::init::defaults From configure tests
On Fri Aug 29 13:58:19 2008, fperrad wrote: 2008/8/29 James Keenan via RT [EMAIL PROTECTED]: This dependence has been eliminated from 20 of the 76 current configuration step tests. More to come. On MinGW32 (ie gcc on Win32), there are new failure since r30361 Thanks for the report, François. Reverted in r30639. kid51
[svn:parrot-pdd] r30644 - trunk/docs/pdds/draft
Author: jkeenan Date: Fri Aug 29 16:21:00 2008 New Revision: 30644 Modified: trunk/docs/pdds/draft/pdd30_install.pod Log: Rebreak a couple of lines in error reporting to prevent t/codingstd/linelength.t from failing. Modified: trunk/docs/pdds/draft/pdd30_install.pod == --- trunk/docs/pdds/draft/pdd30_install.pod (original) +++ trunk/docs/pdds/draft/pdd30_install.pod Fri Aug 29 16:21:00 2008 @@ -148,11 +148,13 @@ $ parrot-pheme.exe load_bytecode couldn't find file 'compilers/tge/TGE/Rule.pbc' current instr.: 'parrot;TGE;__onload' pc 19 (TGE.pir:94) - called from Sub 'parrot;Pheme::AST::Grammar;__onload' pc 7175 (languages/pheme/lib/ASTGrammar.pir:5) + called from Sub 'parrot;Pheme::AST::Grammar;__onload' pc 7175 +(languages/pheme/lib/ASTGrammar.pir:5) called from Sub 'parrot;Pheme::Compiler;main' pc -1 ((unknown file):-1) $ parrot-pipp - Parrot VM: Can't stat /usr/src/perl/parrot/parrot-0.7.0-1/build/languages/pipp/src/common/pipplib.pbc, code 2. + Parrot VM: Can't stat + /usr/src/perl/parrot/parrot-0.7.0-1/build/languages/pipp/src/common/pipplib.pbc, code 2. Unable to append PBC to the current directory current instr.: 'parrot;Pipp;__onload' pc 47 (src/common/pipp.pir:92) called from Sub 'parrot;Pipp;pipp' pc -1 ((unknown file):-1)
general rant over older days
From: Reini Urban [EMAIL PROTECTED] Date: Fri, 29 Aug 2008 19:04:44 +0200 Reini Urban wrote: I hope you know that this #+() syntax is the only existing syntax. It is widely used since about 20 years. The rest is something new we came up with. As the token Lisper on the team, I'm afraid I have to agree with Allison: For this project, lispy syntax is a maintenance cost, with no upside. (I had been trying hard to stay out of this thread. Really I had. Oh, well.) 2008/8/29 Will Coleda [EMAIL PROTECTED]: Progress is nice, but there is no need for us to re-invent *every* wheel for this project. And I'm tempted to add: Actually even the 1984 version of lisps are still technically and syntax-wise far advanced over the perl and parrot state of today. I see not much of a progress . . . You are too impatient; Parrot is not finished. Progress is slow precisely because Parrot is ambitious. Even then I could connect to my life and running lisp image, inspect the variables with all its state and type . . . I hear you. For my money, Kea Common Lisp will have made it when I can use Slime [1] to develop on it. And, with any luck, the Parrot debugging infrastructure it uses will be easy to adapt to other languages, at which point all the cool stuff to which Lisp developers are accustomed will be easy to share with other languages. And then Parrot has a good shot at becoming known as the cool language synergy platform, at which point progress takes off like a rocket. (Or so I fervently hope.) -- Bob Rogers http://rgrjr.dyndns.org/ [1] http://common-lisp.net/project/slime/
Re: [svn:parrot-pdd] r30620 - trunk/docs/pdds/draft
From: Allison Randal [EMAIL PROTECTED] Date: Fri, 29 Aug 2008 16:03:24 +0200 Bob Rogers wrote: By multi do you mean multisub or multimethod? Either way, it seems there is something missing from your enumeration above. A multi (that is a MultiSub PMC) can be invoked as either a sub or a method. There is no distinction between a multisub and a multimethod. There are only multis, which are dispatched based on an evaluation of multiple invocants. Allison My sense of the usage on this list is that multisub means a MultiSub PMC and a multimethod is what you add to the MultiSub when you define a sub with the :multi keyword. Am I the only one who finds this a useful distinction? -- Bob
