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 " is covered by a "goto " 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 I. A > -I is terminated by a newline (). 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] > - > -=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 B 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 C. [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 > +=head3 Statements > > -Identifiers start with a letter or underscore, then may contain > additionally > -letters, digits, underscores and B<::>. Identifiers don't have any limi
[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. # 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. # 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 C 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. # http://rt.perl.org/rt3/Ticket/Display.html?id=46787 > In t/tools/smartlinks.t, within the context of testing the C class there is the todo item: # TODO: ->tree Which means to test the C method of the C 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. # http://rt.perl.org/rt3/Ticket/Display.html?id=46789 > In t/tools/smartlinks.t in the context of the C class there is the todo item: # TODO: many more ->files tests Which means to say; add many more tests of the C 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. # http://rt.perl.org/rt3/Ticket/Display.html?id=46791 > In t/tools/smartlinks.t in the context of the C class there is the todo item: # TODO: ->tests, ->smartlinks Which means to say to test the C and C 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. # 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 C 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. # 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 C 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. # 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 C 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. # 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. # 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. # 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 C, C, C or C,
+The type of a named variable can be C, C, C or C,
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 [: ...]
+=item .sub
-Define a compilation unit with the label I. All code in a
-PIR source file must be defined in a compilation unit. See
-L for available flags.
-Optional flags are a list of I, separated by empty spaces, and empty
-spaces only.
+ .sub [: ...]
+ .sub [: ...]
+
+Define a compilation unit. All code in a PIR source file must be defined in a
+compilation unit. See L for
+available flags. Optional flags are a list of I, 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
+L above), but string sub names can contain any characters,
+including characters from different character sets (see L above).
{{ NOTE: the optional comma in the flag list is deprecated RT#45697 }}
@@ -344,12 +351,12 @@
=item .emit
-Define a I containing PASM code. Always paired with
+Define a compilation unit containing PASM code. Always paired with
C<.eom>.
=item .eom
-End a I 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 "" => [:]*
@@ -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 [: ...]
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 [: ...]
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 :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 " is covered by a "goto " 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. # 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. # 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. # 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. # 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 C the program need to be completely tested.
[perl #46817] [TODO] [Pir] Should there be a warning in a C sub?
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46817] # in the subject line of all future correspondence about this issue. # 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 C 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. # 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. # 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. # 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. > # 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* ResizeableArray needs the exceptions-related tests updated when we have exceptions implemented.
[perl #46825] [TODO] [Pir] Fix ResizableBooleanArray C test
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46825]
# in the subject line of all future correspondence about this issue.
# 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. # 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. # 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. # 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. # 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. # 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. # 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. # 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. # http://rt.perl.org/rt3/Ticket/Display.html?id=46841 > In t/pmc/parrotio.t there is the todo item: # TODO # L # 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. # http://rt.perl.org/rt3/Ticket/Display.html?id=46843 > In t/pmc/parrotio.t there is the todo item: # TODO # L # 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. # 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. # 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. # 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 C
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46851] # in the subject line of all future correspondence about this issue. # 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 C (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. # 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 C, 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. # 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. # 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. # 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. # 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. # 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.
# 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. # 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 directory l
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* ResizeableArray 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]
