HTTPS CERT EXPIRED | 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 3 September 2009.
00:18 japhb joined
dalek TT #976 created by darbelo++: [PATCH] Reduce poking into STRING guts 00:30
darbelo Boy, is the code to freeze PMCs ehm... special. 00:36
chromatic Very. 00:37
Whiteknight NO SARASM!
that code is shit and will be addressed as such 00:38
darbelo Whiteknight: But it's doing it all FOR SPEED! It is -optimized- shit. 00:39
Whiteknight yeah, I'm sure it does exactly what it did in 2004 at top speed 00:40
and we can't make it do any more then that since it's such a mess
cotto chromatic, any thoughts on the profiling runcore code? 00:41
chromatic Haven't quite made it to that yet today.
darbelo It also appears to know more about the internals of strings than the string subsystem itself.
Whiteknight adds the freeze/thaw system to the ever-growing list of things that need to be freaking keel-hauled 00:43
cotto If there weren't so much crap to rip out and rewrite, would you really be happy?
By 4.0 Parrot won't have any crappy subsystems left and we'll all sit around being bored. 00:45
Coke yes.
(be happy)
cotto (6.0 if our deprecation policy stays in place) 00:46
darbelo wonders who thought abusing the next_for_GC pointer here was a good idea. 00:47
Whiteknight darbelo: I don't know, but I would like to find that person and abuse them 00:59
cotto: I would be very happy to be working with better software, and knowing that more people were using Parrot 01:00
I probably wouldn't contribute as much, but I would be happy
cotto I'm joking of course. I'd be thrilled if right now someone submitted a patch that did all the stuff we're working toward.
darbelo, keep up the good work. only 60-70 more patches to go! 01:04
dalek TT #976 closed by cotto++: [PATCH] Reduce poking into STRING guts 01:05
rrot: r40965 | cotto++ | trunk/src (4 files):
[string] remove more ->strstart abuse, courtesy of darbelo++
 01:07
darbelo is slayin' the dragon, one scale at a time. 01:08
cotto I'd really like to figure out a good testing strategy for the profiling runcore.
Whiteknight holy crap, why isn't darbelo a committer by now? 01:09
darbelo cotto: testing that it runs ok or that it profiles ok?
cotto both, plus tests for the postprocessing script 01:10
Whiteknight cotto: take a known sample program, profile it, and save the output to compare
darbelo Whiteknight: I think he's measuring absolute times, that would change a lot from one arch to another. 01:12
cotto The thing is that I'll also eventually want to be able to completely change the pprof format to be binary instead of ascii.
however, if the code is smart enough to output either I can test ascii and use the binary 01:13
for actual profiling work
but that can wait until -e "1" profiles with Rakudo 01:14
dalek rrot: r40966 | cotto++ | branches/pluggable_runcore/tools/dev/pprof2cg.pl:
[profiling] parameterize the last global and do some minor code cleanup
 01:28
darbelo goes on the hunt for sleeps. 01:29
01:30 darbelo left 01:37 s1n joined 01:46 Andy joined
dalek tracwiki: v32 | bacek++ | ParrotQuotes 01:59
tracwiki: Big O notation explanation by chromatic
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
tracwiki: v33 | cotto++ | ParrotQuotes 02:09
tracwiki: sarcasm will not be tolerated
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
tracwiki: v34 | cotto++ | ParrotQuotes
tracwiki: "sacrasm" won't be tolerated either
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
rtcl: r686 | coke++ | trunk/runtime/builtin/file.pir:
First attempt at [file delete]
 02:14
rtcl: r687 | coke++ | trunk/t/cmd_file.t:
Hey, I bet this joke was really funny 4 tests ago.
rtcl: r688 | coke++ | trunk/runtime/builtin/file.pir:
PIR cleanup
02:15 cognominal joined 02:16 mokurai joined
Coke my segfaullllllts. feeeeex theeeeeem. 02:19
02:35 janus joined 03:02 sri joined 03:18 theory joined 03:20 donaldh joined 03:21 dukeleto_ joined 03:26 Andy joined 03:36 Andy joined 04:38 asciiville joined 05:13 payload joined 05:22 HG` joined
dalek rrot: r40967 | mikehh++ | trunk/src/gc/mark_sweep.c:
codetest failure - trailing spaces
 05:33
cotto seen kid51 05:37
purl kid51 was last seen on #parrot 1 days, 3 hours, 44 minutes and 47 seconds ago, saying: kill_parrot_cont branch: Smolder test on Darwin/PPC: smolder.plusthree.com/app/public_pr...ails/26802 [Sep 3 01:46:03 2009]
dalek rrot: r40968 | mikehh++ | trunk/src/pmc/string.pmc:
codetest failure - space after opening parenthesis
 05:40
rrot: r40969 | mikehh++ | trunk/src/pmc/hash.pmc:
codetest failure - isxxx() function not cast to unsigned char
 05:43
cotto How are functions like pir_output_is generated? 05:44
let0 cotto: good question. there is magic in Parrot::Test 05:47
cotto: what do you want to know?
cotto I want to add a set of functions that capture and test the output of the profiling runcore and make sure pprof2cg's output is sane
instareply
let0 cotto: you want to do this in PIR or perl ?
i am writing pir_error_output_like in PIR now-ishly 05:48
let0 is hacking and drinking with a bunch of pdx.pm perl hackers at the #pdx hackathon
cotto Excellent. We'll need stuff like that.
I'd teleport over there to join you, but I can't teleport. 05:49
let0, do you understand the perly magic?
let0 cotto: understand, yes. like, no. 05:50
cotto: the way it is implemented, it reduces the amount of code that needs to be written, but it is very complex/non-intuitive/hard-to-debug code. but it works if you don't touch it...
cotto Yeah. I got the impression that it generated functions. 05:51
let0 cotto: are you trying to capture STDOUT or STDERR ? 05:52
or an exception ? or just normal output?
cotto STDERR sounds best. Currently the profile goes to a file, but stderr sounds like the best place for testing purposes. 05:53
I also want to be able to capture the profiling output in order to test pprof2cg 05:57
let0 cotto: you want to do this from PIR? 06:04
cotto perl is fine
pir would be ideal to avoid creating more perl tests, but I'll take what I can get 06:05
let0 cotto: pir_error_output_like already exists for perl. i am trying to make it work for PIR
cotto you're right. it's plausible to adapt that 06:08
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40969 - Ubuntu 9.04 amd64 (gcc)
cotto chromatic, ping 06:10
mikehh let0: I am getting a backtrace from t/tools/parrot_debugger.t - I think test 41 06:12
NotFound mikehh: you're not alone
let0 mikehh: can you nopaste
mikehh we had this briefly - then it went away - but came back the merge of context_pmc3 branch (on amd64 anyway) 06:13
NotFound It segfaults at Context.destroy
nopaste "mikehh" at 94.3.240.143 pasted "prove -v t/tools/parrot_debugger.t - trunk at r40969 - Ubuntu 9.04 amd64 (gcc)" (163 lines) at nopaste.snit.ch/17802 06:16
cotto chromatic or anyone: I'd like to add an option to parrot that causes the profiling runcore to write its output to a non-default location. What's the best place to stick that info between when the option gets processed and the runcore gets initialized?
mikehh NotFound - yes I think so - it happened in trunk just after some changes by dukeleto - but I think you fixed it - but it came back in context_pmc3 branch 06:19
let0 mikehh: that is a hilarious bug.
mikehh let0: you partying and stuff? 06:22
let0 mikehh: indeed 06:23
mikehh: i am not sure who to blame for that test failure
mikehh let0: me neither - I have been trying to track it down for a few days - but I find that it does not record the backtrace in parrot_test_run.tar.gz (which I save) 06:25
let0 mikehh: i will try to reproduce
mikehh let0: I don't think it happens on i386 (not sure) 06:26
let0 mikehh: i can test it on powerpc
NotFound mikehh: the segfault is in a TODOed test, then parrot_debugger.t PASS anyway 06:27
06:27 iblechbot joined
chromatic pong 06:29
cotto, that's tricky. I'll have to think about it some. 06:30
cotto My first instinct is in the iglobals array and my second instinct is "don't do that". 06:32
It'd be pretty easy if the option processing code didn't remove the stuff it processed from argv. 06:33
chromatic That code has been a minor thorn in my side for ages. 06:34
I moved it partially out of IMCC years ago.
... but it's still tied too closely to IMCC for my comfort, especially in a world where pirc may merge. 06:35
06:37 theory joined
cotto test coverage? 06:40
purl it has been said that test coverage is cv.perl6.cz
mikehh NotFound - it is not either of the TODO tests 06:52
NotFound - if I skip the TODO tests it still backtraces 06:54
I think it is test 40 or 41 - it prints ok 40 - print string registers - backtrace then ok 41 - print string registers when none exist at the end of the backtrace 06:59
07:06 mokurai left
mikehh NotFound: if I skip Test 41 it does not backtrace 07:16
chromatic That's worse than backwash. 07:18
mikehh don't know - I could do with a backwash :-}
depends how you interpret that of course :-} 07:20
07:20 donaldh joined
mikehh bbl 07:32
08:29 dukeleto joined
mikehh rakudo (b51d94c) builds on parrot r40969 - make test / make spectest (up to r28187) PASS - Ubuntu 9.04 amd64 (gcc) 08:34
08:37 preflex joined 08:51 bacek joined
bacek o hai 08:52
09:05 HG` joined 09:12 gaz joined
cotto good night 09:14
mikehh cardinal - builds on parrot r40969 - rake test:all - same 3 failures - Ubuntu 9.04 amd64 (gcc) 09:16
partcl r688 builds on parrot r40969 - make test PASS - Ubuntu 9.04 amd64 (gcc) 09:17
decnum-dynpmcs r181 builds on parrot r40969 - make test PASS - Ubuntu 9.04 amd64 (gcc) 09:20
09:21 cognominal joined 09:22 einstein joined
bacek jrtayloriv: ping 09:41
dalek lscript: f381ee3 | fperrad++ | (3 files):
install dynops & dynpmc in languages/wmlscript/dynext
 09:59
