Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2009-08-18

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

All times shown according to UTC.

Time Nick Message
00:14 rdice joined #parrotsketch
00:27 davidfetter joined #parrotsketch
01:17 mikehh joined #parrotsketch
02:05 japhb joined #parrotsketch
03:54 mikehh_ joined #parrotsketch
05:20 cotto joined #parrotsketch
08:59 masak joined #parrotsketch
11:47 Whiteknight joined #parrotsketch
14:10 masak joined #parrotsketch
15:49 japhb Early report; probably back to not able to make meetings again:
15:49 japhb * Work Done:
15:49 japhb + https://trac.parrot.org/pa​rrot/wiki/ModuleEcosystem -- Comments welcome!
15:49 japhb + Discussed with pmichaud feasibility of writing install tool in NQP (or subset of Perl 6 for now, converting to real NQP in a couple releases); he believes it is reasonable.
15:49 japhb * Next Tasks:
15:49 japhb + Probably nothing until September ($work deadlines)
15:49 japhb + Then start on install tool
15:49 japhb * Blocking On:
15:49 japhb + $work deadlines
15:49 japhb EOR
16:00 davidfetter joined #parrotsketch
17:24 Whiteknight What I did:
17:24 Whiteknight - Released 1.5.0 "TEH PARROTZ!" to much fanfare
17:24 Whiteknight - Lots of testing, emailing, badgering in preparation for the release
17:24 Whiteknight - Started a new branch to start making Contexts into a PMC type
17:24 Whiteknight - Started testing/benchmarking the new lazy PObj allocator, and trying to tune values to improve startup time
17:24 Whiteknight What I will do:
17:24 Whiteknight - Continue the Context PMC work
17:24 Whiteknight - IO stuff
17:24 Whiteknight - GC Work (tuning the lazy allocator, using/testing/benchmarking the fixed-size structure allocator)
17:24 Whiteknight What I am blocking on:
17:24 Whiteknight - Not enough time.
17:32 smash joined #parrotsketch
17:35 pmichaud joined #parrotsketch
17:37 NotFound joined #parrotsketch
17:50 cotto # What I did:
17:50 cotto * got the profiling runcore working with as a pluggable runcore
17:50 cotto - also made the runcore smarter about profiling instructions in inner runloops
17:50 cotto - the pluggable part of the code is solid (thanks chromatic!)
17:50 cotto - instruction-level profiling should be good
17:50 cotto - the problem lies with turning Parrot's CPS into something Callgrind can use
17:50 cotto - to this end, spent some time understanding continuations and CPS (am mostly there now)
17:50 cotto - chromatic and I will be hashing this out (with a wiki page) this week
17:50 cotto # What I hope to do and how many tuits I expect to have:
17:50 cotto * figure out a nice way to stuff Parrot's CPS into a Callgrind file
17:50 cotto * various other smaller improvements to profiling runcore
17:50 cotto * tuit outlook is good
17:50 cotto # What could block my progress:
17:50 cotto * no external blockers
17:51 cotto eor
18:02 pmichaud What I did (since 2009-07-28):
18:02 pmichaud * Rakudo now builds from an installed Parrot
18:02 pmichaud * Rakduo has a "make install" target (needs work, but it functions)
18:02 pmichaud * Worked with Gerd++ on a Fedora 12 package for Rakudo
18:02 pmichaud * Cleaned up some default parameter types in Rakudo
18:02 pmichaud * Moved more things into the setting
18:02 pmichaud * Updated the Rakudo ROADMAP
18:02 pmichaud * Changed <...> and <<...>> to circumfix: instead of quote:
18:02 pmichaud * Added #`[embedded comment] syntax
18:02 pmichaud * Added some Whatever prefix: operators
18:02 pmichaud * Filled out Rakudo release managers for 2009
18:03 pmichaud What I'm doing this week:
18:03 pmichaud * Catching up from travel
18:03 pmichaud What I'm blocking on:
18:03 pmichaud * Too much travel
18:03 pmichaud * Insufficient waking hours
18:03 pmichaud EOR
18:03 Util joined #parrotsketch
18:04 chromatic joined #parrotsketch
18:04 chromatic Merged the runcore encapsulation patch to the branch.
18:04 chromatic Some cleanup.
18:04 chromatic Working on an Integer optimization; a PMC with only one attribute is *a lot* faster when we don't allocate a new attribute struct for it.
18:08 chromatic Answered several questions here and there.
18:08 chromatic I will: continue working with cotto on the profiling core.  We're close.
18:13 allison joined #parrotsketch
18:13 NotFound What I did:
18:13 NotFound * Finished the auto_attrs branch and merged it to trunk
18:13 NotFound * Tested a change in the way class_init PMC functions are handled, TT #918
18:13 NotFound * Minor fixes
18:14 NotFound What I will do:
18:14 NotFound * Try to help with some of the active branches
18:14 NotFound What I'm blocking on:
18:14 NotFound * Too much heat ':)
18:16 barney joined #parrotsketch
18:16 l3t0 What I did: http://leto.net/dukeleto.pl/2​009/08/parrot-hacktivity.html
18:16 Coke joined #parrotsketch
18:17 allison - Fixed test failures on the pcc_arg_unify branch. Down to 308 failing tests in the 'corevm' target. Still can't build PGE, but the failure is now in a different part of PGE (later in the build).
18:17 allison - Added a 'make corevm' target in trunk, allowing 'coretest' to run with out building PGE and PCT.
18:17 allison - Added the current Fedora spec files from Gerd Pecora.
18:17 allison - Working my way through the past 9 months of parrot-dev posts, down to 200.
18:17 allison EOR
18:18 Coke Working on partcl, EOR.
18:19 l3t0 What I will do: hack on various TT's
18:20 l3t0 What I am blocking on: there does not seem to be any spec for sNaN, the signalling NaN, which is mentioned in PDD14
18:26 Util # Done:
18:26 Util * Fixed the doc error that l3t0 mentioned in packfile.c.
18:26 Util # Plan for next week:
18:26 Util * Resolve discrepancies in PDD13 vs actual Packfile {.c,PMC} implementations.
18:26 Util * Write up Trac tickets for Packfile PMC's roundtrip failure and missing basic functionality.
18:26 Util # Blockers:
18:26 Util * None.
18:26 Util .end
18:31 mikehh Testing and fixing failed tests
18:32 cotto Hello.
18:32 NotFound Hola.
18:32 Util hi
18:32 l3t0 'ello
18:32 japhb o/
18:32 barney hi
18:32 allison hi
18:32 mikehh greetings
18:33 Coke ~~
18:34 allison let's get started, any questions?
18:34 jonathan joined #parrotsketch
18:35 NotFound q1q
18:35 allison go ahead NotFound
18:35 NotFound TT #918 needs a deprecation cycle?
18:35 * allison looking
18:35 Coke https://trac.parrot.org/parrot/ticket/918
18:37 allison If you eliminate the pass variable, it would need a deprecation cycle, but otherwise it isn't changing functionality, just reorganizing
18:37 allison pass could probably be passed as an argument to the static function
18:38 NotFound It doesn't eliminate it, is just no more in scope in the user supplied part.
18:38 jhorwitz joined #parrotsketch
18:39 NotFound That way has no advantage, we'll need the deprecation cycle to get rid of it.
18:40 allison NotFound: aye. The rule of thumb is "if users have to modify their code, it requires a deprecation cycle"
18:40 l3t0 where should tickets regarding mod_parrot go? it doesn't build with the newest parrot
18:40 allison the advantage is, you could make the change now, and then eliminate the pass argument in a deprecation cycle
18:40 * jhorwitz is actually here today, though very late
18:40 allison (instead of waiting for the whole thing)
18:41 NotFound allison: yes, but we can't be sure that no one isn't using any other symbol accidentally in scope.
18:41 allison NotFound: then a deprecation cycle it is
18:41 NotFound allison: ok, EOQ
18:42 jonathan q1q
18:42 jhorwitz l3t0: there is a list for that -- i will publish on http://smashing.org/mod_parrot in a bit
18:42 allison jonathan: go ahead
18:43 jonathan allison: I've got a couple of questions on the calling conventions changes that you're currently working on.
18:43 allison okay
18:43 jonathan The backdrop to this is that I'm planning to work in the near future on re-designing and re-implementing Parrot's signature handling and signature binding.
18:43 jonathan So I'd like to get a little more idea on what I can expect from Parrot in a couple of cases.
18:44 allison this may be a longer question, more suitable for #parrot, but let's give it a try
18:44 jonathan 1) Do you plan for Parrot to support a mechanism whereby a positional parameter can be marked as taking a named parameter too? That is, if a named one matches, it takes priority?
18:44 jonathan (this is 1 of 2 :-))
18:44 Whiteknight you mean :lookahead?
18:44 jonathan Right, if that's what it shall be called.
18:44 jonathan And if that's what it does. :-)
18:45 allison yes, that's patrick's suggestion, accepted
18:45 jonathan OK, and do you see this as landing shortly after the current refactors, or further into the future?
18:45 jonathan I'm willing to give tuits to making it happen if needed.
18:46 allison jonathan: I'm not working on it at all, feel free
18:46 jonathan OK.
18:46 jonathan After you've landed the current branch?
18:46 jonathan Or is it appropriate to work on it in that branch?
18:46 Whiteknight that's one of those things that I suspect will land quickly after the first round of refactors land
18:46 allison (you could even add it now, since it's largely orthogonal to the refactors)
18:46 allison jonathan: I'd do it in a branch
18:46 jonathan I'd rather work on the refactored code.
18:46 jonathan OK.
18:47 allison jonathan: I'm not touching that part of the code at all
18:47 jonathan Oh, ouch.
18:47 jonathan What is changing?
18:47 allison really, what this branch does is change the way arguments are passed around the system
18:47 jonathan OK, it's not going to attack inter_call.c and the things that go on in there?
18:48 allison instead of a handful of different argument passing strategies (varargs, pointer to op, fixed integer array, resizable integer array, etc)
18:48 allison they're all passed as a call signature PMC
18:48 jonathan OK
18:48 allison (which is a bit like a Capture)
18:48 jonathan Will there be a way to just get at that CallSignature PMC and process it?
18:49 allison inter_call.c, etc are later refactors
18:49 jonathan That is, rather than specifying a bunch of .param's I could instead say "i can haz CallSignature?" and unpack it myself?
18:49 allison jonathan: not at first, but we will add a :signature or something like that, which takes a whole call signature as a single parameter
18:49 jonathan :signature feels misleading - I'd expect more like :capture
18:49 Whiteknight .param sig :signature?
18:50 allison :sig_object or whatever
18:50 jonathan But maybe that's my Perl 6 world view coming in too much. :-)
18:50 allison .param pmc foo :signature
18:50 allison aye
18:50 allison jonathan: capture is Perl 6, not using it :)
18:50 jonathan OK. And that'd essentially side-step the stuff in inter_call.c that binds parameters, and just give to me the the CallSignature that got constructed on the caller side?
18:51 allison jonathan: oh, I'm already sidestepping the parameter binding stuff
18:51 jonathan OK.
18:51 allison it's done via the call signature
18:51 allison but, yes, you'd just get the CallSignature, and could do whatever you like with it
18:51 jonathan So basically after your refactor, it'll be easy for me to always rely - no matter wehther I'm handling an invocation from PIR or C or whatever - on having a CallSignature with the args in?
18:52 allison essentially, the entire system is using PCC now
18:52 allison yes
18:52 allison everything uses a call signature
18:52 jonathan OK, that sounds good.
18:52 jonathan I suspect that I may well go down that road.
18:53 jonathan And last of all, do you have a rough idea of when the refactor will be mergable?
18:53 jonathan Are we looking at a week, two weeks, a month, two months...?
18:53 pmichaud :signature sounds wrong
18:53 allison The conversion is done, I'm in the long tail of fixing failing tests
18:53 pmichaud a "signature" is something that attaches to the sub, not the arguments
18:53 allison so, no time estimate
18:53 pmichaud i.e., a sub has a signature that indicates what kinds of arguments it accepts
18:54 pmichaud "call signature" might be more appropriate.  or "arg signature"
18:54 jonathan allison: OK. I'll keep watch of your commits to get an idea of how things are going. :-)
18:54 jonathan And if you want Rakudo testing against that branch, let me know.
18:54 jonathan EOQ - thanks.
18:54 jonathan (erm, *when* you want...)
18:54 allison jonathan: will let you know when we get to that point
18:55 jonathan allison: Oh, one more thing
18:55 jonathan In the CallSignature, the invocant will be available just as the first positional, as today?
18:55 allison pmichaud: the name is unspecified at the moment
18:55 allison jonathan: yes, with the signature string "Pi" (marked as invocant)
18:56 allison so a method call that returns a single integer is "Pi->I"
18:56 jonathan OK, but if I have a Sub PMC in $P0, and it was marked as :method when declared, I can call it as both inv.$P0(a, b, c) and $P0(inv, a, b, c) ?
18:57 allison no
18:57 TimToady bad, bad
18:57 jonathan Rakudo relies *very* heavily on being able to do that.
18:57 allison that's not guaranteed to work now
18:57 allison that's your syntax parsing, not Parrot
18:57 jonathan Hmm?
18:57 jonathan I don't follow.
18:57 TimToady it's fundamental to p6 dispatch mechanisms
18:58 allison yes, but p6 dispatch is built on top of Parrot
18:58 TimToady not if it behaves like that
18:58 jonathan To put it another way, if you break the ability to do that, it will require a deprecation cycle, because it will cause Rakudo to need to re-write code. You can't just break that.
18:58 TimToady or did you mean the other 'built on'? :)
18:59 jonathan I suspect Rakudo is also not the only compiler relying on this ability.
18:59 allison that really has nothing to do with the call signature, that's a question of whether the method is stored in the namespace
18:59 allison and patrick keeps insisting methods shouldn't be stored in the namespace
18:59 pmichaud note that "namespace" isn't involved in jonathan's question
18:59 allison so, I'm assuming that you're not using that mis-feature
18:59 pmichaud note that "namespace" isn't involved in jonathan's question
19:00 jonathan allison: No.
19:00 pmichaud jonathan's question is completely independent of namespaces
19:00 allison okay, stop, we're far exceeding the scope of parrotsketch
19:00 jonathan allison: Imagine that I have some $P0 which is a Parrot Sub. Right now, we can invoke it as $P0(a, b, c) and if it was declared as :method then self becomes a.
19:00 allison obviously I don't understand what it is you're relying on
19:00 pmichaud (also, the "patrick keeps insisting part" is actually "how allison originally said it should work"  :-)
19:00 allison but, let's carry this to #parrot
19:01 jonathan OK, sure, there's evidently a bunch more detail to work out here than I'd hoped.
19:01 allison yes, we will provide a way to support whatever features p6 needs
19:01 allison but, parrot dispatch *is not* p6 dispatch, and won't necessarily work like p6 dispatch
19:02 jonathan allison: Yes, but this isn't really about dispatch. But anyway, we continue in #parrot.
19:02 allison ok, any other questions
19:02 Whiteknight why do bad things happen to good people?
19:02 Whiteknight :)
19:03 l3t0 signalling NAN?
19:04 allison l3t0: the question from your report?
19:05 l3t0 allison: PDD14 mentions a signalling NAN. There is a bitflag associated to it, and then no other code/spec anywhere describing how it should work
19:06 allison l3t0: it's a new idea
19:06 allison feel free to propose how you think it should work to the list
19:06 l3t0 how would people want it to work? There is a TT about cleaning up PDD14, which is why I am asking
19:06 l3t0 allison: sounds good
19:07 Coke q1q
19:08 mikehh a signalling NaN is to generate an execption
19:09 allison okay, Coke, go ahead
19:10 Coke regarding tcl - there's a lot of segfaults when running 'make spectest', especially with an optimized parrot. I would appreciate more eyes tracking those down.
19:10 Coke They seem to change if I run with or without --optimize.
19:10 Coke (but mostly with)
19:11 chromatic Sounds like STRING NULLness again.
19:11 Coke also, http://rt.perl.org/rt3/Publi​c/Bug/Display.html?id=57088 is a long standing bug that's now affecting more and more of the code.
19:12 Coke Any help on those parrot issues will make my life easier. Danke.
19:12 Coke eoq.
19:13 allison Coke: I can't promise to work on 57088 before the pcc refactor is done, but it is related, and could be a fix soon after
19:13 allison Coke: the test case in that ticket should be added as a TODO test (or maybe skip)
19:14 Coke yes. an excellent task for a cage cleaner; I didn't because it's really 2 files.
19:15 allison agreed (on cage cleaner)
19:15 allison we do have some tests now that dump out a temporary .pir or .pbc file before running a test
19:17 chromatic make testr
19:17 l3t0 i recently added a function to Parrot::Test called pbc_postprocess_output_like, which aids in testing PBC-related things
19:21 allison any more questions?
19:21 allison quick roadmap review of 1.5 (only 3 items) https://trac.parrot.org/parrot/report/14
19:22 allison packfile pmcs? hit or miss for 1.5?
19:22 allison reschedule to when?
19:22 Util miss
19:22 Util 1.6
19:24 allison great
19:24 allison pir profiling tools? hit or miss for 1.5?
19:24 allison (I know great progress has been made)
19:24 chromatic Miss; 1.6 for sure.
19:24 allison same for pluggable runloops?
19:25 chromatic Yes, they're tied together like two things tied together.
19:25 * Tene ties chromatic to chromatic.
19:25 chromatic I can defeat you with mitosis.
19:26 allison okay, I'll update those roadmap items
19:26 allison any other questions, comments?
19:27 chromatic What are the 1.6 priorities?
19:27 chromatic What should we focus on this week?
19:27 Whiteknight we have a lot of branches and stuff to merge in now
19:27 Whiteknight we might want to focus on raw stability this week
19:28 l3t0 "raw stabiliy" = write more tests?
19:28 chromatic Our PMCs are severely undertested.
19:28 Whiteknight that's a good point. Testing?
19:28 allison we could say the focus is "merge branches"
19:30 japhb Vision for 2.0: Production Users | Priority for 1.6: Merge Branches | Priority for this week: merge ready branches, get stable again | https://trac.parrot.org/parrot/w​iki/ProposedParrotsketchProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead.
19:30 Topic for #parrotsketchis now Vision for 2.0: Production Users | Priority for 1.6: Merge Branches | Priority for this week: merge ready branches, get stable again | https://trac.parrot.org/parrot/w​iki/ProposedParrotsketchProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead.
19:30 allison testing is always good
19:31 Util Reminder: coverage scan at http://tapir2.ro.vutbr.cz/cover/cover-results/ can help find large holes in testing.
19:31 japhb Test coverage as week 2 (next week) priority?
19:32 mikehh test cover gives 68.1 on i386 and 64.6 on amd64
19:33 mikehh % that is on Ubuntu 9.04 in each case
19:34 allison I've updated the roadmap tickets
19:34 allison thanks everybody, tty next week!
19:35 Util left #parrotsketch
19:36 Coke left #parrotsketch
19:37 pmichaud left #parrotsketch
19:48 smash left #parrotsketch
20:38 davidfetter joined #parrotsketch
21:36 Whiteknight joined #parrotsketch
22:17 jonathan left #parrotsketch
22:58 japhb joined #parrotsketch

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