Re: [PIR] Macro layer: an overview document
On Oct 23, 2007, at 5:45 PM, Allison Randal wrote: Klaas-Jan Stol wrote: Hi, attached a document describing the current macro layer of IMCC. On the proposed modifications to macros, I have reservations on the automatic munging of .local variable names. Macros are simple parameterized substitutions. If someone includes a '.local' in a macro, it's likely that they'll expect it to appear literally in the body: .macro declare_my_locals(x) .local int $x .endm .sub bar .declare_my_locals(foo) foo = 5 print foo ... .end I believe tcl actually uses a macro to define an entire sub. It's a little weird but it works and is useful. Some things in macros exist but aren't specced, but forbidding them would likely cause more code in the compiler. A call to a macro can easily cover more than one line. That's counter-intuitive to the nature of PIR but it works and can be clean, take a look at examples/shootout/nbody.pir. Something like this could be useful, especially with array initialization which often uses a lot of lines. .macro Foo (a, b) .local int .a .a = .b .endm .sub main :main .Foo(b, 1) print b print \n .Foo(c, 2) print c print \n .end And unlikely that they'll want it to appear munged for a particular macro name: .sub bar .declare_my_locals(foo) local_declare_my_locals_foo = 5 print local_declare_my_locals_foo ... .end Those aren't meant to be accessed outside the macro. And imcc adds a number to it to make it hard to guess and there's no incentive to do that. If someone needs a certain functionality, they can write a macro that will allow them to use that variable. Looking at runtime/parrot/include/hllmacros.pir might show you some of the potential uses for macros. They're rarely used, but they're available. Comments? Allison
Re: Dynamic variable scoping
Bob Rogers wrote: All I am talking about is the equivalent of what local $var provides for Perl 5, i.e. dynamically-scoped binding of scalar package variables. Perl 5 locals and Perl 6 temps are quite different than Lisp special variables. I don't immediately see a way to explain this any more clearly than I explained it last time. If the problem is simply implement Common Lisp special variables, then the most likely solution is to create a LispSpecialVar PMC. In the same way that a MultiSub acts like a sub but internally stores a list of subs, the LispSpecialVar would act like an ordinary variable to Parrot internals and to all other languages, but would internally store a stack of previous dynamic bindings. How would continuations capture dynamic bindings, then? What information do the continuations need to capture? i.e. what do they need to restore when invoked? In general, continuations capture globals, but don't capture the values of the globals. Invoking a continuation doesn't restore the value of a global. How would stack-unwinding know which dynamic bindings to unmake? A LET has a scope (a beginning and an end), so you generate the binding code at the beginning and the corresponding unbinding code at the end. Allison
Re: [PIR] Macro layer: an overview document
Joshua Isom wrote: .sub bar .declare_my_locals(foo) local_declare_my_locals_foo = 5 print local_declare_my_locals_foo ... .end Those aren't meant to be accessed outside the macro. And imcc adds a number to it to make it hard to guess and there's no incentive to do that. The problem is, there are equally many good uses of macros that depend on setting up .locals that *are* used outside the macro. So, if we use the name '.local' for the auto munging feature, we're shooting ourselves just as badly as the current use of '.local' to make a unique label inside macros. Allison
Re: [PIR] Macro layer: an overview document
jerry gay wrote: yes, '.local' in a macro should mean the same thing as '.local' in pir. You've got it exactly. to confuse the matter further, '.local' in a macro currently means create a unique label. kjs's proposal changes that to '.label' local in pir and macro language means create a local named variable With no munging, agreed. '.local' is essentially ignored by the macro processor, and allowed to pass through unchanged to the resulting PIR code. label in pir and macro language means create a label Do you mean something like: .sub bar .label loop_start .label loop_end $I0 = 0 .loop_start: if $I0 = 3 goto .loop_end print $I0 print \n inc $I0 goto .loop_start .loop_end: .end I can totally see the benefit of unique label generation in macros, but not so much in straight PIR code. Can you think of a code example to illustrate? macro_local in macro language means create a local uniquely named variable each time the macro is run macro_label in macro language means create a uniquely named label each time the macro is run i'm not married to the name 'macro_', however the semantics are an important macro language feature that we're currently missing. Agreed with both, and the 'macro_' naming has the advantage of making it immediately clear that the features belong to macros. Allison
Re: [svn:parrot-pdd] r22428 - trunk/docs/pdds/draft
Hi, I had a look at the revision of pdd19, it reads much better than the first document. I do have some comments, besides the reply I gave earlier (but I later realized I didn't do reply-all). 1. line 96 talks about the data types int, string, pmc and float. I thought the word float was a bit overloaded because it implies a certain standard (IEEE 731 or so? I forgot) about precision. Wasn't the word num standard? 2.a line 246, about .globalconstant, doesn't specify when the global is initialized. Is that when the sub in which it is declared is executed/compiled/loaded? Or at startup? 2.b is the .constant directive from pasm mode (which is in the macro layer) removed? This implies that this is no longer possible: .constant hi Hello World .sub main say .hi # the parser sees Hello World .end 3. line 329. It doesn't say anything about quoted names, does this imply they are removed? So, writing .sub 'new' is no longer allowed? I also saw that local identifiers can be names of parrot ops. Then, the same would be true I assume for .params/.lexicals? And possibly sub-names and labels (as sub-names are just labels)? 4. line 384. The flag :named() is missing (in several places). Is this a mistake? 5. line 491. If branch label is covered by a goto label statement, and goto is considered more human readable, why don't we rename the branch op to goto? In that case, it's 1 less thing to map from PIR to PASM and the PASM becomes more human readable too. regards, kjs On 10/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: allison Date: Tue Oct 23 13:39:33 2007 New Revision: 22428 Modified: trunk/docs/pdds/draft/pdd19_pir.pod Log: [pdd] Some basic structural shaping on PIR PDD, and answering some of the review points. Modified: trunk/docs/pdds/draft/pdd19_pir.pod == --- trunk/docs/pdds/draft/pdd19_pir.pod (original) +++ trunk/docs/pdds/draft/pdd19_pir.pod Tue Oct 23 13:39:33 2007 @@ -6,6 +6,9 @@ =head1 ABSTRACT +This document is outlines the architecture and core syntax of the Parrot +Intermediate Representation (PIR). + This document describes PIR, a stable, middle-level language for both compiler and human to target on. @@ -15,105 +18,110 @@ =head1 DESCRIPTION -This document is the Parrot Design Document for the Parrot Intermediate -Representation (PIR). - -=head1 Comments and empty lines - -Comments start with B# and last until the following newline. These -and empty lines are ignored. +PIR is a stable, middle-level language intended both as a target for the +generated output from high-level language compilers, and for human use +developing core features and extensions for Parrot. -PIR allows POD blocks. +=head2 Basic Syntax -=head1 Statements +A valid PIR program consists of a sequence of statements, directives, comments +and empty lines. -A valid PIR program consists of a sequence of Istatements. A -Istatement is terminated by a newline (NL). So, each statement has to be -on its own line. +=head3 Identifiers -=head2 General statement format - -Any statement can start with a optional label and is terminated by a -newline: - - [label:] [instruction] NL - -=head2 Labels - -PIR code has both local and global labels. Global labels start with an -underscore, local labels shouldn't. Optional label for the given -instruction, can stand on its own line. A label must conform to the syntax -of Bidentifier described below. - -The name of a global label has to be unique, since it can be called at any -point in the program. A local label is accessible only in the compilation -unit where it's defined. A local label name must be unique within a -compilation unit, but it can be reused in other compilation units. +Identifiers start with a letter or underscore, then may contain additionally +letters, digits, and underscores. Identifiers don't have any limit on length at +the moment, but some sane-but-generous length limit may be imposed in the +future (256 chars, 1024 chars?). The following examples are all valid +identifiers. -Examples: +a +_a +A42 - branch L1 # local label - bsr_L2 # global label +Opcode names are not reserved words in PIR, and may be used as variable names. +For example, you can define a local variable named Cprint. [See #24251.] -=head1 INSTRUCTIONS +NOTE: The use of C:: in identifiers is deprecated. -=head2 Terms used here +=head3 Comments -=over 4 +Comments start with C# and last until the following newline. PIR also allows +comments in Pod format. Comments, Pod content, and empty lines are ignored. -=item identifier +=head3 Statements -Identifiers start with a letter or underscore, then may contain additionally -letters, digits, underscores and B::. Identifiers don't have any limit on -length. +A Istatement starts with an optional label, contains an instruction (a Parrot
[perl #43340] [TODO] config/inter/shlibs.pm: Write unit tests
With tests t/configure/117-inter_shlibs-01.t and 02.t committed to trunk last night, test coverage for this package is now 100% in all relevant categories. Ticket is resolved.
Re: [PATCH] Exceptions
Kevin Tew wrote: exceptions_ops.diff adds some simple ops needed for PDD compliance. exceptions.diff attempts to change all instances of clear_eh to pop_eh. Looks good. The exception handler stack introspection interface you added to the PDD is solid. The stack will be replaced by the concurrency scheduler in a few months, but we can preserve this same introspection interface. Let's go with 'eh_count' rather than 'eh_stack_depth', since it won't be a stack. Go ahead and apply. Thanks! Allison
Re: [PATCH] Exceptions
On 10/24/07, Allison Randal [EMAIL PROTECTED] wrote: Kevin Tew wrote: exceptions_ops.diff adds some simple ops needed for PDD compliance. exceptions.diff attempts to change all instances of clear_eh to pop_eh. Looks good. The exception handler stack introspection interface you added to the PDD is solid. The stack will be replaced by the concurrency scheduler in a few months, but we can preserve this same introspection interface. Let's go with 'eh_count' rather than 'eh_stack_depth', since it won't be a stack. Go ahead and apply. there are a few typos and pod nits that can be easily fixed before or after this is applied. i'd prefer 'count_eh', to match every other exception handler related op that has an '_eh' suffix. seems silly to have just one with a 'eh_' prefix. also, i'd suggest 'get_all_eh' rather than 'get_ehs', both to make it more visually distinct from 'get_eh' and also to make it match the '_eh' suffix of the other ops. ~jerry
Re: [PATCH] Exceptions
jerry gay wrote: i'd prefer 'count_eh', to match every other exception handler related op that has an '_eh' suffix. seems silly to have just one with a 'eh_' prefix. 'count_eh' isn't distinctive enough. Another possibility is not to provide an opcode for the number of exception handlers, since it's a relatively uncommon operation, and leave that as an 'inspect' option on the concurrency scheduler. Probably the most common use of 'eh_count' would be to find the number of elements in the array of exception handlers returned by 'get_all_eh' before performing some operation on it, in which case calling the elements vtable function on the array is good enough. also, i'd suggest 'get_all_eh' rather than 'get_ehs', both to make it more visually distinct from 'get_eh' and also to make it match the '_eh' suffix of the other ops. +1 Allison
[perl #46783] [TODO] [Perl] Use temporary files in smartlinks tests
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46783] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46783 In t/tools/smartlinks.t there are many todo items which say: # TODO: this should use a tempfile Implement using temporary files in these tests.
[perl #46785] [TODO] [Perl] Add more File-related tests to the smartlinks tests
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46785] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46785 In t/tools/smartlinks.t there is the todo item in the context of testing the CFile class functionality: # TODO: many more tests Improve the test coverage of this class
[perl #46787] [TODO] [Perl] Add tests of PodFile-tree to the smartlinks tests
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46787] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46787 In t/tools/smartlinks.t, within the context of testing the CPodFile class there is the todo item: # TODO: -tree Which means to test the Ctree method of the CPodFile class
[perl #46789] [TODO] [Perl] Add many more tests of SpecFiles-files to the smartlinks tests
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46789] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46789 In t/tools/smartlinks.t in the context of the CSpecFiles class there is the todo item: # TODO: many more -files tests Which means to say; add many more tests of the Cfiles method of this class.
[perl #46791] [TODO] [Perl] Add more tests of SpecFiles to the smartlinks tests
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46791] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46791 In t/tools/smartlinks.t in the context of the CTestFile class there is the todo item: # TODO: -tests, -smartlinks Which means to say to test the Ctests and Csmartlinks methods of this class, however it'd probably be a great idea to investigate the class more deeply and ensure that the test coverage is as high as possible.
[perl #46793] [TODO] [Perl] Add more tests of Test to the smartlinks tests
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46793] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46793 In t/tools/smartlinks.t there is the todo item: # TODO: Test Which means: test the CTest class thoroughly
[perl #46795] [TODO] [Perl] Add more tests of TestInfo to the smartlinks tests
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46795] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46795 In t/tools/smartlinks.t there is the todo item: # TODO: TestInfo Which means: test the CTestInfo class thoroughly
[perl #46797] [TODO] [Perl] Add more tests of SmartLinkServer to the smartlinks tests
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46797] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46797 In t/tools/smartlinks.t there is the todo item: # TODO: SmartLinkServer Which means: test the CSmartLinkServer class thoroughly
[perl #46801] [TODO] [Perl] Test tools/util/smartlinks.pl
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46801] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46801 In t/tools/smartlinks.t there is the todo item: # TODO: main After discussion with particle++ on #parrot I worked out that this means to test the tools/util/smartlinks.pl program.
[perl #46803] [TODO] [Perl] Improve the GC eagerness test in t/stm/basic.t
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46803] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46803 In t/stm/basic.t there is the todo item (in the context of the GC isn't too eager): # XXX is this test good enough? Which would imply that the test needs to be improved to fish out any potential GC issues.
[perl #46805] [TODO] [Perl] Add more list_* tests
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46805] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46805 In t/src/list.t there is the todo item: # TODO which says much in little i.e.: improve the test coverage of the list_* functionality.
[svn:parrot-pdd] r22457 - trunk/docs/pdds/draft
Author: allison
Date: Wed Oct 24 13:00:06 2007
New Revision: 22457
Modified:
trunk/docs/pdds/draft/pdd19_pir.pod
Log:
[pdd] Round of comments on PIR PDD from KJS.
Modified: trunk/docs/pdds/draft/pdd19_pir.pod
==
--- trunk/docs/pdds/draft/pdd19_pir.pod (original)
+++ trunk/docs/pdds/draft/pdd19_pir.pod Wed Oct 24 13:00:06 2007
@@ -93,7 +93,7 @@
.local pmc foo
-The type of a named variable can be Cint, Cfloat, Cstring or Cpmc,
+The type of a named variable can be Cint, Cnum, Cstring or Cpmc,
corresponding to the types of registers. No other types are used. [See
RT#42769]
@@ -326,13 +326,20 @@
{{ PROPOSAL: stop using integer constants for types RT#45453 }}
-=item .sub identifier [:flag ...]
+=item .sub
-Define a compilation unit with the label Iidentifier. All code in a
-PIR source file must be defined in a compilation unit. See
-LPIR Calling Conventions|imcc/calling_conventions for available flags.
-Optional flags are a list of Iflag, separated by empty spaces, and empty
-spaces only.
+ .sub identifier [:flag ...]
+ .sub quoted string [:flag ...]
+
+Define a compilation unit. All code in a PIR source file must be defined in a
+compilation unit. See LPIR Calling Conventions|imcc/calling_conventions for
+available flags. Optional flags are a list of Iflag, separated by empty
+spaces, and empty spaces only.
+
+The name of the sub may be either a bare identifier or a single- or
+double-quoted string. Bare identifiers must be valid PIR identifiers (see
+LIdentifiers above), but string sub names can contain any characters,
+including characters from different character sets (see LConstants above).
{{ NOTE: the optional comma in the flag list is deprecated RT#45697 }}
@@ -344,12 +351,12 @@
=item .emit
-Define a Icompilation unit containing PASM code. Always paired with
+Define a compilation unit containing PASM code. Always paired with
C.eom.
=item .eom
-End a Icompilation unit containing PASM code. Always paired with
+End a compilation unit containing PASM code. Always paired with
C.emit.
=item .pcc_*
@@ -381,7 +388,7 @@
At the top of a subroutine, declare a local variable, in the manner
of C.local, into which parameter(s) of the current subroutine should
be stored. Available flags:
-C:slurpy, C:optional, C:opt_flag and C:unique_reg.
+C:slurpy, C:named, C:optional, C:opt_flag and C:unique_reg.
=item .param type identifier = identifier [:flag]*
@@ -394,7 +401,7 @@
Between C.pcc_begin_return and C.pcc_end_return, specify one or
more of the return value(s) of the current subroutine. Available
flags:
-C:flat.
+C:flat, C:named.
=back
@@ -405,13 +412,13 @@
=item .arg var [:flag ...]
Between C.pcc_begin and C.pcc_call, specify an argument to be
-passed. Available flags: C:flat.
+passed. Available flags: C:flat, C:named.
=item .result var [:flag ...]
Between C.pcc_call and C.pcc_end, specify where one or more return
value(s) should be stored. Available flags:
-C:slurpy, C:optional, and C:opt_flag.
+C:slurpy, C:named, C:optional, and C:opt_flag.
=back
Re: [svn:parrot-pdd] r22428 - trunk/docs/pdds/draft
Klaas-Jan Stol wrote: 1. line 96 talks about the data types int, string, pmc and float. [...] Wasn't the word num standard? Yup, good catch. Probably crept in during the original edit down to just 4 types from the earlier long list. 2.a line 246, about .globalconstant, doesn't specify when the global is initialized. Is that when the sub in which it is declared is executed/compiled/loaded? Or at startup? 2.b is the .constant directive from pasm mode (which is in the macro layer) removed? This implies that this is no longer possible: .constant hi Hello World .sub main say .hi # the parser sees Hello World .end This isn't going away, and will be allowed in PIR. I'm inclined to say that PIR's old '.const' should change to .local type name :constant and that '.globalconst' can simply be deprecated. (It's only used in the repository for string and int constants, which would be cheaper as a macro-style substitution anyway.) 3. line 329. It doesn't say anything about quoted names, does this imply they are removed? So, writing .sub 'new' is no longer allowed? I also saw that local identifiers can be names of parrot ops. Then, the same would be true I assume for .params/.lexicals? And possibly sub-names and labels (as sub-names are just labels)? Comment on quoted sub names added. Sub names aren't just labels, they're also stored in the namespace. Labels are still required to conform to the standard for Parrot identifiers. 4. line 384. The flag :named() is missing (in several places). Is this a mistake? Added. (Probably need to make a full consistency pass between pdd03 and the PIR PDD.) 5. line 491. If branch label is covered by a goto label statement, and goto is considered more human readable, why don't we rename the branch op to goto? In that case, it's 1 less thing to map from PIR to PASM and the PASM becomes more human readable too. At the PASM level (a plain English translation of the bytecode), 'branch' makes sense, as it's paired with 'jump'. A branch goes to an offset from the current instruction, while a jump goes to a fixed address. At the PIR level 'goto' is an abstraction that currently happens to directly map to 'branch'. It won't necessarily always be a direct mapping. In fact, branch points are prime candidates for optimizations (inlining, etc), so it's highly likely that 'goto' won't always be a direct mapping to 'branch'. Allison
[perl #46799] [TODO] [Perl] Perform end-to-end testing of SmartLinks tests
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46799] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46799 In t/tools/smartlinks.t there is the todo item: # TODO: end-to-end testing Which means to test the smartlink generation process from beginning to end. Stick info at the front and make sure that all the way at the end the right thing comes out.
[perl #46807] [TODO] [Perl] Thread types tests need rework
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46807] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46807 In t/pmc/threads.t there is the todo item: # XXX FIXME rework tests since we don't really have thread types? I hope this comment is fairly self-explanatory.
[perl #46813] [TODO] [Pir] Fix 'join' issue 'sub name lookup in new thread' test
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46813] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46813 In t/pmc/threads.t there is the todo item: $P0.'join'() # XXX within the 'sub name lookup in new thread' test. There is some issue lurking here, although I'm not sure what it is. Hopefully there is someone else who is able to expand upon this so that the issue can be fixed
[perl #46815] [TODO] [Perl] Test all parrot options
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46815] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46815 In t/run/options.t there is the todo item: ## TODO test remaining options Which means that the command line options to Cparrot the program need to be completely tested.
[perl #46817] [TODO] [Pir] Should there be a warning in a Cmain sub?
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46817] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46817 In t/pmc/sub.t there is the todo item: # This is the behavior of Parrot 0.4.3 # XXX Should there be a warning ? which is in the context of turning warnings on in the Cmain sub within pir. So, should there be a warning here?
[perl #46819] [TODO] [Pir] Should core PMCs emit warnings?
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46819] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46819 This ticket is related to RT#46817. In t/pmc/sub.t there is the todo item: # XXX This is the behavior of Parrot 0.4.3 # It looks like core PMCs never emit warning. # Look in perlundef.t for a more sane test of 'warningson' in subs Looking at the following test it seems as if the core PMCs aren't supposed to emit warnings. Is this the correct behaviour?
[perl #46821] [TODO] [Pir] Recursive calls on ResizablePMCArrays fail. Is this what we want?
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46821] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46821 In t/src/ro.t there is the todo item: # XXX: should this work? and the related pir code: # three = 4 # should fail -- is that what we want The question is: is the behaviour encapsulated in the test actually what we want?
[perl #46823] [TODO] [Pir] Rewrite ResizeablePMCArray tests properly when exceptions are implemented
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46823] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46823 In t/pmc/resizeablepmcarray.t there is the todo item: # TODO: Rewrite these properly when we have exceptions Which is to say that the tests of various error conditions and their output needs to be tested more thoroughly when exceptions are implemented.
Re: [perl #46823] [TODO] [Pir] Rewrite ResizeablePMCArray tests properly when exceptions are implemented
On 24/10/2007, via RT Paul Cochrane [EMAIL PROTECTED] wrote: # New Ticket Created by Paul Cochrane # Please include the string: [perl #46823] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46823 In t/pmc/resizeablepmcarray.t there is the todo item: # TODO: Rewrite these properly when we have exceptions Which is to say that the tests of various error conditions and their output needs to be tested more thoroughly when exceptions are implemented. I updated the subject of this ticket to substitute PMC with * as this issue occurs more often than I first guessed (the problems one has when going through code serially...). This issue is actually more general and *any* ResizeablesomethingArray needs the exceptions-related tests updated when we have exceptions implemented.
[perl #46825] [TODO] [Pir] Fix ResizableBooleanArray Cclone test
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46825]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46825
In t/pmc/resizeablebooleanarray.t there is the todo item:
TODO: {
local $TODO = this is broken;
pasm_output_is( 'CODE', 'OUTPUT', clone );
Which is to say, fix cloning in ResizableBooleanArrays or fix the test (or
both?)
[perl #46827] [TODO] [Pir] Test open file, close file, delete file, reopen previously opened stream
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46827] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46827 In t/pmc/parrotio.t there is the todo item: # TODO test open file, close file, delete file, reopen previously opened # stream Do this (please).
[perl #46829] [TODO] [Pir] Clean up temporary files in t/pmc/parrotio.t
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46829] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46829 In t/pmc/parrotio.t there is the todo item: # TODO cleanup 'new_file' Which is to say that the temporary file 'new_file' needs removing after the test has passed.
[perl #46831] [TODO] [Pir] Create a callback in asynchronous open and close test
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46831] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46831 In t/pmc/parrotio.t there is the todo item: $P1 = # TODO create a callback here this needs to be implemented.
[perl #46833] [TODO] [Pir] Test reading/writing code points once supported
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46833] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46833 In t/pmc/parrotio.t there is the todo item: # TODO test reading/writing code points once supported This needs implementing.
[perl #46835] [TODO] [Pir] Test reading long chunks, eof, and across newlines
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46835] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46835 In t/pmc/parrotio.t there is the todo item: # TODO test reading long chunks, eof, and across newlines This needs implementing
[perl #46837] [TODO] [Pir] Test asynchronous print, read, and readline
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46837] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46837 In t/pmc/parrotio.t there is the todo item: # TODO pir_output_is( 'CODE', 'OUT', 'print, read, and readline - # asynchronous', todo = 'not yet implemented' ); So, once asynchronous print, read and readline are implemented, write tests for this functionality. Even better, write TODO tests for this functionality, and hopefully someone will then implement it.
[perl #46839] [TODO] [Pir] Test effects of buffer_type, not just set/get
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46839] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46839 In t/pmc/parrotio.t there is the todo item: # TODO test effects of buffer_type, not just set/get In the buffer_type tests the effects of the buffer type need testing not just the set/get methods.
[perl #46841] [TODO] [Pir] Test buffer_size in t/pmc/parrotio.t
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46841] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46841 In t/pmc/parrotio.t there is the todo item: # TODO # LPDD22/I\/O PMC API/=item buffer_size # NOTES: try setting positive, zero, negative int # perform print and read ops # change buffer size while it contains data # try with all 'buffer_type' modes Please do this.
[perl #46843] [TODO] [Pir] Test get_fd in t/pmc/parrotio.t
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46843] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46843 In t/pmc/parrotio.t there is the todo item: # TODO # LPDD22/I\/O PMC API/=item get_fd # NOTES: this is going to be platform dependent Please implement tests of this functionality.
[perl #46845] [TODO] [Pir] Fix issue associated with 'setting non-existent by name' test
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46845] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46845 In t/pmc/objects.t there is a todo item which looks like it is associated with the 'setting non-existent by name' test. There seems to be some issue here, however it isn't documented in the todo comment. This needs investigation and correction.
[perl #46847] [TODO] [Pir] Replace dummy variable with an io object in iterator tests
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46847] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46847 In t/pmc/io_iterator.t there are many todo items which say: $P99 = 1 # TODO replace with io object Replace this dummy value with an actual io object.
[perl #46849] [TODO] [Pir] Create helper functions to put data in an i/o pmc
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46849] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46849 In t/pmc/io_iterator.t there is the todo item: # TODO create helper functions to put data in an i/o pmc Which is to say that such helper functions would be a good idea for the tests within this test file.
[perl #46851] [TODO] [Pir] Test more return values, including end of file of Cshift
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46851] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46851 In t/pmc/io_iterator.t there is the todo item wthin the tests of the Cshift (opcode??): # TODO test more return values, including end of file Please do this.
[perl #46853] [TODO] [Pir] Setup i/o object with two lines in get_bool (vtable) test
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46853] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46853 In t/pmc/io_iterator.t there is the todo item: # TODO setup i/o object with two lines This is within the context of the tests for Cget_bool (vtable), although the reason isn't obvious to me from the code. Hopefully someone else can add enlightenment here to help whoever ends up working on this ticket.
[perl #46855] [TODO] [Pir] Fix test in t/pmc/fixedpmcarray.t to work with prederef of JIT
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46855] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46855 In t/pmc/fixedpmcarray.t there is the todo item: # XXX doesnt work wit prederef of JIT This issue needs fixing. Either in the test, the code which the test tests, or both.
[perl #46857] [TODO] [Pir] Fix smartlinks in exporter PMC tests once speced
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46857] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46857 In t/pmc/exporter.t there is the todo item: # TODO fix smartlinks once this is specced Do this please.
[perl #46859] [TODO] [Pir] Refactor namespace getting code with make_namespace when implemented
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46859] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46859 In t/pmc/exporter.t there are todo items associated with constructing a namespace before using it in the tests. The todo item looks like: # TODO replace with make_namespace, when implemented Once a make_namespace function/method/thingy is implemented, refactor these tests to use it.
[perl #46861] [TODO] [Pir] Test exporting mmd subs
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46861] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46861 In t/pmc/exporter.t there is the todo item: # TODO test exporting mmd subs So, exporting of multimethod dispatch subs needs testing
[perl #46863] [TODO] [Perl] Factor old code out into Parrot::Test::BigNum
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46863] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46863 In t/pmc/bignum.t there is the todo item: # XXX The following used to be bignum_test.pl. # Maybe it should be factored out to Parrot::Test::BigNum. # This allows a single bignum test to be run directly through the C # library. Usage available by getting the args wrong. This needs to be factored out into a module and the new module will need testing as well.
[perl #46865] [TODO] [Perl] Capture STDOUT when running BigNum tests
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46865]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46865
In t/pmc/bignum.t there is the todo item:
# XXX Capture STDOUT
runtest( $_[0], $_[1], $ops{ $ARGV[2] }, $_[3], $round{ $_[4] }, $_[5] );
Which means that the output from stdout needs to be captured (and
supposedly used) when running individual BigNum tests.
Re: [svn:parrot-pdd] r22428 - trunk/docs/pdds/draft
Klaas-Jan Stol wrote: 2.b is the .constant directive from pasm mode (which is in the macro layer) removed? After some discussion on IRC and review: the only thing I want to change from the current way constants work is to change the name of the '.constant' macro substitution to '.macroconst', and allow '.macroconst' to be used from within PIR. Macro constants can't be type checked, stored in bytecode, or introspected, and so are discouraged for user code. But they are a lightweight way to provide PIR access to C constants (they simply disappear during compilation). There are currently several sets of PASM macro constants being generated from the C constants or for specific subsystems, notably runtime/parrot/include/*.pasm. 2.a line 246, about .globalconstant, doesn't specify when the global is initialized. Is that when the sub in which it is declared is executed/compiled/loaded? Or at startup? Both '.const' and '.globalconst' are initialized during compilation. There's an inconsistency currently in that .const is allowed both inside and outside compilation units, while .globalconst is only allowed inside compilation units. The only difference between the two should be that .const stores the constant in the current bytecode file (in the constant table, the same place unnamed constants get stored), while .globalconst stores the constant in a global constant table. In general, the use of '.const' is preferred over '.globalconst', to diminish effects on other libraries/classes/HLLs running in the same interpreter at the same time. Allison
[perl #46869] [BUG] t/tools/ops2pmutils/: Failures in 4 test files
# New Ticket Created by James Keenan # Please include the string: [perl #46869] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46869 Friends, Within the past 24 hours changes have been committed to trunk which have caused extensive test failures in the suite of tests found in t/ tools/ops2pmutils. These tests, by design, are not run as part of 'make test', but they should be run by any Parrot developer who is working in the areas covered by these tests. Attached is a file that begins with the tail end of the output of a run of 'perl Configure.pl --test' I was doing on Linux at r43328 about an hour ago. I then ran 'prove -v' on each of the 4 files with failures and excerpted the output for each. Since the output implicates 'ops' files, I checked for recent commits. I have a hunch problems may lie with these commits: r22465 | tewk | 2007-10-24 20:11:20 -0400 (Wed, 24 Oct 2007) | 3 lines [exceptions] Adds pop_eh and push_eh_p ** MAKE REALCLEAN REQUIRED DUE TO NEW OPS ** ... and ... r22465 | tewk | 2007-10-24 20:11:20 -0400 (Wed, 24 Oct 2007) | 3 lines [exceptions] Adds pop_eh and push_eh_p ** MAKE REALCLEAN REQUIRED DUE TO NEW OPS ** ... because these are the files that are the raw material for the ops - pm process invoked by 'make'. Note, I did 'make realclean' and 'svn update' before running the tests that resulted in this bug report. So running 'make realclean' is not sufficient to avoid problems. It's late here, so I can't diagnose this further this evening. Thank you very much. kid51 t/tools/ops2pmutils/08-sort_opsNOK 52/91 # Failed test (t/tools/ops2pmutils/08-sort_ops.t at line 176) # 'throwcc_pSKIPPED: not in ops.num nor ops.skip # ' # doesn't match '(?-xism:experimental, not in ops\.num)' t/tools/ops2pmutils/08-sort_opsok 82/91# Looks like you failed 1 test of 91. t/tools/ops2pmutils/08-sort_opsdubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 52 Failed 1/91 tests, 98.90% okay t/tools/ops2pmutils/09-prepare_real_opsok 1/38op push_eh_p: sequence mismatch: ops.num 167 vs. core.ops 1222 at /home/jimk/work/parrot/lib/Parrot/Ops2pm/Utils.pm line 454. # Looks like you planned 38 tests but only ran 16. # Looks like your test died just after 16. t/tools/ops2pmutils/09-prepare_real_opsdubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 17-38 Failed 22/38 tests, 42.11% okay t/tools/ops2pmutils/10-print_moduleok 13/42op push_eh_p: sequence mismatch: ops.num 167 vs. core.ops 1222 at /home/jimk/work/parrot/lib/Parrot/Ops2pm/Utils.pm line 454. # Looks like you planned 42 tests but only ran 16. # Looks like your test died just after 16. t/tools/ops2pmutils/10-print_moduledubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 17-42 Failed 26/42 tests, 38.10% okay t/tools/ops2pmutils/11-print_h.ok 11/23op push_eh_p: sequence mismatch: ops.num 167 vs. core.ops 1222 at /home/jimk/work/parrot/lib/Parrot/Ops2pm/Utils.pm line 454. # Looks like you planned 23 tests but only ran 16. # Looks like your test died just after 16. t/tools/ops2pmutils/11-print_h.dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 17-23 Failed 7/23 tests, 69.57% okay Failed Test Stat Wstat Total Fail List of Failed --- t/tools/ops2pmutils/08-sort_ops.t1 256911 52 t/tools/ops2pmutils/09-prepare_real_ops.t 255 6528038 44 17-38 t/tools/ops2pmutils/10-print_module.t 255 6528042 52 17-42 t/tools/ops2pmutils/11-print_h.t 255 6528023 14 17-23 Failed 4/36 test scripts. 56/1139 subtests failed. Files=36, Tests=1139, 248 wallclock secs (95.54 cusr + 21.25 csys = 116.79 CPU) Failed 4/36 test programs. 56/1139 subtests failed. [li11-226:parrot] 506 $ prove -v t/tools/ops2pmutils/08-sort_ops.t t/tools/ops2pmutils/08-sort_ops OK: Parrot top directory located ... not ok 52 - Got expected warning about experimental ops # Failed test (t/tools/ops2pmutils/08-sort_ops.t at line 176) # 'throwcc_pSKIPPED: not in ops.num nor ops.skip # ' # doesn't match '(?-xism:experimental, not in ops\.num)' [li11-226:parrot] 507 $ prove -v t/tools/ops2pmutils/09-prepare_real_ops.t t/tools/ops2pmutils/09-prepare_real_ops OK: Parrot top
Re: [perl #46869] AutoReply: [BUG] t/tools/ops2pmutils/: Failures in 4 test files
On Oct 24, 2007, at 10:41 PM, Parrot via RT wrote: Attached is a file that begins with the tail end of the output of a run of 'perl Configure.pl --test' I was doing on Linux at r43328 about an hour ago. I mistyped. It was at r22466.
[perl #43328] [TODO] config/inter/encoding.pm: Write unit tests
With a little bit of refactoring and the contribution of two test files in r22466, we have achieved 100% code coverage for inter::encoding. Resolving ticket.
Re: [perl #46869] AutoReply: [BUG] t/tools/ops2pmutils/: Failures in 4 test files
On Oct 24, 2007, at 10:48 PM, James E Keenan wrote: On Oct 24, 2007, at 10:41 PM, Parrot via RT wrote: Attached is a file that begins with the tail end of the output of a run of 'perl Configure.pl --test' I was doing on Linux at r43328 about an hour ago. I mistyped. It was at r22466. 3 of the tests pass again if the ops are renumbered (since this changed the available ops): % make -f tools/dev/ops_renum.mak That leaves the error that is complaining about 'throwcc_p'... -- Will Coke Coleda [EMAIL PROTECTED]
Re: [perl #46823] [TODO] [Pir] Rewrite ResizeablePMCArray tests properly when exceptions are implemented
Paul Cochrane wrote: I updated the subject of this ticket to substitute PMC with * as this issue occurs more often than I first guessed (the problems one has when going through code serially...). This issue is actually more general and *any* ResizeablesomethingArray needs the exceptions-related tests updated when we have exceptions implemented. Could you explain more fully what the problem is? Since we're currently implementing the exceptions PDD, it would be helpful to know any edge cases that need to be fixed. Allison
Re: [perl #46869] AutoReply: [BUG] t/tools/ops2pmutils/: Failures in 4 test files
On Oct 24, 2007, at 11:09 PM, Will Coleda wrote: On Oct 24, 2007, at 10:48 PM, James E Keenan wrote: On Oct 24, 2007, at 10:41 PM, Parrot via RT wrote: Attached is a file that begins with the tail end of the output of a run of 'perl Configure.pl --test' I was doing on Linux at r43328 about an hour ago. I mistyped. It was at r22466. 3 of the tests pass again if the ops are renumbered (since this changed the available ops): % make -f tools/dev/ops_renum.mak That leaves the error that is complaining about 'throwcc_p'... This is a new op, added in the aforementioned commit; Do we need to update PBC_COMPAT? -- Will Coke Coleda [EMAIL PROTECTED]
