Camelia, the Perl 6 bug

IRC log for #parrot, 2010-03-09

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:01 dalek parrot: r44781 | allison++ | branches/pcc_hackathon_6Mar10 (2 files):
00:01 dalek parrot: [pcc] Removed two deprecated and unused functions for setting return arguments
00:01 dalek parrot: in the old-style PCC.
00:01 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44781/
00:01 allison chromatic: oooh, no that's bad
00:02 allison chromatic: it's setting it to null right after fetching the *arguments*, which means it's gone once you get to the return
00:02 chromatic Yep.
00:03 allison a throw-back to a bygone era where calls and returns were different
00:03 chromatic It looked suspicious.
00:03 allison and worked when we were doing the funny pointer saving trick
00:04 chromatic Removing it gives different errors.  Are they better errors?
00:04 Whiteknight different is always better
00:05 allison we probably need to add code to null out the signature in get_results and equivalent
00:05 allison now that those are the final step of the call sequence
00:07 tetragon joined #parrot
00:08 lucian Austin: padre on os x is quite bad
00:08 Austin lucian: Really?
00:08 Austin Is it a gui thing, or is there more?
00:08 lucian Austin: they do say it's experimental
00:08 Whiteknight I havent used padre in a while. probably time to upgrade
00:09 lucian Austin: quite a few GUI things are broken
00:09 lucian the text rendering isn't very good, but that's a known wx bug
00:09 Austin whiteknight: I took a look a few weeks back, and decided it wasn't time yet -- still no multi-window support.
00:09 Whiteknight what I care about most is C syntax highlighting
00:10 lucian heh, the font chooser dialog appears for 0.1sec and then dissapears
00:10 Austin C?
00:10 purl C is for cookie, and it's good enough for you. or chromatic
00:10 dalek rakudo: 3cc313f | jonathan++ | src/Perl6/Module/Locator.pm:
00:10 dalek rakudo: Include alternative versions of modules in the candidate list too.
00:10 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​cc313f8688d20c3cd088d8918a822927746e553
00:10 dalek rakudo: 8b2fb24 | jonathan++ | build/PARROT_REVISION:
00:10 dalek rakudo: Bump PARROT_REVISION to get readdir that works on Win32.
00:10 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​b2fb24120a5d8990e26b1d9a8a6b8b08ee9bf06
00:10 dalek rakudo: aa8c65e | jonathan++ |  (5 files):
00:10 dalek rakudo: Identify version and authority properly for each module in the candidate list. Choosing latest if multiple versions are found now appears to work (though requesting specific version/authority is NYI).
00:10 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​a8c65ed6b9d0b23ba6904b2745f998a83b36c6f
00:10 Austin Geez, dude. What kind of luser still codes in C? Haven't you heard of dynamic languages?
00:10 lucian padre is a bit too young for me, i'll stick to vim
00:11 Whiteknight how do I tell cpan to "yes, always install prerequisites"?
00:11 Austin --dwiw ?
00:11 lucian Austin: editra is mostly the python counterpart to padre
00:12 allison chromatic: did you check in the removal of the stray sig nullification?
00:12 Coke Whiteknight: o conf mumble de mumble
00:12 Coke o conf prerequisites_policy follow
00:12 Coke (while in CPAN shell)
00:16 * Coke tries padre on os x; certainly easier to install than the windows version. =-)
00:17 Coke er, sorry, than the cpan version.
00:18 Whiteknight padre failed mak on my system
00:18 Whiteknight so that answers my question
00:18 chromatic allison, I didn't.  Should I?
00:19 GeJ Good morning everyone
00:19 Maddingu1 joined #parrot
00:20 Coke hurm. no build troubles for rakudo on osx.
00:24 allison chromatic: it's the right fix, so go ahead
00:24 allison chromatic: whatever error comes after we'll tackle next
00:24 chromatic kablammo
00:28 Whiteknight how do I get the GTK+ development files?
00:28 chromatic too many positional arguments: 2 passed, 1 expected
00:28 chromatic current instr.: 'parrot;P6metaclass;register' pc 576 (runtime/parrot/library/P6object.pir:425)
00:29 chromatic Does the CallSignature need reset somehow?
00:33 chromatic ... that'd be morph.
00:34 dalek parrot: r44782 | chromatic++ | branches/pcc_hackathon_6Mar10/​lib/Parrot/Pmc2c/PCCMETHOD.pm:
00:34 dalek parrot: [lib] Removed CallSignature NULLing at the start of PCCMETHODs, as reusing the
00:34 dalek parrot: CallSignature is important for returning values.
00:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44782/
00:34 dalek parrot: r44783 | allison++ | branches/pcc_hackathon_6Mar10/src/call/args.c:
00:34 dalek parrot: [pcc] Remove unused static function to set a default return value (returns now
00:34 dalek parrot: use the same code path as args).
00:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44783/
00:36 allison chromatic: the morph happens in Parrot_pcc_build_call_*
00:37 * Coke wonders if everyone that is working on rakudo has a quad core machine with 16G of memory.
00:37 allison chromatic: but the morph should only happen between call and return
00:37 chromatic Parrot_pcc_build_call_from_varargs seems to do it.
00:37 allison chromatic: between separate calls, the call_sig should be nulled
00:38 allison chromatic: aye
00:38 chromatic Looks like that morph is happening anyway.
00:39 allison the morph will happen anytime an active call sig is passed into Parrot_pcc_build_call_*
00:39 allison it's safe to reuse the same call sig pmc between calls
00:39 allison but the spec says different call sigs
00:39 dalek tracwiki: v24 | allison++ | CallingConventionsTasklist
00:39 dalek tracwiki: http://trac.parrot.org/parrot/wiki/CallingCo​nventionsTasklist?version=24&action=diff
00:40 allison hmmm... looks to me like the call sig isn't getting nulled between calls
00:41 chromatic Maybe morph is missing something.
00:46 allison chromatic: morph only nulls the signature elements, nothing else
00:46 allison chromatic: because between call and return that's all that changes
00:49 allison chromatic: the set_args op ignores the current value of the current call sig, just creates a new one and stuffs it into place
00:49 allison so, that's okay
00:49 allison some other call path might not be doing the same
00:52 chromatic num_positionals is 2.
00:53 allison chromatic: aye, and I'm sure if you look into it, the first one will be from a previous call or return
00:53 allison with the expected arg for the current call pushed on after the old arg
00:54 allison we could get around all this if we didn't recycle callcontexts for return signatures
00:54 allison but, I'd rather avoid thrashing the GC with double the number of PMCs for every call
00:55 chromatic Wild thought.
00:55 chromatic Pushing the invocant at the start?
00:56 dalek tracwiki: v25 | allison++ | CallingConventionsTasklist
00:56 dalek tracwiki: http://trac.parrot.org/parrot/wiki/CallingCo​nventionsTasklist?version=25&action=diff
00:56 allison chromatic: okay, Parrot_pcc_build_sig_object_from_varargs doesn't do the morph trick, is anything still calling that?
00:57 allison one call in src/call/pcc.c
00:57 allison from Parrot_PCCINVOKE
00:58 chromatic Here's your problem.
00:58 allison and a couple of calls to that from src/pmc/role.c
00:59 allison yah?
00:59 purl yah is at a point of agreement almost
00:59 chromatic Returning from a method means you don't unshift the invocant.
00:59 * Whiteknight hates the cpan client. It's always painful
01:00 allison chromatic: ?
01:01 allison chromatic: the invocant should be stored as one of the regular args, and so nulled out when the rest of the sig storage is nulled
01:01 allison chromatic: that is, interp->current_object is nulled as soon as the sig is created, so it's not around later
01:01 nopaste "chromatic" at 173.50.130.127 pasted "-t" (30 lines) at http://nopaste.snit.ch/19885
01:02 nopaste "chromatic" at 173.50.130.127 pasted "Don't unshift the invocant when reusing a CallContext" (30 lines) at http://nopaste.snit.ch/19886
01:03 abqar joined #parrot
01:03 allison chromatic: ensuring that the invocant is only added on call signatures, not on return signatures?
01:03 allison chromatic: that's a reasonable fix for now
01:03 chromatic I can do better.
01:04 allison eventually would like interp->current_object to go away
01:04 allison and use the Pi signature everywhere
01:05 chromatic In theory, we can null it out in returns from PCCMETHODs.
01:06 allison we can null it as soon as fill_params happens
01:06 allison really, we can null it as soon as the call sig is created
01:07 allison (on the argument side, long before the returns)
01:07 nopaste "chromatic" at 173.50.130.127 pasted "Empty it in PCCMETHOD returns" (12 lines) at http://nopaste.snit.ch/19887
01:08 allison chromatic: does that fix the bug?
01:08 chromatic Checking.
01:09 chromatic Seems to.
01:10 allison cool
01:10 chromatic Looks like positional parameter arity checking is way too strict for returns now.
01:10 * Coke does "make -n install" in a perl5 checkout and is hella confused.
01:10 abqar joined #parrot
01:11 allison chromatic: as in, it's not silently ignoring extra return arguments?
01:11 Austin Hmm... does this mean I can do named returns, now?
01:11 allison Austin: aye
01:11 allison Austin: anything that's supported in a call is supported in a return now
01:11 Austin Nicholas Wirth's head just exploded.
01:11 chromatic As in "I'm returning an empty list, but the caller wants to bind four values".
01:11 allison Austin: (it's just the same code)
01:12 allison chromatic: well, shouldn't that be an error?
01:12 chromatic Try to build pbc_to_exe.
01:12 allison chromatic: return params can be marked as :optional
01:13 chromatic see tools/dev/pbc_to_exe.pir line 35
01:13 * allison looking...
01:13 chromatic Then lines 153 and 162.
01:15 allison yah, good example
01:16 chromatic I can't argue that should be an error.
01:16 allison chromatic: calls and returns aren't spec'd to behave differently here
01:17 allison chromatic: (reread the PDD to be sure)
01:17 allison chromatic: it's a bug in the implementation that crept in because they weren't following the same code path
01:18 allison chromatic: we can either declare it a bug that's now fixed, or declare it a feature that requires a deprecation cycle
01:19 allison chromatic: does tagging the returns with :optional work?
01:20 chromatic It gets past that bug anyhow.
01:21 allison well, that's the sensible thing, since return signatures are parameters
01:22 chromatic I'm going to have to convince myself I like that behavior.
01:22 allison long-term, I don't want any code differences between calls and returns (too much chance for maintenance errors)
01:23 allison but in the short term I'm open to saying this is a feature that requires deprecation
01:23 allison maybe ask the HLL devs if they were depending on it?
01:24 allison it boils down to being very explicit at the VM level, so HLLs have the flexibility to choose their behavio
01:24 chromatic We should do that, but we also need to consider how we work around it if we decide to keep it temporarily.
01:24 allison chromatic: two code paths
01:24 allison chromatic: there's not really any other way to do it
01:25 allison okay, we could hack up the fill_params code for it
01:25 allison but, that just makes it harder to remove after 2.3
01:25 allison and since we're talking about 1 month of deprecation... not worth the hack
01:27 chromatic This means a lot of potential fixups.
01:35 allison chromatic: in outside code?
01:35 allison chromatic: potentially
01:36 chromatic Potentially yes.
01:36 allison chromatic: a quick hack would be to modify IMCC to mark all return signatures as :optional for now
01:36 Whiteknight are we really silently treating all returns as optional now?
01:37 Whiteknight even with error checking on?
01:37 allison apparently
01:37 chromatic Yes.
01:37 allison though... I wonder
01:37 Whiteknight better question: were we doing this before the last PCC refactor?
01:37 chromatic I believe so.
01:37 * Austin ++  # Another passing testcase.
01:37 Whiteknight ok
01:37 allison did pbc_to_exe have return checking turned off?
01:38 Whiteknight I don't even remember when pbc_to_exe was converted to PIR
01:38 allison because one problem I do know currently is that the param filling code doesn't check the interpreter attribute for whether to flag return count mismatches
01:39 allison it only checks the attribute for parameter mismatches
01:39 * Austin ++  # Another passing testcase.
01:40 allison chromatic: if it was a bug introduced in the last refactor, we're safe to just call it "fixed"
01:40 chromatic particle and I converted pbc_to_exe to PIR a couple of years ago.
01:40 allison that particular call could be a later addition, though
01:42 chromatic git annotate says that Francois last touched it last July.
01:43 allison then it's been around a while
01:43 Coke as long as you're fixing things, are you going to make no-param subs strict?
01:43 Whiteknight that would be nice
01:43 allison Coke: strict how?
01:43 Coke (wozzit, RT#39844?)
01:43 Whiteknight allison: subs with no params dont check arity
01:44 Coke aka https://trac.parrot.org/parrot/ticket/1033
01:44 Whiteknight I think it was a hack to allow :main to be declared with no params
01:44 Coke it's very very old.
01:45 Coke and is also causing issues for rakudo:
01:45 Coke http://rt.perl.org/rt3/Tic​ket/Display.html?id=56366
01:45 allison Coke: I thought that was fixed in the previous refactor
01:45 allison Coke: I guess not if it's still affecting Rakudo
01:45 Coke never been fixed.
01:45 Coke SFAIK>
01:45 * Coke checks the test.
01:46 allison heh, I like the simple patch that deletes the code in IMCC to hack around parameter checking...
01:46 * Austin ++  # Another passing testcase.
01:46 Coke pir_error_output_like( <<'CODE', <<'OUTPUT', "arg mismatch with no params", todo=> 'TT #1033' );
01:47 Coke I have no problem with a fix that either forces :main to have the required .param decl, or that makes :main special and allows it to ignore argv.
01:47 allison if we are making a special case for subs marked :main, it should only apply to subs marked :main
01:48 Whiteknight +1
01:48 purl 1
01:48 Coke allison: I don't think anyone knows for sure why it is that way now. the :main thing is just the mostly like "what were they thinking"
01:48 Austin What about subs that get treated as main because they're first in line, and there is no :main
01:48 Coke that's the same as :main. =-)
01:48 allison (and subs that happen to get the "main" quality by simple virtue of being first don't get the same treatment
01:48 chromatic :main is because arity checking the command line invocation is a real son of a gun.
01:49 Coke chromatic: not if you force :main to be :slurpy
01:49 Coke (which is the only sane approach)
01:49 Whiteknight chromatic: that shouldn't matter if a :main only takes a single string array
01:49 Whiteknight or, do we do more processing on argv than that?
01:49 allison well, someone might want to, but if they do they can declare their own parameter signature
01:50 Whiteknight okay, I'm off to bed. Goodnight
01:51 allison at the point of that hack in IMCC, we have the sub object and can check if it was flagged :main
01:51 Austin Whiteknight:
01:51 Coke allison: ISTR that there was some reason why I couldn't get that to work. If you can, go for it. =-)
01:51 allison okay, if people in the US are going to bed, that tells me I'm up way too late :)
01:51 Austin I'm about to commit the Cuckoo stuff. Mocking finally works.
01:51 Coke it's only 9pm eastenr
01:51 allison Coke: yah, not in this refactor, but will look into it
01:52 Coke Austin, I've been able to mock you for some time. Code doesn't help.
01:52 allison Coke: mainly just hoping to merge this in quickly, so want to limit the scope
01:52 Austin Sure, Coke, but could you arbitrarily mock anything else?
01:53 * chromatic is done for the night here, needing to work on other things
01:53 Austin my $proto := cuckoo( Some::Class );  my $obj := $proto.new ; calling( $obj ).foo( 1 ).will_return( 7 );  $obj.foo( 1 );  verify( $obj, :never ).foo( 2 );
01:54 Austin And:  verify( $proto ).new.was_called: :once;
01:57 allison chromatic: thanks for the debugging work!
01:57 allison chromatic: I'll look into it further tomorrow
01:59 allison chromatic: did you commit that one last fix to null out the current_object before filling returns?
02:02 chromatic Pushing everything now.
02:04 adu joined #parrot
02:10 allison chromatic: cool, it gets a lot farther in PGE, thanks!
02:12 dalek parrot: r44784 | chromatic++ | branches/pcc_hackathon_6Mar10/​lib/Parrot/Pmc2c/PCCMETHOD.pm:
02:12 dalek parrot: [lib] Made PCCMETHODs clear their invocant before returning, so as to avoid
02:12 dalek parrot: unshifting the invocant onto their list of return values.
02:12 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44784/
02:12 dalek parrot: r44785 | chromatic++ | branches/pcc_hackathon_6Mar1​0/tools/dev/pbc_to_exe.pir:
02:12 dalek parrot: [tools] Fixed up pbc_to_exe to meet return positional strictness checks.
02:12 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44785/
02:28 dalek parrot: r44786 | cotto++ | branches/ops_pct/compilers/opsc (2 files):
02:28 dalek parrot: [opsc] fix ops2c.nqp, fix an incorrect comment
02:28 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44786/
02:39 JimmyZ joined #parrot
02:40 Coke lhf?
02:40 purl i guess lhf is Low Hanging Fruit
02:40 Coke purl+-
03:00 AndyA joined #parrot
03:03 cotto seen bacek
03:03 purl bacek was last seen on #parrot 7 hours, 1 minutes and 8 seconds ago, saying: Coke, it was actually in klingon
03:03 cotto clock?
03:03 purl cotto: LAX: Mon 7:03pm PST / CHI: Mon 9:03pm CST / NYC: Mon 10:03pm EST / LON: Tue 3:03am GMT / BER: Tue 4:03am CET / IND: Tue 8:33am IST / TOK: Tue 12:03pm JST / SYD: Tue 2:03pm EST /
03:05 bacek_at_work cotto, pong
03:07 cotto do you know what's broken atm in opsc?
03:07 cotto I was just about to start looking, but I figured you might have an idea.
03:07 bacek_at_work something. I updated it this morning. Still fails epically on PGE compilation.
03:07 cotto but hello world works, which is nice
03:07 bacek_at_work I suspect some of "goto" rewrites
03:08 cotto I'll look over those very carefully.
03:08 bacek_at_work check "PC + n" gotos.
03:08 bacek_at_work It fails with assertion when pc == 1
03:09 cotto will do that
03:14 cotto It'd help if I tried to debug ops2c.nqp with a non-bootstrapped parrot
03:17 dalek parrot: r44787 | cotto++ | branches/ops_pct/MANIFEST:
03:17 dalek parrot: [opsc] manifest update
03:17 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44787/
03:35 janus joined #parrot
03:36 dalek rakudo: b093791 | (Solomon Foster)++ | t/spectest.data:
03:36 dalek rakudo: Turn on S04-statements/for.t.
03:36 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​0937917c08aad7d5ba70be4e3212146240c99ed
03:36 dalek rakudo: 0162536 | (Solomon Foster)++ | t/spectest.data:
03:36 dalek rakudo: Add test file S03-operators/comparison-simple.t.
03:36 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​1625360b3c63f9db5a1c9e8eef955a1c1335bc6
04:01 tony joined #parrot
04:06 ewilhelm joined #parrot
04:07 ewilhelm hey all, who's up for summer of code?
04:08 Coke ewilhelm: see dukeleto.
04:09 dukeleto i have ewilhem hostage and we are working on gsoc stuff
04:09 dukeleto who wants to be a mentor?
04:09 cotto dukeleto, is PaFo registered?
04:10 tuxdna joined #parrot
04:10 zostay joined #parrot
04:16 dukeleto cotto: i am working on the app now. we need a gsoc projects page. i am working on that now
04:18 dukeleto i have whiteknight's blog posts as a starting point, if anybody else has ideas, let me konw
04:18 dukeleto know, even
04:32 ewilhelm cotto: we're proposing TPF as an org.  Is there anybody who wants to head-up PaFo as its own entity for GSoC?
04:34 cotto sounds like a good #ps question.  What's involved?
04:40 ewilhelm cotto: http://socghop.appspot.com/document/show/g​soc_program/google/gsoc2010/faqs#org_apply
04:42 ewilhelm it would need somebody to be administrator for the org, so they would need to go through that process, round up some mentors, students, then herd cats throughout the summer
04:43 ewilhelm or parrot projects can feel free to ride with perlfoundation
04:44 dukeleto parrot is riding with TPF this year. But that is something to think about for next year
04:44 ewilhelm yeah it's probably too late for an org to try to get that together this year.  Put it on the calendar for Jan 02 2011
04:45 dukeleto i implore everyone in here to please add something to http://www.perlfoundation.org/pe​rl5/index.cgi?gsoc_2010_projects if you have ideas for GSoC projects this year
04:45 dukeleto there is also http://trac.parrot.org/parrot/wiki/GSOC2010, but that links back to that page
04:45 dukeleto the parrot wiki page could still use some love in terms of making it friendly to new devs
04:47 dalek tracwiki: v1 | dukeleto++ | GSOC2010
04:47 dalek tracwiki: http://trac.parrot.org/parrot/wiki/​GSOC2010?version=1&amp;action=diff
04:49 dukeleto if you would like to be a GSoC mentor, please add yourself to http://www.perlfoundation.org​/perl5/index.cgi?gsoc_mentors
04:50 dukeleto also, if you were one last year and DO NOT want to be one this year, you should take yourself off that page. It is opt-out this year :) ::laughs deleriously::
04:59 * Coke might be about to break the build on windows.
04:59 chromatic Good, that means we only support Linux now, like God and Queen intended.
05:02 ewilhelm see also #soc-help
05:06 Coke chromatic: ... I'm pretty sure Freddy was a Mac guy.
05:06 davidfetter o/` god save the queen o/`
05:06 Austin I think you're bigoting on the wrong axis. If we could just focus support on x86, we'd make a lot faster progress..
05:06 davidfetter o/` we mean it, man o/`
05:08 dalek kakapo: 0bca702 | austin++ |  (33 files):
05:08 dalek kakapo: Got cuckoo() mocking system working. (Now it just needs documentation...)
05:08 dalek kakapo: Signed-off-by: Austin Hastings <Austin_Hastings@Yahoo.com>
05:08 dalek kakapo: review: http://gitorious.org/kakapo/kakapo/commit​/0bca7026d63a1521963e2f9bf06b86079a85594c
05:08 dalek kakapo: 7adbb4d | austin++ | :
05:08 dalek kakapo: review: http://gitorious.org/kakapo/kakapo/commit​/7adbb4d9b8e93f7586db2f09c79c0e59aeb065c8
05:11 chromatic I can't imagine Apple wooing someone as creative and talented as Freddy Mercury.  Overvalued and self-indulgent like John Lennon sure, but not Freddy Mac.
05:11 cotto It makes me sad how much faster than ops2c.nqp ops2c.pl is.
05:11 chromatic Profile?
05:11 purl somebody said Profile was protected by a password
05:12 cotto I'm running a profile at work.  It'll be ready sometime tomorrow.
05:13 mikehh joined #parrot
05:13 cotto (8*60*60)
05:13 purl 28800
05:17 Austin message Whiteknight Kakapo release 8 is on master. See http://code.google.com/p/kakap​o-parrot/wiki/CuculinaeLibrary
05:17 purl Message for whiteknight stored.
05:42 adu joined #parrot
05:46 * Coke finds that the obscure ops lib is not being built as a switch.
06:09 Coke ugh. close to eliminating recursive make on dynoplibs, but not tonight.
06:32 dalek parrot: r44788 | cotto++ | trunk/lib/Parrot/Op.pm:
06:32 dalek parrot: [ops2c] remove some unneeded regexes
06:32 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44788/
06:36 Coke if I compile src/dynoplibs/*.o using the default C rule, it fails. if I add -I. to the command line args, it compiles. wtf.
06:42 Coke pushed the work into a branch, if anyone wants to poke at it.
06:44 dukeleto msg whiteknight can you add short descriptions of your gsoc ideas to http://www.perlfoundation.org/pe​rl5/index.cgi?gsoc_2010_projects and link them to your blog posts? thanks!
06:44 purl Message for whiteknight stored.
06:46 bacek joined #parrot
06:49 cotto hio bacek
06:49 dalek parrot: r44789 | cotto++ | branches/ops_pct/compilers/opsc/src/Ops/Op.pm:
06:49 dalek parrot: [opsc] remove some unneeded substitutions
06:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44789/
06:49 dalek parrot: r44790 | coke++ | branches/rm_dynoplibs_make:
06:49 dalek parrot: Eliminate the recursive make used for src/dynoplibs
06:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44790/
06:49 dalek parrot: r44791 | coke++ | branches/rm_dynoplibs_make (8 files):
06:49 dalek parrot: Close but not quite;
06:49 dalek parrot: Build fails on src/dynoplibs/*.o - but if you run the compilation by hand
06:49 dalek parrot: and add -I., it works. ??
06:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44791/
06:49 dalek parrot: r44792 | cotto++ | trunk/src/ops/var.ops:
06:49 dalek parrot: [ops] Fix pod for find_sub_not_null.  I don't know why this was working before.
06:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44792/
06:49 bacek aloha cotto
06:49 cotto any objections to a sync on the branch?
06:49 bacek nope
06:50 cotto btw, cutting out those extra subst() calls dropped the time to run ops2c.nqp from ~8m to ~6m.
06:50 bacek We do need caching of regexes...
06:53 cotto If nqp doesn't do /o by default, it just became a really important feature.
06:54 cotto With that latest commit, opsc generates the same number of ops as ops2c.
06:55 cotto I also didn't see anything broken about the output of any of the goto FOO() code.
06:56 bacek Hmm... nqp doesn't require /o. It's already compiled down to pir code.
06:57 bacek cotto, are you doing merge now or I'm free to dcommit my changes?
06:57 cotto Rats.  I thought that might be the case.
06:57 cotto go ahead
06:59 cotto is it just those 2 commits?
06:59 bacek 3 I think
07:00 bacek 44795 is last one
07:01 cotto In that case I'll sync now.
07:02 bacek ok
07:03 bacek I'm trying to build selfhosted ops again...
07:03 cotto I tried with reordered ops and didn't get any better results.
07:04 bacek Sigh...
07:05 dalek parrot: r44793 | bacek++ | branches/ops_pct/compilers/opsc/ops2c.nqp:
07:05 dalek parrot: Use ops in same order as ops2pm.
07:05 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44793/
07:05 dalek parrot: r44794 | bacek++ | branches/ops_pct/compilers/ops​c/src/Ops/Compiler/Actions.pm:
07:05 cotto I really want to avoid comparing the code for the generated ops, but that may become necessary.
07:05 dalek parrot: Auto-vivify OPLIB in Actions.
07:05 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44794/
07:05 dalek parrot: r44795 | bacek++ | branches/ops_pct/compilers​/opsc/src/Ops/Trans/C.pm:
07:05 dalek parrot: Generate code closer to ops2c.
07:05 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44795/
07:05 uniejo joined #parrot
07:06 cotto sync committed
07:11 bacek Hmm... Just parsing all ops takes 15 seconds...
07:20 ewilhelm left #parrot
07:22 dalek parrot: r44796 | cotto++ | branches/ops_pct (17 files):
07:22 dalek parrot: [opsc] sync branch with trunk
07:22 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44796/
07:24 cotto Now opsc generates a bunch of extra ops.
07:27 bacek Remove second set.ops in ops2c.nqp
07:27 bacek It was badly merged...
07:28 cotto committed
07:28 cotto thanks
07:32 cotto How does that even happen?  I can accept myself making a stupid mistake, but it's pretty weak for a vcs to do that.
07:32 bacek It's on my side. I forgot to push some changes and then missed bad merge by git-svn
07:33 cotto ok
07:35 cotto Do you know if there's a nice way to add #line directives to the generated code?
07:37 bacek $/ should have enough info to store in Ops::Op
07:38 dalek parrot: r44797 | cotto++ | branches/ops_pct/compilers/opsc/ops2c.nqp:
07:38 dalek parrot: [opsc] fix merge goof
07:38 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44797/
07:49 fperrad joined #parrot
07:50 bacek cotto, I can't spot any obvious bugs in generated code... It's almost same as before. Slightly better in code-style. But semantically same
07:51 cotto There's clearly a bug somewhere.
07:51 cotto but it is a little mystifying.
07:52 bacek indeed.
07:58 bacek Ok. I'm going to redo this bloody double substitution nonsense. We are loosing time waiting ops2c.nqp to finish.
08:00 cotto go for it
08:01 cotto a mandatory 6-minute break tends to break my focus too
08:11 chromatic How do you run ops2c.nqp on ops?
08:14 bacek ./parrot-nqp compilers/opsc/ops2c.nqp
08:15 bacek It will generate include/ and src/ files
08:16 chromatic Is this supposed to work?
08:16 chromatic $ make compilers/opsc/opsc.pbc
08:16 cotto make opsc
08:16 bacek make opsc
08:17 chromatic ./parrot-nqp --target=pir --output=compilers/opsc/gen/Ops/Trans/C.pir compilers/opsc/src/Ops/Trans/C.pm
08:17 chromatic Unable to open filehandle from path 'compilers/opsc/gen/Ops/Trans/C.pir'
08:17 bacek oops
08:18 bacek looks like we need more IGNOREME files
08:18 cotto mkdir compilers/opsc/gen/Ops/Trans #until it gets fixed in svn
08:18 bacek cotto, can you commit IGNOREME in this directory?
08:19 chromatic I can if you need it.
08:19 cotto I can do it
08:19 cotto I can do it nine times.
08:19 chromatic Okay, you do that.
08:19 lucian joined #parrot
08:21 cotto done
08:27 dalek parrot: r44798 | cotto++ | branches/ops_pct/compilers/o​psc/gen/Ops/Trans/IGNOREME:
08:27 dalek parrot: [opsc] add IGNOREME file
08:27 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44798/
08:36 chromatic I find nothing obvious profiling at the C level.
08:36 chromatic We can probably get a ~3% improvement on most call-heavy programs by allocating more than one cell at a time in CallContext, but that's not a big problem here.
08:51 cotto bacek, it'd also be nice if opsc generated ops in the order of ops.num
08:51 bacek ops.num is also generated...
08:51 purl okay, bacek.
08:51 cotto ops.num?
08:51 purl ops.num is mapping between op name and pbc/switch statement in generated code. or generated...
08:51 cotto oh.
08:52 cotto it's a tough nut to crack, but it'll be cracked
09:12 iblechbot joined #parrot
09:43 uniejo joined #parrot
09:45 AndyA joined #parrot
10:05 dalek parrot: r44799 | bacek++ | branches/ops_pct/compilers​/opsc/src/Ops/Trans/C.pm:
10:05 dalek parrot: Generate code close to ops2c.pl
10:05 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44799/
10:05 dalek parrot: r44800 | bacek++ | branches/ops_pct/compilers/opsc/ops2c.nqp:
10:05 dalek parrot: Put experimental.ops as last one to keep order of ops same as ops2c.pl
10:05 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44800/
10:08 bacek joined #parrot
10:13 tony joined #parrot
10:14 tony joined #parrot
10:18 TonyC joined #parrot
10:28 lbr left #parrot
10:28 dalek rakudo: de996e9 | moritz++ | src/core/Any-str.pm:
10:28 dalek rakudo: fix RT #73120: Str.subst should allow both :g and :global
10:28 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​e996e92de87f8f968f57b0afb8b1d8ab21a1708
10:32 mikehh ha - that was fun - pcc_hackathon_6Mar10 branch still goes into infinite loop on t/compilers/imcc/syn/regressions.t
10:33 mikehh I was working on something else and suddenly had no memory etc left
10:34 moritz mikehh: I strongly recommend ulimit -v before running parrot tests
10:34 moritz mikehh: at least that's what I do before running experimental rakudo tests
10:35 mikehh moritz - normally have no problem there - just trying to work on 2 branches at once and forgot to stop the test :-}
10:57 dalek rakudo: 16efb68 | moritz++ | src/core/Any-str.pm:
10:57 dalek rakudo: implement Str.subst($matcher, Code, :g)
10:57 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​6efb687daaca43f809995e9eec4b7ab0c31a5f2
10:57 mj41_ joined #parrot
11:01 cosimo joined #parrot
11:03 payload joined #parrot
11:05 baest joined #parrot
11:09 dalek kakapo: adec347 | austin++ | src/Internals/Full.nqp:
11:09 dalek kakapo: Fixed Kakapo::Full to mark all pre-initload modules as completed for DepQ processing.
11:09 dalek kakapo: review: http://gitorious.org/kakapo/kakapo/commit​/adec347512c59591592e7cfd5cd119874a6a3a61
11:42 dalek parrot: r44801 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops (2 files):
11:44 dalek parrot: Generate code closer to ops2c.pl
11:44 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44801/
11:44 dalek parrot: r44802 | bacek++ | failed to fetch changeset:
11:44 dalek parrot: Regenerate ops without #line directives to simplify comparision with opsc
11:44 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44802/
11:45 dalek parrot: r44803 | bacek++ | failed to fetch changeset:
11:45 dalek parrot: Remove get_label and set_label from ops.num. They are in
11:45 dalek parrot: experimental.ops and don't belong to ops.num.
11:45 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44803/
11:46 bacek cotto, IT WORKS!!!!!!!!!
11:47 bacek msg cotto IT WORKS!!!
11:47 purl Message for cotto stored.
11:50 bacek msg cotto You was right about ops code vs ops.num. After fixing ops.num in r44803 everything start magically works.
11:50 purl Message for cotto stored.
11:59 kid51 joined #parrot
12:05 payload joined #parrot
12:22 ruoso joined #parrot
12:30 dalek parrot: r44804 | bacek++ | branches/ops_pct/compilers/opsc/TODO:
12:30 dalek parrot: Update TODO
12:30 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44804/
12:30 dalek parrot: r44805 | bacek++ | branches/ops_pct/compilers/opsc/t/07-emitter.t:
12:30 dalek parrot: Update test
12:30 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44805/
12:32 mikehh bacek: got a bunch of manifest/codetest fixes ready
12:33 bacek mikehh, ship it! :)
12:40 mikehh bacek: what do we do about src/ops/core_ops.c and include/parrot/oplib/core_ops.h which are generated but are in the MANIFEST/source tree
12:40 bacek can we put them in MANIFEST.skip?
12:41 mikehh bacek: not sure what to do about them
12:41 bacek They are generated. Very similar to bison/flex files.
12:42 mikehh what do we do about other generated files?
12:42 bacek So, codetest should ignore them
12:43 mikehh definately at the moment - lots of errors from them - make realclean removes them but svn status -u says they are missing
12:43 bacek it's work-in-progress
12:44 bacek At the end - make realclean will not remove them.
12:44 mikehh yeah - I'll give it a good thunk or something :-}
12:45 mikehh anywat will come back to that
12:45 bacek ok
12:46 dalek parrot: r44806 | bacek++ | branches/ops_pct/compilers/opsc/t/07-emitter.t:
12:46 dalek parrot: More test updates
12:46 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44806/
12:46 dalek parrot: r44807 | mikehh++ | branches/ops_pct/MANIFEST:
12:46 dalek parrot: re-generate MANIFEST
12:46 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44807/
13:03 dalek parrot: r44808 | mikehh++ | branches/ops_pct (4 files):
13:03 dalek parrot: add svn properties
13:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44808/
13:04 whiteknight joined #parrot
13:06 kurahaupo joined #parrot
13:16 dalek rakudo: 3fba2c3 | moritz++ |  (2 files):
13:16 dalek rakudo: implement :x in Str.subst; implement :all in Str.split(Str)
13:16 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​fba2c3a343806885b983c624c4c1aeb7389c009
13:19 dalek parrot: r44809 | jkeenan++ | trunk/src/ops/var.ops:
13:19 dalek parrot: [codingstd] No trailing whitespace.
13:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44809/
13:26 whiteknight joined #parrot
13:27 moritz Coke++ # going through the perl6 RT queue
13:35 dalek parrot: r44810 | mikehh++ | branches/ops_pct/src/ops/var.ops:
13:35 dalek parrot: remove trailing whitespace and update copyright
13:35 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44810/
13:35 dalek parrot: r44811 | mikehh++ | branches/ops_pct/compilers/ops​c/src/Ops/Compiler/Actions.pm:
13:35 dalek parrot: remove trailing whitespace and update copyright
13:35 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44811/
13:35 dalek parrot: r44812 | mikehh++ | branches/ops_pct/compilers/ops​c/src/Ops/Compiler/Grammar.pm:
13:35 dalek parrot: remove trailing whitespace and update copyright
13:35 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44812/
13:39 bubaflub joined #parrot
13:43 smash joined #parrot
13:43 smash hello everyone
13:44 Coke If you are adding more generated files to the build, please make them re-generatable via the same mechanism as --maintainer.
13:44 Coke moritz: I thought I was subscribed to the mailing list, but I'm not seeing any emails from those tickets I modified.
13:45 moritz Coke: I see them :-)
13:45 dalek rakudo: 85ef035 | (Solomon Foster)++ | t/spectest.data:
13:45 dalek rakudo: Turn on S05-match/blocks.t.
13:45 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​5ef035ff8c461a9ed45af0ee8e37bcf37c4554b
13:45 Coke ... ah, they're here this morning.
13:46 mikehh anyway whole lot more to come, but gotta go out for a while - bbl with more
13:46 Coke moritz: what is the mechanism for saying "this works now but needs tests?"
13:46 Coke (in rakudo RT)
13:46 moritz Coke: yes; say that in the ticket, assign it to me
13:46 moritz there's also a "needs test" tag or so, but I'm not sure if you can already search for it
13:50 Coke you can search for anything! =-)
13:50 Coke I didn't see the tag, though.
13:50 atrodo joined #parrot
13:50 * moritz finds RT's search to suck a lot
13:51 moritz but maybe I just don't understand it
13:51 dalek parrot: r44813 | mikehh++ | branches/ops_pct/compilers​/opsc/src/Ops/Emitter.pm:
13:52 Coke moritz: what's your id?
13:52 dalek parrot: remove trailing whitespace and add copyright and Id
13:52 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44813/
13:52 dalek parrot: r44814 | mikehh++ | branches/ops_pct/compilers​/opsc/src/Ops/Compiler.pm:
13:52 dalek parrot: add copyright and Id
13:52 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44814/
13:52 dalek parrot: r44815 | mikehh++ | branches/ops_pct/compilers/opsc/src/Ops/Trans.pm:
13:52 dalek parrot: remove trailing whitespace and add copyright and Id
13:52 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44815/
13:53 moritz Coke: moritz
13:54 Coke moritz: odd. you're not on the list of potential owners.
13:54 Coke odd. you are.
13:54 Coke (wtf.)
13:54 Coke I don't see any field, custom or otherwise, that refers to tests, other than:
13:54 Coke tag: testcommitted
13:55 moritz ah
13:55 moritz but no testneeded
13:57 Coke Seems like that should actually be a status, not a tag.
13:57 Coke no matter, assignment to you is fine for now. =-)
13:58 slavorgn joined #parrot
14:00 Coke now, if someone would just magically fix my branch...
14:00 whiteknight Coke: which branch?
14:01 Coke https://svn.parrot.org/parro​t/branches/rm_dynoplibs_make
14:01 Coke it is very close to killing another recursive make target.
14:01 Coke I'm either missing a dependency or a compilation flag.
14:02 Coke .. or something else. =-)
14:04 payload joined #parrot
14:17 dalek rakudo: 2302b7c | moritz++ | t/spectest.data:
14:17 dalek rakudo: enable type.t
14:17 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​302b7c9ea8ae9858ce118e7142d4b28f23399a5
14:25 bluescreen joined #parrot
14:26 patspam joined #parrot
14:30 patspam joined #parrot
14:35 whiteknight_ joined #parrot
14:36 payload joined #parrot
14:45 Essobi left #parrot
14:51 whiteknight dukeleto: ping
14:52 dalek rakudo: 24faa67 | moritz++ | t/spectest.data:
14:52 dalek rakudo: enable what.t
14:52 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​4faa670da1654dea74adc999f41d4c2affc0b9b
14:53 whiteknight purl msg dukeleto: I have a few GSoC project ideas for tangential projects like parrot-linear-algebra. Would those be cool to add to the list of projects?
14:53 purl Message for dukeleto stored.
14:58 darbelo whiteknight: More is better.
14:58 whiteknight darbelo: yeah, I know. I just want to make sure things on the fringe of the ecosystem are allowed
14:59 whiteknight oooh, I just had a great idea: threading system enhancements
14:59 whiteknight or, a new threading system
14:59 darbelo Good point. My project eneded up on the fringe of the ecosystem, but it started out as a core thing.
15:00 darbelo That reminds me. I hate our bignums and want them to die...
15:00 atrodo out of curiosity, what's the problems with the current threads?
15:00 darbelo atrodo: All of it?
15:00 purl All of it is supposed to be somewhat redundant, and you might be calling that boring, but that's for a reason.
15:02 darbelo Less glib answer: They were designed and implemented a long time ago, when parrot was pretty different from what it is today.
15:02 darbelo And nobody cares enough bout them to update them.
15:03 whiteknight they are extremely buggy and very inefficient
15:04 whiteknight darbelo: I agree with the bignums thing 100%. I want bignums out of the repo and moved to their own project
15:06 whiteknight There's no sense keeping them when I suspect a majority of users can't use them because they don't have GMP installed
15:07 darbelo Actually, I wouldn't mind them being in the core if they weren't dependant on a lib I don't have.
15:08 darbelo I actually had started to write a stand-alone BigInteger PMC after last year's SoC.
15:09 whiteknight that would make an awesome project too.
15:09 Andy joined #parrot
15:09 whiteknight I think we should have lots of projects like that, and for developers to be able to pick which solution they want
15:10 moritz are there no good, portable and liberally licensed bigint libraries available?
15:10 whiteknight as we are now, it's easier to force BigInt to pretend to do what we need instead of just using the best solution, which might be DecNumber or something else
15:10 whiteknight moritz: GMP
15:11 moritz then... the right path for rakudo would be to require GMP, no?
15:11 moritz rakudo needs bigints; actually it needs them quite badly
15:12 darbelo Maybe, but GMP is much, much more than just bignums. It's a pretty big library.
15:12 whiteknight libdecnumber is decent too
15:12 darbelo Our PMCs don't even start to scratch the surface of what GMP can do.
15:12 payload joined #parrot
15:13 whiteknight darbelo: so moving those PMCs out to a separate library and adding wrappers for other functionality might be nice
15:13 Psyche^ joined #parrot
15:14 darbelo I would consider a GMP binding much more valuble to parrot than our current use of the lib, yes.
15:15 darbelo Also, libdecnumber is pretty good in some aspects, but sucks in others.
15:16 darbelo variably sized numbers are a complete pain in the ass. And it doesn't really do bigints at all.
15:18 davidfetter joined #parrot
15:18 whiteknight allison: ping
15:18 whiteknight darbelo: we should suggest that today at #ps
15:19 bubaflub last  year i worked a bit with GMP library and suggested to dukeleto we work on a GMP binding for parrot
15:19 bubaflub last year with GSOC and perl 5
15:20 darbelo bubaflub: That would be nice to have.
15:20 bubaflub though we used an existing perl 5 binding (Math::GMPz)
15:20 whiteknight yes, that would be a wonderful project
15:20 bubaflub but we could nab the test suite and what not
15:21 bubaflub i'm not totally sure how to do the bindings in parrot - are their SWIG bindings for parrot?
15:21 bubaflub or would it rather be done with NCI?
15:21 whiteknight exactly. We have the two PMC types, and we could write wrappers for the rest of the library and get all sorts of additional power
15:21 whiteknight bubaflub: I don't know about swig. Ifthere are, I haven't heard about them in a long time
15:22 bubaflub whiteknight: ok.
15:22 whiteknight NCI would work. Adding PMCs or ops is a good idea too
15:22 whiteknight so we have the existing BigInt and BigNum PMCs, we could add methods to them
15:22 bubaflub i think access to the GMP library in general would be nice; the stuff i worked on last year was setting some foundational stuff for cryptography libraries
15:23 whiteknight bubaflub: you may be interested in the parrot-linear-algebra project. We're trying to put together bindings to the cblas/atlas libraries
15:23 whiteknight linear algebra is very important for cryptography
15:24 bubaflub agreed.
15:24 bubaflub man, so many proposal options for GSOC
15:24 whiteknight bubaflub: more to come!
15:25 bubaflub haha.
15:25 bubaflub i'm leaning more towards math / linear-algebra type stuff as that was my undergrad
15:25 bubaflub but i'm also open to hacking on some HLLs
15:27 darbelo Right now I'm researching possibilities for the RTEMS port as a GSoC project.
15:28 darbelo PARROTS IN SPACE!!!
15:28 bubaflub hah.
15:30 darbelo The tricky part is finding the right balance between too much and too little.
15:31 bubaflub it's also difficult to judge how long things will take
15:31 bubaflub who knows, a few hours into something a light bulb could turn on and you could get a major breakthrough
15:32 bubaflub or you could be banging your head against your desk for months
15:36 darbelo If I'm right about what the port will take, Coke just did a lot of the work for me in rm_cflags ;)
15:37 Coke c question - is '.' ever implicitly in the include path?
15:37 NotFound Possible idea: resurrect parrot ecmascript, or write a new one from scratech.
15:38 dalek rakudo: ad6b5d8 | moritz++ | t/spectest.data:
15:38 dalek rakudo: turn on more smartmatch tests
15:38 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​d6b5d838092c86fa2e45a082f4ddb504d27087b
15:38 * Coke tries to remind himself that we don't expect GSOC projects to work on core aspects of parrot.
15:39 NotFound Coke: search paths are implementation dependant.
15:39 Coke ok. so if I want ., I should be explicit.
15:41 NotFound Do you mean #include "./something", or using -I . or equivalent command line option?
15:41 darbelo I think he means -I .
15:42 Coke ops2c.pl is generating "#include "src/foo/bar.c"" on dynamic files.
15:42 Coke $(CC) is getting invoked with -Isrc/foo, but not -I., so the build fails.
15:42 Coke so I either need to change the ops2c --dynamic generator, or the makefile rule.
15:43 Coke (easier to change the generator, methinks)
15:43 darbelo Coke: you could ping cotto or bacek on that one. They're rewriting ops2c right now.
15:44 NotFound I think changing the generator is preferable, too much additions to -I may lead to confusions.
15:44 whiteknight dukeleto: ping
15:45 cotto good morning
15:45 whiteknight purl msg dukeleto I listed security sandboxing as a possible GSoC project. If that's a good idea, I think we could use some documentation about what is needed.
15:45 purl Message for dukeleto stored.
15:46 cotto bacek++
15:46 cotto bacek++
15:46 cotto bacek++
15:47 cotto Coke, it's probably easier to change the generator.
15:48 cotto though neither sounds very hard
15:48 Coke that seems to have done it -the dynops build failed when pulled into the top level build because regular ops have their inc file in the public area. dynops leave them in src/*, so it's not quite the same pathing issues.
15:49 Coke and by "done it" I mean it now fails differently. :|
15:49 cotto also, mikehh++ for the cleanups
15:50 cotto nice to have you keeping an eye out for those
15:50 Coke (ok. the .o's build in src/dynoplibs - now the link to generate the output file in dynext is failing.)
15:51 Coke src/extra_nci_thunks.c seems to be leftover on a realclean.
15:52 cotto istr that it's generated but checked in for bootstrapping porpoises
15:53 Coke then it shouldn't be svn:ignored.
15:53 Coke that's only generated-but-not-checked-in stuff.
15:53 bubaflub Coke: i'm also seeing some other files left over from `make realclean` - src/events.o, src/events.str src/tsq.o, runtime/parrot/include/io_thr_msg.pasm, and CFLAGS
15:54 Coke bubaflub: you are working from an old checkout.
15:54 cotto istr incorrectly
15:54 bubaflub Coke: ok.
15:54 Coke you probably have them leftover; realclean, remove them, rebuild, realclean, and check again.
15:55 bubaflub will do
15:55 payload joined #parrot
15:55 Coke (we don't remove files that are no longer generated; if you have them still generated and regen your makefilie before a realclean, you're sol)
15:55 Coke $ svn ls src/*extra*.c
15:55 Coke svn: 'src/extra_nci_thunks.c' is not under version control
16:02 whiteknight Coke: how do we specify a compiler does not have negative zero?
16:04 dalek parrot: r44816 | coke++ | branches/rm_dynoplibs_make/​lib/Parrot/Ops2c/Utils.pm:
16:04 dalek parrot: Now build src/dynoplibs/*.o
16:04 dalek parrot: (still have a link failure)
16:04 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44816/
16:07 bubaflub whiteknight: are you working on getting parrot to build with ICC by any chance?
16:07 whiteknight bubaflub: yes, I'm doing that right now
16:08 whiteknight parrot does build with ICC, but fails some tests
16:08 bubaflub whiteknight: yeah, i was looking into that for dukeleto about a week back; i put my findings in a ticket
16:08 bubaflub i'm looking for the ticket number now
16:09 bubaflub http://trac.parrot.org/parrot/ticket/1488
16:09 bubaflub not sure if that'll help ya
16:09 whiteknight yes, definitely helps
16:10 bubaflub i think there is a discrepancy between the parrot sprintf and c printf
16:11 particle we tried really hard to get rid of those years ago, but sprintf is tough
16:11 particle platform-independent sprintf with extended functionality, that is
16:15 bubaflub whiteknight: right around line 199 or 200 of src/spf_render.c i think
16:16 whiteknight bubaflub: the ICC compiler isn't even storing -0.0 in the structure
16:16 Coke whiteknight: you can override the neg_0 value in the your hints file for that platform.
16:16 bubaflub whiteknight: doh.
16:17 Coke something like $conf->data->set->{'has_negative_zero'} = 0 if $compiler eq 'icc' in the linux hints file.
16:18 Coke (looks like there's already an icc section in config/init/hints/linux.pm)
16:22 whiteknight Coke: I think I may have a fix
16:24 whiteknight GOT IT
16:25 whiteknight bubaflub: reconfigure with the --ccflags="-fp-model source"
16:25 bubaflub nice.  lemme try.
16:26 whiteknight it looks like ICC optimizes floating-point too aggressively byt default, and loses ANSI compliance in the process
16:26 whiteknight Coke: where are the hints files?
16:26 Coke config/init/hints/linux.pm
16:27 whiteknight Coke++
16:27 Coke see: _handle_icc_ccflags
16:27 whiteknight (sorry about all the n00b questions)
16:28 Coke oh, hey, look at that, icc puts all sorts of warnings here in the wrong place.
16:28 * Coke will have to fix that if someone ever installs icc on feather. =-)
16:28 bubaflub whiteknight: i'm building now with perl Configure.pl --cc=icc --ld=icc --link=icc --ccflags="-fp-model source"
16:29 whiteknight Coke: do you happen to know off-hand what distro feather uses?
16:31 moritz debian
16:31 moritz unstable/experimental unhealthy mixture
16:35 iblechbot joined #parrot
16:37 whiteknight bubaflub: that fixes some errors, but still have a stringification problem
16:37 whiteknight so $N0 = -0.0 works now, but $P0 = -0.0, say $P0 doesn't
16:37 bubaflub whiteknight: i'm running `make coretest` now
16:37 Coke ->
16:39 davidfetter joined #parrot
16:40 bubaflub whiteknight: weird, coretest passes for me
16:41 whiteknight I'm trying again
16:43 whiteknight if so, this could be the shortest branch ever
16:44 whiteknight the ICC build still outputs a crapton of warnings
16:44 darbelo icc is picky.
16:45 whiteknight most of the errors it finds are problems with trailing commas in headers
16:45 whiteknight so we could fix those easily
16:46 bubaflub whiteknight: is there any test / test suite you'd like me to run?
16:47 theory joined #parrot
16:50 whiteknight we have a lot of instances in the code of PARROT_ASSERT(!"string"), which ICC hates
16:50 whiteknight a PARROT_FAIL("") macro might be better for the purpose
16:52 dalek parrot: r44817 | whiteknight++ | branches/fix_icc_failures (2 files):
16:52 dalek parrot: update hints to compile with '-fp-model source' on icc. This fixes handling of negative zero, but doesn't fix stringification of negative zero issues
16:52 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44817/
16:52 dalek parrot: r44818 | whiteknight++ | branches/fix_icc_failures/include/parrot (3 files):
16:52 dalek parrot: remove some non-standard trailing commas at the end of enums, which isn't a problem most of the time but ICC hates it
16:52 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44818/
16:53 cotto_work Yay!  The opsc-generated src/core_ops.c has no new test failures!
16:57 whiteknight cotto++
16:57 whiteknight Coke: is that hints file in the same place after all your refactors?
16:57 cotto_work t/compilers/pct/complete_workflow.t fails, but it also fails with the checked-in core_ops.c
16:57 cotto_work bacek++ did 90% of the work
16:59 whiteknight bubaflub: yes, I'm seeing all tests pass now too, after the realclean
16:59 whiteknight I think this branch is mergable.
17:00 bubaflub whiteknight++
17:00 whiteknight bubaflub: if we could fix some build warnings today, that would be awesome
17:00 bubaflub sure sure.  should i make realclean and build again?
17:01 whiteknight just make clean
17:01 bubaflub whoops.
17:01 bubaflub i'm about to head out to lunch with coworkers, i'll start a build and take a look at some errors.
17:02 whiteknight okay, I'm off to lunch too. Let's fix whatever we can today and merge it tonight or tomorrow
17:06 bubaflub whiteknight: i'll throw the build errors i find onto the ticket
17:06 nopaste "whiteknight" at 173.12.37.77 pasted "ICC warnings for bubaflub++" (800 lines) at http://nopaste.snit.ch/19895
17:07 whiteknight bubaflub: There's a listing of all build warnings for you.
17:07 bubaflub huzzah.
17:07 bubaflub hooboy
17:07 bubaflub whiteknight: what platform are you building on?
17:08 ruoso joined #parrot
17:10 whiteknight bubaflub: Ubuntu x86
17:10 bubaflub whiteknight: ok, i'm on Mac OS X 10.6 (and change)
17:12 nopaste "bubaflub" at 173.209.128.134 pasted "ICC warnings on Mac OS X" (178 lines) at http://nopaste.snit.ch/19896
17:12 bubaflub whiteknight: those are the errors i get when i make with icc
17:16 chromatic joined #parrot
17:23 payload joined #parrot
17:32 ruoso joined #parrot
17:37 kjeldahl_ joined #parrot
17:50 dalek rakudo: 62d70b7 | moritz++ | t/spectest.data:
17:50 dalek rakudo: enable two more test files
17:50 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​2d70b7beee3a596b83a59df5d845902b23e66d0
18:09 lichtkind joined #parrot
18:10 lichtkind dukeleto: i have some questions and want to talk about GSOC
18:14 whiteknight lichtkind: what kinds of questions?
18:14 lichtkind whiteknight: what were the most important changes between parrot 1 and 2
18:15 whiteknight ah, good question
18:15 whiteknight There were relatively few major feature additions between them. Mostly it was a period of intense cleanup, coding standards, refactoring, code improvement, etc
18:17 lichtkind whiteknight: that i know, wasnt too lazy to read logs but i cant say if there were any "important features" between them
18:18 lichtkind whiteknight: beside that i currently write http://www.perlfoundation.o​rg/perl6/index.cgi?timeline
18:18 lichtkind please tell me if theres something missing
18:18 whiteknight okay, let me look at your list
18:19 lichtkind whiteknight: that are 2 completely different questions :)
18:20 whiteknight lichtkind: I only saw one question
18:24 PerlJam lichtkind: somewhere in 2003/2004 Dan gave up working on perl6 and TPF started a search for a Perl 6 Pumpking that culminated in selecting pmichaud.
18:24 dukeleto lichtkind: hello
18:25 lichtkind dukeleto: hai
18:25 dukeleto lichtkind: hola
18:26 lichtkind PerlJam: do you know when this was?
18:27 dukeleto whiteknight: I think GSoC projects need to be parrot-core-only, sadly. That isn't set in stone, it might be something to bring up on parrot-directors and/or parrot-dev
18:27 lucian joined #parrot
18:27 lichtkind whiteknight: im really interested which parrot features or changes were most important between 1 and 2 which isnt subject of the timeline
18:27 PerlJam lichtkind: I'm looking it up, but I think it was in the spring of 2004 just after A12 release
18:28 dukeleto whiteknight: and i think the idea of a gsoc project on PDD18 (security sandboxing) would be awesome
18:28 lichtkind PerlJam: thanks a lot a date for dans leaving  were great too
18:29 lichtkind dukeleto: i wanted you just tell thats great that you du gsow and that i could help as drop in mentor for november
18:30 dalek parrot: r44819 | whiteknight++ | branches/fix_icc_failures (6 files):
18:30 dalek parrot: Added PARROT_ASSERT_MSG macro, which does an assertion with a custom error message. Added PARROT_FAILURE which does an unconditonal assertion failure with a custom error message. PARROT_ASSERT was used (abused) to provide these two functions, but ICC gets very unhappy about it. No changes to functionality, but a lot fewer warnings on ICC"
18:30 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44819/
18:31 davidfetter when's #ps?
18:31 dukeleto lichtkind: awesome! did you add yourself to the gsoc mentors wiki page? http://www.perlfoundation.org​/perl5/index.cgi?gsoc_mentors
18:31 lichtkind dukeleto: im currently opened this page
18:32 cotto_work dukeleto, in 117 minutes
18:33 * davidfetter notes in future to ask either the time-to-ps or specify a time zone
18:34 PerlJam lichtkind: Hmm.  All I've found so far is an Aug 6 email congratulating pmichaud on being accepted as the perl 6 compiler pumpking
18:34 PerlJam lichtkind: Aug 6 2004 that is
18:37 dukeleto cotto_work: thanks for asking my question before I asked :)
18:39 cotto_work I'd like to blame autocomplete, but that was more of a pebcak
18:42 lichtkind PerlJam: thank you, and any notice when dan resign, the current date is related to his farewell post
18:43 dukeleto when did parrot switch to a monthly release cycle? that would be good to put in the timeline
18:43 lichtkind dukeleto: written
18:44 cotto_work You can see that pretty easily by looking at docs/parrothist.pod
18:45 cotto_work looks like Jan 2007
18:54 dukeleto cotto_work: thanks, i added that to the timeline
18:56 lichtkind pmichaud: ** August 6 - [Patrick Michaud] got accepted as the perl 6 compiler pumpking, after [TPF] was looking for a new one for some time
18:59 PerlJam lichtkind: that's when the email was.  He may have gotten accepted sooner  than that :)
18:59 lichtkind PerlJam: its a wiki we can change it anytime
19:00 lichtkind dukeleto: when exactly was the release cycle change?
19:03 chromatic November or December 2006, I think.
19:03 aukjan1 joined #parrot
19:03 japhb joined #parrot
19:05 dukeleto lichtkind: i wrote Jan 2007 on the wiki
19:05 whiteknight Austin: ping
19:05 Austin ?
19:06 whiteknight Austin: the mock stuff looks great
19:06 whiteknight if it does everything the docs claim, it's fantastic
19:06 Austin Currently, I think it does - the test cases all run.
19:07 lichtkind dukeleto: allright, could you tellme whats parrots biggest feature or improvement between 1.0 and 2.0?
19:07 Austin I haven't had time to use it under load, yet, since I'm on a different project today. But I should have some real-world experience in the next few days.
19:07 whiteknight I would like to start getting some of my projects using it more. I think I want to update Parrot-Linear-Algebra to use Kakapo for the whole test suite
19:07 chromatic lichtkind, your question makes me think that you believe we increment the major version number to coincide with a large feature release.
19:08 PerlJam lichtkind: pmichaud "applied" for the perl 6 compiler position in Jul 2004
19:13 PerlJam lichtkind: so, I guess Dan stepped down as the perl 6 compiler guy sometime between Apr 2004 and Jul 2004
19:14 PerlJam oh!  here's an announcement from Dan on Jul 6, 2004:  http://www.perlmonks.org/?node_id=372089   (Dan == Elian)
19:14 AndyA joined #parrot
19:14 lichtkind chromatic: as i wrote, i ask because i dont have the feeling log reading makes me really knowing whats going on
19:16 chromatic There's no single big feature, but thousands of commits.
19:17 AndyA_ joined #parrot
19:17 chromatic The best anyone could do is look over the release announcements and pick out a handful of big things.
19:18 chromatic Profiling runcore, GC tuning, PCC revamps, some MMD changes, NQP-rx I believe.
19:18 cotto_work chromatic, #ps reports would also be good for mining
19:20 lichtkind hm
19:20 whiteknight Austin: I get a test failure on kakapo master:
19:20 whiteknight t/Program.nqp ......................... Parent isn't a Class.
19:20 whiteknight current instr.: 'parrot;P6metaclass;add_parent' pc 224 (runtime/parrot/library/P6object.pir:232)
19:21 Austin Whiteknight: That's odd. Are you on master:HEAD, or at release 8?
19:21 whiteknight master:HEAD
19:21 Austin Okay. Whew.
19:22 Austin I'm working on Program in the background, so probably something slipped through. You can safely ignore it for now. I'll try to stabilize it today for you.
19:22 allison Whiteknight: pong (many hours later)
19:22 whiteknight allison: what's the status of the pcc branch? I checked out early last night
19:23 whiteknight I also had a question about returns checking and how strict we plan to be
19:25 kthakore joined #parrot
19:25 kthakore dukeleto: around?
19:25 allison whiteknight: I've been working my way through errors in PGE
19:26 allison whiteknight: chromatic put in a good bit of work there yesterday too
19:26 whiteknight allison: I'm wondering about the case where we call a function but ignore all return values. Will that be acceptable?
19:26 lichtkind allison: hello
19:26 allison whiteknight: I can't say how many errors are left in PGE, but the tasklist for this refactor is almost completed
19:27 whiteknight ok
19:27 allison whiteknight: currently, returns are exactly as strict as parameters
19:27 whiteknight okay, so there's no way to completely ignore return values?
19:27 allison whiteknight: they can be marked as optional, but not completely ignored
19:27 whiteknight okay, is that feature on the wish-list?
19:27 allison whiteknight: not at the moment, now
19:28 allison whiteknight: we had some discussion last night on whether that's a bug or a features
19:28 allison feature
19:28 allison lichtkind: hi
19:28 purl hey, allison.
19:28 dukeleto kthakore: ahoy
19:29 allison whiteknight: it could go either way, really, it's a question for HLL devs
19:29 lichtkind allison: really long time we talked :)
19:29 allison whiteknight: that is, do we want to silently ignore mismatches in return signatures?
19:30 allison whiteknight: or, do we require explicitly marking when a return is dropped?
19:30 whiteknight allison: true, but to draw an analogy, how many people ever use the return value of printf in C?
19:30 allison whiteknight: almost never
19:30 purl i guess almost never is not good enough.
19:31 allison whiteknight (it could be argued that it's a poorly designed function, but that's a side question)
19:31 whiteknight ...so, not a great analogy
19:31 allison the thing is, there are substantial advantages to fully treating return invocations as sub calls
19:32 allison one code path means one maintenance path, means escaping subtle bugs between implementations of the same code
19:32 darbelo (returns = calls)++
19:32 whiteknight I dont debate that. I'm thinking more along the lines of "if we never call get_results, who's going to know?"
19:33 NotFound So we'll need to cal get_results to get void?
19:33 eternaleye joined #parrot
19:33 allison in CPS, returns really *are* calls (of a return continuation)
19:34 whiteknight allison: I know that.
19:34 allison whiteknight: aye, I'm just running over tthe advantages for the sake of discussion
19:34 whiteknight okay
19:35 allison whiteknight: on the other hand, we have the "principle of least surprise"
19:35 particle tewk: you'll want to have the code coda etc on that generated file to mark it as read-only
19:36 allison whiteknight: Perl 5 silently ignores mismatches in the return args and params
19:36 allison I suspect Perl 6 does too
19:37 allison it's possible to implement an HLL that silently ignores missing or extra returns on top of a VM that's strict about them (thought a bit of a hassle)
19:37 whiteknight Austin: Where does kakapo install to? I tried installing it but don't see the files anywhere
19:38 whiteknight allison: Well, we can be strict about them when get_results is called. But, if IMCC uses a heuristic to not call get_results if no results are wanted, we bypass the check
19:38 whiteknight there's a difference between () = foo(), and just bare foo()
19:39 dalek rakudo: e42042c | moritz++ | src/pmc/p6opaque.pmc:
19:39 dalek rakudo: awesome error message when you try to access attributes of type objects, as suggested by TimToady++
19:39 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​42042c4a2bfde3e7b3981ded1e8b2f3c9a0b22b
19:40 tewk in a CPS world get_results sounds wrong.  It should be this is the continuation and signature you call next.
19:41 Austin Depends, but probably /usr/local/lib/parrot
19:41 shockwave joined #parrot
19:41 shockwave Howdy.
19:41 allison whiteknight: yes, and it may actually handle that now if get_results isn't called in the second case
19:42 shockwave Can an array access be used anywhere a register can be? i.e., $P[0]
19:42 shockwave $P1[0] ^^^
19:42 Austin shockwave: no
19:42 shockwave umh
19:42 Austin Array (and hash) accesses can be used to store, and fetch.
19:43 Austin $P0 = $P1[1]
19:43 Austin But not generally whereever an op takes a  $P register.
19:43 shockwave ah
19:43 Austin $P2 = newclass $P0[1]   # Doesn't work
19:43 allison tewk: oddly enough, it actually makes sense to have separate ops for results, because they pull from a different context level than params
19:44 allison tewk: (get_params pulls from the current context, get_results pulls from a child of the current context
19:44 shockwave Austin, so, is the recommended thing is to do something like: $P2 = $P1[0] ... Use $P2 as pointing to $P1[0] ?
19:44 Austin $P0[1] = split '::', $P1    # Doesn't work
19:44 Austin shockwave: right! Remember that PMCs are pointers, so you're creating an alias.
19:45 Austin $P0 = $P1[4]
19:45 Austin inc $P0
19:45 Austin will increment $P1[4], whatever "increment" means to that pmc.
19:45 allison whiteknight: but, yeah, I could see an argument that () = foo() should do parameter checking, while foo() shouldn't
19:45 allison whiteknight: of course, we also have the global setting for "don't check return parameter mismatches"
19:46 Coke ... osx has icc?
19:46 whiteknight all that is a little moot if we never call get_returns
19:46 shockwave Austin, So I'm correct in assuming that if I do: $P1[0] = 42; $P2 = $P1[0]; inc $P2; # That, although I stored a literal int, it will be incremented correctly?
19:47 Austin Won't work.
19:47 Austin Use 'box'
19:47 Coke PerlJam: (dan gave up working on perl6) ... do you mean parrot? I don't recall dan working on p6.
19:47 shockwave $P1[0] = box 42
19:47 chromatic I remember that, Coke.
19:47 PerlJam Coke: Dan was doing double duty on parrot and perl6 in the early days
19:47 allison whiteknight: (trying a quick code example)
19:47 allison PerlJam: Parrot *was* perl 6 in the earliest days
19:47 Austin $P0 = box 42 ; $P1 = new ['ResizablePMCArray'] ; $P1[0] = $P0 ; inc $P0 ; $P2 = $P1[0] ; say $P2
19:48 PerlJam allison: well, that's one way to look at it :)
19:48 shockwave Austin, Thanks alot. You're the man.
19:48 allison PerlJam: but he never worked on Perl6 design, if that's the question
19:48 PerlJam allison: right.
19:48 PerlJam Coke: what allison said
19:48 allison PerlJam: or on any of the early prototype implementations of Perl6 on top of the VM
19:48 allison PerlJam: only on the VM that eventually came to be known as Parrot
19:49 allison PerlJam: so you're *both* right :)
19:49 tewk allison, I've not been following the latest PCC changes, but I would suspect that tailcalls use the same context right?
19:49 allison tewk: yes
19:52 tewk offtopic, it would be nice for parallelism if parrot had some container types whose size were set on creation
19:52 chromatic I agree.
19:54 allison tewk: certainly doable
19:54 Coke $P0 = new 'arryish',  5
19:54 whiteknight so add an init_int vtable?
19:54 TiMBuS joined #parrot
19:55 whiteknight that seems highly reasonable
19:55 whiteknight I also like that it would prevent us from needing to shoehorn Fixed*Array.set_integer for the purpose of setting the capacity
19:55 whiteknight or, us continuing to do that
19:55 tewk whiteknight, that is exactly the problem,
19:56 tewk is that feature needed anywhere?
19:56 whiteknight if the dream comes true and we have only one array-like type in the repo, it won't really be needed, no
19:57 whiteknight but other array types and other PMCs would use it
19:57 whiteknight one fewer vtable call for every single Integer PMC in the system, which adds up
19:58 chromatic There's already init_pmc, though that means creating and throwing away a temporary Integer for each arraylike creation.
19:59 shockwave left #parrot
19:59 tewk constructors are really a powerfull concept, maybe once pmcs and objects become one ...
20:00 zostay joined #parrot
20:00 chromatic CallContext would be cheaper if we could initialize its storage size on creation.
20:01 tewk yep, you could eliminate PMC_data indirections.
20:02 whiteknight we can ask if there are any objections at #ps, but I think it's a great iea
20:02 whiteknight idea
20:04 allison me too
20:04 tewk In some ways we optimized VTABLES and object methods backwards, native method access should be optimized first and interop access later.
20:05 chromatic VTABLEs should have used MMD from the start.
20:06 allison tewk: a lot of it fell out of "what's easiest to implement"
20:06 chromatic Number of problems that would have caused: few.
20:06 chromatic Number of problems that would have prevented: many.
20:06 allison chromatic: aye
20:06 allison chromatic: they were pseudo-MMD pretty early on
20:06 chromatic Not really.
20:06 allison chromatic: but, the system didn't play well at all with any true MMD
20:07 allison chromatic: there was that funny kind-of MMD system we ripped out in the MMD refactor
20:07 allison chromatic: oh, but it was only for a limited set of math ops, so you're basically right
20:08 chromatic Yeah, true MMD doesn't easily fall out of a system where you always first dispatch on the leftmost invocant and then, maybe, redispatch.
20:09 chromatic I'll save the rest of my "The Marriage of Heavenly Methods and Hellish VTABLEs" for the William Blake stage of Lorito however.
20:14 * dukeleto ponders writing a script to scrape Trac to autogenerate some parts of his weekly #ps report
20:16 whiteknight dukeleto: I would pay for a tool like that
20:16 whiteknight just being reminded of what commits I made would be awesome
20:16 dukeleto whiteknight: I won't forget that ;)
20:17 darbelo Not exactly what you are asking for, but http://home.gna.org/forgeplucker/
20:17 bubaflub dukeleto: http://trac.parrot.org/parrot/timeline?from=03/09​/10&amp;daysback=7&amp;ticket=on&amp;changeset=on​&amp;milestone=on&amp;wiki=on&amp;update=Update
20:17 Coke dukeleto: I just ... right.
20:17 Coke I bet if you were clever, you coudl get that to restrict by actor.
20:17 dukeleto whiteknight: yes, being reminded of what $user did in the last week would benefit everyone and make our #ps reports easier to make better
20:18 tewk I get "easiest to implement", I was nostalgic to see PCCMETHOD AND PCCINVOKE in the channel discussion recently :)
20:18 japhb fperrad, ping
20:19 particle whiteknight: http://cia.vc/stats/author/whiteknight
20:20 * particle used this for years as #parrotsketch prep
20:21 whiteknight particle: holy shit, what is this magical page?
20:21 darbelo You... prepped on whiteknight's commits?
20:21 darbelo Kinda creepy.
20:22 dukeleto bubaflub: that is useful, thanks
20:22 Coke trac is slightlz nicer because also� tickets.
20:22 Coke ... what happened to mz kezboard_
20:23 Coke -win 4
20:23 Coke aigh.
20:23 dukeleto Coke: looks like you switched to a german qwertz layout
20:23 Coke I cannot tzpe a slash.
20:23 Coke qwertz
20:23 Coke azup.
20:23 particle heh
20:23 Coke -me wonders how that happened, as he thought he disabled german input on this kezboard.
20:24 moritz Coke: Shift + 7 if it's really German
20:25 Coke is a slash, zes.
20:25 Coke -me is more wondering how to disable this. ��=
20:26 Coke er, ;)
20:27 dukeleto bubaflub: wow, that timeline really helps. I did a lot more than I remembered :)
20:27 whiteknight damnit, /me has to run over to the lab now, will miss at least the first part of #ps.
20:28 bubaflub dukeleto: yeah, the authors have their own span class, so aggregating the data shouldn't be too bad
20:28 darbelo clock?
20:28 purl darbelo: LAX: Tue 12:28pm PST / CHI: Tue 2:28pm CST / NYC: Tue 3:28pm EST / LON: Tue 8:28pm GMT / BER: Tue 9:28pm CET / IND: Wed 1:58am IST / TOK: Wed 5:28am JST / SYD: Wed 7:28am EST /
20:28 bubaflub at least in my head with a ruby / nokogiri type script
20:28 darbelo #ps in 2.
20:28 bacek joined #parrot
20:28 ruoso joined #parrot
20:31 chromatic #ps time
20:33 kthakore ps ?
20:33 purl well, ps is postscript or process status or see "parrotsketch" or non-vector?! or annoying.
20:33 kthakore oh ok
20:33 darbelo parrotsketch
20:33 purl somebody said parrotsketch was a status meeting for parrot core committers held every Tuesday at 20:30 UTC in #parrotsketch
20:36 Coke aha. "alt-shift" switches between german & english mode (despite a lack of DE being specified anymore in regions)
20:36 dukeleto bubaflub: feel free to write something like that :)
20:40 chromatic Coke, could you take a look at the PGE dependency on the PCC hackathon branch?
20:41 whiteknight joined #parrot
20:42 joeri joined #parrot
20:44 Coke chromatic: sure, post $DAYJOB.
20:45 chromatic Thanks.
20:45 Coke I'm not sure it makes sense to add a test for it, but I can definitely unbork it.
20:47 darbelo japhb: Count me in for any plumage work you need help on.
20:48 japhb darbelo, Ah, cool, there you are.  Didn't see you on #ps
20:49 japhb (and thanks!)
20:51 whiteknight in #ps, did anybody mention the new init_int vtable?
20:52 Topic for #parrotis now #parrot Parrot 2.1.1 Released! | http://parrot.org/ | Channel log: http://irclog.perlgeek.de/parrot/today | Task: Fix HLL bugs!
20:52 chromatic Not yet, whiteknight.
20:57 shockwave joined #parrot
20:57 nopaste "shockwave" at 76.119.137.239 pasted "Long question." (27 lines) at http://nopaste.snit.ch/19897
20:58 Coke chromatic: and monkey's brains, while a popular dish in cantonese cuisine...
20:58 shockwave I have a question, but since is pretty long, I posted it at the above location.
20:58 chromatic My monkey is a robot.  Just try to get at his positronic brain.
21:00 moritz shockwave: parrot basically has no notion of assignment, just binding. pmichaud has been cursing about this for years - I'm sure he can tell you what his workaround his (but he is much distracted by real life these days)
21:00 moritz shockwave: you might also find plenty of discussions in old #parrotsketch and mailing list discussions
21:00 moritz http://trac.parrot.org/parrot/wiki​/WhyDoesNQPGenerateInefficientCode
21:01 shockwave moritz, reading the link right now...
21:03 whiteknight I really didn't expect that question to generate so much opposition
21:04 dalek parrot-plumage: 51ac9c0 | japhb++ | src/lib/Plumage/Project.nqp:
21:04 dalek parrot-plumage: [LIB] Plumage::Project: Support nqp_setup method
21:04 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/51ac9c01e348e8756a760e781dac3c89b301c138
21:04 dalek parrot-plumage: 3c71f8b | japhb++ | metadata/kakapo.json:
21:04 dalek parrot-plumage: [METADATA] Update kakapo.json: use nqp_setup, other improvements; fperrad++
21:04 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/3c71f8b7b41521594f1baaa968e9ce861177c9d5
21:07 Coke plumage?
21:07 purl hmmm... plumage is the future Parrot module ecosystem.  It will include tools to search metadata, handle dependencies, install modules, and so forth. The repository is at http://gitorious.org/parrot-plumage/parrot-plumage and the design docs are at https://trac.parrot.org/pa​rrot/wiki/ModuleEcosystem
21:07 whiteknight the day after Rakudo* is released, I'm starting work on my "dancing hamsters" port to Parrot
21:08 whiteknight And then I'm porting the TI Calculator game "Drug Wars" to Parrot
21:08 chromatic Man, that game takes me back.
21:08 whiteknight And then I'm going to port Parrot to my roomba
21:09 japhb I want Parrot on my old TI graphing calculator
21:11 whiteknight chromatic: still need help on #389?
21:11 shockwave @moritz, Sorry, it took me a while to read and understand that post. I'm feeling like "oh, oh, I'm going to be in for some hurt".
21:11 whiteknight I think I can knock #1505 out tonight, and then I can move to that since I know it's still a big deal for rakudo
21:11 chromatic whiteknight, I do.  I have one more thing to try, but if you don't see anything from me by this time Thursday, I'm stuck.
21:12 whiteknight okay, well let's keep a dialog open about it. I
21:12 whiteknight 'm in that code now and will offer all the tuits I have
21:13 shockwave msg pmichaud Hit me up when you get a chance. I'd like to talk to you about assignment vs binding. For reference: http://trac.parrot.org/parrot/wiki​/WhyDoesNQPGenerateInefficientCode
21:13 purl Message for pmichaud stored.
21:13 chromatic I'm going to try once more to create the PMCProxy during class init 2.  If that doesn't work, I'll probably do what you suggested and stuff a method hash into the VTABLE.
21:13 shockwave Thanks, moritz
21:14 whiteknight why doesn't it work at class init 2? That seems like the perfect time
21:14 chromatic I may have done it poorly.
21:14 chromatic Last time I tried to make it work and pretty at the same time.
21:14 chromatic Perhaps we need to consider a pretty pass later.
21:15 whiteknight if we add a third init stage, I may foam at the mouth until we remove non-essential PMC types from the repo
21:15 chromatic Not init 3, but "Let's go over the code and make it pretty now that it works."
21:16 whiteknight yeah, I definitely want to get in there and gussy up some of that shit
21:16 japhb ^ quote
21:17 whiteknight class_init with a flag and two branches is worse than two separate class_init functions with no branches
21:17 cotto_work istr that one-stage PMC init would be possible if we hard-coded the PMCs needed to initialize other PMCs.
21:18 whiteknight cotto_work: like a fixed ordering?
21:18 cotto_work yes but just for the first few
21:18 cotto_work The rest could be lazy or in whatever order.
21:19 cotto_work I briefly looked into it when thinking about implementing lazy PMC initialization.
21:19 whiteknight I'm not sure that's going to work anymore after chromatic's work
21:19 cotto_work ok
21:19 whiteknight because every type is going to require an RPA and a PMCProxy
21:19 whiteknight and you can't initialize them at the same time
21:19 chromatic I'm not sure a stage one init works with the way we initialize vtables.
21:21 chromatic bacek, care to look at weird behavior in compact_pool?
21:21 whiteknight chromatic: instead of storing methods on the proxy, what if we created a Hash* pointer in the vtable?
21:21 whiteknight could be done immediately because that isn't a PMC type
21:21 chromatic Yes, that's doable, but I like it less.
21:21 bacek chromatic, holley schitt. What about compact_pool?
21:21 chromatic I like the use of PMCProxy because we can unify method lookup that way.
21:21 chromatic bacek, I think it grows unconstrained.
21:21 whiteknight what do you mean "unify method lookup"?
21:22 chromatic Classes look up methods one way.
21:22 chromatic PMCs look up methods another way.
21:22 bacek chromatic, any test cases?
21:22 chromatic Building gen_core.pm for Rakudo.
21:22 lucian i'm curious about GSoC. what are the chances of a pynie proposal being accepted?
21:22 bacek And it actually grows unconstrained. We just compact it.
21:23 PerlJam lucian: zero I'd think.  But what do I know?
21:23 chromatic I don't think compacting actually works.
21:23 lucian PerlJam: right. well, good to know that's what you think :)
21:24 PerlJam lucian: you'd have to show a strong connection between whatever you propose for pynie to perl 5, perl 6, or parrot.  That's where the focus lies for TPF.
21:24 chromatic bacek, I *think* the size of the single pool always grows, even if most of the STRINGs are garbage and don't need collected.
21:24 lucian PerlJam: right, fair enough
21:24 bacek chromatic, hmmm...
21:25 lucian PerlJam: i'd propose work to bring pynie as close to CPython as possible
21:25 PerlJam lucian: maybe the python people would approve it  :)
21:25 chromatic If you write a benchmark that makes a bunch of large strings that are immediately garbage, you should see it grow without bounds.
21:25 japhb lucian, better for a submission to the Python foundation?
21:26 lucian japhb: yes, that's a consideration as well. i figured i should ask here as well
21:26 Austin lucian: It's a problem of politics and structure. The SoC "slots" are allocated to mentoring organizations. So your project has to be relevant to an organization in order for them to carry it forward to Google.
21:26 lucian Austin: true
21:27 whiteknight lucian: your project might have a better chance of being supported by the python people
21:27 japhb lucian, As Austin said.  TPF + PaFo decided to join forces again this year, in attempt to gain extra slots.  But that means they are very Perl-biased.
21:27 japhb Well, maybe not 'very', but at least somewhat
21:27 whiteknight if the two communities have good report, you could do the project under the python banner with a co-mentor from Parrot
21:27 Austin * rapport
21:27 PerlJam whiteknight: good point.
21:27 whiteknight Austin++
21:28 lucian whiteknight: ok. i'll ask around
21:28 PerlJam whiteknight: probably doable too
21:28 whiteknight lucian: ask allison, she's friendly with python people
21:28 Austin Not that there's anything wrong with that...
21:28 whiteknight Austin: did you get my message earlier about kakapo not installing?
21:29 Austin Whiteknight: I just pushed a set of Program changes that pass
21:29 lucian Austin: heh
21:29 whiteknight Austin++
21:29 Austin Yeah, I replied. Look in /usr/local/lib/*parrot*/library/...
21:29 * japhb chuckled on looking at allison's slide in her Pynie talk at PyCon in which NQP got re-acronymed
21:29 whiteknight Austin: I did look there. Nothing
21:29 lucian allison: ping
21:29 Austin Curiouser and curiouser.
21:29 purl Now I'm opening out like the largest telescope that ever was! Good-bye, feet!"
21:29 allison lucian: hi
21:30 allison japhb: we're a multi-cultural bunch :)
21:30 japhb whiteknight, kakapo not installing?  I just pushed a new Plumage and kakapo metadata, to switch over to using setup.nqp/distutils.  Seemed to work here.
21:30 lucian allison: i may be interested in doing GSoC work on pynie
21:30 Austin whiteknight: I've never actually run the install myself, so I may have misconfigured something in the setup.nqp.
21:30 allison lucian: excellent!
21:30 purl Smithers, release the hounds!
21:31 whiteknight okay, I'll look at it more tonight too. As I mentione,d I'm planning to redo parrot-linear-algebra to use all kakapo all the time
21:31 allison lucian: I'd be happy to mentor
21:31 lucian allison: what's the best way to about it? apply to the PSF? PaFo?
21:31 Topic for #parrotis now #parrot Parrot 2.1.1 Released! | http://parrot.org/ | Channel log: http://irclog.perlgeek.de/parrot/today | Tasks: Fix HLL bugs!  Fix and test corevm target!
21:31 Coke I think it is possible to cross-post.
21:31 lucian allison: just so you know up front, this would be my second choice, right now Sugar Labs would be my first
21:31 allison lucian: PaFo is a small foundation, we've gone under the TPF umbrella
21:31 lucian allison: yes, i noticed
21:31 Austin Damn, dude! Never tell a woman she's your second choice.
21:32 allison luician: it's worth talking to the Python folks and see if they'd be willing to include it in their list
21:32 particle lucian: it might be worth starting a conversation with the org admin for psf, as well as allison
21:32 particle allison++
21:32 lucian allison: right. i know the PSF is interested in py3 projects mostly
21:32 allison lucian: but feel free to put it in the PaFo queue otherwise
21:32 shockwave Are all the vtable methods listed in src/vtable.tbl available to a custom class, or are some of those methods only available if one subclasses specific classes?
21:32 allison lucian: pynie *is* a py3 project
21:32 lucian allison: right. i'll talk to the PSF people
21:33 particle what version of python is pynie emulating? ah, 3, excellent.
21:33 whiteknight shockwave: some of them cannot currently be overridden from PIR
21:33 lucian allison: i know, which is why i said that
21:33 allison lucian: ah, yeah
21:33 whiteknight shockwave: most can, and most *should*. if you find one you cannot override but think of a plausible reason why you would want to, it's a bug
21:33 Austin shockwave: All the vtables are on all the pmcs. But not all pmcs use them - like who tries to .invoke() an array?
21:33 shockwave whiteknight, is there a way to know which one, or is it a try and see thing?
21:33 Coke but in general, all vtables are at least invokable on all pmcs. some will error and carp about being unimplemented, but that's the implementation. =-)
21:33 whiteknight try and see, mostly
21:34 Coke Austin: I invoke an array all the time: Eval.
21:34 dalek kakapo: f1a4df5 | austin++ |  (3 files):
21:34 dalek kakapo: Simplified Program, got tests passing for Whiteknight.
21:34 dalek kakapo: Signed-off-by: Austin Hastings <Austin_Hastings@Yahoo.com>
21:34 dalek kakapo: review: http://gitorious.org/kakapo/kakapo/commit​/f1a4df5a4e9ac0fe2c617e4ca55c4cce5e54dbfa
21:34 Austin (Of course, a MultiSub is sort of an invocable array, but ...)
21:34 whiteknight okay, I'm packing up and heading home. Laterz
21:34 shockwave whiteknight, Austin, thanks.
21:34 Austin Coke: How?
21:35 Austin $P0 = new ['ResizablePMCArray'] ; $P0()
21:35 Coke Austin: Eval is an array of subs.
21:37 shockwave I hope the "solution" to the assignment issue I'm having will work, even if not very efficient. Sucks that I wont be able to try it for some time.
21:39 dukeleto well, that was an exciting #ps
21:39 Coke oooh, I think I can make all the makefiles autoregen.
21:40 chromatic That sounds like a way to orphan files!
21:40 Coke 'include' everything that is dynamically generated, and provide a rule to regen them.
21:41 cotto_work Hmm.  The profiling runcore seems to be useless for profiling opsc.
21:42 chromatic The line number problem blocking on japhb?
21:43 cotto_work no, it
21:43 cotto_work s showing almost nothing
21:43 cotto_work I'll be digging into it.
21:43 japhb Bah.
21:44 chromatic Just call me Mr. Teflon.
21:44 * japhb is trying to unblock people, now that tuits not completely eaten, but I've got a substantial backlog.
21:44 cotto_work line numbers aren't that big a deal as long as I've got sub info
21:45 Coke is this corevm building PGE thing happening in trunk?
21:45 Tene I have a fix for 'rethrow' telling lies about the source of rethrown exceptions in exceptions_refactor branch.
21:45 Coke I'm not seeing it.
21:46 Coke Tene: wow, that's an old ticket. =-)
21:46 chromatic Coke, it's the pcc hackathon branch.
21:46 Coke tene++
21:46 chromatic cotto_work, line numbers are very wrong in several places.
21:46 cotto_work indeed
21:46 Coke chromatic: ... has that branch been updated from trunk lately?
21:47 chromatic I thought so, but perhaps not in the past week.
21:48 bluescreen joined #parrot
21:51 dalek rakudo: 5b81dfe | moritz++ | src/Perl6/ (2 files):
21:51 dalek rakudo: awesomize error message for regexes in packages a bit (though allowing them would really be preferrable)
21:51 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​b81dfe3bd08497b1b277d9713c7a5bdf9b24228
21:51 Coke svn++ for # svn ls ^/branches
21:53 cotto_work Coke, which version introduces that?
21:53 Coke iunno. "recent"
21:53 Coke ^ == "repository root"
21:53 Coke useful for switch, ls, log, etc.
21:53 cotto_work yeah
21:54 PerlJam 1.6 I think
21:55 PerlJam svn++ for finally adding that feature indeed
21:59 Coke that branch predates the mergeback of rm_cflags.
22:00 Coke so I would recommend doing a merge update first.
22:00 Coke (before tackling the corevm problem.)
22:01 Coke also, I get no failures on 'make -j3 corevm' in that branch.
22:02 Coke ->
22:02 dalek parrot: r44820 | mikehh++ | branches/ops_pct/compilers/opsc/src/Ops/Op.pm:
22:02 dalek parrot: remove trailing spaces
22:02 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44820/
22:02 dalek parrot: r44821 | mikehh++ | branches/ops_pct/compilers​/opsc/src/Ops/Trans/C.pm:
22:02 dalek parrot: remove trailing whitespace and add copyright and Id
22:02 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44821/
22:08 snarkyboojum joined #parrot
22:08 bacek joined #parrot
22:08 tewk How does something get in the embedding interface?
22:09 chromatic We document it as such.
22:09 moritz http://www.perlmonks.org/?node_id=825863 more parrot hackers need to participate in that poll :-)
22:10 particle prepend PARROT_API to the c function definition
22:19 dalek parrot: r44822 | mikehh++ | branches/ops_pct/compilers/opsc/t/common.pir:
22:19 dalek parrot: remove trailing whitespace and add copyright and Id
22:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44822/
22:19 dalek parrot: r44823 | mikehh++ | branches/ops_pct/compilers/opsc/src/builtins.pir:
22:19 dalek parrot: remove trailing whitespace and fix copyright and Id
22:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44823/
22:19 dalek parrot: r44824 | tewk++ | trunk/lib/Parrot/OpsRenumber.pm:
22:19 dalek parrot: generate include/parrot/opsenum.h
22:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44824/
22:22 tewk so I only found PARROT_API in one doc file, PARROT_EXPORT seemes to be used by everything in embed.h
22:24 particle tewk: some time ago PARROT_API and PARROT_EXPORT had a divorce, i can't remember who's side we're on.  i'm sure it was discussed in #ps and on the mailing list
22:25 GeJ Good morning everyone.
22:32 davidfetter hi GeJ
22:33 tewk particle, yeah I have faint memories of the discussion
22:33 particle it may be, "we'll figure PARROT_API out later, for now, mark what you need exported with PARROT_EXPORT"
22:35 dalek parrot: r44825 | mikehh++ | branches/ops_pct/compilers/opsc/opsc.pir:
22:35 dalek parrot: remove trailing spaces
22:35 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44825/
22:35 dalek parrot: r44826 | mikehh++ | branches/ops_pct/compilers/opsc/t/03-past.t:
22:35 dalek parrot: remove trailing whitespace and add copyright and Id
22:35 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44826/
22:35 dalek parrot: r44827 | mikehh++ | branches/ops_pct/compilers/n​qp/src/Grammar/Actions.pir:
22:35 dalek parrot: remove trailing spaces
22:35 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44827/
22:35 dalek parrot: r44828 | mikehh++ | branches/ops_pct/compilers/opsc/t/01-parse.t:
22:35 dalek parrot: add copyright and Id and fix coda
22:35 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44828/
22:40 tewk which is preferred Parrot_string_ or Parrot_str_ prefix, by count it looks like Parrot_str?
22:43 cotto_work sounds right
22:44 cotto_work joined #parrot
22:46 Andy joined #parrot
22:50 allison Parrot_str_ is the new (following the coding standards for a short prefix)
22:50 allison Parrot_string_ is still on some older functions
22:51 tewk Adding deprecations now. I've created Parrot_str_is_null and deprecated STRING_is_null too.
22:51 dalek parrot: r44829 | mikehh++ | branches/ops_pct/compilers/opsc/t/07-emitter.t:
22:51 dalek parrot: add copyright and Id
22:51 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44829/
22:51 dalek parrot: r44830 | mikehh++ | branches/ops_pct/compilers/opsc/t (3 files):
22:51 dalek parrot: add copyright and Id
22:51 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44830/
22:51 dalek parrot: r44831 | mikehh++ | branches/ops_pct/compilers/​opsc/t/02-parse-all-ops.t:
22:52 dalek parrot: add copyright and Id
22:52 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44831/
22:53 tewk =item C<PMC* Parrot_str_split(PARROT_INTERP, STRING *delim, STRING *str)>
22:53 tewk Splits the string C<str> at the delimiter C<delim>, returning a
22:53 tewk C<ResizableStringArray>, or his mapped type in the current HLL,
22:54 tewk opps
22:57 lucian allison: i'm trying to make sense of pynie's source. what flavor of developing languages on parrot does it follow?
22:59 cotto_work bacek++ for making all of opsc's test pass again
22:59 PerlJam pynie hasn't been updated to use nqp-rx yet, has it?
23:00 japhb PerlJam, last I heard allison was working on that conversion in a separate repo
23:00 PerlJam lucian: if what japhb says is true, *that's* probably the pynie you want to look at.
23:00 japhb (And according to her PyCon talk, converting from Python 2.5 grammar + 3.0 fixes to pure 3.0 grammar)
23:01 lucian japhb: PerlJam: she directed me to this repo http://bitbucket.org/allison/pynie/overview/
23:03 allison the pynie-nqp repo is the update
23:03 allison but, it's just the fresh grammar
23:03 allison that is, it's a replacement, not an in-place update
23:03 allison though, everything but the grammar and actions file will remain the same after the nqp conversion
23:04 * lucian is furiously reading parrot docs :)
23:05 allison japhb: yes, the pynie-nqp grammar is a pure translation of the 3.x grammar
23:07 Tene allison: I remember a long time ago we discussed OO for pynie, and you planned to do a lot of thinking about how you wanted to build the metamodel for pynie (not inheriting from P6object, I think).  Has that happened?
23:07 allison Tene: for now I'd like to get the simplest possible thing working
23:08 * Tene nods.
23:08 allison Tene: AFAICT, that's a thin wrapper around Parrot's Object/Class
23:08 allison Tene: I don't see much value in P6object for Python
23:09 Tene I'd really like to work on that sometime soon, but I'm not hopeful.
23:09 allison Tene: it's okay
23:10 allison Tene: I worked on it some at PyCon, will work on it some more soon
23:10 allison Tene: the thing I'm not sure of is whether to work on features, or on moving to NQP
23:10 lucian allison: is NQP not quite perl?
23:10 allison Tene: I'm finding NQP-rx a lot easier to work with than PGE
23:11 PerlJam lucian: aye
23:11 allison lucian: it's a lightweight language used inside the compiler tools
23:11 Tene Moving to NQP isn't too bad.  I could put whatever time I end up with into that.
23:11 lucian allison: reading some nqp code. i guess my eyes are trained to recoil at the sight of perl
23:12 allison lucian: aye, my ultimate goal is to write the Python compiler differently (as you heard in my talk), but these tools are quite far along
23:12 allison lucian: it's a good boot-strap
23:13 allison lucian: don't think of it as perl, just think of it as a declarative DSL
23:14 lucian allison: yes, i get that it's a bootstrap. i'll have to supress my instincts
23:19 lucian allison: i rather like pir. it is indeed the nicest assembly i've ever seen
23:19 Whiteknight joined #parrot
23:20 allison lucian: it's a good language, simple and powerful
23:22 particle except where it's messy and ugly
23:22 particle sure would be nice to get failure semantics cleared up.
23:26 dalek parrot: r44832 | tewk++ | trunk (7 files):
23:26 dalek parrot: Added Parrot_str_is_null, DEPRECATED Parrot_string_* and STRING_is_null
23:26 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44832/
23:32 Whiteknight did PBC_COMPAT bump recently?
23:33 tewk Whiteknight, are you working on init_int?  I've decided to just bust it out, half way done already
23:34 tewk I've got everything done but the vtable, I don't remember how to do those, looking
23:34 chromatic If you benchmark it, we'll get the biggest gains from adding it to CallContext and fixing the "Allocate one cell at a time" nonsense there.
23:35 chromatic If you're looking for an example of my "make it work, then make a pretty pass" philosophy, the allocation strategy in CallContext is certainly an example of something.
23:36 tewk chromatic, I'm motivated by fixing fixed*arrays but I'll paste a patch
23:36 tewk soon
23:38 chromatic Do you consider them buggy or merely inefficient?
23:41 tewk I'm willing to live with data race conditions (who wrote to an array location last) but having to lock on every read and write to the array (sequential consistency) just to see if the array is allocated yet seems wasteful.
23:42 particle can't you emit two instructions for array creation?
23:42 chromatic Arguably you won't have anything sharing an array before you've finished creating it.
23:43 tewk particle, sure, but I'm trying to carve out a set of opcodes that have safety properties.  And build a runloop that only allows safe instructions.
23:44 dalek parrot: r44833 | whiteknight++ | trunk/src/global.c:
23:44 dalek parrot: allow adding of :anon :vtable Subs to the namespace. This technically resolves TT #1505, though some cleanup and performance improvements in this area would be welcome additions later
23:44 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44833/
23:46 tewk if fixed*arrays' actuall data array is allocated when the fixed*arrays is created I know that sets and gets to fixed*arrays are safe.
23:46 cotto_work tewk, opsrenumber is only run rarely, so enumops.h should probably be checked in or built as part of the build process
23:46 cotto_work also, ops_enum.h would be a subjectively nicer name
23:47 tewk cotto_work, feel free to fix it
23:47 cotto_work ok
23:47 chromatic +1 to ops_enum.h.
23:47 tewk I check things in so others can make them better :)
23:48 tewk yeah I like it too, +1 I was trying to hard to be consistent to enum_class_ in the filename.
23:48 Whiteknight I check things in so that they may be absolutely perfect the first time!!!
23:48 * Whiteknight lies
23:49 chromatic I like the whole idea, not just the name.
23:49 tewk imperfect checkins helps motivate newcomers that they can contribute too :)  I believe in the bazaar.
23:50 allison ooh, I forgot to mention in my report, Parrot 2.0 is in Debian and Ubuntu Lucid
23:50 japhb yay!
23:51 cotto_work nice
23:52 Whiteknight allison: I would like to learn more about the whole debian packaging process
23:52 tewk howto add a vtable docs?  I added a line to src/vtable.tbl,  now what?
23:52 chromatic Have you heard of the description of Usenet as a stampede of elephants?
23:53 allison Whiteknight: happy to pass along info, get people started
23:53 Whiteknight chromatic: that metaphor never accounted for the huge volumes of porn on usenet. To my knowledge, most elephants are not obsessed with porn
23:53 japhb chromatic, It is just so much more painful than that
23:53 allison Whiteknight: I figure we'll have quite a few packages coming up for various languages
23:53 japhb Whiteknight, only because they haven't been provided with elephant-friendly cameras
23:53 Whiteknight allison: how painful is it? With the infrastructure in place now, how hard is it to get a release into the package repos?
23:54 dalek TT #1505 closed by whiteknight++: :anon vtable overrides don't work in PIR
23:54 Whiteknight japhb: they say the camera adds 15,000 lbs
23:54 chromatic Besides the large quantities of processed elephant food the process produces, it also produces large amounts of arguing over the legal intent and interpretation of non-legal documents written by non-lawyers and interpreted by non-lawyers.
23:54 allison Whiteknight: it can be slow, but patient persistence seems to do it
23:55 tewk plumage should provide a autopackage for debian/ubuntu,  how I wish cpan had that feature
23:55 allison tewk: that would be great
23:55 Whiteknight allison: (patient persistance) damnit! I was hoping I could help!
23:55 japhb fperrad++ has been doing a great job of making Plumage metadata for everything under the sun.  That should be a very useful boost for doing system packages.  (Plus I think distutils does/will have some ability to make packages on its own)
23:55 allison tewk: some custom rolling likely still needed, but the common cases can be tackled
23:55 japhb Whiteknight, (re: 15000 lbs) *chuckle*
23:56 tewk allison, right, but it should do 95% of the work
23:56 japhb tewk: Plumage + distutils seems to be a powerful combo.
23:57 tewk japhb, I need to take a look at it sometime, nqp-nx too, I spend all my time in the c guts of parrot and PLT Scheme.
23:57 japhb nodnod
23:57 * chromatic didn't realize PLT Scheme had a lot of C guts.
23:58 tewk Yes it has a lot, we want to get rid of them but we have less man power than parrot and a lot more complex, complete features.
23:58 tewk it grew out of libscheme and has its C roots from there.
23:59 chromatic In the words of the tenth Doctor, "I'm sorry.  I'm so sorry."

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

Parrot | source cross referenced