Re: [perl #48014] [DEPRECATED] PMC union struct
Allison Randal wrote: Christoph Otto via RT wrote: I'm running into a snag trying to implement this. It turns out that many lines which use the PMC_x_val macros use them on different types of PMCs, especially parents and children (e.g. FixedPMCArray and ResizablePMCArray). There are also some instances where the PMCs with a related purpose but no inheritance (e.g. RetContinuation and ExceptionHandler) have the unionval used in the same way on a line of code. What's the right way to fix these cases to use the GETATTR/SETATTR macros? Tough to answer without looking at the code, but... The GET_ATTR/SET_ATTR macros will work on inherited attributes as well as child attributes. (Actually, at the moment you're required to declare all parent attributes in the ATTR list before the child attributes, so inherited attributes *are* child attributes.) If two unrelated PMCs are being called in the same line of code, that probably means it should really be a vtable function call instead of direct access into the data struct. Allison When I say "attributes", I mean the things that are declared in .pmc files right after the pmclass line, e.g. ATTR INTVAL foo_refs; /*foo refcount*/ These do not appear to be passed down to extending PMCs. This is a problem for e.g UnManagedStruct/ManagedStruct, where PMC_int_val is used the same way by both PMCs. For example, say that I add ATTR INTVAL struct_size; to UnManagedStruct. It's possible to replace some instances of PMC_int_val with VTABLE_get_integer in these two PMCs, but I can't use GETATTR_UnManagedStruct_struct_size in UnManagedStruct's get_integer VTABLE function because ManagedStruct uses UnManagedStruct's get_integer, but doesn't have its ATTRs. It would be possible to add the same ATTR to ManagedStruct and make sure that it had its own get_integer VTABLE function. Unfortunately this would mean more code duplication and would negate some of the benefits of allowing PMCs to extend each other. What I'd like is for the pmc2c code to be smart enough to make ATTRs from an extended PMC accessible by an extending PMC through the GET_ATTR/SET_ATTR macros. If I could get a description of how such a patch should behave from our architect, I'd be glad to write one up and submit it for review.
Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)
The Prelude could be helpful for training. I've been trying to work out a logical path into Perl 6 for quite some time, not least because it's been a moving target. If there's a set of definitions that a computer can follow, humans should be able to move along that path too. -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
[perl #62462] rakudo -V does not work
# New Ticket Created by Gabor Szabo # Please include the string: [perl #62462] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=62462 > ga...@notebook:~/work/parrot$ ./parrot languages/perl6/perl6.pbc -v This is Rakudo Perl 6, revision 35597 built on parrot 0.8.2-devel for i486-linux-gnu-thread-multi. Copyright 2006-2008, The Perl Foundation. ga...@notebook:~/work/parrot$ ./parrot languages/perl6/perl6.pbc -V Unable to open filehandle current instr.: 'parrot;PCT;HLLCompiler;evalfiles' pc -4093858 ((unknown file):-1) called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc -4094893 ((unknown file):-1) called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc -7188 ((unknown file):-1) called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1256 (src/PCT/HLLCompiler.pir:683) called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1456 (src/PCT/HLLCompiler.pir:778) called from Sub 'parrot;Perl6;Compiler;main' pc 21112 (perl6.pir:158) Gabor Szabo
[perl #62474] Rakudo forgets to clone when pushing xx'ed values to an array
# New Ticket Created by "Carl Mäsak" # Please include the string: [perl #62474] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=62474 > $ perl6 -e 'my @a = "a" xx 5; @a[1] = "b"; say @a' abaaa $ perl6 -e 'push my @a, "a" xx 5; @a[1] = "b"; say @a' b $ svn info | grep Revi Revision: 35707
[perl #62478] C-style for loop does not give an error
# New Ticket Created by Gabor Szabo
# Please include the string: [perl #62478]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=62478 >
for (my $i = 1; $i <= 3; $i++) { say $i; }
prints 2 instead of giving an intelligent error message that one should use loop
or better yet for 1..3 -> $i { }
Gabor
Re: Rakudo leaving the Parrot nest
On Jan 14, 9:01 pm, pmich...@pobox.com (Patrick R. Michaud) wrote: Sorry for the 'tldr' reply... > Source code repository > -- > This is the immediate issue at hand, because we need to move Rakudo > out of the Parrot repository so that it can cleanly move to its new > home at parrot.org. I assume you're saying the parrot project will be moving from svn.perl.org to its own repo somewhere on the parrot domain. > Currently Rakudo Perl lives at > http://svn.perl.org/parrot/trunk/languages/perl6/, while the > spectest suite (on which development/testing depends) > lives at http://svn.pugscode.org/pugs/t/spec/. I propose a restructuring/divestiture of the pugscode and rakudo code repositories, as follows: 1. Centralize/reorganize the implementation-independent/agnostic resources, documentation, and tools under a new repository, which could be hosted at one of the perl6-related domain names I have, such as git:// (and http(s)://www.perlsix.org/git/perl6 for git-http-*), with automatic one-way (or two-way! with user impersonation) replication/mirroring to svn and/or bzr on launchpad.net/perl6. This repo would include both the human- readable (!) language specifications, and the machine- readable/testable language specifications (the spec tests), the standard grammar and its related tools, any global prelude, and all the other implementation-nonspecific items. The current pugscode user accounts can be migrated to whatever backs the authentication. 2. Leave the current svn.pugscode repo as is (except for the items listed above), so that all the other implementations and Perl6-related miscellany stored there can be migrated over to new repos as necessary. 3. Host the rakudo repository in git or whatever [else] is selected following the same convention, git/http(s)://www.perlsix.org/git/rakudo and http(s)://www.perlsix.org/svn/rakudo Use the same authentication store as http(s)://www.rakudo[perl].org (see below)... perhaps integrated with single-sign-on and unified-sign-on systems at launchpad.net, OpenID, BitCard, etc. > Many people have strongly suggested that we switch to > using "git" as our version control system. At the moment I'm > neither strongly in favor of nor strongly opposed to switching > version control systems, but we have to recognize that at least > two of Rakudo's "dependencies" (Parrot and the spectest suite) > are using Subversion and are likely to remain that way for > a while. We don't want to require non-developers to install a > lot of different source code control systems simply to run and > test the latest incarnation of Rakudo Perl. No, but for this use case, snapshots of the requisite Parrot release and then the client for whatever scm system Rakudo uses should be sufficient, since the spectest suite can be hosted in the same format, even if merely a one-way mirror. > Web site / blog / wiki > -- > Currently Rakudo really does not have a dedicated website > providing basic information about it. There is the > http://rakudo.org/site, but it's currently more of a > blog than a true web site. For example, someone visiting > rakudo.org would not be able to easily find out how to > download and run Rakudo Perl. As the site of a major implementation of a multi-implementation programming language, the www.rakudo(perl).* site(s) need to be similar in content to the sites, for the following use cases: www.ruby-lang.org www.python.org www.php.net 1. Obtain/Develop-ish category a. Download binaries/installer links b. Linux/BSD distribution/packages links (deb, rpm, launchpad) c. Build-from-source walkthrough (including dependencies) d. Contributor/developer initiation/training (1) git/svn training/walkthrough (2) bug-tracking system (launchpad.net?) links/tutorial (3) mailing list descriptions e. Spec-test progress/history/graphics f. Release announcements, developers' blog g. IRC links, logs h. gitweb and/or SVN::Web intefaces i. PCT tutorials/documentation 4. Discover-ish category a. Rakudo documentation, tutorials b. [Links to] Perl 6 documentation, specifications, tutorials c. User/community support forums & mailing lists (exposed through http, smtp, and nntp) d. Links to and/or aggregates of other/related blogs e. Links to Perl Foundation & development/benefactor news f. Link to www.perl.org or replicate much of its content g. Interactive web terminal to try out rakudo, "live" h. Links to sites/projects using rakudo I recommend hosting this site on the WebGUI CMS on a VPS I'll provide; I'll also provide a $30/year GoDaddy SSL certificate in perpetuity for privacy/security, though since it's an open-source project, the first year of the SSL cert may be free from GoDaddy. I have a VPS where the site (including all SCM repos) could be hosted; others' VPSes could provide backup destinations. One option is to set the http://www.rakudo.org page to redirect to http://w
Re: A Logo design for Rakudo Perl 6
> Justin Simoni You may have to be careful about the camel imagery; I think O'Reilly have a legal lock on camel-related graphics in association with Perl. Richard Dice can probably give you more details. -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
[perl #62476] TODO 1..8:by(2) not yet implemented
# New Ticket Created by Gabor Szabo
# Please include the string: [perl #62476]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=62476 >
for 1..8:by(2) -> $i {
say $i;
}
Gabor
Roles definition
Hi there!
I use role to mix in some functionality for testing:
my $s = November::Storage::File.new does Testing;
And I have Role definition _after_ this:
role Testing { ... }
Now this is fall with:
Null PMC access in isa()
current instr.: 'infix:does' pc 20660 (src/builtins/op.pir:403)
called from Sub '_block14' pc 108 (EVAL_20:47)
And all work again if I put definition _before_ instant and `does`.
It looks like bug for my, but mb this is right behaviour?
Thank you!
Ilya
Re: Roles definition
Илья (>):
> I use role to mix in some functionality for testing:
>
> my $s = November::Storage::File.new does Testing;
>
> And I have Role definition _after_ this:
>
> role Testing { ... }
>
> Now this is fall with:
>
> Null PMC access in isa()
> current instr.: 'infix:does' pc 20660 (src/builtins/op.pir:403)
> called from Sub '_block14' pc 108 (EVAL_20:47)
>
> And all work again if I put definition _before_ instant and `does`.
>
> It looks like bug for my, but mb this is right behaviour?
The 'Null PMC access' certainly isn't right, but even modulo that, the
role must be declared before it's being used. Jonathan said that it
should really be a compile error.
Generally, in Perl 6, one has to declare identifiers in some way
before referring to them.
// Carl
Re: [perl #62478] C-style for loop does not give an error
On Sat, Jan 17, 2009 at 5:44 PM, via RT Gabor Szabo
wrote:
> for (my $i = 1; $i <= 3; $i++) { say $i; }
>
> prints 2 instead of giving an intelligent error message that one should use
> loop
> or better yet for 1..3 -> $i { }
A warning, surely? As far as I can tell, the above is perfectly legal
code. Presumably "say $_" would also yield 2, since I gather the for
is looping over ($i).
--
Mark J. Reed
Re: A Logo design for Rakudo Perl 6
Thank you for pointing this out. This is a reality I've lived with for so long that it didn't even cross my mind to caution others (who haven't been so tied up in the legal and organizational aspects of Perl) when this thread appeared. O'Reilly is the only organization that can have trademarks that incorporate a camel in reference to the Perl programming language. This statement is a first-order approximation, but damn good one. Basically, the message is: stay away from using camels. Cheers, - Richard On Fri, Jan 16, 2009 at 12:12 PM, wrote: > > Justin Simoni > > You may have to be careful about the camel imagery; I think O'Reilly have > a legal lock on camel-related graphics in association with Perl. Richard > Dice can probably give you more details. > > > -- > > Email and shopping with the feelgood factor! > 55% of income to good causes. http://www.ippimail.com > >
[perl #62472] Rakudo fails to parse a my declaration in an if statement
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #62472]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=62472 >
rakudo: if 5 > my $a = 4 { say $a }
rakudo 35707: OUTPUT«Unable to set lvalue on PAST::Val node [...]
it works if I use parens, but what does that error mean?
Hmm.
masak: What's the next line down in the backtrace?
called from Sub 'parrot;PAST;Compiler;as_post' pc 4013
(src/PAST/Compiler.pir:986)
Ah, damm. It's failed in the PAST->POST.
* masak submits rakudobug
Method Postfix sleuthing...
Here's some more sleuthing and differences between STD.pm and Synopsis
3:
Methodcall precedence operators in STD.pm seem to include this set:
.meth - single call
.?meth - 0 or 1 call
.+meth - 1 or more call
.*meth - 0 or more call
.=meth - mutating call
.:meth - ?? what is this
.^meth - meta call
!meth - private call
.^!meth - private meta call
S03 doesn't have the private versions.
S03 defines .:prefix as the dotted form of a prefix operator, but that
is clearly not what STD.pm parses.
?? What does <.:> mean?
Now, meth is really , which can be one of three things:
a method name (or variable with such in it)
a postfix operator
which in this context is just <++>, <-->, and their hyper
forms
?? I think I heard that in this context, won't be considered an
operator
though STD.pm parses it this way for now
a postcircumfix
while is one of (~) [~] {~} <~> <<~>> «~»
S03 doesn't explain that the postcircumfix form can be used with any
of the Methodcall operators, it only calls out <.>.
STD.pm actually treats differently here - it only takes a method
name.
?? Is <.^!> meant to be different in this regard from ?
?? Also, only matches the token privop -- shouldn't <.^!> match
that production as well?
The expansion for a method name (really ) includes not only
the name of the method, but also optionally the arguments, via either
'(' ~ ')' form, '.(' ~ ')' form, or ':' invocant marker form. This
later one has me stumped: Won't it mean that the ':' as invocant
marker will have different precedence depending on if it is preceded
by an explicit dotted method call vs. a computed expression... I'm not
sure I can think of a case that the parses would in fact be different,
but why the two different ways to parse this use of <:>?
- mark
Re: [perl #48014] [DEPRECATED] PMC union struct
Christoph Otto wrote: Allison Randal wrote: (Actually, at the moment you're required to declare all parent attributes in the ATTR list before the child attributes, so inherited attributes *are* child attributes.) When I say "attributes", I mean the things that are declared in .pmc files right after the pmclass line, e.g. ATTR INTVAL foo_refs; /*foo refcount*/ These do not appear to be passed down to extending PMCs. This is a problem for e.g UnManagedStruct/ManagedStruct, where PMC_int_val is used the same way by both PMCs. Right, at the moment it is absolutely required that the first ATTR declarations of the child are manual copies of the ATTR declarations of the parent. Otherwise, the inheritance won't work at all. (Ultimately, inheritance will automatically copy the parent's attributes and prepend them onto the front of the child's attribute list, but at the moment it has to be done manually.) What I'd like is for the pmc2c code to be smart enough to make ATTRs from an extended PMC accessible by an extending PMC through the GET_ATTR/SET_ATTR macros. If I could get a description of how such a patch should behave from our architect, I'd be glad to write one up and submit it for review. The fix actually goes in a different place. The GET_ATTR/SET_ATTR macros will be correctly generated for all child attributes. What really needs to change is to add the parent's attribute list to the child's attribute list during PMC parsing in Pmc2c. Take a look at lib/Parrot/Pmc2c/Parser.pm. (I can give more specific guidance after the release, working on milestone items at the moment.) Allison
Re: [perl #41825] [BUG] morph vtable override not working in PIR
Jonathan Worthington wrote: I'm curious - is anyone else doing a HLL on Parrot that uses morph? If nobody is, is it worth spending time on, or even worth keeping? 'morph' was added specifically for the Perl 5 behavior of changing types when assigned to. But really, a more accurate representation of Perl 5 behavior would be to have a single Scalar PMC that can act as a string, int, or number. So, yes, it's possible that 'morph' could be deprecated. It needs a review of current uses to make sure that they're either unnecessary (most examples I've seen are), or can be cleanly substituted with something else. Allison
spelunking in the meta-ops in STD.pm
I was looking through STD.pm at the parsing of metaops. I was
exploring to see if the legal metaops for a given operator could be
notated on the operator chart. What I found was some oddness...
op= (infix_postfix_meta_operator:sym<=>)
The internal op is restricted to be not :assoc('chain') and
not :assoc('non')... But, the various precedence groupings have a
property, :assign on them that is never used. Yet, this property seem
like just the thing. To my eye, :assign seems like the right set of
operators that are expected to be used here. The current test is too
liberal, allowing things like ,= and ==>>= (gasp!)
!op (infix_prefix_meta_operator:sym)
---
The internal op is restricted to be :assoc('chain'), or not have a
default :assoc and be :bool. This seems overly defined: The only
operators with :assoc('chain') have :bool. Like above, I think the
internal op should be restricted on the :bool property alone.
[op] (prefix_circumfix_meta_operator.reduce)
This internal op is restricted to not have :assoc('non') nor be at the
same precedence level as %conditional. That later test strikes me as
strange. The restriction should be not having :assoc('chain')
nor :assoc('non').
Now - the classes of what can be applied to what, especially
considering other metaops, is a bit tangled:
>>op -- op can be any >>op, postfix, dotty, privop, or postcircumfix
the later is odd: what could >>(...) mean?
op<< -- op can be any prefix, a [op], or another >op<< -- op can only be a (simple) infix operator
[op], XopX -- op can an infix, or !op or XopX or >>op<<
or, put another way, any simple or complex infix op, except op=
I understand why op= and !op have highly restricted internal op sets.
But why should >>op<< be so restricted as well? It means that >><=<<
and >>~~<< are legal, but >>!<=<< and >>!~~<< are not.
And, if the prefix and postfix hyper metaops can be nested... then why
not the infix: + anybody? (Not, mind you, that *I* would
advocate for them, or such exotic beasts as [X>>+<
Lastly, the token for [x] (prefix_circumfix_meta_operator.reduce) has
an oddity that it allows an optional trailing << (acutally, only the
Unicode version of that!). I'm not sure why the prefix hyper metaop is
parsed here... especially since the code for token PRE clearly parses
this construction.
- Mark
