perl6-projects.org/ | nopaste: sial.org/pbot/perl6 | evalbot: 'perl6: say 3;' | irclog: irc.pugscode.org/
Set by mncharity on 25 March 2009.
jnthn How's the unicode props stuff going, by the way? 00:00
00:06 FurnaceBoy joined 00:11 felipe joined 00:15 Doubi left
pmichaud ooops, had to run to store. 00:31
unicode stuff is going very well, although ICU is a bit frustrating at times (the docs, not the implementation)
pugs_svn r26141 | hinrik++ | [util/perl6.vim] the slashes in //= are part of an operator, not a pattern 00:39
r26142 | hinrik++ | [util/perl6.vim] timestamp, etc
00:54 frew|wor1 joined 01:00 Whiteknight left 01:08 Doubious left
pugs_svn r26143 | lwall++ | plant some camelias 01:11
01:19 justatheory left
pugs_svn r26144 | autarch++ | Fix a very tiny typo in Temporal::Datetime.iso8601 01:19
01:19 justatheory joined
pugs_svn r26145 | pmichaud++ | [t/spec]: More Unicode property tests refactored from properties.t . 01:20
01:23 dukeleto left 01:26 justatheory left
pmichaud The unicode properties tests for S05 include things like <isInArabic>, <isInArrows>, etc., for checking if codepoints are members of a specific block. But Synopsis 5 doesn't mention <isIn...> -- shall I assume that it's supposed to? 01:37
(The "InArabic", "InArrows", etc. categories appear to be a p5-ism.) 01:38
01:40 frew|wor1 left 01:41 kst joined 01:45 justatheory joined 01:46 payload left
pugs_svn r26146 | pmichaud++ | [t/spec]: Last bit of refactoring for Unicode properties.t . 01:47
r26147 | pmichaud++ | [t/spec]: Once again, failing to plan is planning to fail (properties-derived.t) 01:48
TimToady pmichaud: I don't think those turned out to be terribly useful 01:58
pmichaud how about isBidiL, isBidiES, etc? 01:59
TimToady doesn't the Bidi stuff come from the consortium? 02:02
pmichaud they don't appear to be standard property names
the standard names are L, ES, etc. in the bidi class, if I'm reading this right.
I think adding "Bidi" to the front might be another p5-ism
for example: 02:03
002B;PLUS SIGN;Sm;0;ES;;;;;N;;;;;
the "ES" indicates the bidi class of the plus sign.
TimToady I don't know if I added that or someone else 02:04
pmichaud well, I just about have them working, so I'll leave them in for now. If we decide they're not part of the spec, we can remove the tests from the suite.
TimToady whatever looks like it might be useful...
02:04 brunov is now known as brunoVi
pmichaud the InArabic, InArrows, etc., tests for block membership contains ~670 tests. 02:05
(which Rakudo mostly passes now :-)
pugs_svn r26148 | pmichaud++ | [t/spec]: Unfudge Bidi* tests in properties-script.t . 02:10
02:10 dukeleto joined 02:11 brunoVi is now known as brunov 02:15 payload joined 02:30 cdarroch left
cspencer rakudo: say 1..5.int 02:38
p6eval rakudo 0a9dd6: OUTPUTĀ«12345ā¤Ā»
cspencer rakudo: say (1..5).int
p6eval rakudo 0a9dd6: OUTPUTĀ«5ā¤Ā»
02:44 payload left
dalek kudo: 85ab143 | pmichaud++ | src/ops/perl6.ops:
Refactor is_uprop opcode a bit.
 02:58
kudo: a2bb078 | pmichaud++ | :
Merge branch 'master' of [email@hidden.address]
kudo: f545fee | pmichaud++ | src/ops/perl6.ops:
Add "Bidi" and "In" support to unicode character properties.
02:59 sitaram joined 03:09 sri_kraih joined 03:14 FurnaceBoy left
pugs_svn r26149 | pmichaud++ | [t/spec]: Remove properties.t (it's been refactored into four separate files). 03:20
03:21 dukeleto left 03:23 justatheory left 03:27 Kisu left 03:38 dukeleto joined
dalek kudo: 4ae560c | pmichaud++ | t/spectest.data:
Update spectest.data with properties.t tests.
 03:40
03:43 hercynium left 03:46 Kisu joined 03:48 dukeleto left 03:52 [particle] left 03:53 [particle] joined 04:11 skids left
cspencer pmichaud: ping 04:16
04:17 cspencer left 04:28 sephee left 04:29 dukeleto joined 04:31 Tene_ joined 04:34 dukeleto left 04:35 sephee joined, dukeleto joined 04:38 nekobaka joined 04:39 frew|wor1 joined 04:41 frew|wor1 left 04:42 kst left, kst joined 04:45 Tene left 04:46 araujo left 04:49 araujo joined 04:52 dukeleto left 05:22 [particle]1 joined 05:27 [particle]1 left 05:28 orafu joined 05:36 [particle]1 joined 05:40 [particle] left, dukeleto joined 05:46 brunov left 06:03 agentzh left 06:06 agentzh joined 06:11 TimToady left 06:12 diakopter left
moritz_ good morning 06:14
pmichaud good morning 06:16
pmichaud drum rolls....
moritz_ I've seen you've been busy
pmichaud drum rolls a bit more... 06:17
(waiting for dalek)
dalek kudo: e05aff7 | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 354 files, 10224 passing, 0 failing
 06:18
moritz_ woot!
I CAN HAZ 10k!
eiro hello world
moritz_ pmichaud++ 06:19
06:21 justatheory joined
pmichaud rakudo: say 10224/15627 06:23
p6eval rakudo 4ae560: OUTPUTĀ«0.654252255711269ā¤Ā»
pmichaud 65%
moritz_ rakudo: printf '%0.2f', 10224/15627 06:24
p6eval rakudo 4ae560: OUTPUTĀ«0.65Ā»
06:27 justatheory left
pmichaud okay, time for bed here. More writing tomorrow. 06:30
moritz_ good night
pugs_svn r26150 | moritz++ | [t/spec] unfudge tests for typed arrays 06:52
r26151 | moritz++ | [t/spec] unfudge type-based.t 07:04
07:17 masak joined
masak hello #perl6, you wonderful channel you. 07:18
lambdabot masak: You have 2 new messages. '/msg lambdabot @messages' to read them.
masak @massage
lambdabot jnthn said 7h 30m 30s ago: maybe if you have time take a look at rt.perl.org/rt3/Ticket/Display.html?id=62968 and see if you think we're looking good on that one now.
jnthn said 7h 30m 4s ago: we may want some tests for it if so; scribble on the ticket if there's still issues there :-)
masak so, 10k eh?
\o/
07:22 Doubi joined 07:25 iblechbot joined
moritz_ rakudo: class O { method oO { } }; try { given O.new { .oO( ... ) } }; say "alive" 07:29
p6eval rakudo e05aff: OUTPUTĀ«aliveā¤Ā»
moritz_ YaY, .oO( ... ) is valid Perl 6 ;-)
eiro lol! right! 07:30
moritz_ afk 07:31
07:32 kst left, kst joined 07:33 kidd` joined 07:38 ejs joined
Matt-W Morning 07:48
07:48 ejs left
masak tips hat 07:49
Matt-W masak: I did some Form last night!
masak Matt-W: I saw, in the backlog!
kudos.
Matt-W Unfortunately after I did some useful things I got sidetracked trying to figure out an algorithm for full justification
Which was probably not a useful use of my time
because it seems ridiculously complicated, and it causes a null pmc access 07:50
masak Matt-W: what's the part of full justification that you considered?
Matt-W I suppose it might at least help me find a rakudo bug
07:51 meppl joined
masak Matt-W: seems to me full justification boils down to line breaking + inserting extra spaces as evenly/invisibly as possible. 07:54
07:59 DemoFreak joined 08:02 szabgab left
moritz_ rakudo: class A { has Int @.a is rw }; my $x=A.new; $x.a = (2, 3, 4); say $x.a.perl 08:04
p6eval rakudo e05aff: OUTPUTĀ«[2, 3, 4]ā¤Ā»
moritz_ rakudo: class A { has Int @.a is rw }; my $x=A.new; $x.a = (2, 3, 4); $x.a.push: 'foo'; say $x.a.perl
p6eval rakudo e05aff: OUTPUTĀ«[2, 3, 4, "foo"]ā¤Ā»
moritz_ masak: care to submit? :-) 08:05
masak bug.
masak submits
moritz_ rakudo: class A { has Int @.a is rw }; my $x=A.new; $x.a = <foo bar> say $x.a.perl
Matt-W masak: yes, that's basically it
p6eval rakudo e05aff: OUTPUTĀ«Statement not terminated properly at line 1, near "say $x.a.p"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)ā¤Ā»
moritz_ rakudo: class A { has Int @.a is rw }; my $x=A.new; $x.a = <foo bar>; say $x.a.perl
p6eval rakudo e05aff: OUTPUTĀ«["foo", "bar"]ā¤Ā»
Matt-W masak: it's more complicated if you have a proper layout system of course
masak Matt-W: 'proper layout system'? 08:06
08:06 szabgab joined
Matt-W masak: as in one where you can adjust letter spacing and things 08:06
masak yes. ouch,
moritz_ you mean a rendering engine?
like pango?
08:07 agentzh left
sitaram moritz_: in the @list.sort example within the comments at perlgeek.de/blog-en/perl-6/y-combin...writeback, did the spaceship operator disappear due to HTML interpretation at some point? I see only dollar-hat-b-space-dollar-hat-a. Normally I wouldn't ask but am trying to learn perl 6, and the syntax is new enough that I want to make sure this isn't some new way of specifying a sort sub 08:11
(I assume that page is yours; apologies if not)
moritz_ sitaram: it is. Let me take a look... 08:12
08:13 alexn_org joined
moritz_ sitaram: yes, it should be $^a <=> $^b 08:14
sitaram thanks :-)
little things matter when taking baby steps into a new language, especially after a long gap!
moritz_ apologies for the inconvience 08:15
I've since then fixed the blog software
sitaram (and actually, for that specific point you were making, the b should come first
moritz_ (and in the mid term or long run I'll switch over to perlblog.org)
sitaram moritz_: not a problem at all! thanks for your help 08:16
(and I was so caught up in grokking that example I didn't even look one para down, where you already said that the blog software ate the < and > signs (blush!) 08:18
moritz_ :-)
u haz a spazeship but i eated it 08:19
08:21 ejs joined 08:29 ejs left 08:30 ejs joined 08:34 agentzh joined
Matt-W Wow 08:36
10,000 spectests
everyone++
sitaram aah -- now I know what that 10k meant...! 08:40
(still new; too new... sigh!)
08:41 alexn_org left 08:51 payload joined 09:02 szabgab left
moritz_ sitaram: if there are more terms that you don't understand, don't hesitate to ask 09:04
09:04 bacek_ left 09:05 szabgab joined
sitaram will do; thanks! 09:11
this sounded like something I could guess or would come through eventually :)
09:12 hanekomu joined 09:26 DemoFreak left 09:32 hanekomu left 09:36 riffraff joined
jnthn morning folks 09:50
moritz_ good morning jnthn 09:51
jnthn: I found you another bug... types on array attributes don't work ;-) 09:52
lunch&
jnthn pmichaud++ # 10,000!! 09:54
moritz_: Ah, yes...that's not so surprising.
10:03 payload left 10:05 bacek joined 10:16 payload joined 10:30 schinkelm joined 10:36 payload left
pmichaud It's just 10,000, not 10,000! (which would be a huge number :-) 10:45
jnthn pmichaud: Did you actually, like, sleep? ;-) 10:46
pmichaud for a couple of yours, yes. 10:47
jnthn :-)
pmichaud *hours
(obviously didn't sleep much -- can't type again :-)
jnthn Ah, planned sleep deprevation for beating NPW jet-lag. ;-)
pmichaud Paula woke up and so I'm now able to make YAPC::NA travel arrangements (because I know her schedule) 10:48
10:52 orafu left 10:53 davidad left 11:00 DemoFreak joined 11:02 payload joined 11:04 schinkelm left 11:11 bacek left
jnthn Hmm. The tests in svn.pugscode.org/pugs/t/spec/S06-ad...res/wrap.t seem to think that .wrap gives you back some kind of invokable handle. 11:13
However, the specs say nothing like that.
jnthn goes with the spec 11:14
moritz_ i think there's a different method that does that 11:20
feel free to correct the tests
jnthn moritz_: Aye, will do. 11:23
11:25 payload left, payload joined 11:28 kidd` left
masak rakudo: my @a = 1..4; say @a[1..*].perl 11:46
p6eval rakudo e05aff: OUTPUTĀ«[2, 3, 4, undef]ā¤Ā»
jnthn masak: I worked out why we get that wrong this morning.
masak nice.
jnthn masak: But it didn't lead me to realizing an obvious fix.
Basically though we end up substituting * for the number of arguments. 11:47
So you're not actually constructing an infinite range, which is what it probably should do.
masak mm.
jnthn But instead the finite range 1..@a.elems
masak * has many meanings in indices.
moritz_ instead of 1..@a.end
jnthn Which then gives you an off-by-one.
Amusingly, 1..^* would probably work. ;-) 11:48
masak aye.
rakudo: my @a = 1..4; say @a[1..^*].perl
p6eval rakudo e05aff: OUTPUTĀ«[2, 3, 4]ā¤Ā»
jnthn Yeah
I hadn't tried it, just looked at the code...
moritz_ for *-1 to work you have to pass it @a.elems
so you need to special-case 1..*
jnthn Maybe. 11:49
But *-1 should by itself construct a block { $_ - 1 } IIUC
Whereas 1..* would not?
Or does 1..* count in with the operators where * forms a block too?
moritz_ maybe it should construct a block { 1.. $_ } - but then you'd get the offbyone again 11:50
jnthn Ugh. That would can probably go more than one way. :-|
moritz_: Well, exactly...
moritz_: We're faking constructing that block now.
But getting the semantics as if we had.
masak why faking it? 11:59
jnthn masak: 'cus we aren't doing the general block-building thingy. 12:01
masak ok.
jnthn rakudo: say (*-1).WHAT
p6eval rakudo e05aff: OUTPUTĀ«Use of uninitialized valueā¤Numā¤Ā» 12:02
jnthn Output should be Block
masak * -- the blockless block. 12:07
12:11 s1n left, cls_bsd left, jnthn joined, s1n joined, cls_bsd joined, Maddingue joined, buu joined, ingy joined, irc.freenode.net sets mode: +o jnthn
dalek kudo: 43b9e57 | jnthn++ | src/classes/Routine.pir:
First cut of wrap and unwrap.
 12:20
