Perl 6 - the future is here, just unevenly distributed

IRC log for #phasers, 2010-12-07

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

All times shown according to UTC.

Time Nick Message
10:00 [Coke] left #phasers
10:06 [Coke] joined #phasers
15:35 colomon joined #phasers
19:00 colomon o/
19:00 TimToady
19:00 Util ~~
19:01 TimToady looks like Util is under water
19:01 colomon Perl 6: Now our line noise is Unicode friendly!
19:01 Util Finished replacing badly leaking water heater 10 minutes ago
19:02 TimToady ooh, I got it right!
19:02 Util :)
19:03 diakopter my report: tons of progress on porting pm's regex engine; lots more stuff is functional. :)
19:03 TimToady .oO(a water heater that is leaking badly would not leak much at all...)
19:03 smash joined #phasers
19:03 Util Doh!
19:03 diakopter *poorly
19:04 TimToady "My water heater is leaking well today."
19:04 colomon stupid adverbs
19:04 * TimToady apologizes if a pun war breaks out now
19:05 colomon diakopter++
19:07 colomon my report: Did Advent post on sequences.  Feel like the spec is definitely nicer now, it seemed easy to explain.  TimToady++ .eor
19:08 * moritz_ also did some p6advent stuff. EOR.
19:09 colomon moritz_++ also kept Rakudo up with the latest (?) Parrot
19:10 moritz_ a two-line patch, not really news worthy
19:11 Util My report. Attended PDS. Gathering thoughts for Advent cal. Q1q. EOR
19:13 pmichaud good afternoon, #phasers
19:13 PerlJam <report>doing nothing Perl 6 related except conversing on #parrot/#perl6.  preparing for p6advent2010 posts</report>
19:14 PerlJam pmichaud: greetings.  how goes?
19:14 pmichaud things are fine
19:15 masak joined #phasers
19:15 moritz_ we still need a volunteer for the advent calendarm for Thursday
19:16 * masak catches up in the backlog
19:18 masak my report: did advent post about lexical variables. got non-mean comment on proggit about it. \o/ still mulling over S24 draft (testing). eor
19:18 pmichaud my report:  mulling over lots of stuff :)
19:18 moritz_ masak: feel free to share early
19:18 masak nod.
19:18 masak as soon as I have something written down.
19:19 pmichaud no!  we want it before you write it down!!!
19:19 diakopter pmichaud: I'm in a cubemeeting but can you talk in 20min?
19:19 masak ooh, speaking of sharing, some of my energy is currently diverted into preparing Big Announcement, due Friday.
19:20 pmichaud diakopter: I'm actually about to depart in the next 10 min :(
19:20 pmichaud ...big announcement?  Perl related?
19:21 masak pmichaud: yes. Perl 6.
19:21 masak I pre-announced it a month ago.
19:22 pmichaud ummmm, I missed it then :|
19:22 masak been dropping clues at 10-day intervals since.
19:22 PerlJam masak: "my employer has decided to fund Perl 6 development by paying both Patrick Michaud and Jonathan Worthington to work on it full time for the next year"   ;)
19:22 masak that *would* be kinda nice.
19:23 masak no, you'll just have to wait. three more days.
19:24 moritz_ can we do anything to un-stall rakudo development?
19:24 PerlJam masak: "I've figured out how to make Rakudo go *fast* and here are the patches to prove it"  :-)
19:24 masak PerlJam: you overestimate me in flattering ways.
19:25 colomon what moritz_ said.
19:25 colomon (Not that I'm not excited about the Big Announcement, mind you.)
19:25 masak moritz_: set a time-based goal, like Rakudo Star?
19:26 moritz_ masak: that allone doesn't help
19:27 masak I think the biggest reason it feels like Rakudo development has stalled is that the two core devs are busy doing other things.
19:27 moritz_ probably
19:27 colomon There are several of us capable of doing "routine" development work, but there doesn't seem to be any goal to work toward at the moment.
19:28 moritz_ except "implementing Perl 6", of course :-)
19:28 pmichaud we should probably see about addressing some of the rt queue
19:28 PerlJam identifying the LHF and "challenging" people to pick it might be good
19:29 colomon identifying LHF alone would be a great start.
19:29 masak moritz_: there are benefits to identifying "natural next step" features along that path.
19:29 PerlJam it doesn't even have to be LHF ... it could be "fruit that needs a small step ladder to reach"
19:30 Util This topic fits in with my earlier-queued question.
19:30 Util I suspect that Rakudo Star would get more early adopters if pre-compiled packages were available for major platforms.
19:30 Util I think jnth did a Win32 .msi for the first R*, but nothing after.
19:30 Util I am looking into .dmg or .pkg for OS X, but welcome anyone to wants to get it done faster than I can.
19:30 Util Of course, we need a commitment from someone for each platform to build a package the day of each release
19:31 Util (or provide the release manager with a fool-proof procedure).
19:31 Util Any thoughts?
19:33 PerlJam Util: I like it.  Fool-proof procedures + access to the major platforms could lower the barrier to entry for building the packages and spread the work load.
19:33 PerlJam Util: can we get access to the major platforms?
19:33 colomon I'd sure love to have a Win32 .msi available, because I'm hopeless at making Rakudo work under Windows.  And I guess I could research what it would take to create a .dmg for OS X -- I certainly can build Rakudo there.
19:34 pmichaud I think that .msi / win32 possibly should have a separate release manager
19:34 Util PerlJam: Several of us have OS X, and you can built .dmg or .pkg with native tools.
19:34 pmichaud since it requires different platform and skills
19:35 PerlJam Util: I have access to a macbook, but have no idea how to build a .dmg or .pkg on it.
19:36 Util I can do .zip on Win32 from MinGW, but I only have the free version of the MS compiler, and I think jnth said that only the paid version can generate .msi.
19:36 pmichaud anyway, +1 to identifying person/process for releasing R* prebuilds
19:37 Util PerlJam: When I am done with my research, I should be able to write a process that you can follow for OS X, at least for .dmg.
19:37 pmichaud I think it's entirely possible/plausible to consider windows-distros as related/separate from the unix distro.
19:37 pmichaud anyway, I have to run some errands again -- bbl (probably tomorrow sometime
19:37 pmichaud )
19:38 colomon Util: are you on the problem for OS X, then, and I shouldn't worry about it?
19:38 Util pmichaud: certainly possible, in fact possible to consider *any* binary dist to be beyond R* scope, but I hope that it can all be done under R*'s roof.
19:39 pmichaud Util: I fear that might overtask a release manager.
19:39 Util colomon: For the figure-it-out part, for OS X, yes, I am on it.
19:39 pmichaud and drastically limit the scope of candidates.
19:39 PerlJam Util++
19:39 pmichaud I'm fine with it being under R* roof; I just think delegation wins
19:40 Util pmichaud: point well taken. Volenteer binary packagers for day-after, then.
19:40 pmichaud right
19:40 colomon Util: if you can figure out the how, I can probably do the actual work for some/many/all the R* releases.
19:40 Util colomon++ ; great!
19:40 pmichaud anyway, gotta run -- bbl
19:40 moritz_ me too, if somebody sends me a mac :-)
19:42 colomon afk # errands
19:42 tylercurtis joined #phasers
19:49 diakopter what'd I miss
19:51 diakopter ok, nothing
19:51 Util diakopter: http://irclog.perlgeek.de/phasers/2010-12-07
19:51 diakopter yeah, um, thanks for nothing; I've been here the whole time
19:51 Util discussion of pre-packaged R* binaries for Win32 and OS X
19:52 Util diakopter: then I am confused, but that is fine.
19:52 diakopter I was at first making light conversation, then I made light of the conversation
19:53 Util Thx, confusion resolved.
19:59 Util afk, bbl
20:00 jnthn hi - sorry I missed #phasers
20:00 sorear hi - this is what I get for not preposting
20:01 diakopter me too. I had plenty of questions for the 10 min of pmichaud
20:01 jnthn I meant to preport, but got dragged off to $onsite...
20:02 masak preportuous!
20:02 TimToady y'all can postreport instead
20:02 jnthn masak: :P
20:03 jnthn Well, this wake I mostly slept badly, refactored stuff in nqpclr, watched diakopter++ do good stuff, refactored opcode bits to help towards native type handling later, but also getting some code-gen wins now.
20:03 jnthn er, this week.
20:04 jnthn ...appropriate typo was appropriate...
20:04 sorear DID:
20:04 sorear - more random optimizations: STD-on-niecza is now 4x faster than the viv version, but I'm hitting dimishing returns *hard*
20:04 masak sorear++
20:05 masak .oO( dwimmish returns )
20:05 sorear - Cleaned out the bug queue except for "no submethods"
20:05 TimToady are there places we can be more type-specific in STD that would result in better optimizations?
20:06 masak sorear: as things settle down after Friday, I'll get back to trying out niecza and submitting bug tickets.
20:06 TimToady .oO(he didn't say *how* he cleans out the bug queue...)
20:06 sorear - Now using an actual binder, rather than open-coding - junctions are within reach
20:07 sorear - Started playing with use :from<dotnet> technology.
20:07 sorear EOR
20:07 masak \o/
20:07 sorear TimToady: my attempts at profiling so far have mostly blamed Regex.ACCEPTS and the various list-assignment helpers
20:08 sorear TimToady: so I think the biggest important thing I can do is to find a faster way to implement $foo ~~ /^\w/
20:08 sorear and related constructs
20:09 sorear right now, Regex.ACCEPTS tries every possible start position until one succeeds
20:09 diakopter ?
20:09 sorear and then the regex autofails if pos != 0
20:09 TimToady you mean it doesn't even anchor on ^?
20:09 sorear TimToady: ^ is treated as a zero-width assertion
20:10 sorear (I'm getting horrible lag to host02 atm, is it just me?)
20:10 TimToady should probably turn into a call that knows it shouldn't scan
20:10 TimToady I seem fine
20:11 diakopter (me too) in pm's regex engine, it pushes a backtrack that fails when returned to, then passes if po==0
20:12 TimToady maybe San Diego is being routed through China :)
20:12 diakopter (and that pushed backtrack point is on top of scan's backtrack points)
20:13 TimToady the default in the STD engine is that everything is anchored to the current position
20:13 TimToady so scanning has to be done outside the .parse, as it were
20:14 diakopter I haz teh lag too
20:14 TimToady echo lag or message lag?
20:14 diakopter irssi-reported lag
20:15 diakopter [Lag: 5.43]
20:15 TimToady prolly just a DDOS from the Pythonistas...
20:15 diakopter but my connection to host02 from our 30Gb/s network is quite fine
20:17 * diakopter imagines sorear fixing .parse to know about a separate stack of anchor cutpoints
20:18 sorear TimToady: echo lag for me
20:18 TimToady I'm getting a pretty consistent ping time of about 1/2 second to host02
20:18 TimToady which is odd
20:19 sorear TimToady: niecza is the same way - regex functions always anchor to the curret position, so ACCEPTS has to scan
20:19 sorear and ACCEPTS doesn't know anything about the regex - they're opaque subs - so it has to scan in the worst way
20:19 diakopter Reply from 209.9.237.164: bytes=32 time=77ms TTL=48
20:21 TimToady Oh, wait, it's not 1/2 sec, it's 0.500 ms
20:21 diakopter heh
20:21 diakopter that's even odder
20:21 TimToady well ~.5
20:22 diakopter that's faster than the speed of light
20:22 TimToady ms, not µs
20:25 sorear ping is being very odd
20:26 sorear 64 bytes from 209.9.237.164: icmp_seq=6 ttl=55 time=115 ms
20:26 sorear 64 bytes from 209.9.237.164: icmp_seq=7 ttl=55 time=106 ms
20:26 sorear there was a 3 second pause between these lines
20:27 TimToady you aren't doing a compile in the background are you?
20:27 TimToady you could get that from demand paging
20:27 diakopter c is 186 miles/millisecond? so ..
20:28 TimToady that's pinging host02 from 209.9.237.164
20:28 sorear that just means TimToady is within 40 miles of the central US
20:28 diakopter the server's in Virginia
20:29 TimToady I was checking for internal network clogging
20:31 TimToady traceroute gives me 9 hops to apflux
20:31 TimToady *pp
20:32 diakopter o_O actually, interestingly (perhaps), the server is rather near Ft. Meade; maybe their Internet goes faster than c
20:33 TimToady but does it go faster than c++?
20:33 diakopter bah-dum
20:34 TimToady ooh, after noon already, I should go and get dressed, so I can be clothed and in my right mind...or at least...clothed...
20:37 sorear anyways what I need is for ACCEPTS to somehow know what's in the regex
20:37 sorear so it can be scanned better
20:37 moritz_ uhm
20:37 diakopter a regex compiler
20:37 moritz_ you're doing an ACCEPTS for every subrule call in the regex?
20:38 sorear moritz_: no
20:39 sorear only for stuff like STD.pm6:5182
20:39 sorear that's one of the most expensive lines in STD, even after rewriting it to use a character class
20:42 moritz_ sorear: it's only used to generate warnings, and can probably be left out as a start
20:42 moritz_ sorear: you could also move it further down, below all the other 'next if' lines
20:42 moritz_ std: my $
20:43 sorear ENOP6EVAL
20:43 moritz_ just noticed :-)
20:43 moritz_ oh, and you can anchor the regex, I believe
20:44 moritz_ or is there a case where the sigil doesn't come at the start?
20:44 moritz_ like OUTER::$x ?
20:45 sorear OUTER::<$x> tends not to appear in lexpads
20:48 TimToady I suspect the lack of ^ there is an oversight
20:49 TimToady but I did not suspect such code would be on the hot path
20:55 sorear It wouldn't be if my implementation of freestanding regexes didn't suck ;)
21:13 TimToady well, I can understand that completely--P5 goes to extraordinary lengths to avoid calling into regexec
22:47 masak left #phasers

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