|
weekly Rakudo status meetings with phase transitions: Tue 19:00 UTC | IR clogs at irclog.perlgeek.de/phasers/today Set by moderator on 3 October 2010. |
|||
|
05:41
pmichaud left
05:47
pmichaud joined
09:49
moritz__ joined,
moritz_ left
09:51
moritz__ is now known as moritz_
11:41
_ilbot2 joined
|
|||
| moderator | weekly Rakudo status meetings with phase transitions: Tue 19:00 UTC | IR clogs at irclog.perlgeek.de/phasers/today | ||
|
18:54
mberends joined
|
|||
| sorear | hello | 19:00 | |
| mberends | hello | ||
| pmichaud | hello | 19:01 | |
| jnthn | oh hai | ||
| mberends | so whoz op today? | 19:02 | |
|
19:03
colomon joined
|
|||
| jnthn hands mberends the op badge | 19:03 | ||
| mberends | lol | ||
| ok, <report> | |||
| tried to play catch-up to jnthn in 6model, and despite some progress ended up farther behind. But that's because jnthn++ moved *ahead* a lot more! </report> | 19:05 | ||
| pmichaud | nobody can catch up to jnthn++ :-) | ||
| sorear | I'm trying! | ||
| PerlJam | greets | 19:06 | |
| jnthn | pmichaud: Anything to report? | ||
| pmichaud | I'm still not quite at a healthy threshhold, it seems. | ||
| $!cold is mostly gone, but now have other issues :( | |||
| anyway, I'm working my way back into p6 development... plus will be working on R* release | 19:07 | ||
| (I plan to start making candidate tarballs on friday for release next tuesday) | |||
| EOR | |||
| jnthn | pmichaud: Best wishes for a speedy full recovery. | 19:08 | |
| pmichaud | jnthn: thanks :) | ||
| jnthn | sorear? | ||
| moritz_ here | 19:09 | ||
| sorear | not a whole lot to report in specifics - I'm much closer to having a version of STD running on Niecza, I'll probably have all the compile-time errors gone by next week (and then I get the runtime bugs) | 19:10 | |
| jnthn | Nice :-) | ||
| sorear | big missing features: $<foo>=[...], (foo) | ||
| pmichaud | sorear: Best wishes for a speed..... oh, different kind of bugs. :-P | ||
| sorear | on the runtime side I haven't quite figured out what to do about $*HIGHEXPECT (accessing Perl 6 contextuals from the bowels of the regex engine feels wrong), and I need something to store .syml files (probably a JSYNC::XS) | 19:11 | |
| EOR | 19:12 | ||
| jnthn | Alphabet overflow, back around to...colomon! | 19:13 | |
| colomon | nothing really to report this time out. | ||
| I've been doing some perl 6 hacking for $work, and no rakudo issues were found in the process. | |||
| PerlJam | colomon++ awesome | ||
| colomon | still have a terrible urge to write Math::Prime. :) | ||
| moritz_ | colomon: give in! | 19:14 | |
| colomon | EOR | ||
| jnthn | Nice to hear Rakudo is being used for useful stuff. \\o/ colomon++ | ||
| jnthn? Oh, yes, that's me... | 19:15 | ||
| LAST WEEK | |||
| * Up until Friday, felt mostly exhausted and a little ill and depressed, so didn't really get anything done :-( | |||
| * Spent some time at the weekend on dispatch, especially the new multi-dispatch | |||
| * Ran into various design issues, which I'm kinda blocked on | |||
| * Wrote 6guts.wordpress.com/2010/10/17/wres...-dispatch/ which I hope will help us work through the issues | |||
| * Yesterday, took care of various bits of LHF in 6model on .Net, which let it pass 6 more test files from the NQP test suite | |||
| THIS WEEK | |||
| * Want to try and get basics of arrays and hashes in place for NQP on .Net, which will remove at least one notable blocker for running ClassHOW there | |||
| * Probably need to worry about how to implement our-scoped stuff at some point soon too - it blocks some tests we could run | |||
| * If PCT::HLLCompiler gets moved to NQP's repo, I'll have a crack at switching the class keyword to use the new ClassHOW. | |||
| * Going to England at the weekend, hope to get some design work done on the train, probably on serialization stuff, or native type handling. | |||
| * Probably will be distracted for several days while in the UK; may well miss #phasers next week. | |||
| EOR | |||
| moritz_? | 19:16 | ||
| moritz_ | * wired Str.flip up to use the new String.reverse from parrot | ||
| more than 100x faster than the previous one | 19:17 | ||
| colomon | moritz_++ | ||
| moritz_ | * did a new challenge for improving hyper op error messages | ||
| * got a submission, improved it a bit, pushed it | |||
| jnthn | .oO( the old one was so slow, it went in reverse... ) |
||
| moritz_ | * worked a bit on the book, and fixed a rakudo bug that prevented JSON from properly working | ||
| * next step: calling example for to-json() | |||
| .EOR | |||
| sorear | hmm, I never actually did look at jnthn's 6model slides before | 19:19 | |
| very interesting | |||
| jnthn | sorear: I only uploaded them on Saturday or so. :-) | ||
| moritz_++ | |||
| PerlJam: Anything to report? | 19:20 | ||
| PerlJam | aye | 19:22 | |
| I'm doing the rakudo release this week :-) | |||
| other than that, nada. | 19:23 | ||
| eor | |||
| pmichaud | PerlJam++ | ||
| sorear | jnthn: if you think 2 pointers per object is "getting a little fat", don't look at the p5vm sources. Or Parrot for that matter. :) | ||
| pmichaud | all of which means we should probably update NEWS and drafting release announcements or .... | ||
| jnthn | sorear: Well, thanks to the SC, we end up with 2 anyway. | ||
| sorear: And that's forgetting the VM's overhead. | 19:24 | ||
| pmichaud | "Do these pointers make me look fat?" ;-) | ||
| jnthn | Only 32 bits. | ||
| ;-) | |||
| Anyone I missed? | 19:25 | ||
| Guess not. :-) | 19:27 | ||
| Anything to discuss? | |||
| moritz_ | hm | 19:28 | |
| PerlJam | Do we need a dedicated push on the book? | ||
| moritz_ | yes | ||
| I gave m:g// a shot this week | |||
| this works: | |||
| $_ = "foo"; | |||
| .say for m:g/./ | |||
| but | |||
| 'foo' ~~ m:g/./ | 19:29 | ||
| returns False | |||
| because m:g/./ returns a list, so it smart-matches the string against the list of Match objects | |||
| any ideas? | |||
| jnthn | I'm sure we've seen this exactly style of issue somewhere else... | 19:31 | |
| moritz_ | yes | ||
| which is what made us do $a ~~ Match.new return $a | |||
| erm | |||
| return the Match object | |||
| but we can't do that for lists | |||
| pmichaud | (book) can we do something to reduce the build requirements? The number of dependencies seems... high. | ||
| moritz_ | pmichaud: one can always build the HTML version | 19:32 | |
| pmichaud | we could fix it if m:g returned a Match object with the positionals corresponding to the individual matches | ||
| instead of returning a list of matches | |||
| sorear | jnthn: Incidentally, Niecza already does bounded serialization, though in a somewhat unusual way. | ||
| moritz_ | pmichaud: and then we can't distinguish 'abc' ~~ m:g/./ from 'abc' ~~ /(.)(.)(.)/ | ||
| jnthn | sorear: Unusual? :-) | ||
| moritz_ | pmichaud: which breaks split() und such | 19:33 | |
| pmichaud | moritz_: do we need to distinguish them? | ||
| yes, if it breaks split | |||
| afk, kid pickup | 19:35 | ||
| moritz_ | so, any ideas? | 19:36 | |
| PerlJam | moritz_: I don't quite understand. How does "foo" ~~ m:g/./ work exactly? | 19:40 | |
| jnthn | iiuc, "foo" is put into $_, and then m:g/./ operates on $_ | 19:41 | |
| moritz_ | PerlJam: $a ~~ $b desugars to do { my $_ = $a; .ACCEPTS($b) } | ||
| jnthn | At which point we'd like to be done, but the smart match "didn't happen" yet.. | ||
| moritz_ | m:g// desugars to $/ := $_.match(rx/.../) | 19:42 | |
| so it executes immediately | |||
| and the .ACCEPTS is run the result of the Match | |||
| s/Match/match/ | |||
| so the whole thing is like (do { my $_ = $lhs; .match(:g, rx/.../) }).ACCEPTS($lhs) | 19:45 | ||
| jnthn | moritz_: I follow why it goes wrong. I'm doing less well on a solution. :-( | 19:48 | |
| moritz_: If we went with what pmichaud++ suggested in a world where we had slice context, do you think Match it could be made to work? | |||
| s/Match// | |||
| moritz_ | jnthn: maybe... | 19:49 | |
| jnthn | That is, would .slice bring out something different for m:g/(.)/ vs m/(.)(.)/ in slice context? | ||
| moritz_ | that's what the spec says | ||
| jnthn | Yeah...that may be the "proper answer"...but sadly we lack slice context. :-( | ||
| moritz_ | but then I don't understad what $/.list would return in the case of m/(.)(.)/ | 19:50 | |
| (but that might be due to general lack of understandiing of slice context) | 19:51 | ||
| pmichaud | it's no longer .slice, iirc. It's now .lol | ||
| jnthn | lolwut? | ||
| :-) | |||
| moritz_ | in any case, we need more information in the Match object | 19:52 | |
| pmichaud | anyway, we might be able to do it by returning a LoL instead of a Slice | ||
|
19:52
tylercurtis joined
|
|||
| pmichaud | s/Slice/List | 19:52 | |
| anyway, I think that's something that might require a TimToady++ answer | 19:53 | ||
| and perhaps some more tuits towards resolving $/ in general, which still needed to be done last time I looked at this | |||
| moritz_ | especially the "how does $/ get promoted to the block RHS of s[foo] = bar" | 19:54 | |
| pmichaud | right -- same issue there. | ||
| (well, maybe not exactly the same -- but something else that is definitely related) | |||
| I have this nagging feeling that we're getting :g fundamentally wrong in the design | 19:55 | ||
| it feels like it doesn't fit the rest of Perl 6 somehow | 19:56 | ||
| sorear | I'm now thinking that $/ is actually a contextual | ||
| not a dynamically-accessible lexical | |||
| pmichaud | The spec already says that, iirc :-) | ||
| moritz_ | well, the whole modifiers thing is a bit of a mess | ||
| sorear | well, the rhs of s[foo] = bar can see $/ because $/ is set in .subst | 19:57 | |
| and contextuals search through caller chains | |||
| moritz_ | there are some whose values must be known at compile time | ||
| pmichaud | anyway, my brane isn't up for deep or intricate discussion today -- sorry. | ||
| sorear | (fwiw, Perl 5 10.0 changed $/ to be automatically 'local'ized in any block where it is set) | ||
| moritz_ | and then there are those that only applly to m// and s///, but not to rx// | ||
| isn't $/ in perl 5 something completly different? | 19:58 | ||
| sorear | I mean the equivalent of Perl 6's $/ | 19:59 | |
| Util sticks his head in to remind the world: | 20:02 | ||
| Configure option --gen-parrot=HEAD would have made it easy to prevent today's mishap. | |||
| See 12 lines starting irclog.perlgeek.de/parrotsketch/201...#i_2826386 . | |||
| .end | |||
| moritz_ | Util: having an option doesn't help alone. We also need people using it | ||
| Util: I regularly build rakudo on latest parrot an report issues; but I don't always time the build, and don't care how long it takes | 20:03 | ||
| Util | moritz_: Very true | ||
| pmichaud | and given that Parrot is about to switch to git and we'll have to rewrite much of the build system anyway, I decided it wasn't worth the tuits to get svn to work | 20:05 | |
| (and it ended up being non-trivial) | |||
| sorear | svn doesn't work? | 20:06 | |
| Util | Ah, I see. Thanks, all. Will ponder, and bring it back up if a path becomes clear. | 20:07 | |
| moritz_ | asked the other way round... why don't parrot folks try to build Rakudo after they change the GC, since that's known to be the hardest GC stress test? | 20:08 | |
| PerlJam | moritz++ | 20:09 | |
| pmichaud | it's entirely possible that they did, fwiw. :-) | 20:10 | |
| moritz_ | ... and ignored the result? | ||
| pmichaud | they also might not have cared/noticed how long it took. | ||
| especially if run in background in a different window, etc. | |||
| PerlJam | if you're testing the GC, don't you care about timing more than pass/fail? | 20:11 | |
| (I would) | |||
| moritz_ | speed, memory usage and success | 20:12 | |
| PerlJam | exactly | ||
| pmichaud | well, given that the change enabled *parrot* to build on platforms where it wouldn't previously build, it'd be easy to assume that there would be similar improvements for rakudo | ||
| PerlJam | and it may have :) | 20:13 | |
| moritz_ | in terms of memory usage maybe | ||
| pmichaud | afk, errand | 20:14 | |
| PerlJam | A standard set of benchmarks for parrot would have told if things are getting slower/faster. | 20:15 | |
| (of course, someone would have had to come up with a stress-test-gc benchmark probably) | |||
| jnthn | I fear it's machine specific though. On a low-memory machine, lots of GC runs may still beat lots of swapping. | 20:16 | |
| colomon | may have spoken too soon on the "no rakudo bugs causing $work problems" thing. :( | 20:25 | |
| jnthn | Aww. | ||
| sorear | colomon: very useful word: "yet" | 20:26 | |
| colomon | I'm more than a little disturbed about this one at the moment, as at first glance it looks like Rakudo while copying an array of strings to a file. but I'm still investigating. | 20:27 | |
| sorear | ENOVERB | 20:30 | |
| colomon | s/Rakudo while/Rakudo is losing data while/ | 20:31 | |
| looks like a major rakudo-bug. | 20:32 | ||
| probably related to new GC? | 20:33 | ||
| lose the last ~30 lines of (80 characters per line) file unless I explicitly say $file.close. | |||
| guess I should take this over to #perl6 | 20:34 | ||
| jnthn | colomon: *nod* | 20:35 | |
| pmichaud | weird, the 2010.08.1 tarball doesn't pass spectests for me :-/ | 20:36 | |