Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6, 2010-08-21

Perl 6 | Reference Documentation | Rakudo

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 tylercurtis left #perl6
00:01 Psyche^ joined #perl6
00:04 drbean left #perl6
00:05 Patterner left #perl6
00:05 Psyche^ is now known as Patterner
00:22 pugssvn r32077 | lwall++ | [rx.t] <before> should be a parsefail
00:23 pugssvn r32078 | lwall++ | [STD] normspace should be optional before regex error or s/// doesn't fail right
00:23 TimToady std: s///
00:23 p6eval std 32076: OUTPUT«[31m===[0mSORRY![31m===[0m␤Regex not terminated at /tmp/JEEY2FH7xy line 1 (EOF):␤------> [32ms///[33m⏏[31m<EOL>[0m␤    expecting quantifier␤Undeclared routine:␤ 's' used at line 1␤Parse failed␤FAILED 00:01 118m␤»
00:24 jnthn ur failin it rong.
00:24 TimToady ayup.
00:25 TimToady it was requiring a normspace before figgering it out, which there ain't one in s///
00:25 jnthn Ah, yes.
00:25 TimToady someone (prolly me) was thinkin' that normspace could match '' like ws could
00:25 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.
00:26 jnthn Well, or hack stuff. :-)
00:26 ruoso joined #perl6
00:26 jnthn Turns out that I'm spending most of the time in expensive coercion methods.
00:27 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? :-)
00:27 jnthn 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.
00:28 jnthn *box it into
00:30 kid51 joined #perl6
00:30 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 jnthn *hand
00:31 jnthn This probably means it's time to work out how to write a proper multi dispatch cache.
00:32 colomon jnthn: look at how long it takes to read a 10,000 line text file.
00:32 jnthn colomon: ...in Rakudo?
00:32 colomon yes
00:33 jnthn Probably a lot longer than it should.
00:33 colomon well, yes
00:33 colomon but I'm investigating.
00:33 jnthn Would be interesting to know where we're spending time.
00:33 artcoder joined #perl6
00:33 jnthn I can't really express how much I love http://www.red-gate.com/produc​ts/ants_performance_profiler/
00:33 colomon oh, hey, there we go.  55s using "for $*IN.lines"
00:34 jnthn colomon: youch!
00:34 colomon are you using it for your experiment?  (does your experiment have a proper name I'm forgetting)
00:34 jnthn colomon: Yeah.
00:34 colomon sweet
00:34 sorear niecza can read any text file with O(1) overhead
00:34 jnthn colomon: My $dayjob company is actually a redgage partner.
00:35 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 ;-)
00:35 jnthn But this is using a lazy iterator over the file.
00:35 colomon next step: try writing it with just .get
00:36 colomon yes, about to find out how much overhead the lazy iterator causes
00:39 colomon 44s for the loop using $*IN.get
00:40 jnthn That's still insanely bad.
00:40 colomon so using the iterator adds 25% to the execution time.
00:40 colomon jnthn: very true.
00:40 tylercurtis joined #perl6
00:42 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.
00:42 jnthn colomon: Oh
00:43 jnthn colomon: get auto-chomps iirc
00:43 sorear .get has the "our loops and calling conventions take forever" excuse
00:43 jnthn colomon: Wonder if the chomp is what costs us so badly
00:43 colomon for reference, $*IN.slurp takes 5.5s.  that's still insanely slow, considering.  :(
00:44 jnthn *confused look*
00:44 colomon yeah, .get does autochomp, but surely that shouldn't shouldn't slow things down that badly, should it?
00:44 jnthn Maybe we could write a PIR benchmark to see how fast Parrot can actually slurp it in.
00:44 jnthn colomon: I wonder how chomp is implemented...
00:44 jnthn colomon: I see to remember, scarily.
00:45 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.
00:45 colomon jnthn__
00:45 colomon jnthn++
00:45 colomon having typing issues tonight.  I blame my brain.
00:46 pmichaud good evening
00:46 colomon o/
00:47 pmichaud I don't think that %h<foo> should flatten
00:47 colomon pmichaud: trying to time reading text.
00:47 pmichaud rakudo:   my %h = (abc => [1,2,3], def => 4);   for %h<abc def> -> $x { say $x.perl; }
00:47 p6eval rakudo 7b0031: OUTPUT«[1, 2, 3]␤4␤»
00:47 jnthn pmichaud: oh ffs
00:47 jnthn gah
00:48 jnthn colomon: offs
00:48 jnthn colomon: Reading a 10,000 line text file in *PIR* seems to take a few seconds
00:48 jnthn colomon: Let me send you the code to time it on the file you have
00:48 pmichaud is Parrot still suffering from insanely slow I/O?
00:48 jnthn http://gist.github.com/541540
00:49 jnthn colomon: ^^ and replace the foo.txt with the name of your file then just parrot x.pir
00:49 jnthn pmichaud: This doesn't look encouraging.
00:50 jnthn pmichaud: 2 seconds to read a 280 K file.
00:50 jnthn With the above gist.
00:52 colomon jnthn: I get 0.84s to read it using your PIR.
00:53 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?
00:54 jnthn http://gist.github.com/541544
00:54 colomon pmichaud: I get 0.84s to start up parrot and read the file.
00:54 jnthn colomon: ^^
00:54 jnthn pmichaud: Start up Parrot and read the file, but Parrot start-up is negligible.
00:54 jnthn pmichaud: Well, for a 2s runtime it is.
00:54 pmichaud okay
00:54 * pmichaud tries
00:54 pmichaud what are you using for foo.txt, ooc?
00:54 jnthn I - oddly - get a significantly faster read with reading each line individually
00:55 jnthn Rather than readall to read the lot at once. :/
00:55 jnthn pmichaud: it's a file with 10000 lines all containing "lol a line with text on it"
00:55 colomon woah, same here!
00:55 colomon 0.026s to read all 10001 lines.
00:56 jnthn ...so reading line by line is faster in Parrot than .readall?
00:56 colomon mine is about 20% Violet Jacob poems and the remainder core.pm
00:56 jnthn Are the poems valid Perl 6 too?
00:56 colomon jnthn: nope, too many Scottish words
00:56 dalek 6model: 7608b1b | jnthn++ | dotnet/ (3 files):
00:56 dalek 6model: Stop signature binding swamping the profile. At least one lesson to teach Rakudo's from this experience.
00:56 dalek 6model: review: http://github.com/jnthn/6model/commit/7​608b1ba6f2c55f3971a30323e9469f19bd4d992
00:57 colomon O Jean, my Jean, when the bell ca's the congregation
00:57 colomon Owre valley an' hill wi' the ding frae its iron mou',
00:57 colomon When a'body's thochts is set on his ain salvation,
00:57 colomon Mine's set on you.
00:57 jnthn Yeah, an' is not a valid identifier due to ending in the ' :-(
00:58 pmichaud heh
00:58 pmichaud readall in filehandle.pmc:
00:58 pmichaud do {
00:58 pmichaud STRING * const part = Parrot_io_reads(INTERP, SELF, 0);
00:58 pmichaud result = STRING_IS_NULL(result) ? part :
00:58 pmichaud Parrot_str_concat(INTERP, result, part);
00:58 pmichaud } while (!Parrot_io_eof(INTERP, SELF));
00:58 jnthn omfg
00:58 pmichaud 10000 string concatenations
00:58 jnthn Someone want to file TT? :-)
00:59 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.
01:00 colomon chomp does two regex compares with the line in the normal case.  :(
01:00 jnthn er, yes, I just found that
01:00 jnthn We...should find a rather better way to do that.
01:01 jnthn Doesn't Parrot have a chomp opcode anyway?
01:01 * colomon looks to pmichaud...
01:01 sorear 38 seconds to 'for $*IN.lines -> { }' Rakudo's core.pm
01:02 jnthn sorear: In Niczea?
01:02 jnthn Or Rakudo?
01:02 sorear in niecza
01:02 jnthn k
01:02 sorear testing rakudo on the same machine now
01:03 jnthn colomon: Anyway, this chomp is almost certainly one example of a builtin that wants re-doing efficiently.
01:03 synth joined #perl6
01:03 colomon jnthn: abso-effing-lutely
01:03 pmichaud Parrot has a chop opcode, but not a chomp
01:03 pmichaud still, chomp can be far more efficient than rakudo's setting.
01:04 jnthn pmichaud: Indeed.
01:04 pmichaud oh dear
01:04 pmichaud yes, this is horribly slow
01:04 jnthn I bet it's where we're spending most of our time.
01:05 pmichaud even a string compare would be far faster than this.
01:05 jnthn Right
01:05 colomon does it actually compare each character of the string as it goes?
01:05 pmichaud ??
01:06 colomon the regex
01:06 jnthn pmichaud: Is the regex engine smart about end anchoring?
01:06 pmichaud the regex engine doesn't know about end anchoring yet, no.
01:06 pmichaud it can be done, but... tuits
01:06 colomon jnthn++ for saying it properly
01:06 jnthn Ah, so it likely is walking through the whole string.
01:06 colomon yeah, that sounds massively bad.
01:06 pmichaud a utf8 string, at that.
01:07 jnthn We need to stop dealing with utf8 strings interally.
01:07 * colomon seems to have lost his Rakudo/src editor window.  :\
01:07 jnthn Maybe the NFG work of late will let us do that.
01:07 Juerd There are huge files in /tmp on feather
01:07 Juerd Made by www-data. They contain huge diffs.
01:07 jnthn Juerd: Don't try to read through them with Rakudo.
01:07 jnthn ;-)
01:08 pmichaud who's filing the TT on readall, if anyone?
01:08 Juerd Many are >100 MB
01:08 Juerd Could you please have a look and see if you know their origin?
01:08 jnthn pmichaud: Dunno if anyone volunteered yet?
01:08 pmichaud I'll do it.
01:08 jnthn pmichaud: Thanks
01:09 * Juerd doesn't know what kind of web thing creates this kind of enormous diffs
01:09 jnthn http://gist.github.com/541544 and http://gist.github.com/541540 are the examples
01:09 Holy_Cow joined #perl6
01:11 colomon is our chomp even right?
01:11 jnthn Juerd: I get permission denied when trying to look
01:11 Holy_Cow left #perl6
01:11 jnthn Juerd: Oh, looking at their chomod'ing I would.
01:12 jnthn 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.
01:12 jnthn No
01:13 Juerd The mtimes coincide with access_log entries for REPORT requests on SVN
01:14 Juerd 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 Juerd We've had huge memory leaks (still have them), and now it turns out to put stuff in /tmp and never clean that. :(
01:15 Juerd Anyway. Cause found. Removing junk from /tmp.
01:16 pmichaud jnthn, colomon:  http://trac.parrot.org/parrot/ticket/1749
01:16 colomon pmichaud++
01:17 jnthn pmichaud++ # thanks
01:17 * pmichaud prepares to sadly part with his shiny new Nexus One
01:17 Juerd 15 GB deleted from feathers /tmp
01:17 jnthn pmichaud: Oh?
01:17 colomon pmichaud: why?
01:17 pmichaud well, it's the 'extra' one I got from Google at OSCON (more)
01:17 * colomon updated his Droid to 2.2 this morning.  o/
01:18 pmichaud daughter was promised a smartphone if she did well academically last year, and she pulled it off.
01:18 pmichaud rather than buy a new smartphone for her, my 'extra' gets to be hers.
01:18 Juerd What kind is your primary smartphone?
01:18 pmichaud A Nexus One.  :-)
01:18 pmichaud but I liked having a spare :)
01:18 Juerd That's okay then, you'll still have infinite awesomeness.
01:19 Juerd You had double infinity, which wasn't useful anyway :)
01:19 * jnthn only has a dumbphone
01:19 pmichaud also, it was going to be nice to have an extra to do some development on, someday (hopefully not too long away)
01:19 * Juerd has the HTC Desire, which is almost identical
01:20 Juerd 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:30 * jnthn -> sleep
01:32 colomon 'night
01:36 sorear If $/ in a regex refers to the cursor, what's the point of $¢?
01:37 sorear How do I check what version of Rakudo I have installed?
01:38 sorear perl6 -v only gives the Parrot version (47723)
01:39 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
01:39 sorear ping me when it can be built in <400MiB
01:42 jferrero left #perl6
01:42 artcoder left #perl6
01:44 gfx joined #perl6
01:52 colomon left #perl6
01:54 sorear nevermind, found the answer.
02:02 * flyback heading to the store, bbl
02:06 shade_ left #perl6
02:14 sorear When, precisely, does a sub need to contain 'my $/ is context'?
02:24 dalek niecza: 8513447 | sorear++ | src/Niecza/Actions.pm:
02:24 dalek niecza: Parsing for <?> etc
02:24 dalek niecza: review: http://github.com/sorear/niecza/commit/8​5134471a6b7c7481124d29be8bf84e8e4f9aab2
02:24 dalek niecza: 36516a9 | sorear++ | lib/Kernel.cs:
02:24 dalek niecza: Readonly binding should strip containers
02:24 dalek niecza: review: http://github.com/sorear/niecza/commit/3​6516a9e8174b03c482d5fae62059a82f4fa58e4
02:24 dalek niecza: 5de4fa0 | sorear++ | test2.pl:
02:24 dalek niecza: Test for ro binding
02:24 dalek niecza: review: http://github.com/sorear/niecza/commit/5​de4fa0dc3e0c2d1059a572b87cd10c446275899
02:34 azert0x left #perl6
02:34 shade_ joined #perl6
02:53 risou left #perl6
02:58 sorear Rakudo puts my $/ is context = OUTER::<$/>; in every single block
02:58 sorear I don't like that for Niecza, since 'is context' variables are not cheap
03:02 pmichaud changing .chomp to PIR reduces the time needed to do 'for $*IN.lines' on my system from 75s to 21s
03:03 pmichaud (on a 10,000 line input file)
03:03 pmichaud running 'make spectest' now.
03:06 araujo left #perl6
03:06 araujo joined #perl6
03:12 justatheory left #perl6
03:15 pmichaud omg
03:15 pmichaud I just realized that PCT::HLLCompiler uses .readall to read in source files
03:15 pmichaud which means we pay a penalty when reading, say, core.pm (~7000 lines)
03:16 * pmichaud updates the TT with this information.
03:17 alester joined #perl6
03:17 pmichaud oh, wait.
03:18 pmichaud we use the .readall('filename') form, which is much faster than the .'readall'() form on an already-opened filehande
03:18 pmichaud so it's probably not as expensive.
03:19 sorear open("/path/to/core.pm").slurp takes 1.4 seconds locally
03:19 sorear generating core.pir takes 400 seconds
03:20 sorear 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
03:20 pmichaud i.e., reading a 7000-line file creates 7000 string objects
03:20 pmichaud (more, since it's doing concats on each pair)
03:21 sorear won't they all get eliminated on the first GC?
03:21 pmichaud yes, but given how slow our gc is....
03:21 sorear how can I force a GC from Perl6 to test?
03:21 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
03:22 pmichaud it's not like I think this is going to cut our compile time by half
03:23 kid51 left #perl6
03:24 * flyback rummadges thru his piles of old pc parts to find a good canadate for a flashrom programmer motherboard
03:29 * sorear is toying with the idea of abandoning static code generation for regexes
03:29 kid51 joined #perl6
03:29 artcoder joined #perl6
03:36 dalek rakudo: 03a9388 | pmichaud++ | build/PARROT_REVISION:
03:36 dalek rakudo: Bump PARROT_REVISION to get && in regexes.
03:36 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​3a9388c127d14547496ba05abf867bd03425d27
03:36 dalek rakudo: 1996bac | pmichaud++ | src/Perl6/Grammar.pm:
03:36 dalek rakudo: Refactor <.dumbsmart> rule.
03:36 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​996bacea349965ca5116ffe864432a2804e29ce
03:36 dalek rakudo: d1015f0 | pmichaud++ | src/core/Cool-str.pm:
03:36 dalek rakudo: 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:36 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​1015f0a7bfe4fc0e6435a261426a3735ffa7aec
03:43 flyback left #perl6
03:44 xinming_ joined #perl6
03:48 xinming left #perl6
03:48 REPLeffect left #perl6
03:50 kid51 left #perl6
03:56 Italian_Plumber left #perl6
04:02 REPLeffect joined #perl6
04:03 jaldhar joined #perl6
04:03 artcoder left #perl6
04:13 hercynium left #perl6
04:24 gfx left #perl6
04:24 masonkramer joined #perl6
04:24 risou joined #perl6
04:24 dduncan joined #perl6
04:25 dduncan left #perl6
04:31 risou left #perl6
04:32 HarryS left #perl6
04:58 xinming joined #perl6
05:01 xinming_ left #perl6
05:14 envi^home joined #perl6
05:22 Guest23195 joined #perl6
05:38 risou joined #perl6
05:45 risou left #perl6
05:49 lue there's a *Hyper*Whatever ? O.o
05:51 molaf joined #perl6
06:03 Guest29521 left #perl6
06:03 Trashlord joined #perl6
06:05 perigrin lue: yes but with some adderal they say it will calm down.
06:06 lue :)
06:08 Trashlord left #perl6
06:08 lue seems like a wonderful challenge to implement it :)   afk o/
06:09 Trashlord joined #perl6
06:11 masonkramer left #perl6
06:48 envi_home joined #perl6
06:48 envi^home left #perl6
06:51 justatheory joined #perl6
06:52 justatheory_ joined #perl6
06:52 justatheory left #perl6
06:52 justatheory_ is now known as justatheory
07:02 justatheory left #perl6
07:14 Alias_ left #perl6
07:21 tylercurtis left #perl6
07:31 stepnem left #perl6
07:32 wamba joined #perl6
07:34 envi_home left #perl6
07:34 envi^home joined #perl6
07:35 stepnem joined #perl6
07:37 zulon joined #perl6
07:38 wamba left #perl6
07:44 envi^home left #perl6
07:48 snarkyboojum g'day perl6 type hackers
07:48 moritz_ o/
07:50 * snarkyboojum is in the process of compiling rakudo star on his phone ;)
07:50 snarkyboojum Perl 5 already shipped with it! (albeit an old version)
07:51 snarkyboojum needed a couple of modules to get Configure.pl going (which required hacking cpanm a little - yes, cpanm on my phone ho ho)
07:52 snarkyboojum but currently parrot is building, so I'll keep you posted if I can eventually play with the REPL on my phone :)
07:55 envi^home joined #perl6
08:11 Chillance left #perl6
08:13 mikehh joined #perl6
08:15 pnate left #perl6
08:18 sorear snarkyboojum: just HOW much memory does your phone have?
08:18 * sorear is toying with making regexes !~~ Block
08:18 lichtkind joined #perl6
08:18 lichtkind szabgab: ping
08:18 snarkyboojum sorear: 1GB :P
08:19 snarkyboojum sorear: well 256MB RAM, and 768MB swap space
08:19 snarkyboojum so 1GBish virtually
08:22 sorear handling stuff like regex { :my $*foo = class { ... }; <...> } is a bit tricky if regexes are anything other than ordinary subs, though
08:24 drbean joined #perl6
08:40 sorear I wonder if I could just get away with calling that illegal.
08:41 snarkyboojum scarily, parrot compiled :)
08:48 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␤»
08:50 moritz_ std: my regex a { :my $*x = class { method foo { say "hi" } }; {$*x.foo() }; }; 'a' ~~ /<&a>/
08:50 p6eval std 32078: OUTPUT«[31m===[0mSORRY![31m===[0m␤Semicolon must be quoted at /tmp/wzbrn1Mi2d line 1:␤------> [32mmethod foo { say "hi" } }; {$*x.foo() };[33m⏏[31m }; 'a' ~~ /<&a>/[0m␤Parse failed␤FAILED 00:01 121m␤»
08:50 moritz_ if I remove that ;, it wors locally in Rakudo :-)
08:52 sorear how do you keep going on such a thankless task
08:55 sorear I for one don't think I'll be able to go on much longer without any encouragement
09:04 lichtkind moritz_: grüße von der froscon hab heute beim frühstück ehemaligen studiencollegen von dir gesprochen
09:05 Mowah joined #perl6
09:07 moritz_ sorear: which thankless task?
09:07 moritz_ sorear: the key is to do something you enjoy doing
09:07 moritz_ rakudo: my regex a { :my $*x = class { method foo { say "hi" } }; {$*x.foo() } }; 'a' ~~ /<&a>/
09:08 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
09:08 sorear moritz_: It was fun two days ago
09:10 moritz_ sorear: also it's important not to try to do everything correct at the first shot
09:12 moritz_ 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 moritz_ afk
09:14 drbean left #perl6
09:19 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␤»
09:19 sorear pugs: say ?"0"
09:19 p6eval pugs: OUTPUT«␤»
09:19 sorear alpha: say ?"0"
09:19 p6eval alpha 30e0ed: OUTPUT«0␤»
09:19 sorear alpha: say ?"x"
09:19 p6eval alpha 30e0ed: OUTPUT«1␤»
09:21 cognominal submitted a patch for #77322
09:23 sorear std: /<[x][y][z]>/
09:23 p6eval std 32078: OUTPUT«ok 00:01 117m␤»
09:23 lichtkind left #perl6
09:26 cognominal in S05, what's the difference between a printable character and a graph character?
09:26 Italian_Plumber joined #perl6
09:30 sorear graph excludes spaces
09:33 meppl joined #perl6
09:37 thebird joined #perl6
09:52 zulon left #perl6
10:03 suhailck joined #perl6
10:06 suhailck left #perl6
10:09 * snarkyboojum has Rakudo star running on his phone :D
10:11 snarkyboojum a Nokia N900 fwiw :)
10:23 snarkyboojum high fives all round :)
10:25 mberends left #perl6
10:34 [Coke] left #perl6
10:35 [Coke] joined #perl6
11:14 colomon joined #perl6
11:32 risou joined #perl6
11:32 cognominal snarkyboojum, how much memory?
11:32 snarkyboojum cognominal: available or used?
11:33 cognominal I am speaking of RAM, nor rlash.
11:33 cognominal *flash
11:34 snarkyboojum 256MB RAM
11:35 cognominal how long did it take toc ompile?
11:36 snarkyboojum about an hour and a half :)
11:36 snarkyboojum parrot took the longest
11:37 risou left #perl6
11:37 snarkyboojum it's only a 600Mhz ARM processor :)
11:38 masak joined #perl6
11:39 masak halloy, #perl6!
11:43 masak 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:44 HarryS joined #perl6
11:48 HarryS left #perl6
11:48 HarryS joined #perl6
11:53 Mowah left #perl6
11:57 masak snarkyboojum++ # http://twitter.com/snarkyboojum/status/21738635293
11:57 snarkyboojum masak o/
11:57 masak \o
11:57 Trashlord left #perl6
11:58 molaf left #perl6
11:58 snarkyboojum lots of fun running perl 6 in a repl on my phone :)
11:58 snarkyboojum partly because the n900 is such a cool device
11:58 Trashlord joined #perl6
11:58 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
11:59 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␤»
11:59 masak locally, 0.
12:02 masak another take on http://rt.perl.org/rt3/Tic​ket/Display.html?id=77340 is the question whether the second argument of &map also flattens in the absence of $ or []
12:25 azert0x joined #perl6
12:29 drbean joined #perl6
12:29 zulon joined #perl6
12:35 zulon left #perl6
12:44 masak nom, then studying &
12:52 jnthn Afternoon, 6folk :-)
12:59 cognominal jnthn, can you review and  possibly apply my patch for getting  the class Grammar as parent of any grammar?  #77322
13:00 colomon jnthn: \o # just who I wanted to see...
13:02 colomon lolibloggedagain: http://justrakudoit.wordpress.com/2010​/08/21/timing-text-file-reads-part-2/
13:02 jnthn colomon: I don't see a patch attached to the ticket?
13:02 colomon the parrot ticket?
13:02 jnthn tab complete FAIL
13:03 jnthn cognominal: ^^
13:03 cognominal \o/
13:03 jnthn colomon: Nice post - nice improvement, but yes, ouch, that iterator stuff hurts us.
13:03 colomon darn you tab!!!!!
13:04 cognominal And how come compiling perl6.c is so slow?
13:04 jnthn cognominal: It's pretty fast here.
13:04 jnthn cognominal: Depends on your C compiler. Mine is a good one. :-)
13:04 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.
13:05 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...
13:06 jnthn colomon: my $parcel := pir::new('Parcel'); pir::push($parcel, 42);
13:06 cognominal jnthn, I have TABs in my patch?
13:06 jnthn colomon: Note the :=
13:06 jnthn cognominal: No, I can't find your patch. Where is it?
13:06 colomon jnthn++
13:08 cognominal jnthn, probably making its way to p6c... forwarded to you
13:08 orafu left #perl6
13:08 orafu joined #perl6
13:13 cognominal trying to compile with clang.
13:16 jnthn colomon: Though these pir::new's might come back to haunt me in a month or two. :-)
13:16 jnthn Well, OK. *will* :-)
13:17 jnthn cognominal: Got it, will look over it shortly.
13:17 cognominal Apparently clang recognize most gcc switches
13:18 cognominal and emits more warnings
13:23 cognominal I see that clang is also part of freebsd.
13:24 colomon jnthn: yeah, I've been wondering about that.  the pure PIR optimizations are even worse.
13:24 colomon I mean, great for Parrot-based Rakudo, but making life harder for you in the near future.
13:25 colomon also, both the Range and .chomp optimizations are literal translations not-quite-correct Perl 6.
13:25 alester left #perl6
13:26 jnthn colomon: I'm not even thinking portability, I'm thinking meta-model changes.
13:27 colomon oh.
13:27 jnthn Anyway, no worries for now.
13:27 colomon well, we'll burn that bridge when we come to it, eh?
13:27 jnthn I'll probably have a branch for a while.
13:27 jnthn Yes.
13:33 drbean left #perl6
13:37 jnthn cognominal: Will try and get talks submitted for OSDC.fr this weekend too.
13:38 cognominal nice
13:40 * 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:49 ruoso left #perl6
13:56 masonkramer joined #perl6
14:08 rlb3 joined #perl6
14:08 dudulz joined #perl6
14:09 Guest23195 left #perl6
14:09 colomon jnthn: ping?
14:10 colomon 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␤»
14:10 colomon oooo, stylish new error
14:10 jnthn oh noes p6eval is busted
14:11 colomon having a terrible time getting the parcel code to work in my new iterator.  :\
14:12 jnthn What're you seeing?
14:12 colomon I'll make a gist
14:13 colomon http://gist.github.com/542357
14:16 colomon ah, got it working by switching to $!value (instead of $parcel)
14:17 jnthn colomon: ah, OK
14:17 jnthn That'll be more efficient anyway, I suspect.
14:18 jnthn $.value = $parcel; is a method call
14:18 jnthn And also
14:18 jnthn has $.value;
14:18 jnthn You didn't declare it as having an rw accessor
14:18 jnthn So Rakudo is doing the right thing here.
14:18 rlb3 left #perl6
14:20 colomon okay, first new iterator version is actually slightly slower than the default gather / take .lines iterator
14:21 jnthn $.filehandle.get; # can use $!filehandle there too
14:22 colomon jnthn: already made that change, too.
14:22 colomon :)
14:22 jnthn aww
14:22 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
14:23 colomon three lines at a time, 15.5s
14:24 colomon LAST doesn't work yet, does it?
14:25 jnthn No, I don't think so.
14:25 jnthn colomon: How fast was the .get loop ooc?
14:26 justatheory joined #perl6
14:26 tadzik joined #perl6
14:26 colomon 7.2s
14:27 tadzik oh hai
14:27 jnthn OK, still quite some overhead.
14:27 jnthn Probably in building the objects.
14:27 jnthn colomon: This is naughty but how much faster is
14:28 jnthn method new($fh) { my $result = self.CREATE; pir::setattribute($result, '$!filehandle', $fh); $result; } and then pass it positionally in the call to .new
14:31 colomon jnthn: The opcode 'setattribute_p_p_p' (setattribute<3>) was not found. Check the type and number of the arguments
14:33 jnthn colomon: oh you'll have to specify the siggy
14:33 jnthn setattribute__PsP
14:34 jnthn colomon: Then we save all the BUILDALL/BUILD overhead.
14:34 jnthn I'm curious how significant that is.
14:35 colomon The opcode 'setattribute_p_s_p_p' (setattribute<4>) was not found. Check the type and number of the arguments
14:37 jnthn oh sorry
14:37 jnthn vPsP
14:37 jnthn Doesn't return anything
14:39 dju left #perl6
14:45 dju joined #perl6
14:49 TiMBuS do multi methods require signatures?
14:49 colomon jnthn: that's actually significantly slower
14:50 colomon 20s for the new version versus 15.5 for the old
14:50 jnthn wtf
14:51 REPLeffect left #perl6
14:51 jnthn TiMBuS: Well, writing one without a signature is like a candidate that only takes the invocant
14:51 jnthn e.g. multi method foo { ... } is the same as multi method foo() { ... }
14:52 TiMBuS oh ok then. i thought it would sort of become a 'default' method
14:53 jnthn TiMBuS: No. Mark it "is default" for that.
14:53 colomon jnthn: http://gist.github.com/542417 is the code.  maybe I did something wrong?
14:53 jnthn colomon: That...really surprises me.
14:53 jnthn colomon: Let me look.
14:53 jnthn (Catching up some $dayjob here too... :-))
14:54 colomon trying to entertain my parents' puppy here...  :)
14:55 jnthn colomon: Aww...is it cute? :-)
14:55 jnthn colomon: OK, that's what I was meaning...but I totally don't get why it'd be slower.
14:55 colomon yes, but incredibly full of energy
14:55 jnthn Puppys tend to be. :-)
14:58 jnthn colomon: That actually makes me want to benchmark a few more things because that result is extremely odd indeed.
14:59 colomon indeeed
14:59 colomon gets back to our "nobody knows anything yet" thesis
15:00 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 jnthn At the moment I find it hard to know exactly what's really happening in some cases.
15:00 jnthn This result is one of those cases.
15:03 colomon I just constructed a version which does eight-at-a-time iteration, and it's still not better than 15.8s.
15:03 colomon (that's not using your new pessimization)
15:03 jnthn :S
15:10 justatheory left #perl6
15:13 wamba joined #perl6
15:14 dudulz left #perl6
15:19 Guest23195 joined #perl6
15:27 Su-Shee joined #perl6
15:31 pmichaud good morning, #perl6
15:31 colomon o/
15:31 jnthn morning, pmichaud
15:31 tadzik good morning
15:31 colomon thanks for the .chomp optimization last night.
15:37 pmichaud sure
15:38 pmichaud I can rewrite that without Q:PIR, fwiw -- I just did the quick-and-dirty version to see the performance improvement.
15:38 pmichaud at some point I suspect we may want to replace Q:PIR and pir:: with nqp:: equivalents (more)
15:39 xinming_ joined #perl6
15:39 pmichaud for example, we might replace the entire chomp method with   nqp::chomp(self)
15:39 xinming left #perl6
15:39 pmichaud and then nqp takes care of providing an optimal version of chomp
15:39 pmichaud then we just figure out what basic operations we need in nqp :-)
15:40 pmichaud which eventually tells us what basic opcodes we really need from Parrot / $othervm
15:43 colomon sounds like a very sensible approach
15:43 Trashlord left #perl6
15:43 masonkramer left #perl6
15:44 Trashlord joined #perl6
15:46 artcoder joined #perl6
15:49 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 #perl6
15:50 bbkr left #perl6
15:51 colomon lolibloggedagain: http://justrakudoit.wordpress.com/2010/08/21/157/
15:51 jnthn Whoa!
15:51 jnthn colomon is an epic blogger!
15:51 artcoder left #perl6
15:53 pmichaud colomon: "where it leaves us"  is that the current IO impleemntation is wrong.  IO needs to become an iterator
15:53 pmichaud then   .lines  will just be .list
15:53 pmichaud i.e.,:   method lines() { self.list; }
15:54 pmichaud then reify ends up being a method on the IO object itself
15:54 pmichaud and it can do whatever buffering it wants
15:54 tadzik colomon: how to do you time this tests? 'time perl6 code.pl'?
15:55 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
15:55 colomon pmichaud: errr... actually, I think A) ate B).
15:56 pmichaud and yes, "rewrite IO substantially" has t ohappen anyway
15:57 colomon tadzik: yes
15:57 colomon tadzik: it's not super-precise, but it seems to work fairly well with big enough loops to drown out the start-up time
15:57 tadzik colomon: tried Benchmark maybe?
15:58 colomon tadzik: nope
15:58 tadzik it was green on the test results, iirc, but it also has no tests, iirc
15:59 tadzik I wonder if it works
16:02 * jnthn afk, walk
16:04 hudnix left #perl6
16:05 Mowah joined #perl6
16:10 hudnix joined #perl6
16:16 justatheory left #perl6
16:23 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
16:24 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:25 colomon I don't see how having an inner Iterator that .lines and .get both reference helps that at all.
16:25 artcoder joined #perl6
16:26 TimToady isa iterator, not hasa iterator
16:26 TimToady otoh, if we added a .line method, we could remain agnostic on that subject
16:27 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:28 colomon 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 #perl6
16:29 TimToady then there's only one iterator
16:30 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:31 TimToady the unreified list could do the text buffering, methinks
16:32 colomon I'm not saying this well.
16:32 TimToady and when you reify to lines it just happens to come in whatever the current text buffer gives you sized batches
16:33 TimToady one think we'll have to think about is seeking
16:33 TimToady it's possible that IO merely *does* Iterator
16:33 colomon What I'm trying to say is .lines cannot be the same iterator that .get is using for its source data
16:33 TimToady I don't see it
16:34 TimToady but that could be insufficient caffienation
16:34 colomon because if you do $a = $*IN.lines; $a.shift; $a.shift; $*IN.get; $a.shift;
16:34 colomon $a is a list which contains lines 1, 2, and 4
16:35 colomon that cannot be generated by the same iterator which generates lines 1, 2, 3, and 4
16:35 tylercurtis joined #perl6
16:35 colomon afk # noms
16:35 dju left #perl6
16:37 TimToady not a problem if .lines just means .flat, and is otherwise a no-op
16:38 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␤»
16:38 TiMBuS O___o
16:39 tadzik yeah...
16:39 TiMBuS well that seems to print Any
16:39 TiMBuS which sucks
16:40 dju joined #perl6
16:40 TiMBuS and i cant use unquoted (state => thing)
16:40 TiMBuS argh
16:41 tadzik state seems something special
16:41 TimToady try :state(thing)
16:41 tadzik works then. But something seems broken
16:42 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␤»
16:42 TimToady std: say (state => 42).perl
16:42 p6eval std 32078: OUTPUT«ok 00:01 116m␤»
16:42 tadzik star: say (state => 42).perl
16:42 TiMBuS using state alone causes parsebug, i think its known
16:42 p6eval star 2010.07: OUTPUT«===SORRY!===␤Malformed state at line 22, near "=> 42).per"␤»
16:42 TimToady yes, it's not autoquoting before =>
16:44 TimToady probably an LTM failure, since the whitespace isn't constant
16:45 zulon joined #perl6
16:45 TimToady so rakudo is LTMing on <identifier> rather than <identifier> \h* '=>' as STD is
16:46 TimToady 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
16:46 pmichaud so the \h* causes issues
16:47 TimToady std: state␤=> 42;  # might also fail
16:47 p6eval std 32078: OUTPUT«[31m===[0mSORRY![31m===[0m␤Malformed state at /tmp/aVmyvkNv1X line 2:␤------> [32m<BOL>[33m⏏[31m=> 42;  # might also fail[0m␤    expecting any of:␤    scoped declarator␤        statement end␤    statement list␤Parse failed␤FAILED 00:01 114m␤»
16:47 TiMBuS another spike i just stepped on: why does warn throw an exception? warn doesnt seem very exceptional..
16:48 pmichaud TiMBuS: so it can be caught and suppressed
16:48 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
16:48 TiMBuS i guess ill wait for the exception overhaul before trying to deal with that
16:48 TimToady don't think of them as quite so violent
16:48 TimToady exceptions are really just questioning your context for what you should do now
16:49 TimToady the actaul stack unwind happens when some exception handler decides to do that
16:49 TimToady or doesn't decide to, in the case of a warning
16:50 TiMBuS how do you filter out what you want
16:54 mberends joined #perl6
16:59 lmistura joined #perl6
17:01 jnthn TiMBuS: Generally, CATCH { when ... { ... } }
17:02 jnthn TiMBuS: If no when accepts it, then it's re-thrown.
17:02 TimToady warnings should go to CONTROL, by spec
17:04 TiMBuS i guess i mean, when 'what'? what is a warning
17:05 TiMBuS 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
17:06 TimToady presumably there's an X::Warning that splits up into finer gradations
17:07 pmichaud I think moritz_++ was looking to work on the exceptions model
17:07 jnthn Aye
17:07 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?
17:08 pmichaud lmistura: for 0x41..0x5a { .chr.say }
17:08 pmichaud rakudo: for 0x41..0x5a { .chr.say }
17:08 p6eval rakudo d1015f: OUTPUT«PackFile_unpack: This Parrot cannot read bytecode files with version 8.2.␤␤PackFile header failed during unpack␤»
17:08 pmichaud grrrr
17:08 pmichaud lmistura: yes.
17:08 tylercurtis star: for 0x41..0x51 { .chr.say }
17:08 p6eval star 2010.07: OUTPUT«A␤B␤C␤D␤E␤F␤G␤H␤I␤J␤K␤L␤M␤N␤O␤P␤Q␤»
17:08 pmichaud \o/
17:09 jnthn Oh yay, that one works. :-)
17:09 pmichaud star:  for 0xa0..0xbf { .chr.say; }
17:09 p6eval star 2010.07: OUTPUT«\xA0␤\xA1␤\xA2␤\xA3␤\xA4␤\xA5␤\xA6␤​\xA7␤\xA8␤\xA9␤\xAA␤\xAB␤\xAC␤\xAD␤\xAE␤\x​AF␤\xB0␤\xB1␤\xB2␤\xB3␤\xB4␤\xB5␤\xB6␤\xB7​␤\xB8␤\xB9␤\xBA␤\xBB␤\xBC␤\xBD␤\xBE␤\xBF␤»
17:09 pmichaud grrr
17:09 pmichaud (it works locally)
17:09 pmichaud > for 0xa0..0xbf { .chr.print }; say '';
17:09 pmichaud ¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿
17:10 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 #perl6
17:19 thebird left #perl6
17:21 thebird joined #perl6
17:22 lue good $*TIME everybody o/ [morning for me :)]
17:25 tadzik looks like TIME is not really global ;)
17:25 tylercurtis lue: don't you mean good DateTime.new(now)? :)
17:25 lue please tell me HyperWhatevers are useful beyond array sizes.
17:26 lue tylercurtis: I know, but I thought a global variable looked cooler :)
17:27 thebird left #perl6
17:28 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␤»
17:29 tylercurtis lue: It might look nicer than a simple map in a chain of feeds.
17:30 lue they are nyi, and I thought it'd be fun to see if I could implement them :)
17:33 lue When modifying rakudo, do I need to do anything more than make a branch locally?
17:34 pmurias joined #perl6
17:34 pmurias hi
17:34 lue hi o/
17:35 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?
17:35 tadzik (I never did this actually)
17:36 * 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"
17:36 lue [that and last time I didn't use a branch I messed up and had to redownload rakudo :(]
17:37 lue std: my @a = 1..50; @a ==> grep * %  2 ==> **.say # just checking
17:37 p6eval std 32078: OUTPUT«ok 00:03 118m␤»
17:38 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␤»
17:39 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:"␤»
17:39 lmistura pmichaud: thanks a lot!
17:39 tylercurtis Aww. :( I guess that either won't work in Rakudo yet or possibly shouldn't work.
17:40 tadzik left #perl6
17:41 pmichaud star: (1..10) ==> map( *.say )
17:41 p6eval star 2010.07:  ( no output )
17:41 pmichaud star: sink (1..10) ==> map( *.say )
17:41 p6eval star 2010.07: OUTPUT«1␤2␤3␤4␤5␤6␤7␤8␤9␤10␤»
17:41 pmichaud tylercurtis: ^^^
17:42 mberends lue: if you can afford another 400MB in your file system, it is easier to have two Rakudo clones in separate directories.
17:43 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 ); }
17:43 p6eval star 2010.07: OUTPUT«===SORRY!===␤Sorry, do not know how to handle this case of a feed operator yet. at line 22, near " -> *@_ { "␤»
17:43 pmichaud hmmmm
17:44 pmichaud I'm surprised.
17:44 pmichaud star: sink (1..10) ==> sub (*@_) { @_.map( *.say ); }
17:44 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 (*@_)"␤»
17:45 lue I get the feeling there's more to Whatever than what's in core/Whatever.pm and core/WhateverCode.pm .
17:45 rurban joined #perl6
17:46 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
17:46 jnthn pmichaud: There's lots to add.
17:46 pmichaud gotta go here -- bbl
17:47 sorear good * #perl6
17:47 jnthn o/ sorear
17:49 zulon left #perl6
17:49 sorear TimToady: pmichaud: What blocks need $/ ?
17:50 Mowah left #perl6
17:50 sorear Alternatively, how should $/ interact with the if  { } inlining optimization
17:51 sorear 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 #perl6
17:58 TimToady sorear: why can't you ask easy questions?  :)
17:58 TimToady we've got the same issue with $! and $_ too
17:59 xinming joined #perl6
17:59 xinming_ left #perl6
18:02 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 TimToady nearly all uses of $/ will be indicated by later ref to $/, $0, $<foo> etc.
18:03 TimToady likewise $! tends to be used explicitly, if at all
18:03 lmistura left #perl6
18:03 TimToady we already kinda know if $_ has been used
18:04 TimToady alternately, we have some way of embedding the inlined lexical scope and redirect various refs to alternate locations
18:04 TimToady so that if 1 { my $x } still scopes my $x properly somehow
18:05 TimToady 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
18:05 sorear the trick is that $/ "is dynamic"
18:06 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
18:06 sorear OK
18:06 TimToady if nobody uses $/ in the block, we can assume it needn't be set
18:07 jnthn Rakudo doesn't inline any blocks ATM either for this reason, fwiw.
18:07 justatheory joined #perl6
18:07 TimToady as quietfanatic just said over my shoulder, some things are less important than optimization
18:07 jnthn :-)
18:09 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:11 TimToady one is almost tempted to suggest that such dynavars live on a stack somewhere separate from the lexpad
18:12 TimToady 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 TimToady in the limit, we could inline something and have no benefit because we're emulating everything that the call would do... :/
18:13 jnthn Make it work, get lots of test cases, then optimize. :-)
18:13 TimToady um...
18:15 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 #perl6
18:16 TimToady the only extra overhead for the typical inline is to allocate 3 more slots
18:18 jnthn Hmm, sounds plausible.
18:18 TimToady then CALLER::<$_> would have to be a little smart to find the right $_
18:18 jnthn TimToady: allocate them but don't initialize them?
18:18 sorear Why is $_ dynamic?
18:19 sorear I can understand $/ (Regex.ACCEPTS) and $! (fail) easily enough
18:19 TimToady so a signature can default to CALLER::<$_>
18:20 sorear mm
18:20 TimToady which really only the default sig for {} does these days
18:20 achromic left #perl6
18:20 sorear I thought the default sig for {} defaulted to OUTER::<$_>
18:20 TimToady ah, you're right
18:21 TimToady the only occurrence of that is a fossil ./S29-functions.pod: our Bool multi chroot ( Str $path = CALLER::<$_> )
18:22 justatheory joined #perl6
18:22 TimToady arguably m/foo/ defaults to CALLER::<$_> though
18:22 sorear That's syntactic now
18:23 sorear or I suppose it always was
18:23 TimToady I said it was arguable  :)
18:23 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?
18:24 TimToady lazily?
18:25 TimToady not sure what you mean by that
18:25 achromic joined #perl6
18:26 TimToady the intent of the spec is that those three are initialized to their OUTER upon entry, unless specifically bound otherwise
18:28 TimToady 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:29 TimToady 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:30 TimToady then local refs to $_ stay straight to the lexpad
18:30 TimToady and only upscope references use the dynamic stack of dispositions
18:31 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
18:31 sorear I've just been having a bit of trouble working it into my IR
18:32 sorear I wonder if I could get away with saying,
18:32 sorear "Bare and pointy blocks don't have their own $/ and $! unless you explicitly 'my' them"
18:33 TimToady or -> them
18:33 TimToady makes 'em a bit more thunky by default, I suppose you might say
18:35 TimToady well, other languages get away with stuff everything into the sub pad, so we might be able to get away with that.
18:35 TimToady *stuffing
18:36 TimToady and it's already the case that we have to be careful not to clobber $_ going into a .{} subscript block
18:38 TimToady and presumably one could just say sub {...} to get all the vars by default for blocks as terms
18:39 TimToady it's really tempting, but I feel like I need to let it rattle around a while before committing to it
18:39 TimToady it'll violate some of the expectations of P5 programmers, for one...
18:40 TimToady otoh, it gives a way for $/ etc to escape a block if the user wants it
18:41 TimToady 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 TimToady and any mechanism for the latter might also work for the former
18:43 TimToady there's some relation to macros and lift there, if a function is to parasitize the (non)-caller's lexical scope
18:45 TimToady 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:47 * 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:48 TimToady and an inlined call can throw that away when it doesn't want it
18:49 TimToady 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 rurban left #perl6
18:50 TimToady this doesn't help with ordinary dynvars, though, which likely want to be set *now* rather than at return
18:51 TimToady but $! and $/ really are more like return statuses.  maybe we shouldn't think of them as dynvars at all
18:51 TimToady (just brainstorming, nobody panic please)
18:52 TimToady ((well, don't panic unnecessarily))
18:52 TimToady biab &
18:55 Su-Shee left #perl6
19:00 justatheory left #perl6
19:02 cmadsen1 is now known as cmadsen
19:03 dalek 6model: b93266b | jnthn++ | dotnet/runtime/Metamodel/SharedTable.cs:
19:03 dalek 6model: 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 dalek 6model: review: http://github.com/jnthn/6model/commit/b​93266b2fb88a2084896d05daac145568b13d687
19:03 dalek 6model: fabd625 | jnthn++ | dotnet/compiler/Grammar.pm:
19:03 dalek 6model: Get JnthnNQP to parse protos.
19:03 dalek 6model: review: http://github.com/jnthn/6model/commit/f​abd625c71ac5f435195e54e70322518886a1271
19:03 pmurias sorear: if $/ and $! is not ues in a bare or pointy block can you determine that?
19:04 sorear I do not follow
19:05 pmurias why don't you want bare and pointy blocks not to have $/ and $!?
19:06 pmurias s/not//
19:08 pmurias sorear: if 1 {...} should turn into {...}
19:11 draxil left #perl6
19:12 pmurias sorear: i read through the backlog, and it seems i got a bit confused (plus my typing was really bad)
19:17 jnthn Oh no!
19:17 * jnthn discovers PAST::Block.multi...
19:18 moritz_ what does it do?
19:19 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
19:20 jnthn Right
19:20 sorear PAST::Block.multi is used only for tcurtis' work
19:20 sorear it's not something you need to copy
19:20 jnthn Hmm. The whole way this was put into NQP seems to assume you'd only ever want types on multis...
19:20 jnthn sorear: Well, I should at lesat think about it a little before I lead NQP away from using it.
19:21 sorear pmurias: if 1 { ... } can turn into { ... }, but it can't turn into ... if there are any dynamic vars involved
19:22 * jnthn figures he'll just do what he thinks is right and we can deprecate anything that doesn't fit with that
19:22 jnthn (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.)
19:24 jnthn (Not least because we need to move to the proto-decides model.)
19:25 jnthn And we need :D / :U supported deep too.
19:26 sorear Do you really have to make "0" falso
19:26 sorear That's bitten me like, once a day
19:27 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␤»
19:27 jnthn star: say ?"0"
19:27 p6eval star 2010.07: OUTPUT«0␤»
19:27 jnthn sorear: It's spec afaik.
19:27 jnthn sorear: And it makes sense overall.
19:27 jnthn One of those DWIMmy things.
19:30 macroron joined #perl6
19:43 artcoder joined #perl6
19:45 ruoso joined #perl6
19:47 mberends dalek: what is JnthnNQP ?
19:48 moritz_ jnthn is not quote perl?
19:48 mberends ok, thanks moritz_
19:48 pmurias ruoso: hi
19:48 jnthn mberends: It's my experimental "branch" of NQP.
19:51 moritz_ rakudo: say "test"
19:51 p6eval rakudo : OUTPUT«test␤»
19:53 sorear jnthn: What is 'knowhow'?
19:53 draxil joined #perl6
19:53 jnthn sorear: Package declarator for a pure prototype
19:53 sorear What's a pure prototype?
19:53 jnthn sorear: It just has methods and (will have) attributes.
19:53 jnthn No idea about inheritance or anything like that.
19:54 jnthn Essentially, the simplest thing we might be able to call an object.
19:54 jnthn It's the primitive at the bottom of the meta-model in my prototype so far.
19:55 jnthn 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
19:55 jnthn (But I don't have enough other primitives to do so.)
19:56 pmichaud it's strictly a type-based multi, same as Parrot
19:56 pmichaud we can introduce a new attribute/mechanism if we need one
19:56 jnthn pmichaud: *nod*
19:56 jnthn pmichaud: Aye, I'm still working out quite what we want.
19:56 jnthn 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 #perl6
19:57 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
19:57 pmichaud how that translates to virtual machines or object systems... we'll have to work that out
19:58 jnthn pmichaud: I don't expect to put the constraints stuff into NQP.
19:58 pmichaud right
19:58 pmichaud I think that belongs on the callable object anyway
19:58 jnthn pmichaud: I do expect to need the definedness flags.
19:58 pmichaud I'm fine with the definedness flags being there.
19:58 pmichaud we can certainly figure out how to make that work.
19:59 jnthn pmichaud: Anyway, I'll prototype it in 6model
19:59 jnthn pmichaud: It's easier to play around with ideas there. :-)
19:59 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.
20:00 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++
20:00 * pmichaud goes back to re-read backscroll, for comprehension this time
20:01 pmichaud TimToady: for verification --  <before> is a parsefail because the parser recognizes 'before' specially?
20:01 TimToady yes
20:01 pmichaud okay
20:01 pmichaud tnx
20:01 TimToady std: / <normal> <before> /
20:01 p6eval std :  ( no output )
20:02 TimToady huh
20:02 pmichaud does  <before pattern>   still capture to $<before>  ?
20:02 TimToady presumably
20:02 pmichaud okay.
20:02 TimToady no std eval either...
20:03 moritz_ std: 1
20:03 p6eval std 32078: OUTPUT«ok 00:01 114m␤»
20:03 TimToady std: / <normal> <before> /
20:03 p6eval std 32078: OUTPUT«[31m===[0mSORRY![31m===[0m␤before requires an argument at /tmp/d4NQdvh0TF line 1:␤------> [32m/ <normal> <before[33m⏏[31m> /[0m␤    expecting assertion␤Parse failed␤FAILED 00:01 116m␤»
20:03 moritz_ std: / <after> /
20:03 p6eval std 32078: OUTPUT«[31m===[0mSORRY![31m===[0m␤after requires an argument at /tmp/2Zy8cs8a9S line 1:␤------> [32m/ <after[33m⏏[31m> /[0m␤    expecting assertion␤Parse failed␤FAILED 00:01 116m␤»
20:03 TimToady I might be okay with .match not setting $/
20:04 moritz_ how about m:g// ?
20:04 moritz_ rakudo: 'abc'.match(/.+/); say $/
20:04 p6eval rakudo : OUTPUT«Any()␤»
20:04 TimToady rakudo: $/ = 'abc'.match(/.+/); say $/
20:04 p6eval rakudo : OUTPUT«abc␤»
20:05 TimToady looks like it already doesn't :)
20:05 pmichaud if .match/.subst doesn't set $/, how does    .subst( /(pattern)/, { $0.uc } )
20:05 pmichaud work?
20:05 pmichaud (I know that $/ doesn't work right in rakudo now.... I've been working out how to get $/ to work
20:05 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
20:06 pmichaud the current workaround?
20:06 pmichaud hmmmm
20:06 TimToady -> $/ { $0.uc }
20:06 pmichaud oh, and make that the official way to do it?
20:06 masak really? :(
20:06 TimToady mebbe
20:07 moritz_ it would make life for the implementor easier
20:07 masak it would suck.
20:07 moritz_ but it would make it harder for the user to use the non-inplace form
20:07 jnthn Oh no I feel like we're not being tormented enough!
20:07 jnthn ;-)
20:07 TimToady it's not clear where rx// sits in all this though
20:07 moritz_ I've kinda come to like the non-inplace form
20:08 TimToady nodnod
20:08 TimToady still just trying to find a sweet spot
20:08 pmichaud especially since p5 has recently been touting that it finally has a non-inplace form :)
20:08 moritz_ I think we need a way to supply a default $/ to a closure
20:08 TimToady alternately, .subst needs some magical way to inject $/
20:09 moritz_ that way both the method and syntacticall form could be made to work
20:09 moritz_ named manybe? add an implicit :$/ = OUTER::<$/> ?
20:09 moritz_ to every block
20:10 * 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.
20:10 pmichaud sorear: ...ack?
20:11 jferrero joined #perl6
20:11 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
20:11 moritz_ pmichaud: I agree it's a heavy-weight solution
20:12 masak left #perl6
20:14 sorear pmichaud: ack really isn't a pipeline-friendly tool
20:14 sorear though I can make it work for now
20:14 pmurias ack6 would be great
20:15 TimToady it's too slow :P
20:15 pmichaud ...what TimToady++ said
20:15 pmichaud sorear said "fast command line 'comb'".... and p6 doesn't have that feature yet :)
20:16 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
20:16 pmichaud (might need a .slurp there)
20:17 pmichaud TimToady: (profiler) I agree
20:17 jnthn +1
20:17 sorear jnthn: I get the tormentation, you get the fame.  Don't complain.
20:17 jnthn I've been using Redgate's profiler while hacking on 6model and it's been extremely valuable.
20:18 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?
20:18 pmichaud TPF president; the one who basically got the Hague Grants going
20:18 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
20:18 pmichaud (former TPF president until last summer)
20:19 pmichaud 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" :-)
20:19 jnthn Progress... :-)
20:19 pmichaud I think it should be JNQP
20:19 jnthn "progress"
20:19 pmichaud :-)
20:19 jnthn :P
20:20 jnthn pmichaud: I hope it won't last long...
20:20 pmichaud "Just Not Quite Perl".
20:20 jnthn pmichaud: Tssk...why'd I not give it a short name :-)
20:20 pmichaud ah, having a longer name helps make it more temporary?
20:20 jnthn pmichaud: Yeah, I'll get sick of typing it. ;-)
20:20 pmichaud in that case, I'm all in favor of JonathanWorthingtonNQPReplacement
20:20 pmichaud s/Replacement/Upgrade/
20:20 jnthn pmichaud: :P
20:21 jnthn pmichaud: I did note that if I follow your ng example, then "new object model" => nom, or just no :-)
20:21 achromic left #perl6
20:21 pmichaud cooooooool
20:21 jnthn "Where's the new object model work?" "no"
20:21 * sorear is feeling slightly upstaged
20:21 pmichaud I like "nom"
20:21 moritz_ nom +1
20:22 pmichaud sorear: ...upstaged?
20:22 jferrero left #perl6
20:23 TimToady .oO(the opera's not over till the Fat Parrot croaks...)
20:23 pmichaud croaking we have down pretty well already.
20:24 * TimToady is still thinking about $/ on sorear++'s behalf
20:25 pmichaud TimToady: I'm happy to let you think about it on all of our behalfs :-)
20:25 pmichaud I'd also be really happy to find a way to not create a new $! and $/ in every block
20:26 pmichaud (as a general case, not strictly as an optimization)
20:26 dalek niecza: 2372c12 | sorear++ | src/Niecza/Actions.pm:
20:26 dalek niecza: Fix tribble parsing again
20:26 dalek niecza: review: http://github.com/sorear/niecza/commit/2​372c1278b13a721eccefa13c0e493cf8f3d9c62
20:26 dalek niecza: 120cf42 | sorear++ | .gitignore:
20:26 dalek niecza: Add *.bc to gitignore, git mono leaves them lying around
20:26 dalek niecza: review: http://github.com/sorear/niecza/commit/1​20cf421dd27138386886a1532dc4b4e0df0e018
20:26 dalek niecza: d186587 | sorear++ | src/ (2 files):
20:26 dalek niecza: Finish parsing character classes
20:26 dalek niecza: review: http://github.com/sorear/niecza/commit/d​186587cfb40acfa8c01b3f8a9e7dad1fe49b682
20:26 pmurias left #perl6
20:27 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: http://niner.name/rakudo/benchmarks.png
20:27 pmichaud nine_: you probably need to remove+rebuild parrot
20:28 pmichaud huh, only 5% :-)
20:28 pmichaud er, only 95%
20:28 jnthn nine_: lol, nice graph :-)
20:28 jnthn .oO( so all we have to do to optimize Rakudo is break the build? :-) )
20:28 nine_ Well, the graph is a bit ahead of time I think :)
20:28 moritz_ nine_: it means that you have some old .pbc files that broke rakudo
20:29 moritz_ doing an rm -rf parrot parrot_install; make realclean; # and then building again should help
20:29 moritz_ and the graphs will be much more useful if you filter out such anomalies
20:30 moritz_ (I had the same build troubles on the p6eval server)
20:31 nine_ moritz_: many thanks. Trying again with a clean directory.
20:31 dalek rakudo: 0c374d8 | cognominal++ | src/metamodel/GrammarHOW.pir:
20:31 dalek rakudo: fixes #77322 : changed sub compose in GrammarHOW.pir so that grammars always inherit from Grammar
20:31 dalek rakudo:
20:31 dalek rakudo: Signed-off-by: Moritz Lenz <moritz@faui2k3.org>
20:31 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​c374d8e34c305539efe82fbd1567efa874808fc
20:32 risou joined #perl6
20:32 nine_ I think, I'm gonna do some measurements on how much jitter is to be expected in that graph anyway.
20:34 nine_ Would be nice to be able to be sure that rakudo really got 2.8% faster in the past three weeks :)
20:35 masak joined #perl6
20:35 pmichaud I'm somewhat curious about how the 2.8% result is obtained, though.
20:35 pmichaud i.e., what is that graph really measuring?
20:36 fod joined #perl6
20:36 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
20:36 pmichaud and it's not tests but test *files*, yes?
20:36 moritz_ test files
20:36 nine_ it is test files, yes
20:36 nine_ But the set should not get smaller
20:37 pmichaud why souldn't it?  tests change all of the time.
20:37 pmichaud if we unfudge a test, we remove that test file from the set, right?
20:37 moritz_ yes, but only a roughly constant number of tests each day get changes
20:37 achromic joined #perl6
20:37 pmichaud so, those percentages are day-on-day changes, not overall changes?
20:37 moritz_ *changed
20:37 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
20:38 nine_ The percentages should fairly well represent the difference to the first run
20:38 pmichaud I'm not sure I agree with that.
20:39 pmichaud 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')
20:39 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
20:39 p6eval ..22:/tmp/PUiWn8O0Uy␤»
20:40 moritz_ that's a bug, right?
20:40 pmichaud well, the grammar is overriding the .any method
20:40 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.
20:40 sorear really, the specsuite is a parser benchmark
20:41 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.
20:41 nine_ sorear: well, that's certainly true since the tests themselves don't run that long...
20:42 pmichaud the trig tests run long, not strictly due to parsing.
20:42 offby1 joined #perl6
20:42 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?
20:43 pmichaud we could turn them to .pir easily enough, yes.
20:43 pmichaud last time I checked, there wasn't a significant difference between .pir and .pbc
20:44 pmichaud 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.
20:45 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?
20:45 pmichaud test_summary.pl is no longer reporting the total number of spectests correctly (on my system)
20:46 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
20:46 pmichaud there's also a challenge in figuring out exactly what a git repository looks like as of a given date
20:47 pmichaud since merging and rebasing "rewrite history a bit", going back to a previous time doesn't seem to work quite right.
20:47 pmichaud (or I'm doing something wrong)
20:47 moritz_ nine_: look at the numbers for S32
20:47 moritz_ there passing > total
20:48 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.
20:48 pmichaud but various changes made to test_summary.pl seem to have broken that
20:48 pmichaud and more and more of the test files have been written with "plan *;", which makes that guess even more inexact.
20:49 sorear really we should replace plan * with actual test numbers everywhere
20:49 sorear requiring Whatever support in order to run tests does nobody any favors
20:50 moritz_ sorear: it only requires recognizing * as of type Whatever
20:50 risou left #perl6
20:50 moritz_ no currying necessary
20:50 pmichaud it's just a parameter/term there, so .... what moritz++ said
20:50 pmichaud it's not currying
20:50 pmichaud but I agree in that I was never really a big fan of "plan *;"  in the spectests.
20:50 pmichaud I much preferred having the actual number present.
20:50 moritz_ well, if somebody steps up and volunteers to maintain the test counts...
20:51 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 #perl6
20:53 cheep perl6: say 3;
20:54 p6eval pugs, rakudo d1015f: OUTPUT«3␤»
20:54 jferrero joined #perl6
20:55 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:56 pmichaud I have trouble seeing why maintaining the counts is hard (more)
20:56 pmichaud if the count is wrong, you get a test failure that has to be fixed.
20:56 pmichaud it's not like an incorrect count goes unnoticed.
20:57 pmichaud 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:58 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.
20:58 pmichaud anyway, I'm not opposed to "plan *;" to actually do anything about it :)
20:58 pmichaud *opposed enough
20:59 pmichaud so I'm fine if they stay.
20:59 moritz_ you get that from test_summary.pl too, if it works
20:59 pmichaud no
20:59 pmichaud you get an *estimate* from test_summary.pl
20:59 pmichaud because test_summary.pl can't say anything about the files it's unable to run
20:59 sorear really I think our tests should have more metadata in general
20:59 pmichaud (and that have "plan *;"
20:59 moritz_ sorear: and who would maintain them?
20:59 mberends our mindset seems to have been taken over by http://www.shadowcat.co.uk/blog/​matt-s-trout/a-cunning-no_plan/
21:00 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 :)
21:00 pmichaud moritz_: let's try to break down "our current problem" into its subproblems
21:00 pmichaud so, what are our current problems we want to address?
21:01 pmichaud (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
21:01 pmichaud that's due to #1, I believe.
21:01 macroron left #perl6
21:01 pmichaud (1a)  do we _really_ need to know the total number of tests?
21:02 moritz_ that's due to a bug in test_summary.pl
21:02 moritz_ no
21:02 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.
21:02 pmichaud if we accept that test_summary.pl simply estimates the count... then sure, I can go with that.
21:02 moritz_ it *is* a bug
21:02 moritz_ its current design should never allow passed > spec
21:03 pmichaud fine.
21:03 pmichaud I'll accept that.  However, given that its current design is wrong, what do we want to propose to do about it?
21:03 pmichaud do we really want to go back and re-calculate all of spectest-progress.csv ?
21:03 moritz_ pmichaud: what exactly is wrong about the current design?
21:03 pmichaud and would we have a mechanism for doing that anyway?
21:04 pmichaud moritz_: I don't know what's wrong with the current design -- that's what I'm saying
21:04 pmichaud when I wrote test_summary.pl, it was more accurate
21:04 pmichaud but people have patched it while I was out such that it's no longer accurate
21:04 moritz_ I don't think anything is wrong with the current design - just with the implementaiton
21:04 pmichaud okay, then s/design/implementation then
21:04 pmichaud if you ask me what's wrong with the current implementation -- I don't know.  It used to work, it stopped working.
21:05 pmichaud 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 pmichaud 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
21:05 moritz_ the time of the breakage was around colomon++'s trig test overhaul
21:05 tylercurtis rakudo: multi age-group ($age where * < 16) { "child" }; say "alive"
21:05 pmichaud I noticed problems as early as May
21:05 p6eval rakudo 0c374d: OUTPUT«===SORRY!===␤Malformed multi at line 22, near "age-group "␤»
21:06 tylercurtis Should that work?
21:06 jnthn multi age-group ($age where (* < 16)) { "child" }; say "alive"
21:06 moritz_ tylercurtis: I think you need a type constraint if you have a 'where'
21:06 pmichaud (I don't remember when the trig test overhault took place)
21:06 jnthn rakudo: multi age-group ($age where (* < 16)) { "child" }; say "alive"
21:06 jnthn std: multi age-group ($age where (* < 16)) { "child" }; say "alive"
21:06 p6eval rakudo 0c374d: OUTPUT«alive␤»
21:06 p6eval std 32078: OUTPUT«Potential difficulties:␤  $age is declared but not used at /tmp/lwHg7W9ZS7 line 1:␤------> [32mmulti age-group ([33m⏏[31m$age where (* < 16)) { "child" }; say "a[0m␤ok 00:01 120m␤»
21:06 [particle] pmichaud: when ~10k tests were removed iirc
21:07 pmichaud [particle]: no, the problems actually were appearing before then.
21:07 tylercurtis std: multi age-group ($age where * < 16) { "child" }
21:07 jnthn tylercurtis: I think STD patched a precedence recently and Rakudo didn't catch up yet.
21:07 p6eval std 32078: OUTPUT«[31m===[0mSORRY![31m===[0m␤Unable to parse signature at /tmp/JQ2zaFuHIw line 1:␤------> [32mmulti age-group [33m⏏[31m($age where * < 16) { "child" }[0m␤Couldn't find final ')'; gave up at /tmp/JQ2zaFuHIw line 1:␤------> [32mmulti age-group ($age where * [33m⏏[31m< 16) {
21:07 p6eval ..…
21:07 pmichaud I should rephrase
21:07 jnthn Oh, no, it hasn't
21:07 moritz_ rakudo: multi age-group(Numeric $age where (* < 16)) { say "child" }; age-group(4)
21:07 p6eval rakudo 0c374d: OUTPUT«child␤»
21:07 pmichaud the removal of the ~10K tests is when it became obvious that passing > tests
21:07 jnthn tylercurtis: I think TimToady++ mentioned at YAPC::EU that maybe those parens shoudln't be needed.
21:07 jnthn tylercurtis: But for now they are.
21:07 tylercurtis Alright.
21:07 pmichaud I think that before that point the counts were incorrect, but that it wasn't as obvious.
21:07 jnthn tylercurtis: If STD changes there, we can easily patch Rakudo though.
21:08 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?
21:08 pmichaud It's clear that the total count has been wrong at least since february
21:08 pmichaud because clearly when we switched to ng, the total # of spectests didn't go down.
21:08 mberends I was responsible for earlier patches to test_summary.pl, but I was not aware of any counting bugs.
21:09 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 pmichaud which means it wasn't counting things correctly even then
21:09 moritz_ well, that's the limit of the current design
21:09 pmichaud so, that gets back to my other question
21:09 pmichaud do we *need* the total number of spectests
21:09 pmichaud and
21:09 moritz_ of supplying data for planless tests from actual runs
21:10 pmichaud is it worth the trouble to go back and recalculate history?
21:10 moritz_ no, and no (IMHO)
21:10 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?"
21:10 pmichaud I mean, like, all the time.
21:10 mberends recalculate automatically if possible, but not manually
21:11 pmichaud 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?
21:11 pmichaud moritz_: people just want to know that number.  I don't know what they expect to gain from it.
21:11 risou joined #perl6
21:11 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:12 moritz_ pmichaud: I'm fine with disappointing people on that number
21:12 milki left #perl6
21:12 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 ;)
21:12 moritz_ "we don't know"
21:12 nine_ mberends: exactly!
21:12 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 #perl6
21:13 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
21:13 mberends is it correct that Perl 5 has about 350000 spectests?
21:13 [particle] moritz_: that's useless
21:13 moritz_ mberends: if you s/spec//, yes
21:13 moritz_ [particle]: just as the number of tests
21:13 [particle] no, that's less useless
21:13 moritz_ I disagree
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
21:14 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 pmichaud nine_: correct.
21:14 [particle] then you can ask questions like, "how complete is the p6 spectest suite?"
21:14 [particle] "how complete is the rakudo implementation, based on that?"
21:14 moritz_ [particle]: the number of trig tests show how useless such numbers and comparisons are
21:14 pmichaud [particle]: I don't think knowing that number in any way answers that other question
21:15 pmichaud 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
21:15 nine_ So since the number we had was useless anyway, why not substitute it by an equally useless number that's simpler to get?
21:15 [particle] it's not purely quantitative
21:15 moritz_ probably ~20%
21:15 [particle] it's a measure of completeness, not the actual percentage
21:15 pmichaud it's not a measure of completeness, even.
21:15 moritz_ "a measure of" is as vague as you can get
21:15 [particle] s/measure/indicator/
21:15 moritz_ ok, you *can* get more vague, if you try
21:15 [particle] no, measure is a term for a piece of data
21:16 [particle] indicator is more vague.
21:16 pmichaud it's a number.
21:16 pmichaud it doesn't have any good association with reality.
21:16 moritz_ ... of which you don't know the relation to the thing you actually want to know
21:16 dalek niecza: ad4148e | sorear++ | lib/Kernel.cs:
21:16 dalek niecza: Change the responder interface to an abstract class
21:16 dalek niecza:
21:16 dalek niecza: This allows the fallback implementations of methods to be shared.  Rather
21:16 dalek niecza: suprisingly, this also triples the runtime speed of the testsuite.
21:16 dalek niecza: review: http://github.com/sorear/niecza/commit/a​d4148edca6f51dca6c7ca4163bfe1d426b0c840
21:16 dalek niecza: 1801379 | sorear++ | / (2 files):
21:16 dalek niecza: Cache the first four lexicals directly in the Frame
21:16 dalek niecza:
21:16 dalek niecza: Saves 25K on the compiled testsuite in indirect lookups.
21:16 dalek niecza: review: http://github.com/sorear/niecza/commit/1​801379584f6d746ab369cb5cb4b57a28fa13c7f
21:16 synth "guesstimate" ?
21:16 nine_ So what number could we give people that tells them that there is progress, but doesn't have to actually be useful?
21:16 [particle] ok, let's put it this way... it matters to people who may use rakudo
21:16 moritz_ synth++
21:17 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
21:17 moritz_ I find the number of available modules a far more interesting number for users
21:17 [particle] moritz_: that's another number which means nothing
21:17 pmichaud [particle]: I even given test coverage analysis, and that seems to have no impact.
21:17 pmichaud *give
21:18 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
21:18 moritz_ [particle]: I disagree. It has rather direct impact on what the user can do, and what not
21:18 nine_ [particle]: that's the nice thing in marketing :)
21:18 [particle] moritz_: the count  means nothing, it's the breadth of the modules, or their depth in a particular area.
21:18 moritz_ [particle]: fact is, most of our modules are not duplicates; many of our tests are.
21:18 moritz_ which gives the number of modules a meaning
21:19 [particle] yes, but a single number can't differentiate the two
21:19 moritz_ yes
21:19 pmichaud (single number)  I think that's our point :-)
21:19 [particle] yes, that's the point
21:19 pmichaud "percentage of passing tests" doesn't mean anything.
21:19 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.
21:19 [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
21:20 [particle] it's subjective
21:20 risou_ joined #perl6
21:20 [particle] nine_: agreed, it's marketing fodder
21:20 moritz_ probably that's related to me knowing the test suite rather well
21:20 pmichaud anyway, I think we're ratholing.
21:20 [particle] and so we should try to get an accurate test count
21:20 [particle] moritz_: indeed
21:20 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 #perl6
21:21 [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?
21:21 nine_ nine_: so why not put up the number that's easy to get?
21:21 [particle] pmichaud: why? do it for rakudo *
21:21 [particle] start a new count.
21:21 pmichaud [particle]: because that number is hard to calculate.
21:21 pmichaud if it were easy to calculate, no problem.
21:22 pmichaud (and we wouldn't be having this discussion)
21:22 [particle] ok
21:22 [particle] so, ask for contributors to help with historic test counts
21:22 [particle] don't bother with it now
21:22 risou left #perl6
21:22 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
21:22 pmichaud if counting present-day tests is hard, counting historic ones is not much simpler.
21:23 [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.
21:23 [particle] so checkout based on datetime
21:23 pmichaud the problem isn't in getting the historical view of the spectests
21:23 moritz_ nine_: which is a real pity
21:23 pmichaud the problem is in the *counting*
21:23 pmichaud (historical pass rates) -- we could do monthly snapshots instead of daily.
21:24 pmichaud 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
21:24 [particle] no, wait, it might be easier to estimate, or have an intern count them.
21:24 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.
21:24 [particle] fun gsoc project ;)
21:24 pmichaud we know it'll be wrong for things like loops
21:25 [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 #perl6
21:25 [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
21:25 pmichaud anyway, at this point I'm generally in favor of discontinuing spectest-progress.csv altogether
21:26 pmichaud or, at least making it not be daily snapshots
21:26 [particle] monthlies?
21:26 pmichaud (since we don't have any reliable way to reproduce/recalculate the results)
21:26 nine_ pmichaud: but a replacement would be very nice. This graph really helped in my opinion.
21:26 [particle] you ship t/spec with rakudo *, correct?
21:27 pmichaud nine_: oh, I think we need to have some measure of progress, definitely.
21:27 pmichaud I'm just saying that spectest-progress isn't likely to be it anymore.
21:27 pmichaud unless someone wants to go through a massive project or trying to correct the values for the past several months
21:27 pmichaud *of trying
21:27 pmichaud [particle]: ship t/spec with rakudo * -- not relevant.
21:28 nine_ btw. rakudo.org down?
21:28 pmichaud (at least, not significant)
21:28 [particle] pmichaud: it gives you a snapshot to do monthly test counts
21:28 * masak` is playing Achilles-and-tortoise with today's backlog
21:28 masak` is now known as masak
21:28 pmichaud 21:23 <pmichaud> the problem is in the *counting*
21:28 pmichaud 21:23 <pmichaud> the problem is in the *counting*
21:28 pmichaud 21:23 <pmichaud> the problem is in the *counting*
21:28 pmichaud getting a historical view of the spectests for any minute in time is *no problem*
21:29 pmichaud (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
21:30 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 #perl6
21:30 moritz_ I hope you know that's rooted in an ancient greek's philosopher's parabola
21:30 dalek rakudo: 9288360 | moritz++ | t/spectest.data:
21:30 dalek rakudo: run grammar inheritance tests
21:30 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​2883603d6b228666d5b59cc4e9775a37e1a4588
21:30 moritz_ (at least the name)
21:31 masak [particle]: Lewis Carroll -- and before him Aesop and Zeno -- had it as "Achilles and the tortoise"
21:31 masak hm, maybe Aesop did have a hare.
21:31 sorear tortoise and hare and tortoise and Achilles are two very different problems
21:31 sorear one of them is an Aesop about persistance and backstabbing
21:31 offby1 left #perl6
21:32 sorear the other is a thought experiment on the evils of the continuum
21:32 [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.
21:32 masak [particle]: he had more than one. and I've heard his as having Achilles in it, not a hare.
21:33 moritz_ Zeno => Achilles, Aesop => hare
21:33 dalek 6model: 1e62243 | jnthn++ | dotnet/compiler/Actions.pm:
21:33 dalek 6model: Start refactoring multi-dispatch handling in the JnthnNQP actions towards the proto-in-control model.
21:33 dalek 6model: review: http://github.com/jnthn/6model/commit/1​e6224390761aa5c682c0087d72e508cac85d203
21:33 [particle] masak: yes, so have i, i just never knew it by that name
21:33 [particle] but now i know :)
21:33 * sorear dreams of a spectest suite in a simply-parsable format with 30,000 blocks of text, each containing 1 test + fudge data
21:33 masak if I ever get a hare, I'll name it Achilles :)
21:33 [particle] sorear: you imagine a test suite without loops?
21:34 masak sorear: what about several tests with the same buildup data?
21:34 pmichaud okay, so I have a mini-proposal of sorts
21:34 jnthn masak: Can you train a hare to come to heel, like a dog? ;-)
21:34 pmichaud (comments/reactions desired)
21:35 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
21:35 pmichaud 2.  For scripts that have an unambiguous "plan \d+;"  line in them, use that number.
21:36 pmichaud 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 pmichaud 4.  Calculate the historical size of the test suite going back through May 2008, but do it weekly instead of daily
21:37 pmichaud 5.  Switch rakudo to weekly estimates of spectest-progress
21:37 pmichaud (daily is a bit much)
21:37 pmichaud I can go back and recalculate Rakudo progress for 2010
21:37 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.
21:37 pmichaud masak: I'm thinking not worth the trouble.
21:38 masak the parsing would probably be fragile.
21:38 pmichaud right.
21:38 moritz_ pmichaud: I like your proposal; I'm just not sure if it's worth the effort
21:38 [particle] so, instead, make those failures for a human to deal with
21:38 [particle] or not deal with.
21:39 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 pmichaud I agree with nine_ that we really want to have some measure of progress
21:39 pmichaud I'm open for alternate suggestions of that measure
21:39 [particle] "couldn't parse test count in t/spec/.../....t: plan @tests * 42 + @other_tests;"
21:39 pmichaud [particle]: ...and then do what?
21:40 [particle] chose to manually adjust the test count in some cached file?
21:40 * masak sleeps
21:40 masak left #perl6
21:40 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 [particle] nine_: today. historically, there may be more
21:41 sftp left #perl6
21:41 pmichaud and the counts might have changed historically as well
21:41 offby1` is now known as offby1
21:41 offby1 left #perl6
21:41 offby1 joined #perl6
21:41 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.
21:41 moritz_ we can neglect those plans
21:42 moritz_ they sum up to less than 1k
21:42 pmichaud right... "not worth the trouble"  :-)
21:42 sftp joined #perl6
21:42 moritz_ and currently we have about 30k to 40k tests
21:42 offby1 left #perl6
21:42 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.
21:42 [particle] ok, so you could do a first order approximation by extrapolating in a straight line
21:42 pmichaud instead of having rakudo do it.
21:42 pmichaud and that count could also be per-synopsis
21:43 * moritz_ -> sleep
21:43 pmichaud then other implementations could query that table of "the official count"
21:43 nine_ sounds reasonable
21:43 pmichaud and we can also see where spectest coverage is lacking
21:43 pmichaud (at least to a first approximation)
21:44 [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
21:44 pmichaud well, it's only neglected for a few weeks, iirc :-)
21:45 pmichaud that's hardly "neglected".  It just means "not updated daily"
21:45 pmichaud if it was months out of date, I'd feel differently.
21:45 nine_ pmichaud: sorry to say that, but if I come up with the word "neglected", others will too.
21:45 nine_ Unfortunately, marketing does not have anything to do with facts.
21:46 nine_ btw. rakudo.org down?
21:46 pmichaud appears to be
21:47 nine_ where's it hosted?
21:48 pmichaud alester's server
21:57 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
21:57 p6eval ..984:CORE.setting␤  …
21:57 tylercurtis rakudobug or bug in my code?
21:57 pmichaud I'd say rakudobug.
21:58 pmichaud 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.
22:04 tylercurtis rakudo: say (16 < * < 66)(5)
22:04 p6eval rakudo 0c374d: OUTPUT«1␤»
22:04 tylercurtis rakudo: say 16 < 5 < 66
22:04 p6eval rakudo 0c374d: OUTPUT«0␤»
22:04 pmichaud bug.
22:04 pmichaud (the first, not the second)
22:05 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.
22:05 pmichaud so, submit.
22:05 jnthn I've not seen that beofre
22:05 pmichaud (and thanks)
22:05 jnthn Not sure how it's happening. :-S
22:06 pmichaud I suspect the WhateverCode builder is acting a little too soon.
22:06 tylercurtis rakudo: say False < 6
22:06 p6eval rakudo 0c374d: OUTPUT«1␤»
22:06 cheep left #perl6
22:06 pmichaud i.e., it's probably parsing it as   (16 < *) < 66
22:06 pmichaud which isn't the same.
22:07 pmichaud (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 #perl6
22:08 pmichaud chaining altogether probably needs a rethink/rework in Rakudo (and PCT)
22:08 pmichaud but  building a WhateverCode at the point of the infix is likely "premature"
22:09 * jnthn works on a blawg post
22:10 artcoder left #perl6
22:12 * gfldex can't wait to read it
22:14 pmichaud afk for a while
22:16 wamba left #perl6
22:18 * mberends sleeps
22:18 mberends left #perl6
22:25 * tylercurtis needs to either revive his old and never-really-posted-to blog or start a new one for this post.
22:29 tylercurtis Anyone have any suggestions for a good blog host?
22:29 jnthn I like hosted Wordpress so far. There's also blogs.perl.org.
22:30 lue ohai o/
22:30 [Coke] ugh. one version shy on PARROT_version, have to do a full rebuild. :P
22:30 lue does anyone have a step-by-baby-step guide through Actions.pm? :D
22:33 lue (all the more incentive for me to create such a thing)
22:40 * tylercurtis blogged: http://blogs.perl.org/users/tyler_curtis​/2010/08/age-discrimination-in-perl-6-us​ing-subsets-and-multiple-dispatch.html
22:44 * tylercurtis also didn't proofread before posting. :)
22:45 lue Ya' gotta love perl: http://tech.slashdot.org/story/10/08/21/141​239/Gaming-Foursquare-With-9-Lines-of-Perl
22:50 Guest23195 left #perl6
22:51 jferrero left #perl6
22:53 lue tylercurtis++  # good blog post
23:02 colomon left #perl6
23:08 * lue can't help but wonder how anyone managed to code Actions.pm
23:09 jnthn lue: It wasn't just one person. :-)
23:09 jnthn lue: If you want a simpler one to look at, see the Actions.pm of nqp-rx.
23:13 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:15 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 jnthn lue: Trying to understand the action methods in isolation to the data they're operating on is going to be rather harder. :-)
23:17 lue Alright. I got the crazy idea to try my hand at HyperWhatever's :)
23:18 tylercurtis lue: thanks.
23:18 lue (For some reason, Grammar.pm is visually less intimidating for me)
23:20 lue 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:27 sftp left #perl6
23:27 sftp joined #perl6
23:35 sftp left #perl6
23:35 sftp joined #perl6
23:39 jnthn I blogged, and it's a long one: http://6guts.wordpress.com/2010/08/2​2/rakudos-meta-model-the-road-ahead/
23:44 sorear jnthn: I think my problem is that our goals have unexpectedly converged, and now I feel like I have no place.
23:49 jnthn sorear: In what sense?
23:52 jnthn 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:54 jnthn 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 artcoder joined #perl6
23:55 artcoder left #perl6
23:57 sftp left #perl6
23:59 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.

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

Perl 6 | Reference Documentation | Rakudo