Parrot 2.8.0 will be released at "2010-09-21 08:00 UTC" | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets; remove deprecated items (especially CodeString); record deprecations; polish for 2.8 release
Set by moderator on 20 September 2010.
whiteknight NotFound: :) 00:01
the word isn't bad. My use of the word was bad. You can call Winxed anything you want to call it 00:02
00:03 hercynium joined
whiteknight has to go. Goodnight 00:07
00:07 whiteknight left, muixirt_ joined
dalek website: jkeenan++ | Parrot Design Documents in Need of Overhaul 00:08
website: www.parrot.org/content/parrot-desig...d-overhaul
00:10 patspam joined, patspam left 00:11 muixirt left, muixirt_ is now known as muixirt 00:23 kid51 is now known as kid51_at_dinner 00:37 jsut joined 00:42 jsut_ left 00:46 muixirt left
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.
davidfetter waves to dukeleto from the caltrain 00:50
dukeleto davidfetter: werd 01:04
01:06 davidfetter left 01:33 kid51_at_dinner is now known as kid51
dalek TT #1231 closed by jkeenan++: src/pmc/hash.pmc: Use freeze in get_repr() (for hashes) 01:59
TT #1231: trac.parrot.org/parrot/ticket/1231
ash_ is there a specific person thats sorta the 'goto person' for os x issues for parrot? 02:13
02:34 s1n joined 02:35 davidfetter joined, janus left
dukeleto ash_: i used to be one of them, but went back to linux 02:40
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
dukeleto ash_: that would be appreciated 02:42
02:42 betterworld left
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
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:44
what other darwin issues are there? 02:47
kid51 You can do a query in Trac for that 02:48
02:48 janus joined
kid51 must sleep 02:48
purl Sleep is for the weak.
02:53 x3nU joined 02:59 betterworld joined 03:19 kid51 left 03:23 Andy joined 03:45 silug left 03:48 sjn_ left 03:50 s1n left
sorear <echosystm> python is a lie 03:59
classic
04:03 ash_ left
plobsing oh noes. the snake is a lie! 04:03
04:04 ash_ joined 04:26 ash_ left 04:56 hercynium left 04:57 necrolyte joined 04:58 lucian joined 05:02 necrolyte left 05:12 lucian left 05:21 Andy left 05:53 theory left
dukeleto blarg 05:53
06:58 fperrad joined 07:36 tadzik joined 07:40 gerd joined
gerd I want to start the checkout for release 2.8.0. Can I start with it now? 07:45
Nobody is again it - so I will start the update to version 2.8.0 07:48
"make world docs html" is still running 07:55
"make fulltest" is still running ... 07:57
"make fulltest" finished successful - so I do the commit now 08:04
The commit is done, I will run the tests now again with the sources from the 2.8.0 tarfile 08:07
dalek rrot: r49192 | gerd++ | trunk (10 files):
switch the version to 2.8.0
08:17 Tene left 08:20 mikehh left
gerd tests from the tarfile finished, I tagged the release 08:22
dalek rrot: r49193 | gerd++ | tags/RELEASE_2_8_0:
tagged release 2.8.0
 08:24
gerd ftp server is triggered; I will start writing the HTML page 08:27
cotto nice 08:31
gerd++
It's barely Tuesday for me and we've already got a release. 08:32
08:35 mikehh joined 08:42 Tanami left 08:47 Tanami joined 08:58 dalek left, dalek joined 09:00 dalek left 09:01 dalek joined 09:25 dip joined 09:30 muixirt joined
muixirt is someone working on cardinal? 09:33
cotto github.com/cardinal/cardinal/ 09:41
looks like nothing recent
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:42
dalek website: gerd++ | Parrot 2.8.0 "Tui Parakeet" Released! 09:44
website: www.parrot.org/news/2020/Parrot-2.8.0
Tanami :D 09:47
hooray
cotto no quote? 09:49
we'll let it go this time
gerd I changed the website to: www.parrot.org/news/2010/Parrot-2.8.0 09:58
I will send the e-mail after lunch 09:59
cotto clock?
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 /
gerd Happy hacking, bye! 10:00
cotto Mmmm. Future parrot.
bacek aloha, humans 10:01
10:01 gerd left
cotto aloha, bacek 10:01
bacek cotto, hi
I would like to declare gc_massacre mergeable back to trunk.
cotto ship it
jnthn bacek: What GC improvements does the branch bring? 10:02
jnthn wonders if it fixes the recursion problem... 10:03
moderator 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:03
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
E.g. GenGC
OTOH, I can fix recursion problem straight after merging back.
In new branch.
jnthn It'd be wonderful to have that fixed. 10:06
bacek++
cotto what's the recursion problem? 10:07
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
(We actually do hit it in Rakudo...)
cotto I remember that one.
10:08 tadzik left
bacek cotto, trac.parrot.org/parrot/ticket/1723 10:10
jnthn, however trac.parrot.org/parrot/ticket/1789#comment:9 :) 10:11
afk # dinner
dalek rrot: r49195 | bacek++ | branches/gc_massacre/t/op/string_cs.t:
Sync test with trunk
 10:12
