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.
Set by moderator on 23 August 2009.
01:39 particle joined 12:17 mikehh joined 12:39 masak joined 15:31 jhorwitz joined 15:59 raig joined 16:13 raig` joined 17:29 pmichaud joined
pmichaud my report for today's #ps 17:40
What I did (since 2009-08-18):
* Worked on updating Rakudo's Configure system to better detect when "make install-dev" hasn't been done for Parrot
* Assisted with Rakudo #20 ("PDX")
* Did more planning for handling of lexicals and parameter bindings
What I'm doing this week:
* Grant-related administrative things
* Finishing up Lisbon-related posts and planning activities for Rakudo Star 17:41
* Working on many NQP updates
What I'm blocking on:
* Insufficient waking hours
EOR
17:44 rdice joined 17:49 whiteknight joined
Tene REPORT: 17:51
Um, dunno.
I said I'd do some stuff for masak and japhb.
Haven't had time yet.
KTHXBAI
17:57 mikehh_ joined 17:58 darbelo joined
NotFound What I did: 18:02
* Set auto_attrs flag in most remaining PMCs.
* Fixed some issues in the order of initialization of the interpreter.
* Replaced logic in Object.clone that duplicated functionality of
Parrot_oo_find_vtable_override to a call of the later.
* Cage cleaning related to the recent merges.
What I will do:
* Keep looking at the recent merges.
* Take a look at interdepences between oo.c and Object and Class PMCs.
EOR
18:08 jonathan joined
cotto # What I did: 18:11
* finally understood the actual purpose of contexts thanks to allison++
* ran some quick and dirty experiments to see if the current context + the current sub is sufficient for profiling
- it looks promising now that I understand contexts
# What I hope to do and how many tuits I expect to have:
* use the context "stack" as a way to map beween CPS and Callgrind's call/return expectations
* hopefully, get the code cleaned up and merged
# What could block my progress:
* nothing external
eor
q1q
18:11 allison joined
mikehh What I did 18:11
* testing, testing, testing
* on both amd64 and i386 with gcc and g++
* built and tested rakudo, partcl and cardinal
* but lua failed to build
* fixed codetest (and distro_tests) failures and manifest_tests failure
What I want to do
* more of the same
* incorporate nqp_test into smolder_test and test (not as separate step)
* and missing tests into fulltest 18:12
eor
18:12 kid51 joined
allison - Continued work on test failures in the pcc_arg_unify branch. Added 2700 test failures when I got the PIR version of Test::More working (printing out the plan so the tests were counted). Resolved 2500 of them when I switched MultiSub to use the new argument passing scheme. 18:13
- Spent some time answering Tene's questions, he did some great work on pcc branch test failures too.
- The email2trac interface is working now, replying to a ticket status message on parrot-tickets will add a comment to the ticket in Trac.
- Reminder: Parrot Foundation elections are today.
EOR
darbelo The past: 18:14
* Busy week. Didn't get to do much coding.
* Forgot to thank cotto++ for being an excelent mentor.
* GSoC is done. I CAN HAZ GOOGLES COTTON!
* Started documenting the PMCs.
The future:
* Will write a big summary of this summer.
* Still plan to work on decnum-dynpmcs.
* Started getting evil ideas for the future of decnum-dynpmcs.
EOR
jonathan Rakudo
* Got my Hague Grant finished up, submitted final report
* Was mostly just getting traits on variables and attributes functional
* Expect there will be some ongoing spec tweakery around that, but we have something that works now
* Plus tests for that of course...
* Rakudo day today has mostly been bug fixes and also...
Blizkost
* New project to embed Perl 5 in Parrot and expose it through HLLCompiler interface
* Already got it to the stage that you build and install it, and then eval('print "hello from Perl 5"', :lang<perl5>) will work
* Will be loads of harder bits later on of course, but it's not a bad outcome for half a day's hacking 18:15
* Planning to have a pretty free policy on commit access to it
* It's on github: github.com/jnthn/blizkost/tree/master
Parrot
* Fixed a PCT bug today. One that I-- introduced, not pmichaud++. :-)
.end
jhorwitz what i did:
* fixed broken mod_parrot due to API deprecations
* began looking at mod_perl6 failures but ran out of tuits
* some foundation financials
EOR
duk3leto What I did: 18:20
* Attempted to work with rurban's patch to fix the Complex NaN bug (TT #358), but failed.
* Wrote many tests for the proper handling of Inf/NaN, which exposed some bugs in fdiv, cmod and mod when using PMCs
* Updated editor documentation regarding generating tags
* Found out that sin and asin are implemented, as well as sinh but not asinh.
* Updated documentation about math functions in Ch04 of The PIR Book
* Signed up to be the release manager of Parrot for October. Exciting!
What I want to do:
* Add missing trig functions as dynops
* Continue testing NaN/Inf errors
EOR
japhb Done: 18:26
* Day one of Parrot Plumage implementation work ...
* Which turned out not to involve any implementation,
* But rather creating the repo and SHOUTING FILES,
* Doing a bunch of NQP exploration,
* And finally blogging about it.
* Response was mixed.
* pmichaud++ for perfectly timed skillful mentoring and talking me down to earth.
To do:
* Lots. No really, LOTS.
Blockers:
* Lack of $time and surplus of @work_tasks
EOR
18:30 Util joined
whiteknight What I did: 18:30
* Merged the pmc_sans_unionval branch into trunk. jessevdam++
* Examined the fixed-size allocator, it's malfunctioning so it's been turned off.
* Moral support for bacek and the context_pmc3 branch
* Misc fixes, testing, cleaning
What I am doing:
* More of the same
What I am blocking on:
* Nothing
Util # Done: 18:31
* NULL
# Plan for next week:
* Packfile PMC issues
# Blockers:
* Tuit chaos.
.end
18:32 treed joined
whiteknight hello 18:32
allison hi all
18:32 Coke joined
japhb o/ 18:32
mikehh hello there 18:33
Coke I have a belated one line report.
Util hi
allison Coke: drop it in whenever
cotto good day
NotFound Hola
darbelo Hello
Coke r40628 has a really big memory leak, making parrot unusable for partcl at HEAD.
.
duk3leto 'ello 18:34
darbelo ENOCHROMATIC
allison IIRC, chromatic said he'd be missing this week, so let's go ahead
whiteknight I think I have a fix for r40628, haven't had any time to test the patch though
will get on that tonight
Coke whiteknight: I can test it, post it on the ticket. =-)
allison Any missed reports?
Any questions? 18:35
whiteknight q1q
cotto q1q (total of one)
duk3leto q1q ?
whiteknight "queue 1 question"
allison whiteknight: go ahead with your question
whiteknight brought up on the list a little: the context_pmc3 branch. I think we need to iron out the deprecation issues that might prevent that from being merged 18:36
duk3leto ok, 10-4. I would like to q1q
allison whiteknight: I'll review the branch today or tomorrow
whiteknight okay, I'm not in a huge rush, but I want to make sure the deprecation policy doesn't require a cycle to make changes to internals 18:37
allison whiteknight: it's likely possible to make the API functions/macros backward compatible, but can't be sure until I look at it
whiteknight okay, fair enough. On a related note, if people want access to our contexts, we should put an API together for that
allison (I'm doing the same on the pcc branch, making API functions backward compatible)
whiteknight because there is a lot of direct-poking at structure fields going on that shouldn't be going on 18:38
ok
EOQ
allison whiteknight: honestly, contexts and return continuations (and possibly also call signatures) are likely all collapsing anyway
whiteknight right. turning them into PMCs now is the first logical step in that I think 18:39
allison down to one "call state" object
right
whiteknight yes, and I would like to deploy CallState by 2.0, instead of wating till post-2.0 to start i
whiteknight has stupid fingers today
pmichaud see also my note on parrot-dev about "rakudo can't wait for this until February 2010"
allison so, the "interface" may be no more than adding a :call_state parameter type to get the object
pmichaud: on the flip side, merging in a branch without a sane migration strategy will cause Rakudo more pain than it'll ease 18:40
pmichaud allison: my note addresses that. 18:41
allison pmichaud: okay, will take a look
pmichaud the pain of waiting is becoming much greater than the pain of breakage.
allison (no need to duplicate discussions from the mailing list here)
pmichaud we can address breakage. We can't do much about a wait.
jonathan (sorry, store took longer than I thought, here now) 18:42
whiteknight especially if it's a wait-because-of-policy
allison policy is there for a reason, it saves us from shooting ourselves in the foot :)
whiteknight and I just want to make sure the policy is sane, consistent, and does what we all need it to do
pmichaud actually, the policy isn't saving us from that either (see note at bottom of my message :-) 18:43
allison but, it is perfectly possible to do a stepped migration that preserves an old interface
whiteknight it does no good if the policy shoots us in the foot, to prevent other things from doing the same
okay
18:43 kurahaupo joined
allison it's not a binary choice between "change everything now" and "change nothing" 18:44
mikehh as I understand it - the changes are to the internals (which some languages are using) not to the interface
whiteknight right, if this change affects them, it's probably because they weren't using an interface in the first place
jonathan Rakudo probably has in a couple of places poked into internals that I would not count as unreasonable to have changed. 18:45
allison won't know until I look at the branch
whiteknight okay, thanks.
jonathan I fully expect when the calling conventions branch lands to have to change a bit of Perl6MultiSub, for example. 18:46
(In fact, I'll get to delete about 40-50 lines of code.)
allison cotto: you had a question?
cotto This week instead of having a nonspecific priority like "testing", how about trying to increase test coverage by (e.g.) 3% on a specific platform? 18:47
allison cotto: sounds reasonable, do we have a way of measuring percentage of test coverage?
cotto make cover
japhb Cotto, I thought the current week's priority (see /topic) was pretty specific ...
cotto that was for last week, iiuc 18:48
allison cotto: and which platform?
japhb cotto, sorry, I meant last week, yes
cotto, but is that priority completed? 18:49
NotFound We're not stable again, this is still a priority
allison japhb: merging branches is an ongoing task
japhb That's what I thought ... so my suggestion is to keep that priority and focus.
allison are there more branches pending merge? 18:50
cotto mj41 has a bot set up to run make cover and publish the results. We could go with whatever platforms he's running to prevent the need for users to run make cover.
(he has x86 and x64 builds going iirc)
allison or, are we on "get stable after branch merges" instead
18:50 kid51 joined
allison cotto: that's general again, harder to target 18:50
NotFound The later 18:51
There is a memory leak waiting fix, mainly.
pmichaud will the calling conventions branch land before the release?
are there other branches that are expected to land before the release?
allison so, priority this week "stability after branch merges, increase test coverage on LInux x86"
?
I don't plan to merge calling conventions before 1.6, but hope to merge it the week after 18:52
cotto I'd like to see a percentage in there, but yes.
pmichaud is there _anything_ that can be done to speed up the calling conventions branch? it's been "postponed" for months now. 18:53
allison cotto: I don't have a sense of how many tests 3% would be, so don't know if it's a reasonable 1-week target
cotto We can set a goal and see how reasonable it is to meet during the week.
allison pmichaud: it was postponed by my paying job, that always eats up the summer 18:54
pmichaud: so, yes, there's one thing that would speed it up, but it's not a likely thing :)
moderator Vision for 2.0: Production Users | Priority for 1.6: Merge Branches | Priority for this week: stability after branch merges, increase test coverage on Linux x86 by 3% | trac.parrot.org/parrot/wiki/Propos...chProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead. 18:54
NotFound Win the lotto? 18:54
japhb NotFound, I am *so* working on that.
allison pmichaud: on the plus side, I'm pretty much off the rest of the year 18:55
japhb US "MegaMillions" lottery is up to 1/4 Billion dollars ....
allison cotto: how about we don't attach a percentage this week, and see how much can get done this week? 18:56
cotto sounds great
moderator Vision for 2.0: Production Users | Priority for 1.6: Merge Branches | Priority for this week: stability after branch merges, increase test coverage on Linux x86 | trac.parrot.org/parrot/wiki/Propos...chProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead. 18:56
moderator Vision for 2.0: Production Users | Priority for 1.6: Merge Branches | Priority for this week: stability after branch merges, increase test coverage on Linux x86 (no %, calibrating workload) | trac.parrot.org/parrot/wiki/Propos...chProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead. 18:57
japhb sorry for collision 18:57
allison japhb: yours is clearer
duk3leto: you had a question?
kid51 q1q 18:58
cotto for the record, current test coverage is 65.8% (tapir2.ro.vutbr.cz/cover/cover-resu.../c_cover/)
duk3leto allison: implementing other trig functions as dynops that Rakudo currently manually implements. good idea? 18:59
such as, asinh and friends
allison pmichaud: do you have an opinion on that, would dynops be helpful?
duk3leto the "obscure" math ops are badly named, i am thinking of a dynop containing all the extra trig ops 19:00
pmichaud for Rakudo, I suspect not so much
unless it's a huge speed win (which it could be), we're likely to keep the Perl 6 definitions around
duk3leto i meant to say, a dynop collection that contains all the extra non-core trig ops
pmichaud for other languages it could be a big bonus, however.
allison duk3leto: go ahead, and shouldn't they be in math.ops? 19:01
(I mean src/dynoplibs/math.ops)
duk3leto allison: i am indifferent to where they go. currently only the rand dynops are in there, and then the obscure trig ops are in obscure.ops
mikehh on my last run of make cover I got 68.1% on i386 and 64.6% on amd64
allison or, to split them out, make it math_trig.ops 19:02
duk3leto allison: splitting them out sounds better to me, that way, people only load small sets of dynops that they actually want
allison duk3leto: sounds good 19:03
whiteknight 360 tests, about
allison kid51: you had a question? 19:04
kid51 I will be meeting with members of Buffalo.pm tonight and Toronto.pm on Thursday. Is there any task in either Parrot or Rakudo that almost-complete-newcomers can take on (apart from Smolder testing of Parrot)?
whiteknight writing tests 19:05
allison kid51: look at docs.parrot.org and tell us what makes absolutely no sense to a newcomer
kid51: fresh eyes are incredibly valuable for that 19:06
kid51 whiteknight: I doubt noobs can write tests; Allison: that's a useful suggestion
pmichaud kid51: Rakudo needs programs written in p6
kid51 pmichaud: Noted; I'll be passing out copies of your use.perl posts 19:07
pmichaud excellent :)
NotFound And if all makes sense, they are no more complete-newcomers ;)
duk3leto kid51: testing out examples and making sure they work on all platforms. especially sdl and opengl, which have some bugs
kid51: just getting bug reports for which platforms the examples are not working on will be very valuable. 19:08
kid51 duk3leto: Yes, we still have some obscure platforms bug reports from the *last* time I was in Toronto -- 17 months ago :( 19:09
japhb duk3leto, kid51, and if you find anyone who knows OS X linking ... recruit them with a vengeance.
kid51 japhb: Can you be more specific? There is one person who might show up in Toronto who knows that stuff, but I'd need very precisely worded tasks. 19:10
NotFound That reports aren't very useful if no one has access to that platforrm.
kid51 NotFound: Yes, that was our experience last year. 19:11
NotFound We call them 'obscure' for some reason.
Coke well, not after 17 months, no. but if we can get on top of them immediately, that's great.
duk3leto NotFound: knowing something is broken on a platform we don't *currently* have access to is useful. then we can fix the *currently* part
japhb kid51, basically, I have *no* idea how to fix OpenGL on Mac OS X when it breaks, or even what broke it. We get it working for a couple releases, and then bam it breaks, and I don't know what to do with the pieces.
kid51 japhb: Are there any TTs on that subject?
Coke I'd be sure to say if you submit a bug report on some obscure platform, you're going to need to do more than just file the initial report.
japhb kid51, yes, I believe so, checking
19:12 davidfetter joined
NotFound duk3leto: I think that asking people for a work that will not have any visible benfit for months or years is discouraging. 19:12
japhb kid51, here's one: trac.parrot.org/parrot/ticket/924
pmichaud we can get visible benefit if the person filing the bug report can be available for followups
Coke (that's what I said!) 19:13
pmichaud (yes, I'm agreeing with coke++)
Coke ^_^
kid51 japhb: If you see others, just post on list before thursday
NotFound pmichaud: agreed, but that's a completely different petition.
japhb kid51, roger that
kid51 Thanks for the responses. 19:15
allison any more questions?
Roadmap review for 1.6: trac.parrot.org/parrot/report/14 19:16
export conventions and hll interop (#566, #567, #568)
japhb I've had no cycles for that, because of module ecosystem 19:17
Tene?
Looks like he's away. I know he's doing some work this week. (Was planned for last night, but got bumped by his $life)
allison okay, great, so "in progress" 19:18
packfile pmcs?
call it "at risk" 19:19
Util Little progress, but I expect to have more tuits this week.
allison excellent
Util "at risk" sounds about right :)
allison pir profiling tools and pluggable runloops? 19:20
looks like the branch is about to merge?
cotto on track
allison great
cotto a merge this week is not overly optimistic
mikehh if anyone need any branch testing just let me know 19:21
allison cotto: likely before 1.6?
cotto very
allison excellent!
standard seed libraries? 19:22
the thought for 1.6 was zlib
not a high priority
(beginning to wonder if seed libraries should be on the Parrot roadmap) 19:23
whiteknight +1
NotFound I don't even started to look at zlib, got distracted by the auto attrs thing
japhb allison, I delayed working on seed libraries until I know what I need for the module installer
allison japhb: aye, I'd say that comes first 19:24
and, the whole seed libraries question we've pushed off to the module installer
japhb nod 19:25
allison may be time for a ticket name change, call it "module installer (for standard libraries and extensions)"
japhb NotFound, if you happen to get a working zlib, that would be cool anyway. :-)
allison review objects PDD starts as a task for me, will work on that this week
(split it into any task tickets) 19:26
prune c data structures?
whiteknight PMC got pruned pretty good
PMC_EXT got killed
sort of a side-effect of other work though
allison aye, but it's a general task 19:27
japhb q1q
allison the contexts branch is also progress
whiteknight yes
and the Parrot_Sub structure is gone now
allison a review of other candidate C structures in the next couple of weeks would be good 19:28
that's it for the roadmap review
any other questions, comments, discussions? 19:29
ah, japhb had a questions
s/s//
japhb jonathan or pmichaud: any idea when you would be able to add object attribute declarations to NQP?
At least private ones?
pmichaud japhb: it's not high on my priority list at the moment. I might be able to bump it up a bit if it's not too difficult. 19:30
japhb planning whether to continue with NQP on next hacking day, or switch temporarily to Rakudo)
jonathan pmichaud: I probably can if you approve it.
japhb pmichaud, gotcha
pmichaud it may fall out of other refactors I'm doing
jonathan: I'm in favor of adding private attributes to NQP; not much more than that, though.
japhb ISTR pmichaud did approve private attributes
and there we go
pmichaud I'm not at all in favor of supporting auto initialization or automatic accessor methods
at least, not yet
japhb (That's all I really need anyway) 19:31
EOQ I think 19:32
meeting all done? 19:33
allison okay, that's a wrap. thanks everybody!
19:33 Util left, pmichaud left, NotFound left, jonathan left 19:34 Coke left, darbelo left 19:46 kid51 left 20:14 raig` left 21:16 allison joined 21:45 Whiteknight 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!