lscript: f72e19c | fperrad++ | t/ (3 files):
run parrot in current directory
lscript: 7800a1f | fperrad++ | t/pmc/ (10 files):
rewrite in PIR
l: e57bace | fperrad++ | t/Parrot/Test/Xml.pm:
run parrot in current directory
 10:04
bacek ooookey... gms GC is badly broken. 10:19
msg whiteknight Is it reasonable to try to resurrect gms or better to start from scratch? 10:20
purl Message for whiteknight stored.
11:20 donaldh joined 11:31 masak joined
Coke wasn't there a ticket about removing all non-default GCs? 11:37
(I think the just the option to use them might have been removed, but not the GCs themselves. If that's the case, we can remove the GC itself.) 11:38
einstein the other gc system are not updated for a long while and are really broken, but the code still exist there, so someone can use that code if they like to repair them 11:55
but i think a system should be added so you can choise which gc is used at startup time of the interpreter 11:56
before someone is gonna try to repair to other gc systems
dalek lscript: 5ebdd54 | fperrad++ | t/pmc/ (10 files):
fix shebang
12:18 whiteknight joined
jrtayloriv bacek_at_work, pong, I have been looking at GMS too -- It is pretty much useless ... refers to many things that are no longer there, and wasn't fully implemented in the first place. 12:18
whiteknight yeah, GMS is a mess
some good ideas, but probably better to start from scratch at this point
smolder? 12:19
purl i think smolder is sourceforge.net/projects/smolder or web-based smoke test aggregator used by developers and testers to upload (automated or manually) and view smoke/regression tests using the Test Anything Protocol (TAP). or smolder.plusthree.com/app/public_pr..._reports/8
12:19 rindolf joined
rindolf Hi all. 12:20
whiteknight hello
rindolf I'd like to implement www.shlomifish.org/open-source/projects/Spark/ on top of Parrot, and would like to start with one of Parrot's lisp impls.
Is it OK?
whiteknight that sounds like a great project
jrtayloriv whiteknight, I was actually just getting started in an attempt to write one from scratch, now that I've read a bit more about GC. I also have been changing a few things around so that I can get rid of the #ifdefs and choose a GC at parrot invocation ... for instance, I've gotten it so that gc_initialize doesn't use macros anymore ... 12:21
whiteknight jrtayloriv: that's awesome! I would love to see a patch!
rindolf: definitely OK
rindolf: in fact, it would be great 12:22
rindolf whiteknight: OK.
jrtayloriv whiteknight, yes -- I wouldn't mind having you take a look at it to let me know if I'm on the right track. Let me clean up a few things, and I'll post up a sample later today.
whiteknight we don't have any List implementations that are active and up-to-date
rindolf whiteknight: I hope people are not possessive about me spinning-off one of their Lisp implementations.
whiteknight rindolf: not at all
rindolf Because Spark is not just another Scheme or CL implementation.
whiteknight what's so different about it?
rindolf whiteknight: OK, thanks.
whiteknight is not familiar with Spark 12:23
rindolf whiteknight: it's very new.
whiteknight: I'm going to borrow many good ideas from Arc, Perl, Ruby, Python, Moose, etc.
whiteknight: and it will be much more brief than Scheme or CL. 12:24
And with better human engineering.
See : bitbucket.org/shlomif/spark/src/tip...n-Lisp.txt 12:25
whiteknight Ah, so better in every way? That's awesome!
particle whiteknight: how goes the context_pmc3 branch merge cleanup? 12:26
rindolf whiteknight: better in every way to what?
whiteknight particle: I've just been reviewing the smolder reports. Looks like things are pretty stable except on AIX
(although I don't know if AIX was passing 100% before, so I don't know)
rindolf: Just making a joke. Sounds like an awesome project 12:27
particle well, you can check smolder for that info
whiteknight rindolf: Are there other implementations, or is this going to be the first one?
rindolf whiteknight: yeah.
whiteknight: it's the first one.
whiteknight: I came up with the Spark name.
whiteknight: it doesn't even have a spec yet.
whiteknight well very cool. You can't pick a better place to start then with Parrot.
rindolf whiteknight: thanks.
whiteknight particle: how do I check the history of reports for one platform? 12:29
particle checking...
smolder.plusthree.com/app/public_graphs/start/8 12:30
rats, you can't click through to the reports there 12:31
ok: smolder.plusthree.com/app/public_pr..._reports/8 12:32
you can use the 'aix' tag
whiteknight okay, looks like AIX has been stable in it's fail rate
particle yes
whiteknight so, we good to merge the kill_parrot_cont branch soon then?
particle yes, looks like it.
announce the successful merge of context_pmc3 first, and move forward 12:33
whiteknight any rakudo hackers in the house today?
Coke whiteknight: AIX has pretty much always failed. 12:34
... and then I catch up to the last 10 lines. whoops.
whiteknight yeah, it looks like they are failing a very specific grouping of tests too, so that helps to narrow down where the problems are (and where the problems aren't)
though I don't have an AIX machine to do any debugging on 12:37
Coke good luck finding out who that is. =-) 12:38
we have a lot of stealth smokers, I think. =-)
whiteknight Coke: How is partcl doing right now? Is it experiencing any context_pmc3-related failures? 12:39
Coke whiteknight: code.google.com/p/partcl/source/bro...ogress.csv -- pretty sure r40959 is post-merge. 12:40
whiteknight you need a fancy graph
Coke NotFound++ #again.
(kind of a non-sequitor, I know.) 12:41
non-sequitur, before austin corrects me again. =-)
moritz you could steal from rakudo's tools/progress-graph.pl
Coke moritz: That's why i started making the CSV, I hoped someone else would do that bit. =-)
moritz ;-)
whiteknight moritz: how is Rakudo doing? 12:42
(is it experiencing any problems after context_pmc3?)
moritz whiteknight: well; I pushed bacek++'s patch, no new test failures
whiteknight excellent news! 12:43
Coke whiteknight: my biggest concern is the "time to run", which has gone from 6381s to 8340s. 12:44
(not all of that is the context branch, but some of it definitely is.)
moritz rakudo is also a bit slower
purl okay, moritz.
whiteknight Coke: Last night I re-enabled the fixed-size allocator. That should do a lot to help with performance. Could you run another test sometime to see? 12:45
I haven't done any benchmarks of course, but it *should* help
And there are other optimizations we need to make too. Many of the changes recently were just first steps in these comprehensive refactors 12:46
particle whiteknight: one comment on your otherwise excellent email... we're globally distributed, and not everyone knows your time zone. try to use 'eight hours from now' instead of 'later this evening' or something like that 12:50
whiteknight irclogs?
purl well, irclogs is irclog.perlgeek.de/parrot/today or see also: infrared clogs
whiteknight particle: I specifically leave things vague like that because I'm too lazy to do it when I say I will
it's always evening somewhere :)
and it's better then saying "I'll do it whenever I get around to it, which might be never because I'm a mook" 12:51
particle :P 12:52
good thing we don't make any performance guarantees in our policies
parrot is 10% slower? none of the tests fail... so no problem!
whiteknight We really do need to start focusing on performance, but some of the systems are so messy that we haven't been able to do any meaningful improvements to them in-place 12:53
so it's the class situation of "it will get worse before it gets better"
particle it's always darkest after you go blind. 12:54
12:54 ruoso joined
dalek rtcl: r689 | coke++ | wiki/SpecTestStatus.wiki:
Our [file delete] broke something
 12:57
