Camelia, the Perl 6 bug

IRC log for #parrot, 2009-12-01

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:01 dukeleto 'ello
00:01 cotto_work hi allison
00:01 allison hi cotto
00:02 bacek joined #parrot
00:02 * dukeleto pours bacek a beer
00:13 Tene Any requests for parrot hacking tonight.  I think I'm inclined to move abc and squaak over to nqp-rx, if not.
00:13 cotto_work Make Parrot fast.
00:13 cotto_work That shouldn't take very long.
00:14 Tene cp /usr/bin/yes /usr/bin/parrot
00:14 chromatic Tene, any of https://trac.parrot.org/parr​ot/wiki/ClassVtableOverrides will help.
00:14 Tene There was that pir vtable override thing C asked me to do...
00:14 Tene Yeah, that.
00:14 purl Sure, that.
00:14 plobsing joined #parrot
00:15 Tene I think that's going to have to wait for a weekend, though.
00:15 chromatic None of the steps are particularly laborious in and of themselves.
00:16 chromatic One of the first is writing a small program to parse src/vtable.tbl and generate forwarding VTABLE functions.
00:17 Tene Hmm.  Okay, I'll try to take a look sooner.
00:17 Tene afk, going home.
00:18 bacek_at_work dukeleto, it's too early for beer...
00:39 japhb "too early for beer"?  That must not be English, because if it is English, it clearly makes no sense.  ;-)
00:44 dukeleto bacek_at_work: i will drink your beer then
00:49 cotto_work clock?
00:49 purl cotto_work: LAX: Mon 4:49pm PST / CHI: Mon 6:49pm CST / NYC: Mon 7:49pm EST / LON: Tue 12:49am GMT / BER: Tue 1:49am CET / IND: Tue 6:19am IST / TOK: Tue 9:49am JST / SYD: Tue 11:49am EST /
00:59 abqar joined #parrot
01:15 cognominal joined #parrot
01:27 plobsing hey, are there any tools for looking at frozen pmcs?
01:30 cotto_work You can read and dump them, but I don't think there are any existing non-trivial tools.
01:30 theory joined #parrot
01:30 cotto_work s/can/can write PIR to/
01:31 plobsing would such tools be useful to anyone (aside from myself)?
01:32 cotto_work if you build it...
01:32 plobsing if I manage to build it.
01:34 * cotto_work goes home
01:51 allison joined #parrot
01:53 * japhb decides that figuring out where to insert the UUID code into the parrot make process requires too much brain right now, and goes to watch a Christopher Eccleston movie instead
01:58 Coke japhb: ... I went to high school with a Christopher Eccleston, I think.
02:02 * Coke finally sets up ssh-agent.
02:02 Coke yay, github is no longer incredibly painful.
02:19 JimmyZ joined #parrot
03:01 bacek joined #parrot
03:27 JimmyZ joined #parrot
03:32 theory seen dukeleto
03:32 purl dukeleto was last seen on #pdx.pm 8 minutes and 57 seconds ago, saying: just found a bug!
03:34 tetragon joined #parrot
03:36 dukeleto theory: yo
03:42 KatrinaTheLamia joined #parrot
04:20 Andy joined #parrot
04:24 cotto pmichaud, ping
04:37 xenoterracide joined #parrot
05:22 bacek joined #parrot
05:57 dukeleto what is this weeks focus for development?
06:28 particle1 joined #parrot
06:42 dalek TT #1341 created by plobsing++: [PATCH] hide magic numbers in src/pmc_freeze.c with macros
06:43 cotto I'm all for hiding magic numbers in nasty code.
06:44 plobsing this is just a small start. that code needs serious work.
06:45 cotto Fvery
06:45 cotto s/F//
06:45 cotto For future reference, a more descriptive filename than "diff" would be nice.
06:46 plobsing i suppose so
06:50 cotto not a big deal, of course
06:57 dalek parrot: r42832 | cotto++ | trunk/src/pmc_freeze.c:
06:57 dalek parrot: [pmc] name some magic constants, patch courtesy of plobsing++
06:57 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42832/
06:59 dalek TT #1341 closed by cotto++: [PATCH] hide magic numbers in src/pmc_freeze.c with macros
07:09 uniejo joined #parrot
07:12 theory joined #parrot
07:36 cotto arbitrary restrictions on passwords make me angry
07:38 bacek joined #parrot
07:39 cotto hi bacek
07:39 cotto clock?
07:39 purl cotto: LAX: Mon 11:39pm PST / CHI: Tue 1:39am CST / NYC: Tue 2:39am EST / LON: Tue 7:39am GMT / BER: Tue 8:39am CET / IND: Tue 1:09pm IST / TOK: Tue 4:39pm JST / SYD: Tue 6:39pm EST /
07:44 dukeleto hola
07:46 cotto good night
07:47 dukeleto cotto: cheers!
07:47 dukeleto does parrot have something like perl's -I ?
07:47 dukeleto i guess my problem is that i am including .pir that is not installed somewhere
07:53 chromatic There should be a -I flag; isn't there?
07:54 dukeleto chromatic: look at that. there is. chromatic++
07:54 dukeleto chromatic: i have a TAP harness written in PIR cookin'
07:56 chromatic I saw.  That'll be super handy.
07:56 dukeleto chromatic: i am benchmarking it now.
07:57 dukeleto chromatic: at first glance, running the tapir test suite with itself, and then t/harness from parrot, it looks like tapir takes about 60-70% of the time
07:57 dukeleto that should make some people happy
07:57 dukeleto still not feature complete, but getting close
07:58 dukeleto dealing with exit codes properly is the last big feature that needs to be there
07:59 dukeleto is there any actually preferred format for the test summary? just emulate what Test::Harness does, by default?
07:59 chromatic Why is it faster?
07:59 dukeleto chromatic: it is written in PIR instead of Perl 5 ?
07:59 chromatic I wouldn't normally expect PIR to be notably faster than Perl 5.
08:00 dukeleto chromatic: it doesn't do nearly as much yet, and I need to benchmark it on the parrot test suite
08:00 dukeleto chromatic: for simple things, PIR is noticeably faster.
08:01 chromatic Good to know.
08:01 allison joined #parrot
08:01 dukeleto chromatic: parsing TAP can be done with amazingly few tools
08:02 dukeleto chromatic: and tapir is not optimized *at all*
08:02 chromatic True.  T::H 3.x definitely has some overengineering.
08:03 dukeleto chromatic: i looked at the implementation. it has a reasonably inheritance hierarchy that must slow it down a bit
08:03 dukeleto reasonable, even
08:03 chromatic Eric had a few rants about that.
08:04 dukeleto chromatic: also, i am not using PGE or nqp-rx to parse. Just ye old 'split' opcode
08:05 dukeleto my biggest motivations are speed and lack of dependencies other than parrot core
08:09 dukeleto chromatic: looks like tapir is just shy of twice as fast as parrot's t/harness for running the tapir test suite
08:10 dukeleto chromatic: will try parts of the parrot test suite next
08:11 iblechbot joined #parrot
08:13 dukeleto chromatic: http://gist.github.com/246158
08:14 dukeleto chromatic: i can only assume that tapir gets faster as the number of tests grows, just by how much memory has to be allocated for each test in Test::Harness
08:15 chromatic True.
08:17 chromatic $ cat ~/bin/calc_pct.pl
08:17 chromatic use Modern::Perl;
08:17 chromatic my ($before, $after) = map { tr/,//d; $_ } @ARGV;
08:17 chromatic my $diff = $before - $after;
08:17 chromatic say sprintf "%d (%.03f)", $diff, ( $diff / $before ) * 100;
08:17 chromatic Could be more useful than bc.
08:17 dukeleto chromatic: indeed
08:21 dukeleto chromatic: from calc_pct.pl, 44% faster for 62 tests in 4 files
08:22 dukeleto i think HLL's will really benefit from tapir as well
08:22 chromatic If that holds, we could get make coretest in 20 seconds.
08:22 chromatic Parallel make test in 32.
08:23 chromatic ... provided you can run tests in parallel.
08:24 dukeleto chromatic: parrallelizing across subdirectories or individual files would be interesting. has any multi-threaded app been written in PIR?
08:26 chromatic A few.
08:26 chromatic I don't think you have to do threading though.
08:26 dukeleto chromatic: yes, threading is overkill
08:26 dukeleto chromatic: which examples?
08:26 chromatic As long as you can popen an external process and not block on reading its output, you should be fine.
08:26 chromatic There are a few in t/SOMETHING/threads.t.
08:27 dukeleto chromatic: sweet
08:27 chromatic It's merely an event loop.
08:27 chromatic Launch N programs.
08:27 dukeleto a parallel tapir could be quite fast
08:27 chromatic Loop around select a few times.
08:27 chromatic Detect the ending of one program and launch another.
08:27 dukeleto chromatic: that sounds reasonable
08:28 moritz event loops - everybody should have written one!
08:28 dukeleto chromatic: is there an exception raised when a program ends?
08:28 chromatic Event loops are like DSLs in Ruby.  You already have for().  You get to choose the symbol names.
08:28 chromatic I don't know much about IO in Parrot; I can't answer that.
08:28 dukeleto moritz: i did some perl/tk and perl/gtk coding back in the day. those are my memories about event loops. and a bit of POE
08:29 chromatic I don't even know if there's waitpid.
08:29 dukeleto chromatic: yes, we have waitpid
08:29 moritz dukeleto: that roughly matches my experience
08:29 fperrad joined #parrot
08:30 dukeleto chromatic: spawnw() opcode returns the status of the waitpid system call
08:30 dukeleto chromatic: don't know if that is exactly the same
08:30 dukeleto chromatic: parrot does not seem to have a waitpid opcode or anything
08:30 chromatic It's two things.
08:31 chromatic First, figure out when a program has ended.
08:31 chromatic Second, reap that program so it doesn't stick around as a zombie.
08:31 dukeleto chromatic: do the current t/foo/threads.t tests reap as well?
08:33 chromatic waitpid() for threads is join(), so yes.
08:35 dukeleto looks like parrot does not expand ~ in -I, or at least does not correctly on darwin. feature or bug?
08:36 chromatic Unimplemented; not necessarily either.
08:36 chromatic You can argue that your shell should or shouldn't.
08:37 dukeleto chromatic: or i can ignore the problem. i choose that.
08:38 dukeleto just ran t/op/inf_nan.t on both harness' (105 tests, 1 file) and tapir is closer to 3x faster
08:38 dukeleto wait a sec
08:39 dukeleto 60% faster, almost a 1/3 of the running time, is what I meant
08:40 dukeleto this looks like it could be *quite* a speed up across the entire parrot test suite, even without -j
08:41 dukeleto i am going to finish adding features before any more benchmarking. but it looks promising
08:43 fperrad_ joined #parrot
08:50 dalek tracwiki: v20 | jimmy++ | ArrayTasklist
08:50 dalek tracwiki: change RT #56718</a> to TT <a class="new ticket" href="https://trac.parrot.org/parrot/ticket/1293" title="bug: Array PMC freeze/thaw/visit broken (new)">#1293</a>
08:50 purl dalek: that doesn't look right
08:50 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Ar​rayTasklist?version=20&amp;action=diff
08:53 JimmyZ joined #parrot
08:53 JimmyZ moritz: hello, there's a bug for irclog, see http://irclog.perlgeek.de/p​arrot/2009-12-01#i_1786528.
08:55 moritz JimmyZ: what's the bug?
08:55 purl the bug is probably http://www.cbttape.org/funny/bug3.jpg or http://img227.imageshack.us​/img227/2596/featureiu1.jpg
08:55 moritz JimmyZ: dalek reported the HTML on the channel, it's not generated by the irc logger
08:59 JimmyZ :)
09:17 dukeleto The opcode 'die_p_kic' (die<2>) was not found
09:17 dukeleto so sad :(
09:25 dukeleto is there an easy way to lower/upper case strings in PIR?
09:26 pdcawley joined #parrot
09:26 dalek parrot: r42833 | fperrad++ | trunk (7 files):
09:26 dalek parrot: [library] rename Configure.pir to Configure/genfile.pir (see TT #1279)
09:26 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42833/
09:27 moritz dukeleto: upcase $S0
09:27 dukeleto moritz: thanks! i hadn't seen that yet
09:28 * moritz looked into rakudo's sources to figure it out :-)
09:28 dukeleto moritz: how long does rakudo take to run the spec test suite these days?
09:29 moritz dukeleto: 70 minutes on two cores :/
09:30 dukeleto moritz: i might have something for you ;)
09:30 moritz *blink*
09:31 dukeleto moritz: i am working on a pure-PIR test harness, tapir. it is *fast*
09:31 moritz dukeleto: that's good. But it's not primarily the harness that's slow.
09:31 dukeleto moritz: but you have to deal with "fudging" in the spec test suite. that might make things complicated. but i could build fudging support into tapir
09:32 moritz dukeleto: no need, if you can give it a list of files
09:32 dukeleto moritz: i understand that. but you don't realize how slow Test::Harness is
09:32 moritz dukeleto: then the rakudo harness can call fudge, and call to tapir
09:33 moritz dukeleto: one more thing... remember the smoke reports
09:33 dukeleto moritz: you mean submitting to smolder?
09:33 moritz right
09:33 moritz it requires some kind of recording of the test results
09:34 dukeleto moritz: parrot needs a TAP::Harness::Archive anyway
09:35 dukeleto moritz: tapir is mainly geared for parrot first, but could be useful to rakudo down the line
09:35 dukeleto moritz: parrot and HLL's
09:36 moritz the spectest run in master executes 453 files... with a startup time of nearly 1s that's more than 7 minutes startup time
09:37 dukeleto moritz: it takes 5x longer to load Test::Harness than to load Tapir
09:37 dukeleto but Test::Harness only gets loaded once per test run
09:38 dukeleto it is mostly the overhead of internal Test::Harness data structures that makes it slow
09:39 dukeleto it is very customizable and maintainable code, but some speed was sacrificed
09:40 gaz_ joined #parrot
09:47 chromatic Fixing freeze/thaw should speed up Rakudo's starting substantially though.
09:48 moritz aye
10:04 bacek joined #parrot
10:19 riffraff joined #parrot
10:21 mikehh All tests PASS (pre/post-config, smoke (#30310), fulltest) at r42833 - Ubuntu 9.10 i386 (gcc with --optimize)
10:21 mikehh t/pmc/complex.t - TODO passed:   467 - in smoke and all cores
10:22 JimmyZ_ joined #parrot
10:22 mikehh want to check that on amd64 befor I remove that TODO
10:24 bacek o hai
10:24 dukeleto o bai
10:25 riffraff joined #parrot
10:25 bacek mikehh, can you nopaste "prove -v t/pmc/complex.t"?
10:25 * dukeleto invokes sleep
10:25 bacek I didn't expect any passed tests
10:25 bacek dukeleto, good night
10:26 * bacek cast "Sleep" to dukeleto
10:42 nopaste "mikehh" at 81.149.189.7 pasted "result of prove -v t/pmc/complex.t on Ubuntu 9.10 i386 (same with both g++/gcc with optimize)" (478 lines) at http://nopaste.snit.ch/18907
10:42 mikehh got to go out for a bit - bbl
10:57 bacek_ joined #parrot
10:58 bacek_ msg mikehh test 467 isn't passed. It's actually todoed. Check TT#1318 for explanations
10:58 purl Message for mikehh stored.
12:00 jsut joined #parrot
12:11 ruoso joined #parrot
12:14 bluescreen joined #parrot
12:25 bluescreen joined #parrot
12:28 bluescreen joined #parrot
12:54 dalek parrot: r42834 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
12:54 dalek parrot: [distutils] some refactors
12:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42834/
13:00 patspam joined #parrot
13:04 plobsing joined #parrot
13:18 dalek TT #1294 closed by doughera++: Build failure on OpenBSD 4.6 -- missing dependency?
13:28 nopaste joined #parrot
13:32 he Woohoo, have a patch for TT #1340 which makes "make smoke" pass again on my test host.
13:32 TonyC joined #parrot
13:32 Coke I am surprised at the number of non-developers on the list who have responded to my google wave invite request.
13:33 * Coke hands out invites instead of interrogating them on their contributions.
13:34 Coke ... or not.
13:34 iblechbot joined #parrot
13:34 Coke the only post I can find from this guy is "un-subscribe" to the main list in '06.
13:36 moritz seems the un-subscribe was not successfull :-)
13:41 mikehh All tests PASS (pre/post-config, smoke (#30315), fulltest) at r42834 - Ubuntu 9.10 i386 (g++ with --optimize)
13:43 fperrad seen barney
13:43 purl barney was last seen on #parrot 13 days, 5 hours, 27 minutes and 2 seconds ago, saying: Austin: glad to help  [Nov 18 08:14:52 2009]
13:45 payload joined #parrot
13:49 he BTW, patch has been attached to TT #1340
13:58 * Coke grumbles; the gui ssh-agent for os x doesn't seem to work if you're not on console.
13:59 moritz Coke: the ssh agent works with environment variables
13:59 moritz Coke: so the root process of all GUI applications has to start the ssh agent, and propagate the env variables to all child processes
14:00 moritz so it might be a question of starting it with right hook
14:00 Coke moritz: ah. this is an old screen session that I was still remoted into. moment.
14:01 Coke nope.
14:21 pmichaud good morning, #parrot
14:22 mikehh hollo
14:23 iblechbot joined #parrot
14:28 nopaste joined #parrot
14:34 pmichaud 19:28 <cotto_work> pmichaud, what's your estimate on how much Parrot's lack of a proper lvalue model slows down the code that nqp generates?
14:34 pmichaud cotto: my estimate is that it's less than 2%.
14:36 pmichaud cotto: the lack of an lvalue model makes for some really ugly code generation and lots of unnecessary operations, but in the profiling I've done it's never shown itself to be a significant source of slowdown
14:37 moritz so what *is* slow, apart from GC?
14:37 pmichaud PCC
14:38 moritz :(
14:39 dalek hq9plus: 85fe1b6 | bernhard++ | Configure.pir:
14:39 dalek hq9plus: Use Configure/genfile.pbc instead of Configure.pbc.
14:39 dalek hq9plus: review: http://github.com/bschmalhofer/hq9plus/comm​it/85fe1b61eb1511fcfc22625d9f7d9e2a1bc8dee4
14:40 patspam joined #parrot
14:43 dalek unlambda: 4e0b954 | bernhard++ | Configure.pir:
14:43 dalek unlambda: Use Configure/genfile.pbc instead of Configure.pbc.
14:43 dalek unlambda: review: http://github.com/bschmalhofer/unlambda/comm​it/4e0b954fbaf9ed17bdb5850d5cd4a88c90caf62d
14:47 Coke and hopefully lorito will ease some of the PCC work.
14:47 Coke (I think)
14:47 dalek xml: 3bf0eb4 | fperrad++ |  (2 files):
14:47 dalek xml: add manifest_includes
14:47 dalek xml: review: http://github.com/fperrad/xml/commit/3b​f0eb47e29d4d9dd66be597477ba2593fcab0fb
14:48 dalek parrot-linear-algebra: fff3a2e | (Markus Mayr)++ | src/pmc/numvector.pmc:
14:48 dalek parrot-linear-algebra: Add a vector PMC, mostly untested.
14:48 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/fff3a2e0d25fdbc04c48748424d08ac80e9999a6
14:50 * Coke wonders if he can use ARE as an example to implement globbing.
14:51 * Coke looks at the ARE code, and says "nope." =-)
14:53 pmichaud oh, I bet I can write a globber fairly quickly
14:53 particle isn't there a glob front end for pge?
14:53 dalek partcl-nqp: 1dbaf7a | (Will Coleda)++ | src/PmTcl/commands/string.pm:
14:53 dalek partcl-nqp: make [string compare]'s current special case explicit.
14:53 dalek partcl-nqp: t/cmd_string.t now runs to completion.
14:53 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/1dbaf7a4ae93531e9094435f4f492df7ff6f6bb0
14:53 pmichaud yes, but we're not using pge any more.
14:53 dalek partcl-nqp: c76b570 | (Will Coleda)++ | src/PmTcl/commands/main.pm:
14:53 dalek partcl-nqp: Add [exit]
14:53 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/c76b5705ec75c86858f6ad9aa1a15fed60686913
14:53 dalek partcl-nqp: 80a48c7 | (Will Coleda)++ | TODO:
14:53 dalek partcl-nqp: Add to the pile.
14:53 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/80a48c7c763389e95b8f4e6c04dac89488886dfe
14:53 dalek partcl-nqp: d37dec1 | (Will Coleda)++ | src/PmTcl/commands/string.pm:
14:53 dalek partcl-nqp: implement [string last]
14:53 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/d37dec186639cf60b4c3fba91ded5858d8152039
14:54 particle i know, but i'm sure it has a test suite
14:54 Coke pmichaud: as I'm going through [string] now, that'll help with [string match], anyway.
14:55 * Coke encourages particle to implement something on partcl-nqp!
14:55 Coke (It's almost all NQP)
14:56 dalek markdown: e46bda4 | fperrad++ |  (2 files):
14:56 dalek markdown: add metadata
14:56 dalek markdown: review: http://github.com/fperrad/markdown/commit​/e46bda45260ba20fb84aa91128112b941739942c
14:56 Coke pmichaud: I was thinking that the old helper getIndex() should probably be rewritten as a method on both tcllist and tclstring.
14:57 pmichaud Coke: makes sense to me
14:57 Coke (right now you have to pass in the object you wish to index, so making it a method seems to make more sense.)
14:57 pmichaud okay, I have a serious "wtf?" moment.
14:57 Coke about tcl? =-)
14:57 pmichaud about Parrot
14:57 Coke oh, that I can't help with. =-)
14:57 pmichaud let me put together the full example.
14:58 pmichaud will take a bit
15:01 pmichaud did someone say that nopaste.snit.ch is down?
15:01 pmichaud oh, it's up
15:01 pmichaud (ISP fail here today)
15:02 nopaste "pmichaud" at 66.25.4.52 pasted "parrot/nqp huh?!?" (29 lines) at http://nopaste.snit.ch/18908
15:03 Coke I presume the wtf is that running the nqp takes twice as along as the compilation to PIR /plus/ running the PIR?
15:03 pmichaud right.
15:04 pmichaud the whole is 2x greater than the sum of its its parts
15:04 Coke I can only assume the whole is loading some other part.
15:04 pmichaud I can't imagine what it would be.... unless   compreg "PIR" is somehow that much slower.
15:04 Coke oh, it's slow. =-)
15:05 Coke I don't know that it is /much/ slower, but it ain't fast.
15:05 pmichaud I can imagine "slow."   I can't imagine   "that slow"
15:05 Coke well, that's easy to test, anyway.
15:05 pmichaud it's not like the resulting .pir is that big
15:05 pmichaud right, testing now.
15:06 pmichaud omg
15:06 Coke as good a hypothesis as anything (and would explain why partcl was such a dog.)
15:06 pmichaud I wonder if the internal PIR compiler is slow on utf8-encoded strings.
15:07 moritz Coke: you speak if partcl in the past tense... have you abandoned it in favour of the nqp based thing?
15:07 Coke pmichaud: hurm. my previous incarnation of index parsing included a rule in the grammar to parse a few different cases. I should probably continue to use that.
15:07 Coke moritz: presuming the nqp-based version can be brought up to where the old pir-based version was, yes.
15:07 Coke so, jump on in!
15:08 pmichaud Coke: that works, although nqp should be getting native regexes rsn
15:08 pmichaud i.e. -- ability to match against a regex that is in the source and not in the grammar
15:08 Coke pmichaud: oooh
15:08 Coke ok, I'll hold off. plenty of other stuff to do. =-)
15:08 pmichaud I'll bump that up a notch, then.
15:09 pmichaud I finally figured out how to deal with parrot not being able to distinguish regex subs from normal subs
15:09 Coke how?
15:09 pmichaud the regex library will have a class of objects that will wrap regex subs
15:09 pmichaud since regex subs aren't invoked directly but always through an api, I can do the unwrapping then.
15:10 Coke we might need something similar for tcl procs, as we have to store metadata about them that parrot doesn't allow for.
15:10 pmichaud (at the nqp-level, at least.)
15:10 Coke (in partcl, I just subclassed .Sub for that.)
15:10 pmichaud Coke: how about properties?
15:10 Coke pmichaud: that works. I did the subclass so I could use attributes.
15:11 Coke but as long as I can cram arbitrary properties on something, sure.
15:11 pmichaud Coke: ...and then how did you rebless the compiled subs into your subclass?
15:11 Coke pmichaud: moment.
15:12 Coke http://github.com/partcl/partcl/blo​b/master/src/class/tclproc.pir#L217
15:12 Coke the first line highlighted is invoking the pir compreg.
15:13 Coke (all this metadata is needed for [info])
15:13 pmichaud ah, you did an assign.
15:13 pmichaud I like that approach... it might work out much better than what I was thinking.
15:13 Coke Good luck. =-)
15:21 Coke not to keep changing topics, but any idea what's causing that lexical error message on t/cmd_for.t?
15:22 Coke (it is happening after the 'command_line' invocation in :main)
15:23 Coke (I'm assuming it's a leftover EH that was never popped)
15:30 bubaflub joined #parrot
15:32 lucian joined #parrot
15:33 Andy joined #parrot
15:34 dalek partcl-nqp: 606f07c | (Will Coleda)++ | src/PmTcl.pir:
15:34 dalek partcl-nqp: Document workaround due to parrot bug.
15:34 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/606f07cbab3ed79e877906889d303701560ad041
15:39 dalek partcl-nqp: 304f7be | (Will Coleda)++ |  (3 files):
15:39 dalek partcl-nqp: Add [namespace] stub.
15:39 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/304f7be5abd36e97cf82bef9c56eddd793614e81
15:42 pmichaud I'll look at cmd_for.t in a bit
15:48 Coke pmichaud++
15:48 pmichaud I want to find that execution cost
15:49 dalek nqp-rx: 2665b51 | duff++ | src/NQP/Actions.pm:
15:49 dalek nqp-rx: [nqp] simplify statement modifier logic slightly
15:49 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/2​665b51b6fc7c8ef9fcca32cb75ee8ef6d18c45c
15:51 dalek partcl-nqp: 4f7222d | (Will Coleda)++ | src/PmTcl/commands/namespace.pm:
15:51 dalek partcl-nqp: Replace harcoded bad command name with actual bad command.
15:51 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/4f7222d191a46a6f8d7da83d98ce8c4aaba6fe8c
15:51 dalek partcl-nqp: 30b236f | (Will Coleda)++ |  (3 files):
15:51 dalek partcl-nqp: add stub for [info]
15:51 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/30b236f07b4bc882bd23ea8ff78a40c07f621a02
15:55 Psyche^ joined #parrot
16:01 Coke pmichaud: any reason why the lex pad initialization in PmTcl.pir couldn't be moved into a .pm file's INIT block?
16:02 nopaste "pmichaud" at 66.25.4.52 pasted "updated timings for fib.nqp benchmark, with and without -G" (40 lines) at http://nopaste.snit.ch/18909
16:02 Coke (I'm trying to add some nqp-level initialization (setting some %GLOBALS), and it doesn't seem to be working.
16:03 nopaste "coke" at 72.228.52.192 pasted "this is invoked, but [puts $tcl_version] outputs empty string." (6 lines) at http://nopaste.snit.ch/18910
16:04 pmichaud Coke: --that's because %GLOBALS is later overwritten by 'main'
16:04 Coke figured. so i could put the global/main lexpad setup into that INIT block?
16:04 pmichaud you could initialize %GLBOALS in the same INIT block, yes.
16:05 Coke k. let me see if I can figure out that syntax.
16:07 dalek unlambda: 95026a8 | bernhard++ |  (7 files):
16:07 dalek unlambda: Use setup.pir instead of Configure.pir.
16:07 dalek unlambda: review: http://github.com/bschmalhofer/unlambda/comm​it/95026a81e2b2f312318178aa99fdec5e06bc9c37
16:07 dalek unlambda: 0724443 | bernhard++ |  (2 files):
16:07 dalek unlambda: Parrot::Config wasn't used, so don't load it.
16:07 dalek unlambda: review: http://github.com/bschmalhofer/unlambda/comm​it/072444393c7cda1e49585bd4cca801aa2557884f
16:08 payload joined #parrot
16:08 Coke pmichaud: does NQP understand "new" ?
16:08 Coke oh. whoops.
16:08 pmichaud it's newpad in this case :-)
16:09 Coke i was doing "new Foo", not "Foo.new"
16:09 Coke (and then taking on the newpad, yes.)
16:09 pmichaud in this case I think it's   TclLexPad.newpad
16:09 Coke not TclLexPad.new.newpad ? ok.
16:09 pmichaud right
16:09 pmichaud note that the original has no "new"
16:10 Coke "null pmc access in find_method "newpad".. bah, probably hasn't created the lexpad yet.
16:13 nopaste "coke" at 72.228.52.192 pasted "ok, what's wrong with this naive version? =-)" (9 lines) at http://nopaste.snit.ch/18911
16:14 Coke I removed it from the INIT block so that the TclLexPad was created first.
16:14 Coke but I'm not sure that's a faithful translation.
16:20 Coke ... (after doing a realclean, I'm not getting the error with INIT anymore. odd.)
16:21 nopaste "coke" at 72.228.52.192 pasted "this looks slightly better to me, but "set a 3" still dies with Null PMC access in get_pmc_keyed()" (12 lines) at http://nopaste.snit.ch/18912
16:24 Coke looking at the generated code, the line where I assign %GLOBALS doesn't seem to do what I think it should.
16:31 Coke ok. even if I move that lexpad setup into a Q:PIR block in init.pm, I still get the null pmc error later using set.
16:33 Coke ... I think because of the lexicals. if I move that lexical definition elsewhere, it's not available to the commandline() invocation, is it?
16:34 Coke guess I need to put this in as an explicit init() call after the lexical but before the commandline.
16:40 Coke yay, fixed.
16:40 ascent joined #parrot
16:45 pmichaud correct -- if we move the lexical definition elsewhere, then called functions can't see it in their global scope
16:45 pmichaud it can be done from the init block if you wish -- I'lll refactor it if so
16:45 Coke I figured the less PIR the better.
16:45 Coke *figure
16:45 pmichaud I agree.
16:45 Coke so if you want to clean that up, by all means.
16:46 Coke (pushed)
16:47 Coke is there a way in NQP to refer to a namespace outside of your HLL?
16:48 pmichaud not outside of pir:: or Q:PIR yet
16:48 Coke (i'm using module _tcl { ... } in a few places but that's inside the tcl hll, which is one level too low.
16:48 pmichaud I need a syntax for it
16:48 dalek partcl-nqp: 31d4a5d | (Will Coleda)++ |  (4 files):
16:48 dalek partcl-nqp: Add an NQP-based init section, set some globals used by [info]
16:48 dalek partcl-nqp: review: http://github.com/partcl/partcl-nqp/commit​/31d4a5df8ceed905519de5b4bf8a94b2bbc9edbe
16:48 Coke I was going to vote for having ::parrot magically refer to the top level parrot NS.
16:48 pmichaud it may end up being   Foo::Bar:from<perl6>
16:49 pmichaud so then the top level parrot NS would end up being   GLOBAL:from<parrot>   or something like that
16:49 pmichaud just trying to remain p6-compatible, mainly
16:49 Coke ayup
16:50 Coke as long as there's a way to do it.
16:50 dalek wmlscript: 705eba0 | fperrad++ | t/pmc/ (10 files):
16:50 dalek wmlscript: chmod +x *.t
16:50 dalek wmlscript: review: http://github.com/fperrad/wmlscript/commit​/705eba05fba48493fd9d3462d73234aca1d19e4d
16:50 dalek wmlscript: 4143db8 | fperrad++ |  (2 files):
16:50 dalek wmlscript: add manifest_includes & manifest_excludes
16:50 dalek wmlscript: review: http://github.com/fperrad/wmlscript/commit​/4143db84989963314b932f3bfc404846a69509a9
16:54 Coke pmichaud: is there a way to use pasm constants in NQP?
16:55 Coke (ala   config = interp[.IGLOBALS_CONFIG_HASH]
16:55 pmichaud Coke: not at present.  Is there a way to look them up at runtime in PIR?
16:55 Coke I just do an .include of the file that defines them.
16:55 Coke I can't iterate over them, no.
16:55 pmichaud right.... but NQP isn't so lucky there.
16:57 pmichaud sounds like NQP might need a module or something for parsing the .pasm files
16:58 pmichaud or for embedding .include into the source and then emitting the constant
16:58 pmichaud probably means that PAST::Val needs a way of registering constants, though.
16:59 * pmichaud starts writing his parrot-dev post about gc effects on runtime
17:00 Coke 3/17
17:00 purl 0.176470588235294
17:01 dalek parrot: r42835 | pmichaud++ | trunk/compilers/pct/src/PCT/HLLCompiler.pir:
17:01 dalek parrot: [pct]:  Add a simple --stagestats option to PCT::HLLCompiler.
17:01 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42835/
17:11 theory joined #parrot
17:19 theory_ joined #parrot
17:20 dalek lua: 6ad653d | fperrad++ |  (2 files):
17:20 dalek lua: add manifest_includes & manifest_excludes
17:20 dalek lua: review: http://github.com/fperrad/lua/commit/6a​d653db84769ce44d110a93c082e142fff179cc
17:34 dalek parrot: r42836 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
17:34 dalek parrot: [distuils] add _clean_smoke
17:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42836/
17:36 nopaste joined #parrot
17:43 dalek lazy-k: 233331d | bernhard++ |  (9 files):
17:43 dalek lazy-k: Use setup.pir for Lazy K with an installed parrot.
17:43 dalek lazy-k: review: http://github.com/bschmalhofer/lazy-k/commi​t/233331d43b4e4211cbe63086518e9e7a5384d29e
17:48 brrant joined #parrot
17:55 mtk1 joined #parrot
17:55 mtk1 left #parrot
17:55 chromatic joined #parrot
17:55 Coke chromatic: hio
17:58 chromatic morning
17:58 cotto_work ni
17:59 cotto_work hi
18:03 nopaste joined #parrot
18:04 cotto_work #ps in 26
18:07 barney joined #parrot
18:16 pmichaud cotto_work: looks like the cost of the extra fetch opcodes might be closer to 4%
18:17 pmichaud I'm not sure how much of that can actually be achieved though.  And find_lex is probably a lot more expensive than it needs to be.
18:19 cotto_work That's still pretty lightweight.  I'm working on the profile of a long-running nqp process.  It'll be interesting to see how that looks.
18:20 dalek parrot: r42837 | coke++ | trunk/src/ops/var.ops:
18:20 dalek parrot: grammar updates
18:20 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42837/
18:21 Coke looks like the docs for find_lex lie; it's not basing the decision to throw an exception on the pmc.
18:22 Coke (or rather, that's not the only time an error is thrown)
18:23 pmichaud cotto_work: it appears our big problem is gc (see my latest to parrot-dev)
18:24 cotto_work yup.  I'm verifying atm.
18:25 pmichaud I was completely shocked by that result.  I only stumbled across it while researching the answer to your "how much does it cost..." question :)
18:25 cotto_work That's a good reinforcement of chromatic's results.
18:26 pmichaud indeed, but I'm completely stunned that such a small source program could have that much impact.
18:27 moritz I don't understand the difference... is keeping around those objects from these trees so expensive, because every GC run has to consider them?
18:27 pmichaud moritz: yes, it appears so.
18:28 pmichaud there's also the cost of the objects created by loading nqp.pbc, past.pbc, etc.
18:28 pmichaud but I suspect the source tree will ultimately be the overriding factor
18:33 nopaste joined #parrot
18:34 Coke chromatic: how short lived? short enough that we can delete them ourselves?
18:34 Coke (re: email)
18:37 pmichaud #ps in -6 ?
18:37 pmichaud er, -7 ?
18:37 chromatic That depends on how complex our control flow is.
18:40 pmichaud how does one force a gc run ?
18:40 brrant joined #parrot
18:41 pmichaud (in PIR)
18:41 particle sweep 1; collect 1;
18:41 mikehh joined #parrot
18:42 pmichaud collect doesn't take an argument -- I'm guessing it's just "collect"
18:43 particle ah, yes.
18:44 particle 'sweep' 1 runs mark and sweep, 'collect' compacts.
18:46 * Coke thanks dukeleto for the obligatory "oh, and other HLLs!" mention. :P
18:51 Coke dukeleto: http://pivotallabs.com/users/colin/blo​g/articles/844-kcachegrind-os-x-10-5-6
18:51 Coke wonder if that helps. :|
18:52 Topic for #parrotis now Parrot 1.8.0 Zygodactyly released | Priority: https://trac.parrot.org/parr​ot/wiki/ClassVtableOverrides | Latest modified TT's: http://icanhaz.com/parrotbugs | Parrot Languages: http://icanhaz.com/parrotlang
18:52 dukeleto Coke: i will take a look, thanks!
18:53 pmichaud http://nopaste.snit.ch/18913   #  I don't think sweep 1/collect is doing a GC run...
18:55 chromatic collect doesn't, for some reason.
18:56 chromatic The 'run_gc' method on the Interpreter PMC does, though.
18:58 pmichaud so,  $P0 = getinterp;  $P0.'run_gc'()   ?
18:58 * pmichaud tries that
18:58 chromatic That's the one.
18:59 pmichaud still bizarre (nopaste soming)
18:59 particle how confusing.
18:59 pmichaud *coming
19:01 pmichaud http://nopaste.snit.ch/18914   # still not sure a gc run is happening here
19:02 chromatic What would you expect to see if it were?
19:02 pmichaud a much larger amount of time
19:02 mikehh joined #parrot
19:03 pmichaud according to the times there, the gc run at the beginning accounts for only 0.014 sec
19:03 pmichaud and that should be our most expensive gc run if we're cleaning up all of the PCC headers from copmilation
19:03 pmichaud but if a gc run only requires 0.014 sec
19:03 chromatic Hm, it doesn't look like it calls finalize in the GC.
19:04 pmichaud then that means the 10-second difference we're seeing would be the result of (10/0.014) gc runs
19:04 Coke (I wonder if the problem is in interpreter exit)
19:04 pmichaud Coke: no, because the final time is output before interpreter exit
19:04 chromatic pmichaud, add to src/pmc/interpreter.pmc Parrot_gc_finalize(interp) on line 798.
19:04 Coke pmichaud: and does that match up with ./time ?
19:04 chromatic also, there's a question in #ps for you.
19:05 Coke er, "time ./parr..."
19:05 pmichaud Coke: it does
19:05 Coke k
19:05 iblechbot joined #parrot
19:07 pmichaud chromatic: no difference (nopaste coming)
19:08 ruoso joined #parrot
19:08 pmichaud http://nopaste.snit.ch/18915   # still still not sure a gc run is happening here
19:09 ingy joined #parrot
19:10 particle pmichaud: use printf!
19:10 chromatic I can't imagine any reason why it wouldn't, unless my typo is that interp should be PMC_interp(SELF) (which won't make a difference unless you're using kid interps).
19:10 pmichaud anyway, assuming that a gc run is taking place there, the upper-bound cost of a gc run would seem to be 0.014 seconds.  (It's actually much less because we have the PCCMETHOD overhead in this version )
19:11 pmichaud which means that the fibonacci code itself is requiring 700+ GC runs... plausible.
19:11 nopaste joined #parrot
19:11 pmichaud the point I'm trying to get to is to refute chromatic's last message that it's the PCC objects causing the slowdown, though.
19:12 PerlJam pmichaud: Have you tried plotting the time as a function of $N ?   That might tell you something interesting.
19:13 chromatic If you want to refute my supposition, profile and see how many PMCs and STRINGs get created and where.
19:13 pmichaud the gc run at the beginning should be clearing out any PCC objects left over from the compilation process, leaving only the long-lived data structures
19:13 pmichaud so the only remaining pcc objects would be those generated by running the code itself, which ought to be the same in both the .pir and .nqp versions
19:14 pmichaud however, we still see that execution of the .nqp version requires ~20 seconds, while execution of the .pir takes <10 sec
19:14 chromatic We need to profile both versions then.
19:15 pmichaud I'm still very non-expert with the profiler at the moment, though.
19:15 chromatic Callgrind-wise, I mean.
19:16 pmichaud I'm a non-expert with that, too.  :0|
19:17 pmichaud anyway, I'll post these latest items to the mailing list and people can build from them.
19:17 chromatic Sure, I can profile them.
19:25 dukeleto that felt like a productive meeting
19:27 bacek joined #parrot
19:28 Util dukeleto: I would be interested in any success you have with kcachegrind on OS X 10.5
19:28 pmichaud oh, crap.
19:28 davidfetter joined #parrot
19:29 pmichaud Houston, I think we have a serious problem.
19:29 chromatic Houston *is* a serious problem.
19:30 pmichaud That also.
19:31 pmichaud Let's assume we're calling a sub.  The sub does its thing, and exits.  When does the context for that sub's execution get freed?
19:31 chromatic When it's unreachable.
19:31 pmichaud when does it become unreachable?  the sub still has a reference to it.
19:32 chromatic The Sub PMC or something else?
19:32 pmichaud the Sub PMC, iirc
19:32 chromatic That doesn't sound right.
19:33 pmichaud it would become unreachable the next time the Sub is invoked (when the sub gets a new context attached to it)
19:33 chromatic That *really* doesn't sound right.  Recursion works.
19:33 pmichaud oh sure, that's no problem
19:33 pmichaud it doesn't affect recursion
19:33 chromatic If it doesn't affect recursion, where's the problem?
19:34 pmichaud the problem is that every sub keeps its last context alive
19:34 pmichaud via its *ctx attribute
19:34 pmichaud and since that last context is alive, all of that context's callers are alive
19:34 pmichaud and all of the outers are alive
19:34 pmichaud (via their respective pointers as well)
19:35 chromatic If that chain gets marked.
19:35 chromatic <cue lingering horror>
19:35 pmichaud surely the sub gets marked, yes?
19:35 chromatic and the sub marks its context.
19:35 pmichaud Parrot_gc_mark_PMC_alive(interp, sub->ctx);
19:36 pmichaud so, this would mean that all of the methods and subs that got called during compilation are holding pointers to their contexts
19:36 chromatic Looks that way.
19:36 pmichaud still, I'm not sure this completely accounts for it, unless some of those objects are Capture PMCs (referring to your earlier analysis of a couple of weeks ago)
19:37 dalek tracwiki: v116 | barney++ | Languages
19:37 dalek tracwiki: Lazy K works on Parrot 1.8.0
19:37 dalek tracwiki: https://trac.parrot.org/parrot/wiki/L​anguages?version=116&amp;action=diff
19:37 chromatic It's not that the Capture PMC is particularly expensive to mark.
19:37 chromatic Merely that for that particular GC profile, it happened that kcachegrind's cycle detection picked a cycle starting with Capture's mark.
19:37 pmichaud okay.
19:38 chromatic If it happens to be a parent of a Continuation somewhere, it'll look expensive, inclusive-wise.
19:38 chromatic A different workload would fill up a GCable pool at a different point.
19:38 pmichaud anyway, our notion of "long-lived PMC" has to include these context PMCs that hang around after a sub has been invoked
19:38 pmichaud (and all of the objects they reference)
19:39 pmichaud s/has been invoked/has exited/  # more precise
19:39 chromatic We can't have Sub PMCs pointing to contexts, in other words.
19:39 pmichaud we have to, though, for lexicals.
19:40 pmichaud what I think we need is a way for a Sub to release its ->ctx when its return continuation is invoked
19:40 pmichaud or when it's otherwise marked as "exiting"
19:41 pmichaud (which gets back to my earlier comments about needing improvement to Sub exit semantics)
19:41 chromatic When invoking a RetCont, for example.
19:44 pmichaud so yes, I'll agree that PCC structures are adding to the load, at least to the extent that they've become long-lived structures
19:45 pmichaud (if a sub is invoked 1000 times, though, its only its last set of pcc structures that get preserved, so it's not the 1000 structures that are the load, unless something else is holding pointers to them)
19:45 chromatic Right.
19:46 pmichaud and the new nqp doesn't use coroutines, so there shouldn't be a lot of those lying about
19:46 chromatic I'm testing invalidation in RetCont.
19:47 pmichaud make sure that sub->ctx is cleared only if the RetCont is the current sub->ctx
19:47 pmichaud (because of recursion and lexical capture)
19:48 chromatic Already caught that case.
19:48 pmichaud chromatic++
19:48 pmichaud I need lunch here... I'll see about summarizing further later.
19:49 pmichaud it's becoming a complex analysis :-(
19:52 xenoterracide joined #parrot
19:52 chromatic The expensive calls from Sub's mark() seem to be namespace_name and outer_sub.
19:57 zostay joined #parrot
20:02 bubaflub does parrot have a similar flag like -d on perl
20:02 bubaflub i.e. parrot -d blah-blah.pir
20:02 bubaflub to run it line by line
20:03 dukeleto bubaflub: -v tells you extra stuff
20:03 dukeleto bubaflub: not quite what you want
20:04 dukeleto bubaflub: you can use the parrot_debugger
20:04 dukeleto bubaflub: beware, breakpoints probably don't work
20:04 bubaflub yikes
20:04 bubaflub yeah
20:04 bubaflub it exploded
20:04 bubaflub hmmm
20:05 dukeleto bubaflub: use the "t" debugger command to trace one line
20:05 dukeleto trace = execute and print source
20:05 dukeleto bubaflub: nopaste?
20:05 purl nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels)  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 or tools/dev/nopaste.pl or https://trac.parrot.org/parrot/br​owser/trunk/tools/dev/nopaste.pl
20:05 bubaflub ah, yeah
20:05 bubaflub let me poke at it a bit longer
20:06 cotto_work left #parrot
20:06 dukeleto bubaflub: have fun. the debugger can be helpful, but she is a harsh mistress
20:07 cotto_work joined #parrot
20:20 pdcawley joined #parrot
20:27 bacek Good morning
20:29 cotto_work hi bacek
20:30 bacek cotto_work, hio!
20:32 tewk joined #parrot
20:34 joeri joined #parrot
20:36 * dukeleto pours bacek a scotch
20:37 dukeleto ENOBACEKINPARROTSKETCH
20:37 cotto_work clock?
20:37 purl cotto_work: LAX: Tue 12:37pm PST / CHI: Tue 2:37pm CST / NYC: Tue 3:37pm EST / LON: Tue 8:37pm GMT / BER: Tue 9:37pm CET / IND: Wed 2:07am IST / TOK: Wed 5:37am JST / SYD: Wed 7:37am EST /
20:37 cotto_work He's a slacker like that, refusing to get up at 0530 for #ps.
20:38 bacek dukeleto, it's too early for scotch and parrotsketch :)
20:38 dukeleto bacek: what is the name of the branch with your callsig/context merge?
20:38 dukeleto bacek: and is it feasible to get merged in before 1.9.0 ?
20:39 bacek dukeleto, context_unify
20:39 bacek dukeleto, no, it's not ready. And I don't have much time for it...
20:40 bacek dukeleto, and I choose wrong approach in this branch...
20:41 cotto_work now you know a way not to do it
20:41 chromatic What's the right approach?
20:41 purl the right approach is to utilize the GPU for things it's good at.
20:41 mikehh joined #parrot
20:41 bluescreen joined #parrot
20:42 bacek 1. build_sigobject should create new CallContext
20:42 bacek 2. Sub.invoke should get CallContext from CURRENT_CONTEXT
20:42 bacek 3. ... allocate registers in it
20:42 bacek 4. Set it as CURRENT_CONTEXT
20:43 bacek It's about few days work.
20:44 bacek (And I think it's better to start from scratch)
20:44 chromatic Did you create any new PMCs?
20:44 dukeleto bacek: i am all for you rm'ing context_unify and doing it right. we would really appreciate getting it in before 1.9.0 . are there any tests that I can help write?
20:45 bacek chromatic, I just merged Context and CallSignature
20:45 bubaflub left #parrot
20:45 Coke purl, forget the right approach
20:45 purl Coke: I forgot right approach
20:45 bacek dukeleto, there is enough tests afaiu
20:46 chromatic Is that CallContext?
20:46 bacek chromatic, yes
20:46 dukeleto i am interested to see how CallContext affects gc performance
20:47 bacek dukeleto, it will create 25% less PMCs
20:47 bacek in other words - not much. Without generational GC we are doomed.
20:48 bacek (about GC) http://irclog.perlgeek.de/p​arrot/2009-09-09#i_1486986
20:51 dalek parrot: r42838 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
20:51 dalek parrot: [distutils] modify the semantic of manifest_includes & manifest_excludes
20:51 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42838/
20:51 mikehh joined #parrot
20:51 dukeleto how long will it take to write a small POC optional generational GC ?
20:52 Tene dukeleto: whiteknight would be able to give you the best estimate there.
20:53 bacek dukeleto, I will say 2 weeks full time job.
20:53 bacek Or we can try to borrow GC from other project. Like Apache Harmony
20:53 Coke (borrow+++++++++++++++++++++++​++++++++++++++++++++++++++++)
20:53 darbelo joined #parrot
20:53 chromatic I don't think borrowing will be any faster.
20:53 Coke to implement or at runtime?
20:54 bacek chromatic, It will not. But it will help with proper encapsulation of GC in Parrot.
20:54 Coke and if the time comes from a tradeoff between making the API fit vs. implementing GC code, I say the time is better spent on the API matchup.
20:55 Coke but, IANABCP
20:55 Coke er, GCP!
20:55 dalek lua: 88ca3b8 | fperrad++ | setup.pir:
20:55 dalek lua: compatible with r42838
20:55 dalek lua: review: http://github.com/fperrad/lua/commit/88​ca3b80ffd81795c67b26bf27e668dddff4abd0
20:56 tewk GC tend to be closely coupled to VM implementation details, for performance reasons.
20:57 tewk borrowing raw code is hard, borrowing implementation tatics and ideas works very well.
20:57 dalek wmlscript: 460eba8 | fperrad++ | setup.pir:
20:57 dalek wmlscript: compatible with r42838
20:57 dalek wmlscript: review: http://github.com/fperrad/wmlscript/commit​/460eba8bfdbdddc4fcdc24cbaf448148d086619a
20:57 chromatic I annotated the GC to see what gets destroyed when.
20:57 mikehh joined #parrot
20:57 dukeleto tewk++ # let's borrow tactics and API designs
21:12 chromatic Grr, Parrot dev bounces.
21:15 Coke ?
21:16 Coke ah, there it is. moment.
21:16 Coke Message body is too big: 45064 bytes with a limit of 40 KB
21:16 purl Message for body stored.
21:17 body messages
21:17 body ;)
21:18 * Coke doubles the size limit for the list.
21:18 * bacek sending "Enlarge your size" mail to Coke
21:19 mikehh joined #parrot
21:19 * Coke gets a "cool beans" overview from someone on #tcl
21:20 Coke most positive conversation I've had in there in six year.s =-)
21:21 * Coke trolls for more contributors to partcl-nqp!
21:24 mikehh joined #parrot
21:26 nopaste joined #parrot
21:29 bacek ok, almost $dayjob time
21:29 bacek chromatic, I'll merge CS and CSR tonight. It's couple of hours job.
21:30 chromatic Excellent, thank you.
21:33 brrant joined #parrot
21:38 nopaste joined #parrot
21:51 TonyC joined #parrot
21:58 nopaste joined #parrot
22:09 redbrain joined #parrot
22:19 lucian joined #parrot
22:40 cotto_work looks like there's an unexpectedly passing test in t/pmc/complex.t
22:45 dukeleto cotto_work: it is platform-specific, i think
22:46 cotto_work that's a distinct possibility
22:47 dalek parrot: r42839 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
22:47 dalek parrot: [distutils] partial revert of r42838. Restore the previous semantic.
22:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42839/
22:49 dukeleto cotto_work: there may be a TT for it
22:54 dalek wmlscript: 0795343 | fperrad++ | setup.pir:
22:54 dalek wmlscript: restore previous semantic
22:54 dalek wmlscript: review: http://github.com/fperrad/wmlscript/commit​/0795343b0c875e65e4b2ad76ca0f27d5296c295d
22:54 dalek lua: 31e3d8b | fperrad++ | setup.pir:
22:54 dalek lua: restore previous semantic
22:54 dalek lua: review: http://github.com/fperrad/lua/commit/31​e3d8b99f2b031506c15d7dfd3056d72b4af7ff
22:58 nopaste joined #parrot
23:04 dalek parrot: r42840 | fperrad++ | trunk/tools/dev/mk_language_shell.pl:
23:04 dalek parrot: [languages] fix shebang
23:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42840/
23:05 TonyC joined #parrot
23:15 * cotto_work tries to figure out how chromatic got those results
23:16 chromatic cg ./parrot ext/nqp-rx/nqp-rx.pbc fib4.nqp
23:16 chromatic cg ./parrot fib4.pir
23:17 japhb His keyboard has a 'results' key, clearly
23:17 chromatic alias cg='time valgrind --tool=callgrind --dump-instr=yes --trace-jump=yes'
23:17 cotto_work your alias for cg is just valgrind --tool=callgrind with some callgrind-specific options, right?
23:17 chromatic It also has time traveling, to answer questions before you ask.
23:18 cotto_work nice feature
23:18 purl nice feature is that you can get a SunPCI card to run Windows natively within the workstation itself.  So it's virtually a Sun WS and a nice gaming PC
23:22 cotto_work For me nqp fib takes about 12.5x longer and 4.7x more instructions than the pir version on examples/benchmark/fib.pir, using n=26.  It's puzzling that the results would be so different.
23:25 cotto_work s/ on / in /
23:25 pmichaud chromatic: in your message, why fib(26) instead of fib(28) ?
23:26 pmichaud also, why does only one timestamp appear before the output, instead of two?
23:26 chromatic To make callgrind faster, for the first question.
23:26 chromatic I removed the GC run for the second.
23:26 pmichaud okay.
23:26 pmichaud I can try with $N=26 on my system, for comparison.
23:26 pmichaud just a sec.
23:27 TonyC joined #parrot
23:29 pmichaud http://nopaste.snit.ch/18916  # fib.nqp benchmark for $N := 26, with times
23:30 chromatic 64-bit or 32?
23:30 pmichaud 64 bit
23:30 pmichaud but I think I may be running unoptimized parrot
23:31 japhb pmichaud, you're using the fakecutable, and chromatic is using the PBC ... could that have any effect?
23:31 pmichaud japhb: it didn't have any measurable difference when I tried earlier
23:31 japhb pmichaud, OK, fair enough
23:31 cotto_work I'm running optimized.
23:31 pmichaud $ time ./parrot runtime/parrot/library/nqp-rx.pbc fib-5.nqp
23:31 pmichaud 1259710297.79801
23:31 pmichaud fib(26) = 121393
23:31 pmichaud 1259710305.70347
23:31 pmichaud real0m8.178s
23:32 pmichaud .pbc doesn't seem to make a difference.
23:32 japhb I'd love to see how yours changes with an optimized parrot (though I'm surprised you aren't -- I thought you changed the --gen-parrot default to --optimize some weeks ago)
23:32 pmichaud japhb: I thought I did so also... but I can't find it now
23:32 japhb For rakudo only maybe?
23:32 pmichaud it's possible
23:32 pmichaud and apparently only for rakudo master, as it's not that way in ng
23:33 pmichaud oh, it's --optimize in ng
23:34 pmichaud ...and in nqp-rx, so apparently that's not it.
23:34 pmichaud any way to check parrot_config for an optimized build?
23:34 japhb look for the reconfig var
23:34 pmichaud configure_args => '"--prefix=/home/pmichaud/nqp-rx/parrot_install" "--optimize"'
23:35 japhb yep, that's the one
23:35 pmichaud looks like "optimized" then.
23:35 japhb chromatic, you're running optimized too?
23:35 pmichaud so, 64-bit linux, running with Parrot --optimize
23:35 chromatic yes.
23:36 nopaste joined #parrot
23:36 chromatic The next question is what's different between the code run directly from NQP versus the PIR code saved to a file.
23:37 pmichaud they are almost certainly the same.
23:37 chromatic I can't believe there are any differences, but something's very different in these execution models.
23:37 pmichaud all that --target=pir does is interrupt the normal compilation sequence and output the PIR
23:37 pmichaud if --target=pir isn't present, then the next stage (evalpmc) invokes imcc on the PIR source to get an Eval object
23:38 pmichaud that is then returned from the 'compile' method, and then invoked (along with any arguments from the command line)
23:39 pmichaud however... you might try this
23:39 pmichaud in the .pir file, add the line
23:39 pmichaud load_bytecode 'nqp-rx.pbc'
23:39 pmichaud right at the top of main
23:39 pmichaud then run it
23:39 chromatic There's no main; how about the first line of the file?
23:39 chromatic I mean, the first line of the first sub.
23:39 pmichaud first sub, yes
23:41 pmichaud nopaste coming.
23:41 chromatic $ time ./parrot ext/nqp-rx/nqp-rx.pbc fib4.nqp
23:41 chromatic real    0m1.028s
23:41 chromatic $ time ./parrot fib4.pir
23:41 chromatic real    0m0.927s
23:41 nopaste "pmichaud" at 66.25.4.52 pasted "pir version of fib w/o and w/ load_bytecode" (17 lines) at http://nopaste.snit.ch/18917
23:42 pmichaud http://nopaste.snit.ch/18917   #  timing with and without load_bytecode in the .pir file
23:42 pmichaud fib-nqp-5.pir is the original pir
23:42 pmichaud fib-nqp-5b.pir is the pir with the load_bytecode line added
23:43 pmichaud clearly there's little difference in calling sequence as a result
23:46 japhb I'm really confused.  How can loading the NQP-rx bytecode using the load_bytecode op take 10x as long as not only loading it but using it to do a compile?
23:47 pmichaud 10x?
23:47 purl somebody said 10x was see thx
23:49 japhb Didn't you show that --target=pir (which uses the NQP-rx bytecode to do the compile) was like .2 seconds, and yet the difference between the raw fib.pir and adding load_bytecode nqp-rx.pbc is 2.1 s?
23:49 pmichaud running nqp to do the compile+run took 8sec
23:49 TonyC joined #parrot
23:49 pmichaud oh, just compiling the source to pir takes .25 sec, yes.
23:49 pmichaud all of the cost is in the code execution
23:49 japhb So somehow using NQP-rx to do a compile takes 1/10 of the time of loading it with load_bytecode.
23:50 pmichaud no
23:50 chromatic The PIR version continually runs the GC ten times as much.
23:50 pmichaud that's not what this is saying
23:50 pmichaud using NQP-rx to copmile the code takes .25 seconds
23:50 pmichaud that's pretty invariant
23:50 pmichaud if we then run the compiled code from within nqp, it takes 8 seconds
23:50 pmichaud if we save the copmiled code to PIR and run it, it takes 3.5 seconds
23:51 pmichaud if we run the generated PIR, but add a load_bytecode 'nqp-rx.pbc'  (which does nothing but load nqp-rx and its associated libraries), then the cost of running the generated PIR increases to 5.8 seconds
23:52 japhb Oh, I see ... you're saying not that the load_bytecode is expensive, but its *effect on the following code's performance*
23:52 pmichaud correct.
23:52 japhb gotcha.  OK, that makes a lot more sense.  I thought I was losing my grip there.
23:52 pmichaud we know that the load_bytecode isn't the expensive part, because the first timestamp is printed *after* the load_bytecode occurs.
23:53 japhb right
23:53 pmichaud it's also the case that although compiling a source file may result in a ton of PCC calls, simply loading NQP.pbc shouldn't result in nearly as many.
23:54 japhb I should hope not.
23:54 japhb None, most preferably.
23:54 pmichaud well, there are some, because of :load subs in the various libraries
23:55 japhb fair enough
23:55 japhb Let me say not "none" but "a very small number"
23:56 chromatic Hm, we reclaim 10x as many PMCs during GC in the NQP as we do in the PIR version.
23:57 pmichaud is that for the total execution cost (including compile)?  That wouldn't surprise me.
23:57 chromatic I mean each GC run, even when it's clearly in the "executing the generated PIR" stage.
23:58 japhb o_O
23:58 pmichaud ...reclaim?
23:58 chromatic Recycle?
23:59 pmichaud reclaim meaning "collect"?
23:59 chromatic Yes.

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

Parrot | source cross referenced