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