Re: Nomenclature Question - BEGIN etc.
JMD Consider the words that may be used to introduce a block for a special JMD purpose, like JMD JMD BEGIN JMD END JMD INIT JMD CATCH JMD etc. JMD JMD What do you call those? Well, lessee. The Common Lisp spec calls them situations in the definition of (eval-when)... JMD They are not even special named blocks because JMD that is not the block name (that already means something). Now you've lost me. I was pretty sure that was the block name. AIUI, you can give arbitrary names to any block, and these names function the same way (i.e. can be used in flow control statements), but they also happen to control when the block is actually evaluated. CO The perldocs call them Five specially named code blocks, The Camel CO names them individually (e.g. BEGIN block). How about phase blocks? CO They control in what phase of compilation/runtime the code runs in. I don't know, phase sounds too specific to me. Does the catching of an exception really bring us into a new phase of execution? What about the LAST time through a loop? etc. -- Mark J. Reed [EMAIL PROTECTED]
Re: Nomenclature Question - BEGIN etc.
On Thu, Apr 10, 2008 at 2:16 AM, Mark J. Reed [EMAIL PROTECTED] wrote: JMD Consider the words that may be used to introduce a block for a special JMD purpose, like JMD JMD BEGIN JMD END JMD INIT JMD CATCH JMD etc. JMD JMD What do you call those? Well, lessee. The Common Lisp spec calls them situations in the definition of (eval-when)... JMD They are not even special named blocks because JMD that is not the block name (that already means something). Now you've lost me. I was pretty sure that was the block name. AIUI, you can give arbitrary names to any block, and these names function the same way (i.e. can be used in flow control statements), but they also happen to control when the block is actually evaluated. CO The perldocs call them Five specially named code blocks, The Camel CO names them individually (e.g. BEGIN block). How about phase blocks? CO They control in what phase of compilation/runtime the code runs in. I don't know, phase sounds too specific to me. Does the catching of an exception really bring us into a new phase of execution? What about the LAST time through a loop? etc. -- Mark J. Reed [EMAIL PROTECTED] It looks like they already have a name in S04: Closure traits*. * http://dev.perl.org/perl6/doc/design/syn/S04.html#Closure_traits -- Chas. Owens wonkden.net The most important skill a programmer can have is the ability to read.
Re: Nomenclature Question - BEGIN etc.
On Thu, Apr 10, 2008 at 2:26 AM, Chas. Owens [EMAIL PROTECTED] wrote: It looks like they already have a name in S04: Closure traits*. * http://dev.perl.org/perl6/doc/design/syn/S04.html#Closure_traits I don't know, it seems like any value might happen to both be a closure and have traits, which aren't necessarily these particular ones... -- Mark J. Reed [EMAIL PROTECTED]
Re: Nomenclature Question - BEGIN etc.
On Thu, Apr 10, 2008 at 2:29 AM, Mark J. Reed [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 2:26 AM, Chas. Owens [EMAIL PROTECTED] wrote: It looks like they already have a name in S04: Closure traits*. * http://dev.perl.org/perl6/doc/design/syn/S04.html#Closure_traits I don't know, it seems like any value might happen to both be a closure and have traits, which aren't necessarily these particular ones... snip How about Control Closure then? -- Chas. Owens wonkden.net The most important skill a programmer can have is the ability to read.
[perl #52666] [PATCH] Eclectus: implement EQ?, EQV? and EQUAL?
# New Ticket Created by Andreas Rottmann # Please include the string: [perl #52666] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=52666 Well, the subject sais it all. For implementing EQ? efficiently (using the `issame' instruction), the compiler now emits `get_root_global' instructions to access the boolean and empty list values, and those are initialized when the program is loaded. Implement equality primitives From: Andreas Rottmann [EMAIL PROTECTED] --- MANIFEST |2 + languages/eclectus/compiler.scm | 83 -- languages/eclectus/t/equality.pl |5 ++ languages/eclectus/t/equality.t | 15 +++ 4 files changed, 84 insertions(+), 21 deletions(-) create mode 100644 languages/eclectus/t/equality.pl create mode 100644 languages/eclectus/t/equality.t diff --git a/MANIFEST b/MANIFEST index 5a50f1f..4827a78 100644 --- a/MANIFEST +++ b/MANIFEST @@ -1324,6 +1324,8 @@ languages/eclectus/t/conditionals.pl[eclectus] languages/eclectus/t/conditionals.t [eclectus] languages/eclectus/t/empty_list.pl [eclectus] languages/eclectus/t/empty_list.t [eclectus] +languages/eclectus/t/equality.pl[eclectus] +languages/eclectus/t/equality.t [eclectus] languages/eclectus/t/harness[eclectus] languages/eclectus/t/integers.pl[eclectus] languages/eclectus/t/integers.t [eclectus] diff --git a/languages/eclectus/compiler.scm b/languages/eclectus/compiler.scm index 2fee04e..fbb7295 100644 --- a/languages/eclectus/compiler.scm +++ b/languages/eclectus/compiler.scm @@ -63,7 +63,6 @@ $P0 = split ' ', 'post pir evalpmc' past_compiler.'stages'( $P0 ) past_compiler.'eval'(stmts) - .end ))) @@ -71,6 +70,16 @@ (define emit-builtins (lambda () (emit + .sub '__initconst' :init + $P0 = new 'EclectusBoolean' + $P0 = 1 + set_root_global ['_eclectus'], '#t', $P0 + $P0 = new 'EclectusBoolean' + set_root_global ['_eclectus'], '#f', $P0 + $P0 = new 'EclectusEmptyList' + set_root_global ['_eclectus'], '()', $P0 + .end + .sub 'say' .param pmc args :slurpy if null args goto end @@ -127,6 +136,29 @@ .return ($I0) .end + .sub 'eq?' + .param pmc a + .param pmc b + $I0 = issame a, b + + .return ($I0) + .end + + .sub 'eqv?' + .param pmc a + .param pmc b + $I0 = iseq a, b + + .return ($I0) + .end + + .sub 'equal?' + .param pmc a + .param pmc b + $I0 = iseq a, b + + .return ($I0) + .end ))) ; recognition of forms @@ -308,7 +340,14 @@ (define-primitive (fx arg1 arg2) (emit-comparison infix: arg1 arg2)) +(define-primitive (eq? arg1 arg2) + (emit-comparison eq? arg1 arg2)) + +(define-primitive (eqv? arg1 arg2) + (emit-comparison eqv? arg1 arg2)) +(define-primitive (equal? arg1 arg2) + (emit-comparison equal? arg1 arg2)) ; asking for the type of an object (define emit-typequery @@ -371,26 +410,28 @@ (viviself Undef (define (emit-constant x) - (past::val - (cond -((fixnum? x) - (quasiquote (@ (value (unquote x)) -(returns EclectusFixnum -((char? x) - (quasiquote (@ (value (unquote (char-integer x))) -(returns EclectusCharacter -((null? x) - '(@ (value 0) - (returns EclectusEmptyList))) -((boolean? x) - (quasiquote (@ (value (unquote (if x 1 0))) -(returns EclectusBoolean -((string? x) - (quasiquote (@ (value (unquote (format #f '~a' x))) -(returns EclectusString -((vector? x) - (quasiquote (@ (value '#0()') -(returns EclectusString))) + (cond + ((fixnum? x) +(past::val `(@ (value ,x) + (returns EclectusFixnum + ((char? x) +(past::val `(@ (value ,(char-integer x)) + (returns EclectusCharacter + ((null? x) +(emit-global-ref ())) + ((boolean? x) +(emit-global-ref (if x #t #f))) + ((string? x) +(past::val `(@ (value (unquote (format #f '~a' x))) + (returns EclectusString + ((vector? x) +(past::val '(@ (value '#0()') + (returns EclectusString)) + + +(define (emit-global-ref name) + (past::op `(@ (pasttype inline) +(inline
[perl #52680] [BUG]: 'make' failure on Linux; possibly TGE-related
On Wed Apr 09 20:52:37 2008, infinoid wrote: I've implemented a workaround (manually specifying build rules for the subdir files) in r26899, to keep us rolling in the meantime. Please revert that when a real fix comes around. And after a little more research, I've found the proper fix. GNU Make was ignoring the .pir.pbc rule (regardless of whether it was in a subdir or not) because it didn't recognise those file suffixes. With an added .SUFFIXES line, all works fine. So, fixed in r26901. Mark
[perl #52706] [BUG]: t/dynpmc/gdbmhash.t hanging on Darwin
# New Ticket Created by James Keenan # Please include the string: [perl #52706] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=52706 While conducting 'make test' on Darwin last night, I noticed that the process was hanging on t/dynpmc/gdbmhash.t. Running that file with 'prove -v', I get the same hang, which appears to come from test #3: $ prove -v t/dynpmc/gdbmhash.t t/dynpmc/gdbmhash.. 1..13 ok 1 - typeof ok 2 - check whether interface is done I have not had time to diagnose this, but it appears to have developed between r26707 (April 2) and r26892 (April 9). I have not experienced this hang on Linux, nor has it been reported in any smoke test (but then we rarely get smoke reports on Darwin posted to our page). Later tonight I will try to do a binary search and identify the revision where this problem began. Any ideas? Thank you very much. kid51
Re: Nomenclature Question - BEGIN etc.
On Wed, Apr 9, 2008 at 10:31 PM, John M. Dlugosz [EMAIL PROTECTED] wrote: Consider the words that may be used to introduce a block for a special purpose, like BEGIN END INIT CATCH etc. What do you call those? They are not even special named blocks because that is not the block name (that already means something). syntactically speaking, http://svn.pugscode.org/pugs/src/perl6/STD.pm groups them in statement_control, just like 'if' and 'for'. semantically speaking, i don't have a clever or unique name for them, other than what larry has already come up with. ~jerry
Re: What I'm Working On
HaloO, John M. Dlugosz wrote: Can you give a pointer to where this was discussed? It was said by $Larry in the Adding linear interpolation to an array thread where I also tried to explain co- and contravariant typing of container types. Regards, TSa. -- The Angel of Geometry and the Devil of Algebra fight for the soul of any mathematical being. -- Attributed to Hermann Weyl
Re: Nomenclature Question - BEGIN etc.
On Thu, Apr 10, 2008 at 08:52:38AM -0700, jerry gay wrote: : On Wed, Apr 9, 2008 at 10:31 PM, John M. Dlugosz : [EMAIL PROTECTED] wrote: : Consider the words that may be used to introduce a block for a special : purpose, like : : BEGIN : END : INIT : CATCH : etc. : : What do you call those? They are not even special named blocks because : that is not the block name (that already means something). : : syntactically speaking, http://svn.pugscode.org/pugs/src/perl6/STD.pm : groups them in statement_control, just like 'if' and 'for'. : semantically speaking, i don't have a clever or unique name for them, : other than what larry has already come up with. It's a really good question, particularly because it's so exposed to the user, so it needs to be something not too unwieldy. Semantically, they are closures that are attached as properties of the surrounding lexical scope, and since they're compile-time properties, they're declarative. So we've been calling them closure traits. But I pretty certain we should be using the term block here instead, even though they are technically closures (or potentially closures, depending on how you define that). But people will generally prefer the more concrete block if there are always curlies involved, and people are already used to saying BEGIN block and such. And traits is also problematic; it says what they are, but not really what they do. They're really come froms with predefined names that are automatically called at the appropriate time. So I think perhaps the best term for them might be something more like event blocks, blocks that are called if and when a particular event happens. That's a more user-oriented definition. Larry
Re: Nomenclature Question - BEGIN etc.
Mark J. Reed markjreed-at-mail.com |Perl 6| wrote: Now you've lost me. I was pretty sure that was the block name. AIUI, you can give arbitrary names to any block, and these names function the same way (i.e. can be used in flow control statements), but they also happen to control when the block is actually evaluated. I might have misremembered, but i thought labels were followed by a colon in Perl 6. A quick scan of the docs... It is illegal for a provisional subroutine call to be followed by a colon postfix, since such a colon is allowed only on an indirect object, or a method call in dot form. (It is also allowed on a label when a statement is expected.) ... foo:# label -- must be label at statement boundary. -- ILLEGAL otherwise foo: bar: # two labels in a row, okay
Re: Nomenclature Question - BEGIN etc.
As I read it, the original question was about the actual keyword - e.g. the word BEGIN - as distinct from the block it's attached to. Though I agree we need a general term for the latter, the name event block seems to imply that BEGIN et al are events, which might be ok or might cause confusion with more thoroughly event-driven programming models. On 4/10/08, Larry Wall [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 08:52:38AM -0700, jerry gay wrote: : On Wed, Apr 9, 2008 at 10:31 PM, John M. Dlugosz : [EMAIL PROTECTED] wrote: : Consider the words that may be used to introduce a block for a special : purpose, like : : BEGIN : END : INIT : CATCH : etc. : : What do you call those? They are not even special named blocks because : that is not the block name (that already means something). : : syntactically speaking, http://svn.pugscode.org/pugs/src/perl6/STD.pm : groups them in statement_control, just like 'if' and 'for'. : semantically speaking, i don't have a clever or unique name for them, : other than what larry has already come up with. It's a really good question, particularly because it's so exposed to the user, so it needs to be something not too unwieldy. Semantically, they are closures that are attached as properties of the surrounding lexical scope, and since they're compile-time properties, they're declarative. So we've been calling them closure traits. But I pretty certain we should be using the term block here instead, even though they are technically closures (or potentially closures, depending on how you define that). But people will generally prefer the more concrete block if there are always curlies involved, and people are already used to saying BEGIN block and such. And traits is also problematic; it says what they are, but not really what they do. They're really come froms with predefined names that are automatically called at the appropriate time. So I think perhaps the best term for them might be something more like event blocks, blocks that are called if and when a particular event happens. That's a more user-oriented definition. Larry -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed [EMAIL PROTECTED]
Re: Nomenclature Question - BEGIN etc.
On Thu, Apr 10, 2008 at 01:35:57PM -0400, Mark J. Reed wrote: : As I read it, the original question was about the actual keyword - : e.g. the word BEGIN - as distinct from the block it's attached to. : Though I agree we need a general term for the latter, the name event : block seems to imply that BEGIN et al are events, which might be ok : or might cause confusion with more thoroughly event-driven programming : models. Hmm, maybe control event blocks and control events, then... Larry
[perl #52712] Build broken
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #52712]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=52712
Today I tried to test if an imcc patch worked and ran into the following
weird build problem:
$ perl5.8 Configure.pl
Can't use an undefined value as a HASH reference at
lib/Parrot/Configure/Options/Test.pm line 39.
Compilation failed in require at Configure.pl line 13.
BEGIN failed--compilation aborted at Configure.pl line 13.
It's a strange problem. I suspect it's a strange interaction between a
broken MANIFEST file and an insufficiently defensive
Parrot/Configure/Options/Test.pm, though what, precisely, that Test.pm
file is trying to do at 'use' time that causes Configure.pl to completely
fail, is beyond me.
Here's an easy recipe to reproduce it on any Unix-based system.
First, get in a working directory containing an svn checkout of parrot.
Then run the following:
#!/bin/sh
rm -rf ../parrot-copy
mkdir ../parrot-copy
awk '!/^#/ {print $1}' MANIFEST | cpio -pdm ../parrot-copy
cd ../parrot-copy
perl Configure.pl
(This is, in fact, how I make copies of the parrot source to spread around
to different systems for testing.)
--
Andy Dougherty [EMAIL PROTECTED]
key.c and missing default in key_integer switch
Hey,
I *thought* I'd try and clean up an easy one, so I took
src/key.c
src/key.c: In function `key_integer':
src/key.c:368: warning: switch missing default case
After a little poking I tracked the rest of the Key__FLAG s down to
include/parrot/key.h (and pobj.h) [1] and so I rearrainged the case stmt
to cover them all (noting the TODO on slices, I separated those), putting
in the current default behavior for everything that wasn't already covered
and then adding a default branch w/ an exception (taken from the next sub
... ). This broke iterator.t tests and it appears to be due to a missing
(?) flag value of '8' for switch test
switch (PObj_get_FLAGS(key) KEY_type_FLAGS) {
So ... either there's a missing KEY__FLAG or something. One hint is in
src/packdump.c [3] which would say the '8' is an 'is_string' flag? I've
not yet been able to track backwards (my debugging is painfully slow w/
printf's and re-makes) to see who's calling w/ the funny flag value but I
thought I'd ask here to see if anybody had an answer.
Thanks.
a
p.s. Thanks again to jkeen for being so helpful and patient w/ my
rambling. I *almost* asked this on #parrot last night, but I chickened
out ;-
[1]
key.h
typedef enum {
KEY_integer_FLAG= PObj_private0_FLAG,
KEY_number_FLAG = PObj_private1_FLAG,
KEY_hash_iterator_FLAGS = PObj_private0_FLAG | PObj_private1_FLAG,
KEY_string_FLAG = PObj_private2_FLAG,
KEY_pmc_FLAG= PObj_private3_FLAG,
KEY_register_FLAG = PObj_private4_FLAG,
KEY_start_slice_FLAG= PObj_private5_FLAG,
KEY_end_slice_FLAG = PObj_private6_FLAG,
KEY_inf_slice_FLAG = PObj_private7_FLAG,
...
pobj.h
#define POBJ_FLAG(n) ((UINTVAL)1 (n))
/* PObj flags */
typedef enum PObj_enum {
/* This first 8 flags may be used privately by a Parrot Object.
* You should alias these within an individual class's header file.
*
* Note: If the meanings of these flags are changed, then the
symbolic
* names kept in flag_bit_names (see src/packdump.c) must also be
updated.
*/
PObj_private0_FLAG = POBJ_FLAG(0),
PObj_private1_FLAG = POBJ_FLAG(1),
PObj_private2_FLAG = POBJ_FLAG(2),
PObj_private3_FLAG = POBJ_FLAG(3),
PObj_private4_FLAG = POBJ_FLAG(4),
PObj_private5_FLAG = POBJ_FLAG(5),
PObj_private6_FLAG = POBJ_FLAG(6),
PObj_private7_FLAG = POBJ_FLAG(7),
[2]
PARROT_API
PARROT_WARN_UNUSED_RESULT
INTVAL
key_integer(PARROT_INTERP, ARGIN(PMC *key))
{
if (VTABLE_isa(interp, key, CONST_STRING(interp, Key))) {
switch (PObj_get_FLAGS(key) KEY_type_FLAGS) {
case KEY_hash_iterator_FLAGS:
case KEY_integer_FLAG:
{
return PMC_int_val(key);
}
case KEY_integer_FLAG | KEY_register_FLAG:
{
return REG_INT(interp, PMC_int_val(key));
}
case KEY_pmc_FLAG | KEY_register_FLAG:
{
PMC * const reg = REG_PMC(interp, PMC_int_val(key));
return VTABLE_get_integer(interp, reg);
}
case KEY_string_FLAG:
{
return string_to_int(interp,
PMC_str_val(key));
}
case KEY_string_FLAG | KEY_register_FLAG:
{
STRING * const s_reg = REG_STR(interp, PMC_int_val(key));
return string_to_int(interp, s_reg);
}
/* TODO check for slice_FLAGs */
case KEY_start_slice_FLAG:
case KEY_end_slice_FLAG:
case KEY_inf_slice_FLAG:
{
return VTABLE_get_integer(interp, key);
}
case KEY_number_FLAG:
{
return VTABLE_get_integer(interp, key);
}
default:
real_exception(interp, NULL, INVALID_OPERATION,
Key_integer %d %d %d not a valid flag!\n, VTABLE_get_int eger(interp,
key), PObj_get_FLAGS(key), PObj_get_FLAGS(key) KEY_type_FLAGS);
}// switch
} // if VTABLE_isa
return VTABLE_get_integer(interp, key);
} // sub key_integer
[3]
/* [this desperately needs better abstraction, so we're not duplicating
the enum
* PObj_enum definition in the include/parrot/pobj.h file. -- rgr,
1-Mar-08.]
*/
static const char *flag_bit_names[] =
{
private0,
private1,
private2,
private3,
private4,
private5,
private6,
private7,
is_string,
is_PMC,
is_PMC_EXT,
---
Andy Bach
Systems Mangler
Internet: [EMAIL PROTECTED]
Voice: (608) 261-5738 Fax: 264-5932
The bureaucracy is
Re: failure notice
Just so you don't think this is warnocked, I'm looking at it, and thinking about it. By and large it seems to be going the right direction, though I've naturally got a number of quibbles. Probably each quibble needs to be a separate thread though, since many of them will probably breed discussion. On a larger question, I'm wondering if it's time to slush/freeze the Synopses as historical documents and put all spec effort into the new form (presumably as a wiki that knows how to serialize into a document). I don't think we have the bandwidth to maintain multiple standard documents. Well, okay, *I* don't have the bandwidth... You might need to teach some of us how to write in Standardese, however. :) If we did set up a wiki, we could have some of the specific language lawyering discussions attached to the specchunk in question, which seems like a good idea to save wear and tear on our email clients, and to prevent recurring FAQs. We'll probably need to exercise a modicum of control over who gets to revise the spec. We also probably need to have a discussion of whether the current section outline is optimal, and if not, whether it needs fixing now or can be simply renegotiated via wiki. Larry
Re: failure notice
On Thu, Apr 10, 2008 at 11:23 AM, Larry Wall [EMAIL PROTECTED] wrote: On a larger question, I'm wondering if it's time to slush/freeze the Synopses as historical documents and put all spec effort into the new form (presumably as a wiki that knows how to serialize into a document). I don't think we have the bandwidth to maintain multiple standard documents. Well, okay, *I* don't have the bandwidth... from the perspective of a language implementor, i believe that formalization may be a benefit in the long term. however, it will cause some short-term disruption with which i'd greatly appreciate help. specifically, the spec test suite employs the use of smartlinks, which are pod-like tags used to relate a set of tests to specific locations in the synopses. modification of the spec format will require modification of the spec test suite, and the coverage/reporting tools (e.g. smartlinks.pl.) also, modification of the spec file type from .pod to .odf will certainly add to the complexity of any tool migration. as multiple implementations of the spec are now maturing, these tools have become more important to judging the progress of any implementation. also, as manager for the parrot and perl 6 projects under the perl foundation umbrella for google summer of code (GSoC), i'd like to note that there's a chance we'll have a student working on a project to improve the perl 6 test suite. i expect this student to make good use of today's existing tools, like smartlinks.pl, in the course of his project. reformatting the spec documents will likely implement this effort, and may lead to a failed project where the student will not be compensated. i certainly don't want to see that happen. i'll know more about whether or not this project has been accepted in the coming week. i hope that the hackathons during the upcoming conference season will be a place where folks can help us improve the spec test suite, and that a spec document format change today will be disruptive. i'd love to see folks helping out with migration to a new documentation format, as well, but i think it's easier if we keep the current documents up-to-date until the migration is considered complete. i believe that if we put effort into migrating to a new format, while keeping the current spec pod format as canon, and later (post-GSoC) marking the current spec documents as historical, it will allow time for implementation, documentation, and testing projects to move forward during the traditionally busy summer months. ~jerry
Re: failure notice
On Thu, Apr 10, 2008 at 12:11:05PM -0700, jerry gay wrote: : On Thu, Apr 10, 2008 at 11:23 AM, Larry Wall [EMAIL PROTECTED] wrote: : On a larger question, I'm wondering if it's time to slush/freeze : the Synopses as historical documents and put all spec effort into : the new form (presumably as a wiki that knows how to serialize into : a document). I don't think we have the bandwidth to maintain multiple : standard documents. Well, okay, *I* don't have the bandwidth... : : from the perspective of a language implementor, i believe that : formalization may be a benefit in the long term. however, it will : cause some short-term disruption with which i'd greatly appreciate : help. Not to panic; there is almost certainly a creative path through this. : specifically, the spec test suite employs the use of smartlinks, which : are pod-like tags used to relate a set of tests to specific locations : in the synopses. modification of the spec format will require : modification of the spec test suite, and the coverage/reporting tools : (e.g. smartlinks.pl.) Nothing needs to change there over the short term. We aren't deleting the Synopses. :) : also, modification of the spec file type from : .pod to .odf will certainly add to the complexity of any tool : migration. as multiple implementations of the spec are now maturing, : these tools have become more important to judging the progress of any : implementation. If the spec file type ends up .odf at some point, it will be an accident. I think of it more as wikified pod. Smartlinks are fine, but we're running into the limitations of naming pieces of spec, which really has little to do with what format they're in, and *shouldn't* have much to do with the organization of the specs. You're looking for an invariant, and that's fine, but the *orderedness* of the various bits of the Synopses cannot be that invariant over the long term. In short, we need invariant symbolic indexing, not invariant numeric indexing. : also, as manager for the parrot and perl 6 projects under the perl : foundation umbrella for google summer of code (GSoC), i'd like to note : that there's a chance we'll have a student working on a project to : improve the perl 6 test suite. i expect this student to make good use : of today's existing tools, like smartlinks.pl, in the course of his : project. reformatting the spec documents will likely implement this : effort, and may lead to a failed project where the student will not be : compensated. i certainly don't want to see that happen. i'll know more : about whether or not this project has been accepted in the coming : week. It may well be that the smartlinks can be made a hair smarter, and point to an abstract naming scheme rather than a concrete file. Think URLs, not trying to navigate a .odt file. : i hope that the hackathons during the upcoming conference season will : be a place where folks can help us improve the spec test suite, and : that a spec document format change today will be disruptive. i'd love : to see folks helping out with migration to a new documentation format, : as well, but i think it's easier if we keep the current documents : up-to-date until the migration is considered complete. Which is why I said slush/freeze rather than freeze. In any case, not all smartlinks have to be converted at once. And the naming scheme that rides above the document organization may well continue to resemble synopses numbers and section content. As usual, we're just thinking about another level of indirection... :) : i believe that if we put effort into migrating to a new format, while : keeping the current spec pod format as canon, and later (post-GSoC) : marking the current spec documents as historical, it will allow time : for implementation, documentation, and testing projects to move : forward during the traditionally busy summer months. It will always be too early, and too late. There will always be reasons not to do it till next year, and reasons you're hosed because it wasn't done years ago. Now is all we've got at the moment... Larry
[perl #52710] key.c and missing default in key_integer switch
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #52710]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=52710
Hey,
I *thought* I'd try and clean up an easy one, so I took
src/key.c
src/key.c: In function `key_integer':
src/key.c:368: warning: switch missing default case
After a little poking I tracked the rest of the Key__FLAG s down to
include/parrot/key.h (and pobj.h) [1] and so I rearrainged the case stmt
to cover them all (noting the TODO on slices, I separated those), putting
in the current default behavior for everything that wasn't already covered
and then adding a default branch w/ an exception (taken from the next sub
... ). This broke iterator.t tests and it appears to be due to a missing
(?) flag value of '8' for switch test
switch (PObj_get_FLAGS(key) KEY_type_FLAGS) {
So ... either there's a missing KEY__FLAG or something. One hint is in
src/packdump.c [3] which would say the '8' is an 'is_string' flag? I've
not yet been able to track backwards (my debugging is painfully slow w/
printf's and re-makes) to see who's calling w/ the funny flag value but I
thought I'd ask here to see if anybody had an answer.
Thanks.
a
p.s. Thanks again to jkeen for being so helpful and patient w/ my
rambling. I *almost* asked this on #parrot last night, but I chickened
out ;-
[1]
key.h
typedef enum {
KEY_integer_FLAG= PObj_private0_FLAG,
KEY_number_FLAG = PObj_private1_FLAG,
KEY_hash_iterator_FLAGS = PObj_private0_FLAG | PObj_private1_FLAG,
KEY_string_FLAG = PObj_private2_FLAG,
KEY_pmc_FLAG= PObj_private3_FLAG,
KEY_register_FLAG = PObj_private4_FLAG,
KEY_start_slice_FLAG= PObj_private5_FLAG,
KEY_end_slice_FLAG = PObj_private6_FLAG,
KEY_inf_slice_FLAG = PObj_private7_FLAG,
...
pobj.h
#define POBJ_FLAG(n) ((UINTVAL)1 (n))
/* PObj flags */
typedef enum PObj_enum {
/* This first 8 flags may be used privately by a Parrot Object.
* You should alias these within an individual class's header file.
*
* Note: If the meanings of these flags are changed, then the
symbolic
* names kept in flag_bit_names (see src/packdump.c) must also be
updated.
*/
PObj_private0_FLAG = POBJ_FLAG(0),
PObj_private1_FLAG = POBJ_FLAG(1),
PObj_private2_FLAG = POBJ_FLAG(2),
PObj_private3_FLAG = POBJ_FLAG(3),
PObj_private4_FLAG = POBJ_FLAG(4),
PObj_private5_FLAG = POBJ_FLAG(5),
PObj_private6_FLAG = POBJ_FLAG(6),
PObj_private7_FLAG = POBJ_FLAG(7),
[2]
PARROT_API
PARROT_WARN_UNUSED_RESULT
INTVAL
key_integer(PARROT_INTERP, ARGIN(PMC *key))
{
if (VTABLE_isa(interp, key, CONST_STRING(interp, Key))) {
switch (PObj_get_FLAGS(key) KEY_type_FLAGS) {
case KEY_hash_iterator_FLAGS:
case KEY_integer_FLAG:
{
return PMC_int_val(key);
}
case KEY_integer_FLAG | KEY_register_FLAG:
{
return REG_INT(interp, PMC_int_val(key));
}
case KEY_pmc_FLAG | KEY_register_FLAG:
{
PMC * const reg = REG_PMC(interp, PMC_int_val(key));
return VTABLE_get_integer(interp, reg);
}
case KEY_string_FLAG:
{
return string_to_int(interp,
PMC_str_val(key));
}
case KEY_string_FLAG | KEY_register_FLAG:
{
STRING * const s_reg = REG_STR(interp, PMC_int_val(key));
return string_to_int(interp, s_reg);
}
/* TODO check for slice_FLAGs */
case KEY_start_slice_FLAG:
case KEY_end_slice_FLAG:
case KEY_inf_slice_FLAG:
{
return VTABLE_get_integer(interp, key);
}
case KEY_number_FLAG:
{
return VTABLE_get_integer(interp, key);
}
default:
real_exception(interp, NULL, INVALID_OPERATION,
Key_integer %d %d %d not a valid flag!\n, VTABLE_get_int eger(interp,
key), PObj_get_FLAGS(key), PObj_get_FLAGS(key) KEY_type_FLAGS);
}// switch
} // if VTABLE_isa
return VTABLE_get_integer(interp, key);
} // sub key_integer
[3]
/* [this desperately needs better abstraction, so we're not duplicating
the enum
* PObj_enum definition in the include/parrot/pobj.h file. -- rgr,
1-Mar-08.]
*/
static const char *flag_bit_names[] =
{
private0,
private1,
private2,
private3,
private4,
private5,
Re: [perl #52710] key.c and missing default in key_integer switch
On Thu, 10 Apr 2008 10:53:31 -0700
[EMAIL PROTECTED] (via RT)
[EMAIL PROTECTED] wrote:
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #52710]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=52710
Hey,
I *thought* I'd try and clean up an easy one, so I took
src/key.c
src/key.c: In function `key_integer':
src/key.c:368: warning: switch missing default case
After a little poking I tracked the rest of the Key__FLAG s down
to include/parrot/key.h (and pobj.h) [1] and so I rearrainged the
case stmt to cover them all (noting the TODO on slices, I separated
those), putting in the current default behavior for everything that
wasn't already covered and then adding a default branch w/ an
exception (taken from the next sub ... ). This broke iterator.t tests
and it appears to be due to a missing (?) flag value of '8' for
switch test switch (PObj_get_FLAGS(key) KEY_type_FLAGS) {
So ... either there's a missing KEY__FLAG or something. One hint
is in src/packdump.c [3] which would say the '8' is an 'is_string'
flag? I've not yet been able to track backwards (my debugging is
painfully slow w/ printf's and re-makes) to see who's calling w/ the
funny flag value but I thought I'd ask here to see if anybody had an
answer.
Thanks.
Hi,
Here's the code you posted in [2], in unified diff format, without the
C++-style comments and white space changes. It looks like your mail
client screwed up the white space, which made it pretty hard to
see what was changed... please read docs/submissions.pod when you have a
chance, the tips contained within make this kind of thing a lot easier.
Thanks!
Mark
Index: src/key.c
===
--- src/key.c (revision 26901)
+++ src/key.c (working copy)
@@ -322,7 +322,18 @@
return string_to_int(interp, s_reg);
}
/* TODO check for slice_FLAGs */
+case KEY_start_slice_FLAG:
+case KEY_end_slice_FLAG:
+case KEY_inf_slice_FLAG:
+return VTABLE_get_integer(interp, key);
+case KEY_number_FLAG:
+return VTABLE_get_integer(interp, key);
+default:
+real_exception(interp, NULL, INVALID_OPERATION,
+Key_integer %d %d %d not a valid flag!\n,
VTABLE_get_integer(interp,
+key), PObj_get_FLAGS(key), PObj_get_FLAGS(key)
KEY_type_FLAGS);
}
+
}
return VTABLE_get_integer(interp, key);
My specdoc (was Failure Notice)
Larry Wall larry-at-wall.org |Perl 6| wrote: Just so you don't think this is warnocked, I'm looking at it, and thinking about it. Thanks. I thought perhaps everyone filtered it out since it had a bad subject line. By and large it seems to be going the right direction, though I've naturally got a number of quibbles. Probably each quibble needs to be a separate thread though, since many of them will probably breed discussion. On a larger question, I'm wondering if it's time to slush/freeze the Synopses as historical documents and put all spec effort into the new form (presumably as a wiki that knows how to serialize into a document). I don't think we have the bandwidth to maintain multiple standard documents. Well, okay, *I* don't have the bandwidth... You might need to teach some of us how to write in Standardese, however. :) If we did set up a wiki, we could have some of the specific language lawyering discussions attached to the specchunk in question, which seems like a good idea to save wear and tear on our email clients, and to prevent recurring FAQs. We'll probably need to exercise a modicum of control over who gets to revise the spec. We also probably need to have a discussion of whether the current section outline is optimal, and if not, whether it needs fixing now or can be simply renegotiated via wiki. Larry I was contemplating that a Wiki or other hypertext format might alleviate the issue of outlining since it would not have to have a unique outline, but can refer to definitions and other concepts as it goes, and have multiple organizing pages of links. I'm having no problem re-arranging the outline as things suggest themselves, just by dragging. I agree that a hyperdocument would render that moot. Right now, since I have a productive period of full-time effort, I'd like to keep pouring stuff in myself. And work on standard language and terminology by posting threads like the current one on BEGIN etc. I'm really pulling on three straws at the same time: 1) copy every fact from the Synopses documents to the new outline. 2) flesh out things that are not explained well, have conflicts, etc. 3) state things in formal language. The synopses combine tutorial and specification. The spec doc should be specification, without explanation to a certain extent. For the casual reader, this renders it unfathomable. So I think explanation and discussion of a feature can be linked in as non-normative sections. As a hyperdocument, there are several kinds of pages (or content on one physical page): - the formal spec itself - explanation to give an approximate understanding of what the spec will say - rationale on why things were done a certain way - commentary and feedback of any other content - implementation notes for specific implementations These can be clearly differentiated by style, so explanation and formal spec could be mixed on a page much as literate programming mixes code and comments. Maybe we need to start identifying a documentation system that does what we need. I think I can teach standardeze by example once I get some worked in there. I never really thought about it; it just grows on you. It's more like programming than essaying, is how it feels. Vocabulary is important: use the correct term for the concept, watch your will, shall, etc. as that is the programming of the actual specification. --John
Re: [perl #52710] key.c and missing default in key_integer switch
On Thu, 10 Apr 2008 13:21:23 -0700 Mark Glines [EMAIL PROTECTED] wrote: } + } Okay, without *most* of the white space changes. Oh well, I tried. Mark
Re: Nomenclature Question - BEGIN etc.
On Apr 10, 2008, at 13:29 , John M. Dlugosz wrote: I might have misremembered, but i thought labels were followed by a colon in Perl 6. A quick scan of the docs... It is illegal for a provisional subroutine call to be followed by a colon postfix, since such a colon is allowed only on an indirect object, or a method call in dot form. (It is also allowed on a label when a statement is expected.) ... The last sentence there implies that a label can exist *without* a colon. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: Nomenclature Question - BEGIN etc.
On Thu, Apr 10, 2008 at 04:38:27PM -0400, Brandon S. Allbery KF8NH wrote: On Apr 10, 2008, at 13:29 , John M. Dlugosz wrote: I might have misremembered, but i thought labels were followed by a colon in Perl 6. A quick scan of the docs... It is illegal for a provisional subroutine call to be followed by a colon postfix, since such a colon is allowed only on an indirect object, or a method call in dot form. (It is also allowed on a label when a statement is expected.) ... The last sentence there implies that a label can exist *without* a colon. I think the intent there is to say that a label is only allowed at the start of a statement, not that a label can have a : left off. -ryan
Re: Nomenclature Question - BEGIN etc.
I've consolidated all the discussion into one reply: The perldocs call them Five specially named code blocks, The Camel names them individually (e.g. BEGIN block). How about phase blocks? They control in what phase of compilation/runtime the code runs in. I don't know, phase sounds too specific to me. Does the catching of an exception really bring us into a new phase of execution? What about the LAST time through a loop? etc. An exception is certainly a phase-change. Last time through a loop? Well, context anyway, if not phase, unless phase means stage in this instance. Hmm, I'm starting to talk like Larry. Bad John. Well, lessee. The Common Lisp spec calls them situations in the definition of (eval-when)... Good pointer, not just for the name candidate, but to look at another formal spec to help clear up details. If they've already been thought out, steal it. It looks like they already have a name in S04: Closure traits I don't know, it seems like any value might happen to both be a closure and have traits, which aren't necessarily these particular ones... My feeling exactly. As I read it, the original question was about the actual keyword - e.g. the word BEGIN - as distinct from the block it's attached to. Though I agree we need a general term for the latter, the name event block seems to imply that BEGIN et al are events, which might be ok or might cause confusion with more thoroughly event-driven programming models. Hmm, maybe control event blocks and control events, then... How about Control Closure then? syntactically speaking, http://svn.pugscode.org/pugs/src/perl6/STD.pm groups them in statement_control, just like 'if' and 'for'. semantically speaking, i don't have a clever or unique name for them, other than what larry has already come up with. It's a really good question ... But I pretty certain we should be using the term block here instead, ... people are already used to saying BEGIN block and such. And traits is also problematic; it says what they are, but not really what they do. ... So I think perhaps the best term for them might be something more like event blocks, blocks that are called if and when a particular event happens. That's a more user-oriented definition. OK, so people already want to say The BEGIN block. So the set of them are The XXX blocks where XXX is the collective name for those keywords. Beware of these words as they already convey meaning or connotation: event trait ... ? Perhaps the concept of phase/stage needs to be described in detail as well, in and of itself. Then the same term can be used. In C++ there are phases of translation (or is it stages?). We already refer to compile-time vs run-time, sometimes CHECK time etc. so we need a name for that semantic category. Cue the thesaurus... episode makes my short list. An incident in the course of a series of events... an incident within a narrative usually fully developed and either integrated within the main story or digressing from it. An intermediate or digressive passage. A portion of a narrative that relates an event or a series of connected events and forms a coherent story in itself. A passage between statements of a main subject or theme, as in a rondo or fugue. Those all have allegories with the work of the Perl implementation. CATCH relates an event and forms a coherent story in itself. BEGIN, CHECK, INIT etc may be portions of the overall series of events, or chapters if you will. But a block that is written among the lines of the main code but put elsewhere for execution is a passage between statements of a main subject. exigency is interesting, but hang on to that for exception handling and continuations. --John
[perl #52718] [BUG] pge - optable parsing from Perl6Grammar doesn't honor ws rule
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #52718] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=52718 When using Perl6Grammar to build parsers (e.g., as part of PCT), the is optable trait used to attach a rule to an operator precedence parser doesn't inherit any custom ws rule. Should be an easy fix, but just needed to record this in RT so I don't forget it. Pm
Re: Nomenclature Question - BEGIN etc.
On Thu, Apr 10, 2008 at 03:41:19PM -0500, John M. Dlugosz wrote:
I've consolidated all the discussion into one reply:
The perldocs call them Five specially named code blocks, The Camel
names them individually (e.g. BEGIN block). How about phase blocks? They
control in what phase of compilation/runtime the code runs in.
I don't know, phase sounds too specific to me. Does the catching of
an exception really bring us into a new phase of execution? What about
the LAST time through a loop? etc.
An exception is certainly a phase-change. Last time through a loop? Well,
context anyway, if not phase, unless phase means stage in this instance.
Hmm, I'm starting to talk like Larry. Bad John.
You're just going through a stage that I'm stuck in. :)
Well, lessee. The Common Lisp spec calls them situations in the
definition of (eval-when)...
That's not bad. Other languages call them ON blocks and such.
OK, so people already want to say The BEGIN block. So the set of them
are The XXX blocks where XXX is the collective name for those keywords.
Beware of these words as they already convey meaning or connotation:
event trait ... ?
Perhaps the concept of phase/stage needs to be described in detail as
well, in and of itself. Then the same term can be used.
In C++ there are phases of translation (or is it stages?). We already
refer to compile-time vs run-time, sometimes CHECK time etc. so we need a
name for that semantic category. Cue the thesaurus...
episode makes my short list. An incident in the course of a series of
events... an incident within a narrative usually fully developed and either
integrated within the main story or digressing from it. An intermediate or
digressive passage. A portion of a narrative that relates an event or a
series of connected events and forms a coherent story in itself. A passage
between statements of a main subject or theme, as in a rondo or fugue.
Those all have allegories with the work of the Perl implementation. CATCH
relates an event and forms a coherent story in itself. BEGIN, CHECK, INIT
etc may be portions of the overall series of events, or chapters if you
will. But a block that is written among the lines of the main code but put
elsewhere for execution is a passage between statements of a main
subject.
Not sure I like the stage/phase/chapter metaphor, really. Too static.
On the other hand, situation seems to convey more ad hoc-ness than
strictly necessary.
exigency is interesting, but hang on to that for exception handling and
continuations.
or contingency.
An offline correspondent offers:
event handler blocks
event handlers
handler blocks
handlers
Maybe FOO {} is a handler block, and FOO is just the handle
for the handler...10-4 good buddy?
Larry
Re: Nomenclature Question - BEGIN etc.
On Thu, Apr 10, 2008 at 5:00 PM, Larry Wall [EMAIL PROTECTED] wrote:
Well, lessee. The Common Lisp spec calls them situations in the
definition of (eval-when)...
That's not bad.
Oh, sure, ignore it when I first said it, but let John quote me and
allasudden it's notable.. :-)
An offline correspondent offers:
event handler blocks
event handlers
handler blocks
handlers
Maybe FOO {} is a handler block, and FOO is just the handle
for the handler...10-4 good buddy?
The handler idea is interesting. As a sort of self-countering
response to my earlier objection about event-orientedness, I note that
Applescript treats user-defined subroutines as just a special case of
event handlers, where the triggering event is a call to the routine.
So maybe talking about BEGIN and friends the same way is not so wacky.
I don't know about handle for the keyword, though. It's awfully
overloaded in programming. For instance, does Perl6 still have
FILEHANDLES?
Something keeps making me think of the {SG,H,X}ML terminology of
elements with tags. I don't think element fits here, but tag
for the keyword feels right to me. We could just call them tagged
blocks, but that's a syntactic description, which fails to convey
anything about the semantics.
So maybe event tags and event blocks, with the combination of the
two constituting an event handler?
Also: a CB reference? Really? (Y)our age is showing. :)
--
Mark J. Reed [EMAIL PROTECTED]
[perl #52712] Build broken
Am in transit so cannot provide a complete analysis now. However, please look at line 40 of lib/Parrot/Manifest.pm. This line seems to exclude all file names containing the string 'ports'. While this correctly excludes ports of Parrot, it probably incorrectly excludes all source files with that string in their names. Andy D's command relies on MANIFEST to copy files to a new location. MANIFEST is made by tools/dev/mk_manifest_and_skip.pl, which in turn relies on Parrot::Manifest. When the t/steps/auto_macports*.t files fail to be copied to the new location, Parrot::Configure::Options::Test barfs because it cannot locate files corresponding to particular config steps. HTH kid51
Re: Nomenclature Question - BEGIN etc.
From: Larry Wall [EMAIL PROTECTED] Date: Thu, 10 Apr 2008 14:00:53 -0700 On Thu, Apr 10, 2008 at 03:41:19PM -0500, John M. Dlugosz wrote: Well, lessee. The Common Lisp spec calls them situations in the definition of (eval-when)... That's not bad. FWIW, eval-when only does BEGIN and INIT; CATCH, LEAVE, etc. are handled by other special forms. Other languages call them ON blocks and such. AFAIR, only languages that use ON as the keyword to introduce them. OK, so people already want to say The BEGIN block. So the set of them are The XXX blocks where XXX is the collective name for those keywords . . . Not sure I like the stage/phase/chapter metaphor, really. Too static. On the other hand, situation seems to convey more ad hoc-ness than strictly necessary. . . . Larry How about daemon blocks? That suggests to me that they are invoked as required, and not necessarily in synchrony with their containing blocks. -- Bob Rogers http://rgrjr.dyndns.org/
[perl #52720] [TODO] Update documentation of the compreg opcode
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #52720] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=52720 When removing Parrot/HLLCompiler for RT#48030 I noticed that the docs of 'comreg' did not match very well with reality. pmichaud elaborated on IRC: [22:17] barney Looks like the docs to 'compreg' is incomplete [22:19] Coke something in particular lacking? [22:20] barney Registering an object on which the method 'compile' will be called [22:20] Coke the opcode descriptions are shy. [22:20] pmichaud compreg is old [22:20] Coke barney: You can DO that? [22:20] Coke I thought it was just an invokable. [22:20] pmichaud compreg doesn't care what kind of object it's given [22:20] pmichaud it's basically a glorified hash [22:21] barney I need to do that, It complained when I wanted to register a Sub [22:21] pmichaud whatever you stick into it is what you get out [22:21] Coke pmichaud: the expectation, though, is that when you get something out of the hash, you can simply invoke it and pass in the source as a single string arg. [22:21] barney I see. Calling the method 'compile' then is just a convention ? [22:21] pmichaud coke: I think that's no longer true either [22:22] pmichaud nowadays we expect to have a compiler object with a 'compile' method [22:22] pmichaud but I don't think that's been officially specced in a PDD yet, except for... [22:22] Coke ... that's definitely not documented near the opcode. [22:22] Coke and is very likely not how tcl works. [22:23] Coke barney: opening a ticket would be good. The scope of this ticket, is that the docs are to be updated, so that they reflect the current state. Specifying an interface for compiler object is a different issue.
RE: Nomenclature Question - BEGIN etc.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark J. Reed Sent: Thursday, April 10, 2008 4:26 PM To: perl6-all@perl.org; [EMAIL PROTECTED] Subject: Re: Nomenclature Question - BEGIN etc. but tag for the keyword feels right to me. We could just call them tagged blocks, but that's a syntactic description, which fails to convey anything about the semantics. So maybe event tags and event blocks, with the combination of the two constituting an event handler? Perhaps event match block ? - Hugh Miller e-mail: [EMAIL PROTECTED]
(Not so) super
Hi, We have a couple of bits of OO stuff missing in Parrot. The callmethodsupercc op isn't implemented. I'm thinking for this we need a variant of find_method, which does the required skipping over the current class? We'll also need to work out how to do callmethodnextcc too, which is another find_method variant, I guess. It occurs to me that if we're doing a next method style thing, then we know what the last method was, and we can pass that as a resume from this point style thing, and if possible that can be optimized somehow later to do something better than the obvious going through the lookup process until we find the current method and then returning the one we find after that. Even with super implemented, this doesn't help me with a more immediate issue. I need to take a PMC, subclass it with a high level class, then override one of the v-table methods in PIR. All this I can do fine. But what I can't see how to do with what we currently have (neither spec'd nor implemented), is to invoke the super of the v-table method. For example, you might want to override assign_pmc to do some check on the value, and then call the original v-table method in the PMC we inherited from to actually stash the value being assigned somewhere. What should this look like at a PIR level? In fact, this last issue is the main one I'm blocking on at the moment. Thanks, Jonathan
Re: (Not so) super
On Thu, Apr 10, 2008 at 6:59 PM, Jonathan Worthington [EMAIL PROTECTED] wrote: Hi, We have a couple of bits of OO stuff missing in Parrot. The callmethodsupercc op isn't implemented. I'm thinking for this we need a variant of find_method, which does the required skipping over the current class? We'll also need to work out how to do callmethodnextcc too, which is another find_method variant, I guess. It occurs to me that if we're doing a next method style thing, then we know what the last method was, and we can pass that as a resume from this point style thing, and if possible that can be optimized somehow later to do something better than the obvious going through the lookup process until we find the current method and then returning the one we find after that. Even with super implemented, this doesn't help me with a more immediate issue. I need to take a PMC, subclass it with a high level class, then override one of the v-table methods in PIR. All this I can do fine. But what I can't see how to do with what we currently have (neither spec'd nor implemented), is to invoke the super of the v-table method. For example, you might want to override assign_pmc to do some check on the value, and then call the original v-table method in the PMC we inherited from to actually stash the value being assigned somewhere. What should this look like at a PIR level? In fact, this last issue is the main one I'm blocking on at the moment. I can't speak for *should*, but Tcl is doing this now: languages/tcl/src/class/tclconst.pir subclasses String, then overrides set_string_native. Once we're done with our string manipulation, we then invoke string's copy of the vtable to actually store the desired value: # Finally, delegate to our parent's set_string $P0 = getattribute self, ['String'], 'proxy' $P0 = value Thanks, Jonathan -- Will Coke Coleda
Re: [perl #52710] key.c and missing default in key_integer switch
Yeah, it wasn't really a patch as it doesn't work. It was more of a question 'does anybody know if it's a missing Key__FLAG or something else' that's bringing in the unexpected (I guess) switch case value. The code was for illustrative purposes, just tracking what I've found so far. Thanks for the diff though. a --- Andy Bach Systems Mangler Internet: [EMAIL PROTECTED] Voice: (608) 261-5738 Fax: 264-5932 The bureaucracy is expanding to meet the needs of an expanding bureaucracy.
[perl #52712] Build broken
On Thu Apr 10 14:16:58 2008, infinoid wrote: Oddly, adding config/auto/macports.pm to MANIFEST didn't help. It is copied, but I don't think this module is getting use'd, for whatever reason. What the heck? When I added t/steps/auto_macports-*.t to MANIFEST (in r26916), it started working. So, uh, fixed in r26916 and r26914. Though I have no idea why r26916 fixed it and r26914 didn't. Mark
Re: Nomenclature Question - BEGIN etc.
On Apr 10, 2008, at 18:58 , Bob Rogers wrote: From: Larry Wall [EMAIL PROTECTED] Date: Thu, 10 Apr 2008 14:00:53 -0700 On Thu, Apr 10, 2008 at 03:41:19PM -0500, John M. Dlugosz wrote: Well, lessee. The Common Lisp spec calls them situations in the definition of (eval-when)... That's not bad. FWIW, eval-when only does BEGIN and INIT; CATCH, LEAVE, etc. are handled by other special forms. On the other hand, that may be the answer right there: when-blocks. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
episodes of execution
See my latest, in section 4.2, for a first cut on episodes. I took a first stab at formalizing all phases of translation and execution, and documented what was known about the episodes I knew about, especially those corresponding to keywords that introduce an episodic block (as a generalization of BEGIN block, etc. That also makes the term non-episodic block for a normal statement a perfect legaleeze example) Just this section: http://www.dlugosz.com/files/2.pdf and the full files (specdoc.pdf and .odt) have also been updated. --John
Re: failure notice
It will always be too early, and too late. There will always be reasons not to do it till next year, and reasons you're hosed because it wasn't done years ago. Now is all we've got at the moment... Larry That's how C++ was. The call to ANSI was hot on the heels of a statement saying it was not time to standardize yet! But the ANSI/ISO committee actually because a language design, not a standardization/documentation effort at all. Very unusual in that it invented most of what it set down. It also took 10 years. --John
Re: [perl #52712] Build broken
On Thu, 10 Apr 2008, Mark Glines via RT wrote: On Thu Apr 10 14:16:58 2008, infinoid wrote: Oddly, adding config/auto/macports.pm to MANIFEST didn't help. It is copied, but I don't think this module is getting use'd, for whatever reason. What the heck? When I added t/steps/auto_macports-*.t to MANIFEST (in r26916), it started working. Yes. The fact that lib/Parrot/Configure/Step.pm lists auto::macports implicity *assumes* that there will be corresponding tests in t/steps/auto_macports-*.t, and if there aren't, Configure bails out with a fatal error during build time. This is just really strange. For example, it makes it more difficult to develop a new step because you can't even begin to develop the new step unless you already have the tests in place. So, uh, fixed in r26916 and r26914. Though I have no idea why r26916 fixed it and r26914 didn't. Well, adding those tests works around the design oddity, but I wouldn't really call it fixed. -- Andy Dougherty [EMAIL PROTECTED]
Re: Nomenclature Question - BEGIN etc.
Brandon S. Allbery KF8NH skribis 2008-04-10 19:41 (-0400):
On the other hand, that may be the answer right there: when-blocks.
No, this is a when block:
when /foo/ { ... }
:)
--
Met vriendelijke groet, Kind regards, Korajn salutojn,
Juerd Waalboer: Perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
Convolution: ICT solutions and consultancy [EMAIL PROTECTED]
Re: Nomenclature Question - BEGIN etc.
On Thu, Apr 10, 2008 at 7:41 PM, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: On the other hand, that may be the answer right there: when-blocks. We have those already: given...when. -- Mark J. Reed [EMAIL PROTECTED]
Re: Nomenclature Question - BEGIN etc.
My suggestion: consequential blocks -- Met vriendelijke groet, Kind regards, Korajn salutojn, Juerd Waalboer: Perl hacker [EMAIL PROTECTED] http://juerd.nl/sig Convolution: ICT solutions and consultancy [EMAIL PROTECTED]
Re: Nomenclature Question - BEGIN etc.
On Thu, Apr 10, 2008 at 8:49 PM, Juerd Waalboer [EMAIL PROTECTED] wrote: My suggestion: consequential blocks ...which would make other blocks inconsequential? Nuh-uh. -- Mark J. Reed [EMAIL PROTECTED]
[perl #52680] [BUG]: 'make' failure on Linux; possibly TGE-related
And I'm getting somewhat similar failure on Darwin RT 52726
Re: [svn:parrot] r26920 - trunk/src/pmc
On Thu, Apr 10, 2008 at 05:53:10PM -0700, [EMAIL PROTECTED] wrote: Author: chromatic Date: Thu Apr 10 17:53:10 2008 New Revision: 26920 [OO] Optimized isa() vtable entry for Class. Instead of delegating most of its work to isa_pmc(), this entry now performs its work directly. This is slightly faster and avoids creating a temporary PMC. The Perl 6 build process is now 19.78% faster with this patch, and all tests still pass. I'm guessing slightly faster here was meant as humorous understatement... A nearly 20% improvement in _overall_ build time?!? I'm a little curious as to _why_ updating isa() for Class makes such a big difference -- what is (or was) calling isa() so frequently on a Class object? Pm
Re: [svn:parrot] r26920 - trunk/src/pmc
On Thursday 10 April 2008 18:35:00 Patrick R. Michaud wrote: [OO] Optimized isa() vtable entry for Class. Instead of delegating most of its work to isa_pmc(), this entry now performs its work directly. This is slightly faster and avoids creating a temporary PMC. The Perl 6 build process is now 19.78% faster with this patch, and all tests still pass. I'm guessing slightly faster here was meant as humorous understatement... A nearly 20% improvement in _overall_ build time?!? It's only the NQP - PIR generation that I can prove is 20% faster. The rest of it is probably faster. I'm a little curious as to _why_ updating isa() for Class makes such a big difference -- what is (or was) calling isa() so frequently on a Class object? I think it's everything that called isa on a Class or Object. It wasn't so much the frequency of the calls, but that every call allocated a temporary PMC that almost immediately went unused. Allocating fewer unnecessary PMCs in hot paths dramatically improves our performance at the moment. A better GC will help, but it's still a good practice. -- c
[perl #52680] [BUG]: 'make' failure on Linux; possibly TGE-related
On Thu Apr 10 18:17:17 2008, [EMAIL PROTECTED] wrote: And I'm getting somewhat similar failure on Darwin RT 52726 r26910 introduced a bug into PGE's build process -- PGE suddenly depended on PCT, but PCT was being built after PGE. This is fixed in r26918, and reportedly solves the remaining issue that jkeen was seeing in r26917. Re-closing ticket, Pm
[perl #52706] [BUG]: t/dynpmc/gdbmhash.t hanging on Darwin
I hypothesized that this problem -- which is continuing as of r26920
(Apr 10) -- originated in a recent change to a GDBM-related file within
the Parrot distribution.
[parrot] 530 $ find . ! -path '*/.svn*' -iname '*gdbm*' | xargs svn
status -v
2692026101 particle config/auto/gdbm
2692026101 particle config/auto/gdbm/gdbm.in
2692026101 particle config/auto/gdbm/gdbm.in
2692026790 fperrad config/auto/gdbm.pm
? gdbm_hash_1
I
runtime/parrot/dynext/gdbmhash.bundle
I src/dynpmc/gdbmhash.bundle
I src/dynpmc/gdbmhash.c
I src/dynpmc/gdbmhash.dump
I src/dynpmc/gdbmhash.o
2692026647 chromaticsrc/dynpmc/gdbmhash.pmc
So I started with the most recent change: r26790 change to
config/auto/gdbm.pm.
$ svn diff -r 24769:26790 config/auto/gdbm.pm
See attached for the diff.
Note these lines:
-else {
-eval { $conf-cc_build( '', '-lgdbm' ); };
-}
+eval { $conf-cc_build(); };
In the prior revision, a non-Win32 OS explicitly had '-lgdbm' added to
its flags. But in the later revision, this flag goes missing.
It's too late for me to test this out tonight, i.e., to see what happens
if I revert or modify auto::gdbm. François, could you take a look at
this please?
Thank you very much.
kid51
Index: config/auto/gdbm.pm
===
--- config/auto/gdbm.pm (revision 24769)
+++ config/auto/gdbm.pm (revision 26790)
@@ -61,18 +61,10 @@
# Fink location.
$self-_handle_darwin_for_fink($conf, $osname, 'gdbm.h');
+_handle_mswin32($conf, $osname, $cc);
+
$conf-cc_gen('config/auto/gdbm/gdbm.in');
-if ( $osname =~ /mswin32/i ) {
-if ( $cc =~ /^gcc/i ) {
-eval { $conf-cc_build( '', '-llibgdbm' ); };
-}
-else {
-eval { $conf-cc_build( '', 'gdbm.lib' ); };
-}
-}
-else {
-eval { $conf-cc_build( '', '-lgdbm' ); };
-}
+eval { $conf-cc_build(); };
my $has_gdbm = 0;
if ( !$@ ) {
my $test = $conf-cc_run();
@@ -88,6 +80,22 @@
return 1;
}
+sub _handle_mswin32 {
+my ($conf, $osname, $cc) = @_;
+if ( $osname =~ /mswin32/i ) {
+if ( $cc =~ /^gcc/i ) {
+$conf-data-add( ' ', libs = '-lgdbm.dll' );
+}
+else {
+$conf-data-add( ' ', libs = 'libgdbm.lib' );
+}
+}
+else {
+$conf-data-add( ' ', libs = '-lgdbm' );
+}
+return 1;
+}
+
sub _evaluate_cc_run {
my $self = shift;
my ($test, $has_gdbm, $verbose) = @_;
[svn:parrot-pdd] r26921 - in trunk: compilers/pct/src/PAST docs/pdds
Author: pmichaud Date: Thu Apr 10 19:28:40 2008 New Revision: 26921 Modified: trunk/docs/pdds/pdd26_ast.pod Changes in other areas also in this revision: Modified: trunk/compilers/pct/src/PAST/Node.pir Log: [pct]: * Add symbol_defaults method to PAST::Block, to simply setting default 'scope' attribute for PAST::Var nodes. Modified: trunk/docs/pdds/pdd26_ast.pod == --- trunk/docs/pdds/pdd26_ast.pod (original) +++ trunk/docs/pdds/pdd26_ast.pod Thu Apr 10 19:28:40 2008 @@ -486,6 +486,14 @@ typically used to provide the Cscope attribute for any nested CPAST::Var nodes that do not provide an explicit Cscope attribute. +=item symbol_defaults([attr1 = val1, attr2 = val2, ...]) + +Sets default attributes for symbols that aren't explicitly +given by the Csymbol method above. For example, an abstract +syntax tree can use this method on a top-level CPAST::Block +to specify the Cscope attribute to be used for all +variable nodes that don't otherwise provide one. + =item pir_pragma([value]) Get/set any PIR pragmas to be used when generating the block.
syntax question on parameter lists
S06 shows how to define named-only parameters, marked with a prefix :. But no example shows anything more than a bare parameter name. No type is ever given! Looking through my copy of STD.pm, I'm baffled, as it seems not to take types in parameter lists at all. So, is it method bytes ( Encoding :$encoding ) returns Int or method bytes ( : Encoding $encoding ) returns Int ? I'm guessing that the latter would be confused with use of : after the invocant, and it follows that method bytes (Encoding :encoding($override_encoding)) returns Int would work.
[perl #52706] [BUG]: t/dynpmc/gdbmhash.t hanging on Darwin
I have confirmed that this problem developed in r26790 or later. t/dynpmc/gdbmhash.t was running properly as of 26789: /usr/bin/g++ -o pbc_merge \ src/pbc_merge.o \ src/parrot_config.o \ src/string_primitives.o \ -L/Users/jimk/work/parrot/26789/blib/lib -L/Users/jimk/work/parrot/26789/blib/lib -lparrot -lm -lgmp -lreadline -lcrypto -undefined dynamic_lookup -L/sw/lib t/dynpmc/gdbmhash.. 1..13 ok 1 - typeof ok 2 - check whether interface is done ok 3 - get_integer ok 4 - get_bool ok 5 - modify an entry ok 6 - exists_keyed ok 7 - set STRING with STRING key ok 8 - set STRING with a PMC key ok 9 - set PMC with STRING key ok 10 - set PMC with a PMC key ok 11 - set INTVAL with STRING key ok 12 - set FLOATVAL with a PMC key ok 13 - delete_keyed ok All tests successful. Files=1, Tests=13, 4 wallclock secs ( 0.04 usr 0.02 sys + 1.01 cusr 0.76 csys = 1.83 CPU) Result: PASS
default parameters in methods
It is not specified in the Synopses as I recall, but I believe that this is useful enough that it must be made to work: method bytes (Encoding :$encoding = .encoding) returns Int or even method bytes (Encoding :$encoding = self!encoding) returns Int That is, a named-only parameter, which may be used as an optional adverb or extra parameter to affect details of the function, should default to a pre-set value inside the instance. If this is not allowed, the beginning of the method would always have to check for defaults. That should be automatic. And it documents the situation nicely in the signature, without further explanation that if the parameter is not supplied... This means that the default arguments run inside the context of the method call, and can do anything that you would expect from their lexical position. --John
Re: syntax question on parameter lists
On Fri, Apr 11, 2008 at 03:26:02AM -, John M. Dlugosz wrote: : S06 shows how to define named-only parameters, marked with a prefix :. But no example shows anything more than a bare parameter name. No type is ever given! : : Looking through my copy of STD.pm, I'm baffled, as it seems not to take types in parameter lists at all. It's at the top of token parameter where there is a type_constraint*. : So, is it : method bytes ( Encoding :$encoding ) returns Int : : or : : method bytes ( : Encoding $encoding ) returns Int : : ? : : I'm guessing that the latter would be confused with use of : after the invocant, and it follows that : : method bytes (Encoding :encoding($override_encoding)) returns Int : : would work. Indeed. Larry
Re: default parameters in methods
On Fri, Apr 11, 2008 at 03:35:37AM -, John M. Dlugosz wrote: : It is not specified in the Synopses as I recall, but I believe that this is useful enough that it must be made to work: : :method bytes (Encoding :$encoding = .encoding) :returns Int : : or even : :method bytes (Encoding :$encoding = self!encoding) :returns Int : : That is, a named-only parameter, which may be used as an optional adverb or extra parameter to affect details of the function, should default to a pre-set value inside the instance. : : If this is not allowed, the beginning of the method would always have to check for defaults. That should be automatic. And it documents the situation nicely in the signature, without further explanation that if the parameter is not supplied... : : This means that the default arguments run inside the context of the method call, and can do anything that you would expect from their lexical position. All default expressions to any parameter are defined to run in the context that assumes any parameters to their left are already bound, so you may safely depend on self already being set. Larry
PCT tutorial update suggestions
With some recent PCT-related changes I think we may want to
update the tutorials a bit.
1. Remove the custom List class.
ResizablePMCArray now has built-in shift/unshift/push/pop
methods, so we can use it directly from NQP and don't need
to create a custom List class to be able to invoke these
operations.
2. Remove :scope attribute from PAST::Var nodes.
My intent has been that most PAST::Var nodes for simple variables
would not require individual scope attributes; with the changes
I checked into Parrot tonight this should be easier. In Squaak's
case this means that the Cidentifier action method should now
read:
method identifier($/) {
make PAST::Var.new( :name($name),
:viviself('Undef'),
:node($/) );
}
In particular, note that there's no longer a need to
explicitly search outer blocks for the scope -- PCT
will handle this automatically.
To indicate that all undeclared variables should default
to 'package' scope, we use the Csymbol_defaults method on
the top-level block. For Squaak, we add the following to its
TOP action method:
$?BLOCK.symbol_defaults(:scope('package'));
This says that 'package' scope is to be used for any PAST::Var
node that doesn't have its own :scope and that doesn't have a
scope provided by an outer block's symbol hash.
3. (Bonus problem) Eliminate @?BLOCK
Since PAST::Var nodes no longer need to search outer blocks
(PCT will handle that), we no longer need to maintain a @?BLOCK
array. So, for bonus points, eliminate @?BLOCK from the Squaak
methods.
If I can help explain or demonstrate any of the above, let me know.
Thanks!
Pm
Re: syntax question on parameter lists
On Thu, Apr 10, 2008 at 09:18:38PM -0700, Larry Wall wrote: On Fri, Apr 11, 2008 at 03:26:02AM -, John M. Dlugosz wrote: : S06 shows how to define named-only parameters, marked with a prefix :. But no example shows anything more than a bare parameter name. No type is ever given! : : Looking through my copy of STD.pm, I'm baffled, as it seems not to take types in parameter lists at all. It's at the top of token parameter where there is a type_constraint*. Yes, but where does type_constraint resolve down to a typename? My reading of STD.pm is that type_constraint becomes a value (since it's not a 'where' clause in this case), and value is currently one of quote, number, or version. Pm
Re: [perl #52720] [TODO] Update documentation of the compreg opcode
On Thu, Apr 10, 2008 at 02:02:37PM -0700, Bernhard Schmalhofer wrote: When removing Parrot/HLLCompiler for RT#48030 I noticed that the docs of 'comreg' did not match very well with reality. pmichaud elaborated on IRC: [...] See also the thread on this topic at [1]. Essentially a decision was made in November 2006 that Ccompreg would return compiler objects and that compilation would be done via a method call, but this has yet to be recorded in a PDD. For now I propose that we address the ticket by changing the docs to read: =item Bcompreg(out PMC, in STR) Get the compiler object for source type $2. The returned compiler object should provide a Ccompile method for translating code in the source type. However, some Parrot compilers such as CPIR and CPASM currently return a sub that is to be invoked directly on the source. =item Bcompreg(in STR, invar PMC) Register $2 as the compiler object for source type $1. A patch is attached making this change. Pm 1. http://groups.google.com/group/perl.perl6.internals/browse_thread/thread/9c58722a98f731b3
Re: [perl #52720] [TODO] Update documentation of the compreg opcode
On Thu, Apr 10, 2008 at 11:53:00PM -0500, Patrick R. Michaud wrote: A patch is attached making this change. Attaching patch. Pm Index: src/ops/core.ops === --- src/ops/core.ops(revision 26926) +++ src/ops/core.ops(working copy) @@ -1270,12 +1270,15 @@ =item Bcompreg(out PMC, in STR) -Get a compiler for source type $2. +Get the compiler object for source type $2. The returned compiler +object should provide a Ccompile method for translating code +in the source type. However, some Parrot compilers such as +CPIR and CPASM currently return a sub that is to be +invoked directly on the source. =item Bcompreg(in STR, invar PMC) -Register the sub $2 as a compiler for source type $1. -$2 is either a NCI PMC with signature CpIt or a PASM Sub. +Register $2 as the compiler object for source type $1. =item Bnew_callback(out PMC, invar PMC, invar PMC, in STR)
