»ö« | perl6.org/ | nopaste: paste.lisp.org/new/perl6 | evalbot usage: 'perl6: say 3;' or rakudo:, alpha:, pugs:, std:, or /msg p6eval perl6: ... | irclog: irc.pugscode.org/ | UTF-8 is our friend!
Set by lichtkind on 5 March 2010.
TimToady yes :) 00:00
sorear I appear to be spending a considerable amount of time not tracing the DFA engine
TimToady it's a good idea, just needs someone young, active, with lots of tuits, who is not allergic to yak shaving 00:01
diakopter do tuits get rounder or anglier with age
pmichaud rarer. 00:02
and pricklier.
TimToady there's a slightly smaller number of tuits, but many more places to put 'em 00:03
sorear I have a semi-automatic yak shaver, it's labelled :%s///cg 00:04
TimToady I've spent a goodly portion of today talking to my brother-in-law, who is making large holes in my house.
jnthn Hmm. So Parrot currently allocates for every object an Object PMC and in turn a ResizablePMCArray ==> two GCables + some memory overhead for the attribute storage. I'd figured that switching that to a C array would save us a lot of GCables (well, I guess that has happened) but also memory usage *increased*. Maybe I've sprung a leak... :-S
pmichaud hmm. jnthn has leaks in his objects, and TimToady has holes in his house. 00:05
sorear jnthn: I've been telling people that Object = 5 memory blocks for a while now... 00:06
jnthn sorear: I wasn't not believing you. :-)
sorear: I've known it's heavy for a while, I figured it was time for a diet. :-)
Alas, the diet made me fatter.
pmichaud today during the design meeting I proposed holding a Lorito/Parrot BOF at YAPC::NA, the explicit purpose of which is to come up with some core design principles that might drive the development of Lorito. (more)
(1) suggestions would be welcomed 00:07
(2) my #1 suggestion is going to be "make a fast and efficient object metamodel/implementation"
(end for now) 00:08
diakopter :)
jnthn pmichaud: I've been sketching out how to do better for Rakudo on that front of late.
pmichaud jnthn: well, we can only do so much before we basically take over (or thoroughly subvert) the VM :) 00:09
jnthn: important ping
jnthn pmichaud: important pong
pmichaud okay, I have a problem (at least I think it's a biggish one) 00:10
jnthn Ugh.
pmichaud I've moved Positional into the setting
now I want to declare Match as being "does Positional does Associative"
and I get
Method 'of' collides and a resolution must be provided by the class
jnthn conflict relating to 'of'? 00:11
pmichaud yes.
jnthn gah, you beat me.
:-)
method of { Mu }
pmichaud perfect.
okay, not big then.
sorear what does "of" mean in both roles?
jnthn pmichaud: .of tells you what the ::T was
pmichaud right
TimToady maybe they both do the "Of" role
jnthn sorear: role Positional[::T] { method of { T } }
pmichaud I was trying to figure out how to get to the T.
but I don't need to do that. 00:12
so, we're good.
jnthn pmichaud: Well, for match objects they're always using untyped.
pmichaud jnthn: right.
as I said, "perfect." :-)
jnthn So Mu is the correct answer.
(take over the VM) yeah, I wonder each time we do that a step more how long until we almost *have* a VM. :-) 00:13
pmichaud well, that's why I volunteered to set something up for yapc::na
we'll have a lot of parrot core people there, and maybe I can set a few guidelines for them
or at least say "if you really want a good VM for rakudo, this is what we think needs emphasizing" 00:14
jnthn I think we both have ideas of what we'd like the metamodel to look like, but how far the Parrot folks will buy them, or if they'll get rejected as "too Perlish", I've no idea.
pmichaud right
I was going to suggest the Perl 6/Moose metamodel as well, especially since that model can be used to support both class-based and prototype-based OO 00:15
but more important (to me) is to have a speedy object system. Right now what we have is anything but that.
jnthn I'm certainly willing to try working with the Parrot folks to get us what we want first though. It's far preferable.
pmichaud I mean, attribute access is slow, method invocation is slow, etc.
jnthn *nod*
Attribute access in Perl 6 can be done by offset. 00:16
pmichaud I'd much rather have a fast object system at the core, with operators and stuff layered on top, than to have fast operators at the core, with an object model layered on type.
jnthn *nod*
pmichaud s/type/top/
jnthn (for a lot of cases)
But we can't take advantage of that at the moment.
diakopter "fast object system" - incl primitive types, classes? single-inheritance? GC? 00:17
pmichaud diakopter: GC, yes
jnthn diakopter: primitive types as attributes has to happen.
00:17 skids joined
diakopter k 00:17
pmichaud "classes" in the way that the Perl 6 metamodel has them
i.e., they're meta-level objects that manage dispatch 00:18
ash__ parrot's PIR meta model is a bit bare....
diakopter it's not the dispatch at the lowest levels that makes it slow?
(currently in parrot?)
pmichaud diakopter: it's partially that, yes.
currently method dispatch requires hash lookups and a pretty lengthy search through inheritance and role chains, iiuc. 00:19
jnthn Not role chains.
pmichaud sorry, inheritance chains
jnthn Composition is (really) flattening.
pmichaud you're correct, not role chains
jnthn Just inheritance.
diakopter none of it is resolved at compile-time?
00:19 Visitor99 joined
pmichaud a HLL can potentially do that, yes. 00:19
but we're not really set up to do that at the moment. 00:20
diakopter I mean, at the lowest levels
the dispatching on the lowest level objects
pmichaud and parrot doesn't really help much there, as its facilities for managing and referencing subs is a bit limited
anyway, I don't know that what we produce will greatly influence Parrot, and that would be okay, I just thought it'd be useful for them and us to brainstorm the key design principles we'd like to see in an vm 00:21
jnthn *nod*
We can ask. :-)
pmichaud to me, it's not really us asking them (more) 00:22
oops, I have to run to dinner
we'll pick this up again tomorrowish
jnthn ENOMORE
OK :-)
pmichaud on the plus side, the branch is up to S05-mass/properties-derived.rakudo................. 178 0 0 78 256
with apparently no errors
jnthn \o/
pmichaud (I'm running full spectest now) 00:23
so I think we're closing in on a merge quickly.
jnthn :-)
pmichaud bbl
jnthn o/
pugssvn r31303 | sorear++ | [dfa/Cursor] Don't use Class::MOP to locate protoregex methods; do it manually. Reduces time to parse 2 + 2 cold from 5.15s to 3.35s (avg 10 runs) 00:25
Visitor99 rakudo: sub s1{.say for(1..5)}; &s1;
p6eval rakudo c9ee2e: ( no output )
jnthn Visitor99: &s1 doesn't call the sub 00:26
Also, some extra whitespace needed. :-) 00:27
rakudo: sub s1{.say for 1..5}; s1;
p6eval rakudo c9ee2e: OUTPUT«1␤2␤3␤4␤5␤»
sorear the hot time for trunk Cursor is 2.35s
so we've mostly bridged the gap
Visitor99 i want to have a junction with 2 funtions
and the run the junction
it is possible?
jnthn Yup
Should be
Visitor99 the=then
jnthn rakudo: sub a { say 1 }; sub b { say 2 }; my $j = &a & &b; $j(); 00:28
p6eval rakudo c9ee2e: OUTPUT«1␤2␤»
Visitor99 sub s1{.say for(1..5)}; sub s2{.say for('a'..'b')}; $subs = &s1|&s2; $subs.say.perl;
00:28 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
Visitor99 rakudo: sub s1{.say for(1..5)}; sub s2{.say for('a'..'b')}; $subs = &s1|&s2; $subs.say.perl; 00:29
p6eval rakudo c9ee2e: OUTPUT«===SORRY!===␤Symbol '$subs' not predeclared in <anonymous> (/tmp/xn73YuQyE_:11)␤»
Visitor99 rakudo: sub s1{.say for(1..5)}; sub s2{.say for('a'..'b')}; my $subs = &s1|&s2; $subs.say.perl;
p6eval rakudo c9ee2e: OUTPUT«any({ ... }, { ... })␤»
jnthn Visitor99: You're not actually calling them there.
You're calling .say on the junction object.
Visitor99 well... that's the part i don't know yet :)
jnthn rakudo: sub s1{.say for(1..5)}; sub s2{.say for('a'..'b')}; my $subs = &s1|&s2; $subs().say.perl; 00:30
p6eval rakudo c9ee2e: OUTPUT«1␤2␤3␤4␤5␤a␤b␤Method 'HOW' not found for invocant of class 'ArrayIterator'␤ in '&infix:<===>' at line 5938:CORE.setting␤ in 'Junction::postcircumfix:<( )>' at line 1␤ in main program body at line 11:/tmp/zwEbsCxljj␤»
Visitor99 rakudo: sub s1{.say for(1..5)}; sub s2{.say for('a'..'b')}; my $subs = &s1|&s2; $subs.say.perl; $subs();
p6eval rakudo c9ee2e: OUTPUT«any({ ... }, { ... })␤1␤2␤3␤4␤5␤a␤b␤Method 'HOW' not found for invocant of class 'ArrayIterator'␤ in '&infix:<===>' at line 5938:CORE.setting␤ in 'Junction::postcircumfix:<( )>' at line 1␤ in main program body at line 11:/tmp/B1Hbg74UTw␤»
jnthn wtf
diakopter bbq
jnthn It ran it anyway...
mmm...bbq
Visitor99 rakudo: sub s1{.say for(1..5)}; sub s2{.say for('a'..'b')}; my $subs = &s1|&s2; $subs();
p6eval rakudo c9ee2e: OUTPUT«1␤2␤3␤4␤5␤a␤b␤Method 'HOW' not found for invocant of class 'ArrayIterator'␤ in '&infix:<===>' at line 5938:CORE.setting␤ in 'Junction::postcircumfix:<( )>' at line 1␤ in main program body at line 11:/tmp/W34xAjikHY␤»
Visitor99 it is possible to run them in parallel? 00:31
rakudo: sub s1{.say for(1..5)}; sub s2{.say for('a'..'e')}; my $subs = &s1^&s2; $subs();
p6eval rakudo c9ee2e: OUTPUT«1␤2␤3␤4␤5␤a␤b␤c␤d␤e␤»
jnthn Visitor99: Not yet in Rakudo.
Visitor99 rakudo: sub s1{.say for(1..5)}; sub s2{.say for('a'..'e')}; my $subs = one(&s1,&s2); $subs(); 00:33
p6eval rakudo c9ee2e: OUTPUT«1␤2␤3␤4␤5␤a␤b␤c␤d␤e␤»
Visitor99 rakudo: sub s1{.say for(1..5)}; sub s2{.say for('a'..'e')}; my $subs = all(&s1,&s2); $subs();
p6eval rakudo c9ee2e: OUTPUT«1␤2␤3␤4␤5␤a␤b␤c␤d␤e␤Method 'HOW' not found for invocant of class 'ArrayIterator'␤ in '&infix:<===>' at line 5938:CORE.setting␤ in 'Junction::postcircumfix:<( )>' at line 1␤ in main program body at line 11:/tmp/ZnWRewdWFz␤»
Visitor99 rakudo: sub s1{.say for(1..5)}; sub s2{.say for('a'..'e')}; my $subs = none(&s1,&s2); $subs();
p6eval rakudo c9ee2e: OUTPUT«1␤2␤3␤4␤5␤a␤b␤c␤d␤e␤Method 'HOW' not found for invocant of class 'ArrayIterator'␤ in '&infix:<===>' at line 5938:CORE.setting␤ in 'Junction::postcircumfix:<( )>' at line 1␤ in main program body at line 11:/tmp/bzXpKGcuLV␤»
Visitor99 rakudo: sub s1{.say for(1..5)}; sub s2{.say for('a'..'e')}; my $subs = one(s1(),s2()); $subs(); 00:34
p6eval rakudo c9ee2e: OUTPUT«1␤2␤3␤4␤5␤a␤b␤c␤d␤e␤invoke() not implemented in class 'ArrayIterator'␤ in <anon> at line 5139:CORE.setting␤ in 'Junction::postcircumfix:<( )>' at line 5938:CORE.setting␤ in main program body at line 11:/tmp/A7_D6O6vm_␤»
pugssvn r31304 | sorear++ | [dfa/Cursor] Gut the monolithic lexer cache, as it is now actually a pessimization. 00:36
00:38 lest_away is now known as lestrrat 00:40 masonkramer_ joined, masonkramer left, masonkramer_ is now known as masonkramer
jnthn -> sleep 00:41
sorear stefan@stefans:/usr/local/src/pugs/src/perl6$ perl -e 'use strict; BEGIN { constant->import(DEBUG => 1) }; BEGIN { DEBUG }' 00:43
Bareword "DEBUG" not allowed while "strict subs" in use at -e line 1.
I have a feeling I'm misunderstanding something extremely important
are BEGIN blocks not run before the remainder of the file is parsed?
pmichaud down to 6 failing test files. 00:45
sorear ah, found it
apparently "constant" wasn't loaded 00:46
00:50 kidd left
pugssvn r31305 | sorear++ | [dfa/Cursor] Change $DEBUG to a use constant. 00:52
00:53 snarkyboojum joined
sorear only took 30 seconds of STD.pm6 parse time 00:56
01:04 cdarroch left 01:08 knewt2 left
pugssvn r31306 | sorear++ | [dfa/Cursor] Small evil microoptimization to the decision tree engine 01:13
sorear Is there a good way to get precise costs from Perl 5? 01:16
I'd like some magic button I can push for "Report # of executed ops at end" 01:17
there's too much statistical noise in STD.pm6 timings to effectively microoptimize with just timings
01:21 knewt2 joined 01:25 plobsing joined
snarkyboojum sorear++ # re dfa/Cursor bootstrapping STD.pm6!! 01:26
01:33 Chillance joined 01:36 broquaint joined 01:37 whiteknight left 01:45 snarkyboojum left, xabbu42 left 01:46 xabbu42 joined 01:47 masonkramer_ joined 01:52 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42 02:01 Visitor99 left
diakopter giggles at the mention of "the evil mangler" in www.cse.unsw.edu.au/~chak/papers/ghc-llvm.pdf 02:09
sorear yes, the evil mangler 02:13
postprocessing gcc -S output with regexes, what could possibly go wrong?
02:13 snarkyboojum joined
diakopter this paper is interesting 02:13
02:14 Chillance left 02:21 TiMBuS joined
diakopter hah; "the Righteous Mangler" 02:22
snarkyboojum hey - that's my uni! :) 02:25
and that's my lecturer for next session :) 02:27
diakopter heh 02:28
02:28 meppl left
diakopter tell him typo in first paragraph of section 6.2 - missing space in line 5 02:28
snarkyboojum heh 02:29
diakopter also missing a space in the sixth-from-last line of section 6.2 02:30
pugssvn r31307 | colomon++ | [t/spec] Fudge out test that depended on Array isa Seq. 02:31
diakopter its -> it's in the 3rd-to-last line of first paragraph of section 6.3
same in the last sentence of section 6.3 02:32
snarkyboojum diakopter: perhaps you could provide your peer review services :) 02:34
diakopter certainly not technical review.. maybe english punctuation 02:35
02:35 pnate left 02:42 xabbu42 left, xabbu42_ joined
colomon pmichaud: uniq.t error is kind of weird. I mean, for sure our .uniq implementation sucks. But I really don't understand why the test works in master and fails in list. 02:43
02:52 ggoebel left 02:54 snarkyboojum left 02:56 pronik` joined 02:57 pronik left 03:07 pnate joined 03:08 Visitor99 joined 03:09 masonkramer_ left 03:13 tedv left, snarkyboojum joined 03:24 xabbu42_ left, xabbu42 joined 03:29 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42 03:44 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
Visitor99 hi again.... 03:44
is there such thing as a "Duration" datatype? (related to time) 03:45
sorear yes
it's even called that
Visitor99 is there a synopse about that? i was looking at s32 and Instant is mentioned there 03:47
but no 'Duration'
pmichaud Visitor99: Synopsis 2 03:48
Visitor99 thanks pmichaud!
03:48 hercynium joined
pugssvn r31308 | sorear++ | [dfa/Cursor] Cache results of decision trees for a 1.43% instruction count reduction 03:48
03:49 snarkyboojum left 03:55 skids left 03:56 macdaddy left 04:07 snarkyboojum joined, kda left, kda joined 04:10 Visitor99 left
dukeleto How does one turn a Rakudo data structure into a Parrot data structure ? 04:14
dukeleto has Perl 6 running on PL/Parrot, and is now trying to data marshall 04:15
Rakudo Perl 6 on PL/Parrot, that is.
04:24 mikehh left
pmichaud dukeleto++ 04:25
dukeleto pmichaud: thanks. it is still rough, but is looking promising
Parrot_PMC_get_integer seems to just return 0 on any Rakudo integer 04:26
dukeleto is mostly sure about that, but will verify
pmichaud it's possible, although I'd find it odd.
actually, I'm pretty sure that can't be the case, or a lot of other code would break. 04:27
dukeleto pmichaud: if you think it should work, then I probably have a bug somewhere in my code, which gives me hope :)
pmichaud I'm pretty sure it works at least part of the time. 04:28
otherwise arrays wouldn't index properly.
(which definitely use Rakudo Ints for the indexes)
04:29 mikehh joined
dukeleto pmichaud: i am using the Parrot embed interface from C, could that be part of it? Rakudo goes thru NQP->PIR, right? 04:30
pmichaud it could. Yes, when Rakudo is running it's all PIR, dynops, and dynpmcs. 04:31
there aren't any special C libraries or anything we use.
oops, I'm wrong -- we do have a special binder library... but that shouldn't affect this at all.
04:33 pronik`` joined 04:36 pronik``` joined, pronik` left
dukeleto pmichaud: i will dig deeper and try to figure out exactly what is not working. And write more tests.... 04:37
04:38 pronik`` left 04:48 Superjane joined
Superjane hi 04:48
04:51 agentzh joined 04:58 xomas_ left 05:00 ewilhelm left, ewilhelm joined, sunnavy left 05:01 sunnavy joined 05:07 yinyin left
pmichaud down to 9 failing tests. 05:08
PerlJam pmichaud: good morrow :)
pmichaud at least I think it's 9, the "make test" output is awfully noisy.
05:10 yinyin joined 05:12 kaare joined, kaare is now known as Guest94288
dukeleto Superjane: good $localtime 05:12
05:13 \shade\ left, pronik``` left
sorear has figued out how to implement *general* cursor reuse 05:15
for all tweaks, not just add_categorical ones
*lexer reuse
PerlJam sorear++ 05:17
(I have no idea what that really /means/, but sorear++ nonetheless :-) 05:18
pmichaud it's pretty important
snarkyboojum agrees with PerlJam
pmichaud I'm eager to hear how it's done (when my brain will be able to take it)
(which isn't now)
PerlJam sorear: could you explain it to me? (maybe even tell how it's done and pmichaud can backlog when he's able) 05:19
pmichaud 7 tests. 05:20
dukeleto would be interested to hear as well 05:21
05:23 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
snarkyboojum pmichaud++ # pretty heroic effort :) 05:25
dukeleto rakudo: sub r { 42 }; r() 05:26
p6eval rakudo c9ee2e: ( no output )
dukeleto what is wrong with that?
snarkyboojum prints 42 in the REPL
05:27 ab5tract left
dukeleto snarkyboojum: yep 05:27
snarkyboojum: that is what is tripping me up
05:27 ab5tract joined
sorear the crucial point is that the lexer cache needs to be keyed off Regex.WHICH, not name 05:27
snarkyboojum which is right no?
sorear once that's done it fell into place quickly
dukeleto perl6: sub r { 42 }; r()
p6eval elf 31308, pugs, rakudo c9ee2e: ( no output )
sorear I'll make this clearer with code in a little bit
PerlJam At a guess I'd say that "lexer reuse" sounds like an optimization whereby each time we switch languages (perl, regex, quoted strings, whatever) rather than creating a new lexer each time, we use one we've already built. 05:28
snarkyboojum rakudo: sub r { 42 }; say r()
p6eval rakudo c9ee2e: OUTPUT«42␤»
dukeleto std: sub r { 42 }; r()
p6eval std 31308: OUTPUT«ok 00:01 107m␤»
snarkyboojum dukeleto: REPL autoprinting vs commandline not printing anything? 05:29
dukeleto snarkyboojum: could be. how would I "return" r() instead of printing it ?
snarkyboojum: i am running that Perl 6 code from the Parrot embed API, and it is not returning a value 05:30
sorear PerlJam: sort of. That's actually the easiest case, and one STD has supported for ages
snarkyboojum dukeleto: oic - I'm not familiar with the parrot embed api 05:31
05:31 shade__ joined
PerlJam sorear: like I said ... I don't know what it really means :) 05:31
sorear PerlJam: STD generates new languages at runtime - Q:foo, :foo is actually a mixin applied to the quote language
lexer reuse allows us to keep much of the lexer work even when small changes are made to the language
ash__ dukeleto: &r will let you access the sub r as a variable 05:32
rakudo: sub foo { 'foo called' }; my $a = &foo; say $a();
p6eval rakudo c9ee2e: OUTPUT«foo called␤»
pmichaud ooooh
PerlJam sorear: sort of like inheritance in oop-land
pmichaud yes, that sounds somewhat similar to what nqp is doing for its token caches
it's essentially tied to the grammar. although you said Regex.WHICH above... I'd have to think about that one a bit. 05:33
oh, wait, I get it. Nice.
sorear++ sorear++
sorear nqp doesn't really support creating new grammars at run time, though
pmichaud well, not yet. :-) 05:34
dukeleto snarkyboojum: well, it would basically the same as wanting to eval that code and wanting the return value
pmichaud it *does* support creating new grammars at runtime -- it's called "inheritance". As far as the engine is concerned, there's not much difference. :)
but yes, for the types of changes that would be needed for a true P6 STD model, it's a little primitive at the moment. 05:35
(like some of the early versions of STD before the optimizations)
3 tests.
05:36 Mowah joined
PerlJam pmichaud: at this hour that sounds like a countdown to sleep :) 05:36
pmichaud maybe, but not likely.
ash__ rakudo: my $a = eval "-> { return 1 + 2 }"; say $a(); # am i wrong assuming this should return a closure? The eval that is 05:37
05:37 orafu left
p6eval rakudo c9ee2e: ( no output ) 05:37
05:37 orafu joined
pmichaud Within the last six hours I've finally figured out how to clean up most of rakudo's variable handling, so that we get autovivification to work, eliminate the Proxy class, throw out a bunch of obsolete/convoluted code, etc. 05:37
oh, and binding. :-)
PerlJam rakudo: my $a = eval "-> { return 1 + 2 }"; say $a.WHAT;
p6eval rakudo c9ee2e: ( no output )
dukeleto ash__: that sounds similar to my issue
05:38 shade__ left
pmichaud shouldn't be a 'return' in a pointy block. 05:38
so it's generating an exception, which the eval is catching.
PerlJam rakudo: my $a = eval "-> { leave 1 + 2 }"; say $a.WHAT;
pmichaud rakudo: my $a = eval "-> { 1 + 2 }"; say $a();
p6eval rakudo c9ee2e: OUTPUT«Could not find sub &leave␤ in main program body at line 11:/tmp/nmapR6o9wi␤»
rakudo c9ee2e: OUTPUT«invoke() not implemented in class 'Seq'␤ in main program body at line 11:/tmp/SQ3FPBT1KZ␤»
pmichaud rakudo: my $a = eval "-> { 1 + 2 }"; say $a.WHAT; 05:39
p6eval rakudo c9ee2e: OUTPUT«Seq()␤»
pmichaud huh
that's... weird.
rakudo: say (eval "-> { 1+2 }").WHAT
p6eval rakudo c9ee2e: OUTPUT«Parcel()␤»
pmichaud looks like a parcel fail
don't know why eval wants to return a Parcel there. 05:40
05:40 ewilhelm left, ewilhelm joined
PerlJam looks like there's an unwritten test or two there :) 05:40
pmichaud 1 test.
05:40 ewilhelm left
pmichaud ...that I think I'm simply going to mark as "skip" or "todo" :-) 05:40
ash__ rakudo: sub foo { 1 + 3 }; my $a = eval "&foo"; say $a(); # it evals fine in this form, is it something specific to pointy blocks? 05:41
pmichaud okay, let's see what happens if I merge to master.
p6eval rakudo c9ee2e: OUTPUT«4␤»
pmichaud rakudo: my $a = "eval sub { 1 + 3 }"; say $a.WHAT; 05:42
p6eval rakudo c9ee2e: OUTPUT«Str()␤»
pmichaud er
rakudo: my $a = eval "sub { 1 + 3 }"; say $a.WHAT;
p6eval rakudo c9ee2e: OUTPUT«Seq()␤»
ash__ (i tried that)
pmichaud ohhhh!
I know what the problem is.
Evil.
PerlJam need a ; in front?
pmichaud no.
05:42 rhr left
PerlJam was guessing at some weird misparse 05:43
pmichaud In Parrot, whenever you dynamically compile some code using the PIR compiler, you get back something called an Eval PMC
it's basically an array of the subs that were in the PIR source
pugssvn r31309 | sorear++ | [dfa/Cursor] Lexer caches need to be keyed on lexer identity, not lexer name. +0.25% ops
pmichaud oh, hmm, that doesn't quite follow, I guess 05:44
I was going to say that the eval() ends up returning the Eval PMC, which then gets treated as a Parcel containing the compiled sub.
sorear search.cpan.org/~sorear/Devel-CountOps-0.01/
pmichaud but that's not it.
sorear so much for "this doesn't seem to exist"
ash__ dukeleto: with embedded parrot does it execute each statement in an Eval PMC?
pmichaud okay, time to try a merge with master and see what happens.... 05:45
no merge conflicts.
compiling...
05:46 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
pmichaud spectesting... 05:49
dukeleto ash__: 'compile' returns an Eval PMC
pmichaud dukeleto: yes, but Rakudo's eval is supposed to then invoke the Eval PMC and return that result
so something else is happening there. 05:50
rakudo: my $a = eval "sub { 1 + 3 }"; say $a.perl;
p6eval rakudo c9ee2e: OUTPUT«()␤»
pmichaud yeah, it's just ending up with Nil.
rakudo: my $a = eval "(-> { 1 + 3 })"; say $a.perl; 05:51
p6eval rakudo c9ee2e: OUTPUT«()␤»
pmichaud rakudo: my $a = eval "(-> { 1 + 3 })()"; say $a.perl;
p6eval rakudo c9ee2e: OUTPUT«()␤»
pmichaud ohhhh!
duh!
I know what the problem is! I know what the problem is!
sorear Excellent!
pmichaud rakudo: my $a = eval '-> { 1 + 3 }'; say $a(); 05:52
p6eval rakudo c9ee2e: OUTPUT«4␤»
pmichaud WIN
PerlJam ha
interpolation
05:52 yinyin left
ash__ doh 05:52
PerlJam pmichaud++
ash__ well never mind then
05:52 yinyin joined
pmichaud we do need to get it so that eval returns any exception into the result value 05:53
05:53 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
pmichaud that shouldn't be hard... just call the &fail equivalent. 05:53
05:55 shade__ joined
dalek ok: 61514b0 | duff++ | src/r (2 files):
[regex] lexicalize free-standing regex
 05:56