pmichaud I didn't implement the closure-semantics of Whatever yet (because they weren't defined at the time).
What Rakudo does now was just a guess in order to get things to work while the spec was being fleshed out :-) 12:21
jnthn pmichaud: Sure, that bit of spec came after the postcircumfix work. :-) 12:23
pmichaud: Thing is, I ain't completley sure even changing it to be what the spec says will deal with the 1..* issue.
pmichaud: BTW, for the 1 + * becomes { 1 + $_ } stuff, any thoughts on how to implement it? 12:27
I see we can go two ways: multi variants recognizing a Whatever, or compiler transform.
12:30 skids joined 12:36 payload left
pmichaud I think that TimToady was describing it as multi variants. 12:38
I'd have to review the logs... but I'm pretty sure that's what it was.
also, fwiw, in yesterday's design meeting TimToady mentioned that he had been thinking of leave semantics as not being exception-based 12:40
I meant to ask at #parrotsketch about subroutine exit triggers but forgot. :-(
12:55 payload joined
jnthn If they're a bunch of multi variants, then I guess we want to generate them just as we generate the junctional variants. 12:56
pmichaud makes sense. 12:57
jnthn If I can ever get to the bottom of what I've screwed up in implementing callwith so wrap is actually useful, I might pop those in... 12:58
13:02 bacek joined
dalek kudo: 508a18c | (Moritz Lenz)++ | t/spectest.data:
fix typo in t/spectest.data, moritz--
 13:06
13:11 Khisanth left
moritz_ since Str.reverse is Str.flip now - shouldn't it be also findex instead of rindex? ;-) 13:12
pmichaud how many people want to find their ex?
moritz_ actually index and rindex look like they could be unified to one function, with a named arg to decide the search direction
with :backwards = Bool::False or so 13:13
pmichaud actually, we could make all of the builtins into a single function with a named arg to decide the function. :-)
13:13 Doubious joined
moritz_ pmichaud: syscall() 13:13
pmichaud I propose that this single function be called ""
masak convenient. 13:14
moritz_ ;-)
masak then you can call it with just .
pmichaud and that the first identifier following the "" will be the function identifier
13:14 Tene_ left
moritz_ and if you leave that out, it returns a junction of the results of all builtins ;-) 13:15
pmichaud heh
moritz_ but to get back to serious language design busines, I don't think that index and rindex are sufficiently distinct to warrant a different sub each
they might be implemented quite differently, but from a language perspective we shouldn't care 13:16
masak moritz_: I think it's good to have them separate.
moritz_ just my 2Ā¢
masak: why?
masak rindex is a good deal shorter than anything you can do with named args.
it's huffmannized. 13:17
moritz_ how often do you use it?
masak moritz_: perhaps 10% as often as index.
maybe less.
I don't use either much.
Perl 5/6 often has better ways to manip strings.
13:17 cognominal left
moritz_ aye 13:17
let's see what TimToady thinks when he returns 13:18
masak maybe if you called the named arg :r...
moritz_ that would be fine by me as well
masak but even then, it feels a bit like premature abstraction to me.
moritz_ and like justified abstraction to me ;-) 13:19
masak $abstraction.is-in( $beholder.eye )
moritz_ ::a āˆˆ Eye of Beholder 13:20
remeber, ::-sigiled variables do Abstraction anyway ;-) 13:21
masak perhaps there's a middle ground here. we could add the named arg to index, but keep rindex and add a :forwards = False to it... :P
moritz_ ;-)
pmichaud afk for a short while
moritz_ $str.rindex($s, :forward) :/
masak exactly. 13:22
moritz_ :forward, :flip, :reverse) 13:24
masak no-one can blame us for not being general enough.
moritz_ hey, what about up, down and the diagonals? 13:25
we're thinking way too one-dimensional
masak: I see that you haven't commented or voted on the gsoc proposals yet... 13:26
masak: will you change that?
masak moritz_: how much time do I have left?
I have looked through them, but didn't take the time to vote/comment.
moritz_ masak: if you want to leave the students the chance to react on your feedback, you should do it in the next two days or so 13:27
masak I can do that.
bit busy these days, but two days should be fine. 13:28
moritz_ on April 15th everything must be decided
masak aye.
moritz_++ # for reminding
pugs_svn r26152 | jnthn++ | Unfudge 5 tests for type checked arrays. 13:30
r26153 | jnthn++ | Review, correct and simplify (as in relying on less unrelated features) some of the tests for wrap.
jnthn (And just pushed changes to get us passing those wrap.t tests now they're reviewed.) 13:32
13:32 payload left, Doubi left 13:33 orafu joined, cognominal joined
dalek kudo: a36c3b2 | jnthn++ | src/classes/Routine.pir:
Some tweaks to the first cut of wrap; assign could get things confused, plus also need to track relations of Parrot and Rakudo level subs.
 13:38
kudo: 6bcccd6 | jnthn++ | src/builtins/control.pir:
Implement callwith for the wrapped sub case.
kudo: 8abc537 | jnthn++ | t/spectest.data:
Add wrap.t to spectest.data.
kudo: 4561d2f | jnthn++ | :
Merge branch 'master' of [email@hidden.address]
pugs_svn r26154 | jnthn++ | [t/spec] Tests for out-of-order unwrapping and making sure re-unwrapping and unwrapping something never wrapped dies. 13:39
13:45 Doubious left, davidad joined 13:47 cognominal left 13:48 cognominal joined 13:49 cognominal left 13:51 Tene joined
PerlJam good morrow #perl6 13:51
moritz_ hi PerlJam 13:52
PerlJam pulls a fresh rakudo
masak PerlJam: good day, sir. 13:53
13:54 alester joined
moritz_ jnthn: t/spec/S09-typed-arrays/arrays.t fails three tests here, which is somewhat my fault because I mis-spelled it in t/spectest.data :) 14:01
jnthn moritz_: I tought it had 3 tests towards the end fudged? 14:02
I unfudged 5 that were passing...
moritz_ Failed tests: 33-34, 36 14:03
TODO passed: 35, 37
jnthn odd
OK, fudge as needed.
moritz_ oh wait
I didn't realclean or so
let me try that first
jnthn moritz_: I fail 33,34, 36 14:06
14:06 cognominal joined
moritz_ still the same here afer realclean + rebuild 14:06
14:07 payload joined
moritz_ jnthn: can you take care? you know better than me what's supposed to work ;-) 14:07
jnthn moritz_: Can do. Those ones that are failing are ones that I expected to. 14:08
moritz_ I'l be gone for about 10 days, easter vacations and all ;-)
jnthn But I thought they were fudged.
Will check the file.
Wow!
moritz_ maybe I'll find a stray internet cable here and there, but no promisies ;-)
masak moritz_: haveaniceeastervacation.
moritz_ masak: thank you
jnthn Actually any of that block of tests that pass are bogus passes anyway. 14:09
14:10 frew|work joined
pugs_svn r26155 | jnthn++ | [t/spec] Skip some tests that mostly fail; any that pass are false positives anyway (thus why skip and not todo). 14:11
jnthn moritz_: Enjoy your break. :-) 14:14
Eek. callsame is a tad tricky... 14:15
14:26 rindolf joined 14:29 LylePerl joined 14:31 ihrd joined 14:35 nihiliad joined 14:37 payload left 14:46 TimToady joined 14:47 ihrd left, diakopter joined 14:50 ashizawa left 14:51 frzntoz joined 14:53 ashizawa joined 15:02 Tene_ joined 15:05 ashizawa left 15:06 ashizawa joined, ashizawa left, ashizawa joined 15:07 ashizawa left, ashizawa joined 15:10 ashizawa left 15:13 ashizawa joined 15:14 ashizawa left 15:15 iblechbot_ joined
jnthn pmichaud: ping 15:15
15:15 ashizawa joined
pmichaud pong 15:16
15:16 Tene left
jnthn pmichaud: I'm working on wrap 15:17
I'm having a bit of fun with...guess what...lexicals. :-)
In wrapping.t it basically does wrap with a block in a loop.
It seems if I clone that block in wrap though, I end up losing the right lexical context. 15:18
pmichaud line number?
jnthn I have local changes but see around 45
Starts for (1..10) -> $num {
pmichaud what's that $^t parameter supposed to be? 15:19
jnthn wait, I'll commit a less buggy version of the test
pugs_svn r26156 | jnthn++ | [t/spec] Some tweaks to wrapping.t. 15:20
jnthn pmichaud: OK, comitted.
pmichaud: I think that was somebody not understanding postfix++ and readonlyness when the test was written. ;-)
pmichaud what's that $^t parameter supposed to be?
masak we have both wrap.t and wrapping.t ?
15:21 payload joined
jnthn It's just the parameter that is taken by the block that is serving as the wrapper. 15:21
masak: Yeah, they are testing some different things, probably candidates for a merge though.
So the idea is that we'd end up wrapping more and more deeply, and since we can with $^t + 1 each time, we have a number that represents the wrap level. 15:22
The problem I am hitting is that I maintain as properties on the block the chain of inners. 15:23
15:23 iblechbot left
jnthn They're chained through stuff in the prop hash, that is. 15:23
But to do that, I need to clone them.
But if I clone the wrapping block in the wrap call, things in wrap.t start failing, since they reference outer lexicals of where the block being used to wrap. 15:24
pmichaud failing meaning segfault, or ... ? 15:26
callwith( $^t + 1 ); 15:27
what exactly does that mean here?
(I need to review S06)
jnthn Let me back up a bit.
sub foo($x) { say $x }
foo(1); # 1
dalek kudo: 531fe43 | jnthn++ | src/builtins/control.pir:
Add a stubby callsame that works for argumnetless case. Not figured out how to handle getting the arguments so well just yet, but this is probably enough to pass some of wrapping.t which only needs that.
 15:28
