Priorities for this week: MappedByteArray increase coverage & write demo, Google Code-In | 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 23 December 2010.
02:27 kid51 joined
kid51 has blizzard issues; will be trying to keep his car from getting towed; may not be at #ps today 02:28
03:13 kid51 left 04:44 Coke left 05:07 Coke joined 05:28 cotto joined 12:33 bluescreen joined 17:41 NotFound joined
dukeleto will not be able to make #ps today 19:53
20:00 whiteknight joined
whiteknight WHAT I DID: 20:02
* Got embed_api merged. cotto++ for the help
* Fixed a handful of issues relating to embed_api
* Trying to keep up with GCI tasks.
* Holiday related stuff
WHAT I WILL DO:
* Still haven't fixed my dev laptop. Need to do that ASAP.
* Continue on with GCI.
WHAT I AM BLOCKING ON:
* Laptop broken
* Sick kid
* Not enough time.
Coke - on master & checkdepend_pmcs, got t/std/codingstd.t looking at all .c file deps. Please review branch and mergeback to trunk. 20:15
- poked whiteknight++ into some bugfixes for rakudo.
*EOR
er, t/src/checkdepend.t # odd mistype.
20:18 kid51 joined
kid51 kid51 additional report 20:19
* Followed up on ? of who can approve/publish GCI tasks
* Created 3 GCI tasks (which I think are still unclaimed)
* Had no time for TT #855 20:21
WILL TRY TO DO:
* TT #855 renewed effort
* Blogging re teams and roadmaps
BLOCKING ON:
* Blizzard travails: Car was not towed but is ... injured :-( 20:22
EOR
cotto_work *did:
- keep up (kinda) with gci
- lots of code review
- coke++ for the dependency cleanups, restoring my faith in make -j
- nwellnhof++ for making our coverage tests less ugly
- more of the same
- packfile planning and hacking
*blockers:
- none
*eor
20:26 nwellnhof joined, allison joined
mikehh What I did since my last report: 20:27
* building and testing parrot on amd64/i386, with gcc/g++
* last couple of days g++ does not build
* some fixes
* replace concat_s_s/concat_s_sc in examples
* html_cleanup needs to generate index pages (docs/index/*.json has the necessary info)
What I intend to do in the next week:
* testing and fixing
* hopefully complete the index/header pages in html_cleanup
.eor
nwellnhof what i did 20:28
- merge string_unescape
- work on my other branches
- misc fixes
plans
- merge unicode_io
eor
20:29 davidfetter joined
Util Note: Poor connectivity; traveling 20:29
# Done:
20:29 Kapace_ joined
Util Nothing; on holiday this week. 20:29
# Blockers:
'Tis the season...
# 7-day ticket report: 20:30
2 closed: done
12 closed: fixed
10 new
1 reopened
.end
cotto_work good morning 20:32
Util Hello
whiteknight hello
kid51 Hello; q1q
mikehh hi there 20:33
kid51 Are any of our customary discussion leaders here?
cotto_work?
cotto_work hi
kid51 u want to start off? 20:34
cotto_work How'd we do on last week's goals?
kid51 1. Goals were recorded in #parrot, but not in #parrotsketch
2. (I don't know how to set the topic in #parrotsketch)
mikehh missed out on merge for html_cleanup, got distracted by g++ issues and examples_tests failures
kid51 3. Lots of GCI-related activity.
4. We were temporarily blocked on GCI due to absence of an "organization administrator" to approve/publish issues. I believe that has been resolved. 20:35
cotto_work yes
I made a note of the goals at the end of last #ps
keeping up with gci seems to have been ok 20:36
kid51 5. Since many of the GCI participants are on Xmas break, they seem to be working/on channel round the clock :-)
cotto_work I'm an org admin and dukeleto is back, so we shouldn't be blocking on that.
NotFound Late hello
kid51 nwellnhof merged one branch (per earlier report) 20:37
nwellnhof and we merged embed_api
whiteknight ...and dealt with the fallout 20:38
q2q
cotto_work html_cleanup needs a bit of work. mikehh, do you think it can be merged this week?
mikehh hopefully, it's just the index page generation 20:39
cotto_work let's make that a goal then
Did anyone look at distutils or plumage to try and increase their bus number? 20:40
whiteknight I moved plumage to github
parrot/plumage
cotto_work great
mikehh frontend/parrot/main.c fails to build with g++ (gcc ok) and attempts I have made to fix it have failed
whiteknight so everybody reading this is now a committer on it
20:40 atrodo joined
NotFound cotto_work: I took some look, but I'm not fluent witn nqp 20:40
whiteknight mikehh: I'm buidling with g++ now and will have that issue fixed soon 20:41
mikehh whiteknight: thanks
whiteknight cotto_work: I suggest plumage be the second priority
cotto_work wfm
whiteknight: anything specific about it? 20:42
kid51 q3q
whiteknight make it work perfectly, make it able to submit smoke reports
smoke reports for it would be a huge help
cotto_work any volunteers for that?
NotFound I had a plumage failure in machine at work with an updated ubuntu. I think the problem is the usage of a git command not pesent in old versions. 20:43
s/updated/outdated
kid51 NotFound: quite possible; my Debian box has a 1.5-ish git. There are certain commands I have to do differently from 1.6 and 1.7. 20:44
How are smoke reports for Plumage done?
Do they go to Smolder?
NotFound I'll look at it in more detail and fill a ticket.
mikehh they used to, probably needs fixing 20:45
there was a build target to test and smolder test
cotto_work ok. Anything else before we move to questions? 20:46
kid51: you had some questions 20:47
kid51 Yes.
1. I'm getting very inconsistent results with 'make quickcover'. I know I had it working reasonably well, but others have been modifying it since. 20:48
Could i ask that if you touch the coverage targets, you do so in a branch and make sure you test both 'make quickcover' and 'make cover'?
Discussion? Otherwise, I'll move on to #2. 20:49
nwellnhof kid51: i tracked it down to changes in Devel::Cover. version 0.68 and above break our current system.
kid51 nwellnhof: Can you post about that to parrot-dev? 20:50
nwellnhof yes, of course
kid51 Thanks.
#2: 3.0 release next month -- 3 weeks from today; anything special we have to do?
whiteknight PANIC
cotto_work DON'T PANIC
whiteknight those are the two options 20:51
kid51 Is there anything we have promised for 3.0 that we will not be able to deliver on?
whiteknight I don't think we've made many promises about it, no
kid51 Or is the .0 release fundamentally no different from the .11?
whiteknight so long as it's stable and no slower, I think we can accept it and support it
mikehh cotto_work: you are the release manager are you not? 20:52
cotto_work yes
kid51 Any deprecations we have to get in?
mikehh q1q
cotto_work I think we have plenty already, but now would be a good time if anyone thinks of one.
bluescreen old embed api ? 20:53
whiteknight bluescreen: yes
I would like to deprecate the functions in src/embed.c in general. Some of those functions can remain but should be moved to better homes
and with moving may come renaming, etc 20:54
kid51 Does Rakudo have any special needs as we go to 3.0?
cotto_work It sounds like doing an embed api review should be a goal for this week.
whiteknight cotto_work: yes, a review of those functions in general is a good idea
cotto_work I submitted a patch to Rakudo for the removal of concat_s_s, so they're ready for that. 20:55
whiteknight some are superfluous now, some can be improved/moved/renamed
cotto_work I'm not sure about other HLLs
20:55 plobsing joined
kid51 #3: Are any of our GCI students here right now? Want to say anything to the assembled masses of developers? 20:56
Kapace_ Make more tasks!
:P
perferably non-test coverage tasks, since make cover keeps blowing up
mikehh how long has GCI got to run? 20:57
cotto_work mikehh: it ends on the 10th
Kapace_ 12 more days
whiteknight Kapace_: noted
kid51 Kapace_: Although 'make cover' does blow up, and that's a PITA, these tasks have focused us more on code coverage than ever before in the history of the Parrot Project 20:58
Util We just discussed GCI on #phasers for Perl 6. Masak intends to submit/mentor some Perl6 tasks.
cotto_work Great! I'll be happy to see Perl 6 get some gci love.
nwellnhof Kapace_: you can try 'make quickcover_new' if 'make cover' blows up. 20:59
kid51 END of my questions
Kapace_ nwellnhof: yes, I have tried that seems to work :)
cotto_work whiteknight: you had some questions
whiteknight yes 21:00
We need to expose Parrot_pmc_gc_register and Parrot_pmc_gc_unregister through the API to help embedders protect their PMCs from GC 21:01
any opinions on the best way to do that, or should I just put together a thin wrapper?
mikehh how much added complexity does it add 21:02
s/add/bring/ 21:03
plobsing the only concern I know of was that it puts expectations on GC that might be undesirable
whiteknight there are two functions I want to expose. At the simplest, that's two small API functions
plobsing but I think there may be workarounds
whiteknight plobsing: exactly. We could call it something like "pin/unpin" to hide details
the API does provide a mechanism for specifying a stacktop for GC stackwalking, so most embedding data should be safe 21:04
but there are rare instances when we would like to keep a reference alive even when it doesn't appear to libparrot that it's still reachable
mikehh you are effectively telling the gc don't deal with this memory item - I will 21:05
plobsing like anonymous callback subs held in head-allocated structures
s/head/heap/
whiteknight mikehh: What registering does is puts the PMC into an array that is marked explicitly by the GC
so yes, it's like explicitly saying to keep a PMC alive until I say otherwise
nwellnhof couldn't we abstract the API completely away from PMCs? 21:06
whiteknight nwellnhof: And use what instead?
mikehh so register says keep it and unregister says ok get rid of it
whiteknight mikehh: exactly
nwellnhof whiteknight: some wrappers
whiteknight nwellnhof: We could explore that option. I'm not sure I see a benefit in it right now 21:07
nwellnhof whiteknight: the benefit would be a nicer API. it's more work though.
plobsing nwellnhof: how would the wrappers handle the lifetime of objects? 21:08
Util Can we give methods to the PMCs that call reg/unreg on themselves? 21:10
plobsing wouldn't we still need to have explicit lieftime-management functions in the API?
whiteknight Util: We could put a method on default.pmc, yes
Util: Calling a PMC method from an embedding C application is not trivial though
okay, let's move this discussion to #parrot or the list, since I think we could talk about it all day 21:11
My second question: I would like to deprecate and eventually remove the EventHandler PMC.
Until this morning, it had been unusably broken for several months. Attempting to invoke it caused a segfault. It was completely untested 21:12
I've put in a fix this morning, but the PMC is still unused, isn't pretty, and is part of a subsystem that is going to need major work in the coming months
I suggest we remove it now, while we know that nobody is making effective use of it 21:13
or, deprecate it now
nwellnhof it it's broken it's kind of deprecated already. 21:14
whiteknight I would agree, but I won't argue that point
I would like to remove it, deprecate it otherwise
mikehh was it always broken, or just recently 21:15
whiteknight mikehh: Certainly it was never updated to work since the PCC refactor. So it's been months without so much as a bug report
I can't say if it worked before that
(untested, unused)
cotto_work If it's that broken, nobody wins anything by keeping it around. 21:16
nwellnhof i can't image it has any users, then.
cotto_work fire at will
mikehh just curious, some of the older HLL haven't been tested recently, eg cardinal
whiteknight cotto_work: thanks. Exactly what I wanted to hear
cotto_work Is that the last of your questions, whiteknight? 21:17
Tene mikehh: Cardinal recently received a small amount of work towards making it build successfully, at least, although it does not pass tests any more.
mikehh Tene: maybe if we get plumage going again we can work on cardinal and some others 21:18
cotto_work mikehh: yes. I think part of the drive to get plumage usable is that it'll let us more easily test HLLs and libraries automatedly. 21:19
Tene whiteknight: You're wrong here. EventHandler has worked just fine for a long time. What was broken was the invoke vtable, which wasn't used because it's meaningless. EventHandlers aren't vtable_invoked.
whiteknight Tene: Then maybe I don't understand what they are. What purpose do they serve if not invoked as a handler? 21:21
Tene whiteknight: The real eventhandler functionality, addhandler/schedule, has not stopped working at any time, afaict.
whiteknight cotto_work: yes, that's it
Tene whiteknight: it's like an exceptionhandler.
whiteknight Tene: exception handlers are invoked
Tene whiteknight: not vtable_invoked, no.
Hmm... could be I'm full of shit here, not entirely sure. 21:22
Still, the functionality of eventhandlers *has* continued to work just fine, as demonstrated by tests.
whiteknight Tene: src/exceptions.c:232 21:23
it is VTABLE_invoked
there's no other way to move control flow there
Tene you addhandler an eventhandler, and then schedule a task, and it works fine.
whiteknight Tene: there are very very few tests for EventHandler. Code coverage until this morning was at like 17%
Tene: addhandler may be doing something weird. I need to look at it 21:24
NotFound whiteknight: we have lots of PMC with very low coverage, that says nothing.
Tene whiteknight: t/pmc/scheduler.t 21:25
whiteknight NotFound: no, the coverage by itself says nothing
but if the PMC is throwing segfaults and nobody notices, we can't prove that it works 21:26
Tene Throwing segfaults for an unsupported operation that's not used by anything, or necessary.
NotFound whiteknight: I've been fixing segfault conditions in several importante PMCs that nobody noticed.
whiteknight Okay. I'll hold off on EventHandler for more study, but I still think we don't need it and it should be deprecated 21:27
cotto_work That sounds like a good idea.
whiteknight I'll look at it and raise the issue again next week if necessary 21:28
whiteknight has to sign out now. Later
cotto_work mikehh: you had a question
21:28 whiteknight left
mikehh mor like an observation really - I think it is important to run fulltest and perhaps test rakudo (maybe plumage) before merging a branch 21:29
NotFound Example of very low coverage: multisub.pmc 29% 21:30
kid51 make fulltest before branch merges+++++
mikehh for example removal of concat_s_s/concat_s_sc caused problems with rakudo and examples_tests
NotFound And for winxed
cotto_work I agree. We need to be more proactive about ensuring that we don't break HLLs, especially Rakudo and Partcl.
kid51 If your branch touches any file starting with 'src/', you really need to do 'make fulltest'
cotto_work The plumage work should make that simpler.
mikehh don't forget winxed 21:31
NotFound But that thing was already deprecated and announced and there was an easy update path, no big issue.
plobsing branch merges shouldn't break core's fulltest. breaking HLLs should be fine if they have a reasonable upgrade path. 21:32
Tene considers make_hlltests
21:34 bluescreen left
nwellnhof examples is the most critical part of make fulltest. maybe they should be moved to normal tests. 21:34
cotto_work I think they were taken out because of how long they took to run. 21:35
plobsing nwellnhof: do that, and I'll only run coretest most of the time
mikehh also codetest
I think we might want to separate out the perlcritic test in codetest as they are the longest running part 21:36
nwellnhof the problem with make fulltest is that it tests all the runcores IIRC. that takes ages. 21:38
mikehh at the moment just testb, testf and testr 21:40
nwellnhof make examples_tests takes about a minute.
mikehh used to be another 4 or so
so does codetest without perlcritic
kid51 'make not-quite-fulltest', anyone? ;-) 21:41
cotto_work So it sounds like we need more emphasis on examples_tests 21:42
Tene make did-i-break-it
nwellnhof i'm for adding examples to the standard test target.
kid51 If people can tell me what they want, I'll create an intermediate target
'make test' + 'make examples_tests' + 'make codetest (except perlcritic)' -- does that sound okay? 21:43
(I don't want 'make test' to take any longer than it currently does.) 21:44
mikehh good target, don't know what to call it though
kid51 I'll think of something
cotto_work kid51: sounds fine. serial examples_tests takes under a minute on my machine, parallel takes 38s. 21:45
mikehh but still keep fulltest as it is
cotto_work that's not excessive
nwellnhof i'd rather make that the default target and have other targets for quicker tests.
cotto_work Can someone start a parrot-dev thread to discuss this further?
kid51 nwellnhof: I recommend let's try an intermediate target and see how we like it -- later we can ponder making it the default for 'make test' 21:46
Tene The default should be more comprehensive, yes. We've had problems with people not running the right tests, and a proliferation of small test targets that people need to remember doesn't actually help anyone.
I'm not really clear on what the utility of trimming down the 'test' target is.
kid51 Tene: I don't think we're talking of trimming 'make test' 21:47
mikehh time to run the tests
kid51 Tene: We're talking of a new target that would include 'make test' plus others -- but much less than 'make fulltest'
Tene If the examples tests are important to run, why not add them to 'make test'?
kid51 They will only run quickly on boxes with high resources.
Also, as I stated above, I recommend trying out the new target before substituting it for 'make test' 21:48
Tene I really feel like I'm missing something here, but I certainly haven't been active enough to legitimately complain, so I'll just assume you guys have good reasons that I just haven't been present enough to notice. :) 21:50
kid51 I will open up a Trac ticket for this.
cotto_work kid51: thanks.
Are there any other questions? 21:51
NotFound Maye instead of adding make targets we should kill some, and use parrot programs to run some of that things.
cotto_work NotFound: that's an interesting idea. Can you mention that in kid51's ticket? 21:52
NotFound More complex Makefile --> more portability problems
mikehh and test with C++ as well as C
cotto_work Here are the goals I have for the week: 21:53
GOAL 1: more gci tasks (everyone)
GOAL 2: merge html_cleanup (mikehh)
GOAL 3: get plumage working, increase its bus number (?)
GOAL 4: review current embedding api, decide what to keep (whiteknight)
GOAL 5: study EventHandler, decide what parts are useful and what's worthwhile (whiteknight)
GOAL 6: run examples_tests and test Rakudo, Partcl and winxed before merging significant changes into master (everyone)
NotFound But... plumage is working, isn't it?
kid51 cotto_work++ on goals
cotto_work NotFound: If it is, that'll be a very easy goal.
Either way, we need more people who understand it. 21:54
mikehh also bus number increase
NotFound Last week it was broken for metedata with utf8 chars, but I fixed that, and was a parrot problem, not a plumage one.
mikehh NotFound++ 21:55
NotFound The only problem I know is the one I commented before, git targets with old git versions. 21:56
kid51 Anything else before we wrap? 21:58
cotto_work That's a wrap. 21:59
moderator 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 22:06
22:08 dduncan joined, kid51 left 22:12 NotFound left 22:14 plobsing left 22:18 atrodo left 22:29 davidfetter left, nwellnhof left 23:09 dduncan left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!