Parrot 1.8.0 Zygodactyly released | Priority: trac.parrot.org/parrot/wiki/ClassV...eOverrides | Latest modified TT's: icanhaz.com/parrotbugs | Parrot Languages: icanhaz.com/parrotlang
Set by moderator on 5 December 2009.
00:12 theory joined
cotto chromatic, ping 00:31
00:36 mikehh joined
cotto chromatic, unping. I'll catch you later. 00:37
chromatic Okay. 00:38
dalek rrot: r42903 | pmichaud++ | trunk/compilers/pct/src/PAST/Compiler.pir:
[pct]: Allow PAST::Val int constants to auto-promote to num constants
 00:43
01:28 chromatic joined 01:46 patspam joined
dalek TT #1360 created by jpaton++: "smoke_languages.pl" doesn't deal with spaces in paths 02:30
dukeleto is benching oofib.pir across all parrot releases and trunk 02:31
dalek pir: f72cd79 | dukeleto++ | TODO:
Update TODO with info about tests
 02:32
dukeleto prepare for hard truths
02:36 mikehh joined
dukeleto mikehh: what is the fastest "make fulltest" that you can get with only one core? what is the fastest with however many cores you have? 02:37
02:37 kid51 joined 02:43 mikehh joined 02:48 mikehh joined 02:55 mikehh joined
dalek TT #1353 closed by dukeleto++: svn:ignore-ing too many things in t/ 03:03
dukeleto msg chromatic oofib.pir bechmark: gist.github.com/250024 03:14
purl Message for chromatic stored.
dukeleto looks like parrot trunk is faster than 1.4,1.6-1.8, but older parrots are all faster. trunk is 35% slower than 0.8.1 03:16
dukeleto is running the gc_waves_sizeable_data.pasm benchmark now 03:24
kid51 What figure do you have for trunk now? 03:26
Oh, I see. I was misreading chart. 03:27
dukeleto kid51: just about as fast as 1.5.0 03:31
kid51: for oofib.pir
kid51 Do we have any idea why our speed went down (say, after 0.8)?
dukeleto kid51: i haven't benched anything before 0.8.1 . where are they? 03:32
kid51 I don't know. 03:33
dukeleto kid51: i think they are on the backpan 03:34
here are some oldies: backpan.perl.org/authors/id/P/PM/PMIC/ 03:36
and here are the real oldies: backpan.cpan.org/authors/id/L/LT/LTOETSCH/ 03:41
my benchmarks are going to get a lot more interesting :)
there were so many releases in 0.4.x !
msg chromatic gc_waves_sizeable_data.pasm bechmark gist.github.com/250034 03:44
purl Message for chromatic stored.
kid51 dukeleto: Yes, we had a different release number philosophy up until last year. 03:47
The fact that there were so many release in 0.4 means that we had a lot of trouble getting to 0.5 ;-) 03:48
dukeleto kid51: i am wondering if i should benchmark against all of them, or just pick a few ? 03:50
kid51 dukeleto: I think the ones you've already done are sufficient. 03:55
What I think is more important than looking at older releases is to figure out why we are slower now than, say, at 0.5. 03:56
Does anyone know how to use 'xargs' in conjunction with 'scp' on Darwin? 03:57
On Linux, I would say something like: find . -type f -name '*.patch' | xargs -i scp me@myserver.com 03:58
Correction: On Linux I would say: find . -type f -name '*.patch' | xargs -i scp {} me@myserver.com 03:59
But you don't have '-i' on Darwin 04:01
dukeleto kid51: yeah, i will just take 1 or 2 representatives from 0.4.x, but i do want to go back as far as i can 04:05
perspective is good 04:06
i imagine i will go back far enough and our current benchmarks won't compile, so that will be my event horizon :)
Tene kid51: maybe the 'find' there has '+' as a -exec terminator? find . -type f -name '*.patch' -exec rsync -Pav {} me@server + 04:16
dukeleto /home/leto/src/parrot/parrot-0.8.1/parrot /home/leto/svn/parrot-trunk/examples/benchmarks/primes.pasm 05:06
Segmentation fault
purl (Core dumped)
dukeleto that is no good
looks like --optimize wasn't around until 0.1.0 05:38
actually 0.0.13 had it 05:39
parrot 0.0.1 doesn't compile on linux for me 06:01
cotto Did they even have Linux back then? 06:07
dukeleto cotto: evidently dinosaurs used OS/2 back then 06:09
cotto d'oh. chromatic's gone 06:12
japhb Interesting that 0.8 is fastest for oofib, and slowest (by a long shot) for gc_waves 06:13
dukeleto is compiling parrot 0.2.0 - 0.8.0 now 06:14
pmichaud dukeleto: your benchmark results are interesting. :-)
cotto dukeleto, are you doing optimized and non-optimized?
pmichaud today I've been playing around with benchmarks as well
dukeleto pmichaud: i will be making some more, on more versions of parrot
pmichaud dukeleto: fwiw, I'm not sure that benchmarking the older versions of parrot is all that useful. 06:15
interesting, yes, but I don't think it tells us much.
dukeleto pmichaud: not very useful, but i would like to know the perspective. are we slower then back then? only one way to find out 06:16
pmichaud oh.
I know we're slower than back then :)
w/o question. :)
japhb pmichaud: seeing the whole lifetime gives us an idea of the high water mark and how far we are from it.
dukeleto 0.7.0 segfaults when building nqp for me
pmichaud: i am going to make pretty graphs
pmichaud: are you trying to use euler_bench? 06:17
pmichaud no, I've just been using variations of fib.pir for now. 06:18
I find that particular benchmark very.... illuminating
dukeleto pmichaud: oofib.pir is good too
cotto dukeleto, building nqp's Actions.pm with --target=pir would probably be a worthwhile benchmark 06:21
that'd basically do what I was talking about Friday.
pmichaud I found a place where I can speed up nqp speed a fair bit
cotto pmichaud++
dukeleto cotto: that is a good idea. you are saying run that against each version of parrot? 06:22
pmichaud building Actions.pm will only work with very recent versions of Parrot, though.
I bet it requires 1.8.0 or later 06:23
dukeleto pmichaud: yeah, that is what i am thinking
purl Oooh he is soooo fine!!!
dukeleto can anyone get this to compile? backpan.cpan.org/authors/id/S/SI/SI...0.1.tar.gz 06:24
cotto oh boy
pmichaud here's the statistic I find troubling at the moment....
(nopasting)
fib(28) = 317811 1.52681708335876s # fib benchmark using native registers 06:25
fib(28) = 317811 2.56401109695435s # fib benchmark using PMCs (next one is bad one) 06:26
fib(28) = 317811 23.2272439002991s # fib benchmark using hll-mapped types
dukeleto pmichaud: that is from unoptimized vtables, probably. and an inefficient gc 06:27
parrot 0.0.1 probably doesn't compile because gcc 4.3.x is too new for it 06:28
pmichaud currently I can get nqp to generate code that is 5.1s for the fib benchmark 06:36
if I had a fast mechanism for caching PMCs across subroutine calls I could get it down to 4.4s
(...noting that set_root_global is apparently not very fast.) 06:37
dukeleto very few script can be run against really old parrot versions 06:41
"hello world" in PIR across Parrot 0.2.0 - trunk gist.github.com/250103 06:57
dalek rrot: r42904 | dukeleto++ | trunk (2 files):
[examples] Add a 'hello world' benchmark that can run on Parrots as old as 0.2.0
 07:31