kudo: 04f63fc | jnthn++ | src/classes/Routine.pir:
Make sure accessing the non-existent return value of unwrap doesn't cause Null PMC Access by handing back Nil.
kudo: 4866942 | jnthn++ | src/classes/Code.pir:
Implement .callwith method for Code objects.
jnthn &foo.wrap({ callwith($^t + 1) });
jnthn foo(1); # 2
Because callwith calls the inner thingy, that we wrapped
masak finally makes some headway with the Lobster
15:29 Tene_ is now known as Tene
jnthn rakudo: sub foo($x) { say $x }; foo(1); &foo.wrap({ callwith($^t + 1) }); foo(1); 15:29
p6eval rakudo 4561d2: OUTPUTĀ«1ā¤2ā¤Ā»
jnthn So if we wrap again
rakudo: sub foo($x) { say $x }; foo(1); &foo.wrap({ callwith($^t + 1) }); foo(1); &foo.wrap({ callwith($^t + 1) }); foo(1);
p6eval rakudo 4561d2: OUTPUTĀ«1ā¤2ā¤3ā¤Ā»
jnthn Which is fine. The problem comes if we do, say
rakudo: sub foo($x) { say $x }; foo(1); for 1..2 { &foo.wrap({ callwith($^t + 1) }); foo(1); } 15:30
p6eval rakudo 4561d2: OUTPUTĀ«1ā¤2ā¤Parrot VM: PANIC: Out of mem!ā¤C file src/gc/memory.c, line 52ā¤Parrot file (not available), line (not available)ā¤ā¤We highly suggest you notify the Parrot team if you have not been working onā¤Parrot. Use parrotbug (located in parrot's root directory) or send anā¤e-mail to
..parro...
jnthn Basically, because when we do a wrap, we use properties ont he block pased - the { $^t + 1 } in this case - to chain them. 15:31
"This is my inner block that callwith() should invoke."
Apart from, they don't get cloned, so the chaining gets messed up.
But I can't make wrap clone the block because if the block cares about its outer lexical scope (see examples pushing to @log in wrap.t) the clone causes issues there, it seems. 15:32
pmichaud cloning shouldn't be causing problems. 15:33
short answer is that you have to clone the block. 15:34
(or that you should be cloning the block)
jnthn Yeah, doing that makes wrap.t go and fail. :-(
pmichaud then I suspect the issue is in wrap.t
(or the code trying to execute wrap.t)
jnthn It does stuff like 15:35
sub wrapper { push @log, "wrapper before"; try { callwith() }; push @log, "wrapper after";
}
Where @log is in the outer lexical scope of the wrapping block
I'll make sure it really is a lexical-ish issue...or if it's something else that the clone throws up.
15:36 ejs left, brunov joined
pmichaud I don't quite understand the spec's intended mechanics for callwith() 15:37
jnthn How so? 15:38
pmichaud in wrap.t, that first call to wrapper() ends up with an exception for callwith() ?
jnthn Yes
thus why it's in a try
pmichaud and it's an exception because...?
jnthn (That was the way I found the test. I think it's just to sanity check.)
Because there's nothing to call.
pmichaud where "something to call" comes from ? 15:39
jnthn It's only when you apply it as a wrapper to something else that callwith then calls the thing that was wrapped.
$handle = &thermo.wrap( { callwith( ($^t-32)/1.8 ) } );
pmichaud how does callwith detect that?
jnthn When you do that, thermo() now calls that block, and callwith calls the original block.
pmichaud how does callwith know "the original block" ? 15:40
jnthn Well, how callwith does that is implementaiton specific I guess - the spec doesn't seem to lay any constraints on that. But in Rakudo's case it stores the original block in a property ont he sub.
pmichaud on which sub?
jnthn And callwith looks for that property on its caller.
Or an outer up to the limit of a routine anyway.
15:41 hercynium joined
pmichaud but in the case of wrapper() there, the caller to callwith() is always wrapper 15:41
15:41 bacek left
pmichaud the caller to the block containing callwidth() is always wrapper 15:41
jnthn *nod*
pmichaud there's not a way to call that block directly.
jnthn *confused*
pmichaud so it can't just be "my caller"
jnthn No, it's not as simple as "my caller" really. 15:42
The block ends up associated with the original sub...which means that yes, we really do need to clone it...
pmichaud which block ends up associated with the original sub ... ?
jnthn The clone of wrapper in the case above.
Routines are mutable. 15:43
pmichaud but that still doesn't answer my question
jnthn I don't really follow what you're asking.
pmichaud how does callwith find "the original block" ?
jnthn Because it's attached as a property to the (should be clone) of the wrapping block.
pmichaud how does callwith find the wrapping block? 15:44
TimToady a wrap sets up a call to a candidate list. callwith/callsame/nextwith/nextsame always interact with some caller's candidate list
jnthn By examining first its caller, then its callers outers.
pmichaud that's my point
oh, wait
jnthn (Limiting the seach to within one routine.)
TimToady it has to be the same mechanism as used by multis and methods
pmichaud jnthn: I'm missing something very fundamental in your description here. 15:45
TimToady !@#$!@#$!
jnthn pmichaud: Maybe the code will be clearer than I am? 15:46
TimToady HELLO, IS THIS MIKE ON???
masak rakudo: say (1,2,3).map: { $_ } 15:47
jnthn TimToady: I can see that callwith, callsame etc also deal with those, yes.
p6eval rakudo 486694: OUTPUTĀ«123ā¤Ā»
masak rakudo: module Foo { say (1,2,3).map: { $_ } }
p6eval rakudo 486694: OUTPUTĀ«Parameter type check failed for expr in call to mapā¤current instr.: 'die' pc 16596 (src/builtins/control.pir:222)ā¤Ā»
masak submits rakudobug
pmichaud jnthn: with &foo.wrap( &wrapper ), what happens, exactly?
TimToady but you seem to be wanting to invent a different mechanism for wraps than for other dispatches
jnthn TimToady: So how exactly is it meant to work? 15:48
TimToady callwith does exactly the same thing in a method calling a SUPER that it does in a multi calling the next candidate, and a wrap calling it's next wrappee 15:49
jnthn That is, what should wrap really be doing?
TimToady it makes a candidate list
and a call to the function name calls the dispatcher to the first wrap candidate, which may call the others, or not
think of them all as "next METHOD" where there's some implicit dispatcher loop labelled METHOD: 15:50
only with more finesse about the arguments and tailcalls 15:51
jnthn OK, but what is that candidate list associated with? 15:52
The Routine?
LylePerl hi 15:54
TimToady whatever gets called first thing when you say &foo.()
15:54 Psyche^ joined
TimToady where do you hide the candidate list for a multi? 15:54
jnthn The thingy in the symbol table/lexpad/method slot for a multi is an instance of some type Multi which holds all of the variants. 15:55
LylePerl masak: ping
TimToady this is about one level down from that, a sub-dispatcher associated with the &foo routine that delegates
wrapping is a level of indirection hidden inside the &foo symbol 15:56
masak LylePerl: pong.
TimToady so &foo contains a dispatcher instead of the bare routine
jnthn Whereas at the moment for a single routine foo() we install it directly into such a slot.
Ah, OK.
Do you see callsame() etc then as essentially being exceptional control flow? 15:57
LylePerl masak: Getting Perl 5 scripts to work properly on IIS usually requires FindBin and chdir. I can't seem to find these for Perl 6, do they exist?
TimToady and if we wrap something that's already wrapped, we can just keep the one dispatcher and add to its candidate list
masak LylePerl: I highly doubt it. 15:58
jnthn That is, they throw exceptions that the current dispatcher catches and then knows to invoke the next thing in the candidate list?
masak LylePerl: furthermore, the things those modules encapsulate are currently fairly hard to do in Rakudo.
15:58 amoc joined
masak LylePerl: we do them in our projects, but with difficulty and hardship. 15:58
TimToady pugs has a FindBin 15:59
literal how hard would it be to port this? svn.pugscode.org/pugs/ext/FindBin/lib/FindBin.pm
TimToady yes, that
masak looks
TimToady might be bitrotted, but it is in p6
might also depend on pugs primitives 16:00
masak it depends on File::Spec...
LylePerl TimToady: thanks
pmichaud File::Spec : svn.pugscode.org/pugs/ext/File-Spec/
masak LylePerl: it definitely looks port-able.
LylePerl :) 16:01
masak I see nothing strange in FindBin.pm that Rakudo would choke on.
masak looks at File::Spec
pmichaud it'd be nice to get rid of the :P5's in File::Spec::Win32
TimToady rakudo: eval "say 'hi'" 16:02
p6eval rakudo 486694: OUTPUTĀ«hiā¤Ā»
masak LylePerl: I see some things in File::Spec::Unix that will cause problems under Rakudo. 16:03
pmichaud masak: at npw I think it might be really good for us to talk about library packaging ideas :-)
masak pmichaud: indeed.
LylePerl What about chdir? I read some converstations in 2005 about using @CWD instead?
16:03 payload left
jnthn TimToady: Or put another way, would an implementation that did the dispatcher flow in terms of an exception model sound wrong to you? 16:04
PerlJam LylePerl: chdir doesn't yet exist in rakudo
masak LylePerl: Rakudo, as far as I know, doesn't do anything there.
ah. what PerlJam said.
pmichaud ...but it could.
assuming that Parrot gives us access to chdir, at least.
masak LylePerl: I think it's certainly doable to port these modules to Rakudo. if you're willing to negotiate some small features with the Rakudo devs.
pmichaud (well, we could make it work even if Parrot doesn't :-)
I think I'd be quite eager to get some of the modules into Rakudo 16:05
jnthn Method chdir ont he OS PMC.
[particle]- anyone have a camelia image link? i can't find it
pmichaud and to think about how we might want to set up libraries
masak jnthn: sounds promising.
jnthn masak: If you wants it I can write it... 16:06
masak [particle]-: www.wall.org/~larry/camelia.pdf
LylePerl would make november on IIS much easier 16:07
[particle]- ah, pdf! thanks.
pmichaud particle: svn.pugscode.org/pugs/misc/
masak jnthn: it would make life easier for proto, that's for sure.
TimToady use the camelias in pugs/misc
16:07 frzntoz left
pmichaud pugs/misc has .odf version 16:07
and .svg
and .ico
TimToady 32 and 16
jnthn masak: OK. is chdir in S32, I wonder...or S16...
LylePerl S29 16:08
masak @spack chdir
lambdabot loves chdir, so no slapping
masak :P
buubot: spack chdir
buubot masak: Sorry, I couldn't find any matches for: chdir
LylePerl isn't not part of the default namespace
perlcabal.org/syn/S29.html
[particle]- not as cute as glenda, the plan 9 bunny, but with an artist's help... maybe.
TimToady jnthn: when I say "next METHOD" I'm referring to an exception model, it would seem
pmichaud given that IO and filesystem stuff are currently a bit underspecified in the synopses, I'm willing to be a bit liberal about what Rakudo implements 16:09
16:09 justatheory joined
pmichaud i.e., we can put things in Rakudo that aren't official spec. But we should also keep a list of warning-warning-warning about them somewhere. 16:09
[particle]- io stuff was waiting for parrot implementation a bit iirc
so rakudo impl will likely influence the spec there
TimToady either that, or whack someone upside the head to put it into the spec :) 16:10
or, given current state of S32, just put it into the spec yourself :)
jnthn TimToady: OK, I'll ponder that a bit...
[particle]- well, any of us here can do that, it's in the pugs repo, after all
16:10 Patterner left, Psyche^ is now known as Patterner, kst left
pmichaud my suggestion: whoever wants chdir implemented in rakudo can just write it. Or, if they're not inclined/empowered to do that, they should write the spec for it in S32 or somewhere and then file a ticket to have it implemented :-) 16:11
oh, and tests.
masak LylePerl: got that? :) 16:12
TimToady it would be nice if there were a mechanism that different dynamic scopes could think they were in different directories, but perhaps that's not a feature we should delay 6.0 for
LylePerl It's above me, I only started looking at Rakudo on Sunday and Parrot a couple of days ago :(
pmichaud LylePerl: writing the spec or tests shouldn't be above you :-) 16:13
or, at least, not too far above you :-)
masak LylePerl: you can count on help from me and others on this channel with any questions you have.
pmichaud audreyt had a very nice policy of trading new features for tests.
LylePerl I'll give it a go, prob take me a while though ;)
pmichaud I think we can do a similar thing with rakudo -- write the spec and tests that you want, and someone else will likely pick up the feature implementation itself fairly quickly. 16:14
masak no worries. keep it simple, small iterations.
(that was for LylePerl)
LylePerl ok. Where do I start, gimme a list of things to lookup and I'll read up and work through it 16:15
pmichaud masak, others: any thoughts about opening up a cpan-like repository on github for things like File::Spec, Find::Bin, etc. that could be shared among multiple implementations?
or should we just keep it all in pugs (and fix what's there now...?)
16:15 frzntoz joined
masak pmichaud: I think perl6-examples is that repository already. 16:15
pmichaud: just look inside its lib/ directory and you'll see what I mean. :) 16:16
all sorts of goodies there.
pmichaud masak: okay. I have the 'perl6' account on github, so I'm wondering if it perhaps should move there.
then we could have perl6/examples, perl6/library, etc.
masak pmichaud: I don't mind.
TimToady it's the GPAN... 16:17
masak but you should perhaps negotiate that with eric256.
pmichaud yes, of course.
masak pmichaud: until such a move happens, I think perl6-examples is more than adequate for such modules.
pmichaud masak: I'm thinking more about packaging issues... at some point I suspect that rakudo should "ship" with such modules already in place. 16:18
masak pmichaud: ok.
LylePerl TimToady: Guinea Pig Adoption Network gpan.net ? :p
pmichaud but I don't think the rakudo repo is the correct place for those modules to be housed
masak pmichaud: not even Test.pm, methinks. 16:19
pmichaud masak: well, we keep saying that Test.pm will really be core, so it's already a bit of a misnomer
masak right, right.
masak likes Test.pm as it is :)
pmichaud i.e., in theory we could start moving Test.pm into setting/
and it then just becomes part of the standard build.
TimToady gpan.org is available, if gpan.net isn't :) 16:20
masak has to go RSN
pmichaud where "gpan" == "github ... " ?
TimToady that's was the original pun, yes
pmichaud okay.
masak gpun.
pmichaud I'm a bit slow and sleep-deprived this morning, I think.
TimToady well, the pun was the resemblance between G and C, actually
pmichaud and the G does look kinda like a "6" :-) 16:21
almost halfway between CPAN and 6PAN :-)
TimToady but now I feel unclean :)
shower &
pmichaud LylePerl: (where to start) here's my suggestion 16:22
assuming that you need a chdir function available in Rakudo to support whatever it is you're wanting to do
LylePerl I was saying on #parrot the other day it would be good if cpan (or the new one) was part of TPF
pmichaud: yes 16:23
pmichaud (1) review existing synopses and spectests to see if chdir has already been worked on
if yes, then see if it makes sense and point the developers at it.
"point the developers" generally means "file a ticket"
if there's nothing existing for chdir, then
masak LylePerl: I'll be away for a day and a half, but I'm sure others in the channel will help you if you need it. also, I will backlog, so just saying things loudly works too, but possibly with a bit of a delay.
LylePerl: good luck. 16:24
pmichaud (2) draft what you think chdir should look like
to draft it, look at other functions in S32 or other places to see how they've been documented
PerlJam is pretty sure LylePerl is going to quickly move to step 2
16:24 kst joined
pmichaud also, we don't completely ignore Perl 5 -- so look at Perl 5's documentation and see if you think it makes sense for Perl 6 16:25
and just try to adapt it to a Perl 6 sort of idea
masak PerlJam: aye. there's only one mention of 'chdir', and it's in S29. it only lists chdir and moves on.
pmichaud if what you draft is incorrect, no problem -- others will fix it. We definitely prefer "progress with errors" to "everyone waits on everyone else to do something"
masak moves on too
16:26 masak left
LylePerl masak: ok, catch up later 16:26
pmichaud: ok :)
pmichaud also, RT #49171 is our "high priority meta ticket". So, if something is really important, you can (get someone to) attach your ticket as a dependency of #49171. 16:27
PerlJam pm: how important do you think it is to get rakudo working with IIS? :) 16:28
pmichaud pj: that's actually a bit high on my priority list 16:29
because Web.pm will likely want or need it
and we still tend to be very application-driven
PerlJam LylePerl: remember pmichaud's answer to my question when you create that first ticket ;)
pmichaud so if LylePerl++ and masak++ both are saying "we need feature XYZ", then I think it deserves some quick attention
(assuming it can be done relatively quickly, as this one can) 16:30
LylePerl I see
pmichaud we also have people who are interested in hacking on Rakudo over the next few months -- tickets like this are good entry points into learning about how things work.
which is partially why I'm not jumping to implement chdir myself right now -- I think it'd be good to find someone else (perhaps LylePerl, perhaps another) to do it 16:31
LylePerl ok :s
pmichaud but things are nicer when we start with the spec and/or tests
and that doesn't really require Parrot knowledge
afk for a bit 16:32
LylePerl ok. I'd better get back to Ā£workĀ£. I read up on all this tonight/tomorrow. Thanks for all your help 16:34
16:39 frzntoz left 16:43 Tene_ joined, japhb left 16:48 legis joined 16:52 cdarroch joined 16:53 Tene left
dalek kudo: 4cc08e8 | jnthn++ | src/parser/actions.pm:
Add multiple prefix constraint check, as done by STD.pm.
 17:10
