»ö« | perl6.org/ | 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 moritz_ on 25 June 2010.
00:00 tylercurtis left 00:01 Psyche^ joined 00:04 drbean left 00:05 Patterner left, Psyche^ is now known as Patterner
pugssvn r32077 | lwall++ | [rx.t] <before> should be a parsefail 00:22
r32078 | lwall++ | [STD] normspace should be optional before regex error or s/// doesn't fail right 00:23
TimToady std: s///
p6eval std 32076: OUTPUT«===SORRY!===␤Regex not terminated at /tmp/JEEY2FH7xy line 1 (EOF):␤------> s///⏏<EOL>␤ expecting quantifier␤Undeclared routine:␤ 's' used at line 1␤Parse failed␤FAILED 00:01 118m␤»
jnthn ur failin it rong. 00:24
TimToady ayup.
it was requiring a normspace before figgering it out, which there ain't one in s/// 00:25
jnthn Ah, yes.
TimToady someone (prolly me) was thinkin' that normspace could match '' like ws could
jnthn In metamodel prototype land...turns out I probably need to implement a basic multi-dispatcher before I can understand how well the meta-model prototype is performing.
Well, or hack stuff. :-) 00:26
00:26 ruoso joined
jnthn Turns out that I'm spending most of the time in expensive coercion methods. 00:26
colomon performance! That was what I was going to do when I got the chance. 00:27
jnthn colomon: What're you going to perform for us? :-)
It turns out one thing Parrot can do fast is take a native integer and stick it into a PMC. Well, turns out that's not so relevant for Rakudo, but it does mean I have a fight on my hands to work out how to get us about as fast boxing to full-blown Perl 6-y objects.
*box it into 00:28
00:30 kid51 joined
jnthn At the moment on the benchmark I'm trying, I beat Rakudo hands down but Parrot NQP manages to beat the prototype. On the one hand, "that's not fair" because I'm creating "real" objects rather than just an Integer PMC, so it's irrelevant for Rakudo performance. On the other had, I'd like to have a deisgn that can be comparable or beat it anyway. 00:30
*hand
This probably means it's time to work out how to write a proper multi dispatch cache. 00:31
colomon jnthn: look at how long it takes to read a 10,000 line text file. 00:32
jnthn colomon: ...in Rakudo?
colomon yes
jnthn Probably a lot longer than it should. 00:33
colomon well, yes
but I'm investigating.
jnthn Would be interesting to know where we're spending time.
00:33 artcoder joined
jnthn I can't really express how much I love www.red-gate.com/products/ants_perf..._profiler/ 00:33
colomon oh, hey, there we go. 55s using "for $*IN.lines"
jnthn colomon: youch! 00:34
colomon are you using it for your experiment? (does your experiment have a proper name I'm forgetting)
jnthn colomon: Yeah.
colomon sweet
sorear niecza can read any text file with O(1) overhead
jnthn colomon: My $dayjob company is actually a redgage partner.
sorear using System.IO.File.ReadAllText(path) and then wrapping it in a str 00:35
jnthn Yes, well I suspect Rakudo can slurp rather faster too ;-)
colomon next step: try writing it with just .get
jnthn But this is using a lazy iterator over the file.
colomon yes, about to find out how much overhead the lazy iterator causes 00:36
44s for the loop using $*IN.get 00:39
jnthn That's still insanely bad. 00:40
colomon so using the iterator adds 25% to the execution time.
jnthn: very true.
00:40 tylercurtis joined
colomon actually, I guess it could be considered *more* insanely bad when it takes a long time using .get. At least .lines has the "completely unoptimized lazy iterator" excuse. 00:42
jnthn Right.
colomon: Oh
colomon: get auto-chomps iirc 00:43
sorear .get has the "our loops and calling conventions take forever" excuse
jnthn colomon: Wonder if the chomp is what costs us so badly
colomon for reference, $*IN.slurp takes 5.5s. that's still insanely slow, considering. :(
jnthn *confused look* 00:44
colomon yeah, .get does autochomp, but surely that shouldn't shouldn't slow things down that badly, should it?
jnthn Maybe we could write a PIR benchmark to see how fast Parrot can actually slurp it in.
colomon: I wonder how chomp is implemented...
colomon: I see to remember, scarily.
colomon jnthn: you take a look at the PIR, I'll take a look at the chomp? 00:45
jnthn colomon: Let me work something up.
colomon jnthn__
jnthn++
having typing issues tonight. I blame my brain.
pmichaud good evening 00:46
colomon o/
pmichaud I don't think that %h<foo> should flatten 00:47
colomon pmichaud: trying to time reading text.
pmichaud rakudo: my %h = (abc => [1,2,3], def => 4); for %h<abc def> -> $x { say $x.perl; }
p6eval rakudo 7b0031: OUTPUT«[1, 2, 3]␤4␤»
jnthn pmichaud: oh ffs
gah
colomon: offs 00:48
colomon: Reading a 10,000 line text file in *PIR* seems to take a few seconds
colomon: Let me send you the code to time it on the file you have
pmichaud is Parrot still suffering from insanely slow I/O?
jnthn gist.github.com/541540
colomon: ^^ and replace the foo.txt with the name of your file then just parrot x.pir 00:49
pmichaud: This doesn't look encouraging.
pmichaud: 2 seconds to read a 280 K file. 00:50
With the above gist.
colomon jnthn: I get 0.84s to read it using your PIR. 00:52
jnthn colomon: OK now try: 00:53
pmichaud jnthn: is that 2 seconds for reading the file, or 2 seconds to start up parrot and read the file?
jnthn gist.github.com/541544 00:54
colomon pmichaud: I get 0.84s to start up parrot and read the file.
jnthn colomon: ^^
pmichaud: Start up Parrot and read the file, but Parrot start-up is negligible.
pmichaud: Well, for a 2s runtime it is.
pmichaud okay
pmichaud tries
what are you using for foo.txt, ooc?
jnthn I - oddly - get a significantly faster read with reading each line individually
Rather than readall to read the lot at once. :/ 00:55
pmichaud: it's a file with 10000 lines all containing "lol a line with text on it"
colomon woah, same here!
0.026s to read all 10001 lines.
mine is about 20% Violet Jacob poems and the remainder core.pm 00:56
jnthn ...so reading line by line is faster in Parrot than .readall?
Are the poems valid Perl 6 too?
colomon jnthn: nope, too many Scottish words
dalek odel: 7608b1b | jnthn++ | dotnet/ (3 files):
Stop signature binding swamping the profile. At least one lesson to teach Rakudo's from this experience.
colomon O Jean, my Jean, when the bell ca's the congregation 00:57
Owre valley an' hill wi' the ding frae its iron mou',
When a'body's thochts is set on his ain salvation,
Mine's set on you.
jnthn Yeah, an' is not a valid identifier due to ending in the ' :-(
pmichaud heh 00:58
readall in filehandle.pmc:
do {
STRING * const part = Parrot_io_reads(INTERP, SELF, 0);
result = STRING_IS_NULL(result) ? part :
Parrot_str_concat(INTERP, result, part);
} while (!Parrot_io_eof(INTERP, SELF));
10000 string concatenations
jnthn omfg
Someone want to file TT? :-)
sorear Also, this is the first benchmark that niecza and rakudo can compete honestly in, since it involves no arithmetic 00:59
jnthn Anyway, that tells us why slurp is sucky but less about why a .get loop is.
colomon chomp does two regex compares with the line in the normal case. :( 01:00
jnthn er, yes, I just found that
We...should find a rather better way to do that.
Doesn't Parrot have a chomp opcode anyway? 01:01
colomon looks to pmichaud...
sorear 38 seconds to 'for $*IN.lines -> { }' Rakudo's core.pm
jnthn sorear: In Niczea? 01:02
Or Rakudo?
sorear in niecza
jnthn k
sorear testing rakudo on the same machine now
jnthn colomon: Anyway, this chomp is almost certainly one example of a builtin that wants re-doing efficiently. 01:03
01:03 synth joined
colomon jnthn: abso-effing-lutely 01:03
pmichaud Parrot has a chop opcode, but not a chomp
still, chomp can be far more efficient than rakudo's setting.
jnthn pmichaud: Indeed. 01:04
pmichaud oh dear
yes, this is horribly slow
jnthn I bet it's where we're spending most of our time.
pmichaud even a string compare would be far faster than this. 01:05
jnthn Right
colomon does it actually compare each character of the string as it goes?
pmichaud ??
colomon the regex 01:06
jnthn pmichaud: Is the regex engine smart about end anchoring?
pmichaud the regex engine doesn't know about end anchoring yet, no.
it can be done, but... tuits
colomon jnthn++ for saying it properly
jnthn Ah, so it likely is walking through the whole string.
colomon yeah, that sounds massively bad.
pmichaud a utf8 string, at that.
jnthn We need to stop dealing with utf8 strings interally. 01:07
colomon seems to have lost his Rakudo/src editor window. :\
jnthn Maybe the NFG work of late will let us do that.
Juerd There are huge files in /tmp on feather
Made by www-data. They contain huge diffs.
jnthn Juerd: Don't try to read through them with Rakudo.
;-)
pmichaud who's filing the TT on readall, if anyone? 01:08
Juerd Many are >100 MB
Could you please have a look and see if you know their origin?
jnthn pmichaud: Dunno if anyone volunteered yet?
pmichaud I'll do it.
jnthn pmichaud: Thanks
Juerd doesn't know what kind of web thing creates this kind of enormous diffs 01:09
jnthn gist.github.com/541544 and gist.github.com/541540 are the examples
01:09 Holy_Cow joined
colomon is our chomp even right? 01:11
jnthn Juerd: I get permission denied when trying to look
01:11 Holy_Cow left
jnthn Juerd: Oh, looking at their chomod'ing I would. 01:11
colomon: Well, it at least knows what Windows line endings are :-) 01:12
colomon but it doesn't handle old Mac-style line endings, as far as I can see.
jnthn No
Juerd The mtimes coincide with access_log entries for REPORT requests on SVN 01:13
Who maintains svn in apache2 on feather? This software behaves very badly and I want to disable it, and perhaps have it moved to a more confined environment. 01:14
We've had huge memory leaks (still have them), and now it turns out to put stuff in /tmp and never clean that. :(
Anyway. Cause found. Removing junk from /tmp. 01:15
pmichaud jnthn, colomon: trac.parrot.org/parrot/ticket/1749 01:16
colomon pmichaud++
jnthn pmichaud++ # thanks 01:17
pmichaud prepares to sadly part with his shiny new Nexus One
Juerd 15 GB deleted from feathers /tmp
jnthn pmichaud: Oh?
colomon pmichaud: why?
pmichaud well, it's the 'extra' one I got from Google at OSCON (more)
colomon updated his Droid to 2.2 this morning. o/
pmichaud daughter was promised a smartphone if she did well academically last year, and she pulled it off. 01:18
rather than buy a new smartphone for her, my 'extra' gets to be hers.
Juerd What kind is your primary smartphone?
pmichaud A Nexus One. :-)
but I liked having a spare :)
Juerd That's okay then, you'll still have infinite awesomeness.
You had double infinity, which wasn't useful anyway :) 01:19
jnthn only has a dumbphone
pmichaud also, it was going to be nice to have an extra to do some development on, someday (hopefully not too long away)
Juerd has the HTC Desire, which is almost identical
Its case is a bit different (but also very much alike) and it runs HTCs sweet Sense interface, but apart from that they're the same device 01:20
jnthn -> sleep 01:30
colomon 'night 01:32
sorear If $/ in a regex refers to the cursor, what's the point of $¢? 01:36
How do I check what version of Rakudo I have installed? 01:37
perl6 -v only gives the Parrot version (47723) 01:38
colomon must be pretty old, my perl6 -v gives This is Rakudo Perl 6, version 2010.07-153-g90637b6 built on parrot 2.7.0 r48559 01:39
sorear ok, I'll update my rakudo before gloating how much slower it is
ping me when it can be built in <400MiB
01:42 jferrero left, artcoder left 01:44 gfx joined 01:52 colomon left
sorear nevermind, found the answer. 01:54
flyback heading to the store, bbl 02:02
02:06 shade_ left
sorear When, precisely, does a sub need to contain 'my $/ is context'? 02:14
dalek ecza: 8513447 | sorear++ | src/Niecza/Actions.pm:
Parsing for <?> etc
 02:24