rrot: r49196 | bacek++ | branches/gc_massacre/t/op/string_mem.t:
Fix string_mem test to use C<skip> instead of C<todo>
jnthn bacek: ooh! :-) 10:14
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
(i get an error build lua because of this (?))
erm, mixed up the versions 10:27
so that function has changed and lua didn't keep up
muixirt confused 10:28
purl You won't be after this episode of Soap!
10:36 kid51 joined
kid51 r49191: Darwin/PPC: make fulltest PASS 10:36
muixirt for the record: lua builds fine with parrot 2.8.0 10:37
10:54 sjn_ joined 10:58 ruoso left 11:00 whiteknight joined
dalek rrot: r49197 | mikehh++ | branches/gc_massacre/src/gc/gc_ms2.c:
[gc_massacre] fix codetest failures - replace ms with ms2 in ASSERT_ARGS and documentation
 11:03
rrot: r49198 | jkeenan++ | trunk/config/gen/makefiles/root.in:
Eliminate LIBPARROT dependency in LIBNCI_TEST_SO. See �trac.parrot.org/parrot/ticket/1130. (make reconfigure)
rrot: r49199 | mikehh++ | branches/gc_massacre/src/gc/fixed_allocator.c:
[gc_massacre] add ASSERT_ARGS
nopaste "kid51" at 192.168.1.3 pasted "gc_massacre branch: failure in t/pmc/filehandle.t" (55 lines) at nopaste.snit.ch/23504 11:11
whiteknight good morning, #parrot 11:12
my amd64 laptop is broken into dozens of little pieces, otherwise I would run some tests for the gc_massacre branch
kid51 That gc_massacre failure was at r 49196 11:13
Linux/i386
whiteknight kid51 # nice blog post! 11:16
kid51 whiteknight thx 11:29
mikehh bacek: ping 11:31
ttbot Parrot trunk/ r49179 i386-linux-thread-multi make error tt.taptinder.org/file/cmdout/396135.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 11:37
11:55 bkuhn joined
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:56
kid51: the t/pmc/filehandle.t test passes for me in gc_massacre (on amd64 though) 11:59
kid51 mikehh: I've tried it twice. Same results both times. 12:02
That most recent ttbot report is nearly 20 hours old and no longer relevant 12:06
12:07 gerd joined, gerd left
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
12:08 bkuhn left
kid51 3rd time fail on linux/i386 -- and I worked from make realclean up 12:17
kid51 to $job
12:17 kid51 left 12:19 kid51 joined 12:20 kid51 left 12:30 ruoso joined 12:36 bkuhn joined
whiteknight I'll give it a look on linux/i386 in a little while 12:38
12:50 ash_ joined 12:56 tadzik joined 13:02 patspam joined 13:16 davidfetter left 13:18 Psyche^ joined, Patterner left, Psyche^ is now known as Patterner
Coke Docs on parrot.org are showing 2.7.0-devel, WHOOPS. 13:31
(those have traditionally been release-only versions of the docs.)
13:43 tadzik1 joined 13:44 tadzik left, lucian joined 13:49 tadzik1 is now known as tadzik 14:02 davidfetter joined
dalek TT #1130 closed by jkeenan++: dependency problem for libnci_test 14:16
TT #1130: trac.parrot.org/parrot/ticket/1130
14:22 ash_ left 14:30 ash_ joined
whiteknight dukeleto: ping 14:30
14:30 Andy joined
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.
aloha OK. I'll deliver the message.
moritz whiteknight: you can look at rakudo's build/Makefile.in. It uses curl for uploading the reports 14:34
whiteknight yeah, I was thinking about that. That's Plan B 14:35
systems don't always have curl
but if you're running plumage, you do have parrot
moritz well, there's an HTTP client in parrot somewhere, no?
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
Coke added by leo about 8 years ago.
(the http stuff) no clue if it's maintained.
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
NotFound runtime/parrot/library/LWP/ ? 14:40
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.
whiteknight there's no good alternative though, if we're looking for decent performance 14:44
NQP is much easier to maintain, but obviously slower because of some of the lexicals issues that we've talked about, among other things
NotFound winxed can be an alternative 14:45
Or Close, if someone finishes it.
moritz would expect network performance to be the bottleneck for LWP
dalek rrot: r49200 | coke++ | trunk/config/gen/makefiles/root.in:
[build] fix a dep reported missing by tools/dev/checkdepend.pl
Coke or, call me crazy, we could make nqp faster. ;) 14:46
rather than finding YA workaround.
NotFound Not a bad idea,
moritz would love to see tcurtis' optimization framework in ext/ 14:47
then it would be much easier to use for nqp and rakudo
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.
moritz NotFound: C really is a workaround for assembler. 14:49
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...
Coke atrodo: that's pretty much parrot in a nutshell. ;) 14:51
NotFound Anyway, I would prefer a slow LWP that works rather than a fast one that works.... sometimes. 14:53
whiteknight getting NQP performance fixed is in no small way tied to the lvalue assignment problems that Parrot has 14:54
and fixing that is going to require somebody who's knowledgable about the issue to put down a concrete design for it
jnthn We should also be less stupid about lexicals generally 14:55
Why on earth do we look them up by name?
pmichaud I'm not sure I agree with that assessment.
jnthn That should be a last resort, not a first one.
NotFound We do?
jnthn (For the case where they're all statically known at compile time.)
$P0 = find_lex '$lol'
pmichaud since NQP doesn't have assignment, I don't see why it's a significant performance penalty.
find_lex isn't *that* expensive. 14:56
jnthn pmichaud: Individually, no...
whiteknight pmichaud: I may be mistakenly remembering old discussions
jnthn pmichaud: When you do enough of them, though...
pmichaud jnthn: even cumulatively I don't think it's that expensive.
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.
*swamps it
pmichaud jnthn: I'm thinking it's likely "everything else in Parrot..."
whiteknight pmichaud: what do you see as the major performance bottleneck in NQP?
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.
jnthn Yeah, but if we keep not optimizing stuff because the problem is "everything else"... :/
pmichaud for typical NQP programs, the major performance cost is in method call overhead and return exception handling, iirc. 14:58
whiteknight hmm...those are a little bit less straight-forward to fix 14:59
pmichaud ...and GC, of course.
muixirt pmichaud: method call overhead? Can explain that a bit more? 15:05
15:06 theory joined
pmichaud muixirt: method calls have traditionally been somewhat slow in Parrot 15:06
atrodo Is it a large cost in context initialization? 15:07
muixirt why?
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.
muixirt wonders what steps are necessary in parrot for a method call 15:12
15:13 lucian left 15:19 muixirt left
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:20
creating exception handlers to handle return exceptions is about 60% 15:21
jnthn omg
*60*?
pmichaud I go from 5.1sec to 2.2sec when I take out the return exception handler creation
whiteknight oi
atrodo That seems quite excessive
pmichaud that does seem excessive, now that I think about it. 15:22
jnthn pmichaud: Is that just creating the handlers?
moritz so an optimization that simply removes the return() where possible would be quite welcome
pmichaud moritz: I'm not making a return()
jnthn pmichaud: Or also throwing the return exception and catching it?
Wow!
pmichaud I'm simply creating the handler -- not throwing the exception.
just a sec.
NotFound pmichaud: what is the code that creates control exception handlers in nqp? 15:23
pmichaud new $P15, 'ExceptionHandler'
set_addr $P15, control_14
$P15."handle_types"(.CONTROL_RETURN)
push_eh $P15
atrodo So, as the new guy, this would be like installing a try block? 15:24
pmichaud the handle_types calls accounts for 40%
jnthn Youch, that's a method call and what looks like a slurpy taking METHOD.
NotFound handle_types is a method with slurpy param, that may be a noticeable part of the cost.
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.
pmichaud jnthn: because each closure needs its own continuation.
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.
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
pmichaud yes, method calls are expensive :-) 15:26
at least for NQP and Rakudo, I think this is the only exception handler that is looking for just one type, though. 15:27
all of the others look for a subset of types. 15:28
afk for a few minutes
15:29 JimmyZ joined
ash_ why are the handler's needed? to create continuations? 15:29
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:30
JimmyZ remembers trac.parrot.org/parrot/wiki/WhyDoes...icientCode 15:32
NotFound ack '.CONTROL_RETURN' in ext/nqp-rx shows a lot of usages 15:37
jnthn NotFound: Every sub 15:38
(in the Perl 6 sense of sub, not the Parrot one)
NotFound I can try a hack for ExceptionHandler but don't how to do a quick speed test of it. 15:40
15:41 ruoso left
NotFound s/don't/don't know 15:41
Coke create a branch, let pmichaud test it. ;) 15:42
NotFound Coke: a branch ow what? parrot? nqp? both?
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 :-)
*he
Coke I don't know what you're changing, but if it's nqp source, there, and if it's parrot source, here?
or just wait. ;)
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:44
Coke: the idea is simple: add init_int vtable to ExceptionHandler and use the int value as type handled. 15:45
Easy to write, hard to test for me. 15:46
Coke that will only work when you're trying to handle a single type, yes? 15:47
(might also need an init_pmc that takes an RPA/List/something) 15:48
but that's a good first step, I bet.
NotFound++
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.
pmichaud handling a single type (.CONTROL_RETURN) is useful.
we have a lot of return handlers.
(one per logical subroutine)
github.com/perl6/nqp-rx/blob/master...es/fib.nqp # my fib.nqp test program 15:49
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
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? ...
pmichaud pct generates the handler creation
look for control_pir, iirc
NotFound Maybe I can test it, then.
dalek p-rx/master: f59925c | pmichaud++ | examples/fib.nqp:
Add fib.nqp as a recursion benchmark example.
pmichaud I'll be happy to run tests here.
NotFound src/PAST/Node.pir 15:51
524:value "return_pir" generates code to handle C<CONTROL_RETURN> exceptions.
This one?
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)
pmichaud that's it... "return_pir"
NotFound src/PAST/Compiler.pir ? 15:52
pmichaud line 970
NotFound Looks easy to change. I'll give it a try. 15:53
15:53 davidfetter left
pmichaud oh, wait 15:53
lines 934-937 15:54
that's the part that generates the handler
the other part is the handler itself (probably doesn't need modification)
Coke which file is this?
NotFound bpost.'push_pirop'('new', $S0, "'ExceptionHandler'") and following, isn't it?
pmichaud compilers/pct/src/PAST/Compiler.pir
Coke oh, PAST, not PCT.
danke.
15:55 davidfetter joined
pmichaud hmmm 15:58
15:58 davidfetter left
pmichaud commenting out the push_eh step runs 14% faster 15:58
that's.... weird also.
maybe we're seeing gc interactions here. 15:59
jnthn pmichaud: That's kinda scary. We have a *lot* of very short subs/methods.
pmichaud I wonder if push_eh is forcing the generation of additional RPA's (one per context)
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
pmichaud gist.github.com/589930 # cost of push_eh step 16:01
feels like push_eh ought to be a lot faster than that. 16:02
NotFound Parrot_cx_add_handler_local creates a RPA when the first handler is added. 16:04
16:05 JimmyZ joined 16:06 davidfetter joined 16:08 ruoso joined
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:08
atrodo ash_> Nope, it's not suppose to. I just never finished it :D 16:10
ash_ ah, got ya
nopaste "NotFound" at 192.168.1.3 pasted "patch: testing a shortcut for handlers of .CONTROL_RETURN" (44 lines) at nopaste.snit.ch/23508 16:18
16:19 wow left 16:22 JimmyZ left
whiteknight I suggest that maybe the first handler pushed should not create an RPA, but just be used by itself 16:33
additional handlers can create an RPA when/if they are pushed
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:34
16:41 chromatic joined 16:43 davidfetter left, davidfetter joined
whiteknight good morning, chromatic 16:44
chromatic aloha 16:45
dukeleto howdy, folks
whiteknight I had an idea this morning about creating NCI method PMCs lazily
dalek rrot: r49201 | nwellnhof++ | trunk (2 files):
[io] Fix Parrot_io_read_utf8 with 3-byte chars
dukeleto chromatic: did you see my msg about the stress_strings.pir slowdown ?
chromatic That'd be handy.
whiteknight it seems to me like initializing and installing all those PMCs is quirte expensive
chromatic dukeleto, I did.
The MultiSubs for PMCs are spendy. 16:46
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.
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
chromatic: i am also interested to see how stress_strings.pir does on gc_massacre
purl okay, dukeleto.
dukeleto whiteknight: just saw your mesage. examples/io/post.pir 16:49
chromatic I thought that example only changed a threshold.
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:51
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:53
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.
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
whiteknight dukeleto: This is sounding more and more like the grand test framework project I want to implement
dukeleto whiteknight: have you given any more thought to including kakapo in PLA? 16:55
whiteknight what do you mean?
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
PLA only uses the unit test portions of kakapo, nothing else. I'm thinking about forking that portion, or writing something like it
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
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
I've got instructions for how to get the correct version of kakapo and everything
that examples/io/post.pir looks extremely similar to the smolder upload code in distutils 16:59
dukeleto whiteknight: good to hear, i will try your new release when it hits the interwebs 17:02
dalek rrot: r49202 | fperrad++ | trunk/runtime/parrot/library/LWP/Protocol.pir:
[LWP] handles an IO error
dukeleto whiteknight: yes, post.pir is basically the same code that is in distutils
17:07 Andy joined 17:16 sjn is now known as _sjn
NotFound whiteknight: the idea about the first handler has a problem: the handlers list is managed by direct access from several places. 17:17
whiteknight ha, doesn't surprise me 17:18
17:18 sjn_ is now known as sjn
pmichaud gist.github.com/590074 # effect of NotFound++'s init_int patch on fib.nqp 17:20
Coke 4.85194206237793 / 3.39949893951416 17:21
purl 1.4272521182405
aloha 1.4272521182405
pmichaud rakudo: (4.85-3.40)/4.85
purl 0.298969072164948
Coke purl, play in traffic.
purl Coke: huh?
p6eval rakudo be80e9: ( no output )
pmichaud hard to argue with a 30% speedup. :)
Coke I'd say ship it. ;) 17:22
pmichaud too bad we didn't do this before the release :-|
NotFound 30% ? I'm amazed
Coke pmichaud: next release is always better. :|
pmichaud I'm not. we avoid a method call.
ash_ is that only 1 method call's difference between the two? 17:23
pmichaud basically, yes.
Coke that one call is repeated many times.
(yes?)
pmichaud it's one call per invocation, yes.
NotFound And some less bytes for sub implied.
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.
NotFound Commit it, then?
pmichaud I'll commit, yes.
I'm reworking the PAST::Compiler change slightly, and need to do a full test.
(need to make sure nqp still works with the change) 17:25
NotFound pmichaud: ok
pmichaud can I get rid of the ** TESTING ** note?
(in init_int() ?)
NotFound pmichaud: sure
dukeleto whiteknight: nice work on the github pages for PLA. very sexy
ash_ how hard/long are method lookups?
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
Coke url?
whiteknight Coke: whiteknight.github.com/parrot-linear-algebra/
I'm not colorblind, I'm just extremely non-artistic
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_
Coke any other places in compilers/ that can benefit from this update? 17:27
oh, needs tests, too. :|
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.
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 :)
NotFound pmichaud: but creates an array pmc during the call
ash_ whiteknight: you have an error in your html, <h1>Parrot-Linear-Algebra</h2> is probably not what you meant to do
NotFound Ah, yes, the array is reused.
pmichaud although the fixedintegerarray is probably more efficient 17:29
whiteknight ash_: damnit! Thanks for pointing out my fail
ash_ whiteknight: in my browser, the entire site is in H1 STYLE BIG FONT
pmichaud Coke: I don't know that anything uses .CONTROL_RETURN other than things generated via pct and/or nqp.
NotFound likes w3c validator
ash_ no problem
dukeleto ash_: are you using lynx ?
ash_ nope, chrome 17:30
but if you curl the page
the html tag was kinda obviously the cause </h2> should of been </h1>
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.
(other than .CONTROL_RETURN)
Coke worth a simple ack. ;) 17:32
pmichaud simple ack doesn't come up with any single-argument handle_types calls that aren't .CONTROL_RETURN 17:34
(well, there are some, but none significant) 17:35
(mostly in t/)
NotFound pmichaud: In tests I use single arg a lot, but just for checking that throws the expected type. 17:37
Coke in git, can you checkout a tag? 17:39
whiteknight git checkout <tag_name>
Coke (instead of a branch)
ok. how can I tell if I've done that already? ;)
whiteknight "git tag"? 17:40
Coke git tag shows a list of tags.
pmichaud git status?
purl git status is probably porcelain
Coke (I don't see any special annotations)
in tag or status.
pmichaud iirc, if it says you're on a branch, then you haven't done that. 17:41
(e.g., if it says you're on branch master, then you are really on master and not a tag)
Coke danke.
ugh. now to re-re-fix git through corporate firewall. 17:42
jnthn Wow, we get 30% win?! :-) 17:44
pmichaud in that example, yes.
it would obviously be less of a win if the sub were more complex.
jnthn pmichaud++, NotFound++
Right, but we have quite a lot of short subs/methods too.
pmichaud correct. 17:45
no matter how you slice it, we made an expensive+common operation much less expensive.
jnthn That's what we need. :-)
pmichaud next is to see if we can improve push_eh
jnthn *nod*
And when you improve them, what % of the time *then* is messing with lexicals. :-) 17:46
s/them/that/
Coke hurm. "git checkout <tag name> ;git status" - "not currently on any branch" ... no mention of the tag itself.
pmichaud oddly, it was still 10% in my preliminary test
jnthn Oddness.
pmichaud i.e., instead of saving 0.5 seconds, it only saved 0.3
(okay, 15%.)
ish.
Coke: it only knows the commit your on, not the tag.
*you're
although git-describe might indicate the tag. 17:47
dukeleto you may need "git describe --tags" 17:49
gerd++ # another solid release 17:52
NotFound gerd++ 17:53
Coke dukeleto++ #that's what I'm looking for, thanks.
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:58
pmichaud dukeleto: not yet. 17:59
I wasn't planning to use
I wasn't planning to use "git describe" for that, necessarily.
gist.github.com/590149 # effect of additional (and possibly unneeded) find_lex opcodes on fib.nqp 18:04
chromatic 10% there 18:05
pmichaud but it takes a lot of analysis to determine that the find_lex is in fact unnecessary 18:06
(and in the general case might not be knowable)
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.
jnthn pmichaud: So you can get it down to a few pointer follows, rather than a bunch of hash lookups.
pmichaud: That's what I've (partially) done in 6model.
chromatic That's what Perl 5 does.
pmichaud in this case it'd be an upper-bound improvement of 10%, though.
davidfetter it's all it ever does!
pmichaud (in the case of nested blocks, it'd probably be greater)
davidfetter oh, wait. wrong movie
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 :)
gist.github.com/590171 # cost of push_eh opcode 18:10
rakudo: (3.40-2.84)/3.40
purl 0.164705882352941
p6eval rakudo be80e9: ( no output )
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
pmichaud dukeleto: you can tell git-describe to only report specific tags or tags matching a pattern 18:11
dalek rrot: r49203 | pmichaud++ | trunk/src/pmc/exceptionhandler.pmc:
Patch to add init_int() VTABLE function for ExceptionHandler. Courtesy NotFound++ .
rrot: r49204 | pmichaud++ | trunk/compilers/pct/src/PAST/Compiler.pir:
[pct]: Update PCT 'return_pir' generation to use newp_s_ic opcode instead of "handle_types" methodcall.
rrot: r49205 | pmichaud++ | trunk/t/pmc/exceptionhandler.t:
[core]: Add test for init_int initialization of ExceptionHandler PMC.
dukeleto pmichaud: that sounds useful. Time to go read the man page again
chromatic 16.48% there. 18:12
pmichaud dukeleto: I was thinking that simpler might be to make sure that a given commit appears in the history. 18:14
as opposed to worrying about tags.
(one could also check that a given tag appears in the history.)
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:15
pmichaud: perhaps that should change 18:16
Coke dukeleto: if it simplifies the conversion, go fo rit.
pmichaud oh yes, it would require the repo.
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
Coke if someone is strongly opposed, they can do something post-git
pmichaud anyway, my preference would be to do things similar to how rakudo manages it now 18:18
i.e., it gets its version number from the output of git-describe with a --match option.
and records that.
git describe --match '2*' # what rakudo currently uses to embed a revision number 18:19
dukeleto pmichaud: where does that code live?
pmichaud build/gen_version.pl
so then we end up with:
pmichaud@plum:~/rakudo$ ./perl6 --version 18:20
This is Rakudo Perl 6, version 2010.08-119-gccde8dc built on parrot 2.7.0 r49091
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"
and we'd assume that a parrot reporting "2010.09" would always be after "2010.08" 18:21
chromatic That's doable.
pmichaud since parrot uses n.x.y tags, though, it'd probably need to be "2.8.0-50" 18:22
which would be fine also
it gets very nasty/tricky though with things like 2.8.1
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
pmichaud: yes, version numbers suck.
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. ;)
since 2.8.1 could be a single bug fix over 2.8.1, and missing all of 2.8.0-100
(assuming a linear flow seems LTA.) 18:24
pmichaud Coke: would 2.8.1 be tagged in master?
Coke I don't know what "in master" means in this context.
it would be tagged, sure.
pmichaud the master branch of the parrot repo.
currently gen_parrot.pl always grabs from the trunk/master branch 18:25
Coke I've said before that's not a sustainable thing. ;)
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
"sustainable" shows up when we're able to restrict development to parrot releases.
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.
pmichaud I don't see that happening before 4.0.0
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?
s/sync to/require/
which is unchanged from today.
pmichaud PARROT_REVISION curre.... right
Coke so we're not losing any functionality, so <shrug> 18:28
pmichaud so, why is push_eh so expensive?
chromatic Besides the method call to set its type? 18:30
pmichaud ...method call?
jnthn pmichaud: push_eh $P0 18:31
(the pmc variant)
?
pmichaud jnthn: yes.
ash_ can we profile it?
pmichaud it appears to always need a ResizablePMCArray for the context. 18:32
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
pmichaud if we could set it so that the first handler pushed doesn't require an RPA, that'd be a win.
jnthn e.g. it does multiple gets on the same thing.
pmichaud I thought that had been done already... but apparently not.
...multiple gets on the same thing? 18:34
NotFound pmichaud: is a bit complicated, the array is accessed from several places.
whiteknight what would it take to clean it up so it wasn't accessed from several places?
jnthn oh, it only reads from a struct 18:35
pmichaud: It does Parrot_pcc_get_handlers twice
NotFound scheduler.c and the Scheduler pmc are the ones I've positively found. Maybe more.
jnthn pmichaud: I thought maybe that was costly but it's not
pmichaud: It's a macro encapsulating a struct access by the looks of it.
So yeah, the most expensive thing I can see it doing is making the RPA. 18:36
pmichaud is making an RPA that expensive?
chromatic It's not cheap.
pmichaud yes, that appears to be the cost. 18:37
jnthn :S 18:38
jnthn is a bit surprised it's that costly.
pmichaud (I replaced push_eh with $P0 = new ['ResizablePMCArray'] and got essentially the same time.
NotFound unshift is not cheap. Let me try a tiny change...
pmichaud unshift onto an empty RPA ought to be relatively cheap.
chromatic What's the benchmark code? 18:39
pmichaud chromatic: fib.nqp compiled to .pir
nopasting
gist.github.com/590253 # benchmark code 18:40
chromatic Thanks.
pmichaud when we started, that was taking 5.0 sec
jnthn Why does it unshift rather than push?
The order doesn't matter at all, no?
pmichaud jnthn: because you add new handlers to the top of the stack 18:41
jnthn oh...OK
pmichaud it doesn't matter if there's not already a list.
jnthn So it does matter
dalek tracwiki: v144 | fperrad++ | Languages
tracwiki: update Parrot version 2.8.0
tracwiki: trac.parrot.org/parrot/wiki/Languag...ction=diff
jnthn pmichaud: Not in this case, no
oh, it looks like it unconditionally calls memmove 18:43
unshift_pmc calls do_unshift(INTERP, SELF, value);
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.
pmichaud it'd be trivial to add an "if (size)" check, though. 18:46
or "if (size > 0)"
still, I agree that's not likely an expense.
the real cost is in creating the RPA
chromatic I'm getting a real profile here.
Hm, looks like the deps for parrot-nqp aren't all there. 18:47
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:49
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.
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?
chromatic the NQP
pmichaud ah 18:54
so that includes the cost of compilation
chromatic 9.5% of runtime.
I'm sorry. I mean the NQP compiled to PIR.
pmichaud okay
chromatic Running the generated .pir directly.
pmichaud and that's the cost of running the entire .pir directly
as opposed to just the cost of the fib() subroutine
chromatic Right.
pmichaud okay.
ooc, what's the cost of the push_eh instruction? 18:55
chromatic 0.3% of runtim
e
pmichaud how about including the things it calls?
chromatic 9.8% of runtime 18:56
pmichaud okay.
push_eh gets called a *lot*, and generally there's one per context.
optimizing that would seem to be a really nice win.
chromatic We should rethink how this works. 18:57
There's basically an exception handler active for the entire sub.
Seems like we could know that at compilation time. 18:58
It's a Sub property, isn't it?
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.
pmichaud But yes, we know at compile time if this Sub wants a return exception handler.
chromatic So we shouldn't have to fiddle with all of this mess at runtime.
pmichaud we still have to create the continuation
(which is what the handler is)
chromatic Is there no way we can avoid it? 19:00
whiteknight I'm sure there's something
pmichaud not from my tests.... continuations are tied to the context that created them
whiteknight because this is absud
absurd
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.
jnthn chromatic: It needs to catch exceptions thrown from nested scopes too.
That is, return exceptions.
whiteknight right That's the rub right there. Nested subroutines
pmichaud nested *blocks*
(in the HLL sense) 19:02
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.
chromatic Maybe we should store these exception handlers with Subs, not Contexts. 19:04
pmichaud we still need to create the continuation, though.
chromatic Why?
pmichaud so we know what context to return to when it's invoked? 19:05
(when the exception is thrown and the handler is invoked?)
chromatic Why does that need to be a property of the exception handler?
pmichaud let me clarify slightly, then. 19:06
are we limiting our discussion to handlers for return exceptions?
as opposed to other exception handlers that might exist?
chromatic Sure, if that helps.
pmichaud or, phrased differently 19:07
are we only talking about handlers that are tied to an entire Parrot sub dynamic scope?
chromatic Yes.
tadzik trac.parrot.org/parrot/wiki/Languages -- where are the svn links here? I cannot find the LOLCODE repo url, is it even written anywhere?
pmichaud because we definitely have handlers that are not so tied, and they still have to be accommodated
dalek TT #502 closed by cotto++: [PATCH] build on OpenBSD/ppc 19:09
TT #502: trac.parrot.org/parrot/ticket/502
pmichaud I suppose it'd be possible to create a single exception handler and tie it to a Sub PMC 19:10
to be shared across all of that Sub PMC's clones/contexts
when I tried it before, it failed (more)
the problem was that the shared ExceptionHandler was always tied to the (original) Sub PMC that created it. 19:11
rephrase
the shared ExceptionHandler was always tied to the original context that created it
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.
chromatic Sure, and that's the source of a lot of these problems.
Seems to me that finding the right EH means unwinding all of your contexts. 19:13
When you've found the EH, you've found a context.
You even know the opcode where you want to start executing the handler.
pmichaud where's the "find the right EH" code? 19:14
chromatic Right now, I don't remember.
Parrot_ex_find_handler_local() or something.
pmichaud if we can extend that...
19:15 preflex left
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.
pmichaud i.e., we can attach handlers to subs that are assumed to be in force from the invocation of the sub
subclass of Sub gets nasty, in general.
chromatic It shouldn't have to.
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?
chromatic type check
pmichaud I'd prefer to have handler as a property of all subs, in general.
no, I mean when I'm generating code
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)
chromatic Ultimately the PIR/PBC generator should handle that.
19:17 preflex joined
chromatic Yes, my hands waved a little. 19:17
pmichaud the problem with subclasses is when they need to be mixed
for example, how do I get Coroutine with handler?
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.
whiteknight there was, at one point, an :instance_of() modifier for subs
I don't know if it was ever implemented, or if it's just a figment of documentation
pmichaud whiteknight: yes, that was an early attempt to differentiate subs in Rakudo and it didn't go well
because it requires compile-time knowledge of all of the possible Sub PMCs
chromatic Until we get a better metamodel for PMCs, I guess we fatten up Sub some then.
whiteknight it seems like we could either pass it in as an argument, or as a parameter 19:19
foo(:needs_handler)
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.
We have to fix that first.
That's why I'm trying to figure out *why* EH has to extend Continuation.
whiteknight IT's too bad I wasn't able to find a good, comprehensive way to add in exit handlers to sbs 19:21
subs
pmichaud not all eh's are static.
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
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?
s/has/have/ 19:23
atrodo chromatic> as opposed to?
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
NotFound It can contains a continuation instead.
chromatic What does an EH *need* to encapsulate? The type of exceptions it handles and the opcode at which to begin its work.
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
also, if we assume that the only way an eh might be invoked is by an exception 19:24
i.e., one cannot invoke an eh directly
chromatic My assumption is that we can create read-only EHs.
Not all EHs have to be read-only, but many can be.
pmichaud so, we really want a special class of EH
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?
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.
I'm sure there is one.... but I haven't come up with it yet.
NotFound whiteknight: I think it was just an idea we talked about.
whiteknight ok
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
...which is entirely possible, given perl6's need for lexotic return.
oh 19:30
another possible reason for needing a continuation-based eh is the possibility of resuming from the handler.
although in the case of 'return', there's generally no resume taking place.
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
Do I need to tell the garbage collector that the memory shouldn't be reused or something?
chromatic Do you have a mark() and did you set the mark flag?
betterworld Unfortunately I couldn't get any hints from the docs or from looking at other source code 19:32
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?
moritz maybe nopaste the co... /me too slow :-)
nopaste "betterworld" at 192.168.1.3 pasted "source code" (43 lines) at nopaste.snit.ch/23513
betterworld ah
I forgot to tell nopaste the channel the first time 19:34
jnthn Yes, you need to mark that STRING *
That'll be the problem.
pmichaud ummmmm
nopaste "betterworld" at 192.168.1.3 pasted "example output" (47 lines) at nopaste.snit.ch/23514
pmichaud yeah. 19:35
auto_attrs doesn't take care of mark()?
jnthn No, just alloc/dealloc
chromatic It should, but it doesn't yet.
betterworld So I need to mark it right after I create it?
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
pmichaud afk, kid pickup
betterworld ah, and that mark vtable needs to flag my attrs
jnthn Correct
betterworld ok, thanks
NotFound pmichaud: an auto_attrs generated mark will be too risky giving the strange values people sometimes store in PMC *, like (PMC *)1 19:39
whiteknight who does (PMC *)1? 19:41
NotFound whiteknight: a sort of flag.
jnthn whiteknight: ;-) 19:42
Actually I don't think I have done that one...
:-)
I'd probably use a union. :-)
NotFound Maybe is no more in current codebase, but I have seen it. 19:43
19:44 kid51 joined
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
(windows api)
ash_ thats scary
NotFound "I've seen things you people wouldn't believe..." 19:48
19:52 patspam left 19:53 allison joined
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 kudo: 1222485 | moritz++ | t/spectest.data:
run two more test files
kudo: acc8fcb | moritz++ | build/PARROT_REVISION:
bump PARROT_REVISION to 2.8.0 release
kudo: ac9fdb9 | moritz++ | t/spectest.data:
fix test nmae, moritz--
 19:54
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:55
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. 19:58
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:01
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:02
20:05 nwellnhof joined
NotFound In NQP they are issues but in parrot are problems? ;) 20:05
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:07
atrodo NotFound> I prefer to call them "opportunities" </phb> 20:09
20:10 ash_ left
nwellnhof r49204 broke the Rakudo build for me 20:11
dalek kudo: 750a024 | moritz++ | docs/announce/2010.09:
[release] initial 2010.09 announcement
 20:12
