weekly Rakudo status meetings with phase transitions: Tue 19:00 UTC | IR clogs at irclog.perlgeek.de/phasers/today
Set by moderator on 26 April 2011.
10:10 _ilbot joined
moderator weekly Rakudo status meetings with phase transitions: Tue 19:00 UTC | IR clogs at irclog.perlgeek.de/phasers/today
11:35 _ilbot joined
moderator weekly Rakudo status meetings with phase transitions: Tue 19:00 UTC | IR clogs at irclog.perlgeek.de/phasers/today
16:50 mikehh joined 17:17 pmichaud joined 17:23 mberends joined
pmichaud Here's my pre-report: 18:10
What I did:
nom stuff:
* Completed rework of nom and nqp Configure.pl systems
→ moved build/ to tools/build/, reduced number of scripts needed
→ added config.default for specifying default option values
→ --gen-parrot and --gen-parrot now accept branch identifiers
→ common NQP::Configure library
→ Configure.pl can be easily parameterized for use by other nqp-based langs 18:11
* Added List, Array, Parcel, and Hash, postcircumfix:<[ ]>, postcircumfix:<{ }>, infix:<,>
* Added Numeric and Real types (classes for now, will switch to roles when we can)
* Added &return and &return-rw (both do &return-rw for now)
* Worked on array/hash autovivification
* Cleaned up register allocation. CORE.setting.pir now compiles in 2s instead of 50s on my system.
* Updated Bool methods and prefix:<?>
* Worked out Str vs Stringy implementation
* Worked on preliminary gather/take implementation
* Fixed variable interpolation in strings
* Split out Perl6::Compiler, added --version option to nom
* Eliminated the final .pir file from nom.
nqp stuff:
* Fixed 6model attribute binding
* Updated Configure.pl system (see entry under rakudo Configure.pl above)
* Cleaned up register allocation.
* Added pir::const::* symbolic constants
* Automatically add common ".include 'foo.pasm'" directives to output
* Future-proofing: regex codegen now uses .CCLASS_* symbols instead of numeric equivalent
* Fixed PAST to be able to handle binding of native I/N/S types
* Restored the --combine flag for HLL::Compiler
master stuff:
* Fixed my @t; @t[0][2] = @t[0][0] = 9 assignment
* Worked on some zavolaj test files and bugfixes 18:12
* Improved register allocation. 40% improvement in t/spec/S05-mass/rx.t (YMMV)
* More benchmark timings against recent parrots
parrot stuff:
* Added PAST::Stmt to encapsulate temporary register allocations
* Added :childorder to allow specifying the order of child node evaluation
* Improved the ability for PAST::Val to remain constants in output
* Fixed a string bug in
nqp-rx stuff:
* Improved register allocation
What I plan to do:
* Finish List, Array, Hash, Iterator, Iterable
* Implement Range, gather/take, map, LoL
* Add pir::const:: to nqp-rx, nom, and (maybe) master
* Work on S07 redraft
EOR
moritz pmichaud++
mberends wow, pmichaud++
tadzik oh wow. So great to see you back in action. pmichaud++ 18:14
moritz my pre-report (not pre typed, so slow):
pmichaud that last parrot item is supposed to be "* Fixed a string bug in NCI::Utils::ncifunc
18:15 benabik joined
moritz + added various built-ins to nom, most notably Numeric stuff (Rat, Complex, numeric operators) 18:15
+ started to add classes/roles for exception stuff (but less than I hoped to do)
+ bugged jnthn++ about missing features, reported regressions in nom
+ fixed an lwp-simple bug 18:16
.EOR
sorear DID: 18:21
* optimized .new handling, calling of defaults is 10x faster
* implemented basic use of submethod BUILD
* implemented s:g
* new small functions: Block.arity, sign, truncate, round, floor, ceiling, conjugate
* Stole series op from Rakudo
* fixed binding to @var
* Immediate metamodel refactor: metaobjects are constructed during the parse now
- Many crash-errors are now sorries
- Switched to nom-like class stubbing
- Many small improvements during refactor, like "also is rw" in blocks
* Starting to gut $*CURLEX and create a single consistent model
* Discussed the meaning of names in depth with jnthn
WILL DO:
* Finish gutting $*CURLEX
* Fix bugs once that's done with
* Use newfound insights to implement all the remaining cases of qualified names 18:22
EOR
moritz sorear++ 18:23
mberends indeed, sorear++ 18:25
so, my report:
* found out which Parrot NCI signature was broken in Zavolaj and MiniDBI. 18:26
* almost completed a biggish-int library that, with a little more work, could provide Integer functionality for NQP. 18:28
(github.com/jnthn/zavolaj/blob/mast...gishint.c)
.eor 18:29
tadzik moritz++ sorear++ mberends++
PerlJam my pre-report:
* did absolutely nothing but talk on #perl6 and occasionally watch everyone else do awesome things.
.eor :-) 18:30
mberends PerlJam += 0.5 ?
tadzik so I'll pre-report to, it looks fashionable
did: gsoc week #3, everything done, mentors happy 18:31
fixed some spec typos and thinkos
a little bit of nom hacking 18:32
...passed every exam I could, 2 finals ahead
=end report
=for plans 18:33
pass the finals, mail Damian Conway about the spec doubts 18:34
PerlJam tadzik: cc'd to perl6-language too?
tadzik I can 18:35
pmichaud I wouldn't cc. 18:37
Two separate messages, maybe.
mberends pmichaud: how well does rakudo hacking currently mix with pressure from other home and work responsibilities? We care a lot about your afk life. 18:46
moritz I might miss #phasers, because we'll by trying to feed Ronja some semi-solid food for the first time... no idea how long that takes :-) 18:47
tadzik is there much sense in maintaining gsoc-podparser on nom rather than on master?
moritz if my continued abasense from #phasers is a problem for anybody, I can look for other solutions
PerlJam tadzik: I bet nom is master by the end of the summer, so you'll have to cross that bridge at some point I think. 18:48
moritz he doesn't have to
it would be nice, but it's not required
tadzik I don't think I'll need a full spec-complete implementation
oh, this way, I get it 18:49
my point is that nom is even quite usable right now, and I'm not sure if it's not suitable for the pod parser at the moment of speaking
and working around the lack of serialization in master might be not worth the effort, especially if it would have been reimplemented anyway 18:50
PerlJam moritz: not required, but ... I'd hate to see it languish and IMHO the surest way to prevent that is to make sure the code is merged into whatever the master branch is/will be.
tadzik what's best for Rakudo? I don't need to go the easiest way
moritz iirc nom doesn't do any regexes yet
tadzik they work in the parser, that's what I need
mberends tadzik: I'd recommend staying on master for another month or so, just so that the nom developers can focus tightly on its critical path. Your work is kinda peripheral, and nom isn't at the peripheral stage yet. 18:52
PerlJam concurs
tadzik mberends: the dangerously near part of the work is making the parse tree runtime-available. In master that means creating past nodes that will create the whole pod tree in runtime. In nom, that could *probably* be just building something and serializing it 18:54
pmichaud tadzik: you could work from a branch of nom, perhaps
and then periodically sync with nom
mberends tadzik: you may ... pmichaud++ said it
tadzik I don't want the whole work to end up something that "worked in beta, but there's no one to port it", like these dozen of Parrot compiles basing on PGE or even older stuff
PerlJam tadzik++ 18:55
tadzik pmichaud: yeah, that's my dillema: work from master or from nom
pmichaud tadzik: I think only you can answer that one. I wouldn't want you to block on nom, though.
and it's possible that could happen.
PerlJam gsoc has a fixed schedule, nom does not 18:56
pmichaud master is relatively stable and a known working quantity (fsvo "working"). nom is a bit more unpredictable.
tadzik in theory I have 3 weeks to start working on the serialization stuff, nom may be far more ready for it then
pmichaud will you be blocking on serialization before then? 18:57
tadzik I don't think so, unless I'll have too much time in between the finals and will start experimenting. But nothing mission critical for sure
pmichaud also, keep in mind that nom development may slow again soon, as Perl workshops come into play
NPW is this Saturday, and I believe FPW is the following weekend, so there may be less nom progress than "normal" 18:58
(or it may be "normal" and not accelerated like the last couple of weeks have been)
tadzik right
19:00 colomon joined
colomon o/ 19:00
sorear o/
Util o/
tadzik o/
pmichaud anyway, either choice is valid... if you go with nom, be sure to have a strategy if nom isn't up to whatever you need from it based on your schedule constraints 19:01
good afternoon, everyone. Welcome to #phasers, today is June 14 at 19:01 UTC.
(translate "afternoon" to your localtime as appropriate)
mberends q1q 19:02
Util q1report
pmichaud Util: report please :)
Util New RC Perl 6 solutions: 19:03
rosettacode.org/wiki/Euler_method
rosettacode.org/wiki/Caesar_cipher
rosettacode.org/wiki/Draw_a_cuboid
rosettacode.org/wiki/Unbias_a_random_generator
rosettacode.org/wiki/Non-continuous_subsequences
rosettacode.org/wiki/Strip_a_set_of...m_a_string
rosettacode.org/wiki/Kaprekar_numbers
rosettacode.org/wiki/Convert_decimal_number
Improved:
rosettacode.org/wiki/Spiral_matrix
rosettacode.org/wiki/Sierpinski_carpet
rosettacode.org/wiki/Matrix_transposition
# Plan to do: $WORK
EOR
pmichaud wow! Util++
colomon Util++
Util plans RC lightning talk at YAPC::NA 19:04
pmichaud Util: any reactions about p6 or rakudo after having written these and other solutions?
colomon I've been pondering trying to do a sequences lightning talk at YAPC::NA.
pmichaud colomon: +1 to that
tadzik Util++, very nice, I have to read through that one day 19:05
Util I love Perl 6 more for each solution I write. I am also becoming aware/worried about item/list auto-defer distinctions that I cannot always resolve using just my brain; I must just try it to see which way somthing works. 19:06
moritz re 19:07
pmichaud since I'm writing the List synopsis I'll keep that in mind and see if we can make it clearer
Util Also, I need to turn my bug/wanted-to list into Rakudo bug reports and public wishlist items (for NYI features)
pmichaud Util: +1
Util munch vs. batch zapped me again this week; I just fell back to splice(0, $n)
pmichaud Util: also, wanted to make sure you knew that the @t[0][2] = @t[0][0] = $x bug seems to be fixed in Rakudo master
sorear pmichaud: how did you fix it? 19:08
Util pmichaud++
pmichaud sorear: evaluate the operands to infix:<=> r-to-l
(since it's right associative)
anyone else have any reports to give? 19:09
sorear hmm
interesting approach, but it'll require adding some kind of S, to niecza 19:10
pmichaud I had to add an option for it in PAST, yes.
no other reports, so mberends had a q1q
mberends A few weeks ago we undertook to appoint two people to coordinate liaison with two people in Parrot. What has been done/needs to be done about that?
sorear q1q=?
tadzik queue one question
pmichaud mberends: good question 19:11
mberends: I don't think we had a discussion/consensus yet.
I propose <pmichaud jnthn moritz>.pick(2)
19:12 lichtkind joined
pmichaud anyone feel that others should be added to the candidate set there? 19:13
mberends tadzik? 19:14
PerlJam nope (jnthn and moritz were the first people I thought of before)
tadzik mberends: you mean me? 19:15
pmichaud tadzik: interested?
tadzik well, I don't mind volunteering, but I feel like there are people here who are more into the business than me
pmichaud okay: I'll poll all(<pmichaud moritz jnthn tadzik>) and we'll grab our candidates from that set
mberends I think the people making the most commits to nom are somehow the most appropriate candidates. 19:16
pmichaud mberends: thanks for remembering that detail; it had slipped my mind
mberends++
tadzik for the both sides. The point is for Rakudo to benefit, and for that we need deep understanding about what Rakudo needs from Parrot, and maybe how Parrot should do it
pmichaud jnthn doesn't appear to be present atm, so I'll work on this later today 19:17
any other questions, comments, or reports?
tadzik pmichaud: did we get to anything regarding Select PMC? 19:18
pmichaud tadzik: I'll ping cotto about that.
oh, wait, we did. They had some design changes they wanted to see made, iirc.
tadzik yeah, he reviewed and posted his opinions
pmichaud I'll bump the ticket and see if we can get a decision (more) 19:20
basically, the question will be "accept the proposed Select PMC as experimental" or "wait for a better implementation to come along".
tadzik we can poke that on #ps today
pmichaud we could also adopt the PMC into Rakudo (master) for the time being.
tadzik after all, this is something we want from Parrot
pmichaud Another very interesting might be to ask what you would want from select if we were to implement it in nqp/nom. :-) 19:21
*interesting question
tadzik hmm
pmichaud it wouldn't need to be a PMC then -- it could be a 6model object or library or something like that
tadzik we want async io, disregarding the details of implementation, methinks
int eresting; 19:22
pmichaud do you have a specific application/test in mind for async io?
sorear Have we decided on an API for async IO?
pmichaud No. 19:23
tadzik I think the Net::IRC module could benefit from that. I have no specific reasons for that, I just remember that the two most common things that people missed in Star were threads and async io
and speed of course
pmichaud Basically the consensus opinion is that we need to see use cases before trying to put together a spec
tadzik Star was almost a year ago, and we're nowhere near those things
pmichaud so IO in general (incl async IO) really wants people to prototype solutions that we can look at before trying to adopt something as a spec 19:24
tadzik true, history shows that :)
sorear pmichaud: I will take some initiative there 19:25
pmichaud anyway, it'd be interesting to (re-)write a Net::IRC or similar application. Instead of asking "what API do I have", write it with the notion of "I can have any API I want" :-)
then we can prototype it in nqp, nom, or master (and poke the parrot folks if we decide that's really the appropriate place)
tadzik we can steal ideas from some good Perl 5 solution
cpan is quite used to reimplementing ideas that people don't like in a less painful way 19:26
pmichaud but in general, custom PMCs in Parrot will end up simply being things we have to wrap up in some other object in nom.
so maybe it's better to just do the work in nom directly, and to figure out how to do that. 19:27
Same goes for NCI, btw.
if we don't like Parrot's NCI interface, we still have the option of writing our own. :)
(and since 6model can have a much richer type system at the native level than Parrot offers, we can get it to be closer to what we want) 19:28
anyway, that's the strategy I suggest for now. But I'm open to whatever brings about progress. 19:29
mikehh pmichaud: I think that we need feedback in parrot as to what is needed, so that it can be incorporated there
if something does not work, then we need to fix it 19:30
pmichaud mikehh: I don't disagree in theory, but historical practice seems to indicate otherwise (e.g., the recent zavolaj breakage)
too often "fix it" ends up meaning "break it in such a way as to make our life even harder than it was before" 19:31
mikehh although there are a lot of things going on there rakudo is still our principal customer
and trying to herd cats (or parrots) just ain't easy 19:32
pmichaud right... at some point I'd rather just solve the problem myself than try to herd parrot's cats :)
s/myself/ourselves/
benabik I will also note that things implemented in 6model may migrate back to parrot. There's a fair amount of interest there in adopting 6model into core. 19:33
pmichaud I'm not saying we won't work with parrot, of course we will. I'm just saying I don't want to be blocked by that.
mikehh I yjink one of the reasons we need better liason is that rakudo's need are not always considered by the parrot devs 19:34
think
pmichaud benabik: (6model adoption) yes, I expect that will eventually happen. I doubt it will happen in 2011.
benabik pmichaud: Sad, but true. But if rakudo starts writing a pile of NQP/6model libraries, that seems like it would add weight to the migration. 19:35
pmichaud I'm certain we'd keep the libraries separate.
certainly well-bounded, at any rate. 19:36
one should be able to adopt 6model without having to adopt everything built on top of it :)
that's kind of the point of 6model :)
benabik pmichaud: Yes, but being able to say "hey, if we adopt 6model all this stuff is available to parrot" is nice. 19:37
pmichaud I agree fully
anyway, for anyone that wants to work on it, async I/O would seem a fruitful area of exploration and it's entirely possible to look at doing it in nqp, master, or nom as well as creating a parrot solution. 19:38
benabik re-lurks.
pmichaud and from a perl 6 perspective, niecza can be an excellent "help explore the spec" platform as well
(i.e., "sorear initiative" +1) 19:39
any other comments or questions?
pmichaud leaves the microphone open for anyone that wants to pick it up. 19:40
moritz sings a ballade
moritz not a good singer 19:41
tadzik doesn't sing good, but sings a lot 19:50
jnthn oops, sorry I missed phasers 19:53
$dayjob event lasted longer than expected, then trains were screwed up on way home :/ 19:54
sorear \\o/ jnthn
count yourself lucky you have usable trains
jnthn sorear: I do. :)
sorear: I've just encountered really good usable trains and the less good ones grate a bit :) 19:55
sorear jnthn: I'm finding myself adding $/ parameters to most of the metamodel add_attribute and whatnot methods
jnthn sorear: eww.
That's gonna blow up the serialization graph
sorear no, I'm not storing that 19:56
jnthn Oh
sorear I'm just using it so they can call sorry
(also, source position information)
jnthn OK. That sounds like the wrong factoring.
sorear I agree.
That's why I'm talking to you about it.
jnthn Though I should probably ask what you're trying to do before criticising your approach. :)
jnthn did enough criticism today :)
sorear at the very least, PackageHOW.add_attribute really wants to produce a SORRY! 19:57
I'm also trying to move redeclaration error logic into add_my_name
jnthn Hmm. I'd hope your PackageHOW doesn't have an add_attribute. 19:58
Did you mean ClassHOW?
sorear right now, my PackageHOW has an add_attribute that throws an exception
jnthn Oh.
I don't like that apporach. 19:59
sorear because "Cannot find method add_attribute" is very very LTA
jnthn Yes, and that's why we don't give that in Rakudo. :)
You just do .^can on the meta-object. 20:00
If it can't, you report a nice, helpful error.
sorear see #perl6 20:01
I want to have source location on that
jnthn Sure
sorear ideally, integrated into the SORRY/$*FATALS system
jnthn So try/CATCH around the meta-method call.
And then SORRY in CATCH
sorear ew
jnthn Well, it's a bunch better than what you're suggesting. 20:02
There's not very many declarators.
Need to think about the meta-programmer.
Making them write a bunch of methods that throw exceptions for things they don't want to support is a sub-optimal meta-programming experience. 20:03
Plus it's easy to write a generic thing that does CATCH -> SORRY
And pass a closure to it.
That's probably how I'll factor it in nom. 20:04
moderator weekly Perl 6 status meetings with phase transitions: Tue 19:00 UTC | IR clogs at irclog.perlgeek.de/phasers/today 20:39
20:51 [particle] left 21:03 [particle] joined 22:10 benabik left 22:13 lichtkind left 22:32 mberends left 22:34 mberends joined 22:38 mberends left 23:54 [particle] left, [particle] joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!