ecza: 36516a9 | sorear++ | lib/Kernel.cs:
Readonly binding should strip containers
ecza: 5de4fa0 | sorear++ | test2.pl:
Test for ro binding
02:34 azert0x left, shade_ joined 02:53 risou left
sorear Rakudo puts my $/ is context = OUTER::<$/>; in every single block 02:58
I don't like that for Niecza, since 'is context' variables are not cheap
pmichaud changing .chomp to PIR reduces the time needed to do 'for $*IN.lines' on my system from 75s to 21s 03:02
(on a 10,000 line input file) 03:03
running 'make spectest' now.
03:06 araujo left, araujo joined 03:12 justatheory left
pmichaud omg 03:15
I just realized that PCT::HLLCompiler uses .readall to read in source files
which means we pay a penalty when reading, say, core.pm (~7000 lines)
pmichaud updates the TT with this information. 03:16
03:17 alester joined
pmichaud oh, wait. 03:17
we use the .readall('filename') form, which is much faster than the .'readall'() form on an already-opened filehande 03:18
so it's probably not as expensive.
sorear open("/path/to/core.pm").slurp takes 1.4 seconds locally 03:19
generating core.pir takes 400 seconds
I don't really think this is omg-worthy, even if it is worth fixing 03:20
pmichaud it's not just the time needed to read the file, it's all of the gc-ables that get created in the process
i.e., reading a 7000-line file creates 7000 string objects
(more, since it's doing concats on each pair)
sorear won't they all get eliminated on the first GC? 03:21
pmichaud yes, but given how slow our gc is....
sorear how can I force a GC from Perl6 to test?
pmichaud I agree, I don't expect this to save a huge amount of time; but the point is that it's something that is far far slower than it ought to be, and creates a lot of waste
it's not like I think this is going to cut our compile time by half 03:22
03:23 kid51 left
flyback rummadges thru his piles of old pc parts to find a good canadate for a flashrom programmer motherboard 03:24
sorear is toying with the idea of abandoning static code generation for regexes 03:29
03:29 kid51 joined, artcoder joined
dalek kudo: 03a9388 | pmichaud++ | build/PARROT_REVISION:
Bump PARROT_REVISION to get && in regexes.
 03:36
kudo: 1996bac | pmichaud++ | src/Perl6/Grammar.pm:
Refactor <.dumbsmart> rule.
kudo: d1015f0 | pmichaud++ | src/core/Cool-str.pm:
Rewrite .chomp method to be more efficient. With this change, the time needed to read 10,000 lines via for $*IN.lines { ... } goes from 75 seconds to 21 seconds on my system.
03:43 flyback left 03:44 xinming_ joined 03:48 xinming left 03:50 kid51 left 03:56 Italian_Plumber left 04:02 REPLeffect joined 04:03 jaldhar joined, artcoder left 04:13 hercynium left 04:24 gfx left, masonkramer joined, risou joined, dduncan joined 04:25 dduncan left 04:31 risou left 04:32 HarryS left 04:58 xinming joined 05:01 xinming_ left 05:14 envi^home joined 05:22 Guest23195 joined 05:38 risou joined 05:45 risou left
lue there's a *Hyper*Whatever ? O.o 05:49
05:51 molaf joined 06:03 Guest29521 left, Trashlord joined
perigrin lue: yes but with some adderal they say it will calm down. 06:05
lue :) 06:06
06:08 Trashlord left
lue seems like a wonderful challenge to implement it :) afk o/ 06:08
06:09 Trashlord joined 06:11 masonkramer left 06:48 envi_home joined, envi^home left 06:51 justatheory joined 06:52 justatheory_ joined, justatheory left, justatheory_ is now known as justatheory 07:02 justatheory left 07:14 Alias_ left 07:21 tylercurtis left 07:31 stepnem left 07:32 wamba joined 07:34 envi_home left, envi^home joined 07:35 stepnem joined 07:37 zulon joined 07:38 wamba left 07:44 envi^home left
snarkyboojum g'day perl6 type hackers 07:48
moritz_ o/
snarkyboojum is in the process of compiling rakudo star on his phone ;) 07:50
Perl 5 already shipped with it! (albeit an old version)
needed a couple of modules to get Configure.pl going (which required hacking cpanm a little - yes, cpanm on my phone ho ho) 07:51
but currently parrot is building, so I'll keep you posted if I can eventually play with the REPL on my phone :) 07:52
07:55 envi^home joined 08:11 Chillance left 08:13 mikehh joined 08:15 pnate left
sorear snarkyboojum: just HOW much memory does your phone have? 08:18
sorear is toying with making regexes !~~ Block
08:18 lichtkind joined
lichtkind szabgab: ping 08:18
snarkyboojum sorear: 1GB :P
sorear: well 256MB RAM, and 768MB swap space 08:19
so 1GBish virtually
sorear handling stuff like regex { :my $*foo = class { ... }; <...> } is a bit tricky if regexes are anything other than ordinary subs, though 08:22
08:24 drbean joined
sorear I wonder if I could just get away with calling that illegal. 08:40
snarkyboojum scarily, parrot compiled :) 08:41
moritz_ rakudo: my regex a { :my $*x = class { method foo { say "hi" } }; {$*x.foo() }; }; 'a' ~~ /<&a>/ 08:48
p6eval rakudo d1015f: OUTPUT«PackFile_unpack: This Parrot cannot read bytecode files with version 8.2.␤␤PackFile header failed during unpack␤»
moritz_ std: my regex a { :my $*x = class { method foo { say "hi" } }; {$*x.foo() }; }; 'a' ~~ /<&a>/ 08:50
p6eval std 32078: OUTPUT«===SORRY!===␤Semicolon must be quoted at /tmp/wzbrn1Mi2d line 1:␤------> method foo { say "hi" } }; {$*x.foo() };⏏ }; 'a' ~~ /<&a>/␤Parse failed␤FAILED 00:01 121m␤»
moritz_ if I remove that ;, it wors locally in Rakudo :-)
sorear how do you keep going on such a thankless task 08:52
I for one don't think I'll be able to go on much longer without any encouragement 08:55
lichtkind moritz_: grüße von der froscon hab heute beim frühstück ehemaligen studiencollegen von dir gesprochen 09:04
09:05 Mowah joined
moritz_ sorear: which thankless task? 09:07
sorear: the key is to do something you enjoy doing
rakudo: my regex a { :my $*x = class { method foo { say "hi" } }; {$*x.foo() } }; 'a' ~~ /<&a>/
p6eval rakudo d1015f: OUTPUT«PackFile_unpack: This Parrot cannot read bytecode files with version 8.2.␤␤PackFile header failed during unpack␤» 09:08
moritz_ shouts at parrot
sorear moritz_: It was fun two days ago
moritz_ sorear: also it's important not to try to do everything correct at the first shot 09:10
sorear: I admire your work on niecza. So far I just haven't found a use case where it's better than rakudo 09:12
afk
09:14 drbean left
sorear rakudo: say ?"0" 09:19
p6eval rakudo d1015f: OUTPUT«PackFile_unpack: This Parrot cannot read bytecode files with version 8.2.␤␤PackFile header failed during unpack␤»
sorear pugs: say ?"0"
p6eval pugs: OUTPUT«␤»
sorear alpha: say ?"0"
p6eval alpha 30e0ed: OUTPUT«0␤»
sorear alpha: say ?"x"
p6eval alpha 30e0ed: OUTPUT«1␤»
cognominal submitted a patch for #77322 09:21
sorear std: /<[x][y][z]>/ 09:23
p6eval std 32078: OUTPUT«ok 00:01 117m␤»
09:23 lichtkind left
cognominal in S05, what's the difference between a printable character and a graph character? 09:26
09:26 Italian_Plumber joined
sorear graph excludes spaces 09:30
09:33 meppl joined 09:37 thebird joined 09:52 zulon left 10:03 suhailck joined 10:06 suhailck left
snarkyboojum has Rakudo star running on his phone :D 10:09
a Nokia N900 fwiw :) 10:11
high fives all round :) 10:23
10:25 mberends left 10:34 [Coke] left 10:35 [Coke] joined 11:14 colomon joined 11:32 risou joined
cognominal snarkyboojum, how much memory? 11:32
snarkyboojum cognominal: available or used?
cognominal I am speaking of RAM, nor rlash. 11:33
*flash
snarkyboojum 256MB RAM 11:34
cognominal how long did it take toc ompile? 11:35
snarkyboojum about an hour and a half :) 11:36
parrot took the longest
11:37 risou left
snarkyboojum it's only a 600Mhz ARM processor :) 11:37
11:38 masak joined
masak halloy, #perl6! 11:39
I wonder if a talk with the title "The Design of Perl 6", and the subtitle "There's some madness to the method" would attract a crowd... 11:43
11:44 HarryS joined 11:48 HarryS left, HarryS joined 11:53 Mowah left
masak snarkyboojum++ # twitter.com/snarkyboojum/status/21738635293 11:57
snarkyboojum masak o/
masak \o
11:57 Trashlord left 11:58 molaf left
snarkyboojum lots of fun running perl 6 in a repl on my phone :) 11:58
partly because the n900 is such a cool device
11:58 Trashlord joined
masak if there's any smartphone I'd consider buying, it's the n900. 11:58
snarkyboojum did alot of the installing over ssh to my phone from my laptop :) pretty darn cool
masak rakudo: say ?"0" 11:59
p6eval rakudo d1015f: OUTPUT«PackFile_unpack: This Parrot cannot read bytecode files with version 8.2.␤␤PackFile header failed during unpack␤»
masak locally, 0.
another take on rt.perl.org/rt3/Ticket/Display.html?id=77340 is the question whether the second argument of &map also flattens in the absence of $ or [] 12:02
12:25 azert0x joined 12:29 drbean joined, zulon joined 12:35 zulon left
masak nom, then studying & 12:44
jnthn Afternoon, 6folk :-) 12:52
cognominal jnthn, can you review and possibly apply my patch for getting the class Grammar as parent of any grammar? #77322 12:59
colomon jnthn: \o # just who I wanted to see... 13:00
lolibloggedagain: justrakudoit.wordpress.com/2010/08/...ds-part-2/ 13:02
jnthn colomon: I don't see a patch attached to the ticket?
colomon the parrot ticket?
jnthn tab complete FAIL
cognominal: ^^ 13:03
cognominal \o/
jnthn colomon: Nice post - nice improvement, but yes, ouch, that iterator stuff hurts us.
colomon darn you tab!!!!!
cognominal And how come compiling perl6.c is so slow? 13:04
jnthn cognominal: It's pretty fast here.
cognominal: Depends on your C compiler. Mine is a good one. :-)
colomon jnthn: yes, I was wondering if you still remembered the magic pir:: to make a Parcel on the fly, so I can try writing a smarter iterator for .lines.
cognominal may be I should try clang instead of gcc. 13:05
jnthn I haven't heard people complain of gcc being slow for perl6.c...
colomon: my $parcel := pir::new('Parcel'); pir::push($parcel, 42); 13:06
cognominal jnthn, I have TABs in my patch?
jnthn colomon: Note the :=
cognominal: No, I can't find your patch. Where is it?
colomon jnthn++
cognominal jnthn, probably making its way to p6c... forwarded to you 13:08
13:08 orafu left, orafu joined
cognominal trying to compile with clang. 13:13
jnthn colomon: Though these pir::new's might come back to haunt me in a month or two. :-) 13:16
Well, OK. *will* :-)
cognominal: Got it, will look over it shortly. 13:17
cognominal Apparently clang recognize most gcc switches
and emits more warnings 13:18
I see that clang is also part of freebsd. 13:23
colomon jnthn: yeah, I've been wondering about that. the pure PIR optimizations are even worse. 13:24
I mean, great for Parrot-based Rakudo, but making life harder for you in the near future.
also, both the Range and .chomp optimizations are literal translations not-quite-correct Perl 6. 13:25
13:25 alester left
jnthn colomon: I'm not even thinking portability, I'm thinking meta-model changes. 13:26
colomon oh. 13:27
jnthn Anyway, no worries for now.
colomon well, we'll burn that bridge when we come to it, eh?
jnthn I'll probably have a branch for a while.
Yes.
13:33 drbean left
jnthn cognominal: Will try and get talks submitted for OSDC.fr this weekend too. 13:37
cognominal nice 13:38
colomon just realized how stupid it was to try to redefine IO.lines right in the setting, without prototyping the code in a standalone .pl file. 13:40
13:49 ruoso left 13:56 masonkramer joined 14:08 rlb3 joined, dudulz joined 14:09 Guest23195 left
colomon jnthn: ping? 14:09
rakudo: my $a := pir::new('Parcel'); pir::push($a, 42); 14:10
p6eval rakudo d1015f: OUTPUT«PackFile_unpack: This Parrot cannot read bytecode files with version 8.2.␤␤PackFile header failed during unpack␤»
colomon oooo, stylish new error
jnthn oh noes p6eval is busted
colomon having a terrible time getting the parcel code to work in my new iterator. :\ 14:11
jnthn What're you seeing? 14:12
colomon I'll make a gist
gist.github.com/542357 14:13
ah, got it working by switching to $!value (instead of $parcel) 14:16
jnthn colomon: ah, OK 14:17
That'll be more efficient anyway, I suspect.
$.value = $parcel; is a method call 14:18
And also
has $.value;
You didn't declare it as having an rw accessor
So Rakudo is doing the right thing here.
14:18 rlb3 left
colomon okay, first new iterator version is actually slightly slower than the default gather / take .lines iterator 14:20
jnthn $.filehandle.get; # can use $!filehandle there too 14:21
colomon jnthn: already made that change, too. 14:22
:)
jnthn aww
colomon okay, if I make it off-spec and read two lines at a time in the iterator, I cut the read time from 22.9s to 17.2s
three lines at a time, 15.5s 14:23
LAST doesn't work yet, does it? 14:24
jnthn No, I don't think so. 14:25
colomon: How fast was the .get loop ooc?
14:26 justatheory joined, tadzik joined
colomon 7.2s 14:26
tadzik oh hai 14:27
jnthn OK, still quite some overhead.
Probably in building the objects.
colomon: This is naughty but how much faster is
method new($fh) { my $result = self.CREATE; pir::setattribute($result, '$!filehandle', $fh); $result; } and then pass it positionally in the call to .new 14:28
colomon jnthn: The opcode 'setattribute_p_p_p' (setattribute<3>) was not found. Check the type and number of the arguments 14:31
jnthn colomon: oh you'll have to specify the siggy 14:33
setattribute__PsP
colomon: Then we save all the BUILDALL/BUILD overhead. 14:34
I'm curious how significant that is.
colomon The opcode 'setattribute_p_s_p_p' (setattribute<4>) was not found. Check the type and number of the arguments 14:35
jnthn oh sorry 14:37
vPsP
Doesn't return anything
14:39 dju left 14:45 dju joined
TiMBuS do multi methods require signatures? 14:49
colomon jnthn: that's actually significantly slower
20s for the new version versus 15.5 for the old 14:50
jnthn wtf
14:51 REPLeffect left
jnthn TiMBuS: Well, writing one without a signature is like a candidate that only takes the invocant 14:51
e.g. multi method foo { ... } is the same as multi method foo() { ... }
TiMBuS oh ok then. i thought it would sort of become a 'default' method 14:52
jnthn TiMBuS: No. Mark it "is default" for that. 14:53
colomon jnthn: gist.github.com/542417 is the code. maybe I did something wrong?
jnthn colomon: That...really surprises me.
colomon: Let me look.
(Catching up some $dayjob here too... :-))
colomon trying to entertain my parents' puppy here... :) 14:54
jnthn colomon: Aww...is it cute? :-) 14:55
colomon: OK, that's what I was meaning...but I totally don't get why it'd be slower.
colomon yes, but incredibly full of energy
jnthn Puppys tend to be. :-)
colomon: That actually makes me want to benchmark a few more things because that result is extremely odd indeed. 14:58
colomon indeeed 14:59
gets back to our "nobody knows anything yet" thesis
jnthn It's going to be a lot easier to reason about a bunch of the performance when I've got an object model design that I have well mapped out in my head. 15:00
At the moment I find it hard to know exactly what's really happening in some cases.
This result is one of those cases.
colomon I just constructed a version which does eight-at-a-time iteration, and it's still not better than 15.8s. 15:03
(that's not using your new pessimization)
jnthn :S
15:10 justatheory left 15:13 wamba joined 15:14 dudulz left 15:19 Guest23195 joined 15:27 Su-Shee joined
pmichaud good morning, #perl6 15:31
colomon o/
jnthn morning, pmichaud
tadzik good morning
colomon thanks for the .chomp optimization last night.
pmichaud sure 15:37
I can rewrite that without Q:PIR, fwiw -- I just did the quick-and-dirty version to see the performance improvement. 15:38
at some point I suspect we may want to replace Q:PIR and pir:: with nqp:: equivalents (more)
15:39 xinming_ joined
pmichaud for example, we might replace the entire chomp method with nqp::chomp(self) 15:39
15:39 xinming left
pmichaud and then nqp takes care of providing an optimal version of chomp 15:39
then we just figure out what basic operations we need in nqp :-)
which eventually tells us what basic opcodes we really need from Parrot / $othervm 15:40
colomon sounds like a very sensible approach 15:43
15:43 Trashlord left, masonkramer left 15:44 Trashlord joined 15:46 artcoder joined
jnthn pmichaud: The 6model prototype already supports nqp::op; at the moment by a PAST::Op with :pasttype('nqpop') 15:49
pmichaud jnthn: +1
15:50 justatheory joined, bbkr left
colomon lolibloggedagain: justrakudoit.wordpress.com/2010/08/21/157/ 15:51
jnthn Whoa!
colomon is an epic blogger!
15:51 artcoder left
pmichaud colomon: "where it leaves us" is that the current IO impleemntation is wrong. IO needs to become an iterator 15:53
then .lines will just be .list
i.e.,: method lines() { self.list; }
then reify ends up being a method on the IO object itself 15:54
and it can do whatever buffering it wants
tadzik colomon: how to do you time this tests? 'time perl6 code.pl'?
colomon pmichaud: A) you mean a non-perl-6 iterator? I don't see how a pure p6 iterator can be faster, other than rewriting IO substantially. 15:55
pmichaud colomon: it can be done as a pure p6 iterator
colomon pmichaud: errr... actually, I think A) ate B).
pmichaud and yes, "rewrite IO substantially" has t ohappen anyway 15:56
colomon tadzik: yes 15:57
tadzik: it's not super-precise, but it seems to work fairly well with big enough loops to drown out the start-up time
tadzik colomon: tried Benchmark maybe?
colomon tadzik: nope 15:58
tadzik it was green on the test results, iirc, but it also has no tests, iirc
I wonder if it works 15:59
jnthn afk, walk 16:02
16:04 hudnix left 16:05 Mowah joined 16:10 hudnix joined 16:16 justatheory left
colomon pmichaud: okay, here's what I don't understand about this inner IO iterator idea. 16:23
TiMBuS pmichaud, did you ever push the fix for .hash and co? i think it just bit me again
colomon the hypothetical problem (as I understand it) is that the current .lines iterator can only go one-at-a-time so calls to .get can be interleaved. 16:24
I don't see how having an inner Iterator that .lines and .get both reference helps that at all. 16:25
16:25 artcoder joined
TimToady isa iterator, not hasa iterator 16:26
otoh, if we added a .line method, we could remain agnostic on that subject
colomon but if the inner iterator goes N-at-a-time, then you'll need yet another iterator for .lines so it works correctly, won't you? 16:27
pmichaud mentioned implementing .lines as just .list on the inner iterator, but in that case everything that .get gets while also be in .lines. 16:28
TimToady the question is whether the handle IS that inner iterator with decorations
16:29 artcoder left
TimToady then there's only one iterator 16:29
colomon but that iterator still cannot buffer lines, can it? (it might buffer raw text which has not been broken into lines, of course.) 16:30
TimToady the unreified list could do the text buffering, methinks 16:32
colomon I'm not saying this well.
TimToady and when you reify to lines it just happens to come in whatever the current text buffer gives you sized batches
one think we'll have to think about is seeking 16:33
it's possible that IO merely *does* Iterator
colomon What I'm trying to say is .lines cannot be the same iterator that .get is using for its source data
TimToady I don't see it
but that could be insufficient caffienation 16:34
colomon because if you do $a = $*IN.lines; $a.shift; $a.shift; $*IN.get; $a.shift;
$a is a list which contains lines 1, 2, and 4
that cannot be generated by the same iterator which generates lines 1, 2, 3, and 4 16:35
16:35 tylercurtis joined
colomon afk # noms 16:35
16:35 dju left
TimToady not a problem if .lines just means .flat, and is otherwise a no-op 16:37
TiMBuS rakudo: class foo { has $.state }; foo.new('state' => 5).state.say 16:38
p6eval rakudo d1015f: OUTPUT«PackFile_unpack: This Parrot cannot read bytecode files with version 8.2.␤␤PackFile header failed during unpack␤»
TiMBuS O___o
tadzik yeah... 16:39
TiMBuS well that seems to print Any
which sucks
16:40 dju joined
TiMBuS and i cant use unquoted (state => thing) 16:40
argh
tadzik state seems something special 16:41
TimToady try :state(thing)
tadzik works then. But something seems broken
TimToady rakudo: say (state => 42).perl 16:42
p6eval rakudo d1015f: OUTPUT«PackFile_unpack: This Parrot cannot read bytecode files with version 8.2.␤␤PackFile header failed during unpack␤»
TimToady std: say (state => 42).perl
p6eval std 32078: OUTPUT«ok 00:01 116m␤»
tadzik star: say (state => 42).perl
TiMBuS using state alone causes parsebug, i think its known
p6eval star 2010.07: OUTPUT«===SORRY!===␤Malformed state at line 22, near "=> 42).per"␤»
TimToady yes, it's not autoquoting before =>
probably an LTM failure, since the whitespace isn't constant 16:44
16:45 zulon joined
TimToady so rakudo is LTMing on <identifier> rather than <identifier> \h* '=>' as STD is 16:45
which results in a tie, which is resolved the wrong direction 16:46
pmichaud rakudo doesn't know how to ltm on quantified things yet
so the \h* causes issues
TimToady std: state␤=> 42; # might also fail 16:47
p6eval std 32078: OUTPUT«===SORRY!===␤Malformed state at /tmp/aVmyvkNv1X line 2:␤------> <BOL>⏏=> 42; # might also fail␤ expecting any of:␤ scoped declarator␤ statement end␤ statement list␤Parse failed␤FAILED 00:01 114m␤»
TiMBuS another spike i just stepped on: why does warn throw an exception? warn doesnt seem very exceptional..
pmichaud TiMBuS: so it can be caught and suppressed
TimToady exceptions are merely looking up the stack for handlers, and do not by themselves do flow control 16:48
pmichaud what a lower-level layer thinks deserves a warning might be "no problem" to a higher-level layer
TiMBuS i guess ill wait for the exception overhaul before trying to deal with that
TimToady don't think of them as quite so violent
exceptions are really just questioning your context for what you should do now
the actaul stack unwind happens when some exception handler decides to do that 16:49
or doesn't decide to, in the case of a warning
TiMBuS how do you filter out what you want 16:50
16:54 mberends joined 16:59 lmistura joined
jnthn TiMBuS: Generally, CATCH { when ... { ... } } 17:01
TiMBuS: If no when accepts it, then it's re-thrown. 17:02
TimToady warnings should go to CONTROL, by spec
TiMBuS i guess i mean, when 'what'? what is a warning 17:04
this probably has something to do with what moritz_ is working on.. 17:05
TimToady S04:1149 describes the mechanism, but we don't have an exception hierarchy defined yet
presumably there's an X::Warning that splits up into finer gradations 17:06
pmichaud I think moritz_++ was looking to work on the exceptions model 17:07
jnthn Aye
lmistura Hello! Im new to this wonderful perl6 language. Im wondering if it is possible to loop thru hexadecimal values in foreach and print unicode chars of this codepoint?
pmichaud lmistura: for 0x41..0x5a { .chr.say } 17:08
rakudo: for 0x41..0x5a { .chr.say }
p6eval rakudo d1015f: OUTPUT«PackFile_unpack: This Parrot cannot read bytecode files with version 8.2.␤␤PackFile header failed during unpack␤»
pmichaud grrrr
lmistura: yes.
tylercurtis star: for 0x41..0x51 { .chr.say }
p6eval star 2010.07: OUTPUT«A␤B␤C␤D␤E␤F␤G␤H␤I␤J␤K␤L␤M␤N␤O␤P␤Q␤»
pmichaud \o/
jnthn Oh yay, that one works. :-) 17:09
pmichaud star: for 0xa0..0xbf { .chr.say; }
p6eval star 2010.07: OUTPUT«\xA0␤\xA1␤\xA2␤\xA3␤\xA4␤\xA5␤\xA6␤\xA7␤\xA8␤\xA9␤\xAA␤\xAB␤\xAC␤\xAD␤\xAE␤\xAF␤\xB0␤\xB1␤\xB2␤\xB3␤\xB4␤\xB5␤\xB6␤\xB7␤\xB8␤\xB9␤\xBA␤\xBB␤\xBC␤\xBD␤\xBE␤\xBF␤»
pmichaud grrr
(it works locally)
> for 0xa0..0xbf { .chr.print }; say '';
 ¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿
