"Tuesday at 20:30 UTC"
Set by moderator on 20 September 2010.
00:41 Util joined 02:30 particle1 joined 02:33 particle left 02:50 ash_ left 03:11 mikehh joined 09:43 contingencyplan left 13:00 mikehh left 13:37 PerlPilo1 left, PerlJam left 13:38 PerlPilot left 13:39 PerlJam joined 14:32 ash_ joined 15:43 plobsing joined
plobsing What I Did: 15:55
* Minix port 15:56
* compiles
* completes coretest (with some issues)
* smoketesting not currently possible due to slightly broken system perl
* identified several faulty assumptions in Parrot (now fixed)
* Fixes and debuggging on portability improvements brought about by Minix port
* Fixes to profiling and tracing runcores (broken after dynop_mapping)
What I Plan:
* Fix TT #1813
* No Fixed Plan. Potential projects:
* Minix port - fix tests
* Minix port - run rakudo (tricky due to lack of dlopen on minix, lack of graceful fallback in parrot)
* PBC linking (in anticipation of 6model) 15:57
EOR
17:31 Tene joined 17:32 ash_ left 17:41 contingencyplan joined 18:05 mikehh joined 18:36 kid51 joined
kid51 kid51's report 18:36
* Testing on linux/i386 and darwin/ppc.
* Raised issues about new config steps committed directly to trunk without TTs: See: groups.google.com/group/parrot-dev/...243aefd0f#
* While in Toronto, gave lightning talk seeking more Parrot developers 18:37
* Also while in Toronto, met with Richard Dice, former Perl Foundation president
* Preparing for Pacific Northwest Parrot Developers gathering, Sat Oct 16, Portland OR. Space is secured; will be composing agenda with dukeleto.
EOR
18:40 kid51 left 18:58 ash_ joined 18:59 dukeleto joined
dukeleto I won't be at #ps today. Hopefully cotto++ can give a status update on the GitMigration. 18:59
I wrote some tests for create_language/mk_language_shell and did some smoking on darwin ppc.
cotto For the record, I can do that. 19:17
19:28 chromatic joined 19:31 bacek joined 19:47 cotto left, cotto joined
GeJ Report for GeJ 19:56
== What I did
* Spent most of the week refreshing my memory on PIR.
* Reading Data::Dumper code as it is my next target. Planning some changes (bacwards incompatible unfortunately) and improvements.
* Will probably need the help of more savvy people to confirm some assumptions I have
== What I'll do
* Will convert some easier tests this week.
* Will post a RFC on the list about my Data::Dumper plan and ask about the right thing to do.
--
EOR
cotto #done: 19:58
- wrote more github plugin test cases
- all tests pass now
- I'm calling the code "ready for use"
- more test cases are always welcome (see GitHubTracPluginTests on the wiki)
#to do:
- make the profiling runcore as easy-to-understand as practical
- get the nqp-rx build working with PARROT = $(PARROT_BIN_DIR)/parrot$(EXE) -Rprofiling
- sync with osuosl about the post-migration configuration of trac.parrot.org 19:59
#eor
GeJ PS: I don't know yet if I'll be able to attend #ps this morning as I have an appointment. Will backlog later on and answer any question on /q or #parrot. 20:04
20:08 tcurtis joined 20:13 atrodo joined
tcurtis What I have done since the last #ps I attended: Probably nothing Parrot-related. Started university. 20:14
What I will do in the coming week: Probably not much, if anything, Parrot-related, but if I do, hopefully work on bring the branch I initially used for my GSoC work up to date.
End of report. 20:15
mikehh What I did since my last report:
* 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:16 kid51 joined
bacek Little bit of work on generational_gc branch. Not so much as I want. 20:17
chromatic I'm blocking on time and have done nothing interesting. 20:23
20:24 ash_ left
Util No Parrot work done this week; all todos from last week moved forward to coming week. Will be absent for #ps. 20:25
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}'
3 closed: fixed
10 new
.eor
20:26 Paul_the_Greek joined
cotto It's that time again. 20:30
chromatic Good $localtime
mikehh hello
chromatic How did we do last week? 20:31
3 closed tickets and 10 new. Are the current tickets more difficult, or did we have a convergence of Real Life? 20:33
Paul_the_Greek Hey there, all.
Real $life for me, that's for sure.
mikehh spent most of my parrot time tracking down bugs
kid51 Travel + same as mikehh 20:34
Was not able to spend any time in past week culling thru old tickets
chromatic Any concerns that this is a long term malaise? 20:36
kid51 I don't have that concern *yet*. 20:37
mikehh always concerns in that area, but I think that a new University year is starting (at least in the Northern Hemisphere)
kid51 I hope that our gathering in Portland will increase energy level, at least of participants.
But we're due for another online Parrot Dev Summit, IIRC.
chromatic That's also true. 20:38
Were there any goals for last week besides closing tickets?
mikehh some of the GDOC branches might be ready to merge after the release 20:39
gsoc
cotto q1q related to that 20:40
chromatic Let's move on to plans for this week. Recommendations?
mikehh well keep closing tickets and release prep 20:41
kid51 q1q
mikehh it's a major release
Tene Looks like I probably won't be attending the gathering in portland.
cotto and getting ready for the git migration
mikehh we need to get any deprecations in 20:42
chromatic Should we set a ticket goal?
cotto -1 from me, just because they seem to be losing effectiveness 20:43
chromatic Would making the more directed goals help? 20:44
cotto sure 20:45
chromatic Followup: what direction? 20:46
cotto maybe something like "start branches for deprecations to be merged after the release" or "find stuff that needs to be deprecated"
kid51 When I met with whiteknight last month outside Phila, he identified several problem areas; see his first blog post
Perhaps we could pick one of those.
(This will be one of the discussion topics in Portland, in any case.) 20:47
cotto "Woe Is Parrot!"?
kid51 My hunch is that we haven't fully sorted out all the ramifications of the gc_massacre merge.
cotto: No, the one before that.
chromatic For example, gc_massacre has disabled global destruction.
mikehh will there be any online presence in Portland?
kid51 mikehh: For part of the day, yes. but we'll have more details in a few days. 20:48
cotto mikehh, as long as there's wifi
wknight8111.blogspot.com/2010/09/pa...tform.html <- that one then/
?
kid51 cotto: yes
Whatever major problems he identified there ... or we collectively identify here, at gathering or at online summit ... 20:49
... my hope is to have more or less clearly defined teams working on each problem ...
... if for no other reason than to increase the bus number. 20:50
In other words, let's make a modest attempt to match our talents/interests to Parrot's needs. 20:51
chromatic +1 20:52
mikehh +1
cotto +1 20:53
chromatic That'll help the planning for 3.0 20:54
Is there anything we can do for 2.9?
Coke speed. profiling.
20:56 plobsing_ joined
chromatic Any other tasks for 2.9? 20:57
Let's move on to questions then. 20:58
kid51?
kid51 Related to what I posted on list today: We have to decide whether to retain what plobsing did re inf_nan in trunk or to pull it back into a branch so that it's not part of the release. 20:59
Someone other than me should make that call, because I have strong feelings about it.
cotto The ones who care are the ones who get things done. 21:00
kid51 I can't spend much more time on that until next week ... which would be too close to the release.
mikehh one of the problems there is that what seems a small change, can cause problems elsewhere
cotto how likely is it to get fixed before the release? 21:01
i.e. do people who aren't kid51 know how to fix it
kid51 cotto: As I said, I can't guarantee that I'll have the time to work thru the steps Peter outlined ...
mikehh like, ok this is a bug fix and tests ok on my platform, but it blows up win32 or something
kid51 ... but dukeleto reported a PASS on that platform.
So we have inconsistent smoke results. 21:02
plobsing_ You used different compilers 21:03
dukeleto used gcc, you used g++
mikehh just for the linker
kid51 plobsing_: Yes, I believe we did.
I used the same compiler/linker/loader combo I've always used on that box. 21:04
chromatic What's the problem with adding new configuration steps? Is the problem "Our policy says discuss on the list, open a ticket, develop on a branch, and only then merge?"
mikehh I often get failures with g++ that pass on gcc
kid51 IIRC, there was another report of a FAIL due to g++ being in the mix somewhere.
chromatic: Yes, that's what our policy says ... at least with respect to Trac.
mikehh I think that got fixed
chromatic Is that the only problem with these commits, that it violates that policy? 21:05
kid51 My belief is that these sorts of debugging issues are best handled when the code is still in a branch.
plobsing_ like I said in the email, feel free to revert it. 21:06
chromatic I can't agree until we get branches smoked in any reliable fashion.
kid51 chromatic: As I said in one of my posts to that thread, when developers post requesting in branch, the cage cleaners (well, mikehh and I) are quick to get on those requests.
In recent weeks I've smoked branches for bacek and nwellnhof, at least. 21:07
mikehh we broke the MSWin32 build (it was a case of an #ifdef that should have been an #ifndef, but worked everywhere else 21:08
chromatic Okay, but is there a problem with these commits other than "It violates the policy"?
Coke which is quickly pointed out by taptinder.
I don't mind temporary breakage on trunk as long as it is very temporary.
plobsing_ which we wouldn't have caught in a branch 'cause I can never seem to get people to smoke branches on windows
kid51 The policy is there so that everyone knows what someone is proposing to merge into trunk.
Coke Perhaps adding more taptinder clients would help make this less painful. 21:09
mikehh +1
Coke Yes, but if it's only for "configure steps", it's not very really consistent.
chromatic kid51, are you suggesting that we should consider doing *all* development work in branches?
mikehh We need to have testing done on a lot more platyforms
kid51 Coke: While the policy was explicit to configuration steps, the fact is that *most* of our dev work now is conducted in branches.
mikehh it will be a lot easier with git 21:10
kid51 And in git, most of the dev work will, in effect, be conducted in branches.
chromatic I'm still trying to understand the problem. 21:11
mikehh how does one decide if a simple bug fix needs more serious testing
plobsing_ mikehh: crystal ball
kid51 The problem is that the code in 1 of 3 new config steps was directly committed to trunk and started breaking things.
So we're playing catch-up-and-debug in trunk where we could have been doing it in branch. 21:12
chromatic How is that different from code not in a config step committed to trunk and breaking things?
kid51 As I said, most of the work our developers are doing these days is conducted in branches. 21:13
When the devs requesting, we do it in branch.
...
And that reduces the likelihood of breaking things in trunk.
Not 'eliminates', but 'reduces'
chromatic I assume no one wants to break trunk. 21:14
cotto I'm always sad when I break trunk. 21:15
kid51 chromatic: It's a question of attitude ...
chromatic No one has yet suggested "Let's develop everything in branches and only merge once they've smoked clear on all important platforms."
What's this discussion *about* then?
kid51 It's about committing code directly to trunk, relatively close to release, that wasn't available for code review prior to being committed to trunk. 21:16
mikehh I think if we have functional changes, they need to be worked on in a branch, but not for simple bug fixing - it should still be tested before commiting 21:17
kid51 mikehh: Of course, there is a level of simple bug fixing that can and should be done in trunk
e.g., your codingstd corrections.
chromatic Ha.
I broke Rakudo once with a simple codingstd correction.
kid51 But adding new config steps does not, in my book, constitute simple bug fixing. 21:18
cotto so "big changes in a branch please, fsvo big"?
chromatic If these commits hadn't broken one platform, would we be having this discussion?
kid51 cotto: Yes.
chromatic: Yes, though perhaps not today. Today because we're a week away from supported release. See whiteknight's post in this thread from today. 21:19
chromatic Isn't the release two weeks away?
mikehh yeah 21:20
kid51 Corrected.
plobsing_ kid51 did mention objections to my additions before the one that broke things. we might still be having this discussion.
chromatic What do people hope to get out of this discussion?
A policy that we develop only in branches? 21:21
A promise that we never break trunk?
Reverting these commits?
A policy that we don't make changes in trunk a week before the release?
mikehh I think some guidelines on when we need to work in a branch and not in trunk 21:22
kid51 chromatic: As I said above, on the inf_nan things I'm inclined to revert ...
... and it appears Peter can live with that too.
We can put that stuff in a branch and work on it for next two weeks before release. 21:23
mikehh I thought the guideline there was for bugfixing on the Saturday before release
kid51 Well, look, I'm a pro-branch guy. Have been ever since I joined the project. 21:24
plobsing_ doesn't the release manager dictate a code freeze before these releases?
mikehh I think we got that mostly sorted out now
kid51 At that time, the theme was: "Commit [directly to trunk] early and often."
cotto plobsing_, yes, that's primarily been the release manager's prerogative.
kid51 We've gotten away from that ...
... which in my book is a good thing.
But I recognize that not everyone shares my opinion.
21:25 nwellnhof joined
chromatic In the absence of specific directives followed to the letter, we have a couple of guidelines: 1) don't break trunk 2) use your best judgment. 21:25
Sometimes those will fail.
mikehh kid51: to a degree, but where to draw the line is the problem
chromatic needs to leave for a meeting 21:26
mikehh and often what looks like a simple change can break things 21:27
chromatic If we need to change our policy guidelines that's fine, but I don't see a huge failure here.
We've reverted commits before as necessary and we'll do it again in the future.
cotto +1 to chromatic
kid51 (Got called away to $job discussion there.) 21:29
mikehh Something I wanted to bring up - I don't think aloha is ready for prime time and purl has been kicked, I think she is still needed 21:33
cotto did we lose chromatic?
mikehh, +a lot
plobsing_ so many factoids no longer available
a couple of which were actually useful 21:34
mikehh chromatic said he had to leave for a meeting
kid51 has issues at $job to deal with 21:35
cotto any further thoughts on purl? 21:37
mikehh bring her back 21:38
cotto any volunteers to do so?
mikehh no idea how to 21:39
I think moritz told her to go
cotto Can you talk to him about getting her back in #parrot? 21:40
mikehh I can try 21:42
cotto Did anyone else have a question?
I had one in that case. 21:43
My gsoc student's project (instrumentation for Parrot) currently lives in both a svn branch and on github. Whiteknight has done some work to get it working with trunk, but I'm concerned that it'll bitrot again pretty quickly, assuming he has the tuits to figure it out. 21:44
I think the code has the potential to replace (or at the very least strongly complement) the profiling runcore and that it'd do well as a core feature.
What are people's thoughts on making gsoc-instrument a core parrot component?
mikehh isn't is more for embeded rather than core? 21:45
cotto mikehh, what do you mean?
mikehh hmmnn not sure really 21:46
21:46 allison joined
mikehh but from what I have seen of it - it looks good 21:46
plobsing_ I'm not really in favour of it going into trunk. What makes this work really amazingl is that it is (was) able to live outside of trunk. 21:47
I might have some tuits to throw at it though. Chances are I broke it (I tend to break a lot of things :( ) 21:48
cotto allison, any architecty thoughts on irclog.perlgeek.de/parrotsketch/201...#i_2893642 ?
mikehh to put it another way, what specific benefits does it bring to trunk 21:49
cotto I think it could give us some useful everyday parrot debugging tools.
mikehh plobsing_: breaking things focuses on the inherent problems there :-} 21:50
allison cotto: will take a look
mikehh cotto: if it gives us better debugging facilities I am all for it 21:51
cotto eoq then 21:52
allison cotto: can we add it without removing or disrupting any existing features? if so, then no risks
cotto absolutely
allison cotto: seems like a win, then
cotto the branch only adds files and makefile infrastructure
allison cotto: does it need to be marked as "experimental" or is the API pretty settled? 21:53
mikehh I'll give it some more testing time
cotto It should be marked as experimental, at least for a bit. 21:54
allison is there any risk of it breaking compiles on rarer platforms? 21:55
mikehh ha, there is always that risk, even with a one character change
cotto I'm not sure. I'll ask for smoking once the branch works is updated to work with trunk.
eoq 21:57
any further comments or other questions?
22:01 tcurtis left
cotto That's a wrap then. 22:05
22:05 nwellnhof left 22:08 Coke left, Paul_the_Greek left 22:10 kid51 left 22:14 plobsing_ left 22:20 PacoLinux left 22:32 plobsing left 22:37 chromatic left 23:50 ash_ 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!