www.parrot.org | Add test after fixing bugs after context_pmc3 merge | Improve test coverage for FixedPMCArray and NameSpace / Fix Segfaults for Coke / Port Tests to PIR / Merge Stable Branches for 1.6 SOON
Set by moderator on 6 September 2009.
darbelo dukeleto: I'm testing a hack to get you going, wait for the nopaste. 00:00
dukeleto darbelo: coolio 00:01
dalek TT #984 created by dukeleto++: pluggable_runcore branch merge broke build on darwin
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 nopaste.snit.ch/17856
darbelo dukeleto: See if that patch fixes your build. 00:03
You'll need a realclean too. 00:04
dukeleto darbelo; trying now 00:05
darbelo: compiles and passes coretest. do you have a commit bit ? 00:08
darbelo nope.
You should copy the modified file into config/gen/platform/darwin/hires_timer.c and revert the original. 00:09
dukeleto darbelo: anything else? 00:10
purl anything else is violating dry. and we're in the wrong channel.
darbelo You might have to alter MANIFEST, but the Configure system should notice the platform-specific file and ignore the generic one. 00:11
dukeleto darbelo: yes, it seems to 00:12
chromatic Hm, anyone want fewer PMCProxy PMCs created? 00:13
Tene I do!
darbelo dukeleto: You might also want to check the sanity of the profiling runcore's output. 00:14
dukeleto darbelo: how do I do that? 00:15
dalek rrot: r41087 | dukeleto++ | trunk (2 files):
[build] Fix build on darwin by using gettimeofday instead of clock_gettime, darbelo++, darwin--
 00:17
dukeleto please test the latest trunk on your platform to make sure nothing wonky is going on
i am sure ttbot will pipe up soon if I b0rked something 00:18
karma darwin
purl darwin has karma of 12
dukeleto darwin--
chromatic Hm, a 10.51% improvement. 00:20
darbelo dukeleto: try parrot -R profiling some/file.pir ; also nothing broken here. 00:21
dukeleto darbelo: the file gets generated. how do I view the info in it? 00:22
darbelo dukeleto: Your favorite text editor. It's ascii 00:23
dukeleto darbelo: i can see that. i want pretty visualizations :) 00:24
dalek TT #984 closed by dukeleto++: pluggable_runcore branch merge broke build on darwin 00:25
nopaste "chromatic" at 72.87.39.97 pasted "Reduce PMCProxy Creation" (40 lines) at nopaste.snit.ch/17857 00:26
chromatic mikehh, Tene, Coke, can you test that patch with your languages?
dukeleto i would also like a flying unicorn that prints $20 bills
Tene chromatic: just verify that the languages don't fail? 00:27
chromatic Yes.
If you note any speed improvements, I'm happy to hear that too.
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 :).
Tene chromatic: steme passes... working on cardinal now 00:29
looks like cardinal HEAD is broken 00:31
chromatic With the patch or without?
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.
Tene lemme check
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?
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.
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
chromatic Tene, you might need to realclean.
Tene chromatic: Oh. i cna do that. 00:36
rebuilding.
chromatic: it still fails, even after realclean. 00:38
chromatic Okay. Hm. Do you have any Classes with the same name as internal PMCs? 00:39
nopaste "tene" at 24.10.252.130 pasted "Cardinal's classes for chromatic++" (49 lines) at nopaste.snit.ch/17858 00:41
chromatic That's not it either then. 00:43
This should only change the $P0 = new 'SomeString' and $P0 = new $S0 cases 00:44
Tene chromatic: seems to come from somewhere in here: shorl.com/fekodrubodyli
Oh, that might not be helpful. 00:45
chromatic Not as much as the corresponding PIR.
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. :)
Yes, it's one of those. 00:47
nopaste "tene" at 24.10.252.130 pasted "relevant pir for chromatic++" (12 lines) at nopaste.snit.ch/17859
chromatic My guess is the Exception line.
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
cardinalexception has-a exception.
chromatic Oh.
Tene iirc
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.
But, yes, it's hll_mapped.
chromatic If you have a map between Exception and CardinalException, this'll create that type instead.
I can see how that would be wrong.
Revert that bit, and let's see what happens. 00:50
Tene should NQP be generating a root_new for that?
chromatic If you have the core PMC type name there directly... I say no.
Tene OK, realcleaning and rebuilding now. 00:52
That is, should NQP use root_new to implement 'return'? 00:54
chromatic I don't know.
Tene although, this *should* work fine if we were able to subclass PMCs from PIR. 00:55
Which we can't do now anyway.
chromatic This might be the wrong place to fix it.
Tene Yes, cardinal compiles fine with the first part reverted.
s/compiles/runs/ 00:56
I'd be okay with reverting cardinal, though, because that part doesn't work anyway.
chromatic I think this is the wrong approach though. 00:57
Parrot_oo_get_class_str probably shouldn't cause the *creation* of PMCProxy PMCs. 00:58
When called from these ops, all we want to know is if there's a class of that name.
Barring that, instantiate the appropriate PMC directly.
PMCProxy is only necessary when there *is* a class of that type. 00:59
Maybe we need to rethink PMCProxy in general. 01:04
ttbot Parrot trunk/ r41087 cygwin-thread-multi-64int make error tt.ro.vutbr.cz/file/cmdout/84084.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
dalek rrot: r41088 | jrtayloriv++ | branches/gc-refactor (18 files):
Renamed Arenas to Memory_Pools, renamed Fixed_Size_Obj_Pool to Fixed_Size_Pool, updated pdd09 and memory_internals.pod
chromatic In theory, we only need it when something subclasses a builtin PMC.
01:17 Whiteknight joined 01:19 Andy joined 01:20 tetragon joined
japhb Progress! evaling in language: json 01:21
Null PMC access in find_method()
japhb iterates
Whiteknight pluggable_runcore was almost as disruptive as context_pmc3 01:22
and definitely the current poster child for "short-lived branches" 01:23
japhb (unable to rebase continuously)-- 01:25
darbelo Whiteknight: accurate or portable. When it concerns time you can get, at most, one. 01:26
I would have never expected darwin to lack cloack_gettime, specially if it's trying to pass itself off as UNIX :) 01:30
dalek rrot: r41089 | dukeleto++ | trunk (2 files):
[t] Improve the diagnostic message of like() in test_more.pir
 01:31
01:38 kid51 joined
kid51 Whiteknight: Is trac.parrot.org/parrot/ticket/926 closable? 01:59
Whiteknight closed. Thanks 02:02
02:02 sri joined
dalek TT #926 closed by whiteknight++: Kill Parrot_cont structure 02:02
ttbot Parrot trunk/ r41089 cygwin-thread-multi-64int make error tt.ro.vutbr.cz/file/cmdout/84164.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 02:21
darbelo nopaste? 02:30
purl nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others) or gist.github.com/ or paste or gtfo
nopaste "darbelo" at 190.3.155.110 pasted "[PATCH] Fix the cygwin build, I hope." (12 lines) at nopaste.snit.ch/17860 02:32
darbelo Is anyone on cygwin available to test nopaste.snit.ch/17860 ? I think that's what needed to fix ttbot's last complaint. 02:33
02:36 janus joined
dalek rrot: r41090 | jrtayloriv++ | branches/gc-refactor/src/gc (8 files):
Replaced Fixed_Size_Obj_Arena with Fixed_Size_Arena, and corrected some minor errors resulting from last sed replacement.
 02:38