moritz_ TiMBuS: I'm thinkiong about some parts of the execption model, but the interaction of warnings, errors and control exceptions aren't what I work on 17:10
TiMBuS oh ok
17:18 Trashlord left 17:19 thebird left 17:21 thebird joined
lue good $*TIME everybody o/ [morning for me :)] 17:22
tadzik looks like TIME is not really global ;) 17:25
tylercurtis lue: don't you mean good DateTime.new(now)? :)
lue please tell me HyperWhatevers are useful beyond array sizes.
tylercurtis: I know, but I thought a global variable looked cooler :) 17:26
17:27 thebird left
lue rakudo: my @a[**]; 17:28
p6eval rakudo d1015f: OUTPUT«PackFile_unpack: This Parrot cannot read bytecode files with version 8.2.␤␤PackFile header failed during unpack␤»
tylercurtis lue: It might look nicer than a simple map in a chain of feeds. 17:29
lue they are nyi, and I thought it'd be fun to see if I could implement them :) 17:30
When modifying rakudo, do I need to do anything more than make a branch locally? 17:33
17:34 pmurias joined
pmurias hi 17:34
lue hi o/
tylercurtis lue: here's a simple test case for you: my @a = 1..50; @a ==> grep * %% 2 ==> **.say 17:35
tadzik lue: why to make a branch locally?
(I never did this actually)
tylercurtis thinks that should work. 17:36
lue I did that last time, just wondering if there's anything else I have to do to modify rakudo "properly"
[that and last time I didn't use a branch I messed up and had to redownload rakudo :(]
std: my @a = 1..50; @a ==> grep * % 2 ==> **.say # just checking 17:37
p6eval std 32078: OUTPUT«ok 00:03 118m␤»
tylercurtis rakudo: (1..10) ==> { @_.map: *.say } 17:38
p6eval rakudo d1015f: OUTPUT«PackFile_unpack: This Parrot cannot read bytecode files with version 8.2.␤␤PackFile header failed during unpack␤»
tylercurtis star: (1..10) ==> { @_.map: *.say } 17:39
p6eval star 2010.07: OUTPUT«===SORRY!===␤Sorry, do not know how to handle this case of a feed operator yet. at line 22, near " { @_.map:"␤»
lmistura pmichaud: thanks a lot!
tylercurtis Aww. :( I guess that either won't work in Rakudo yet or possibly shouldn't work.
17:40 tadzik left
pmichaud star: (1..10) ==> map( *.say ) 17:41
p6eval star 2010.07: ( no output )
pmichaud star: sink (1..10) ==> map( *.say )
p6eval star 2010.07: OUTPUT«1␤2␤3␤4␤5␤6␤7␤8␤9␤10␤»
pmichaud tylercurtis: ^^^
mberends lue: if you can afford another 400MB in your file system, it is easier to have two Rakudo clones in separate directories. 17:42
tylercurtis pmichaud: I'm wondering about whether feeding to a block should work, since that was the first non-array-slicing use case that came to my mind for HyperWhatever. 17:43
pmichaud star: sink (1..10) ==> -> *@_ { @_.map( *.say ); }
p6eval star 2010.07: OUTPUT«===SORRY!===␤Sorry, do not know how to handle this case of a feed operator yet. at line 22, near " -> *@_ { "␤»
pmichaud hmmmm
I'm surprised. 17:44
star: sink (1..10) ==> sub (*@_) { @_.map( *.say ); }
p6eval star 2010.07: OUTPUT«===SORRY!===␤Sorry, do not know how to handle this case of a feed operator yet. at line 22, near " sub (*@_)"␤»
lue I get the feeling there's more to Whatever than what's in core/Whatever.pm and core/WhateverCode.pm . 17:45
17:45 rurban joined
jnthn pmichaud: Feed operators really don't know how to handle much yet. 17:46
pmichaud lue: most of it is in Actions.pm, since it's compile-time
jnthn pmichaud: There's lots to add.
pmichaud gotta go here -- bbl
sorear good * #perl6 17:47
jnthn o/ sorear
17:49 zulon left
sorear TimToady: pmichaud: What blocks need $/ ? 17:49
17:50 Mowah left
sorear Alternatively, how should $/ interact with the if { } inlining optimization 17:50
if 1 { $f(); } # but what if $f is &[~~].assuming("foo", /(o)/) ? 17:51
lue O.o … How are you able to code the stuff in Actions.pm ? I bow to thee |o|
17:56 envi^home left
TimToady sorear: why can't you ask easy questions? :) 17:58
we've got the same issue with $! and $_ too
17:59 xinming joined, xinming_ left
TimToady maybe if we make a static determination/guess as to whether a dynamic var is used in the lexical scope you want to optimize away, we can suppress the creation of the var and the setting of it, since it's not there in the inlined scope (somehow)... 18:02
nearly all uses of $/ will be indicated by later ref to $/, $0, $<foo> etc.
likewise $! tends to be used explicitly, if at all 18:03
18:03 lmistura left
TimToady we already kinda know if $_ has been used 18:03
alternately, we have some way of embedding the inlined lexical scope and redirect various refs to alternate locations 18:04
so that if 1 { my $x } still scopes my $x properly somehow
in the limit that looks a lot like Perl 5's implementation of lexical scopes with a range of statements constraint 18:05
sorear I can handle if 1 { my $x } reasonably well
the trick is that $/ "is dynamic"
TimToady I think static analysis of use (not of setting) will have to do for that, and the user can say my $/ if necessary to force it 18:06
sorear my current implementation refuses to inline any block with a dynamic variable, so putting $/ in every block would be a killer
OK
TimToady if nobody uses $/ in the block, we can assume it needn't be set
jnthn Rakudo doesn't inline any blocks ATM either for this reason, fwiw. 18:07
18:07 justatheory joined
TimToady as quietfanatic just said over my shoulder, some things are less important than optimization 18:07
jnthn :-)
TimToady how to teach a construct not to set the wrong $/ without giving it a fake $/ is a tough nut though, unless we somehow scope a care/don'tcare bit for each dynamic var 18:09
one is almost tempted to suggest that such dynavars live on a stack somewhere separate from the lexpad 18:11
or the context pointer that points to the current lexpad can point to a piece of the outer lexpad, and that is saved/restored somehow around the inline--but that seems more fragile 18:12
in the limit, we could inline something and have no benefit because we're emulating everything that the call would do... :/
jnthn Make it work, get lots of test cases, then optimize. :-) 18:13
TimToady um...
jnthn TimToady: Having a large test suite is useful for indicating whether something is an optimization or a wrongtimization. :-) 18:15
TimToady ideally, you'd like to just reserve some extra space in the outer lexpad that is suitably labelled, and put the work on the $/ setter to make sure it finds the right one, which puts no overhead on the case that $/ is not set
18:16 justatheory left
TimToady the only extra overhead for the typical inline is to allocate 3 more slots 18:16
jnthn Hmm, sounds plausible. 18:18
TimToady then CALLER::<$_> would have to be a little smart to find the right $_
jnthn TimToady: allocate them but don't initialize them?
sorear Why is $_ dynamic?
I can understand $/ (Regex.ACCEPTS) and $! (fail) easily enough 18:19
TimToady so a signature can default to CALLER::<$_>
sorear mm 18:20
TimToady which really only the default sig for {} does these days
18:20 achromic left
sorear I thought the default sig for {} defaulted to OUTER::<$_> 18:20
TimToady ah, you're right
the only occurrence of that is a fossil ./S29-functions.pod: our Bool multi chroot ( Str $path = CALLER::<$_> ) 18:22
18:22 justatheory joined
TimToady arguably m/foo/ defaults to CALLER::<$_> though 18:22
sorear That's syntactic now
or I suppose it always was 18:23
TimToady I said it was arguable :)
sorear in Rakudo, $_ $/ $! are always initialized to OUTER::<$x>. Is this a spec thing, and how does it interact with $x being lazily created in OUTER?
TimToady lazily? 18:24
not sure what you mean by that 18:25
18:25 achromic joined
TimToady the intent of the spec is that those three are initialized to their OUTER upon entry, unless specifically bound otherwise 18:26
I'm wondering if we really need to keep dynamic vars on a separate stack, with a barrier that marks abstract stack frames, including inlined ones 18:28
or rather, keeps the names on a stack, with a disposition "this is really this $_ over in the lexpad", or "this isn't wanted by anyone" 18:29
then local refs to $_ stay straight to the lexpad 18:30
and only upscope references use the dynamic stack of dispositions
sorear I'm already planning to do sort-of that 18:31
TimToady it seems to me that this is more robust, insofar as you only have to manage the dispositions stack on real calls
sorear I've just been having a bit of trouble working it into my IR
I wonder if I could get away with saying, 18:32
"Bare and pointy blocks don't have their own $/ and $! unless you explicitly 'my' them"
TimToady or -> them 18:33
makes 'em a bit more thunky by default, I suppose you might say
well, other languages get away with stuff everything into the sub pad, so we might be able to get away with that. 18:35
*stuffing
and it's already the case that we have to be careful not to clobber $_ going into a .{} subscript block 18:36
and presumably one could just say sub {...} to get all the vars by default for blocks as terms 18:38
it's really tempting, but I feel like I need to let it rattle around a while before committing to it 18:39
it'll violate some of the expectations of P5 programmers, for one...
otoh, it gives a way for $/ etc to escape a block if the user wants it 18:40
another consideration is that, while this makes it easier to inline blocks, it doesn't help much for inlining functions, which we also need 18:41
and any mechanism for the latter might also work for the former
there's some relation to macros and lift there, if a function is to parasitize the (non)-caller's lexical scope 18:43
and there are relationships to wrappers that want to pretend they're not really in the call stack, as well as what to do about tailcall optimizations 18:45
TimToady is now wondering about a mileau in which $/ and $! are never set directly by a subcall, but merely scheduled to be set upon return 18:47
and an inlined call can throw that away when it doesn't want it 18:48
sort of a Go-ish notion that every routine returns both an in-band value and an out-of-band value, where the out-of-band value can set $! or $/ 18:49
18:49 rurban left
TimToady this doesn't help with ordinary dynvars, though, which likely want to be set *now* rather than at return 18:50
but $! and $/ really are more like return statuses. maybe we shouldn't think of them as dynvars at all 18:51
(just brainstorming, nobody panic please)
((well, don't panic unnecessarily)) 18:52
biab &
18:55 Su-Shee left 19:00 justatheory left 19:02 cmadsen1 is now known as cmadsen
dalek odel: b93266b | jnthn++ | dotnet/runtime/Metamodel/SharedTable.cs:
A few extra pieces in the STable (SC has always been there in my mental model; the ID is a tad speculative but likely to stay).
 19:03
odel: fabd625 | jnthn++ | dotnet/compiler/Grammar.pm:
Get JnthnNQP to parse protos.
pmurias sorear: if $/ and $! is not ues in a bare or pointy block can you determine that?
sorear I do not follow 19:04
pmurias why don't you want bare and pointy blocks not to have $/ and $!? 19:05
s/not// 19:06
sorear: if 1 {...} should turn into {...} 19:08
19:11 draxil left
pmurias sorear: i read through the backlog, and it seems i got a bit confused (plus my typing was really bad) 19:12
jnthn Oh no! 19:17
jnthn discovers PAST::Block.multi...
moritz_ what does it do? 19:18
jnthn Caters to Parrot multi-dispatch without too much thought to being general, by the looks of it. 19:19
moritz_ seems not to be used in rakudo
jnthn Right 19:20
sorear PAST::Block.multi is used only for tcurtis' work
it's not something you need to copy
jnthn Hmm. The whole way this was put into NQP seems to assume you'd only ever want types on multis...
sorear: Well, I should at lesat think about it a little before I lead NQP away from using it.
sorear pmurias: if 1 { ... } can turn into { ... }, but it can't turn into ... if there are any dynamic vars involved 19:21
jnthn figures he'll just do what he thinks is right and we can deprecate anything that doesn't fit with that 19:22
(NQP is certianly going to continue to support multi dispatch...it just can't look like this, nor can it use Parrot's multi dispatcher.)
(Not least because we need to move to the proto-decides model.) 19:24
And we need :D / :U supported deep too. 19:25
sorear Do you really have to make "0" falso 19:26
That's bitten me like, once a day
jnthn rakudo: say ?"0" 19:27
p6eval rakudo d1015f: OUTPUT«PackFile_unpack: This Parrot cannot read bytecode files with version 8.2.␤␤PackFile header failed during unpack␤»
jnthn star: say ?"0"
p6eval star 2010.07: OUTPUT«0␤»
jnthn sorear: It's spec afaik.
sorear: And it makes sense overall.
One of those DWIMmy things.
19:30 macroron joined 19:43 artcoder joined 19:45 ruoso joined
mberends dalek: what is JnthnNQP ? 19:47
moritz_ jnthn is not quote perl? 19:48
mberends ok, thanks moritz_
pmurias ruoso: hi
jnthn mberends: It's my experimental "branch" of NQP.
moritz_ rakudo: say "test" 19:51
p6eval rakudo : OUTPUT«test␤»
sorear jnthn: What is 'knowhow'? 19:53
19:53 draxil joined
jnthn sorear: Package declarator for a pure prototype 19:53
sorear What's a pure prototype?
jnthn sorear: It just has methods and (will have) attributes.
No idea about inheritance or anything like that.
Essentially, the simplest thing we might be able to call an object. 19:54
It's the primitive at the bottom of the meta-model in my prototype so far.
At some point I'll dig into writing knowhow ClassHOW { ... } which will specify how classes work. 19:55
pmichaud PCT::Block.multi was primarily used for bacek's work
jnthn (But I don't have enough other primitives to do so.)
pmichaud it's strictly a type-based multi, same as Parrot 19:56
we can introduce a new attribute/mechanism if we need one
jnthn pmichaud: *nod*
pmichaud: Aye, I'm still working out quite what we want.
pmichaud: Since we won't be using Parrot Class/Object, it follows that we won't be able to use Parrot's multi dispatch.
19:57 rurban joined
jnthn pmichaud: But since the idea was iiuc to make things written in NQP have multi dispatch, I suspect we can make the switchover quite transparent to users. 19:57
pmichaud bacek requested multi, and I'm fine with a type-based multi
how that translates to virtual machines or object systems... we'll have to work that out
jnthn pmichaud: I don't expect to put the constraints stuff into NQP. 19:58
pmichaud right
I think that belongs on the callable object anyway
jnthn pmichaud: I do expect to need the definedness flags.
pmichaud I'm fine with the definedness flags being there.
we can certainly figure out how to make that work.
jnthn pmichaud: Anyway, I'll prototype it in 6model 19:59
pmichaud: It's easier to play around with ideas there. :-)
pmichaud ($/ is context) I'm very open for new models here... just remember that there are some cases (e.g. .match) where it's not statically obvious that $/ is being used or set.
jnthn I think I've worked out how to make an efficient multi-dispatch cache too (e.g. rather better than the one we have today). 20:00
pmichaud jnthn++
pmichaud goes back to re-read backscroll, for comprehension this time
TimToady: for verification -- <before> is a parsefail because the parser recognizes 'before' specially? 20:01
TimToady yes
pmichaud okay
tnx
TimToady std: / <normal> <before> /
p6eval std : ( no output )
TimToady huh 20:02
pmichaud does <before pattern> still capture to $<before> ?
TimToady presumably
pmichaud okay.
TimToady no std eval either...
moritz_ std: 1 20:03
p6eval std 32078: OUTPUT«ok 00:01 114m␤»
TimToady std: / <normal> <before> /
p6eval std 32078: OUTPUT«===SORRY!===␤before requires an argument at /tmp/d4NQdvh0TF line 1:␤------> / <normal> <before⏏> /␤ expecting assertion␤Parse failed␤FAILED 00:01 116m␤»
moritz_ std: / <after> /
p6eval std 32078: OUTPUT«===SORRY!===␤after requires an argument at /tmp/2Zy8cs8a9S line 1:␤------> / <after⏏> /␤ expecting assertion␤Parse failed␤FAILED 00:01 116m␤»
TimToady I might be okay with .match not setting $/
moritz_ how about m:g// ? 20:04
rakudo: 'abc'.match(/.+/); say $/
p6eval rakudo : OUTPUT«Any()␤»
TimToady rakudo: $/ = 'abc'.match(/.+/); say $/
p6eval rakudo : OUTPUT«abc␤»
TimToady looks like it already doesn't :) 20:05
pmichaud if .match/.subst doesn't set $/, how does .subst( /(pattern)/, { $0.uc } )
work?
(I know that $/ doesn't work right in rakudo now.... I've been working out how to get $/ to work
TimToady we could continue with the current workaround, on the assumption that people won't use the form if s/// works most of the time
pmichaud the current workaround? 20:06
hmmmm
TimToady -> $/ { $0.uc }
pmichaud oh, and make that the official way to do it?
masak really? :(
TimToady mebbe
moritz_ it would make life for the implementor easier 20:07
masak it would suck.
moritz_ but it would make it harder for the user to use the non-inplace form
jnthn Oh no I feel like we're not being tormented enough!
;-)
TimToady it's not clear where rx// sits in all this though
moritz_ I've kinda come to like the non-inplace form
TimToady nodnod 20:08
still just trying to find a sweet spot
pmichaud especially since p5 has recently been touting that it finally has a non-inplace form :)
moritz_ I think we need a way to supply a default $/ to a closure
TimToady alternately, .subst needs some magical way to inject $/
moritz_ that way both the method and syntacticall form could be made to work 20:09
named manybe? add an implicit :$/ = OUTER::<$/> ?
to every block
sorear wants a fast command line 'comb' tool 20:10
pmichaud well, since part of the point (I think) is to try to reduce the number of lexicals defined in every block... that doesn't seem to resolve that.
sorear: ...ack?
20:11 jferrero joined
pmichaud e.g., "ack -o" ? 20:11
TimToady it would also be difficult to explain to people why bare /(foo)/ sets $/ but func(/(foo)/) doesn't
moritz_ pmichaud: I agree it's a heavy-weight solution
20:12 masak left
sorear pmichaud: ack really isn't a pipeline-friendly tool 20:14
though I can make it work for now
pmurias ack6 would be great
TimToady it's too slow :P 20:15
pmichaud ...what TimToady++ said
sorear said "fast command line 'comb'".... and p6 doesn't have that feature yet :)
TimToady parrot really, really, really needs a good profiler 20:16
pmichaud although ./perl6 -e '$*ARGFILES.comb(/xyz/)>>.say' ought to be a reasonable first approximation
(might need a .slurp there)
TimToady: (profiler) I agree 20:17
jnthn +1
sorear jnthn: I get the tormentation, you get the fame. Don't complain.
jnthn I've been using Redgate's profiler while hacking on 6model and it's been extremely valuable.
pmichaud chromatic++ put in a proposal for one last year, and rdice++ turned it down in spite of me arguing strenuously for it 20:18
sorear rdice?
pmichaud TPF president; the one who basically got the Hague Grants going
jnthn sorear: I'm currently working out how to re-do multi-dispatch having already been and done it in a way I thought was pretty decent once. I'm somewhat tormented too. :P
pmichaud (former TPF president until last summer)
I'm sure there's plenty of torment being spread around :) 20:19
jnthn Talking of which, JnthnNQP just told me "multi cannot be declared without a proto in scope" :-)
Progress... :-)
pmichaud I think it should be JNQP
jnthn "progress"
pmichaud :-)
jnthn :P
pmichaud "Just Not Quite Perl". 20:20
jnthn pmichaud: I hope it won't last long...
pmichaud: Tssk...why'd I not give it a short name :-)
pmichaud ah, having a longer name helps make it more temporary?
jnthn pmichaud: Yeah, I'll get sick of typing it. ;-)
pmichaud in that case, I'm all in favor of JonathanWorthingtonNQPReplacement
s/Replacement/Upgrade/
jnthn pmichaud: :P
pmichaud: I did note that if I follow your ng example, then "new object model" => nom, or just no :-) 20:21
20:21 achromic left
pmichaud cooooooool 20:21
jnthn "Where's the new object model work?" "no"
sorear is feeling slightly upstaged
pmichaud I like "nom"
moritz_ nom +1 20:22
pmichaud sorear: ...upstaged?
20:22 jferrero left
TimToady
.oO(the opera's not over till the Fat Parrot croaks...)
 20:23
pmichaud croaking we have down pretty well already.
TimToady is still thinking about $/ on sorear++'s behalf 20:24
pmichaud TimToady: I'm happy to let you think about it on all of our behalfs :-) 20:25
I'd also be really happy to find a way to not create a new $! and $/ in every block
(as a general case, not strictly as an optimization) 20:26
dalek ecza: 2372c12 | sorear++ | src/Niecza/Actions.pm:
Fix tribble parsing again
ecza: 120cf42 | sorear++ | .gitignore:
Add *.bc to gitignore, git mono leaves them lying around
ecza: d186587 | sorear++ | src/ (2 files):
Finish parsing character classes
20:26 pmurias left
nine_ Current rakudo gives me a: PackFile_unpack: This Parrot cannot read bytecode files with version 8.2. This leads to a nice peak into the future: niner.name/rakudo/benchmarks.png 20:27
pmichaud nine_: you probably need to remove+rebuild parrot
huh, only 5% :-) 20:28
er, only 95%
jnthn nine_: lol, nice graph :-)
.oO( so all we have to do to optimize Rakudo is break the build? :-) )
nine_ Well, the graph is a bit ahead of time I think :)
moritz_ nine_: it means that you have some old .pbc files that broke rakudo
doing an rm -rf parrot parrot_install; make realclean; # and then building again should help 20:29
and the graphs will be much more useful if you filter out such anomalies
(I had the same build troubles on the p6eval server) 20:30
nine_ moritz_: many thanks. Trying again with a clean directory. 20:31
dalek kudo: 0c374d8 | cognominal++ | src/metamodel/GrammarHOW.pir:
fixes #77322 : changed sub compose in GrammarHOW.pir so that grammars always inherit from Grammar