pmichaud nwellnhof: that's possible.
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.
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)
dukeleto nwellnhof: i've pinpointed the stress_strings.pir slowdown to r48585, which was your commit. Any ideas?
nwellnhof dukeleto: yes, it's because of the GC threshold changes. i think i mentioned it on IRC.
you should get the old results if you run with --gc-threshold=50 20:15
pmichaud nwellnhof: feel free to revert 49204 for now if you need to, though. 20:16
it's easy to put it back again later after I have more time to test it with rakudo.
I tested it with nqp-rx, and it worked fine there.
nwellnhof pmichaud: i can simply revert it my local branch, no problem
pmichaud: fyi, i get a segfault in Parrot_Continuation_init_pmc when building core.pir 20:17
pmichaud oh, that's weird. 20:18
nwellnhof shall i post a backtrace?
pmichaud I get the same error.
yes, post backtrace please 20:19
20:19 pjcj left
nopaste "nwellnhof" at 192.168.1.3 pasted "Backtrace of segfault during build of core.pir" (28 lines) at nopaste.snit.ch/23515 20:20
chromatic Nothing obvious there. 20:21
20:21 Paul_the_Greek joined
pmichaud well, it's being called from Parrot_new_p_sc_ic 20:21
which is the new code
dukeleto nwellnhof: that commit didn't change the THRESHOLD, at least not that I can see 20:22
nwellnhof dukeleto: yes, it did. back then it was hidden in a right shift (>>). 20:23
20:24 pjcj joined
NotFound pmichaud: maybe using ['ExceptionHandler'] instead of the plain string name is safer. 20:25
dukeleto nwellnhof: so the shift that changed from >> 1 to >> 2 is what you are talking about? 20:26
pmichaud NotFound: makes sense 20:27
it's likely trying to convert the string into a class object and perhaps getting confused there?
NotFound pmichaud: not sure, there are some ugliness in the get_class functions 20:28
pmichaud the backtrace shows it's trying to build a Proxy PMC, which often indicates a get_class somewhere. 20:29
NotFound I think sometimes it gets a proxy when it should get the PMC. 20:30
mikehh #ps time
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?
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: lists.parrot.org/pipermail/parrot-d...04792.html
NotFound s/can/can't 20:33
nwellnhof dukeleto: and it doesn't affect the bug fixes. 20:34
dukeleto nwellnhof: i understand now. thanks. I am not sure what we want more: 30% speedup or 30% less memory use. 20:40
nwellnhof dukeleto: i think the 30% speedup is only for stress_strings. for the rakudo build it's about 10% speedup. 20:41
Andy I'm gonna get all up in the gc_massacre branch tonight 21:02
CONSTING I WILL GO
21:07 theory left 21:13 ruoso left 21:14 estrabd left 21:16 estrabd joined 21:23 fperrad left 21:29 kid51 left 21:37 theory joined
mikehh Andy: try to make sure that any const-ing also works with g++ 21:37
Andy mikehh: g++ is my go-to compiler. 21:39
Because it is pickier than gcc 21:40
mikehh Andy: exactly :-}
21:48 NordQ joined 21:50 NordQ left, NordQ joined 21:52 NordQ left, NordQ joined, tadzik left 21:54 NordQ left, NordQ joined 21:55 NordQ left 22:02 bkuhn left
dalek rrot: r49206 | nwellnhof++ | trunk/src/pmc/nci.pmc:
[pmc] Off-by-one error in NCI PMC
 22:10