02:38 Andy joined
darbelo msg cotto ttbot reported a broken cytgwin build (tt.ro.vutbr.cz/file/cmdout/84164.txt), after some online research I think nopaste.snit.ch/17860 should fix it. 02:46
purl Message for cotto stored.
cotto i'm here 02:51
(haven't checked the backscroll yet though)
yay. another platform with unreliable profiling information. 02:53
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
cotto nuts
;) 03:08
dukeleto cotto: nice try ;) 03:10
cotto I wonder if I could suc^H^H^Hconvince anyone else to do it. 03:11
at least Devel::NYTProf is there to steal from 03:12
dukeleto cotto: darbelo seems to be pumping out patches. give him a bit already! 03:13
cotto darbelo, did you ever send in a CLA? 03:14
I may be forced to nominate you for a +2 bit of committing. 03:15
japhb Tene, ping 03:21
Tene japhb: pong
japhb For a normal HLL, the sequence is load_language, compreg, .'compile'(), then tailcall the result of the .'compile'(), yes? 03:22
Tene depends on whether you want to trap errors or not. 03:24
.tailcall for not trapping errors, push_eh, invoke, pop_eh, handler for trapping errors
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
OK, sure.
Tene Right.
japhb (And we should do the error-trapping sequence in the NQP version.)
s/version/implementation of eval/
Tene A standing question is what NQP's eval should return on error.
I think that right now it returns undef 03:26
japhb it literally returns the result of the final call.
it's effectively a tailcall without the scope smush
Although ... it's NQP. Maybe the nakedness of that is appropriate. 03:27
Meaning, eval != try
or rather eval !~ try 03:28
Tene Sure.
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:30
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 03:35 tetragon joined
darbelo cotto: no CLA, but I can send one. 03:42
cotto darbelo, if you want a commit bit I'll be glad to nominate you. It's your call. 03:43
darbelo Sure, nominate me. I'll print-sign-send the CLA tomorro^Win the morning. 03:45
03:48 sri joined
cotto will do 04:00
treed The breakage I experience is now directly Cardinal related. 04:04
It's bug 977.
And there was no refactor.
Cardinal's exceptions started that way.
And I haven't moved them to the has-a model yet.
Tene treed: I was remembering Proc or something else.
treed Ah. 04:05
Proc is mega-broken.
Tene Yeah.
treed There's a rewrite scheduled in a few hops.
I just need to get this Object model rewrite nailed down. 04:06
I ran into a problem and haven't had time to investigate it yet.
Once that's in, there's a bunch of stuff that can happen. 04:07
And I move in like a week. 04:09
So tuits will be pretty limited for a while.
(Starting my new job.)
Tene treed: I don't know how much scrollback you read... I was testing a potential patch to parrot for chromatic.
theory chromatic: search on modernperlbooks.com returns a 500.
treed I just tried to look at highlights. 04:10
So anything that mentioned cardinal or my name.
but only so far back
theory Oops, that should have been a /msg. Apologies.
treed What was the potential revert on Cardinal?
Tene treed: it would have made "new 'Exception'" obey HLL mappings, which breaks 'return' because you can't throw a CardinalException. 04:11
because PIR subclasses of PMCs are broken. 04:12
It would mean that we'd have to turn off the Exception HLL mapping until it worked.
treed Oh, yeah.
Tene He decided to investigate another way to do it anyway.
treed I intended to change CardinalException to has-a soonish, anyway.
So rather than reverting, could just do that.
Tene right. 04:13
chromatic We need to fix PIR subclassing before I can do what I want to do.
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.
treed Oh, yeah. 04:14
that was the idea
It's written down in the issue.
cotto Is TT #952 a valid ticket? I don't see the point of a ticket about failing tests in a branch.
Tene yeah
treed chromatic: Fixing PIR subclassing would be awesome.
My current Cardinal project is a new object model.
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.
Which is so inordinately complicated and confusing.
Tene There's now a patch for tt#744, which works around a weird bug elsewhere, but allows HLL interop for my scheme compiler.
chromatic Hm, we could almost make auto_attrs work for PIR classes.... 04:17
darbelo Hmm. What sort of information does the pmc compiler need to automagically 'map' c structure types to unmanaged struct PMCs? 04:22
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?
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.
Tene so... either make a PMC, or abandon the $P0(...) interface.
japhb: although, there's a dirty solution here...
well, depending on whether compreg downcases. I don't remember if it does. 04:25
japhb curiosity peaked ...
"downcases"?
Tene if it doesn't, you could just register the function as compreg 'JSON' and the object as compreg 'json'
japhb oh. Ouch.
Tene Well, if you're renaming it anyway... 04:26
it's... um... compatibility. leaving ht eold interface in place, kind of.
>.>
I recommend just dropping the old one.
japhb But I can't have both on the same filesystem.
(on all platforms)
yeah, going to.
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:32
dalek rrot: r41091 | dukeleto++ | trunk/t/library/test_more.t:
[t] Add another test for like() for matching partial literal strings
 04:33
Tene japhb: that's right. 04:42
04:43 sri joined
japhb Tene, bah. It's not working. I'm missing something obvious, I think. 04:45
nopaste?
purl nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others) or gist.github.com/ or paste or gtfo
Tene japhb: nopaste is also tools/dev/nopaste.pl
purl okay, Tene.
japhb Hmmm, I wonder where I accidently sent that ... 04:46
nopaste "japhb" at 76.191.190.8 pasted "Compiler class for JSON" (61 lines) at nopaste.snit.ch/17862 04:47
Tene japhb: and what doesn't work about that? 04:49
japhb I've gotten each of these:
Class '[ 'JSON' ]' not found 04:50
current instr.: '__onload' pc -1 ((unknown file):-1)
Class JSON already registered!
current instr.: 'parrot;P6metaclass;new_class' pc 884 (runtime/parrot/library/P6object.pir:549)
called from Sub 'parrot;JSON;__onload' pc -1 ((unknown file):-1)
evaling in language: json
Null PMC access in find_method()
current instr.: 'eval' pc 36714 (src/builtins.pir:145)
jrtayloriv goes night night ... zzzzzzz
japhb A tad frustrating, because I can't cargo cult a solution. :-)
Tene japhb: 'sec, lemme try something... 04:51
chromatic Hm, the profiling core aborts for me on trunk. Lovely.
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.
Tene japhb: you also need to use .HLL 'json', compreg 'json', etc. 04:52
japhb Tene, sigh, OK.
Partial case flattening sucks.
nopaste "tene" at 24.10.252.130 pasted "This doesn't fail, and seems to work..." (57 lines) at nopaste.snit.ch/17863 04:53
Tene How does that look, japhb?
dalek rrot: r41092 | dukeleto++ | trunk/t/library/test_more.t:
[t] Add test for dealing with spaces in like()
japhb Tene, merging with my local copy .... 04:54
cotto chromatic, what happens? 04:55
chromatic Run it on a pbc file. 04:56
src/pmc_freeze.c:1336: failed assertion 'must_have_seen'
japhb YES! 04:57
THANK YOU TENE!
Tene++
Frack some of that is non-obvious
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 nopaste.snit.ch/17864
chromatic Hm. Maybe I should rebuild this PBC. 05:00
That worked. Hm. 05:01
cotto sounds like it could be a stale pbc issue
chromatic Sounds like it was. 05:02
cotto does the pbc file contain line numbers from the pir source? 05:08
chromatic I don't think so.
I'm not really sure.
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 rrot: r41093 | dukeleto++ | trunk/t/library/test_more.t:
[t] Fix tests for like() which passed for the wrong reason
cotto That's a good test case, though. 05:11
ttbot Parrot trunk/ r41092 cygwin-thread-multi-64int make error tt.ro.vutbr.cz/file/cmdout/84330.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 05:13
chromatic Wow. src/pmc_freeze.c is full of scary. 05:15
Tene srsly 05:16
cotto mj41++ for having your bot notify me that I didn't actually commit the fix for that failure. 05:18
dalek rrot: r41094 | cotto++ | trunk/config/init/hints/cygwin.pm:
[profiling] use CLOCK_REALTIME on cygwin
 05:20
