Camelia, the Perl 6 bug

IRC log for #parrot, 2009-09-07

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 darbelo dukeleto: I'm testing a hack to get you going, wait for the nopaste.
00:01 dukeleto darbelo: coolio
00:01 dalek TT #984 created by dukeleto++: pluggable_runcore branch merge broke build on darwin
00:02 mikehh Coke: all passed at r41080, multiple segfaults at r41081, fewer at r41083 and different results at r41086 in three runs
00:02 nopaste "darbelo" at 190.3.155.110 pasted "Quick hack for dukeleto++ (darwin--)" (18 lines) at http://nopaste.snit.ch/17856
00:03 darbelo dukeleto: See if that patch fixes your build.
00:04 darbelo You'll need a realclean too.
00:05 dukeleto darbelo; trying now
00:08 dukeleto darbelo: compiles and passes coretest. do you have a commit bit ?
00:08 darbelo nope.
00:09 darbelo You should copy the modified file into config/gen/platform/darwin/hires_timer.c and revert the original.
00:10 dukeleto darbelo: anything else?
00:10 purl anything else is violating dry. and we're in the wrong channel.
00:11 darbelo You might have to alter MANIFEST, but the Configure system should notice the platform-specific file and ignore the generic one.
00:12 dukeleto darbelo: yes, it seems to
00:13 chromatic Hm, anyone want fewer PMCProxy PMCs created?
00:13 Tene I do!
00:14 darbelo dukeleto: You might also want to check the sanity of the profiling runcore's output.
00:15 dukeleto darbelo: how do I do that?
00:17 dalek parrot: r41087 | dukeleto++ | trunk (2 files):
00:17 dalek parrot: [build] Fix build on darwin by using gettimeofday instead of clock_gettime, darbelo++, darwin--
00:17 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41087/
00:17 dukeleto please test the latest trunk on your platform to make sure nothing wonky is going on
00:18 dukeleto i am sure ttbot will pipe up soon if I b0rked something
00:18 dukeleto karma darwin
00:18 purl darwin has karma of 12
00:18 dukeleto darwin--
00:20 chromatic Hm, a 10.51% improvement.
00:21 darbelo dukeleto: try parrot -R profiling some/file.pir ; also nothing broken here.
00:22 dukeleto darbelo: the file gets generated. how do I view the info in it?
00:23 darbelo dukeleto: Your favorite text editor. It's ascii
00:24 dukeleto darbelo: i can see that. i want pretty visualizations :)
00:25 dalek TT #984 closed by dukeleto++: pluggable_runcore branch merge broke build on darwin
00:26 nopaste "chromatic" at 72.87.39.97 pasted "Reduce PMCProxy Creation" (40 lines) at http://nopaste.snit.ch/17857
00:26 chromatic mikehh, Tene, Coke, can you test that patch with your languages?
00:26 dukeleto i would also like a flying unicorn that prints $20 bills
00:27 Tene chromatic: just verify that the languages don't fail?
00:27 chromatic Yes.
00:27 chromatic If you note any speed improvements, I'm happy to hear that too.
00:27 darbelo dukeleto: Oh. tools/dev/pprof2cg.pl will convert that to a callgrind-compatible profile. You'll have to bug cotto++ for the rest, the profiling runcore is his fault :).
00:29 Tene chromatic: steme passes... working on cardinal now
00:31 Tene looks like cardinal HEAD is broken
00:31 chromatic With the patch or without?
00:32 Tene I haven't tried it recently at all.  It fails with "Not a throwable object", which looks unrelated to your patch.
00:32 chromatic Sounds unrelated.
00:32 Tene lemme check
00:33 darbelo Tene: treed mentioned breakage the list time he was arround. It had something to do with parrot_config being broken on his platform, IIRC.
00:33 Tene darbelo: nobody else has been able to reproduce parrot_config breakage, have they?
00:34 darbelo I have no idea, I think mikeh has been testing Cardinal regularly whithout it affecting him. But I could be misremembering that.
00:34 Tene chromatic: looks like cardinal compiles fine without the patch, and fails with the patch.
00:35 Tene treed: what failure are you seeing in parrot_config, and on what platform?
00:35 dalek TT #985 created by dukeleto++: proper Configure.pl-time check for hires timers
00:35 chromatic Tene, you might need to realclean.
00:36 Tene chromatic: Oh.  i cna do that.
00:36 Tene rebuilding.
00:38 Tene chromatic: it still fails, even after realclean.
00:39 chromatic Okay.  Hm.  Do you have any Classes with the same name as internal PMCs?
00:41 nopaste "tene" at 24.10.252.130 pasted "Cardinal's classes for chromatic++" (49 lines) at http://nopaste.snit.ch/17858
00:43 chromatic That's not it either then.
00:44 chromatic This should only change the $P0 = new 'SomeString' and $P0 = new $S0 cases
00:44 Tene chromatic: seems to come from somewhere in here: http://shorl.com/fekodrubodyli
00:45 Tene Oh, that might not be helpful.
00:45 chromatic Not as much as the corresponding PIR.
00:46 chromatic My guess is that it's one of the return lines, but that's just a guess.
00:46 Tene Yes, well, that would be easier if imcc line reporting worked. :)
00:47 Tene Yes, it's one of those.
00:47 nopaste "tene" at 24.10.252.130 pasted "relevant pir for chromatic++" (12 lines) at http://nopaste.snit.ch/17859
00:47 chromatic My guess is the Exception line.
00:48 Tene it gets down to the throw opcode... if I print the typeof of the exception, it says it's of type CardinalException, which is *not* an exception.
00:48 Tene cardinalexception has-a exception.
00:48 chromatic Oh.
00:48 Tene iirc
00:49 chromatic Could be the HLL map.
00:49 Tene Ah, no, it was refactored since I last looked.  Now it inherits from parrot;Exception and CardinalObject.
00:49 Tene But, yes, it's hll_mapped.
00:49 chromatic If you have a map between Exception and CardinalException, this'll create that type instead.
00:49 chromatic I can see how that would be wrong.
00:50 chromatic Revert that bit, and let's see what happens.
00:50 Tene should NQP be generating a root_new for that?
00:50 chromatic If you have the core PMC type name there directly... I say no.
00:52 Tene OK, realcleaning and rebuilding now.
00:54 Tene That is, should NQP use root_new to implement 'return'?
00:54 chromatic I don't know.
00:55 Tene although, this *should* work fine if we were able to subclass PMCs from PIR.
00:55 Tene Which we can't do now anyway.
00:55 chromatic This might be the wrong place to fix it.
00:55 Tene Yes, cardinal compiles fine with the first part reverted.
00:56 Tene s/compiles/runs/
00:56 Tene I'd be okay with reverting cardinal, though, because that part doesn't work anyway.
00:57 chromatic I think this is the wrong approach though.
00:58 chromatic Parrot_oo_get_class_str probably shouldn't cause the *creation* of PMCProxy PMCs.
00:58 chromatic When called from these ops, all we want to know is if there's a class of that name.
00:58 chromatic Barring that, instantiate the appropriate PMC directly.
00:59 chromatic PMCProxy is only necessary when there *is* a class of that type.
01:04 chromatic Maybe we need to rethink PMCProxy in general.
01:04 ttbot Parrot trunk/ r41087 cygwin-thread-multi-64int make error http://tt.ro.vutbr.cz/file/cmdout/84084.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
01:04 dalek parrot: r41088 | jrtayloriv++ | branches/gc-refactor (18 files):
01:04 dalek parrot: Renamed Arenas to Memory_Pools, renamed Fixed_Size_Obj_Pool to Fixed_Size_Pool, updated pdd09 and memory_internals.pod
01:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41088/
01:04 chromatic In theory, we only need it when something subclasses a builtin PMC.
01:17 Whiteknight joined #parrot
01:19 Andy joined #parrot
01:20 tetragon joined #parrot
01:21 japhb Progress!  evaling in language: json
01:21 japhb Null PMC access in find_method()
01:21 * japhb iterates
01:22 Whiteknight pluggable_runcore was almost as disruptive as context_pmc3
01:23 Whiteknight and definitely the current poster child for "short-lived branches"
01:25 japhb (unable to rebase continuously)--
01:26 darbelo Whiteknight: accurate or portable. When it concerns time you can get, at most, one.
01:30 darbelo I would have never expected darwin to lack cloack_gettime, specially if it's trying to pass itself off as UNIX :)
01:31 dalek parrot: r41089 | dukeleto++ | trunk (2 files):
01:31 dalek parrot: [t] Improve the diagnostic message of like() in test_more.pir
01:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41089/
01:38 kid51 joined #parrot
01:59 kid51 Whiteknight:  Is https://trac.parrot.org/parrot/ticket/926 closable?
02:02 Whiteknight closed. Thanks
02:02 sri joined #parrot
02:02 dalek TT #926 closed by whiteknight++: Kill Parrot_cont structure
02:21 ttbot Parrot trunk/ r41089 cygwin-thread-multi-64int make error http://tt.ro.vutbr.cz/file/cmdout/84164.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
02:30 darbelo nopaste?
02:30 purl nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/ or http://paste.scsys.co.uk (for #catalyst, #dbix-class, #moose  and others) or http://gist.github.com/ or paste or gtfo
02:32 nopaste "darbelo" at 190.3.155.110 pasted "[PATCH] Fix the cygwin build, I hope." (12 lines) at http://nopaste.snit.ch/17860
02:33 darbelo Is anyone on cygwin available to test http://nopaste.snit.ch/17860 ? I think that's what needed to fix ttbot's last complaint.
02:36 janus joined #parrot
02:38 dalek parrot: r41090 | jrtayloriv++ | branches/gc-refactor/src/gc (8 files):
02:38 dalek parrot: Replaced Fixed_Size_Obj_Arena with Fixed_Size_Arena, and corrected some minor errors resulting from last sed replacement.
02:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41090/
02:38 Andy joined #parrot
02:46 darbelo msg cotto ttbot reported a broken cytgwin build (http://tt.ro.vutbr.cz/file/cmdout/84164.txt), after some online research I think http://nopaste.snit.ch/17860 should fix it.
02:46 purl Message for cotto stored.
02:51 cotto i'm here
02:51 cotto (haven't checked the backscroll yet though)
02:53 cotto yay.  another platform with unreliable profiling information.
03:07 cotto dukeleto, a Configure.pl-based approach to finding the best timing function would be ideal.  Do you want to work on it or should I toss it on my todo list?
03:07 dukeleto cotto: tis all yours
03:07 cotto nuts
03:08 cotto ;)
03:10 dukeleto cotto: nice try ;)
03:11 cotto I wonder if I could suc^H^H^Hconvince anyone else to do it.
03:12 cotto at least Devel::NYTProf is there to steal from
03:13 dukeleto cotto: darbelo seems to be pumping out patches. give him a bit already!
03:14 cotto darbelo, did you ever send in a CLA?
03:15 cotto I may be forced to nominate you for a +2 bit of committing.
03:21 japhb Tene, ping
03:21 Tene japhb: pong
03:22 japhb For a normal HLL, the sequence is load_language, compreg, .'compile'(), then tailcall the result of the .'compile'(), yes?
03:24 Tene depends on whether you want to trap errors or not.
03:24 Tene .tailcall for not trapping errors, push_eh, invoke, pop_eh, handler for trapping errors
03:25 japhb Then for a deserializer, like JSON or XML or YAML or whatever, I'm thinking the .'compile'() returns a sub that will the build the data structure represented by the textual input.  So when you tailcall that, you get the deserialized structure.
03:25 japhb OK, sure.
03:25 Tene Right.
03:25 japhb (And we should do the error-trapping sequence in the NQP version.)
03:25 japhb s/version/implementation of eval/
03:25 Tene A standing question is what NQP's eval should return on error.
03:26 Tene I think that right now it returns undef
03:26 japhb it literally returns the result of the final call.
03:26 japhb it's effectively a tailcall without the scope smush
03:27 japhb Although ... it's NQP.  Maybe the nakedness of that is appropriate.
03:27 japhb Meaning, eval != try
03:28 japhb or rather eval !~ try
03:28 Tene Sure.
03:30 japhb It looks like the JSON language was not based on PCT, though it uses PGE (and possibly TGE).  I'm figuring out how to do the conversion to PCT (in between chasing @children)
03:31 Tene japhb: it doesn't need to use PCT, as long as it responds to .compile()
03:31 japhb Tene, true enough
03:32 Andy joined #parrot
03:35 tetragon joined #parrot
03:42 darbelo cotto: no CLA, but I can send one.
03:43 cotto darbelo, if you want a commit bit I'll be glad to nominate you.  It's your call.
03:45 darbelo Sure, nominate me. I'll print-sign-send the CLA tomorro^Win the morning.
03:48 sri joined #parrot
04:00 cotto will do
04:04 treed The breakage I experience is now directly Cardinal related.
04:04 treed It's bug 977.
04:04 treed And there was no refactor.
04:04 treed Cardinal's exceptions started that way.
04:04 treed And I haven't moved them to the has-a model yet.
04:04 Tene treed: I was remembering Proc or something else.
04:05 treed Ah.
04:05 treed Proc is mega-broken.
04:05 Tene Yeah.
04:05 treed There's a rewrite scheduled in a few hops.
04:06 treed I just need to get this Object model rewrite nailed down.
04:06 treed I ran into a problem and haven't had time to investigate it yet.
04:07 treed Once that's in, there's a bunch of stuff that can happen.
04:09 treed And I move in like a week.
04:09 treed So tuits will be pretty limited for a while.
04:09 treed (Starting my new job.)
04:09 Tene treed: I don't know how much scrollback you read... I was testing a potential patch to parrot for chromatic.
04:09 theory chromatic: search on modernperlbooks.com returns a 500.
04:10 treed I just tried to look at highlights.
04:10 treed So anything that mentioned cardinal or my name.
04:10 treed but only so far back
04:10 theory Oops, that should have been a /msg. Apologies.
04:10 treed What was the potential revert on Cardinal?
04:11 Tene treed: it would have made "new 'Exception'" obey HLL mappings, which breaks 'return' because you can't throw a CardinalException.
04:12 Tene because PIR subclasses of PMCs are broken.
04:12 Tene It would mean that we'd have to turn off the Exception HLL mapping until it worked.
04:12 treed Oh, yeah.
04:12 Tene He decided to investigate another way to do it anyway.
04:12 treed I intended to change CardinalException to has-a soonish, anyway.
04:12 treed So rather than reverting, could just do that.
04:13 Tene right.
04:13 chromatic We need to fix PIR subclassing before I can do what I want to do.
04:13 Tene treed: you really don't even need to do that... just change the 'throw' into shoving the thrown thing into the payload of a parrot exception.
04:14 treed Oh, yeah.
04:14 treed that was the idea
04:14 treed It's written down in the issue.
04:14 cotto Is TT #952 a valid ticket?  I don't see the point of a ticket about failing tests in a branch.
04:14 Tene yeah
04:14 treed chromatic: Fixing PIR subclassing would be awesome.
04:14 treed My current Cardinal project is a new object model.
04:15 chromatic It's probably more important than most other things.
04:15 treed ANd my classes and metaclasses and eigenclasses have to be has-a parrot;Class.
04:15 treed Which is so inordinately complicated and confusing.
04:15 Tene There's now a patch for tt#744, which works around a weird bug elsewhere, but allows HLL interop for my scheme compiler.
04:17 chromatic Hm, we could almost make auto_attrs work for PIR classes....
04:22 darbelo Hmm. What sort of information does the pmc compiler need to automagically 'map' c structure types to unmanaged struct PMCs?
04:23 chromatic Offset into the structure.
04:23 japhb Gah.  My brain is not working properly.  How do I create a compiler object that does both the '$P0 = compreg "foo"; result = $P0("input")' interface and the '$P0 = compreg "foo"; compiled = $P0."compile"("input"); result = compiled()' interface?
04:24 Tene japhb: the only way to do that is to have :vtable('invoke') on some class, and you can't do that from PIR
04:24 japhb Well, that would explain why my brain is not functioning.
04:24 Tene so... either make a PMC, or abandon the $P0(...) interface.
04:24 Tene japhb: although, there's a dirty solution here...
04:25 Tene well, depending on whether compreg downcases.  I don't remember if it does.
04:25 japhb curiosity peaked ...
04:25 japhb "downcases"?
04:25 Tene if it doesn't, you could just register the function as compreg 'JSON' and the object as compreg 'json'
04:25 japhb oh.  Ouch.
04:26 Tene Well, if you're renaming it anyway...
04:26 Tene it's... um... compatibility.  leaving ht eold interface in place, kind of.
04:26 Tene >.>
04:26 Tene I recommend just dropping the old one.
04:26 japhb But I can't have both on the same filesystem.
04:26 japhb (on all platforms)
04:26 japhb yeah, going to.
04:32 japhb Tene, so the proper way to "manually" register a compiler that uses the .compile() interface would be: in the onload sub, do '$P1 = newclass "Foo"; $P2 = new ["Foo"]; compreg "Foo", $P2'   ?
04:33 dalek parrot: r41091 | dukeleto++ | trunk/t/library/test_more.t:
04:33 dalek parrot: [t] Add another test for like() for matching partial literal strings
04:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41091/
04:42 Tene japhb: that's right.
04:43 sri joined #parrot
04:45 japhb Tene, bah.  It's not working.  I'm missing something obvious, I think.
04:45 japhb nopaste?
04:45 purl nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/ or http://paste.scsys.co.uk (for #catalyst, #dbix-class, #moose  and others) or http://gist.github.com/ or paste or gtfo
04:45 Tene japhb: nopaste is also tools/dev/nopaste.pl
04:45 purl okay, Tene.
04:46 japhb Hmmm, I wonder where I accidently sent that ...
04:47 nopaste "japhb" at 76.191.190.8 pasted "Compiler class for JSON" (61 lines) at http://nopaste.snit.ch/17862
04:49 Tene japhb: and what doesn't work about that?
04:49 japhb I've gotten each of these:
04:50 japhb Class '[ 'JSON' ]' not found
04:50 japhb current instr.: '__onload' pc -1 ((unknown file):-1)
04:50 japhb Class JSON already registered!
04:50 japhb current instr.: 'parrot;P6metaclass;new_class' pc 884 (runtime/parrot/library/P6object.pir:549)
04:50 japhb called from Sub 'parrot;JSON;__onload' pc -1 ((unknown file):-1)
04:50 japhb evaling in language: json
04:50 japhb Null PMC access in find_method()
04:50 japhb current instr.: 'eval' pc 36714 (src/builtins.pir:145)
04:50 * jrtayloriv goes night night ... zzzzzzz
04:50 japhb A tad frustrating, because I can't cargo cult a solution.  :-)
04:51 Tene japhb: 'sec, lemme try something...
04:51 chromatic Hm, the profiling core aborts for me on trunk.  Lovely.
04:51 japhb Tene, if you're trying my file locally, note that in the install tree I symbolic linked json.pbc -> JSON.pbc, so the case smushing would be happy.
04:52 Tene japhb: you also need to use .HLL 'json', compreg 'json', etc.
04:52 japhb Tene, sigh, OK.
04:52 japhb Partial case flattening sucks.
04:53 nopaste "tene" at 24.10.252.130 pasted "This doesn't fail, and seems to work..." (57 lines) at http://nopaste.snit.ch/17863
04:53 Tene How does that look, japhb?
04:53 dalek parrot: r41092 | dukeleto++ | trunk/t/library/test_more.t:
04:53 dalek parrot: [t] Add test for dealing with spaces in like()
04:53 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41092/
04:54 japhb Tene, merging with my local copy ....
04:55 cotto chromatic, what happens?
04:56 chromatic Run it on a pbc file.
04:56 chromatic src/pmc_freeze.c:1336: failed assertion 'must_have_seen'
04:57 japhb YES!
04:57 japhb THANK YOU TENE!
04:57 japhb Tene++
04:57 japhb Frack some of that is non-obvious
04:59 Tene Like I said, this really really sucks, but it's far easier to just lowercase all HLL names everywhere always than to try to work out when you can and can't, or to fix it.
04:59 nopaste "cotto" at 74.61.2.46 pasted "successful attempt to profile a pbc file" (31 lines) at http://nopaste.snit.ch/17864
05:00 chromatic Hm.  Maybe I should rebuild this PBC.
05:01 chromatic That worked.  Hm.
05:01 cotto sounds like it could be a stale pbc issue
05:02 chromatic Sounds like it was.
05:08 cotto does the pbc file contain line numbers from the pir source?
05:08 chromatic I don't think so.
05:08 chromatic I'm not really sure.
05:10 cotto I don't think it'll matter too much.  If the profiler thinks all instructions come from the same line, it'll still get the subs right.
05:10 dalek parrot: r41093 | dukeleto++ | trunk/t/library/test_more.t:
05:10 dalek parrot: [t] Fix tests for like() which passed for the wrong reason
05:10 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41093/
05:11 cotto That's a good test case, though.
05:13 ttbot Parrot trunk/ r41092 cygwin-thread-multi-64int make error http://tt.ro.vutbr.cz/file/cmdout/84330.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
05:15 chromatic Wow.  src/pmc_freeze.c is full of scary.
05:16 Tene srsly
05:18 cotto mj41++ for having your bot notify me that I didn't actually commit the fix for that failure.
05:20 dalek parrot: r41094 | cotto++ | trunk/config/init/hints/cygwin.pm:
05:20 dalek parrot: [profiling] use CLOCK_REALTIME on cygwin
05:20 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41094/
05:23 * darbelo fears that his strstart killing travels will lead him into that file.
05:23 chromatic Oh they will....
05:24 dalek parrot: r41095 | chromatic++ | trunk/src/pmc_freeze.c:
05:24 dalek parrot: [src] Tidied code in src/pmc_freeze.c.  It's still scary, but at least it's
05:24 dalek parrot: slightly more readable.
05:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41095/
05:24 darbelo Yeah. It's the biggest concentration of strstart outside of the src/string directory.
05:25 darbelo chromatic++ # Making the scary readable.
05:27 cotto chromatic, if it helps, ascii freeze/thaw has been broken since forever.  I'm reasonably sure that it never worked.
05:28 ttbot Parrot trunk/ r41093 cygwin-thread-multi-64int make error http://tt.ro.vutbr.cz/file/cmdout/84396.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
05:29 cotto It'd be nice if the *_ascii_* functions worked, but it might be better just to rip them out.
05:30 dalek parrot: r41096 | dukeleto++ | trunk/t/pmc/namespace.t:
05:30 dalek parrot: [t] Refactor some namespace pmc tests to use throws_like
05:30 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41096/
05:31 chromatic I don't know much about this code; I wouldn't know how to figure out how to use the ASCII versions.
05:31 chromatic Test writers, we need tests for TT #800.
05:32 cotto There's a FREEZE_ASCII define that makes it easy to switch to the broken functions.
05:33 dalek TT #921 closed by chromatic++: warnings in imcc/imcparser.c (statement with no effect)
05:36 cotto we should throw our bacek at that code
05:36 Tene ... um... this was segfaulting on exit until I tried running it under gdb, and now it doesn't segfault on exit anymore.
05:36 * Tene considers shutting down the laptop for a memtest run.
05:37 chromatic cotto, did we fix TT #898?
05:37 cotto checking
05:38 cotto chromatic, no.  I'll do that now.
05:40 dalek TT #506 closed by chromatic++: generate callgrind output
05:40 dalek TT #969 closed by dukeleto++: Convert t/pmc/float.t to PIR
05:40 dukeleto Tene: reverse heisenbug
05:41 dalek parrot: r41097 | dukeleto++ | trunk/t/pmc/float.t:
05:41 dalek parrot: [TT #969][t] Convert t/pmc/float.t to PIR, flh++
05:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41097/
05:41 dalek parrot: r41098 | tene++ | trunk/ext/SQLite3/SQLite3.pir:
05:41 dalek parrot: [SQLite3]: Add a few needed functions.  This should be moved to library/ eventually.
05:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41098/
05:44 treed dukeleto: Erm.
05:44 treed Re: your comment on my bug.
05:44 treed Why wouldn't I be using an installed parrot?
05:45 treed I'm asking the installed parrot for its build_dir.
05:45 Tene treed: link?
05:45 treed https://mail.google.com/mail/?ui=2&​amp;view=bsp&ver=1qygpcgurkovy
05:45 treed er
05:45 treed https://trac.parrot.org/pa​rrot/ticket/977#comment:10
05:46 treed Regardless, an installed parrot_config should not be returning that error.
05:46 treed Removing the installed parrot is kinda like removing someone's head because they have a headache.
05:47 dalek TT #986 created by darbelo++: [PATCH] Further ->strstart removals
05:47 kyle_l5l joined #parrot
05:47 Tene treed: cardinal really should only be using the install dir, not the build dir, which is a completely separate issue.
05:47 treed Tene: I cribbed that from the Makefile.
05:47 Tene Yeah.
05:47 treed If you want to tell me how to use an installed parrot, I'll fix it.
05:47 Tene That was from before Parrot even had an install.
05:47 chromatic We have had ~30 commits per day in the past week.
05:48 Tene treed: or I could even fix it myself... *GASP*
05:48 treed Heh.
05:48 * Tene trolls himself.
05:48 treed You could, although you'd need to modify the Rakefile for that.
05:48 Tene I can do that just fine.
05:48 Tene I have an editor.
05:48 treed k
05:48 treed Don't break it.
05:49 Tene That's what I told her.
05:49 treed (It's been getting kinda nasty/convoluted lately.)
05:49 treed I want to reorganize it.
05:49 Tene want to borrow my editor?
05:49 treed Put all the configuration stuff in one place, all the testing stuff in one place, all the convenience functions in one place.
05:49 treed Nah, I've got my own.
05:49 treed I think yours wouldn't run on OS X without a recompile anyway.
05:50 Tene oh right... maybe I should rewrite it to run on Parrot first.
05:50 dalek TT #884 closed by dukeleto++: parrot_debugger generates a Bus error if you set a break point before the ...
05:50 dukeleto why is there no Trac component for "tools" ?
05:51 Tene dukeleto: I doubt there's a reason, and I doubt anyone would object to it being added.
05:52 dukeleto Tene: can i add one myself?
05:52 dukeleto Tene: i don't think i have the permissions
05:52 Tene dukeleto: I have no idea what the permissions are like on trac.
05:52 Tene I recommend a mail to the list, or opening a ticket about it.
05:53 Tene I'm done for the evening...
05:53 dalek TT #987 created by dukeleto++: Make breakpoints actually work in parrot_debugger
05:54 cotto chromatic, would it be a Bad Idea to have a PMC's VTABLE* be a static variable in Parrot_Foo_get_vtable()?
05:55 chromatic Thread safety might be interesting.
05:55 chromatic I don't see any memory leaks in PIR hello, world though.
05:56 cotto TT #898 leaks would only occur if you hit dynpmc code that called SUPER
05:56 chromatic Ah.
05:56 chromatic I do see leaks there now.  Grr.
05:57 dalek TT #988 created by dukeleto++: Add component "tools" to Trac
05:57 chromatic Parrot_gc_get_attributes_from_pool is leaky.
05:58 Tene dukeleto: that ticket is about trac... you should set its component to 'tools'.
06:00 dukeleto Tene: please see recursion
06:03 cotto chromatic, what about something like this:
06:03 nopaste "cotto" at 74.61.2.46 pasted "thread-safer vtable creation with a static VTABLE*" (17 lines) at http://nopaste.snit.ch/17865
06:04 chromatic I don't understand it full.
06:04 chromatic fully
06:06 cotto create a normal vtable and update the pointers as the PMC's inheritance requires.  Then check if another thread has already initialized and only set the vtable if it hasn't.
06:06 cotto (and obvious optimization is to check at the beginning too)
06:07 cotto that minimizes the amount of time when multiple threads could step on each other's toes
06:08 cotto s/and/an/
06:09 cotto This way the function will always return the right VTABLE*, but it won't need to be freed except at interp destruction.
06:10 cotto It's not perfectly thread-safe, but it'd probably be good enough for something like pmc initialization.
06:13 cotto actually, interp destruction is a problem with that approach.
06:30 dalek parrot: r41099 | cotto++ | trunk/lib/Parrot/Vtable.pm:
06:30 dalek parrot: [VTable] make some comments less irritating and more informative
06:30 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41099/
06:41 cotto chromatic, I'm sure of the right way to solve that bug.  The problem is that the interface requires a function with a single argument (interp) to get the VTABLE* when I don't know the index into the vtable** to use.
06:41 cotto s/sure/not sure/
07:28 dalek parrot: r41100 | chromatic++ | trunk/src/gc (2 files):
07:28 dalek parrot: [GC] Fixed a memory leak in the GC by freeing attribute pools during final
07:28 dalek parrot: destruction.
07:28 purl destruction is, like, http://www.kuro5hin.org/story/2004/11/11/143618/87
07:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41100/
07:34 fperrad joined #parrot
07:37 dalek wmlscript: 275e370 | fperrad++ | t/pmc/ (10 files):
07:37 dalek wmlscript: refactor PIR tests with ok & nok (instead of is)
07:37 dalek wmlscript: review: http://github.com/fperrad/wmlscript/commit​/275e3706c6946013d17be43000618ac8d967e0ff
08:18 Zak joined #parrot
08:31 kentnl joined #parrot
08:33 dalek parrot: r41101 | mikehh++ | trunk/config/gen/platform/darwin/hires_timer.c:
08:33 dalek parrot: set svn properties
08:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41101/
08:33 dalek TT #988 closed by coke++: Add component "tools" to Trac
08:34 dalek lua: fc8a480 | fperrad++ | t/pmc/ (16 files):
08:34 dalek lua: refactor PIR tests with ok & nok (instead of is)
08:34 dalek lua: review: http://github.com/fperrad/lua/commit/fc​8a480f02ae41b5f999d70d515076612f00dbe3
08:34 dalek lua: e0dd9cd | fperrad++ | t/pmc/ (3 files):
08:34 dalek lua: use better type register
08:34 dalek lua: review: http://github.com/fperrad/lua/commit/e0​dd9cd4aabae488388ad5d825b71ceb2cb68552
08:34 dalek lua: 718c326 | fperrad++ |  (2 files):
08:34 dalek lua: fix LUA_PBCPATH for build tree
08:34 dalek lua: review: http://github.com/fperrad/lua/commit/71​8c3264a522a7c505b3e531f839e99fc4063ca0
08:40 dalek parrot: r41102 | chromatic++ | trunk/src/pmc/integer.pmc:
08:40 dalek parrot: [PMC] Replaced some VTABLE calls with macro attribute access in Integer PMC.
08:40 dalek parrot: This speeds up the primes.pasm benchmark by 6.434%, no fooling.  Yes, it's a
08:40 dalek parrot: microbenchmark, but if you use Integer PMCs for flow control....
08:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41102/
08:40 dalek parrot: r41103 | chromatic++ | trunk/src/pmc/fixedpmcarray.pmc:
08:40 dalek parrot: [PMC] Tidied FixedPMCArray a minor amount; no functional changes.
08:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41103/
08:40 dalek parrot: r41104 | chromatic++ | trunk/src/gc/alloc_register.c:
08:40 dalek parrot: [Contexts] Avoided repeated calls to Parrot_pcc_get_context_struct() when
08:40 dalek parrot: allocating a new context (unintentional irony, yes) by clearing register
08:40 dalek parrot: contents directly.  A judicious use of memset() would likely be faster, but a
08:40 dalek parrot: 1.7% performance improvement in the fib.pir benchmark is reasonable.  Bigger
08:40 dalek parrot: register sets will have better performance here too.
08:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41104/
08:41 chromatic Hm, that one was a 3.316% performance improvement in Rakudo's "Hello, world!"
08:41 chromatic Very nice.
08:42 szbalint only 4987 such improvements left to go :)
08:46 chromatic I think I can get another 3.5% here shortly.
08:47 kentnl how is .parrot_current_rev generated ? my when I'm building parrot the .svn dir is removed from the build dir prior to configure, and its resulting in .parrot_current_rev == 0
08:47 kentnl I've poked around in the code and can't seem to see where it comes from
08:48 szbalint I roughly estimated last time using an Euler problem as a baseline and comparing things to P5 that PIR is about 10 times slower while Rakudo is about 13000 times slower than the algorithmically identical P5 code
08:48 chromatic PIR should be getting closer to P5 after this week.
08:48 szbalint I'm thinking of setting up benchmarking statistics gathering to visualize how PIR/Rakudo performance changes over time
08:49 szbalint I don't think it's currently tracked?
08:49 moritz szbalint: did you compile parrot with --optimize?
08:49 chromatic I talked to leto and notbenh about that at PDX.pm last week.  I'd like to see that.
08:49 moritz szbalint: it also hepls to use the fastcore as parrot runcore
08:49 szbalint yeah, I tried with a matrix of a couple of options
08:49 szbalint (on 32bit linux)
08:50 moritz did you use num / int registers, or PMC registers?
08:51 szbalint hm, let me nopaste the code. It's the first PIR I've ever written so it's possibly quite shoddy
08:52 szbalint http://scsys.co.uk:8001/33520
08:54 moritz I think that the reverse sub is quite inefficient, and I suspect there's a faster builtin
08:55 moritz but having not written much PIR code myself I don't know how off-hand
08:55 chromatic I was just looking at that.
08:55 szbalint oh
08:55 moritz I guess you just use scalar reverse in the Perl 5 version?
08:55 chromatic Even a resizable integer array would be faster.
08:55 szbalint yeah
08:56 chromatic Let's see.
08:56 szbalint http://github.com/perl6/perl6-exampl​es/blob/ca0f04ee06ee3f6b147062682fca​795c238d7117/euler/prob004-unobe.pl
08:56 szbalint P6 version
08:57 szbalint (I killed it after 110 minutes of runtime...)
08:58 szbalint http://scsys.co.uk:8001/33521
08:58 szbalint this is the P5 I've used
08:58 masak joined #parrot
09:04 dalek parrot: r41105 | mikehh++ | trunk/src/pmc_freeze.c:
09:04 dalek parrot: fix codetest failure and g++ build error
09:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41105/
09:06 cotto if those coding standards were worth anything, they wouldn't allow that file in the first place. ;)
09:06 * cotto proposes an AI-based codingstd
09:08 cotto good night
09:09 dalek lua: 2510c17 | fperrad++ | t/pmc/ (15 files):
09:09 dalek lua: more refactor, less stringify (typeof -> isa)
09:09 dalek lua: review: http://github.com/fperrad/lua/commit/25​10c17a2a912c0454389a2ef94f4df8a4623420
09:20 chromatic How'd you like it three times faster, szbalint?
09:20 nopaste "chromatic" at 72.87.39.97 pasted "Euler #4 in PIR, faster" (47 lines) at http://nopaste.snit.ch/17866
09:21 szbalint =)
09:21 chromatic 1.833 seconds for me, with the fast core.
09:21 moritz don't we have a string reversal method in parrot?
09:21 chromatic The fast core for your version is 8.162 seconds.
09:22 chromatic If you want to go faster, manually inline the reverse function.
09:22 szbalint yeah, it is indeed a lot faster :)
09:27 chromatic Algorithmically I can get it faster.  Hold on.
09:28 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41105 - Ubuntu 9.04 amd64 (g++)
09:28 szbalint yeah, the exercise is: http://projecteuler.net/index.​php?section=problems&id=4
09:28 chromatic Ah, you can figure it out.  It's late here.
09:29 chromatic Change 'reverse' to 'is_palindrome' and you'll see the improvement.
09:29 purl chromatic: that doesn't look right
09:29 chromatic You can bail out a few ops early.
09:29 szbalint it's also possible to count down the loop and quit yeah
09:29 szbalint *quit early
09:31 szbalint that should give an improvement about 10x, but I just wanted to compare the P5/PIR/P6 versions, changing the algorithm doesn't really help to measure relative speed
09:31 chromatic Right.
09:32 gaz joined #parrot
09:32 chromatic The Perl 5 version (without debugging symbols and such) is about four times faster than my PIR version.
09:33 szbalint same for my version
09:33 chromatic Let's inline.
09:34 chromatic After inlining, they're about the same.
09:34 chromatic Perl 5 may be ~10% faster.
09:34 mokurai left #parrot
09:35 chromatic Now without debugging enabled in Parrot....
09:41 szbalint with the JIT runcore, inlined it's about 40% faster for me than P5
09:41 szbalint (with debugging enabled in Parrot)
09:43 chromatic It's twice as fast as P5 for me with JIT and an optimized Parrot without debugging.
09:44 chromatic We're at the point where Parrot's startup time is significant.
09:45 szbalint Yep
09:48 Ron joined #parrot
09:49 mikehh rakudo (205733f) builds on parrot r41105 - make test / make spectest (up to r28196) PASS - Ubuntu 9.04 amd64 (g++)
09:52 chromatic I can live with twice as fast, for now.
09:52 szbalint so I guess that the gap between PIR and Rakudo is broader than I thought, while the gap between PIR and P5 is different :)
09:52 mikehh partcl r697 builds on parrot r41105 - make test Segmentation faults - Ubuntu 9.04 amd64 (g++)
09:53 szbalint I guess I'm more interested in the trend than the current speed, both for Parrot and Rakudo
09:54 chromatic Me too, but it's nice to know that the possibility exists to match P5 in speed currently.
09:54 szbalint yeah
09:55 szbalint although PIR is a lower abstraction level, so it's not entirely apples and oranges
09:57 chromatic Rakudo will never go faster than PIR.
09:58 chromatic I believe we can get parts of Rakudo as fast as PIR in certain circumstances.
09:59 mikehh partcl: ran make test twice - first time 13 test FAIL but only 4 subtests (all segfaults) - second time 15 tests FAIL (1 the same) but only 2 subtests (1 the same)
09:59 polyglotbot OUTPUT[Parrot VM: Can't stat languages/tcl/tcl.pbc, code 2.␤main: Packfile loading failed␤]
10:01 mikehh argh - don't use : after languages :-}
10:01 mikehh and also don't start a line with /
10:02 szbalint PIR is a lower bound in execution time for Rakudo, but I'd very much like Rakudo to end up faster than P5 eventually, which implies that PIR needs to be pretty fast too
10:07 mikehh decnum-dynpmcs r181 builds on parrot r41105 - make test PASS - Ubuntu 9.04 amd64 (g++)
10:07 HG` joined #parrot
10:08 treed Whoa.
10:08 treed Are you guys saying that Rakudo is faster than P5 already?
10:09 treed Or am I misunderstanding?
10:09 treed Or, wait.
10:09 mikehh cardinal - builds on parrot r41105 - rake test:all - same 3 failures - Ubuntu 9.04 amd64 (g++)
10:09 chromatic PIR needs to be ten times faster than equivalent P5 for Rakudo to be faster than P5, I think.
10:10 chromatic The good news is that we can achieve that.
10:10 jonathan Rakudo is decidedly not faster than P5 yet. :-)
10:10 mikehh lorito?, nqp?
10:10 * treed nods.
10:10 treed How much slower as it stands?
10:11 jonathan I'm not sure, the figures
10:11 jonathan vary quite a bit with program too.
10:12 treed But not abyssmally slow or anything.
10:12 treed (Unlike Cardinal. :-(
10:12 treed Even without Cardinal's parser the test suite takes 30 seconds on Parrot.
10:12 treed And 2 seconds with mainline Ruby.
10:12 chromatic Time to profile.
10:13 chromatic After sleep, anyhow.
10:13 treed heh.
10:13 treed Yeah, sleep time.
10:13 szbalint This particular instance I've tested was about 13000 times slower in Rakudo than in P5, but there are differences in the code. My uneducated guess would be about 100x difference for a lot of things...
10:14 szbalint I'm pretty sure with a bit of profiling the difference will go down drastically
10:18 mikehh ok - let's see if I can figure out those segfaults in partcl
10:22 jonathan treed: No, Rakudo is horribly slow too.
10:22 purl okay, jonathan.
10:23 jonathan Though I know some of the reasons why.
10:25 payload joined #parrot
10:26 mikehh messages
10:29 moritz be we NOW HAZ PROFILER!
10:29 moritz s/be/but/
10:35 jonathan Anyone ran it on Rakudo yet?
10:38 mikehh jonathan: I did in branch testing - haven't tried since
10:38 moritz jonathan: yes, I did
10:40 jonathan Nice. Any interesting results?
10:41 moritz I can put the file somewhere; I myself wasn't too enlightened by the results
10:41 mikehh got a 3MBmb file from perl -e 'say "HELLO"'
10:43 mikehh 3031775
10:43 moritz http://moritz.faui2k3.org/tmp/parrot.out.22749 for t/spec/S03-operators/comparison.t
10:44 mikehh supposed to be compatible with kcachegrind
10:53 Whiteknight joined #parrot
10:54 Whiteknight good morning #parot
10:54 Whiteknight or #parrot
10:57 jonathan mikehh: Yeah, I belive so - didn't work out how to run that yet, but will play with it at some point.
10:58 bacek joined #parrot
11:27 quek joined #parrot
11:43 masak joined #parrot
11:46 bacek O hai
11:49 Whiteknight morning bacek
11:50 bacek Whiteknight: welcome to the future :)
11:50 Whiteknight welcome to the past
11:50 szbalint :)
11:50 szbalint what a wonderful afternoon
11:51 Whiteknight szbalint: did you ever get your coretest times down?
11:52 szbalint yep
11:53 szbalint Test::Harness was outdated
11:53 szbalint that was the cause
11:54 bacek Whiteknight: can you fix NEWS please?
11:54 szbalint It went from 3 minutes down to 38s.
11:54 jrtayloriv Wow -- looks like we insomniacs have synchronized ourselves.
11:54 jrtayloriv Morning!
11:54 purl Mornings are great. Every time you experience morning, you're not dead yet!
11:54 dalek parrot: r41106 | whiteknight++ | trunk/src/pmc/coroutine.pmc:
11:54 dalek parrot: [pmc] a few simple cleanups and refactors of the coroutine PMC. Removed VTABLE_mark since it was just a redirect to SUPER.
11:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41106/
12:05 jrtayloriv Whiteknight, I just sent a message to the mailing list regarding the SVN problems -- seems like mod_dav_svn causes this problem for a lot of people.
12:05 dalek parrot: r41107 | bacek++ | branches/tt971_current_context_functions:
12:05 dalek parrot: Create branch for adding 'current' Context functions as described in tt971
12:05 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41107/
12:05 bacek seen chromatic
12:05 purl chromatic was last seen on #parrot 1 hours, 52 minutes and 40 seconds ago, saying: After sleep, anyhow.
12:08 Whiteknight okay, awesome
12:09 bacek Whiteknight: You broke something badly?
12:10 Whiteknight did I?
12:10 Whiteknight nothing seems broke to me
12:10 Whiteknight bacek: how is the Context ATTR work going?
12:11 bacek Whiteknight: you did ask it yesterday :)
12:11 Whiteknight did I?
12:11 * Whiteknight can't remember, very busy day yesterday
12:11 bacek I switched to fixed-allocator for Parrot_Context after our chat :)
12:14 Whiteknight but does Context use ATTRs?
12:15 kid51 joined #parrot
12:17 bacek Whiteknight: no. Because of registers.
12:21 Whiteknight ok
12:28 JimmyZ joined #parrot
12:30 kid51 jrtayloriv:  Your post on list re SVN is interesting.  To me it appears consistent with hypothesis that this was related to our lapse of certification.
12:30 nopaste "NotFound" at 213.96.228.50 pasted "Load bytecode and dynops in HLL 'parrot' context, TT #150" (54 lines) at http://nopaste.snit.ch/17867
12:31 NotFound Someone thinks that fix might give problems? It build and pass tests of parrot, rakudo and partcl
12:34 jrtayloriv kid51, Dozens of sites besides the one I quoted also pointed to DAV
12:35 kid51 Well, today is holiday in US.  Hopefully the sysadmins will take a look at that tomorrow.
12:35 jrtayloriv Good deal.
12:35 * kid51 spends his holiday installing Catalyst
12:36 dalek parrot: r41108 | whiteknight++ | trunk/src/pmc (7 files):
12:36 dalek parrot: [pmc] lots of misc cleanups for some PMC types that have been affected by recent branch merges. Convert ParrotRunningThread to use auto_attrs
12:36 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41108/
12:37 kid51 What does "Use the fingerprint to validate the certificate manually!" mean I should do?
12:38 NotFound kid51: you can look at the fingerprint using "Page info" on a browser in https://www.parrot.org/ for example
12:39 dalek parrot: r41109 | whiteknight++ | trunk/src/pmc/parrotrunningthread.pmc:
12:39 dalek parrot: [pmc] small additional touchup to parrotrunningthread.pmc
12:39 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41109/
12:40 kid51 NotFound:  that worked; thanks.
12:47 NotFound The certficate is used for *.parrot.org, so is the same for web, trac and https svn
13:01 Whiteknight fperrad: ping
13:02 fperrad Whiteknight, pong
13:02 Whiteknight fperrad: Is TT #472 still a problem?
13:04 jrtayloriv Whiteknight, Is anyone planning to do anything with the src/gc/alloc_memory.c::mem__internal_foo() functions? They seem to do exactly the same thing as their non-"internal" counterparts, and aren't called from anywhere.
13:05 Whiteknight jrtayloriv: they should be getting called from macros like mem_internal_foo()
13:05 jrtayloriv Whiteknight, Oh -- I see now. Thanks.
13:06 NotFound BTW we must start thinking about not dying on out-of-memory errors
13:06 fperrad Whiteknight, yes
13:07 Whiteknight fperrad: okay, I'll see if I can take a look at it
13:10 quek left #parrot
13:12 TiMBuS joined #parrot
13:22 Zak joined #parrot
13:26 dalek parrot: r41110 | whiteknight++ | trunk (4 files):
13:26 dalek parrot: [ctx] move the context-related functions from src/gc/alloc_register.c to src/call/context.c
13:26 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41110/
13:49 dalek parrot: r41111 | whiteknight++ | trunk (6 files):
13:49 dalek parrot: [ctx] move most of the guts from register.h to context.h. Fix POD errors in alloc_register.c and context.c
13:49 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41111/
13:50 PacoLinux joined #parrot
13:51 payload joined #parrot
13:56 Zak joined #parrot
13:57 dalek lua: 097b717 | fperrad++ | t/pmc/ (15 files):
13:57 dalek lua: refactor tests with isa_ok
13:57 dalek lua: review: http://github.com/fperrad/lua/commit/09​7b71757a1fcb3b639edf5897e5ba959e7e2f57
13:57 dalek lua: 6eeb8d9 | fperrad++ | t/pmc/t (2 files):
13:57 dalek lua: refactor PIR tests with throws_like
13:57 dalek lua: review: http://github.com/fperrad/lua/commit/6e​eb8d9dd0fb963fb68076036c8a2414603747e6
14:03 dalek parrot: r41112 | whiteknight++ | trunk (7 files):
14:03 dalek parrot: [ctx] delete the unneeded files register.h and alloc_register.c.
14:03 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41112/
14:29 MoC joined #parrot
14:31 dalek parrot: r41113 | whiteknight++ | trunk/config/gen/makefiles/root.in:
14:31 dalek parrot: [makefile] fix a dependency error introduced by the context stuff
14:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41113/
14:37 dalek wmlscript: 9f6b142 | fperrad++ | t/pmc/ (10 files):
14:37 dalek wmlscript: refactor PIR tests with isa_ok
14:37 dalek wmlscript: review: http://github.com/fperrad/wmlscript/commit​/9f6b14234925ed35b8ecaa0c099a01583937fede
14:37 jrtayloriv Whiteknight, Is there any reason for me to not go around and remove all of the commented out GMS write_barrier checks that are scattered all over the place? None of it works anyway, and from what everyone seems to be saying, noone is going to try to make it work (instead looking towards rewriting all of it later).
14:38 jrtayloriv I can just leave a comment in the GC_Subsystem struct that show where the write_barrier hooks should go *if* someone decides to use them later.
14:46 kid51 joined #parrot
14:48 nopaste "kid51" at 68.237.13.98 pasted "t/compilers/tge/grammar.t failure at r41109 on Darwin/PPC" (26 lines) at http://nopaste.snit.ch/17870
14:51 kid51 Hmm, when I ran 'make test', that showed up as a FAIL rather than a TODO.
14:52 kjeldahl joined #parrot
14:53 Psyche^ joined #parrot
15:03 Whiteknight jrtayloriv: i say kill the
15:03 Whiteknight them
15:04 jrtayloriv Whiteknight, OK -- that's what bacek thought too. I don't see any use for them, other than to add clutter. Thanks.
15:04 Whiteknight jrtayloriv: but be careful that your branch doesn't do too much! better to start a separate branch to do things unrelated to your current work
15:04 Whiteknight or better yet, do simple stuff like that in trunk
15:08 jrtayloriv Whiteknight, Other than adding the GC_Subsytem struct, and getting rid of the preprocessor directives, most of what I've done a lot of renaming things, and moving them to more appropriate places. I'm just trying to make the GC code more readable at this point. I won't be making very many more structural/functional changes.
15:08 Whiteknight okay, that's good
15:08 Whiteknight and readability is a very good thing
15:09 jrtayloriv Whiteknight, The write barrier stuff won't conflict with any of the work that's been done since the branch was created. And after I'm done removing that, I'll be pretty close to ready to merge.
15:09 jrtayloriv Unless, someone else wants to do more with it.
15:11 Whiteknight tomorrow at #ps we'll ask allison to review it for sanity
15:11 Whiteknight I'll take a look over it a little later on to make sure everything makes sense first
15:11 dalek TT #989 created by jkeenan++: t/compilers/tge/grammar.t:  FAIL under 'make test', but passes with ...
15:12 jrtayloriv OK -- I'll have bacek help me go over it later today as well, whenever he's back on. He expressed interest in helping me find any problems with what I've done.
15:23 dalek parrot: r41114 | whiteknight++ | trunk/t/pmc/namespace.t:
15:23 dalek parrot: [t] make sure to pop_eh for every time we push_eh
15:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41114/
15:23 Whiteknight so long as you get the thumbs-up from allison, we could talk about merging right after 1.6.0
15:25 theory joined #parrot
15:27 jrtayloriv Whiteknight, Sounds good. I'll finish up with the changes today, and then be done.
15:37 dalek parrot: r41115 | NotFound++ | trunk/src (2 files):
15:37 dalek parrot: [core] load bytecode and dynops in HLL 'parrot' conext, TT #150
15:37 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41115/
15:51 dalek parrot: r41116 | jrtayloriv++ | branches/gc-refactor/src (12 files):
15:51 dalek parrot: Removed unused GMS code from various places.
15:51 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41116/
15:57 cotto joined #parrot
16:00 jrtayloriv purl: GMS is "Good Morning Sunshine"
16:00 purl ...but gms is Growling Mad Scientist or Generational Mark and Sweep...
16:05 Whiteknight purl GMS is also Good Morning Sunshine
16:05 purl okay, Whiteknight.
16:06 Whiteknight purl GMS is also Goddamn Motherhonking Shit
16:06 purl okay, Whiteknight.
16:09 cotto hi
16:11 dalek TT #990 created by whiteknight++: Cannot lookup ISO-8859 NameSpace using Unicode
16:12 Whiteknight hello cotto
16:15 darbelo joined #parrot
16:18 NotFound Whiteknight: are you writing that file with mixed encodings?
16:19 dalek parrot: r41117 | whiteknight++ | trunk/t/pmc/namespace.t:
16:19 dalek parrot: [t] add reference to TT #990 to the test that is giving me grief
16:19 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41117/
16:19 Whiteknight NotFound: what do you mean?
16:20 Whiteknight I don't know a lot about encodings, otherwise I would fix it myself
16:20 NotFound Whiteknight: the iso-8859-1 prefix assumes that the characters are already encoding that way. Same for the unicode.
16:21 Whiteknight NotFound: okay, I'm not even sure what that means.
16:22 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41116 - Ubuntu 9.04 amd64 (gcc)
16:22 NotFound I'm sure that doesn't make sense at all, but imcc works that way.
16:23 Whiteknight NotFound: okay, so here's the question: is this a reasonable test or should it be deleted?
16:23 NotFound Whiteknight: let me think about a reasonable way...
16:37 chromatic joined #parrot
16:51 nopaste "NotFound" at 213.96.228.50 pasted "patch: namespace.t mixing charsets" (111 lines) at http://nopaste.snit.ch/17871
16:51 NotFound Whiteknight: that way is reasonable
17:03 payload joined #parrot
17:11 Whiteknight NotFound: thanks, I was hoping it would be easier but this isn't a problem either
17:12 jrtayloriv In what timezone is #parrotsketch at 6:30?
17:12 moritz UTC
17:12 moritz ps?
17:12 purl ps is probably postscript or process status or see "parrotsketch" or non-vector?! or annoying.
17:13 jrtayloriv moritz, thanks
17:13 moritz parrotsketch?
17:13 purl i heard parrotsketch was a status meeting for parrot core committers held every Tuesday at 18:30 UTC in #parrotsketch
17:13 jrtayloriv Aah -- parrot.org just says 6:30PM -- no time zone.
17:13 moritz on which page?
17:13 moritz oh, in the calendar
17:13 moritz I don't think I can fix that
17:14 einstein joined #parrot
17:14 jrtayloriv moritz, no problem -- I just noticed it in the text below the calender -- it says "all events listed shown in GMT time zone"
17:15 Whiteknight it's actually UTC, not GMT
17:15 Whiteknight when daylight savings time rolls around, about half the people don't make it
17:15 NotFound It explicitly says is GMT for me, but maybe that text is hidden depending on browser and font size
17:15 dalek parrot: r41118 | whiteknight++ | trunk/t/pmc/namespace.t:
17:15 dalek parrot: [t] Apply a patch from NotFound++ to make the unicode stuff work properly
17:15 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41118/
17:15 moritz Whiteknight: GMT doesn't imply DST
17:15 * jrtayloriv obviously knows nothing about anything but US time zones ... thought they were the same thing :)
17:15 Whiteknight I had heard that they weren't the same. I may be wrong
17:15 moritz the difference between GMT and UTC is neglectible (a few seconds, or parts of seconds even)
17:17 NotFound So youn need to find another excuse for arriving late to #ps ;-)
17:17 moritz date --utc is rather useful.
17:18 NotFound The google calendar page shows it in your local zone... provided you setup one in your accont.
17:19 Whiteknight timezones are such a stupid idea
17:19 NotFound I'm making a proposal to make the earth squared
17:20 NotFound I just need to get funds to buy four elefants and a a turtle...
17:21 jbert joined #parrot
17:23 darbelo NotFound: You are WRONG! The turtles are artifacts of the campaign to discredit the mighty TIME CUBE.
17:23 NotFound They are, but expensive artifacts.
17:24 NotFound So I need the funds anyway
17:28 * darbelo could accept a squared earth as a step towards cubed time.
17:28 NotFound And a scorched planet?
17:29 darbelo As long as it is on the other side of the cube, I'm fine with it :)
17:37 rhr joined #parrot
17:38 dalek rakudo: e2eaf33 | pmichaud++ | src/builtins/globals.pir:
17:38 dalek rakudo: Remove contextual fallback to %*ENV (as per r28193).
17:38 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​2eaf3371e93abd20c1a7b82bba6b3410eb128b8
17:39 dalek parrot: r41119 | whiteknight++ | trunk/t/pmc (2 files):
17:39 dalek parrot: [t] convert another NameSpace test to PIR
17:39 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41119/
17:41 dukeleto t/pmc/threads.t seems to hang on darwin in a full test run, but works when run individually. teh sux
17:41 cotto which make target asplodes?
17:42 dukeleto my test suite has been hung on t/pmc/threads.t for like 9 hours now
17:43 dukeleto cotto: i get the hang with "make fulltest" and using multiple test jobs, i am looking at what happens with a plain "make test" now
17:43 cotto you could also try make fulltest without multiple jobs
17:44 dukeleto cotto: will try that as well
17:44 cotto then just look for whichever way the most recent test run was started
17:44 cotto it's usually just an issue of figuring out which flags were passed to parrot
17:45 dukeleto "make test" does not hang on threads on darwin. i am checking a "make fulltest" with no parrallelization now
17:46 mokurai joined #parrot
17:46 dukeleto cotto: it seems to work fine without -j
17:50 dalek rakudo: 8d5a40a | moritz++ | t/spectest.data:
17:50 dalek rakudo: add contextual.t to spectest.data, pmichaud++
17:50 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​d5a40adf46e318490e4bec6ffa4bb16f70e9931
17:50 dalek rakudo: c1d96ce | pmichaud++ | docs/spectest-progress.csv:
17:50 dalek rakudo: spectest-progress.csv update: 435 files, 14255 pass, 0 fail
17:50 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​1d96ceeb33539be5f007431d3e396040135e7af
17:53 dalek parrot: r41120 | whiteknight++ | trunk/t/pmc (2 files):
17:53 dalek parrot: [t] convert one more test to PIR
17:53 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41120/
17:53 chromatic Wow, that's 850 new passing Rakudo tests since yesterday.
17:54 szbalint wow
17:54 * szbalint is impressed
17:54 moritz I think a good deal was colomon++ adding tests like mad
17:54 Whiteknight I need an example Unicode string for a test
17:54 moritz mostly for trigonometric functions
17:54 moritz Whiteknight: I like €uros ;-)
17:55 Whiteknight moritz: what's the ASCII version of that?
17:55 Whiteknight \x{?}uros
17:55 moritz € is not in ASCII.
17:55 szbalint € is € :)
17:55 Whiteknight right, what's the number for that glyph?
17:56 * Whiteknight doesn't know all the terminology, be patient
17:56 moritz U+20AC EURO SIGN
17:56 moritz it's called the "codepoint" number
17:56 Whiteknight so \x{20AC}uros
17:56 moritz right
17:56 Whiteknight w00t
17:57 NotFound Whiteknight: I'm not sure, but I think imcc result is more predictable with \u20AC
17:58 Whiteknight ok
17:58 * Whiteknight adds another item to the list of reasons to kill IMCC in a fire
18:00 moritz there are codepoints that don't fit into 4 hex digits
18:00 * darbelo hands Whiteknight some matches.
18:00 NotFound moritz: you have \U for that
18:00 moritz \Uhm.
18:01 * dukeleto gives Whiteknight a fully-charged flamethrower with a few extra barrels of napalm
18:02 chromatic We should have a pirc sprint soon.
18:03 NotFound If we don't make cristal clean the pir pdd about that things, switching to pirc or whatever might fail to solve the problems.
18:03 dukeleto chromatic: i am all about that
18:07 dalek TT #887 closed by dukeleto++: [patch]removed unused macro args
18:07 Whiteknight chromatic: you should be happy, I've added about 40 tests for NameSpaces
18:07 dalek parrot: r41121 | dukeleto++ | trunk (2 files):
18:07 dalek parrot: [TT #887] Remove unused macro args in CHARSET_VALIDATE, jimmy++
18:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41121/
18:07 dalek parrot: r41122 | whiteknight++ | trunk/t/pmc (2 files):
18:07 dalek parrot: [t] add several tests for Namespaces with unicode names. We now officially have more PIR tests for NameSpace PMC then we ever had written in Perl5
18:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41122/
18:07 Whiteknight and the majority of them are written in PIR now
18:08 NotFound I've added some to FPA, following coverity report
18:08 Whiteknight Maybe somebody can riddle me this: What is the difference between Array and ResizablePMCArray?
18:09 moritz isn't Array justa base class?
18:09 dukeleto Whiteknight: Array cannot change it's size?
18:09 Whiteknight or better phrased, why do we have both?
18:09 NotFound Array is a role, or something
18:09 Whiteknight dukeleto: so then what is the difference between FixedPMCArray and Array?
18:09 Whiteknight NoFound: we have tests for Array where it is directly instantiated
18:09 NotFound Whiteknight: "FixedPMC" ;)
18:10 moritz so did anybody find any parrot bugs while adding more tests?
18:10 Whiteknight I can understand if it's a base class for other types, but then it shouldn't be used directly
18:10 NotFound Ah, yes, Array != array
18:13 nillo joined #parrot
18:14 NotFound Looks like Array is a tiny wrapper for src/list.c
18:14 dukeleto moritz: yeps. one example; https://trac.parrot.org/parrot/ticket/943
18:15 pmichaud (codepoints)  I don't think the issue is an irc issue, but a PIR one
18:15 pmichaud s/irc/imcc/
18:16 iblechbot joined #parrot
18:16 pmichaud it's very difficult for  unicode:"«"  and iso-8859-1:"«"  to both work if we don't have a standard encoding for the PIR source file itself
18:16 NotFound BTW both list and hash have a container member that points to the pmc that contains it, and that mitgh not be updated in morph and similar operations.
18:17 einstein I have questions about the _metadata filed in the pmc struct, which can be set by addprop,setprop,getprop,delprop vtable functions
18:17 NotFound pmichaud: we talked about that several times, but things haven't improved yet.
18:18 pmichaud NotFound: yes; I'm just pointing out it's a PIR specification issue and not an imcc one.
18:18 NotFound Yeah, we can't fix imcc without a consistent plan in mind.
18:19 cotto anybody interested, I'd appreciate proofreading of the docs in this next commit
18:19 einstein why are these functions and ops not called addmetadata,getmetadata,*metadata*,etc, it�s a little confising to call them get-/setprop
18:19 chromatic First we have to get pirc to the point where it compiles and we can start running tests.
18:20 pmichaud einstein: I think the opcodes were designed to match Perl 6's idea of "properties" on objects (more)
18:20 pmichaud einstein: at this point I'd say it makes more sense to change the _metadata field to be _props  :)
18:20 dalek parrot: r41123 | cotto++ | trunk/tools/dev/pprof2cg.pl:
18:20 dalek parrot: [pprof2cg] add documentation to pprof2cg
18:20 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41123/
18:20 einstein but it
18:21 dukeleto chromatic: you are talking about the pirc that bacek has a github repo for, or no?
18:21 einstein but it's something different from variable members of a class
18:21 pmichaud I don't understand "variable members of a class"
18:21 pmichaud (in this context)
18:22 pmichaud if you mean that properties are not attributes... you're correct.
18:22 einstein yes
18:22 NotFound That's because they are called metadata instead of data ;)
18:22 pmichaud attributes are defined in a class, such that all instances of the class have slots for those attributes
18:22 pmichaud properties are per-object; any given object can have an entirely different set of properties from another object (even if the two objects are of the same type)
18:23 moritz (which you can achieve with mixins in some programming languages, including Perl 6)
18:23 japhb I'm going to have to change the case of a filename in the parrot repo ... anything SVN-related I should be aware of here?  Are Windows people going to have to nuke their checkouts?
18:24 pmichaud einstein: if your complaint is generally that opcode names don't match the underlying structure names -- that's a common problem throughout parrot :)
18:24 NotFound japhb: What filename? JSON?
18:24 einstein ok if you see it in that way then it better called property, i did saw it in a way of adding metadata to any kind object, something like metadata fields in java
18:24 japhb NotFound, yeah.  JSON.pir to be exact.
18:24 einstein so if you clone a object these properties do not get copied
18:25 NotFound japhb: I think there is a ticket to refactor that as json/reader and json/writer or something...
18:25 pmichaud as rakudo is currently using them, cloning an object does not clone its properties, yes.
18:25 dukeleto japhb: use svn copy ?
18:25 japhb dukeleto, to change the case of the file?
18:25 dukeleto japhb: that way you preserve file history
18:26 japhb dukeleto, I'm not worried about that part.  It's the Windows filesystem dain bramage I'm worried about.  And whether SVN will be smart enough to force the case change down to people's checkouts
18:26 sri joined #parrot
18:26 dukeleto japhb: you will make some people cry if you just rename a file and don't "svn copy" it, because it will lose all the history associated with it.
18:27 sri joined #parrot
18:27 einstein ok thanks for the information, then i know for which thing it is currently used, maybe it's better to rename the _metadata field to _properties and put some comment it is used for p6 as properties
18:27 japhb NotFound, It's annoying in current situation.  There is a library/JSON.pir -- that's the writer.  There's a compilers/json/JSON.pir -- that's the reader.  And a poorly named library/Config/JSON.pir, which is a shell around the other two.
18:27 dukeleto japhb: not sure if svn is case-senstive . this is why you don't track content with files. you track content :)
18:28 NotFound japhb: if we change location to a saner scheme, we can avoid the renaming problem
18:28 japhb dukeleto, sure, but again, I'm not worried about the history (I will svn copy it, sure, that's not the problem)
18:28 japhb dukeleto, preaching to the choir, son.
18:28 chromatic dukeleto, that's the one.
18:28 dukeleto japhb: gotcha. sorry!
18:28 japhb dukeleto, np!
18:29 HG` joined #parrot
18:29 japhb NotFound, OK, and I can agree with you for the library/ case.  But the compilers/ case seems more thorny, since 'json' is the correct name for that directory ... and we can't rename the file without renaming the directory and the language, because of the magic.
18:30 NotFound Uhhh... right
18:30 japhb Because once again, Bill Gates Was Wrong.
18:31 japhb Not that I'm bitter.
18:31 dalek parrot: r41124 | dukeleto++ | trunk/src/pmc/env.pmc:
18:31 dalek parrot: [cag] Fix link to pdd17 in src/pmc/env.pmc
18:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41124/
18:31 joeri joined #parrot
18:31 dukeleto cotto: "interst of simplicity"
18:31 NotFound I suugest a radical approach: rename also the compiler, letting the old in place until the end of deprecation cycle.
18:31 cotto intersting
18:31 purl intersting is that the strategy for seperating build time from installed config works perfect for the utils, this includes either parrot_config.o or install_config.o
18:32 cotto forget intersting
18:32 purl cotto: I forgot intersting
18:32 japhb NotFound, that's radical all right.
18:32 NotFound Let's radical!
18:33 japhb Tene.'ping'()
18:34 japhb Are there any limitations to the name of an HLL, other than alphabetics have to be lowercase?  Any other limitations of length or characters allowed?
18:34 Tene japhb: pong
18:34 Tene japhb: no, not as far as I know
18:34 dalek parrot: r41125 | cotto++ | trunk/tools/dev/pprof2cg.pl:
18:34 dalek parrot: [pprof2cg] various spelling fixes
18:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41125/
18:34 japhb Tene, OK, thank you.
18:34 Tene japhb: you'd likely run into problems if you use a / or \ in it
18:34 japhb heh
18:35 japhb Damn, no language named 'c:\/'
18:35 Tene ><
18:35 * Tene larts japhb
18:35 japhb heh
18:35 NotFound Tene: Have you looked at TT #150 ?
18:35 Tene NotFound: I reported it
18:35 japhb OK, in all seriousness, anyone object to 'data_json'?
18:36 dukeleto japhb: for a language name?
18:36 japhb dukeleto, for a language name that is *not* 'json'.  :-)
18:36 NotFound Tene: at the last comments, I mean
18:37 Tene i have now :)
18:37 Tene NotFound: I'll try to test by reverting the workaround in cardinal and rakudo.
18:38 dalek parrot: r41126 | cotto++ | trunk/tools/dev/pprof2cg.pl:
18:38 dalek parrot: [pprof2cg] one last (?) grammar fix
18:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41126/
18:38 dalek rakudo: 6b22b9d | moritz++ | Configure.pl:
18:38 dalek rakudo: when --gen-parrot-prefix is passed along, we should also search in that path for parrot_config
18:38 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​b22b9dfb9e31e72845f2c68af6a9356d019e721
18:38 dalek rakudo: 446d49f | moritz++ | :
18:38 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
18:38 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​46d49f4cae7d88b84c42d5c83df75bc0e3edde8
18:38 NotFound Tene: the problem is that I haven't figured how to write a parrot regression test for it
18:39 japhb OK, I'm taking silence as assent.
18:41 dukeleto japhb: i can't think of anything better
18:41 japhb dukeleto, nod
18:42 dukeleto should a ticket like https://trac.parrot.org/parrot/ticket/886 be left open or closed? it is kind of ambiguous and seems like the kind of ticket that will just sit open forever
18:42 japhb And come to think of it, it makes a useful prefix for all data-only (non-executable) languages. 'data_yaml', 'data_xml', etc.  Now we just need to do 'data_md3' ....
18:43 Tene NotFound: are there tests for loadlib and dynpmc?
18:43 Tene NotFound: you should be able to test it by loading a library that contains a dynpmc at runtime from a different HLL and then inspecting the appropriate namespace.
18:44 dukeleto Tene: i would like to see some for loadlib. is it supposed to fail silently?
18:44 Tene dukeleto: That's irritated me before.  I think that that was the originally specified behavior, but I don't know whether anyone else still wants it.
18:45 dukeleto Tene: i don't want it. it 'causes errors at a distance
18:45 Tene dukeleto: it *returns* something different on failure.
18:45 Tene So if you always check your return values, you're fine...
18:45 Tene but I'd love to see it throw an exception.
18:45 dukeleto Tene: you can check the return value of loadlib?
18:45 Tene $P0 = loadlib 'libfoo'
18:47 NotFound Tene: will be a problem to build an HLL just for that test
18:48 Tene NotFound: um, no it won't...
18:48 Tene .HLL 'foo'
18:48 Tene done
18:48 Tene or do you mean dynpmcs?
18:48 Tene I'd think you could just reuse whatever the dynpmc tests use.
18:48 dukeleto Tene: what about .loadlib ?
18:48 Tene dukeleto: there's no way to check for failure of .loadlib
18:48 nillo joined #parrot
18:49 NotFound That's is far away from my know-how on writing tests
18:49 Tene I wouldn't mind seeing it deprecated.
18:49 dukeleto Tene: *that* is what pisses me off
18:49 Tene and just put it in a :immediate .sub if you need it to happen at that time.
18:49 dukeleto Tene: so .loadlib is immediate while loadlib happens at runtime ?
18:49 Tene dukeleto: yes.
18:50 dukeleto Tene: you need to use .loadlib for dynops, right ?
18:50 Tene I have no idea at all.
18:50 Tene It wouldn't surprise me.
18:50 Tene You could still do it in a :immediate sub, though, I'd suspect.
18:50 dukeleto Tene: that is where I ran into the issue. some dynops were not getting installed, and .loadlib didn't tell me it couldn't find them. teh sux
18:50 Tene dukeleto: .loadlib *definitely* should fail loudly.
18:50 dukeleto Tene: why can't .loadlib throw an exception ?
18:51 dukeleto Tene: it currently does not
18:51 dalek parrot: r41127 | japhb++ | trunk/compilers/nqp/src/builtins.pir:
18:51 dalek parrot: [compilers/nqp] remove unneeded debug output from eval()
18:51 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41127/
18:51 Tene dukeleto: It certainly *could*.
18:51 NotFound There is a problem with catching exceptions thrown inside imcc
18:52 Tene I personally wouldn't feel comfortable adding that without checking with allison or someone else to put blame on.
18:52 dukeleto Tene: +1 to .loadlib throwing an exception. i will try to add some tests relating to this issue, then perhaps an email to the list about changing the behavior
18:52 Tene dukeleto: yes, that would be great.
18:52 dukeleto Tene: yes, I will add tests to document the current behavior, then put it up to the list to decide if the current behavior sucks or not
18:53 dukeleto we have the shiny new throws_ok() test_more.pir function to play with
18:53 dukeleto s/throws_ok/throws_like/
18:53 NotFound Current behavioir sucks, but I don't think it can be cleaned until all packfile things are handled via pmc.
18:54 moritz ack -w loadlib # should that a whole lot of files don't check the return value
18:54 dukeleto NotFound: care to explain that a bit more  to a mere mortal ?
18:54 dukeleto moritz: just about no one checks the return value now
18:55 moritz t/pmc/nci.t
18:55 moritz does
18:55 moritz as well as some t/dynpmc/*.t
18:55 NotFound dukeleto: if you throw an exception while imcc is compiling or executing fixups, the packfile structures may stay in an inconsistent state.
18:55 Tene moritz: and it's impossible to test the return value of .loadlib
18:56 dukeleto NotFound: that makes a lot more sense to me, thanks!
18:57 Whiteknight dukeleto: I'm having some trouble with throws_like
18:57 moritz anyway, it wouldn't hurt to get in a deprecation notice now
18:57 dukeleto Whiteknight: let me at it. what's up?
18:57 Whiteknight match failed: target 'destination namespace not specified' does not match pattern 'destination namespace not specified'
18:57 Whiteknight ...and I can't think of a better match
18:57 dukeleto Whiteknight: whitespace in a PGE pattern is ignored. you need to backslash it
18:57 moritz is that a regex?
18:57 moritz or simply add an :s at the start
18:57 moritz ':s destination namespace not specified'
18:58 dukeleto Whiteknight: see the tests for test_more.pir in t/library/test_more.t
18:58 dukeleto moritz: now you tell me!
18:58 moritz dukeleto: you were free to read S05 all the time ;-) *SCNR*
18:58 dukeleto Whiteknight: yes, please go with :s instead of backslashitis. feel free to change the tests to use :s instead of backslashitis :)
18:58 dalek parrot: r41128 | japhb++ | trunk/compilers/data_json (2 files):
18:58 dalek parrot: [compilers/data_json] Straight copy of compilers/JSON; probably broken right now
18:58 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41128/
18:59 Whiteknight ah, that fixes it
18:59 dukeleto moritz: freedom didn't have much to do with it ;)
18:59 Whiteknight I was using the slashes, but I had double quotes not single ones
18:59 Whiteknight so I was double-breaking it
18:59 dukeleto Whiteknight: yeah, backslashitis sucks
19:02 dukeleto does anybody a favorite Perl 5 testing function that they would like to see in test_more.pir ? Preferably useful ones :)
19:02 dalek parrot: r41129 | cotto++ | trunk (3 files):
19:02 dalek parrot: [profiling] add news item, update imcc options and helpful output to profiling exit message
19:02 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41129/
19:04 Whiteknight the pure-PIR version runs 70 tests in .3s. the Perl version runs 38 tests in 1.5s
19:05 Whiteknight brb
19:06 dalek parrot: r41130 | japhb++ | trunk/MANIFEST:
19:06 dalek parrot: Update MANIFEST for data_json and a couple stragglers
19:06 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41130/
19:06 dalek parrot: r41131 | whiteknight++ | trunk/t/pmc (2 files):
19:06 dalek parrot: [t] convert 4 more tests using throws_like. Help from dukeleto++ and moritz++.
19:06 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41131/
19:08 cotto I thought Mondays were supposed to be slow.
19:08 dukeleto Whiteknight++ # glad to see throws_like getting taken for a spin
19:08 MoC` joined #parrot
19:11 Whiteknight joined #parrot
19:11 dukeleto chromatic: where is the source to your  Project Euler #4 ? i want to put it in euler_bench :)
19:15 einstein when creating a new instance from a "core" pmc a "core" pmc object is created, but when a subclass is and then create a new object i get a object (object.pmc)
19:16 einstein why do i not always get i object such a i get when i have subclassed i core pmc class
19:17 kyle_l5l joined #parrot
19:17 dalek TT #990 closed by whiteknight++: Cannot lookup ISO-8859 NameSpace using Unicode
19:20 NotFound einstein: because a class instance is not the same as a pmc instance
19:23 einstein I mean when i for example create a new exception then i get a object which hold the c exception.pmc object, but when i subclass exception and then create a object i get a c object.pmc which has exception class
19:23 quek joined #parrot
19:24 Coke msg cotto I opened 952 to track progress on the branch, (mainly because it had no original ticket for the work going on in the branch.)
19:24 purl Message for cotto stored.
19:24 Whiteknight einstein: that sounds right
19:24 pdcawley_ joined #parrot
19:24 einstein when i would do getattribute $P5,eh,'handled_types' where eh = new ['ExceptionHandler'] then i get error, but ...
19:25 einstein when i would do when i would do getattribute $P5,eh,'handled_types' where eh = new (class subclassed from exceptionhandler) then i get no error
19:27 Tene einstein: there are currently problems with subclassing PMCs from PIR, exactly what you're describing.
19:27 Tene This is something that is planned to be fixed.
19:27 einstein is there a ticket for this?
19:27 pdcawley_ joined #parrot
19:27 Tene For exceptions specifically, subclasses of Exception and ExceptionHandler don't work.
19:27 Tene I believe so.
19:28 NotFound throw is explicitly filtering anything but 'Exception'
19:29 einstein I used this example because there was only 1 sub test failing when i removed the functionality of attributedefs from the vtable struct
19:29 einstein which was one in the exception handling test cases
19:30 einstein It was just a test of my to see how much would be failing if I removed this thing
19:31 NotFound einstein: Removing what?
19:31 purl Removing is probably backwards compatible
19:32 einstein I tested what would fail i remove the attributedefs field from the vtable struct, and found out only 1 subtest began to fail
19:35 einstein Tene: is there a ticket describing this problem?
19:35 NotFound einstein: no wonder, there are problems with that feature so almost nobody uses it.
19:35 Tene einstein: I believe that there is, but I don't know.
19:36 cotto Coke, gotcha
19:36 darbelo Hm. Is the next_for_GC pointer in PMCs actually useful for something?
19:36 szbalint duk3leto: perl6-examples
19:37 szbalint or do you mean PIR?
19:37 einstein it is used by the gc system to implement somekind of prioritization mechanism in the gc
19:40 dukeleto joined #parrot
19:42 Coke Whiteknight: on #990 - /how/ did he fix your issue?
19:42 Coke msg Whiteknight on #990 - /how/ did he fix your issue?
19:42 purl Message for whiteknight stored.
19:44 NotFound Coke: r41118
19:46 allison joined #parrot
19:46 Tene hi allison
19:47 allison hi Tene
19:47 particle joined #parrot
19:48 cotto wb allison
19:48 cotto we've been busy while you've been gone
19:49 Tene allison: is there any reason that .loadlib fails silently?
19:49 allison cotto: excellent!
19:49 purl EGG-see-lent!
19:50 allison Tene: IIRC, it's because it searches in a large number of places and there wasn't an obvious point in the code to say "we really found nothing"
19:50 allison Tene: that may no longer be true
19:51 Tene allison: so would there be any objection to making it throw an exception?
19:51 allison none at all
19:52 Tene dukeleto: allison says that .loadlib can fail
19:52 NotFound I have one: it may give to lots of diifficult to diagnose test reports
19:53 dukeleto Tene: sweet
19:54 allison which means probably after 2.0
19:55 dalek TT #591 closed by cotto++: pir profiling tools
19:58 rhr joined #parrot
20:02 dalek parrot: r41132 | japhb++ | trunk/config/gen/makefiles/data_json.in:
20:02 dalek parrot: [data_json] svn copy makefile skeleton: json.in -> data_json.in
20:02 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41132/
20:02 Tene allison: someone here was asking about the reasons that Parrot uses SVN and what would be required to move to git.
20:03 iblechbot joined #parrot
20:03 beta joined #parrot
20:03 allison We use git because it's stable, reliable, and easy for new programmers to pick up quickly.
20:04 allison Tene: We won't be making any more infrastructure changes until after 3.6, but might consider git then.
20:04 MoC joined #parrot
20:04 allison Tene: although, there are quite a few other options coming along quite well, so it's possible that one of them may over take git by the time we're ready to consider changes.
20:05 NotFound We can even write one with parrot X-)
20:05 allison Tene: My particular concern about git is in the "easy for new programmers" department.
20:05 allison Tene: but, it could make a good bit of progress there in the next couple of years
20:05 allison NotFound: also possible
20:05 purl rumour has it also possible is creating an "Error" type, which could also contain an error message (explaining the reason for the Null return value), and allowing easy promotion to an actual exception in certain contexts or pragmas
20:06 dukeleto git is a framework for building distributed version control systems. the porcelain keeps getting better
20:06 allison dukeleto: aye, I think it has great potential
20:07 Tene purl: msg bacek I think it was you that was asking about git... if so, read the irc logs for this time.
20:07 purl Message for bacek stored.
20:07 allison s/git/svn/ in that first sentence
20:07 Tene Of course. :)
20:07 dukeleto allison: ah, you were confusing me a bit :)
20:07 kid51 joined #parrot
20:08 dukeleto allison: branch merges are currently very painful because svn handles them so poorly, this is the price we pay for being easy for newcomers
20:09 allison dukeleto: the leading cause of painful branch merges is programmer inexperience, which is worse with git
20:09 dukeleto allison: stable and reliable reasons are a bit subjective too. one could argue that git is a lot more stable and reliable, but that dead horse has already been kicked enough
20:10 moritz well, it seems that current average parrot programmer has more difficulites with branch merges in svn than in git, inexperience or not
20:10 allison dukeleto: I've never had trouble with my branches, though I did have a painful experience with a new contributor's branch
20:10 dukeleto allison: there has been a lot of weird technical issues with the svn repo recently. people couldn't properly merge for unknown reasons
20:10 NotFound I don't have any problem with branches in git... because I've never used git other than for clone and diff
20:11 allison lately I've been moving more toward Patrick's branching strategy
20:11 allison he uses a series of fresh branches from trunk
20:11 allison instead of updating the branch from trunk
20:11 allison it's much cleaner
20:12 allison and encourages code review every time you rebranch
20:13 dukeleto in git, i make a topic branch from trunk for each unit of code that i want to commit. if you don't continually merge trunk into the topic branch, it makes later merging much easier.
20:13 Whiteknight what we really need right now is a set of good guidelines and best practices for branching
20:14 * kid51 feels that merging from trunk into branch is risky regardless of VCS
20:14 Whiteknight keep them focused, short-lived, etc
20:15 allison Whiteknight: feel free to add to docs/project/branching_guide.pod
20:15 NotFound I do a lot of merges from trunk during the auto_attrs branch without big problems, and it was the first branch I ever made.
20:16 * kid51 remembers the long ago days of 2007, when he was practically the only person using branches!
20:16 NotFound And the few problems I had were my fault.
20:18 Whiteknight besides the issues over the weekend (which I think jrtayloriv has diagnosed), I haven't had any issues with branching
20:20 kid51 ... and jrtayloriv's diagnosis is consistent with my hunch that this was connected to our cert-expiration problems.
20:20 jrtayloriv And it should be noted that, as Allison mentioned, the branch that was troublesome was from a newcomer (namely, myself) -- there are likely several things I could have done to make it less difficult. It was only exacerbated by the problems with the server.
20:21 Whiteknight jrtayloriv: which branch was that?
20:21 dukeleto gc-refactor ?
20:21 jrtayloriv kill_parrot_cont was the branch that was causing so many issues the other night.
20:22 Whiteknight allison: there have been a LOT of changes to contexts, continuations, etc recently. is the pcc_arg_unify branch going to be able to surive that?
20:22 Whiteknight or better question, what can we laypeople do to help nudge that branch along?
20:22 dalek parrot: r41133 | dukeleto++ | trunk (3 files):
20:22 dalek parrot: [t] Finish translating t/pmc/integer.t to PIR and delete old file
20:22 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41133/
20:23 kid51 My feeling is that lately we've had a lot of branches active -- which, cet. par., is a good thing -- but all touching the same files.  So that with kill_parrot_conf, even once we overcame the repository problems, we still had 21 files in conflict.
20:23 allison Whiteknight: I'll be making another fresh branch from trunk and merging the changes in
20:23 Whiteknight allison: okay, that's probably a good idea. Like I said, lots of changes since that branch was created
20:23 kid51 Whiteknight:  I just posted in TT requesting a description of that branch's objectives.
20:23 allison Whiteknight: but, do need to get the last ~500 tests passing first
20:24 Whiteknight allison: Okay, I would love to help debugging. Any pointers about where to start, or do I just dive in?
20:24 allison kid51: yeah, that's pretty much unavoidable
20:24 allison Whiteknight: just take a look at failing tests
20:25 Whiteknight Okay, I'll dive in. Probably later tonight
20:25 * Whiteknight has to take off. Later
20:26 allison Whiteknight: check with me before committing anything, we've had a few people find "surface" fixes that weren't actually the right fix (they got the test passing, but caused more problems than they solved)
20:26 dalek parrot: r41134 | dukeleto++ | trunk/t/pmc/integer.t:
20:26 dalek parrot: [cage] Removed unused/commented out code from t/pmc/integer.t
20:26 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41134/
20:26 Whiteknight allison: will do. Post to a ticket or email you directly?
20:26 allison It's a branch, so not ticket-worthy.
20:26 allison email or IRC works
20:27 Whiteknight okay. Noted.
20:27 Whiteknight see you later
20:27 allison Whiteknight: later
20:28 NotFound Have you looked at TT #150? Maybe that issue is also creating pcc problems.
20:30 kid51 allison: What you describe as pmichaud's approach to branching -- which I think is wise for large branches -- runs counter to the instruction given by docs/project/branching_guide.pod starting at line 38
20:30 NotFound allison: last line was for you
20:31 allison NotFound: looking now
20:32 kid51 Speaking of branches ...
20:32 allison kid51: yes, I wrote that a while ago, for the strategy I was using at the time
20:32 allison kid51: it's worth adding a note "for large changes or long-lived branches"...
20:33 kid51 Is there anyone with a non-symlinkable system who can do a checkout of the tt509_install_files branch, do perl Configure.pl --prefix=/some/tempdir/, make and make install ... and then comment in https://trac.parrot.org/parrot/ticket/509 ?  Thanks.
20:34 NotFound kid51: system or filesystem?
20:34 kid51 I think either or both.  There were comments in that ticket about both systems (Win32) and filesystems.
20:35 kid51 All my systems are symlinkable, so I can't test it properly myself.
20:35 kid51 I applied wayland's most recent patch in branch in the hope that we can resolve the ticket.
20:35 kid51 Don't claim to understand the issues completely myself.
20:37 NotFound The issue in some message I've seen was that some people assume that if the system has symbolic linking capabilities you always build/install in filesystems that have them.
20:38 davidfetter joined #parrot
20:38 quek left #parrot
20:40 dalek parrot: r41135 | jkeenan++ | trunk/docs/project/branching_guide.pod:
20:40 dalek parrot: Qualify advice about synchronizing branch with more recent changes in trunk.
20:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41135/
20:42 cotto kid51, revision number isn't required for svn >= 1.5.x
20:42 NotFound cotto: on the client, server, or both?
20:42 kid51 cotto:  what are you referring to?  the POD?
20:42 cotto as long as the branch was created with a svn client >= 1.5.x
20:43 cotto both, but the server iirc has been upgraded
20:43 cotto kid51, yes
20:44 kid51 cotto, you're probably correct -- but can we assume that everyone is using a recent SVN client?
20:45 cotto no.  I'd suggest a note that users of recent svn clients don't need to record the revision number.
20:47 bobke joined #parrot
20:47 dalek parrot: r41136 | mikehh++ | trunk/MANIFEST:
20:47 dalek parrot: run tools/dev/mk_manifest_and_skip.pl
20:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41136/
20:48 kid51 cotto:  Feel free to add it.  (Today was first day I was aware of that POD.)  gotta go.
20:54 allison cotto: Even users of ancient svn clients can fetch the initial revision number of the branch from Trac. Though, I record the number anyway for quick reference.
21:07 dalek parrot: r41137 | japhb++ | trunk (10 files):
21:07 dalek parrot: [data_json] Now with less horribly borken; frob makefile templates, svn properties, manifests, etc. to match
21:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41137/
21:12 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41136 - Ubuntu 9.04 amd64 (g++)
21:19 jrtayloriv joined #parrot
21:20 dalek rakudo: f01875f | moritz++ | tools/test_summary.pl:
21:20 dalek rakudo: [test_summary.pl] if we run a test, use the "plan" information gathered from its output
21:20 dalek rakudo: This should reduce the number of 'plan *' related mis-counts even further.
21:20 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​01875fb6153419f186b167f6c9966bf5c215532
21:27 mikehh rakudo (446d49f) builds on parrot r41136 - make test / make spectest (up to r23204) PASS - Ubuntu 9.04 amd64 (g++)
21:32 dalek rakudo: 01ae3fa | moritz++ | docs/release_guide.pod:
21:32 dalek rakudo: [docs] propose ThousandOaks as a release name, in recognition of their cool Perl 6 hackathon
21:32 dalek rakudo: Also remove some trailing whitespaces
21:32 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​1ae3fae981eed2ecd8a75c94a72c119340044cf
21:34 mikehh partcl r697 builds on parrot r41136 - make test Segmentation faults - Ubuntu 9.04 amd64 (g++)
21:38 mikehh partcl - ran make test 6 times - different tests fail with segmentation faults - the only one that failed in every run t/cmd_parray.t also failed subtests (between 1 and 4 but different ones)
21:39 NotFound It doesn't fail for me
21:39 mikehh NotFound - how did you fix it - maybe I need to do a clean checkout
21:40 NotFound mikehh: I didn't do anything
21:41 NotFound Rebuilding now without --optimize
21:49 NotFound All test pass, no core
21:49 dalek close: r100 | Austin++ | trunk/ (14 files):
21:49 dalek close: Another refactoring checkpoint. Cross-nsp calls working now. Starting
21:49 dalek close: initializer fixup.
21:50 dalek close: review: http://code.google.com/p/close/source/detail?r=100
21:52 mikehh cardinal - builds on parrot r41136 - rake test:all - same 3 failures - Ubuntu 9.04 amd64 (g++)
21:54 dalek parrot: r41138 | japhb++ | trunk (3 files):
21:54 dalek parrot: [data_json] More pedantic .HLL handling; switch examples/json/* to use data_json (with minor cleanups)
21:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41138/
21:55 mikehh decnum-dynpmcs r181 builds on parrot r41136 - make test PASS - Ubuntu 9.04 amd64 (g++)
22:01 bacek joined #parrot
22:07 * jrtayloriv growls at svn and begins installing git-svn
22:10 tjc joined #parrot
22:11 mikehh NotFound: partcl - after a clean co I had problems building - did a make realclean then it built but still segfaults all over the place
22:11 NotFound Looks like an epidemy of memory chips failures
22:12 mikehh I think I am going to reboot - check some i386 stuff and then clean up everything and see what happens
22:13 darbelo mikehh: can you test a patch on i386?
22:14 mikehh darbelo: when I re-boot - hold on about 10 minutes
22:14 mikehh bbl
22:14 darbelo I can wait a lot more thatn that :)
22:16 joeri left #parrot
22:20 ruoso joined #parrot
22:25 jrtayloriv bacek, Do you have time now or later to review what I've done in gc-refactor branch, and see if there is anything you would do differently or add?
22:29 * darbelo grabs his machete and walks into pmc_freeze.c
22:36 Andy joined #parrot
22:39 buildbot joined #parrot
22:42 jan joined #parrot
22:43 rg1 joined #parrot
22:46 bacek Good morning
22:46 purl And good moroning to you, bacek.
22:46 bacek jrtayloriv: yes, I'll review your branch later today.
22:46 jrtayloriv bacek, thank you
22:52 dalek parrot: r41139 | bacek++ | trunk/src/runcore/cores.c:
22:52 dalek parrot: [cage] Initialise coredata->flags
22:52 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41139/
22:52 dalek parrot: r41140 | bacek++ | trunk/include/parrot/context.h:
22:52 dalek parrot: [core] Manually inline REG macros for optimised builds
22:52 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41140/
22:53 mikehh joined #parrot
22:54 mikehh back on i386
22:55 bacek jrtayloriv: can you sync branch with trunk? There is many changes related to latest merges of pluggable_runcores and kill_cont which makes review harder than needed.
22:56 jrtayloriv bacek, I'm getting git-svn installed at the moment -- I tried to sync with trunk and svn kept dying.
22:56 jrtayloriv But once I do, then yes, I will sync it up.
22:56 bacek jrtayloriv: ok. You have about ~10-12 hours before I can start proper reviewing :)
22:57 jrtayloriv ok
22:57 bacek msg whiteknight Can we remove ifdef _WIN32 for GC_USE_FIXED_SIZE_ALLOCATOR now?
22:57 purl Message for whiteknight stored.
23:02 dukeleto Parrot VM: PANIC: Out of mem!
23:02 dukeleto i am working on translating FixedPMCArray to PIR and adding more tests. i think I just found a nice bug :)
23:03 dalek parrot: r41141 | bacek++ | trunk/NEWS:
23:03 dalek parrot: Fix small typo in NEWS about Contexts.
23:03 dalek parrot: It was about ~7.5k lines diff from "not" to "now" apparently.
23:03 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41141/
23:03 japhb bacek, it looks like you nuked the NEWS about the profiling runcore
23:04 bacek japhb: nope :)
23:05 japhb bacek, I'm confused by the changeset diff then.
23:05 bacek japhb: context_pmc3 branch
23:05 japhb bacek, but you changed NEWS in trunk ...
23:06 bacek japhb: Bah! Gotcha.
23:07 bacek Fixed.
23:07 dalek TT #991 created by dukeleto++: Parrot dumps core when attempting to create a FixedPMCArray with negative ...
23:08 bacek $dayjob time. Better to stop braking parrot and return to "stupid manager" duties...
23:08 bacek see you!
23:09 dalek parrot: r41142 | bacek++ | trunk/NEWS:
23:09 dalek parrot: Readd NEWS about profiling runcore. bacek--, japhb++
23:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41142/
23:10 darbelo mikehh: can you give the patch attached to TT#986 a test? JIT in particular.
23:18 mikehh I'll give it a go - but I got some $work problems to sort out first - if you are not in too much of a hurry
23:32 Andy joined #parrot
23:34 darbelo seen Whiteknight
23:34 purl Whiteknight was last seen on #parrot 3 hours, 6 minutes and 47 seconds ago, saying: see you later
23:49 Whiteknight joined #parrot
23:51 Whiteknight good evening, #parot
23:51 Whiteknight or parrot
23:53 darbelo Whiteknight: I have a surprise for you.
23:53 Whiteknight ???
23:54 darbelo Remember the next_for_gc abuse in pmc_freeze.c you disliked so much?
23:55 darbelo It's dead code. there's a #define there disabling it.
23:56 bacek joined #parrot
23:56 darbelo I just amputated it with no test failures.
23:57 Whiteknight holy shit. darbelo == awesome
23:57 Whiteknight do you have the commit bit yet?
23:57 dalek parrot: r41143 | jrtayloriv++ | failed to fetch changeset:
23:57 dalek parrot: Merged changes from r41010 to r41116
23:57 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41143/
23:57 darbelo Not my work, actually. The pointer abuse got replaced with a hash at some point, but the old code was left in behind a #define.
23:58 darbelo All I did was remove a lot of dead code :)
23:59 Whiteknight nice, so I can remove that garbage from the GC then
23:59 Whiteknight and there was much rejoicing
23:59 purl yay.
23:59 dalek TT #940 closed by whiteknight++: miniparrot segfaults on Windows
23:59 jrtayloriv Whiteknight, That didn't just merge to trunk did it? Why isn't it saying gc-refactor in the commit message? I fetched and merged in the refactor branch.

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

Parrot | source cross referenced