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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!