Priorities for this week: irclog.perlgeek.de/parrotsketch/201...#i_3126985 | Post closed tickets in your report. | Note: This channel is for our Tuesday status meetings (at 20:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/parrotsketch/today
Set by moderator on 28 December 2010.
00:05 bacek left 00:19 bacek joined 00:36 bacek_ joined 00:41 bacek left 01:08 mikehh left 01:21 mikehh joined 01:43 bacek__ joined 01:48 bacek_ left 02:12 bluescreen left 02:15 bacek_ joined 02:20 bacek__ left, contingencyplan joined 02:56 bacek_ left 03:05 bacek_ joined 03:35 bacek__ joined 03:40 bacek_ left 04:02 bacek__ left 04:20 bacek joined 04:24 cottoo joined, cotto left, cottoo is now known as cotto 04:48 contingencyplan left 06:35 bacek_ joined 06:40 bacek left 06:59 bacek__ joined 07:04 bacek_ left 07:51 bacek__ is now known as bacek 08:27 chromatic left 09:46 bacek_ joined 09:51 bacek left 10:13 contingencyplan joined 11:02 bacek_ left, bacek_ joined 11:23 Util joined 12:31 bacek_ left 13:10 lucian_ joined 13:15 lucian left 13:24 Coke joined 13:44 bluescreen joined 13:56 lucian_ left 14:53 bluescreen left 15:08 bluescreen joined 15:34 atrodo joined 15:37 PerlPilot joined, PerlPilot left 15:38 PerlPilot joined 16:11 PerlJam left 17:52 kid51 joined
kid51 kid51's report 17:52
DONE 17:53
* Created trac.parrot.org/parrot/ticket/1908, implemented 'make moretests', closed ticket.
* Created trac.parrot.org/parrot/ticket/1900, change names of cover targets.
* Closed trac.parrot.org/parrot/ticket/1897, implement 'silent' configuration, with assistance from GCIer.
* Took trac.parrot.org/parrot/ticket/1925, delete config step auto::jit; hope it will get picked up by GCIer. 17:54
17:54 chromatic joined
kid51 * Created trac.parrot.org/parrot/ticket/1922, review 'make help'; ticket has been claimed by GCIer, but I haven't heard anything yet. 17:54
* Did more thinking about trac.parrot.org/parrot/ticket/855, profiling options.
* Worked on trac.parrot.org/parrot/ticket/1927, spaces in directory names; have now been assigned this ticket and hope to merge into master soon.
* Wrote two blogposts on roadmaps and teams: parrot.org/content/roadmaps-and-teams parrot.org/content/roadmaps-and-teams-part-two
* In preparation for next Summit (sometime in weekend of Jan 29/30), began to follow up on action items from previous summit (thread.gmane.org/gmane.comp.compile...vel/4948).
* Posted final version of minutes from 2010 Parrot Foundation members' meeting.
TO BE DONE 17:55
* We need to decide exactly when during the weekend of Jan 29/20 we will hold our next PDS.
* I will do more follow up on action items leading into that summit, i.e., expect more email from me about that.
* By next Tuesday's #parrotsketch, GCI will be closed, so we should give public recognition to our student participants and mentors.
* Will post to list thoughts on coverage targets; short-version: Recommend pulling them out of Makefile.
EOR
18:03 lucian joined 18:04 bluescreen left 18:32 bluescreen joined 19:05 bluescreen left, whiteknight joined 19:22 bluescreen joined 19:32 bacek joined
mikehh What I did since my last report: 20:14
* building and testing parrot on amd64/i386, with gcc/g++
* quite a lot of fixes, especially related to GCI
* sorted out some build failures and removed some warnings
* html_cleanup branch, mergerd in latest origin/master (having a problem trying to merge master)
* did not have as much time as I wanted to devote to the branch (spent a lot of time on master)
* working on generating index/header pages, still some work to do there, the rest ok,
* all the referenced pages are generated ok
What I intend to do in the next week:
* testing and fixing
* hopefully complete the index/header pages in html_cleanup
.eor
20:19 tcurtis joined
Coke DID - slight improvement to c2str.pl's execution time. 20:19
flailing about at other build/runtime speed improvements. (Hey, where's chromatic? ;) 20:20
.eor
Util # Done:
* Made first cut of Rakudo Star OS X .dmg binary
= s3.datasaw.com/Rakudo_Star_2010-12_...ment_2.dmg
= Should also work as a Parrot binary
# Plan to do:
* Heal
# Blockers:
* Cold and flu season
# 7-day ticket report:
1 closed: done
2 closed: duplicate
17 closed: fixed
1 closed: invalid
1 closed: worksforme 20:21
27 new
2 reopened
.end
cotto_work *did: 20:23
- keep up with gci
- made a few new tasks
- deputized atrodo to help deal with the flood
- Monday is the last day of gci
- started digging into nqp-rx/nom
- it's ... unusual
*will do:
- finish up gci
- nom writeup
*blockers:
- none
*eor
tcurtis Did: nothing. Will do: hopefully work on tree-optimizations. Blockers: school/etc.
cotto_work Hmm. report got cut off some 20:24
*did:
- keep up with gci
- made a few new tasks
- deputized atrodo to help deal with the flood
- Monday is the last day of gci
- dukeleto++ for crazy task creation 20:25
- whiteknight++ for helping with tasks
- lots of code review
- coke++ for speeding up str2c
- started digging into nqp-rx/nom 20:26
- it's ... unusual
*will do:
- finish up gci
- nom writeup
20:26 pmichaud joined
cotto_work *blockers: 20:26
- none
*eor
whiteknight WHAT I DID: 20:27
* Working on GCI
* Trying to fix the Win64 situation, which apparently is sort of broken and undertested
* Miscellaneous fixes, reviewing code, etc
WHAT I WILL DO:
* Cleaning, testing, bugfixing. 3.0 is on the horizon.
* Directors have a phone meeting next week, so I'm preparing for that
* We're supposed to have a January PDS at the end of this month, so preparing for that
WHAT I AM BLOCKING ON:
* My laptop is still broken
20:28 nwellnhof joined, tadzik joined
tadzik can I sit in a corner and listen? :) 20:28
nwellnhof what i did: 20:29
- merge unicode_io
plans:
mikehh tadzik: there's nothing to stop you joining in
nwellnhof - more work on io and encodings, see TT #1863 and branch nwellnhof/read_chars 20:30
.eor
kid51 tadzik: Post a report on anything you've done re Parrot in last week (or two)
tadzik well, I can say what I did about cardinal
kid51 2030 has arrived; who will chair?
cotto_work hello 20:31
cotto_work has a chair
mikehh hi there
tadzik so, I was to move it to nqp-rx, discussed on #parrot and decided to make it run properly first. Made it compile and run simple things, the thing which stops me from contunuing is posted to parrot-dev and to the GH issues. That'd be all 20:32
Util Hello
whiteknight hello
tcurtis Hi.
cotto_work How'd we do on last week's goals? 20:33
kid51 1. More gci tasks: Achieved.
2. merge html_cleanup: mikehh?
3. Get plumage working? I saw that it was moved to github, but beyond that I didn't see anything. 20:34
whiteknight no movement on plumage
mikehh hopefully in the next couple of days
kid51 4. Review current embedding API: bluescreen? whiteknight?
whiteknight I made a ticket and some recommendations about the old embedding API
kid51 5. Study EventHandler: (probably 0)
whiteknight the new embedding api has increased it's test coverage
kid51 6. Run examples_tests before merges: This is now feasible with 'make moretests'
whiteknight no movement on eventhandler
kid51 END_OF_QUICK_VERSION 20:35
cotto_work mikehh: we've been trying to merge html_cleanup for a while. What will it take to get it merged today or tomorrow? 20:36
kid51 Personally, last week I was thinking that 6 goals was way too many ... but it turned out that we touched all but 1 of them and did a lot on 3 of them
cotto_work It's a good task, but nothing's been happening for too long. 20:37
mikehh? 20:38
mikehh cotto_work: sortin' out the index/header page generation, got some ideas - the .json files are there, just needs to push through Parrot::Docs::HTMLPage.pm
everything else works fine, all the referenced pages are generated 20:39
passes all tests etc.
kid51 Is any part of this delegateable?
perhaps we should move on? 20:42
cotto_work sure
mikehh if anyone has the tuits, I think the tools/docs/make_html_doc.pl does most of it already, just needs to generate the index pages from the json stuff
cotto_work ok. If anyone has tuits, please take a look at that.
Does someone have tuits to study EventHandler? That didn't get done last week. 20:44
whiteknight I'll do it, just didn't have time this last week
we don't need to mark that as a goal, it's low-priority
cotto_work ok 20:45
kid51 Good.
cotto_work any questions or points for discussion?
kid51 Who is the point person for "get Plumage working"? 20:46
cotto_work kid51: there wasn't one
whiteknight i did suggest it
I can take on that role
cotto_work excellent 20:47
mikehh I think NotFound said it was working, just did not have time to try it out last week
kid51 whiteknight: At the risk of doubting your capabilities ... how many roles can you take on at once?
whiteknight bajillion
kid51 ok. 20:48
whiteknight plumage is working, I believe. I want to add it to smolder so we can keep it that way
so it shouldn't be a huge task
kid51 Will that be of benefit to the "Test HLLs before doing branch merges" part of last week's Goal #6 (where we got burned yesterday re Rakudo)? 20:49
cotto_work If we can automatically and easily smoke test languages with plumage before merging, it'll do a lot to help HLL stability. 20:50
kid51 k
nwellnhof but we have to test HLLs against new branches, not against master.
cotto_work nwellnhof: yes. We can install Parrot built from a branch and use plumage on to test how HLLs work with it. 20:51
mikehh one of the problems with rakudo, for example, is that it take ages to build and run the test suite - close to an hour on a 4core system 20:52
nwellnhof if it's all automatic, how do we tell which branches to test
Coke make a web service that lists branches ready-to-be-tested? 20:54
(or a wiki page on github)
pmichaud 20:52 <mikehh> one of the problems with rakudo, for example, is that it take ages to build and run the test suite - close to an hour on a 4core system
this group can help a lot with that :-)
mikehh pmichaud: hi, yes 20:55
cotto_work nwellnhof: I was talking about automated local testing, i.e. install a Parrot build from branch and run a simple command to test a bunch of HLLs with it. 20:56
nwellnhof pmichaud: the problem with make spectest is mostly Rakudo's startup time. that's not entirely Parrot's fault.
pmichaud nwellnhof: it would help if we had a better serialization mechanism
cotto_work both can be optimized
whiteknight yes, I was about to say that. If Parrot provided better serialization stuff, we could help Rakudo improve startup time 20:57
pmichaud right now parrot's lack of serialization forces us to do all built-in initialization at startup (runtime) instead of compile-time.
whiteknight that's the end-goal of many of these packfile cleanups/refactors that plobsing has been working on
cotto_work q1q
kid51 pmichaud: Short of running Rakudo's 'make spectest', is there any quick-er way to see whether a given branch is going to harm Rakudo? 20:58
mikehh q1q
pmichaud kid51: in some sense that's the wrong question (more)
the latest breakages cause problems with *nqp* too
so it's not entirely a problem with rakudo's spectest time
since running an nqp test takes <1 minute 20:59
in other words, one could've found the latest parrot problems much quicker than an hour
mikehh so we should include nqp tests in our test suite
pmichaud so saying "we don't test because rakudo's spectest takes so long" is a bit misleading, imo
kid51 What does one need to do to run that NQP test? Is it part of Parrot or part of Rakudo?
pmichaud nqp is its own repo
it's just another hll on parrot 21:00
(and a much smaller/easier to test one)
cotto_work nqp-rx's tests are pretty quick.
maybe a minute
mikehh but we don't run them at the moment
kid51 Could someone wrap that in a perl 5 script such that, say, I could run it after 'make moretests'?
Coke if we're shipping nqp-rx, we really should test it a lot.
mikehh they are in plumage of course
Coke perhaps this would be a good time to switch nqp-rx over to a git subproject. 21:01
pmichaud Coke: well, there's a difference (perhaps big) between testing the nqp that is stored with parrot, versus building nqp from its own sources
mikehh used them when working on pir/pirate
Coke pmichaud: are we even doing the first, though? 21:02
pmichaud I think that nqp should be treated just like any other hll that parrot wants to test
cotto_work +1
21:02 bacek_ joined
Coke (and if we included it as a subproject, I assume we'd use that to say "ok, /this/ is the version we want" and having it be a reference instead of a copy. 21:02
pmichaud if someone wants us to copy nqp's tests into the parrot repo along with its pir source, we can do that.
cotto_work It'd also be a good first HLL because it's relatively small and quick to test.
mikehh hang on, we use nqp-rx in parrot a lot now - so we should have the tests there 21:03
whiteknight nqp-rx is an ext/ thing, it's developed externally
pmichaud mikehh: yes, but I think I'm saying that just because nqp-rx's tests pass with the parrot-stored nqp doesn't mean that one would be able to build nqp
whiteknight so the tests are external
cotto_work mikehh: We do need to be *testing* nqp-rd regularly. I'd prefer that we do so through plumage.
pmichaud and being able to build+run nqp (as a separate hll) is really what hll devels (such as rakudo devs) will want 21:04
Coke 'sfine with me.
pmichaud i.e., we want to know that we can build+run hlls on parrot, not just that an existing hll runs
21:04 plobsing joined
mikehh it's going to be one of the first things we build in plumage, so yes 21:04
21:06 bluescreen left
cotto_work Is this resolved? It sounds like the best solution is to keep nqp-rx's test external but to make sure they're run frequently, and that plumage is a good mechanism to accomplish that. 21:06
mikehh +1 21:07
21:07 bacek left
pmichaud I'm not sure it's resolved (more) 21:08
somehow I think the underlying issue is we need good mechanisms for testing hlls before committing significant changes
(and they need to be used)
cotto_work agreed
whiteknight I think we get into a tarpit here, arguing over what constitutes a "big" change, and what all HLLs we need to test beforehand 21:09
pmichaud but I don't have any suggestions for improving that
whiteknight and then whether it's only HLLs, or all ecosystem projects
NQP-RX obviously does need to be high on the list 21:10
plobsing pmichaud: for the record, I *did* test nqp-rx (among other HLLs) before merging and attempted to fix the problems, but being unfamiliar with it was unable to. I posted to the list requesting assistance, but seeing as other languages worked well with trivial fixes, did not see it as a blocker for merging
whiteknight Rakudo too. It would be very nice if we had some tool to calculate tests that are impacted by code changes beforehand
kid51 Let's approach this incrementally. 21:11
pmichaud plobsing: noted
kid51 Let's first get a way to asses the impact of branches on NQP*.
Worry about other HLLs only thereafter.
cotto_work kid51: I agree. Let's get started and build on that once it's ready.
further comments? 21:12
question time then 21:13
I made two gci tasks to take 100 lines off the monstrous 400 line fill_params function in src/call/args.c by factoring out self-contained blocks. Does this sound reasonable to anyone who's worked on the code? 21:14
mikehh we just need to make it easy to test a branch on plumage
nwellnhof cotto: i don't think that's GCI material
cotto_work nwellnhof: care to expand on that thought? 21:15
nwellnhof you simply need some experience with Parrot's internals before you can hack on that code
cotto_work even just to break code into separate functions? 21:16
chromatic Extracting out reasonable pieces into static functions is very good, and a moderately difficult project. 21:17
nwellnhof cotto: maybe, but breaking code into separate functions doesn't make automatically better to understand.
cotto_work If the functions have descriptive names and are fairly self-contained, I'd disagree. 21:18
nwellnhof and there's a chance that it will make the code slower which is something we can't afford for fill_params.
cotto_work Right, but that's what compilers are for. static functions like that can easily be inlined by the compiler. 21:20
pmichaud presumably that could be tested in a branch (speed)
whiteknight I broke out a piece of that code yesterday evening, but I purposefully picked a branch of code that I knew to be cold
we can't afford PCC to get any slower. That code needs to be handled with kid glvoes
nwellnhof i don't think that moving code that is used just once to static functions always makes for more readable code. 21:21
whiteknight I actually have some thoughts about that code that I need to expand on, but I sincerely don't think it's right for GCI
chromatic If we extracted out smaller functions, we could eliminate the indirection required to handle va_list/context arguments.
cotto_work whiteknight: ok. I'll remove the task. It does sound like it'd be a bit much for a gci student. 21:22
whiteknight I'm thinking that we try to break that up into several functions initially, then create multiple copies to pull conditionals out of tight loops
plobsing chromatic: is there evidence that that indirection is costing us much? I've seen cases where indirection removal gained essentially nothing.
cotto_work unpublished
chromatic Given that that indirection means at least one function pointer invocation to access an array element for each argument/parameter, I believe so. 21:23
pmichaud (sorry, I had one further comment on the branch merge, which is that both nqp and rakudo are not working even after re-enabling implicit :main) 21:25
(just wanted to make sure that was noticed)
plobsing pmichaud: ouch. did not know it was still broken. 21:26
whiteknight has to leave now. Will backscroll
pmichaud (also, I just checked, and even rakudo's "make test" fails)
plobsing q1q
21:26 whiteknight left
pmichaud (i.e., one could find the failure with rakudo much faster than doing a full "make spectest") 21:26
plobsing: TT #1932 21:27
kid51 was mikehh next question?
cotto_work yes
pmichaud (I'm done)
cotto_work mikehh: go ahead 21:28
21:29 bacek__ joined
cotto_work plobsing: go ahead 21:31
mikehh I noticed that two python progs were added to tools/dev, what about coding standards, like copyright etc
plobsing the deprecation steps were followed for TT #1704, the code for which has since been rolled back 21:32
what happens now?
do we put it back to its previous deprecation state? do we reject the deprecation and remove all references?
do we leave it in its current inconsistent state? 21:33
kid51 mikehh: Recommend pushing that codingstd discussion into Trac. 21:34
cotto_work We need to understand and address the issues it caused and why the :main sub has to be dynamic in some cases. pmichaud mentioned his reasoning and use cases yesterday iirc. That should be added to the ticket. 21:35
21:35 bacek_ left
pmichaud some modules are meant to be included as part of larger programs, and thus should not have :main. Some modules are meant to be standalone, and thus would need :main if it's mandatory. Some modules can be run both standalone and as part of a larger program. 21:36
mikehh kid51: ticket?
pmichaud we can move this discussion to #parrot so that #parrotsketch can proceed 21:38
kid51 mikehh: Yes, please open a ticket so I can look at it when i get home. 21:39
mikehh kid51: 'k
cotto_work pmichaud: thanks. 21:40
kid51 Are there any more questions?
cotto_work If not, here are the goals I have: 21:41
GOAL 1: keep up with gci (ends on the 10th) (everyone) 21:42
GOAL 2: get plumage working (whiteknight)
any others I missed?
kid51 Get Rakudo working (I really think this should be #1) 21:44
cotto_work the goals aren't ordered by importance, but that's a big one 21:45
kid51 3.0 is 2 weeks away
cotto_work GOAL 3: get Rakudo working again
kid51 Enough, IMHO 21:46
cotto_work That's a wrap, then. 21:47
21:49 tcurtis left, plobsing left
dukeleto oops. 21:50
dukeleto missed #ps
21:55 kid51 left 22:08 nwellnhof left 22:19 bacek_ joined 22:24 bacek__ left 23:08 bacek_ left 23:12 lucian left 23:20 bacek_ 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!