rrot: r49207 | chromatic++ | trunk/src/gc/system.c:
[GC] Fixed a compiler warning.
rrot: r49208 | chromatic++ | trunk/src/runcore/main.c:
[runcore] Fixed two compilation warnings.
rrot: r49209 | chromatic++ | trunk/src/runcore/trace.c:
[runcore] Fixed a compiler warning.
rrot: r49210 | chromatic++ | trunk/src/packfile/pf_items.c:
[pf] Fixed a compiler warning.
rrot: r49211 | chromatic++ | trunk/compilers/imcc/symreg.c:
[IMCC] Fixed a compilation warning.
rrot: r49212 | chromatic++ | trunk (4 files):
[ops] Fixed a compilation warning.
TT #1796 created by nwellnhof++: PIR heredocs and encodings 22:18
TT #1796: trac.parrot.org/parrot/ticket/1796
22:21 whiteknight left 22:33 Paul_the_Greek left
dalek rrot: r49213 | Paul C. Anagnostopoulos++ | trunk/t/dynoplibs/trans-infnan.t:
Clarify messages in test
 22:44
22:45 whiteknight joined
whiteknight my internet connection is T3H FAILZ 23:07
chromatic We call it "little rat" 23:12
23:12 ash_ joined 23:15 kid51 joined
dalek rrot: r49214 | bacek++ | branches/gc_massacre/src/gc/gc_ms2.c:
Remove commented out code.
 23:18
rrot: r49215 | bacek++ | branches/gc_massacre/src/gc/gc_ms2.c:
Use self->gc_threshold for triggering m&s.
whiteknight okay, for TT #254, is there objection to me merging in the method changes? 23:23
I would like to, I don't think anybody really expressed much of a negative opinion towards it
cotto 254 was closed 17 months ago 23:26
whiteknight #264. sorry 23:27
23:31 Andy left
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:32
whiteknight++ 23:34
23:39 s1n joined
whiteknight cotto: what names would you prefer? 23:47
23:49 kid51 left
cotto s/_handle// 23:49
23:53 kid51 joined 23:54 s1n left

Powered by Cro and the Raku® Programming Language.

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

Thank you!