05:56 dalek left 05:57 dalek joined, Mowah left 06:11 yinyin left 06:12 yinyin joined
dukeleto what does "No exception handler and no message" actually mean? 06:14
pmichaud it means an exception was generated and thrown and there was no handler available to catch it. 06:15
ciphertext rakudo: (1,2,3 Z 4,5,6).perl.say 06:16
p6eval rakudo c9ee2e: OUTPUT«(1, 4, 2, 5, 3, 6)␤»
ciphertext rakudo: (1,2,3 Z[,] 4,5,6).perl.say 06:17
p6eval rakudo c9ee2e: OUTPUT«(1, 4, 2, 5, 3, 6)␤»
pmichaud > (1,2,3 Z[,] 4,5,6).perl.say
((1, 4), (2, 5), (3, 6))
(in the new branch)
dukeleto pmichaud: how do I install an exception handler (or where do I read about that?) in Rakudo
pmichaud ...in Rakudo? That would be CATCH { ... } or try { ... } 06:18
dukeleto pmichaud++
pmichaud okay, all tests pass (I think)
so.... prepare for commit flood.
list branch merged to master. 06:19
06:19 [Coke] left
ciphertext pmichaud: that's what i'm getting, but the spec says that Z should be an alias for Z[,] 06:19
"The Z, operator is perhaps more clearly written as Z[,]. However, this list form is common enough to have a shortcut, the ordinary infix Z operator described earlier."
pmichaud sounds like a rakudo bug to me then. 06:20
ciphertext k.
that's what i thought.
(i was just checking whether it was something i had done locally)
dalek kudo: ddb39d0 | (Solomon Foster)++ | t/spectest.data:
Regress range-iterator.t, because it conforms to the now-obsolete former
06:21
kudo: 6b2af44 | moritz++ | src/core/MAIN.pm:
cca4a84 | pmichaud++ | src/Perl6/Compiler.pir:
06:21 dalek left
moritz_ is this the list merge? 06:22
moritz_ just got up
06:22 dalek joined
pmichaud it is. 06:22
moritz_ \o/
snarkyboojum wowsers, that's a serious merge :) 06:24
pmichaud 154 commits.
pugssvn r31310 | pmichaud++ | [t/spec] Fudge some tests for later review as part of Rakudo's list branch merge.
pmichaud only one (very minor) merge conflict. :)
06:25 Su-Shee joined
moritz_ nqp: sub f($x) { 3 }; say(&f) 06:25
p6eval nqp: OUTPUT«Symbol '&f' not predeclared in <anonymous>␤current instr.: 'parrot;PCT;HLLCompiler;panic' pc 152 (compilers/pct/src/PCT/HLLCompiler.pir:109)␤»
pmichaud nqp doesn't automatically prepend subs with &'s 06:26
but you can put them there.
moritz_ which is not Perl 6
pmichaud nqp: sub &f($x) { 3 }; say(&f);
p6eval nqp: OUTPUT«&f␤»
moritz_ can you refer to subs by name withou using &f in the name?
pmichaud nqp doesn't do any automatic adding or removal of &'s
moritz_ I told tcurtis that the 'sub &f' thing was an nqp oddity and not Perl 6, best to be avoided 06:27
pmichaud wfm
it's one of those known deviations because otherwise nqp doesn't provide a clean way to get at parrot subs that don't have the &'s 06:28
or to produce parrot subs that don't have &'s
06:28 synth left
pmichaud and other HLLs might really want to do that. 06:28
well, if others can run spectests and double-check my results, that'd be great. 06:30
I'll start updating spectest-progress now.
moritz_ I'm spectesting now on list pre-merge 06:31
Tene I'm spectesting right now. I spectested master earlier today.
pmichaud okay, I fixed rotate.t post-merge.
moritz_ Your branch is behind 'origin/master' by 155 commits, and can be fast-forwarded.
epic.
pmichaud it was a huge amount of work, yes.
I'm sooooo glad we had git and not svn. 06:32
and I have a bunch more improvements I can add shortly now to fix a whole slew of long-standing bugs (some of which are on the ROADMAP), but I'll wait until after release to try to bring those in.
after I get a little sleep, my plan is bug stomping, ticket wrangling, and blog posting. 06:33
moritz_ pmichaud: you accidentally merged the commenting out of some spectests
pmichaud oh
moritz_ pmichaud: S03-metaops/{reduce,zip}.t
pmichaud I didn't realize they had been commented out.
Tene I'm up into S11
moritz_ S03-operators/series*.t
Tene Yeah, we definitely need to include *some* bugs in the release.
moritz_ that were the tests that used .batch
pmichaud I suspect many of them will "just pass" 06:34
I'll try them quickly.
sorear don't we have an automatic defuzzer script? 06:36
szabgab some spec-test are failing for me
anything I can do ?
t/spec/S03-operators/assign.rakudo ............................. Failed 1/240 subtests
t/spec/S03-operators/range-basic.rakudo ........................ Dubious, test returned 1 (wstat 256, 0x100)
pmichaud szabgab: you might need to svn up t/spec
szabgab I just did it 06:37
about 1 min ago
pmichaud okay, looking
szabgab to 31310
pmichaud oh, I need to put error reporting back in. 06:39
pushed. 06:40
Tene pmichaud: gist.github.com/441765 06:42
pmichaud Tene++ # thanks 06:43
Tene updated with pre-merge spectest output
pmichaud likes seeing all of those passing TODOs
there are also a bunch of passing skips that we can start looking for as well :)
06:44 Zapelius joined
Tene are you working on removing the TODO markers, or should I do that? 06:44
pmichaud I'm not doing that now, no.
pmichaud (so yes, please feel free)
right now I'm mainly taking deep breaths and saying "wow, that was a lot." 06:46
@x = 2, 3, 4; 06:50
is @x.pop, 4, 'can pop from typed array';
is @x.unshift(2), [2, 2, 3], 'can unshift from typed array';
...doesn't that last test look wrong?
oh, I guess not
missed the .pop 06:51
anyway, I'm getting a bit sleepy here so I'll take a short break. Feel free to clean up spectests as appropriate. 06:56
pugssvn r31311 | tene++ | Remove a few rakudo skip and todo markers
pmichaud bbiaw 06:58
06:58 yinyin left
sorear has gotten general reuse to work, but something is slowing it down an unexpected amount and it's not being a net win 06:58
pugssvn r31312 | tene++ | remove a rakudo todo marker 06:59
06:59 yinyin joined
moritz_ pmichaud: t/spec/S03-metaops/reduce.t fails one test 07:01
I'll just put it in anyway; it's a regression
maybe I'll investigate later
pmichaud yes... given the number of other things this branch fixes, I'm not too worried about a small number of regressions :) 07:02
sorear are we passed alpha yety? 07:03
moritz_ in what terms? 07:04
sorear #tests passing 07:06
moritz_ yes, for a few weeks 07:07
t/spec/S09-typed-arrays/arrays.rakudo fails here 07:09
dalek kudo: a5f844b | moritz++ | t/spectest.data:
enable quite a few passing test files (some of them were regressions of the list
07:09 cono left
moritz_ get_pmc_keyed() not implemented in class '' 07:09
after test 7
afk
07:13 xabbu42 left, xabbu42_ joined
pugssvn r31313 | tene++ | Remove more rakudo skip and todo markers 07:14
07:14 cono joined
Tene Yeah, I know, I don't need to commit this often. :P 07:17
pugssvn r31314 | tene++ | Remove another rakudo todo marker
07:17 yinyin left
mathw Morning 07:26
07:26 plobsing left
pugssvn r31315 | tene++ | Remove more rakudo todo markers 07:28
07:29 kensanata joined
snarkyboojum rakudo: <a>.rotate 07:31
p6eval rakudo e3eb60: OUTPUT«Method 'rotate' not found for invocant of class 'Str'␤current instr.: '_block14' pc 148 (EVAL_1:66) (/tmp/lJbMXDQajh:11)␤»
snarkyboojum rakudo: <a b>.rotate
p6eval rakudo e3eb60: OUTPUT«Method 'rotate' not found for invocant of class 'Parcel'␤current instr.: '_block14' pc 154 (EVAL_1:65) (/tmp/1CUBFnQhg9:11)␤»
pmichaud needs to be added to Cool, probably.
see the pattern used for .join and .sort 07:32
snarkyboojum Cool :)
pugssvn r31316 | tene++ | Remove two more rakudo todo markers 07:35
pmichaud or Any-list.pm, come ot think of it. 07:40
snarkyboojum adding it to Parcel.pm like this works too gist.github.com/441809 07:41
pugssvn r31317 | tene++ | Remove more rakudo todo markers 07:42
pmichaud putting it in Parcel is too far down the chain. 07:43
07:43 xabbu42_ left, xabbu42 joined
pmichaud since Parcel is ~~ Any, it would go better there. 07:43
snarkyboojum it's in List.pm too isn't it
pmichaud List.pm is where it's actually implemented
Any should forward to list
snarkyboojum ah ok :)
07:44 pronik``` joined 07:48 dual left 07:50 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42, shade__ left 07:53 shade__ joined, dual joined
pugssvn r31318 | tene++ | Remove more rakudo todo markers 07:55
r31319 | tene++ | Remove todo markers for "fails intermittently" added two months ago. I could not reproduce, but if it still fails intermittently, we can re-fudge. 07:56
r31320 | sorear++ | [dfa/Cursor] Implement lexer reuse. Something is not quite right; it's definitely reusing lexers but the performance increase is underwhelming 07:57
r31321 | tene++ | Remove another rakudo todo marker 07:58
szabgab how can I run a specific spectest in verbose mode so I'll see the details of the failure? 07:59
pmichaud make t/spec/S02-whatever/test.t
(with apologies to TimToady++) 08:00
szabgab so not the .rakudo ? 08:01
pmichaud .t
phenny Thu, 17 Jun 2010 08:01:30 GMT
moritz_ pmichaud: do you also get a failure in t/spec/S09-typed-arrays/arrays.rakudo? 08:03
pmichaud Yes.
szabgab I got weird test failurse after I added a call to die() in the need method of src/Perl6/Module/Loader.pm , well just playing to see if I make an impact at all with my changes, now let's try with a real change...
08:04 [Coke] joined 08:06 pnate left, pnate joined
pmichaud moritz_: I think I have an idea on the typed-arrays error, but will have to wait until morning to fix it. 08:08
Tene spectesting again, will post shortly.
pmichaud it has to do with how arrays are initialized
moritz_ pmichaud: should we wait with the rakudo release so long?
erm, s/we/masak/
pmichaud masak said he was going to release around 2000 utc 08:09
moritz_ ok
pmichaud so I think I'll have it in place before the release w/o any difficulty
moritz_ great
pmichaud are typed arrays going to generally be a blocker?
I mean, although I think they've not caused problems, we haven't had actual type checking since alpha
(but I know how to fix that now, will do that shortly after release... :-) 08:10
anyway, I need sleep. bbiaw
moritz_ sleep well 08:11
snarkyboojum is that a more appropriate way to fix rotate for parcels then gist.github.com/441829?
pmichaud I'd add "multi"
other than that, looks great.
I'd probably also use "is export" instead of the separate proto 08:12
unless there's a big reason for the proto
(really gone now)
moritz_ named arguments
snarkyboojum I just did it to follow suit with other methods, but would have used the is export.. will give that a whirl ;)
moritz_ rotate :array[1, 2, 3] only works with a proto 08:13
08:13 ajs left
snarkyboojum moritz_: ok that works with that current change 08:14
pugssvn r31322 | sorear++ | [dfa/Cursor] Combine two separate (and separately cached) protoregex scanner loops. -0.8% ops 08:15
snarkyboojum moritz_: potential patch then? gist.github.com/441834 (if keeping proto is appropriate)
Tene gist.github.com/441765 -- updated spectest results
if anyone else wants to pick up un-fudging 08:16
08:16 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
Tene afk, sleep. 08:16
08:16 masak joined
moritz_ snarkyboojum: thanks, pushed 08:18
masak o/, #perl6
phenny masak: 16 Jun 21:17Z <pmichaud> tell masak it's official, tomorrow's release is "Kiev"
dalek kudo: 012ea2b | snarkyboojum++ | src/core/Any-list.pm:
Get rotate working for Parcel again
masak \Kiev/
08:19 pronik``` left
mathw o/ masak 08:19
snarkyboojum moritz_: thanks! 08:20
moritz_ snarkyboojum: thank you for yoru patch 08:22
sorear tryfile STD.pm6 in 2:26 08:26
1-1.5 minutes faster than trunk
08:26 thebird joined
moritz_ \o/ 08:27
pugssvn r31323 | sorear++ | [dfa/Cursor] Gut the old RE-based LTM entirely
r31324 | moritz++ | [t/spec] unfudges for rakudo 08:28
masak most likely not R* priority, but eventually I would like Rakudo (and the spec) to address all the points in this post: blog.ksplice.com/2010/05/top-10-per...er-tricks/ 08:31
pugssvn r31325 | moritz++ | [t/spec] another small rakudo unfudge 08:32
08:33 cono left, cono joined 08:35 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42 08:37 JimmyZ joined
JimmyZ Test Summary Report on Windows XP. gist.github.com/441854 08:37
sorear masak: 4,7,8,9 are core Perl 6 features and have better syntax 08:38
10 is a SMOP
the rest are vaguely thought of under the concept of "settings
"
masak thing is, they need to be relatively easy.
moritz_ #1 too
autochomping is default
masak that's the beauty of -n and -p. they're right there.
sorear 4,7,8,9 are relatively easy 08:39
no harder than perl5
#10 will be much easier with named regex syntax
masak I still don't really know how one'd write `perl -ne 'print if /start/../stop/'` in Perl 6.
jnthn good morning, #perl6
masak jnthn: morning!
sorear perl6 -ne '.say if /start/ ff /stop/'
moritz_ sorear: close. perl6 -n -e 08:40
masak moritz_: what, why?
moritz_ only boolean single-letter args may be clustered
according to current spec
sorear you're upending thirty years of tradition...why?
masak exactly.
08:40 dakkar joined
moritz_ not me 08:41
masak I think that rule should be loosened up.
moritz_ [particle]'s decision, iirc
masak boolean single-letter flags can have other single letter flags following them, or something like that.
that would allow -ne and -lne and similar.
moritz_ would work for me
jnthn list branch merged!! :-D 08:42
pmichaud++
moritz_ aye
there's some fallout though
jnthn And (all others who worked on it)++
moritz_: How much?
masak pmichaud++
moritz_ jnthn: gist.github.com/441854
colomon yow 08:43
jnthn moritz_: Is that from Win32?
moritz_ jnthn: yes ( JimmyZ nopasted it earlier)
pmichaud yeah, I'm not quite sure what happened there. all of the spectests were passing on my box. 08:44
jnthn They failed in master on Win32 before anyway :-(
sorear parrot version stuff? 08:45
moritz_ callframe.t also failes here
pmichaud oh
jnthn Something is not quite right with the cases where we shell out
And run another Rakudo proccess
I thnk
*think
pmichaud then that would be why... I was just trying to match whatever tests master was running.
jnthn pmichaud: Yeah
pmichaud: I keep meaning to look at that.
pmichaud I suspect a linux person re-enabled some tests that otherwise fail on win32
jnthn We also segfault on Win32 on t\spec\S05-capture\subrule.rakudo
pmichaud: It's fine, though a bit noisy for me, but it'll eventually irk me enough to track it down. :-) 08:46
On caught the segfault in the debugger but it was actually a (C-level) stack overflow in the GC.
pmichaud well, I'm fine with the group adjusting the spectests however it's decided best
jnthn I'd suggest not adjusting them for Win32-specific issues. 08:47
It's just some platform lag.
I caught a little of it a while back when I fixed chomp, but there's a tad more to go.
(I think one underlying issue is to blame for most of them.) 08:48
pmichaud okay. I just think we may get a lot of faq from win32 people who say "the tests don't pass"
in that sense I'd rather todo them than leave them failing, I think.
pugssvn r31326 | sorear++ | [STD-ecosystem] Merge back dfa branch of Cursor, rebootstrap, and remove all references to lex from the makefile. 08:49
jnthn pmichaud: Heh, then we'll get a lot of "there's TODO passes" ;-)
pmichaud sure, but we can put a note that says "fails on Win32"
jnthn pmichaud: srsly though, I'll try and give it some tuits at the weekend.
08:49 Superjane left
pmichaud wfm 08:49
jnthn is mini-hackathoning with mberends++ this weekend.
sorear speaking of tuits, STD is now 25% faster 08:50
jnthn Today though, I really need to give $dayjob some attention.
sorear: Nice!
sorear from the LTM rewrite
and I've killed the on-disk lexer cache with fire; lexer generation is now sufficiently lazy that short files aren't killed by a cold start
pmichaud btw, in my local repo: 08:51
> my Int @a = 1, 2, 3, 'x', 7
Unable to store value of type Str in list of Int
moritz_ \o/
sorear the only thing that STD writes to disk now is precompiled modules
pmichaud jnthn: while working on the list branch tonight I totally figured out how to fix assignment, scalars, proxys, vivification, and binding 08:52
(but it's too big a refactor to try to fit in before the release, so I'm doing it afterwards) 08:54
moritz_ hopes it's not gone after sleep :-)
pmichaud moritz_: I wrote it down :)
(actually I was writing to address a different problem, and then said "oh! Cool!")
jnthn pmichaud: Nice!
masak pmichaud: why 'list of Int' when it's an Array?
pmichaud: what would it say if it were a Hash? 08:55
pmichaud masak: I don't yet know how to get the invocant's type name
masak ok.
moritz_ self.WHAT.perl ?
masak :)
jnthn Aye, that.
moritz_ (might be naiive though)
pmichaud well, I was hoping for the names without the parens
jnthn Possibly, yes.
pmichaud so I was trying .WHO
jnthn .perl strips 'em.
pmichaud oh, .perl
yes
okay
jnthn rakudo: say 42.WHAT; say 42.WHAT.perl; 08:56
p6eval rakudo 012ea2: OUTPUT«Int()␤Int␤»
pmichaud jnthn: In the process, the fix I have also means that with my Int @a; all of the elements of @a will start out as the Int type object :)
jnthn pmichaud: That's nice. 08:57
moritz_ sounds like a ponie :-)
pmichaud so: my @a; say @a[5].WHAT; # Int()
dalek meta: r334 | anteus4++ | trunk/doc/PerlesqueDocumentation.html:
added more class related syntax and callable type
jnthn \o/
sorear Who is anteus4? 09:00
pmichaud maybe us3? </obscure> 09:01
moritz_ jaffa4?
dalek meta: r335 | anteus4++ | trunk/doc/PerlesqueDocumentation.html:
changed subroutine syntax
 09:02
