Camelia, the Perl 6 bug

IRC log for #parrot, 2011-09-20

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:13 dalek rakudo/nom: 0d73bac | Coke++ | t/spectest.data:
00:13 dalek rakudo/nom: run fudged test
00:13 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/0d73bacf0e
00:32 soh_cah_toa joined #parrot
00:35 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 #parrot
01:16 jkitazawa joined #parrot
01:18 dalek rakudo/nom: cbdd9b0 | Coke++ | t/spectest.data:
01:18 dalek rakudo/nom: run fudged test.
01:18 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/cbdd9b07d6
01:20 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:21 cotto_work +1
01:21 soh_cah_toa plobsing: ha! i know. i do that all the time :)
01:21 plobsing for the record, I meant 3.*8* release in the email I just sent to parrot-dev
01:22 woosley joined #parrot
01:27 soh_cah_toa alright, i now have all necessary access to ftp-osl.osuosl.org and parrot.org
01:27 soh_cah_toa 'fulltest' passes on my fedora and openbsd machines w/ all combinations of gcc/g++/clang so we're looking good for tomorrow
01:27 soh_cah_toa 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 #parrot
01:34 ttbot joined #parrot
02:00 dalek parrot/hints_more_verbose: b6bf3d3 | jkeenan++ | config/init/hints/ (2 files):
02:00 dalek parrot/hints_more_verbose: FreeBSD and OpenBSD: make hints display better when verbose output has been selected (along same lines as Darwin and Linux).
02:00 dalek parrot/hints_more_verbose: review: https://github.com/parrot/parrot/commit/b6bf3d3273
02:02 cotto ~~
02:20 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:28 nopaste "soh_cah_toa" at 192.168.1.3 pasted "Test Failures While Smoking OpenSolaris" (13 lines) at http://nopaste.snit.ch/81852
02:33 nopaste "soh_cah_toa" at 192.168.1.3 pasted "Verbose Output for Test Failures on OpenSolaris" (39 lines) at http://nopaste.snit.ch/81853
02:35 soh_cah_toa unfortunately, i'm not familiar w/ those tests (or dynoplibs, for that matter) so there's not much i can do
03:05 cotto joined #parrot
04:09 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
04:20 dalek parrot: ba4bd62 | petdance++ | src/call/context.c:
04:20 dalek parrot: Don't try to return a function that returns void
04:20 dalek parrot: review: https://github.com/parrot/parrot/commit/ba4bd62fd6
04:26 Coke no slushie?
04:27 soh_cah_toa ???
04:29 cotto soh_cah_toa, code slush (like a freeze but not quite)
04:30 soh_cah_toa petdance said he didn't know about the freeze
04:31 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
04:32 cotto wfm
04:34 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 soh_cah_toa a whole lot
04:34 soh_cah_toa most of them are 'see TT #1234, it's not done yet'
05:41 rfw joined #parrot
06:11 JimmyZ joined #parrot
06:23 zby_home joined #parrot
07:04 JimmyZ joined #parrot
07:06 mj41 joined #parrot
07:37 cotto phpunit--
07:38 cotto it wouldn't be so bad if they called it a code-running framework instead of a test framework
07:46 schmooster joined #parrot
08:42 SHODAN joined #parrot
10:06 he_ joined #parrot
10:40 lateau joined #parrot
11:36 Psyche^ joined #parrot
11:39 benabik joined #parrot
12:03 mtk joined #parrot
12:11 whiteknight joined #parrot
12:12 whiteknight good morning, #parrot
12:12 moritz good morning whiteknight
12:15 tadzik good morning
12:15 whiteknight hello moritz, tadzik. How are you two doing today?
12:15 benabik o/
12:15 tadzik suprisingly good :)
12:16 benabik morning, whiteknight moritz tadzik
12:19 bluescreen joined #parrot
12:29 Coke who manages rakudo.org?
12:29 tadzik pmichaud I think
12:29 atrodo =~
12:29 tadzik ~=
12:29 Coke whoops, wrong window.
12:29 redicaps joined #parrot
12:34 benabik We're all talkative this morning.  :-D
13:01 benabik joined #parrot
13:43 mls hi whiteknight!
13:44 whiteknight hello mls
13:44 mls so, no subprof in this week's parrot release?
13:47 bluescreen joined #parrot
13:49 whiteknight no, there's a code freeze on master. We'll merge it in right after the release
13:50 mls k, sounds good.
13:54 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:55 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 #parrot
14:04 jsut_ joined #parrot
14:17 redicaps left #parrot
14:55 lateau joined #parrot
15:00 dmalcolm joined #parrot
15:40 Patterner can I break crypt()?
15:41 Patterner "Parrot now compatible to PHP 5.3.7."
15:42 benabik Break how?
16:18 Patterner return only the salt or something like that...
16:23 JimmyZ joined #parrot
16:25 benabik …  I don't see a crypt function in parrot.
16:26 JimmyZ_ joined #parrot
16:32 cosimo joined #parrot
16:36 bluescreen joined #parrot
16:37 Coke I think he was making a joke about php, not offering to patch parrot for reals.
16:37 contingencyplan joined #parrot
16:38 benabik Oh.  u.u
16:42 fperrad joined #parrot
16:54 fperrad joined #parrot
16:59 dalek rakudo/nom: 7552eb9 | jnthn++ | src/pmc/perl6lexpad.pmc:
16:59 dalek rakudo/nom: Remove now unrequired calls to steal_outer (mls++).
17:00 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/7552eb9424
17:10 mj41 joined #parrot
17:16 zby_home joined #parrot
17:28 cotto_work ~~
17:28 dalek rakudo/nom: 7fdc6b4 | jnthn++ | src/binder/container.c:
17:28 dalek rakudo/nom: Apply patch from mls++ to harden container storage.
17:28 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/7fdc6b455b
17:37 benabik joined #parrot
18:10 dalek rakudo/nom: 79344e0 | jnthn++ | src/pmc/perl6lexpad.pmc:
18:10 dalek rakudo/nom: Try to eliminate a bunch of C compiler warnings tadzik++ is seeing.
18:10 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/79344e05a2
19:15 dalek rakudo/nom: 091c262 | jnthn++ | src/ (2 files):
19:15 dalek rakudo/nom: 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 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/091c2627c1
19:25 cotto_work #ps in 5
19:25 dukeleto http://blog.llvm.org/2011/09/greedy-​register-allocation-in-llvm-30.html
19:30 cotto_work Heh.  I didn't mention that link because I figure you'd already done so.
19:45 benabik joined #parrot
19:55 whiteknight joined #parrot
20:04 jsut joined #parrot
20:09 jsut_ joined #parrot
20:29 soh_cah_toa joined #parrot
20:38 cotto_work soh_cah_toa: ping
20:38 soh_cah_toa cotto_work: pong
20:38 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.
20:38 soh_cah_toa yup
21:03 Coke missed the meeting. Yes, allison did not, as i recall, like git.
21:18 allison Coke: curiously, I actually like git now
21:18 allison Coke: but I still hate our branching technique
21:19 allison Coke: it's like we brought all the pain of subversion into git
21:20 allison cotto: to answer the question from the meeting, simplify it
21:20 allison cotto: and stop using --rebase
21:20 allison cotto: --rebase is supposed to be rare
21:20 allison (any git developer will tell you that)
21:21 benabik I tend to use pull --rebase a lot, but only to maintain really simple patches on master, not for branches.
21:21 benabik (Example: I have a patch to todo a select.t test)
21:23 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 Coke benabik++ I mean.
21:23 benabik During GSoC, I also used rebase -i to clean up commits.
21:23 allison cotto: I suspect --no-ff is part of our mess too
21:23 benabik But suggesting rebase to new users is probably not completely wise...
21:24 benabik (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
21:24 allison cotto: including working primarily by cherry picking, and having one person do the final integration
21:25 allison cotto: it doesn't have to be the architect, that'd just lead to burn out
21:25 allison cotto: but, the release manager for the month could also be the patch meister
21:25 Coke so we have a single user bottleneck instead of a single branch bottleneck? what's the advantage?
21:25 allison a rotating bottleneck
21:25 Coke quality control?
21:25 allison yup
21:25 Coke HA
21:26 Coke mmhehe.
21:26 allison and sanity of the repo
21:26 Coke ok. Before we fix the workflow to address quality control, we need to address our quality. ;)
21:26 allison remember, linus doesn't review every patch, but several people in tree as patches filter up to him do
21:26 allison Coke: chicken and egg problem
21:27 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?
21:27 Coke the toolchain isn't going to give it to us.
21:27 allison Coke: quality control is the best way to improve quality
21:27 allison that's what the toolchain was designed for
21:27 benabik The toolchain was designed to be flexible.  There's not really one true git model.
21:28 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.
21:28 Coke *interested
21:28 perlite_ joined #parrot
21:28 Coke *care from a practical standpoint.
21:30 allison Coke: I suppose it's a conversion of sorts
21:30 allison Coke: but on the whole, I think it's better to wholeheartedly embrace change if we're going to make it
21:31 allison Coke: in the long-run, it's less painful than straddling the fence
21:32 Coke Having living through change for change's sake in our toolchain in the past, I hope it's actually a beneficial change.
21:36 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:37 allison 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.
21:38 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
21:38 benabik (directly to master)
21:39 allison having multiple people all merging directly to the "release branch" does cause trouble
21:39 allison linux has a "linux-next" branch where multiple people integrate
21:40 allison then linus's branch, where he pulls from linux-next, and cuts the final release
21:42 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:43 benabik (Or could narrow window to a week or two if we don't want master to diverge far from release)
21:45 benabik our core can integrate in master as they see fit.  If we're doing well, release can just merge master straight in.
21:45 benabik 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)
21:46 dukeleto ~~
21:46 cotto_work and back
21:46 allison I'd go with that, except would replace the simple fixes with cherry picking, instead of direct commit.
21:47 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.
21:47 allison i.e. developers all have their own private parrot git repo
21:48 benabik The biggest advantage with our namespaced branches is dalek...  Everyone can see how everyone's working.
21:49 allison dalek could track other repos too
21:49 cotto_work It'd need to be manually set up, but it's possible.
21:50 benabik I don't think where the branches live matters very much.
21:50 allison benabik: it's a workflow thing
21:51 allison benabik: using personal branches and pull requests, rather than merges
21:51 allison benabik: where anyone can service anyone else's pull request
21:51 benabik Ah.  code review.
21:51 allison benabik: (but not their own)
21:51 dukeleto allison: that is pretty much what we do now
21:51 benabik "Someone else thinks merging this is a good idea"
21:52 benabik 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?
21:52 dukeleto allison: in practice
21:53 dukeleto allison: for example: https://github.com/parrot/parrot/pull/163
21:53 allison dukeleto: you mean for non-committers?
21:53 allison dukeleto: how about for committers?
21:54 dukeleto allison: also, --no-ff always leaves a record that a merged happened, which I prefer (as well as many other projects)
21:54 dukeleto allison: new current practice is for anybody, core committer or not, to submit a pull request for review
21:54 allison dukeleto: it's not documented
21:54 dukeleto allison: patches welcome
21:54 dalek winxed: 533961d | NotFound++ | winxedst1.winxed:
21:54 dalek winxed: 'multi' modifier for functions, without arguments for a now
21:54 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/533961d0d1
21:55 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...
21:55 dukeleto benabik: damnit
21:55 allison dukeleto: you may personally prefer --no-ff, but it makes for a messy commit history
21:55 allison dukeleto: it certainly wasn't intended as such, it wasn't part of the planned talk at all
21:55 dukeleto allison: your opinion, i guess. I think it leaves a trail of merges, which is quite helpful.
21:56 dukeleto 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)
21:56 dukeleto allison: no, i think you are misunderstanding stuff
21:56 benabik allison: git log --no-merges  :-)
21:57 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
21:58 allison 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
21:58 allison dukeleto: and, I do think that git, the way we're using it now, is hurting the project
21:59 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
21:59 allison dukeleto: tools can be used in many different ways
22:00 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 dukeleto allison: can you describe more, exactly, how our current git workflow is hurting the project?
22:00 dukeleto allison: because the perception of core developers that commit just about every day is not the same perception that you have
22:01 allison dukeleto: frog in boiling water?
22:01 allison dukeleto: it's too complex, not well documented, not inviting to new contributors
22:01 dukeleto allison: that is a problem with Parrot, not Git.
22:01 allison dukeleto: true of both
22:02 allison 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)
22:02 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
22:02 dukeleto allison: so, from my perspective, all your issues are with the parrot workflow, and have very little to do with the parrot *git* workflow
22:02 allison dukeleto: and that's my point, we're using git like it's svn
22:03 allison dukeleto: I understand we wanted the change to be less traumatic
22:03 allison dukeleto: but, it sounds like we're already moving to a more pure git model (which I'm glad to hear)
22:04 allison 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.
22:04 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"
22:05 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.
22:05 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
22:05 benabik Does parrot-dev get notified re: pull requests?
22:05 NotFound I'd say even more, the more official and documented things are the most distant to reality.
22:05 dukeleto benabik: nope
22:05 dukeleto NotFound: indeed
22:05 dukeleto Also: http://www.treehugger.com/files/20​11/09/escaped-pet-birds-are-teachi​ng-wild-birds-to-speak-english.php
22:06 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...
22:06 dukeleto benabik: that would be reasonably easy
22:06 dukeleto 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.
22:07 dukeleto 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.
22:07 soh_cah_toa agreed
22:07 benabik trac--
22:07 soh_cah_toa it's just one long list
22:07 soh_cah_toa disgusting
22:07 cotto_work dukeleto: I'd have migrated it to github if there were a button to do so.
22:07 dukeleto at some point, we will want to seriously consider migrating to a github wiki.
22:07 dukeleto cotto_work: of course :)
22:08 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
22:08 allison soh_cah_toa: delete it! replace the page with a single paragraph! or a link to github! :)
22:08 benabik Biggest problem with trac wiki is knowing what's old and what's current...
22:09 allison don't be bound by the past, clear out the deadwood :)
22:09 dukeleto allison++
22:09 soh_cah_toa allison: i started a while ago, i'll have to see where i saved it
22:09 dukeleto trac is mostly filled with non-relevant garbage
22:09 dukeleto and the vcs integration on trac doesn't even work anymore
22:09 soh_cah_toa "making parrot accessible to newbies" is a big place that we fail, imho
22:10 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
22:12 benabik There are some scripts in the wild for importing TT into github.
22:12 soh_cah_toa http://syncwith.us/sd/
22:12 cotto_work Parrot on github will still have most of the same problems of Parrot on trac, and those are the hard ones.
22:13 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
22:13 benabik soh_cah_toa: verrrrry interesting
22:13 soh_cah_toa indeed
22:13 dukeleto Just to be clear: I just want to nuke the trac wiki for now, not the ticket system.
22:13 cotto_work I was expecting something expensive, not something I could install with aptitude.
22:13 cotto_work dukeleto: I'd love to see that.
22:13 benabik dukeleto: Some of us dream big.  ;-)
22:14 dukeleto benabik: i like the idea of converting all TTs -> gh issues, but I ain't volunteering for it ;)
22:15 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.
22:15 allison cotto: the number of bug reports makes Parrot's tickets look like a picnic
22:16 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.
22:16 allison cotto: Murphy's law, I guess.
22:16 allison Ubuntu is shifting from looking at bug reports on an individual basis, to data mining.
22:17 allison 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 allison And, bugs that are waiting on user feedback forever, just get expired, auto closed.
22:18 dukeleto Git goes the route of just not having a bugtracker. Just a mailing list.
22:18 soh_cah_toa wow
22:18 cotto_work allison: it'd be amazing to maintain a tiny list of open bugs, but I'm not holding by breath.
22:18 allison (You can search for expired bugs, but the volume is too high to ever get there.)
22:18 soh_cah_toa i kind of like that approach
22:18 benabik Git's approach works surprisingly well.
22:18 dukeleto benabik: surprisingly
22:19 allison dukeleto/benabik: I like that.
22:19 benabik I expected it to become less effective over time, but it really hasn't.
22:19 benabik I think junio is a big part of that though.
22:19 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.
22:19 allison But, it sounds appealing.
22:20 benabik The list o' important bugs is maintained by Junio, really.  It can somewhat be seen in the "What's Cooking" messages.
22:20 benabik Although it also has an active enough community that many bugs just have patches arrive within a day.
22:22 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 dukeleto Not to mention Github employing core git devs to mostly just work on Git.
22:22 benabik dukeleto: That too
22:25 * dukeleto heads out
22:25 benabik I always find it odd that I connect to freenode for #perl6 and perl.org for #parrot...
22:25 soh_cah_toa oh god, don't go there ;)
22:25 benabik Every time I use a new client, I end up on #parrot on Freenode and #perl6 on perl
22:25 benabik_ joined #parrot
22:26 soh_cah_toa those really should be switched around
22:27 soh_cah_toa if we really are gonna be a vm for all languages, not just p6
22:27 soh_cah_toa but whatever
22:27 benabik soh_cah_toa: Getting people to move is just not worth the effort... Just amusing
22:30 soh_cah_toa yeah
22:36 dmalcolm_ joined #parrot
22:39 benabik joined #parrot
22:39 benabik_ joined #parrot
22:55 GeJ joined #parrot
22:55 eternaleye joined #parrot
22:55 AzureStone joined #parrot
22:55 perlite joined #parrot
22:55 particle1 joined #parrot
22:55 Hunger joined #parrot
22:55 bubaflub joined #parrot
22:56 NotFound I've found the most bizarre thing: video exercises of '80 style Basic using my Basic interpreter: http://www.youtube.com/watch?v=ry9OGm1i-0A
22:58 cotto_work NotFound: PIRRIC?
22:58 cotto_work nice.  I bet that's weird.
22:58 cotto_work too bad it's not PIRRIC
22:58 NotFound No, an older, non parrot and more complete one. Blassic.
22:58 nbrown joined #parrot
22:59 cotto_work That first related video is *not* related.
22:59 cotto_work that's all I'll say
23:00 NotFound Looks like it's some Malaysian school.
23:01 jsut joined #parrot
23:13 benabik joined #parrot
23:15 benabik Sorry for leaving abruptly, I wondered outside of WiFi range by accident and then my ride arrived…  :-D  Did I miss anything?
23:16 cotto_work not much
23:17 benabik woo
23:18 plobsing has the release been cut yet?
23:19 cotto_work soh_cah_toa: ^
23:24 cotto_work he said he'd let people know when he's ready
23:24 plobsing ok
23:24 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.
23:24 * plobsing just got home from $work and wondered if it was merge o'clock yet
23:25 benabik Step 1: Create a release branch.
23:25 plobsing benabik: my thoughts exactly
23:25 cotto_work That's quite sensible.
23:26 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.

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced