Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
Patrick R. Michaud wrote: What's the language-agnostic term for this, then? Well, 'gather' is basically a clever use of a coroutine, and 'take' is basically a 'yield'. But, what's unique about the construct is that it aggregates the results. So, 'gather' is an aggregating coroutine and 'take' is an aggregating yield. To allow for a distinction in the control exception types, call it 'CONTROL_YIELD_AGGREGATE'. Aggregating coroutine and aggregating yield aren't nearly as zippy as 'gather' and 'take', but they're more meaningful to a broader audience, which may help the feature spread. Allison
[perl #58982] Bug -- make per6 unexpected dot
# New Ticket Created by Kamil Kułaga
# Please include the string: [perl #58982]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58982
$ make perl6
make -C compilers/pct
make[1]: Wejście do katalogu `/usr/local/src/parrot/compilers/pct'
make[1]: Nie ma nic do zrobienia w `all'.
make[1]: Opuszczenie katalogu `/usr/local/src/parrot/compilers/pct'
make -C compilers/pge
make[1]: Wejście do katalogu `/usr/local/src/parrot/compilers/pge'
make[1]: Nie ma nic do zrobienia w `all'.
make[1]: Opuszczenie katalogu `/usr/local/src/parrot/compilers/pge'
make -C compilers/tge
make[1]: Wejście do katalogu `/usr/local/src/parrot/compilers/tge'
make[1]: Nie ma nic do zrobienia w `all'.
make[1]: Opuszczenie katalogu `/usr/local/src/parrot/compilers/tge'
make -C compilers/nqp
make[1]: Wejście do katalogu `/usr/local/src/parrot/compilers/nqp'
make[1]: Nie ma nic do zrobienia w `all'.
make[1]: Opuszczenie katalogu `/usr/local/src/parrot/compilers/nqp'
make -C compilers/json
make[1]: Wejście do katalogu `/usr/local/src/parrot/compilers/json'
make[1]: Nie ma nic do zrobienia w `all'.
make[1]: Opuszczenie katalogu `/usr/local/src/parrot/compilers/json'
make -C languages/perl6 perl6
make[1]: Wejście do katalogu `/usr/local/src/parrot/languages/perl6'
../../parrot -o perl6.pbc perl6.pir
error:imcc:syntax error, unexpected DOT ('.')
in file 'src/gen_builtins.pir' line 7787
included from 'perl6.pir' line 1
make[1]: *** [perl6.pbc] Błąd 1
make[1]: Opuszczenie katalogu `/usr/local/src/parrot/languages/perl6'
make: *** [perl6] Błąd 2
--
Pozdrawiam
[perl #41291] [RFC] Can't use null PMC with :multi sub
On Thu Jan 18 14:14:30 2007, mdiep wrote: On Thu Jan 18 13:52:33 2007, leo wrote: While that was never actually specced, I do consider a NULL PMC as something like a null pointer in C. Any access (except testing for NULL-ness) to it is an error. Above example tests, that some usage of a NULL PMC fails. It's of course debatable, which usage of NULL should be allowed, e.g. above one. An explicit test in PMC-type conversion for PMCNULL in the MMD code is very likely all to make above code running (mmd.c:167,168). I based the bug report on the behavior of normal subs: .sub main :main null $P0 foo($P0) # this *does* print foo\n .end .sub foo say foo .end I don't know that I particularly need to be able to pass null PMCs to a MultiSub, but I at least demand a better error message. :-) I think either way will be trivial to write, but it probably needs some input from the architect. -- Matt Diephouse The above code prints Any in the mmd branch. Unless that's an unwanted behavior, it looks like this ticket can be resolved once the mmd branch is merged.
[perl #54110] [BUG] segfault in infix/n_infix with string arguments
On Tue Sep 09 15:06:38 2008, [EMAIL PROTECTED] wrote: Patrick R. Michaud wrote: Just for clarification: IIUC, the n_* opcodes and their semantics aren't really going away -- they're simply being renamed to not have the leading n_ prefix. It's the existing add, sub, mul, div, etc. opcodes that are being eliminated. Yes. That is, calling 'add', 'sub', etc. will now create a new PMC for the result on all the builtin PMCs. But, HLL/application developers will have the option of writing their own PMCs that reuse the destination PMC instead of a creating a new one. [...] This would seem to indicate that the string variants of the various math opcodes are also going away (and that's okay with me). So, if we can just get an official ruling that the add_p_p_s, sub_p_p_s, etc. opcodes are going away, then we can close this ticket as moot. Yes, these string variants only existed because of the unintelligent way the infix/n_infix opcodes blindly redispatched. In the branch, where the math opcodes are real opcodes, there are no string variants and we're not adding them. So, ticket can be reclassified as irrelevant. Allison In that case it's rejected.
Re: throw oddities in pdd23
Not long ago, Stephen Weeks proclaimed... Not long ago, Patrick R. Michaud proclaimed... Personally I like the idea that any PMC can be thrown as an exception, which would seem to argue against forcing resume continuations into the thrown PMC (which might not have a slot for them). So, rather than saying that anything thrown as an exception contains its resume continuation, perhaps we should say that all handlers are invoked with the exception and resume continuation as arguments, and the single-argument throw simply takes a continuation at the next instruction to pass to the handler(s). Pm This proposal has been implemented in the exceptionmagic branch. Looks like all tests are passing there without problem, although I'm not certain about a couple of the languages. Can I get some confirmation from someone else on the desirability of this proposal? This has now been committed to trunk. I'm pretty sure that I updated every exception handler in the tree.
[perl #58866] calling a PIR sub with 206 params segfaults parrot
On Wed Sep 17 08:31:26 2008, particle wrote: On Tue, Sep 16, 2008 at 11:45 PM, Christoph Otto via RT [EMAIL PROTECTED] wrote: On Tue Sep 16 15:00:24 2008, [EMAIL PROTECTED] wrote: On Tuesday 16 September 2008 14:47:58 NotFound wrote: It certainly shouldn't segfault. But, the question is: why does it segfault at 206 parameters? Throwing an exception to avoid an error we don't understand isn't good for the long-term health of the VM. The problem is located inside compilers/imcc/pcc.c:pcc_get_args function. It has the comment /* XXX check avail len */ just at the point where the segfault happens. char buf[1024] is the variable overrunned. That sounds like a bog-standard static variable overflow, where each parameter requires five bytes of storage. If that's a good rule of thumb, we could malloc/free that buffer instead, and then beat anyone who uses more than a dozen parameters. -- c Looking at the code, it's 5n+1. r31200 changes the static buffer to a dynamic one of the correct size. The original PIR code now runs without segfaulting, as does a version with 20,000 int params. make test also passes, so nothing new appears to be broken. With the assumption that the said beatings will be a manual process, I'm marking this resolved. you didn't mention it, but i sincerely hope you committed a test with 20,000 params that proves this and makes sure we don't regress in a future revision. parrot needs much more stress testing like this, and it would be a shame to miss this opportunity. ~jerry I didn't think of it until after I went to bed, but I added one with 1000 params in r31208 the next morning. The 20,000 param version took more than a second to run and I didn't see any reason to slow the tests down more than necessary.
Re: throw oddities in pdd23
Stephen Weeks wrote: This has now been committed to trunk. I'm pretty sure that I updated every exception handler in the tree. Apologies if my comments on this thread and update to the exceptions PDD weren't clear. The resume continuation should continue to live within the exception object, not be passed as a separate argument to the handler. The change to remove the exception message string as a separate parameter to the handler is correct, thanks for making that. -- (The current text of PDD23 is accurate:) Active exception handlers (if any) will be invoked with IEXCEPTION as the only parameter, and the return continuation stored within that exception object. -- Please revert the branch merge or make another update. Thanks! Allison
[svn:parrot-pdd] r31218 - in trunk: compilers/bcg/t compilers/pct/src/PAST compilers/pct/src/PCT docs/pdds languages/APL/src/parser languages/WMLScript languages/WMLScript/src languages/dotnet/build l
Author: tene
Date: Wed Sep 17 20:34:19 2008
New Revision: 31218
Modified:
trunk/docs/pdds/pdd19_pir.pod
trunk/docs/pdds/pdd23_exceptions.pod
Changes in other areas also in this revision:
Modified:
trunk/compilers/bcg/t/BCG.t
trunk/compilers/pct/src/PAST/Compiler.pir
trunk/compilers/pct/src/PCT/HLLCompiler.pir
trunk/languages/APL/src/parser/actions.pm
trunk/languages/WMLScript/src/wmlsstdlibs.pir
trunk/languages/WMLScript/wmls2pbc.pir
trunk/languages/WMLScript/wmls2pir.pir
trunk/languages/WMLScript/wmlsd.pir
trunk/languages/WMLScript/wmlsi.pir
trunk/languages/dotnet/build/translator.pl
trunk/languages/dotnet/src/translator.pir
trunk/languages/ecmascript/src/parser/actions.pm
trunk/languages/forth/forth.pir
trunk/languages/forth/test.pir
trunk/languages/lua/luac2pir.pir
trunk/languages/lua/luad.pir
trunk/languages/lua/src/lib/bc.pir
trunk/languages/lua/src/lib/glut.pir
trunk/languages/lua/src/lib/lfs.pir
trunk/languages/lua/src/lib/luaaux.pir
trunk/languages/lua/src/lib/luabasic.pir
trunk/languages/lua/src/lib/luacoroutine.pir
trunk/languages/lua/src/lib/luadebug.pir
trunk/languages/lua/src/lib/luaos.pir
trunk/languages/perl6/src/builtins/control.pir
trunk/languages/perl6/src/parser/actions.pm
trunk/languages/pheme/pheme.pir
trunk/languages/squaak/src/parser/actions.pm
trunk/languages/tcl/runtime/builtin/dict.pir
trunk/languages/tcl/runtime/builtin/info.pir
trunk/languages/tcl/runtime/builtin/inline.pir
trunk/languages/tcl/runtime/conversions.pir
trunk/languages/tcl/src/macros.pir
trunk/languages/tcl/t/internals/select_option.t
trunk/languages/tcl/t/internals/select_switches.t
trunk/src/exceptions.c
trunk/src/ops/core.ops
trunk/src/pmc/exception.pmc
trunk/t/compilers/pge/p5regex/p5rx.t
trunk/t/compilers/pge/perl6regex/01-regex.t
trunk/t/library/pg.t
trunk/t/op/calling.t
trunk/t/op/exceptions.t
trunk/t/op/sprintf.t
trunk/t/pmc/bigint.t
trunk/t/pmc/complex.t
trunk/t/pmc/coroutine.t
trunk/t/pmc/exception.t
trunk/t/pmc/float.t
trunk/t/pmc/namespace.t
trunk/t/pmc/resizablestringarray.t
Log:
Merge exceptionmagic branch into trunk.
Modified: trunk/docs/pdds/pdd19_pir.pod
==
--- trunk/docs/pdds/pdd19_pir.pod (original)
+++ trunk/docs/pdds/pdd19_pir.pod Wed Sep 17 20:34:19 2008
@@ -617,18 +617,15 @@
Using the Cpush_eh op you can install an exception handler. If an exception
is thrown, Parrot will execute the installed exception handler. In order to
retrieve the thrown exception, use the C.get_results directive. This
-directive always takes 2 arguments: an exception object and a message string.
-
-{{ NOTE: Wouldn't it be more useful to make this flexible, or at least only
-the exception object? The message can be retrieved from the exception object.
-See RT #57436 }}
+directive always takes 2 arguments: an exception object and a return
+continuation.
push_eh handler
...
handler:
.local pmc exception
- .local string message
- .get_results (exception, message)
+ .local pmc continuation
+ .get_results (exception, continuation)
...
This is syntactic sugar for the Cget_results op, but any flags set on the
@@ -636,6 +633,15 @@
The C.get_results directive must be the first instruction of the exception
handler; only declarations (.lex, .local) may come first.
+To resume execution after handling the exception, just invoke the continuation
+parameter.
+
+ ...
+ .get_results(exception,continuation
+ ...
+ continuation()
+ ...
+
=head2 Syntactic Sugar
Any PASM opcode is a valid PIR instruction. In addition, PIR defines some
Modified: trunk/docs/pdds/pdd23_exceptions.pod
==
--- trunk/docs/pdds/pdd23_exceptions.pod(original)
+++ trunk/docs/pdds/pdd23_exceptions.podWed Sep 17 20:34:19 2008
@@ -66,18 +66,17 @@
=item Bthrow IEXCEPTION [ , ICONTINUATION ]
-Throw an exception consisting of the given IEXCEPTION PMC, after taking a
-continuation at the next opcode. When a ICONTINUATION is passed in, it will
-use that instead of generating a new continuation. Active exception handlers
-(if any) will be invoked with IEXCEPTION as the only parameter, and the
-return continuation stored within that exception object.
+Throw the given IEXCEPTION PMC to the active exception handlers.
+If a ICONTINUATION is not passed in, throw will take a new one at
+the next opcode. Active exception handlers (if any) will be
+invoked with IEXCEPTION and the given continuation as parameters.
PMCs other than Parrot's Exception PMC may also be thrown, but they must
support the interface of an Exception PMC. An HLL may implement throwing any
arbitrary type of PMC, by storing that PMC as the payload of an Exception PMC.
Exception handlers can resume execution
[perl #58988] [RFC] Parrot_get_runtime_prefix function
# New Ticket Created by NotFound # Please include the string: [perl #58988] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58988 The Parrot_get_runtime_prefix in src/library.c return a char *, forcing the places that currently uses it to be more complicated than desired for no real gain. I added and used a STRING * variant named Parrot_get_runtime_path (that name makes more sense to me) in r31216 The question is: must we retain the old variant, kill it, deprecate it, use his name for the new version, or revert the change and stay with the char * way? -- Salu2
Re: Parrot 0.7.1 Manu Aloha released
2008/9/17 Patrick R. Michaud [EMAIL PROTECTED]:
On Wed, Sep 17, 2008 at 08:08:47PM +0200, Reini Urban wrote:
http://www.parrotcode.org/release/devel still points to 0.7.0
I sent the appropriate patch to the webmaster, but it hasn't
been applied yet (and I lack a commit bit for the parrotcode.org site).
Once that's applied, the url should be fixed.
FYI:
I thought the best generic method to get the latest release URI should be
SRC_URI=$(lwp-request -m HEAD -x -e
http://www.parrotcode.org/release/devel; 21 | \
grep /authors/id | tail -n1 | perl -ane 'print $F[2]')
The authors id changes in the uri below with every release:
http://search.cpan.org/CPAN/authors/id/P/M/PMIC/parrot-${PV}.tar.gz
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
[svn:parrot-pdd] r31223 - in trunk: compilers/bcg/t compilers/pct/src/PAST compilers/pct/src/PCT docs docs/pdds languages/APL/src/parser languages/WMLScript languages/WMLScript/src languages/dotnet/bu
Author: tene
Date: Thu Sep 18 01:47:46 2008
New Revision: 31223
Modified:
trunk/docs/pdds/pdd19_pir.pod
trunk/docs/pdds/pdd23_exceptions.pod
Changes in other areas also in this revision:
Modified:
trunk/compilers/bcg/t/BCG.t
trunk/compilers/pct/src/PAST/Compiler.pir
trunk/compilers/pct/src/PCT/HLLCompiler.pir
trunk/docs/compiler_faq.pod
trunk/languages/APL/src/parser/actions.pm
trunk/languages/WMLScript/src/wmlsstdlibs.pir
trunk/languages/WMLScript/wmls2pbc.pir
trunk/languages/WMLScript/wmls2pir.pir
trunk/languages/WMLScript/wmlsd.pir
trunk/languages/WMLScript/wmlsi.pir
trunk/languages/dotnet/build/translator.pl
trunk/languages/dotnet/src/translator.pir
trunk/languages/ecmascript/src/parser/actions.pm
trunk/languages/forth/forth.pir
trunk/languages/forth/test.pir
trunk/languages/lua/luac2pir.pir
trunk/languages/lua/luad.pir
trunk/languages/lua/src/lib/bc.pir
trunk/languages/lua/src/lib/glut.pir
trunk/languages/lua/src/lib/lfs.pir
trunk/languages/lua/src/lib/luaaux.pir
trunk/languages/lua/src/lib/luabasic.pir
trunk/languages/lua/src/lib/luacoroutine.pir
trunk/languages/lua/src/lib/luadebug.pir
trunk/languages/lua/src/lib/luaos.pir
trunk/languages/perl6/src/builtins/control.pir
trunk/languages/perl6/src/parser/actions.pm
trunk/languages/pheme/pheme.pir
trunk/languages/squaak/src/parser/actions.pm
trunk/languages/tcl/runtime/builtin/dict.pir
trunk/languages/tcl/runtime/builtin/info.pir
trunk/languages/tcl/runtime/builtin/inline.pir
trunk/languages/tcl/runtime/conversions.pir
trunk/languages/tcl/src/macros.pir
trunk/languages/tcl/t/internals/select_option.t
trunk/languages/tcl/t/internals/select_switches.t
trunk/src/exceptions.c
trunk/src/ops/core.ops
trunk/src/pmc/exception.pmc
trunk/t/compilers/pge/p5regex/p5rx.t
trunk/t/compilers/pge/perl6regex/01-regex.t
trunk/t/library/pg.t
trunk/t/op/calling.t
trunk/t/op/exceptions.t
trunk/t/op/sprintf.t
trunk/t/pmc/bigint.t
trunk/t/pmc/complex.t
trunk/t/pmc/coroutine.t
trunk/t/pmc/exception.t
trunk/t/pmc/float.t
trunk/t/pmc/namespace.t
trunk/t/pmc/resizablestringarray.t
Log:
Revert my previous exceptions commit. It was wrong.
Modified: trunk/docs/pdds/pdd19_pir.pod
==
--- trunk/docs/pdds/pdd19_pir.pod (original)
+++ trunk/docs/pdds/pdd19_pir.pod Thu Sep 18 01:47:46 2008
@@ -617,15 +617,18 @@
Using the Cpush_eh op you can install an exception handler. If an exception
is thrown, Parrot will execute the installed exception handler. In order to
retrieve the thrown exception, use the C.get_results directive. This
-directive always takes 2 arguments: an exception object and a return
-continuation.
+directive always takes 2 arguments: an exception object and a message string.
+
+{{ NOTE: Wouldn't it be more useful to make this flexible, or at least only
+the exception object? The message can be retrieved from the exception object.
+See RT #57436 }}
push_eh handler
...
handler:
.local pmc exception
- .local pmc continuation
- .get_results (exception, continuation)
+ .local string message
+ .get_results (exception, message)
...
This is syntactic sugar for the Cget_results op, but any flags set on the
@@ -633,15 +636,6 @@
The C.get_results directive must be the first instruction of the exception
handler; only declarations (.lex, .local) may come first.
-To resume execution after handling the exception, just invoke the continuation
-parameter.
-
- ...
- .get_results(exception,continuation
- ...
- continuation()
- ...
-
=head2 Syntactic Sugar
Any PASM opcode is a valid PIR instruction. In addition, PIR defines some
Modified: trunk/docs/pdds/pdd23_exceptions.pod
==
--- trunk/docs/pdds/pdd23_exceptions.pod(original)
+++ trunk/docs/pdds/pdd23_exceptions.podThu Sep 18 01:47:46 2008
@@ -66,17 +66,18 @@
=item Bthrow IEXCEPTION [ , ICONTINUATION ]
-Throw the given IEXCEPTION PMC to the active exception handlers.
-If a ICONTINUATION is not passed in, throw will take a new one at
-the next opcode. Active exception handlers (if any) will be
-invoked with IEXCEPTION and the given continuation as parameters.
+Throw an exception consisting of the given IEXCEPTION PMC, after taking a
+continuation at the next opcode. When a ICONTINUATION is passed in, it will
+use that instead of generating a new continuation. Active exception handlers
+(if any) will be invoked with IEXCEPTION as the only parameter, and the
+return continuation stored within that exception object.
PMCs other than Parrot's Exception PMC may also be thrown, but they must
support the interface of an Exception PMC. An HLL may implement throwing any
arbitrary type of PMC, by storing that PMC as the payload of an Exception PMC.
New Parrot mailing list
The new Parrot mailing list (replacing perl6-internals/parrot-porters) is [EMAIL PROTECTED]. If you were subscribed to the old list, you're now subscribed to the new list. If you were a digest subscriber to the old list, you're now a digest subscriber to the new list. More information about the list and public archives are available at: http://lists.parrot.org/mailman/listinfo/parrot-dev A Google group for the list has been created at: http://groups.google.com/group/parrot-dev We'll likely end up with messages scattered between both lists for a little while, but the perl6-internals/parrot-porters addresses are deprecated and will be disabled after a sensible deprecation cycle (and after the automatic RT posts have been shifted to parrot-dev). The new mailing list will not automatically update tickets in the RT queue, for that CC [EMAIL PROTECTED] on the message. Allison
[perl #45909] [TODO] Replace quadratic search with something linear in find_exception_handler()
On Mon Oct 01 10:40:33 2007, pcoch wrote: In src/exceptions.c there is the todo comment: [TODO: replace quadratic search with something linear, hopefully without trashing abstraction layers I can't find this comment any more, nor any occurrence of this ticket's number. I'll do some digging later to see where the comment went, but it's likely that this ticket can be resolved or rejected. Christoph
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Thu, Sep 18, 2008 at 09:23:50AM +0200, Allison Randal wrote: What's the language-agnostic term for this, then? Well, 'gather' is basically a clever use of a coroutine, and 'take' is basically a 'yield'. But, what's unique about the construct is that it aggregates the results. So, 'gather' is an aggregating coroutine and 'take' is an aggregating yield. It's also a little unique that the take/yield can happen from called subs deep within the coroutine, and doesn't have to occur within the coroutine itself. To allow for a distinction in the control exception types, call it 'CONTROL_YIELD_AGGREGATE'. Aggregating coroutine and aggregating yield aren't nearly as zippy as 'gather' and 'take', but they're more meaningful to a broader audience, which may help the feature spread. I'm rather hoping and expecting that gather and take become the meaningful names for this feature, much like grep started out as a Unix shell command but is now the language-agnostic term for extract things from a list matching a pattern. Pm
[perl #59006] stringifying Floats into PIR literals loses (a lot of) precision
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #59006] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=59006 When generating PIR output (e.g., from the compiler tools), we often need to convert a Float value into an equivalent representation for PIR. Unfortunately, all of the mechanisms I've looked at for doing this lose a lot of precision, which really isn't acceptable. The prime candidate for this seems to be the Cget_repr opcode, which AFAICT is intended for this purpose. However, it appears to provide only about 7 digits of precision. The approaches I've tried thus far are simple stringification, the get_repr opcode, and variations on sprintf formats. Here's an example showing the difficulty: $ cat x.pir .sub 'main' $N0 = exp 1.0 'as_pir'($N0) .end .sub 'as_pir' .param pmc value print set_p_s : $S0 = value say $S0 print get_repr : $S0 = get_repr value say $S0 print printf %g: $P0 = new 'ResizablePMCArray' push $P0, value $S0 = sprintf '%g', $P0 say $S0 .end $ ./parrot x.pir set_p_s : 2.71828 get_repr : 2.718282 printf %g: 2.71828 By way of comparison, Perl 5 gives a far more reasonable result: $ perl -e 'print exp(1),\n' 2.71828182845905 One approach might be to take whatever algorithm Perl 5 uses for stringifying its floats (or something close to it), and adopt that for get_repr and/or Float stringification. The current situation blocks PCT's (and thus HLLs such as Rakudo) ability to generate reasonably accurate PIR involving floating point constants. Phrased another way: to get reasonable floating point semantics HLLs are currently having to restrict themselves to supporting floating point literal syntaxes that directly or easily translate to PIR output and don't rely on actually computing the float value. Pm
Re: throw oddities in pdd23
Not long ago, Allison Randal proclaimed... Stephen Weeks wrote: This has now been committed to trunk. I'm pretty sure that I updated every exception handler in the tree. Apologies if my comments on this thread and update to the exceptions PDD weren't clear. The resume continuation should continue to live within the exception object, not be passed as a separate argument to the handler. The change to remove the exception message string as a separate parameter to the handler is correct, thanks for making that. -- (The current text of PDD23 is accurate:) Active exception handlers (if any) will be invoked with IEXCEPTION as the only parameter, and the return continuation stored within that exception object. -- Please revert the branch merge or make another update. This has been reverted. I'll fix it and commit again sometime soon.
Re: [perl #59006] stringifying Floats into PIR literals loses (a lot of) precision
On Thu, Sep 18, 2008 at 9:13 AM, Patrick R. Michaud (via RT) [EMAIL PROTECTED] wrote: # New Ticket Created by Patrick R. Michaud # Please include the string: [perl #59006] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=59006 When generating PIR output (e.g., from the compiler tools), we often need to convert a Float value into an equivalent representation for PIR. SNIP This sounds very much like partcl's need to support [set tcl_precision 0] -- Will Coke Coleda
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Thu, 2008-09-18 at 07:34 -0500, Patrick R. Michaud wrote: Aggregating coroutine and aggregating yield aren't nearly as zippy as 'gather' and 'take', but they're more meaningful to a broader audience, which may help the feature spread. I don't buy this. The Perl 6 terms are well chosen, and as soon as you know what they mean in the context of programming, you won't forget. The other versions ... well, let's leave it at easy to forget. (OK, one more thing -- the word coroutine scares people. Gather does not.) I'm rather hoping and expecting that gather and take become the meaningful names for this feature, much like grep started out as a Unix shell command but is now the language-agnostic term for extract things from a list matching a pattern. Now *this* I agree with. The first system to make a feature standard gets first try at standardizing the name. If they've chosen the name well, there's a decent chance it will stick. -'f
Re: [perl #58866] calling a PIR sub with 206 params segfaults parrot
I changed the fix in r31230 to allocate char instead of char *, adjusted the formula for buffer size and added a comment explaining it to lower the level of black magic, and added a check for each item, dropping the XXX comment that asked for it. I hope this is enough understanding of the error ;) -- Salu2
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Thu, Sep 18, 2008 at 8:37 AM, Geoffrey Broadwell [EMAIL PROTECTED] wrote: On Thu, 2008-09-18 at 07:34 -0500, Patrick R. Michaud wrote: Aggregating coroutine and aggregating yield aren't nearly as zippy as 'gather' and 'take', but they're more meaningful to a broader audience, which may help the feature spread. I don't buy this. The Perl 6 terms are well chosen, and as soon as you know what they mean in the context of programming, you won't forget. The other versions ... well, let's leave it at easy to forget. (OK, one more thing -- the word coroutine scares people. Gather does not.) I'm rather hoping and expecting that gather and take become the meaningful names for this feature, much like grep started out as a Unix shell command but is now the language-agnostic term for extract things from a list matching a pattern. Now *this* I agree with. The first system to make a feature standard gets first try at standardizing the name. If they've chosen the name well, there's a decent chance it will stick. what's the difference between gather and aggregating coroutine? lipstick. but seriously, folks, what some refer to as traits, perl 6 calls roles. what some refer to as associative arrays, perl calls hashes. but aren't hashes that funny key on your phone you type after you've entered your credit card info? oh, right, that's pound. huh? i thought that's an outdated form of currency. let's call it octothorpe. wait, what? you store your dispatch table in an octothorpe? we need to be precise in naming constructs, rather than using common names. scientists call a chanterelle mushroom by its proper name, Cantharellus cibarius. we should call gather and take by their proper names where they're defined. aggregating coroutine is more precise and descriptive than is gather, however gather is much easier to say in polite company, and is therefore a better name to use at the language level. a related point: wherever these constructs are defined, they need to be documented. you may think CONTROL_RETURN is obviously for return statements, but many will find it quite strange that return is an Exception at all. ~jerry
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Thu, Sep 18, 2008 at 09:06:44AM -0700, jerry gay wrote: On Thu, Sep 18, 2008 at 8:37 AM, Geoffrey Broadwell [EMAIL PROTECTED] wrote: On Thu, 2008-09-18 at 07:34 -0500, Patrick R. Michaud wrote: Aggregating coroutine and aggregating yield aren't nearly as zippy as 'gather' and 'take', but they're more meaningful to a broader audience, which may help the feature spread. I don't buy this. The Perl 6 terms are well chosen, and as soon as you know what they mean in the context of programming, you won't forget. The other versions ... well, let's leave it at easy to forget. (OK, one more thing -- the word coroutine scares people. Gather does not.) I'm rather hoping and expecting that gather and take become the meaningful names for this feature, much like grep started out as a Unix shell command but is now the language-agnostic term for extract things from a list matching a pattern. Now *this* I agree with. The first system to make a feature standard gets first try at standardizing the name. If they've chosen the name well, there's a decent chance it will stick. what some refer to as traits, perl 6 calls roles. what some refer to as associative arrays, perl calls hashes. [...] we need to be precise in naming constructs, rather than using common names. scientists call a chanterelle mushroom by its proper name, Cantharellus cibarius. Other languages have adopted the Perl shortname of hash as well, including Ruby and this odd little creature known as Parrot. Perhaps we should rename Parrot's Hash class to AssociativePMCArray? 1/2 ;-) we should call gather and take by their proper names where they're defined. aggregating coroutine is more precise and descriptive than is gather, however gather is much easier to say in polite company, and is therefore a better name to use at the language level. By this reasoning, we should also change the other exceptions: .CONTROL_RETURN = .CONTROL_SUB_RETURN (or .CONTROL_SUB_EXIT) .CONTROL_BREAK= .CONTROL_LOOP_EXIT .CONTROL_CONTINUE = .CONTROL_LOOP_NEXT and perhaps add .CONTROL_LOOP_REPEAT there as well. Note that I'm not at all opposed to this -- if we're going to do it for one, we really ought to do it for all. a related point: wherever these constructs are defined, they need to be documented. you may think CONTROL_RETURN is obviously for return statements, but many will find it quite strange that return is an Exception at all. Agreed that we should document them all somewhere. I vote that we do it in the Exceptions PDD. :-P Pm
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Thu, Sep 18, 2008 at 10:21 AM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Thu, Sep 18, 2008 at 09:06:44AM -0700, jerry gay wrote: On Thu, Sep 18, 2008 at 8:37 AM, Geoffrey Broadwell [EMAIL PROTECTED] wrote: On Thu, 2008-09-18 at 07:34 -0500, Patrick R. Michaud wrote: Aggregating coroutine and aggregating yield aren't nearly as zippy as 'gather' and 'take', but they're more meaningful to a broader audience, which may help the feature spread. I don't buy this. The Perl 6 terms are well chosen, and as soon as you know what they mean in the context of programming, you won't forget. The other versions ... well, let's leave it at easy to forget. (OK, one more thing -- the word coroutine scares people. Gather does not.) I'm rather hoping and expecting that gather and take become the meaningful names for this feature, much like grep started out as a Unix shell command but is now the language-agnostic term for extract things from a list matching a pattern. Now *this* I agree with. The first system to make a feature standard gets first try at standardizing the name. If they've chosen the name well, there's a decent chance it will stick. what some refer to as traits, perl 6 calls roles. what some refer to as associative arrays, perl calls hashes. [...] we need to be precise in naming constructs, rather than using common names. scientists call a chanterelle mushroom by its proper name, Cantharellus cibarius. Other languages have adopted the Perl shortname of hash as well, including Ruby and this odd little creature known as Parrot. Perhaps we should rename Parrot's Hash class to AssociativePMCArray? 1/2 ;-) we should call gather and take by their proper names where they're defined. aggregating coroutine is more precise and descriptive than is gather, however gather is much easier to say in polite company, and is therefore a better name to use at the language level. By this reasoning, we should also change the other exceptions: .CONTROL_RETURN = .CONTROL_SUB_RETURN (or .CONTROL_SUB_EXIT) .CONTROL_BREAK= .CONTROL_LOOP_EXIT .CONTROL_CONTINUE = .CONTROL_LOOP_NEXT and perhaps add .CONTROL_LOOP_REPEAT there as well. Note that I'm not at all opposed to this -- if we're going to do it for one, we really ought to do it for all. agreed. precision is of little benefit unless it's consistent across related functionality. ~jerry
Re: New Parrot mailing list
On Thu, Sep 18, 2008 at 11:00:31AM +0200, Allison Randal wrote: We'll likely end up with messages scattered between both lists for a little while, but the perl6-internals/parrot-porters addresses are deprecated and will be disabled after a sensible deprecation cycle (and after the automatic RT posts have been shifted to parrot-dev). Will we also be able to get svn commits to the new mailing list, or at least to *a* mailing list? The new mailing list will not automatically update tickets in the RT queue, for that CC [EMAIL PROTECTED] on the message. Wouldn't it be possible to have the new mailing list manager check for [perl #n] in the message subject and automatically forward it (controlling for loops as appropriate)? Or, if the MLM can't do it, then perhaps subscribe an address to parrot-dev that performs this action for us? Pm
Re: [perl #58726] [PATCH] add the option encoding to Configure.pl
Can you explain a bit more about the rationale for adding this option to Configure.pl? I think I is necessary to tell parrot to work on a computer with utf-8 encoding also with the same encoding, so that for example the following PASM-code works: set S0, Ö123\n That code is not supposed to work. Encoding and charset must be specified. Is not good that pir or pasm code meaning be dependent of locale specifics of the system. Also in several operating systems is not the computer who is working with some charset and encoding or other, is each process (depending of user settings on locale env vars, for example). So establishing an immutable global default is not a good idea. -- Salu2
Re: [svn:parrot] r31230 - in trunk: compilers/imcc src src/pmc
On Thursday 18 September 2008 08:42:46 [EMAIL PROTECTED] wrote:
Author: julianalbo
Date: Thu Sep 18 08:42:43 2008
New Revision: 31230
Modified:
trunk/compilers/imcc/pcc.c
Log:
miscellaneous fixes
Modified: trunk/compilers/imcc/pcc.c
===
=== --- trunk/compilers/imcc/pcc.c (original)
+++ trunk/compilers/imcc/pcc.cThu Sep 18 08:42:43 2008
@@ -211,7 +211,16 @@
int i, flags;
char s[16];
SymReg ** const regs = mem_allocate_n_zeroed_typed(n + 1, SymReg *);
-char* buf = mem_allocate_n_typed(5*n+1, char *);
+/* Assumptions:
+ * Flags has no more than 3 hex digits
+ * Plus 0x and , gives 6 char for arg
+ * 4 more for: ( , ), and
+ * 1 more for C string 0 delimiter
+ * Last item has no , but we can forget that to avoid
+ * to have to check for 0 args.
+ */
+unsigned int bufsize = 6 * n + 5;
+char * buf = mem_allocate_n_typed(bufsize, char);
strcpy(buf, \();
for (i = 0; i n; i++) {
The comment helps, but defining these magic numbers as magic constants might
be even clearer (but please keep the comment).
@@ -252,7 +261,8 @@
if (i n - 1)
strcat(s, ,);
-strcat(buf, s); /* XXX check avail len */
+PARROT_ASSERT(strlen(buf) + strlen(s) bufsize);
+strcat(buf, s);
}
strcat(buf, )\);
That only helps with debug builds; if there are possible inputs we won't
discover in our testing, we might as well make this an unconditional test and
throw an exception if something goes wrong here. IMCC is user-facing, so I
want to be paranoid.
-- c
Re: [svn:parrot] r31230 - in trunk: compilers/imcc src src/pmc
On Thu, Sep 18, 2008 at 8:14 PM, chromatic [EMAIL PROTECTED] wrote:
-char* buf = mem_allocate_n_typed(5*n+1, char *);
+/* Assumptions:
+ * Flags has no more than 3 hex digits
+ * Plus 0x and , gives 6 char for arg
+ * 4 more for: ( , ), and
+ * 1 more for C string 0 delimiter
+ * Last item has no , but we can forget that to avoid
+ * to have to check for 0 args.
+ */
+unsigned int bufsize = 6 * n + 5;
+char * buf = mem_allocate_n_typed(bufsize, char);
strcpy(buf, \();
for (i = 0; i n; i++) {
The comment helps, but defining these magic numbers as magic constants might
be even clearer (but please keep the comment).
I think that setting a constant is sort of establishing it as a
documented value, and I don't think that document who many digits can
have the hex representation of flags is good, or it must be done in a
file other than the one that defines the flags.
+PARROT_ASSERT(strlen(buf) + strlen(s) bufsize);
+strcat(buf, s);
That only helps with debug builds; if there are possible inputs we won't
discover in our testing, we might as well make this an unconditional test and
throw an exception if something goes wrong here. IMCC is user-facing, so I
want to be paranoid.
After some thinking I must agree. I hope that this code will be
refactored before 1.0, but we can't be sure.
The problem is that I don't know what severity must be used, and if it
the exception must be catched by the main imcc entry points or let it
propagate to the caller. Maybe all imcc fail conditions must throw
exceptions, for the benefit of load_bytecode invocations.
--
Salu2
Re: [perl #51262] [BUG] Segfault in pdump
Changed in r31328: now string DATA use string_escape_string and delimit with double quotes, avoiding the need to a special case for empty strings and giving less problematic results with non ascii encodings and control characters. -- Salu2
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Thu, 2008-09-18 at 10:28 -0700, jerry gay wrote: On Thu, Sep 18, 2008 at 10:21 AM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Thu, Sep 18, 2008 at 09:06:44AM -0700, jerry gay wrote: what some refer to as traits, perl 6 calls roles. The Perl 6 name is a better, more natural and self-describing name. Larry has a gift for naming, and he puts a lot of effort into making names obvious. I think it's a mistake to ignore that, just because Larry didn't design all of the major dynamic languages himself. Other languages have adopted the Perl shortname of hash as well, including Ruby and this odd little creature known as Parrot. Perhaps we should rename Parrot's Hash class to AssociativePMCArray? 1/2 ;-) I personally agree that 'hash' is by far the better name. But to be fair, it helps that 'hash' is one of the basic data structures taught to every CS student freshman year we should call gather and take by their proper names where they're defined. aggregating coroutine is more precise and descriptive than is gather, If you had no idea what an 'aggregating coroutine' was, would your first guess be something that acts as a generator for a lazy list? Really? And you'd get that faster than guessing what 'gather' might mean? Do you think the same is true of someone without a CS degree and/or a rather advanced background? however gather is much easier to say in polite company, and is therefore a better name to use at the language level. We should not have the implementation and the HLLs use utterly different terminology for the same concept (unless every HLL uses different terminology and they all suck) -- that will just confuse contributors who don't do full time core work. It is certainly proper for the core and the HLLs to use different terminology for things that are similar but different, but in this case we're talking about the implementation of the HLL concept -- it should use the same terminology. Of course, I'm fine with using slightly more verbosity in the core, because it will be more rarely looked at and therefore needs to optimize more for clarity than stroke reduction. By this reasoning, we should also change the other exceptions: .CONTROL_RETURN = .CONTROL_SUB_RETURN (or .CONTROL_SUB_EXIT) .CONTROL_BREAK= .CONTROL_LOOP_EXIT .CONTROL_CONTINUE = .CONTROL_LOOP_NEXT and perhaps add .CONTROL_LOOP_REPEAT there as well. Note that I'm not at all opposed to this -- if we're going to do it for one, we really ought to do it for all. agreed. precision is of little benefit unless it's consistent across related functionality. Along the same lines, how about one of the following pairs? * .CONTROL_GENERATOR_GATHER and .CONTROL_GENERATOR_TAKE * .CONTROL_GENERATOR_SINK and .CONTROL_GENERATOR_SOURCE * .CONTROL_GATHER_SINK and .CONTROL_GATHER_SOURCE * .CONTROL_GATHER_LIST and .CONTROL_YIELD_LIST_ELEMENT(S) * .CONTROL_LIST_GATHER and .CONTROL_LIST_YIELD * .CONTROL_LAZY_GATHER and .CONTROL_LAZY_YIELD * .CONTROL_LAZY_LIST_GATHER and .CONTROL_LAZY_LIST_YIELD (Or something similar; my naming fu is off today.) -'f
Re: [svn:parrot] r31230 - in trunk: compilers/imcc src src/pmc
On Thursday 18 September 2008 12:03:19 NotFound wrote: On Thu, Sep 18, 2008 at 8:14 PM, chromatic [EMAIL PROTECTED] wrote: The comment helps, but defining these magic numbers as magic constants might be even clearer (but please keep the comment). I think that setting a constant is sort of establishing it as a documented value, and I don't think that document who many digits can have the hex representation of flags is good, or it must be done in a file other than the one that defines the flags. Even #define-ing them locally to the function has readability value. I want the code to be so blindingly obvious to read that if there's a problem, it's apparent without having to turn magic numbers back into their meanings. The compiler doesn't care either way. +PARROT_ASSERT(strlen(buf) + strlen(s) bufsize); +strcat(buf, s); That only helps with debug builds; if there are possible inputs we won't discover in our testing, we might as well make this an unconditional test and throw an exception if something goes wrong here. IMCC is user-facing, so I want to be paranoid. After some thinking I must agree. I hope that this code will be refactored before 1.0, but we can't be sure. I sort of hope IMCC can vanish before 1.0, or at least find a small army of heavily motivated cage cleaners who merge it with pirc. The problem is that I don't know what severity must be used, and if it the exception must be catched by the main imcc entry points or let it propagate to the caller. Maybe all imcc fail conditions must throw exceptions, for the benefit of load_bytecode invocations. I don't think anyone's asked that question yet (at least no one has answered it yet), so let's not let that get in the way of adding an exception here now. Unifying IMCC exceptions with Parrot exceptions does seem valuable (though convincing IMCC not to leak memory under those circumstances... I'm going to lie down now for a while). -- c
Re: New Parrot mailing list
Allison Randal wrote: The new Parrot mailing list (replacing perl6-internals/parrot-porters) is [EMAIL PROTECTED]. If you were subscribed to the old list, you're now subscribed to the new list. If you were a digest subscriber to the old list, you're now a digest subscriber to the new list. More information about the list and public archives are available at: http://lists.parrot.org/mailman/listinfo/parrot-dev Does this mean that the newsgroup perl.perl6.internal on nntp.perl.org is dying as well? If so, I think that will be a real loss. I vastly prefer the news interface to a mailing list for following such groups. (And I wish this had been discussed publicly before this announcement!) kid51