Coke particle: I'll be happier when we start catching all the segfaults in parrot instead of the HLLs. :P
rtcl: r690 | coke++ | trunk/docs/spectest- (2 files):
Pass 2 files that originally failed to complete (See Issue #102).

Net gain of 137 passing tests.
Coke whiteknight: checking with latest parrot...
13:05 sri_ joined 13:06 Eevee joined
rindolf rgrjr.dyndns.org/svn/kea-cl/trunk/README.text - crud! Same terms as Perl 5. GPLv1+ or Artistic-1 only. 13:07
trac.parrot.org/languages/browser/lisp/trunk - this is better - Artistic 2. 13:08
whiteknight rindolf: yeah, our kea-cl implementation is very old 13:09
older then some of these licensing discussions
rindolf whiteknight: ah. 13:10
13:11 quek joined
Coke whiteknight: I have kicked off a test run. See you in 3 hours. 13:12
whiteknight I'll be here :) 13:13
I have plans to set up a test machine of my own for that kind of stuff, but I don't have a suitable machine
Coke I wonder if it would be worth making 'make spectest' respect TEST_JOBS. 13:15
probably not, since each invocation of parrot chews 100% of the CPU and usually takes minutes.
whiteknight if you have more then one core, definitely
Coke I'm on feather, it's a VM, and I'm sharing it.
whiteknight oh, then no 13:16
Coke After this, I should do another run with fastcore and see if that helps. 13:18
(tell me again why we don't default to the fastest core?)
whiteknight I have no idea, but for releases I think we definitely should
moritz: ping 13:21
moritz whiteknight: pong
whiteknight moritz: could you run a Rakudo spectest today to see if it is any faster?
moritz whiteknight: yes 13:22
Coke whiteknight: (for releases) the problem with that being the default is what's tested mostly in between releases.
so if we change it for the release, we're screwing our QA.
moritz I didn't time it before, so that's what I'm doing right now
then I'll update parrot
and try again
whiteknight I enabled the fixed-size allocator in r40962, so before and after that should show some improvements 13:23
particle we shouldn't default to a core we don't regularly run tests on 13:27
particle catches up with scrollback, coke++
whiteknight I would recommend then that we switch fastcore to be the global default 13:28
slowcore is only useful in debugging
particle yeah, who does that? 13:29
how much faster is the fast core over the slow core before context_pmc3 merge?
whiteknight we only need to debug when something is demonstrably wrong. And the fastcore will alert us that something is wrong
I have no idea, I haven't seen recent numbers
particle agreed. i'm considering a recommendation to move to fast core after we finish the branch merges, before 1.6 release 13:30
as long as we have enough time to get smokes
it would be nice not to regress performance-wise
whiteknight We do need to develop some higher-performance cores, like a good context-threaded core 13:31
With a pluggable system, we are likely to get that faster 13:32
moritz what's the context-threaded core? any documentation/ideas/whatever about it?
whiteknight mortiz: doesnt exist yet. 13:33
It's like a mini-JIT that can provide a real performance boost
jrtayloriv jikes ... GC_WRITE_BARRIER is going to be fun to untangle from everything ... 13:36
whiteknight jrtayloriv: Yeah, and we've been saving it just for you!
rindolf If anyone is interested I registered #spark on Freenode.
whiteknight rindolf: you blog about it 13:45
?
rindolf whiteknight: the #spark channel?
whiteknight: I mentioned Spark in my homepage's blog.
whiteknight no, spark in general
ok 13:46
rindolf But didn't really publicise it.
whiteknight: I think I'd rather do it when I have a little to show for.
CatB , etc.
whiteknight Understood. 13:47
purl Understood. are you on schedule?
whiteknight If you do start blogging about it, Parrot has an aggregator that we could include you in 13:48
13:48 snarkyboojum joined
rindolf whiteknight: yes. 13:59
whiteknight: I'm getting: 14:00
<<< Can't open perl script "/usr/lib/parrot/1.5.0/tools/dev/gen_makefile.pl": No such file or directory >>>
On Mandriva Linux Cooker.
With the parrot .rpm's.
Coke ISTR gen_makefile.pl is out of date. 14:01
moritz it's worth usiing parrot HEAD if you develop a language on top of it
whiteknight you need parrot-dev, not parrot
the regular parrot distribution doesn't include all the development tools
Coke (tcl, for example, has its own makefiles, and doesn't let parrot gen them.) 14:02
rindolf whiteknight: I have everything. 14:03
moritz: OK.
BTW, I like the Parrot homepage.
IT's attractive, and usable.
NotFound coverity? 14:06
purl hmmm... coverity is a commercial tool for Automated Error Prevention and Source Code analysis, See, www.coverity.com/main.html or it has been used to measure the quality of the LAMP stack and other major source projects
NotFound cover?
purl cover is not at link?
Coke rindolf: danke. it is a standard drupal site, I think, with some minor style tweaks (probably from allison) 14:11
rindolf Coke: ah, Ok.
Coke: the colours may be a bit too glowing. 14:12
moritz needs more CPU cores for rakudo testing
rindolf But it looks good.
moritz rindolf: if you find the parrot.org colors too glowing, never visit perl6.org :-)
rindolf moritz: get yourself a nice UltraSPARC Niagra machine. 14:13
The Niagara has 64 cores or so.
moritz and you think that parrot and rakudo will build on it? ;-)
8 cores amd64 would be a great improvement already
rindolf moritz: yes.
14:14 Psyche^ joined
rindolf I think parrot and rakudo run on UltraSPARCs. 14:14
rindolf is building parrot trunk now.
dukeleto 'ello 14:25
Coke wonders if anyone can debug why partcl's expr.test is exploding just before it completes. (looks like the PIR comiler starts to choke, but if I run those tests without the intervening several thousand lines of tcl, they complete fine.) 14:29
moritz so not related to the inferior runloop problem? 14:30
whiteknight: rakudo is now a tad slower than right after the context_pmc3 merge 14:31
46m21 then, 48m3 now
Coke not that I'm aware of; pretty sure NotFound++'s workaround on that is still working.
moritz: greaaat. =-)
dalek rrot: r40970 | NotFound++ | trunk/t/pmc/fixedpmcarray.t:
[t] increase coverage of fixedpmcarray
Coke (48+3/60)/(46+21/60)
purl 1.03667745415318
whiteknight moritz: so that's better then 13% slower that pmichaud mentioned yesterday, but still not as good as it was
moritz whiteknight: no, that's *additional* slowness 14:32
whiteknight oh jeez
well that's no good. We're going to have to disable the fixed-size allocator again and see if that was the culprit
Coke Perhaps we should avoid trying to improve speed related issues that aren't blindingly obvious until the profiler is profiling. =-) 14:33
whiteknight seriously thought it would be faster
Coke whiteknight: does it serve any other purpose?
(reduce memory usage, etc?)
moritz Coke++
NotFound whiteknight: maybe you must try to disable the lazy part
whiteknight NotFound: that's a good point too
Coke: No, basically reduces calls to malloc and makes all allocations O(1) 14:34
probably needs tuning in any case
rindolf whiteknight: <<< Can't open perl script "/home/shlomi/apps/parrot/lib/1.5.0-devel/tools/dev/gen_makefile.pl": No such file or directory >>>
whiteknight: seems like it is out-of-date
whiteknight rindolf: Probably very out of date. I don't know how to help with that 14:35
Coke rindolf: what is telling you to use that? 14:38
(are you trying to build someone else's code?)
rindolf Coke: svn.parrot.org/languages/lisp/trunk
Coke: yes, I am.
Coke rindolf: the languages in there were orphans; no one cared enough to put them in their own repository and work on them. 14:39
so we shoved them there so they wouldn't get lost.
it will probably take some effort to update that to work with latest and greatest parrot.
14:39 jrtayloriv joined
whiteknight yeah, all that stuff is very old 14:39
rindolf Coke: OK.
Coke (though fperrad++ has done a lot of work trying to keep them building.) 14:40
dukeleto i know people don't like the whole t/foo.t and t/foo-old.t, but if we are going to greatly expand test coverage for core PMC's, shouldn't we do it in PIR? We are making more work for ourselves every time we write a test in Perl that doesn't require being written in Perl (i.e. tests that don't need to catch errors or do other freaky things that test_more.pir cannot do yet) 14:41
14:41 janus joined
whiteknight who is writing tests in Perl? 14:41
PIR is definitely the new hotness 14:42
dukeleto whiteknight: trac.parrot.org/parrot/changeset/40970/
NotFound Can't we write test in nqp?
particle whiteknight: arguably, that's nqp now
rindolf whiteknight: I see.
particle NotFound: depends what we're testing
whiteknight oh, well if the test file is already in Perl, that's different
rindolf Well, maybe I'll look at a Scheme implementation.
whiteknight Scheme is going to be even worse
particle new tests should not be written in perl 14:43
rindolf There are some Scheme implementations.
NotFound I suppose things like pir_output_is will be easier to implement in nqp than in pir
whiteknight rindolf: and they are all bad
rindolf whiteknight: ah.
whiteknight one is written in flex/bison
particle old tests should be converted... it reduces our reliance on perl, and improves performance
rindolf Wow.
14:44 jrtayloriv joined
dukeleto whiteknight: that is what I am talking about. for example, see t/pmc/integer.t and t/pmc/integer-old.t . We need to start splitting files, so that people don't keep adding perl tests since they don't want to start a new file. we are digging a deeper hole for ourselves if we don't 14:44
whiteknight true 14:45
dukeleto i am working on pir_error_output_like in PIR, that will allow a lot more tests to be converted to PIR
whiteknight oh wow, that would be awesome
what would that be, a try/catch that tests the exception message? 14:46
dukeleto whiteknight: yep, it is mostly written, just making sure there are no kinks 14:47
haven't had time to work on it in the last few days
whiteknight after kill_parrot_cont lands, I want to spend most of the rest of this cycle writing tests 14:49
so that would be awesome
NotFound Any idea about where a context can be freed other than in Context.destroy ? 14:57
whiteknight NotFound: RetContinuations free themselves after invocation 14:58
otherwise, no
So RetContinuation:invoke()
NotFound Parrot_continuation_rewind_environment ? 14:59
whiteknight I have to double-check that function
why, are you getting a problem with double-free contexts?
15:00 theory joined
NotFound whiteknight: the parrot_debugger segfault happens at Context.destroy, I suspect is a double free. 15:00
whiteknight okay 15:01
NotFound I'm thinking the problem must be in parrot_debugger itself, some mixing between debugger and debuggee interpreters 15:08
Coke chromatic had a scheme implementation called pheme that had one of the first test suites to self-host. 15:17
15:17 jan joined
dukeleto NotFound: that test is a little sketchy 15:21
NotFound whiteknight: with #define GC_USE_LAZY_ALLOCATOR 0 parrot test pass, the debugger segfault remains and rakudo builds and pass test. amd64 15:22
whiteknight so is that different from setting it to 1? 15:23
NotFound No, just verifying that it works the same
Changing it requires a realclean, looks like we lack some dependecies in the Makefile 15:25
Maybe just a clean, I just go straight to the real ;) 15:26
partcl also builds and pass test 15:37
15:38 sri joined
dalek tracwiki: v10 | whiteknight++ | JITRewrite 15:44
tracwiki: trac.parrot.org/parrot/wiki/JITRew...ction=diff
rindolf whiteknight: so what should I do? 15:51
whiteknight: start from a different front-end?
A non-Lisp one?
whiteknight ridolf: yes, that's what I would recommend for now. None of the Lisp implementations are workable right ow 15:52
now
start from scratch is probably easiest
15:53 Andy joined
rindolf whiteknight: OK. 15:53
whiteknight: thanks.
whiteknight np 15:54
we should start thinking about GSOC next year 16:02
this year I don't think we had a great list of suggestions for new projects
but we have Partcl and Cardinal that need help, other new compilers to write, seed libraries to wrap, a library distribution system to develop and manage, and a whole list of subsystems in Parrot needing a serious overhaul 16:04
dalek a: 2885dd7 | fperrad++ | t/ (9 files):
run parrot in current directory
 16:13
a: b6ebbc8 | fperrad++ | t/pmc/ (16 files):
rewrite tests in PIR
NotFound whiteknight: in amd64 non optimized build, rakudo make test looks a liittle bit faster with GC_USE_LAZY_ALLOCATOR 1, but the difference is less than system load variations. Anyway, it surely is no significantly slower. 16:17
whiteknight NotFound: GC_USE_LAZY_ALLOCATOR shouldn't be a speed improvement really, GC_USE_LAZY_ALLOCATOR should be 16:18
I mean, GC_USE_FIXED_SIZE_ALLOCATOR 16:19
NotFound whiteknight: yeah, but I was checking anyway just in case
whiteknight okay
So that confirms performance. We can probably make the lazy allocator the default if it works and doesn't hurt performance 16:20
NotFound Actually it is
whiteknight Well, I mean we can take out the flag and not have a non-lazy option
NotFound Ah, ok.
whiteknight chromatic was doing some tuning though, so we can wait for that before making any decisions
NotFound +1 16:21
purl 1
NotFound I'd like an allocator with pink neon lights
16:22 MoC joined
whiteknight that would be fine too 16:22
NotFound That's what meny people understand when you say "tuning" 16:23
whiteknight And I want to put a "Type-R" sticker on it 16:24
to give it more horsepower
NotFound I'd like better "TURBO", it has a retro fashion... 16:25
16:29 cotto joined
duk3leto whiteknight: i am very excited about possibilities for parrot and perl 6 for gsoc next year 16:30
whiteknight: starting to plan now is definitely a good idea. especially, read the end of summer summaries from other orgs that did really well. there is a lot to learn 16:31
NotFound whiteknight: disabling the fixed size allocator is slower, maybe a 1% 16:36
whiteknight okay, so fixed-size *is faster*? 16:37
NotFound Yeah
whiteknight okay, that's all I needed to hear
(although I'm upset that it's such a small increase)
we really need to convert Context PMC to use ATTRs
16:38 kjeldahl joined
particle by next tuesday, please. 16:38
NotFound I don't think rakudo make test is very good benchmark, but give us some idea
cotto good morning
purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
whiteknight particle: so give a week before the release without big changes?
good morning cotto
particle NotFound: spectest is a much better benchmark 16:40
heck, building rakudo is probably a better benchmark than rakudo's test target
many more pmc's to gc
no, not needed for this release, i just want you to work hard this weekend :)
NotFound particle: spectest is too long for quick tests 16:41
particle NotFound: but building rakudo isn't 16:42
16:45 mokurai joined
cotto particle, I want to add an option to parrot that specifies the name of the output file. Where can I store it in the time between when it's parsed by parseflags and when the runcore gets initialized? 16:49
NotFound 2m16 with fixed size allocator vs 2m20 without. in time make
amd64 unoptimized 16:50
whiteknight There are some fixes to the allocator that I think I can make to improve things a little 16:53
but that's going to have to wait till tonight 16:54
NotFound 1m32 with --optimize. That's a difference 16:56
whiteknight that is pretty significant 16:59
is that with or without the allocator?
NotFound With, testing now without
whiteknight crosses his fingers
treed Saw the message on the mailing list asking for tests from HLLs after the context_pmc drop.
whiteknight treed: and? How is Cardinal doing? 17:00
treed It won't even start building.
running parrot_config results in:
Invalid charset number '1768057203' specified
whiteknight ouch, that's as bad as can be
particle cotto: (i'm on the phone)
treed I can force it to not need parrot_config by writing build.yaml myself.
cotto np
treed But probably better to just fix that.
whiteknight treed: I've never even heard of an error likethat 17:02
NotFound 1m64 with --optimize and without the FSA
1m36 with --optimize and without the FSA
whiteknight okay, that makes more sense
still not as good as I hoped
NotFound Strange cross fingers :?
treed src/string/api.c 17:05
767: "Invalid charset number '%d' specified", charset_nr);
whiteknight maybe malloc performs much better then I expected 17:06
treed: and where in the build process do yo get that? 17:07
NotFound treed: that sounds like mixing parrot libs
whiteknight treed: what platform are you on? 17:16
jrtayloriv Can someone help me debug a stupid programming error on my part? Here is (what I think is ) the relevant code, and the error message: pastebin.com/dcb9c3cf ... please tell me if there is any more info you need.
I'm trying to get rid of the GC_WRITE_BARRIER macros, and make functions that actually need to use it register a hook in the gc_sys structure I created. 17:17
It's probably something obvious I'm missing ... my C skills are pretty weak. 17:18
treed whiteknight: That's when I call "parrot_config build_dir".
OS X
or any invocation of parrot_config 17:19
whiteknight jrtayloriv: run "make headerizer" 17:20
NotFound jrtayloriv: you need to make headerizer before using the ASSERT_ARGS macro in a new function
And make headerizer usually doesn't work without executing make first, so you may need to temporarily delete the macro 17:21
(A nice project for beginners: fix this) ;) 17:22
jrtayloriv thanks! ... now I can move on to my next batch of errors! :) 17:23
whiteknight is very very interested to see this next patch...
NotFound whiteknight: num_free_objects is used for something? Looks like is incremented and decremented but never checked 17:29
whiteknight NotFound: might not be, that's true 17:30
I've got a lot of little cleanups I would like to make in there
17:39 quek left 17:40 chromatic joined
whiteknight hullo chromatic 17:42
chromatic morning
whiteknight NotFound has been benchmarking the fixed-size allocator all morning, and there really doesn't appear to be any performacne benefit to it 17:43
and I know you were doing some local work tuning the lazy allocator, but that doesn't currently offer any benefits either
NotFound FSV of "benchmarking"
whiteknight "timing" in either case, it shows that there is no real benefit 17:44
which sort of surprised me, I figured it would be signficantly faster then malloc, especially once we get items coming in to the free list 17:45
Although maybe I'm overestimating how many calls to malloc we're making. 17:46
chromatic I'll take a look. 17:47
whiteknight If that's only a small part of our performance problem, Amdahl's law says huge improvements to it won't affect overall system performance much
treed BBL
whiteknight chromatic: It's not a huge issue. I was hoping we could make up some of our performance losses with the new allocator, but isn't panning out that way 17:50
17:50 payload joined
whiteknight we can look for other low-hanging fruit before the release 17:50
chromatic Last time I tried it, it did show some benefits. 17:51
whiteknight NotFound's numbers today were like 1-2% 17:52
cotto chromatic, what about this:
nopaste "cotto" at 74.61.2.46 pasted "allow access to unprocessed argv list" (63 lines) at nopaste.snit.ch/17811
chromatic cotto, that's probably workable for now... but do we *need* that feature for the testing now? 17:53
cotto The alternative is always writing to stderr or stdout, which means an annoying redirect for any non-testing purposes. 17:54
NotFound cotto: can't you use getenv? 17:55
chromatic PARROT_PROFILE_OUTPUT or something? 17:57
NotFound Yes, something like that.
cotto That'd also work and be less annoying. 17:58
chromatic Less code too. 17:59
cotto I'll just use that. Thanks for not missing a good obvious solution, NotFound++
whiteknight In reality, we probably don't want all our argument handling to happen internally to IMCC
at least not forever, since IMCC could be involved in a terrible code accident one day 18:00
that's a stylistic preference for now, of course 18:01
chromatic I tried to move that code a couple of times. I always had trouble because it processes IMCC options too. 18:02
whiteknight yeah, we would need a non-trivial refactor of the IMCC interface to make that work correctly 18:03
chromatic Or leave that code there and pass in some non-mangled data to IMCC_initialize and let it set its own options.
whiteknight I've actually been considering an interface refactor there for a while. Just haven't had any particular reason to attempt it 18:04
It ain't so broke that it needs fixin' above any other projects 18:05
chromatic It's not a big priority until pirc starts to get mergeable.
18:11 davidfetter joined
Coke whiteknight: re-ran the test. 18:13
whiteknight Coke: Let me guess, no real improvement? 18:14
Coke "2009-09-03 22:20",688,"r40959",97,7752,3570,2131,2051,8811,"--optimize"
"2009-09-04 09:05",690,"r40969",97,7752,3569,2132,2051,8287,"--optimize"
8287/8811
purl 0.940528884349109
Coke looks like those 10 parrot revisions gave me a 5% speedup. 18:15
(and one failed test. not sure what's up with that.)
so, just need to get it back down to 40897 speeds. (and then beyond. =-)
whiteknight really? I'm surprised you saw 5% 18:19
18:21 darbelo joined
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40970 - Ubuntu 9.04 amd64 (g++) 18:25
cardinal - builds on parrot r40970 - rake test:all - same 3 failures - Ubuntu 9.04 amd64 (g++) 18:27
whiteknight well that's surprising. Treed said he can't get cardinal to build at all 18:29
mikehh I noticed that - but it builds ok for at the moment 18:30
NotFound WTF is a HashIteratorKey ?
18:31 Psyche^ joined
mikehh ok for me 18:31
Coke NotFound: was that bacek? someone split up iterators into separate chunks. 18:33
NotFound I can avoid a segfault in partcl by fixing HashIteratorKey but don't know if the fix makes sense.
Well, I'll fix the segfault and let others make sense of it.
Coke trac sloooow 18:34
mikehh rakudo (b51d94c) builds on parrot r40970 - make test / make spectest (up to r28187) PASS - Ubuntu 9.04 amd64 (g++) 18:35
Coke NotFound: that would potentially fix 2 of partcl's segfaults. 18:36
(set-old and dict)
NotFound Let me check parrot test first... 18:37
mikehh I tracked down the 3 failures in cardinal to r40788 - all three fail with - Method 'iterator' not found for invocant of class 'String' - they pass at r40787 and have failed since
dalek rrot: r40971 | cotto++ | branches/pluggable_runcore/src/runcore/cores.c:
[profiling] allow the output file to be specified by the PARROT_PROFILING_OUTPUT environment variable
 18:38
NotFound Coke: set-old is the one I was checking 18:41
dalek rrot: r40972 | NotFound++ | trunk/src/pmc/hashiteratorkey.pmc:
[pmc] fix? HashIteratorKey.get_string
Coke updating, checking... 18:43
chromatic Why would an iterator exist without a hash? 18:50
whiteknight NotFound: looks sane to me
chromatic: that's actually a good question. I would be very interested to see the PIR snippet that was causing this 18:51
(and then make a test to insure it never happens again)
Coke whiteknight: ... there is no snippet.
only several thousand lines of tcl. =-) 18:52
whiteknight Coke: somewhere in that pile of TCL is a PIR fragment that causes this error
likely implicit, but it exists
Coke not necessarily.
whiteknight ...and it wouldn't be because...? 18:53
mikehh partcl r691 builds on parrot r40970 - make test PASS - Ubuntu 9.04 amd64 (g++)
Coke I'm not saying you can't generate that with pir. I'm saying that you can't necessarily take the code I'm running, find the single offending bit, and then use that. there could have to be a GC run, some setup code ...
<initial something> <3000 lines of tcl which does god knows what include trigger a GC run> <sample<> 18:54
and the sample is where the segfault occurs, but if you run it alone, nothing happens.
nothing /bad/
rindolf whiteknight: which dynamic languages do you suggest as the basis for parspark? 18:55
whiteknight: which Parrot front-end do you suggest as the basis for parspark?
Coke that said, I have not tried to reduce that particular segfault down to a PIR sample.
whiteknight rindolf: I'm not sure any existing language implementations are going to be a good prototype for an S-expression language. Your best bet is to start from scratch and look at developed implementations (like Rakudo or Cardinal) as you get stuck 18:56
rindolf whiteknight: ah.
whiteknight: is Cardinal a Ruby impl?
Tene Yes.
whiteknight Coke: knowing where the problem occurs in PIR, even if we can't always reproduce it completely, can be very instructive
rindolf Tene: thanks.
Tene s-exps? 18:57
i have a scheme impl
whiteknight "This code causes problems sometime" is good enough
Tene: what's the status of that?
rindolf Tene: ah, for Parrot?
Tene Yes, for parrot.
rindolf Tene: nice.
Tene i haven't read scrollback, what's up?
whiteknight: It's my standard PCT presentation demo. 18:58
whiteknight Tene: What's it called?
Tene github.com/tene/steme/tree/master
rindolf Tene: fine. Want to start working on www.shlomifish.org/open-source/projects/Spark/
Tene: ah.
whiteknight Tene: rindolf is looking to implement a new lisp-like language on Parrot
rindolf Tene: what licence is it under?
Coke NotFound: dict.test and set-old.test now both complete.
;that's an extra 291 PASSED.
NotFound Nice :)
whiteknight very nice 18:59
Coke that's >8%
Tene rindolf: After at *least* 10 seconds of thinking about it, it's under the "Um... license? Dunno. Whatever you want." license.
rindolf Tene: can it be MIT/X11?
Tene rindolf: It certainly can be for you.
Coke hey, yet another license!
rindolf Tene: thanks! 19:00
rindolf hugs Tene
Tene rindolf: Spark is a new lisp-like language you'd like to write, I guess?
rindolf Tene: yes. 19:01
Tene: it's still in the planning stage.
Tene That's great. I'd love to work with you on it.
Well, if you're planning to build it on Parrot. :)
rindolf Tene: I released the first spec of it (back when it was called Park) after frustration from the fact that PG didn't release Arc.
Then he did, but I realised Arc kinda sucked. 19:02
Tene: yes , I'm planning to use Parrot.
dalek TT #963 closed by coke++: segfault in Parrot_HashIteratorKey_get_string
Tene I don't quite have the tuits to get into a completely different community right now. :)
rindolf Tene: anyway read the web page www.shlomifish.org/open-source/projects/Spark/
cotto use the WTFPL 19:03
Tene rindolf: My email is /me at allalone.org if you want to contact me later.
Tene reads. 19:04
rindolf Tene: ok.
Tene: got IM?
MSN/Jabber/etc.?
Tene jabber: sweeks at gurulabs.com
rindolf Tene: www.shlomifish.org/me/contact-me/
Tene: adding you from ShlomiFish@jabber.org 19:05
Tene great
rindolf Tene: :-)
Tene: I've registered #spark on Freenode. 19:06
Coke ponders providing NotFound with beer credit. 19:07
dalek rtcl: r691 | coke++ | trunk/ (3 files):
rerun spec test, mainly to test speed for whiteknight++

