"Tuesday at 20:30 UTC"
Set by moderator on 20 September 2010.
01:10 kid51 left 02:26 bluescreen left 05:47 Util left 05:52 Util joined 08:05 contingencyplan left 08:17 particle left 08:45 particle joined 12:47 particle left 12:48 particle joined 13:20 bluescreen joined 16:52 kid51 joined
kid51 kid51's report 16:52
* Won't be at #parrotsketch today. Am on vacation, but will be paying a courtesy call on OSU Open Source Lab. 16:53
* Getting ready for Pacific Northwest Parrot Developers Gathering in Portland this Saturday, Oct 16, 1100-1700 PT. If you haven't RSVPed, please do so.
DONE
* Merged in a branch to close TT #1810.
* Performed testing for TT #1813. Provisional results: The problems we are having with the infnan branch on certain machines cannot be attributed solely to use of g++ rather than gcc.
* Some testing re t/tools/mk_language_shell.t with dukeleto.
CONCERNS
* It's still the case that, without hacking deep inside C source code files, Parrot will no longer build on boxes with smaller resources. This inhibits testing on such boxes, since every time I go to test a branch I have to perform surgery on src/gc/gc_ms2.c.
EOR
17:03 bluescreen left 17:04 bluescreen joined 17:14 kid51 left 17:45 contingencyplan joined 19:08 atrodo joined 19:54 mikehh joined 20:15 chromatic joined
mikehh What I did since my last report: 20:18
* building and testing parrot on amd64/i386, with gcc/g++
* some fixes
* branch testing and fixing
What I intend to do in the next week:
* testing and fixing
.eor
20:20 Paul_the_Greek joined, allison joined, luben joined
Util No Parrot progress last week. 20:26
curl -s 'trac.parrot.org/parrot/timeline?day...ticket=on' | perl -wlne '/<em[^>]+\\(([^"]+)\\)">/ or next; $h{$1}++; END {printf "%7d\\t%s\\n", $h{$_}, $_ for sort keys %h}'
2\tclosed: duplicate
(correction)
2 closed: duplicate
3 closed: fixed
9 new
.end
dukeleto What I did: 20:29
* Got Parrot + Rakudo access to the GCC Compile Farm
* Did some optimized darwinppc smoking and found some failing tests TT#1813
* Wrote a bunch of tests for the Socket PMC and found some bugs TT#1820
* Helped fix tests for mk_language_shell.pl
* Researched why String.reverse was removed and helping bluescreen++ put it back TT#1821
(reported by moritz++)
* Added info to the bug in Parrot where PID is 0 on OS X TT#1817
What I will do:
* Contiue testing our networking code so that I can apply the ipv6 patch sitting in our queue
* Help kid51 add a config step to detect if ipv6 is available TT#1824
Blocking on:
* Nice weather.
.EOR
oh yeah, and I should work on that GitMigration thing too. 20:30
And I helped in the attempt to merge gsoc_nci to trunk
cotto #done:
- finished fixing and cleaning up the profiling runcore (a.k.a. "PCore")
- Parrot builds and passes all tests with PCore hard-coded to the default
- same for nqp-rx
- Rakudo build fine but fails a small number of spectests. I'll investigate once the spectest run is done within the next few days.
- added API for adding STRINGs to the gc root set
#to do:
- try using the PCore, work on deficiencies I find
- figure out where the Rakudo spectest failures come from
- sync with osuosl about the post-migration configuration of trac.parrot.org
#eor
allison - Worked on release of other project (Ubuntu). 20:31
- There's potential for Parrot to be reviewed as one of the "recommended" technologies for Ubuntu's new lightweight "desktop apps" (like Android Marketplace).
EOR
chromatic Good $localtime all.
cotto hello
dukeleto howdy peeps.
mikehh hi hi]#
allison hi
mikehh oops
hello 20:32
chromatic Let's review last week.
Ticket closing? Looks sparse.
dukeleto I opened many tickets.
Util dukeleto++ # Compile Farm
dukeleto q1q when it is that time 20:33
I think we closed many of the easy tickets in weeks past.
chromatic I think we're running out of interested labor this past month. 20:34
20:34 nwellnhof joined
dukeleto We should try to concentrate on tickets of certain subsystems now, if we have a weekly goal of ticket closing. 20:34
chromatic +1, with the caveat we probably need mentoring for certain subsystems (and that's a good thing to do anyway) 20:35
dukeleto chromatic: yes, it will facilitate osmosis of knowledge between parrot hackers
cotto I'd be up for an excuse to learn pcc more thoroughly.
chromatic Other comments on the proposal? 20:36
cotto (or most given components)
dukeleto Perhaps we need a visualization of ticket activity. It could help motivate people.
cotto You seem to be all about visualizations this week. +1 20:37
dukeleto Like a simple graph from the data that Util++ adds to #ps
chromatic I'm not sure what could motivate people other than work.
Suggestions for a subsystem this week?
dukeleto what about the config subsystem? Didn't plobsing create some branches related to it? 20:38
but our GC could be more important
chromatic Fixing GC bugs is non-trivial. 20:39
dukeleto we recently had a GC-related goal, which I think did not have enough focus.
chromatic: indeed.
cotto Prior attempts to get more people involved in the GC haven't gotten much done.
mikehh bacek has been working on generational_gc
some failing tests etc
cotto If we want to do that, we should figure out what the barrier is and how to address it.
dukeleto chromatic: Well, one thing that I think will be easy to get progress on is testing our socket API. We have horrific test coverage for networking code. 20:40
i was in the 20%'s for most files or less, and I got Socket PMC up to 30% in the last week
this is related to our ipv6 patch that is sitting in our Trac queue, which has no tests. It would be nice to be able to apply that and know that we didn't break ipv4 sockets 20:41
chromatic We have 19 open build system tickets.
43 open configure tickets.
20:42 bacek joined
bacek ~~ 20:42
chromatic Can we close 20 configure tickets in the next week? 20:43
dukeleto I am +1 to trying it as a goal 20:44
mikehh we can look at it
chromatic Let's do it then.
Other goals for last week?
dukeleto even if we only close half that many configure tickets, it will be well worth it.
what were the goals? 20:45
bacek (last week report: gen_gc is almost there. coretest passed modulo RO tests (which are disabled for now))
chromatic all GC related last week, I think
dukeleto bacek: what are RO tests? 20:46
mikehh read only - got some failures there 20:47
bacek dukeleto, we have ro_variant_vtable to use when we switch PMC to RO mode.
dukeleto allison: if you could post more info about your parrot+ubuntu announcement to parrot-dev, that would be awesome 20:48
chromatic Shall we set other goals for this week? 20:49
2.9 comes out next week, if I read the calendar correctly.
allison dukeleto: it's not an announcement, it's just an "entry for candidacy" at this point 20:50
bacek If someone can jump on gen_gc branch it will be helpful. Not worth for weekly goal, but still. 20:52
chromatic What do you need there?
dukeleto allison: well any information about an entry for candidacy would be useful and interesting to hear about :) 20:53
bacek: do you need that branch smoked?
bacek chromatic, pair of eyes.
chromatic Any other goals for this week?
bacek dukeleto, not smoked yet. Just some kind of review of logic. 20:54
dukeleto bacek: i will take a look to try and learn about what is going on there, but I offer no promise of a useful critique.
bacek dukeleto, deal
20:54 plobsing joined
dukeleto plobsing: we are almost done with goals for the week. Do you have anything to add? 20:55
plobsing dukeleto: I haven't done much parrot-y this week, so likely not 20:56
chromatic Let's move on to blockers. 20:57
What's blocking us and why?
dukeleto Not having a configure step to detect ipv6 is blocking me from committing more tests to trunk
We already have a ticket for it: trac.parrot.org/parrot/ticket/1824 20:58
mikehh probably need a branch 20:59
chromatic Let's make that happen then.
Other blockers?
dukeleto Well, mk_language_shell.pl is blockig the migration to git 21:01
so is create_language.pl
Util how are they blocking?
dukeleto currently they check to see if parrot is new enough for the HLL to compile by comparing two integer subversion revisions, one from parrot_config and the other stored in the file PARROT_REVISION 21:02
there is no linear ever-increasing revision in git 21:03
the closest thing is "git describe"
which gives you a symbolic "version" relative to a tag, so it would return something like RELEASE_2_7_0~100gcafe 21:04
which means "this parrot is 100 commits after the tag RELEASE_2_7_0, using 'git' and has the sha1 cafe
this is all well and good, but the problem is if we release a parrot x.2.1 after x.3.0 (such as a security release), comparing versions becomes very freaking hard 21:05
Please guide me from this dark maze, where all the corridors look exactly the same.
This is related to semver.org/ 21:06
chromatic Could we compare dates instead? 21:07
Util Shouldn't there be a way to query if a certain commit is in the history tree of the repo that parrot_config is using? If so, the embed the latest in PARROT_REVISION, and check for it.
cotto a note: we have the same security release problem with our current scheme
dukeleto chromatic: i like the idea of comparing dates. Actually, the scam I have thought of recently is a date+git-describe string pair. I think that is what can work. 21:09
chromatic Any other blockers to discuss?
dukeleto Util: HLLs don't currently require for the repo to exist to determine if parrot is new enough
Util: comparing sha1's directly requires a git repo
Util: or we could ship a database of version info with every HLL, but that seems to be a suboptimal solution to me 21:10
Util dukeleto: I see. In that case, simple date comparison is probably good enough for most cases. 21:11
dukeleto Util: yes, simple date comparison is an ~80% solution 21:12
are we onto questions now? 21:14
chromatic Let's move to questions.
dukeleto Util: I agree 21:16
How do we best utilize the GCC Compile Farm? 21:17
chromatic Can we submit tasks to it? 21:18
GeJ * Belated report :
- Unfortunately did nothing parrot related : $health got in the way and pain management is occupying most of my time.
- Things don't look any brighter for the upcoming week as I should go under the knife (date to be confirmed with surgeon)
Sorry.
dukeleto chromatic: in theory, yes. We could setup a buildbot or set up TapTinder or have smokers
GeJ EOR
And good morning.
dukeleto GeJ: top of the localtime() 21:19
chromatic: taptinder doesn't have installation instructions
chromatic: smoke tests aren't integrated to anything else very well (we manually have to check reports) 21:20
chromatic: buildbot could be the better solution, maybe not. I've never set it up before
chromatic Sounds like we need more research then.
dukeleto One other cool thing is that RTEMS uses the GCC Compile Farm, which means we can setup testing on RTEMS on the compile farm.
and we can test against a range of gcc releases as well as gcc trunk if we want 21:21
chromatic Shall we move to the next question? 21:22
Util wait 21:23
Ranked thoughts:
1. Port to new platforms (PS3, woohoo!)
2. Smokers on rare platforms (we can smoke common platforms elsewhere)
3. Smoke across multiple GCC variants and compile flags
50. Smokers on common platforms
99. Benchmarking - suboptimal on shared systems
.end
dukeleto in a related note, "make test" goes into an infinite loop on the PS3 (but core_test passes) 21:24
chromatic I rank in almost the opposite order.
dukeleto, can you figure out what we need to do to submit jobs there and get information back? 21:25
21:25 bluescreen left
dukeleto I think we should have a dedicated testing $whatever for supported platforms. If we don't continually test on all "supported" platforms, we are just lying. 21:25
chromatic: i will ask if we can submit jobs (i think most likely it is yes), but I will check
chromatic: the machines can connect out to the internet, so they could periodically check for new jobs 21:26
chromatic: so I think we can assume that we can submit jobs
chromatic Continual testing of core platforms is a very good idea.
dukeleto There are a few sparc machines in the compile farm, but almost every machine is running debian. So the compile farm represents many platforms, but not many OS's. 21:27
there are also some arm machines, which I am not sure is supported by Parrot currently
chromatic Optimized and non-optimized builds are useful for testing. 21:28
dukeleto chromatic: yes. We are failing our optimized darwinppc build right now. 21:29
chromatic Any other questions? 21:30
dukeleto In theory we could define N options to parrot, and smoke all kinds of combinations of them, but the important ones need to defined, because the number of possibilities grows combinatorically i.e. exponentially
like ICU, optimized, readline, etc
GMP would be a good thing to test regularly as well, since we have core PMCs that use it 21:31
I will create an RFC ticket for the compile farm to gather comments.
q1q 21:32
chromatic go ahead
dukeleto There is something called Google Code-In coming up, that is like GSoC, but aimed at high school students and younger. It is the re-invention of the Google Highly Open Participation thingy 21:33
Do we want to invest resources to be part of it? Anyone interested in volunteering for things related to that?
They will be announcing a call for organizations to apply next week, I think. 21:34
mikehh do we have the sort of tasks that would work there? 21:35
dukeleto mikehh: Tyler Curtis is 18 yrs old and did a magnificient job in his GSoC project, so I think the answer is yes 21:36
cotto Sure. Even for someone just getting into open source, we could always use more docs. 21:37
dukeleto mikehh: and Google Code-In in more open than GSoC, so students can translate or add documentation, or work on graphics and things like that
mikehh: it isn't only code
mikehh I got the impression that it was more of a group participation thing
dukeleto GSoC doesn't allow docs-only projects, Code-In does
mikehh: Code-In is supposed to be individual only, just like GSoC
students are given "tasks" which are smaller than GSoC proposals 21:38
mikehh I think HLL development might work there
dukeleto and then the Goog pays students some small amount per task, up to $500 or so
it is mostly geared towards younger students getting introduced to open source, and not so much as being a summer stipend
I think Parrot should be involved, but I don't know how much time I can put towards it. I will need help if Parrot is going to do it properly. 21:39
cotto What kind of help would you need? 21:40
dukeleto so if a few people are willing to come up with small tasks for newcomers to accomplish, that would be awesome.
if we are accepted as an org, we will can create a bunch of tasks that we would find useful but will also teach someone new about open source
i am not sure if students are supposed to come up with their own "tasks" or not, but we can defintely suggest them 21:41
and if we can say "Parrot has X tasks to choose from" we will get more people than "Figure out a task for yourself to work with Parrot"
mikehh I will certainly give it some thought, not sure if I have any tuits in that area
Util Tasks for newcomers should be tickets tagged with keyword: newbie; they will appear on report {19} in trac. 21:42
dukeleto Util++ doing stuff
Util cotto++ # original idea 21:43
cotto I'd originally intended newbie tickets as something that'd take a newbie a relatively short time to complete (a few days, max), but I like the repurposing of it. 21:44
especially since nobody's been tagging very many tickets as "newbie"
dukeleto +1 to making newbie ~~ code-in tasks 21:45
newbie tickets probably need more friendly descriptions, with some background.
cotto alternately, we could have a "code-in" tag
dukeleto i think a newbie tag is sufficient 21:47
it is more useful because code-in could be a one-time or rarely-occuring thing
newbie is a useful tag for parrot in general
cotto wfm. We can divide up ranges of tickets during the week for tagging. 21:48
dukeleto If a newbie ticket is trying to be useful for code-in, that can be mentioned, and some background given.
I am done with Code-In related matter.
matters, even. 21:49
cotto dukeleto, is that the extent of the code-in help you'd need?
dukeleto cotto: no, that is just the beginning. I don't know exactly what will be involved. I have never done something like it, other than GSoC, and this is the first year of Code-In 21:50
cotto dukeleto, I'm willing to help out some with that. 21:51
let me know how when the time comes
mikehh also
chromatic Anything else to discuss this week? 21:53
dukeleto There is a parrot hackathon happening soon. 21:55
the PDX Gathering/Hackathon this Saturday 21:56
Just wanted to mention it. If people want things to be brought up at it, they can ask on parrot-dev.
cotto looking forward to it 21:58
dukeleto agrees 21:59
chromatic See you all (some) there. 22:02
dukeleto Are we calling it a wrap? 22:10
chromatic wrap
22:20 nwellnhof left 22:24 luben left, Paul_the_Greek left 22:31 bacek left 22:33 bacek joined 22:54 bacek left 23:08 bacek joined 23:21 bacek left 23:22 bluescreen joined 23:34 GeJ left, GeJ joined, wagle left, wagle joined 23:36 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!