Perl 6 - the future is here, just unevenly distributed

IRC log for #phasers, 2011-07-12

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

All times shown according to UTC.

Time Nick Message
11:34 Util left #phasers
11:34 tadzik left #phasers
11:34 PerlJam left #phasers
11:35 pmichaud left #phasers
11:50 tadzik joined #phasers
11:52 pmichaud joined #phasers
11:52 PerlJam joined #phasers
11:52 Util joined #phasers
12:50 PerlJam left #phasers
12:52 PerlJam joined #phasers
14:15 [Coke] left #phasers
14:16 [Coke] joined #phasers
14:27 [Coke] left #phasers
14:29 [Coke] joined #phasers
16:23 [particle] left #phasers
16:23 [particle] joined #phasers
16:49 benabik joined #phasers
17:50 sorear did:
17:50 sorear mostly small things
17:50 sorear fixed »+=« and related double meta operators
17:51 sorear made (@x is copy) DTRT with itemy lists [1,2,3]
17:51 sorear changed [+] to be a listop, seems to work great so far
17:52 sorear got $_ $! $/ working according to spec... well it doesn't do the *-twigil-like thing yet
17:53 sorear state $, \(state $), state $x will start, now implemented
17:53 sorear made $*OUT.print 4 detection work properly
17:54 sorear attempted to discuss how sink context work, failed
17:54 sorear will do:
17:54 sorear try grapheme ropes
17:54 sorear EOR
17:56 takadonet joined #phasers
17:59 mberends joined #phasers
18:07 mberends pre-report:
18:08 mberends * began committing preparatory bits of 6model/c
18:09 mberends * only some infrastructure testing so far, this will be slow drawn out progress
18:09 mberends * aiming to support Windows as well as Unix from the start
18:11 mberends * laptop battery soon to expire, will miss the official start of #phasers
18:11 mberends * bbl
18:11 mberends .eor
18:11 mberends left #phasers
18:42 [Coke] did:
18:42 [Coke] * worked on some VLHF in nom
18:42 [Coke] * triage the nom spec tests to generate more LHF * mostly updates to t/spectest.data; * mark some tests as 'nom regression'
18:42 [Coke] will do:
18:42 [Coke] EOR
18:42 [Coke] * more test-related work
18:49 masak joined #phasers
18:49 masak pre-report: still blogging. distracted by $vacation, but writing in my spare**2 time on the adventure game. progress is made all the time. life is good. eor
18:51 masak will probably miss #phasers.
18:53 pmichaud Pm's report:
18:54 pmichaud What I did:
18:54 pmichaud nom stuff:
18:54 pmichaud * Refactored some core methods (Any.values)
18:54 pmichaud * Fixed the interactive REPL, with jnthn++
18:54 pmichaud * Wrote basic Juntion type (jnthn++ then added junction dispatch)
18:54 pmichaud * Cleaned up .gist a bit
18:54 pmichaud * Added Stringy Role, Str.perl now escapes
18:54 pmichaud * Enabled some more spectests
18:54 pmichaud * Added infix<=:=>, reversed sequences, 0-arg and 1-arg operators
18:54 pmichaud * Added and optimized List.roll and List.pick
18:54 pmichaud nqp stuff:
18:54 pmichaud * Fixed interactive REPL context handling
18:54 pmichaud * Added nqp::deb() opcode for efficient debugging
18:54 pmichaud * Added NQPMu.__dump so nqp objects participate in Parrot's Data::Dumper
18:54 pmichaud * New nqp-based implementation of regex engine
18:54 pmichaud What I plan to do:
18:54 pmichaud * nom regexes
18:54 pmichaud * more CORE functionality
18:54 pmichaud * more spectests
18:54 pmichaud * Work on S07 redraft
18:54 pmichaud EOR
18:55 Util # Done and Doing:
18:55 Util * Helped soa_cah_toa++ to reduce Q:PIR in Digest::SHA256
18:55 Util * Gave "Highlights from YAPC" talk at Atlanta.pm
18:55 Util = ...included recaps of Parrot and Perl 6 team interactions.
18:55 Util = Encouraged Jeek++ to make his first (Perl 5) RosettaCode post
18:55 Util * Running smoker and fixing bugs (mappedbytearray) on Win32 for upcoming Parrot release.
18:55 Util * Working on 2nd Perl 6 solution for RosettaCode: Zig-zag_matrix
18:55 Util * Thinking deeply on Flutter
18:56 Util EOR
19:00 sorear o/
19:00 Util \o
19:01 tadzik o/
19:02 Util Be advised: #parrotsketch has moved their meeting up 1 hour, and will now start 30 minutes after the start of #phasers.
19:02 Util (So some of us will be straddling channels)
19:02 tadzik can i/
19:02 tadzik ?
19:03 jnthn o/
19:03 jnthn tadzik: go ahead
19:03 tadzik so: finished the serialization of Pod, enabled = as a twigil and $=POD now works nicely and holds the sensemaking content
19:04 tadzik implemented tables in pod, tests are still being tuned
19:04 tadzik moved most of the Pod processing methods from Actions.pm to Pod.pm (new file)
19:05 tadzik filed my midterm evaluations
19:05 tadzik plans: finish formatting codes before
19:05 tadzik s/before//
19:05 tadzik .WHY and other things on schedule
19:06 tadzik blockers: @familystuff
19:06 tadzik =end report
19:06 jnthn tadzik++
19:08 * jnthn can report
19:08 jnthn Over the last week...
19:08 jnthn * Returned from Beijing Perl Workshop
19:08 jnthn * Junction auto-threading in multi and single dispatch
19:08 jnthn * Only generate accessor methods if needed
19:08 jnthn * Implement "is rw" trait for routines, scattered it where needed in CORE.setting
19:08 jnthn * Implement type checking of return values and introspection of the return type
19:08 jnthn * Fixed performance bug in scalar assignment
19:08 jnthn * Fixed "has ($!a, $!b)"
19:08 jnthn * Implemented default *%_ for methods, in a lazy way so we don't hose performance
19:08 jnthn * Scalar return values are decontainerized when we fall off the bottom now
19:08 jnthn * Fixes to nested classes
19:08 jnthn * Implemented auto-generation of protos for lexical and method multis
19:08 jnthn * Implemented multis in nested lexical scopes
19:08 jnthn * Made .^parents work, including :tree
19:08 jnthn * Implemented Attribute.get_value
19:08 jnthn * Made mentions of generic types in non-declarative contexts in roles work
19:08 jnthn * Fixed default { ... }
19:08 jnthn * First cut of mixins (does and but infix operators)
19:08 jnthn * [next|call][same|with] for multi dispatch and method dispatch
19:08 jnthn * Improved BEGIN-time/CHECK-time code execution; it now sees declarative things in the outer scopes
19:08 jnthn * Assorted smaller fixes
19:08 jnthn In the next day or two...
19:09 jnthn * Enums
19:09 jnthn * Work with Pm on regexes
19:09 jnthn I'll be heading on vacation on Thursday evening, to the mountains. No wifi at the place I'm staying, no laptop, no IRC, very unlikely I'll backlog. Will try to check emails now and then; /msg me if you want the address that I'll be checking.
19:09 jnthn EOR
19:09 tadzik woo
19:09 tadzik jnthn++
19:09 tadzik also: sorear++ mberends++ [Coke]++ masak++ pmichaud++ and Util++ while I was late-ish :)
19:10 pmichaud any other reports?
19:10 pmichaud I have one item for discussion.
19:11 * moritz reappars-ish
19:13 mberends joined #phasers
19:13 sorear as do I (probably the same one)
19:14 pmichaud okay, here's my item:
19:14 pmichaud (several points lead up to it)
19:15 pmichaud * Parrot 3.6.0 releases a week from today
19:15 pmichaud * The next Rakudo compiler release is (nominally) two days after that
19:15 pmichaud * We're also scheduled for a Star release in July
19:15 pmichaud * We want to have a distribution release based on nom sometime either before or during yapc::eu
19:15 pmichaud * That distribution release almost certainly will not be based on any nom release we make in July
19:15 pmichaud How shall we announce/schedule for July and August? Ideas?
19:16 mberends sorear: is this your item too?
19:16 tadzik do we have anything new in Rakudo since last release?
19:16 pmichaud bugfix.
19:16 * moritz is in favor of an irregular, nom-based release
19:16 moritz compiler release, that is
19:17 moritz and then base a star release on it
19:17 tadzik Star is supposed to be the Star that sorear++ can finally build, right?
19:17 moritz timing? no idea
19:17 tadzik or was that the last one?
19:17 pmichaud tadzik: no idea -- I didn't know that sorear++ couldn't build Star.
19:18 pmichaud I agree with moritz (I think) -- I don't know that we need to push to do nom->master for the July compiler release, if we know that we're going to turn around and issue another release a week or two after that
19:19 pmichaud (I'm still in favor of making nom->master as soon as we can, though :)
19:19 jnthn To the degree that it matters that I'm around when nom->master happens, I know that I'll not be back from vacation by nom->master.
19:19 jnthn er
19:19 jnthn gah
19:19 jnthn I mean, back by the July release.
19:20 jnthn As I see it the key things are:
19:20 jnthn 1) We have a nom-based distribution release for YAPC::EU
19:21 jnthn 2) We have some distribution releae prior to that, so we can give people advanced warning about several of the upcoming changes that are likely to bite them (mostly because nom follows spec better)
19:21 jnthn Generally, 1 wants to be as far aways as possible to have maximum polish, and 2 wants to be as soon as possible for the role we want it to play.
19:22 pmichaud Okay, here's an idea.
19:22 pmichaud Let's make the rakudo compiler release based on master.
19:22 pmichaud (the July release)
19:22 jnthn In terms of end users, the compiler releases matter a bunch less, plus there's no reason a distribution release has to be based on a compiler release.
19:22 pmichaud It will be the *last* compiler release based on master.
19:22 pmichaud Very shortly after that release, we do the nom->master switch.
19:23 pmichaud I.e., we're committed that the next compiler release (whenever it is) will be based on nom.
19:23 Util Thoughts: 1. Do not make a late release of Rakudo, no matter what. 2. Delay R* until Rakudo has had a nom-based release. 3. Make an early release of Rakudo if nom is ready off-regular-release-schedule.
19:24 pmichaud I think we should also do one more R* release based on master.
19:24 pmichaud If only so we can give adequate deprecation warnings.
19:24 jnthn Util: Trouble with 2 is that we could do with an R* release taht comes before a nom one...what pmichaud++ said.
19:24 pmichaud The distribution release that happens around yapc::eu doesn't have to be called "Star", either.  :)
19:26 pmichaud okay, I think this crystallizes my thoughts a bit (more)
19:26 pmichaud July compiler release based on master
19:26 pmichaud July Star release based on that, with notes about the upcoming switch
19:26 pmichaud shortly after the 20th, switch nom->master in github
19:27 pmichaud the weekend of Jul 30 (time to be determined) we're thinking of having a "modules hackathon" where we can go through the Star modules and test/update them for nom
19:27 pmichaud if Jul 30 doesn't work out, we'll aim for Aug 6
19:28 pmichaud sometime around Aug 6 we issue a nom-based compiler release
19:28 pmichaud sometime shortly after that we craft up a distribution based on that
19:28 pmichaud name to be determined, date to be determined
19:28 pmichaud but something available as a tarball for people to try out by the beginning of the yapc::eu hackathon
19:28 jnthn +1
19:29 Util As long as R* coming out in July does not block a nom-based R* (for the normal 3 months), I am good with any variation of that.
19:29 pmichaud we're never "blocked" on releases
19:29 Util the R* schedule is 3 months, right?
19:29 pmichaud R* is structured such that we say when we expect the next release to occur (and stick to it), but can always issue an earlier release if there's reason to do so
19:30 Util I am just asserting that nom is a reason to do so.
19:30 pmichaud and there's absolutely no argument about that :)
19:30 Util +1
19:30 pmichaud I think we're all eager to get nom out for general usage asap
19:30 pmichaud but we also want to be mindful of "underpromise, overdeliver"
19:30 [Coke] +1
19:31 pmichaud any objections to the tentative plan scoped above?  If not, I'll write it up for the blog and rakudo.org
19:32 pmichaud that will give us time for public comment and ideas as well.
19:33 pmichaud (objections can be logged here or #perl6 for the next few hours)
19:33 pmichaud end of item for me -- I relinguish the floor to whoever wants to take it next.  :)
19:33 * TimToady just wants the ceiling
19:33 * benabik is a fly on the wall.
19:34 TimToady that itches
19:34 pmichaud TimToady is always asking implementors to do the impossible... maybe the next release can be "Rakudo Impossible"  :_)
19:35 pmichaud or even just "Rakudo Moon" :)
19:36 jnthn "Rakudo Impossible" may be...unfortunate
19:36 jnthn Rakudo Impossible To Get Faster!
19:36 jnthn Rakudo Impossible To Release Next Week!
19:37 jnthn :)
19:38 pmichaud sorear: you had an item for discussion also... what what I presented your item?
19:41 TimToady The Man from R.A.K.U.D.O.
19:41 TimToady Get Rakudo
19:41 TimToady Wild Wild Rakudo
19:42 TimToady The R Team
19:42 TimToady Perl Six Million Dollar Rakudo
19:42 * TimToady looks at everyone staring at him
19:42 pmichaud I call "The Man from R.A.K.U.D.O."  for use in a talk somewhere
19:43 pmichaud :-P
19:43 * pmichaud updates his slides.
19:43 sorear pmichaud: I still want proper discussion of "sink context"
19:44 pmichaud The Rakudo Prophecy.  The Dark Rakudo.
19:44 pmichaud The Good, The Bad, and The Rakudo.
19:44 sorear pmichaud: last time we came to some vague ideas that "=" is syntactically special, but we didn't get anything on what the context *is*, although TimToady said it probably wasn't a method
19:44 TimToady The Seven Rakudai
19:44 pmichaud Rakudo IV: A new Hope.
19:44 pmichaud er, Rakudo Episode IV: A New Hope
19:45 pmichaud to be followed by Rakudo Episode V: The Wall Strikes Back   :-P
19:45 sorear sinkiness has been implicated in do { (1..*).map(&say); 2 }
19:45 sorear it has also been implicated in do { returns_a_failure(); 2 }
19:45 pmichaud (taking rakudo movie titles to #perl6)
19:45 TimToady the first is merely eager()
19:47 pmichaud iiuc, it's implicated in  { @list.map(&say); 2 }
19:47 TimToady the second means either examining the values directly for unhandled failure, or passing it off to some immediate GC that does it
19:47 pmichaud regardless of whether @list is infinite
19:48 TimToady you think sink is strictly eager?  something to be said for that
19:48 TimToady since you're obviously throwing away any .plan
19:49 TimToady the only reason to have it is if it has a side effect
19:49 pmichaud well, I'm thinking of the case
19:49 pmichaud { for @list { ... };  2 }
19:49 pmichaud _something_ makes that for loop do its thing.  I always assumed it was sink context.
19:49 TimToady and a side-effecty thing can be marked infinite yet terminate
19:50 pmichaud (well, I didn't "always" assume that, that's what I've come to expect from previous discussions :)
19:50 TimToady yes, that's likely
19:51 TimToady I think strict eager is pretty easy to understand; it's the failure business that is hazier
19:51 pmichaud but my question is
19:51 pmichaud { @list.map({...}); 2 }    # we eagerly evaluate the map
19:52 pmichaud { my $x = @list.map({...});  2 }   # what suppresses the eagerness?
19:52 TimToady we don't apply sink to an assignment or pseudo-assignment
19:53 TimToady an assignment is already a "sink"
19:53 pmichaud and that's a syntactic suppression?
19:53 pmichaud or ... ?
19:54 TimToady or shallow semantic
19:54 TimToady a role of KitchenSink on the operator?
19:55 pmichaud I'm fine if it's a trait or something that we can easily recognize
19:56 TimToady just sayin' it shouldn't be a list of operators, but a generalizable thingy
19:58 pmichaud ooc, what's the expected behavior of something like:
19:59 TimToady and since we don't guarantee refcount GC, I think sink has to examing each value it's discarding for unhandled failure
19:59 pmichaud that seems good
19:59 TimToady *mine
20:02 pmichaud so, maybe something like    sub infix:<foo>($a, $b) is unsinkable { ... }    ?
20:02 TimToady is sucky
20:03 pmichaud the idea, or an alternative to my Titantic reference?  ;-)
20:03 TimToady both :)
20:03 TimToady course we'd have to rename sink to suck then
20:04 pmichaud I'm not sure we want 'suck context'
20:04 pmichaud :)
20:04 TimToady to an FPtician, all side effects are in suck context :)
20:05 TimToady "avoid context" :)
20:06 sorear TimToady: what does "a roles of KitchenSink on the operator" even mean?
20:08 TimToady you look at the op at the top of the expression tree, and if it already is a sink, you don't slap a sink op around that.
20:09 TimToady at most, just something that throws away any values it does return, if you're on, say, a stack machine
20:09 TimToady but not eagerly, and not with prejudice against failures
20:10 TimToady basically, each statement needs some cleanup, which in some cases is a no-op, or close to it, but in the normal sink case has to provide eagerness and autodie
20:11 TimToady final statements instead need to arrange for return
20:12 TimToady in many cases the sink actually provides the synchronization point between statements; it controls what must happen before control passes to the next statement
20:13 TimToady I don't care if it's a role on operators, or just some other trait or bit flag, as long as it's generalizable to user-defined ops too
20:13 TimToady is there anything else you want to know about it?
20:14 pmichaud not for me... I think that works out okay fo rme.
20:14 sorear I'm trying to figure out what you mean by a role on operators.
20:14 sorear Like &infix:<=> does KitchenSink; ?
20:15 sorear or maybe class Op::Assign does KitchenSink { ... }?
20:15 TimToady I just mean some bit that can be mixed into an operator object that otherwise would not have that bit
20:15 TimToady I don't care about the specifics
20:15 jnthn Most probably it'd happen by an "is foo" which in the trait handler does a mixin
20:15 pmichaud that's what I'm thinking.
20:15 sorear What is an operator object in Standard #perl6 Jargon?
20:15 TimToady it's just a Routine
20:15 jnthn sorear: Just a Routine most probably.
20:16 sorear aha.
20:16 sorear ok.
20:16 TimToady conceivably one could somehow mark the datastream instead, and then an always-there sink op would see if the datastream was already "sunk"
20:17 TimToady but that seems like unnecessary complication
20:17 TimToady and you'd like to optimize away the sink entirely where it's not needed
20:18 TimToady (though the equivalent to sink in Perl 5 is also useful for statement stepping in the debugger)
20:19 TimToady that could be pessimized when you request the debugger though
20:19 TimToady and, in fact, it's more of a statement starter in p5, not a statement stopper...
20:20 TimToady anyway, that was mostly an idle thought
20:23 sorear ooc, what was pp_nextstate's original purpose?
20:23 sorear DB::DB?  FREETEMPS?  setting the line number?  something else?
20:23 TimToady DB::DB was later
20:24 TimToady mostly the latter two
20:24 TimToady stack discipline and line metatdata
20:43 TimToady s:3rd/t//
20:51 * sorear is vaguely concerned about whether sink context will pull its weight in the long run, but at least has enough info to go on now
21:42 [particle] left #phasers
21:43 [particle] joined #phasers
22:47 masak left #phasers
23:49 TimToady it doesn't have to pull any weight if you write in FP style, since it only enforces side effects :)
23:52 sorear I mean that it has a runtime cost and I feel a need to justify all costs.
23:54 sorear interesting corner case: my $a; my @x; sub foo() { $a = 5; @x = 1..* }; foo; 2
23:54 sorear the user might have a semantic model where foo() reeturns "nothing important"
23:54 sorear but it actually returns the list, so by using it in a sink context the user has eagerized @x
23:59 TimToady well, that argues for marking the list as "sunk" before you return it
23:59 TimToady since it's an assignment

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