Re: Suggested magic for a .. b
On Jul 28, 2010, at 1:37 PM, Mark J. Reed wrote: On Wed, Jul 28, 2010 at 2:30 PM, Chris Fields cjfie...@illinois.edu wrote: On Jul 28, 2010, at 1:27 PM, Mark J. Reed wrote: Can I get an Amen? Amen! -- Mark J. Reed markjr...@gmail.com +1. I'm agnostic ; Militant? :) ( http://tinyurl.com/3xjgxnl ) Nothing inherently religious about amen (or me), but I'll accept +1 as synonymous. :) -- Mark J. Reed markjr...@gmail.com Not militant, just trying to inject a bit of humor into the zombie thread that won't die. chris
Re: Suggested magic for a .. b
On Jul 28, 2010, at 1:27 PM, Mark J. Reed wrote: On Wednesday, July 28, 2010, Jon Lang datawea...@gmail.com wrote: Keep it simple, folks! There are enough corner cases in Perl 6 as things stand; we don't need to be introducing more of them if we can help it. Can I get an Amen? Amen! -- Mark J. Reed markjr...@gmail.com +1. I'm agnostic ; chris
Str.trans implementation
Moritz, Funny, went to IRC after seeing this brought up to respond, and didn't even notice you made this the weekly contribution to perl6! I have a Str.trans implementation on my rakudo github fork that's working and passes 20 tests: http://github.com/cjfields/rakudo A few caveats: 1) It's very simplistic and just does alternation mapping using the recent regex interpolation additions. I agree we could switch to .comb if needed. Matching against a long list of alternates using captures like /@alternates/ is very slow (one of the tests bears this out). If these are somehow stringified and maybe regex grouped they may be faster. 2) No regex matching yet, but we do have closures working. 3) :d and :s work, but I don't think these are spec'ed. 4) Simple single char transliteration should be very efficient and could be optimized as a special case. 5) A strange bug: the following test does not parse; this broke recently. Any obvious reason why this is breaking? is(nbsp;lt;gt;amp;.trans( ['nbsp;', 'lt;', 'gt;', 'amp;'] = [' ', '','','' ] ), ,The array version can map one characters to one-or-more characters); I think, in order to get regexes to work we will need a way of getting the name of the matching regex from the Match object somehow. Any idea how to do that? chris (pyrimidine)
Re: Counting characters
Would you want to use something else for that, maybe .comb? From the spec: 'The comb function looks through a string for the interesting bits, ignoring the parts that don't match. In other words, it's a version of split where you specify what you want, not what you don't want.' chris On Jan 27, 2010, at 7:08 AM, Mark J. Reed wrote: What does trans return in numeric (+) context? On Wednesday, January 27, 2010, Carl Mäsak cma...@gmail.com wrote: How is character counting done in Perl 6? In Perl 5, it is `scalar tr/CG//` if I want to count the number of Cs plus the number of Gs in a string. S05 describes tr/// in terms of the .trans function, a handsome but very different beast. Specifically, it doesn't seem to have a scalar context, with which one could count things. -- Mark J. Reed markjr...@gmail.com
Re: Module naming conventions
On Jun 2, 2009, at 5:11 PM, Daniel Carrera wrote: John M. Dlugosz wrote: So CPAN6 is basically only going to be for Parrot? What are you talking about? Did you even read my email? I said that a module might be implemented in multiple languages (see Digest::SHA VS Digest::SHA::PurePerl) and someone might have both versions installed. Daniel. Speaking as an almost complete outsider (I'm a bioperl core dev writing up a perl6 port), I find the tone of several of these more recent posts (re: CPAN6 and module conventions) counterproductive. TimToady recently posted about snippiness and 'tensegrity', so I'm not the only one sensing it. chris
Re: References to parts of declared packages
On Feb 11, 2009, at 2:46 PM, Carl Mäsak wrote:
Jon (), Jonasthan ():
If we declared, for example:
role A::B {};
Then what should a reference to A be here? At the moment, Rakudo
treats it
as a post-declared listop, however I suspect we should be doing
something a
bit smarter? If so, what should the answer to ~A.WHAT be?
I'd go with one of two possibilities:
* Don't allow the declaration of A::B unless A has already been
declared.
[...]
Please don't go with this former alternative. In a project even of
moderate size like Druid, many packages of type A::B are declared
before the corresponding A package is, for perfectly legitimate
reasons.
Agree completely. Bio::* currently has the same issue.
* A should be treated as a post-declared package.
Whatever this means, it sounds preferable. :)
// Carl
Agree again. The latter is definitely preferred.
chris
Re: odd (lexical?) issue with Rakudo/Parrot
On Jul 17, 2008, at 9:41 PM, Patrick R. Michaud wrote: On Thu, Jul 17, 2008 at 02:20:33PM -0500, Chris Fields wrote: Okay, I'll set it up so $foo = 'abcd'.match(/alpha+/) returns a Match object, and $/ would remain unset. Makes sense to me. Right now the match object is converted over to a Str; I'll take a look at the parser grammar/actions to see if that can be fixed. It is? That's odd and shouldn't be happening -- something must be incorrect there. Pm The PGE::Match appears to be converted to a Str, regardless of the invoking object type. The following is .match (in any-str.pir, with the builtins). Also, .ACCEPTS now uses .match to retrieve the Match object. # any-str.pir .sub 'match' :method :multi(_) .param pmc x .local pmc match match = x(self) .return (match) .end # Code.pir .sub 'ACCEPTS' :method .param pmc topic .local pmc match match = topic.'match'(self) $P0 = getinterp $P1 = $P0['lexpad';1] $P1['$/'] = match .return (match) .end the following is a test p6 script (results in comments): my $x = '123.456'; my $y = $x.match(/\d+/); say $x;# 123.456 say $x.WHAT; # Str say $y;# 123 say $y.WHAT; # Str - Should be Match $x = 123.456; $y = $x.match(/\d+/); say $x;# 123.456 say $x.WHAT; # Num say $y;# 123 say $y.WHAT; # Str - Should be Match say $/;# Nothing say $/.WHAT; # Failure, .match doesn't set $/ $x ~~ /\d+/; say $/;# 123 say $/.WHAT; # Match As shown above, calling .match from .ACCEPTS (either using smart match or using /\d+/.ACCEPTS($x) ) works fine, but calling .match as a method from p6 doesn't. Makes me think it's a mapping issue. chris
Re: odd (lexical?) issue with Rakudo/Parrot
On Jul 18, 2008, at 5:18 PM, Jonathan Worthington wrote: Hi, Chris Fields wrote: The PGE::Match appears to be converted to a Str, regardless of the invoking object type. The following is .match (in any-str.pir, with the builtins). Also, .ACCEPTS now uses .match to retrieve the Match object. # any-str.pir .sub 'match' :method :multi(_) .param pmc x .local pmc match match = x(self) .return (match) .end # Code.pir .sub 'ACCEPTS' :method .param pmc topic .local pmc match match = topic.'match'(self) $P0 = getinterp $P1 = $P0['lexpad';1] $P1['$/'] = match .return (match) .end the following is a test p6 script (results in comments): my $x = '123.456'; my $y = $x.match(/\d+/); say $x;# 123.456 say $x.WHAT; # Str say $y;# 123 say $y.WHAT; # Str - Should be Match Ouch! But I've tracked it down. :-) The interesting thing is that: my $x = foo; say ($x.match(/o+/)).WHAT; # Match So it fails in the assignment. And that's because infix:= to a scalar does: .sub 'infix:=' :method .param pmc source $P0 = source.'item'() assign self, $P0 .return (self) .end And calling item on a Match object gets the string that matched. Thus why we don't get the Match object. So, that's the cause; I'm not sure what the correct fix is, so I'll delegate to pmichaud on that one. We could special case it, but it doesn't feel very clean, and special cases in a hot code patch like infix:= probably ain't so desirable. Thanks, Jonathan Good catch, jonathan++ I would rather wait for the right fix so no hurry (special casing seems wrong to me as well). I'll start a ticket so it doesn't get lost in the ether. We can implement .match after that, doesn't make sense to have it pass back the wrong thing in the meantime. chris
Re: odd (lexical?) issue with Rakudo/Parrot
On Jul 16, 2008, at 1:28 PM, Patrick R. Michaud wrote: On Wed, Jul 16, 2008 at 11:20:28AM -0500, Chris Fields wrote: I have submitted a simple 'match' implementation for rakudo (method version of m//, RT#56970) and ran into an odd issue. The current version of match which works uses a tail call: .sub 'match' :method .param pmc x .return x.ACCEPTS(self) .end .ACCEPTS should be calling .match, not vice-versa. Okay, though ACCEPTS is currently defined in Code.pir (REJECTS as well). Would calling .match pertain to all executable blocks, or should we have a Regex-specific ACCEPTS that calls .match? BTW (and a bit OT, but probably related to the above), Rakudo currently indicates a regex is a Block, not a Regex; haven't looked at it in detail and don't know if it's worth worrying about for now. say /foo/.WHAT Block Essentially the difference is that smart-match sets $/, while a simple call to .match probably should not. Pm I can have .match not set $/ for now and simply return matches based on context (though I haven't messed with context much). If we get some clarification about whether .match should set $/ we can always change it later. chris
Re: odd (lexical?) issue with Rakudo/Parrot
On Jul 16, 2008, at 5:45 PM, Chris Fields wrote: On Jul 16, 2008, at 1:28 PM, Patrick R. Michaud wrote: On Wed, Jul 16, 2008 at 11:20:28AM -0500, Chris Fields wrote: I have submitted a simple 'match' implementation for rakudo (method version of m//, RT#56970) and ran into an odd issue. The current version of match which works uses a tail call: .sub 'match' :method .param pmc x .return x.ACCEPTS(self) .end .ACCEPTS should be calling .match, not vice-versa. Okay, though ACCEPTS is currently defined in Code.pir (REJECTS as well). Would calling .match pertain to all executable blocks, or should we have a Regex-specific ACCEPTS that calls .match? Forget that last bit; I'm re-reading the relevant parts of S03/S05 to get everything straight. chris
Re: odd (lexical?) issue with Rakudo/Parrot
On Jul 17, 2008, at 1:56 AM, Moritz Lenz wrote: Essentially the difference is that smart-match sets $/, while a simple call to .match probably should not. Pm I can have .match not set $/ for now and simply return matches based on context IMHO that's the wrong approach. Perl 6 tries not to return stuff based on context, but to return stuff that will behave right in every context. So if you just return a match object (that one that would usually ends up in $/ ) you should be just fine all contexts. Moritz Okay, I'll set it up so $foo = 'abcd'.match(/alpha+/) returns a Match object, and $/ would remain unset. Makes sense to me. Right now the match object is converted over to a Str; I'll take a look at the parser grammar/actions to see if that can be fixed. chris
odd (lexical?) issue with Rakudo/Parrot
I have submitted a simple 'match' implementation for rakudo (method version of m//, RT#56970) and ran into an odd issue. The current version of match which works uses a tail call: .sub 'match' :method .param pmc x .return x.ACCEPTS(self) .end If I try the following: .sub 'match' :method .param pmc x .local pmc match match = x.ACCEPTS(self); .return (match) .end I run into 'Null PMC access in set_pmc_keyed()' with ACCEPTS (below), which is failing to get the LexPad: .sub 'ACCEPTS' :method .param pmc topic .local pmc match match = self(topic) $P0 = getinterp $P1 = $P0['lexpad';1] $P1['$/'] = match .return (match) .end If I simply change match to mimic ACCEPTS, everything works fine. This makes me think something is going on with lexicals, but I'm not quite sure. Am I missing something? chris
spaces and transliteration
I am working on the transliteration method operator (trans()) for
Rakudo and wanted to get some input on how character ranges are to be
used.
Should spaces be ignored in ranges like 'A .. Z'? Currently the
implementation I have ignores those spaces but counts any other spaces
as important, so (using parrot perl6.pbc with my patch):
say Whfg nabgure Crey unpxre.trans(' a .. z' = '_n .. za .. m',
'A .. Z' = 'N .. ZA .. M')
Just_another_Perl_hacker
chris
spaces and transliteration
I am working on the transliteration method operator (trans()) for
Rakudo and wanted to get some input on how character ranges are to be
used.
Should spaces be ignored in ranges like 'A .. Z'? Currently the
implementation I have ignores those spaces but counts any other spaces
as important, so (using parrot perl6.pbc with my patch):
say Whfg nabgure Crey unpxre.trans(' a .. z' = '_n .. za .. m',
'A .. Z' = 'N .. ZA .. M')
Just_another_Perl_hacker
chris
Re: Possible GC bug in Rakudo (parrot r27449, r27451)
That also fixes the bus error I reported in rt:
http://rt.perl.org/rt3/Public/Bug/Display.html?id=54004
I went ahead and closed that ticket out. jonathan++
Thanks!
chris
On May 16, 2008, at 7:01 AM, Jonathan Worthington wrote:
Chris Fields wrote:
There appears to be a possible GC-related bug introduced to Parrot
prior to r27449 which is showing up in Rakudo. Using the following
script (courtesy of Jonathan W):
snip
After investigating a little, the breakage occurred in:
http://www.parrotvm.org/svn/parrot/revision?rev=27447
Basically, protoobjects didn't handle the switch-over to using the
new copy opcode for :pasttype('copy') nodes properly. Fixed in
r27539, so this example runs again.
Thanks,
Jonathan
Christopher Fields
Postdoctoral Researcher
Lab of Dr. Marie-Claude Hofmann
College of Veterinary Medicine
University of Illinois Urbana-Champaign
Possible GC bug in Rakudo (parrot r27449, r27451)
There appears to be a possible GC-related bug introduced to Parrot
prior to r27449 which is showing up in Rakudo. Using the following
script (courtesy of Jonathan W):
class Foo {
has $.x;
method boo { say $.x }
}
class Bar is Foo {
method set($v) { $.x = $v }
}
my Foo $u .= new(x = 5);
$u.boo;# 5
$u= Bar.new(Foo{ x = 12 });
$u.boo;# 12
$u.set(9);
$u.boo;# 9
'perl6 obj_init.p6' results :
5
Segmentation fault
'parrot ~/src/parrot/languages/perl6/perl6.pbc obj_init.p6' results:
cjfields:tests cjfields$ parrot ~/src/parrot/languages/perl6/perl6.pbc
obj_init.p6
5
get_pmc_keyed() not implemented in class 'Undef'
current instr.: '_block10' pc 137 (EVAL_13:46)
called from Sub 'parrot;PCT::HLLCompiler;eval' pc 785 (src/PCT/
HLLCompiler.pir:458)
called from Sub 'parrot;PCT::HLLCompiler;evalfiles' pc 1067 (src/PCT/
HLLCompiler.pir:587)
called from Sub 'parrot;PCT::HLLCompiler;command_line' pc 1246 (src/
PCT/HLLCompiler.pir:676)
called from Sub 'parrot;Perl6::Compiler;main' pc 9647 (perl6.pir:187)
'parrot -G ~/src/parrot/languages/perl6/perl6.pbc obj_init.p6' results:
5
get_pmc_keyed() not implemented in class 'Any'
current instr.: '_block10' pc 137 (EVAL_13:46)
called from Sub 'parrot;PCT::HLLCompiler;eval' pc 785 (src/PCT/
HLLCompiler.pir:458)
called from Sub 'parrot;PCT::HLLCompiler;evalfiles' pc 1067 (src/PCT/
HLLCompiler.pir:587)
called from Sub 'parrot;PCT::HLLCompiler;command_line' pc 1246 (src/
PCT/HLLCompiler.pir:676)
called from Sub 'parrot;Perl6::Compiler;main' pc 9647 (perl6.pir:187)
Note difference with Any (-G) vs Undef (no -G). Not sure if it means
anything.
-chris