Lost one test in upvar ?!		 19:08
rtcl: r692 | coke++ | wiki/SpecTestStatus.wiki:
NotFound++ - these tests no longer segfault.
rtcl: r693 | coke++ | trunk/config/PARROT_VERSION:
This version avoids a segfault that gets us 291 more passing tests.
19:08 MoC joined
whiteknight NotFound has been quite the rockstar this month 19:10
NotFound gets a copy of Guitar Hero
whiteknight NotFound *is* a guitar hero 19:11
dalek rtcl: r694 | coke++ | wiki/SpecTestStatus.wiki:
add a table of contents
 19:12
chromatic Is the switched core faster than the fast core? 19:20
whiteknight chromatic: from what I have seen, fast core is the fastest
makes some sense since it will be the friendliest to most branch predictors
switch core technically has fewer instructions per dispatch, but uses an indirect jump which is horrible on the predictors. 19:21
we're talking 100% miss rate
cotto is there a portable way to do prefetching? 19:22
whiteknight cotto: what do you mean by that?
nopaste "chromatic" at 72.87.39.97 pasted "GC Tuning Patch for Testing" (25 lines) at nopaste.snit.ch/17812 19:24
Coke is fast core always built?
cotto get the relevant memory into cache before it's needed so we don't get a cache miss
whiteknight chromatic: can we make the values in that patch constant numbers, so we get the same numbers of PMCs allocated on x64 too? 19:25
chromatic Sure, I just wanted the most minimal patch here.
whiteknight okay
In fact, if we could make the total arena allocation a multiple of the system page size, that would be the best 19:27
chromatic Definitely. 19:28
Coke for partcl's "while.test" : 19:29
-R fast : real 0m52.950s
<default> : real 0m55.665s
52.950/55.665
purl 0.951226084613312
Coke so, not super fast. (but every bit helps.)
moritz chromatic: timing 'make spectest' with your patch now 19:30
dalek rrot: r40973 | cotto++ | branches/pluggable_runcore/tools/dev/pprof2cg.pl:
[pprof2cg] return the callgrind profile as a string and let main decide what to do with it
chromatic 6.5% improvement on the primes.pasm benchmark with my patch.
whiteknight Coke: Because our ops are so large and complicated, there is a relatively small boost to be had by improving dispatch
that is, most time is spent in the ops, not moving between them 19:31
Coke chromatic: on speed?
chromatic yes
whiteknight If our op set was more atomic, like Lorito is intended to be, we would see more significant differences in dispatch mechanisms
Coke (jit for while.test: real 1m19.580s
chromatic 10.235% improvement between default core and fast core on primes.pasm benchmark. 19:32
whiteknight And JIT has more up-front cost. You need longer tests to amortize the costs
Coke whiteknight: a test that runs for about sixty seconds isn't long enough? 19:33
(obviously not, but should we reasonably expect that to be the case?)
whiteknight Not saying it's not, just trying to provide some annotations :)
I assume that our JIT is producing heinously un-optimized machine code 19:34
chromatic 26.51% improvement between default core and switch core on primes.pasm 19:35
whiteknight really? that is definitely not a result I have ever seen before
chromatic I'm not claiming it's a representative test, just that it's interesting.
whiteknight Once the pluggable runcore branch lands, I really want to take a stab at a context-threaded core 19:36
chromatic That's probably as good as we can get for now.
whiteknight it really shouldn't be too hard to do, I hope, and should give us really good performance gains
well, not "really good", but nice 19:37
after that it's all blue skies and trace-based JIT 19:38
szbalint and ponies 19:41
Tene Hmm. I still get that weird segfault when loading rakudo from steme. 19:48
it goes away when I run Parrot with -G
whiteknight solution: don't do that
Tene: can you reproduce that segfault consistently?
Tene whiteknight: gist.github.com/181081 19:50
whiteknight: you can get steme at github.com/tene/steme/
whiteknight and that small amount of code triggers a segfault consistently?
Tene Yes. 19:51
whiteknight well then
Tene Every time I've run it for the past four or five months, iirc.
whiteknight can you put this information into a ticket?
Tene I think I already have... maybe.
magic-ticket-bot: Where is that ticket I posted once about something? 19:52
whiteknight Oh, I'll have to dig for it
Tene Oh, magic-ticket-bot doesn't exist yet.
trac.parrot.org/parrot/ticket/744
you can ignore the start, these days
just 'make install' with rakudo
You even commented on it! :) 19:53
whiteknight go me 19:54
dalek rrot: r40974 | NotFound++ | trunk/src/string/charset/unicode.c:
[string] Dubious fix for an out-of-bounds string access, avoids TT #967 segfaults
 19:55