darbelo fears that his strstart killing travels will lead him into that file. 05:23
chromatic Oh they will....
dalek rrot: r41095 | chromatic++ | trunk/src/pmc_freeze.c:
[src] Tidied code in src/pmc_freeze.c. It's still scary, but at least it's
 05:24
darbelo Yeah. It's the biggest concentration of strstart outside of the src/string directory.
chromatic++ # Making the scary readable. 05:25
cotto chromatic, if it helps, ascii freeze/thaw has been broken since forever. I'm reasonably sure that it never worked. 05:27
ttbot Parrot trunk/ r41093 cygwin-thread-multi-64int make error tt.ro.vutbr.cz/file/cmdout/84396.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 05:28
cotto It'd be nice if the *_ascii_* functions worked, but it might be better just to rip them out. 05:29
dalek rrot: r41096 | dukeleto++ | trunk/t/pmc/namespace.t:
[t] Refactor some namespace pmc tests to use throws_like
 05:30
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
Test writers, we need tests for TT #800.
cotto There's a FREEZE_ASCII define that makes it easy to switch to the broken functions. 05:32
dalek TT #921 closed by chromatic++: warnings in imcc/imcparser.c (statement with no effect) 05:33
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.
Tene considers shutting down the laptop for a memtest run.
chromatic cotto, did we fix TT #898? 05:37
cotto checking
chromatic, no. I'll do that now. 05:38
dalek TT #506 closed by chromatic++: generate callgrind output 05:40
TT #969 closed by dukeleto++: Convert t/pmc/float.t to PIR
dukeleto Tene: reverse heisenbug
dalek rrot: r41097 | dukeleto++ | trunk/t/pmc/float.t:
[TT #969][t] Convert t/pmc/float.t to PIR, flh++
 05:41
rrot: r41098 | tene++ | trunk/ext/SQLite3/SQLite3.pir:
[SQLite3]: Add a few needed functions. This should be moved to library/ eventually.
treed dukeleto: Erm. 05:44
Re: your comment on my bug.
Why wouldn't I be using an installed parrot?
I'm asking the installed parrot for its build_dir. 05:45
Tene treed: link?
treed mail.google.com/mail/?ui=2&vie...gpcgurkovy
er
trac.parrot.org/parrot/ticket/977#comment:10
Regardless, an installed parrot_config should not be returning that error. 05:46
Removing the installed parrot is kinda like removing someone's head because they have a headache.
dalek TT #986 created by darbelo++: [PATCH] Further ->strstart removals 05:47
05:47 kyle_l5l joined
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.
Tene Yeah.
treed If you want to tell me how to use an installed parrot, I'll fix it.
Tene That was from before Parrot even had an install.
chromatic We have had ~30 commits per day in the past week.
Tene treed: or I could even fix it myself... *GASP* 05:48
treed Heh.
Tene trolls himself.
treed You could, although you'd need to modify the Rakefile for that.
Tene I can do that just fine.
I have an editor.
treed k
Don't break it.
Tene That's what I told her. 05:49
treed (It's been getting kinda nasty/convoluted lately.)
I want to reorganize it.
Tene want to borrow my editor?
treed Put all the configuration stuff in one place, all the testing stuff in one place, all the convenience functions in one place.
Nah, I've got my own.
I think yours wouldn't run on OS X without a recompile anyway.
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 ...
dukeleto why is there no Trac component for "tools" ?
Tene dukeleto: I doubt there's a reason, and I doubt anyone would object to it being added. 05:51
dukeleto Tene: can i add one myself? 05:52
Tene: i don't think i have the permissions
Tene dukeleto: I have no idea what the permissions are like on trac.
I recommend a mail to the list, or opening a ticket about it.
I'm done for the evening... 05:53
dalek TT #987 created by dukeleto++: Make breakpoints actually work in parrot_debugger
cotto chromatic, would it be a Bad Idea to have a PMC's VTABLE* be a static variable in Parrot_Foo_get_vtable()? 05:54
chromatic Thread safety might be interesting. 05:55
I don't see any memory leaks in PIR hello, world though.
cotto TT #898 leaks would only occur if you hit dynpmc code that called SUPER 05:56
chromatic Ah.
I do see leaks there now. Grr.
dalek TT #988 created by dukeleto++: Add component "tools" to Trac 05:57
chromatic Parrot_gc_get_attributes_from_pool is leaky.
Tene dukeleto: that ticket is about trac... you should set its component to 'tools'. 05:58
dukeleto Tene: please see recursion 06:00
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 nopaste.snit.ch/17865
chromatic I don't understand it full. 06:04
fully
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
(and obvious optimization is to check at the beginning too)
that minimizes the amount of time when multiple threads could step on each other's toes 06:07
s/and/an/ 06:08
This way the function will always return the right VTABLE*, but it won't need to be freed except at interp destruction. 06:09
It's not perfectly thread-safe, but it'd probably be good enough for something like pmc initialization. 06:10
actually, interp destruction is a problem with that approach. 06:13
dalek rrot: r41099 | cotto++ | trunk/lib/Parrot/Vtable.pm:
[VTable] make some comments less irritating and more informative
 06:30
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
s/sure/not sure/
dalek rrot: r41100 | chromatic++ | trunk/src/gc (2 files):
[GC] Fixed a memory leak in the GC by freeing attribute pools during final
 07:28
purl destruction is, like, www.kuro5hin.org/story/2004/11/11/143618/87
07:34 fperrad joined
dalek lscript: 275e370 | fperrad++ | t/pmc/ (10 files):
refactor PIR tests with ok & nok (instead of is)
 07:37
08:18 Zak joined 08:31 kentnl joined
dalek rrot: r41101 | mikehh++ | trunk/config/gen/platform/darwin/hires_timer.c:
set svn properties
 08:33
TT #988 closed by coke++: Add component "tools" to Trac
a: fc8a480 | fperrad++ | t/pmc/ (16 files):
refactor PIR tests with ok & nok (instead of is)
 08:34
a: e0dd9cd | fperrad++ | t/pmc/ (3 files):
use better type register
a: 718c326 | fperrad++ | (2 files):
fix LUA_PBCPATH for build tree
rrot: r41102 | chromatic++ | trunk/src/pmc/integer.pmc:
[PMC] Replaced some VTABLE calls with macro attribute access in Integer PMC.

microbenchmark, but if you use Integer PMCs for flow control....		 08:40
rrot: r41103 | chromatic++ | trunk/src/pmc/fixedpmcarray.pmc:
[PMC] Tidied FixedPMCArray a minor amount; no functional changes.
rrot: r41104 | chromatic++ | trunk/src/gc/alloc_register.c:
[Contexts] Avoided repeated calls to Parrot_pcc_get_context_struct() when

contents directly. A judicious use of memset() would likely be faster, but a 1.7% performance improvement in the fib.pir benchmark is reasonable. Bigger register sets will have better performance here too.
chromatic Hm, that one was a 3.316% performance improvement in Rakudo's "Hello, world!" 08:41
Very nice.
szbalint only 4987 such improvements left to go :) 08:42
chromatic I think I can get another 3.5% here shortly. 08:46
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
I've poked around in the code and can't seem to see where it comes from
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.
szbalint I'm thinking of setting up benchmarking statistics gathering to visualize how PIR/Rakudo performance changes over time
I don't think it's currently tracked? 08:49
moritz szbalint: did you compile parrot with --optimize?
chromatic I talked to leto and notbenh about that at PDX.pm last week. I'd like to see that.
moritz szbalint: it also hepls to use the fastcore as parrot runcore
szbalint yeah, I tried with a matrix of a couple of options
(on 32bit linux)
moritz did you use num / int registers, or PMC registers? 08:50
szbalint hm, let me nopaste the code. It's the first PIR I've ever written so it's possibly quite shoddy 08:51
scsys.co.uk:8001/33520 08:52
moritz I think that the reverse sub is quite inefficient, and I suspect there's a faster builtin 08:54
but having not written much PIR code myself I don't know how off-hand 08:55
chromatic I was just looking at that.
szbalint oh
moritz I guess you just use scalar reverse in the Perl 5 version?
chromatic Even a resizable integer array would be faster.
szbalint yeah
chromatic Let's see. 08:56
szbalint github.com/perl6/perl6-examples/blo...4-unobe.pl
P6 version
(I killed it after 110 minutes of runtime...) 08:57
scsys.co.uk:8001/33521 08:58
this is the P5 I've used
08:58 masak joined
dalek rrot: r41105 | mikehh++ | trunk/src/pmc_freeze.c:
fix codetest failure and g++ build error
 09:04
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
good night 09:08
dalek a: 2510c17 | fperrad++ | t/pmc/ (15 files):
more refactor, less stringify (typeof -> isa)
 09:09
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 nopaste.snit.ch/17866
szbalint =) 09:21
chromatic 1.833 seconds for me, with the fast core.
moritz don't we have a string reversal method in parrot?
chromatic The fast core for your version is 8.162 seconds.
If you want to go faster, manually inline the reverse function. 09:22
szbalint yeah, it is indeed a lot faster :)
chromatic Algorithmically I can get it faster. Hold on. 09:27
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: projecteuler.net/index.php?section=...s&id=4
chromatic Ah, you can figure it out. It's late here.
Change 'reverse' to 'is_palindrome' and you'll see the improvement. 09:29
purl chromatic: that doesn't look right
chromatic You can bail out a few ops early.
szbalint it's also possible to count down the loop and quit yeah
*quit early
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
chromatic The Perl 5 version (without debugging symbols and such) is about four times faster than my PIR version. 09:32
szbalint same for my version 09:33
chromatic Let's inline.
After inlining, they're about the same. 09:34
Perl 5 may be ~10% faster.
09:34 mokurai left
chromatic Now without debugging enabled in Parrot.... 09:35
szbalint with the JIT runcore, inlined it's about 40% faster for me than P5 09:41
(with debugging enabled in Parrot)
chromatic It's twice as fast as P5 for me with JIT and an optimized Parrot without debugging. 09:43
We're at the point where Parrot's startup time is significant. 09:44
szbalint Yep 09:45
09:48 Ron joined
mikehh rakudo (205733f) builds on parrot r41105 - make test / make spectest (up to r28196) PASS - Ubuntu 9.04 amd64 (g++) 09:49
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 :)
mikehh partcl r697 builds on parrot r41105 - make test Segmentation faults - Ubuntu 9.04 amd64 (g++)
szbalint I guess I'm more interested in the trend than the current speed, both for Parrot and Rakudo 09:53
chromatic Me too, but it's nice to know that the possibility exists to match P5 in speed currently. 09:54
szbalint yeah
although PIR is a lower abstraction level, so it's not entirely apples and oranges 09:55
chromatic Rakudo will never go faster than PIR. 09:57
I believe we can get parts of Rakudo as fast as PIR in certain circumstances. 09:58
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ā¤]
mikehh argh - don't use : after languages :-} 10:01
and also don't start a line with /
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:02
mikehh decnum-dynpmcs r181 builds on parrot r41105 - make test PASS - Ubuntu 9.04 amd64 (g++) 10:07
10:07 HG` joined
treed Whoa. 10:08
Are you guys saying that Rakudo is faster than P5 already?
Or am I misunderstanding? 10:09
Or, wait.
mikehh cardinal - builds on parrot r41105 - rake test:all - same 3 failures - Ubuntu 9.04 amd64 (g++)
chromatic PIR needs to be ten times faster than equivalent P5 for Rakudo to be faster than P5, I think.
The good news is that we can achieve that. 10:10
jonathan Rakudo is decidedly not faster than P5 yet. :-)
mikehh lorito?, nqp?
treed nods.
How much slower as it stands?
jonathan I'm not sure, the figures 10:11
vary quite a bit with program too.
treed But not abyssmally slow or anything. 10:12
(Unlike Cardinal. :-(
Even without Cardinal's parser the test suite takes 30 seconds on Parrot.
And 2 seconds with mainline Ruby.
chromatic Time to profile.
After sleep, anyhow. 10:13
treed heh.
Yeah, sleep time.
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...
I'm pretty sure with a bit of profiling the difference will go down drastically 10:14
mikehh ok - let's see if I can figure out those segfaults in partcl 10:18
jonathan treed: No, Rakudo is horribly slow too. 10:22
purl okay, jonathan.
jonathan Though I know some of the reasons why. 10:23
10:25 payload joined
mikehh messages 10:26
moritz be we NOW HAZ PROFILER! 10:29
s/be/but/
jonathan Anyone ran it on Rakudo yet? 10:35
mikehh jonathan: I did in branch testing - haven't tried since 10:38
moritz jonathan: yes, I did
jonathan Nice. Any interesting results? 10:40
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"'
3031775 10:43
moritz moritz.faui2k3.org/tmp/parrot.out.22749 for t/spec/S03-operators/comparison.t
mikehh supposed to be compatible with kcachegrind 10:44
10:53 Whiteknight joined
Whiteknight good morning #parot 10:54
or #parrot
jonathan mikehh: Yeah, I belive so - didn't work out how to run that yet, but will play with it at some point. 10:57
10:58 bacek joined 11:27 quek joined 11:43 masak joined
bacek O hai 11:46
Whiteknight morning bacek 11:49
bacek Whiteknight: welcome to the future :) 11:50
Whiteknight welcome to the past
szbalint :)
what a wonderful afternoon
Whiteknight szbalint: did you ever get your coretest times down? 11:51
szbalint yep 11:52
Test::Harness was outdated 11:53
that was the cause
bacek Whiteknight: can you fix NEWS please? 11:54
szbalint It went from 3 minutes down to 38s.
jrtayloriv Wow -- looks like we insomniacs have synchronized ourselves.
Morning!
purl Mornings are great. Every time you experience morning, you're not dead yet!
dalek rrot: r41106 | whiteknight++ | trunk/src/pmc/coroutine.pmc:
[pmc] a few simple cleanups and refactors of the coroutine PMC. Removed VTABLE_mark since it was just a redirect to SUPER.
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 rrot: r41107 | bacek++ | branches/tt971_current_context_functions:
Create branch for adding 'current' Context functions as described in tt971
bacek seen chromatic
purl chromatic was last seen on #parrot 1 hours, 52 minutes and 40 seconds ago, saying: After sleep, anyhow.
Whiteknight okay, awesome 12:08
bacek Whiteknight: You broke something badly? 12:09
Whiteknight did I? 12:10
nothing seems broke to me
bacek: how is the Context ATTR work going?
bacek Whiteknight: you did ask it yesterday :) 12:11
Whiteknight did I?
Whiteknight can't remember, very busy day yesterday
bacek I switched to fixed-allocator for Parrot_Context after our chat :)
Whiteknight but does Context use ATTRs? 12:14
12:15 kid51 joined
bacek Whiteknight: no. Because of registers. 12:17
Whiteknight ok 12:21
12:28 JimmyZ joined
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 nopaste.snit.ch/17867
NotFound Someone thinks that fix might give problems? It build and pass tests of parrot, rakudo and partcl 12:31
jrtayloriv kid51, Dozens of sites besides the one I quoted also pointed to DAV 12:34
kid51 Well, today is holiday in US. Hopefully the sysadmins will take a look at that tomorrow. 12:35
jrtayloriv Good deal.
kid51 spends his holiday installing Catalyst
dalek rrot: r41108 | whiteknight++ | trunk/src/pmc (7 files):
[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
kid51 What does "Use the fingerprint to validate the certificate manually!" mean I should do? 12:37
NotFound kid51: you can look at the fingerprint using "Page info" on a browser in www.parrot.org/ for example 12:38
dalek rrot: r41109 | whiteknight++ | trunk/src/pmc/parrotrunningthread.pmc:
[pmc] small additional touchup to parrotrunningthread.pmc
 12:39
kid51 NotFound: that worked; thanks. 12:40
NotFound The certficate is used for *.parrot.org, so is the same for web, trac and https svn 12:47
Whiteknight fperrad: ping 13:01
fperrad Whiteknight, pong 13:02
Whiteknight fperrad: Is TT #472 still a problem?
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:04
Whiteknight jrtayloriv: they should be getting called from macros like mem_internal_foo() 13:05
jrtayloriv Whiteknight, Oh -- I see now. Thanks.
NotFound BTW we must start thinking about not dying on out-of-memory errors 13:06
fperrad Whiteknight, yes
Whiteknight fperrad: okay, I'll see if I can take a look at it 13:07
13:10 quek left 13:12 TiMBuS joined 13:22 Zak joined
dalek rrot: r41110 | whiteknight++ | trunk (4 files):
[ctx] move the context-related functions from src/gc/alloc_register.c to src/call/context.c
 13:26
rrot: r41111 | whiteknight++ | trunk (6 files):
[ctx] move most of the guts from register.h to context.h. Fix POD errors in alloc_register.c and context.c
 13:49
13:50 PacoLinux joined 13:51 payload joined 13:56 Zak joined
dalek a: 097b717 | fperrad++ | t/pmc/ (15 files):
refactor tests with isa_ok
 13:57
a: 6eeb8d9 | fperrad++ | t/pmc/t (2 files):
refactor PIR tests with throws_like
rrot: r41112 | whiteknight++ | trunk (7 files):
[ctx] delete the unneeded files register.h and alloc_register.c.
 14:03
14:29 MoC joined
dalek rrot: r41113 | whiteknight++ | trunk/config/gen/makefiles/root.in:
[makefile] fix a dependency error introduced by the context stuff
 14:31
lscript: 9f6b142 | fperrad++ | t/pmc/ (10 files):
refactor PIR tests with isa_ok
 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).
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:38
14:46 kid51 joined
nopaste "kid51" at 68.237.13.98 pasted "t/compilers/tge/grammar.t failure at r41109 on Darwin/PPC" (26 lines) at nopaste.snit.ch/17870 14:48
kid51 Hmm, when I ran 'make test', that showed up as a FAIL rather than a TODO. 14:51
14:52 kjeldahl joined 14:53 Psyche^ joined
Whiteknight jrtayloriv: i say kill the 15:03
them
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
or better yet, do simple stuff like that in trunk
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
and readability is a very good thing
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
Unless, someone else wants to do more with it.
Whiteknight tomorrow at #ps we'll ask allison to review it for sanity 15:11
I'll take a look over it a little later on to make sure everything makes sense first
dalek TT #989 created by jkeenan++: t/compilers/tge/grammar.t: FAIL under 'make test', but passes with ...
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:12
dalek rrot: r41114 | whiteknight++ | trunk/t/pmc/namespace.t:
[t] make sure to pop_eh for every time we push_eh
 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
jrtayloriv Whiteknight, Sounds good. I'll finish up with the changes today, and then be done. 15:27
dalek rrot: r41115 | NotFound++ | trunk/src (2 files):
[core] load bytecode and dynops in HLL 'parrot' conext, TT #150
 15:37
rrot: r41116 | jrtayloriv++ | branches/gc-refactor/src (12 files):
Removed unused GMS code from various places.
 15:51
15:57 cotto joined
jrtayloriv purl: GMS is "Good Morning Sunshine" 16:00
purl ...but gms is Growling Mad Scientist or Generational Mark and Sweep...
Whiteknight purl GMS is also Good Morning Sunshine 16:05
purl okay, Whiteknight.
Whiteknight purl GMS is also Goddamn Motherhonking Shit 16:06
purl okay, Whiteknight.
cotto hi 16:09
dalek TT #990 created by whiteknight++: Cannot lookup ISO-8859 NameSpace using Unicode 16:11
Whiteknight hello cotto 16:12
16:15 darbelo joined
NotFound Whiteknight: are you writing that file with mixed encodings? 16:18
dalek rrot: r41117 | whiteknight++ | trunk/t/pmc/namespace.t:
[t] add reference to TT #990 to the test that is giving me grief
 16:19
Whiteknight NotFound: what do you mean?
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.
Whiteknight NotFound: okay, I'm not even sure what that means. 16:21
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.
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
nopaste "NotFound" at 213.96.228.50 pasted "patch: namespace.t mixing charsets" (111 lines) at nopaste.snit.ch/17871 16:51
NotFound Whiteknight: that way is reasonable
17:03 payload joined
Whiteknight NotFound: thanks, I was hoping it would be easier but this isn't a problem either 17:11
jrtayloriv In what timezone is #parrotsketch at 6:30? 17:12
moritz UTC
ps?
purl ps is probably postscript or process status or see "parrotsketch" or non-vector?! or annoying.
jrtayloriv moritz, thanks 17:13
moritz parrotsketch?
purl i heard parrotsketch was a status meeting for parrot core committers held every Tuesday at 18:30 UTC in #parrotsketch
jrtayloriv Aah -- parrot.org just says 6:30PM -- no time zone.
moritz on which page?
oh, in the calendar
I don't think I can fix that
17:14 einstein joined
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:14
Whiteknight it's actually UTC, not GMT 17:15
when daylight savings time rolls around, about half the people don't make it
NotFound It explicitly says is GMT for me, but maybe that text is hidden depending on browser and font size
dalek rrot: r41118 | whiteknight++ | trunk/t/pmc/namespace.t:
[t] Apply a patch from NotFound++ to make the unicode stuff work properly
moritz Whiteknight: GMT doesn't imply DST
jrtayloriv obviously knows nothing about anything but US time zones ... thought they were the same thing :)
Whiteknight I had heard that they weren't the same. I may be wrong
moritz the difference between GMT and UTC is neglectible (a few seconds, or parts of seconds even)
NotFound So youn need to find another excuse for arriving late to #ps ;-) 17:17
moritz date --utc is rather useful.
NotFound The google calendar page shows it in your local zone... provided you setup one in your accont. 17:18
Whiteknight timezones are such a stupid idea 17:19
NotFound I'm making a proposal to make the earth squared
I just need to get funds to buy four elefants and a a turtle... 17:20
17:21 jbert joined
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.
So I need the funds anyway 17:24
darbelo could accept a squared earth as a step towards cubed time. 17:28
NotFound And a scorched planet?
darbelo As long as it is on the other side of the cube, I'm fine with it :) 17:29
17:37 rhr joined
dalek kudo: e2eaf33 | pmichaud++ | src/builtins/globals.pir:
Remove contextual fallback to %*ENV (as per r28193).
 17:38
rrot: r41119 | whiteknight++ | trunk/t/pmc (2 files):
[t] convert another NameSpace test to PIR
 17:39
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?
dukeleto my test suite has been hung on t/pmc/threads.t for like 9 hours now 17:42
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
dukeleto cotto: will try that as well 17:44
cotto then just look for whichever way the most recent test run was started
it's usually just an issue of figuring out which flags were passed to parrot
dukeleto "make test" does not hang on threads on darwin. i am checking a "make fulltest" with no parrallelization now 17:45
17:46 mokurai joined
dukeleto cotto: it seems to work fine without -j 17:46
dalek kudo: 8d5a40a | moritz++ | t/spectest.data:
add contextual.t to spectest.data, pmichaud++
 17:50
kudo: c1d96ce | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 435 files, 14255 pass, 0 fail
rrot: r41120 | whiteknight++ | trunk/t/pmc (2 files):
[t] convert one more test to PIR
 17:53
chromatic Wow, that's 850 new passing Rakudo tests since yesterday.
szbalint wow 17:54
szbalint is impressed
moritz I think a good deal was colomon++ adding tests like mad
Whiteknight I need an example Unicode string for a test
moritz mostly for trigonometric functions
Whiteknight: I like ā‚¬uros ;-)
Whiteknight moritz: what's the ASCII version of that? 17:55
\\x{?}uros
moritz ā‚¬ is not in ASCII.
szbalint ā‚¬ is ā‚¬ :)
Whiteknight right, what's the number for that glyph?
Whiteknight doesn't know all the terminology, be patient 17:56
moritz U+20AC EURO SIGN
it's called the "codepoint" number
Whiteknight so \\x{20AC}uros
moritz right
Whiteknight w00t
NotFound Whiteknight: I'm not sure, but I think imcc result is more predictable with \\u20AC 17:57
Whiteknight ok 17:58
Whiteknight adds another item to the list of reasons to kill IMCC in a fire
moritz there are codepoints that don't fit into 4 hex digits 18:00
darbelo hands Whiteknight some matches.
NotFound moritz: you have \\U for that
moritz \\Uhm.
dukeleto gives Whiteknight a fully-charged flamethrower with a few extra barrels of napalm 18:01
chromatic We should have a pirc sprint soon. 18:02
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
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
dalek rrot: r41121 | dukeleto++ | trunk (2 files):
[TT #887] Remove unused macro args in CHARSET_VALIDATE, jimmy++
rrot: r41122 | whiteknight++ | trunk/t/pmc (2 files):
[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
Whiteknight and the majority of them are written in PIR now
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?
moritz isn't Array justa base class? 18:09
dukeleto Whiteknight: Array cannot change it's size?
Whiteknight or better phrased, why do we have both?
NotFound Array is a role, or something
Whiteknight dukeleto: so then what is the difference between FixedPMCArray and Array?
NoFound: we have tests for Array where it is directly instantiated
NotFound Whiteknight: "FixedPMC" ;)
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
NotFound Ah, yes, Array != array
18:13 nillo joined
NotFound Looks like Array is a tiny wrapper for src/list.c 18:14
dukeleto moritz: yeps. one example; trac.parrot.org/parrot/ticket/943
pmichaud (codepoints) I don't think the issue is an irc issue, but a PIR one 18:15
s/irc/imcc/
18:16 iblechbot joined
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.
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.
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.
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
chromatic First we have to get pirc to the point where it compiles and we can start running tests.
pmichaud einstein: I think the opcodes were designed to match Perl 6's idea of "properties" on objects (more) 18:20
einstein: at this point I'd say it makes more sense to change the _metadata field to be _props :)
dalek rrot: r41123 | cotto++ | trunk/tools/dev/pprof2cg.pl:
[pprof2cg] add documentation to pprof2cg
einstein but it
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
pmichaud I don't understand "variable members of a class"
(in this context)
if you mean that properties are not attributes... you're correct. 18:22
einstein yes
NotFound That's because they are called metadata instead of data ;)
pmichaud attributes are defined in a class, such that all instances of the class have slots for those attributes
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)
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?
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?
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
japhb NotFound, yeah. JSON.pir to be exact.
einstein so if you clone a object these properties do not get copied
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.
dukeleto japhb: use svn copy ?
japhb dukeleto, to change the case of the file?
dukeleto japhb: that way you preserve file history
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
18:26 sri joined
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:26
18:27 sri joined
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.
dukeleto japhb: not sure if svn is case-senstive . this is why you don't track content with files. you track content :)
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)
dukeleto, preaching to the choir, son.
chromatic dukeleto, that's the one.
dukeleto japhb: gotcha. sorry!
japhb dukeleto, np!
18:29 HG` joined
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:29
NotFound Uhhh... right 18:30
japhb Because once again, Bill Gates Was Wrong.
Not that I'm bitter. 18:31
dalek rrot: r41124 | dukeleto++ | trunk/src/pmc/env.pmc:
[cag] Fix link to pdd17 in src/pmc/env.pmc
18:31 joeri joined
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.
cotto intersting
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
cotto forget intersting 18:32
purl cotto: I forgot intersting
japhb NotFound, that's radical all right.
NotFound Let's radical!
japhb Tene.'ping'() 18:33
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
japhb: no, not as far as I know
dalek rrot: r41125 | cotto++ | trunk/tools/dev/pprof2cg.pl:
[pprof2cg] various spelling fixes
japhb Tene, OK, thank you.
Tene japhb: you'd likely run into problems if you use a / or \\ in it
japhb heh
Damn, no language named 'c:\\/' 18:35
Tene ><
Tene larts japhb
japhb heh
NotFound Tene: Have you looked at TT #150 ?
Tene NotFound: I reported it
japhb OK, in all seriousness, anyone object to 'data_json'?
dukeleto japhb: for a language name? 18:36
japhb dukeleto, for a language name that is *not* 'json'. :-)
NotFound Tene: at the last comments, I mean
Tene i have now :) 18:37
NotFound: I'll try to test by reverting the workaround in cardinal and rakudo.
dalek rrot: r41126 | cotto++ | trunk/tools/dev/pprof2cg.pl:
[pprof2cg] one last (?) grammar fix
 18:38