pmichaud > my Int @a = 1, 2, 'x', 4;
Unable to store value of type Str in of Int
(sigh)
yeah, can't get the type name of self 09:03
jnthn Oh
moritz_ is that in a role?
oh wait
jnthn Yeah, because of the way we currently set up typed arrays. :/
pmichaud anyway, easy to fix up a bit later :) 09:04
jnthn *nod*
pmichaud okay, let's see if _now_ I can get to sleep
bbiaw
szabgab pmichaud, you were supposed to go to sleep:)
a long time ago
pmichaud szabgab: yes, but I keep thinking of cool things to try in the new implementation :)
szabgab go now 09:05
jnthn Sleep is overrated. :)
szabgab and underrsupplied :)
masak and strangely distributed :/ 09:08
szabgab rakudo: say <sleep hack eat code debug commit patch>.pick 09:10
p6eval rakudo 012ea2: OUTPUT«sleep␤»
masak \o/
hejki rakudo: say <work work work work work work>.pick
p6eval rakudo 012ea2: OUTPUT«work␤»
hejki aww.. :<
masak hejki: what did you expect? :P
hejki masak: some savory side-effect to save me from working? :P 09:11
sorear std: 2
p6eval std 31325: OUTPUT«ok 00:01 107m␤»
moritz_ rakudo: say <hack work work work work>.pick 09:12
p6eval rakudo 012ea2: OUTPUT«hack␤»
moritz_ \o/
moritz_ goes to fix callframe.t
masak suspects Rakudo is rigged out of self-preservation :P 09:13
hejki moritz_: :)) 09:14
masak jnthn: can you put several parameters in the siggy in the [] of a role declaration? 09:15
moritz_ sure
you can even do multi dispatch on them
szabgab so in src/Perl6/Module/Loader.pm I am trying to make some small fix 09:16
masak what does .of return in such a case?
jnthn masak: It's a full Perl 6 signature in that case
szabgab I am trying to use open() but rakudo cannot find it
jnthn masak: .of is just a method in Positional and Associative.
szabgab I guess it is not exported yet or sg similar
jnthn masak: It's not "automatic" in any sense.
masak jnthn: oh, ok.
that's fine, then.
szabgab how can I use it then?
moritz_ rakudo: role A[$x, $y] { method x { say $x + $y } }; A[4, 5].new.x
p6eval rakudo 012ea2: OUTPUT«No applicable candidates found to dispatch to for '_block52'. Available candidates are:␤:(Mu $x, Mu $y)␤␤ in main program body at line 1␤»
szabgab IO.open() ? 09:17
jnthn ...wtf?
moritz_ szabgab: the module loader is written in nqp, not Perl 6
masak submits rakudobug
moritz_ szabgab: so you need to resort to parrot tools
szabgab moritz_, so does it mean I cannot use code from core yet ?
moritz_ right
szabgab so I cannot do my planned refactoring then :( 09:18
09:18 yinyin joined, kensanata left
jnthn szabgab: Ah, you wanted to change the use of pir::open in the module loader? 09:18
szabgab yes 09:19
jnthn I'd maybe rather that wasn't done, even were it possible.
09:19 mberends joined
jnthn Otherwise we can't "use" when compiling the setting. 09:19
Which we may at some point want to do.
szabgab ok, so something else then
how can I find the implementation of things that are written pir::name__XYZ ? 09:20
for example the pir::open__PSS
masak rakudo: role A[$x, $y] { method x { say $x + $y } }; A[4, 5].new 09:22
p6eval rakudo 012ea2: OUTPUT«No applicable candidates found to dispatch to for '_block52'. Available candidates are:␤:(Mu $x, Mu $y)␤␤ in main program body at line 1␤»
dalek kudo: d1a7442 | moritz++ | src/core/CallFrame.pm:
fix callframe().line and .file by creating a Perl 6 hash from the annotations
kudo: cb0e95e | moritz++ | src/core/CallFrame.pm:
simplify CallFrame.pm, and make a parameter optional
jnthn masak: I wonder if it's passing the role args as just one Parcel. 09:26
Rather than properly sending them in as multiple args.
masak that might be it.
moritz_ szabgab: you have to go through the parrot docs 09:30
szabgab where is my yak ? :) 09:31
moritz_ szabgab: pir::open__PSS means it's an opcode that returns a P(MC) and receives two S(trings)
mberends yay! today I'm going to Sweden to visit a world famous pivo connoisseur! 09:32
szabgab so theoretically I could just write pir:opendir__PS ? 09:33
moritz_ right
jnthn mberends: going, but arriving tomorrow, no? :-) 09:35
mberends yes, overnight coach trip :)
jnthn Phew, the pivo connoisseur wasn't drunk when you told him the dates after all. :-)
masak jnthn, mberends: what will you two be hacking on this weekend?
jnthn pivo! 09:36
oh, hacking, not drinking...
masak :)
dlm hi martin
jnthn That...other thing I do... :-)
09:36 dlm is now known as dolmen
mberends the hacking will have to be sekrit, in case is fails ;-) 09:36
hi dolmen!
09:37 dolmen is now known as Guest58318
jnthn masak: I'm not sure. Last time mberends showed up at my place, we spontaneously wrote Zavolaj. But then we had to leave the country. 09:37
Guest58318 was in Calais
09:37 Guest58318 is now known as dolmen_, dolmen_ is now known as dolmen__
mberends bounce, bounce 09:37
masak jnthn: any causation between spontaneously writing Zavolaj and having to leave the country? :P 09:38
09:38 dolmen__ left
mberends masak: the 'is native' trait may have caused a problem, since we were both foreigners 09:38
masak *lol* 09:39
jnthn :D
09:40 dlm joined, xabbu42 left, xabbu42 joined
szabgab I guess if I attempt to implement opendir it should be in some module called IO::Dir and not in IO.pm , right ? 09:40
dlm doesn't remembers its freenode account :(
moritz_ szabgab: does the spec say anything about it? 09:43
szabgab I don't think so 09:44
masak each time I read the file IO parts of the spec, I do so with some amounts of disbelief and suspicion.
szabgab S29 mentiones opendir once
moritz_ it would be very cool to have a function that lazily returns all directory entries in a lazy list
there's basically no need for opendir/readdir/closedir if you have that 09:45
szabgab for now I'd be happy with any first implementation of it
masak I wouldn't be sad if we just scrapped that (overdesigned and overly complex) part of the spec and did exactly what Perl 5 is doing.
jnthn Maybe we can gather some hackers to take that on.
szabgab moritz_, I'd guess that would be a utility function
moritz_ do we have an API to generate a list from an iterator?
szabgab I found IO::Directory in S32/IO 09:47
but does not have much of a spec as I can see
mathw As far as I see it, IO's still in a horrendous state in spec terms 09:50
Nobody ever seems to agree on how to do it
ciphertext rakudo: my @a = gather { take [1,2],3}; @a.perl.say; 09:51
p6eval rakudo 012ea2: OUTPUT«[[1, 2], 3]␤»
masak it has only been touched by people who like abstractions so far, not people who know file IO.
09:51 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
moritz_ rakudo: say WHAT gather { take 1 } 09:51
p6eval rakudo 012ea2: OUTPUT«List()␤»
masak (with due apologies to people who have edited that piece of the spec, and actually know file IO -- it's just that that's not what it looks like)
ciphertext rakudo: say gather {my $x = 0; take $x++; take $x}; 09:52
p6eval rakudo 012ea2: OUTPUT«01␤»
09:54 dlm left
ciphertext rakudo: my f($x is copy) { say gather { take $x++; take $x }}; f(5); 09:58
p6eval rakudo 012ea2: OUTPUT«===SORRY!===␤Malformed my at line 11, near "f($x is co"␤»
ciphertext rakudo: my sub f($x is copy) { say gather { take $x++; take $x }}; f(5);
p6eval rakudo 012ea2: OUTPUT«56␤»
10:01 aesop_ joined 10:02 aesop left 10:03 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
ciphertext rakudo: say gather { my $x = 10; take $x while --$x >= 0; }; 10:05
p6eval rakudo 012ea2: OUTPUT«-1-1-1-1-1-1-1-1-1-1␤»
ciphertext aha! i knew it was still broken.
moritz_ to reproduce, you have to always take() the same variable
if you take $x++, the $x++ returns a value that's not the same variable as $x 10:06
10:08 yinyin left
ciphertext right. i submitted a patch yesterday (rt.perl.org/rt3/Ticket/Display.html?id=75810), but now that the list branch isn't riddled with errors, i can see that my patch broke something... 10:08
moritz_ there's an easy enough fix... 10:09
clone the arguments to take()
I'm just not sure if it's the right fix
ciphertext that's what i did in the patch...
moritz_ why does it change so much unrelated code? 10:11
ciphertext what do you mean? 10:12
10:12 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
moritz_ I'd expect the patch only to change .sub 'take' 10:12
if it makes other things simpler, putting those changes into a second patch makes review much easier 10:13
ciphertext i'll keep that in mind 10:14
oh yeah, i think i submitted the multiple fixes as one patch because my patch to &infix:<...> didn't work without the patch to take 10:15
> my @a = gather { take [1,2],3}; @a.perl.say;
[1, 2, 3]
moritz_ ouch 10:16
hejki i still so hate gather not being lazy :<
moritz_ hejki: but, it is
hejki oh
10:16 xabbu42 left
hejki for isn't then 10:16
:>
moritz_ right
10:16 xabbu42 joined
moritz_ .map is 10:16
hejki rakudo: my @ar = gather { for ^Inf -> $i { take $i if $i % 2 == 0 } }; @ar[4].say
10:16 lestrrat is now known as lest_away
hejki i want this :> 10:16
p6eval rakudo 012ea2: ( no output ) 10:17
moritz_ rakudo: my @ar = gather { while 1 { take $i++ if $i % 2} }; say @ar[4] 10:18
p6eval rakudo 012ea2: OUTPUT«===SORRY!===␤Symbol '$i' not predeclared in <anonymous> (/tmp/IbZIN6GFFs:11)␤»
moritz_ rakudo: my @ar = gather { while 1 { my $i = -1; take $i++ if $i % 2} }; say @ar[4]
p6eval rakudo 012ea2: ( no output )
hejki rakudo: my @ar = gather { while ++$i { take $i if $i % 2 == 0 } }; @ar[4].say
p6eval rakudo 012ea2: OUTPUT«===SORRY!===␤Symbol '$i' not predeclared in <anonymous> (/tmp/z4MiQEMiNM:11)␤»
hejki rakudo: my @ar = gather { my $i = 0; while ++$i { take $i if $i % 2 == 0 } }; @ar[4].say
p6eval rakudo 012ea2: ( no output ) 10:19
moritz_ rakudo: say (gather { my $i = 0; while ++$i { take $i if $i % 2 == 0 } }.[4]
p6eval rakudo 012ea2: OUTPUT«===SORRY!===␤Unable to parse postcircumfix:sym<( )>, couldn't find final ')' at line 11␤»
moritz_ rakudo: say (gather { my $i = 0; while ++$i { take $i if $i % 2 == 0 } ).[4]
p6eval rakudo 012ea2: OUTPUT«===SORRY!===␤Unable to parse blockoid, couldn't find final '}' at line 11␤»
moritz_ rakudo: say (gather { my $i = 0; while ++$i { take $i if $i % 2 == 0 } }).[4] 10:20
sorear std: 2
p6eval rakudo 012ea2: OUTPUT«10␤»
std 31325: OUTPUT«ok 00:01 104m␤»
moritz_ hejki: it seems that array assignment isn't lazy yet :(
hejki ye
sorear moritz_: array assignment isn't lazy as specced. Note that it returns the list, which is then put into void context... 10:21
ciphertext rakudo: say ((^Inf).map: {$_ if $_ % 2 == 0})[4]
p6eval rakudo 012ea2: OUTPUT«4␤»
moritz_ sorear: rakudo doesn't detect void/sink context yet
sorear oh.
ciphertext wait... that's not right... 10:22
nvm
moritz_ ciphertext: I guess it always puts one (possibly empty) Capture into the list
rakudo: say ((^Inf).map: {$_ if $_ % 2 == 0}).flat.[4]
p6eval rakudo 012ea2: OUTPUT«8␤» 10:23
moritz_ better? :-)
hejki much better :>
now i just need to make one giving me lazy primes :>
and then i can start rejoiceing projecteuler with perl6 :>
10:30 JimmyZ left
masak rakudo: say (gather loop (my $i = 2;;++$i) { take $i + 0 if $i % all 2..$i/2 }).[^10].perl 10:38
p6eval rakudo 012ea2: OUTPUT«(2, 3, 5, 7, 11, 13, 17, 19, 23, 29)␤»
masak man, that's cool.
jnthn perl6++ 10:39
masak pmichaud++
jnthn rakudo: say (gather for 1..* -> $i { take $i + 0 if $i % all 2..$i/2 }).[^10].perl 10:40
p6eval rakudo 012ea2: ( no output )
jnthn Aw.
ciphertext jnthn: for isn't lazy yet
jnthn I thought gather/take being continuation-y would win over that, though. 10:41
10:41 dakkar left
masak jnthn: no, because the loop never starts. 10:41
rakudo: say (gather loop (my$i=2;;++$i){take +$i if$i%all 2..$i/2}).[^10].perl # curious manifestation of the 'take' bug
p6eval rakudo 012ea2: OUTPUT«(29, 3, 5, 7, 11, 13, 17, 19, 23, 29)␤»
ciphertext > say (gather loop (my$i=2;;++$i){take +$i if$i%all 2..$i/2}).[^10].perl 10:44
(2, 3, 5, 7, 11, 13, 17, 19, 23, 29)
10:44 dakkar joined
ciphertext unfortunately, the fix breaks "take [0,1]" type statements for some reason... 10:44
masak ciphertext: you just happened to have a fix to that? cool! 10:45
10:46 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
ciphertext see rt.perl.org/rt3/Ticket/Display.html?id=75810 (note that it is also a patch for &infix:<...> ) 10:46
10:47 Mowah joined
masak sounds like something we'd want to apply. 10:48
10:48 sjohnson joined
masak any particular reason it's one patch instead of one-per-fix? 10:49
10:49 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
masak the one applying them might want to review them separately. 10:49
10:52 dakkar left, dakkar joined
ciphertext the patch for &infix:<...> doesn't work without the patch for take :/ 10:53
10:54 LylePerl joined, xabbu42_ joined
masak oh, ok. 10:54
10:54 xabbu42 left, xabbu42_ is now known as xabbu42
masak I just did a spectest, so I might as well apply those patches and make another one. :) 10:55
10:56 ggoebel joined
ciphertext well, keep in mind, the take patch broke something else (i'm currently trying to figure out how) 10:56
sorear hmm down to 88.84%
significant regression :/
10:56 xabbu42 left, xabbu42 joined
masak ciphertext: in that case, I'll leave it to pmichaud to decide what to do. 10:56
LylePerl Hello 10:57
sorear Hello
10:57 am0c joined
LylePerl It's been a long time 10:58
10:58 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42 11:01 sdvsdvsdv left, arthur-_ joined
LylePerl We (Bristol & Bath Perl Mongers) had a trial run of our Perl 6 discovery workshop last tues 11:01
mberends LylePerl: how did it go? 11:03
masak LylePerl: nice. what were the conclusions from the trial run?
11:04 quester_ joined
quester_ . 11:04
LylePerl Not quite as smoothly as I'd hoped :/ I'm glad we delayed the big one which we plan to promote nationally to all the UK groups
masak I have three failing test files: t/spec/S06-advanced_subroutine_features/callframe.rakudo t/spec/S09-typed-arrays/arrays.rakudo t/spec/S12-methods/submethods.rakudo -- and still lots of TODO passes in other files. 11:05
LylePerl: we'll be happy to help smooth out rough spots if we can.
LylePerl Thanks Masak, I've got some questions and thoughts based on our experiments 11:06
masak excellent.
11:07 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42, tadzik joined
LylePerl The format of the workshop is that people are divided into groups, then given an area of Perl 6 to investigate, 2hrs later all group present their findings to each other (with code examples) 11:07
masak interesting idea. must try that sometime. 11:08
LylePerl From the experience, Picking things at random from the synopsis didn't work as some chunks are mostly un-implemented 11:09
mberends LylePerl: could you write up a summary of the areas chosen and the findings?
LylePerl Such as Data Structures, I looked at these and found much un-implemented
mberends: Good idea, I'll start a discussion on the groups list and do a blog post 11:10
11:10 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
mberends LylePerl++ 11:10
LylePerl So I think for the big one we need more specific areas for the groups to work on, the interesting bits where much is implemented 11:11
The overall aim is to inspire people to play with Rakudo more, we really don't want them to be put off in any way 11:12
mberends yes, so a priority is to identify and work around blockers 11:13
11:13 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
LylePerl Is there a kind of list kept of what's implemented and what's not? 11:14
sorear t/spec/spectest.data
within the spectests themselves, individual tests are also annotated by who passes them
snarkyboojum seems that Rakudo Star might be a good opportunity to update "Things that work in Rakudo" on rakudo.org/status 11:15
LylePerl excellent, now I know where to start, prob should have thought of that
jnthn Note, t/spectest.data
11:16 kensanata joined
LylePerl Another idea came forward for which order things are being implemented 11:17
snarkyboojum or will there be another list of "things that work in Rakudo Star"?
LylePerl That possibly the interesting and often complicated things are being implemented first because they are more challenging and fun to do 11:18
which is potentially leaving some comparatively easy to implement features 11:19
11:19 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42 11:20 mjk joined
LylePerl which would be ideal for people new to rakudo and wanting to help with implementation 11:20
So an idea of what isn't implemented, ranked by complexity would be useful for people like myself 11:22
ciphertext rakudo: my $x = gather { take 0,[1,2]; }; say $x.perl; say $x.flat.perl; 11:24
p6eval rakudo cb0e95: OUTPUT«((0, [1, 2]))␤(0, [1, 2])␤»
moritz_ LylePerl: if you want to fix (relatively straight-forward) things in the existing implementation, I have an idea for you
11:24 synth joined
ciphertext rakudo: my $x = gather { take 0,[1,2]; }; say $x.WHAT; say $x.flat.WHAT; 11:25
p6eval rakudo cb0e95: OUTPUT«List()␤List()␤»
moritz_ get t/spec/S03-operators/series-arity0.t to pass again on rakudo
it's in src/core/operators.pm starting at line 311 11:26
it's only Perl 6 code, no PIR or other magic involved
LylePerl (just for a little background, I disappeared last year because of a new job and starting a part time MSc. I've now passed the first year of the MSc with Distinction, got my results yesterday so I'm pretty chuffed :) It's proved to myself at least that I am capable of learning at a pretty high level. Uni doesn't start again until september, so I want to devote some time again to Perl 6 at least until then) 11:27
ciphertext rakudo: my $x = gather { take 0,[1,2]; }; say $x[0].WHAT;
p6eval rakudo cb0e95: OUTPUT«Parcel()␤»
moritz_ LylePerl: congratulations
LylePerl moritz_: thanks. At this point I probably know more PIR than Perl 6 from my experiences last year. Which is pretty embarrasing. Sounds like a good reason to learn more Perl 6 :) 11:30
masak LylePerl: yay! there's been a modest module explosion in the past year. you might get inspired by reading through some source code: proto.perl6.org/ 11:33
11:34 _buno_ joined, _buno_ left 11:35 _buno_ joined 11:38 jjore left
ciphertext moritz_: i have a patch for &infix:<...>. (Unfortunately, it's dependent on a patch to fix the 'take while' bug, which is causing other problems) 11:38
moritz_ which other problems is it causing?
pugssvn r31327 | sorear++ | [viv] Pregenerate protoregex data & declaration class fields. -0.6% ops, prerequisite for killing \d\d\d
11:39 jjore_ joined
sorear std: 2 11:39
p6eval std 31325: OUTPUT«ok 00:01 104m␤»
LylePerl masak: I saw this pop up on the mailing list, good stuff :)
moritz_ ciphertext: also it's pretty easy to work around the take-bug
ciphertext: take my $tmp = $value;
ciphertext moritz_: masak and i were talking about this earlier.
moritz_ then I should backlog 11:40
masak aye.
LylePerl: I think this is a good time to jump on the Perl 6 train. R* will probably generate a lot of activity, and much focus will go to explain things to beginners.
moritz_ ciphertext: is infix:<scmp> spec? 11:42
if not, it should not be user-visible
ciphertext no, not spec. Is there a way to make it not user-visible, but still visible to all the multi's of &infix:<...>? 11:45
11:45 xabbu42 left, xabbu42 joined
moritz_ you could try to put them into a common block 11:46
{ my multi sub scmp($a, $b) { ... }; all infix:<...> subs here, as 'our multi' }
11:47 JimmyZ joined
ciphertext ok. i'll do that, then. 11:47
11:47 pnu left
moritz_ (doesn't need to be an operator, sub form works too 11:47
snarkyboojum I think its a good idea 11:48
masak neat trick.
11:48 _buno_ left 11:49 pnu joined
moritz_ lexical scoping ftw! 11:50
masak aye... will have to remember that for my upcoming scoping tutorial.
11:51 xabbu42 left, xabbu42_ joined, xabbu42_ is now known as xabbu42 11:55 envi^home joined 11:57 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42, arthur-_ left
moritz_ autounfudge seems to find quite a few passing tests 12:00
sorear: FYI, there were about 5 newly passing test files after the 'list' merge 12:01
masak moritz_: both Tene and I have found lots of TODO passes in the backlog. what's the rule for knowing when such tests can be unfudged? 12:02
moritz_ masak: normally all of them can... except for those notrious intermittent passing TODOs in uc.rakudo and some of the role composition tests
I removed a few todo markers after Tene++'s nopaste 12:03
need to do a fresh spectest to look what's left
masak moritz_++
12:03 xabbu42 left, xabbu42 joined
moritz_ but first I need to finish the autounfudge run 12:05
takadonet morning all 12:09
masak \o
12:09 xabbu42 left, xabbu42 joined
masak any volunteers for ChangeLog updates? the release guide has good tips on how to go about it. I'll do it later today if no-one else has done it, but I'll also happily accept contributions. :) 12:10
moritz_ I've tried to keep it up-to-date while adding features, but I appear to be the only one
masak in the kingdom of the blind, the one-eyed is overburdened with responsibility :P 12:11
moritz_ aye :-)
masak someone writing something about Rakudo * in Japanese. twitter.com/ryochin/status/16383155941 -- something about being put off, about June, and about already existing. 12:12
moritz_ can somebody please run callframe.t on an up-to-date rakudo and tell me if it passes? 12:13
12:14 skids joined
moritz_ rakudo: say (5 but 'foo').Str 12:16
p6eval rakudo cb0e95: OUTPUT«foo␤»
masak rakudo: say ~(5 but 'foo')
p6eval rakudo cb0e95: OUTPUT«5␤»
moritz_ that's correct, but probably for the wrong reasons
12:16 arthur-_ joined
masak aye. 12:17
jnthn No, it's correct for the right reason.
See infix:<does> in operators.pm
masak cool!
snarkyboojum moritz_: I get a fail for callframe.t 12:18
moritz_ snarkyboojum: does it fail after the first test?
jnthn It's quite cool, it looks at the type of the RHS argument and constructs a role with the right method name using the metamodel, then composes it. :-)
snarkyboojum tests 2, 6 and 7 fail here
oh
no, just the 2nd 12:19
masak in all honesty, a better name for $do-it-to-me is probably $receiver, or something similarly boring. :)
I say this as someone who created a project called Hit-on-me :P
snarkyboojum moritz_: 'got: Proxy.new(), expected 15'
moritz_ jnthn: I'd expect ~(5 but 'foo') to return '5' because prefix:<~> calls .Stringy, not .Str 12:20
jnthn moritz_: Me too.
moritz_ does it do that?
jnthn It did above, no?
moritz_ I thought it still called .Str
jnthn Oh. :S
masak moritz_: callframe.t aborts after the third test. Method 'inline' not found for invocant of class 'CallFrame'. 12:21
jnthn masak: Can I call it $doee? :-)
moritz_ rakudo: class A { method Str { 'Str' }; method Stringy { 'Stringy' } }; say ~A.new()
p6eval rakudo cb0e95: OUTPUT«Str␤»
moritz_ masak: needs to run with fudge
masak jnthn: yes! that's a good compromise :)
moritz_: ah, you asked about .t
jnthn masak: I think it also sounds like Dutch for "bye" ;-)
12:21 xabbu42 left, xabbu42 joined
moritz_ masak: and I meant .rakudo, sorry 12:21
snarkyboojum well, I ran it with make so I was talking about .rakudo as well 12:22
masak moritz_: the .rakudo file runs to completion. test 6 fails.
oh, and test 2.
moritz_ method line() { 12:24
self!annotations()<fline>;
}
that explains a lot
moritz--
jnthn flail
12:24 xabbu42 left, xabbu42 joined 12:25 arthur-_ left 12:26 JimmyZ left
colomon moritz_: don't forget those tests you turned off on Tuesday can be turned back on (assuming they weren't in the merge because the test count seems low) 12:26
moritz_ colomon: I've turned on some of them again 12:27
colomon: some still fail, but I guess I should re-enable them anyway
colomon moritz_: which ones fail? that indeed would be good to know... 12:28
12:28 am0c left
moritz_ series-simple.t for example 12:29
only series test left
I've re-enabled all the others
-#?rakudo skip "Why should Complex.sign fail gracefully enough to work with this test?" ok sign(3+4i).notdef, 'sign(Complex) fails'; 12:30
colomon: should that skip marker go? the test passes
colomon yes
I wasn't sure what to do with it, then I made things consistent by making the other Real-only methods have nice fails for non-Real Numeric too. 12:31
dalek kudo: 19e7264 | moritz++ | src/core/CallFrame.pm:
fix typo in CallFrame.pm, moritz--
 12:32
