Camelia, the Perl 6 bug

IRC log for #parrot, 2009-09-04

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:18 japhb joined #parrot
00:30 dalek TT #976 created by darbelo++: [PATCH] Reduce poking into STRING guts
00:36 darbelo Boy, is the code to freeze PMCs ehm... special.
00:37 chromatic Very.
00:37 Whiteknight NO SARASM!
00:38 Whiteknight that code is shit and will be addressed as such
00:39 darbelo Whiteknight: But it's doing it all FOR SPEED! It is -optimized- shit.
00:40 Whiteknight yeah, I'm sure it does exactly what it did in 2004 at top speed
00:40 Whiteknight and we can't make it do any more then that since it's such a mess
00:41 cotto chromatic, any thoughts on the profiling runcore code?
00:41 chromatic Haven't quite made it to that yet today.
00:41 darbelo It also appears to know more about the internals of strings than the string subsystem itself.
00:43 * 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?
00:45 cotto By 4.0 Parrot won't have any crappy subsystems left and we'll all sit around being bored.
00:45 Coke yes.
00:45 Coke (be happy)
00:46 cotto (6.0 if our deprecation policy stays in place)
00:47 * darbelo wonders who thought abusing the next_for_GC pointer here was a good idea.
00:59 Whiteknight darbelo: I don't know, but I would like to find that person and abuse them
01:00 Whiteknight cotto: I would be very happy to be working with better software, and knowing that more people were using Parrot
01:00 Whiteknight I probably wouldn't contribute as much, but I would be happy
01:00 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.
01:04 cotto darbelo, keep up the good work.  only 60-70 more patches to go!
01:05 dalek TT #976 closed by cotto++: [PATCH] Reduce poking into STRING guts
01:07 dalek parrot: r40965 | cotto++ | trunk/src (4 files):
01:07 dalek parrot: [string] remove more ->strstart abuse, courtesy of darbelo++
01:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40965/
01:08 * 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.
01:09 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?
01:10 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
01:12 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.
01:13 cotto however, if the code is smart enough to output either I can test ascii and use the binary
01:13 cotto for actual profiling work
01:14 cotto but that can wait until -e "1" profiles with Rakudo
01:28 dalek parrot: r40966 | cotto++ | branches/pluggable_runcore/tools/dev/pprof2cg.pl:
01:28 dalek parrot: [profiling] parameterize the last global and do some minor code cleanup
01:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40966/
01:29 * darbelo goes on the hunt for sleeps.
01:30 darbelo left #parrot
01:37 s1n joined #parrot
01:46 Andy joined #parrot
01:59 dalek tracwiki: v32 | bacek++ | ParrotQuotes
01:59 dalek tracwiki: Big O notation explanation by chromatic
01:59 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Pa​rrotQuotes?version=32&action=diff
02:09 dalek tracwiki: v33 | cotto++ | ParrotQuotes
02:09 dalek tracwiki: sarcasm will not be tolerated
02:09 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Pa​rrotQuotes?version=33&action=diff
02:09 dalek tracwiki: v34 | cotto++ | ParrotQuotes
02:09 dalek tracwiki: "sacrasm" won't be tolerated either
02:09 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Pa​rrotQuotes?version=34&action=diff
02:14 dalek partcl: r686 | coke++ | trunk/runtime/builtin/file.pir:
02:14 dalek partcl: First attempt at [file delete]
02:14 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=686
02:14 dalek partcl: r687 | coke++ | trunk/t/cmd_file.t:
02:14 dalek partcl: Hey, I bet this joke was really funny 4 tests ago.
02:14 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=687
02:14 dalek partcl: r688 | coke++ | trunk/runtime/builtin/file.pir:
02:14 dalek partcl: PIR cleanup
02:14 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=688
02:15 cognominal joined #parrot
02:16 mokurai joined #parrot
02:19 Coke my segfaullllllts. feeeeex theeeeeem.
02:35 janus joined #parrot
03:02 sri joined #parrot
03:18 theory joined #parrot
03:20 donaldh joined #parrot
03:21 dukeleto_ joined #parrot
03:26 Andy joined #parrot
03:36 Andy joined #parrot
04:38 asciiville joined #parrot
05:13 payload joined #parrot
05:22 HG` joined #parrot
05:33 dalek parrot: r40967 | mikehh++ | trunk/src/gc/mark_sweep.c:
05:33 dalek parrot: codetest failure - trailing spaces
05:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40967/
05:37 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:  http://smolder.plusthree.com/app/pu​blic_projects/report_details/26802  [Sep  3 01:46:03 2009]
05:40 dalek parrot: r40968 | mikehh++ | trunk/src/pmc/string.pmc:
05:40 dalek parrot: codetest failure - space after opening parenthesis
05:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40968/
05:43 dalek parrot: r40969 | mikehh++ | trunk/src/pmc/hash.pmc:
05:43 dalek parrot: codetest failure - isxxx() function not cast to unsigned char
05:43 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40969/
05:44 cotto How are functions like pir_output_is generated?
05:47 let0 cotto: good question. there is magic in Parrot::Test
05:47 let0 cotto: what do you want to know?
05:47 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
05:47 cotto instareply
05:47 let0 cotto: you want to do this in PIR or perl ?
05:48 let0 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
05:48 cotto Excellent.  We'll need stuff like that.
05:49 cotto I'd teleport over there to join you, but I can't teleport.
05:49 cotto let0, do you understand the perly magic?
05:50 let0 cotto: understand, yes. like, no.
05:50 let0 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...
05:51 cotto Yeah.  I got the impression that it generated functions.
05:52 let0 cotto: are you trying to capture STDOUT or STDERR ?
05:52 let0 or an exception ? or just normal output?
05:53 cotto STDERR sounds best.  Currently the profile goes to a file, but stderr sounds like the best place for testing purposes.
05:57 cotto I also want to be able to capture the profiling output in order to test pprof2cg
06:04 let0 cotto: you want to do this from PIR?
06:04 cotto perl is fine
06:05 cotto 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
06:08 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)
06:10 cotto chromatic, ping
06:12 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
06:12 let0 mikehh: can you nopaste
06:13 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
06:16 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 http://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?
06:19 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.
06:22 mikehh let0: you partying and stuff?
06:23 let0 mikehh: indeed
06:23 let0 mikehh: i am not sure who to blame for that test failure
06:25 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
06:26 mikehh let0: I don't think it happens on i386 (not sure)
06:26 let0 mikehh: i can test it on powerpc
06:27 NotFound mikehh: the segfault is in a TODOed test, then parrot_debugger.t PASS anyway
06:27 iblechbot joined #parrot
06:29 chromatic pong
06:30 chromatic cotto, that's tricky.  I'll have to think about it some.
06:32 cotto My first instinct is in the iglobals array and my second instinct is "don't do that".
06:33 cotto It'd be pretty easy if the option processing code didn't remove the stuff it processed from argv.
06:34 chromatic That code has been a minor thorn in my side for ages.
06:34 chromatic I moved it partially out of IMCC years ago.
06:35 chromatic ... but it's still tied too closely to IMCC for my comfort, especially in a world where pirc may merge.
06:37 theory joined #parrot
06:40 cotto test coverage?
06:40 purl it has been said that test coverage is http://cv.perl6.cz
06:52 mikehh NotFound - it is not either of the TODO tests
06:54 mikehh NotFound - if I skip the TODO tests it still backtraces
06:59 mikehh 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
07:06 mokurai left #parrot
07:16 mikehh NotFound: if I skip Test 41 it does not backtrace
07:18 chromatic That's worse than backwash.
07:18 mikehh don't know - I could do with a backwash :-}
07:20 mikehh depends how you interpret that of course :-}
07:20 donaldh joined #parrot
07:32 mikehh bbl
08:29 dukeleto joined #parrot
08:34 mikehh rakudo (b51d94c) builds on parrot r40969 - make test / make spectest (up to r28187) PASS - Ubuntu 9.04 amd64 (gcc)
08:37 preflex joined #parrot
08:51 bacek joined #parrot
08:52 bacek o hai
09:05 HG` joined #parrot
09:12 gaz joined #parrot
09:14 cotto good night
09:16 mikehh cardinal - builds on parrot r40969 - rake test:all - same 3 failures - Ubuntu 9.04 amd64 (gcc)
09:17 mikehh partcl r688 builds on parrot r40969 - make test PASS - Ubuntu 9.04 amd64 (gcc)
09:20 mikehh decnum-dynpmcs r181 builds on parrot r40969 - make test PASS - Ubuntu 9.04 amd64 (gcc)
09:21 cognominal joined #parrot
09:22 einstein joined #parrot
09:41 bacek jrtayloriv: ping
09:59 dalek wmlscript: f381ee3 | fperrad++ |  (3 files):
09:59 dalek wmlscript: install dynops & dynpmc in languages/wmlscript/dynext
09:59 dalek wmlscript: review: http://github.com/fperrad/wmlscript/commit​/f381ee32024156926915800242bb1150908e12b3
09:59 dalek wmlscript: f72e19c | fperrad++ | t/ (3 files):
09:59 dalek wmlscript: run parrot in current directory
09:59 dalek wmlscript: review: http://github.com/fperrad/wmlscript/commit​/f72e19c39e6df78bba09f23ffd71cb77d776dd75
09:59 dalek wmlscript: 7800a1f | fperrad++ | t/pmc/ (10 files):
09:59 dalek wmlscript: rewrite in PIR
09:59 dalek wmlscript: review: http://github.com/fperrad/wmlscript/commit​/7800a1f1867f7e606a9a1c822629e3d475607b0d
10:04 dalek xml: e57bace | fperrad++ | t/Parrot/Test/Xml.pm:
10:04 dalek xml: run parrot in current directory
10:04 dalek xml: review: http://github.com/fperrad/xml/commit/e5​7baced904647f0a2177bbbac35c604126e37dd
10:19 bacek ooookey... gms GC is badly broken.
10:20 bacek 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 #parrot
11:31 masak joined #parrot
11:37 Coke wasn't there a ticket about removing all non-default GCs?
11:38 Coke (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:55 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:56 einstein but i think a system should be added so you can choise which gc is used at startup time of the interpreter
11:56 einstein before someone is gonna try to repair to other gc systems
11:56 dalek wmlscript: 5ebdd54 | fperrad++ | t/pmc/ (10 files):
11:56 dalek wmlscript: fix shebang
11:56 dalek wmlscript: review: http://github.com/fperrad/wmlscript/commit​/5ebdd545fc88f87c0a1673d5d3122137df57b233
12:18 whiteknight joined #parrot
12:18 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
12:18 whiteknight some good ideas, but probably better to start from scratch at this point
12:19 whiteknight smolder?
12:19 purl i think smolder is http://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 http://smolder.plusthree.com/app​/public_projects/smoke_reports/8
12:19 rindolf joined #parrot
12:20 rindolf Hi all.
12:20 whiteknight hello
12:20 rindolf I'd like to implement http://www.shlomifish.org/o​pen-source/projects/Spark/ on top of Parrot, and would like to start with one of Parrot's lisp impls.
12:20 rindolf Is it OK?
12:20 whiteknight that sounds like a great project
12:21 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!
12:21 whiteknight rindolf: definitely OK
12:22 whiteknight rindolf: in fact, it would be great
12:22 rindolf whiteknight: OK.
12:22 rindolf whiteknight: OK.
12:22 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.
12:22 whiteknight we don't have any List implementations that are active and up-to-date
12:22 rindolf whiteknight: I hope people are not possessive about me spinning-off one of their Lisp implementations.
12:22 whiteknight rindolf: not at all
12:22 rindolf Because Spark is not just another Scheme or CL implementation.
12:22 whiteknight what's so different about it?
12:22 rindolf whiteknight: OK, thanks.
12:23 * whiteknight is not familiar with Spark
12:23 rindolf whiteknight: it's very new.
12:23 rindolf whiteknight: I'm going to borrow many good ideas from Arc, Perl, Ruby, Python, Moose, etc.
12:24 rindolf whiteknight: and it will be much more brief than Scheme or CL.
12:24 rindolf And with better human engineering.
12:25 rindolf See : http://bitbucket.org/shlomif/spark/src/tip/doc​s/mission/Spark-Pre-Birth-of-a-Modern-Lisp.txt
12:25 whiteknight Ah, so better in every way? That's awesome!
12:26 particle whiteknight: how goes the context_pmc3 branch merge cleanup?
12:26 rindolf whiteknight: better in every way to what?
12:26 whiteknight particle: I've just been reviewing the smolder reports. Looks like things are pretty stable except on AIX
12:26 whiteknight (although I don't know if AIX was passing 100% before, so I don't know)
12:27 whiteknight rindolf: Just making a joke. Sounds like an awesome project
12:27 particle well, you can check smolder for that info
12:27 whiteknight rindolf: Are there other implementations, or is this going to be the first one?
12:27 rindolf whiteknight: yeah.
12:27 rindolf whiteknight: it's the first one.
12:27 rindolf whiteknight: I came up with the Spark name.
12:27 rindolf whiteknight: it doesn't even have a spec yet.
12:27 whiteknight well very cool. You can't pick a better place to start then with Parrot.
12:27 rindolf whiteknight: thanks.
12:29 whiteknight particle: how do I check the history of reports for one platform?
12:29 particle checking...
12:30 particle http://smolder.plusthree.co​m/app/public_graphs/start/8
12:31 particle rats, you can't click through to the reports there
12:32 particle ok: http://smolder.plusthree.com/app​/public_projects/smoke_reports/8
12:32 particle you can use the 'aix' tag
12:32 whiteknight okay, looks like AIX has been stable in it's fail rate
12:32 particle yes
12:32 whiteknight so, we good to merge the kill_parrot_cont branch soon then?
12:32 particle yes, looks like it.
12:33 particle announce the successful merge of context_pmc3 first, and move forward
12:33 whiteknight any rakudo hackers in the house today?
12:34 Coke whiteknight: AIX has pretty much always failed.
12:34 Coke ... and then I catch up to the last 10 lines. whoops.
12:34 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)
12:37 whiteknight though I don't have an AIX machine to do any debugging on
12:38 Coke good luck finding out who that is. =-)
12:38 Coke we have a lot of stealth smokers, I think. =-)
12:39 whiteknight Coke: How is partcl doing right now? Is it experiencing any context_pmc3-related failures?
12:40 Coke whiteknight: http://code.google.com/p/partcl/source/​browse/trunk/docs/spectest-progress.csv -- pretty sure r40959 is post-merge.
12:40 whiteknight you need a fancy graph
12:40 Coke NotFound++ #again.
12:41 Coke (kind of a non-sequitor, I know.)
12:41 Coke non-sequitur, before austin corrects me again. =-)
12:41 moritz you could steal from rakudo's tools/progress-graph.pl
12:41 Coke moritz: That's why i started making the CSV, I hoped someone else would do that bit. =-)
12:41 moritz ;-)
12:42 whiteknight moritz: how is Rakudo doing?
12:42 whiteknight (is it experiencing any problems after context_pmc3?)
12:42 moritz whiteknight: well; I pushed bacek++'s patch, no new test failures
12:43 whiteknight excellent news!
12:44 Coke whiteknight: my biggest concern is the "time to run", which has gone from 6381s to 8340s.
12:44 Coke (not all of that is the context branch, but some of it definitely is.)
12:44 moritz rakudo is also a bit slower
12:44 purl okay, moritz.
12:45 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 whiteknight I haven't done any benchmarks of course, but it *should* help
12:46 whiteknight And there are other optimizations we need to make too. Many of the changes recently were just first steps in these comprehensive refactors
12:50 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?
12:50 purl well, irclogs is http://irclog.perlgeek.de/parrot/today or see also: infrared clogs
12:50 whiteknight particle: I specifically leave things vague like that because I'm too lazy to do it when I say I will
12:50 whiteknight it's always evening somewhere :)
12:51 whiteknight 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:52 particle :P
12:52 particle good thing we don't make any performance guarantees in our policies
12:52 particle parrot is 10% slower? none of the tests fail... so no problem!
12:53 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 whiteknight so it's the class situation of "it will get worse before it gets better"
12:54 particle it's always darkest after you go blind.
12:54 ruoso joined #parrot
12:57 dalek partcl: r689 | coke++ | wiki/SpecTestStatus.wiki:
12:57 dalek partcl: 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
12:57 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=689
12:57 dalek partcl: r690 | coke++ | trunk/docs/spectest- (2 files):
12:57 dalek partcl: Pass 2 files that originally failed to complete (See Issue #102).
12:57 dalek partcl: Lose one file (probably due to r686)
12:57 dalek partcl: Net gain of 137 passing tests.
12:57 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=690
12:57 Coke whiteknight: checking with latest parrot...
13:05 sri_ joined #parrot
13:06 Eevee joined #parrot
13:07 rindolf https://rgrjr.dyndns.org/sv​n/kea-cl/trunk/README.text - crud! Same terms as Perl 5. GPLv1+ or Artistic-1 only.
13:08 rindolf https://trac.parrot.org/la​nguages/browser/lisp/trunk - this is better - Artistic 2.
13:09 whiteknight rindolf: yeah, our kea-cl implementation is very old
13:09 whiteknight older then some of these licensing discussions
13:10 rindolf whiteknight: ah.
13:11 quek joined #parrot
13:12 Coke whiteknight: I have kicked off a test run. See you in 3 hours.
13:13 whiteknight I'll be here :)
13:13 whiteknight 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
13:15 Coke I wonder if it would be worth making 'make spectest' respect TEST_JOBS.
13:15 Coke probably not, since each invocation of parrot chews 100% of the CPU and usually takes minutes.
13:15 whiteknight if you have more then one core, definitely
13:15 Coke I'm on feather, it's a VM, and I'm sharing it.
13:16 whiteknight oh, then no
13:18 Coke After this, I should do another run with fastcore and see if that helps.
13:18 Coke (tell me again why we don't default to the fastest core?)
13:18 whiteknight I have no idea, but for releases I think we definitely should
13:21 whiteknight moritz: ping
13:21 moritz whiteknight: pong
13:21 whiteknight moritz: could you run a Rakudo spectest today to see if it is any faster?
13:22 moritz whiteknight: yes
13:22 Coke whiteknight: (for releases) the problem with that being the default is what's tested mostly in between releases.
13:22 Coke so if we change it for the release, we're screwing our QA.
13:22 moritz I didn't time it before, so that's what I'm doing right now
13:22 moritz then I'll update parrot
13:22 moritz and try again
13:23 whiteknight I enabled the fixed-size allocator in r40962, so before and after that should show some improvements
13:27 particle we shouldn't default to a core we don't regularly run tests on
13:27 * particle catches up with scrollback, coke++
13:28 whiteknight I would recommend then that we switch fastcore to be the global default
13:28 whiteknight slowcore is only useful in debugging
13:29 particle yeah, who does that?
13:29 particle how much faster is the fast core over the slow core before context_pmc3 merge?
13:29 whiteknight we only need to debug when something is demonstrably wrong. And the fastcore will alert us that something is wrong
13:29 whiteknight I have no idea, I haven't seen recent numbers
13:30 particle agreed.  i'm considering a recommendation to move to fast core after we finish the branch merges, before 1.6 release
13:30 particle as long as we have enough time to get smokes
13:30 particle it would be nice not to regress performance-wise
13:31 whiteknight We do need to develop some higher-performance cores, like a good context-threaded core
13:32 whiteknight 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?
13:33 whiteknight mortiz: doesnt exist yet.
13:33 whiteknight It's like a mini-JIT that can provide a real performance boost
13:36 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!
13:36 rindolf If anyone is interested I registered #spark on Freenode.
13:45 whiteknight rindolf: you blog about it
13:45 whiteknight ?
13:45 rindolf whiteknight: the #spark channel?
13:45 rindolf whiteknight: I mentioned Spark in my homepage's blog.
13:45 whiteknight no, spark in general
13:46 whiteknight ok
13:46 rindolf But didn't really publicise it.
13:46 rindolf whiteknight: I think I'd rather do it when I have a little to show for.
13:46 rindolf CatB , etc.
13:47 whiteknight Understood.
13:47 purl Understood. are you on schedule?
13:48 whiteknight If you do start blogging about it, Parrot has an aggregator that we could include you in
13:48 snarkyboojum joined #parrot
13:59 rindolf whiteknight: yes.
14:00 rindolf whiteknight: I'm getting:
14:00 rindolf <<< Can't open perl script "/usr/lib/parrot/1.5.0/tools/dev/gen_makefile.pl": No such file or directory >>>
14:00 rindolf On Mandriva Linux Cooker.
14:00 rindolf With the parrot .rpm's.
14:01 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
14:01 whiteknight you need parrot-dev, not parrot
14:01 whiteknight the regular parrot distribution doesn't include all the development tools
14:02 Coke (tcl, for example, has its own makefiles, and doesn't let parrot gen them.)
14:03 rindolf whiteknight: I have everything.
14:03 rindolf moritz: OK.
14:03 rindolf BTW, I like the Parrot homepage.
14:03 rindolf IT's attractive, and usable.
14:06 NotFound coverity?
14:06 purl hmmm... coverity is a commercial tool for Automated Error Prevention and Source Code analysis, See,  http://www.coverity.com/main.html or it has been used to measure the quality of the LAMP stack and other major source projects
14:06 NotFound cover?
14:06 purl cover is not at link?
14:11 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.
14:12 rindolf Coke: the colours may be a bit too glowing.
14:12 * moritz needs more CPU cores for rakudo testing
14:12 rindolf But it looks good.
14:12 moritz rindolf: if you find the parrot.org colors too glowing, never visit perl6.org :-)
14:13 rindolf moritz: get yourself a nice UltraSPARC Niagra machine.
14:13 rindolf The Niagara has 64 cores or so.
14:13 moritz and you think that parrot and rakudo will build on it? ;-)
14:13 moritz 8 cores amd64 would be a great improvement already
14:13 rindolf moritz: yes.
14:14 Psyche^ joined #parrot
14:14 rindolf I think parrot and rakudo run on UltraSPARCs.
14:14 * rindolf is building parrot trunk now.
14:25 dukeleto 'ello
14:29 * 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:30 moritz so not related to the inferior runloop problem?
14:31 moritz whiteknight: rakudo is now a tad slower than right after the context_pmc3 merge
14:31 moritz 46m21 then, 48m3 now
14:31 Coke not that I'm aware of; pretty sure NotFound++'s workaround on that is still working.
14:31 Coke moritz: greaaat. =-)
14:31 dalek parrot: r40970 | NotFound++ | trunk/t/pmc/fixedpmcarray.t:
14:31 Coke (48+3/60)/(46+21/60)
14:31 dalek parrot: [t] increase coverage of fixedpmcarray
14:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40970/
14:31 purl 1.03667745415318
14:31 whiteknight moritz: so that's better then 13% slower that pmichaud mentioned yesterday, but still not as good as it was
14:32 moritz whiteknight: no, that's *additional* slowness
14:32 whiteknight oh jeez
14:32 whiteknight well that's no good. We're going to have to disable the fixed-size allocator again and see if that was the culprit
14:33 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
14:33 Coke whiteknight: does it serve any other purpose?
14:33 Coke (reduce memory usage, etc?)
14:33 moritz Coke++
14:33 NotFound whiteknight: maybe you must try to disable the lazy part
14:33 whiteknight NotFound: that's a good point too
14:34 whiteknight Coke: No, basically reduces calls to malloc and makes all allocations O(1)
14:34 whiteknight probably needs tuning in any case
14:34 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 >>>
14:34 rindolf whiteknight: seems like it is out-of-date
14:35 whiteknight rindolf: Probably very out of date. I don't know how to help with that
14:38 Coke rindolf: what is telling you to use that?
14:38 Coke (are you trying to build someone else's code?)
14:38 rindolf Coke: https://svn.parrot.org/languages/lisp/trunk
14:38 rindolf Coke: yes, I am.
14:39 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 Coke so we shoved them there so they wouldn't get lost.
14:39 Coke it will probably take some effort to update that to work with latest and greatest parrot.
14:39 jrtayloriv joined #parrot
14:39 whiteknight yeah, all that stuff is very old
14:39 rindolf Coke: OK.
14:40 Coke (though fperrad++ has done a lot of work trying to keep them building.)
14:41 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 janus joined #parrot
14:41 whiteknight who is writing tests in Perl?
14:42 whiteknight PIR is definitely the new hotness
14:42 dukeleto whiteknight: https://trac.parrot.org/parrot/changeset/40970/
14:42 NotFound Can't we write test in nqp?
14:42 particle whiteknight: arguably, that's nqp now
14:42 rindolf whiteknight: I see.
14:42 particle NotFound: depends what we're testing
14:42 whiteknight oh, well if the test file is already in Perl, that's different
14:42 rindolf Well, maybe I'll look at a Scheme implementation.
14:42 whiteknight Scheme is going to be even worse
14:43 particle new tests should not be written in perl
14:43 rindolf There are some Scheme implementations.
14:43 NotFound I suppose things like pir_output_is will be easier to implement in nqp than in pir
14:43 whiteknight rindolf: and they are all bad
14:43 rindolf whiteknight: ah.
14:43 whiteknight one is written in flex/bison
14:43 particle old tests should be converted... it reduces our reliance on perl, and improves performance
14:43 rindolf Wow.
14:44 jrtayloriv joined #parrot
14:44 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:45 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
14:45 whiteknight oh wow, that would be awesome
14:46 whiteknight what would that be, a try/catch that tests the exception message?
14:47 dukeleto whiteknight: yep, it is mostly written, just making sure there are no kinks
14:47 dukeleto haven't had time to work on it in the last few days
14:49 whiteknight after kill_parrot_cont lands, I want to spend most of the rest of this cycle writing tests
14:49 whiteknight so that would be awesome
14:57 NotFound Any idea about where a context can be freed other than in Context.destroy ?
14:58 whiteknight NotFound: RetContinuations free themselves after invocation
14:58 whiteknight otherwise, no
14:58 whiteknight So RetContinuation:invoke()
14:59 NotFound Parrot_continuation_rewind_environment ?
14:59 whiteknight I have to double-check that function
14:59 whiteknight why, are you getting a problem with double-free contexts?
15:00 theory joined #parrot
15:00 NotFound whiteknight: the parrot_debugger segfault happens at Context.destroy, I suspect is a double free.
15:01 whiteknight okay
15:08 NotFound I'm thinking the problem must be in parrot_debugger itself, some mixing between debugger and debuggee interpreters
15:17 Coke chromatic had a scheme implementation called pheme that had one of the first test suites to self-host.
15:17 jan joined #parrot
15:21 dukeleto NotFound: that test is a little sketchy
15:22 NotFound whiteknight: with #define GC_USE_LAZY_ALLOCATOR 0 parrot test pass, the debugger segfault remains and rakudo builds and pass test. amd64
15:23 whiteknight so is that different from setting it to 1?
15:23 NotFound No, just verifying that it works the same
15:25 NotFound Changing it requires a realclean, looks like we lack some dependecies in the Makefile
15:26 NotFound Maybe just a clean, I just go straight to the real ;)
15:37 NotFound partcl also builds and pass test
15:38 sri joined #parrot
15:44 dalek tracwiki: v10 | whiteknight++ | JITRewrite
15:44 dalek tracwiki: https://trac.parrot.org/parrot/wiki/J​ITRewrite?version=10&amp;action=diff
15:51 rindolf whiteknight: so what should I do?
15:51 rindolf whiteknight: start from a different front-end?
15:51 rindolf A non-Lisp one?
15:52 whiteknight ridolf: yes, that's what I would recommend for now. None of the Lisp implementations are workable right ow
15:52 whiteknight now
15:52 whiteknight start from scratch is probably easiest
15:53 Andy joined #parrot
15:53 rindolf whiteknight: OK.
15:53 rindolf whiteknight: thanks.
15:54 whiteknight np
16:02 whiteknight we should start thinking about GSOC next year
16:02 whiteknight this year I don't think we had a great list of suggestions for new projects
16:04 whiteknight 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:13 dalek lua: 2885dd7 | fperrad++ | t/ (9 files):
16:13 dalek lua: run parrot in current directory
16:13 dalek lua: review: http://github.com/fperrad/lua/commit/28​85dd7509285d63914128f5ad683cf50b49430f
16:13 dalek lua: b6ebbc8 | fperrad++ | t/pmc/ (16 files):
16:13 dalek lua: rewrite tests in PIR
16:13 dalek lua: review: http://github.com/fperrad/lua/commit/b6​ebbc85facaedc352755e98f78f4271e2bb2094
16:17 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:18 whiteknight NotFound: GC_USE_LAZY_ALLOCATOR shouldn't be a speed improvement really, GC_USE_LAZY_ALLOCATOR should be
16:19 whiteknight I mean, GC_USE_FIXED_SIZE_ALLOCATOR
16:19 NotFound whiteknight: yeah, but I was checking anyway just in case
16:19 whiteknight okay
16:20 whiteknight 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
16:20 whiteknight Well, I mean we can take out the flag and not have a non-lazy option
16:20 NotFound Ah, ok.
16:20 whiteknight chromatic was doing some tuning though, so we can wait for that before making any decisions
16:21 NotFound +1
16:21 purl 1
16:21 NotFound I'd like an allocator with pink neon lights
16:22 MoC joined #parrot
16:22 whiteknight that would be fine too
16:23 NotFound That's what meny people understand when you say "tuning"
16:24 whiteknight And I want to put a "Type-R" sticker on it
16:24 whiteknight to give it more horsepower
16:25 NotFound I'd like better "TURBO", it has a retro fashion...
16:29 cotto joined #parrot
16:30 duk3leto whiteknight: i am very excited about possibilities for parrot and perl 6 for gsoc next year
16:31 duk3leto 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:36 NotFound whiteknight: disabling the fixed size allocator is slower, maybe a 1%
16:37 whiteknight okay, so fixed-size *is faster*?
16:37 NotFound Yeah
16:37 whiteknight okay, that's all I needed to hear
16:37 whiteknight (although I'm upset that it's such a small increase)
16:37 whiteknight we really need to convert Context PMC to use ATTRs
16:38 kjeldahl joined #parrot
16:38 particle by next tuesday, please.
16:38 NotFound I don't think rakudo make test is very good benchmark, but give us some idea
16:38 cotto good morning
16:38 purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
16:38 whiteknight particle: so give a week before the release without big changes?
16:38 whiteknight good morning cotto
16:40 particle NotFound: spectest is a much better benchmark
16:40 particle heck, building rakudo is probably a better benchmark than rakudo's test target
16:40 particle many more pmc's to gc
16:40 particle no, not needed for this release, i just want you to work hard this weekend :)
16:41 NotFound particle: spectest is too long for quick tests
16:42 particle NotFound: but building rakudo isn't
16:45 mokurai joined #parrot
16:49 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
16:50 NotFound amd64 unoptimized
16:53 whiteknight There are some fixes to the allocator that I think I can make to improve things a little
16:54 whiteknight but that's going to have to wait till tonight
16:56 NotFound 1m32 with --optimize. That's a difference
16:59 whiteknight that is pretty significant
16:59 whiteknight is that with or without the allocator?
16:59 NotFound With, testing now without
16:59 * whiteknight crosses his fingers
16:59 treed Saw the message on the mailing list asking for tests from HLLs after the context_pmc drop.
17:00 whiteknight treed: and? How is Cardinal doing?
17:00 treed It won't even start building.
17:00 treed running parrot_config results in:
17:00 treed Invalid charset number '1768057203' specified
17:00 whiteknight ouch, that's as bad as can be
17:00 particle cotto: (i'm on the phone)
17:00 treed I can force it to not need parrot_config by writing build.yaml myself.
17:00 cotto np
17:00 treed But probably better to just fix that.
17:02 whiteknight treed: I've never even heard of an error likethat
17:02 NotFound 1m64 with --optimize and without the FSA
17:02 NotFound 1m36 with --optimize and without the FSA
17:02 whiteknight okay, that makes more sense
17:02 whiteknight still not as good as I hoped
17:02 NotFound Strange cross fingers :?
17:05 treed src/string/api.c
17:05 treed 767:            "Invalid charset number '%d' specified", charset_nr);
17:06 whiteknight maybe malloc performs much better then I expected
17:07 whiteknight treed: and where in the build process do yo get that?
17:07 NotFound treed: that sounds like mixing parrot libs
17:16 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: http://pastebin.com/dcb9c3cf ... please tell me if there is any more info you need.
17:17 jrtayloriv 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:18 jrtayloriv 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".
17:18 treed OS X
17:19 treed or any invocation of parrot_config
17:20 whiteknight jrtayloriv: run "make headerizer"
17:20 NotFound jrtayloriv: you need to make headerizer before using the ASSERT_ARGS macro in a new function
17:21 NotFound And make headerizer usually doesn't work without executing make first, so you may need to temporarily delete the macro
17:22 NotFound (A nice project for beginners: fix this) ;)
17:23 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...
17:29 NotFound whiteknight: num_free_objects is used for something? Looks like is incremented and decremented but never checked
17:30 whiteknight NotFound: might not be, that's true
17:30 whiteknight I've got a lot of little cleanups I would like to make in there
17:39 quek left #parrot
17:40 chromatic joined #parrot
17:42 whiteknight hullo chromatic
17:42 chromatic morning
17:43 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 whiteknight and I know you were doing some local work tuning the lazy allocator, but that doesn't currently offer any benefits either
17:43 NotFound FSV of "benchmarking"
17:44 whiteknight "timing" in either case, it shows that there is no real benefit
17:45 whiteknight 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:46 whiteknight Although maybe I'm overestimating how many calls to malloc we're making.
17:47 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
17:47 treed BBL
17:50 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 payload joined #parrot
17:50 whiteknight we can look for other low-hanging fruit before the release
17:51 chromatic Last time I tried it, it did show some benefits.
17:52 whiteknight NotFound's numbers today were like 1-2%
17:52 cotto chromatic, what about this:
17:52 nopaste "cotto" at 74.61.2.46 pasted "allow access to unprocessed argv list" (63 lines) at http://nopaste.snit.ch/17811
17:53 chromatic cotto, that's probably workable for now... but do we *need* that feature for the testing now?
17:54 cotto The alternative is always writing to stderr or stdout, which means an annoying redirect for any non-testing purposes.
17:55 NotFound cotto: can't you use getenv?
17:57 chromatic PARROT_PROFILE_OUTPUT or something?
17:57 NotFound Yes, something like that.
17:58 cotto That'd also work and be less annoying.
17:59 chromatic Less code too.
17:59 cotto I'll just use that.  Thanks for not missing a good obvious solution, NotFound++
17:59 whiteknight In reality, we probably don't want all our argument handling to happen internally to IMCC
18:00 whiteknight at least not forever, since IMCC could be involved in a terrible code accident one day
18:01 whiteknight that's a stylistic preference for now, of course
18:02 chromatic I tried to move that code a couple of times.  I always had trouble because it processes IMCC options too.
18:03 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.
18:04 whiteknight I've actually been considering an interface refactor there for a while. Just haven't had any particular reason to attempt it
18:05 whiteknight 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 #parrot
18:13 Coke whiteknight: re-ran the test.
18:14 whiteknight Coke: Let me guess, no real improvement?
18:14 Coke "2009-09-03 22:20",688,"r40959",97,7752,35​70,2131,2051,8811,"--optimize"
18:14 Coke "2009-09-04 09:05",690,"r40969",97,7752,35​69,2132,2051,8287,"--optimize"
18:14 Coke 8287/8811
18:14 purl 0.940528884349109
18:15 Coke looks like those 10 parrot revisions gave me a 5% speedup.
18:15 Coke (and one failed test. not sure what's up with that.)
18:15 Coke so, just need to get it back down to 40897 speeds. (and then beyond. =-)
18:19 whiteknight really? I'm surprised you saw 5%
18:21 darbelo joined #parrot
18:25 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40970 - Ubuntu 9.04 amd64 (g++)
18:27 mikehh cardinal - builds on parrot r40970 - rake test:all - same 3 failures - Ubuntu 9.04 amd64 (g++)
18:29 whiteknight well that's surprising. Treed said he can't get cardinal to build at all
18:30 mikehh I noticed that - but it builds ok for at the moment
18:30 NotFound WTF is a HashIteratorKey ?
18:31 Psyche^ joined #parrot
18:31 mikehh ok for me
18:33 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.
18:33 NotFound Well, I'll fix the segfault and let others make sense of it.
18:34 Coke trac sloooow
18:35 mikehh rakudo (b51d94c) builds on parrot r40970 - make test / make spectest (up to r28187) PASS - Ubuntu 9.04 amd64 (g++)
18:36 Coke NotFound: that would potentially fix 2 of partcl's segfaults.
18:36 Coke (set-old and dict)
18:37 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
18:38 dalek parrot: r40971 | cotto++ | branches/pluggable_runcore/src/runcore/cores.c:
18:38 dalek parrot: [profiling] allow the output file to be specified by the PARROT_PROFILING_OUTPUT environment variable
18:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40971/
18:41 NotFound Coke: set-old is the one I was checking
18:41 dalek parrot: r40972 | NotFound++ | trunk/src/pmc/hashiteratorkey.pmc:
18:41 dalek parrot: [pmc] fix? HashIteratorKey.get_string
18:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40972/
18:43 Coke updating, checking...
18:50 chromatic Why would an iterator exist without a hash?
18:50 whiteknight NotFound: looks sane to me
18:51 whiteknight chromatic: that's actually a good question. I would be very interested to see the PIR snippet that was causing this
18:51 whiteknight (and then make a test to insure it never happens again)
18:51 Coke whiteknight: ... there is no snippet.
18:52 Coke only several thousand lines of tcl. =-)
18:52 whiteknight Coke: somewhere in that pile of TCL is a PIR fragment that causes this error
18:52 whiteknight likely implicit, but it exists
18:52 Coke not necessarily.
18:53 whiteknight ...and it wouldn't be because...?
18:53 mikehh partcl r691 builds on parrot r40970 - make test PASS - Ubuntu 9.04 amd64 (g++)
18:53 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 ...
18:54 Coke <initial something> <3000 lines of tcl which does god knows what include trigger a GC run> <sample<>
18:54 Coke and the sample is where the segfault occurs, but if you run it alone, nothing happens.
18:54 Coke nothing /bad/
18:55 rindolf whiteknight: which dynamic languages do you suggest as the basis for parspark?
18:55 rindolf whiteknight: which Parrot front-end do you suggest as the basis for parspark?
18:55 Coke that said, I have not tried to reduce that particular segfault down to a PIR sample.
18:56 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.
18:56 rindolf whiteknight: is Cardinal a Ruby impl?
18:56 Tene Yes.
18:56 whiteknight Coke: knowing where the problem occurs in PIR, even if we can't always reproduce it completely, can be very instructive
18:56 rindolf Tene: thanks.
18:57 Tene s-exps?
18:57 Tene i have a scheme impl
18:57 whiteknight "This code causes problems sometime" is good enough
18:57 whiteknight Tene: what's the status of that?
18:57 rindolf Tene: ah, for Parrot?
18:57 Tene Yes, for parrot.
18:57 rindolf Tene: nice.
18:57 Tene i haven't read scrollback, what's up?
18:58 Tene whiteknight: It's my standard PCT presentation demo.
18:58 whiteknight Tene: What's it called?
18:58 Tene http://github.com/tene/steme/tree/master
18:58 rindolf Tene: fine. Want to start working on http://www.shlomifish.org/o​pen-source/projects/Spark/
18:58 rindolf Tene: ah.
18:58 whiteknight Tene: rindolf is looking to implement a new lisp-like language on Parrot
18:58 rindolf Tene: what licence is it under?
18:58 Coke NotFound: dict.test and set-old.test now both complete.
18:58 Coke ;that's an extra 291 PASSED.
18:58 NotFound Nice :)
18:59 whiteknight very nice
18:59 Coke that's >8%
18:59 Tene rindolf: After at *least* 10 seconds of thinking about it, it's under the "Um... license?  Dunno.  Whatever you want." license.
18:59 rindolf Tene: can it be MIT/X11?
18:59 Tene rindolf: It certainly can be for you.
18:59 Coke hey, yet another license!
19:00 rindolf Tene: thanks!
19:00 * rindolf hugs Tene
19:00 Tene rindolf: Spark is a new lisp-like language you'd like to write, I guess?
19:01 rindolf Tene: yes.
19:01 rindolf Tene: it's still in the planning stage.
19:01 Tene That's great.  I'd love to work with you on it.
19:01 Tene Well, if you're planning to build it on Parrot. :)
19:01 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.
19:02 rindolf Then he did, but I realised Arc kinda sucked.
19:02 rindolf Tene: yes , I'm planning to use Parrot.
19:02 dalek TT #963 closed by coke++: segfault in Parrot_HashIteratorKey_get_string
19:02 Tene I don't quite have the tuits to get into a completely different community right now. :)
19:02 rindolf Tene: anyway read the web page http://www.shlomifish.org/o​pen-source/projects/Spark/
19:03 cotto use the WTFPL
19:03 Tene rindolf: My email is /me at allalone.org if you want to contact me later.
19:04 * Tene reads.
19:04 rindolf Tene: ok.
19:04 rindolf Tene: got IM?
19:04 rindolf MSN/Jabber/etc.?
19:04 Tene jabber: sweeks at gurulabs.com
19:04 rindolf Tene: http://www.shlomifish.org/me/contact-me/
19:05 rindolf Tene: adding you from ShlomiFish@jabber.org
19:05 Tene great
19:05 rindolf Tene: :-)
19:06 rindolf Tene: I've registered #spark on Freenode.
19:07 * Coke ponders providing NotFound with beer credit.
19:08 dalek partcl: r691 | coke++ | trunk/ (3 files):
19:08 dalek partcl: rerun spec test, mainly to test speed for whiteknight++
19:08 dalek partcl: Looks a smidge faster.
19:08 dalek partcl: Lost one test in upvar ?!
19:08 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=691
19:08 dalek partcl: r692 | coke++ | wiki/SpecTestStatus.wiki:
19:08 dalek partcl: NotFound++ - these tests no longer segfault.
19:08 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=692
19:08 dalek partcl: r693 | coke++ | trunk/config/PARROT_VERSION:
19:08 dalek partcl: This version avoids a segfault that gets us 291 more passing tests.
19:08 dalek partcl: NotFound++
19:08 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=693
19:08 MoC joined #parrot
19:10 whiteknight NotFound has been quite the rockstar this month
19:10 * NotFound gets a copy of Guitar Hero
19:11 whiteknight NotFound *is* a guitar hero
19:12 dalek partcl: r694 | coke++ | wiki/SpecTestStatus.wiki:
19:12 dalek partcl: add a table of contents
19:12 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=694
19:20 chromatic Is the switched core faster than the fast core?
19:20 whiteknight chromatic: from what I have seen, fast core is the fastest
19:20 whiteknight makes some sense since it will be the friendliest to most branch predictors
19:21 whiteknight switch core technically has fewer instructions per dispatch, but uses an indirect jump which is horrible on the predictors.
19:21 whiteknight we're talking 100% miss rate
19:22 cotto is there a portable way to do prefetching?
19:22 whiteknight cotto: what do you mean by that?
19:24 nopaste "chromatic" at 72.87.39.97 pasted "GC Tuning Patch for Testing" (25 lines) at http://nopaste.snit.ch/17812
19:24 Coke is fast core always built?
19:24 cotto get the relevant memory into cache before it's needed so we don't get a cache miss
19:25 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.
19:25 whiteknight okay
19:27 whiteknight In fact, if we could make the total arena allocation a multiple of the system page size, that would be the best
19:28 chromatic Definitely.
19:29 Coke for partcl's "while.test" :
19:29 Coke -R fast   : real    0m52.950s
19:29 Coke <default> : real    0m55.665s
19:29 Coke 52.950/55.665
19:29 purl 0.951226084613312
19:29 Coke so, not super fast. (but every bit helps.)
19:30 moritz chromatic: timing 'make spectest' with your patch now
19:30 dalek parrot: r40973 | cotto++ | branches/pluggable_runcore/tools/dev/pprof2cg.pl:
19:30 dalek parrot: [pprof2cg] return the callgrind profile as a string and let main decide what to do with it
19:30 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40973/
19:30 chromatic 6.5% improvement on the primes.pasm benchmark with my patch.
19:30 whiteknight Coke: Because our ops are so large and complicated, there is a relatively small boost to be had by improving dispatch
19:31 whiteknight that is, most time is spent in the ops, not moving between them
19:31 Coke chromatic: on speed?
19:31 chromatic yes
19:31 whiteknight If our op set was more atomic, like Lorito is intended to be, we would see more significant differences in dispatch mechanisms
19:31 Coke (jit for while.test: real    1m19.580s
19:32 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
19:33 Coke whiteknight: a test that runs for about sixty seconds isn't long enough?
19:33 Coke (obviously not, but should we reasonably expect that to be the case?)
19:33 whiteknight Not saying it's not, just trying to provide some annotations :)
19:34 whiteknight I assume that our JIT is producing heinously un-optimized machine code
19:35 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
19:35 chromatic I'm not claiming it's a representative test, just that it's interesting.
19:36 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.
19:36 whiteknight it really shouldn't be too hard to do, I hope, and should give us really good performance gains
19:37 whiteknight well, not "really good", but nice
19:38 whiteknight after that it's all blue skies and trace-based JIT
19:41 szbalint and ponies
19:48 Tene Hmm.  I still get that weird segfault when loading rakudo from steme.
19:48 Tene it goes away when I run Parrot with -G
19:48 whiteknight solution: don't do that
19:48 whiteknight Tene: can you reproduce that segfault consistently?
19:50 Tene whiteknight: http://gist.github.com/181081
19:50 Tene whiteknight: you can get steme at http://github.com/tene/steme/
19:50 whiteknight and that small amount of code triggers a segfault consistently?
19:51 Tene Yes.
19:51 whiteknight well then
19:51 Tene Every time I've run it for the past four or five months, iirc.
19:51 whiteknight can you put this information into a ticket?
19:51 Tene I think I already have... maybe.
19:52 Tene magic-ticket-bot: Where is that ticket I posted once about something?
19:52 whiteknight Oh, I'll have to dig for it
19:52 Tene Oh, magic-ticket-bot doesn't exist yet.
19:52 Tene https://trac.parrot.org/parrot/ticket/744
19:52 Tene you can ignore the start, these days
19:52 Tene just 'make install' with rakudo
19:53 Tene You even commented on it! :)
19:54 whiteknight go me
19:55 dalek parrot: r40974 | NotFound++ | trunk/src/string/charset/unicode.c:
19:55 dalek parrot: [string] Dubious fix for an out-of-bounds string access, avoids TT #967 segfaults
19:55 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40974/
19:55 whiteknight Tene: When does it segfault? Does it print the "zzz" or not?
19:55 Tene It prints nothing.
19:56 Tene It segfaults when it tries to load_language perl6.pbc
19:56 moritz chromatic: with your GC patch Rakudo is a wee bit faster
19:56 whiteknight oh, okay
19:56 moritz (46 * 60 + 30) / (48 * 60 + 3)
19:56 purl 0.967741935483871
19:57 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
19:58 whiteknight 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.
19:58 chromatic That'll help too.
19:58 bacek joined #parrot
19:58 iblechbot joined #parrot
19:58 darbelo whiteknight: In time for the next release?
19:59 whiteknight darbelo: who knows?
19:59 purl and it's way past purl's bed time young man!
20:00 Tene whiteknight: Oh... apparently it now segfaults with Cardinal, too.
20:00 Tene it used to work with Cardinal.
20:02 whiteknight well, that's good for consistency
20:02 Tene Heh.
20:08 donaldh joined #parrot
20:10 Tene I wonder if hll interop between cardinal and rakudo still works...
20:17 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:19 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 jrtayloriv . 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.
20:19 whiteknight jrtayloriv: sure thing. I would love to see the patch
20:20 whiteknight Although I don't know when I will have time to look at it
20:20 moritz whiteknight: good idea
20:20 purl moritz: Good Idea: Playing the scales on a piano. Bad Idea: Playing the scales on a fish.
20:20 joeri joined #parrot
20:20 whiteknight moritz: I'm wondering if we can get two bare-bones toy languages that we can use for meaningful tests
20:21 whiteknight 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
20:21 whiteknight GEnerated code tests, .HLL tests, etc
20:21 whiteknight jrtayloriv: you could email me the patch
20:21 whiteknight I'll be home in about 1hr and can see it then too
20:22 jrtayloriv whiteknight, ok, will do.
20:22 whiteknight Okay, on that note I'm signing off. Later
20:24 dalek rakudo: 3db3e37 | moritz++ | build/gen_setting_pm.pl:
20:24 dalek rakudo: [build] be a bit more idiomatic in gen_setting_pm.pl
20:24 dalek rakudo: Use three-arg open(), and speed don't read line by line if we don't need that.
20:24 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​db3e37a20b08d252feeab3e4671a2d13d9eaeba
20:34 chromatic Parrot_pcc_get_context_struct() is expensive.
20:35 chromatic How about a little naughtiness?
20:36 chromatic Let's see if violating encapsulation improves things.
20:38 chromatic 11.35% performance improvement.
20:40 chromatic Heh.
20:41 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.
20:42 chromatic The *real* problem here is that *every* REG_* and CTX_REG_* macro refetches the current context.
20:42 chromatic That's a problem in some ops which refer to multiple registers.
20:42 darbelo *ouch*
20:43 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
20:43 purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
20:43 NotFound A way to always have the current context in scope in the ops may be a good solution.
20:43 chromatic Exactly what I had in mind.
20:44 chromatic First though, let's speed things up for people right now.
20:45 moritz is there a portable way to write implicit Makefile rules?
20:45 NotFound moritz: yes, using gmake in every platform X-)
20:45 moritz basically I want to write a rule that for each src/foo.pm calls a script to build build/foo.pm
20:46 moritz and I have a list of all relevant files that match src/*.pm
20:46 bacek chromatic: just "revert" r40871
20:47 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.
20:48 dalek parrot: r40975 | chromatic++ | trunk/src/call/context.c:
20:49 dalek parrot: [PCC] Made Parrot_pcc_get_context_struct() poke into the Context PMC's data
20:49 dalek parrot: member directly, rather than going through the get_pointer VTABLE.  This is a
20:49 dalek parrot: big performance improvement (11.35% in primes.pasm), but it's also not as
20:49 dalek parrot: dangerous as it sounds for two reasons:
20:49 dalek parrot:     * nothing extends the Context PMC, so it's safe for the time being
20:49 dalek parrot:     * anything that did extend the Context PMC would need a similar struct here
20:49 dalek parrot:     anyway
20:49 dalek parrot: This can be a temporary optimization until we stop extra context fetching in
20:49 dalek parrot: ops bodies.
20:49 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40975/
20:49 chromatic Let's get some performance numbers on that and see what happens.
20:51 * bacek to have "final sealed" pragmas for PMCs...
20:56 dalek parrot: r40976 | bacek++ | trunk (4 files):
20:56 dalek parrot: [cage] Remove CHUNCKED_CTX_MEMORY and Parrot_gc_context. Contexts are
20:56 dalek parrot: GCable objects now.
20:56 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40976/
20:56 dalek parrot: r40977 | bacek++ | branches/context_attrs:
20:56 dalek parrot: Branch to remove Parrot_Context structure and use ATTRibutes
20:56 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40977/
20:57 chromatic Parrot_inc_p (opcode_t *cur_opcode, Parrot_Interp interp) {
20:57 chromatic ((*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]))));
20:58 chromatic Definitely room for better macros there.
21:03 ruoso joined #parrot
21:07 bacek chromatic: it's autogenerated code.
21:14 PacoLinux joined #parrot
21:17 chromatic Yep, easy to fix.
21:17 dalek parrot: r40978 | bacek++ | branches/context_attrs/src/pmc/context.pmc:
21:17 dalek parrot: Copy Parrot_Context content as attributes into Context PMC
21:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40978/
21:18 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 #parrot
21:23 * chromatic waits for the backlog and the forehead slap
21:24 jrtayloriv Whiteknight, just sent the email a moment ago
21:25 Whiteknight w00t
21:25 jrtayloriv :)
21:25 Coke chromatic: seeing about a 4% speedup on t_tcl/while.test with recent parrot on default core, maybe 2% on fast core.
21:25 jrtayloriv Whiteknight, really, really, unfinished right now ... just warning you :)
21:27 NotFound Coke: have you looked at r40974 ?
21:28 Whiteknight jrtayloriv: I've seen worse
21:28 Whiteknight hell, I've written worse
21:28 Whiteknight :)
21:28 chromatic True.
21:28 Whiteknight !!!
21:28 Coke NotFound: saw it go by, haven't had time to recheck anything yet. will do so tonight or this weekend.
21:28 chromatic As long as you're dogging on yourself, why not?  When will I get that chance again?
21:28 Coke chromatic++ #OH SNAP
21:28 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.
21:29 Coke problem #1: asking Whiteknight for coding advice.
21:29 Coke (OH SNAP)
21:29 NotFound Coke: I'm running partcl spectest for a while and don't have any segfault yet
21:29 Coke NotFound: I don't run the segfaults in the spectest run. =-)
21:29 Whiteknight jrtayloriv: We should add an API function to src/gc/api.c that does WRITE_BARRIER stuff
21:29 NotFound Oh, forgot that :D
21:29 Coke you can run them directly with ./tclsh t_tcl/failing.test
21:29 Whiteknight so that we we can keep all the pointers private to the GC system
21:30 Coke also:
21:30 Coke http://code.google.com/p/partc​l/wiki/SpecTestStatus#segfault
21:30 GeJ_ Good morning everyone
21:30 Whiteknight jrtayloriv: so like create a Parrot_gc_write_barrier and Parrot_gc_write_barrier_key function
21:31 Coke two of those were covered by binary.test and parseExpr.test
21:31 Coke er,
21:31 Coke that TT covered those 2.
21:32 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.
21:32 Coke gotta run.
21:32 Coke NotFound++
21:32 jrtayloriv Whiteknight, i.e. the ones in the GC_Subsystem struct?
21:32 Whiteknight jrtaylor: inside the API functions we can call interp->gc_system->write_barrier() like you are doing now
21:32 Whiteknight we just don't want to give outside code access to GC data structures
21:33 jrtayloriv oh, I see.
21:33 NotFound Coke: I don't have such file
21:33 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.
21:33 Whiteknight Tene: so what is broken?
21:33 Tene Whiteknight: it's always been GC, or other weird segfaults.
21:34 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.
21:34 Whiteknight jrtayloriv: yes, it makes very much sense
21:34 pmichaud the hll interop isn't the source of the breakages, it just exposes them
21:34 pmichaud PGE has had that problem for years
21:34 Whiteknight jrtayloriv: A lot of this patch looks like fixups to the GMS core. I suggest separating that out into it's own patch
21:35 Whiteknight pmichaud: do you have any more insight about what, specifically, is causing this problem?
21:35 pmichaud no
21:35 Whiteknight Okay
21:36 nopaste "tene" at 97.117.70.208 pasted "backtrace for WhiteKnight++" (64 lines) at http://nopaste.snit.ch/17813
21:37 Tene that obj=0x1 looks very weird
21:37 Whiteknight Oh, I have seen that before, haven't I?
21:37 Whiteknight that stupid 0x01 bug
21:38 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:39 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 Whiteknight Tene: you in gdb right now?
21:40 Tene No, but it's like 2s to get back there.
21:40 Tene ok, I am now
21:40 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.
21:40 bacek Whiteknight: prove I'm wrong - we can't allocate arbitrary-size objects in current GC.
21:40 Whiteknight Tene: run back to the segfault, and print out the frame #2
21:41 Tene How do I do that?
21:41 * Tene gdb fail. >.>
21:41 Whiteknight actualy frame 1
21:41 Whiteknight Tene: "up", then "frame"
21:41 Tene it just prints the same line that's in the backtrace
21:42 Tene #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
21:42 Tene what should it do?
21:43 Whiteknight it should print out the line of code that's being executed there
21:43 Whiteknight I want to try to figure out which field in the Context struct has the bad value
21:43 pmichaud just print the context struct, see what has 0x1 ?
21:43 bacek Tene: l
21:43 Whiteknight pmichaud: good idea!
21:43 purl Whiteknight: Good Idea: Singing Christmas carols to your neighbors. Bad Idea: Singing Christmas carols to your neighbors on the Fourth of July.
21:43 bacek it's probably value of PMC register...
21:44 Whiteknight Tene: "p * (Parrot_Context*)pmc->data"
21:45 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 Tene 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}
21:45 bacek it is...
21:45 purl Oh no it isn't!
21:46 Whiteknight current_HLL?
21:46 bacek current_HLL is INTVAL
21:46 Whiteknight so it has to be one of the P or S registers then
21:47 Whiteknight so here's the millon dollar question: Who the hell is writing 0x1 to one of the P or S registers?
21:47 Whiteknight and could whoever is doing it kindly knock it the hell off
21:48 * darbelo blames gremlins.
21:48 gremlin Who cares to blame ME???
21:48 * Whiteknight feeds bacek after midnight
21:49 dalek parrot: r40979 | pmichaud++ | trunk/t/compilers/pge/perl6regex/rx_quantifiers:
21:49 dalek parrot: [pge]:  typo in test description noticed by masak++
21:49 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40979/
21:49 Whiteknight Tene: "p i"
21:49 bacek No way. It's old bug.
21:49 Tene i = 8
21:49 Tene Whiteknight: it's not current_hll
21:49 Whiteknight okay, so it's the eigth PMC register, because there are only 2 S regs and 10 P regs
21:50 Whiteknight Tene: thanks, we're past that now :)
21:50 * Tene reading fail again. :)
21:50 bacek <bacek> it's probably value of PMC register...
21:50 pmichaud ninth PMC register :)
21:50 MoC joined #parrot
21:51 pmichaud can we see the contests of regs_p ?
21:51 pmichaud *contents
21:52 Tene afk phone
21:52 Whiteknight nopaste?
21:52 purl nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/ or http://paste.scsys.co.uk (for #catalyst, #dbix-class, #moose  and others) or http://gist.github.com/ or paste or gtfo
21:52 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?
21:53 nopaste "Whiteknight" at 69.249.176.251 pasted "Patch for Tene++" (15 lines) at http://nopaste.snit.ch/17814
21:53 Whiteknight jrtayloriv: yeah, those are my first suggestions.
21:53 rindolf pmichaud: I've had lunch with someone from Tel-FOSS and he said he's using PmWiki.
21:53 Whiteknight otherwise, it's a great looking patch
21:54 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.
21:54 rindolf pmichaud: yes.
21:54 * chromatic suspects that the Context isn't really a context.
21:54 rindolf pmichaud: I kinda like MediaWiki, but its syntax is very hard to parse.
21:54 Tene Whiteknight: rebuilding...
21:54 rindolf pmichaud: and its test suite has been broken for a while.
21:54 Whiteknight chromatic: so like it's an unintialized value that's being treated as a Context?
21:55 Whiteknight that's a little harder now if they're PMCs
21:55 rindolf pmichaud: but maybe because I'm the most used to MW.
21:55 rindolf MojoMojo also looks nice.
21:55 Whiteknight because we can't even get into mark unless the PMC has a valid VTABLE
21:55 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?  ;-)
21:55 Tene Whiteknight: it runs without a problem now.
21:55 Tene whatever that means.
21:56 Whiteknight It means that we can hide the problem a lot easier then we can fix it
21:56 bacek Whiteknight: bah! Cheater!
21:56 chromatic Or it used to be a context.
21:57 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 Whiteknight but time will tell
21:58 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
21:59 Whiteknight a lot of other pointers from that context have been marked by the time we get here
22:00 nopaste "bacek" at 114.73.43.150 pasted "Epic PCC failure expose patch." (44 lines) at http://nopaste.snit.ch/17815
22:00 bacek t/op/calling................................46/94
22:00 bacek #   Failed test 'clone_key_arg'
22:00 bacek #   at t/op/calling.t line 1409.
22:00 bacek # Exited with error code: [SIGNAL 6]
22:00 bacek # Received:
22:00 bacek # src/gc/alloc_register.c:534: failed assertion 'Parrot_pcc_get_regs_used(interp, ctx, REGNO_STR) > idx'
22:00 bacek # Backtrace - Obtained 25 stack frames (max trace depth is 32).
22:00 bacek This is root of problem
22:01 Whiteknight bacek: that's this failure we're talkig about?
22:01 bacek Whiteknight: yes
22:01 Whiteknight so the register allocator is allocating too few registers?
22:01 bacek pcc accessing wrong register
22:01 darbelo Say, is anyone on i386 available to test a small patch?
22:01 Whiteknight no and no
22:01 bacek or allocating less, than required register.
22:02 bacek registers
22:02 purl well, registers is better http://www.theregister.co.uk/2005​/10/18/wikipedia_quality_problem/
22:02 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"
22:02 Whiteknight whatever that means
22:02 Tene laaaaaaame
22:02 Whiteknight that's what I said!
22:02 NotFound Object must not override assign_pmc ?
22:03 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.
22:03 chromatic My cat's breath smells like cat food.
22:03 Whiteknight our lady friends should get together and take each other out to the park, while we stay on the computer
22:04 Whiteknight okay, later
22:04 pmichaud My wife is falling asleep, which means I get to take daughter to fencing lesson
22:05 nopaste "darbelo" at 200.49.154.172 pasted "[PATCH] Kill ->strstart uses in src/jit/i386/jit_defs.c" (56 lines) at http://nopaste.snit.ch/17816
22:06 darbelo Can anyone on i386 can test http://nopaste.snit.ch/17816 check that http://nopaste.snit.ch/17816 works?
22:06 Tene sleep-fencing ftw
22:08 chromatic blib/lib/libparrot.so: undefined reference to `Parrot_str_from_cstring' darbelo
22:09 chromatic You probably meant Parrot_str_to_cstring.
22:10 chromatic 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.
22:11 chromatic make test works fine for me too.
22:12 darbelo One less strstart. A whole lot more to go!
22:13 pmichaud afk, travel
22:23 TimToady /e
22:24 nopaste "jrtayloriv" at 96.238.200.246 pasted "[PATCH]: Minor GC refactoring" (349 lines) at http://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).
22:26 jrtayloriv 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:30 darbelo (/*JT: What SHOULD we be doing here?*/) : I would put a "default" GC there, or die horribly.
22:36 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*"
22:37 darbelo but 'default' has merits too: "What? No, that's not a valid GC, let me fix that for you."
22:39 darbelo Maybe 'switch to the default and warn the user'.
22:41 rg joined #parrot
23:03 dukeleto joined #parrot
23:04 chromatic Heh.  30.565% performance improvement.
23:04 chromatic 38.446% improvement overall.
23:04 jrtayloriv jeebus ... What did you do?
23:06 chromatic Avoided multiple context fetches in op bodies.
23:06 dukeleto chromatic: yay for that
23:06 jrtayloriv Neato speedo!
23:07 dukeleto chromatic: please translate for mere mortals
23:07 cotto joined #parrot
23:07 chromatic vi src/ops/core_ops.c
23:08 chromatic Read lines 17 - 20
23:08 chromatic *every* register access would call a function to fetch the current context.
23:08 chromatic If you read four registers in an op body and assign to one, you call that function five times.
23:08 chromatic ... even if the context *does not change*.
23:09 chromatic By now, you're thinking "Hey, what if we cached..." and now you know.
23:10 dukeleto chromatic: sweet
23:11 dukeleto cur_opcode[i] all over the place
23:16 * dukeleto pours chromatic a frothy beer
23:18 chromatic More benchmarks welcome.
23:19 dalek parrot: r40980 | chromatic++ | trunk/lib/Parrot (2 files):
23:19 dalek parrot: [ops] Changed slow/fast core ops body generation to look up the current context
23:19 dalek parrot: once per body, using that within register access macros to avoid looking it up
23:19 dalek parrot: for *every* register access.  This improves the primes.pasm benchmark
23:19 dalek parrot: performance by 38.45%.
23:19 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40980/
23:21 dalek close: r99 | Austin++ | trunk/build/Makefile.in:
23:21 dalek close: Removed SymbolLookupVisitor (replaced with Resolution)
23:21 dalek close: review: http://code.google.com/p/close/source/detail?r=99
23:26 jrtayloriv chromatic, yep -- 2.08 seconds with old, 1.53 with your patch for fib.pir benchmark ... nice job!
23:27 chromatic Thanks.  How was it before the context_pmc3 merge, any notes on that?
23:31 chromatic 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).
23:31 chromatic The fast core is still 12.934% faster on the primes.pasm benchmark by avoiding that.  Interesting.
23:32 * jrtayloriv finally just took the time to learn how to check out a specific revision w/ SVN ...
23:33 jrtayloriv 50% speedup ... I'm not impressed. Why don't you shave off another 10 or 15? ;)
23:34 darbelo jrtayloriv: You can also do svn up -rWHATEVER in your working copy instead of checing aout a new one.
23:35 darbelo s/checing/checking/
23:35 dukeleto anybody know what this means: ../../parrot -o ../../runtime/parrot/library/PCT.pbc --output-pbc PCT.pir
23:35 dukeleto Invalid charset number '8' specified
23:36 jrtayloriv darbelo, thanks -- didn't know that.
23:37 szbalint fib.pir is about 25% slower for me at HEAD than at 40521 (fairly old rakudo checkout)
23:41 dukeleto is anyone else using parrot with perl 5.10.1 ?
23:41 * cotto is
23:41 chromatic szbalint, is that with r40980?
23:42 szbalint yes
23:42 chromatic Still a ways to go then.
23:43 jrtayloriv halfway there
23:43 purl i heard halfway there was closer than not at all
23:43 jrtayloriv me too purl -- now shut up before I hurt you
23:43 dukeleto purl, forget halfway there
23:43 purl dukeleto: I forgot halfway there
23:43 chromatic Hm, Parrot_gc_get_attribute_pool is more expensive than it should be.
23:44 dukeleto cotto: are you using libicu as well?
23:44 cotto yup
23:47 dukeleto cotto: well then, the world hates me
23:48 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40980 - Ubuntu 9.04 amd64 (gcc)
23:50 joeri left #parrot
23:50 joeri joined #parrot
23:50 dukeleto github is hating me now as well
23:52 chromatic Go eat worms.
23:53 nopaste "dukeleto" at 32.152.9.125 pasted "Invalid charset number '8' specified" (865 lines) at http://nopaste.snit.ch/17818
23:54 dukeleto that happens to me on a clean checkout. i am totally stumped.
23:54 dukeleto all I know is that I upgraded darwin to perl 5.10.1 last night, so that is very suspicious
23:55 darbelo dukeleto: Did you get the new perl from the same source as the previous perl?
23:56 dukeleto darbelo: i compiled from source
23:56 dukeleto darbelo: i didn't update the system perl, but I updated the perl that Configure.pl use's in my $PATH
23:57 darbelo parrot is a bit too sensitive to changes in the flags used to compile perl.
23:58 dukeleto darbelo: that scares me

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

Parrot | source cross referenced