Re: [perl #59912] Re: hllmagic branch tests namespace changes
On Wed, Oct 15, 2008 at 1:03 PM, chromatic via RT
<[EMAIL PROTECTED]> wrote:
> On Wednesday 15 October 2008 05:54:59 Will Coleda wrote:
>
>> The namespace of the generated file should be changed, the subclass
>> should probably be updated. (TGE itself should probably be updated to
>> not live a namespace with a '::' in it. The actual transform sub can
>> keep the name it has, but the first parameter to add_rule() should
>> probably be updated as well. This /should/ work with the new automatic
>> translation of :: that PGE is doing.
>
> Here's a patch for part of TGE to use the keyed form of classnames. PCT may
> need some changes as well. In particular, the parsegrammar and astgrammar
> methods in src/PCT/HLLCompiler.pir take strings as arguments, as in this
> example from Pheme:
>
>$P0 = get_hll_global ['PCT'], 'HLLCompiler'
>$P1 = $P0.'new'()
>
>$P1.'language'('Pheme')
>$P1.'parsegrammar'( 'Pheme::Grammar' )
>$P1.'astgrammar'( 'Pheme::AST::Grammar' )
>
> They should probably transform these strings into keys internally, as
> P6MetaObject does.
>
> -- c
>
>
>
With this patch, I get a TGC failure trying to compile tcl :
../../parrot ../../compilers/tge/tgc.pir
--output=src/grammar/expr/pge2past.pir src/grammar/expr/pge2past.tg
Null PMC access in invoke()
current instr.: 'parrot;TGE::Compiler;parse_grammar' pc 28 (TGE/Compiler.pir:34)
called from Sub 'parrot;TGE::Compiler;precompile' pc 653 (TGE/Compiler.pir:293)
called from Sub 'main' pc 101 (../../compilers/tge/tgc.pir:87)
make: *** [src/grammar/expr/pge2past.pir] Error 1
--
Will "Coke" Coleda
Re: [svn:perl6-synopsis] r14597 - doc/trunk/design/syn
On Thu, Oct 16, 2008 at 10:37:41PM +0200, Eirik Berg Hanssen wrote: : [EMAIL PROTECTED] writes: : : > -C<< infix: >>, sequential junctional and operator : > +C<< infix: >>, sequential junctional and operator : > : > -EXPR where EXPR where EXPR ... : > +EXPR also EXPR also EXPR ... : > : > Can be used to construct ANDed patterns with the same semantics as : > C<< infix:<&> >>, but with left-to-right evaluation guaranteed, for use : > in guarded patterns: : > : > -$target ~~ MyType where .mytest1 where .mytest2 : > +$target ~~ MyType also .mytest1 also .mytest2 : > : > This is useful when later tests might throw exceptions if earlier : > tests don't pass. This cannot be guaranteed by: : : All this, just to get the exceptions in the right order? It's to get exceptions not to happen at all. Normal junctions don't trap exceptions either, but also can't guarantee order of evaluation. This variant does. That's all. Larry
Re: [svn:perl6-synopsis] r14597 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: > -C<< infix: >>, sequential junctional and operator > +C<< infix: >>, sequential junctional and operator > > -EXPR where EXPR where EXPR ... > +EXPR also EXPR also EXPR ... > > Can be used to construct ANDed patterns with the same semantics as > C<< infix:<&> >>, but with left-to-right evaluation guaranteed, for use > in guarded patterns: > > -$target ~~ MyType where .mytest1 where .mytest2 > +$target ~~ MyType also .mytest1 also .mytest2 > > This is useful when later tests might throw exceptions if earlier > tests don't pass. This cannot be guaranteed by: All this, just to get the exceptions in the right order? Or is it supposed to be short-circuiting, too? :-) Okay, I actually don't recall how junctions + exceptions work, but wouldn't it be nice if the docs for C told us explicitly what this example is supposed to achieve, and some idea of how? Eirik, sideline sniper -- "Its failings notwithstanding, there is much to be said in favor of journalism in that by giving us the opinion of the uneducated, it keeps us in touch with the ignorance of the community." - Oscar Wilde
Re: [perl #36249] [TODO] Document policy on breakage, er, backward compatibility.
On Thu, Oct 16, 2008 at 10:12 AM, Andrew Whitworth via RT <[EMAIL PROTECTED]> wrote: > On Sat Jun 11 13:08:49 2005, chip wrote: >> Short version: Up through version 0.8 or so, we promise to break >> everything constantly (but not until we have a good reason). After >> that, we will establish version number thresholds below which >> individual APIs will not change. >> >> For example, only on a major version change are we allowed to even >> consider breaking the embedding API. On the other hand, we may break >> pasm somewhat more frequently: humans should only write pir, not pasm, >> and it's not against the law to abuse silicon-based life forms. > > Has anybody put any thought into this? Do we have any documents or > drafts which address this issue? We are getting close enough to the 0.8 > release that's mentioned here as a specific milestone for getting this done. > replace 0.8 with 0.50 or so. we're not close enough to release at 0.8 to worry about this yet. ~jerry
[svn:parrot-pdd] r31995 - trunk/docs/pdds
Author: Whiteknight Date: Thu Oct 16 10:42:15 2008 New Revision: 31995 Modified: trunk/docs/pdds/pdd19_pir.pod Log: [PDD] Add some more information about :unique_reg as per the discussion at RT#57636. Modified: trunk/docs/pdds/pdd19_pir.pod == --- trunk/docs/pdds/pdd19_pir.pod (original) +++ trunk/docs/pdds/pdd19_pir.pod Thu Oct 16 10:42:15 2008 @@ -229,7 +229,22 @@ The optional C<:unique_reg> modifier will force the register allocator to associate the identifier with a unique register for the duration of the -subroutine. +subroutine. If the register allocator is thought of as an optimization +tool for allowing fewer registers to be used in a register frame by reusing +unused registers, then the C<:unique_reg> directive forces this +optimization to be turned off. This can be important in a number of +situations: + +=over 4 + +=item* When a subroutine has a small fixed number of registers + +=item* When a named variable or named register is used throughout the entire +subroutine + +=item* When a reference needs to be made to a register + +=back =item .lex ,
[perl #40124] [TODO] Document HLL mappings
On Fri Nov 10 11:19:58 2006, chip wrote: > It's already true that HLLs can remap the basic types so that e.g. > parameter > passing creates a PerlArray rather than a base array. However the > mechanism is > not documented (AFAIK), and it should be. Haven't heard any information about this ticket in two years. I did a quick look-through and didn't see any documentation about HLL mapping. Considering it's been such a big topic in Rakudo development lately (among other things) maybe we have some people now willing to write some quick documentation about it? Or, if somebody can point me to the relevant code, I can try to hack together some docs for it. -- Andrew Whitworth a.k.a Whiteknight
[perl #57636] [TODO][PDD19] Document the reason for :unique_reg flag
On Sat Aug 16 02:36:27 2008, [EMAIL PROTECTED] wrote: > chromatic wrote: > > On Thursday 07 August 2008 08:26:19 Bob Rogers wrote: > > > >> I once suggested a "null register allocator" that would do this > >> globally, but this is a better idea. The only use case I can think > of > >> is debugging, particularly of the register allocator, but that's > still > >> important. > > > > In theory, that's what the vanilla register allocator does. In > practice, > > somehow something sometimes turns on the graph-based allocator, > which has a > > couple of bugs. PGE trips this occasionally. > > The graph-based allocator is currently completely disabled, and may be > ripped out. > > :unique_reg is a useful feature. For one thing, it's a compiler > optimization to skip the allocation code on certain variables. And, > we're likely to run through multiple register allocator algorithms > over > the years, so the ability to protect certain variables from register > alligators is likely to find future use. > > When disabling optimizations, you generally want to do it for the > smallest area possible, so turning off allocation for particular > variables is better than turning it off for an entire subroutine. But, > if we find that supporting :unique_reg for particular variables makes > it > overly difficult to implement future register allocators, we can > deprecate it then and switch to a per-subroutine selector. > > Allison I committed a small update to the :unique_reg documentation in PDD19 in r31995. This should satisfy the original purpose of this ticket (documenting the directive), so I'm going to mark it resolved. There was a lot of good information discussed here though, about register allocators and other stuff, so forgetting about this ticket entirely is probably not a good idea. I'll try to merge some more of these ideas into documentation in various files throughout /docs/ http://rt.perl.org/rt3/Ticket/Display.html?id=57636 -- Andrew Whitworth a.k.a Whiteknight
[perl #43831] [CAGE] Document how we do function decoration
On Thu Feb 28 12:56:30 2008, bernhard wrote: > On Do. 12. Jul. 2007, 08:58:41, petdance wrote: > > Is the documentation of funtion declaration taken care of in > docs/dev/seatbelts.pod ? Or is there more to do? > If I understand what is being asked for in the ticket name (which is very obtuse, and no explanation is given), we're talking about documenting the way our C functions are decorated? If so, then docs/dev/seatbelts.pod really does appear to be it (but it needs updating and expanding). I propose we need to: 1) Rename this ticket to something more descriptive 2) Rename seatbelts.pod to something more descriptive, like /docs/dev/C_Functions.pod or something. 3) Expand that documentation to include more cases (ARGIN, ARGMOD, ARGOUT, all the *_NULLOK variants of those, etc). Any suggestions? -- Andrew Whitworth a.k.a Whiteknight
[perl #36249] [TODO] Document policy on breakage, er, backward compatibility.
On Sat Jun 11 13:08:49 2005, chip wrote: > Short version: Up through version 0.8 or so, we promise to break > everything constantly (but not until we have a good reason). After > that, we will establish version number thresholds below which > individual APIs will not change. > > For example, only on a major version change are we allowed to even > consider breaking the embedding API. On the other hand, we may break > pasm somewhat more frequently: humans should only write pir, not pasm, > and it's not against the law to abuse silicon-based life forms. Has anybody put any thought into this? Do we have any documents or drafts which address this issue? We are getting close enough to the 0.8 release that's mentioned here as a specific milestone for getting this done. -- Andrew Whitworth a.k.a Whiteknight
Re: [perl #59928] Calling methods in many-jointed classes doesn't work
Moritz (>), Carl (>>):
>> Rakudo r31994 can call methods on classes without :: in them, but not
>> on classes having them.
>>
>> $ perl6 -e 'class A { method foo { say "OH HAI" } }; A.new.foo'
>> OH HAI
>>
>> $ perl6 -e 'class A::B { method foo { say "OH HAI" } }; A::B.new.foo'
>> Method 'foo' not found for invocant of class 'A;B'
>> [...]
>
> We clearly need more OO tests. Care to add that one (as TODO) to one of
> the S12 tests that is included in `make spectest`?
I added the new test file t/spec/S12-class/namespaced.t -- feel free
to merge it (and its single test) into another test file. I'm not sure
I got the TODO fudging right.
Re: A question about arrays
On Thu, Oct 16, 2008 at 02:56:28PM +1100, Timothy S. Nelson wrote:
> Hi all. I'm working on the code for trees that I keep talking about,
> and I have code that somewhat resembles the following:
>
> role Tree::Node does Array {
> has Tree::Node @!children handles ;
> }
>
> The intent of this code is that, if you treat the Tree::Node as an
> array, you're operating on its children. I'm sure there are obvious bugs
> in that code that I'd be happy to hear about, but my question at the
> moment is, I want to be able to intercept calls that put things into the
> array and pull them out, and perform code at that time. For example, I'd
> like it if
>
> $node = Tree::Node->new();
> $othernode = Tree::Node->new();
> $node[0] = $othernode;
>
> ...would allow me to operate on $othernode, so that I could ensure that
> they belong to the same tree, for example. Is there a way I can do that?
You have to write your own wrapper methods for that. Delegation does
not mix well with micromanagement. :)
Larry
Re: [perl #57226] [RESOLVED] The statement '.say while =$*IN' makes parrot segfault
No, this one still crashes on my box. It crashes so hard it takes the terminal window with it. // Carl
Re: [svn:perl6-synopsis] r14597 - doc/trunk/design/syn
On Thu, Oct 16, 2008 at 09:34:33AM -0700, [EMAIL PROTECTED] wrote: : rename infix: to infix: The rationale for changing this, by the way, is that (in English) A where B where C tends to imply right-to-left evaluation of preconditions, whereas: A also B also C tends to imply left-to-right evaluation of additional constraints. Larry
[svn:perl6-synopsis] r14597 - doc/trunk/design/syn
Author: larry Date: Thu Oct 16 09:34:30 2008 New Revision: 14597 Modified: doc/trunk/design/syn/S03.pod Log: rename infix: to infix: Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podThu Oct 16 09:34:30 2008 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 8 Mar 2004 - Last Modified: 9 Oct 2008 + Last Modified: 16 Oct 2008 Number: 3 - Version: 143 + Version: 144 =head1 Overview @@ -38,7 +38,7 @@ L Additive + - +| +^ ~| ~^ ?| ?^ L Replication x xx X Concatenation ~ -X Junctive and & where +X Junctive and & also X Junctive or | ^ L Named unary sleep abs sin N Nonchaining infix but does <=> leg cmp .. ..^ ^.. ^..^ @@ -949,15 +949,15 @@ =item * -C<< infix: >>, sequential junctional and operator +C<< infix: >>, sequential junctional and operator -EXPR where EXPR where EXPR ... +EXPR also EXPR also EXPR ... Can be used to construct ANDed patterns with the same semantics as C<< infix:<&> >>, but with left-to-right evaluation guaranteed, for use in guarded patterns: -$target ~~ MyType where .mytest1 where .mytest2 +$target ~~ MyType also .mytest1 also .mytest2 This is useful when later tests might throw exceptions if earlier tests don't pass. This cannot be guaranteed by:
Re: [perl #45859] [RFC][IMCC] clean up method syntax: bare word and quoted method names
On Thu, Oct 16, 2008 at 9:12 AM, Klaas-Jan Stol via RT <[EMAIL PROTECTED]> wrote: > I think this ticket has been resolved by the decision that method names > must be quoted (as stated in pdd19). > > I propose to close ticket. > kjs That decision doesn't correspond to reality, though: $ cat foo.pir .sub main :main $P1 = subclass 'String', 'kjs' $P1 = new 'kjs' $P1.hi() .end .namespace [ 'kjs' ] .sub 'hi' :method say "hi" .end $ ./parrot foo.pir hi Regards. -- Will "Coke" Coleda
[perl #45859] [RFC][IMCC] clean up method syntax: bare word and quoted method names
I think this ticket has been resolved by the decision that method names must be quoted (as stated in pdd19). I propose to close ticket. kjs On Thu Oct 04 16:39:31 2007, coke wrote: > > On Sep 29, 2007, at 12:07 PM, Klaas-Jan Stol (via RT) wrote: > > > # New Ticket Created by Klaas-Jan Stol > > # Please include the string: [perl #45859] > > # in the subject line of all future correspondence about this issue. > > # http://rt.perl.org/rt3/Ticket/Display.html?id=45859 > > > > > > > Hi, > > > > This proposal is about resolving method names: bare words or quoted > > > > it might be that i'm not well informed on this issue, so please > > correct me > > where I go wrong. > > > > > > IMCC currently allows for method call syntax like this: > > > > foo.bar() > > foo."bar"() > > One thing to think about is that allowing double quoted strings > wrapping this allows us to have method names with spaces, unicode, > newlines... (and having single quoted strings allows us to easily > have escaped versions of same.) > > > > Both invoke the method named "bar" on the object "foo", UNLESS > > there is a > > local variable named "bar", in which case the first statement will > > invoke > > the method whose name is stored in that local variable. > > > > This is confusing, and makes reading code not easy (imagine having a > > subroutine of 50+ instructions, and debugging it) > > > > PCCMETHODs (a method on a pmc written in C) is, IIRC, invoked using > > a bare > > word methodname like so: > > > > foo.bar() > > > > So, what is called here? Is bar a method, a PCCMETHOD (but I guess > > that does > > not matter), or a local variable containing the name of a method? > > > > > > > > In order to prevent confusing, I propose that methodnames are > > always written > > between quotes. This should also be true for PCCMETHODs. > > Only then is it always clear when calling a method whose name is > > stored in a > > local variable, or if it's actually the name of the method that was > > written. > > > > I think the method "new" on a class is a PCCMETHOD, right? > > This would mean that you would create a new object instance like so: > > > > .local pmc b > > b = Foo.new() > > > > Having to write > > > > b = Foo.'new'() might seem inconvenient, but I think it's a matter of > > getting used to, and it is more consistent. > > > > Consistency is good. > > > > The assembly language (if you can call PIR that) should not have > > too many > > rules and exceptions. > > -- > Will "Coke" Coleda > [EMAIL PROTECTED] > >
[perl #57400] Working with %*ENV in Rakudo is difficult
Here's a thorough investigation of the strange properties of %*ENV.
Rakudo r31926 has an %*ENV variable which claims to be of Hash type, but
which behaves very non-hashlike when you poke it. Its hash values are
supposedly strings, but don't have the corresponding Str methods.
say 'a'.WHAT;
# Str
say 'a'.trans();
# a
say %*ENV.WHAT;
# Str
say %*ENV.trans();
# too few arguments passed (1) - 3 params expected
say %*ENV.trans( [], [] );
# Null PMC access in get_string()
say %*ENV.trans( [], [] ).WHAT;
# Null PMC access in find_method()
%*ENV .= trans([ "A" => "B" ], [])'
# Null PMC access in name()
sub foo($s is rw) { $s .= trans( [ 'a' => 'b' ], [] ) }
say foo( 'a' );
# b
say foo( %*ENV );
# Null PMC access in can()
%*ENV = "OH HAI"; say %*ENV.perl
# ""
%*ENV := "OH HAI"; say %*ENV.perl
# "OH HAI"
%*ENV = {}
# Parrot VM: Can't modify a singleton
%*ENV := {}; say %*ENV.perl
# {}
my %h = %*ENV
# Parrot VM: Can't turn to a singleton type!
%*ENV.keys
%*ENV.values
%*ENV.kv
%*ENV.perl
# No applicable methods.
say %*ENV.elems
# 1
say %*ENV.join
# get_string() not implemented in class 'Env'
In summary:
1. Ordinary strings and strings in %*ENV are unequally treated. You can call
.trans(), or .trans([]) on the former, but you have to send in two non-
invocant arguments to the latter.
2. The result of a successful .trans call on an %*ENV item returns something
which, when touched in any way, causes Rakudo to explode. Most likely a
Parrot
Null value. This is the case regardless of the value of the %*ENV item, and
regardless of whether it has been defined.
3. Actively modifying the %*ENV item using .=trans produces a Null PMC
access
in another Parrot sub, and doing this from within a subroutine, produces
a Null
PMC acces in yet another Parrot sub.
4. Setting an %*ENV item using infix:<=> has no effect. Setting it using
infix:<:=> works. Setting %*ENV itself using infix:<=> produces a Parrot VM
error. Setting it using infix:<:=> works. Assigning %*ENV to another
variable
using infix:<=> produces another Parrot VM error.
5. When calling the methods .keys, .values, .kv or .perl on %*ENV, something
fails with "No applicable methods". (Note, though, that this is
different from
the error message produced by calling a method that doesn't exist on Hash:
"Method 'foo' not found for invocant of class 'Env'") The %*ENV.elems mehtod
always reports '1'. Calling %*ENV.join() produces an error message.
[perl #59928] Calling methods in many-jointed classes doesn't work
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #59928]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=59928 >
Rakudo r31994 can call methods on classes without :: in them, but not
on classes having them.
$ perl6 -e 'class A { method foo { say "OH HAI" } }; A.new.foo'
OH HAI
$ perl6 -e 'class A::B { method foo { say "OH HAI" } }; A::B.new.foo'
Method 'foo' not found for invocant of class 'A;B'
[...]
Possibly related to the (now resolved) #58368.
[perl #58374] [TODO][PDD19] Decide on maximum identifier length and implement this.
PDD19 already states that there's no limit, and the note that in the future such a limit might be introduced is also there. So, issue is resolved. kjs
[perl #59926] [TODO][IMCC] Remove n_ code
# New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #59926] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=59926 > There's a number of spots in IMCC where the n_ variants of ops are considered. One example is in parser_util.c:364, another in the 'is_op' function that is called for each identifier scanned, also in parser_util.c:275. As the n_ variants are removed, this n_ handling code should be removed as well. kjs
Re: [perl #48549] [DEPRECATED] [PDD19] Let .namespace (no args) have empty brackets
On Wed, Oct 15, 2008 at 11:42 AM, Andrew Whitworth via RT <[EMAIL PROTECTED]> wrote: > On Wed Jul 30 11:57:39 2008, coke wrote: >> PDD19 lists this as deprecated now, changing from an [RFC] to >> [DEPRECATED], re-opening from stalled. > > The big hangup for this ticket is that various parts of PCT and the > CodeString PMC do not support empty brackets, and therefore PCT does not > emit ".namespace []" in these situations. Since PCT is one of the > biggest producers of PIR code, we obviously can't move forward on the > deprecation of this feature until CodeString is updated to emit "[]" for > an empty namespace instead of just saying ".namespace". > > I know pmichaud was talking about a major rewrite of PGE in the future, > maybe this change could be included in the laundry list of things to do > during that time? > since ".namespace " and ".namespace []" mean the same thing, i don't see a reason this can't be converted in trunk and piecemeal. it's already listed as deprecated, so it's just a matter of tuits. i think i have some. am i alone? ~jerry
Re: [perl #31633] [TODO] Allow Languages to be self contained
On Thu, Oct 16, 2008 at 3:55 AM, Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > Will Coleda via RT schrieb: >> >> On Sat Sep 18 23:13:06 2004, coke wrote: >> >>> >>> That is: >>> >>> Contrive things so that no code whatsover must be maintained outside >>> of the language specific directory. This includes: >>> >>> - MANIFEST >>> - config files >>> - ./library/Parrot/Test/* >>> >>> >>> >>> >> >> The long term goal for languages is that they'll live in their own >> repository, rather than being shipped with parrot's. >> > > There are a lot of languages that nobody cares enough about, to put them > into a separate > repository. How about creating a repository, > https://svn.perl.org/parrot-little-languages, > that can serve as a container for those semi-maintained languages? Jerry setup a google code repository for those that don't want to maintain their own: http://code.google.com/p/squawk/ And I would imagine those are for "real" languages; I don't imagine that someone will make an HQ9+ language pack for parrot (but if they do, the squawk repository is a fine place for it.). -- Will "Coke" Coleda
[perl #59924] [BUG] t/examples/library.t: new failure
# New Ticket Created by James Keenan # Please include the string: [perl #59924] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=59924 > The test below, which always previously passed for me on Linux, started to fail somewhere between r31872 (Oct 10) and r31967 (Oct 14). http://smolder.plusthree.com/app/public_projects/tap_stream/6132/396 1..4 ok 1 - examples/library/getopt_demo.pir ok 2 - examples/library/md5sum.pir 7.4 not ok 3 - examples/library/pcre.pir # Failed test 'examples/library/pcre.pir' # at t/examples/library.t line 67. # got: 'asdf =~ /as/ # 1 match(es): # ' # expected: 'asdf =~ /as/ # 1 match(es): # as # ' not ok 4 - ncurses_life.pir # TODO ncurses_life.pir not testable yet # Failed (TODO) test 'ncurses_life.pir' # at t/examples/library.t line 77. # Looks like you failed 1 test of 4. So far I have not been able to identify any files which changed during this interval and which are obvious candidates for causing this bug. kid51
RE: [perl #56972] Error in link
> Since we're migrating to www.parrot.org instead, is this much of an > issue? If not, I think we can close this ticket. This makes sense to me too. Ronald
Re: [perl #46821] [RFC] should readonly be deep or shallow?
Will Coleda via RT wrote: On Wed Oct 24 13:52:33 2007, pcoch wrote: 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? This test is in t/pmc/ro.t, not t/src/ro.t The question can be summed up as: when marking a container PMC as readonly, should that make all the PMCs that are contained readonly as well? If so, we need to make that work (and add a test for at least a hash-style one as well), and if not, we can reverse the sense of the todo test and enable it. I seem to remember a discussion where it was mentioned that marking a container read-only should be shallow, but I couldn't find it in the irc logs. Has a decision been made on this?
[perl #31143] [TODO] Interpreter - share MMD tables
On Sun Aug 15 13:21:16 2004, coke wrote: > Make the MMD tables shareable between interpreters for faster > startup. (Though there are issues with this) > > (From the TODO file) With the pdd27mmd branch merged in now, what's the status of this request? -- Andrew Whitworth a.k.a Whiteknight
[perl #59544] open(null) kills parrot
Problem fixed and test added, closing ticket.
[perl #38432] [BUG] Exception thrown from constructor leads to oddness
On Wed Oct 15 12:42:23 2008, coke wrote: > Here's yet another updated version (this time for the exception handler) > of the test that doesn't segfault, but still generates incorrect output > (generates both an OK line and a NOK line) It looks like the exception handler is resuming after the exception is handled. (Resuming by default, instead of only resuming when the resume continuation is explicitly invoked.) Allison
[perl #46405] [TODO] Reset stacktop or disable GC in Parrot_exit()
On Sat Oct 13 11:14:42 2007, pcoch wrote: > In src/exit.c:Parrot_exit() there is the todo item (with some context): > > /* call all the exit handlers */ > > TODO reset stacktop or better disable GC > > Make a decision as to which is better to do; reset stacktop or disable GC > and then implement as appropriate. I'm trying to figure out exactly what needs to be done here, the comments in the function are a little cryptic. After all the exit handlers are called, we want to perform a finalizing GC run, to make sure all custom destructors are called on all PMCs? Or, is finalization called from somewhere else automatically? That, and what is meant here by "reset stacktop"? I have no idea what that's supposed to mean. -- Andrew Whitworth a.k.a Whiteknight
[perl #52778] [RFC] Are resizable arrays too Perlish?
On Sun Sep 14 13:43:15 2008, cotto wrote: > On Sun Sep 14 07:47:34 2008, pmichaud wrote: > > On Sun, Sep 14, 2008 at 12:41:42AM -0700, Christoph Otto via RT wrote: > > > > > > I got impatient and committed this as r31101. I'm marking this > > ticket > > > as resolved. > > > > According to [1], r31101 causes Rakudo to stop building with the > > following error: > > > > $ make > > ../../parrot > > /home/pmichaud/parrot/trunk/runtime/parrot/library/PGE/Perl6Grammar.pbc > > \ > > --output=src/gen_grammar.pir \ > > src/parser/grammar.pg src/parser/grammar-oper.pg > > ../../parrot /home/pmichaud/parrot/trunk/compilers/nqp/nqp.pbc > > --output=src/gen_actions.pir \ > > --encoding=fixed_8 --target=pir src/parser/actions.pm > > Null PMC access in get_bool() > > current instr.: 'parrot;NQP::Grammar::Actions;routine_def' pc 33982 > > (src/Grammar/Actions.pir:403) > > called from Sub 'parrot;NQP::Grammar;routine_def' pc 20036 > > (src/Grammar_gen.pir:7553) > > called from Sub 'parrot;NQP::Grammar;noun' pc 25828 > > (src/Grammar_gen.pir:9806) > > called from Sub 'parrot;NQP::Grammar;term' pc 22730 > > (src/Grammar_gen.pir:8622) > > called from Sub 'parrot;PGE::OPTable;parse' pc 1959 > > (compilers/pge/PGE/OPTable.pir:554) > > [...] > > > > As a temporary fix, Reini Urban reverted parts of the r31101 patch > > in r31108. > > > > I've traced the problem back to NQP; it was testing a value retrieved > > from a ResizablePMCArray for truth without first checking it for > > PMCNULL. I've since fixed that part of NQP (r31115). > > > > However, this does point out that there may be other languages and > > tools > > in Parrot that likewise depend on the old behavior of the various > > *Array > > types, so I'm reopening this ticket until all of those have been > > tested. > > > > In fact, it may be that we should revert r31101 entirely and > > go through a complete deprecation cycle before changing the > > behaviors of the core Array types in this manner, in case there > > are other libraries or languages depending on it. > > > > Pm > > > > > > 1. > > http://groups.google.com/group/perl.perl6.internals/msg/2cd7d9ede7a3cd4e > > > > I've completely reverted r31101 in r31124 so this behavior change can go > through the deprecation cycle. I also added a note to DEPRECATED.pod in > r31134. I've re-committed the patch in r31968. If it messes anything up (again) this ticket can be reopened, but I'm resolving it for now.
[perl #59918] Re: building parrot
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #59918] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=59918 > On Wed, Oct 15, 2008 at 9:52 AM, Will Coleda <[EMAIL PROTECTED]> wrote: > Do you have a previously installed parrot? It's possible that we're > inadvertently linking against the installed libparrot instead of the > one in your build dir. No file by that name on the box anywhere. Mike -- Michael P. Soulier <[EMAIL PROTECTED]> "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." --Albert Einstein
[perl #45959] [TODO] Check arity of sub in mmd_maybe_candidate()
On Tue Oct 02 10:22:41 2007, pcoch wrote:
> In the file src/mmd.c there is the todo item within mmd_maybe_candiate():
>
> if (VTABLE_isa(interp, pmc, _sub)) {
> /* a plain sub stops outer searches */
> /* TODO check arity of sub */
>
> VTABLE_push_pmc(interp, cl, pmc);
In this, we want to only push on a candidate sub if the arity of the sub
matches the arity of the MMD call? If so, what do we compare it to?
Also, do we need to check the arity of MultiSub candidates too?
Are we sure that Parrot_mmd_maybe_candidate is the right place to be
checking arity on these subs?
--
Andrew Whitworth
a.k.a Whiteknight
[perl #48549] [DEPRECATED] [PDD19] Let .namespace (no args) have empty brackets
On Wed Jul 30 11:57:39 2008, coke wrote: > PDD19 lists this as deprecated now, changing from an [RFC] to > [DEPRECATED], re-opening from stalled. The big hangup for this ticket is that various parts of PCT and the CodeString PMC do not support empty brackets, and therefore PCT does not emit ".namespace []" in these situations. Since PCT is one of the biggest producers of PIR code, we obviously can't move forward on the deprecation of this feature until CodeString is updated to emit "[]" for an empty namespace instead of just saying ".namespace". I know pmichaud was talking about a major rewrite of PGE in the future, maybe this change could be included in the laundry list of things to do during that time? -- Andrew Whitworth a.k.a Whiteknight
[perl #56972] Error in link
On Wed Jul 16 00:14:32 2008, [EMAIL PROTECTED] wrote: > On your page > > http://www.parrotcode.org/faq/ > > you have a link labelled "LANGUAGES.STATUS". I think > that the href= for this link points to a wrong page. > Please check. > > Ronald Since we're migrating to www.parrot.org instead, is this much of an issue? If not, I think we can close this ticket. -- Andrew Whitworth a.k.a Whiteknight
[perl #44457] [TODO] make sure files match test files for DYNPMCs and DYNOPs etc
On Mon Oct 13 07:31:30 2008, [EMAIL PROTECTED] wrote: > Hi Christoph, > > I send you the patch atached. > > The script with TODO block works equal without it(with TODO > gives more information and adds the "not yet implemented" leyend). > > Sincerely, > > Igor Hi Igor, This patch looks good. There's no need to make sure that every .t file has a matching .pmc or .ops file, so I took that code and those tests out. Other than that and a minor codingstd fix, the patch looks good. I've applied it and committed it as r31964. Thanks for contributing. I hope this will be the first of many contributions from you. Christoph PS: The commit can be viewed at http://www.parrotvm.org/svn/parrot/revision?rev=31964 .
Re: [perl #31633] [TODO] Allow Languages to be self contained
Will Coleda via RT schrieb: On Sat Sep 18 23:13:06 2004, coke wrote: That is: Contrive things so that no code whatsover must be maintained outside of the language specific directory. This includes: - MANIFEST - config files - ./library/Parrot/Test/* The long term goal for languages is that they'll live in their own repository, rather than being shipped with parrot's. There are a lot of languages that nobody cares enough about, to put them into a separate repository. How about creating a repository, https://svn.perl.org/parrot-little-languages, that can serve as a container for those semi-maintained languages? Having just gone through this with partcl, I don't think we need to do more in the parrot repository on this ticket; Any language that moves out just needs to have a small Configure.pl: partcl's just invokes reconfigure.pl, nothing else in parrot's repo was needed. Feedback on closing the ticket?
