Parrot 3.7.0 "Wanda" | parrot.org | Log: irclog.perlgeek.de/parrot/today | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 6 September 2011.
dalek kudo/nom: 0d73bac | Coke++ | t/spectest.data:
run fudged test
 00:13
00:32 soh_cah_toa joined
soh_cah_toa msg NotFound thanks for taking care of that issue w/ t/pmc/timer.t 00:35
aloha OK. I'll deliver the message.
00:58 ttbot joined 01:16 jkitazawa joined
dalek kudo/nom: cbdd9b0 | Coke++ | t/spectest.data:
run fudged test.
 01:18
plobsing gah. I hate it when I read over an email 5 times before I send it and yet only seem to see the glaring typo *after* it is sent 01:20
cotto_work +1 01:21
soh_cah_toa plobsing: ha! i know. i do that all the time :)
plobsing for the record, I meant 3.*8* release in the email I just sent to parrot-dev
01:22 woosley joined
soh_cah_toa alright, i now have all necessary access to ftp-osl.osuosl.org and parrot.org 01:27
'fulltest' passes on my fedora and openbsd machines w/ all combinations of gcc/g++/clang so we're looking good for tomorrow
i'd be a little happier w/ some more testing on win32 though. if only i could setup a development environment on windows. it's such a pain not having a package manager for handling dependencies
01:31 arnsholt joined 01:34 ttbot joined
dalek rrot/hints_more_verbose: b6bf3d3 | jkeenan++ | config/init/hints/ (2 files):
FreeBSD and OpenBSD: make hints display better when verbose output has been selected (along same lines as Darwin and Linux).
 02:00
cotto ~~ 02:02
soh_cah_toa damn, t/dynoplibs/trans-infan.t, t/dynoplibs/trans-old.t, and t/dynpmc/select.t (surprise, surprise) are failing on opensolaris 02:20
nopaste "soh_cah_toa" at 192.168.1.3 pasted "Test Failures While Smoking OpenSolaris" (13 lines) at nopaste.snit.ch/81852 02:28
"soh_cah_toa" at 192.168.1.3 pasted "Verbose Output for Test Failures on OpenSolaris" (39 lines) at nopaste.snit.ch/81853 02:33
soh_cah_toa unfortunately, i'm not familiar w/ those tests (or dynoplibs, for that matter) so there's not much i can do 02:35
03:05 cotto joined
Coke given that it's not a core platform, 3 test files failing is not terrible, esp. when one fails on another platform. 04:09
soh_cah_toa yes
dalek rrot: ba4bd62 | petdance++ | src/call/context.c:
Don't try to return a function that returns void
 04:20
Coke no slushie? 04:26
soh_cah_toa ??? 04:27
cotto soh_cah_toa, code slush (like a freeze but not quite) 04:29
soh_cah_toa petdance said he didn't know about the freeze 04:30
cotto though that's a pretty sensible change 04:31
soh_cah_toa yeah, i don't see how it could crash anything but i'm testing all the same
cotto wfm 04:32
soh_cah_toa after having run all these tests for the past several days, i never realized how many todo/skip tests we have 04:34
a whole lot
most of them are 'see TT #1234, it's not done yet'
05:41 rfw joined 06:11 JimmyZ joined 06:23 zby_home joined 07:04 JimmyZ joined 07:06 mj41 joined
cotto phpunit-- 07:37
it wouldn't be so bad if they called it a code-running framework instead of a test framework 07:38
07:46 schmooster joined 08:42 SHODAN joined 10:06 he_ joined 10:40 lateau joined 11:36 Psyche^ joined 11:39 benabik joined 12:03 mtk joined 12:11 whiteknight joined
whiteknight good morning, #parrot 12:12
moritz good morning whiteknight
tadzik good morning 12:15
whiteknight hello moritz, tadzik. How are you two doing today?
benabik o/
tadzik suprisingly good :)
benabik morning, whiteknight moritz tadzik 12:16
12:19 bluescreen joined
Coke who manages rakudo.org? 12:29
tadzik pmichaud I think
atrodo =~
tadzik ~=
Coke whoops, wrong window.
12:29 redicaps joined
benabik We're all talkative this morning. :-D 12:34
13:01 benabik joined
mls hi whiteknight! 13:43
whiteknight hello mls 13:44
mls so, no subprof in this week's parrot release?
13:47 bluescreen joined
whiteknight no, there's a code freeze on master. We'll merge it in right after the release 13:49
mls k, sounds good. 13:50
whiteknight we have a few branches going to merge in after the release. If the subprofiler is ready to go, we'll try to put priority on that so it doesn't get breakage from other things 13:54
mls thanks. 13:55
atrodo I don't think we do enough sub-sub version releases. We don't screw up nearly enough. We should strive to be like php and break little things in big ways.
14:00 soh_cah_toa joined 14:04 jsut_ joined 14:17 redicaps left 14:55 lateau joined 15:00 dmalcolm joined
Patterner can I break crypt()? 15:40
"Parrot now compatible to PHP 5.3.7." 15:41
benabik Break how? 15:42
Patterner return only the salt or something like that... 16:18
16:23 JimmyZ joined
benabik … I don't see a crypt function in parrot. 16:25
16:26 JimmyZ_ joined 16:32 cosimo joined 16:36 bluescreen joined
Coke I think he was making a joke about php, not offering to patch parrot for reals. 16:37
16:37 contingencyplan joined
benabik Oh. u.u 16:38
16:42 fperrad joined 16:54 fperrad joined
dalek kudo/nom: 7552eb9 | jnthn++ | src/pmc/perl6lexpad.pmc:
Remove now unrequired calls to steal_outer (mls++).
 16:59
