Perl 6 - the future is here, just unevenly distributed

IRC log for #phasers, 2010-10-19

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

All times shown according to UTC.

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

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