dukeleto what is the search path of .include in PIR? 07:37
07:45 iblechbot joined 07:51 mikehh joined, bacek joined
dukeleto bacek: o hai 07:52
euler project #2 from euler_bench on parrot 0.2.0 - trunk gist.github.com/250129 08:17
bacek aloha dukeleto 08:18
dukeleto bacek: hola 08:19
purl bonjour, dukeleto.
dukeleto bacek: i am on a benchmark spree
bacek: i have parrot 0.2.0 - trunk compiled and setup with euler_bench
bacek cotto: CONTEXT is old macro to fetch underlying "Parrot_Context" structure. Deprecated and shouldn't be used in new code. CURRENT_CONTEXT fetches Context PMC from interpreter. 08:20
dukeleto so CONTEXT() should be killed. cotto, go forth and kill 08:27
cotto thanks 08:30
dalek rrot: r42905 | bacek++ | branches/cs_csr_cleanup:
Branch for cleanin up code after cs_csr_merge
 08:36
08:37 iblechbot joined
dukeleto another euler project #2 benchmark: gist.github.com/250132 08:41
08:45 fperrad joined 08:50 fperrad_ joined 08:52 mikehh joined
mikehh dukeleto: ping 08:53
All tests PASS (pre/post-config, smoke (#30633), fulltest) at r42904 - Ubuntu 9.04 amd64 (g++ with --optimize) 08:54
09:04 mikehh_ joined
dalek rrot: r42906 | bacek++ | branches/cs_csr_cleanup/src/call/args.c:
Rename csr_elements and csr_set_integer to semantically correct csr_returns_count and csr_reallocate_return_values.
 09:09
09:11 mikehh joined
dukeleto mikehh: pong 09:13
mikehh dukeleto: regarding your question a few hours ago - my test run(s) usually take about 20+ minutes, but that starts from a make realclean, and a smolder test as well as fulltest 09:15
dukeleto: I always run fulltest with logging and TEST_JOBs=5 09:16
dukeleto mikehh: do you ever time just the test run and not the compile? 09:18
09:18 JimmyZ joined
mikehh dukeleto: and I don't start fulltest until make smoke has got to the p's in t/pmc as t/pmc/threads.t and t/pmc/timer.t fail if run in both smoke and fulltest 09:18
dukeleto: i usually run date before each step 09:19
dukeleto: I am about to do a run - I will nopaste the times in about 30 minutes 09:21
dukeleto mikehh: yes, i would just like to know about test runtimes
mikehh: i.e. how long "make test" takes on your box 09:22
"make fulltest" is fine too
mikehh dukeleto: I of course have the timings for each test run in the logs i.e. from testb, testC, testf, testg, testr and testS etc 09:23
dukeleto mikehh: i just need "make test" or "make fulltest", knowing each core isn't that important 09:25
mikehh: for instance, on one of my machines, make -j 3 fulltest is 90 seconds 09:26
dalek rrot: r42907 | bacek++ | branches/cs_csr_cleanup/src/call/args.c:
Rename csr_set_foo_keyed_int to csr_fill_foo
rrot: r42908 | bacek++ | branches/cs_csr_cleanup/src/call/args.c:
Rerun headerizer
rrot: r42909 | bacek++ | branches/cs_csr_cleanup/src/call/args.c:
Merge csr_set_pointer_keyed_int and csr_push_integer into single function. We are not limitied by very narrow VTABLE functions anymore.
rrot: r42910 | bacek++ | branches/cs_csr_cleanup/src/call/args.c:
Made csr_reallocate_return_values to return reallocated values.
 09:43
rrot: r42911 | bacek++ | branches/cs_csr_cleanup/src/call/args.c:
Change semantic of csr_set_pointer to csr_push_pointer. It simplified it a lot.
purl dalek: that doesn't look right
rrot: r42912 | bacek++ | branches/cs_csr_cleanup/src/call/args.c:
Merge csr_allocate_initial_values and csr_reallocate_return_values.
bacek Ok, branch is ready. 09:50
mikehh dukeleto: got to go out for a bit - bbl 09:52
dukeleto bacek: you need testing? 09:56
bacek dukeleto, it will be helpful. But there is not so many changes. 09:57
dalek nxed: r243 | julian.notfound++ | trunk/winxedst1.winxed:
unary - in stage 1
 09:58
dukeleto bacek: what about benchmarking?
dalek rrot: r42913 | bacek++ | branches/cs_csr_cleanup/src/call/args.c:
Remove copypasta error.
bacek dukeleto, there is no performance changes. It's just cleanup - mostly renaming functions. Merge few of them into single one.
dukeleto bacek: gotcha 10:00
dalek nxed: r244 | julian.notfound++ | trunk/Makefile:
tests for sub operator
 10:03
bacek dukeleto, what version of trunk in your benchmarks? Before or after cs_csr_merge? 10:04
dukeleto bacek: r42903, after 10:12
dalek nxed: r245 | julian.notfound++ | trunk/t/sub.t:
forgot to add t/sub.t in last commit
 10:18
10:20 mikehh_ joined
bacek dukeleto, any luck with testing? I'm going to merge branch back to trunk. 10:37
10:51 mikehh joined
dalek rrot: r42914 | bacek++ | trunk/src/call/args.c:
Merge cs_csr_cleanup branch back to trunk.
 11:05
mikehh dukeleto: make -j test TEST_JOBS=20 runs in 65 seconds for me 11:36
that's just the tests - built already 11:37
Files=340, Tests=12150, 30 wallclock secs ( 2.55 usr 0.86 sys + 50.29 cusr 18.11 csys = 71.81 CPU) 11:39
dukeleto: make- j fulltest TEST_JOBS=20 FAILS - a lot of tests don't like being run in parallel 11:48
11:52 JimmyZ joined 12:01 bacek joined
bacek o hai 12:01
mikehh hi bacek 12:02
bacek moritz, looks like irclog.perlgeek.de is slightly broken
aloha mikehh
mikehh All tests PASS (pre/post-config, smoke (#30638), fulltest) at r42914 - Ubuntu 9.10 amd64 (g++ with --optimize) 12:03
bacek: everything seems ok after the latest merge
bacek mikehh, it was pretty small branch. No big functional changes, just functions renames and merging. 12:04
mikehh dukeleto: even less time if I use TEST_JOBS=40 - elapsed 37 seconds and 12:09
dukeleto: Files=340, Tests=12150, 23 wallclock secs ( 2.61 usr 0.90 sys + 46.93 cusr 16.23 csys = 66.67 CPU) 12:10
dukeleto: the rest of the time is spent building nqp 12:11
dukeleto: that's for make -j test TEST_JOBS=40 12:13
dukeleto: elapsed also includes my typing time 12:14
12:45 iblechbot joined
JimmyZ smolder.plusthree.com was down? 12:52
mikehh jimmyZ: it worked for me about an hour ago - haven't tried since - let me see 12:56
JimmyZ: I can connect to it now 12:57
12:59 joeri joined
JimmyZ mikehh: still down here :) 13:00
mikehh JimmyZ: I sometimes fail to connect after a smolder test - you can resend with the following (from parrot) 13:05
JimmyZ: perl -Ilib -MParrot::Harness::Smoke -e'Parrot::Harness::Smoke::send_archive_to_smolder(Parrot::Harness::Smoke::collect_test_environment_data())' 13:06
JimmyZ: if that was the problem? 13:08
JimmyZ mikehh: I think it may be blocked by the Chinese Great Fire Wall. 13:09
though I hate it. :) 13:10
yes, It is blocked 13:12
mikehh you should get an acc on feather.perl6.nl and work through that 13:13
why on earth would they block smolder.plusthree.com 13:14
JimmyZ the Great Fire Wall blocks many sites, such as twitter, blogspot, facebook. 13:17
the gov doesn't like them. :)
mikehh I can understand their reasoning with social networking sites - though I think they are totally wrong - ostrich mentality (head in sand maybe) 13:19
13:19 kid51 joined
JimmyZ hello, kid51 13:26
kid51 Hi JimmyZ 13:27
JimmyZ I had post comment to the patch ticket. :)
kid51 Yes, I saw that. 13:29
I knew of only 8 patches; I didn't see the other 3.
The actual subject matter of the patches is beyond my scope. 13:30
You'll need other people to evaluate whether they *should* be applied.
I was simply trying to see whether they compiled or not.
You ask in TT: "Could you applied which maked succeeded?" 13:31
Do you mean: "On which individual patches did make succeed?" 13:32
dalek tpfwiki: Garry Wertu | Parrot 13:53
tpfwiki: www.perlfoundation.org/parrot/index.cgi?parrot
14:04 JimmyZ joined
JimmyZ kid51: yes 14:05
it's non-english, but I could edit it again. ;)
s/could/couldn't/
kid51 JimmyZ: If we should no longer be looking at this patch, you can remove it from the TT: trac.parrot.org/parrot/attachment/t...cage.patch 14:12
JimmyZ kid51: I have no access. :( 14:14
kid51: I can add it but I can't edit :)
kid51 okay; deleted 14:17
JimmyZ kid51: So could you create a branch for testing my patches? 14:26
I will continue to work for these pmcs to provide new patches. 14:27
kid51: there is a problem for me to test them between two different places. 14:29
nopaste "kid51" at 70.85.31.226 pasted "3 test failures after applying 7 patches" (987 lines) at nopaste.snit.ch/18980 14:32
kid51 JimmyZ: Please take a look at those test failures first.
JimmyZ kid51: well, I will take a look 14:36
kid51 Try to identify which patches might be generating those failures. Once you get them passing, we can have someone who knows more about the substance of your changes (which are deep in core) to review them. 14:41
JimmyZ kid51: thanks 14:51
kid51: I will do it tomorrow, good night ;) 14:52
kid51 The Vtable.pm patch passes make test when applied by itself.
afk 14:53
JimmyZ yes, kid51 just removed some unused macros 14:54
14:54 Essobi joined
JimmyZ s/kid51/it/ 14:54
dalek rrot: r42915 | fperrad++ | trunk/src/pmc (18 files):
[cage] improve C indentation, see TT #1329
 14:57
rrot: r42916 | fperrad++ | trunk/src (13 files):
[cage] improve C indentation, see TT #1329
rrot: r42917 | fperrad++ | trunk/src (31 files):
[cage] improve C indentation, see TT #1329
14:59 flh joined
flh hi! 15:01
I had a little question: why has CallSignatureReturns been removed? is it only because now Parrot creates one PMC less than before on each Sub call, so the GC runs faster? 15:03
or was there a deeper reason?
naypalm is there a function that does similar? 15:04
dalek rrot: r42918 | fperrad++ | trunk (30 files):
[cage] improve C indentation, see TT #1329
 15:15
pmichaud good morning, #parrot 15:29
15:34 jan joined
moritz the IRC logs seem to have lost some data today, sorry for the inconvenience 15:49
15:49 Psyche^ joined
kid51 msg Coke Someone spammed your last post on perlfoundation blog 15:51
purl Message for coke stored.
15:54 tetragon joined 16:09 payload joined 16:10 Zak joined 16:14 Zak joined
mikehh All tests PASS (pre/post-config, smoke (#30656), fulltest) at r42918 - Ubuntu 9.10 amd64 (gcc with --optimize) 16:16
kid51 purl coverage 16:43
purl i heard coverage was cv.perl6.cz
plobsing_ hmm looks like src/ops/*.ops aren't getting their coverage attributed correctly. 16:52
is there an easy way to fix that?
kid51 I don't know -- but ISTR a Trac ticket on that subjet. 16:58
s/subjet/subject/
TT #1181 17:00
trac.parrot.org/parrot/ticket/1181
plobsing_: I guess if it were easy we would have done it already :-) 17:01
plobsing_ its weird because the coverage seems to work for dynopslibs/*.ops
s/dynopslibs/dynoplibs/ 17:02
kid51 Here is a pure guess: 'make' runs two programs: tools/build/ops2pm.pl and ops2c.pl. Might it be the case that by the point coverage stats start getting collected, only the resulting .pm and .c files are visible? 17:03
Would gcov (which is what I think we're using under the hood) be able to detect source code *antecedent* to C-code? 17:05
plobsing_ it does with pmcs
and dynops
I think it works using #line preprocessor statements 17:06
kid51 In the 'make cover' target, I see that 'gcov *.c' is called in each directory in $(COVER_DIRS) -- but there are no .c files in src/ops/ 17:14
Could we say 'gcov *.c *.ops'? 17:16
plobsing_ I've got it 17:18
dynops run ops2c in the $(ROOT)/src/dynops directory 17:19
ops run ops2c in the $(ROOT) directory
thats the only diff I can see
it affects the #line statements, which might in turn affect gcov
17:23 theory joined, brrant joined, mikehh joined
dalek rrot: r42919 | jkeenan++ | trunk/include/parrot/pobj.h:
Applying part of patch submitted by jimmy++ in �trac.parrot.org/parrot/ticket/1346.
 17:26
17:26 Zak joined
fperrad japhb, see github.com/TiMBuS/fun/blob/master/p...e/fun.json 17:31
flh is there an easy way to run some benchmark for Parrot? I think I have an improvement for the calling conventions, yet I'd like to test if it is significant or not 18:02
dukeleto flh: yes
flh: you ask me. that is the easy way. I can also tell you how to recreate my benchmarking setup. That is not as easy 18:03
flh: do you have a branch somewhere? 18:07
flh only my local copy of parrot's trunk 18:10
dukeleto flh: svn or git branch ?
18:11 colomon joined
flh svn: the only thing I've done for the moment is a checkout of the trunk 18:11
colomon Pardon me, can someone quickly give me a pointer in getting a debug build of parrot? Is it simply a matter of running Configure.pl with --debugging=1 and no --optimize? 18:14
dukeleto colomon: --debugging=1 is default 18:15
colomon My Makefile contains -DDISABLE_GC_DEBUG=1 -DNDEBUG -O3 in CFLAGS, so I'm assuming --debugging=0 is being set by Rakudo's --gen-parrot, as well as --optimize? Or something like that? 18:17
dukeleto colomon: looks like, you probably want to add -g in there and get rid of -DDISABLE_GC_DEBUG=1 -DNDEBUG
colomon Is this most easily done by hacking the top-level Makefile? 18:18
dukeleto colomon: yes 18:19
colomon Groovy. Thanks!
dukeleto flh: you can try to get github.com/notbenh/euler_bench on your system, or you can push a public branch somewhere and i can benchmark it. your call.
colomon: no worries
18:20 ttbot joined
flh dukeleto, git complains about your URI, I'm trying to find why 18:21
18:21 Zak joined
flh ok, my mistake, I found the clone URI 18:22
dukeleto flh: :) 18:25
plobsing_ config/gen/platform/ansi/exec.c Parrot_Exec_OS_Comman() 18:29
shouldn't that be Parrot_Exec_OS_Comman*d*()
? 18:30
flh dukeleto, ok, git cloned euler_bench, and installed dependencies: what's my next move?
18:31 mikehh joined
dalek rrot: r42920 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] throws an exception when a command system fails
 18:32
dukeleto flh: write a yaml file 18:34
flh: there is an example in examples/ 18:35
flh: then run it like so: BENCH_CONFIG=bench.yaml ~/git/euler_bench/bin/bench ~/svn/parrot/examples/benchmarks/primes2.pir parrot --count=10 --order=avg 18:36
flh: if you just want to bench a branch against trunk, delete all the parrot interpreter but 2, and add the directory where your branch is compiled and make sure the directory for your parrot trunk is correct
dalek tpfwiki: unregisteredlewis@gmail.com | Parrot
tpfwiki: www.perlfoundation.org/parrot/index.cgi?parrot
dukeleto flh: then you should be good to go 18:37
flh: i would recommend at least --count=100 to get good results
flh: and look out for outliers
fucking spammers 18:39
18:41 mikehh joined
dukeleto can we just delete www.perlfoundation.org/parrot/ ? 18:42
or make it read only?
moritz deletion +1
dukeleto dealing with spammers on wiki we don't care about anymore is just fucking insane
moritz making it RO seems like a bad idea, because it will be outdated very soon
(or is already, dunno)
dalek tpfwiki: jonathan@leto.net | Parrot 18:43
tpfwiki: www.perlfoundation.org/parrot/index.cgi?parrot
dukeleto moritz: it consists of a single page with no content linking to our current wiki
moritz: which can be vandalized 18:44
like it just was, by Zend people
dalek rrot-plumage: 5313c87 | japhb++ | metadata/fun.json:
[METADATA] add fun, care of fperrad++
japhb It should be RO, since it's just a pointer -- and we don't want people who've gotten old links from some google search to be lost.
moritz ok, RO then 18:45
18:46 mikehh joined
dukeleto japhb: redirect would be better 18:47
japhb: i just sent an email to tpf-steering. we shall see 18:48
japhb dukeleto, if that works in that particular system, great
I just assumed it would be easier to set RO than 302
(or actually, 301, come to think of it)
19:38 colomon__ joined 19:42 integral joined 19:43 Zak joined 20:12 cognominal joined 20:29 Whiteknight joined
Whiteknight good afternoon #parrot 20:35
pmichaud good afternoon, whiteknight 20:36
Whiteknight I'm looking through your email now, pmichaud 20:37
pmichaud thanks :)
Whiteknight my problem is that I don't know enough about Perl6 semantics. I could probably come up with a few naive "why don't you just do X" suggestions that are going to fall flat 20:38
pmichaud note that my example isn't Perl 6.
Whiteknight True, but you still have semantics beyond what little you've shown that need to be satisfied
pmichaud it's any language that needs to be able to have loop "continue" or "break" from within a nested lexical block.
so my example applies at least to PHP, Perl 5, and Perl 6 20:39
I suspect to python also, but I'm not familiar enough with python to say for sure.
Whiteknight And I'll save time by presuming that non-exception-based solutions probably won't hack it? 20:41
pmichaud if you can come up with a non-exception based solution, I'd consider it. But I suspect it still involves continuations of some sort, which are effectively exceptions.
Whiteknight this is the best argument I've seen so far for keeping the label-based handlers 20:44
pmichaud fwiw, 'return' has the same issue.
I just figured that the loop control breaks illustrated the problem more directly. 20:45
20:46 bacek joined
Whiteknight in Perl6, can people define custom handlers for last/next? 20:47
pmichaud yes.
and next/last are indeed functions, not keywords. 20:48
Whiteknight see, all my ideas heretofore don't satisfy that
pmichaud tcl has the same issue as well, I believe. 20:50
20:50 lucian joined
Whiteknight Let me recap really quick: 20:50
1) There are very big problems with the current system of nested runloops + label-based exception handlers 20:51
pmichaud (I disagree with the items in #1 being connected, fwiw)
Whiteknight pmichaud: whether you agree or not, those two factors together are the "inferior runloop problem"
pmichaud no, I think the inferior runloop is independent of label-based exception handlers.
i.e., I think a sub-based exception handler has exactly the same inferior runloop issue. 20:52
Whiteknight technically, yes. But this is a very easy and obvious way to manifest it
no, sub-based handlers will be immune from those problems. They were conceived as being a solution
pmichaud I'd like to see how a sub-based exception handler resolves the inferior runloop problem.
I don't think it does.
Whiteknight I've done plenty of analysis on it in the past. I will see if I can dig some of that up 20:53
but in short, I have no doubt about it
pmichaud as I said, an example would really help.
we already have a very short pir example to demonstrate inferior runloop. I'd like to see a sub-based version of that example. 20:54
Whiteknight where's the PIR version?
purl the PIR version is probably gone i think
Whiteknight purl forget the PIR version
purl Whiteknight: I forgot pir version
pmichaud TT #833 20:55
moritz groups.google.com/group/parrot-dev/...15c6?pli=1
pmichaud I can come up with an even smaller example. 20:56
nopaste "pmichaud" at 66.25.4.52 pasted "smaller inferior runloop example (for whiteknight++)" (28 lines) at nopaste.snit.ch/18981 21:01
pmichaud actually, let me revise that a bit. 21:03
nopaste "pmichaud" at 66.25.4.52 pasted "smaller inferior runloop example #2 (for whiteknight++)" (31 lines) at nopaste.snit.ch/18982 21:05
Whiteknight yes, that's a very concise example 21:06
pmichaud let me add a small complicating factor
nopaste "pmichaud" at 66.25.4.52 pasted "smaller inferior runloop example #3 (for whiteknight++)" (36 lines) at nopaste.snit.ch/18983 21:08
pmichaud the "tricky" part that I haven't figured out yet is how a sub-based exception handler would be able to set the value of "result". 21:09
21:09 kurahaupo joined
Whiteknight result would have to be a lexical 21:10
and take my word for it that the final implementation of sub-based handlers would be (or would be able to be) lexically nested within the calling context 21:11
or, within the context where they are defined, I mean
pmichaud even assuming it's a lexical, I don't see how control returns to 'main' when an exception occurs.
Whiteknight a continuation 21:12
purl a continuation is probably builded inside the opcode, there is no way to pass a differente location.
Whiteknight purl forget a continuation
purl Whiteknight: I forgot continuation
pmichaud isn't that what we have now... a continuation?
Whiteknight okay, let me rephrase a little 21:14
pmichaud a complete example of the above would be far more illustrative :)
Whiteknight something has to give. What we have now is broken, so we need to change *something*
pmichaud I understand that something is broken. I don't believe it's the label-based continuations that are the source of the inferior runloop problem.
or, if they are, I don't see how sub-based continuations resolve that.
Whiteknight we could prohibit that exceptions thrown in a nested runloop cannot be handled by a handler defined in an external runloop
but you've already said that option is unacceptable
pmichaud correct, we always have to be able to trap exceptions. 21:15
Whiteknight We could resolve this if we completely refactored runloops, but that's months away if it ever happens
I'm talking about 3.0, and there's no guarantee we would even completely solve it
pmichaud I believe that the correct solution is to have proper "rollup" functionality available for subs and exceptions. 21:16
Whiteknight So if we have sub-based handlers, and if every handler must end with an explicit "rethrow" or "continue-at" command, we can keep the C execution context and PIR executin contexts more closely alighned
aligned 21:17
here's what we need: (more)
21:17 mikehh joined
pmichaud having every handler end with explicit rethrow or continue-at isn't exclusive to label-based exception handlers, though. 21:17
i.e., requiring an explicit rethrow or continue-at can work for label-based handlers the same as sub-based ones. 21:18
Whiteknight there's no way to enforce the "every handler must explicitly end" rule with label-based handlers
you find a way, we;ll do it
pmichaud we don't have to enforce it (more)
the enforcement is "if you don't do this, then you get inferior runloops"
Whiteknight we need to enforce it. That's the problem in a nutshell
pmichaud there are lots of things that occur in Parrot that we don't enforce 21:19
Whiteknight "do it wrong and there be segfaults" is a bad strategy
pmichaud ...note that I didn't get a segfault, I got an exception.
getting an exception is valid.
Whiteknight then you won the crapshoot
because more often than not segfaults happen in these cases
pmichaud I'm not sure that's true anymore. 21:20
Whiteknight maybe somebody wallpapered over that nasty effect
pmichaud all of the inferior runloops we've been getting lately are exceptions, not segfaults.
anyway, all I'm saying is that the solution (require rethrow or continue-at semantics) doesn't absolutely require sub-based exceptions to work
beyond that, this problem exists for more than just exceptions -- it exists for any form of continuation 21:21
i.e., anytime an inferior runloop invokes a continuation from a superior runloop
Whiteknight to finish what I was saying earlier, the solution is to find all cases where we jump between runloops and perform the necessary fixes
and what we need to do is limit the number of cases where we even need to check 21:22
otherwise the fix is intractably complicated
pmichaud I think that goes against parrot's underlying model.
(limit the number of cases where we check)
but you'd have to discuss that part with allison.
Whiteknight parrot's underlying model is broke
pmichaud no, I mean the model of having continuation-based control.
if you're saying we need to get rid of continuations altogether... that would seem to go against everything we've worked towards. 21:23
if you're saying we need to limit the ways in which continuations can be used... that also seems to go against Parrot's design
Whiteknight no, not get rid of continuations
pmichaud anyway, I have to head off to my soccer playoffs 21:25
21:27 Andy joined
pmichaud I've provided two PIR examples currently being handled with label-based continuations, before we deprecate the existing mechanism we really need to know what the replacement will be (because it affects PCT and several other tools pretty heavily) 21:27
dukeleto pmichaud: i hear what you are saying about benchmarks. i am working with a the few benchmark scripts that I have. i can start to do similar benchmarks with HLL's 21:29
pmichaud: but i also feel that it is informative to know how our performance is a function of version number. i was not trying to imply anything about dev priorities or anything like that 21:30
pmichaud dukeleto: perhaps you weren't, but japhb did. 21:31
21:32 bacek joined
pmichaud my fear is mainly that it gets people to look at the wrong things and draw the wrong conclusions. 21:34
Whiteknight build with --maintainer is broken 21:41
at least on my system
hmmm...nevermind It seems to work now 21:44
NotFound Winxed also uses label based exception handlers. 21:45
Whiteknight everybody uses them right now 21:47
it's the only real option
21:52 chromatic joined
mikehh All tests PASS (pre/post-config, smoke (#30663), fulltest) at r42920 - Ubuntu 9.10 amd64 (g++ with --optimize) 21:52
cotto chromatic, ping 22:08
dalek rrot-linear-algebra: 4c9c5dc | Whiteknight++ | (3 files):
Merge branch 'master' of git@github.com:Whiteknight/parrot-linear-algebra
 22:15
rrot-linear-algebra: c8a29fd | Whiteknight++ | t/harness:
harness now exits with non-zero status on failure. This makes the sanity test chaining do the right thing
rrot-linear-algebra: 30ff9cc | Whiteknight++ | t/00-sanity.t:
fix the sanity test so that things are sane on failure
rrot-linear-algebra: 201b7b2 | Whiteknight++ | t/ (2 files):
rename 00-sanity to just sanity
chromatic pong 22:29
dalek nxed: r246 | julian.notfound++ | trunk/ (3 files):
return in stage 1
 22:31
cotto chromatic, I need a quick sanity check on a change to the profiling runcore. Currently I write output to the pprof directly through fprintf, which isn't terribly extensible.
Does this sound like a good idea: for all output to the pprof, there's a single Parrot_Hash* in the runcore struct. When I want to print a value to the pprof, I add a key/value to the hash (e.g. parrot_hash_put(interp, runcore->hash, "time", "1324"), possibly using a #define'd constant for the keys. To record data (i.e. to a pprof), I just iterate the hash and clear it when I'm done.
This would make it easier to have multiple output formats and would minimize the amount of code that needed to care about the output format. The main concern is that this could negatively impact speed.
chromatic As long as you don't cause allocations from Parrot's GC, that should be okay. 22:32
cotto ok 22:33
chromatic We do have to gyrate to avoid measuring the time spent in the profiling core versus the code profiled, but we have to do that anyway.
cotto yes
chromatic There'll be some hash reallocations, but those amortize out. 22:34
cotto I'd be using a Hash* directly to avoid the unnecessary PMC overhead. It might also make sense to add a Parrot_hash_clear function to reuse the Hash to avoid a per-op allocation. 22:36
22:37 colomon_ joined
chromatic Makes sense. 22:37
naypalm can't we just have an extremely slow language with an awesome data type?! 22:38
cotto naypalm, atm we call that "Rakudo" ;)
naypalm well maybe! I do love the pmc though 22:39
22:39 Zak joined
cotto chromatic, thanks. 22:42
dalek trixy: c3c9dc8 | Whiteknight++ | t/ (2 files):
move the operators test to the syntax folder
 22:46
trixy: d8fc170 | Whiteknight++ | (8 files):
start breaking the 303-matrix-operations test file into individual files for different operations
trixy: db4b1db | Whiteknight++ | t/ (7 files):
break the remaining function tests out of the matrix-operations conglomerate file
trixy: abf0b10 | Whiteknight++ | t/functions/mtimes.t:
fix the mtimes function tests
23:30 Zak joined 23:34 jan joined 23:39 mikehh joined
cotto headerizer's error messages leave much to be desired 23:45
23:46 payload joined
dukeleto cotto: patches welcome! 23:49
purl somebody said patches welcome was ponies welcome or Set Objectives, Achieve Results! or swahili for "Put up or shut up."
Whiteknight cotto: in other news, headerizer has error messages? 23:50
I thought it failed silently 23:51
23:51 mikehh joined
cotto it are dum 23:53
23:53 davidfetter joined
cotto It gives error messages about things that aren't there 23:55

Powered by Cro and the Raku® Programming Language.

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

Thank you!