whiteknight Tene: When does it segfault? Does it print the "zzz" or not?
Tene It prints nothing.
It segfaults when it tries to load_language perl6.pbc 19:56
moritz chromatic: with your GC patch Rakudo is a wee bit faster
whiteknight oh, okay
moritz (46 * 60 + 30) / (48 * 60 + 3)
purl 0.967741935483871
NotFound Coke: more music for your ears 19:57
whiteknight We lost 13% on the contexts switchover, we're not going to make up all that ground by patching the GC
We do need to get into the Context pmc and fix that up eventually 19:58
chromatic Hopefully we leak less memory with the Context switchover.
That'll help too.
19:58 bacek joined, iblechbot joined
darbelo whiteknight: In time for the next release? 19:58
whiteknight darbelo: who knows? 19:59
purl and it's way past purl's bed time young man!
Tene whiteknight: Oh... apparently it now segfaults with Cardinal, too. 20:00
it used to work with Cardinal.
whiteknight well, that's good for consistency 20:02
Tene Heh.
20:08 donaldh joined
Tene I wonder if hll interop between cardinal and rakudo still works... 20:10
whiteknight What we need to do is write compilers for at least two toy languages in the Parrot repo, and then write a whole suite of tests to make sure they can interact together 20:17
jrtayloriv whiteknight, If you have time later would you mind helping me figure out what is wrong with my gc refactor patch? It's really sloppy/unfinished right now (I'll make sure to clean it up before posting it to trac) but it at least completes the build of parrot at this point. Currently, it is failing at the "./parrot -o runtime/parrot/include/parrotlib.pbc runtime/parrot/library/parrotlib.pir" step with "Unknown PMC type to thaw 0" 20:19
. Mind trying it out to see if you can find the error, and say what you do/don't like about it? If it doesn't work out, at the very least, there might be some good ideas that could be used to help clean up the GC system.
whiteknight jrtayloriv: sure thing. I would love to see the patch
Although I don't know when I will have time to look at it 20:20
moritz whiteknight: good idea
purl moritz: Good Idea: Playing the scales on a piano. Bad Idea: Playing the scales on a fish.
20:20 joeri joined
whiteknight moritz: I'm wondering if we can get two bare-bones toy languages that we can use for meaningful tests 20:20
because any compilers we write, we will want to use for all sorts of PCT and HLLCompiler tests too 20:21
jrtayloriv whiteknight, msg me later when you can take a look -- thanks
whiteknight GEnerated code tests, .HLL tests, etc
jrtayloriv: you could email me the patch
I'll be home in about 1hr and can see it then too
jrtayloriv whiteknight, ok, will do. 20:22
whiteknight Okay, on that note I'm signing off. Later
dalek kudo: 3db3e37 | moritz++ | build/gen_setting_pm.pl:
[build] be a bit more idiomatic in gen_setting_pm.pl
 20:24