Signed-off-by: Moritz Lenz [email@hidden.address]
20:32 risou joined
nine_ I think, I'm gonna do some measurements on how much jitter is to be expected in that graph anyway. 20:32
Would be nice to be able to be sure that rakudo really got 2.8% faster in the past three weeks :) 20:34
20:35 masak joined
pmichaud I'm somewhat curious about how the 2.8% result is obtained, though. 20:35
i.e., what is that graph really measuring?
20:36 fod joined
moritz_ relative execution times of tests that weren't changed between two runs 20:36
pmichaud right... over time I suspect that set gets smaller and smaller
and it's not tests but test *files*, yes?
moritz_ test files
nine_ it is test files, yes
But the set should not get smaller
pmichaud why souldn't it? tests change all of the time. 20:37
if we unfudge a test, we remove that test file from the set, right?
moritz_ yes, but only a roughly constant number of tests each day get changes
20:37 achromic joined
pmichaud so, those percentages are day-on-day changes, not overall changes? 20:37
moritz_ *changed
nine_ No, we just skip it for the one run. The next run will measure the difference to the new version of this test file
The percentages should fairly well represent the difference to the first run 20:38
pmichaud I'm not sure I agree with that.
I'm not sure I disagree, either.... it just feels like it might be making an invalid assumption somewhere. 20:39
moritz_ rakudo: grammar A { token TOP { <any> }; token any { 'foo' | 'bar' } }; say A.parse('foo')
p6eval rakudo d1015f: OUTPUT«Too many positional parameters passed; got 2 but expected 1␤ in 'Any::any' at line 1361:CORE.setting␤ in 'A::any' at line 22:/tmp/PUiWn8O0Uy␤ in 'A::TOP' at line 22:/tmp/PUiWn8O0Uy␤ in 'Grammar::parse' at line 5864:CORE.setting␤ in main program body at line
..22:/tmp/PUiWn8O0Uy␤»
moritz_ that's a bug, right? 20:40
pmichaud well, the grammar is overriding the .any method
nine_ What I do is simply comparing run time of test files between runs. I record the new run time and the new_run_time/last_run_time. The percentage in the graph is the sum of all these differences. If a test file got changed compared to the last run, I still recored the elapsed time, but assume 1 for the relative difference.
sorear really, the specsuite is a parser benchmark
moritz_ pmichaud: but it's not the overridden .any method that is called, right? 20:41
pmichaud moritz_: I'm still trying to figure out what's happening there.
nine_ sorear: well, that's certainly true since the tests themselves don't run that long...
pmichaud the trig tests run long, not strictly due to parsing. 20:42
20:42 offby1 joined
pmichaud but yes, as a general rule, parsing is still somewhat dominant. 20:42
[particle] can you turn all the tests to pbcs and then run them through parrot?
pmichaud we could turn them to .pir easily enough, yes. 20:43
last time I checked, there wasn't a significant difference between .pir and .pbc
or, counter-intuitively, the .pbc was actually slower than the .pir (e.g., for modules) 20:44
nine_ I'd have to have a closer look at test_summary.pl to do that, but I was planning on doing that anyway.
pmichaud moritz_: yes, I'm sure you can file it as a bug. 20:45
nine_ So what's the problem with the spec test progress graph anyway?
pmichaud test_summary.pl is no longer reporting the total number of spectests correctly (on my system)
nine_ Any idea where I could start digging into that problem? 20:46
pmichaud various things have changed underneath (and from people "improving" the output) that it no longer quite works the way it's supposed to
there's also a challenge in figuring out exactly what a git repository looks like as of a given date
since merging and rebasing "rewrite history a bit", going back to a previous time doesn't seem to work quite right. 20:47
(or I'm doing something wrong)
moritz_ nine_: look at the numbers for S32
there passing > total
pmichaud originally, test_summary.pl would keep track of the number of tests run in each file, and then try to extract the plan number from whatever files it didn't run 20:48
mberends nine_: you could improve the accuracy of test counts by replacing "plan *;" with actual test numbers, where these are stable.
pmichaud but various changes made to test_summary.pl seem to have broken that
and more and more of the test files have been written with "plan *;", which makes that guess even more inexact.
sorear really we should replace plan * with actual test numbers everywhere 20:49
requiring Whatever support in order to run tests does nobody any favors
moritz_ sorear: it only requires recognizing * as of type Whatever 20:50
20:50 risou left
pmichaud it's just a parameter/term there, so .... what moritz++ said 20:50
moritz_ no currying necessary
pmichaud it's not currying
but I agree in that I was never really a big fan of "plan *;" in the spectests.
I much preferred having the actual number present.
moritz_ well, if somebody steps up and volunteers to maintain the test counts...
nine_ 147 plan *; in t/spec 20:51
moritz_ I'd say that even without explicit test counts, maintaining the spectests is sufficiently hard work
20:51 cheep joined
cheep perl6: say 3; 20:53
p6eval pugs, rakudo d1015f: OUTPUT«3␤» 20:54
20:54 jferrero joined
mberends I'll volunteer to maintain test counts, but as a volunteer I'm at risk of not being up to date all the time. 20:55
pmichaud I have trouble seeing why maintaining the counts is hard (more) 20:56
if the count is wrong, you get a test failure that has to be fixed.
it's not like an incorrect count goes unnoticed.
I agree that it might be tedious/annoying to have to go back and update a count to get a file to pass, but that's different from it being difficult. 20:57
moritz_ if you rely on the number of tests you get from running the file, there's no need to put the count into the test file. 20:58
pmichaud ...unless you want a good count of how many overall tests we have.
anyway, I'm not opposed to "plan *;" to actually do anything about it :)
*opposed enough
so I'm fine if they stay. 20:59
moritz_ you get that from test_summary.pl too, if it works
pmichaud no
you get an *estimate* from test_summary.pl
because test_summary.pl can't say anything about the files it's unable to run
sorear really I think our tests should have more metadata in general
pmichaud (and that have "plan *;"
moritz_ sorear: and who would maintain them?
mberends our mindset seems to have been taken over by www.shadowcat.co.uk/blog/matt-s-tro...g-no_plan/
moritz_ pmichaud: I agree, but that doesn't explain our current problem 21:00
nine_ Well the cunning-no_plan is nice. Unless you'd like to know how many tests actually should get run :)
pmichaud moritz_: let's try to break down "our current problem" into its subproblems
so, what are our current problems we want to address?
(1) we'd like to have some measure of the total number of spectests at any given point in time 21:01
moritz_ currently, test_summary.pl gives passed > spec
pmichaud that's due to #1, I believe.
21:01 macroron left
pmichaud (1a) do we _really_ need to know the total number of tests? 21:01
moritz_ that's due to a bug in test_summary.pl 21:02
no
pmichaud I don't believe it's just a bug in test_summary.pl -- I think our tests prevent test_summary.pl from giving an accurate number.
if we accept that test_summary.pl simply estimates the count... then sure, I can go with that.
moritz_ it *is* a bug
its current design should never allow passed > spec
pmichaud fine. 21:03
I'll accept that. However, given that its current design is wrong, what do we want to propose to do about it?
do we really want to go back and re-calculate all of spectest-progress.csv ?
moritz_ pmichaud: what exactly is wrong about the current design?
pmichaud and would we have a mechanism for doing that anyway?
moritz_: I don't know what's wrong with the current design -- that's what I'm saying 21:04
when I wrote test_summary.pl, it was more accurate
but people have patched it while I was out such that it's no longer accurate
moritz_ I don't think anything is wrong with the current design - just with the implementaiton
pmichaud okay, then s/design/implementation then
if you ask me what's wrong with the current implementation -- I don't know. It used to work, it stopped working.
Others have patched test_summary.pl to try to do different things (or in different ways) -- I haven't reviewed those patches to see if any of them broke anything 21:05
I wasn't watching test_summary.pl to make sure that it was working correctly 100% of the time... because frankly I didn't have time earlier in the year to do it
moritz_ the time of the breakage was around colomon++'s trig test overhaul
tylercurtis rakudo: multi age-group ($age where * < 16) { "child" }; say "alive"
pmichaud I noticed problems as early as May
p6eval rakudo 0c374d: OUTPUT«===SORRY!===␤Malformed multi at line 22, near "age-group "␤»
tylercurtis Should that work? 21:06
jnthn multi age-group ($age where (* < 16)) { "child" }; say "alive"
moritz_ tylercurtis: I think you need a type constraint if you have a 'where'
pmichaud (I don't remember when the trig test overhault took place)
jnthn rakudo: multi age-group ($age where (* < 16)) { "child" }; say "alive"
std: multi age-group ($age where (* < 16)) { "child" }; say "alive"
p6eval rakudo 0c374d: OUTPUT«alive␤»
std 32078: OUTPUT«Potential difficulties:␤ $age is declared but not used at /tmp/lwHg7W9ZS7 line 1:␤------> multi age-group (⏏$age where (* < 16)) { "child" }; say "a␤ok 00:01 120m␤»
[particle] pmichaud: when ~10k tests were removed iirc
pmichaud [particle]: no, the problems actually were appearing before then. 21:07
tylercurtis std: multi age-group ($age where * < 16) { "child" }
jnthn tylercurtis: I think STD patched a precedence recently and Rakudo didn't catch up yet.
p6eval std 32078: OUTPUT«===SORRY!===␤Unable to parse signature at /tmp/JQ2zaFuHIw line 1:␤------> multi age-group ⏏($age where * < 16) { "child" }␤Couldn't find final ')'; gave up at /tmp/JQ2zaFuHIw line 1:␤------> multi age-group ($age where * ⏏< 16) {
..…
pmichaud I should rephrase
jnthn Oh, no, it hasn't
moritz_ rakudo: multi age-group(Numeric $age where (* < 16)) { say "child" }; age-group(4)
p6eval rakudo 0c374d: OUTPUT«child␤»
pmichaud the removal of the ~10K tests is when it became obvious that passing > tests
jnthn tylercurtis: I think TimToady++ mentioned at YAPC::EU that maybe those parens shoudln't be needed.
tylercurtis: But for now they are.
tylercurtis Alright.
pmichaud I think that before that point the counts were incorrect, but that it wasn't as obvious.
jnthn tylercurtis: If STD changes there, we can easily patch Rakudo though.
pmichaud I know that as early as May I started having difficulties with the test_summary.pl script not calculating things correctly. 21:08
moritz_ should we just remove the total count from the graphs?
pmichaud It's clear that the total count has been wrong at least since february
because clearly when we switched to ng, the total # of spectests didn't go down.
mberends I was responsible for earlier patches to test_summary.pl, but I was not aware of any counting bugs.
pmichaud but the graphs all seem to indicate that the size of the spectest suite somehow got dramatically smaller with the switch to the ng branch 21:09
which means it wasn't counting things correctly even then
moritz_ well, that's the limit of the current design
pmichaud so, that gets back to my other question
do we *need* the total number of spectests
and
moritz_ of supplying data for planless tests from actual runs
pmichaud is it worth the trouble to go back and recalculate history? 21:10
moritz_ no, and no (IMHO)
pmichaud the downside of not having the total is that the #1 question I get is "what percentage of the test suite do you pass?"
mberends recalculate automatically if possible, but not manually
pmichaud I mean, like, all the time.
No other question even comes close (except maybe "when will it be finished?") 21:11
moritz_ pmichaud: what exactly do we gain from knowing the percentage?
pmichaud moritz_: people just want to know that number. I don't know what they expect to gain from it.
21:11 risou joined
nine_ Since the spec test count seems to have never been that correct and most of all doesn't tell anything about how many tests there _will_ be when Perl 6 is finished, removing it seems to be no loss at all 21:11
moritz_ pmichaud: I'm fine with disappointing people on that number 21:12
21:12 milki left
pmichaud we still need a somewhat standard/good response to the question, though. 21:12
mberends people just want to do their own extrapolation to a finish date ;)
moritz_ "we don't know"
nine_ mberends: exactly!
pmichaud even if it's not a number.... it'd be good to have an answer that gives them what they are really looking for.
21:12 rurban left
pmichaud "we don't know" is too glib, and sounds like we're just not trying to measure (what they think is) a very useful metric. 21:13
moritz_ what we could tell them is the ratio of test files we run to the total number of test files
mberends is it correct that Perl 5 has about 350000 spectests?
[particle] moritz_: that's useless
moritz_ mberends: if you s/spec//, yes
[particle]: just as the number of tests
[particle] no, that's less useless
moritz_ I disagree
nine_ People want to know how much of Perl 6 Rakduo is and how soon it will be finished. But the total spec test count really doesn't answer either, since the spec test suite itself is not finished. 21:14
[particle] if you can count the number of tests, you can compare it to the number of tests in perl 5, or ruby, or python
pmichaud nine_: correct.
[particle] then you can ask questions like, "how complete is the p6 spectest suite?"
"how complete is the rakudo implementation, based on that?"
moritz_ [particle]: the number of trig tests show how useless such numbers and comparisons are
pmichaud [particle]: I don't think knowing that number in any way answers that other question
or even starts to lead to an answer 21:15
moritz_ if you have trig functions and solid numeric types, you get ~8k passing tests or so
nine_ So since the number we had was useless anyway, why not substitute it by an equally useless number that's simpler to get?
[particle] it's not purely quantitative
moritz_ probably ~20%
[particle] it's a measure of completeness, not the actual percentage
pmichaud it's not a measure of completeness, even.
moritz_ "a measure of" is as vague as you can get
[particle] s/measure/indicator/
moritz_ ok, you *can* get more vague, if you try
[particle] no, measure is a term for a piece of data 21:16
indicator is more vague.
pmichaud it's a number.
it doesn't have any good association with reality.
moritz_ ... of which you don't know the relation to the thing you actually want to know
dalek ecza: ad4148e | sorear++ | lib/Kernel.cs:
Change the responder interface to an abstract class

This allows the fallback implementations of methods to be shared. Rather suprisingly, this also triples the runtime speed of the testsuite.
ecza: 1801379 | sorear++ | / (2 files):
Cache the first four lexicals directly in the Frame

Saves 25K on the compiled testsuite in indirect lookups.
synth "guesstimate" ?
nine_ So what number could we give people that tells them that there is progress, but doesn't have to actually be useful?
[particle] ok, let's put it this way... it matters to people who may use rakudo
moritz_ synth++
pmichaud it doesn't measure completeness of the implementation, it measures completeness of the implementation relative to the diligence or level-of-detail given by the people who happened to write some spectests 21:17
[particle] correct, without proper test coverage analysis
moritz_ I find the number of available modules a far more interesting number for users
[particle] moritz_: that's another number which means nothing
pmichaud [particle]: I even given test coverage analysis, and that seems to have no impact.
*give
nine_ [particle]: it doesn't _have_ to mean anything to be able to satisfy people. 21:18
[particle] hey, look, there's 43 cgi-like pm6 modules based on nms
moritz_ [particle]: I disagree. It has rather direct impact on what the user can do, and what not
nine_ [particle]: that's the nice thing in marketing :)
[particle] moritz_: the count means nothing, it's the breadth of the modules, or their depth in a particular area.
moritz_ [particle]: fact is, most of our modules are not duplicates; many of our tests are.
which gives the number of modules a meaning
[particle] yes, but a single number can't differentiate the two 21:19
moritz_ yes
pmichaud (single number) I think that's our point :-)
[particle] yes, that's the point
pmichaud "percentage of passing tests" doesn't mean anything.
nine_ [particle]: 8367 authors 18234 modules on cpan.org. Means equally nothing, but still are very nice numbers to tell people. Usefull numbers for marketing.
[particle] but the number of modules matters more to moritz than the number of tests, because he has inherent knowledge that the number of modules is a better indicator of something
it's subjective 21:20
21:20 risou_ joined
[particle] nine_: agreed, it's marketing fodder 21:20
moritz_ probably that's related to me knowing the test suite rather well
pmichaud anyway, I think we're ratholing.
[particle] and so we should try to get an accurate test count
moritz_: indeed
nine_ [particle]: absolutely. The thing is: the total number of modules is far easier to guess than the total number of tests. Both may be useless for a user but both are good for marketing.
21:20 masak` joined
[particle] they're not that good for marketing on their own, anyway. 21:21
pmichaud [particle]: if you say we should try to get an accurate test count, should we do it historically as well?
nine_ nine_: so why not put up the number that's easy to get?
[particle] pmichaud: why? do it for rakudo *
start a new count.
pmichaud [particle]: because that number is hard to calculate.
if it were easy to calculate, no problem.
(and we wouldn't be having this discussion) 21:22
[particle] ok
so, ask for contributors to help with historic test counts
don't bother with it now
21:22 risou left
pmichaud how would you go about counting historic tests, ooc? 21:22
[particle] show the old charts as historic, and start a new chart that's more accurate
pmichaud if counting present-day tests is hard, counting historic ones is not much simpler.
[particle] well, they're in svn 21:23
nine_ People in #git confirm that getting a branch state exactly as of a certain time is pretty much impossible.
[particle] so checkout based on datetime
pmichaud the problem isn't in getting the historical view of the spectests
moritz_ nine_: which is a real pity
pmichaud the problem is in the *counting*
(historical pass rates) -- we could do monthly snapshots instead of daily.
i.e., just look at the numbers from the release tarballs. 21:24
[particle] the easiest way is probably to create a complete p6 compiler that's backwards compatible with previous versions of the perl 6 spec
no, wait, it might be easier to estimate, or have an intern count them.
pmichaud personally, I'd rather just do an ack to count the number of is/ok/isa_ok/whatever tests and use that as our estimate.
[particle] fun gsoc project ;)
pmichaud we know it'll be wrong for things like loops
[particle] sure, that's a fine way, use the algorithm fudge uses 21:25
pmichaud or, perhaps a version of fudge could be made .... right
21:25 masak left
[particle] at least then there's consistency in the toolsuite 21:25
pugssvn r32079 | moritz++ | [t/spec] more grammar inheritance tests, and fudge for rakudo
pmichaud anyway, at this point I'm generally in favor of discontinuing spectest-progress.csv altogether
or, at least making it not be daily snapshots 21:26
[particle] monthlies?
pmichaud (since we don't have any reliable way to reproduce/recalculate the results)
nine_ pmichaud: but a replacement would be very nice. This graph really helped in my opinion.
[particle] you ship t/spec with rakudo *, correct?
pmichaud nine_: oh, I think we need to have some measure of progress, definitely. 21:27
I'm just saying that spectest-progress isn't likely to be it anymore.
unless someone wants to go through a massive project or trying to correct the values for the past several months
*of trying
[particle]: ship t/spec with rakudo * -- not relevant.
nine_ btw. rakudo.org down? 21:28
pmichaud (at least, not significant)
[particle] pmichaud: it gives you a snapshot to do monthly test counts
masak` is playing Achilles-and-tortoise with today's backlog
21:28 masak` is now known as masak
pmichaud 21:23 <pmichaud> the problem is in the *counting* 21:28
getting a historical view of the spectests for any minute in time is *no problem*
(I've been doing that for a couple of years) 21:29
[particle] "tortoise and the hare" is the story's name (in america anyway), masak
masak [particle]: indeed. but that's a fable, and that's not what I meant. 21:30
sbp appears as Achilles and Tortoise in GEB I think...
21:30 offby1` joined
moritz_ I hope you know that's rooted in an ancient greek's philosopher's parabola 21:30
dalek kudo: 9288360 | moritz++ | t/spectest.data:
run grammar inheritance tests
moritz_ (at least the name)
masak [particle]: Lewis Carroll -- and before him Aesop and Zeno -- had it as "Achilles and the tortoise" 21:31
hm, maybe Aesop did have a hare.
sorear tortoise and hare and tortoise and Achilles are two very different problems
one of them is an Aesop about persistance and backstabbing
21:31 offby1 left
sorear the other is a thought experiment on the evils of the continuum 21:31
[particle] ah, i always knew it as zeno's paradox, but i guess he had more than one. 21:32
masak the continuum isn't too evil, it's just misunderstood.
[particle]: he had more than one. and I've heard his as having Achilles in it, not a hare.
moritz_ Zeno => Achilles, Aesop => hare 21:33
dalek odel: 1e62243 | jnthn++ | dotnet/compiler/Actions.pm:
Start refactoring multi-dispatch handling in the JnthnNQP actions towards the proto-in-control model.
[particle] masak: yes, so have i, i just never knew it by that name
sorear dreams of a spectest suite in a simply-parsable format with 30,000 blocks of text, each containing 1 test + fudge data
[particle] but now i know :)
masak if I ever get a hare, I'll name it Achilles :)
[particle] sorear: you imagine a test suite without loops?
masak sorear: what about several tests with the same buildup data? 21:34
pmichaud okay, so I have a mini-proposal of sorts
jnthn masak: Can you train a hare to come to heel, like a dog? ;-)
pmichaud (comments/reactions desired)
masak jnthn: that pun was so weak as to be almost imperceptible... :) 21:35
pmichaud 1. Create a p5 script that estimates the number of tests in the spectest suite
2. For scripts that have an unambiguous "plan \d+;" line in them, use that number.
3. For scripts that don't have an unambiguous plan, estimate based on number of is/ok/isa_ok/etc. lines, similar to fudge 21:36
4. Calculate the historical size of the test suite going back through May 2008, but do it weekly instead of daily
5. Switch rakudo to weekly estimates of spectest-progress 21:37
(daily is a bit much)
I can go back and recalculate Rakudo progress for 2010
masak pmichaud: you could do slightly better by handling the 'plan @tests * 2 + 7;' case, too. it usually involves counting commas in a literal list. may or may not be worth the trouble, though.
pmichaud masak: I'm thinking not worth the trouble. 21:38
masak the parsing would probably be fragile.
pmichaud right.
moritz_ pmichaud: I like your proposal; I'm just not sure if it's worth the effort
[particle] so, instead, make those failures for a human to deal with
or not deal with.
pmichaud moritz_: well, once the script to count spectest suite size is done, applying it historically on a weekly basis is easy (and fast) 21:39
I agree with nine_ that we really want to have some measure of progress
I'm open for alternate suggestions of that measure
[particle] "couldn't parse test count in t/spec/.../....t: plan @tests * 42 + @other_tests;"
pmichaud [particle]: ...and then do what?
[particle] chose to manually adjust the test count in some cached file? 21:40
masak sleeps
21:40 masak left
nine_ There are 7 test files containing computed test counts 21:40
pmichaud in some senses I think that "repeatable w/o manual intervention" is better than "accurate to the nth degree"
21:41 sftp left
[particle] nine_: today. historically, there may be more 21:41
pmichaud and the counts might have changed historically as well
21:41 offby1` is now known as offby1, offby1 left, offby1 joined
nine_ [particle]: but compared to 147 plan *; files it's not that much of an improvement 21:41
pmichaud so what @tests * 42 + $value evaluates to today might not be the same as a year ago.
moritz_ we can neglect those plans
they sum up to less than 1k 21:42
pmichaud right... "not worth the trouble" :-)
21:42 sftp joined
moritz_ and currently we have about 30k to 40k tests 21:42
21:42 offby1 left
moritz_ so, 3% error. Totally fine 21:42
pmichaud also, I think it might be worth maintaining the total count of spectests in the svn repository itself.
[particle] ok, so you could do a first order approximation by extrapolating in a straight line
pmichaud instead of having rakudo do it.
and that count could also be per-synopsis
moritz_ -> sleep 21:43
pmichaud then other implementations could query that table of "the official count"
nine_ sounds reasonable
pmichaud and we can also see where spectest coverage is lacking
(at least to a first approximation)
[particle] parsed 234 test files, count 43012: average tests/file=183.8. didn't parse 23 test files, extrapolated more 4228 tests 21:44
nine_ One thing is certain: the current graph does no good on rakudo.org. Nothing worse than a website that looks neglected, now that rakudo * is out
pmichaud well, it's only neglected for a few weeks, iirc :-)
that's hardly "neglected". It just means "not updated daily" 21:45
if it was months out of date, I'd feel differently.
nine_ pmichaud: sorry to say that, but if I come up with the word "neglected", others will too.
Unfortunately, marketing does not have anything to do with facts.
btw. rakudo.org down? 21:46
pmichaud appears to be
nine_ where's it hosted? 21:47
pmichaud alester's server 21:48
tylercurtis rakudo: sub foo($a) { True; }; subset Foo of Mu where -> $foo { foo($foo) }; say 5 ~~ Foo 21:57
p6eval rakudo 0c374d: OUTPUT«Could not find sub &foo␤ in <anon> at line 22:/tmp/Tr7Kia_sJE␤ in 'Block::ACCEPTS' at line 5775:CORE.setting␤ in 'infix:<~~>' at line 402:CORE.setting␤ in <anon> at line 1:/tmp/Tr7Kia_sJE␤ in 'Block::ACCEPTS' at line 5775:CORE.setting␤ in 'ACCEPTS' at line
..984:CORE.setting␤ …
tylercurtis rakudobug or bug in my code?
pmichaud I'd say rakudobug.
probably the same one that caused (causes) roles to not see lexical subs. 21:58
tylercurtis will search and submit if not already reported when he finishes what he's working on.
rakudo: say (16 < * < 66)(5) 22:04
p6eval rakudo 0c374d: OUTPUT«1␤»
tylercurtis rakudo: say 16 < 5 < 66
p6eval rakudo 0c374d: OUTPUT«0␤»
pmichaud bug.
(the first, not the second)
tylercurtis Right. Known? If not, I'll search and submit it as well, assuming it's not already reported. 22:05
pmichaud not known by me.
so, submit.
jnthn I've not seen that beofre
pmichaud (and thanks)
jnthn Not sure how it's happening. :-S
pmichaud I suspect the WhateverCode builder is acting a little too soon. 22:06
tylercurtis rakudo: say False < 6
p6eval rakudo 0c374d: OUTPUT«1␤»
22:06 cheep left
pmichaud i.e., it's probably parsing it as (16 < *) < 66 22:06
which isn't the same.
(i.e., it's creating a WhateverCode from the first <, and using that to create another WhateverCode from the < 66 22:07
jnthn pmichaud: Oh, that soundss feasible.
22:08 LionMadeOfLions joined
pmichaud chaining altogether probably needs a rethink/rework in Rakudo (and PCT) 22:08
but building a WhateverCode at the point of the infix is likely "premature"
jnthn works on a blawg post 22:09
22:10 artcoder left
gfldex can't wait to read it 22:12
pmichaud afk for a while 22:14
22:16 wamba left
mberends sleeps 22:18
22:18 mberends left
tylercurtis needs to either revive his old and never-really-posted-to blog or start a new one for this post. 22:25
Anyone have any suggestions for a good blog host? 22:29
jnthn I like hosted Wordpress so far. There's also blogs.perl.org.
lue ohai o/ 22:30
[Coke] ugh. one version shy on PARROT_version, have to do a full rebuild. :P
lue does anyone have a step-by-baby-step guide through Actions.pm? :D
(all the more incentive for me to create such a thing) 22:33
tylercurtis blogged: blogs.perl.org/users/tyler_curtis/2...patch.html 22:40
tylercurtis also didn't proofread before posting. :) 22:44
lue Ya' gotta love perl: tech.slashdot.org/story/10/08/21/14...es-of-Perl 22:45
22:50 Guest23195 left 22:51 jferrero left
lue tylercurtis++ # good blog post 22:53
23:02 colomon left
lue can't help but wonder how anyone managed to code Actions.pm 23:08
jnthn lue: It wasn't just one person. :-) 23:09
lue: If you want a simpler one to look at, see the Actions.pm of nqp-rx.
lue ok. I think it's that anyone trying to jump into it without some sort of reference or prior experience will be hopelessly lost. :) 23:13
jnthn lue: It's better to start in Grammar.pm. Read a rule that parses something. Understand what bits of information it captures. *Then* look at the action method that goes with it. 23:15
lue: Trying to understand the action methods in isolation to the data they're operating on is going to be rather harder. :-)
lue Alright. I got the crazy idea to try my hand at HyperWhatever's :) 23:17
tylercurtis lue: thanks. 23:18
lue (For some reason, Grammar.pm is visually less intimidating for me)
I don't think there's much of Whatever in Grammar.pm, so it helps me just a bit more than core/Whatever.pm :) 23:20
23:27 sftp left, sftp joined 23:34 sftp left 23:35 sftp joined
jnthn I blogged, and it's a long one: 6guts.wordpress.com/2010/08/22/raku...oad-ahead/ 23:39
sorear jnthn: I think my problem is that our goals have unexpectedly converged, and now I feel like I have no place. 23:44
jnthn sorear: In what sense? 23:49
sorear: I hope that I've not conveyed that you aren't welcome to help with efforts on Rakudo. You are. I also hope I haven't conveyed that having multiple implementations is a bad thing (I don't feel that way). I can sympathize that it's hard to get an implementation to the point where it attracts users, though. 23:52
sorear: If it's more than you looked at Rakudo and thought "oh, these things are wrong, I can do it right", but now Rakudo is heading in that direction too, then maybe I did a bad job at conveying that present Rakudo is the way it is for many reasons, but isn't the way that I think it should be in order to have a really good Perl 6 implementation. 23:54
23:54 artcoder joined 23:55 artcoder left 23:57 sftp left
lue [stupid question time] what is the purpose of the metamodel? I hear it plenty of times, but haven't been able to guess its purpose. 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!