17:10 mj41 joined 17:16 zby_home joined
cotto_work ~~ 17:28
dalek kudo/nom: 7fdc6b4 | jnthn++ | src/binder/container.c:
Apply patch from mls++ to harden container storage.
17:37 benabik joined
dalek kudo/nom: 79344e0 | jnthn++ | src/pmc/perl6lexpad.pmc:
Try to eliminate a bunch of C compiler warnings tadzik++ is seeing.
 18:10
kudo/nom: 091c262 | jnthn++ | src/ (2 files):
Fix issue with dynamic compilation of multis belonging to a derived dispatcher. Fixes issues with declaring custom traits and using them in the same compilation unit.
 19:15
cotto_work #ps in 5 19:25
dukeleto blog.llvm.org/2011/09/greedy-regist...vm-30.html
cotto_work Heh. I didn't mention that link because I figure you'd already done so. 19:30
19:45 benabik joined 19:55 whiteknight joined 20:04 jsut joined 20:09 jsut_ joined 20:29 soh_cah_toa joined
cotto_work soh_cah_toa: ping 20:38
soh_cah_toa cotto_work: pong
cotto_work soh_cah_toa: once you've got a branch for the release, make sure to send out the all clear on the appropriate channels.
soh_cah_toa yup
Coke missed the meeting. Yes, allison did not, as i recall, like git. 21:03
allison Coke: curiously, I actually like git now 21:18
Coke: but I still hate our branching technique
Coke: it's like we brought all the pain of subversion into git 21:19
cotto: to answer the question from the meeting, simplify it 21:20
cotto: and stop using --rebase
cotto: --rebase is supposed to be rare
(any git developer will tell you that)
benabik I tend to use pull --rebase a lot, but only to maintain really simple patches on master, not for branches. 21:21
(Example: I have a patch to todo a select.t test)
Coke enabik++ (I always rebase when I have unpushed changes and am doing a pull. and since I don't want to have to remember the current state when I pull, I always pull --rebase.) 21:23
benabik++ I mean.
benabik During GSoC, I also used rebase -i to clean up commits.
allison cotto: I suspect --no-ff is part of our mess too
benabik But suggesting rebase to new users is probably not completely wise...
(It's easy to get into very strange states with rebase) 21:24
allison cotto: on the whole, I suggest adopting the linux kernel workflow, in its entirety
cotto: including working primarily by cherry picking, and having one person do the final integration
cotto: it doesn't have to be the architect, that'd just lead to burn out 21:25
cotto: but, the release manager for the month could also be the patch meister
Coke so we have a single user bottleneck instead of a single branch bottleneck? what's the advantage?
allison a rotating bottleneck
Coke quality control?
allison yup
Coke HA
mmhehe. 21:26
allison and sanity of the repo
Coke ok. Before we fix the workflow to address quality control, we need to address our quality. ;)
allison remember, linus doesn't review every patch, but several people in tree as patches filter up to him do
Coke: chicken and egg problem
Coke allison: we don't have that kind of structure of developers. 21:27
PerlJam allison: is there a concise description of the linux kernel workflow somewhere?
Coke the toolchain isn't going to give it to us.
allison Coke: quality control is the best way to improve quality
that's what the toolchain was designed for
benabik The toolchain was designed to be flexible. There's not really one true git model.
allison benabik: sure, but there are better models and worse models 21:28
Coke I'd be interesting in seeing a writeup about how it's better. I'm not really a committer on parrot at this point, so I don't really care. But I find the fact that you're on the other side of this now quite bemusing.
*interested
21:28 perlite_ joined
Coke *care from a practical standpoint. 21:28
allison Coke: I suppose it's a conversion of sorts 21:30
Coke: but on the whole, I think it's better to wholeheartedly embrace change if we're going to make it
Coke: in the long-run, it's less painful than straddling the fence 21:31
Coke Having living through change for change's sake in our toolchain in the past, I hope it's actually a beneficial change. 21:32
allison Coke: anyone but the core team will only benefit from simplicity, so it really comes down to a question of what's good for them 21:36
Coke: and, it could be as easy as developing a simplified workflow for general use, with a more advanced workflow for those who have commit access on "trunk" 21:37
benabik We could continue to use master as an integration branch and create a long-running release branch where that month's release manager cherry-picks/merges as they see fit.
allison Coke: the rest (or the next step) is just a matter of discipline, deciding, for example, that only one person will commit to "trunk" in the lead up to a particular release 21:38
benabik I think we're already tending more towards features in branches, with only small things in maste.r
(directly to master)
allison having multiple people all merging directly to the "release branch" does cause trouble 21:39
linux has a "linux-next" branch where multiple people integrate
then linus's branch, where he pulls from linux-next, and cuts the final release 21:40
benabik My thought: simple (1 commit) fixes direct to master, features/complex bugfix in branch. Release manager maintains "release" (bikeshed at will) and cherry/merges as they want for the month they control it. 21:42
(Or could narrow window to a week or two if we don't want master to diverge far from release) 21:43
our core can integrate in master as they see fit. If we're doing well, release can just merge master straight in. 21:45
Biggest difference I see from what we do now is starting a release branch. And possibly more discipline with working in branches (but we seem to be doing that a lot already)
dukeleto ~~ 21:46
cotto_work and back
allison I'd go with that, except would replace the simple fixes with cherry picking, instead of direct commit.
cotto_work allison: I just noticed your reply. Thanks. backscrolling now 21:47
benabik Cherry picking is "committing a patch"... Simple fixes would be cherry-picked from master into release.
allison i.e. developers all have their own private parrot git repo
benabik The biggest advantage with our namespaced branches is dalek... Everyone can see how everyone's working. 21:48
allison dalek could track other repos too 21:49
cotto_work It'd need to be manually set up, but it's possible.
benabik I don't think where the branches live matters very much. 21:50
allison benabik: it's a workflow thing
benabik: using personal branches and pull requests, rather than merges 21:51
benabik: where anyone can service anyone else's pull request
benabik Ah. code review.
allison benabik: (but not their own)
dukeleto allison: that is pretty much what we do now
benabik "Someone else thinks merging this is a good idea"
There was some resistance to moving more of our workflow into github pull requests, IIRC 21:52
allison dukeleto: I don't see that in the workflow anywhere, or in practice on the mailing list or IRC. Where does it happen?
dukeleto allison: in practice
allison: for example: github.com/parrot/parrot/pull/163 21:53
allison dukeleto: you mean for non-committers?
dukeleto: how about for committers?
dukeleto allison: also, --no-ff always leaves a record that a merged happened, which I prefer (as well as many other projects) 21:54
allison: new current practice is for anybody, core committer or not, to submit a pull request for review
allison dukeleto: it's not documented
dukeleto allison: patches welcome
dalek nxed: 533961d | NotFound++ | winxedst1.winxed:
'multi' modifier for functions, without arguments for a now
dukeleto allison: i definitely felt like there was some misplaced hostility against parrot at the end of that LWN article 21:55
benabik dukeleto: You're bouncing on and off #perl6...
dukeleto benabik: damnit
allison dukeleto: you may personally prefer --no-ff, but it makes for a messy commit history
dukeleto: it certainly wasn't intended as such, it wasn't part of the planned talk at all
dukeleto allison: your opinion, i guess. I think it leaves a trail of merges, which is quite helpful.
allison: also, linux's workflow getting jammed into the parrot community isn't going to work, because parrot and linux are developed differently 21:56
allison dukeleto: (it also leaves a trail of random garbage from people who aren't using rebase)
dukeleto allison: no, i think you are misunderstanding stuff
benabik allison: git log --no-merges :-)
dukeleto allison: and mixing streams. I am just trying to explain why --no-ff is recommended. Telling users to use git pull --rebase instead of pulling is an orthogonal issue 21:57
allison dukeleto: at the end of the talk, after I talked about development models in general, they asked me for examples of projects that had improved from model changes, and examples of projects that had difficult areas in development models
dukeleto: since I was drawing from memory, I only had personal experience to give them 21:58
dukeleto allison: i understand if it was unintential, but I am just saying that my perception, as an outsider from that article, but as a parrot core dev, and the person who converted us to git, i got bad vibes when reading the end of that article
allison dukeleto: and, I do think that git, the way we're using it now, is hurting the project
dukeleto allison: that is very interesting, because i think many people would wholeheartedly disagree with you 21:59
allison dukeleto: but, speaking to an audience of kernel developers, I also wanted to be clear that it's not git itself which is the problem, it's just a tool
dukeleto: tools can be used in many different ways
dukeleto allison: i.e. we got over 100 pull requests during Google Code-In, and we have been regularly getting pull requests from people on github, which we never would have gotten if we were still on svn 22:00
allison: can you describe more, exactly, how our current git workflow is hurting the project?
allison: because the perception of core developers that commit just about every day is not the same perception that you have
allison dukeleto: frog in boiling water? 22:01
dukeleto: it's too complex, not well documented, not inviting to new contributors
dukeleto allison: that is a problem with Parrot, not Git.
allison dukeleto: true of both
dukeleto: the use of git is faster and easier to fix 22:02
benabik --no-ff can also help clean history... Can choose between --no-merges (see only code changes) and --first-parent (see timeline, with features as single commits)
dukeleto allison: i mostly translated our old merge document into our new git_workflow.pod, and changed svn-ish stuff to git stuff. I didn't wholeheartly change how parrot development happens
allison: so, from my perspective, all your issues are with the parrot workflow, and have very little to do with the parrot *git* workflow
allison dukeleto: and that's my point, we're using git like it's svn
dukeleto: I understand we wanted the change to be less traumatic 22:03
dukeleto: but, it sounds like we're already moving to a more pure git model (which I'm glad to hear)
dukeleto: the "official" way needs to shift with the workflow in practice 22:04
cotto_work We've been on git long enough that updating the process is sensible. The way we've been unoffically using pull requests can be seen as the start of that.
dukeleto nothing really happens "officially" in the parrot community. The way people do things changes, and after long enough, we document that is the "current practice"
allison dukeleto: ah, but that's exactly where newbies get lost 22:05
cotto_work For what it's worth, I'm reasonably sure that kid51's objections are addressed and that he's fine with using pull requests.
dukeleto i think we will want to document soon that pull requests are recommended for any merges, so parrot core devs can +1/-1 them/etc
benabik Does parrot-dev get notified re: pull requests?
NotFound I'd say even more, the more official and documented things are the most distant to reality.
dukeleto benabik: nope
NotFound: indeed
Also: www.treehugger.com/files/2011/09/es...nglish.php
allison NotFound: that's a problem. Deleting the docs is better than keeping them around when they're wrong. 22:06
benabik Actually, possibly more important than parrot-dev would be dalek...
dukeleto benabik: that would be reasonably easy
allison: i very much agree that we need to make parrot more accessible to newbies. For instance, the first page on our Trac wiki is pure garbage.
Also, I hate the trac wiki. 22:07
benabik dukeleto: (re: parrots) That's awesome... Walkting through the serene outdoors when suddenly you're surrounded by a bunch of vulgar parrots.
soh_cah_toa agreed
benabik trac--
soh_cah_toa it's just one long list
disgusting
cotto_work dukeleto: I'd have migrated it to github if there were a button to do so.
dukeleto at some point, we will want to seriously consider migrating to a github wiki.
cotto_work: of course :)
NotFound dukeleto: soon they'll be teaching wild birds how to use git. 22:08
cotto_work as it stands, I find myself ignoring it more frequently
allison soh_cah_toa: delete it! replace the page with a single paragraph! or a link to github! :)
benabik Biggest problem with trac wiki is knowing what's old and what's current...
allison don't be bound by the past, clear out the deadwood :) 22:09
dukeleto allison++
soh_cah_toa allison: i started a while ago, i'll have to see where i saved it
dukeleto trac is mostly filled with non-relevant garbage
and the vcs integration on trac doesn't even work anymore
soh_cah_toa "making parrot accessible to newbies" is a big place that we fail, imho
allison dukeleto: well, it might be time to nuke trac. But, I wouldn't look forward to another bug migration :( 22:10
cotto_work allison: that's the current pain point
benabik There are some scripts in the wild for importing TT into github. 22:12
soh_cah_toa syncwith.us/sd/
cotto_work Parrot on github will still have most of the same problems of Parrot on trac, and those are the hard ones.
dukeleto allison: just the trac wiki, i want to kill. the tickets are a different can of worms 22:13
cotto_work soh_cah_toa: nice find
benabik soh_cah_toa: verrrrry interesting
soh_cah_toa indeed
dukeleto Just to be clear: I just want to nuke the trac wiki for now, not the ticket system.
cotto_work I was expecting something expensive, not something I could install with aptitude.
dukeleto: I'd love to see that.
benabik dukeleto: Some of us dream big. ;-)
dukeleto benabik: i like the idea of converting all TTs -> gh issues, but I ain't volunteering for it ;) 22:14
benabik On the topic of user friendliness, trac tickets are _not_. Have to register, have to get permission for the accounts... And the ticket creation/edit page is just obtuse to people unfamiliar with Trac/RT/similar 22:15
allison cotto: bugs are a pain in every project. Look at Launchpad, if you want a real heart-attack.
cotto: the number of bug reports makes Parrot's tickets look like a picnic
benabik *new users 22:16
allison cotto: the funny thing is, I've noticed that it doesn't matter how many reports you get, or how many developers you have, it's always too many bug reports for that number of developers to handle.
cotto: Murphy's law, I guess.
Ubuntu is shifting from looking at bug reports on an individual basis, to data mining.
Where the high and critical bugs are treated as blockers for release, but it's accepted that the others just won't get attention. 22:17
And, bugs that are waiting on user feedback forever, just get expired, auto closed.
dukeleto Git goes the route of just not having a bugtracker. Just a mailing list. 22:18
soh_cah_toa wow
cotto_work allison: it'd be amazing to maintain a tiny list of open bugs, but I'm not holding by breath.
allison (You can search for expired bugs, but the volume is too high to ever get there.)
soh_cah_toa i kind of like that approach
benabik Git's approach works surprisingly well.
dukeleto benabik: surprisingly
allison dukeleto/benabik: I like that. 22:19
benabik I expected it to become less effective over time, but it really hasn't.
I think junio is a big part of that though.
allison I'm not entirely sure how it would work in practice, how you'd make sure to catch the really critical ones and get them into release.
But, it sounds appealing.
benabik The list o' important bugs is maintained by Junio, really. It can somewhat be seen in the "What's Cooking" messages. 22:20
Although it also has an active enough community that many bugs just have patches arrive within a day.
dukeleto Also note: Google employs two of the main git devs to work on Git fulltime. Parrot doesn't have anything like that. 22:22
Not to mention Github employing core git devs to mostly just work on Git.
benabik dukeleto: That too
dukeleto heads out 22:25
benabik I always find it odd that I connect to freenode for #perl6 and perl.org for #parrot...
soh_cah_toa oh god, don't go there ;)
benabik Every time I use a new client, I end up on #parrot on Freenode and #perl6 on perl
22:25 benabik_ joined
soh_cah_toa those really should be switched around 22:26
if we really are gonna be a vm for all languages, not just p6 22:27
but whatever
benabik soh_cah_toa: Getting people to move is just not worth the effort... Just amusing
soh_cah_toa yeah 22:30
22:36 dmalcolm_ joined 22:39 benabik joined, benabik_ joined 22:55 GeJ joined, eternaleye joined, AzureStone joined, perlite joined, particle1 joined, Hunger joined, bubaflub joined
NotFound I've found the most bizarre thing: video exercises of '80 style Basic using my Basic interpreter: www.youtube.com/watch?v=ry9OGm1i-0A 22:56
cotto_work NotFound: PIRRIC? 22:58
nice. I bet that's weird.
too bad it's not PIRRIC
NotFound No, an older, non parrot and more complete one. Blassic.
22:58 nbrown joined
cotto_work That first related video is *not* related. 22:59
that's all I'll say
NotFound Looks like it's some Malaysian school. 23:00
23:01 jsut joined 23:13 benabik joined
benabik Sorry for leaving abruptly, I wondered outside of WiFi range by accident and then my ride arrived… :-D Did I miss anything? 23:15
cotto_work not much 23:16
benabik woo 23:17
plobsing has the release been cut yet? 23:18
cotto_work soh_cah_toa: ^ 23:19
he said he'd let people know when he's ready 23:24
plobsing ok
cotto_work I remember the process taking ~3 hours, though I don't recall how far into that it became safe to push to master again.
plobsing just got home from $work and wondered if it was merge o'clock yet
benabik Step 1: Create a release branch. 23:25
plobsing benabik: my thoughts exactly
cotto_work That's quite sensible.
benabik Going back to my earlier brainstorming, we should perhaps create that branch some time before the release instead the day of to give it time to settle out and not block master. 23:26

Powered by Cro and the Raku® Programming Language.

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

Thank you!