Parrotsketch Every Tuesday @ 18:30 UTC | IRC Log at irclog.perlgeek.de/parrotsketch/today
Set by moderator on 26 April 2009.
00:56 eternaleye joined 06:15 masak joined 11:20 kid51 joined
kid51 Preposting, then off to $job 11:49
I would appreciate feedback on trac.parrot.org/parrot/ticket/677: how do we determine which files go into MANIFESTs?
Other TTs depend on this: 426, 434, 586
Would also welcome feedback on trac.parrot.org/parrot/ticket/440: what good is pbc_info?
Also, people have been asking me what format/schedule of Parrot Workshop pre-YAPC will be? Who is it aimed at? How much hacking? How much presentations? 11:50
EOR
12:40 Whiteknight joined 14:35 Whiteknight_ joined
masak preposting report -- will miss meeting this Tuesday. 15:35
* submitted 10 new rakudobugs.
* some nice progress on Web.pm and proto.
* submitted a Hague grant proposal for doing Rakudo work (impl of Set, Bag, Buf).
.eor
16:37 cotto joined 16:41 pmichaud joined 17:21 moritz joined 17:54 Util joined 18:05 davidfetter joined 18:17 allison joined 18:19 fperrad joined 18:20 darbelo joined 18:21 Whiteknight joined 18:25 jonathan joined 18:27 raig joined 18:28 NotFound joined
moritz oh hai! 18:30
NotFound hola
Whiteknight hello
fperrad hello
Util Hello
darbelo hi
jonathan ahojte 18:31
allison hi
moritz ENOCRHOMATIC
Whiteknight EITSSPELLEDCHROMATIC
:) 18:32
cotto ohai
allison then let's get started
alphabetical as usual 18:33
cotto?
cotto started implementing a PCT-based vtable.tbl parser, got distracted with rl
eor
allison darbelo? 18:34
darbelo .report :GSoC * Made pmc2c explode. And then learned how to avoid that. * 'Finished' both prototypes. * Played with both. Decided on global-context as the way to go. * Reworked the examples, again. * Started with testing infrastructure. * Something's hosed on OpenBSD wrt tests.
.end
allison fperrad? 18:35
fperrad * build Parrot with llvm-gcc
.EOR
18:35 chromatic joined
allison jonathan? 18:35
jonathan Parrot 18:36
* Improvements to .backtrace() method of Exception PMC so when an exception is thrown from C we can still get a backtrace.
* We can do what I did more neatly and in a way that's more generally useful once contexts are PMCs.
* Patch to make MultiSub something that you can hll_map
Rakudo
* Started using Exception.handler(), so now we show an error and a backtrace with HLL line number and file name
* Started a branch to hll_map MultiSub to Perl6MultiSub. Will need a bit of effort but worth it, and will win us a bit at startup.
* Wrote and checked in some Rakudo micro-benchmarks to get a sense of how we're doing on some of the stuff we do a lot of (method calls, sub calls, multi dispatches, etc).
* On top of pmichaud++'s excellent operator overloading work, I added support for overriding existing postcircumfixes and caught methods up with routines
* Hacked on "parallel" dispatch operators
* Spent some hours trying to track down a problem in the stage 1 compile that makes it hang when trying to add Temporal.pm by mberends++ to the setting....not much clue what it is yet.
.end
pmichaud sneaks into the back of the room...er, channel.
Tene is here.
chromatic hola patos
allison NotFound? 18:37
NotFound * Fixing pipes in io/unix.c
* Some cage cleaning and bug fixing
EOR
allison pmichaud?
pmichaud * NQP: Added Q:PIR construct (to match Rakudo) 18:38
* HLLCompiler: Added a $?FILES variable so compilers can determine what file(s) are being compiled
* Rakudo: Cleaned up utf8-ness of Rakudo's grammar and expressions
* Rakudo: Changed stdin/out/err to default to utf8 encoding
* Rakudo: Added limited forms of user-defined operators
* Rakudo: Improved make() function slightly.
* Rakudo: Added file annotations for smarter error messages
* Rakudo: With Tene++, completed moving Rakudo into its own HLL space
* Rakudo now passing 11,297 spectests (+110 since last week)
q2q
EOR
allison Tene? 18:39
Tene Rakudo in its own HLL
HLL library loading for Rakudo and Cardinal
kthxbai
allison Util?
Util * parrot_config - just spotted a problem and mentioned it in #parrot. Looks like t/ does not exercise it.
* pbc_to_exe win32 status: Changing to hundreds of memcpy - FAIL. 18:40
However, as others mentioned on IRC, linking the PBC into the EXE as a "resource" is the MS-approved way to do this. I have researched the requirements (create .rc file referencing .pbc, compile .rc to .res with `RC`, and include the RC compiler, and add the .res file to the `LINK` commandline), and it works great!
Still translating to PIR for actual final patch.
* Release:
Just in case it is needed pre-release, I just wrote a safer (i.e. does not break Win32) version of the my pbc_to_exe patch that fixes the issue for GCC specifically, and leaves the code path for every other compiler (like MSVC) alone, but my Rakudo tests are failing due to the parrot_config issue.
.eor
allison Whiteknight? 18:41
Whiteknight * Worked on cleaning up the GC internals, better but more to do.
* (TT #670) Would like feedback for some GC API changes to support a new incremental GC I'm working on.
* Planning out the switch from Parrot_Context_t -> Context PMC, finding lots of use cases
* Looking into some bugs related to PIR subclassing built-in PMC types. Most problems look like probems with non-inherited ATTRS
* Testing for the release. All stations are go!
* Queue 3 questions
allison and, back round to the beginning of the alphabet for those missed the first time: 18:42
allison?
- Ticket review and closing, patch application.
- Submitted the article to Linux Magazine.
- Merged the PASM chapter of the book into the PIR chapter. Finished the structural edits in the PIR chapter, half-way through the text pass.
EOR
chromatic?
chromatic Committed several optimizations. 18:43
Closed some tickets.
I have a few more optimizations to commit after release.
I also have what's almost a patch to allow the configuration system to get the release number for SVK users.
This should fix some problems with parrot_config that other Rakudo users may have noticed.
EOR
18:43 PacoLinux joined
allison moritz? 18:44
moritz * Usual Rakudo and Perl 6 testing
* Will be on vacations for the next ~3 weeks
EOR
allison Did I miss anyone?
okay, questions. Whiteknight had 3
Whiteknight (TT #635) The Event PMC is mentioned in the PDDs, but has no implementation. Is this incoming or outgoing? 18:45
allison it got merged into the Task PMC
Whiteknight Okay, thanks.
allison (events are a kind of task)
Whiteknight Next question: 18:46
Stacks: (src/stacks.c) Are they to be deprecated and removed or not?
chromatic Yes please.
Whiteknight I think they are only used currently for storing opcode_t* addresses
allison there is one stack left
Whiteknight so we could easily replace it with an RIA
or something similar
allison what uses the stack to store opcode_t* addresses?
Whiteknight bsr and jsr opcodes, for instance 18:47
allison we should deprecate those
Whiteknight not many other things at all
Whiteknight is fine with that solution too
so deprecate the whole damn mess?
allison yes
Whiteknight Okay, next question:
(TT #483) Is the ":invocant" flag still on the roadmap?
I've gotten a few questions about that recently 18:48
pmichaud I know that last summer we went through and removed all occurrences of bsr in PGE and related libs.
allison pmichaud: aye, we replaced it with the context-local array
pmichaud (I'm a little surprised bsr is still around, even.)
allison yes, :invocant is still desirable
Whiteknight Okay, EOQ
allison pmichaud: IIRC, some language was depending on it, possibly a lisp 18:49
pmichaud: but anything that's using it can use the context-local arrays instead
other questions? 18:50
pmichaud I had two.
allison go ahead
pmichaud er, still have two. :-)
moritz queues one comment
allison ah the beauty of temporal locatives :)
pmichaud First, why does the calling conventions refactor not (no longer) appear on the Parrot roadmap?
allison it was never on the roadmap
pmichaud my photos from PDS 2009 beg to differ. 18:51
it was probably the second item I stuck on the wall.
(er, PDS 2008)
allison hmmm... well, it's not on the list of things I deleted from the roadmap....
it is my primary task for 1.4
pmichaud it was supposed to have been done in the December 2008 timeframe. But it seems to have disappeared entirely.
Whiteknight in either case, the refactors are still happening 18:52
pmichaud More to the point, Rakudo is rapidly getting to the point where we're blocking on them.
jonathan Indeed.
chromatic There are two calling conventions refactorings. One changes Parrot's internals to use less suck. The other supports features Rakudo needs.
pmichaud chromatic: we're blocking on both.
Whiteknight pmichaud: What aspects does Rakudo need, so we can focus on those?
allison what does Rakudo need?
jonathan Rakudo could, in theory, not actually use get_params and roll its own thing.
Whiteknight maybe we need a concrete checklist to make that happen
jonathan I will do that if Parrot blocks us too much longer.
But it's not the road I'd like to go down.
pmichaud we need to know what the new system is going to look like so we can start building to it.
otherwise... what jonathan++ said. 18:53
allison the new system is in a branch, so you can get an idea of how it will work
Whiteknight that's the pcc_rewiring branch, right?
allison it passes a CallSignature PMC around, instead of mucking about with va_args
moritz (one of the high level features that rakudo needs is passing arguments to positional parameters by name, fwiw)
allison yes, pcc_rewiring
Whiteknight passing a positional by name? 18:54
pmichaud do we have an eta on that landing?
allison that already works
Whiteknight like 0 => $foo?
allison I mean, pynie is passing named arguments to positionals now
pmichaud whiteknight: sub foo($a) { say $a }; foo(a => 3);
jonathan Whiteknight: Like sub foo($a) { }; foo(:a(42))
moritz allison: by name?
Whiteknight oh, are these the "lookahead" arguments we've talked about before?
allison by name, yes
pmichaud Whiteknight: yes.
jonathan Yes.
Whiteknight okay, /me is with the program then 18:55
pmichaud I think what pynie is doing is not what rakudo is asking for.
I think pynie allows named parameters to be filled using positional arguments.
allison yes
pmichaud Rakudo needs positional parameters to be filled using named arguments.
Whiteknight There's a lot of cc-related monkeying to do, I'll make sure that gets added to the top of the list
allison pynie does both
jonathan allison: Using trunk? 18:56
allison that is, python treats all parameters as positional/named
jonathan What does the .param line look like for a parameter that can be passed positionally but filled by a named?
allison thinking through the current parameter filling algorithm... 18:57
pmichaud remember, this is why we came up with :lookahead last summer
it's one reason why I put "calling conventions refactor" on the roadmap at PDS
jonathan sub foo($a, $b, $c) { }; foo(1, 3, :b(2));
allison so, the new code only scans positional arguments to fill positional parameters, and named/positional to fill named parameters 18:58
jonathan This would bind 1 to $a, 2 to $b, 3 to $c...
allison it doesn't have an implementation of lookahead
was the lookahead flag already added to IMCC?
pmichaud not as far as I know.
Whiteknight allison: I don't think so no
I added a stub of it in src/call/pcc.c, but no guts
pmichaud does the new code have a notion of "named-only" parameters? 18:59
because Rakudo also needs that.
jonathan sub foo(:$a) { }; foo(1); # this is an error
allison and, the behavior of lookahead should be to act like a positional parameter, but check the named arguments if a corresponding positional argument isn't found?
Whiteknight pmichaud: Doesn't :named do that?
allison or, should it check named arguments first and fall back to positional arguments?
jonathan allison: Not quite. It should before filling the slot with a positional check if there's a matching named. 19:00
pmichaud Whiteknight: no. :named currently fills from named or positionals.
Whiteknight ah, okay. So we need something like :namedonly
pmichaud this was all fleshed out on the mailing list last summer.
jonathan allison: So if there is, it takes the named and the next psotional argument can be used by the next positional parameter.
allison pmichaud: yes, but that was a long time ago :)
I can add lookahead to the pcc_rewiring branch
pmichaud allison: I'm simply saying we shouldn't have to re-design what we already designed. :) 19:01
Whiteknight free karma to the first person who digs up a link!
allison it's easier to add it there than the current code
pmichaud: aye, I'm just asking to make sure I've got the details straight before I implement it
no point in implementing it backwards
are there other things Rakudo needs? 19:02
moritz speed.
pmichaud whiteknight: groups.google.com/group/perl.perl6....d37799cd37
jonathan Indeed.
allison yes, pynie too :)
jonathan allison: Also - and I think with your refactor this one becomes easy - PIR overrides of vtable invoke would be cool. 19:03
allison: As in, ones that pass along the invocant.
Whiteknight jonathan: PIR overriding invoke has been on my radar for a while
pmichaud while we're here, can we somehow get calling conventions back onto the roadmap, since it was originally intended to be there from PDS?
Whiteknight that much will definitely get done
jonathan But it sounds like now that is just going to be unshifting self onto the CallSignature.
NotFound Overriding invoke will be a big +
allison I don't know that this refactor will help there 19:04
it will make it easier to get to the arguments
but, setting up the opcode_t* return is still problematic
I guess we can make it act like NCI
jonathan allison: I'd always seen it as acting like an NCI
allison (where it just returns the "next op" that was passed in to it) 19:05
NotFound That means entering a new runloop?
jonathan allison: The problem has more been that you don't get self.
allison NotFound: no, continuing the same runloop
pmichaud more like "the self that you get isn't the self you're looking for"
chromatic Hm, if only we had some way in PIR of referring to specific nodes in the call graph in a first-class way.
allison you still won't get self, at least not the self you're expecting
NotFound Then isn't useful at all 19:06
jonathan allison: We want self to be the SELF that you'd have inside the vtable method, right?
allison: At the moment, it's like overriding a method but not having the invocant. 19:07
allison if you invoke a PIR sub as a method, you'll get the invocant you passed in
if you invoke it as a sub, you'll get no invocant
jonathan I think you're missing my point.
pmichaud my $P0 = new 'Foo'; $P0()
jonathan $P0(a, b, c) # sets up the args and invokes $P0 19:08
allison aye, no invocant
jonathan In my PIR override for invoke, I currently get a, b and c
allison yup
jonathan But have no way of getting at $P0
allison yes, $P0 is not self
jonathan It's completely useless without having $P0.
allison because it's not a method invocation
Whiteknight We could make a special case of this in object.pmc:invoke 19:09
jonathan OK, if you want to make it inconsistent with every other vtable method, fine...we just need a way to get at $P0.
pmichaud allison: we're saying we need a way to get at the $P0 that had the vtable_invoke performed on it.
it doesn't have to be 'self'. But we need the $P0.
Whiteknight we manually force the invocant onto the front of the CallSignature so it's available from the PIR override
allison agreed
agreed that we need access to it
NotFound Otherwise I see no point in allowing to override it
jonathan But when you override any other vtable method, you *always* get the SELF aliased to self
e.g. .sub '' :vtable('elements') # gets self set 19:10
Whiteknight another option would be splitting the "self" keyword into "self_obj" and "self_sub"
allison jonathan: those are invoked along a completely separate path
Whiteknight Ah TT #103. That's the ticket for this issue 19:11
jonathan allison: Which is, I believe, part of the problem.
allison if you insert the object as self, what happens when you override invoke in an object that acts as a method call?
it still needs access to the invocant of the method call
jonathan That just gets shuffled along a positoin.
*position
allison so you can't force that invocant to be something else
jonathan I was thinking more that you just unshift it onto the start of the argument list. 19:12
allison better to be consistent
jonathan There's more than one way to be consistent. ;-)
allison like, always store the sub object in the CallSignature
jonathan Anyway, I don't mind much which way we do it.
allison it's a useful introspection feature anyway
Whiteknight I like that idea, keeping the current invocant and the current sub object in the CallSignature 19:13
jonathan We just need some way to be able to do $P0() on some $P0 that overrides vtable invoke and get at whatever was in $P0.
allison jonathan: yes, agreed
NotFound We don't have the current sub in the context?
allison it is in the context 19:14
but, not accessible from PIR
The CallSignature will be accessible from PIR
Whiteknight once Contexts are PMCs, they might be accessible from PIR too 19:15
allison long-term refactor will merge the context and the call signature anyway
Whiteknight so don't forget that route
oh, true
allison but, that's not *this* refactor
scrolling back, does this answer the original question? 19:16
pmichaud it helps, but my question remains: can we get calling conventions back on the roadmap? or is this another of those "too specific to a language to deserve being on the roadmap" items? 19:17
allison no, calling conventions should be on the roadmap for 1.4 19:18
chromatic *which* calling conventions?
allison I postponed other roadmap items specifically so I could work on it
chromatic: the one I'm working on now
pmichaud I guess my question would be, is the one you're working on now going to solve the things that are blocking rakudo? 19:19
Because I thought the things that were being worked on last fall/winter would do it, but that didn't happen.
allison pmichaud: IIRC, this is a second pass calling conventions refactor
pmichaud I'm guessing that if CallSignature PMCs are in place then that's sufficient for us to implement whatever we need on top of it, even if Parrot doesn't support it natively.
allison pmichaud: yes, if we give you direct access to the call signature, it should be sufficient 19:20
pmichaud but it would be nice for us to have a few weeks to work on it before the 1.4 release
it would not be nice for something to go into 1.4 that Rakudo has to workaround for six months.
allison I think the best thing is to finish debugging the revamp before I add :lookahead, :namedonly, and :callsig (or whatever we call it) 19:21
right now I'm in the phase of digging through the failures
Whiteknight you need help with that? Have debugger, will travel
pmichaud we can start looking at the branch code also, but it's a little difficult for us to develop a HLL to a branch.
allison the annoying tail stage, the same as every major refactor 19:22
chromatic Yes, please merge the revamp to trunk before adding new features.
allison it's not ready for an HLL target anyway
when you muck about with the core calling conventions, every minor problem is a catastrophic fail
pmichaud having the revamp merged to trunk would help unblock rakudo a fair bit, I think (hope) 19:23
allison Whiteknight: you're welcome to do debugging, but please don't make any commits
Whiteknight deal
pmichaud (or make commits in a separate branch, perhaps?)
allison pmichaud: yes, probably
pmichaud: (patches, mainly because I'm working with a large set of interrelated changes) 19:24
pmichaud anyway, next question (I now have a third question)
allison pmichaud: at least, having it merged into trunk will help once we shake out the kinks. It will likely be a setback at first. Hopefully only a small one. 19:25
pmichaud What's the proper way for us to tag trac tickets as being "high priority for rakudo (or some other hll)"? If there's not a standard method yet, can we quickly devise one?
allison maybe 'critical' plus the language name?
oh, IIRC, we removed the language tag 19:26
pmichaud where would that go?
allison how about 'critical' plus component: 'language'
then say which language in the ticket 19:27
Util language tag is still there
allison ah, it is
Util Priority=High|Critical, Language=Perl6, and set up a custom report?
allison yes
grouped by language, if possible 19:28
pmichaud I'm fine with that... except I'm concerned that some people might think that the "language" field means the bug is specific to the language and not to parrot.
moritz unqueues his question
NotFound Write a good description, then ;)
allison that's how we used to use the language tag, but now language-specific tickets go to separate queues
pmichaud but we can start that way and revise if it doesn't work out.
allison (which is why I was planning to delete the language tag) 19:29
so, this is a sensible use of the language tag
pmichaud NotFound: a description is useful only if someone actually clicks deep enough to see it.
Util Rakudo bugs (proper) go to RT, not Trac, so does that not remove he confusion, pmichaud?
allison we can triage the tickets and kick the ones that are language-specific over to the right queue
so far, people have been getting it right 19:30
pmichaud Util: I'm not the one that would be confused. I just know that from time to time people ask "what tickets are important for rakudo" and we haven't had a good way to produce that report.
using the language tag will be fine.
but I also know that some might look at a ticket summary (in a report), see "language = perl6" and assume that it's a perl6-specific issue.
chromatic As long as everyone on #ps knows our custom, I think we'll be fine. 19:31
pmichaud agreed.
and yes, I may see about creating a custom report for it.
allison yes, that would be very useful
did you have a second question?
pmichaud third question :-) 19:32
allison third question, go ahead
pmichaud This past week we moved Rakudo into its own HLL. Doing so seems to have significantly slowed down its runtime execution. I hoped to have actual numbers in time for #ps, but it turns out I haven't been able to complete my spectest runs in time for that.
Anyone have any ideas why there would be a significant slowdown? Or should I just post this to parrot-dev for discussion there? 19:33
allison nothing immediately comes to mind, maybe we can get chromatic to do some profiling?
pmichaud (fortunately it's easy for us to switch Rakudo between running in the 'perl6' and 'parrot' namespaces at the moment, to get comparisons)
chromatic Someone needs to profile it. By someone I mean "Why didn't I write my profiling guidelines the other day, so someone besides me could do it?"
allison :) 19:34
pmichaud I'm guessing I'll have numbers for comparison in about 5-10 minutes.
allison it likely can be pinned down to one or two routines that haven't been optimized because they haven't been heavily used so far
chromatic Anyone on a decent Unix should be able to install Valgrind and kcachegrind and play along.
NotFound I think that profiling now can be a waste of time, better wait for calling conventions.
pmichaud we can go on to other questions/tasks and I'll report numbers back here when I have them.
chromatic If you have a good benchmark and an easy way to switch, we can take a look.
NotFound, it's unlikely that calling conventions will help this sufficiently. Bottlenecks will still be bottlenecks. 19:35
pmichaud switching is easy. benchmark I'm using is a spectest run, which is by far the place where it hurts us the most right now.
chromatic That's way too big to profile. If you have a program which runs in a second or so but shows the perturbations, that's a better benchmark. 19:36
pmichaud Tene++ has noticed it in smaller benchmarks as well.
chromatic Three seconds is probably tops.
NotFound chromatic: yes, but it may be more difficult to identify and fix now
allison NotFound: I suspect the problem is down in the C level 19:37
pmichaud it should be almost the same PIR code in either case, since all that we do is change 'parrot' to 'perl6' in a few constants.
allison NotFound: at least, what Valgrind and kcachegrind will help us discover is the C level
NotFound: so, not much clash with the calling conventions 19:38
jonathan pmichaud: Once we have a Rakudo that depends on hll_map this will get trickier.
pmichaud jonathan: I think we may need to hold hll_map until we resolve this, then.
otherwise we may not have a good way to locate the bottleneck.
jonathan pmichaud: Sure we do - just don't grab latest Rakudo.
pmichaud okay, or that. :-) 19:39
jonathan :-)
pmichaud hll_map isn't going into the release, correct?
jonathan pmichaud: Unlikely I'll have the branch ready for then.
pmichaud: And I'm inclined even if I do to wait.
(Was before this conversation anyways...)
pmichaud okay, so we can always point to the release version as a test.
jonathan *nod* 19:40
pmichaud that's all the questions from me. I'll summarize to list.
allison did moritz have a question?
pmichaud oh, I have the numbers now.
Rakudo spectest in 'parrot' HLL: 33 minutes 19:41
Rakudo spectest in 'perl6' HLL: 50 minutes
allison that's awful
moritz allison: not anymore
pmichaud so, a 50% performance penalty.
allison something amok in our namespace access code, perhaps
moritz: okay
Other questions? 19:42
Roadmap review: trac.parrot.org/parrot/report/14
jonathan pmichaud: Wow! I hadn't realized it was *that* different.
allison two roadmap items, both related to HLL testing 19:43
any feedback from hll interop testing? 19:44
Whiteknight i didn't even have a chance this week
allison Tene had some good suggestions on the cross-language library loading 19:45
(which apparently doesn't work as currently implemented)
(or at least, doesn't handle Rakudo) 19:46
I think we'll have to call this one missed
jonathan allison: Did you also see Tene's post where he was importing/calling code between Ruby and Perl 6?
moritz blogs.gurulabs.com/stephen/2009/05/...ading.html
pmichaud afaik, Tene's stuff now works with Rakudo.
allison jonathan: no, didn't see it yet 19:47
but, yes, that looks like it follows in the conversation we had 19:48
pmichaud Yes, Tene and I discussed the hll interop yesterday and he implemented it.
We still need to document it and provide some support in HLLCompiler, but I think we're in agreement on the basics of the design.
allison there's a load of code in namespace that was supposed to support this feature 19:49
so, it needs to be updated, or removed 19:50
pmichaud I think it's better if the compiler objects handle it, instead of namespaces.
chromatic Removing code from the NameSpace PMC is a very good thing.
allison I agree that's cleaner
and, it moves us closer to treating HLLs as orthogonal to the namespace tree 19:51
pmichaud so, let's remove it from the namespaces, and I'll work with Tene++ and others on documenting it in HLLCompiler
allison (that is, each HLL has a namespace)
sounds good
pmichaud you can decide how best to reflect that in the status. At any rate, I think we should have it completed by 1.3
allison does someone want to volunteer to review namespace and make the appropriate deprecation notices?
Whiteknight I will if it's low priority 19:52
allison well, the deprecation notices need to get in before 1.4
Whiteknight i've got other stuff coming up in the next few weeks
yeah, that's plenty of time. Put my name down 19:53
allison okay, great
Whiteknight Or i'll put my own name down. Oprah calls that "empowerment"
allison huh
Any other comments, questions, suggestions before we wrap up? 19:54
pmichaud eta to release?
allison has anyone heard from tewk?
pmichaud not me, but I haven't been watching closely. 19:55
allison we didn't have any of the usual "early warning" messages
do we have an absentee release manager?
okay, no ETA at the moment, but if he's not around one of us will pick it up 19:56
(the advantage of multiple release managers) 19:57
cotto I've been looking for him the past couple days and haven't seen anything from him.
Util FYI, I am working on the custom report for high-pro Perl6 tickets in Trac.
fperrad Lua is not in the list of languages for Trac ticket.
Who could append it ?
allison Util can you make it multiple languages, grouped by language? 19:58
fperrad: I can
will do it now
Util allison: Yes, will do.
pmichaud just for the record -- we've tested Rakudo with recent parrots and it looks okay for release (modulo the "parrot_config" bug that has gotten some press today, which might be a release blocker) 19:59
allison pmichaud: excellent, thanks 20:00
adjourning to #parrot
20:00 pmichaud left 20:02 chromatic left, fperrad left, Util left, moritz left, NotFound left 20:03 jonathan left 20:05 darbelo left 20:16 cotto joined 20:26 PacoLinux left, raig left 21:31 Whiteknight joined 21:41 kid51 joined 21:46 kid51 left 22:04 contingencyplan 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!