TimToady well, we'll certainly need a primitive process-wide chdir, even if we hide it from people most of the time 17:11
we don't want a web server's subprocesses chdiring other subprocesses unexpectedly, for instance
so I'd guess our IO system as a whole wants to track current directory separately from the process as a whole 17:12
which probably means the current directory is contextual
(dynamically scoped, that is)
and { temp $*CD = chdir('..'); open($file); } would be taught to do the right thing in context 17:14
$*CD would be an object representing the current directory, not a string 17:15
17:16 ChanServ sets mode: +o TimToady
TimToady well, maybe just have chdir set the current $*CD, whatever its dynamic scope is. 17:17
17:18 frzntoz joined 17:19 [particle]1 left 17:21 frzntoz left 17:24 diakopter left, davidad left, agentzh left, dukeleto left, zostay left 17:26 frzntoz joined, betterworld joined
LylePerl TimToady sounds good 17:28
There is a thread about it here from 2005 groups.google.com/group/perl.perl6....a1ae9d0a76 17:30
At the time you were talking about @CWD 17:31
17:31 xinming left 17:32 zamolxes joined
rindolf rakudo: [+] (5,6,7) 17:34
p6eval rakudo 4cc08e: ( no output )
rindolf rakudo: [+] [5,6,7]
p6eval rakudo 4cc08e: ( no output )
rindolf perl6: [+] [5,6,7]
p6eval pugs, rakudo 4cc08e: ( no output )
..elf 26156: OUTPUTĀ«/home/evalenv/pugs/misc/STD_red/match.rb:117:in `block in to_dump0': undefined method `to_dump0' for nil:NilClass (NoMethodError)ā¤ from /home/evalenv/pugs/misc/STD_red/match.rb:117:in `map'ā¤ from /home/evalenv/pugs/misc/STD_red/match.rb:117:in `to_dump0'ā¤ from
../home/evalenv/pugs/...
jnthn rakudo: say [+] (5,6,7) 17:35
p6eval rakudo 4cc08e: OUTPUTĀ«18ā¤Ā»
PerlJam jnthn: any clue where to start looking for this one ... 17:38
rakudo: my @a=1..10; say @a[4..*];
p6eval rakudo 4cc08e: OUTPUTĀ«5678910Use of uninitialized valueā¤ā¤Ā»
PerlJam ?
jnthn PerlJam: Yeah, in fact I did look for it earlier...
rindolf rakudo: say [*] (1..7)
p6eval rakudo 4cc08e: OUTPUTĀ«5040ā¤Ā»
jnthn PerlJam: The thing is that * here ends up evaluating to the number of elements in the array 17:39
Which is what you want for *-1
But gives an off-by-one in 1..*
17:39 IRSeekBot joined
rindolf rakudo: sub myop ($x, $y) { $x + 2 * $y} say [myop] (1..7) 17:39
p6eval rakudo 4cc08e: OUTPUTĀ«Statement not terminated properly at line 1, near "say [myop]"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)ā¤Ā»
17:39 IRSeekBot left
jnthn PerlJam: Thing is, it's not immediately clear to me in 1..* should construct an infinite range or a { 1 .. $_ } block. 17:41
PerlJam Well, we can always use @a[1..^*] instead :-)
17:41 sitaram left 17:42 IRSeekBot joined, [particle] joined
PerlJam jnthn: can you give me some more context wrt your statement of *-1 ? Where would that show up? 17:42
jnthn PerlJam: Yes, and that one *does* work in Rakudo. :-)
PerlJam: Context in Rakudo or spec? 17:43
PerlJam spec I guess.
jnthn @array[*-1] # Last element of the array
lambdabot Unknown command, try @list
jnthn In S09
PerlJam Hmm. 17:44
jnthn Also on S02
Most of the built-in numeric operators treat an argument of C<*> as 17:45
indicating the desire to create a function of a single unknown, so:
* - 1
produces a function of a single argument:
{ $_ - 1 }
PerlJam okay, where's that in rakudo? I assume that the handling of @a[1..*] happens in Range somewhere and @a[*-1] happens somewhere else?
[particle]- whatever. 17:46
jnthn I've got a local patch that sort of starts refactoring that a bit, but look for postcircumfix:[ ]
TimToady @a[*-1] turns into @a[ { $_ - 1 } ]
jnthn And especially src/classes/Positional.pir
TimToady so the subscripter sees a closure and calls it with +@a.elems
jnthn TimToady: And 1..* constructs an infinite range? Certainly not { 1..$_ } 17:47
TimToady infix:<..> has a (Int,Whatever) and a (Whatever,Int)
and a (Str,Whatever) and a (Whatever,Str)
jnthn Right, which construct infinite ranges, not closures?
[particle]- int or num?
TimToady and Whatever is taken as either pos or negative infinity
jnthn OK. :-)
TimToady well, *..'a' doesn't make sense 17:48
so forget that case
jnthn ;-)
TimToady but yes, .. doesn't make closures
jnthn OK, thanks.
TimToady nor does xx *
jnthn OK. 17:49
S02 says "numeric" operators
TimToady any operator is allowed to have an idiosyncratic interpretation of *
jnthn So I figure * ~ "thingy" doesn't count?
[particle]- i wonder what the idiomatic way is to generate a range around 0, like -5 .. 5
jnthn (As a closure-forming...)
TimToady just most of the standard math ops don't, and just have * cases that make closures
jnthn OK. 17:50
TimToady but it's all multi dispatch driven
jnthn Sure, I planned to do it just by generating a bunch of multis.
17:50 Khisanth joined
jnthn ponders dinner 17:51
TimToady note that the subscripter handles * directly different than *-1 17:53
since one is of type Whatever and the other is of type Code
17:53 [particle] left
TimToady a subscript of Whatever turns into 0..* or some such 17:54
PerlJam: a * is always handled in the next operator it sees, regardless of its outer context 17:55
17:55 riffraff left
TimToady in @a[*-1] the - handles Whatever,Int with no knowledge that it happens to be inside @a[...] 17:55
likewise 0..* doesn't know or care what its outer context is 17:56
PerlJam makes sense
TimToady actually, the subscripter doesn't necessarily supply @a.end; it has to supply the appropriate end for that dimension of the subscript 17:57
which may either be the shaped end or the actual end, depending on whether that dimension is open-ended 17:58
17:58 LylePerl left
jnthn TimToady: It gives .elems and not .end, no? 17:59
PerlJam jnthn: that sounds like it would be off by one.
TimToady yes, elems
sorry
jnthn TimToady: Since .end - 1 is .end.
Right. :-)
[particle]- um.
TimToady and of course, once it's implemented correctly @a[1..^*] will stop working... 18:00
[particle]- jnthn: you wanna review that bit of math?
jnthn TimToady: Because of lack of multi?
[particle]-: oh it's fine if .end returns a junction :-P
s:2nd/end/elems/
erm
1st
Yeah. Certainly it's time for dinner. :-) 18:01
TimToady well, I suppose it might still work if 1..^* means all the integers excluding Inf
[particle]- heh, better
jnthn What's Inf - 1? ;-)
PerlJam I think I'm still confused. my @a = 1..10; @a[5..*]; # the Whatever is @a.elems or @a.end ? The latter is what makes sense to me. 18:02
TimToady I guess the subscriptor is using a range as a lazy list, and ignores running off the end if the range is known to be infinite
that * doesn't know about @a
at all
jnthn PerlJam: I think in this case the...yes, what TimToady said.
We'll have to teach postcircumfix:<[ ]> about infinite ranges.
TimToady it makes an infinite range, and @a[] knows what to do with that 18:03
jnthn std: multi sub my_abs (Num where { $^n < 0 } $n){ -$n } 18:04
TimToady @a[] also knows what to do with a closure, which is call it with the dimension's .elems (or shape)
lambdabot Maybe you meant: arr ask
p6eval std 26156: OUTPUTĀ«##### PARSE FAILED #####ā¤Malformed multiā¤Malformed routineā¤Malformed routineā¤Multiple prefix constraints not yet supported at /tmp/okDOoskiZC line 1:ā¤------> ulti sub my_abs (Num where { $^n < 0 } $n){ -$n }ā¤ expecting any of:ā¤ infix or meta-infixā¤
..infix stopper...
jnthn goody
pugs_svn r26157 | jnthn++ | [t/spec] Correct test that used two prefix constraints. 18:05
18:07 barney joined 18:09 japhb joined, diakopter joined, davidad joined, agentzh joined, dukeleto joined, broquaint joined, zostay joined
TimToady I'll wager my spell checker doesn't like either of subscriptor or subscripter... 18:09
pugs_svn r26158 | jnthn++ | [t/spec] Tests for multiple prefix constraints being an error and for %hash<>. 18:10
dalek kudo: b512bdc | jnthn++ | src/classes/Associative.pir:
%h<> should return everything in the hash, like @a[] returns everything in the array.
 18:12
kudo: 9854f25 | jnthn++ | src/parser/actions.pm:
Enforce a single prefix type constraint on parameters.
kudo: 07ed756 | jnthn++ | src/classes/Range.pir:
Implement postcircumfix:[ ] in Range. It doesn't know about infinite ranges, but not much else does yet either.
18:13 ejs joined
jnthn -> dinner, back later 18:13
PerlJam So ... the following should be equivalent (modulo my syntax errors): my $r = Range(*,5); my @a = "a".."z"; say @a[$r]; say @a[*..5]; 18:14
as an aside, can I use Whatever in place of * ? 18:15
@a[Whatever..5]
lambdabot Unknown command, try @list
PerlJam lambdabot: you really should ignore unknown commands. 18:16
18:21 jferrero joined
pmichaud back from lunch 18:27
18:27 amoc left 18:29 LylePerl joined
pmichaud really likes the graph at rakudo.org/status much better now. :-) 18:30
18:33 barney left
literal hm, what caused that jump? 18:33
pmichaud support for unicode properties in regexes
also a lot of jnthn++'s work on parameterized types 18:34
literal what's the number now? 18:35
pmichaud 10,224 as of this morning.
literal nice
18:36 pmurias joined
literal hm, how many tests does Perl 5 have? 18:37
PerlJam many more
18:38 [particle] joined
jrockway i was looking at the rakudo web page today, and wondered something 18:38
why is it ę„½åœŸ and not ę„½é“ ? 18:39
(i always assumed the second one)
[particle]- !!! 18:40
almost 10K tests 18:41
pmichaud I asked some people I knew in Japan for the logo and that's what they sent. :-)
...almost 10K tests?
[particle]- rakudo: say 10 * 1024;
p6eval rakudo 07ed75: OUTPUTĀ«10240ā¤Ā»
[particle]- ;)
pmichaud oh, _that_ K.
we might already be >10,240 with jnthn++ and moritz++ latest updates to suite.
pmichaud does a test run just to find out. 18:42
PerlJam pm: #moose is arguing about the meaning of that graph 18:47
skids tries to parse S12: 18:49
"All public method calls are "virtual" in the C++ sense. More surprisingly, any class name mentioned in a method is also considered virtual, that is, polymorphic on the actual type of the object."
Trying to grok exactly what that last part is talking about -- "mentioned" how? 18:50
PerlJam skids: I think it meant to say "method signature"
skids That's sorta what I was taking away from it. 18:51
pmichaud pj: what's the crux of the argument? 18:52
pj: and should I bother to join in, or just let them argue? ;-)
PerlJam pm: nah, it's petered out. Basicaly rjbs was reacting to the idea that "more green == more perl6" 18:53
pmichaud it's not as if I went out and added a bunch of tests just to add more green.
These are tests that came from Pugs.
pmichaud wonders if there's a #moose log somewhere. 18:54
skids Yeah if we wanted to just fake out tests .... just Class int8 is Int where {...} or something :-) 18:55
pmichaud or phrased another way -- people often talk about how great pugs is because it passes N tests. Rakudo is for the most part simply re-using those same tests. 18:56
pmurias assuming that the tests don't duplicat themself and that what's not tested doesn't work one could prove that more passing tests == more perl6 working
lambdabot pmurias: You have 1 new message. '/msg lambdabot @messages' to read it.
PerlJam I don't often see anyone saying anything about pugs other than it's bitrotten.
literal pmurias: ...and that the new tests aren't testing something that already worked in Rakudo 18:57
PerlJam though there have been a few people in here over the last year asking how to get started with pugs, but I generally assume that's because they don't know about rakudo.
18:58 legis left
brunov pmurias, the actual argument was that there shouldn't be a reason to be proportionately excited with the number of tests passing, because the coverage per test is not constant 18:59
at least that's what I understood
so you should get equally excited with one more test passing that with 10 more tests passing
PerlJam in some ways pugs has stolen the thunder from any other perl6 implementation. Now when people talk about another implementation you'll get reactions like "but doesn't pugs already do that?" and "oh sure, it'll end up abandoned like pugs" and such.
brunov: It didn't seem like he was interested in modulating the excitement as much as tempering it with reality :) 19:01
pmichaud actually, with this latest commit I'm more excited about percentage of spectest coverage than raw numbers of tests.
brunov PerlJam, I did my best
pmichaud now that the green is the majority of the vertical scale :-)
it makes it look as though we don't have as far to go as it previously did 19:02
previously, people could say "oh, we're not even halfway to pugs yet". Now, we are almost 2/3rds of the way :-)
PerlJam but pugs isn't the bar most people are interested in. 19:05
pmichaud but it did set a high water mark 19:06
and people take that as a measure of progress
19:07 PhatEddy joined
PerlJam as long as you be sure to add a line on the graph to show where pugs was when rakudo passes it :) 19:07
pmichaud unfortunately, I don't know what that was.
Khisanth hmm so this is rakudo progress but not perl6 progress ... 19:09
PhatEddy rakudo: my @a = 1..4; say @a[*..2].perl
p6eval rakudo 07ed75: OUTPUTĀ«Multiple Dispatch: No suitable candidate found for 'cmp', with signature 'PP->I'ā¤current instr.: 'parrot;Range;!to_test' pc 10000 (src/classes/Range.pir:250)ā¤Ā»
pmichaud oh, I think it's perl6 progress also.
The tests that Pugs passed when it was passing tests aren't the same today. 19:10
skids rakudo: class D is ::C {}; class C is also { };
pmichaud and the tests evolved due to improvements in our understanding of Perl 6
p6eval rakudo 07ed75: OUTPUTĀ«Null PMC access in get_string()ā¤current instr.: '!meta_trait' pc -95315 ((unknown file):-1)ā¤Ā»
TimToady ę„½åœŸ means "paradise", literally pleasure earth. earth is "do", short. "way" is "dou", long, so the proper romanization of ę„½é“ would be rakudou, the way of pleasure 19:11
19:11 iblechbot_ left
TimToady it can also be taken as a shortening of rakudadou, the way of the camel 19:11
but then it'd be 駱駝道 19:12
skids Eh, as software names go "pleasure earth" ain't that bad :-)
PerlJam pm: your sentence seems to assume a hypothetical perfect perl 6 that is as yet undiscovered. It seems to me that a physicist is better positioned to find it ;)
PhatEddy Is it reasonable to conclude from the synopses that the leading * in my range example should pretty much always be 0? 19:14
pmichaud pj: I think you go a little farther than I do, there. :-) I don't necessarily assume a hypothetical perfect Perl 6; but I do know that over the past N years we've improved our understanding of the language such that its more expressive, more powerful, has fewer inconsistencies, etc. :-)
pmurias TimToady: re All public method calls are "virtual" in the C++ sense. More surprisingly, any class name mentioned in a method is also considered virtual, that is, polymorphic on the actual type of the object." What does the virtual class name part mean? 19:15
PerlJam PhatEddy: it should be the index of the first element in the array perhaps. I don't know that I can say it will always be 0 :) 19:16
19:17 ejs left
pmurias TimToady: does the class name get refer to subclasses in a subclassed method? 19:18
TimToady yes
PhatEddy If I do "my @a; @a[2] = 'b'; say @a[ * .. 2 ]" is "*" 2 or 0?
s/is/should be/ 19:19
pmichaud It's -Inf :-)
PhatEddy No according to S09 in reference to range slices ... 19:20
pmichaud the fact that the beginning of the range is -Inf may cause postcircumfix:<[ ]> to start at zero 19:21
such that the result of @a[*..2] is the same as @a[0..2]
but the * itself doesn't change.
i.e., it's neither 2 nor 0. The range is *..2, and postcircumfix:<[ ]> treats that range as being the same as 0..2 19:22
TimToady pmurias: see A12 at about line 4074, "In Classes" for an explanation of virtual classes
19:23 ejs joined
skids what's the plan for "is also" --> "is enhanced" as far as the test suite goes, once rakudo goes that way? 19:24
pmichaud I think it's "augment" now, isn't it?
skids Oh maybe, sorry. 19:25
PerlJam read "is enhanced" as "is enchanted" for some reason.
pmichaud moritz++ already has some patches to the test suite to switch "is also" to "augment", but I don't know how quickly Rakudo will be able to make that switch.
skids Mainly will someone patch up pugs, or do we just break the test for it?
pmichaud we can fudge the tests for pugs :-) 19:26
PhatEddy pmichaud: The star is currently implemented as a whatever object. If you do something like "@a[ *..2, *-1]" I am not sure how to get the current implementation to see whatever as both 0 and 3.
pmichaud the current implementation is wrong. 19:27
the current implementation was done before the current definition of Whatever handling was in place.
i.e., the spec changed somewhat after we implemented * in subscripts.
pmurias where can I find the apocalypses in pod form? 19:28
pmichaud pmurias: svn.perl.org/perl6/doc/trunk/design/apo, I think
PhatEddy: in particular, currently Rakudo's implementation "thunks" the expression inside of the brackets so that the whatever * can be evaluated lazily. That's no longer consistent with the spec. Instead what will happen is that the postcircumfix:<[ ]> operator will need to look at the types of its arguments and dispatch accordingly 19:31
so @a[ *..2, *-1 ] would end up calling postcircumfix:<[ ]> with a List
postcircumfix:<[ ]> would then need to go over the elements of that List, producing slices as it goes 19:32
in this case the List contains a Range and a closure
the Range is *..2
the closure is effectively { $^whatever - 1 }
the closure would be produced by infix:<-> 19:33
PhatEddy It more or less does that now. I have a patch that makes it DTRT in array slice context but may not be right for @a = 5 .. * type ranges.
pmichaud unless you've changed it substantially, there's a fairly significant difference between what I just described and what Rakudo currently does. 19:34
what rakudo currently does is to thunk the expression inside the brackets
so that @a[ *..2, *-1 ] ends up looking like @a[ { *..-2, *-1 } ] 19:35
and then postcircumfix:<[ ]> sets the value of * to the number of elements in the array, and call the closure.
which, as you noted earlier, causes problems with seeing the * as both 0 and 3.
PerlJam I don't think it even does the thunking currently. I'm looking at Positional's postcircumfix:<[ ]> and it looks like it just builds a list with special handling for Whatever. 19:36
pmichaud PerlJam: it's a multi
.sub 'postcircumfix:[ ]' :multi(_, 'Sub')
the 'Sub' form handles the case of when it receives a thunked closure. 19:37
PerlJam aye, I see that now
pmichaud I have to pick up Matthew from school... bbiab 19:38
PerlJam makes a mental note for the future ... when searching for a sub, don't stop at the first one you come across that has the name you're looking for :) 19:39
19:44 sri_kraih left
jrockway TimToady: thanks for the explanation 19:46
upon further reflection, it makes sense 19:47
i always think of perl6 as a path, rather than a destination
but... rakudo is actually the destination
clearly you should rename perl6 to rakudou ;)
19:48 LylePerl left 19:49 davidad left
TimToady actually, now Perl 6 itself should be č¶č¶é“, chouchoudou 19:50
jrockway heh 19:51
TimToady or maybe just č¶é“, if you're Chinese 19:52
jnthn oh hai I'm back
TimToady I like that the character for butterfly breaks down into "bug" and "leaf" radicals 19:53
actually, more like "flat" than "leaf" 19:54
"leaf" adds the "plants" radical 19:55
pugs_svn r26159 | pmurias++ | [re-smop] 19:56
r26159 | pmurias++ | added exists and lookup_key to S1P::Hash
r26159 | pmurias++ | moved the utility hash from capture to util
TimToady I think the original meaning of ęž¼ was a perhaps circular flat piece of wood, that is, a piece of wood in the shape of the world (presumably thinking of the world as a disk) 19:59
std: $ęž¼ = "world wood"; 20:00
p6eval std 26159: OUTPUTĀ«Potential difficulties:ā¤ Variable $ęž¼ is not predeclared at /tmp/ZhN99pKghn line 1:ā¤------> $ęž¼ = "world wood";ā¤ok 00:05 41mā¤Ā»
TimToady std: constant ęž¼ = "world wood"; 20:01
p6eval std 26159: OUTPUTĀ«ok 00:04 35mā¤Ā»
20:04 iblechbot joined 20:05 M_o_C joined
TimToady std: class ęž¼ {...}; constant ęž¼ = "world wood"; 20:05
p6eval std 26159: OUTPUTĀ«##### PARSE FAILED #####ā¤Malformed constant at /tmp/FH6fNZnQtB line 1:ā¤------> class ęž¼ {...}; constant ęž¼ = "world wood";ā¤ expecting any of:ā¤ multi_declaratorā¤ typenameā¤FAILED 00:02 35mā¤Ā»
pugs_svn r26160 | hinrik++ | [util/perl6.vim] 'self' should look like a variable, not a function 20:08
jrockway std: constant 2 = 3; 2 + 2 20:11
p6eval std 26160: OUTPUTĀ«##### PARSE FAILED #####ā¤Malformed constant at /tmp/GlXnKEzKGD line 1:ā¤------> constant 2 = 3; 2 + 2ā¤ expecting scoped declaratorā¤FAILED 00:02 34mā¤Ā»
pugs_svn r26161 | jnthn++ | [t/spec] Couple of tests for postcircumfix:<[ ]> on ranges.
pmichaud I think tonight I'll refactor postcircumfix:<[ ]> so that it doesn't thunk its arguments. 20:14
We'd get a good speed win out of that 20:15
and yes, I know to be wary of Postcircumfix[::T] :-)
er, Positional[::T]
20:16 xinming joined
pmichaud jnthn: is "Positional[::T]" simply "the Positional role that can be parameterized"? 20:16
(as in the get_hll_global symbol in Parrot)
jnthn pmichaud: Yes 20:17
pmichaud or are all Positionals now parameterized?
jnthn pmichaud: They are.
pmichaud i.e., is there still a get_hll_global 'Positional' ?
jnthn pmichaud: Let me summarize a little for you - it's not so scary.
pmichaud it doesn't look all that scary 20:18
jnthn There *is* still a get_hll_global 'Positional'
pmichaud but yes, a summary would be very helpful.
jnthn However, you don't "do" it directly.
Notice the call !TOPERL6ROLE
This does all the "neat stuff"
pmichaud TOPERL6ROLE is in ... actions.pm ?
jnthn No, guts.pir I think.
pmichaud (the call) 20:19
jnthn actions.pm also calls it.
wlel
pmichaud okay.
jnthn actions.pm emits code that calls it.
pmichaud I assume all-caps things are in guts.pm
so when I ask "where is ..." I'm generally asking "where it's called from" :-)
jnthn Basically it constructs a Perl6Role object.
Ah, OK.
It's called IIRC from the loadinit of the role body.
Anyway, it adds the role body as a parametric candidate. 20:20
pmichaud I don't see a TOPERL6ROLE anywhere
jnthn erm, yes
sorry
I was thinking of TOPERL6MULTISUB...
It's "!ADDTOROLE"(block) 20:21
And yes, in the loadinit.
Anyway, in the loadinit (or the PIR equivalent in Positional) we call this.
block is the Positional role body.
We give it a signature too, since it's subject to the Perl 6 multi-dispatcher. 20:22
pugs_svn r26162 | hinrik++ | [util/perl6.vim] some cleanup
20:22 M_o_C left
jnthn It creates, if it doesn't already exist, a Perl6Role representing and installs it in the NS as Positional 20:22
pmichaud (side note: would it have been better to use .const 'Sub' instead of get_hll_global '_positional_role_body' ?
jnthn However, Positional itself is not a role as such.
(reply: I copied what the generated code did, but did wonder why it didn't use that too.) 20:23
Positional is probably best of think of as a "role factory"
pmichaud well, from generated code we have a symbol
so it's a package lookup
are all non-parameterized roles essentially "role factories" ?
jnthn er, best to think of
All roles are parametric, yes. 20:24
Some of them might have a (potentially single) variant that takes no explicit parameters.
And nothing more.
pmichaud ahhhhh
because it's in the declaration of the role
thus role Foo[::T] { ... } is like a role factory 20:25
jnthn However, we can't know that we won't end up with more candidates imported later.
pmichaud and role Bar { ... } is a role factory but with no args?
jnthn Yes
pmichaud okay.
jnthn Well, strictly speaking
role Foo[::T] { ... }; role Foo { };
Those both are "role factories" in some sense.
pmichaud right 20:26
I actually kinda get it.
jnthn However, the second of them will only ever produce a single role.
pmichaud okay, two questions (to save you a bit of time now)
(1) are you covering this at all at NPW in your talks?
jnthn Note that there is a bunch of stuff done such that a given parameterization of a role only ever produces a single Parrot-level role.
pmichaud (2) does any postcircumfix handling take place outside of what is currently in Positional.pir ?
(possibly Range.pir has some.) 20:27
20:27 FurnaceBoy joined
jnthn (1) Yes, at some level. I want to fix type-checking on slurpy arrays, and then I can run an example like: role Table[@column_types] { method insert(*@args where { $_ >>~~<< @column_types) { ... } } 20:27
(Table type that checks types of paramters passed on inserts etc) 20:28
(2) Yes, but only from a very recent patch. See postcircumfix:[ ] in Range.pir.
pmichaud okay.
here's my quick takeaway 20:29
(a) I can pretty safely work on postcircumfix: refactors without interfering with your roles work.
jnthn I am half way into a patch making * + 1 etc make a block, BTW - just in case that was on your hit list too.
pmichaud you can put that in also... but we've also got to fix the calling side in actions.pir
and I'm thinking of also hitting the autovivify issues as well.
jnthn OK, that'd be cool.
Thing to be aware of. 20:30
pmichaud it all kinda hangs together.
pugs_svn r26163 | hinrik++ | [util/perl6.vim] some changes to function highlighting
jnthn Note in postcircumfix:[ ]
In Positional.pir
pmichaud (b) the rest of the stuff I'd like to know about parametric role handling I can probably get from your talk
jnthn It finds the type object.
(the find_lex "T")
pmichaud yes, I see. 20:31
jnthn The positioning of where we set types on things was kinda subtly done but I believe correct.
But feel free to do it righter. ;-)
pmichaud it initializes undefs to the protoobject
20:31 FurnaceBoy left
jnthn And sets the type property. 20:31
pmichaud that's what I was expecting, yes.
jnthn Then assignment type checks.
The key thing is that I only do it on undefs.
I don't know how your auto-viv plans hit that.
But if you understand how it works, then that's fine. Also, there is some test coverage. 20:32
pmichaud undefs will become Proxy objects, but they'll have the type property on them.
jnthn On (a) - parametric roles themselves are - at least I like to think - fairly stable.
pmichaud yes, what I've seen thus far looks really good on the design end.
jnthn Yes, there'll be tweaks, optimizations, I think the way that you do a particular version of a role (calling !select) will have to change.
pmichaud I may want to refactor the codegen in actions.pir, but the basic design looks really good to me. 20:33
jnthn The design is - we piggy-back everything off multiple dispatch and lexicals. ;-)
pmichaud amd tjat
oops
PhatEddy If you work on array autovivification you may want to look at rt 62948 - if nothing else you may supersede the patch and be able to close it ... (rt.perl.org/rt3/Public/Bug/Display....?id=62948)
pmichaud and that's what I like about it this design :-)
PhatEddy: yes, that's one of the reasons why it's on my hit list. And I'm thinking it'll be better to have it fixed before NPW. 20:34
jnthn Yes, the moment I had the realization that we really could make it hang together pretty much just off those two was a happy one.
pmichaud and that I can whip it out in an evening or so. I've been thinking about the issue and mulling implementation items in my head for the past couple of weeks.
anytime we can implement things with multi dispatch and lexicals I feel it's fundamentally the right answer.
anytime we have to attach properties on things or use flags of some sort I think we're missing the underlying design. 20:35
(or squirrel things away in odd symbols)
jnthn Aye. Sometimes it takes time to realize such a design though. 20:36
Anyway, I'm happy that you're happy with the parametric role stuff.
pmichaud very. 20:37
jnthn On this whatever block patch - if I find that it handling *-1 does funny things relating to postcircumfix:[ ], do you want me to just omit that from the list of things it fixes up?
pmichaud I can guarantee it's going to do funny things with the existing actions.pm implementation.
jnthn And let you know, rather than fixing it up myself in postcircumfix:[ ]?
OK
pmichaud I guess I'm suggesting that you might be saved a few headaches, since I know where the roadbumps are already. 20:38
jnthn OK. 20:39
I'll omit infix:<->
pmichaud that will work.
what happens with @a[* / 2 + 1] ? 20:45
istr that we also speculated the handling of closures with math ops... but that's not specced 20:46
jnthn Eww 20:48
That'll be nasty.
By precedence you'll end up doing a dispatch on * / 2 which will then give you a Block, at which point you'll try Block + 1
pmichaud right
20:48 ejs left
pmichaud that's the case that caused me to take rakudo's current approach to things :-) 20:48
jnthn rakudo: say { $_ * 2 } + 1
pmichaud maybe we don't support that case :-0
p6eval rakudo 07ed75: OUTPUTĀ«get_number() not implemented in class 'Sub'ā¤current instr.: 'infix:+' pc 22429 (src/builtins/op.pir:284)ā¤Ā»
jnthn A non-silent error. 20:49
[particle]- @a[*.ides]
lambdabot Unknown command, try @list
20:52 rindolf left 20:53 brunov left
jnthn > my $x = * * 2; say $x(4); 20:58
8 20:59
lambdabot <no location info>: parse error on input `='
jnthn
.oO( that one looks funny... )
std: my $x = * * 2; say $x(4);
p6eval std 26163: OUTPUTĀ«ok 00:02 35mā¤Ā»
jnthn :-)
pmichaud: spectesting now, if it works I'll put it in. infix:<-> omitted. 21:02
pmichaud jnthn: there's .sub 'postcircumfix:[ ]' :multi(_, 'Sub')
oops
wrong paste
[particle]- this is going to be hell for folks creating prefix:<*> operators
pmichaud irclog.perlgeek.de/perl6/2009-02-27#i_942578
[particle]- or postfix, for that matter.
jnthn pmichaud: Is this the thingy that became lift? 21:04
pmichaud: Oh, are you meajing the 21:05
multi infix:<eq> (&f:($), Any $b) { -> $a { meta f($a) eq $b } } # user's eq
pmichaud yes.
I'm okay if we leave that unimplemented for now.
jnthn Me too... ;-)
pmichaud I'm primarily interested in only the * - $x case
jnthn Hmm
I wonder if this means the multi-dispatcher has to worry about the sub-signature. 21:06
Or if we treat bindability to thatt as a tie-breaker.
(Also, we don't support sub-sigs yet.)
(Though we could cheat since we know what's code.) 21:07
pmichaud oh, with my $x = 3..*; say ?($x.to ~~ Inf); # true or false ? 21:10
jnthn Off the top of my head without a spec reference, I think true. 21:11
pmichaud i.e., does the Range .to return a Whatever or Inf ?
jnthn I think inf.
pmichaud okay.
21:11 bacek joined
jnthn infix:<..>(Whatever, Any) and infix:<..>(Any, Whatever) are defined (sure I read that before) 21:11
pmichaud we can do it that way until we're told not to. :-)
yes, they're defined.
I'm just wondering what they store :-)
jnthn I figured the purpose of their existence is that they can stick and infinity there. 21:12
Rather than the Whatever, which we'd get stuck in there if they didn't exist.
pmichaud yes, but I wonder if there's a distinction to be made between 0..* and 0..Inf in some contexts.
like, maybe, postcircumfix:<{ }> 21:13
%h{0..*} might be different from %h{0..Inf} :-)
jnthn I see your point...
pmichaud anyway, it's just idle curiosity on my part.
jnthn Would you really want in infinitely big slice? ;-)
skids maybe shaped arrays? 21:14
jnthn Of the various things I could see being lazy, taking of slices hadn't been one of 'em.
skids I seem to recall someone at sometime inferring they were. 21:15
jnthn meh. Now I haz to re-start my spectest run because I forgot to re-bless the Parrot sub into a Perl 6 Block.
skids Damned if I can remember who or when.
jnthn pmichaud: BTW, while you're working on postcircumfix, you could also handle junctions in slices. I pondered in the shower this morning that it may not be so hard - just spot them and re-call postcircumfix:<[ ]> through the junction dispatcher on that element. 21:17
and incorporate what comes back into the resultant slice. 21:18
pmichaud it'll likely just be postcircumfix:<[ ]>(Junction)
(so, yes, no problem)
jnthn yeahbut I'm thinking of like @a[1, 2|3, 4] where only one bit of the slice is junctional. 21:19
Anyway, shouldn't be too bad.
pmichaud well, I'm thinking that the postcircumfix:<[ ]>(List) case decomposes down into smaller postcircumfix calls.
bacek good morning
pmichaud in particular, I don't think that overriding postcircumfix:<[ ]> for any given class should require all of the multi versions 21:20
bacek +~2k passed tests in one day! What happened???
pmichaud i.e., the basic version is postcircumfix:<[ ]>(Int), and the others resolve down to that somehow.
jnthn bacek: pmichaud happened 21:21
skids perlcabal.org/syn/S09.html#line_866
bacek jnthn: :)
jnthn pmichaud: Giving Parrot's calling speed, multiple calls to postcircumfix:<[ ]> doesn't inspire me too much on performance...
skids hrm map {...} <== @a[1..5,4|3,1..*]
pmichaud jnthn: we can optimize some cases down, yes.
but we're already doing multiple calls to postcircumfix:<[ ]> 21:22
in fact, we're even doing it for the simple case of @a[3] 21:23
which is why I think fixing this up may get us an important Speed Win
(because we can avoid that)
by far the most common cases are likely to be single element access, list slices, and range slices. We can make those fast. 21:24
I was very concerned when I started thunking the arguments to postcircumfix:<[ ]> about our performance, but it didn't turn out to be as bad as I had feared.
jnthn Yeah 21:27
We shouldn't worry *too* much about performance just yet.
But there has been an increase in comments on such things of late.
[particle]- the people need to complain about something 21:28
if you focus on performance, they'll complain about missing features
jnthn [particle]-: Oh, of course. ;-) 21:29
And if you focus on features they complain about rising number of bugs. ;-)
Hard balance. :-)
[particle]- yep, then throw time to delivery into the equation... 21:30
jnthn We Don't Talk About Time To Delivery.
:-P
pmichaud we _really_ are getting to the point where we need a good profiler for parrot, though.
[particle]- yes, we certainly are.
jnthn yeah, I know.
[particle]- we have some really bad profilers
they're just not working
pmichaud I fear that the decreases in performance aren't mostly PGE-related. 21:31
jnthn I was kinda hoping some profiler wizz would appear and write one.
pmichaud i.e., I can work on improving parsing speed, but I think our runtime speed is starting to suffer.
jnthn pmichaud: For sure it is.
21:31 Tene_ is now known as Tene
pmichaud OTOH, I think allison expects to have new calling conventions stuff in place shortly after 1.1 release 21:31
she indicated that the conversion had gone surprisingly well.
jnthn pmichaud: Consider how many actual Parrot calls we currently do in class A { method m($x) { } }; A.new.m(42)
pmichaud oh, and also, it looks like we will indeed get a :capture flag 21:32
jnthn And I mean runtime, not initialization.
pmichaud which means we just get the arguments without parrot doing any unpacking, and we unpack ourselves.
[particle]- pmichaud: it's just a piece of the conversion done so far, though
pmichaud [particle]: yes, perhaps I'm naively optimistic again. 21:33
[particle]- well, you're free to try her branch, if things actually compile there
there are no api changes
pmichaud I'll wait until the merge
I have plenty else to keep me occupied :-)
[particle]- that's probably good, you can stay naively optimistic that way, too 21:34
pmichaud Right. And at NPW I can say "allison will be speeding up Parrot calling conventions in a couple of weeks" rather than "I tried out the calling conventions branch and we're in for big trouble. :-P"
[particle]- marketing++ 21:35
pmichaud (plausible deniability)++
21:35 LylePerl joined
skids first make it work, then make it work well, then make it work fast, then drive it off a cliff. 21:36
jnthn Dobre...moj patch funguje! 21:44
21:44 Util joined
jnthn oh language choice fail 21:44
Perl, PIR and English would be enough... 21:45
skids lolcat!
dont forgetz
jnthn oh noes do not want for brainaches! 21:46
*more 21:47
oh geck, now look what I've gone and done...
...OK, nobody watch the bot output to see how well I failed in comitting this patch...
pmichaud kick the bot, quick! :-)
[particle]- /kick dalek
pmichaud prepares for the horror 21:48
[particle]- smiles preemptively
jnthn pmichaud: Heh, the commit message is only the start of it, then there's the patch itself. ;-)
At least it is done in terms of lexicals. ;-)
pmichaud: y'know, the most evil thing about putting properties on subs, is we gotta be all careful over clones losing them... 21:49
pmichaud I'm open for other suggestions.
jnthn I ain't got any just yet. :-(
pmichaud I'm also open for having Subs clone their properties.
jnthn Other than when we do get HLL Map
Well
pmichaud (or at least clone the property reference)
jnthn Some properties we *want* them to lose. 21:50
Example: the property where we stash state variable state between invocations.
dalek kudo: 5658a57 | jnthn++ | build/ (2 files):
Implement * mathop val and val mathop * generating blocks. Left out infix:<-> for now.
kudo: 4a95115 | jnthn++ | perl6.pir:
Oops, forgot this file too. Epic git usage fail...
jnthn Oh good dalek
pmichaud well, that's part of the reason why I wasn't keen on using properties for state variables. :-)
jnthn pmichaud: Yeah but the point is that we *want* to lose them on a clone because That's The Spec. :-) 21:51
pmichaud right
jnthn (BTW I managed to run two commits with the first message...)
bacek jnthn: you can use "git rebase --interactive HEAD~2" to merge two commits in one. (But don't try is after git push)
pmichaud if they weren't properties, we wouldn't have a problem with needing to lose them.
jnthn (But dalek was kind enough to only show one of them)
pmichaud: I don't follow.
21:51 pmurias left
pmichaud right now state variables are being attached as properties on subs 21:51
PerlJam pmichaud: if they weren't properties, where would you store them? 21:52
jnthn The current properties semantics give us exactly what we want for state vars.
pmichaud: I'm thinking more than we may - when we can have our own Sub PMC, subclass Parrot's sub and have an extra attribute in there for $!signature
pmichaud why is using a property for a state variable an advantage?
jnthn Because when you clone a block it's properties are lost. 21:53
Also, because then the state is attached to the block.
Which means as closures are GC'd the state gets neatly GC'd with it.
pmichaud okay, I'll buy that.
jnthn Which would be much harder if you stuck globals beneath them.
At least, I couldn't see a neat way... 21:54
pmichaud anyway, yes, when we have our own Sub PMCs this becomes quite a bit easier
fwiw, I don't see why we can't have our own Sub PMC class now.
jnthn We kinda could but...
pmichaud we already have rebless available, yes?
jnthn Yeah.
I'm lazily waiting for .HLL to be done
pmichaud .HLL will help? 21:55
jnthn Yeah, then we'll just have the right PMC created int he first place.
(.HLL_map)
pmichaud will it help even though we got rid of .HLL_map ? Or are we planning to use :immediate for that ?
jnthn WE...got rid of HLL_map?
pmichaud yes, I think so.
jnthn The syntax or the functionality overall?
pmichaud the syntax.
jnthn Ah, OK
pmichaud the compile-time syntax, that is.
jnthn Whatever the new syntax is.
Ah.
Geck. 21:56
pmichaud I think all that is left is the runtime syntax.
jnthn Oh well. :-)
Anyway, that's tidy-ups for later.
pmichaud I'm not so sure that getting rid of .HLL_map was a good thing to do :-|
jnthn I wasn't even aware if was gone.
*it
pmichaud but can't the Perl6Sub PMC install itself as the mapping?
jnthn I'm not sure.
I didn't think it could...
I think my last attempt got bogged down in the Closure vs Sub PMC stuff. 21:57
pmichaud I know there's a hll_map directive im pmclass (or, at least istr there was one)
But since there's no more Closure PMC ... :-)
jnthn That was a compile time thing.
So yeah, dunno if it's still there.
pmichaud sure, it's a compile-time thing, which is what we want in this case.
jnthn Agree.
21:57 brunov joined
pmichaud I'm also thinking we may regret not having .HLL_map for namespace mapping. 21:57
jnthn I didn't think too much about that one yet. 21:58
In time, namespaces are probably going to become less important for us.
Given that in the future we're gonna need to make a bunch of stuff that is in the namespace now lexical instead. 21:59
pmichaud well, we still need them (e.g. for 'our' stuff). But yes, they'll be much less prominent.
jnthn rakudo: my $a of Str; $a = 42;
p6eval rakudo 07ed75: ( no output )
pmichaud trac.parrot.org/parrot/ticket/314 # deprecation and removal of .HLL_map
jnthn std: my $a of Str; $a = 42;
pmichaud alas, I voted +1 for it, too. 22:00
p6eval std 26163: OUTPUTĀ«ok 00:02 35mā¤Ā»
pmichaud pmichaud-- # Once again you have paid the price for your lack of vision. 22:01
22:01 iblechbot left
jnthn rakudo: say map * + 2, 1,2,3; 22:01
p6eval rakudo 07ed75: OUTPUTĀ«sh: ./perl6: No such file or directoryā¤Ā»
jnthn oooh...'tis the hour of da rebuild
rakudo: say map * + 2, 1,2,3; 22:02
p6eval rakudo 07ed75: OUTPUTĀ«sh: ./perl6: No such file or directoryā¤Ā»
PerlJam marks down "spectacles" as a possible xmas or birthday present for pmichaud
jnthn pmichaud: I think at the time we were finding we needed to be a lot more dynamic...
std: say map *.abs, 1,-2,3,-4; 22:03
p6eval std 26163: OUTPUTĀ«ok 00:02 38mā¤Ā»
jnthn how does'th thou parse it?
pmichaud it's just .abs on the whatever term :-) 22:04
jnthn Likewise, the single dispatcher recognizes C<*.meth> and returns C<{ $_.meth }>, 22:05
so it can be used where patterns are expected:
@primes = grep *.prime, 2..*;
lambdabot Unknown command, try @list
jnthn Ah
Goes in .^dispatch I guess
pmichaud yes. 22:06
jnthn rakudo: say map * + 2, 1,2,3;
p6eval rakudo 4a9511: OUTPUTĀ«345ā¤Ā»
jnthn w00t!
pmichaud jnthn++
$P0 = get_hll_global "$_" # ugh!
jnthn OK, now I feel like I actually achieved something today...
?
oh, that Perl script is horrbilus.
pmichaud why the set_outer ? 22:07
jnthn (Note that $_ becomes the name like infix:== in the ouput!)
pmichaud: Because the helper uses lexical lookup for the op. 22:08
We can't know the outer beforehand.
well, it could be one of many things
thus why we clone and then set_outer
pmichaud why not just do something like .assuming ?
jnthn We do do something like assuming. 22:09
However, assuming has the luxury of there being a helper used for *one* sub.
So it can statically have :outer('assuming')
Note we don't generate one helper sub per operator.
pmichaud yes, I understand that. 22:10
jnthn I was thinking of assuming when I wrote this...
pmichaud it just looks like the long-way-around to get assuming to me.
jnthn Then realized it wouldn't be quite as neat.
What would you change?
You can't statically set the outer because you don't know what it is (unless we want to generate a bunch more code, which feels like a bad thing). 22:11
You can set the outer until you've cloned it.
And you can't capture the lexical scope until you've done both
pmichaud but you can call something that is statically the outer
and I think you don't need the whatever helper left and whatever helper right
jnthn ...statically the outer? 22:12
pmichaud you call a given function 22:13
jnthn is starting to wish he'd just slipped it in with properties instead now...
pmichaud pass it the params you're wanting
PerlJam jnthn: is there a reason you left out infix:- ? :-)
pmichaud PerlJam: because it'll epically break @a[*-1] right now.
oh, it might work, but at the cost of some serious extra indirection.
jnthn Right.
I was going for, low amount of generated code. 22:14
pmichaud jnthn: so am I.
I think I can get lower than what you have :-)
anyway, it's harder to explain than to write (and see what's done), so I might take a crack at it later.
jnthn Aye. 22:15
I don't doubt you'll find a way to shorten it somehow...
I just don't get what you're suggesting.
pmichaud right -- I think you're too used to thinking in terms of explicitly doing .set_outer on things :-) 22:16
jnthn What I've done is essentially equivalent to multi infix:<+>(Whatever, Any $y) { return { $^x + $y } }
But without having to have code generated for all of the inner closures.
pmichaud yes, I'm saying the same. 22:17
I'm explicitly *not* generating lots of code for each multi version.
indeed, each multi will end up with one or two lines of PIR
jnthn With some additional helper sub called?
pmichaud yes.
which will be statically defined/compiled.
jnthn ah
pmichaud and only one.
jnthn Still think it's gonna be more indirection. 22:18
pmichaud just like in Junction, where we have
jnthn But I'll reserve judgement until I see it.
pmichaud .sub '$_' :multi('Junction', _)
.param pmc x
.param pmc y
.tailcall '!DISPATCH_JUNCTION'('$_', x, y)
.end
jnthn Indeed. Another level of indirection.
I was happily avoiding having one of those.
pmichaud oh, you're wanting to avoid the tailcall 22:19
jnthn Right.
It's not a big win not to I guess.
pmichaud at the cost of of adding a 'set_outer', though.
I think it's an even tradeoff.
jnthn Very possibly, yes.
Anyway, it's certainly not wroth spending a lot of time either way over, IMO. 22:20
pmichaud and there's an extra tailcall when the closure gets invoked.
jnthn (Also, I like that at the moment everything relating to this logic is in one file. guts.pir is huge.)
pmichaud oh, I can leave it in the same file -- that's no problem.
jnthn OK. :-)
pmichaud see, for example, the way I did gen_uprop
(the helper function is in gen_uprop, but only one shared by all of the instances) 22:21
jnthn Yes
You went for a dynop rather than waitng for the working out of Parrot's API? :-) 22:22
pmichaud Yes.
Ultimately much easier than anything else I could come up with. 22:23
also, I'm now thinking it may be rakudo-specific-enough that it may remain a dynop.
jnthn That's fair enough.
pmichaud I'm not sure that PGE will want to implement all of the isFoo rules internally.
(it might show up in PCT, though.) 22:24
literal rakudo: my @foo = 1,2,3; say @fooōæ½xAB*ōæ½xBB42; 22:25
p6eval rakudo 4a9511: OUTPUTĀ«Statement not terminated properly at line 1, near "\ufffd*\ufffd42;"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)ā¤Ā»
jnthn rakudo: my @foo = 1,2,3; say @foo<<*>>42; 22:26
p6eval rakudo 4a9511: OUTPUTĀ«Statement not terminated properly at line 1, near "42;"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)ā¤Ā»
jnthn huh?
TimToady two terms in a row
jnthn rakudo: my @foo = 1,2,3; say @foo <<*>> 42;
p6eval rakudo 4a9511: OUTPUTĀ«4284126ā¤Ā»
PerlJam whitespace is your friend.
pmichaud @foo<<*>> is a postcircumfix :-)
lambdabot Unknown command, try @list
TimToady std: my @foo = 1,2,3; say @fooĀ«*Ā»42;
jnthn OH RLY?
p6eval std 26163: OUTPUTĀ«##### PARSE FAILED #####ā¤Syntax error (two terms in a row?) at /tmp/tT6k1FTPjE line 1:ā¤------> my @foo = 1,2,3; say @fooĀ«*Ā»42;ā¤ expecting any of:ā¤ POSTā¤ infix or meta-infixā¤ infix stopperā¤ postfixā¤ postfix_prefix_meta_operatorā¤ standard
..stopperā¤ statement modifie...
22:27 PhatEddy left
TimToady nya, nya, nya 22:27
jnthn But...but...that makes them less useful for obsfucation!
TimToady nya, nya, nya
pmichaud Perl 6 giveth, and Perl 6 taketh away
PerlJam it'll be awesome when rakudo gets all of those helpful hints from std :)
jnthn TimToady: For things like map *.prime @list
TimToady std: map *.prime @list 22:28
jnthn TimToady: Are you expecting map *.thing($arg, $arg) @list to also work?
p6eval std 26163: OUTPUTĀ«##### PARSE FAILED #####ā¤Syntax error (two terms in a row?) at /tmp/4HyLtpcQBK line 1:ā¤------> map *.prime @listā¤ expecting any of:ā¤ infix or meta-infixā¤ infix stopperā¤ standard stopperā¤ statement modifier loopā¤ terminatorā¤FAILED 00:02 35mā¤Ā»
jnthn oh, needs comma
std: map *.thing($arg, $arg), @list
p6eval std 26163: OUTPUTĀ«Potential difficulties:ā¤ Variable $arg is not predeclared at /tmp/5F3TuhV1wl line 1:ā¤------> map *.thing($arg, $arg), @listā¤ Variable $arg is not predeclared at /tmp/5F3TuhV1wl line 1:ā¤------> map *.thing($arg, $arg), @listā¤ Variable @list is not
..pr...
jnthn std: my ($arg); map *.thing($arg, $arg), @list
p6eval std 26163: OUTPUTĀ«Potential difficulties:ā¤ Variable @list is not predeclared at /tmp/CRnwkhqVlq line 1:ā¤------> y ($arg); map *.thing($arg, $arg), @listā¤ok 00:02 38mā¤Ā» 22:29
jnthn yeah yeay
pmichaud std: map *.thing(1,2), <a b c>
p6eval std 26163: OUTPUTĀ«ok 00:02 36mā¤Ā»
jnthn Neat
TimToady I should have it say "Now you're talking sense..."
jnthn It's easter. Have an egg. 22:30
TimToady the yolk's on you
22:31 frzntoz_ joined
TimToady well, sigh, I forgot to run screen before I started irssi... :( 22:32
22:32 TimToady left, TimToady joined
Util rakudo: my ($a,$b,$c,$d) = { foo => 1 } xx 4; say keys( $a ), keys( %($b) ), keys( % $c ), keys( %$d ); 22:34
p6eval rakudo 4a9511: OUTPUTĀ«Scope not found for PAST::Var '%$d' in ā¤current instr.: 'parrot;PCT;HLLCompiler;panic' pc 146 (src/PCT/HLLCompiler.pir:102)ā¤Ā»
Util In Perl 5, you could dereference with `%{$href}`, or just plain `%$href`.
S03 (Changes to Perl 5 operators, first bullet) says that `%{...}` becomes `%(...)`, but is not explicit about whether `%$href` should still work.
Rakudo requires a space: `% $href`, but I cannot tell if this is a quirk of the current implementation.
TimToady still works 22:35
Util Should `%$href` still work in Perl 6, or must I add whitespace?
pmichaud rakudo doesn't understand %$href yet
I have to refactor variable handling a bit for that.
TimToady std: my ($a,$b,$c,$d) = { foo => 1 } xx 4; say keys( $a ), keys( %($b) ), keys( % $c ), keys( %$d );
Util Great, thanks!
p6eval std 26163: OUTPUTĀ«ok 00:03 38mā¤Ā»
TimToady std: my ($a,$b,$c,$d) = { foo => 1 } xx 4; say keys( $a ), keys( %($b) ), keys( % $c ), keys( % $d );
p6eval std 26163: OUTPUTĀ«ok 00:03 38mā¤Ā»
TimToady hmm I didn't expect that one to work
oh wait, it tests that earlier 22:36
Util right, with $c
TimToady I guess it works, but I'd never write it that way
Util S03: Listop-like forms use the bare sigil following by whitespace. 22:37
TimToady so it's in danger of being made illegal :)
pmichaud the listop form is the one that rakudo currently implements
but I completely agree that it's a prime candidate for confusion 22:38
TimToady arguable the %() form is also just the functional form, but...
Util Making case $c fail is fine with me.
TimToady and they all have named forms, except for maybe &() 22:39
Util I am writing a tinker-toy 5->6 converter with PPI, and was looking for clarity w.r.t. S03.
TimToady well, one more thing to (not) think about...
22:40 frzntoz left
TimToady anyway, yes, STD, uses %$foo all over the place 22:40
Util Oh, wait... Case $c works in Perl5. Yuck.
TimToady because it's easy to backtranslate to P5
22:40 Limbic_Region joined
TimToady yes, well, perl allows space in '$ foo' 22:41
Perl 5
in Perl 6 that'd be a foo() call
std: $ foo 22:42
p6eval std 26163: OUTPUTĀ«Undeclared routine:ā¤ foo used at 1 ā¤ok 00:02 35mā¤Ā»
22:42 frzntoz_ left
TimToady the fact that Perl 5 allows that space is one of the reasons Perl 6 doesn't. :) 22:42
and why @ $foo might be disallowed if I get mean enough 22:43
Util PPI mis-parses the percent in `% $foo` as an Operator. It correctly parses as a Cast in `%$foo`. 22:45
jnthn rakudo: say (*).worreva
TimToady well, that's why the existing p5-to-p6 translator is based off of MAD instead...
p6eval rakudo 4a9511: OUTPUTĀ«Could not locate a method 'worreva' to invoke on class 'Whatever'.ā¤current instr.: 'die' pc 16685 (src/builtins/control.pir:222)ā¤Ā» 22:46
22:46 frzntoz joined
jnthn rakudo: say *.worreva 22:46
p6eval rakudo 4a9511: OUTPUTĀ«Statement not terminated properly at line 1, near ".worreva"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)ā¤Ā»
22:46 frzntoz left
jnthn pmichaud: Any clues why the parser might not be liking the second of those? 22:46
pmichaud jnthn: it's parsing as infix:<*> 22:47
i.e., it's parsing as (say) * (.worreva)
jnthn Oh.
That's unfortunate.
pmichaud (that's a guess)
Util Right, but when I poked at MAD last year, it quickly drove me mad.
pmichaud rakudo: say * 3
p6eval rakudo 4a9511: OUTPUTĀ«Statement not terminated properly at line 1, near "3"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)ā¤Ā»
pmichaud oh, maybe not.
hrm.
rakudo: say * .int 22:48
p6eval rakudo 4a9511: OUTPUTĀ«Statement not terminated properly at line 1, near ".int"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)ā¤Ā»
pmichaud okay, that's not it.
Util So this is low-hanging-fruit version. -Ofun
Also, it will make me read every word of the specs. 22:49
TimToady have the appropriate amount of fun
pmichaud jnthn: it's because we have
jnthn pmichaud: If it's helpful, it's dying in called from Sub 'parrot;Perl6;Grammar;eat_terminator
pmichaud token expect_term { | <noun> <post>* {*} #= noun | '*' {*} #= *
} 22:50
Util Thanks, all!
pmichaud i.e., for some reason '*' is being treated specially outside of <noun>
TimToady should just be a term:
pmichaud yes. 22:51
22:51 shachaf joined
TimToady commuting & 22:52
jnthn looks at the email of things NPW want 22:54
1) A list of 4-6 points (max 3-5 words each) of the main things you'd
like people to remember from your talk.
...4-6 points from a 2 hour talk is tricky!
pmichaud people won't remember more than 4-6 anyway :-) 22:55
jnthn * Perl 6 rocks
* Get it at www.rakudo.org
* Buy Jonathan beer
* Contribute! 22:56
done
pmichaud s/Contribute!/Write applications/
make it more specific how they can contribute :-)
jnthn ...I wasn't being enitrely serious with that list... ;-)
But maybe something like that is the way to go.
pmichaud yes, I think so.
jnthn I'm not sure I'll get away with the third though...
OK, moved * to term...let's see how this fares in the tests. 22:57
pmichaud don't forget to update actions.pm (I know youlikely didn't...)
jnthn Akshually I did.
nyah nay 22:58
Sanity tests run. Here goes more make spectest...
(This has the *.abs => { $_.abs } patch in too... :-))
pugs_svn r26164 | hinrik++ | [util/perl6.vim] operator highlighting fixes 22:59
jnthn pmichaud: While you're working on postcircumfix, here's another ticket you might want to be aware of if you ain't already: rt.perl.org/rt3/Ticket/Display.html?id=63986 23:01
23:02 wknight8111 joined
pugs_svn r26165 | hinrik++ | [util/perl6.vim] update TODO 23:02
pmichaud okay, will do that.
... we check specifically for '-1' ? 23:03
wow. :-)
23:03 nihiliad left
pmichaud actually, we check specifically for '[-1]' :-) 23:04
s/we/STD.pm/
that's easy ! :-) 23:05
std: my @a = 1..5; @a[-1]; 23:06
p6eval std 26165: OUTPUTĀ«##### PARSE FAILED #####ā¤Obsolete use of [-1] subscript to access final element; in Perl 6 please use [*-1] instead at /tmp/E6XYpcIuYR line 1:ā¤------> my @a = 1..5; @a[-1];ā¤FAILED 00:02 38mā¤Ā»
pmichaud std: my @a = 1..5; @a[-2];
p6eval std 26165: OUTPUTĀ«ok 00:02 38mā¤Ā»
skids rakudo: class D is ::H {}; 1; 23:07
p6eval rakudo 4a9511: OUTPUTĀ«Null PMC access in isa()ā¤current instr.: '!meta_trait' pc 19173 (src/builtins/guts.pir:640)ā¤Ā»
skids rakudo: class D is ::H {};
p6eval rakudo 4a9511: OUTPUTĀ«Null PMC access in isa()ā¤current instr.: '!meta_trait' pc 19173 (src/builtins/guts.pir:640)ā¤Ā»
jnthn rakudo: ::H
p6eval rakudo 4a9511: ( no output )
jnthn rakudo: say ::H
p6eval rakudo 4a9511: OUTPUTĀ«Null PMC access in isa()ā¤current instr.: 'parrot;List;!flatten' pc 7464 (src/classes/List.pir:236)ā¤Ā»
skids rakudo: my ::H $a;
p6eval rakudo 4a9511: ( no output )
skids rakudo: my ::H $a; 1;
p6eval rakudo 4a9511: ( no output ) 23:08
jnthn rakudo: class D is H { }
p6eval rakudo 4a9511: OUTPUTĀ«The type H does not exist. at line 1, near "{ }"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)ā¤Ā»
jnthn rakudo: class D is H1B::Visa { }
p6eval rakudo 4a9511: OUTPUTĀ«The type H1B::Visa does not exist. at line 1, near "{ }"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)ā¤Ā»
jnthn oh i noez
We see ::H and consider it a type capture.
std: class D is ::H { }
p6eval std 26165: OUTPUTĀ«ok 00:02 34mā¤Ā»
jnthn std: class D is H { }
p6eval std 26165: OUTPUTĀ«ok 00:02 34mā¤Ā» 23:09
pmichaud ::H declares a lexical type, yes.
jnthn ah, std doesn't care for non-existent types yet
pmichaud ::H is a declaration.
jnthn Aye.
pmichaud it's not a claim that H exists.
oh, you mean in the second one.
nm.
skids ::H is a declaration if it is in a declaration, not if it is in an rvalue
jnthn Part of the issue is more that is_type sees the leading ::H and adds H to the types it knows. 23:10
But H could well be a null PMC.
If we didn't set it to something.
rakudo: ::H := Int; my H $x = 42; say $x; $x = "fail"
p6eval rakudo 4a9511: OUTPUTĀ«42ā¤Type mismatch in assignment.ā¤current instr.: 'die' pc 16685 (src/builtins/control.pir:222)ā¤Ā»
jnthn rakudo: ::H; my H $x = 42; say $x; $x = "fail" 23:11
p6eval rakudo 4a9511: OUTPUTĀ«42ā¤Ā»
pmichaud I think ::H might be a declaration even as an rvalue.
jnthn rakudo: my ::H $x = 42; say $x; $x = "fail"
p6eval rakudo 4a9511: OUTPUTĀ«42ā¤Ā»
jnthn rakudo: my ::H $x = 42; say $x; $x = "fail"; say H
skids spec says "as an rvalue" is "is a noop"
p6eval rakudo 4a9511: OUTPUTĀ«42ā¤Null PMC access in isa()ā¤current instr.: 'parrot;List;!flatten' pc 7464 (src/classes/List.pir:236)ā¤Ā»
pmichaud skids: where does it say that? 23:12
jnthn pmichaud: Also, when you add infix:<-> to the list of * ops, there's two tests to unfudge and rt.perl.org/rt3/Ticket/Display.html?id=62066 can be closed. :-) 23:13
Hey, at this rate we might even get back down to 300...
skids S12 line 82
jnthn std: my Blah $x; 23:14
pmichaud okay. So ::H as an rvalue doesn't declare H
p6eval std 26165: OUTPUTĀ«##### PARSE FAILED #####ā¤Malformed myā¤In "my" declaration, typename Blah must be predeclared (or marked as declarative with :: prefix) at /tmp/Q1LdaLDCqy line 1:ā¤------> my Blah $x;ā¤FAILED 00:02 34mā¤Ā»
jnthn std: ::Blah; my Blah $x;
p6eval std 26165: OUTPUTĀ«##### PARSE FAILED #####ā¤Malformed myā¤In "my" declaration, typename Blah must be predeclared (or marked as declarative with :: prefix) at /tmp/1NbNsovliM line 1:ā¤------> ::Blah; my Blah $x;ā¤FAILED 00:02 34mā¤Ā»
jnthn std: class X is ::Blah { }; my Blah $x; 23:15
p6eval std 26165: OUTPUTĀ«##### PARSE FAILED #####ā¤Malformed myā¤In "my" declaration, typename Blah must be predeclared (or marked as declarative with :: prefix) at /tmp/XJvtbHe3SM line 1:ā¤------> class X is ::Blah { }; my Blah $x;ā¤FAILED 00:02 35mā¤Ā»
jnthn OK, STD.pm gets it right, it seems.
pmichaud the error message there seems a bit misleading "marked as declarative"
if ::H is "declarative", I'd expect it to have declared H.
jnthn std: my ::Blah $x;
p6eval std 26165: OUTPUTĀ«ok 00:02 35mā¤Ā»
jnthn hmm 23:16
TimToady traits are not declarative
skids is is "is X" considered declarative "context"?
TimToady or is foo($x) would declare $x
that was actually a bug I had to fix in STD once upon a time
skids I guess that answers that. So at least it's a *good* thing that rakudo behaves differently with my ::H $a. 23:17
TimToady std: my ::Blah $x; my Blah $y;
p6eval std 26165: OUTPUTĀ«ok 00:02 35mā¤Ā»
TimToady whew
std: my $x = ::Blah; 23:18
p6eval std 26165: OUTPUTĀ«ok 00:02 35mā¤Ā»
jnthn TimToady: In this case, what would you expect Blah to be?
TimToady to that extent, it's not a no-op
a type that hasn't been declared yet
presumably the lookup would have to be delayed till later 23:19
skids my ::H $a; class H is also { has $.s }; $a = H.new;
pmichaud but it does signal that Blah is a valid type for the remainder ot he scope, yes?
skids rakudo: my ::H $a; class H is also { has $.s }; $a = H.new;
pmichaud skids: I don't think 'is also' would be needed there
p6eval rakudo 4a9511: OUTPUTĀ«Null PMC access in find_method()ā¤current instr.: '!meta_attribute' pc 19322 (src/builtins/guts.pir:703)ā¤Ā»
pmichaud saying my ::H $a; doesn't create a class.
TimToady should need augment/is also on a stubbed class
jnthn Such that a later ::Blah = Int; would retroactively affect assignments to $a from that point onward?
TimToady *shouldn't
skids my ::H $a; class H {};
rakudo: my ::H $a; class H {}; 23:20
23:20 frew|work left
p6eval rakudo 4a9511: OUTPUTĀ«Re-declaration of type H at line 1, near ";"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)ā¤Ā» 23:20
TimToady we don't know the actual run-time class of H at that point
pmichaud rakudo doesn't have stubs yet.
TimToady only that H whatever type $a is initialized to
which, since there is none, is a problem :)
jnthn TimToady: Is Rakudo thus correct to complain H has already been declared as a type, though? 23:21
TimToady types with :: in a decaration are captured en passnat
pmichaud (I think no.)
TimToady *passant
my ::H $a declares type H, yes
it's not a stub
pmichaud oh.
jnthn Right. So the type is declared.
TimToady mainly this syntax is used in signatures 23:22
jnthn So trying to redeclare it is a re-declaration on the order of class H { }; class H { }
TimToady (::T $x, T $y)
jnthn Right. We handle it in signatures.
TimToady and presumably my ::T $x = something() does the same thing
jnthn That's...tricky... 23:23
But could be made to work, yes.
pmichaud that seems... tricky.
jnthn The difficulty is that it's assignment and not binding.
pmichaud even as binding it's tricky-ish.
jnthn True.
Neither are easy.
pmichaud with my ::T $x = something, does that mean that T is always "whatever type $x has" or "whatever type $x is initialized to"?
jnthn The first scares me... :-) 23:24
pmichaud both scare me :-)
yes, the second scares me less.
but since it ends up parsing as (my ::T $x) = something
that's... icky.
jnthn Implementing either scares me. The potential to screw up using it with the first semantics scares me more. 23:25
TimToady that might force the first choice
well, maybe not
skids also if I get this right in my/our ::H $a; ::H shares the my/our ? 23:27
pugs_svn r26166 | jnthn++ | [t/spec] Couple of tests for *.foo generating a closure. 23:28
jnthn (plus rakudo patches just pushed make that pass :-)) 23:29
dalek kudo: f9a2236 | jnthn++ | src/parser/ (2 files):
Fix parsing of whatever.
kudo: 70fc009 | jnthn++ | src/classes/ClassHOW.pir:
Implement *.foo generating the closure { $^wob.foo }.
jnthn Tene: I've left off the annotations stuff today...let me know if you don't have time to do more on it, and I can look at it some though. 23:31
TimToady skids: don't understand what you're asking
pmichaud skids: ::H is always "my" 23:32
i.e., the H is lexically scoped.
skids S12 says "binds a new type name within the declaration's scope"
23:32 DemoPhreak joined
pmichaud our ::H $a declares $a as a package variable, but the 'H' is only relevant to the current lexical scope. 23:32
(at least, that's what I seem to remember being told before :-) 23:33
skids OK, so it's within the scope the declaration is in, not within the scope the declaration specifies.
pmichaud that's what I remember. 23:34
TimToady yes, that's correct 23:35
all of these declarations are primarily lexical, but some of that have an additional scope, like "our" and "has"
has ::T $.attr = something() is a bit mind blowing though 23:36
skids reminisces his youth when "scope" was just a brand of mouthwash 23:37
TimToady well, some people distinguish scope from lifetime 23:38
pmichaud s/brand of mouthwash/device used to analyze electrical signals/
jnthn is still youthful.
TimToady nah, it's what you put on top of your deer rifle 23:39
jnthn Though most people looking at me think I'm 5-10 years older than I actually am. :-|
TimToady is it better to be thought wiser or more foolish than you really are? :) 23:40
jnthn will write rakudo-day report tomorrow, otherwise it'll probably be full of typos.
pmichaud TimToady: "Yes."
jnthn ;-)
TimToady rakudo: class A { has ::T $.attr = 42; method sayt { say T.WHAT } }; A.new.sayt 23:43
p6eval rakudo 70fc00: OUTPUTĀ«Null PMC access in can()ā¤current instr.: '!dispatch_method' pc 18204 (src/builtins/guts.pir:110)ā¤Ā»
TimToady rakudo: class A { has ::T $.attr = 42; method sayt { say T.WHAT } }; A.new(:attr(42)).sayt 23:44
p6eval rakudo 70fc00: OUTPUTĀ«Null PMC access in can()ā¤current instr.: '!dispatch_method' pc 18204 (src/builtins/guts.pir:110)ā¤Ā»
TimToady am I doing something wrong?
rakudo: class A { has ::T $.attr = 42; method sayt { say $!attr.WHAT } }; A.new(:attr(42)).sayt 23:46
jnthn TimToady: It's not putting anything in T
p6eval rakudo 70fc00: OUTPUTĀ«Intā¤Ā»
jnthn TimToady: You're getting the equivalent of a null pointer exception minus the segfault. :-)
pmichaud rakudo doesn't know to bind ::T on an assignment.
TimToady well, it's not exactly an assignment...
pmichaud correct
jnthn initilization
whatever
pmichaud but it still doesn't know to do it.
it knows to do it on subroutine call binding 23:47
jnthn I hadn't actually ever considered that you'd write a ::T there.
23:47 DemoFreak left
TimToady rakudo: my ::T $x := 42; say T.WHAT 23:47
p6eval rakudo 70fc00: OUTPUTĀ«Null PMC access in can()ā¤current instr.: '!dispatch_method' pc 18204 (src/builtins/guts.pir:110)ā¤Ā»
jnthn And then knowing that I am curious if T is then per instance.
TimToady I expect it would be
pmichaud if ::T is "my" scope, then....
TimToady it's polymorphic, just like any other class name :)
well, I guess we'd have to decide whether it was the class of $!attr or of $.attr, since those could differ... 23:49
$!attr is more sane, but $.attr is more like actual polymorphic classnames 23:50
the "virtual" classnames discussed earlier
pmichaud I find it a bit "weird" to think of it per-instance. Normally ::T creates a lexically-scoped thing.
TimToady it's a lexically scoped name 23:51
pmichaud ...such that later when I say 'T', I'm doing a lexical lookup
23:51 bacek_ joined
pmichaud as opposed to an attribute lookup 23:51
TimToady but in this case, it makes sense only if it points to something else
23:51 bacek left 23:52 LylePerl left
TimToady has $x is also lexically scoped, but refers to the current object 23:52
just because a name is lexically scoped doesn't mean that its meaning can't be dynamically determined 23:53
pmichaud okay.
TimToady but presumably that possibility can be inferred from the declarator in question 23:54
jnthn pmichaud: I more worry that class A { has ::T $x; method x { say T } }; A.new(x => 42).x; A.new(x => 'boo').x # what would this do?
pmichaud jnthn: that's the problem I'm seeing, yes.
jnthn pmichaud: Thus why I thought it might have to be per instance if it's going to make sense.
TimToady I think that can only mean the type of $x in the current instance 23:55
pmichaud I'm not arguing against it being per-instance; it just feels weird. I have to adjust my internal scope a bit.
so, ::T in a 'has' declarator really has per-instance scope, similar to the way that $x in 'has $x' does. 23:56
jnthn pmichaud: Trying seeing the ::T affected by the scope declarator, perhaps.
pmichaud I think I could handle that.
it breaks my concept that '::T' always declares T as being something like 'my', but that's not a big issue for me. 23:57
i.e., I just have to readjust. Plus I'm a bit sleep deprived this evening.
23:57 wknight8111 left
jnthn pmichaud: Sleep deprived? How come? ;-) 23:58
pmichaud got to bed late last night, woke up early this morning.
jnthn Don't worry, soon you'll have some jet lag to help with it. ;-)
pmichaud so, ~ 2hrs sleep.
jnthn !!
ouch!
For me that would take...a LOT of coffee.
skids I CAN HAS PILLOWZ?
pmichaud I'm normally most productive (programming wise) in the late evening, so I tend to stay up very late. 23:59
But lately Paula has been working overtime for $job, which means I'm also the early riser for kiddies.
skids Yeah me too. I think my body tries to kill me when I sleep and the poison only wears off in the evening.

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!