chromatic Parrot_pcc_get_context_struct() is expensive. 20:34
How about a little naughtiness? 20:35
Let's see if violating encapsulation improves things. 20:36
11.35% performance improvement. 20:38
Heh. 20:40
darbelo Didn't bacek just go through all sort of trouble to encapsulate that? 20:41
chromatic It's not so bad in this case.
The *real* problem here is that *every* REG_* and CTX_REG_* macro refetches the current context. 20:42
That's a problem in some ops which refer to multiple registers.
darbelo *ouch*
chromatic GCC can't optimize that because 1) it can't do cross-module optimizations 2) it doesn't know that these functions are pure, at least for the duration of the op and 3) there's a vtable dispatch it can't optimize through 20:43
bacek Good morning
purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
NotFound A way to always have the current context in scope in the ops may be a good solution.
chromatic Exactly what I had in mind.
First though, let's speed things up for people right now. 20:44
moritz is there a portable way to write implicit Makefile rules? 20:45
NotFound moritz: yes, using gmake in every platform X-)
moritz basically I want to write a rule that for each src/foo.pm calls a script to build build/foo.pm
and I have a list of all relevant files that match src/*.pm 20:46
bacek chromatic: just "revert" r40871
NotFound moritz: maybe will be easy to do that in the Makefile generation 20:47
chromatic I don't think they're the problem necessarily.
dalek rrot: r40975 | chromatic++ | trunk/src/call/context.c:
[PCC] Made Parrot_pcc_get_context_struct() poke into the Context PMC's data

big performance improvement (11.35% in primes.pasm), but it's also not as dangerous as it sounds for two reasons:
   * nothing extends the Context PMC, so it's safe for the time being
   * anything that did extend the Context PMC would need a similar struct here
   anyway
This can be a temporary optimization until we stop extra context fetching in ops bodies.		 20:48
chromatic Let's get some performance numbers on that and see what happens.
bacek to have "final sealed" pragmas for PMCs... 20:51
dalek rrot: r40976 | bacek++ | trunk (4 files):
[cage] Remove CHUNCKED_CTX_MEMORY and Parrot_gc_context. Contexts are
 20:56
rrot: r40977 | bacek++ | branches/context_attrs:
Branch to remove Parrot_Context structure and use ATTRibutes
chromatic Parrot_inc_p (opcode_t *cur_opcode, Parrot_Interp interp) { 20:57
((*Parrot_pcc_get_PMC_reg((interp), (interp)->ctx, (cur_opcode[1]))))->vtable->increment(interp, (*Parrot_pcc_get_PMC_reg((interp), (interp)->ctx, (cur_opcode[1]))));
Definitely room for better macros there. 20:58
21:03 ruoso joined
bacek chromatic: it's autogenerated code. 21:07
21:14 PacoLinux joined
chromatic Yep, easy to fix. 21:17
dalek rrot: r40978 | bacek++ | branches/context_attrs/src/pmc/context.pmc:
Copy Parrot_Context content as attributes into Context PMC
chromatic The switch core could be even faster here by using a stack variable above the switch and only fetching a new context *when the context has changed*.
21:20 Whiteknight joined
chromatic waits for the backlog and the forehead slap 21:23
jrtayloriv Whiteknight, just sent the email a moment ago 21:24
Whiteknight w00t 21:25
jrtayloriv :)
Coke chromatic: seeing about a 4% speedup on t_tcl/while.test with recent parrot on default core, maybe 2% on fast core.
jrtayloriv Whiteknight, really, really, unfinished right now ... just warning you :)
NotFound Coke: have you looked at r40974 ? 21:27
Whiteknight jrtayloriv: I've seen worse 21:28
hell, I've written worse
:)
chromatic True.
Whiteknight !!!
Coke NotFound: saw it go by, haven't had time to recheck anything yet. will do so tonight or this weekend.
chromatic As long as you're dogging on yourself, why not? When will I get that chance again?
Coke chromatic++ #OH SNAP
jrtayloriv Whiteknight, :) -- Please tell me everything I did wrong -- will make sure I don't do the same again -- thanks for taking a look at it.
Coke problem #1: asking Whiteknight for coding advice. 21:29
(OH SNAP)
NotFound Coke: I'm running partcl spectest for a while and don't have any segfault yet
Coke NotFound: I don't run the segfaults in the spectest run. =-)
Whiteknight jrtayloriv: We should add an API function to src/gc/api.c that does WRITE_BARRIER stuff
NotFound Oh, forgot that :D
Coke you can run them directly with ./tclsh t_tcl/failing.test
Whiteknight so that we we can keep all the pointers private to the GC system
Coke also: 21:30
code.google.com/p/partcl/wiki/SpecT...s#segfault
GeJ_ Good morning everyone
Whiteknight jrtayloriv: so like create a Parrot_gc_write_barrier and Parrot_gc_write_barrier_key function
Coke two of those were covered by binary.test and parseExpr.test 21:31
er,
that TT covered those 2.
jrtayloriv Whiteknight, OK -- and would you then have that call the system specific write-barrier functions from a switch? 21:32
Coke that would leave 5 segfaults.
gotta run.
NotFound++
jrtayloriv Whiteknight, i.e. the ones in the GC_Subsystem struct?
Whiteknight jrtaylor: inside the API functions we can call interp->gc_system->write_barrier() like you are doing now
we just don't want to give outside code access to GC data structures
jrtayloriv oh, I see. 21:33
NotFound Coke: I don't have such file
Tene Whiteknight: While I do agree that the hll interop stuff needs to be tested, it hasn't been actual hll interop stuff that's broken yet.
Whiteknight Tene: so what is broken?
Tene Whiteknight: it's always been GC, or other weird segfaults.
jrtayloriv Whiteknight, Does the GC_Subsystem struct concept make sense though, as far as a place for each system to define it's own functions/data structures? 21:34
Tene For example, if I fudge the generated PIR so that rakudo.pbc is loaded before steme.pbc, everything works fine. Or if I call into steme code that calls into rakudo code, it works.
Whiteknight jrtayloriv: yes, it makes very much sense
pmichaud the hll interop isn't the source of the breakages, it just exposes them
PGE has had that problem for years
Whiteknight jrtayloriv: A lot of this patch looks like fixups to the GMS core. I suggest separating that out into it's own patch
pmichaud: do you have any more insight about what, specifically, is causing this problem? 21:35
pmichaud no
Whiteknight Okay
nopaste "tene" at 97.117.70.208 pasted "backtrace for WhiteKnight++" (64 lines) at nopaste.snit.ch/17813 21:36
Tene that obj=0x1 looks very weird 21:37
Whiteknight Oh, I have seen that before, haven't I?
that stupid 0x01 bug
jrtayloriv Whiteknight, Yes -- but also, a lot of the GMS stuff was spread around all over the place, in places it didn't need to be, so a lot of getting it cleaned up involved messing with GMS stuff. But there were also a lot of changes that I made while I was toying with the idea of getting GMS to work (before I realized that it's so broken it should just be rewritten), and I can easily seperate those changes from the others. 21:38
Whiteknight jrtayloriv: I would love to see GMS salvaged, but the smaller the patch is, the less pain it will be to apply it 21:39
Tene: you in gdb right now?
Tene No, but it's like 2s to get back there. 21:40
ok, I am now
NotFound I think that the root of the pbc problem comes from using the HLL of the current context, an attempt of solution might be creating a temporary 'parrot' context during the load.
bacek Whiteknight: prove I'm wrong - we can't allocate arbitrary-size objects in current GC.
Whiteknight Tene: run back to the segfault, and print out the frame #2
Tene How do I do that? 21:41
Tene gdb fail. >.>
Whiteknight actualy frame 1
Tene: "up", then "frame"
Tene it just prints the same line that's in the backtrace
#1 0x00007ffff7cbc54f in Parrot_Context_mark (interp=0x608080, pmc=0x9524d0) from /home/sweeks/parrot/lib/libparrot.so.1.5.0 21:42
Whiteknight well that's shitty
Tene what should it do?
Whiteknight it should print out the line of code that's being executed there 21:43
I want to try to figure out which field in the Context struct has the bad value
pmichaud just print the context struct, see what has 0x1 ?
bacek Tene: l
Whiteknight pmichaud: good idea!
purl Whiteknight: Good Idea: Singing Christmas carols to your neighbors. Bad Idea: Singing Christmas carols to your neighbors on the Fourth of July.
bacek it's probably value of PMC register...
Whiteknight Tene: "p * (Parrot_Context*)pmc->data" 21:44
Tene $1 = {caller_ctx = 0x952530, bp = {regs_n = 0xa69de0, regs_i = 0xa69de0}, bp_ps = {regs_p = 0xa69e30, regs_s = 0xa69e30}, n_regs_used = {0, 0, 2, 10}, lex_pad = 0x6a9d30, outer_ctx = 0x0, current_sub = 0x731cb0, handlers = 0x6a9d30, current_cont = 0x952500, current_object = 0x0, current_namespace = 0x6dea00, 21:45
results_signature = 0x, current_pc = 0x7ffff74fd6f8, current_results = 0x7ffff74fd6e8, c onstants = 0x70eed0, current_HLL = 1, warns = 0, errors = 5, trace_flags = 0, recursion_depth = 6, pred_offset = 17592167803956}
bacek it is...
purl Oh no it isn't!
Whiteknight current_HLL? 21:46
bacek current_HLL is INTVAL
Whiteknight so it has to be one of the P or S registers then
so here's the millon dollar question: Who the hell is writing 0x1 to one of the P or S registers? 21:47
and could whoever is doing it kindly knock it the hell off
darbelo blames gremlins. 21:48
gremlin Who cares to blame ME???
Whiteknight feeds bacek after midnight
dalek rrot: r40979 | pmichaud++ | trunk/t/compilers/pge/perl6regex/rx_quantifiers:
[pge]: typo in test description noticed by masak++
 21:49
Whiteknight Tene: "p i"
bacek No way. It's old bug.
Tene i = 8
Whiteknight: it's not current_hll
Whiteknight okay, so it's the eigth PMC register, because there are only 2 S regs and 10 P regs
Tene: thanks, we're past that now :) 21:50
Tene reading fail again. :)
bacek <bacek> it's probably value of PMC register...
pmichaud ninth PMC register :)
21:50 MoC joined
pmichaud can we see the contests of regs_p ? 21:51
*contents
Tene afk phone 21:52
Whiteknight 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
jrtayloriv Whiteknight, so other than moving the GMS data structures into the generational_ms.h header, just leave out most of the changes to the functions in generational_ms.c?
nopaste "Whiteknight" at 69.249.176.251 pasted "Patch for Tene++" (15 lines) at nopaste.snit.ch/17814 21:53
Whiteknight jrtayloriv: yeah, those are my first suggestions.
rindolf pmichaud: I've had lunch with someone from Tel-FOSS and he said he's using PmWiki.
Whiteknight otherwise, it's a great looking patch
jrtayloriv Whiteknight, thanks for your feedback -- I'll work on that and email you it once I've cleaned things up a bit. 21:54
pmichaud rindolf: excellent! I'm frequently surprised (and flattered) that PmWiki gets used as much as it does.
rindolf pmichaud: yes.
chromatic suspects that the Context isn't really a context.
rindolf pmichaud: I kinda like MediaWiki, but its syntax is very hard to parse.
Tene Whiteknight: rebuilding...
rindolf pmichaud: and its test suite has been broken for a while.
Whiteknight chromatic: so like it's an unintialized value that's being treated as a Context?
that's a little harder now if they're PMCs 21:55
rindolf pmichaud: but maybe because I'm the most used to MW.
MojoMojo also looks nice.
Whiteknight because we can't even get into mark unless the PMC has a valid VTABLE
pmichaud yes, I tried to be very careful with PmWiki's markup syntax. I find a lot of MW to be hard to parse. OTOH, a lot of people say the same for PmWiki's syntax, so who knows? ;-)
Tene Whiteknight: it runs without a problem now.
whatever that means.
Whiteknight It means that we can hide the problem a lot easier then we can fix it 21:56
bacek Whiteknight: bah! Cheater!
chromatic Or it used to be a context.
Whiteknight chromatic: that's true too. I think it's more likely that some rogue op is putting garbage into a register slot 21:57
but time will tell
rindolf pmichaud: I see. 21:58
Whiteknight I think it's a valid context, because it would have to be valid to get to this point
a lot of other pointers from that context have been marked by the time we get here 21:59
nopaste "bacek" at 114.73.43.150 pasted "Epic PCC failure expose patch." (44 lines) at nopaste.snit.ch/17815 22:00
bacek t/op/calling................................46/94
# Failed test 'clone_key_arg'
# at t/op/calling.t line 1409.
# Exited with error code: [SIGNAL 6]
# Received:
# src/gc/alloc_register.c:534: failed assertion 'Parrot_pcc_get_regs_used(interp, ctx, REGNO_STR) > idx'
# Backtrace - Obtained 25 stack frames (max trace depth is 32).
This is root of problem
Whiteknight bacek: that's this failure we're talkig about? 22:01
bacek Whiteknight: yes
Whiteknight so the register allocator is allocating too few registers?
bacek pcc accessing wrong register
darbelo Say, is anyone on i386 available to test a small patch?
Whiteknight no and no
bacek or allocating less, than required register.
registers 22:02
purl well, registers is better www.theregister.co.uk/2005/10/18/wi...y_problem/
Whiteknight I actually have to disappear. My wife wants me to all "do stuff" and "get off my ass" and "help out around the house for a while"
whatever that means
Tene laaaaaaame
Whiteknight that's what I said!
NotFound Object must not override assign_pmc ?
Whiteknight and I made a face 22:03
Tene *my* gf wants me to come home from work and take her to the park to socialize.
chromatic My cat's breath smells like cat food.
Whiteknight our lady friends should get together and take each other out to the park, while we stay on the computer
okay, later 22:04
pmichaud My wife is falling asleep, which means I get to take daughter to fencing lesson
nopaste "darbelo" at 200.49.154.172 pasted "[PATCH] Kill ->strstart uses in src/jit/i386/jit_defs.c" (56 lines) at nopaste.snit.ch/17816 22:05
darbelo Can anyone on i386 can test nopaste.snit.ch/17816 check that nopaste.snit.ch/17816 works? 22:06
Tene sleep-fencing ftw
chromatic blib/lib/libparrot.so: undefined reference to `Parrot_str_from_cstring' darbelo 22:08
You probably meant Parrot_str_to_cstring. 22:09
With that changes, make testj passes fine for me. 22:10
darbelo Ah. Yes, that's what I get for modifying files for other platforms.
chromatic make test works fine for me too. 22:11
darbelo One less strstart. A whole lot more to go! 22:12
pmichaud afk, travel 22:13
TimToady /e 22:23
nopaste "jrtayloriv" at 96.238.200.246 pasted "[PATCH]: Minor GC refactoring" (349 lines) at nopaste.snit.ch/17817 22:24
jrtayloriv Anyone mind taking a look at my GC patch? Whiteknight reviewed it for me, and told me to remove a lot of it (the patch was originally 800 lines, but I've cut it down to 360).
baah ... hold on -- I left out part of it when I was making the shorter patch -- that one builds, but it doesn't contain everything I've done. 22:26
darbelo (/*JT: What SHOULD we be doing here?*/) : I would put a "default" GC there, or die horribly. 22:30
jrtayloriv darbelo, I was thinking die horribly, but didn't know how I should do so. But I guess I could just do the default instead. 22:36
darbelo I'm in favor of 'die horribly' "WTF? That's not a valid GC! *crash*"
but 'default' has merits too: "What? No, that's not a valid GC, let me fix that for you." 22:37
Maybe 'switch to the default and warn the user'. 22:39
22:41 rg joined 23:03 dukeleto joined
chromatic Heh. 30.565% performance improvement. 23:04
38.446% improvement overall.
jrtayloriv jeebus ... What did you do?
chromatic Avoided multiple context fetches in op bodies. 23:06
dukeleto chromatic: yay for that
jrtayloriv Neato speedo!
dukeleto chromatic: please translate for mere mortals 23:07
23:07 cotto joined
chromatic vi src/ops/core_ops.c 23:07
Read lines 17 - 20 23:08
*every* register access would call a function to fetch the current context.
If you read four registers in an op body and assign to one, you call that function five times.
... even if the context *does not change*.
By now, you're thinking "Hey, what if we cached..." and now you know. 23:09
dukeleto chromatic: sweet 23:10
cur_opcode[i] all over the place 23:11
dukeleto pours chromatic a frothy beer 23:16
chromatic More benchmarks welcome. 23:18
dalek rrot: r40980 | chromatic++ | trunk/lib/Parrot (2 files):
[ops] Changed slow/fast core ops body generation to look up the current context

