Camelia, the Perl 6 bug

IRC log for #parrot, 2010-09-21

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 whiteknight NotFound: :)
00:02 whiteknight the word isn't bad. My use of the word was bad. You can call Winxed anything you want to call it
00:03 hercynium joined #parrot
00:07 * whiteknight has to go. Goodnight
00:07 whiteknight left #parrot
00:07 muixirt_ joined #parrot
00:08 dalek website: jkeenan++ | Parrot Design Documents in Need of Overhaul
00:08 dalek website: http://www.parrot.org/content/parr​ot-design-documents-need-overhaul
00:10 patspam joined #parrot
00:10 patspam left #parrot
00:11 muixirt left #parrot
00:11 muixirt_ is now known as muixirt
00:23 kid51 is now known as kid51_at_dinner
00:37 jsut joined #parrot
00:42 jsut_ left #parrot
00:46 muixirt left #parrot
00:47 dukeleto aloha, msg chromatic according to my data, the stress_strings.pir slowdown happened in r48585
00:47 aloha dukeleto: OK. I'll deliver the message.
00:50 * davidfetter waves to dukeleto from the caltrain
01:04 dukeleto davidfetter: werd
01:06 davidfetter left #parrot
01:33 kid51_at_dinner is now known as kid51
01:59 dalek TT #1231 closed by jkeenan++: src/pmc/hash.pmc:  Use freeze in get_repr() (for hashes)
01:59 dalek TT #1231: http://trac.parrot.org/parrot/ticket/1231
02:13 ash_ is there a specific person thats sorta the 'goto person' for os x issues for parrot?
02:34 s1n joined #parrot
02:35 davidfetter joined #parrot
02:35 janus left #parrot
02:40 dukeleto ash_: i used to be one of them, but went back to linux
02:41 dukeleto ash_: bubaflub and brianwisti are os x peeps, methinks
02:41 ash_ alright, well, i was thinking of looking into getting parrot to properly build as 32 bit on 64 bit OS X, as well as maybe making a proper fat binary
02:42 dukeleto ash_: that would be appreciated
02:42 betterworld left #parrot
02:43 * dukeleto goes afk
02:43 kid51 ash_:  You're more than welcome to take a whack at all the 'Darwin' platform Trac tickets :-)
02:43 x3nU_ left #parrot
02:44 ash_ i'll look at them and see if i can find anything i'd be able to tackle, i still need to get my GSoC changes merged into the trunk :-x
02:47 ash_ what other darwin issues are there?
02:48 kid51 You can do a query in Trac for that
02:48 janus joined #parrot
02:48 * kid51 must sleep
02:48 purl Sleep is for the weak.
02:53 x3nU joined #parrot
02:59 betterworld joined #parrot
03:19 kid51 left #parrot
03:23 Andy joined #parrot
03:45 silug left #parrot
03:48 sjn_ left #parrot
03:50 s1n left #parrot
03:59 sorear <echosystm> python is a lie
03:59 sorear classic
04:03 ash_ left #parrot
04:03 plobsing oh noes. the snake is a lie!
04:04 ash_ joined #parrot
04:26 ash_ left #parrot
04:56 hercynium left #parrot
04:57 necrolyte joined #parrot
04:58 lucian joined #parrot
05:02 necrolyte left #parrot
05:12 lucian left #parrot
05:21 Andy left #parrot
05:53 theory left #parrot
05:53 dukeleto blarg
06:58 fperrad joined #parrot
07:36 tadzik joined #parrot
07:40 gerd joined #parrot
07:45 gerd I want to start the checkout for release 2.8.0. Can I start with it now?
07:48 gerd Nobody is again it - so I will start the update to version 2.8.0
07:55 gerd "make world docs html" is still running
07:57 gerd "make fulltest" is still running ...
08:04 gerd "make fulltest" finished successful - so I do the commit now
08:07 gerd The commit is done, I will run the tests now again with the sources from the 2.8.0 tarfile
08:07 dalek parrot: r49192 | gerd++ | trunk (10 files):
08:08 dalek parrot: switch the version to 2.8.0
08:08 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49192/
08:17 Tene left #parrot
08:20 mikehh left #parrot
08:22 gerd tests from the tarfile finished, I tagged the release
08:24 dalek parrot: r49193 | gerd++ | tags/RELEASE_2_8_0:
08:24 dalek parrot: tagged release 2.8.0
08:24 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49193/
08:27 gerd ftp server is triggered; I will start writing the HTML page
08:31 cotto nice
08:31 cotto gerd++
08:32 cotto It's barely Tuesday for me and we've already got a release.
08:35 mikehh joined #parrot
08:42 Tanami left #parrot
08:47 Tanami joined #parrot
08:58 dalek left #parrot
08:58 dalek joined #parrot
09:00 dalek left #parrot
09:01 dalek joined #parrot
09:25 dip joined #parrot
09:30 muixirt joined #parrot
09:33 muixirt is someone working on cardinal?
09:41 cotto http://github.com/cardinal/cardinal/
09:41 cotto looks like nothing recent
09:42 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#141) fulltest) at r49194 - Ubuntu 10.10 beta amd64 (g++-4.5 with --optimize)
09:44 dalek website: gerd++ | Parrot 2.8.0 "Tui Parakeet" Released!
09:44 dalek website: http://www.parrot.org/news/2020/Parrot-2.8.0
09:47 Tanami :D
09:47 Tanami hooray
09:49 cotto no quote?
09:49 cotto we'll let it go this time
09:58 gerd I changed the website to: http://www.parrot.org/news/2010/Parrot-2.8.0
09:59 gerd I will send the e-mail after lunch
09:59 cotto clock?
09:59 purl cotto: LAX: Tue 2:59am PDT / CHI: Tue 4:59am CDT / NYC: Tue 5:59am EDT / LON: Tue 10:59am BST / BER: Tue 11:59am CEST / IND: Tue 3:29pm IST / TOK: Tue 6:59pm JST / SYD: Tue 7:59pm EST /
10:00 gerd Happy hacking, bye!
10:00 cotto Mmmm.  Future parrot.
10:01 bacek aloha, humans
10:01 gerd left #parrot
10:01 cotto aloha, bacek
10:01 bacek cotto, hi
10:01 bacek I would like to declare gc_massacre mergeable back to trunk.
10:01 cotto ship it
10:02 jnthn bacek: What GC improvements does the branch bring?
10:03 * jnthn wonders if it fixes the recursion problem...
10:03 Topic for #parrot is now Parrot 2.8.0 released | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | test gc_massacre branch | close 25 tickets; remove deprecated items (especially CodeString);
10:03 bacek jnthn, nope. I reduced initial scope for branch.
10:04 bacek Basically - it's revamp of current Fixed_Pool/Variable_Pool nonsense which will allow to implement more sophisticated GCs little bit more easy.
10:04 bacek E.g. GenGC
10:04 bacek OTOH, I can fix recursion problem straight after merging back.
10:04 bacek In new branch.
10:06 jnthn It'd be wonderful to have that fixed.
10:06 jnthn bacek++
10:07 cotto what's the recursion problem?
10:08 jnthn cotto: If you mark a long linked list or a deep tree, the marker recurses on the C stack, and then stack overflows.
10:08 jnthn (We actually do hit it in Rakudo...)
10:08 cotto I remember that one.
10:08 tadzik left #parrot
10:10 bacek cotto, http://trac.parrot.org/parrot/ticket/1723
10:11 bacek jnthn, however http://trac.parrot.org/par​rot/ticket/1789#comment:9 :)
10:11 bacek afk # dinner
10:12 dalek parrot: r49195 | bacek++ | branches/gc_massacre/t/op/string_cs.t:
10:12 dalek parrot: Sync test with trunk
10:12 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49195/
10:12 dalek parrot: r49196 | bacek++ | branches/gc_massacre/t/op/string_mem.t:
10:12 dalek parrot: Fix string_mem test to use C<skip> instead of C<todo>
10:12 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49196/
10:14 jnthn bacek: ooh! :-)
10:20 muixirt there is 2 arg version of the function Parrot_str_new_noinit in api.c and a 3 arg version in parrot/2.7.0/parrot/string_funcs.h
10:20 muixirt (i get an error build lua because of this (?))
10:27 muixirt erm, mixed up the versions
10:27 muixirt so that function has changed and lua didn't keep up
10:28 * muixirt confused
10:28 purl You won't be after this episode of Soap!
10:36 kid51 joined #parrot
10:36 kid51 r49191: Darwin/PPC: make fulltest PASS
10:37 muixirt for the record: lua builds fine with parrot 2.8.0
10:54 sjn_ joined #parrot
10:58 ruoso left #parrot
11:00 whiteknight joined #parrot
11:03 dalek parrot: r49197 | mikehh++ | branches/gc_massacre/src/gc/gc_ms2.c:
11:03 dalek parrot: [gc_massacre] fix codetest failures - replace ms with ms2 in ASSERT_ARGS and documentation
11:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49197/
11:03 dalek parrot: r49198 | jkeenan++ | trunk/config/gen/makefiles/root.in:
11:03 dalek parrot: Eliminate LIBPARROT dependency in LIBNCI_TEST_SO.  See �http://trac.parrot.org/parrot/ticket/1130. (make reconfigure)
11:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49198/
11:03 dalek parrot: r49199 | mikehh++ | branches/gc_massacre/src/gc/fixed_allocator.c:
11:03 dalek parrot: [gc_massacre] add ASSERT_ARGS
11:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49199/
11:11 nopaste "kid51" at 192.168.1.3 pasted "gc_massacre branch: failure in t/pmc/filehandle.t" (55 lines) at http://nopaste.snit.ch/23504
11:12 whiteknight good morning, #parrot
11:12 whiteknight my amd64 laptop is broken into dozens of little pieces, otherwise I would run some tests for the gc_massacre branch
11:13 kid51 That gc_massacre failure was at r 49196
11:13 kid51 Linux/i386
11:16 whiteknight kid51 # nice blog post!
11:29 kid51 whiteknight thx
11:31 mikehh bacek: ping
11:37 ttbot Parrot trunk/ r49179 i386-linux-thread-multi make error http://tt.taptinder.org/file/cmdout/396135.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
11:55 bkuhn joined #parrot
11:56 mikehh gc_ massacre - apart from c++ comments in src/gc/gc_ms2.c all tests PASS (coretest/test/fulltest) at r49199 - Ubuntu 10.10 beta amd64 (gcc-4,5)
11:59 mikehh kid51: the t/pmc/filehandle.t test passes for me in gc_massacre (on amd64 though)
12:02 kid51 mikehh:  I've tried it twice.  Same results both times.
12:06 kid51 That most recent ttbot report is nearly 20 hours old and no longer relevant
12:07 gerd joined #parrot
12:07 gerd left #parrot
12:08 mikehh kid51: did a prove on it a couple of times - also passed in all 3 core tests in fulltest - but again I haven't tried it on i386
12:08 bkuhn left #parrot
12:17 kid51 3rd time fail on linux/i386 -- and I worked from make realclean up
12:17 * kid51 to $job
12:17 kid51 left #parrot
12:19 kid51 joined #parrot
12:20 kid51 left #parrot
12:30 ruoso joined #parrot
12:36 bkuhn joined #parrot
12:38 whiteknight I'll give it a look on linux/i386 in a little while
12:50 ash_ joined #parrot
12:56 tadzik joined #parrot
13:02 patspam joined #parrot
13:16 davidfetter left #parrot
13:18 Psyche^ joined #parrot
13:18 Patterner left #parrot
13:18 Psyche^ is now known as Patterner
13:31 Coke Docs on parrot.org are showing 2.7.0-devel, WHOOPS.
13:31 Coke (those have traditionally been release-only versions of the docs.)
13:43 tadzik1 joined #parrot
13:44 tadzik left #parrot
13:44 lucian joined #parrot
13:49 tadzik1 is now known as tadzik
14:02 davidfetter joined #parrot
14:16 dalek TT #1130 closed by jkeenan++: dependency problem for libnci_test
14:16 dalek TT #1130: http://trac.parrot.org/parrot/ticket/1130
14:22 ash_ left #parrot
14:30 ash_ joined #parrot
14:30 whiteknight dukeleto: ping
14:30 Andy joined #parrot
14:33 whiteknight msg dukeleto you said we had a stand-alone tool that can upload smolder reports? we need to add reporting capability to plumage and I would prefer to use some kind of existing solution as opposed to completely rewriting things
14:33 purl Message for dukeleto stored.
14:33 aloha OK. I'll deliver the message.
14:34 moritz whiteknight: you can look at rakudo's build/Makefile.in. It uses curl for uploading the reports
14:35 whiteknight yeah, I was thinking about that. That's Plan B
14:35 whiteknight systems don't always have curl
14:35 whiteknight but if you're running plumage, you do have parrot
14:35 moritz well, there's an HTTP client in parrot somewhere, no?
14:36 moritz I'm sure it could be made to accept similar options as curl
14:36 whiteknight yeah, dukeleto mentioned that there was a smolder upload tool in parrot somewhere that already exists
14:36 Coke added by leo about 8 years ago.
14:36 Coke (the http stuff) no clue if it's maintained.
14:39 NotFound The HTTP client code is incomplete, it can't handle chunked responses.
14:39 moritz didn't fperrad write a more complete one recently?
14:39 Andy left #parrot
14:40 NotFound runtime/parrot/library/LWP/ ?
14:41 whiteknight fperrad has written a whole ton of stuff
14:41 NotFound Yeah, the problem is that a ton of stuff written in pir is a hard to maintain ton.
14:44 whiteknight there's no good alternative though, if we're looking for decent performance
14:44 whiteknight NQP is much easier to maintain, but obviously slower because of some of the lexicals issues that we've talked about, among other things
14:45 NotFound winxed can be an alternative
14:45 NotFound Or Close, if someone finishes it.
14:45 * moritz would expect network performance to be the bottleneck for LWP
14:45 dalek parrot: r49200 | coke++ | trunk/config/gen/makefiles/root.in:
14:45 dalek parrot: [build] fix a dep reported missing by tools/dev/checkdepend.pl
14:45 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49200/
14:46 Coke or, call me crazy, we could make nqp faster. ;)
14:46 Coke rather than finding YA workaround.
14:46 NotFound Not a bad idea,
14:47 * moritz would love to see tcurtis' optimization framework in ext/
14:47 moritz then it would be much easier to use for nqp and rakudo
14:48 NotFound If winxed is a workaround for pir, then C is a workaround for assembler ;)
14:48 * Coke wasted a lot of time on partcl avoiding the known slow paths rather than using them and getting them fixed.
14:49 moritz NotFound: C really is a workaround for assembler.
14:50 NotFound And assembler a workaround for 001101010....
14:50 atrodo Not sure about that.  At least in assembler, you don't fool youself into thinking it's portable...
14:51 Coke atrodo: that's pretty much parrot in a nutshell. ;)
14:53 NotFound Anyway, I would prefer a slow LWP that works rather than a fast one that works.... sometimes.
14:54 whiteknight getting NQP performance fixed is in no small way tied to the lvalue assignment problems that Parrot has
14:54 whiteknight and fixing that is going to require somebody who's knowledgable about the issue to put down a concrete design for it
14:55 jnthn We should also be less stupid about lexicals generally
14:55 jnthn Why on earth do we look them up by name?
14:55 pmichaud I'm not sure I agree with that assessment.
14:55 jnthn That should be a last resort, not a first one.
14:55 NotFound We do?
14:55 jnthn (For the case where they're all statically known at compile time.)
14:55 jnthn $P0 = find_lex '$lol'
14:55 pmichaud since NQP doesn't have assignment, I don't see why it's a significant performance penalty.
14:56 pmichaud find_lex isn't *that* expensive.
14:56 jnthn pmichaud: Individually, no...
14:56 whiteknight pmichaud: I may be mistakenly remembering old discussions
14:56 jnthn pmichaud: When you do enough of them, though...
14:56 pmichaud jnthn: even cumulatively I don't think it's that expensive.
14:57 pmichaud I'd be very happy to be proven wrong.
14:57 jnthn pmichaud: Maybe .Net dictionary lookups are slow, or maybe eveyrthing else in Parrot is so slow it swamps in. In 6model, it was a notable win.
14:57 jnthn *swamps it
14:57 pmichaud jnthn: I'm thinking it's likely "everything else in Parrot..."
14:57 whiteknight pmichaud: what do you see as the major performance bottleneck in NQP?
14:57 NotFound I've started to use lexicals for implementing Closures in winxed and haven't noticed speed impacts in the few tests I've do.
14:57 jnthn Yeah, but if we keep not optimizing stuff because the problem is "everything else"... :/
14:58 pmichaud for typical NQP programs, the major performance cost is in method call overhead and return exception handling, iirc.
14:59 whiteknight hmm...those are a little bit less straight-forward to fix
14:59 pmichaud ...and GC, of course.
15:05 muixirt pmichaud: method call overhead? Can explain that a bit more?
15:06 theory joined #parrot
15:06 pmichaud muixirt: method calls have traditionally been somewhat slow in Parrot
15:07 atrodo Is it a large cost in context initialization?
15:07 muixirt why?
15:07 jnthn Trouble is, while I can in the meta-model help on method *lookup*, if the context creation overhead is the bigger part it can only help so much.
15:12 * muixirt wonders what steps are necessary in parrot for a method call
15:13 lucian left #parrot
15:19 muixirt left #parrot
15:20 pmichaud using a simple recursive fibonacci program as a benchmark.... lexical lookup is a bit more costly than I remember from last looking at it.  about 10%.  (more)
15:21 pmichaud creating exception handlers to handle return exceptions is about 60%
15:21 jnthn omg
15:21 jnthn *60*?
15:21 pmichaud I go from 5.1sec to 2.2sec when I take out the return exception handler creation
15:21 whiteknight oi
15:21 atrodo That seems quite excessive
15:22 pmichaud that does seem excessive, now that I think about it.
15:22 jnthn pmichaud: Is that just creating the handlers?
15:22 moritz so an optimization that simply removes the return() where possible would be quite welcome
15:22 pmichaud moritz: I'm not making a return()
15:22 jnthn pmichaud: Or also throwing the return exception and catching it?
15:22 jnthn Wow!
15:22 pmichaud I'm simply creating the handler -- not throwing the exception.
15:22 pmichaud just a sec.
15:23 NotFound pmichaud: what is the code that creates control exception handlers in nqp?
15:23 pmichaud new $P15, 'ExceptionHandler'
15:23 pmichaud set_addr $P15, control_14
15:23 pmichaud $P15."handle_types"(.CONTROL_RETURN)
15:23 pmichaud push_eh $P15
15:24 atrodo So, as the new guy, this would be like installing a try block?
15:24 pmichaud the handle_types calls accounts for 40%
15:24 jnthn Youch, that's a method call and what looks like a slurpy taking METHOD.
15:24 NotFound handle_types is a method with slurpy param, that may be a noticeable part of the cost.
15:25 pmichaud (5.1sec to 3.1sec)
15:25 jnthn I'm not sure I follow why the Parrot way of setting these up is once per block invocation rather than once per block.
15:25 pmichaud jnthn: because each closure needs its own continuation.
15:26 pmichaud I tried sharing exception handlers and that didn't work out so well.
15:26 jnthn Right, but I'd have hoped we could set *some* of it up statically even if we have to do some stuff per invocation too.
15:26 NotFound A lot of handlers handle only one type. A way to set it using a vtable instead of a method can be helpful.
15:26 arnsholt left #parrot
15:26 pmichaud yes, method calls are expensive :-)
15:27 pmichaud at least for NQP and Rakudo, I think this is the only exception handler that is looking for just one type, though.
15:28 pmichaud all of the others look for a subset of types.
15:28 pmichaud afk for a few minutes
15:29 JimmyZ joined #parrot
15:29 ash_ why are the handler's needed? to create continuations?
15:30 NotFound Not so easy, event if we provide a shorter way to set the types handled, it still needs to initialize the handled_types atribute.
15:32 * JimmyZ remembers http://trac.parrot.org/parrot/wiki​/WhyDoesNQPGenerateInefficientCode
15:37 NotFound ack '.CONTROL_RETURN' in ext/nqp-rx shows a lot of usages
15:38 jnthn NotFound: Every sub
15:38 jnthn (in the Perl 6 sense of sub, not the Parrot one)
15:40 NotFound I can try a hack for ExceptionHandler but don't how to do a quick speed test of it.
15:41 ruoso left #parrot
15:41 NotFound s/don't/don't know
15:42 Coke create a branch, let pmichaud test it. ;)
15:42 NotFound Coke: a branch ow what? parrot? nqp? both?
15:43 Coke if you're changing exceptionhandler, parrot, no?
15:43 jnthn NotFound: pmichaud++ can probably give you the PIR to try it on when we returns too :-)
15:43 jnthn *he
15:43 Coke I don't know what you're changing, but if it's nqp source, there, and if it's parrot source, here?
15:43 Coke or just wait. ;)
15:44 NotFound jnthn: I can also write some test cases in pir, but specially written pir test don't show anything about the measurabe impact in real usages of nqp.
15:45 NotFound Coke: the idea is simple: add init_int vtable to ExceptionHandler and use the int value as type handled.
15:46 NotFound Easy to write, hard to test for me.
15:47 Coke that will only work when you're trying to handle a single type, yes?
15:48 Coke (might also need an init_pmc that takes an RPA/List/something)
15:48 Coke but that's a good first step, I bet.
15:48 Coke NotFound++
15:48 NotFound Coke: the idea is to evaluate the impact of a change like that in the .CONTROL_RETURN case. If it pays, we can think about similar approaches for other cases.
15:48 pmichaud handling a single type (.CONTROL_RETURN) is useful.
15:48 pmichaud we have a lot of return handlers.
15:48 pmichaud (one per logical subroutine)
15:49 pmichaud http://github.com/perl6/nqp-rx​/blob/master/examples/fib.nqp  # my fib.nqp test program
15:49 pmichaud you can use --target=pir to convert it to PIR, then hand-edit the PIR to see the effect of various changes on the resulting time
15:50 pmichaud for example, to test the cost of the exception handler, I simply commented it out.
15:50 NotFound Where is the code that generates the handler creation? nqp? pct? ...
15:50 pmichaud pct generates the handler creation
15:50 pmichaud look for control_pir, iirc
15:50 NotFound Maybe I can test it, then.
15:50 dalek nqp-rx/master: f59925c | pmichaud++ | examples/fib.nqp:
15:50 pmichaud I'll be happy to run tests here.
15:50 dalek nqp-rx/master: Add fib.nqp as a recursion benchmark example.
15:50 dalek nqp-rx/master: review: http://github.com/perl6/nqp-rx/commit/f​59925ced7063e24384e7708a40384dc23e48221
15:51 NotFound src/PAST/Node.pir
15:51 NotFound 524:value "return_pir" generates code to handle C<CONTROL_RETURN> exceptions.
15:51 NotFound This one?
15:51 purl it has been said that This one is pretty good, I hope.  the Catalyst update made it straightforward.   When you get time there's that and also jnap's plack updates got merged in and we can look at the psgi engine branch, which seems good to me (but maybe bad code, still passes all tests)
15:51 pmichaud that's it... "return_pir"
15:52 NotFound src/PAST/Compiler.pir ?
15:52 pmichaud line 970
15:53 NotFound Looks easy to change. I'll give it a try.
15:53 davidfetter left #parrot
15:53 pmichaud oh, wait
15:54 pmichaud lines 934-937
15:54 pmichaud that's the part that generates the handler
15:54 pmichaud the other part is the handler itself (probably doesn't need modification)
15:54 Coke which file is this?
15:54 NotFound bpost.'push_pirop'('new', $S0, "'ExceptionHandler'") and following, isn't it?
15:54 pmichaud compilers/pct/src/PAST/Compiler.pir
15:54 Coke oh, PAST, not PCT.
15:54 Coke danke.
15:55 davidfetter joined #parrot
15:58 pmichaud hmmm
15:58 davidfetter left #parrot
15:58 pmichaud commenting out the push_eh step runs 14% faster
15:58 pmichaud that's.... weird also.
15:59 pmichaud maybe we're seeing gc interactions here.
15:59 jnthn pmichaud: That's kinda scary. We have a *lot* of very short subs/methods.
15:59 pmichaud I wonder if push_eh is forcing the generation of additional RPA's (one per context)
16:00 pmichaud I think that already got optimized, though, to generate a RPA only when there's more than one handler active in a given context
16:00 NotFound First uglyness: I changed that file without patching ExceptionHandler and parrot builds and pass tests.
16:00 JimmyZ left #parrot
16:01 pmichaud http://gist.github.com/589930  # cost of push_eh step
16:02 pmichaud feels like push_eh ought to be a lot faster than that.
16:04 NotFound Parrot_cx_add_handler_local creates a RPA when the first handler is added.
16:05 JimmyZ joined #parrot
16:06 davidfetter joined #parrot
16:08 ruoso joined #parrot
16:08 ash_ atrodo: is lorito's 90_fib.t test supposed to end with a single ok  followed by 6765? it says 1..4, so i am just checking
16:10 atrodo ash_> Nope, it's not suppose to.  I just never finished it :D
16:10 ash_ ah, got ya
16:18 nopaste "NotFound" at 192.168.1.3 pasted "patch: testing a shortcut for handlers of .CONTROL_RETURN" (44 lines) at http://nopaste.snit.ch/23508
16:19 wow left #parrot
16:22 JimmyZ left #parrot
16:33 whiteknight I suggest that maybe the first handler pushed should not create an RPA, but just be used by itself
16:33 whiteknight additional handlers can create an RPA when/if they are pushed
16:34 NotFound With this t/compilers/opsc/02-parse-all-ops.t looks a bit faster, but the difference seems to be less than 0.5%
16:41 chromatic joined #parrot
16:43 davidfetter left #parrot
16:43 davidfetter joined #parrot
16:44 whiteknight good morning, chromatic
16:45 chromatic aloha
16:45 dukeleto howdy, folks
16:45 whiteknight I had an idea this morning about creating NCI method PMCs lazily
16:45 dalek parrot: r49201 | nwellnhof++ | trunk (2 files):
16:45 dukeleto chromatic: did you see my msg about the stress_strings.pir slowdown ?
16:45 dalek parrot: [io] Fix Parrot_io_read_utf8 with 3-byte chars
16:45 dalek parrot: Also remove unsafe use of Parrot_str_concat
16:45 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49201/
16:45 chromatic That'd be handy.
16:45 whiteknight it seems to me like initializing and installing all those PMCs is quirte expensive
16:45 chromatic dukeleto, I did.
16:46 chromatic The MultiSubs for PMCs are spendy.
16:47 dukeleto chromatic: i have a tool to run code for every git commit in a commitish, which will come in handy
16:47 chromatic I'll look at that tuning commit and see what I can see.
16:48 dukeleto chromatic: that commit fixed some bugs, so it could be that doing things correctly is slower, but perhaps you can find a way to keep those bugs fixed and not be so slow
16:48 dukeleto chromatic: i am also interested to see how stress_strings.pir does on gc_massacre
16:48 purl okay, dukeleto.
16:49 dukeleto whiteknight: just saw your mesage. examples/io/post.pir
16:49 chromatic I thought that example only changed a threshold.
16:51 whiteknight dukeleto: ah, okay. so it's not really a stand-alone utility so much as an example. I'll probably pull the guts into a separate tool
16:53 whiteknight chromatic: I think we can avoid installing the NCI PMCs at class_init time. Instead, we can build an array of name/func_ptr pairs at compile time, and have Pmc2c implement a custom find_method that looks up the first instance of a method in the array first
16:54 whiteknight I would wager that no program ever written would require the existance of all NCI methods in all built-in classes
16:54 chromatic Exactly.
16:54 dukeleto whiteknight: i think turning post.pir into an actually useful tool would be nice. currently you can't tell it which file you want to post, it just hardcodes it
16:54 whiteknight dukeleto: This is sounding more and more like the grand test framework project I want to implement
16:55 dukeleto whiteknight: have you given any more thought to including kakapo in PLA?
16:55 whiteknight what do you mean?
16:56 dukeleto whiteknight: just wondering if PLA would inclue it's own copy of Kakapo, i.e. a version that is know to work with PLA
16:56 whiteknight I did create a tag on my github mirror
16:56 whiteknight PLA only uses the unit test portions of kakapo, nothing else. I'm thinking about forking that portion, or writing something like it
16:56 dukeleto whiteknight: i was running into issues running the PLA test suite a while ago, haven't tried since then, but I would really like to help hack on PLA
16:57 whiteknight yeah, I've gotten those issues sorted out. I'm preparing a release now and will probably have it out after I am done work
16:57 whiteknight I've got instructions for how to get the correct version of kakapo and everything
16:59 whiteknight that examples/io/post.pir looks extremely similar to the smolder upload code in distutils
17:02 dukeleto whiteknight: good to hear, i will try your new release when it hits the interwebs
17:02 dalek parrot: r49202 | fperrad++ | trunk/runtime/parrot/library/LWP/Protocol.pir:
17:02 dalek parrot: [LWP] handles an IO error
17:02 dukeleto whiteknight: yes, post.pir is basically the same code that is in distutils
17:02 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49202/
17:07 Andy joined #parrot
17:16 sjn is now known as _sjn
17:17 NotFound whiteknight: the idea about the first handler has a problem: the handlers list is managed by direct access from several places.
17:18 whiteknight ha, doesn't surprise me
17:18 sjn_ is now known as sjn
17:20 pmichaud http://gist.github.com/590074  # effect of NotFound++'s init_int patch on fib.nqp
17:21 Coke 4.85194206237793 / 3.39949893951416
17:21 purl 1.4272521182405
17:21 aloha 1.4272521182405
17:21 pmichaud rakudo:  (4.85-3.40)/4.85
17:21 purl 0.298969072164948
17:21 Coke purl, play in traffic.
17:21 purl Coke: huh?
17:21 p6eval rakudo be80e9:  ( no output )
17:21 pmichaud hard to argue with a 30% speedup.  :)
17:22 Coke I'd say ship it. ;)
17:22 pmichaud too bad we didn't do this before the release :-|
17:22 NotFound 30% ? I'm amazed
17:22 Coke pmichaud: next release is always better. :|
17:22 pmichaud I'm not.  we avoid a method call.
17:23 ash_ is that only 1 method call's difference between the two?
17:23 pmichaud basically, yes.
17:23 Coke that one call is repeated many times.
17:23 Coke (yes?)
17:23 pmichaud it's one call per invocation, yes.
17:23 NotFound And some less bytes for sub implied.
17:24 PerlJam pmichaud: there's always another release 1 month away or so
17:24 pmichaud essentially, that subroutine is 30% faster without that method call present.
17:24 NotFound Commit it, then?
17:24 pmichaud I'll commit, yes.
17:24 pmichaud I'm reworking the PAST::Compiler change slightly, and need to do a full test.
17:25 pmichaud (need to make sure nqp still works with the change)
17:25 NotFound pmichaud: ok
17:25 pmichaud can I get rid of the ** TESTING ** note?
17:25 pmichaud (in init_int() ?)
17:25 NotFound pmichaud: sure
17:25 dukeleto whiteknight: nice work on the github pages for PLA. very sexy
17:25 ash_ how hard/long are method lookups?
17:26 whiteknight dukeleto: Ha! kid51 complained about them
17:26 pmichaud it's not just the fact of being a method call... it's a PCCMETHOD call
17:26 Coke url?
17:26 whiteknight Coke: http://whiteknight.github.​com/parrot-linear-algebra/
17:26 whiteknight I'm not colorblind, I'm just extremely non-artistic
17:27 NotFound pmichaud: and even better, with slurpy param
17:27 Coke aside from dark, looks good to me. I have the same problem you do. ;)
17:27 _sjn is now known as sjn_
17:27 Coke any other places in compilers/ that can benefit from this update?
17:27 Coke oh, needs tests, too. :|
17:28 pmichaud well, the slurpy param got used immediately within the method (and retained), so not much additional savings from that.
17:28 Coke if only types were maskable.
17:28 pmichaud i.e., the slurpy param simply became the new bound value for the attribute.  w/o the slurpy param, we'd just have to create a resizable array :)
17:28 NotFound pmichaud: but creates an array pmc during the call
17:28 ash_ whiteknight: you have an error in your html, <h1>Parrot-Linear-Algebra</h2> is probably not what you meant to do
17:28 NotFound Ah, yes, the array is reused.
17:29 pmichaud although the fixedintegerarray is probably more efficient
17:29 whiteknight ash_: damnit! Thanks for pointing out my fail
17:29 ash_ whiteknight: in my browser, the entire site is in H1 STYLE BIG FONT
17:29 pmichaud Coke: I don't know that anything uses .CONTROL_RETURN other than things generated via pct and/or nqp.
17:29 * NotFound likes w3c validator
17:29 ash_ no problem
17:29 dukeleto ash_: are you using lynx ?
17:30 ash_ nope, chrome
17:30 ash_ but if you curl the page
17:30 ash_ the html tag was kinda obviously the cause </h2> should of been </h1>
17:31 Coke pmichaud: I mean handle_types with a single arg.
17:31 pmichaud Coke: I don't think there are many cases of handle_types with a single arg.
17:31 pmichaud (other than .CONTROL_RETURN)
17:32 Coke worth a simple ack. ;)
17:34 pmichaud simple ack doesn't come up with any single-argument handle_types calls that aren't .CONTROL_RETURN
17:35 pmichaud (well, there are some, but none significant)
17:35 pmichaud (mostly in t/)
17:37 NotFound pmichaud: In tests I use single arg a lot, but just for checking that throws the expected type.
17:39 Coke in git, can you checkout a tag?
17:39 whiteknight git checkout <tag_name>
17:39 Coke (instead of a branch)
17:39 Coke ok. how can I tell if I've done that already? ;)
17:40 whiteknight "git tag"?
17:40 Coke git tag shows a list of tags.
17:40 pmichaud git status?
17:40 purl git status is probably porcelain
17:40 Coke (I don't see any special annotations)
17:40 Coke in tag or status.
17:41 pmichaud iirc, if it says you're on a branch, then you haven't done that.
17:41 pmichaud (e.g., if it says you're on branch master, then you are really on master and not a tag)
17:41 Coke danke.
17:42 Coke ugh. now to re-re-fix git through corporate firewall.
17:44 jnthn Wow, we get 30% win?! :-)
17:44 pmichaud in that example, yes.
17:44 pmichaud it would obviously be less of a win if the sub were more complex.
17:44 jnthn pmichaud++, NotFound++
17:44 jnthn Right, but we have quite a lot of short subs/methods too.
17:45 pmichaud correct.
17:45 pmichaud no matter how you slice it, we made an expensive+common operation much less expensive.
17:45 jnthn That's what we need. :-)
17:45 pmichaud next is to see if we can improve push_eh
17:45 jnthn *nod*
17:46 jnthn And when you improve them, what % of the time *then* is messing with lexicals. :-)
17:46 jnthn s/them/that/
17:46 Coke hurm. "git checkout <tag name> ;git status" - "not currently on any branch" ... no mention of the tag itself.
17:46 pmichaud oddly, it was still 10% in my preliminary test
17:46 jnthn Oddness.
17:46 pmichaud i.e., instead of saving 0.5 seconds, it only saved 0.3
17:46 pmichaud (okay, 15%.)
17:46 pmichaud ish.
17:46 pmichaud Coke: it only knows the commit your on, not the tag.
17:46 pmichaud *you're
17:47 pmichaud although git-describe might indicate the tag.
17:49 dukeleto you may need "git describe --tags"
17:52 dukeleto gerd++ # another solid release
17:53 NotFound gerd++
17:53 Coke dukeleto++ #that's what I'm looking for, thanks.
17:58 dukeleto pmichaud: do you have an example of code that parses the output of "git describe" to determine if the necessary version of something is present?
17:59 pmichaud dukeleto: not yet.
17:59 pmichaud I wasn't planning to use
17:59 pmichaud I wasn't planning to use  "git describe" for that, necessarily.
18:04 pmichaud http://gist.github.com/590149  # effect of additional (and possibly unneeded) find_lex opcodes on fib.nqp
18:05 chromatic 10% there
18:06 pmichaud but it takes a lot of analysis to determine that the find_lex is in fact unnecessary
18:06 pmichaud (and in the general case might not be knowable)
18:08 jnthn pmichaud: My point is more than we know how many call frames out the lexical will be statically most of the time. We could also do a compile-time name => slot mapping.
18:08 pmichaud jnthn: yes, agreed.
18:08 jnthn pmichaud: So you can get it down to a few pointer follows, rather than a bunch of hash lookups.
18:08 jnthn pmichaud: That's what I've (partially) done in 6model.
18:08 chromatic That's what Perl 5 does.
18:08 pmichaud in this case it'd be an upper-bound improvement of 10%, though.
18:08 davidfetter it's all it ever does!
18:08 pmichaud (in the case of nested blocks, it'd probably be greater)
18:08 davidfetter oh, wait. wrong movie
18:09 dukeleto pmichaud: in the conversion of mk_language_shell/create_language to be git-aware, I need to parse the output of "git describe"
18:09 pmichaud dukeleto: or you can have git-describe output in whatever format is easy to parse :)
18:10 pmichaud http://gist.github.com/590171  # cost of push_eh opcode
18:10 pmichaud rakudo: (3.40-2.84)/3.40
18:10 purl 0.164705882352941
18:10 p6eval rakudo be80e9:  ( no output )
18:10 dukeleto pmichaud: sure, but parsing git describe output seems more fragile that comparing integers. If someone makes a local tag, i think it will throw a wrench in our plans
18:11 pmichaud dukeleto: you can tell git-describe to only report specific tags or tags matching a pattern
18:11 dalek parrot: r49203 | pmichaud++ | trunk/src/pmc/exceptionhandler.pmc:
18:11 dalek parrot: Patch to add init_int() VTABLE function for ExceptionHandler.  Courtesy NotFound++ .
18:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49203/
18:11 dalek parrot: r49204 | pmichaud++ | trunk/compilers/pct/src/PAST/Compiler.pir:
18:11 dalek parrot: [pct]:  Update PCT 'return_pir' generation to use newp_s_ic opcode instead of "handle_types" methodcall.
18:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49204/
18:11 dalek parrot: r49205 | pmichaud++ | trunk/t/pmc/exceptionhandler.t:
18:11 dalek parrot: [core]:  Add test for init_int initialization of ExceptionHandler PMC.
18:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49205/
18:11 dukeleto pmichaud: that sounds useful. Time to go read the man page again
18:12 chromatic 16.48% there.
18:14 pmichaud dukeleto: I was thinking that simpler might be to make sure that a given commit appears in the history.
18:14 pmichaud as opposed to worrying about tags.
18:14 pmichaud (one could also check that a given tag appears in the history.)
18:15 dukeleto pmichaud: that is interesting, but requires the git repo. Currently, the way create_language/mk_lang_shell work, the repo is not needed
18:16 dukeleto pmichaud: perhaps that should change
18:16 Coke dukeleto: if it simplifies the conversion, go fo rit.
18:16 pmichaud oh yes, it would require the repo.
18:16 dukeleto pmichaud: i have some plans to make a web interface to create_lang/mk_lang_shell, and I suspect most people will want to use that, but for now, we can't convert to git until those 2 scripts are ported over
18:16 Coke if someone is strongly opposed, they can do something post-git
18:18 pmichaud anyway, my preference would be to do things similar to how rakudo manages it now
18:18 pmichaud i.e., it gets its version number from the output of git-describe with a --match option.
18:18 pmichaud and records that.
18:19 pmichaud git describe --match '2*'    # what rakudo currently uses to embed a revision number
18:19 dukeleto pmichaud: where does that code live?
18:19 pmichaud build/gen_version.pl
18:19 pmichaud so then we end up with:
18:20 pmichaud pmichaud@plum:~/rakudo$ ./perl6 --version
18:20 pmichaud This is Rakudo Perl 6, version 2010.08-119-gccde8dc built on parrot 2.7.0 r49091
18:20 pmichaud and it'd be trivially simple for build/PARROT_REVISION to contain something like   "2010.08-50"  which means "at least 50 commits after the 2010.08 tag"
18:21 pmichaud and we'd assume that a parrot reporting "2010.09" would always be after "2010.08"
18:21 chromatic That's doable.
18:22 pmichaud since parrot uses n.x.y tags, though, it'd probably need to be   "2.8.0-50"
18:22 pmichaud which would be fine also
18:22 pmichaud it gets very nasty/tricky though with things like 2.8.1
18:22 dukeleto pmichaud: should we care about backcompat? what about all the parrot projects that currently expect PARROT_REVISION to be an int? I am thinking of using something like PARROT_VERSION going forward
18:22 dukeleto pmichaud: yes, version numbers suck.
18:23 pmichaud I guess we'd assume that a 2.8.1 revision is automatically greater than any 2.8.0 request.
18:23 Coke that's not a reasonable assumption, depending on what you mean by greater. ;)
18:23 Coke since 2.8.1 could be a single bug fix over 2.8.1, and missing all of 2.8.0-100
18:24 Coke (assuming a linear flow seems LTA.)
18:24 pmichaud Coke: would 2.8.1 be tagged in master?
18:24 Coke I don't know what "in master" means in this context.
18:24 Coke it would be tagged, sure.
18:24 pmichaud the master branch of the parrot repo.
18:25 pmichaud currently gen_parrot.pl always grabs from the trunk/master branch
18:25 Coke I've said before that's not a sustainable thing. ;)
18:26 pmichaud so if there's a 2.8.1 tag in the master branch, it wouldn't be possible for a 2.8.0-100 to refer to something that comes after it that isn't tagged by 2.8.1
18:26 pmichaud "sustainable" shows up when we're able to restrict development to parrot releases.
18:26 Coke I don't know enough git to respond here. if this were SVN, I would say I wouldn't expect trunk to contain a snapshot of every tag.
18:26 pmichaud I don't see that happening before 4.0.0
18:27 pmichaud Coke: correct... so if the 2.8.1 tag isn't on the master branch, it doesn't pose a problem.
18:27 Coke except that you can't sync to it. right?
18:27 Coke s/sync to/require/
18:27 Coke which is unchanged from today.
18:27 pmichaud PARROT_REVISION curre.... right
18:28 Coke so we're not losing any functionality, so <shrug>
18:28 pmichaud so, why is push_eh so expensive?
18:30 chromatic Besides the method call to set its type?
18:30 pmichaud ...method call?
18:31 jnthn pmichaud: push_eh $P0
18:31 jnthn (the pmc variant)
18:31 jnthn ?
18:31 pmichaud jnthn: yes.
18:31 ash_ can we profile it?
18:32 pmichaud it appears to always need a ResizablePMCArray for the context.
18:33 NotFound pmichaud: yes, I took a look at it a few minutes ago.
18:33 jnthn Parrot_cx_add_handler_local could be a tiny bit less silly
18:33 pmichaud if we could set it so that the first handler pushed doesn't require an RPA, that'd be a win.
18:33 jnthn e.g. it does multiple gets on the same thing.
18:33 pmichaud I thought that had been done already... but apparently not.
18:34 pmichaud ...multiple gets on the same thing?
18:34 NotFound pmichaud: is a bit complicated, the array is accessed from several places.
18:34 whiteknight what would it take to clean it up so it wasn't accessed from several places?
18:35 jnthn oh, it only reads from a struct
18:35 jnthn pmichaud: It does Parrot_pcc_get_handlers twice
18:35 NotFound scheduler.c and the Scheduler pmc are the ones I've positively found. Maybe more.
18:35 jnthn pmichaud: I thought maybe that was costly but it's not
18:35 jnthn pmichaud: It's a macro encapsulating a struct access by the looks of it.
18:36 jnthn So yeah, the most expensive thing I can see it doing is making the RPA.
18:36 pmichaud is making an RPA that expensive?
18:36 chromatic It's not cheap.
18:37 pmichaud yes, that appears to be the cost.
18:38 jnthn :S
18:38 * jnthn is a bit surprised it's that costly.
18:38 pmichaud (I replaced push_eh with $P0 = new ['ResizablePMCArray']   and got essentially the same time.
18:38 NotFound unshift is not cheap. Let me try a tiny change...
18:38 pmichaud unshift onto an empty RPA ought to be relatively cheap.
18:39 chromatic What's the benchmark code?
18:39 pmichaud chromatic: fib.nqp compiled to .pir
18:39 pmichaud nopasting
18:40 pmichaud http://gist.github.com/590253   # benchmark code
18:40 chromatic Thanks.
18:40 pmichaud when we started, that was taking 5.0 sec
18:40 jnthn Why does it unshift rather than push?
18:40 jnthn The order doesn't matter at all, no?
18:41 pmichaud jnthn: because you add new handlers to the top of the stack
18:41 jnthn oh...OK
18:41 pmichaud it doesn't matter if there's not already a list.
18:41 jnthn So it does matter
18:41 dalek tracwiki: v144 | fperrad++ | Languages
18:41 dalek tracwiki: update Parrot version 2.8.0
18:41 dalek tracwiki: http://trac.parrot.org/parrot/wiki/L​anguages?version=144&amp;action=diff
18:41 jnthn pmichaud: Not in this case, no
18:43 jnthn oh, it looks like it unconditionally calls memmove
18:43 jnthn unshift_pmc calls do_unshift(INTERP, SELF, value);
18:44 jnthn And there's no "need we memmove" check in there
18:44 NotFound jnthn: memmove should be smart enough in all C compilers in this world to handle it.
18:46 pmichaud it'd be trivial to add an "if (size)" check, though.
18:46 pmichaud or "if (size > 0)"
18:46 pmichaud still, I agree that's not likely an expense.
18:46 pmichaud the real cost is in creating the RPA
18:46 chromatic I'm getting a real profile here.
18:47 chromatic Hm, looks like the deps for parrot-nqp aren't all there.
18:49 pmichaud NotFound: it looks to me like the "handlers" in Scheduler.pmc aren't directly related to exception handlers?  Where am I missing the link?
18:50 NotFound pmichaud: not sure about the sanity of that code, but if I change things in scheduler.c it breaks in Scheduler PMC
18:50 pmichaud NotFound: okay.
18:53 chromatic 5.24% of runtime is creating the RPA in Parrot_cx_add_handler_local and the other 3.82% of runtime is unshifting onto it.
18:53 pmichaud chromatic: is that from the .nqp or from the .pir?
18:53 chromatic the NQP
18:54 pmichaud ah
18:54 pmichaud so that includes the cost of compilation
18:54 chromatic 9.5% of runtime.
18:54 chromatic I'm sorry.  I mean the NQP compiled to PIR.
18:54 pmichaud okay
18:54 chromatic Running the generated .pir directly.
18:54 pmichaud and that's the cost of running the entire .pir directly
18:54 pmichaud as opposed to just the cost of the fib() subroutine
18:54 chromatic Right.
18:54 pmichaud okay.
18:55 pmichaud ooc, what's the cost of the push_eh instruction?
18:55 chromatic 0.3% of runtim
18:55 chromatic e
18:55 pmichaud how about including the things it calls?
18:56 chromatic 9.8% of runtime
18:56 pmichaud okay.
18:56 pmichaud push_eh gets called a *lot*, and generally there's one per context.
18:56 pmichaud optimizing that would seem to be a really nice win.
18:57 chromatic We should rethink how this works.
18:57 chromatic There's basically an exception handler active for the entire sub.
18:58 chromatic Seems like we could know that at compilation time.
18:58 chromatic It's a Sub property, isn't it?
18:59 pmichaud I don't quite understand the question.
18:59 chromatic In the sense that it's a property of the Sub, not any particular implementation detail.
18:59 pmichaud But yes, we know at compile time if this Sub wants a return exception handler.
18:59 chromatic So we shouldn't have to fiddle with all of this mess at runtime.
18:59 pmichaud we still have to create the continuation
18:59 pmichaud (which is what the handler is)
19:00 chromatic Is there no way we can avoid it?
19:00 whiteknight I'm sure there's something
19:00 pmichaud not from my tests.... continuations are tied to the context that created them
19:00 whiteknight because this is absud
19:00 whiteknight absurd
19:01 chromatic Ultimately, doesn't this code essentially specify a single "Before you return, run this code"?
19:01 pmichaud as well as capturing the return itself, yes.
19:01 jnthn chromatic: It needs to catch exceptions thrown from nested scopes too.
19:01 jnthn That is, return exceptions.
19:01 whiteknight right That's the rub right there. Nested subroutines
19:01 pmichaud nested *blocks*
19:02 pmichaud (in the HLL sense)
19:03 chromatic The exception handling properties active for any given context are properties of the dynamic scope of the blocks (essentially Subs, as Parrot sees them).  Right?
19:03 pmichaud that sounds right, but I'm not sure I followed every clause correctly there.
19:04 chromatic Maybe we should store these exception handlers with Subs, not Contexts.
19:04 pmichaud we still need to create the continuation, though.
19:04 chromatic Why?
19:05 pmichaud so we know what context to return to when it's invoked?
19:05 pmichaud (when the exception is thrown and the handler is invoked?)
19:05 chromatic Why does that need to be a property of the exception handler?
19:06 pmichaud let me clarify slightly, then.
19:06 pmichaud are we limiting our discussion to handlers for return exceptions?
19:06 pmichaud as opposed to other exception handlers that might exist?
19:06 chromatic Sure, if that helps.
19:07 pmichaud or, phrased differently
19:07 pmichaud are we only talking about handlers that are tied to an entire Parrot sub dynamic scope?
19:07 chromatic Yes.
19:07 tadzik http://trac.parrot.org/parrot/wiki/Languages -- where are the svn links here? I cannot find the LOLCODE repo url, is it even written anywhere?
19:07 pmichaud because we definitely have handlers that are not so tied, and they still have to be accommodated
19:09 dalek TT #502 closed by cotto++: [PATCH] build on OpenBSD/ppc
19:09 dalek TT #502: http://trac.parrot.org/parrot/ticket/502
19:10 pmichaud I suppose it'd be possible to create a single exception handler and tie it to a Sub PMC
19:10 pmichaud to be shared across all of that Sub PMC's clones/contexts
19:10 pmichaud when I tried it before, it failed (more)
19:11 pmichaud the problem was that the shared ExceptionHandler was always tied to the (original) Sub PMC that created it.
19:11 pmichaud rephrase
19:11 pmichaud the shared ExceptionHandler was always tied to the original context that created it
19:12 chromatic I know how it works now.
19:12 pmichaud because ExceptionHandler currently isa Continuation, and the way to invoke a handler is to invoke the continuation.
19:12 chromatic Sure, and that's the source of a lot of these problems.
19:13 chromatic Seems to me that finding the right EH means unwinding all of your contexts.
19:13 chromatic When you've found the EH, you've found a context.
19:13 chromatic You even know the opcode where you want to start executing the handler.
19:14 pmichaud where's the "find the right EH" code?
19:14 chromatic Right now, I don't remember.
19:14 chromatic Parrot_ex_find_handler_local() or something.
19:14 pmichaud if we can extend that...
19:15 preflex left #parrot
19:15 pmichaud i.e., every context has a set of local handlers, and also checks its (static) sub for additional local handlers
19:15 chromatic Right, we create a subclass of Sub which can have local handlers.
19:15 pmichaud i.e., we can attach handlers to subs that are assumed to be in force from the invocation of the sub
19:15 pmichaud subclass of Sub gets nasty, in general.
19:15 chromatic It shouldn't have to.
19:16 chromatic It won't need any additional code as i see it.
19:16 pmichaud how would I (compile-time) distinguish a Sub-with-handler from ordinary Sub?
19:16 chromatic type check
19:16 pmichaud I'd prefer to have handler as a property of all subs, in general.
19:16 pmichaud no, I mean when I'm generating code
19:17 chromatic I don't; I think that's one of the pervasive problems with Parrot.
19:17 pmichaud how do I tell Parrot "I need a sub with handlers" instead of "sub without handlers" (in PIR)
19:17 chromatic Ultimately the PIR/PBC generator should handle that.
19:17 preflex joined #parrot
19:17 chromatic Yes, my hands waved a little.
19:17 pmichaud the problem with subclasses is when they need to be mixed
19:17 pmichaud for example, how do I get Coroutine with handler?
19:18 chromatic Parametric role... okay, good point.
19:18 pmichaud this was one of the early problems with lexicals -- a sub with lexicals was always a Closure PMC, which meant that Coroutine's couldn't have lexicals.
19:18 whiteknight there was, at one point, an :instance_of() modifier for subs
19:18 whiteknight I don't know if it was ever implemented, or if it's just a figment of documentation
19:18 pmichaud whiteknight: yes, that was an early attempt to differentiate subs in Rakudo and it didn't go well
19:18 pmichaud because it requires compile-time knowledge of all of the possible Sub PMCs
19:18 chromatic Until we get a better metamodel for PMCs, I guess we fatten up Sub some then.
19:19 whiteknight it seems like we could either pass it in as an argument, or as a parameter
19:19 whiteknight foo(:needs_handler)
19:20 pmichaud well, the other problem is that the handler itself likely doesn't exist until runtime, unless you *really* want to extend pir
19:20 chromatic That's the biggest problem.
19:20 chromatic We have to fix that first.
19:20 chromatic That's why I'm trying to figure out *why* EH has to extend Continuation.
19:21 whiteknight IT's too bad I wasn't able to find a good, comprehensive way to add in exit handlers to sbs
19:21 whiteknight subs
19:21 pmichaud not all eh's are static.
19:21 whiteknight There are just too many ways for control to leave a sub, and no good way to walk the contexts graph from one point to another
19:22 pmichaud or, more precisely, an eh doesn't have to be static.
19:22 chromatic I agree, but even still why does EH has to extend Continuation?
19:23 chromatic s/has/have/
19:23 atrodo chromatic> as opposed to?
19:23 whiteknight chromatic: That's as good a question as any. It does need to jump to a point in code which may be somewhere weird
19:23 NotFound It can contains a continuation instead.
19:23 chromatic What does an EH *need* to encapsulate?  The type of exceptions it handles and the opcode at which to begin its work.
19:23 pmichaud if we assume that eh's are always tied to the sub in which they are created, it doesn't have to be a continuation
19:24 pmichaud also, if we assume that the only way an eh might be invoked is by an exception
19:24 pmichaud i.e., one cannot invoke an eh directly
19:24 chromatic My assumption is that we can create read-only EHs.
19:24 chromatic Not all EHs have to be read-only, but many can be.
19:24 pmichaud so, we really want a special class of EH
19:25 pmichaud or, we want EH's that are continuation-based and EH's that aren't continuation based.
19:25 whiteknight EHs can be instantiated with a continuation or a sub, not just a label, right?
19:26 whiteknight I can't remember if that feature was ever added, or if it got removed, or whatever
19:26 pmichaud I've never found a good use case for it.
19:26 pmichaud I'm sure there is one.... but I haven't come up with it yet.
19:26 NotFound whiteknight: I think it was just an idea we talked about.
19:26 whiteknight ok
19:28 pmichaud nor have I yet come up with a case where I need to invoke an EH directly.  That might change if we try to optimize HLL 'return' to not use exceptions, though.
19:28 pmichaud ...which is entirely possible, given perl6's need for lexotic return.
19:30 pmichaud oh
19:30 pmichaud another possible reason for needing a continuation-based eh is the possibility of resuming from the handler.
19:30 pmichaud although in the case of 'return', there's generally no resume taking place.
19:31 pmichaud clearly in the case of gather/take we need to be able to do that resume.
19:31 betterworld I'm writing a dynpmc, and I have a method return a ResizablePMCArray with a bunch of newly created PMCs.  My test program shows erratic behaviour, indicating that memory is being reused too early
19:31 betterworld Do I need to tell the garbage collector that the memory shouldn't be reused or something?
19:31 chromatic Do you have a mark() and did you set the mark flag?
19:32 betterworld Unfortunately I couldn't get any hints from the docs or from looking at other source code
19:33 betterworld No.. well, I've read in the docs that most PMCs do not need a special mark method
19:33 chromatic Can you show us your code?
19:33 moritz maybe nopaste the co... /me too slow :-)
19:33 nopaste "betterworld" at 192.168.1.3 pasted "source code" (43 lines) at http://nopaste.snit.ch/23513
19:33 betterworld ah
19:34 betterworld I forgot to tell nopaste the channel the first time
19:34 jnthn Yes, you need to mark that STRING *
19:34 jnthn That'll be the problem.
19:34 pmichaud ummmmm
19:34 nopaste "betterworld" at 192.168.1.3 pasted "example output" (47 lines) at http://nopaste.snit.ch/23514
19:35 pmichaud yeah.
19:35 pmichaud auto_attrs doesn't take care of mark()?
19:35 jnthn No, just alloc/dealloc
19:35 chromatic It should, but it doesn't yet.
19:35 betterworld So I need to mark it right after I create it?
19:36 pmichaud you need a mark() vtable in Golf.
19:36 jnthn betterworld: YOu need to 1) have an init method that sets the flag saying it needs a custom mark, and then 2) what pmichaud just said
19:36 pmichaud afk, kid pickup
19:36 betterworld ah, and that mark vtable needs to flag my attrs
19:36 jnthn Correct
19:36 betterworld ok, thanks
19:39 NotFound pmichaud: an auto_attrs generated mark will be too risky giving the strange values people sometimes store in PMC *, like (PMC *)1
19:41 whiteknight who does (PMC *)1?
19:41 NotFound whiteknight: a sort of flag.
19:42 jnthn whiteknight: ;-)
19:42 jnthn Actually I don't think I have done that one...
19:42 jnthn :-)
19:42 jnthn I'd probably use a union. :-)
19:43 NotFound Maybe is no more in current codebase, but I have seen it.
19:44 kid51 joined #parrot
19:45 NotFound We live in a world when there are functions that declare BOOL return type and can return 0, 1, 2 and -1 X-)
19:45 NotFound (windows api)
19:45 ash_ thats scary
19:48 NotFound "I've seen things you people wouldn't believe..."
19:52 patspam left #parrot
19:53 allison joined #parrot
19:53 pmichaud anyway, all of my comments regarding slowness in nqp were meant to respond to the earlier assertion that nqp might be too slow for a parrot LWP implementation.  I think nqp would be speedy enough.
19:53 dalek rakudo: 1222485 | moritz++ | t/spectest.data:
19:53 dalek rakudo: run two more test files
19:53 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​2224852589433922e6ae657b73bbb2ac96e58b1
19:53 dalek rakudo: acc8fcb | moritz++ | build/PARROT_REVISION:
19:53 dalek rakudo: bump PARROT_REVISION to 2.8.0 release
19:53 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​cc8fcbdf15aa25e31992169ec47184a0d1a58ce
19:54 dalek rakudo: ac9fdb9 | moritz++ | t/spectest.data:
19:54 dalek rakudo: fix test nmae, moritz--
19:54 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​c9fdb9f4beee9ba3c6a46824028ce4934e3b88d
19:55 betterworld If those pmclasses that make use of (PMC*)1 have custom mark methods, I guess it would not be risky to have the default mark method mark all attributes :)
19:58 NotFound betterworld: maybe, but I doubt the possible benefit (not having to write a mark function) pays the cost of implementing and testing that feature.
20:01 whiteknight pmichaud: NQP probably wouldn't be too slow for a networking library. I am glad we did get to talking about performance issues though. Seems to have borne some fruit
20:02 whiteknight where NQP does have performance issues, they are very typically the result of problems in Parrot, and we want to identify those and fix the hell out of them
20:05 nwellnhof joined #parrot
20:05 NotFound In NQP they are issues but in parrot are problems? ;)
20:07 PerlJam NotFound: It's a problem for the underliying VM to be slowish, but just an issue for the HLL to be slowish because of its underlying VM.  :)
20:09 atrodo NotFound> I prefer to call them "opportunities" </phb>
20:10 ash_ left #parrot
20:11 nwellnhof r49204 broke the Rakudo build for me
20:12 dalek rakudo: 750a024 | moritz++ | docs/announce/2010.09:
20:12 dalek rakudo: [release] initial 2010.09 announcement
20:12 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​50a02453757aea2443311c6630c64c11b186dd6
20:12 pmichaud nwellnhof: that's possible.
20:13 pmichaud nwellnhof: right now we're sticking with 49193 until after the rakudo release.
20:13 nwellnhof yeah, it's just that i like to test some code against rakudo, and i allways rebase to parrot trunk.
20:14 pmichaud I'll see if I can figure out why rakudo is failing.
20:14 moritz is it bad that I used r49192 for build/PARROT_REVSION instead? (it's the last commit to trunk before the tag)
20:14 dukeleto nwellnhof: i've pinpointed the stress_strings.pir slowdown to r48585, which was your commit. Any ideas?
20:14 nwellnhof dukeleto: yes, it's because of the GC threshold changes. i think i mentioned it on IRC.
20:15 nwellnhof you should get the old results if you run with --gc-threshold=50
20:16 pmichaud nwellnhof: feel free to revert 49204 for now if you need to, though.
20:16 pmichaud it's easy to put it back again later after I have more time to test it with rakudo.
20:16 pmichaud I tested it with nqp-rx, and it worked fine there.
20:16 nwellnhof pmichaud: i can simply revert it my local branch, no problem
20:17 nwellnhof pmichaud: fyi, i get a segfault in Parrot_Continuation_init_pmc when building core.pir
20:18 pmichaud oh, that's weird.
20:18 nwellnhof shall i post a backtrace?
20:18 pmichaud I get the same error.
20:19 pmichaud yes, post backtrace please
20:19 pjcj left #parrot
20:20 nopaste "nwellnhof" at 192.168.1.3 pasted "Backtrace of segfault during build of core.pir" (28 lines) at http://nopaste.snit.ch/23515
20:21 chromatic Nothing obvious there.
20:21 Paul_the_Greek joined #parrot
20:21 pmichaud well, it's being called from Parrot_new_p_sc_ic
20:21 pmichaud which is the new code
20:22 dukeleto nwellnhof: that commit didn't change the THRESHOLD, at least not that I can see
20:23 nwellnhof dukeleto: yes, it did. back then it was hidden in a right shift (>>).
20:24 pjcj joined #parrot
20:25 NotFound pmichaud: maybe using ['ExceptionHandler'] instead of the plain string name is safer.
20:26 dukeleto nwellnhof: so the shift that changed from >> 1 to >> 2 is what you are talking about?
20:27 pmichaud NotFound: makes sense
20:27 pmichaud it's likely trying to convert the string into a class object and perhaps getting confused there?
20:28 NotFound pmichaud: not sure, there are some ugliness in the get_class functions
20:29 pmichaud the backtrace shows it's trying to build a Proxy PMC, which often indicates a get_class somewhere.
20:30 NotFound I think sometimes it gets a proxy when it should get the PMC.
20:30 mikehh #ps time
20:30 dukeleto nwellnhof: what was the reasoning for changing the threshold? Am I to understand that changing the threshold will not effect the bugs that got fixed in that commit?
20:32 NotFound Anyway, Continuation init_pmc need some check, it can just assume it's always called with a right type.
20:32 nwellnhof dukeleto: it's a speed/memory tradeoff. see here for some numbers: http://lists.parrot.org/pipermail/pa​rrot-dev/2010-September/004792.html
20:33 NotFound s/can/can't
20:34 nwellnhof dukeleto: and it doesn't affect the bug fixes.
20:40 dukeleto nwellnhof: i understand now. thanks. I am not sure what we want more: 30% speedup or 30% less memory use.
20:41 nwellnhof dukeleto: i think the 30% speedup is only for stress_strings. for the rakudo build it's about 10% speedup.
21:02 Andy I'm gonna get all up in the gc_massacre branch tonight
21:02 Andy CONSTING I WILL GO
21:07 theory left #parrot
21:13 ruoso left #parrot
21:14 estrabd left #parrot
21:16 estrabd joined #parrot
21:23 fperrad left #parrot
21:29 kid51 left #parrot
21:37 theory joined #parrot
21:37 mikehh Andy: try to make sure that any const-ing also works with g++
21:39 Andy mikehh: g++ is my go-to compiler.
21:40 Andy Because it is pickier than gcc
21:40 mikehh Andy: exactly :-}
21:48 NordQ joined #parrot
21:50 NordQ left #parrot
21:50 NordQ joined #parrot
21:52 NordQ left #parrot
21:52 NordQ joined #parrot
21:52 tadzik left #parrot
21:54 NordQ left #parrot
21:54 NordQ joined #parrot
21:55 NordQ left #parrot
22:02 bkuhn left #parrot
22:10 dalek parrot: r49206 | nwellnhof++ | trunk/src/pmc/nci.pmc:
22:10 dalek parrot: [pmc] Off-by-one error in NCI PMC
22:10 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49206/
22:10 dalek parrot: r49207 | chromatic++ | trunk/src/gc/system.c:
22:10 dalek parrot: [GC] Fixed a compiler warning.
22:10 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49207/
22:10 dalek parrot: r49208 | chromatic++ | trunk/src/runcore/main.c:
22:11 dalek parrot: [runcore] Fixed two compilation warnings.
22:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49208/
22:11 dalek parrot: r49209 | chromatic++ | trunk/src/runcore/trace.c:
22:11 dalek parrot: [runcore] Fixed a compiler warning.
22:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49209/
22:11 dalek parrot: r49210 | chromatic++ | trunk/src/packfile/pf_items.c:
22:11 dalek parrot: [pf] Fixed a compiler warning.
22:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49210/
22:11 dalek parrot: r49211 | chromatic++ | trunk/compilers/imcc/symreg.c:
22:11 dalek parrot: [IMCC] Fixed a compilation warning.
22:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49211/
22:11 dalek parrot: r49212 | chromatic++ | trunk (4 files):
22:11 dalek parrot: [ops] Fixed a compilation warning.
22:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49212/
22:18 dalek TT #1796 created by nwellnhof++: PIR heredocs and encodings
22:18 dalek TT #1796: http://trac.parrot.org/parrot/ticket/1796
22:21 whiteknight left #parrot
22:33 Paul_the_Greek left #parrot
22:44 dalek parrot: r49213 | Paul C. Anagnostopoulos++ | trunk/t/dynoplibs/trans-infnan.t:
22:44 dalek parrot: Clarify messages in test
22:44 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49213/
22:45 whiteknight joined #parrot
23:07 whiteknight my internet connection is T3H FAILZ
23:12 chromatic We call it "little rat"
23:12 ash_ joined #parrot
23:15 kid51 joined #parrot
23:18 dalek parrot: r49214 | bacek++ | branches/gc_massacre/src/gc/gc_ms2.c:
23:18 dalek parrot: Remove commented out code.
23:18 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49214/
23:18 dalek parrot: r49215 | bacek++ | branches/gc_massacre/src/gc/gc_ms2.c:
23:18 dalek parrot: Use self->gc_threshold for triggering m&s.
23:18 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49215/
23:23 whiteknight okay, for TT #254, is there objection to me merging in the method changes?
23:23 whiteknight I would like to, I don't think anybody really expressed much of a negative opinion towards it
23:26 cotto 254 was closed 17 months ago
23:27 whiteknight #264. sorry
23:31 Andy left #parrot
23:32 cotto The names are a bit unwieldy (I don't see why "_handle" is in there, given that stdin et al are handles), but it's an improvement.
23:34 cotto whiteknight++
23:39 s1n joined #parrot
23:47 whiteknight cotto: what names would you prefer?
23:49 kid51 left #parrot
23:49 cotto s/_handle//
23:53 kid51 joined #parrot
23:54 s1n left #parrot

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

Parrot | source cross referenced