Post closed tickets in your report. | Note: This channel is for our weekly status meetings (Tuesdays at 19:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/
Set by moderator on 6 September 2011.
08:17 lucian joined 13:40 bluescreen joined 15:39 bluescreen joined 16:50 nine joined 17:33 bluescreen joined 17:35 contingencyplan joined 18:49 whiteknight joined
whiteknight WHAT I DID: 18:51
* Random Rosella work.
* Adding a few more features to Jaesop.
* Working on a precise GC prototype. Not quite happy with it yet.
* Played around with the GC API, trying to cut out pointers. Got stuck and gave up for now
WHAT I WILL DO:
* Continue work on GC
EOR
Util Win32 notice: MinGW GCC 4.6.1 is now available via the TDM project at tdm-gcc.tdragon.net/ 19:01
# Done:
* Updated GCC to 4.6.1 on my Win32 box, but have not compiled Parrot yet.
# Plan to do:
* Nothing next week
# Blockers
* $WORK, travel 19:02
# 7-day ticket report:
2 new
.end
19:05 NotFound joined
NotFound What I did: 19:12
-parrot
* Fixed sleep
-winxed
* builtin sleep
* multi modifier, allowing int, float, string, var and class operator
for parameter types
* minor fixes
What I will do:
No plan
EOR
Coke too Distracted by $DAYJOB to hack on muddle for more than 2 minutes. back to it this week. EOR 19:22
19:32 Tene joined
cotto_work hello 19:32
whiteknight hello
NotFound Hola
cotto_work It's been pretty quiet, apart from some annoyances about nqp. 19:33
whiteknight which annoyances? 19:34
Util Hello
cotto_work nqp master breaks with parrot master
whiteknight oh, that's still an issue?
cotto_work yup
whiteknight I wasn't aware. I'll dig into that tonight
cotto_work no Rakudo release -> no nqp merge -> annoyance
NotFound The issue with vtable get_pointer default?
cotto_work whiteknight: it's a known thing that doesn't effect Rakudo 19:35
whiteknight still, it's not good to leave it broken
cotto_work nqp has a branch that fixes it
whiteknight oh, okay
cotto_work in the future we need to make more of an effort to provide a temporary backwards-compatibility shim 19:36
NotFound That is the expected consequence of the deprecation policy relaxing
whiteknight I'm not sure I agree with that. What would that even look like?
We either have that vtable or we don't. How to fake it without making the whole thing moot?
cotto_work whiteknight: simple. keep the old op around until nqp is updated
I don't think nqp cares about the vtable 19:37
NotFound The temporary solution is to revert the get_pointer change.
whiteknight that's counter-productive, especially if Rakudo isn't using this NQP
or, I mean if Rakudo doesn't care about the breakage
cotto_work a permanent solution is to give pmichaud some tuits
NotFound cotto_work: the vtable is the problem. The op doesn't work appropiately without it.
cotto_work might be tricky
whiteknight We have the NQP branch, and if that works, then the branch is the solution 19:38
cotto_work yes
whiteknight Rakudo needs one version of NQP, we need another. Hence, branches
cotto_work whee
whiteknight we could also fork NQP
so long as there was an expectation that the forks would stay close
NotFound The problem is that we can't backport the new op back in time into the parrot rakudo may want to use. 19:39
19:39 benabik joined
whiteknight we *could* make a single patch commit to the old release tag 19:39
that's what a "supported" release is
cotto_work I don't think it's necessary.
NotFound Too complicated, I'll prefer to revert the get_pointer change until transition period ends. 19:40
whiteknight I don't think anything is necessary 19:41
NotFound Fine for me. This is what the discusion about deprecation policy was about, after all.
whiteknight exactly. The only important factor is whether Rakudo is in pain or not, and if they aren't it's all good 19:42
cotto_work In the future we should handle this better. For now, what whiteknight said.
whiteknight yes, we can try, but keeping Rakudo happy means we can break things when Rakudo doesn't care, so long as things are fixed when Rakudo does care
NotFound cotto_work: handle it better --> deprecation policy --> pain 19:43
cotto_work NotFound: more like informal deprecation policy. Note the lack of a chainsaw.
NotFound Either we have a strict dep pol, or we don't
cotto_work "deprecation suggestions"
NotFound If os strict, that kind of things will happen. 19:44
s/os/not
cotto_work It's annoying but acceptable.
NotFound They also happened even with strict, after all ;) 19:45
benabik Could have a policy that Rakudo-breaking merges should be a pull request only merged by the community relations people (or whatever we called them).
Basically: Hey, Rakudo, we'd like to break this, let us know when it's safe.
19:45 bluescreen joined
whiteknight Yeah, I like that idea. Of course, right now we are in a period where we know it's safe, and we know when it won't be safe (after the release) 19:46
cotto_work benabik: that's a possibility. I'd like to minimize the amount of structure needed to make such changes while keeping Rakudo happy.
NotFound If I rememver well, pmichaud discussed the idea with plobsing and agreed with the breakage. 19:47
cotto_work Let's call it acceptable and move on. 19:48
whiteknight +1
NotFound +1
cotto_work Would anyone else like to raise a question? 19:49
whiteknight none from me, yet. I'm working on some GC stuff but it's not mature enough yet for feedback 19:50
I think this meeting doesn't have much steam left. Quits? 19:54
cotto_work sure
any goals for the week?
whiteknight none that I can think of. We don't have much up in the air right now
cotto_work Let's call it a wrap. 19:56
whiteknight okay!
benabik
.oO( A tuna wrap? )
 19:57
cotto_work It's a wrap.
Mmmm.
20:01 NotFound left 20:07 benabik left 20:12 japhb joined 20:38 nine left 21:19 bluescreen joined 21:47 bluescreen joined 22:21 wagle_ joined 22:57 bubaflub joined 23:55 whiteknight 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!