kudo: f17fe96 | moritz++ | docs/ChangeLog:
extend ChangeLog a bit
kudo: 17e43e8 | moritz++ | t/spectest.data:
turn on the series tests; those that fail are regressions from the "list" merge,
cono rakudo: ("62.76.96.200", "62.76.96.201", "62.76.96.202", ... "62.76.96.223").perl.say 12:33
p6eval rakudo cb0e95: ( no output )
cono repl just hang up on this example
is it an error? 12:34
pugssvn r31328 | moritz++ | [t/spec] lots of rakudo unfudges
tadzik cono: no output here, no hanging
ah, but it's #29
cono I think it must print an error message
ciphertext i get: 12:35
> ("62.76.96.200", "62.76.96.201", "62.76.96.202", ... "62.76.96.223").perl.say
===SORRY!===
Stub code executed
snarkyboojum cono: you can get the same behaviour by just putting ... into the repl
cono ciphertext: yup
is it a bug?
jnthn ciphertext: I think you didn't want that , before the ...
ciphertext no, a typo
moritz_ ciphertext: you probably didn't want the comma before teh ,
ciphertext jnthn++
jnthn And no, not a bug
... as a term is stub code that will whine a bit 12:36
cono But I think rakudo must print an error
jnthn cono: Ah, it didn't for you? :-S
cono syntax error ...
moritz_ not a syntax error
jnthn cono: It's not a syntax error.
cono jnthn: perl6 -e '("62.76.96.200", "62.76.96.201", "62.76.96.202", ... "62.76.96.223").perl.say'
moritz_ '...' is both a term and an operator
std: ...
p6eval std 31325: OUTPUT«ok 00:01 104m␤»
moritz_ std: 1 ... 2
p6eval std 31325: OUTPUT«ok 00:02 105m␤»
cono std: ... 2
p6eval std 31325: OUTPUT«ok 00:01 104m␤» 12:37
jnthn rakudo: ("62.76.96.200", "62.76.96.201", "62.76.96.202" ... "62.76.96.223").perl.say
p6eval rakudo cb0e95: OUTPUT«("62.76.96.200", "62.76.96.201", "62.76.96.202")␤»
jnthn rakudo: ("62.76.96.200", "62.76.96.201", "62.76.96.202", ... "62.76.96.223").perl.say
p6eval rakudo cb0e95: ( no output )
jnthn Hm
moritz_ bug
jnthn Yeah
snarkyboojum :)
moritz_ somwhere the fail() is lost
jnthn It should whine about stub code being executed.
We fail to fail. 12:38
And thus we fail.
cono :D
moritz_ meta-fail
12:38 JimmyZ joined
cono submit a bug 12:39
ciphertext > ("62.76.96.200", "62.76.96.201", "62.76.96.202" ... "62.76.96.223")
Null PMC access in find_method('params')
moritz_ another bug
ciphertext (this includes local changes, though)
moritz_ oh
then don't submit :-)
pmichaud good morning, #perl6 12:40
12:40 masonkramer left
snarkyboojum I don't get that behaviour :) 12:40
moritz_ good morning pmichaud
12:40 masonkramer joined
cono pmichaud: morning 12:40
12:41 arthur-_ joined
jnthn re-morning, pmichaud 12:41
moritz_ :-)
12:41 quester_ left
pmichaud so, how do things look a few hours later? ;-) 12:41
JimmyZ wow...
moritz_ pmichaud: a few more commits, less passing TODOs 12:42
pmichaud: I've re-enabled the series tests; some of them are still failing
I've also managed to fix CallFrame.pm, break it, and fix it again :-) 12:43
pmichaud excellent, not so great, and really excellent! :-)
ciphertext in my @a = 1, 2; how is the rhs converted from a parcel to array? i.e. what methods/subs are called? 12:46
moritz_ pmichaud: you might also be pleased that some test files just started passing, like for hash slices (iirc) 12:47
pmichaud moritz_: yes, I was thinking that would happen :)
I know that a *lot* of stuff was backed up on the list/iterator stuff.
(even if it didn't seem to have an obvious connection) 12:48
jnthn ciphertext: infix:<=> is called, and passed the Array from the LHS and the parcel from the RHS
ciphertext: And then shuffles the Parcel's contents into the array
12:49 rgrau joined, xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
colomon looking at series errors... 12:54
ciphertext colomon: see backlog 12:56
colomon oh, changing from batch(N) to [^N] broke the tests -- batch stopped when the iterator ran out, but [^N] pads. 12:57
ciphertext: where?
pmichaud .munch is a somewhat acceptable alternative to .batch, I would think. 12:59
ciphertext masak, moritz_ and i were talking about my patch for &infix:<...>
12:59 Guest94288 left
colomon pmichaud: hmmm.... there's no actual reason to use [^10] in these tests that I can see. We shouldn't need munch either. 13:00
moritz_ nopaste.snit.ch/paste
masak lol i haz blogged: use.perl.org/~masak/journal/40403 13:04
(it's about this weekend's mini-hackathon, and its three-phase nature. I find I really like working like that.) 13:05
pugssvn r31329 | colomon++ | Changing from .batch(N) to.[^N] broke tests that expected to get fewer than N elements from the series. But if there are fewer than N elements, we don't need batch or []!
moritz_ rakudo: say (^5).[^10].elems 13:06
p6eval rakudo 17e43e: OUTPUT«10␤»
moritz_ I'm pretty sure that's wrong
masak aye.
rakudo: say (5).[^10].perl 13:07
p6eval rakudo 17e43e: OUTPUT«Method 'postcircumfix:<[ ]>' not found for invocant of class 'Int'␤ in main program body at line 1␤»
moritz_ slices extending over the upper bound of the list should just be Nil
masak they should? I thought they should be as large as possible.
moritz_ I mean the return value should be Nil
of the excessive elements 13:08
masak I'd expect the above to print "5\n".
pmichaud there are several competing things happening here.
13:08 agentzh left
moritz_ I've tried to put postcircumfix:<[ ]> into Any 13:09
and got stuck with what to do with %h[0]
colomon moritz_: oh, right!
masak disallow it.
moritz_ die "with fire" ? 13:10
masak do Hashes do Positional?
pmichaud no.
but %h.list[0] would work. 13:11
as would (@%h)[0]
masak of course.
[particle] moritz_, masak: re: S19... Single-character options may be clustered with the same syntax and semantics
moritz_ and both would be the same as %h.pairs.[0]
masak that's because then it's no longer a hash.
moritz_ [particle]: then I misremembered something, sorry
masak [particle]++
13:11 xabbu42 left, xabbu42 joined
moritz_ [particle]: with the same syntax and semantics... as perl 5? 13:12
pmichaud my @a = ^5; say @a.perl;
rakudo: my @a = ^5; say @a.perl; 13:13
p6eval rakudo 17e43e: OUTPUT«[0, 1, 2, 3, 4]␤»
pmichaud rakudo: my @a = ^5; say @a[^10].elems
p6eval rakudo 17e43e: OUTPUT«10␤»
colomon pmichaud: can I use .munch in a spectest? 13:14
[particle] moritz_: aye, as perl 5. that is from the "Unchanged Syntactic Features" section
pmichaud colomon: works for me, I expect it to become spec.
13:14 plainhao joined
[particle] only the last single-character option can take a value 13:14
masak just like I hoped it would be :) 13:15
pugssvn r31330 | colomon++ | Replace .[N] with .munch(N) so that results are not padded with Any().
r31331 | colomon++ | [t/spec] Don't use .[^20] on tests which should have finite results. 13:17
13:18 SmokeMachine joined
colomon okay, that's got all the series tests passing (when fudged) again. 13:18
pmichaud \o/
moritz_ colomon++ # cleaning up the mess I accidentally left behind
nopaste.snit.ch/21326 spectest summary (before colomon's fixes) 13:19
jnthn Wow, mostly TODO passes. 13:20
colomon so reduce.t
t/spec/S09-typed-arrays/arrays.t
are the only two problem files remaining?
pmichaud I suspect the problem with arrays.t has to do with object initialization. 13:21
I'll work on that one.
colomon it's the [>>+<<] that's failing in reduce. 13:22
PerlJam gutenTag
13:22 kensanata left
colomon suspect it might have something to do with the .flat? 13:22
13:22 broquaint left
colomon rakudo: say [>>+<<] ([1..3],[1..3],[1..3]) 13:23
p6eval rakudo 17e43e: OUTPUT«Sorry, sides are of uneven length and not dwimmy.␤ in 'hyper' at line 114:CORE.setting␤ in 'hyper' at line 137:CORE.setting␤ in 'reducewith' at line 1␤ in main program body at line 1␤»
13:23 gbacon joined
ciphertext in pir, when cloning a pmc (e.g. $P0 = clone $P1), is type information lost or something? 13:24
jnthn ciphertext: If you have a Perl 6 object, almost certainly better to call .clone() 13:25
Cloning may lose some properties.
PerlJam make
oops
pmichaud if the idea is to get &take to clone its arguments.... I'm not so sure that's a good idea.
ciphertext oh? 13:26
jnthn pmichaud: I tried that bath once in the past.
pmichaud: It fixed the usual test cases...and broke other things.
er, path
:-)
So anyway, I didn't apply it.
pmichaud better would be to strip the arguments of their containers somehow.
i.e., so that you're only taking the values, and not the containers of the values. 13:27
jnthn Would a simple deref do?
er, deobjectref
pmichaud yes and no.
consider
masak under which circumstances should a class author overload the Mu.clone method?
pmichaud take 3, (4,5), 6
I'm not sure how to peek inside of parcels and deobjectref those things.
moritz_ is there a good reason why take() is not a Perl 6 sub which a signature of (\$returns) ? 13:29
s/which/with/
pmichaud ummmm, it is.
that's the reason it's a problem.
jnthn moritz_: \$foo is part of why we end up with the same container referenced throughout.
pmichaud captures capture the container, not just the value. 13:30
so we see changes to the container
jnthn pmichaud: ah, I guess a more apt example is take 3, ($a, $b), 4; or so.
pmichaud jnthn: right
moritz_ last time I looked, take was a PIP sub with a slurpy parameter list
pmichaud moritz_: pir slurpy parameter is basically the same as (\$returns)
it's not like a Perl 6 slurpy that flattens
jnthn moritz_: Even if that is so, the things inside the PIR slurpy will act as if they were all implicitly \$foo 13:31
13:31 xabbu42 left
pmichaud internally, a Parcel is just an RPA 13:31
and .param pmc args :slurpy produces an RPA
13:31 Guest23195 joined
jnthn pmichaud: Hmm. What if take did have a Perl 6 slurpy sig, I wonder... 13:31
Not sure it's right though.
pmichaud it's wrong
jnthn oh, yeah
pmichaud we don't want to flatten
moritz_ ah, the PIR having implicit \ was what I was missing
jnthn It's veyr wrong when we try to do slices. 13:32
colomon rakudo: say [<<+>>] ([1..3],[1..3],[1..3])
p6eval rakudo 17e43e: OUTPUT«3 5 7 4 6 8 5 7 9␤»
pmichaud and even if we do slurpy slices, it's still wrongish.
jnthn *nod*
pmichaud here's the issue with take....
jnthn Yeah, we want it kinda unscathed structurally
Just with its variable links severed
pmichaud rakudo: my $a = 5; sub foo() { $a++; }; sub bar($x) { say $x; foo(); say $x; }; bar($a); 13:33
p6eval rakudo 17e43e: OUTPUT«5␤6␤»
pmichaud this example is turning "take" inside out so we can see what is happening.
essentially, the problem is that when we have a function call, the parameters are bound to the actual containers 13:34
so, with take $a
we're not capturing the value of $a, we're capturing the container itself
moritz_ the common workaround for that is
take my $x = $a
pmichaud correct 13:35
moritz_ could we do that in take() too?
hm
13:35 bluescreen joined
jnthn Thing is we have a parcel that we probably don't want to enforce context on. 13:35
pmichaud I'm not sure what we would do with take 1, ($a,$b), 2
jnthn And assignment one why or another enforces a context.
*way
13:35 bluescreen is now known as Guest99875
moritz_ that would involve unpacking the parcel, identifying the containers, clone them, re-compose into a new parcel 13:36
sound hacky
pmichaud right
jnthn Well, identify the containers, take the values out and re-compose into a new parcel
but yes
(as in, store the de-containered things)
OTOH, do we have a case where that approach wouldn't work? 13:38
pmichaud I can't really think of one at the moment.
and I could certainly prototype something to handle it fairly quickly 13:39
jnthn In a sense, it's a little bit like binding to a signature the same shape as the Parcel with everything "is copy"
pmichaud oh!
actually, yes, I could do this pretty easily in PIR, come to think of it.
oh, yes, there is a problem. 13:40
with something like:
my $x = [1,2,3]; take $x
we can't just strip off the container, because it's the container that gives the value its "item-ness"
taking off the container in this case would convert the non-flattening array into a flattening one 13:41
jnthn pmichaud: In that case, isn't $x a Perl6Scalar (or ObjectRef) in turn referencing another ObjectRef?
pmichaud jnthn: it's a Perl6Scalar referencing an Array
jnthn Ah, yes.
pmichaud it's not a chain of objectrefs, no. 13:42
jnthn And take [ 1,2,3 ] is probably going to thwart any "1-deep"
colomon rakudo: say [<<~>>] ([1..3],[1..3],[1..3])
pmichaud I wonder if there are properties other than flattening that would need to be preserved
p6eval rakudo 17e43e: OUTPUT«111 221 331 112 222 332 113 223 333␤»
jnthn Even if that were the case.
moritz_ ro-ness?
pmichaud ah, yes -- take [ 1, 2, 3 ] would also lose its item nature 13:43
rw is a propery of the container also, so stripping the container would make allof the values ro
jnthn pmichaud: Yeah. It won't fly.
pmichaud I think that's pretty safe.
well, it wouldn't be too difficult for me to grab all of the values, decontainerize them, and then put on a new container with the same flattening characteristics as the original 13:44
that's only about 3 extra lines of PIR.
jnthn fresh container with the same props?
Yeah
especially given setprop
er, setprophash
pmichaud oh, I hadn't thought of same props.
jnthn or whatever it's called
pmichaud that would make it even easier.
Maybe I'll try that.
jnthn I'm not quite up on property use in the latest model. 13:45
We have a scalar property, or a flatten property these days?
Or neither?
pmichaud it's a 'scalar' property. 'flatten' is gone.
jnthn OK
pmichaud also '!FETCH' is gone. :-)
and I'm thinking that 'scalar' may change to 'item' at some point. 13:46
jnthn Hmmm...
!FETCH being gone may have to be considered when we get to doing Proxy or other tied scalar containers, but that's not an immediate worry.
13:46 mjk left
pmichaud ...one thing that we have to recognize is that by doing any of this de-containerization we're fundamentally going outside of p6's existing signature binding model to do it 13:46
jnthn pmichaud: Yeah, that is bothering me a little. 13:47
We're "cheating".
pmichaud big time.
which is why I've been hoping for someone to figure out what "take" really means within the boundaries of the specification.
and then alter the specification to accommodate what we want.
I'm also hoping that I won't find that someone in the mirror. :) 13:48
jnthn What we want to happen with take doesn't seem to have a matching mechanism in the current signature semantics.
13:48 kda left, kda joined, kda left
pmichaud well, I suspect take itself needs a bit of a rethink. 13:48
13:48 kda joined
pmichaud i.e., it's not so much that we need to expand the signature semantics, but we need to rethink how take itself is achieved 13:49
it's trivially simple to say, for example, that &take works by manipulating the parcel to remove containers and the like 13:50
as opposed to saying that the binder has to do it.
jnthn True
And if we have a Perl 6 way to write that, then we're OK I guess.
pmichaud so it *is* possible to do it within the current binding semantics, we just need to officially declare that this is in fact what take does.
jnthn I'm not a big fan of extending binding semantics just for take.
pmichaud right
I'm pretty sure the existing binding semantics are (1) what we want and (2) adequate 13:51
I'm pretty sure the problem lies in the take API and/or model itself.
mathw It seems to me that if nothing else wants to do that kind of thing, and take can do it itself, it should...
jnthn I'm not too keen on making people know that they shouldn't give variables that exist between takes some extra thought, though.
pmichaud mathw++
moritz_ maybe the problem is at another level
jnthn But not entirely against it.
moritz_ afaict gatther() uses .push internally
pmichaud it does not 13:52
moritz_ what does it do?
pmichaud at least, not a p6 push
moritz_ it sounds like it's binding the new values into the array
instead of assigning it
pmichaud ...array?
there's no array
moritz_ list
sorry
pmichaud one cannot assign into a list
a list doesn't have any containers of its own
jnthn Anyway, +1 one what mathw said - if there's to be some magic, it belongs inside take.
pmichaud it cannot have them
lists have to reference the original containers, otherwise things like .map cannot affect the values of the original list 13:53
colomon oh, the reduce bug is actually a hyper bug.
pmichaud s/affect the values/affect the containers/
moritz_ kinda thinks that .map affecting the original list is broken, but that's not the topic of the discussion 13:54
masak I keep seeing people being surprised over and over again by values being changed *after* being put into the invisible gather list by &take. is there a sensible use case of when one would actually want those semantics?
pmichaud moritz_: that's what enables @foo.map( { $_ = ... } ) to work
moritz_ pmichaud: I know
masak and I'm not talking about the bug here, just the normal behaviour of &take.
jnthn masak: My feeling is most people don't expect take to work the way it currently does. 13:58
mathw I certainly don't
moritz_ pmichaud: from a functional programming point of view it's ... very unusual, to say the best
mathw I've been caught by that a lot
pmichaud masak: we would want those semantics if we ever expect the results of a gather to act as lvalues
moritz_ and also from the view of separation of concerns
mathw moritz_: my inner functional programmer says map operates on an immutable list, but this is Perl 6...
moritz_ mathw: right
masak rakudo: my $i = 0; say (gather while $i++ < 10 { take $i }).perl
p6eval rakudo 17e43e: OUTPUT«(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)␤»
masak huh :)
13:58 plobsing joined
moritz_ .map constructs a new list. it's job is not to alter the old one 13:58
rakudo: my $i = 0; say (gather while ++$i < 10 { take $i }).perl
p6eval rakudo 17e43e: OUTPUT«(1, 2, 3, 4, 5, 6, 7, 8, 9)␤»
masak pmichaud: I wouldn't mind sacrificing the opportunity to treat the results as lvalues, if it led to more understandable semantics.
colomon remember, you're talking about "for", too....
jnthn I'd say that if we want to allow the lvalue case, it wants to be the exceptional, dehuffmanized case.
masak isn't the above result *wrong* according to current spec?
jnthn Not the default.
masak jnthn: nod.
moritz_ colomon: I know. I've kinda become an extremist about that lately :-)
PerlJam moritz_: so, you're saying map and for shouldn't be synonyms?
13:58 ruoso left
moritz_ PerlJam: no. I'd be fine with 'for' not modifying the list either 13:58
jnthn masak: I can certainly argue why the current behavior is "not surprising" but I can also completely understand that such arguments will mean nothing to the everyday user.
moritz_ there's still @a.=map for in-place modifications
pmichaud that's actually different.
jnthn masak: And that's who we should really be looking out for.
masak jnthn: aye.
moritz_ pmichaud: I know
masak jnthn: it's probably a symptom if lots of people fall into the same trap.
jnthn masak: Right.
moritz_ but I don't think @larry is likely to make for/map immutable, so my point is moot
mathw I think in the sense of the Perl world, it makes sense for map to see mutable values 13:59
jnthn masak: If I hadn't seen that happen so much, I may have been tempted to argue for the current semantics. As it stands, so many people get bit by it I don't think that any argument in that direction will really hold any water.
pmichaud okay, here's what I think (more)
I think that we should modify take so that it de-containerizes its parcel 14:00
in the p6 sense, this would be done as an operation on parcels
if someone wants to use take in an lvalue sense, that's what captures are for.
(end)
jnthn lvalue is just a \ away 14:01
pmichaud: +1 from me
14:01 Zapelius left
pmichaud well, not only that, but we could have a take_lvalue 14:01
which *doesn't* decontainerize the parcel
I mean, all that &take really does is throw the parcel as part of a "take exception"
jnthn pmichaud: So long as we declare the "magic" is in take, not in the binding.
(in the spec)
pmichaud so I'm proposing that the new &take decontainerize the parcel before it throws it.
jnthn Right. 14:02
That sounds workable.
And explainable.
pmichaud there are also several other places where it would be very handy to decontainerize a parcel
for example, it would make it possible to have array assignment have more lazy characteristics without having to worry about action-at-a-distance effects
(we might even be able to use it to make array assignment completely lazy)
right now there's a problem with something like 14:03
my @a = 1..foo(), $b
if 1..foo() ends up acting like something that halts mostly eager evaluation, we end up lazily evaluating $b
which could happen sometime after $b changes
masak tricky. 14:04
pmichaud but if we have a way of de-containerizing the Parcel
then the connection to $b goes away, leaving only its value at the time of the assignment
which means laziness is no longer an issue
WIN.
mathw Ooh
Which could remove a lot of potential confusion around lazy semantics 14:05
Juerd pmichaud: Does that use CoW somehow?
pmichaud (it doesn't quite work with arrays still, though, because decontainerizing an array still leaves a mutable array. Put another way, arrays *are* containers that can't be decontainerized.)
Juerd: it very well could be a CoW feature.
14:05 patspam joined
mathw Although I have only the vaguest notion of what 'de-containerising' is, it seems like a sensible idea in this context 14:06
pmichaud that might make even more sense
if cow is something we can do to a Parcel, then take is really going to be taking advantage of that feature. 14:07
instead of "de-containerizing"
it's simply marking its values as cow
mathw That's... very sensible 14:08
pmichaud anyway
I see two choices 14:09
(1) we can try to make &take act the way we think it should act, even though we don't yet know the correct underlying semantics 14:10
(2) we can leave &take the way it is now, so that people have to write code to explicitly make their intentions clear until the underlying semantics are known
the advantage of #1 is that take will seem more natural to people, but an underlying semantic change in the future may cause existing code to break 14:11
the advantage of #2 is that code that people write now will continue to work
(but people have to be burdened to realize that there's something spooky going on)
er, potentially spooky
mathw It's probably not a good idea to change it without knowing what the right thing to change it to is. 14:12
jnthn pmichaud: I think that with (1) we'll end up with Rakudo having semantics closer to how I expect things to end up than (2) would.
Juerd "In the future", does that mean after Perl 6 is "done", or during the development process?
jnthn pmichaud: That is, I don't think the final answer will be "people have to be burdened with the action-at-a-distance thing we have now" 14:13
So even if we don't get the semantics spot on, they'd still be closer to the right ones than where we are now.
sjn Juerd: "In the future" means whenever there's a change that has/needs to be made 14:14
moritz_ Juerd: I think it's hard for any of us to imagine what Perl 6 looks like when it's "done" :-)
Juerd sjn: That's vague enough to always apply
PerlJam pmichaud: who are the "people" in #2? Are they mostly on #perl6?
sjn Juerd: exactly (remember, perl6 is a _language_ - it will probably _never_ be "done") 14:15
Juerd I just mean: currently, people *expect* Perl 6 to change, even fundamentally, but after a while it will just get on peoples nerves.
sjn: Yeah yeah. That's why I used the "".
arnsholt PerlJam: I think the assumption should be that users are not in #perl6
sjn Juerd: yep, expect it to change, but also, expect the features that are much used/sensible/useful to become more stable 14:16
masak there are quite a few Perl 6 users who have never been to #perl6.
moritz_ I was about to mention TheDamian, but in fact I've seen him here once :-) 14:17
sjn Juerd: The more people use Perl6, the easier it's to figure out what what needs to be stable
PerlJam sjn: everything :)
masak PerlJam: eventually, yes.
stabilizing things that aren't ready would cause more damage than letting them evolve first. 14:18
sjn PerlJam: imo, "everything" is that nice ideal one can imagine right beyond the horizon. in the meantime, it's probably best to get there one step at a time
...while figuring out what steps to make 14:19
Juerd sjn: I think you're missing my point. Would the hypothetical incompatible change that pmichaud referred to in his option #1 be within the near future (before Perl 6 is widely deployed) or the remote future (when Perl 6 has a large user base) 14:21
sjn aah
moritz_ I think we all hope "near future", but time predicitions have a tendency to be wrong
masak Juerd: and would the change in semantics be associated with a version change, such as 6.0.0 -> 6.1.0?
sjn nvm me then :) 14:22
moritz_ I dearly hope it would
masak I wouldn't mind if 6.1 came fairly soon after 6.0, and contained changes of just that type. improvements, clarifications, new discoveries. nothing fancy, just progress. 14:23
moritz_ too
erm
moritz_ neither
masak it would look good on a history timeline, too :) 14:24
PerlJam If jnthn is correct that the guessed semantics are close to the final semantics, then that future change might not be that big of a deal. So ... how good are jnthn and pmichaud at guessing?
14:24 xabbu42 joined
moritz_ and I hope that there will be a clear versioning scheme for incompatible changes vs. bug fixes 14:24
mathw PerlJam: ask me in 100 years :)
PerlJam wait ... when is Perl 6.0.0 going to be released? Or are we calling that Rakudo*? 14:25
(they're still separate things to me)
jnthn They're certainly separate things. 14:26
mathw That's because they are separate things
PerlJam oh good. Then "we've got plenty of time" :)
jnthn My point was that when we have semantics that users constantly trip over, they tend to get changed.
Currently we have semantics that users trip over and have the option to move to ones that should trip people up less.
Or stay where we are. 14:27
I'm just saying I think adopting ones that trip people up less feels more Perl 6-ish to me. :-)
mathw TRipping users up before we even have any declaration of spec-stability is not good really is it :)
PerlJam mathw: users should expect to be tripped up in the grey areas of the spec :) 14:28
mathw I'd just say that you have to be fairly sure the change is going in the right direction, lest it ends up changing back again...
PerlJam jnthn: Well, if you implement it, who's to say otherwise? :) 14:30
pmichaud let's look at it slightly differently 14:31
earlier this year, we had a list and iterator specification that got put into Rakudo ng
a lot of code was built on top of that specification...
which turned out to be completely unworkable. 14:32
it had some fundamental issues in dealing with "disappearing arrays" and the like.
so, we had to do some fairly deep analysis to determine the flaws in the model and come up with a new one, which makes a fairly different set of assumptions 14:33
and changes the list/iterator API substantially
so, if we move to make &take more dwimmy than it is now, my question is: are we then storing up future problems when we discover that &take needs to do something fundamentally different? Or do we think we can make a good enough guess? 14:34
it's a borderline decision for me. 14:35
I could go either way. 14:36
pmichaud thanks the crickets who remained through this presentation. :)
colomon I don't feel like I have a good enough understanding of the issues to take an informed vote. 14:37
pmichaud colomon: I think we're all in that boat. :) 14:38
PerlJam Do you think the "end semantics" for &take will have it such that the user must be really specific or that &take will be more dwimmy?
colomon But I will say that I don't think we should be too afraid of making mistakes now.
pmichaud colomon++
jnthn I think that we probably wouldn't have got to the current, much better list semantics we have now without doing the last, wrong ones first.
pmichaud PerlJam: I'm sure &take will be more dwimmy. I just don't know what the dwimminess will look like.
PerlJam Then I'm for option #1. Make a best guess and go with it. 14:39
pmichaud so, we could make a dwimmier &take, but somehow warn people that "hey, this isn't a solid specification yet, and if you really want to be safe you should do ..."
moritz_ There's also option #3, ask our Perl 6 oracle
pmichaud moritz_: I'm speculating, but this issue has come up quite a bit before, and I'm guessing the oracle doesn't have a clear answer yet either. :) 14:40
(like with lists/iterators)
jnthn++ # I agree, we probably wouldn't have arrived at the present model without first going through the wrong ones first.
PerlJam But an implementation that "comes close" may help the oracle too :)
pmichaud yeah, I'm coming to that conclusion as well.
moritz_ like it did with iterators
pmichaud okay.
I think we'll try fixing up &take (hubris) and see what happens. 14:41
probably post-release today :)
jnthn hubris ftw
moritz_ indeed
PerlJam pmichaud: what? you mean you can't whip something up in 6 hours or so?
;-)
pmichaud PerlJam: I *can*, yes.
moritz_ without hubris I wouldn't have attempted callframe()
pmichaud In fact, I think I could do this one in two.
masak realizing that we don't have enough information to get everything right the first time, and daring to make mistakes now and correct them later, are two of the main reasons I like the Perl 6 developer community. the only way forward is successive iteration. 14:42
PerlJam masak++ indeed!
pmichaud but I reserved today for todo and ticket wrangling :)
and blog posting
mathw posts pmichaud two more hours
colomon another release question: I'm convinced the current implementation of hyper is wrong. 14:43
rakudo: say ([1, 2, 3] >>+<< [4, 5, 6]).perl 14:44
p6eval rakudo 17e43e: OUTPUT«[[5, 7, 9]]␤»
colomon I think I know how to fix, but I don't know if I can get it done in reasonable time this afternoon.
moritz_ rakudo: say ([1, 2, 3] >>+<< [4, 5, 6]).WHAT
p6eval rakudo 17e43e: OUTPUT«Array()␤»
pmichaud what's wrong about it?
colomon Should we fudge the one failing test (the reduce.t one) and deal with it post-release?
cognominal rakudo: (*)(1)
p6eval rakudo 17e43e: ( no output )
cognominal rakudo: (*+*)(1,2) 14:45
p6eval rakudo 17e43e: ( no output )
colomon pmichaud: if you feed it two arrays, it returns a nested array.
cognominal rakudo: say (*+*)(1,2)
colomon basically, it needs the map solution you suggested yesterday.
p6eval rakudo 17e43e: OUTPUT«3␤»
moritz_ rakudo: say (1 >>+<< 2).perl 14:46
p6eval rakudo 17e43e: OUTPUT«[3]␤»
moritz_ ah
it always returns an array
colomon moritz_: exactly.
moritz_ and if the arguments happen to be arrays, it recurses into them
pmichaud oh, that seems fixable
just a sec
moritz_ woulden't a return |@result; in the end fix that?
pmichaud they shouldn't be arrays at all. 14:47
moritz_ (might be a naiive idea)
pmichaud they should be lists
moritz_ parcels?
pmichaud or parcels, yes.
moritz_ note that hyper is not lazy
it's the opposite :-)
colomon actually, hyper should return the same type it got in, by spec.
pmichaud that's fine, there's still the issue that putting lists into arrays collapses structure.
colomon so pass it two lists, you should get a list back 14:48
pass it two arrays, you should get an array back
pmichaud rakudo: say ((1,2,3) >>+<< (4,5,6)).perl
p6eval rakudo 17e43e: OUTPUT«[5, 7, 9]␤»
pmichaud oh
moritz_ that seemsm kinda scary, from an implementation point of view
pmichaud then yes, I'd try return |@result
moritz_ (preserving list type)
colomon moritz_: it goes much, much deeper than that. 14:49
if you pass it any Iterable, it's supposed to be able to do its thang and then return an object of that type.
Sets, Bags, whatever.
masak colomon: what about when the types don't match?
ash__ rakudo: my $a = eval '{ sub foo { 1 + 3 } }; return &foo'; say ~$a() # do i have something wrong in that? 14:50
p6eval rakudo 17e43e: OUTPUT«invoke() not implemented in class 'Seq'␤ in main program body at line 11:/tmp/dz8TCW5Ost␤»
pmichaud ash__: subs are lexically scoped by default.
also, you have a return outside of any sub.
colomon masak: I don't think it's supposed to work in that case. 14:51
ash__ well, i was trying to figure out how to get the eval to return the sub after its been defined
moritz_ rakudo: my $a = eval '{ sub foo { 1 + 3 } }; &foo'; say $a()
p6eval rakudo 17e43e: OUTPUT«invoke() not implemented in class 'Seq'␤ in main program body at line 11:/tmp/09dRar5bVV␤»
colomon whoops, belay that
Seq(3,8,[2,Seq(9,3)],8) >>->> (1,1,2,1); # Seq(2,7,[0,Seq(7,1)],7
moritz_ rakudo: my $a = eval 'sub foo { 1 + 3 }; &foo'; say $a()
pmichaud there's still no &foo in scope.
p6eval rakudo 17e43e: OUTPUT«4␤»
moritz_ right
better
colomon anyway, I've no idea how to make that work for arbitrary types yet, but it probably should work for lists and arrays. 14:52
ash__ ah, okay, i see what i did wrong, thanks moritz_++ pmichaud++
colomon I don't think implementing it is a multi-day project, but I don't know if it's a release-time project. :)
pmichaud colomon: I'm fine with fudging the one test for the release and working on it a bit later.
moritz_ colomon: the obvious (and probably wrong) approach is to coerce the return type
pmichaud (if I wasn't fine with it, I wouldn't have merged the branch to trunk :)
moritz_ @result."$input.WHAT.perl()"() # URKS
14:53 broquaint joined
pmichaud $input.WHAT(@result) # better? 14:53
moritz_ what does that do?
pmichaud same as Dog(...) 14:54
moritz_ really?
pmichaud (assuming $input is a Dog)
might need parens
($input.WHAT)(@result)
moritz_ runtime error in rakudo in both cases? :-)
pmichaud it doesn't work *yet*
pugssvn r31332 | colomon++ | [t/spec] Fudge test which fails because of hyper issues.
colomon afk # exercise!
moritz_ ah, with parens it makes more sense
pmichaud we haven't fixed up postcircumfix:<( )> on our type objects yet, I don't think. 14:55
moritz_ it's also a parsing issue
rakudo: Int()
p6eval rakudo 17e43e: OUTPUT«Could not find sub &Int␤ in main program body at line 11:/tmp/dVRMfwD9mU␤»
pmichaud yes, that too, although ($input.WHAT)(...) wouldn't be a parsing issue :)
moritz_ that kind of type coercion has the advantage of also working with anonymous classess too 14:56
pmichaud right.
We aim to allow anonymity these days. :)
moritz_ wheres $output."$input.WHAT.perl()" is simply FAIL in those cases
14:58 plobsing left
colomon pmichaud: is "for" still eager, or did it become lazy in the Great List Revamp? 14:59
14:59 ash__ left
pmichaud it's still eager. 14:59
I haven't changed it to use .map yet.
(need sink context for that first)
14:59 rhr joined
jnthn er, I had TypeObject($foo) as being essentially sugar for $foo."{TypeObject}"() 14:59
pmichaud I think it was discussed before and declared that it's not syntactic 15:00
jnthn I didn't say it was syntactic.
pmichaud it's invocationon the TypeObject
jnthn Right
Which (at least by default, unless overridden) does the mapping I just mentioned.
pmichaud that's weird. 15:01
I would just expect it to be handled in the dispatcher.
jnthn huh?
15:01 macdaddy joined
pmichaud (maybe not in the dispatcher, but via normal dispatch) 15:01
jnthn Oh, I wasn't advocating otherwise.
pmichaud oh, you're saying that postcircumfix:<( )> does the method call?
maybe. 15:02
jnthn I was saying that's what...yes, right.
moritz_ jnthn: it's a reasonable default implementation for named types that are available in all scopes
pmichaud yeah, I'm not sure it's going to stand, but it's okay for now :)
jnthn Me either, it's just the answer I got last time I asked, iirc.
pmichaud afk, lunch 15:04
15:05 am0c joined, tadzik left
jnthn -> walk, shopping 15:06
PerlJam y 15:07
15:12 ash__ joined 15:13 xinming_ joined
snarkyboojum rakudo: my$a=42; say $a 15:15
p6eval rakudo 17e43e: OUTPUT«42␤»
15:16 xinming left
snarkyboojum rakudo: my$a=42;$a.say 15:16
p6eval rakudo 17e43e: OUTPUT«42␤»
snarkyboojum didn't realise spaces weren't needed between my and variables 15:17
masak std: my$a=42
p6eval std 31325: OUTPUT«ok 00:01 105m␤»
masak std: my($a,$b)
p6eval std 31325: OUTPUT«===SORRY!===␤Variable $a is not predeclared at /tmp/cnruvy4SFH line 1:␤------> my($a⏏,$b)␤Variable $b is not predeclared at /tmp/cnruvy4SFH line 1:␤------> my($a,$b⏏)␤Undeclared routine:␤ 'my' used at line 1␤Check
..failed␤FAILE…
snarkyboojum or I did and forgot 15:18
15:18 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
masak snarkyboojum: Yapsi supports it too :) 15:18
15:19 kensanata joined, TiMBuS left
snarkyboojum masak: yapsi++ :) 15:20
masak buubot: karma yapsi
buubot masak: yapsi has karma of 1
15:20 am0c left
masak \o/ 15:20
snarkyboojum heh
cono yapsi++ 15:22
snarkyboojum well, it's goodnight from me 15:23
masak: good luck with the release :)
masak snarkyboojum: thanks! good night.
15:24 snarkyboojum left
JimmyZ what does "5 but 'string'" mean? 15:28
it's in the changelog 15:29
cono JimmyZ: adding to Int class methods of 'string'
masak er, no.
ash__ but is like does 15:30
but not exactly
masak adding to *that object* the capabilities of a Str.
arnsholt So the object behaves like 'string' for Str stuff, but 5 for Numeric stuff? 15:31
cono JimmyZ: good examples in S12-objects /Enumeration
masak 'but' attaches run-time properties to individual objects.
I think it does so by returning a new object, not by changing an existing one. 15:32
JimmyZ oh, 'but' keyword
ash__ i don't think it works yet though 15:34
masak rakudo: say (5 but "OH HAI").Str
p6eval rakudo 17e43e: OUTPUT«OH HAI␤»
masak \o/
cono rakudo: enum Day <Sun Mon Tue Wed Thu Fri Sat>; my Str $day = 'Today' but Tue; $day.Day.say
p6eval rakudo 17e43e: OUTPUT«Method 'Day' not found for invocant of class ''␤ in main program body at line 11:/tmp/ck0SNsGudk␤»
ash__ ah, i was using it wrong
cono :(
masak ash__: no, you're using it right. 15:35
ash__: but it doesn't work yet for enums.
moritz_ rakudo: say ('foo' but 5) + 5
p6eval rakudo 17e43e: OUTPUT«5␤»
ash__ rakudo: say 42 but 'the answer' # shouldn't that print "the answer" ? 15:36
p6eval rakudo 17e43e: OUTPUT«42␤»
cono like in p5 we can store int and str value in scalar :)
but in p5 throw the guts 15:37
ash__ 5 but 'string' is the same as 5 but (role { method Str() { 'string'} }), 5 but True is 5 but (role { method Bool() { True } }) 15:38
colomon rakudo: say ('foo' but 5) ~~ Real
p6eval rakudo 17e43e: OUTPUT«0␤»
colomon rakudo: say ('foo' but Real) ~~ Real 15:39
p6eval rakudo 17e43e: OUTPUT«1␤»
colomon rakudo: say ('foo' but 5) ~~ Real
p6eval rakudo 17e43e: OUTPUT«0␤»
masak rakudo: say 5 ~~ Real
p6eval rakudo 17e43e: OUTPUT«1␤»
15:39 xabbu42 left
colomon rakudo: say ('foo' but 5.0) ~~ Real 15:39
p6eval rakudo 17e43e: OUTPUT«0␤»
15:39 xabbu42 joined
masak submits rakudobug 15:39
ash__ i think but is close but not exactly right...
rakudo: say ('foo' but 5.0).Num ~~ Real
p6eval rakudo 17e43e: OUTPUT«1␤»
masak rakudo: say 'foo'.Num ~~ Real 15:40
p6eval rakudo 17e43e: OUTPUT«1␤»
masak :)
cono :)
Str have Num method?
masak cono: yes, it's Cool.
15:41 JimmyZ left
cono Any is Cool? :) 15:41
masak no.
ash__ rakudo: say ('foo' but 5.0).Num
p6eval rakudo 17e43e: OUTPUT«0␤»
TimToady Cool is Any
ash__ :-\
cono Any base all over the p6 world? :D 15:42
ash__ rakudo: say ('foo' but 5).Num, ('foo' but 5).Int
p6eval rakudo 17e43e: OUTPUT«05␤»
TimToady Mu
cono ah
Mu -> Any -> Cool ? :D
masak rakudo: say Int ~~ Real
p6eval rakudo 17e43e: OUTPUT«1␤»
ash__ cono: thats commonly the case, yes but there are some things that don't follow that, but Mu is always the base 15:43
moritz_ right
with the exception of objects from other HLLs
TimToady we will probably make them derive from Mu too :) 15:44
cono in Any.pm, no inheritance..
ash__ rakudo: say Str.^parents
p6eval rakudo 17e43e: OUTPUT«Cool()Any()Mu()␤»
cono ash__: wow
moritz_ cono: src/builtins/Any.pir 15:45
Your branch is behind 'origin/master' by 155 commits, and can be fast-forwarded.
sorry, wrong paste
anyproto = p6meta.'new_class'('Any', 'parent'=>'Mu')
cono moritz_: augment meanse that it extends from pir clas ?
moritz_ yes
cono ty
moritz_ existing class in general
cono ah 15:46
everywhere ?
moritz_ yes
cono ok, thanks :)
ash__ rakudo: use MONKEY_TYPING; augment class Int { method foo { 'foo' } }; say 5.foo
p6eval rakudo 17e43e: OUTPUT«foo␤»
cono wow, awesome feature :)
TimToady well, in Ruby it's a Way of Life 15:48
15:48 [mark] left
ash__ same in python, all classes just let you tack stuff on 15:48
cono new OO feature :) 15:49
ash__ you can extend classes in Obj-C and Smalltalk too
PerlJam Is Perl 6 the only language that discourages it somewhat?
cono I like p5 OO feature: @ISA[0,1] = @ISA[1,0]; $self->SUPER::print(); :D
moritz_ "feature" 15:50
ash__ PerlJam: no, in Obj-C its not that easy either, you have to extend the category of the object you want to change, (its more akin to adding a role at runtime) 15:51
cono e.g.: I can sort DB objects by load in @ISA and call $self->SUPER::select
PerlJam cono: you're a strange one :) 15:52
cono i'm :D
ash__ PerlJam: also in python if you declare your class to have __slots__ it can only have those specific slots filled so you cant append anything you want, but the default behavior is that objects are open
ciphertext nopaste.snit.ch/21332 <-- patch to fix &infix:<...> passes all tests in t/spec/S03-operators/series* +1 TODO 15:59
15:59 REPLeffect joined
cono ciphertext: rakudobug with [PATCH] I guess 16:00
ciphertext well, we were talking about it earlier, so i wanted to post it here, where it'll be seen faster 16:01
16:01 Ross joined
ciphertext *we = masak, moritz_ and i 16:02
cono :)
say we[0] :D
ciphertext o.O except for the improper sigil on we, it's actually valid perl6 (assuming masak, moritz_ and i are functions) 16:03
16:04 cdarroch joined, cdarroch left, cdarroch joined
sorear TimToady: ping 16:04
TimToady: What was your reason for thinking viv would ditch YAML?
cono ciphertext: perl is speaking language :D 16:05
TimToady resolves into a Schrödinger's person
cono cat? :D
TimToady sorear: I was just thinking that we would generally emit data structures natively in whatever was the target language, especially if they could be precompiled 16:07
cono rakudo: ([/] 1, 2, 3).perl.say 16:08
p6eval rakudo 17e43e: OUTPUT«1/6␤»
TimToady sorear: but YAML is fine as a generic solution
16:09 REPLeffect left
TimToady also, not all targets will necessarily support YAML well 16:09
that's all
masak swim & 16:10
TimToady I don't hate YAML
except when I do...
16:10 masak left, REPLeffect joined
sorear TimToady: the YAML version also loads faster, by 0.1 second 16:16
16:17 Trashlord joined 16:18 REPLeffect left, REPLeffect joined
pmichaud back from lunch 16:20
16:21 envi^home left
[Coke] pmichaud: ~~ 16:22
16:26 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42 16:29 meppl joined
colomon ciphertext: is all that scmp stuff solely meant to support handling series with single character endpoints? 16:30
ciphertext colomon: yeah 16:31
colomon seems like it would be cleaner to detect those as a special case, convert the series to a numeric series based on the .ord values, and then map the resulting numeric series back through .chr? 16:33
ciphertext hmm 16:34
actually, it's not 'single character' endpoints that are the problem. 16:35
rakudo: say 'z' cmp 'aa'
p6eval rakudo 17e43e: OUTPUT«1␤»
ciphertext the problem is that cmp compares in lexicographic order, but series go in a more number-like order (i.e. shorter strings come first, then compare alphabetically) 16:36
colomon ciphertext: where does it say that? 16:37
pmichaud it seems to me that the spec is fairly straightforward, and we should simply follow the spec. 16:39
(I grant I might be missing something here.)
colomon pmichaud: right, I'm trying to figure out if I'm missing something. 16:40
ciphertext huh... i guess it doesn't say that. I'm not sure where i got it. 16:42
pmichaud ciphertext: it *used* to be a problem, but the new series specification seems to clear that up a bunch. TimToady++
16:43 charsbar joined
colomon I think we clearly need more series tests here. 16:43
16:44 charsbar_ left 16:45 rv2733 joined
colomon pmichaud: can you think of any objection to my ".ord the inputs, run series on the numbers, and map .chr the outputs" solution to the single character string issue in series? 16:45
pmichaud you mean like....
colomon that seems to me to be the cleanest way to implement TimToady's { $^prev.ord.succ.chr }
pmichaud isn't that exactly what that says? ;-)
colomon afk # diaper change 16:46
pmichaud if you're thinking of .ording the inputs in advance, it's wrong.
sorear perl6: foo; my &foo := sub () { say "HI" } 16:47
p6eval rakudo 17e43e: OUTPUT«invoke() not implemented in class 'Any'␤ in main program body at line 11:/tmp/ggq4IwbTH4␤»
..pugs: OUTPUT«*** Cannot use Undef as a Code object␤ at /tmp/ESC2EjTNI0 line 1, column 1-4␤»
..elf 31332: OUTPUT«/home/p6eval/pugs/misc/STD_red/match.rb:141:in `block in to_dump0': undefined method `to_dump0' for true:TrueClass (NoMethodError)␤ from /home/p6eval/pugs/misc/STD_red/match.rb:140:in `each'␤ from /home/p6eval/pugs/misc/STD_red/match.rb:140:in `map'␤ from
../home/p6eval/pugs/misc/STD…
16:47 Guest99875 left 16:48 kensanata left 16:50 REPLeffect left
sorear S06 doesn't say anything about that example 16:50
16:50 ruoso joined
sorear TimToady: Are sub statements run at an advanced phase in Perl 6, like they are in 5? 16:52
Which S covers this, if any?
jnthn I suspect Pugs and Rakudo are correct on this one.
pmichaud named sub declarations are, yes.
but the binding is runtime, iiuc
16:52 bbkr left
jnthn Right, that's the distinction. 16:52
16:53 bbkr joined
jnthn That's an anonymous sub being explicitly bound. 16:53
At runtime rather than "compile time".
16:53 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
PerlJam does ::= still do compile time binding? 16:53
pmichaud no
sorear so if I said my &foo; BEGIN { &foo := ... }, it would be correct, and more or less equivalent to a sub statement, yes?
pmichaud PerlJam: ::= is binding and make it read-only 16:54
ciphertext colomon: the ordering comes from the specification of autoincrement operators on chars, rather than the series specification. my $a = 'z'; $a++; $a == 'aa';
pmichaud ciphertext: but it's different for single character endpoints 16:55
ciphertext what do you mean? 16:56
pmichaud 'A' ... 'z' will follow the codepoint sequence, not the string iteration one 16:57
PerlJam pmichaud: er, what exactly is the "it" in that sentence? my $a ::= 5; # $a can't be re-bound? or just that $a's value can't change?
cono eval: my $a = "z"; ++$a
jnthn sorear: I believe yes.
colomon is back
jnthn rakudo: my $a = "z"; say ++$a
p6eval rakudo 17e43e: OUTPUT«aa␤»
colomon okay, the single character endpoints case should be easy. 16:58
cono I wanted p5 :D
but buubot keep silence :(
pmichaud i.e., in the series 'A' ... 'z', the thing that comes after 'Z' will be '[' and not 'AA'
colomon oh, except for the extra broken series sub. Hmmm.
ciphertext pmichaud: the spec says "but since 'Z' increments to 'AA', none of these ever terminate: 'A' ... 'zz' " 16:59
pmichaud ciphertext: sure, but that's not a single-character endpoint
colomon ciphertext: single-characters (on both endpoints!) is a special case 17:00
jnthn rakudo: sub foo() { try { my $r = eval ' 42 '; return $r }; }; say foo()
p6eval rakudo 17e43e: OUTPUT«Null PMC access in type()␤ in main program body at line 11:/tmp/UVXgTJRGsR␤»
ciphertext oh. skipped over a paragraph. i see it now
yeah, we need more tests. :p the scmp operator in my patch is used to correctly determine endpoints in string iteration order. It doesn't even consider the single-character exception. 17:03
oddly, 'A' ... 'z' == 'A' ... 'Z'
dalek kudo: 96af91d | pmichaud++ | src/Perl6/Actions.pm:
Remove fossil: 'for' should use &flat on its source, not &eager.
pmichaud uh, no.
not any more. 17:04
ciphertext i meant, that's how my version currently (and incorrectly) works
17:04 dakkar left
pmichaud okay. 17:04
ash__ rakudo: sub foo { try { return 13213 }; return 1 }; say foo; # is that right?
p6eval rakudo 17e43e: OUTPUT«1␤»
pmichaud yes, the old way has always bugged the heck out of me about ranges.
colomon pmichaud: it's officially wrong in ranges, too. 17:05
just haven't changed the code yet.
pmichaud right
I suspect that Ranges should just delegate to the series operator.
colomon well, actually, we did change the code, in the list branch.
pmichaud (since that's what the specification says)
colomon pmichaud: yeah, I was wondering about that yesterday.
the specification still says there's a RangeIter.
it just is supposed to behave exactly like the series operator. 17:06
pmichaud ...and, as followup to that, I suspect that the series operator should be smart enough to generate RangeIter
when it's appropriate to do so
colomon okay, that hurts my head.
pmichaud and I also suspect that RangeIter in the synopsis could be considered a fossil if we determine we really don't need one
i.e., the existence of "RangeIter" could be considered to be a leftover from the old incorrect way of looking at iterators.
colomon: really? I would just think that certain special cases of the series operator shortcut to do something different. 17:07
could even potentially be done with multisubs on &infix:<...>
ash__ try doesn't catch CONTROL exceptions does it?
pmichaud (although probably not)
ash__: Rakudo has known issues with 'return' in closures. 17:08
colomon pmichaud: when I mentioned getting rid of it yesterday to TimToady, he suggested there may be efficiency reasons to keep RangeIter.
pmichaud colomon: I agree
ash__ okay, just checking that is a bug
colomon I wonder if we might really want a SeriesIter, and then have Range delegate to it.
pmichaud I'm just saying that it's &infix:<...> that creates a RangeIter
17:08 Wolfman2000 left
colomon pmichaud: obviously that can work, but it really seems needlessly confusing to me. 17:09
pmichaud I can envision that we would have different types of *Iter depending on the series that needs to be generated
I think there's the same amount of complexity no matter what is done (more)
17:09 clintongormley joined
pmichaud either you have one type of iterator that tries to do everything 17:09
or you have several iterators that each do one thing well, and you select among them
colomon well, I vote we worry about getting it correct using gather / take, and then worry about efficiency afterward. 17:10
pmichaud wfm
I'm just saying that the gather/take approach may itself be fairly complex
if (...) { gather/take 1 }
elsif (...) { gather/take 2 }
elsif (...) { gather/take 3 }
...
also looks complex to me
colomon I don't think it is. 17:11
pmichaud if it can be cleanly done with a single gather/take,, then that'd be fine with me.
I'll be glad to review the code when it's ready. :)
colomon :)
At the moment, I'm still trying to get rid of the fossil infix:<...> we had sitting around confusing matters. 17:12
17:12 thebird left
pmichaud yes. 17:12
colomon ack. 17:14
the fix for 4 ... ^5 was only ever added to the fossil one. so...
rakudo: say ~(4 ... ^5) 17:15
p6eval rakudo 17e43e: OUTPUT«4 3 2 1 0 1 2 3 4␤»
colomon rakudo: say ~(4, 3 ... ^5)
p6eval rakudo 17e43e: OUTPUT«4 3 2 1␤»
dalek kudo: 7df145b | jimmy++ | src/core/metaops.pm:
removed unused code
kudo: 1cfec1c | moritz++ | src/Perl6/Actions.pm:
Merge branch 'master' of github.com:rakudo/rakudo
pmichaud 7df145b might not be safe. 17:16
colomon pmichaud: nah, it should be good. 17:17
17:17 SmokeMachine left
colomon unless &op somehow returns $b directly? 17:17
pmichaud right.
some ops could do that.
colomon in which case the code was wrong anyway.
ah.
pmichaud: can you fix that one? I'm knee-deep in series... 17:20
pmichaud it can stand for now... we just might get bitten by it at some point.
ciphertext colomon, pmichaud: new patch: nopaste.snit.ch/21333 17:21
pmichaud also, I prefer the new version, and assuming we fix &take, it'd be okay.
17:21 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
ciphertext i haven't tested it much yet 17:21
colomon ciphertext: I'm very confused how this patch is supposed to work? 17:22
and I'm fairly certain scmp is the wrong approach.
17:23 REPLeffect joined
colomon ah, I see the single char version now. That's sensible. 17:23
ciphertext re: scmp... i'm not particularly fond of it either, but i don't know of another way to make sure that 'Z' comes before 'AA', for example. 17:26
colomon if you look at the Spec, there are very specific rules for handling those cases, none of which involve comparing string lengths. 17:27
pmichaud the spec has eliminated string length from the equation altogether. 17:28
(other than the 1-character endpoint case)
so if you're relying on length for something... it's probably wrong.
also, is &infix:<scmp> a part of the spec? 17:29
if no, then it may need removal.
ciphertext no. scmp isn't spec. I tried to hide it using moritz_ {my sub &infix:scmp() ... our sub &infix<...> ... }, but it wouldn't compile... right now, however, I think i get how to do without scmp 17:32
pmichaud right
it looks to me like the spec simply uses before, after, and eq
ciphertext related to the single character case:
rakudo: say 'ü'.chars 17:33
p6eval rakudo 17e43e: OUTPUT«1␤»
ciphertext ... well i got '2' on my system
moritz_ on the REPL?
pmichaud some repls don't read utf-8 properly.
moritz_ don't trust it in Unicode questions
pmichaud to test it you really have to put it in a file and test it.
ciphertext ok. i'll try that.
moritz_ mine for example
Tene ciphertext: why don't you just use a function instead of defining an operator? 17:34
moritz_ is there an easy for that?
pmichaud or even a my sub within &infix:<...>
17:34 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
Tene right. 17:34
pmichaud anyway, I'm speculating that "scmp" isn't needed at all.
ciphertext k, in a file, 'ü' works correctly. 17:35
colomon rakudo: my $a = *; say $a ~~ Whatever; say $a.list ~~ Whatever 17:37
p6eval rakudo 17e43e: OUTPUT«0␤0␤»
colomon rakudo: my $a = *; say $a.WHAT
p6eval rakudo 17e43e: OUTPUT«Any()␤»
colomon er?
rakudo
pmichaud rakudo: say (my $a = *).WHAT 17:38
p6eval rakudo 17e43e: OUTPUT«Block()␤»
pmichaud uh oh.
moritz_ that's a weird and reported bug
pmichaud or is that supposed to be turned into a whatever block? ;-)
colomon rakudo: sub tellme($a) { say $a.WHAT; }; tellme(*);
p6eval rakudo 17e43e: OUTPUT«Whatever()␤»
pmichaud it's not wierd, it's just currying &infix:<=>
*weird
colomon rakudo: sub tellme($a) { say $a.WHAT; say $a ~~ Whatever; say $a.list ~~ Whatever }; tellme(*);
p6eval rakudo 17e43e: OUTPUT«Whatever()␤1␤0␤»
pmichaud the question is whether it should be doing that.
colomon surely not? 17:39
rakudo: sub tellme($a) { say $a.WHAT; say $a ~~ Whatever; say $a.list.perl }; tellme(*);
p6eval rakudo 17e43e: OUTPUT«Whatever()␤1␤{ ... }␤»
colomon rakudo: sub tellme($a) { say $a.WHAT; say $a ~~ Whatever; say $a.list.WHAT }; tellme(*);
p6eval rakudo 17e43e: OUTPUT«Whatever()␤1␤Block()␤»
pmichaud colomon: note that binding isn't the same as assignment.
colomon $a.list shouldn't turn into a block either, should it?
pmichaud $a.list would seem to be the same as *.list in that case. 17:40
moritz_ why not?
pmichaud and *.list is definitely a block.
unless whatever-currying is purely syntactic.
colomon I definitely thought whatever-currying was purely syntactic. 17:41
pmichaud discussed at irclog.perlgeek.de/perl6/2010-05-26#i_2371899 17:42
alester hey, moritz_, did you see try.rakudo.org has propagated? 17:44
moritz_ alester: yes
alester I also set up ponie.rakudo.org, too, per your request.
moritz_ alester: I haven't got much further than architectural planning though 17:45
17:45 SmokeMachine joined
jnthn colomon, pmichaud: I know * + 42 is syntacticly transformed. I was under the impression *.foo could happen at runtime though. It certainly currently does in Rakudo. We can change it if needed. 17:45
It'd be a win in some senses to do so. 17:46
sorear std: 1
p6eval std 31325: OUTPUT«ok 00:01 104m␤»
alester so, if anyone wants a ponie, rakudo.org will give it to them. 17:47
17:47 patspam1 joined, patspam left, patspam1 is now known as patspam 17:48 patspam1 joined
colomon feels like he's stepped through the looking glass, where his simple attempt to eliminate what should be dead code has lead to nightmares... 17:48
17:50 ShaneC joined
pmichaud finds a nice big fat juicy bug to fix. 17:50
17:50 ShaneC left
pmichaud (with a 1-line fix) 17:50
sorear pmichaud: see CursorBase.pmc lines 2140-2198 in the current svn; that's the general cross-grammar lexer sharer 17:51
17:51 xabbu42 left, xabbu42 joined
cognominal jnthn, the stuff on Whatever is indeed strange (*)(1) (*+*)(1,2) (*+*+*)(1,2,3) # only the second works :) 17:52
...last time I tried 17:53
17:54 patspam1 left
pmichaud in the first one, (*) is a term, not a block. 17:56
cognominal indeed :)
17:58 Trashlord left
cognominal rakudo *(1).signature.perl 17:58
rakudo: *(1).signature.perl
p6eval rakudo 17e43e: ( no output )
17:58 REPLeffect left
cognominal rakudo: say *(1).signature.perl 17:59
p6eval rakudo 17e43e: OUTPUT«:(;; Mu $x)␤»
17:59 Trashlord joined
pmichaud does anyone have a command-line tool they like to use for nopastes? 18:06
dalek kudo: 7a230d9 | pmichaud++ | docs/spectest-progress.csv:
spectest-progress update through 06-14; still waiting on later dates to be
18:07
PerlJam pmichaud: App::Nopaste? (not a favorite, just one I know of via Padre::Plugin::Nopaste) 18:10
I typically use it from Padre if I use it. 18:11
pmichaud I installed App::Nopaste, and it's totally deficient in documentation.
So I have no idea how to actually use it.
18:11 REPLeffect joined
lue why o hai o/ 18:11
PerlJam If you used padre, it would be a Ctrl+Shift+V away ;) 18:13
pmichaud if I can find out how App::Nopaste works, I can also make it Ctrl+Shift+V away. Globally.
hmmm, my bug fix appears to break .trans 18:14
I'll wait until after the release to apply the fix. 18:15
(and let someone else figure out how to fix .trans :)
Tene pmichaud: I use the script in the parrot repo 18:17
tools/dev/nopaste.pl iirc 18:18
18:18 stephenlb joined
lue thinks maybe RT will provide something to work on. 18:18
PerlJam pmichaud: nopaste filename # it outputs the URL where filename was pasted 18:20
pmichaud aha
colomon okay, think I've got a somewhat cleaned up series with the single-character endpoints case working. spectesting... 18:22
PerlJam pmichaud: nopaste -s Gist filename # paste to gist.github.com
18:22 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
pmichaud PerlJam: awesome 18:22
thanks
now I can set up hotkeys for my nopasting
lue I'm still wondering about custom circumfix operators. I'm afraid, however, that it's out of my depth w/o reading a lot :/ 18:23
pmichaud firefox $(xclip -o | nopaste -s Gist) # niiiiiice 18:24
18:33 Mowah left
arnsholt Hmm. Working with arrays and Rakudo is a bit fiddly =/ 18:40
pmichaud it should be less fiddly now, though. 18:44
if it still has some fiddly areas, we can fix them. :)
18:44 xabbu42 left, xabbu42 joined
lue I'm considering working on Rakudo's binding. 18:45
pmichaud binding should be relatively easy now.
lue [:= of course]
pmichaud first, type-check that the value you're binding to matches the type requirements of the container 18:46
if yes, then change the container (the one you're binding) to be an ObjectRef pointing to the thing you're binding.
lue i.e my Int $a := $b can't work if $b is 3.5 [?]
pmichaud correct 18:47
anyway, that handles binding to a first approximation
for a complete binding implementation, we also have to rebind the symbol in the lexpad, but that's Hard at the moment. 18:48
(or we have to go with yet another level of indirection.... but I'm not really in favor of doing that.) 18:49
lue attempts, by first finding the place where assignment works.
pmichaud assignment is good background, but note that it's in fact very different 18:50
18:50 REPLeffect left
lue I know, it might give me insight to how variables are created though. 18:51
arnsholt pmichaud: The main fiddlyness comes from lack of auto-vivification
pmichaud well, I'd start with scalars only to begin with.
arnsholt: I expect to fix that tomorrow.
(I'd do it today, but I don't want to mess with a release.)
18:51 REPLeffect joined
arnsholt Oooh. That would be awesome 18:51
pmichaud I figured out how to implement it cleanly last night.
(given the other refactors that I was able to do in the list branch) 18:52
lue: I'd start with scalars
18:52 xabbu42 left, xabbu42 joined
pmichaud lue: leave array and hash binding for later (although it's basically the same thing) 18:52
lue: the way that scalar variables work is that they are a Perl6Scalar PMC that holds a reference to a value 18:53
whenever we do an assignment, we change the reference to instead point to the new value
the main difference between assignment and binding whether or not the value itself is a reference 18:54
for assignment, we strip off any references, such that the scalar points directly to the value
for binding, we keep the references, so that the scalar points to a reference to the value
lue In essence, make two variables point to the same PMC, if I'm getting this right. 18:55
pmichaud well, let's consider an example
my $x = 3;
creates a Perl6Scalar, binds the symbol $x to it, and after assignment we have the Perl6Scalar pointing to a PMC containing the value 3 18:56
if we then do $y = $x
that translates into &infix:<=>($y, $x)
this actually receives references to the containers $y and $x 18:57
so, in the simplest case (this one), we make sure that whatever is in $x matches any type constraint attached to the container $y
we also check to see if $y is readonly
throw an exception if needed 18:58
once we decide the assignment can proceed, we dereference $x to get to is underlying value (the PMC holding 3)
and we set $y to also reference that underlying value
okay so far? 18:59
lue in the process this creates another Perl6Scalar for $y, correct?
which also contains 3
pmichaud well, the Perl6Scalar for $y gets created at the "my" step.
it's more like
(my $x) = 3; (my $y) = $x; 19:00
i.e., the "my" creates the Perl6Scalar, the &infix:<=> sets its value
lue ah, ok.
pmichaud assignment doesn't create any new objects, it just manages references to existing ones
well, I should say that item assignment doesn't create any new objects 19:01
(although itemizing the rhs may result in a new object being created... but this is not important for this at the moment.)
so, binding is exactly the same
(my $x) = 3; (my $y) := $x; 19:02
*except*
lue So, for binding, you change $y into an object that can hold a reference, or rather, point to one.
pmichaud $y is already an object that holds a reference
what changes is that we now reference another reference, instead of the value directly.
in other words, instead of dereferencing $x to get to its underlying value, we simply set $y to point directly at $x 19:03
now then, in the case where we're assigning to a container that is referencing another reference, we delegate the assignment to the thing it's referencing
(but we still perform read-only and type checks for all of the references in the chain before doing this) 19:04
so, if we imagine that we have $y := $x and $z := $y
we end up with a chain that looks like $z -> $y -> $x -> value 19:05
if we assign a value to $z, then it delegates the assignment to $y which delegates to $x, and it's $x's value that ultimately changes
lue would infix:<=> have to change then, to accomodate that, or is it already taken care of?
pmichaud it's already somewhat taken care of
dalek kudo: fdb5ca4 | (Solomon Foster)++ | src/core/operators.pm:
Unify the infix:<...>($lhs, $rhs) case with the main infix:<...> code. Add
19:06
pmichaud i.e., infix:<=> already knows that it has to follow the chain of references and change the last one.
It has to know to do this, because this is exactly how parameter-binding works.
lue Ah. So that would explain my ($a is rw) = $b working somewhat like := :) 19:07
pmichaud now then, the thing this model doesn't yet handle is the case where we rebind a variable that has itself been bound to
e.g. $b := $a; $a := $x; 19:08
with this model in place, $b would end up pointing through $a to $x, which is wrong
lue would it then be where $b := $x , or...
pmichaud so, what I'm hoping to be able to do is to find a way to leave the existing $a Perl6Scalar alone, and rebind the symbol "$a" to a new Perl6Scalar that then is bound to $x 19:09
lue in effect creating two $a variables [?] 19:10
pmichaud well, the old one would no longer be associated with the symbol '$a'
it would just be anonymous
lue It seems to be a very interesting programming scenario when you do $a := $b and then $b := $c . 19:11
pmichaud right
anyway, I'm not worrying about that case just yet. It's not common enough to worry about for me.
so, the simple binding is good enough for now, and ought to handle most of what we want done.
lue so, := eq = in terms of type checking and rw, but then the actual operation gets very different. 19:12
pmichaud the main difference being how the source and target containers get dereferenced 19:13
for assignment, we dereference the source all the way down to its last reference, and dereference the target all the way down to its value
for binding, we don't do any dereferencing of either source or target
lue pmichaud++ for explaining. Any further questions that come up I'll be sure to ask. 19:14
pmichaud sure thing
also, I plan to do some more major refactoring of variables in the next two days
lue
.oO(Perl6: Where you learn how everything from classes to = works)
pmichaud so, you'll be chasing a bit of a moving target
(the refactor will clean up the terms a bit, as well as resolve autovivification of hashes/arrays)
lue Good, we need to cut our dependence on foreign code! [the Foreign Code of course being… 19:15
…PMC]
19:15 xabbu42 left
lue That is one eventual goal, right? 19:15
pmichaud well, we hope to be able to abstract to multiple backends 19:16
but I think the basic model I described above is going to be pretty common
it somewhat has to be that way in order to preserve type constraint and rw characteristics. (there are some places where you can collapse chains of references for efficiency, but the conceptual model remains the same)
TimToady jnthn: *.foo(bar()) must be syntactic, or bar gets called too early 19:17
lue pmichaud: I'd be lucky to finish in time to get messed up by your refactoring :D 19:18
pmichaud TimToady: I'm planning to propose a Hague Grant to rewrite S07, S08, and update the rest of the synopses for the list/iterator stuff. Any comments/objections?
(as well as document Rakudo's internals and flesh out a few other things dealing with lists, iterators, and parcels)
lue
.oO(\o/ for API)
 19:19
jnthn TimToady: Ah.
TimToady: Thanks for clarification.
Will get to it at some point hopefully soonish. :-)
TimToady pmichaud: that seems fine to me, but then typeglobs seemed fine to me at the time...
pmichaud lol 19:20
jnthn TimToady: Can I also assume that my $x = *; $x.foo # does not need to auto-curry?
TimToady I don't think people will expect = to autocurry
jnthn TimToady: no no
I meant if I have a variable with a Whatever in it
And I do a method invocation on that variable.
pmichaud fwiw, $x = * is currently autocurrying in Rakudo. :)
jnthn lol
I accidentally the curry. 19:21
pmichaud rakudo: say (my $x = *).WHAT
p6eval rakudo 7a230d: OUTPUT«Block()␤»
jnthn heh
pmichaud I agree it's unexpected.
lue
.oO(The apathy variable)
jnthn Yeah, we should probably not do it for that, or binding. :-)
TimToady I can argue late currying either way
jnthn TimToady: Thing is, it's a huge pain to do late currying for the * + 1 case 19:22
That's why we made it syntactic, iirc.
I'd prefer consistency between the two.
pmichaud I think we agree that it needs to be syntactic
(at least, I do.)
jnthn pmichaud: Sure, my question is if you have a Whatever in $x and do a method call on $x, what happens.
pmichaud oh, I could go either way on that also. :) 19:23
jnthn pmichaud: Because it lets me rip a bunch of code out of the dispatcher if we go purely syntactic.
lue So, := does not dereference AT ALL (.|?)
pmichaud lue: only for optimization purposes, but conceptually, no.
lue: if we have
my Int $a; my $b := $a; then $b needs to retain $a's constraint. 19:24
TimToady why would there be code in the dispatcher anyway? seems like late Whatever would work more like junctions and just fall out of normal dispatch rules
pmichaud and if $b binds to something that is readonly, then $b also needs to act read-only
lue ah, well of course. In that case, would $b inheret this from $a's Perl6Scalar, or does it need to be explicitly read and set? 19:25
TimToady I'm not sure binding always adds an indirection
pmichaud TimToady: so far it's the only consistent model I've found. I could be argued out of it.
jnthn TimToady: For a bunch of reasons, it doesn't.
TimToady: Anyway, I'd prefer if we could make it purely syntactic. 19:26
TimToady well, you could have a flat model if proxying were separate from references
pmichaud lue: I don't like to say it "inherits" these behaviors -- rather that it just accumulates the behaviors of the thing it references
...proxying?
jnthn TimToady: If anything because $x + 1 where $x is a Whatever won't auto-curry.
lue it collects, then :) 19:27
pmichaud lue: or delegates
lue So, in $a := $b, $a always says, "just look at $b, and that's me too." [?] 19:28
19:28 chitragupt joined
pmichaud lue: mostly 19:28
TimToady lue: and that's what I'm carping about 19:29
pmichaud $a says "here are my constraints, and obtw you need to match $b's constraints too"
TimToady that's proxying, not referencing
pmichaud okay, then that's what I'm thinking of doing :-)
lue
.oO(maybe waiting for variable refactor can save valuable key-hours (those keyboard keys do wear out))
pmichaud or that's effectively what we're doing.
yes, I agree we can do without chains of indirections 19:31
TimToady it feels like a Big Mistake to me
lue methinks it'd be very brilliant if someone managed to write assignment in P6 as opposed PIR…
alester Hey, people using perl6.vim, are you seeing what's described here? github.com/petdance/vim-perl/issues#issue/26
lue [w/o inline PIR of course, that's just cheating]
pmichaud TimToady: or, are you thinking that constraints are temporary?
i.e., when I do 19:32
my Int $b := $a;
that adds a constraint to $a preventing it from becoming anything but an Int, for as long as $b is bound to the proxy?
(and actually not to $a itself, but to the proxy that $a references...)
TimToady I think it only checks the constraint when bound, and if you modify the type of $a out-of-band, it's probably just erroneous 19:33
pmichaud so...
TimToady but readonly still needs proxying, I suspect 19:34
pmichaud sub foo(Int $b) { $a = 'hello'; }; my $a = 3; foo($a); # what happens?
sorry, put my $a before foo
my $a = 3; sub foo(Int $b) { $a = 'hello'; }; foo($a);
does $a inside of foo() "see" $b's constraint? 19:35
19:35 plainhao left
jnthn TimToady: Ah, the reason it doesn't fall out of failover just like junctions is because Whatever is Any, and we may want to *.some-method-in-any and have it curried. 19:35
pmichaud
.oO(does Whatever have to be Any?)
TimToady if *.foo is syntactic, then we could move Whatever out of Any 19:36
pmichaud I had been provisionally working from a model where constraints are based primarily on the variable used to access a value.
so in the above, $a = 'hello' ends up being allowed, because we got to the proxy via $a. 19:37
TimToady there's something here going on very much like "which thread owns this object"
pmichaud and $b might later carp about "hey, where's my Int?"
and, in particular, even though $b is readonly, $a is not. 19:38
19:39 slavik left
lue And to think, when I thought about fixing := the first time, I wanted to change the .WHERE of variables... 19:40
pmichaud anyway, the model I described above is really "provisional" until there are some clearer test cases.
and I think it's workable to a first approximation for now.
I agree that chains-of-indirections feels like Big Mistake; but I know that it's very optimizable
TimToady I think of constraints as gatekeepers, and we can't keep people from climbing the walls without a great number of guards, who have finanical and/or cultural overhead 19:41
19:41 macdaddy left
pmichaud TimToady: that sounds to me like $a = 'hello' above would be allowed 19:41
TimToady I don't see us dynamically altering the type of the $a container 19:42
pmichaud okay, good.
TimToady that way lies madness
19:42 slavik joined
pmichaud I agree. 19:42
anyway, I'm fine with variable -> proxy -> value
TimToady and "Int" doesn't even say it has to be an int, only that $b has to support Int, and the actual type of $a may well also support Str 19:43
arnsholt alester: You don't get that behaviour? Weeird
alester ooh wait
arnsholt I'm on OS X 10.6, vim 7.2.108, if it matters
pmichaud I think of type constraint as "if you bind or assign to this variable/container, you must first meet these constraints"
19:43 am0c joined
pmichaud not "I guarantee to enforce this constraint at all times" 19:44
lue pmichaud: hopefully the variable refactor will end up being Better Than Before :)
alester ok, I do get it. I now understand.
pmichaud lue: of course, otherwise, why refactor? ;-)
lue Clearer Than Before is another one :)
.oO(An Actual API would be wunderbar!)
TimToady hmm, for assignment, it's almost more like, try assigning this, and then see if the resulting object is still consistent with the constraint, and if so, commit the transaction, otherwise rollback 19:45
pmichaud TimToady: that works also.
I agree that's a better phrasing and model than what I described.
TimToady but higher overhead in the general case
arnsholt alester: Ah, good. Also, I feel that there should be a better way to solve the issue, but I'm not sure how
alester arnsholt: can you please paste your line 760 here in the channel?
the whole line 19:46
arnsholt syn match p6RegexName display "\%(\<\%(regex\|rule\|token\)\@<!\%([$%@&].\)\s\+\)\@<=\K\%(\k\|[-']\K\@=\)*" nextgroup=p6RegexBlockCrap skipwhite skipempty
alester and as to submitting patches on Github, the typical way is to fork the project, commit your change, and then send a pull request
19:46 pronik``` joined
arnsholt Ah, of course. Another one for the "this is how you do it in git" book 19:47
pmichaud I still find github's "fork queue" for pull requests totally unusable.
19:47 bbkr left
alester pmichaud: it works for me, but then again, I don't have nearly the number of pull requests I'm sure you do. 19:47
19:47 bbkr joined
lue thinks of gitorious. KDE uses it! 19:47
pmichaud I end up with screenfuls of red-lined commits that all say "will not apply cleanly". 19:48
jnthn pmichaud: I did use it for one person's patches at the weekend hackathon.
TimToady pmichaud: otoh, the whole notion of inheritance is based on multiple levels of delegation, so maybe there's some unity lurking in the multilevel idea
jnthn pmichaud: Mostly because they were sat next to me and I'd watched them run the spectests. ;-)
pmichaud jnthn: you used the fork queue interface on the web? 19:49
TimToady pmichaud: maybe we can think about it and find some time to talk next week
lue frankly, I'm still sort of wondering about the difference btwn fork and branch [on git, not in Real Life :)]
jnthn pmichaud: Yes
pmichaud jnthn: in the rakudo account?
jnthn pmichaud: Yes
pmichaud oh, can all committers see that?
19:49 ggoebel left
pmichaud that's an improvement. 19:49
jnthn pmichaud: fwiw, I see some green, some red.
pmichaud: I think it's a "get 'em while they're hot" situation though. 19:50
pmichaud jnthn: yeah
lue Are forks a normal part of git?
alester arnsholt: Porbably the better fix is to not recognize rule, regex or token if they are preceded by a sigil or twigil.
pmichaud forks are normal in git, yes.
alester "fork" doesn't mean what you probably think it imeans.
Think of it like "branching the entire repo"
jnthn pmichaud: Anyway, it's not convenient for me in general for patches because I like to know they past spectest for myself before I commit.
lue well, that leaves me wondering what the diff. between branch and fork is.
pmichaud jnthn: same here.
jnthn pmichaud: But it was kinda nice in a hackathon situation.
alester branch means branch 19:51
jnthn That's about the first time I've used it in months though.
pmichaud lue: branch creates a copy within your repository
TimToady pmichaud: and just because something feels like a Big Mistake doesn't mean it is one...that's how disruptive technologies arise, by making what seems like a big mistake...
alester fork means "I'm making my own copy of the entire repo"
19:51 ggoebel joined
pmichaud lue: fork means create a copy *of* a repository, all branches 19:51
lue: it's essentially "git clone"
but I think github uses "fork" because they get to use a new word and a bunch of double entendres
alester Remember that "fork" is only meaningful on github.
lue Then, unless I somehow need to, I see no point in forking when I already have a clone of the repo. 19:52
pmichaud TimToady: (disruptive technologies) agreed
alester oops, meeting, brb 19:53
pmichaud lue: github's model is that you clone the repo on github, then clone a local working copy from there
lue: you then work with your local copy as much as you want, pushing things up to your github repo as appropriate
when you have something ready for the master repo, you issue a "pull request" from your github repo
and the master repo on github can then pull your commits from github directly 19:54
(while you continue to work locally)
lue Hm, not sure I like the sound of that model. [Ah well, I'm not a master of version control systems. I'm pretty sure there is a really good reason somewhere]
pmichaud lue: well, I'm not a fan of it either, which is why rakudo doesn't make much use of pull requests :)
lue is tempted to go to gitorious to see the difference. 19:55
pmichaud I still find applying a patch file and testing to be easier than trying to cherry-pick and pull things from repos.
although pulling branches from remote repos (on github or elsewhere) also seems to work pretty nicely.
okay, time for me to bug fix and write 19:56
19:56 pmurias joined
pmurias ruoso: hi 19:56
pmichaud (still here, but in other windows)
pugssvn r31333 | pmurias++ | [smop] mildew is used by tools/ri instead of the haskell m0ld
dalek kudo: 2be1d04 | (Solomon Foster)++ | src/core/operators.pm:
Handle the infix:<@lhs, @rhs> case we forgot about last time.
 19:57
pugssvn r31334 | colomon++ | [t/spec] Unfudge series / Range tests Rakudo now passes, and add a few more tests in those areas.
colomon TimToady: is 'ZZ' ... 'A' expected to be a finite list? 19:58
lue is examining the feature lists of github & gitorious out of curiousity
arnsholt colomon: For consistency it should be the same as 3 ... 1, no? 19:59
colomon arnsholt: nope.
or at least, at a low level, they are quite different operations. 20:00
pmichaud colomon: what comes next after 'AC', 'AB', 'AA', ...
?
colomon rakudo: 'AA'.prec
p6eval rakudo 7a230d: OUTPUT«Method 'prec' not found for invocant of class 'Str'␤ in main program body at line 11:/tmp/OTApycdzxD␤»
colomon rakudo: 'AA'.pred
pmichaud I think that the predecessor to 'AA' ends up being an exception.
p6eval rakudo 7a230d: ( no output )
pmichaud or a Failure object of some kind
20:01 ggoebel left
jnthn rakudo: say 'AA'.pred 20:01
p6eval rakudo 7a230d: ( no output )
pmichaud > say 'AA'.pred
===SORRY!===
Decrement out of range
can probably make that a soft-fail.
colomon that's the very message.
arnsholt Oh. But 'Z'.succ is 'AA', isn't it?
pmichaud yes
.succ can add characters, but .pred doesn't (yet?) take them away
20:02 REPLeffect left
pmichaud it would be hard to know what comes before 'A0', for example. 20:02
20:02 ggoebel joined
pmichaud colomon: at first glance, I'd be fine with the series terminating at AA 20:02
arnsholt Good point
20:03 REPLeffect joined
pmichaud i.e., the next value in sequence is at least undefined, and so terminates the sequence (or something like that) 20:03
lue afk 20:04
pmichaud and a good compiler could/should warn when something odd like that is taking place
i.e., if it's a decrementing range of strings, make sure the ending string has the same form and length as the starting one.
colomon so (generalizing) if the code block which generates the next item in the series generates a fail, the series ends?
20:04 Psyche^ joined
pmichaud I dunno... does the spec say anything about udnefs? 20:05
TimToady I believe current spec says there's nothing before AA
20:06 patrickas joined, silug joined
colomon ooo, I think terminating is the right thing to do. 20:06
(I mean, terminating the series)>
pmichaud for a terminating closure, the series terminates on a false value
(from the closure, that is) 20:07
colomon Right, but this is the generating closure.
pmichaud it doesn't seem to say anything about values from the generating closure
colomon I think if it fails, the series should terminate.
it will make Wed ... * terminate, right?
20:08 Patterner left, Psyche^ is now known as Patterner
pmichaud well, I'm not sure "terminate on the first failure" is exactly right. 20:08
colomon (or is Sun.succ Sun again?)
cognominal Depending on the Oracle?
pmichaud rakudo: say Mu before 'AA'
p6eval rakudo 7a230d: OUTPUT«No applicable candidates found to dispatch to for 'infix:<before>'. Available candidates are:␤:()␤:(Any $a, Any $b)␤␤ in main program body at line 11:/tmp/nqRVMd7lbl␤»
20:09 ash__ left
pmichaud rakudo: say Any before 'AA' 20:09
p6eval rakudo 7a230d: OUTPUT«0␤»
pmichaud rakudo: say Any after 'AA'
p6eval rakudo 7a230d: OUTPUT«1␤»
pmichaud huh.
I guess it stringified to "Any()" or somesuch. :-)
colomon pmichaud: yes, Any()
pmichaud rakudo: say Any before 'BB'
p6eval rakudo 7a230d: OUTPUT«1␤»
pmichaud anyway, if failure ended up being treated as '', then it would clearly be before 'AA' (or any other string other than the empty string) and the series would naturally terminate :-) 20:10
(and it might throw a useful warning, too) 20:11
I'm thinking that 'AA'.pred should &fail instead of &die.
colomon I really think terminate series on Failure is the Right Thing.
rakudo: say 'AA'.pred.WHAT
p6eval rakudo 7a230d: OUTPUT«Failure()␤»
pmichaud oh, it's already doing that. :-)
colomon: I can imagine series where failures are reasonable within the series. 20:12
otoh, perhaps the closure should make that explicit in that case
so, we could default to "failure terminates, use an explicit closure somehow if you want failure to be part of the series" 20:13
or
"failure doesn't terminate, use a closure if you want it to do so"
the latter seems far far easier on the programmer.
colomon If the user doesn't provide an explicit generating closure, no Failure is every going to lead to anything other than an infinite series of Failures. 20:14
(unless we terminate on the first Failure, I mean)
pmichaud not true -- the case I gave above ('ZZ' .. 'A') would naturally terminate. :-) 20:15
TimToady S03:518 specs that 'aaa' and '000' don't decrement
colomon pmichaud: no it wouldn't
pmichaud colomon: ummm, why not?
colomon unless Failure.pred doesn't generate a Failure?
pmichaud Failure ends up being before 'A' 20:16
so its beyond the endpoint
TimToady before AA by S03:518
pmichaud and the series stop.
(since this is a decrementing series, we reverse the test on the endpoint)
TimToady it doesn't do AA -> Z
so never gets to A 20:17
20:17 pronik``` is now known as pronik
pmichaud with 'AA' ... 'Z' we'd fail immediately after 'AA', yes? 20:17
TimToady by current spec, yes
colomon no, because that's an increasing series
pmichaud colomon: it is? hrm.
TimToady er, yeah
colomon absolutely is.
20:18 masak joined
masak ahojte! 20:18
colomon 'AA' is before 'Z', so we do .succ as the generator.
pmichaud then it's infinite, and we never see a failure.
masak let's go into Release Mode for real here. :)
pmichaud so failure doesn't come into the picture.
colomon it's not infinite, either.
TimToady eh?
20:18 Chillance joined
pmichaud oh, I guess it stops at ZA 20:18
since 'ZA' after 'Z'
either way, failure isnt a problem there. 20:19
colomon stops at YZ, actually.
jnthn masak! :-)
masak :)
pmichaud right, last element produced is YZ
TimToady I think series on alphas should probably only stop on exact match
colomon right.
TimToady: aiigh, no!
[particle] nfg exact? 20:20
pmichaud at any rate, we still don't have the case of "failure leading to anything other than infinite series of failures"
jnthn masak: I read your blog post and couldn't help but thing of some of Visual Studio's "Generate From Usage" features.
*think
pmichaud i.e., we still don't have an instance where we need to do something special to terminate on generating a failure.
jnthn masak: Where you can write code that instantiates classes and calls methods on them, and then take the code and have the stub classes/methods generated for you.
colomon pmichaud: you keep saying that, but I don't think you're right. 20:21
pmichaud colomon: feel free to provide a counter example. :)
colomon at least, we're not terminating on Failure now, and every other case seems to work fine.
pmichaud colomon: my point is that having a failure show up in an automatically-generated sequence is pretty rare
masak jnthn: that sounds like a blessing-and-a-curse feature. :)
jnthn: I actually quite enjoy doing it by hand, and by-need.
pmichaud and the only one we can come up with (decrementing strings), does a reasonable thing by default.
masak jnthn: the error messages guide me on, in a way. 20:22
pmichaud so, that goes back to my point, which is that if we terminate a series on Failure by default, then it becomes hard for a generator to create a series with a Failure in it
but if we allow a series to continue by default, it's pretty easy to provide a closure that can terminate the series when a Failure occurs.
jnthn masak: Aye...of course, you can run code in a dynamic language without having a bunch of stuff implemented, whereas same wouldn't even compile in a static one. :-)
TimToady so why are we returning Failure rather than Nil? 20:23
pmichaud TimToady: currently rakudo has 'AA'.pred returning a Failure
we can change that to Nil if the spec so indicates (haven't checked recent spec on this)
TimToady return $x.pred // Nil;
pmichaud sure, that works
colomon huh. 20:24
pmichaud but I think that's a part of the generator, not part of the series logic.
i.e., the generator sees a failure and returns Nil to stop the series.
not that the series sees a failure being generated and thus stops.
colomon well, it appears I have been chasing after the wrong problem here.
TimToady: think of the case of enums, please.
20:24 tadzik joined
colomon if we get this right, I think we will handle them automatically... 20:25
what I actually get: if I do say 'ZZ' ... 'A', everything works and it stops on 'AA'
If I do say ('ZZ' ... 'A').elems, I get "Decrement out of range"
ruoso pmurias, hi
pmichaud colomon: TimToady is suggesting to use $x.pred // Nil as your generator there 20:26
that will prevent the Decrement out of range
(by converting it to a Nil)
20:26 masak left
colomon really? 20:26
pmichaud since Failures are undefined, yes. 20:27
colomon can you explain why I get the Decrement out of range?
is Failure actually the last element of the series?
pmichaud 'AA'.pred returns a Failure object
if you attempt to do anything with that Failure object other than test it for definedness or truth, it throws its exception
rakudo: say 'AA'.pred 20:28
p6eval rakudo 7a230d: ( no output )
pmichaud rakudo: say 'AA'.pred // 'hello'
p6eval rakudo 7a230d: OUTPUT«hello␤»
pmichaud this is the basics of how Failures work in Perl 6 :-)
colomon will switching it to Nil do the right thing, though?
pmichaud I think that returning Nil from a generator terminates the sequence 20:29
(can't seem to find that point in the spec atm)
colomon you mean, terminates the series?
TimToady what is this "generator" of which you speak?
do you mean List or iterator?
pmichaud in a series like 'ZZ' .. 'AA', we can have a closure that does { $^x.pred } as a generating sequence 20:30
i.e., something like
'ZZ', { $^x.pred } .. 'AA'
(sorry, three dots)
20:30 silug left
pmichaud 'ZZ', { $^x.pred } ... 'AA' 20:30
colomon is concerned that with
'ZZ', { $^x.pred } ... 'A' 20:31
TimToady then whatever is calling that needs to check for definedness
pmichaud we end up with an exception after generating 'AA's predecessor
I'm saying that if he instead generated the sequence as
'ZZ', { $^x.pred // Nil } ... 'A'
TimToady $generator() // last 20:32
pmichaud then &infix:<...> doesn't need the definedness check.
colomon but will it need a Nil check?
pmichaud I'm fine if &infix:<...> does check for defined elements, but that means it can't really be used to create sequences containing failures
TimToady Nil is probably a bad sentinal
pmichaud (which is okay by me, but I could imagine some classes of generating closures where that might be desirable)
colomon rakudo: say 'aa' cmp Nil 20:33
p6eval rakudo 7a230d: OUTPUT«1␤»
pmichaud we could resurrect EMPTY :-)
TimToady and in fact we already have specced something that returns an infinite series of Nils
I think we should just require definedness
pmichaud okay, then colomon++ is right :-)
TimToady $generator() // last
20:34 ive joined
colomon we're locked down for release, right? 20:34
TimToady gather loop { take $generator(|@someargs) // last }
or some such 20:35
pmichaud I don't know about "locked down", but I'd avoid any major semantic changing commits
colomon TimToady: it's a lot more complicated than that. :)
TimToady yes, it's pseudocode :)
colomon but the // last is easy to add. TimToady++
20:35 silug joined
TimToady it's a conservative approximation that will work until the time that we want serieses with undefined values :) 20:36
colomon well, the good news here is series works for single-char arguments now, and seems to mostly do the right thing with other strings.
excepting the case where we need // last added. :) 20:37
moritz_ maybe the // needs to become an exception-aware operator one day (orelse?)
pmichaud TimToady: I buy that form of conservatism as well. 20:38
masak: I just updated spectest-progress.csv in master
colomon TimToady++ # it's not as if any previous definition of series has lasted longer than a week! ;)
TimToady and at that point we can switch to pure iterators
20:38 ive left
dalek kudo: af53808 | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 489 files, 33280 (83.4% of 39887) pass, 37 fail
 20:38
pmichaud note however that the number of tests reported there is *before* the branch merge
TimToady and for pure iterators, Nil really does mean "no more iterators" 20:39
pmichaud (because it is the state of the repo as of 0000 CDT, or 0500 UTC, and the merge occurred around 0700 UTC)
20:39 mberends left
pmichaud afk for a bit 20:39
alester arnsholt: I have pushed my changes 20:40
arnsholt Cheers
colomon / last appears to fix this case. 20:41
/ last, sorry.
moritz_ colomon: / //
20:41 masak joined
moritz_ most IRC clients accept '/ ' to escape a leading / 20:42
masak we now return to your regularly scheduled Release Mode.
colomon ah, so I didn't make the same stupid typo twice in a row. Nice to know.
alester I just type a leading space 20:43
lue ohai 20:44
20:44 clintongormley left
masak lue: \o 20:47
lue: time to make a Rakudo release :) 20:48
colomon \o/
masak runs spectests
jnthn feeds masak with a Chicken Kiev
masak jnthn: quite full on post-swim pasta already, thank you :) 20:49
20:50 Mowah joined 20:54 Schwern left
lue :=) 20:56
diakopter /
///
pmurias diakopter: hi 20:57
Juerd 22:42 <@moritz_> most IRC clients accept '/ ' to escape a leading / 20:59
Which is sometimes implemented as an alias for /say
Which also works, in many clients
21:00 macdaddy joined
moritz_ testing 21:00
//
/say // also works
in irssi
21:01 eternaleye_ joined 21:02 eternaleye left
lue enclosing stuff in double brackets causes links to wikipedia. 21:04
pmurias masak: any progress on tote? (i just read the blog post) 21:06
masak pmurias: a commenter also asked that, as you'll note.
pmurias: I've been a bit egotistical, and not packaged what I already have (and use quite efficiently) as a Perl 6 project. 21:07
I will make amends soonish.
pugssvn r31335 | pmurias++ | [smop] store the build files in build/ instead of builddir/ 21:08
21:12 azert0x joined
masak it would seem PARROT_REVISION is set to Parrot 2.5.0. check. 21:12
21:12 macdaddy left 21:13 Mowah left
arnsholt When I've created a new branch locally, how do I push that to the remote origin? 21:13
masak arnsholt: make sure you're "in the branch", as in 'git checkout $branch' 21:14
arnsholt: then, just 'git push origin $branch'
arnsholt Ah, there we go. Thanks 21:15
masak the two instances of $branch don't have to be identical, but it's generally good for sanity if they are. :)
arnsholt Hehe
masak things in docs/ChangeLog appear in decreasing order of importance, yes? 21:16
jnthn masak: I don't know there's been a deliberate attempt to do that in the past. 21:18
masak: More that the things that make it into the announcement are the biggies.
21:19 whiteknight joined
masak aye, but ISTR that it's semi-common practice to put big changes at the top, lest reader falls asleep halfway through list. 21:19
patrickas masak: It seems chronological to me (except first line) 21:20
masak going through the git commit log now to see if we've missed something. 21:21
'.' goes on the end in @*INC now. I'll mention this, because it might impact some module authors.
21:23 xinming joined
arnsholt There. I do like git, but sometimes it makes me want to strangle someone =) 21:23
21:23 tadzik left
masak arnsholt: I don't think I've ever felt that. what's up? 21:24
arnsholt masak: Just struggled to get onto the new branch on my other computer
diakopter pmurias: hi
masak hm, Rakudo's developers still don't use --rebase enough when pulling :P
arnsholt Finally foung branch -b foo origin/foo
21:25 xinming_ left
masak arnsholt: 'git checkout -b foo origin foo' probably also works. 21:25
arnsholt Cool.
masak hm. maybe not.
arnsholt I think my main problem with git is that I've not fully assimilated the way git works into my mental model of how source control works 21:26
masak that's usually the big stumbling block.
arnsholt: read "Git From the Bottom Up". that's the biggest favour you can do yourself in terms of understanding. :)
21:28 Guest23195 left
arnsholt I really like the add/commit mechanism of git though 21:28
21:28 rv2733 left
arnsholt Working with an SVN repo at work, I went "but those changes are -local- don't wanna commit those!" today =) 21:29
21:30 skids left
masak I saw it in the commit when it arrived earlier this month, but then promptly forgot about it: github.com/rakudo/rakudo/blob/maste...ate.pm#L94 21:32
21:32 Su-Shee left
masak can that work? 21:32
if it can, I still don't understand the :: sigil.
rakudo: say ::A.foo; class A { method foo { "OH HAI" } }
p6eval rakudo 2be1d0: OUTPUT«OH HAI␤»
masak huh. 21:33
arnsholt ::Foo means that you want the Foo from the root namespace, no?
jnthn Not in Perl 6.
arnsholt Oh. Ignore me, then =)
jnthn std: say ::A.foo; class A { method foo { "OH HAI" } } # curious
p6eval std 31325: OUTPUT«ok 00:01 105m␤»
masak I honestly did not expect that to work.
the rakudo evaluation, that is.
patrickas arnsholt: that would be GLOBAL::Foo (I think) 21:34
lue .rnd(as far as I can tell, gitorious has no forks) 21:38
21:41 perlygatekeeper left 21:43 SmokeMachine left
pmurias diakopter: have you thought about rewriting perlesque in itself once it has working grammars? 21:47
dalek kudo: 736bef8 | masak++ | docs/ChangeLog:
[docs/ChangeLog] some further updates
 21:48
masak ok. spectest done. t/spec/S09-typed-arrays/arrays.rakudo still fails here.
jnthn Comment out in the spectest.data for release?
masak so does t/spec/S12-methods/submethods.rakudo.
haven't seen that one before.
jnthn That one is more...surprising. :-S
diakopter pmurias: maybe, but it'd be better to make a perlesque emitter for viv
masak jnthn: it runs fine out of the harness. :/
jnthn oh wtf 21:49
I hate it when that happesn.
masak it runs fine with 'make', too.
might have been a cosmic ray or something.
pmurias diakopter: which will emit code with perlesque like semantics?
masak still lots of passing TODO tests, as well.
I won't do anything about them.
jnthn *nod*
"This release is SO win it come with passing TODOs!" 21:50
masak do more people agree that I should comment out t/spec/S09-typed-arrays/arrays.rakudo from spectest.data for release?
I'm not really a fan of that practice.
jnthn masak: You're a fan of a month of people pointing out it fails?
masak no, I'm a fan of fixing it before release :)
21:50 rgrau left
jnthn masak: Is it a total fail? 21:51
21:51 eternaleye_ left
masak checking. 21:51
yes.
get_pmc_keyed() not implemented in class ''
after test 7.
jnthn Oh, so it actually compiles. Hm 21:52
masak after fixing that, it dies later in the script.
applying rolling fixes until it passes.
pmichaud I suggest skipping the tests in S09-typed-arrays for now.
it's not a trivial fix. 21:53
masak I'm adding #?skip comments.
jnthn pmichaud: What's the akshaul issue?
pmichaud (or it may be a trivial fix, but it's not a trivial find.)
jnthn heh
masak ah, only two were required. :)
pmichaud #?skip +1
right
jnthn What's the actual symptom?
:-)
pmichaud it crashes. :)
srsly. :)
jnthn :P :P
masak pmichaud: what about t/spec/S12-methods/submethods.rakudo ?
pmichaud that one was passing for me last time I checked. 21:54
looking.
(or, at least, it wasn't failing.)
yeah, that one shows everything passing for me.
masak I also couldn't get it to fail on demand.
pmichaud So, I dunno.
pugssvn r31336 | masak++ | [S09-typed-arrays/arrays.t] skip-fudged two tests
masak I'll just leave it in.
maybe it'll come back and bite us, and we'll treat it then. 21:55
pmichaud that's fine.
I'm also fine with skipping it, or commenting it out of spectest.data for the release
so we don't get a lot of people saying "you shipped something with failing tests?!?"
masak I would if I (or anyone) could reproduce it. 21:56
jnthn Yeah, doing another spectest run just to try and spot it again would be annoying I guess. 21:57
masak: What if you put it and a few other things into localtest?
masak jnthn: trying.
pmichaud this is one of those areas that I feel has no definite right answer, so it's really the release manager's call
masak jnthn: care to write up a sentence or two about the rationale for the name "Kiev" for this release? 21:58
21:58 eternaleye joined
jnthn masak: Can you hold on 5 mins while I finsih tracking a $dayjob test fail? 21:59
masak oh, definitely.
jnthn kk :-)
masak still at least half an hour left of the preparations :)
submethods.rakudo runs fine in localtest.data as well. :/ 22:00
oh wait.
it runs all the way through, but exits with exit status 1.
seems *that* is reproducible, even out-of-harness. 22:01
um. it ends with 'exit(1)'. so... :) 22:02
do all fudged test files end with 'exit(1)'?
seems not.
why this one? must be something the fudger added. 22:03
22:03 Mowah joined
jnthn woo, passes 22:03
22:03 Ross left
jnthn switches to extolling the virtues of Kiev 22:03
sorear pmichaud: nopaste -x /path/to/file or command | nopaste -x 22:05
pmichaud: -x tells nopaste to place the URL directly into the clipboard for pasting into IRC
masak hm, seems the 'fudge' tool adds an 'exit(1)' if --keep-exit-code hasn't been supplied to it.
but why?
sorear nopaste --help 22:06
pmichaud masak: yeah, that seems new or different somehow.
I noticed that I get exit(1) on all of the files with fudged tests now, and I don't think I used to get that.
(or at least the test harness is a lot more verbose about it) 22:07
jnthn pmichaud: Me too and it's...horrible.
I get so much test output about that. :S
pmichaud: But I thought it was a Parrot destruction bug.
I never suspected the test harness.
Or the fudger.
:S
pmichaud for exit code 1, it's usually not Parrot.
it's the fudger, returning exit 1 because "you really didn't pass all of the test file" :-) 22:08
jnthn pmichaud: Yeah, it did seem...odd.
pmichaud: Yeah but...it upsets the test harness.
pmichaud but we used to have an option in place that caused the harness to not report that condition
jnthn I'd really rather it didn't.
pmichaud so I'm not sure what happened to it
22:08 patrickas left
jnthn Does having them give exit code 1 win us anything? 22:08
pmurias if the harness ignores that it shouldn't give anything 22:09
pmichaud can we pass --keep-exit-code to fudge?
(were we at one point, and it changed?)
pmichaud looks... github to the rescue. 22:10
sorear pmichaud: The big problem with := hacking lexpads is that, well, it only works on lexicals
masak at this point, I would like to be able to use 'ack' in the time dimension, as well :)
pmichaud hmmm, Makefile has 22:12
HARNESS_WITH_FUDGE = $(PERL) t/harness --fudge --keep-exit-code --icu=$(HAS_ICU)
does --keep-exit-code not get passed along to fudge?
looks like it does, or should. 22:13
masak good. we've found two ends of the inconsistency. :) 22:16
only bisection left, then. 22:17
pmichaud anyway, I'm not at all fond of the way it works now (where I get lots of false errors reported from T::H because something somewhere is choosing to generate a strange exit code), so whatever can be done to fix that I'm in favor of.
I don't think it's Rakudo generating the exit code, so that just leaves fudge or something in Test::Harness (or equiv) 22:18
22:18 macdaddy joined
pmichaud I don't know why it started appearing when it previously did not. 22:20
(at least on my systems)
22:22 eternaleye left 22:25 pmurias left 22:27 gbacon left
masak tools/contributors.pl is not Unicode-aware, but it sure simplifies things. 22:28
22:29 lest_away is now known as lestrrat
masak github.com/rakudo/rakudo/blob/maste...ce/2010.06 -- please help review, find errors, possible improvements, etc. this is your last chance to help with the release, so take it! :) 22:35
dalek kudo: 22b71e0 | masak++ | docs/announce/2010.06:
[docs/announce/2010.06] added
jnthn reads 22:36
pmichaud other features off the top of my head
match objects now act like real hashes and arrays
hash and array slicing is greatly improved 22:37
(you can adopt or ignore these as you wish)
variable interpolation in regexes now works (that's kind of a biggie to me)
masak the first of those is in docs/ChangeLog, but maybe it's important enough to mention even in the release announcement. yes, probably.
pmichaud: I wrote that last one! :)
pmichaud oh, I see it now. 22:38
<-- blind.
masak the hash/array slices one should probably go both in the docs/ChangeLog and in the release announcement.
fixing.
jnthn masak: "The list semantics received a complete overhaul" -> semantics and implementation?
masak jnthn: this is for the implementation.
pmichaud the next release is scheduled for July 22, I think.
22:39 Mowah left
pmichaud Certainly not the 17th. 22:39
(which is a Saturday)
masak oh yes.
apparently I can't read a calendar properly.
jnthn "many things that should be truly lazily evaluated, now are." -> that comma looks odd to me
masak removing.
22:40 xabbu42 joined
pmichaud maybe: "Rakudo now uses immutable iterators internally, and generally hides their existence from programmers. Many more things are now evaluated lazily." 22:40
might be too long.
masak no, it's fine. 22:41
masak uses that
jnthn Wow...the list of contributors to this months release feels quite sizable. :-)
pmichaud it's quite impressive, I agree.
masak any duplicates?
I found a few, maybe not all.
jnthn 25 people
:-D
masak: no
Or at least, not unless somebody has an alias and a real name pair that I'm not aware of. 22:42
22:43 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
masak new version: github.com/rakudo/rakudo/blob/maste...ce/2010.06 22:43
hm, the bullet point about the spectests is improperly indented. 22:44
jnthn + Backtraces with Perl 6 subroutine names and line numbers 22:45
pmichaud +2
jnthn masak: Is that noteworth enough to be in the announce as well as the changelog?
pmichaud Yes.
jnthn masak: It feels like quite a big thing for users.
masak definitely.
it must have slipped my mind. 22:46
jnthn++ # backtraces!
jnthn Maybe something that hints that the backtraces are more accurate than alphas ever were too.
pmichaud jnthn: any suggestions for a grant manager for my proposal? ;-)
22:46 mikehh left
pmichaud jnthn: I'll punt the issue for now, I think. 22:46
jnthn pmichaud: Grant manager?
dalek kudo: 8a1a1a5 | masak++ | docs/ (2 files):
[ChangeLog, announce] improvements
pmichaud for the proposal I'm putting togehter. I'll send you a copy shortly. 22:47
I think I'll just say "I'm not sure who should be manager" and see what we come up with. :)
masak that's the old commit. new commit coming up :)
jnthn pmichaud: It'd feel slighlty weird to grant-manage the pumpking. :-) OTOH, I'm probably better positioned to actually understand/assess it than most due to my level of Rakudo involvement...
pmichaud: I'm happy to, so long as it won't be seen as "too cosy" (e.g. given it leaves us essentially managing each others grants :-)). 22:48
pmichaud jnthn: yes; I'm just worried that it starts to look a bit strange if we're all serving as manager's for each other's grants.
right, what you just said :)
masak vim's spellchecker found a double 'the the' that neither of us had found. :P
pmichaud I totally can't believe we we missed that! 22:49
masak :P :P
final version so far: github.com/rakudo/rakudo/blob/maste...ce/2010.06
(this might be the one!) 22:50
pmichaud ooc, where does the 33,280 number come from?
masak docs/spectest-progress.csv
jnthn double checks the Ukrainian words
masak last line, third column.
pmichaud that number was actually as of 0000 UTC 22:51
the release probably passes quite a few more than that :-P
22:51 xabbu42 left, xabbu42_ joined
masak care to give a newer number? 22:51
pmichaud anyway, it's fine to cite that number.
I don't think we want to wait an hour for me to calculate the new one.
Oh, I might have a calc... just a sec
masak :)
pmichaud as of 1320 this morning, we were passing 33378 22:52
22:52 Schwern joined
pmichaud out of 39887 counted. 22:52
masak ok.
I can change it to that.
dalek kudo: 6b12f89 | masak++ | docs/announce/2010.06:
[announce] more fixes
22:53 patspam left
pmichaud I think it looks really good. 22:54
Amazing progress this past month.
actually, amazing progress this past three months.
masak indeed.
for a bunch of raving lunatics, we're doing pretty good. :P
jnthn I'm a true believer in all of us! 22:55
[particle] pmichaud: re: grant manager... jhorwitz?
22:55 eternaleye joined
[particle] he is a tpf grant manager 22:55
masak runs 'make release 2010.06' 22:56
22:56 tedv joined
pmichaud [particle]: excellent suggestion also 22:56
masak "Try 'make release VERSION=yyyymm'"
pmichaud the manager for this grant is going to have very little to have to do
masak should I update the release guide? :)
pmichaud it should be VERSION=yyyy.mm"
(note dot)
at least, I think it's supposed to have the dot. 22:57
[particle] wishes he was able to contribute something this past month
masak aye.
pmichaud oh, wait.
masak missed the VERSION=
pmichaud yes.
[particle] pmichaud: i'll offer myself, but that might still be to incestuous
masak but the error message is missing the dot.
pmichaud the error message needs a fix then ( can happen post release )
masak aye 22:58
I'll try to remember, and fix it post-release.
dalek kudo: 5eb3875 | masak++ | docs/announce/2010.06:
[announce] more recent passing-tests figure
22:59 skids joined, xabbu42_ left, xabbu42 joined
masak untars and runs spectests in a different directory 23:00
the release guide speaks about an 'initial tarball'. is the implication that after applying the git tags, one should produce a new tarball? 23:03
23:03 xabbu42 left, xabbu42 joined
pmichaud no 23:03
23:03 lestrrat is now known as lest_away
pmichaud the intent is that the tarball might not work, and so you'd have to fix something and possibly make another 23:03
masak right.
pmichaud however, I don't think that's ever really happened in practice
masak :) 23:04
pmichaud so if you want to remove "initial" or otherwise rephrase the document, +1 from me :)
masak will do.
running spectests just in case, one last time.
pmichaud yes, I do that as well.
masak++
masak I have a number of smallish changes to the release guide, but I'll push them after the release.
pmichaud wfm.
masak finally gets an account at rakudo.org 23:06
pmichaud masak: do you need posting privs? 23:07
masak I'll shout if I do. still creating the account.
yes, seems I do. 23:08
account name 'masak'.
pmichaud done, I think.
masak I don't see any difference... 23:09
pmichaud oh, oops.
23:09 shade__ is now known as \shade\
pmichaud try now. 23:09
(reload)
masak that's better. :)
thanks.
23:11 eternaleye_ joined 23:12 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42, eternaleye left
masak likes Aaron Sherman's suggestion about underscores after the radix in numbers 23:13
std: 0x_dead_beef 23:14
p6eval std 31325: OUTPUT«===SORRY!===␤Whitespace is required between alphanumeric tokens at /tmp/RJjIcwt5A6 line 1:␤------> 0⏏x_dead_beef␤Whitespace is required between alphanumeric tokens at /tmp/RJjIcwt5A6 line 1:␤------> 0x⏏_dead_beef␤Undeclared
..na…
diakopter std: 0xd_ead_beef 23:15
p6eval std 31325: OUTPUT«ok 00:01 104m␤»
23:18 pronik` joined, pronik left
jnthn masak: Unfortunately, though, he's patched a generated file. 23:21
masak we're getting comment spam on rakudo.org. I removed those I just discovered.
jnthn masak: Maybe we need a note in ext/nqp-rx in Parrot saying not to edit the files
masak jnthn: I suspected as much. someone should tell him.
jnthn Or maybe there is one.
masak generally, generated files should contain a note, yes. :)
"OH HAI IM GENERATED"
23:22 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42 23:23 snarkyboojum joined
pmichaud the file does say it's generated. 23:26
errrr..... it *used* to say it. 23:27
hmmm
pmichaud makes a note to go add notes to the generate files.
...and wonders what happened to the code he added last month-ish to add notes to the files... 23:28
cxreg adds .rand to a subset condition 23:29
23:29 cdarroch left, xabbu42 left
cxreg subset Lol of Int where { 2.rand.Int } 23:29
23:29 xabbu42 joined 23:31 arthur-_ left 23:32 REPLeffect left
masak rakudo: subset Lol of Int where { (0..1).pick }; say 5 ~~ Lol for ^10 23:33
p6eval rakudo 736bef: OUTPUT«0␤1␤1␤0␤0␤0␤1␤0␤1␤0␤» 23:34
masak interesting idea. subsets which change over time.
23:34 arthur-_ joined
arnsholt I can't decide if I hate you or love you =D 23:35
23:35 REPLeffect joined
TimToady the two are not mutually exclusive 23:35
arnsholt Heh, true
masak rakudo: subset IntOnAThursday of Int where { Date.today.day-of-week == 4 }; say 5 ~~ IntOnAThursday 23:36
p6eval rakudo 736bef: OUTPUT«1␤»
masak \o/
23:36 macdaddy left
arnsholt But it's friday! ^^ 23:36
masak arnsholt: not in UTC :)
arnsholt Spoilsport ;p
jnthn masak: At some talk a while back I caused some amusement by writing a sub signature that'd randomly fail to bind. :-)
masak there's much untapped fun here, for sure. 23:37
23:38 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
pmichaud rakudo: say "I can't decide if I {any(<hate love>)} you." 23:38
p6eval rakudo 736bef: OUTPUT«I can't decide if I any("hate", "love") you.␤»
pmichaud :-D 23:39
23:42 REPLeffect left
masak rakudo: say "I've decided: I {<hate love>.pick} you." # risky! 23:43
p6eval rakudo 736bef: OUTPUT«I've decided: I hate you.␤»
masak :( 23:44
jnthn hugme: hug masak
hugme hugs masak
masak :)
23:44 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
jnthn rakudo: say "She loves me { ('', 'not').pick }" 23:44
p6eval rakudo 736bef: OUTPUT«She loves me not␤»
jnthn Typical. 23:45
masak hugme: hug jnthn
hugme hugs jnthn
jnthn :)
23:45 REPLeffect joined
masak release announcement posted to rakudo.org, p6l, p6c, p6announce, p6u, and use.perl.org. I updated the Wikipedia article. 23:48
jnthn masak: Got the mail. \o/
jnthn wonders if use.perl.org copes with the unicode chars
masak the independant spectest has finished, after 35 minutes. it looks good.
jnthn: in posts, yes. in comments, no.
use.perl.org/~masak/journal/40405
jnthn ah, phew 23:49
pugssvn r31337 | lwall++ | [S02] allow _ between radix and digits as suggested by ajs++
jnthn I was sure there was some issue somewhere.
pugssvn r31338 | lwall++ | [STD] allow _ between radix and digits as suggested by ajs++ 23:50
sorear hugme is for wusses.
sorear hugs masak
dalek kudo: cbff7d0 | masak++ | docs/release_guide.pod:
[docs/release_guide.pod] updates and improvements
 23:51