for *every* register access. This improves the primes.pasm benchmark performance by 38.45%.		 23:19
ose: r99 | Austin++ | trunk/build/Makefile.in:
Removed SymbolLookupVisitor (replaced with Resolution)
 23:21
jrtayloriv chromatic, yep -- 2.08 seconds with old, 1.53 with your patch for fib.pir benchmark ... nice job! 23:26
chromatic Thanks. How was it before the context_pmc3 merge, any notes on that? 23:27
Crazier thought: pass the context into op bodies, as the slow core always sets pc in the context before dispatching each op. 23:31
jrtayloriv chromatic, don't know -- don't have any old revisions around right now. I had just checked out a few minutes prior to your patch (40979).
chromatic The fast core is still 12.934% faster on the primes.pasm benchmark by avoiding that. Interesting.
jrtayloriv finally just took the time to learn how to check out a specific revision w/ SVN ... 23:32
50% speedup ... I'm not impressed. Why don't you shave off another 10 or 15? ;) 23:33
darbelo jrtayloriv: You can also do svn up -rWHATEVER in your working copy instead of checing aout a new one. 23:34
s/checing/checking/ 23:35
dukeleto anybody know what this means: ../../parrot -o ../../runtime/parrot/library/PCT.pbc --output-pbc PCT.pir
Invalid charset number '8' specified
jrtayloriv darbelo, thanks -- didn't know that. 23:36
szbalint fib.pir is about 25% slower for me at HEAD than at 40521 (fairly old rakudo checkout) 23:37
dukeleto is anyone else using parrot with perl 5.10.1 ? 23:41
cotto is
chromatic szbalint, is that with r40980?
szbalint yes 23:42
chromatic Still a ways to go then.
jrtayloriv halfway there 23:43
purl i heard halfway there was closer than not at all
jrtayloriv me too purl -- now shut up before I hurt you
dukeleto purl, forget halfway there
purl dukeleto: I forgot halfway there
chromatic Hm, Parrot_gc_get_attribute_pool is more expensive than it should be.
dukeleto cotto: are you using libicu as well? 23:44
cotto yup
dukeleto cotto: well then, the world hates me 23:47
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40980 - Ubuntu 9.04 amd64 (gcc) 23:48
23:50 joeri left, joeri joined
dukeleto github is hating me now as well 23:50
chromatic Go eat worms. 23:52
nopaste "dukeleto" at 32.152.9.125 pasted "Invalid charset number '8' specified" (865 lines) at nopaste.snit.ch/17818 23:53
dukeleto that happens to me on a clean checkout. i am totally stumped. 23:54
all I know is that I upgraded darwin to perl 5.10.1 last night, so that is very suspicious
darbelo dukeleto: Did you get the new perl from the same source as the previous perl? 23:55
dukeleto darbelo: i compiled from source 23:56
darbelo: i didn't update the system perl, but I updated the perl that Configure.pl use's in my $PATH
darbelo parrot is a bit too sensitive to changes in the flags used to compile perl. 23:57
dukeleto darbelo: that scares me 23:58

Powered by Cro and the Raku® Programming Language.

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

Thank you!