Vision for 2.0: Production Users | Don't forget to post closed tickets in your report. | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead. | irclog: irc.pugscode.org/
Set by moderator on 2 February 2010.
14:25 bluescreen joined 18:46 darbelo joined 18:50 whiteknight joined
whiteknight WHAT I DID 18:57
* Worked on fix_icc_failures branch with dukeleto and bubaflub. With branch merge (later today) Parrot will build and pass all tests when compiled with ICC (and throw a lot fewer build warnings to boot).
* Worked on pcc_hackathon_6Mar10 branch. Modest contributions, mostly watched allison and later chromatic work on it
* Killed dead code files src/events.c, src/tsq.c with help from cotto.
WHAT I WILL DO
* Merge the fix_icc_failures branch
* More hacking/fixing on the pcc_hackathon_6Mar10 branch, hope to get that ready soonish
WHAT I AM BLOCKING ON
* Lack of time
19:03 japhb joined
cotto_work #did: 19:05
* helped get opsc to generate the C code for the function-based runcore
- It works (!!!) and causes no new test failures.
- code generation is slow (2:45 with --optimize)
- other lesser warts exist
#will do:
* clean up build process
* profiling and optimizing
* other runcores
#blockers:
* time and brains
#closed TTs:
#eor
will probably be late for #ps but will backscroll
also, bacek++ for doing the majority of the opsc work
19:06 NotFound joined 19:13 davidfetter joined
darbelo DONE: 19:14
- Got the TGE PIR compiler building again.
- More rm_cflags testing on Sun CC.
- Tended after dbm-dynpmcs, kept it in sync with trunk, etc.
- Attended a week-long symposium on embedded systems.
TODO:
- Go back to working on cross-compilation.
- More PIR compiler necromancy.
- GSoC prep. RTEMS research.
EOR
19:19 chromatic joined
NotFound What I did: 19:19
- parrot
* Applied the patch that avoids generation of duplicated string constants.
* Documented the plan for auto/manual_attrs, TT #1506
* Minor fixes.
What I will do:
No plan
EOR
19:28 bubaflub joined 19:33 eternaleye joined 19:47 Coke joined
Coke Done in parrot: 19:53
- merged back rm_cflags - now each invocation of the compiler doesn't
invoke perl too. Involved some last minute windows bugfixen, which
particle & ttbot helped with.
- started to eliminate the dynoplibs recursive make target. nearly done.
(that will leave two.) 19:54
- closed some tickets.
Done in rakudo:
- went through some tickets and through action or inaction, caused them
to be closed. (mainly involved finding a platform on which I could
actually BUILD rakudo; fails on 2 out of 3.)
EOR
20:03 dukeleto joined 20:10 allison joined 20:19 lichtkind joined
chromatic I worked on a couple of branches and made some progress on the PCC refactors. 20:22
I think I have TT #389 cracked, but it'll take some time tomorrow or Thursday to verify that. 20:23
I'm still blocking on time.
allison Last week:
- Started and nearly completed the PCC refactor branch for 'get_results'.
- Thanks to all who participated in the hackathon for that.
- Caught up on mailing list discussions.
Next week:
- Fix remaining failures in PCC branch, prepare for merge after 2.2.
EOR
Util # Done: 20:25
* Mu.
# Plan to do:
* See if TT#1489 is what is causing Rakudo build failures on Win32.
* Try Intel VTune on EC2 on Parrot.
# Blockers:
* $WORK, but an end is in sight.
.end
japhb WIP: 20:29
* Discuss HLL interop changes with Tene
20:29 mikehh joined
japhb * Adding nqp_setup support to plumage 20:29
TODO: 20:30
* More of both WIP items
EOR
dukeleto Did:
* Got PL/Parrot (with eggyknap++) to actually run PIR from Postgres
* Still trying to figure out how to pass arguments and return values between Parrot + Postgres
* Setup an openembedded dev environment on mj41++'s server, getting closer to having a BitBake recipe for Parrot
This means that it will be easy for Parrot to get cross-compiled for all embedded devices supported by OpenEmbedded
* Working on application for TPF and PaFo to be part of Google Summer of Code 2010
leto.net/dukeleto.pl/2010/03/google...-2010.html
* Created new wiki page for GSOC2010 trac.parrot.org/parrot/wiki/GSOC2010 (Please give it some love!)
* Created an RFC to start implementing security measures described in PDD18, but no responded to my email to the list:
trac.parrot.org/parrot/ticket/1500
* Created TT for testing that "make corevm" works correctly: trac.parrot.org/parrot/ticket/1502
* Created TT for making necessary parrot string functions available to embedders: trac.parrot.org/parrot/ticket/1496
Will Do:
* Still planning on writing a blog post summarizing recent developments in the Parrot core + ecosystem
* More of the same
Blocks:
* Real life
.EOR
chromatic Anyone else to prepaste? 20:31
Okay, let's begin. 20:32
Last week review.
mikehh only just got here - hadn't prepared a report
chromatic You can report if you like.
mikehh just a bunch of testing and fixing - branch and trunk 20:33
chromatic PCC Hackathon: how'd that go? 20:34
mikehh some progress - still can't get PGE to build, infinite loop on t/compilers/imcc/syn/regressions.t 20:37
allison the hackathon went well
good team effort
mikehh PGE should not be part of make corevm
allison mikehh: yes, that was a recently introduced bug 20:38
did we get a ticket in for it?
darbelo blames Coke
allison checks trac
mikehh it builds up to there and still can run makecoretest until it loops
chromatic Any estimates of how much more work it needs?
20:39 bacek joined
allison the tasklist is almost complete, so from that perspective it's pretty much done 20:39
what's left is debugging
chromatic As far as I know, there's no progress on TT #389.
allison it would be really nice if we could run the core tests without hanging on PGE
chromatic Anything else on last week's goals? 20:40
mikehh well they start running
bacek Done:
* opsc reached big milestone - generated core_ops.c have no new failures. 20:41
Todo:
* More work on opsc
Sorry, I'm late.
dukeleto fixing "make corevm" -> trac.parrot.org/parrot/ticket/1502
allison dukeleto: excellent, thanks!
it was a pretty easy fix the first time, should be no trouble
mikehh the build system has changed in trunk from rm_cflags merge 20:42
we want to make sure that it also does the same
chromatic Let's pick two new goals for next week. 20:43
Our next release is next Tuesday. 20:44
dukeleto i would like some help on PDD18, maybe make that a goal? 20:45
chromatic Is that the security PDD?
dukeleto my RFC ticket trac.parrot.org/parrot/ticket/1500 got no responses on the list
chromatic: yes
mikehh anything specific we need to include for the release - tests ok for me so far
dukeleto would LOVE some kind of feedback on my proposed API and how to make it happen
chromatic I don't know that PDD 18 helps Rakudo * right away though. 20:46
20:46 whiteknight joined
dukeleto chromatic: that is write. I didn't know the goals where Rakudo*-specific 20:46
s/write/right/
japhb I'm making a push to have Plumage actually *itself* installable (I know, what a concept) this week. dukeleto, do you think you might have some cycles if I need a second pair of eyes/hands?
dukeleto japhb: yep, i can write some tests and or test on my boxen 20:47
japhb dukeleto, cool, thank you.
mikehh we need to be as ready as possible for rakudo*
japhb Anyone else interested is of course invited to ping me for a commit bit
chromatic Does anyone know of the top bugs for which Rakudo needs Parrot fixes? Maybe we should have a HLL bug week. 20:48
dukeleto chromatic: this looks important for Rakudo* trac.parrot.org/parrot/ticket/1505
japhb mikehh, I'm going to see what I can do to get their installer needs met (during the last week, they put out a list of module install/load features they want for Rakudo *)
darbelo "HLL bug week" sounds good.
Coke bah, just call it rakudo bug week. :P
Tene Oh, I'm here. I was overwhelmed by life the past week, didn't get anything done, but did chat with japhb about hll interop stuff. 20:49
KTHXBAI
cotto_work hi
chromatic Anyone else for a Rakudo bug week? 20:50
allison sounds good
Util +1
mikehh +1
Coke WFM
bacek wfm
japhb Definitely +1
Coke q1q
whiteknight +1 20:51
chromatic Alright. That means that we should make fixing Rakudo bugs a priority over exploring other things.
mikehh we also need to get moritz, pmichaud and others involved
spinclad (jnthn, masak) 20:52
dukeleto +1 to rakudo bug week
mikehh right
Coke some of us can hang out in #perl6 on freenode.
dukeleto Coke: i am always lurking in there
whiteknight q1q
mikehh me too 20:53
chromatic Any other thoughts on a weekly priority?
Coke I'm going to keep hacking at the build.
allison that one's important enough to be the one priority for the week
whiteknight agreed
Coke dq1q. 20:54
spinclad (which, rakudo or build?)
Coke spinclad: rakudo
chromatic Let's move to question time. whiteknight? 20:55
dukeleto just notified the peeps in #perl6 to send a list of bugs that Rakudo needs fixed to parrot-dev
whiteknight would like to add a new VTABLE_init_int, which would allow initialization from an integer
Would allow preallocation of things like Fixed*Array, Integer, CallContext, etc
darbelo +1 20:56
bacek -1
Coke pros/cons vs. using init_pmc?
whiteknight Coke: you would have to create a throwaway Integer PMC to do the same thing
darbelo One less throwaway PMC. 20:57
bacek Why it's better that VTABLE_init/VTABLE_assign_integer_native?
whiteknight and the integer PMC would have to be created and then call set_integer
bacek: better atomicity for threaded applications
plus, one fewer vtable call on pmcs that support it
Coke whiteknight: fair enough on the pmc vs. int. +0; =-)
bacek this PMC isn't shared between thread.
chromatic Atomicity is a red herring with our current threading model.
whiteknight "current threading model" being the operative phrase there 20:58
bacek vtable calls are cheap.
whiteknight like saying the potpurri doesn't smell great next to our current garbage
darbelo If tewk's futures runloop would benefit from them.
tewk tewk, pushed this issue.
darbelo s/If //
NotFound What will be the way to invoke that vtable from pir?
allison whiteknight: does this imply VTABLE_init_str and VTABLE_init_num?
whiteknight allison: the case for symmetry can be made, but in the pilot I am proposing, *_int has more utility 20:59
Coke NotFound: new $P1, ['Array'], 5
allison I am in favor or ways to avoid creating intermediate throw-away PMCs
chromatic That's a new op too.
whiteknight new op, yes
$P0 = new ['FixedIntegerArray'], 10 21:00
Coke prolly just an op variant, though that's a small distinction.
NotFound For simmetry at pir level, we can do autoboxing to init_pmc for N and S.
whiteknight NotFound: yes, that's a good stop gap measure while we consider the utlity of init_string and init_number vtables 21:01
allison NotFound: yes, that's sensible, avoid the extra vtable functions unless absolutely necessary
chromatic Why add ops for the sake of symmetry?
-1 to adding ops unless there's a significant benefit to adding them. 21:02
Coke +1 on only added what we need.
*adding
whiteknight a small pilot experiment would need one op and one vtable
darbelo We could just atobox, and only add the vtables if benchmarking shows the boxing hurts.
whiteknight marked experimental, we could remove it later or expand on it if people like it
tewk +1
darbelo That would add no vtables. 21:03
dukeleto this conversation sounds like it is getting a bit too-detailed for #ps, can we take it to #parrot ?
chromatic One question for #ps is "Is this a good use of our time right now?"
darbelo Maybe next week would eb better. 21:04
chromatic I mean it may or may not be a worthwhile experiment (and it sounds like the consensus runs generally positive), but is it the most worthwhile feature we could be working on now? 21:05
whiteknight chromatic: I think the time investment would be minor for an experiment
dukeleto chromatic: worthwhile for Rakudo* or for parrot in general? 21:06
chromatic My bias is what's worthwhile for Rakudo * is worthwhile for Parrot in general.
Frankly, if whiteknight works on this instead of TT #1505, I think that hurts both Rakudo * and Parrot.
allison chromatic: the specific benefit mentioned was in PCC cleanups 21:07
whiteknight I think #1505 will be done tonight
bacek and vice versa
whiteknight I know how to prioritize when a release is nigh
bacek How much work left on PCC cleanups?
dukeleto chromatic: in some sense, yes. But as a PL/Parrot dev, getting some semblance of a security subsystem would be very important to all embedders, which is possibly a lot more people than Rakudo devs
allison bacek: in this particular branch, just PGE debugging 21:08
bacek: it's a series of small refactors
bacek allison, ok. I'll try to jump on this branch today/tomorrow to help finish it. 21:09
chromatic I'm not saying "Don't experiment" or "Let's not add new features", but that we agreed on priorities in the November meeting and I'm concerned that we're not going to achieve them.
allison then it's worth reviewing those priorities 21:10
possibly in a quick note at the end of every weekly meeting
dukeleto i think making "make corevm" work correctly is, like, massively important
whiteknight dukeleto:: +1
cotto_work +1 21:11
NotFound +1
dukeleto can we make that a priority this week, along with fixing rakudo bugs? 21:12
chromatic Sounds like there's agreement on that.
whiteknight the fix, ideally, will be smal 21:13
a test to prevent regressions, however, could be large
chromatic Coke said he'd look at it today after his day job. 21:14
allison whiteknight: the fix is good enough 21:15
the test is, possibly impossible 21:16
dukeleto the fix is key, but the test prevents this from happening again in the future, which is still quite important. But not as big as fixing "make corevm" right now
allison: i can make that test, i just haven't had much time to throw at it
allison: no stopping energy is necessary ;)
allison dukeleto: the more limited test we talked about? aye 21:17
mostly just saying "make the fix first priority, the test is lower, but good to have"
dukeleto allison: yes, your idea for checking for the non-existence of some files after "make corevm" is a great idea
allison: i am in full agreement
chromatic Other priorities?
darbelo World Domination. 21:18
chromatic That's our priority every week. 21:19
particle how do you know corevm hasn't been run after all, or some target which would create files outside corevm?
dukeleto chromatic: if i could get some feedback on trac.parrot.org/parrot/ticket/1500, i could move forward on that. I just don't know if my proposed API is even reasonable at this point
allison particle: corevm is a subset of the more full build target 21:20
particle make world; #hack; make corevm #test fails
allison particle: but you can run "clean" and check that a few key files don't reappear when you run 'corevm'
dukeleto particle: in "make fulltest" a fresh copy of parrot can be created in a subdir, "make corevm" run, and then the non-existence of certain files is checked for
allison particle: it's not the ultimate test, but will at least give us an indicator 21:21
dukeleto running "make clean" in our test suite sounds like it could wipe out developer work-in-progress, which i don't like
allison particle: PGE is the big one that kills us, because we get stuck in obtuse errors buried deep in PGE, instead of starting by debugging test failures 21:22
particle i understand the motive
it seems a bit odd to write tests for make targets, especially when the tests try to prove that all non-black things are non-crows 21:23
dukeleto if people have ideas about testing "make corevm" please add them to trac.parrot.org/parrot/ticket/1502
particle: please add your comments to TT1502
chromatic Let's get back to larger design and scheduling issues.
Any other questions?
dukeleto chromatic: yes. can someone please give feedback on trac.parrot.org/parrot/ticket/1500 ? 21:24
dukeleto is starting to sound like a broken record. I am done, i think.
allison dukeleto: I'll comment on it
dukeleto allison: thanks!
NotFound Question: Some comment about trac.parrot.org/parrot/ticket/1506 ? 21:25
chromatic +1 to TT #1506 21:26
whiteknight NotFound: +1 from me
cotto_work NotFound,
+1
allison +1
NotFound We can discuss deprecation points later. 21:27
chromatic Other questions?
Coke point of order. 21:28
(not really, but not a question, either)
chromatic Go ahead.
Coke the # of people subscribed to the tickets list is VERY small compared to the # on the -dev list; if you're looking for feedback on something, you're probably better off having the discussion on -dev and capturing it for the ticket, rather than (more) 21:29
posting the ticket and waiting for feedback there. (I myself have several tickets languishing in this state.)
not a priority for this week, just something to think about. 21:30
.
dukeleto finds that it is always a good idea to email -dev and ask for input on TT's
Coke++
chromatic Any other questions?
whiteknight nope 21:33
chromatic Okay, let's call it a week then. 21:34
21:34 PacoLinux left
dukeleto ENODISHES 21:34
21:34 dukeleto left 21:35 davidfetter left, bubaflub left, darbelo left 21:37 Coke left 21:40 NotFound left 21:41 chromatic left 21:48 bluescreen joined 22:08 bacek joined 22:44 cotto_work joined 23:19 Whiteknight joined