masak sorear: if that's what it takes to get hugs, I'm a wuss. :P 23:52
23:52 xabbu42 left, xabbu42 joined
masak goes to look up 'wuss' 23:52
jnthn If I get wussier, do I get hugged more?
jnthn gets curious about the etymology
23:53 REPLeffect left
jnthn oh 23:53
It's recentish maybe
masak jnthn: depends if there's a correlation between degree of wussiness and amount of hugs. :)
dictionary.com suggest it's from the 1980s. 23:54
perhaps a mixture of 'wimp' and 'puss'.
23:54 REPLeffect joined
masak there's also 'wussy', which corroborates that. 23:54
jnthn masak: I think I mixture of wimp and pussy
masak oh, but that's the adhective form. 23:55
jnthn To get wussy
Which was then shortened.
*a mixture
23:55 xabbu42_ joined, xabbu42 left, xabbu42_ is now known as xabbu42
masak right. 'wuss' might be a fairly obvious back-formation from 'wussy'. 23:55
jnthn You can call somebody a pussy if they're being a a wimp.
masak but 'puss' also is a noun, meaning 'cat'.
jnthn Yes, but more slangy, at least in my dialect 23:56
Puss is also nasty fluid
masak no, that's with one 's'.
dalek kudo: 30db218 | masak++ | build/Makefile.in:
[Makefile.in] added missing '.' in error message
 23:57
jnthn masak: Really?
oh, yes 23:58
snarkyboojum puss can also mean 'girl or young woman' apparently - never heard it used that way though
according to thefreedictionary.com anyway
masak jnthn: don't debate English spelling with a Swede. :P
jnthn snarkyboojum: I'd...not try it. :) 23:59
arnsholt snarkyboojum: My guess would be that the "girl" meaning has been replaced by a more, er, narrow sense =)
snarkyboojum jnthn: I can imagine even a romantic mood wouldn't help :)
jnthn masak: It sucks to be a native speaker, never quite knowing how to spell things. :-)
23:59 supernovus joined
jnthn snarkyboojum: OTOH, I've heard all kinds of terms of endearment from different dialects in the UK, so I guess it varies a lot. 23:59
arnsholt (For some reason words for woman and girl are prone to extreme semantic drift)
masak jnthn: I have no idea what you're talking about :P

Powered by Cro and the Raku® Programming Language.

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

Thank you!