kudo: 6b22b9d | moritz++ | Configure.pl:
when --gen-parrot-prefix is passed along, we should also search in that path for parrot_config
kudo: 446d49f | moritz++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
NotFound Tene: the problem is that I haven't figured how to write a parrot regression test for it
japhb OK, I'm taking silence as assent. 18:39
dukeleto japhb: i can't think of anything better 18:41
japhb dukeleto, nod
dukeleto should a ticket like 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' ....
Tene NotFound: are there tests for loadlib and dynpmc? 18:43
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.
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.
dukeleto Tene: i don't want it. it 'causes errors at a distance 18:45
Tene dukeleto: it *returns* something different on failure.
So if you always check your return values, you're fine...
but I'd love to see it throw an exception.
dukeleto Tene: you can check the return value of loadlib?
Tene $P0 = loadlib 'libfoo'
NotFound Tene: will be a problem to build an HLL just for that test 18:47
Tene NotFound: um, no it won't... 18:48
.HLL 'foo'
done
or do you mean dynpmcs?
I'd think you could just reuse whatever the dynpmc tests use.
dukeleto Tene: what about .loadlib ?
Tene dukeleto: there's no way to check for failure of .loadlib
18:48 nillo joined
NotFound That's is far away from my know-how on writing tests 18:49
Tene I wouldn't mind seeing it deprecated.
dukeleto Tene: *that* is what pisses me off
Tene and just put it in a :immediate .sub if you need it to happen at that time.
dukeleto Tene: so .loadlib is immediate while loadlib happens at runtime ?
Tene dukeleto: yes.
dukeleto Tene: you need to use .loadlib for dynops, right ? 18:50
Tene I have no idea at all.
It wouldn't surprise me.
You could still do it in a :immediate sub, though, I'd suspect.
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
Tene dukeleto: .loadlib *definitely* should fail loudly.
dukeleto Tene: why can't .loadlib throw an exception ?
Tene: it currently does not 18:51
dalek rrot: r41127 | japhb++ | trunk/compilers/nqp/src/builtins.pir:
[compilers/nqp] remove unneeded debug output from eval()
Tene dukeleto: It certainly *could*.
NotFound There is a problem with catching exceptions thrown inside imcc
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
Tene dukeleto: yes, that would be great.
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
we have the shiny new throws_ok() test_more.pir function to play with 18:53
s/throws_ok/throws_like/
NotFound Current behavioir sucks, but I don't think it can be cleaned until all packfile things are handled via pmc.
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 ?
moritz: just about no one checks the return value now
moritz t/pmc/nci.t 18:55
does
as well as some t/dynpmc/*.t
NotFound dukeleto: if you throw an exception while imcc is compiling or executing fixups, the packfile structures may stay in an inconsistent state.
Tene moritz: and it's impossible to test the return value of .loadlib
dukeleto NotFound: that makes a lot more sense to me, thanks! 18:56
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
dukeleto Whiteknight: let me at it. what's up?
Whiteknight match failed: target 'destination namespace not specified' does not match pattern 'destination namespace not specified'
...and I can't think of a better match
dukeleto Whiteknight: whitespace in a PGE pattern is ignored. you need to backslash it
moritz is that a regex?
or simply add an :s at the start
':s destination namespace not specified'
dukeleto Whiteknight: see the tests for test_more.pir in t/library/test_more.t 18:58
moritz: now you tell me!
moritz dukeleto: you were free to read S05 all the time ;-) *SCNR*
dukeleto Whiteknight: yes, please go with :s instead of backslashitis. feel free to change the tests to use :s instead of backslashitis :)
dalek rrot: r41128 | japhb++ | trunk/compilers/data_json (2 files):
[compilers/data_json] Straight copy of compilers/JSON; probably broken right now
Whiteknight ah, that fixes it 18:59
dukeleto moritz: freedom didn't have much to do with it ;)
Whiteknight I was using the slashes, but I had double quotes not single ones
so I was double-breaking it
dukeleto Whiteknight: yeah, backslashitis sucks
does anybody a favorite Perl 5 testing function that they would like to see in test_more.pir ? Preferably useful ones :) 19:02
dalek rrot: r41129 | cotto++ | trunk (3 files):
[profiling] add news item, update imcc options and helpful output to profiling exit message
Whiteknight the pure-PIR version runs 70 tests in .3s. the Perl version runs 38 tests in 1.5s 19:04
brb 19:05
dalek rrot: r41130 | japhb++ | trunk/MANIFEST:
Update MANIFEST for data_json and a couple stragglers
 19:06
rrot: r41131 | whiteknight++ | trunk/t/pmc (2 files):
[t] convert 4 more tests using throws_like. Help from dukeleto++ and moritz++.
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 19:11 Whiteknight joined
dukeleto chromatic: where is the source to your Project Euler #4 ? i want to put it in euler_bench :) 19:11
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:15
why do i not always get i object such a i get when i have subclassed i core pmc class 19:16
19:17 kyle_l5l joined
dalek TT #990 closed by whiteknight++: Cannot lookup ISO-8859 NameSpace using Unicode 19:17
NotFound einstein: because a class instance is not the same as a pmc instance 19:20
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
19:23 quek joined
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.
Whiteknight einstein: that sounds right
19:24 pdcawley_ joined
einstein when i would do getattribute $P5,eh,'handled_types' where eh = new ['ExceptionHandler'] then i get error, but ... 19:24
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:25
Tene einstein: there are currently problems with subclassing PMCs from PIR, exactly what you're describing. 19:27
This is something that is planned to be fixed.
einstein is there a ticket for this?
19:27 pdcawley_ joined
Tene For exceptions specifically, subclasses of Exception and ExceptionHandler don't work. 19:27
I believe so.
NotFound throw is explicitly filtering anything but 'Exception' 19:28
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
which was one in the exception handling test cases
It was just a test of my to see how much would be failing if I removed this thing 19:30
NotFound einstein: Removing what? 19:31
purl Removing is probably backwards compatible
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:32
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.
Tene einstein: I believe that there is, but I don't know.
cotto Coke, gotcha 19:36
darbelo Hm. Is the next_for_GC pointer in PMCs actually useful for something?
szbalint duk3leto: perl6-examples
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
Coke Whiteknight: on #990 - /how/ did he fix your issue? 19:42
msg Whiteknight on #990 - /how/ did he fix your issue?
purl Message for whiteknight stored.
NotFound Coke: r41118 19:44
19:46 allison joined
Tene hi allison 19:46
allison hi Tene 19:47
19:47 particle joined
cotto wb allison 19:48
we've been busy while you've been gone
Tene allison: is there any reason that .loadlib fails silently? 19:49
allison cotto: excellent!
purl EGG-see-lent!
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
Tene: that may no longer be true
Tene allison: so would there be any objection to making it throw an exception? 19:51
allison none at all
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
dukeleto Tene: sweet 19:53
allison which means probably after 2.0 19:54
dalek TT #591 closed by cotto++: pir profiling tools 19:55
19:58 rhr joined
dalek rrot: r41132 | japhb++ | trunk/config/gen/makefiles/data_json.in:
[data_json] svn copy makefile skeleton: json.in -> data_json.in
 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, beta joined
allison We use git because it's stable, reliable, and easy for new programmers to pick up quickly. 20:03
Tene: We won't be making any more infrastructure changes until after 3.6, but might consider git then. 20:04
20:04 MoC joined
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:04
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.
Tene: but, it could make a good bit of progress there in the next couple of years
NotFound: also possible
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
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
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.
allison s/git/svn/ in that first sentence
Tene Of course. :)
dukeleto allison: ah, you were confusing me a bit :)
20:07 kid51 joined
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:08
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
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
dukeleto allison: there has been a lot of weird technical issues with the svn repo recently. people couldn't properly merge for unknown reasons
NotFound I don't have any problem with branches in git... because I've never used git other than for clone and diff
allison lately I've been moving more toward Patrick's branching strategy 20:11
he uses a series of fresh branches from trunk
instead of updating the branch from trunk
it's much cleaner
and encourages code review every time you rebranch 20:12
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
kid51 feels that merging from trunk into branch is risky regardless of VCS 20:14
Whiteknight keep them focused, short-lived, etc
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.
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.
Whiteknight besides the issues over the weekend (which I think jrtayloriv has diagnosed), I haven't had any issues with branching 20:18
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.
Whiteknight jrtayloriv: which branch was that? 20:21
dukeleto gc-refactor ?
jrtayloriv kill_parrot_cont was the branch that was causing so many issues the other night.
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
or better question, what can we laypeople do to help nudge that branch along?
dalek rrot: r41133 | dukeleto++ | trunk (3 files):
[t] Finish translating t/pmc/integer.t to PIR and delete old file
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
Whiteknight allison: okay, that's probably a good idea. Like I said, lots of changes since that branch was created
kid51 Whiteknight: I just posted in TT requesting a description of that branch's objectives.
allison Whiteknight: but, do need to get the last ~500 tests passing first
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
Whiteknight: just take a look at failing tests
Whiteknight Okay, I'll dive in. Probably later tonight 20:25
Whiteknight has to take off. Later
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 rrot: r41134 | dukeleto++ | trunk/t/pmc/integer.t:
[cage] Removed unused/commented out code from t/pmc/integer.t
Whiteknight allison: will do. Post to a ticket or email you directly?
allison It's a branch, so not ticket-worthy.
email or IRC works
Whiteknight okay. Noted. 20:27
see you later
allison Whiteknight: later
NotFound Have you looked at TT #150? Maybe that issue is also creating pcc problems. 20:28
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
allison NotFound: looking now 20:31
kid51 Speaking of branches ... 20:32
allison kid51: yes, I wrote that a while ago, for the strategy I was using at the time
kid51: it's worth adding a note "for large changes or long-lived branches"...
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 trac.parrot.org/parrot/ticket/509 ? Thanks. 20:33
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.
All my systems are symlinkable, so I can't test it properly myself. 20:35
I applied wayland's most recent patch in branch in the hope that we can resolve the ticket.
Don't claim to understand the issues completely myself.
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:37
20:38 davidfetter joined, quek left
dalek rrot: r41135 | jkeenan++ | trunk/docs/project/branching_guide.pod:
Qualify advice about synchronizing branch with more recent changes in trunk.
 20:40
cotto kid51, revision number isn't required for svn >= 1.5.x 20:42
NotFound cotto: on the client, server, or both?
kid51 cotto: what are you referring to? the POD?
cotto as long as the branch was created with a svn client >= 1.5.x
both, but the server iirc has been upgraded 20:43
kid51, yes
kid51 cotto, you're probably correct -- but can we assume that everyone is using a recent SVN client? 20:44
cotto no. I'd suggest a note that users of recent svn clients don't need to record the revision number. 20:45
20:47 bobke joined
dalek rrot: r41136 | mikehh++ | trunk/MANIFEST:
run tools/dev/mk_manifest_and_skip.pl
 20:47
kid51 cotto: Feel free to add it. (Today was first day I was aware of that POD.) gotta go. 20:48
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. 20:54
dalek rrot: r41137 | japhb++ | trunk (10 files):
[data_json] Now with less horribly borken; frob makefile templates, svn properties, manifests, etc. to match
 21:07
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41136 - Ubuntu 9.04 amd64 (g++) 21:12
21:19 jrtayloriv joined
dalek kudo: f01875f | moritz++ | tools/test_summary.pl:
[test_summary.pl] if we run a test, use the "plan" information gathered from its output
 21:20
mikehh rakudo (446d49f) builds on parrot r41136 - make test / make spectest (up to r23204) PASS - Ubuntu 9.04 amd64 (g++) 21:27
dalek kudo: 01ae3fa | moritz++ | docs/release_guide.pod:
[docs] propose ThousandOaks as a release name, in recognition of their cool Perl 6 hackathon
 21:32
mikehh partcl r697 builds on parrot r41136 - make test Segmentation faults - Ubuntu 9.04 amd64 (g++) 21:34
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:38
NotFound It doesn't fail for me 21:39
mikehh NotFound - how did you fix it - maybe I need to do a clean checkout
NotFound mikehh: I didn't do anything 21:40
Rebuilding now without --optimize 21:41
All test pass, no core 21:49
dalek ose: r100 | Austin++ | trunk/ (14 files):
Another refactoring checkpoint. Cross-nsp calls working now. Starting
mikehh cardinal - builds on parrot r41136 - rake test:all - same 3 failures - Ubuntu 9.04 amd64 (g++) 21:52
dalek rrot: r41138 | japhb++ | trunk (3 files):
[data_json] More pedantic .HLL handling; switch examples/json/* to use data_json (with minor cleanups)
 21:54
mikehh decnum-dynpmcs r181 builds on parrot r41136 - make test PASS - Ubuntu 9.04 amd64 (g++) 21:55
22:01 bacek joined
jrtayloriv growls at svn and begins installing git-svn 22:07
22:10 tjc joined
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
mikehh I think I am going to reboot - check some i386 stuff and then clean up everything and see what happens 22:12
darbelo mikehh: can you test a patch on i386? 22:13
mikehh darbelo: when I re-boot - hold on about 10 minutes 22:14
bbl
darbelo I can wait a lot more thatn that :)
22:16 joeri left 22:20 ruoso joined
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:25
darbelo grabs his machete and walks into pmc_freeze.c 22:29
22:36 Andy joined 22:39 buildbot joined 22:42 jan joined 22:43 rg1 joined
bacek Good morning 22:46
purl And good moroning to you, bacek.
bacek jrtayloriv: yes, I'll review your branch later today.
jrtayloriv bacek, thank you
dalek rrot: r41139 | bacek++ | trunk/src/runcore/cores.c:
[cage] Initialise coredata->flags
 22:52
rrot: r41140 | bacek++ | trunk/include/parrot/context.h:
[core] Manually inline REG macros for optimised builds
22:53 mikehh joined
mikehh back on i386 22:54
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:55
jrtayloriv bacek, I'm getting git-svn installed at the moment -- I tried to sync with trunk and svn kept dying. 22:56
But once I do, then yes, I will sync it up.
bacek jrtayloriv: ok. You have about ~10-12 hours before I can start proper reviewing :)
jrtayloriv ok 22:57
bacek msg whiteknight Can we remove ifdef _WIN32 for GC_USE_FIXED_SIZE_ALLOCATOR now?
purl Message for whiteknight stored.
dukeleto Parrot VM: PANIC: Out of mem! 23:02
i am working on translating FixedPMCArray to PIR and adding more tests. i think I just found a nice bug :)
dalek rrot: r41141 | bacek++ | trunk/NEWS:
Fix small typo in NEWS about Contexts.
 23:03
japhb bacek, it looks like you nuked the NEWS about the profiling runcore
bacek japhb: nope :) 23:04
japhb bacek, I'm confused by the changeset diff then. 23:05
bacek japhb: context_pmc3 branch
japhb bacek, but you changed NEWS in trunk ...
bacek japhb: Bah! Gotcha. 23:06
Fixed. 23:07
dalek TT #991 created by dukeleto++: Parrot dumps core when attempting to create a FixedPMCArray with negative ...
bacek $dayjob time. Better to stop braking parrot and return to "stupid manager" duties... 23:08
see you!
dalek rrot: r41142 | bacek++ | trunk/NEWS:
Readd NEWS about profiling runcore. bacek--, japhb++
 23:09
darbelo mikehh: can you give the patch attached to TT#986 a test? JIT in particular. 23:10
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:18
23:32 Andy joined
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
Whiteknight good evening, #parot 23:51
or parrot
darbelo Whiteknight: I have a surprise for you. 23:53
Whiteknight ???
darbelo Remember the next_for_gc abuse in pmc_freeze.c you disliked so much? 23:54
It's dead code. there's a #define there disabling it. 23:55
23:56 bacek joined
darbelo I just amputated it with no test failures. 23:56
Whiteknight holy shit. darbelo == awesome 23:57
do you have the commit bit yet?
dalek rrot: r41143 | jrtayloriv++ | failed to fetch changeset:
Merged changes from r41010 to r41116
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.
All I did was remove a lot of dead code :) 23:58
Whiteknight nice, so I can remove that garbage from the GC then 23:59
and there was much rejoicing
purl yay.
dalek TT #940 closed by whiteknight++: miniparrot segfaults on Windows
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.

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!