Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2009-05-19

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

All times shown according to UTC.

Time Nick Message
00:56 eternaleye joined #parrotsketch
06:15 masak joined #parrotsketch
11:20 kid51 joined #parrotsketch
11:49 kid51 Preposting, then off to $job
11:49 kid51 I would appreciate feedback on https://trac.parrot.org/parrot/ticket/677: how do we determine which files go into MANIFESTs?
11:49 kid51 Other TTs depend on this:  426, 434, 586
11:49 kid51 Would also welcome feedback on https://trac.parrot.org/parrot/ticket/440: what good is pbc_info?
11:50 kid51 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 kid51 EOR
12:40 Whiteknight joined #parrotsketch
14:35 Whiteknight_ joined #parrotsketch
15:35 masak preposting report -- will miss meeting this Tuesday.
15:35 masak * submitted 10 new rakudobugs.
15:35 masak * some nice progress on Web.pm and proto.
15:35 masak * submitted a Hague grant proposal for doing Rakudo work (impl of Set, Bag, Buf).
15:35 masak .eor
16:37 cotto joined #parrotsketch
16:41 pmichaud joined #parrotsketch
17:21 moritz joined #parrotsketch
17:54 Util joined #parrotsketch
18:05 davidfetter joined #parrotsketch
18:17 allison joined #parrotsketch
18:19 fperrad joined #parrotsketch
18:20 darbelo joined #parrotsketch
18:21 Whiteknight joined #parrotsketch
18:25 jonathan joined #parrotsketch
18:27 raig joined #parrotsketch
18:28 NotFound joined #parrotsketch
18:30 moritz oh hai!
18:30 NotFound hola
18:30 Whiteknight hello
18:30 fperrad hello
18:30 Util Hello
18:30 darbelo hi
18:31 jonathan ahojte
18:31 allison hi
18:31 moritz ENOCRHOMATIC
18:31 Whiteknight EITSSPELLEDCHROMATIC
18:32 Whiteknight :)
18:32 cotto ohai
18:32 allison then let's get started
18:33 allison alphabetical as usual
18:33 allison cotto?
18:33 cotto started implementing a PCT-based vtable.tbl parser, got distracted with rl
18:33 cotto eor
18:34 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.
18:34 darbelo .end
18:35 allison fperrad?
18:35 fperrad * build Parrot with llvm-gcc
18:35 fperrad .EOR
18:35 chromatic joined #parrotsketch
18:35 allison jonathan?
18:36 jonathan Parrot
18:36 jonathan * Improvements to .backtrace() method of Exception PMC so when an exception is thrown from C we can still get a backtrace.
18:36 jonathan * We can do what I did more neatly and in a way that's more generally useful once contexts are PMCs.
18:36 jonathan * Patch to make MultiSub something that you can hll_map
18:36 jonathan Rakudo
18:36 jonathan * Started using Exception.handler(), so now we show an error and a backtrace with HLL line number and file name
18:36 jonathan * 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.
18:36 jonathan * 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).
18:36 jonathan * On top of pmichaud++'s excellent operator overloading work, I added support for overriding existing postcircumfixes and caught methods up with routines
18:36 jonathan * Hacked on "parallel" dispatch operators
18:36 jonathan * 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.
18:36 jonathan .end
18:36 * pmichaud sneaks into the back of the room...er, channel.
18:36 * Tene is here.
18:36 chromatic hola patos
18:37 allison NotFound?
18:37 NotFound * Fixing pipes in io/unix.c
18:37 NotFound * Some cage cleaning and bug fixing
18:37 NotFound EOR
18:37 allison pmichaud?
18:38 pmichaud * NQP: Added Q:PIR construct (to match Rakudo)
18:38 pmichaud * HLLCompiler: Added a $?FILES variable so compilers can determine what file(s) are being compiled
18:38 pmichaud * Rakudo: Cleaned up utf8-ness of Rakudo's grammar and expressions
18:38 pmichaud * Rakudo: Changed stdin/out/err to default to utf8 encoding
18:38 pmichaud * Rakudo: Added limited forms of user-defined operators
18:38 pmichaud * Rakudo: Improved make() function slightly.
18:38 pmichaud * Rakudo: Added file annotations for smarter error messages
18:38 pmichaud * Rakudo: With Tene++, completed moving Rakudo into its own HLL space
18:38 pmichaud * Rakudo now passing 11,297 spectests (+110 since last week)
18:38 pmichaud q2q
18:38 pmichaud EOR
18:39 allison Tene?
18:39 Tene Rakudo in its own HLL
18:39 Tene HLL library loading for Rakudo and Cardinal
18:39 Tene kthxbai
18:39 allison Util?
18:39 Util * parrot_config - just spotted a problem and mentioned it in #parrot. Looks like t/ does not exercise it.
18:40 Util * pbc_to_exe win32 status: Changing to hundreds of memcpy - FAIL.
18:40 Util 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!
18:40 Util Still translating to PIR for actual final patch.
18:40 Util * Release:
18:40 Util 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.
18:40 Util .eor
18:41 allison Whiteknight?
18:41 Whiteknight * Worked on cleaning up the GC internals, better but more to do.
18:41 Whiteknight * (TT #670) Would like feedback for some GC API changes to support a new incremental GC I'm working on.
18:41 Whiteknight * Planning out the switch from Parrot_Context_t -> Context PMC, finding lots of use cases
18:41 Whiteknight * Looking into some bugs related to PIR subclassing built-in PMC types. Most problems look like probems with non-inherited ATTRS
18:41 Whiteknight * Testing for the release. All stations are go!
18:41 Whiteknight * Queue 3 questions
18:42 allison and, back round to the beginning of the alphabet for those missed the first time:
18:42 allison allison?
18:42 allison - Ticket review and closing, patch application.
18:42 allison - Submitted the article to Linux Magazine.
18:42 allison - 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.
18:42 allison EOR
18:42 allison chromatic?
18:43 chromatic Committed several optimizations.
18:43 chromatic Closed some tickets.
18:43 chromatic I have a few more optimizations to commit after release.
18:43 chromatic I also have what's almost a patch to allow the configuration system to get the release number for SVK users.
18:43 chromatic This should fix some problems with parrot_config that other Rakudo users may have noticed.
18:43 chromatic EOR
18:43 PacoLinux joined #parrotsketch
18:44 allison moritz?
18:44 moritz * Usual Rakudo and Perl 6 testing
18:44 moritz * Will be on vacations for the next ~3 weeks
18:44 moritz EOR
18:44 allison Did I miss anyone?
18:44 allison okay, questions. Whiteknight had 3
18:45 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
18:45 Whiteknight Okay, thanks.
18:45 allison (events are a kind of task)
18:46 Whiteknight Next question:
18:46 Whiteknight Stacks: (src/stacks.c) Are they to be deprecated and removed or not?
18:46 chromatic Yes please.
18:46 Whiteknight I think they are only used currently for storing opcode_t* addresses
18:46 allison there is one stack left
18:46 Whiteknight so we could easily replace it with an RIA
18:46 Whiteknight or something similar
18:46 allison what uses the stack to store opcode_t* addresses?
18:47 Whiteknight bsr and jsr opcodes, for instance
18:47 allison we should deprecate those
18:47 Whiteknight not many other things at all
18:47 * Whiteknight is fine with that solution too
18:47 Whiteknight so deprecate the whole damn mess?
18:47 allison yes
18:47 Whiteknight Okay, next question:
18:47 Whiteknight (TT #483) Is the ":invocant" flag still on the roadmap?
18:48 Whiteknight 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.
18:48 allison pmichaud: aye, we replaced it with the context-local array
18:48 pmichaud (I'm a little surprised bsr is still around, even.)
18:48 allison yes, :invocant is still desirable
18:48 Whiteknight Okay, EOQ
18:49 allison pmichaud: IIRC, some language was depending on it, possibly a lisp
18:49 allison pmichaud: but anything that's using it can use the context-local arrays instead
18:50 allison other questions?
18:50 pmichaud I had two.
18:50 allison go ahead
18:50 pmichaud er, still have two.  :-)
18:50 * moritz queues one comment
18:50 allison ah the beauty of temporal locatives :)
18:50 pmichaud First, why does the calling conventions refactor not (no longer) appear on the Parrot roadmap?
18:50 allison it was never on the roadmap
18:51 pmichaud my photos from PDS 2009 beg to differ.
18:51 pmichaud it was probably the second item I stuck on the wall.
18:51 pmichaud (er, PDS 2008)
18:51 allison hmmm... well, it's not on the list of things I deleted from the roadmap....
18:51 allison it is my primary task for 1.4
18:51 pmichaud it was supposed to have been done in the December 2008 timeframe.  But it seems to have disappeared entirely.
18:52 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.
18:52 jonathan Indeed.
18:52 chromatic There are two calling conventions refactorings.  One changes Parrot's internals to use less suck.  The other supports features Rakudo needs.
18:52 pmichaud chromatic: we're blocking on both.
18:52 Whiteknight pmichaud: What aspects does Rakudo need, so we can focus on those?
18:52 allison what does Rakudo need?
18:52 jonathan Rakudo could, in theory, not actually use get_params and roll its own thing.
18:52 Whiteknight maybe we need a concrete checklist to make that happen
18:52 jonathan I will do that if Parrot blocks us too much longer.
18:52 jonathan But it's not the road I'd like to go down.
18:52 pmichaud we need to know what the new system is going to look like so we can start building to it.
18:53 pmichaud 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
18:53 Whiteknight that's the pcc_rewiring branch, right?
18:53 allison it passes a CallSignature PMC around, instead of mucking about with va_args
18:53 moritz (one of the high level features that rakudo needs is passing arguments to positional parameters by name, fwiw)
18:53 allison yes, pcc_rewiring
18:54 Whiteknight passing a positional by name?
18:54 pmichaud do we have an eta on that landing?
18:54 allison that already works
18:54 Whiteknight like 0 => $foo?
18:54 allison I mean, pynie is passing named arguments to positionals now
18:54 pmichaud whiteknight:    sub foo($a) { say $a };    foo(a => 3);
18:54 jonathan Whiteknight: Like sub foo($a) { }; foo(:a(42))
18:54 moritz allison: by name?
18:54 Whiteknight oh, are these the "lookahead" arguments we've talked about before?
18:54 allison by name, yes
18:54 pmichaud Whiteknight: yes.
18:54 jonathan Yes.
18:55 Whiteknight okay, /me is with the program then
18:55 pmichaud I think what pynie is doing is not what rakudo is asking for.
18:55 pmichaud I think pynie allows named parameters to be filled using positional arguments.
18:55 allison yes
18:55 pmichaud Rakudo needs positional parameters to be filled using named arguments.
18:55 Whiteknight There's a lot of cc-related monkeying to do, I'll make sure that gets added to the top of the list
18:55 allison pynie does both
18:56 jonathan allison: Using trunk?
18:56 allison that is, python treats all parameters as positional/named
18:56 jonathan What does the .param line look like for a parameter that can be passed positionally but filled by a named?
18:57 * allison thinking through the current parameter filling algorithm...
18:57 pmichaud remember, this is why we came up with :lookahead last summer
18:57 pmichaud it's one reason why I put "calling conventions refactor" on the roadmap at PDS
18:57 jonathan sub foo($a, $b, $c) { }; foo(1, 3, :b(2));
18:58 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...
18:58 allison it doesn't have an implementation of lookahead
18:58 allison was the lookahead flag already added to IMCC?
18:58 pmichaud not as far as I know.
18:58 Whiteknight allison: I don't think so no
18:58 Whiteknight I added a stub of it in src/call/pcc.c, but no guts
18:59 pmichaud does the new code have a notion of "named-only" parameters?
18:59 pmichaud because Rakudo also needs that.
18:59 jonathan sub foo(:$a) { }; foo(1); # this is an error
18:59 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?
18:59 Whiteknight pmichaud: Doesn't :named do that?
18:59 allison or, should it check named arguments first and fall back to positional arguments?
19:00 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.
19:00 Whiteknight ah, okay. So we need something like :namedonly
19:00 pmichaud this was all fleshed out on the mailing list last summer.
19:00 jonathan allison: So if there is, it takes the named and the next psotional argument can be used by the next positional parameter.
19:00 allison pmichaud: yes, but that was a long time ago :)
19:00 allison I can add lookahead to the pcc_rewiring branch
19:01 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!
19:01 allison it's easier to add it there than the current code
19:01 allison pmichaud: aye, I'm just asking to make sure I've got the details straight before I implement it
19:01 allison no point in implementing it backwards
19:02 allison are there other things Rakudo needs?
19:02 moritz speed.
19:02 pmichaud whiteknight: http://groups.google.com/group/perl.perl6.internals/msg/96417ed37799cd37
19:02 jonathan Indeed.
19:02 allison yes, pynie too :)
19:03 jonathan allison: Also - and I think with your refactor this one becomes easy - PIR overrides of vtable invoke would be cool.
19:03 jonathan allison: As in, ones that pass along the invocant.
19:03 Whiteknight jonathan: PIR overriding invoke has been on my radar for a while
19:03 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?
19:03 Whiteknight that much will definitely get done
19:03 jonathan But it sounds like now that is just going to be unshifting self onto the CallSignature.
19:03 NotFound Overriding invoke will be a big +
19:04 allison I don't know that this refactor will help there
19:04 allison it will make it easier to get to the arguments
19:04 allison but, setting up the opcode_t* return is still problematic
19:04 allison I guess we can make it act like NCI
19:04 jonathan allison: I'd always seen it as acting like an NCI
19:05 allison (where it just returns the "next op" that was passed in to it)
19:05 NotFound That means entering a new runloop?
19:05 jonathan allison: The problem has more been that you don't get self.
19:05 allison NotFound: no, continuing the same runloop
19:05 pmichaud more like "the self that you get isn't the self you're looking for"
19:05 chromatic Hm, if only we had some way in PIR of referring to specific nodes in the call graph in a first-class way.
19:05 allison you still won't get self, at least not the self you're expecting
19:06 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?
19:07 jonathan 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
19:07 allison if you invoke it as a sub, you'll get no invocant
19:07 jonathan I think you're missing my point.
19:07 pmichaud my $P0 = new 'Foo';   $P0()
19:08 jonathan $P0(a, b, c) # sets up the args and invokes $P0
19:08 allison aye, no invocant
19:08 jonathan In my PIR override for invoke, I currently get a, b and c
19:08 allison yup
19:08 jonathan But have no way of getting at $P0
19:08 allison yes, $P0 is not self
19:08 jonathan It's completely useless without having $P0.
19:08 allison because it's not a method invocation
19:09 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.
19:09 pmichaud allison: we're saying we need a way to get at the $P0 that had the vtable_invoke performed on it.
19:09 pmichaud it doesn't have to be 'self'.  But we need the $P0.
19:09 Whiteknight we manually force the invocant onto the front of the CallSignature so it's available from the PIR override
19:09 allison agreed
19:09 allison agreed that we need access to it
19:09 NotFound Otherwise I see no point in allowing to override it
19:09 jonathan But when you override any other vtable method, you *always* get the SELF aliased to self
19:10 jonathan 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"
19:10 allison jonathan: those are invoked along a completely separate path
19:11 Whiteknight Ah TT #103. That's the ticket for this issue
19:11 jonathan allison: Which is, I believe, part of the problem.
19:11 allison if you insert the object as self, what happens when you override invoke in an object that acts as a method call?
19:11 allison it still needs access to the invocant of the method call
19:11 jonathan That just gets shuffled along a positoin.
19:11 jonathan *position
19:11 allison so you can't force that invocant to be something else
19:12 jonathan I was thinking more that you just unshift it onto the start of the argument list.
19:12 allison better to be consistent
19:12 jonathan There's more than one way to be consistent. ;-)
19:12 allison like, always store the sub object in the CallSignature
19:12 jonathan Anyway, I don't mind much which way we do it.
19:12 allison it's a useful introspection feature anyway
19:13 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.
19:13 allison jonathan: yes, agreed
19:13 NotFound We don't have the current sub in the context?
19:14 allison it is in the context
19:14 allison but, not accessible from PIR
19:14 allison The CallSignature will be accessible from PIR
19:15 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
19:15 Whiteknight so don't forget that route
19:15 Whiteknight oh, true
19:15 allison but, that's not *this* refactor
19:16 allison scrolling back, does this answer the original question?
19:17 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:18 allison no, calling conventions should be on the roadmap for 1.4
19:18 chromatic *which* calling conventions?
19:18 allison I postponed other roadmap items specifically so I could work on it
19:18 allison chromatic: the one I'm working on now
19:19 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 pmichaud Because I thought the things that were being worked on last fall/winter would do it, but that didn't happen.
19:19 allison pmichaud: IIRC, this is a second pass calling conventions refactor
19:19 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.
19:20 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
19:20 pmichaud it would not be nice for something to go into 1.4 that Rakudo has to workaround for six months.
19:21 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 allison right now I'm in the phase of digging through the failures
19:21 Whiteknight you need help with that? Have debugger, will travel
19:21 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.
19:22 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.
19:22 allison it's not ready for an HLL target anyway
19:22 allison when you muck about with the core calling conventions, every minor problem is a catastrophic fail
19:23 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
19:23 Whiteknight deal
19:23 pmichaud (or make commits in a separate branch, perhaps?)
19:23 allison pmichaud: yes, probably
19:24 allison 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)
19:25 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?
19:25 allison maybe 'critical' plus the language name?
19:26 allison oh, IIRC, we removed the language tag
19:26 pmichaud where would that go?
19:26 allison how about 'critical' plus component: 'language'
19:27 allison then say which language in the ticket
19:27 Util language tag is still there
19:27 allison ah, it is
19:27 Util Priority=High|Critical, Language=Perl6, and set up a custom report?
19:27 allison yes
19:28 allison 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.
19:28 * moritz unqueues his question
19:28 NotFound Write a good description, then ;)
19:28 allison that's how we used to use the language tag, but now language-specific tickets go to separate queues
19:28 pmichaud but we can start that way and revise if it doesn't work out.
19:29 allison (which is why I was planning to delete the language tag)
19:29 allison so, this is a sensible use of the language tag
19:29 pmichaud NotFound: a description is useful only if someone actually clicks deep enough to see it.
19:29 Util Rakudo bugs (proper) go to RT, not Trac, so does that not remove he confusion, pmichaud?
19:29 allison we can triage the tickets and kick the ones that are language-specific over to the right queue
19:30 allison 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.
19:30 pmichaud using the language tag will be fine.
19:30 pmichaud 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.
19:31 chromatic As long as everyone on #ps knows our custom, I think we'll be fine.
19:31 pmichaud agreed.
19:31 pmichaud and yes, I may see about creating a custom report for it.
19:31 allison yes, that would be very useful
19:31 allison did you have a second question?
19:32 pmichaud third question :-)
19:32 allison third question, go ahead
19:32 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.
19:33 pmichaud 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?
19:33 pmichaud (fortunately it's easy for us to switch Rakudo between running in the 'perl6' and 'parrot' namespaces at the moment, to get comparisons)
19:33 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?"
19:34 allison :)
19:34 pmichaud I'm guessing I'll have numbers for comparison in about 5-10 minutes.
19:34 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
19:34 chromatic Anyone on a decent Unix should be able to install Valgrind and kcachegrind and play along.
19:34 NotFound I think that profiling now can be a waste of time, better wait for calling conventions.
19:34 pmichaud we can go on to other questions/tasks and I'll report numbers back here when I have them.
19:34 chromatic If you have a good benchmark and an easy way to switch, we can take a look.
19:35 chromatic 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.
19:36 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.
19:36 chromatic Three seconds is probably tops.
19:36 NotFound chromatic: yes, but it may be more difficult to identify and fix now
19:37 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.
19:37 allison NotFound: at least, what Valgrind and kcachegrind will help us discover is the C level
19:38 allison 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.
19:38 pmichaud jonathan: I think we may need to hold hll_map until we resolve this, then.
19:38 pmichaud otherwise we may not have a good way to locate the bottleneck.
19:38 jonathan pmichaud: Sure we do - just don't grab latest Rakudo.
19:39 pmichaud okay, or that.  :-)
19:39 jonathan :-)
19:39 pmichaud hll_map isn't going into the release, correct?
19:39 jonathan pmichaud: Unlikely I'll have the branch ready for then.
19:39 jonathan pmichaud: And I'm inclined even if I do to wait.
19:39 jonathan (Was before this conversation anyways...)
19:39 pmichaud okay, so we can always point to the release version as a test.
19:40 jonathan *nod*
19:40 pmichaud that's all the questions from me.  I'll summarize to list.
19:40 allison did moritz have a question?
19:40 pmichaud oh, I have the numbers now.
19:41 pmichaud Rakudo spectest in 'parrot' HLL:  33 minutes
19:41 pmichaud Rakudo spectest in 'perl6' HLL:  50 minutes
19:41 allison that's awful
19:41 moritz allison: not anymore
19:41 pmichaud so, a 50% performance penalty.
19:41 allison something amok in our namespace access code, perhaps
19:41 allison moritz: okay
19:42 allison Other questions?
19:42 allison Roadmap review: https://trac.parrot.org/parrot/report/14
19:42 jonathan pmichaud: Wow! I hadn't realized it was *that* different.
19:43 allison two roadmap items, both related to HLL testing
19:44 allison any feedback from hll interop testing?
19:44 Whiteknight i didn't even have a chance this week
19:45 allison Tene had some good suggestions on the cross-language library loading
19:45 allison (which apparently doesn't work as currently implemented)
19:46 allison (or at least, doesn't handle Rakudo)
19:46 allison I think we'll have to call this one missed
19:46 jonathan allison: Did you also see Tene's post where he was importing/calling code between Ruby and Perl 6?
19:46 moritz http://blogs.gurulabs.com/stephen/2009/05/cross-language-library-loading.html
19:46 pmichaud afaik, Tene's stuff now works with Rakudo.
19:47 allison jonathan: no, didn't see it yet
19:48 allison 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.
19:48 pmichaud 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.
19:49 allison there's a load of code in namespace that was supposed to support this feature
19:50 allison 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.
19:50 chromatic Removing code from the NameSpace PMC is a very good thing.
19:50 allison I agree that's cleaner
19:51 allison 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
19:51 allison (that is, each HLL has a namespace)
19:51 allison sounds good
19:51 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
19:51 allison does someone want to volunteer to review namespace and make the appropriate deprecation notices?
19:52 Whiteknight I will if it's low priority
19:52 allison well, the deprecation notices need to get in before 1.4
19:52 Whiteknight i've got other stuff coming up in the next few weeks
19:53 Whiteknight yeah, that's plenty of time. Put my name down
19:53 allison okay, great
19:53 Whiteknight Or i'll put my own name down. Oprah calls that "empowerment"
19:53 allison huh
19:54 allison Any other comments, questions, suggestions before we wrap up?
19:54 pmichaud eta to release?
19:54 allison has anyone heard from tewk?
19:55 pmichaud not me, but I haven't been watching closely.
19:55 allison we didn't have any of the usual "early warning" messages
19:55 allison do we have an absentee release manager?
19:56 allison okay, no ETA at the moment, but if he's not around one of us will pick it up
19:57 allison (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.
19:57 Util FYI, I am working on the custom report for high-pro Perl6 tickets in Trac.
19:57 fperrad Lua is not in the list of languages for Trac ticket.
19:57 fperrad Who could append it ?
19:58 allison Util can you make it multiple languages, grouped by language?
19:58 allison fperrad: I can
19:58 allison will do it now
19:58 Util allison: Yes, will do.
19:59 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)
20:00 allison pmichaud: excellent, thanks
20:00 allison adjourning to #parrot
20:00 pmichaud left #parrotsketch
20:02 chromatic left #parrotsketch
20:02 fperrad left #parrotsketch
20:02 Util left #parrotsketch
20:02 moritz left #parrotsketch
20:02 NotFound left #parrotsketch
20:03 jonathan left #parrotsketch
20:05 darbelo left #parrotsketch
20:16 cotto joined #parrotsketch
20:26 PacoLinux left #parrotsketch
20:26 raig left #parrotsketch
21:31 Whiteknight joined #parrotsketch
21:41 kid51 joined #parrotsketch
21:46 kid51 left #parrotsketch
22:04 contingencyplan joined #parrotsketch

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