Camelia, the Perl 6 bug

IRC log for #parrot, 2009-12-06

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:12 theory joined #parrot
00:31 cotto chromatic, ping
00:36 mikehh joined #parrot
00:37 cotto chromatic, unping.  I'll catch you later.
00:38 chromatic Okay.
00:43 dalek parrot: r42903 | pmichaud++ | trunk/compilers/pct/src/PAST/Compiler.pir:
00:43 dalek parrot: [pct]:  Allow PAST::Val int constants to auto-promote to num constants
00:43 dalek parrot: by adding ".0" to the stringified version.
00:43 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42903/
01:28 chromatic joined #parrot
01:46 patspam joined #parrot
02:30 dalek TT #1360 created by jpaton++: "smoke_languages.pl" doesn't deal with spaces in paths
02:31 * dukeleto is benching oofib.pir across all parrot releases and trunk
02:32 dalek tapir: f72cd79 | dukeleto++ | TODO:
02:32 dalek tapir: Update TODO with info about tests
02:32 dalek tapir: review: http://github.com/leto/tapir/commit/f7​2cd79be6345fd68aac4c505c09f7c1d13c5f22
02:32 dukeleto prepare for hard truths
02:36 mikehh joined #parrot
02:37 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 kid51 joined #parrot
02:43 mikehh joined #parrot
02:48 mikehh joined #parrot
02:55 mikehh joined #parrot
03:03 dalek TT #1353 closed by dukeleto++: svn:ignore-ing too many things in t/
03:14 dukeleto msg chromatic oofib.pir bechmark: http://gist.github.com/250024
03:14 purl Message for chromatic stored.
03:16 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:24 * dukeleto is running the gc_waves_sizeable_data.pasm benchmark now
03:26 kid51 What figure do you have for trunk now?
03:27 kid51 Oh, I see.  I was misreading chart.
03:31 dukeleto kid51: just about as fast as 1.5.0
03:31 dukeleto kid51: for oofib.pir
03:31 kid51 Do we have any idea why our speed went down (say, after 0.8)?
03:32 dukeleto kid51: i haven't benched anything before 0.8.1 . where are they?
03:33 kid51 I don't know.
03:34 dukeleto kid51: i think they are on the backpan
03:36 dukeleto here are some oldies: http://backpan.perl.org/authors/id/P/PM/PMIC/
03:41 dukeleto and here are the real oldies: http://backpan.cpan.org/authors/id/L/LT/LTOETSCH/
03:41 dukeleto my benchmarks are going to get a lot more interesting :)
03:41 dukeleto there were so many releases in 0.4.x !
03:44 dukeleto msg chromatic gc_waves_sizeable_data.pasm bechmark http://gist.github.com/250034
03:44 purl Message for chromatic stored.
03:47 kid51 dukeleto:  Yes, we had a different release number philosophy up until last year.
03:48 kid51 The fact that there were so many release in 0.4 means that we had a lot of trouble getting to 0.5 ;-)
03:50 dukeleto kid51: i am wondering if i should benchmark against all of them, or just pick a few ?
03:55 kid51 dukeleto:  I think the ones you've already done are sufficient.
03:56 kid51 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:57 kid51 Does anyone know how to use 'xargs' in conjunction with 'scp' on Darwin?
03:58 kid51 On Linux, I would say something like:  find . -type f -name '*.patch' | xargs -i scp me@myserver.com
03:59 kid51 Correction:  On Linux I would say:  find . -type f -name '*.patch' | xargs -i scp {}  me@myserver.com
04:01 kid51 But you don't have '-i' on Darwin
04:05 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:06 dukeleto perspective is good
04:06 dukeleto i imagine i will go back far enough and our current benchmarks won't compile, so that will be my event horizon :)
04:16 Tene kid51: maybe the 'find' there has '+' as a -exec terminator? find . -type f -name '*.patch' -exec rsync -Pav {} me@server +
05:06 dukeleto /home/leto/src/parrot/parrot-0.8.1/parrot     /home/leto/svn/parrot-trunk/ex​amples/benchmarks/primes.pasm
05:06 dukeleto Segmentation fault
05:06 purl (Core dumped)
05:06 dukeleto that is no good
05:38 dukeleto looks like --optimize wasn't around until 0.1.0
05:39 dukeleto actually 0.0.13 had it
06:01 dukeleto parrot 0.0.1 doesn't compile on linux for me
06:07 cotto Did they even have Linux back then?
06:09 dukeleto cotto: evidently dinosaurs used OS/2 back then
06:12 cotto d'oh.  chromatic's gone
06:13 japhb Interesting that 0.8 is fastest for oofib, and slowest (by a long shot) for gc_waves
06:14 * dukeleto is compiling parrot 0.2.0 - 0.8.0 now
06:14 pmichaud dukeleto: your benchmark results are interesting.  :-)
06:14 cotto dukeleto, are you doing optimized and non-optimized?
06:14 pmichaud today I've been playing around with benchmarks as well
06:14 dukeleto pmichaud: i will be making some more, on more versions of parrot
06:15 pmichaud dukeleto: fwiw, I'm not sure that benchmarking the older versions of parrot is all that  useful.
06:15 pmichaud interesting, yes,  but I don't think it tells us much.
06:16 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.
06:16 pmichaud I know we're slower than back then :)
06:16 pmichaud w/o question.  :)
06:16 japhb pmichaud: seeing the whole lifetime gives us an idea of the high water mark and how far we are from it.
06:16 dukeleto 0.7.0 segfaults when building nqp for me
06:16 dukeleto pmichaud: i am going to make pretty graphs
06:17 dukeleto pmichaud: are you trying to use euler_bench?
06:18 pmichaud no, I've just been using variations of fib.pir for now.
06:18 pmichaud I find that particular benchmark very.... illuminating
06:18 dukeleto pmichaud: oofib.pir is good too
06:21 cotto dukeleto, building nqp's Actions.pm with --target=pir would probably be a worthwhile benchmark
06:21 cotto that'd basically do what I was talking about Friday.
06:21 pmichaud I found a place where I can speed up nqp speed a fair bit
06:21 cotto pmichaud++
06:22 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.
06:23 pmichaud I bet it requires 1.8.0 or later
06:23 dukeleto pmichaud: yeah, that is what i am thinking
06:23 purl Oooh he is soooo fine!!!
06:24 dukeleto can anyone get this to compile? http://backpan.cpan.org/authors/i​d/S/SI/SIMON/parrot-0.0.1.tar.gz
06:24 cotto oh boy
06:24 pmichaud here's the statistic I find troubling at the moment....
06:24 pmichaud (nopasting)
06:25 pmichaud fib(28) = 317811 1.52681708335876s   #  fib benchmark using native registers
06:26 pmichaud fib(28) = 317811 2.56401109695435s  # fib benchmark using PMCs  (next one is bad one)
06:26 pmichaud fib(28) = 317811 23.2272439002991s  # fib benchmark using hll-mapped types
06:27 dukeleto pmichaud: that is from unoptimized vtables, probably. and an inefficient gc
06:28 dukeleto parrot 0.0.1 probably doesn't compile because gcc 4.3.x is too new for it
06:36 pmichaud currently I can get nqp to generate code that is 5.1s for the fib benchmark
06:36 pmichaud if I had a fast mechanism for caching PMCs across subroutine calls I could get it down to 4.4s
06:37 pmichaud (...noting that set_root_global is apparently not very fast.)
06:41 dukeleto very few script can be run against really old parrot versions
06:57 dukeleto "hello world" in PIR across Parrot 0.2.0 - trunk http://gist.github.com/250103
07:31 dalek parrot: r42904 | dukeleto++ | trunk (2 files):
07:31 dalek parrot: [examples] Add a 'hello world' benchmark that can run on Parrots as old as 0.2.0
07:31 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42904/
07:37 dukeleto what is the search path of .include in PIR?
07:45 iblechbot joined #parrot
07:51 mikehh joined #parrot
07:51 bacek joined #parrot
07:52 dukeleto bacek: o hai
08:17 dukeleto euler project #2 from euler_bench on parrot 0.2.0 - trunk http://gist.github.com/250129
08:18 bacek aloha dukeleto
08:19 dukeleto bacek: hola
08:19 purl bonjour, dukeleto.
08:19 dukeleto bacek: i am on a benchmark spree
08:19 dukeleto bacek: i have parrot 0.2.0 - trunk compiled and setup with euler_bench
08:20 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:27 dukeleto so CONTEXT() should be killed. cotto, go forth and kill
08:30 cotto thanks
08:36 dalek parrot: r42905 | bacek++ | branches/cs_csr_cleanup:
08:36 dalek parrot: Branch for cleanin up code after cs_csr_merge
08:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42905/
08:37 iblechbot joined #parrot
08:41 dukeleto another euler project #2 benchmark: http://gist.github.com/250132
08:45 fperrad joined #parrot
08:50 fperrad_ joined #parrot
08:52 mikehh joined #parrot
08:53 mikehh dukeleto: ping
08:54 mikehh All tests PASS (pre/post-config, smoke (#30633), fulltest) at r42904 - Ubuntu 9.04 amd64 (g++ with --optimize)
09:04 mikehh_ joined #parrot
09:09 dalek parrot: r42906 | bacek++ | branches/cs_csr_cleanup/src/call/args.c:
09:09 dalek parrot: Rename csr_elements and csr_set_integer to semantically correct csr_returns_count and csr_reallocate_return_values.
09:09 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42906/
09:11 mikehh joined #parrot
09:13 dukeleto mikehh: pong
09:15 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:16 mikehh dukeleto: I always run fulltest with logging and TEST_JOBs=5
09:18 dukeleto mikehh: do you ever time just the test run and not the compile?
09:18 JimmyZ joined #parrot
09:18 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:19 mikehh dukeleto: i usually run date before each step
09:21 mikehh 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
09:22 dukeleto mikehh: i.e. how long "make test" takes on your box
09:22 dukeleto "make fulltest" is fine too
09:23 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:25 dukeleto mikehh: i just need "make test" or "make fulltest", knowing each core isn't that important
09:26 dukeleto mikehh: for instance, on one of my machines, make -j 3 fulltest is 90 seconds
09:26 dalek parrot: r42907 | bacek++ | branches/cs_csr_cleanup/src/call/args.c:
09:26 dalek parrot: Rename csr_set_foo_keyed_int to csr_fill_foo
09:26 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42907/
09:26 dalek parrot: r42908 | bacek++ | branches/cs_csr_cleanup/src/call/args.c:
09:26 dalek parrot: Rerun headerizer
09:26 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42908/
09:26 dalek parrot: r42909 | bacek++ | branches/cs_csr_cleanup/src/call/args.c:
09:26 dalek parrot: Merge csr_set_pointer_keyed_int and csr_push_integer into single function. We are not limitied by very narrow VTABLE functions anymore.
09:26 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42909/
09:43 dalek parrot: r42910 | bacek++ | branches/cs_csr_cleanup/src/call/args.c:
09:43 dalek parrot: Made csr_reallocate_return_values to return reallocated values.
09:43 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42910/
09:43 dalek parrot: r42911 | bacek++ | branches/cs_csr_cleanup/src/call/args.c:
09:43 dalek parrot: Change semantic of csr_set_pointer to csr_push_pointer. It simplified it a lot.
09:43 purl dalek: that doesn't look right
09:43 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42911/
09:43 dalek parrot: r42912 | bacek++ | branches/cs_csr_cleanup/src/call/args.c:
09:43 dalek parrot: Merge csr_allocate_initial_values and csr_reallocate_return_values.
09:43 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42912/
09:50 bacek Ok, branch is ready.
09:52 mikehh dukeleto: got to go out for a bit - bbl
09:56 dukeleto bacek: you need testing?
09:57 bacek dukeleto, it will be helpful. But there is not so many changes.
09:58 dalek winxed: r243 | julian.notfound++ | trunk/winxedst1.winxed:
09:58 dalek winxed: unary - in stage 1
09:59 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=243
09:59 dukeleto bacek: what about benchmarking?
09:59 dalek parrot: r42913 | bacek++ | branches/cs_csr_cleanup/src/call/args.c:
09:59 dalek parrot: Remove copypasta error.
09:59 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42913/
09:59 bacek dukeleto, there is no performance changes. It's just cleanup - mostly renaming functions. Merge few of them into single one.
10:00 dukeleto bacek: gotcha
10:03 dalek winxed: r244 | julian.notfound++ | trunk/Makefile:
10:03 dalek winxed: tests for sub operator
10:03 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=244
10:04 bacek dukeleto, what version of trunk in your benchmarks? Before or after cs_csr_merge?
10:12 dukeleto bacek: r42903, after
10:18 dalek winxed: r245 | julian.notfound++ | trunk/t/sub.t:
10:18 dalek winxed: forgot to add t/sub.t in last commit
10:18 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=245
10:20 mikehh_ joined #parrot
10:37 bacek dukeleto, any luck with testing? I'm going to merge branch back to trunk.
10:51 mikehh joined #parrot
11:05 dalek parrot: r42914 | bacek++ | trunk/src/call/args.c:
11:05 dalek parrot: Merge cs_csr_cleanup branch back to trunk.
11:05 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42914/
11:36 mikehh dukeleto: make -j test TEST_JOBS=20 runs in 65 seconds for me
11:37 mikehh that's just the tests - built already
11:39 mikehh Files=340, Tests=12150, 30 wallclock secs ( 2.55 usr  0.86 sys + 50.29 cusr 18.11 csys = 71.81 CPU)
11:48 mikehh dukeleto: make- j fulltest TEST_JOBS=20 FAILS - a lot of tests don't like being run in parallel
11:52 JimmyZ joined #parrot
12:01 bacek joined #parrot
12:01 bacek o hai
12:02 mikehh hi bacek
12:02 bacek moritz, looks like irclog.perlgeek.de is slightly broken
12:02 bacek aloha mikehh
12:03 mikehh All tests PASS (pre/post-config, smoke (#30638), fulltest) at r42914 - Ubuntu 9.10 amd64 (g++ with --optimize)
12:03 mikehh bacek: everything seems ok after the latest merge
12:04 bacek mikehh, it was pretty small branch. No big functional changes, just functions renames and merging.
12:09 mikehh dukeleto: even less time if I use TEST_JOBS=40 - elapsed 37 seconds and
12:10 mikehh dukeleto: Files=340, Tests=12150, 23 wallclock secs ( 2.61 usr  0.90 sys + 46.93 cusr 16.23 csys = 66.67 CPU)
12:11 mikehh dukeleto: the rest of the time is spent building nqp
12:13 mikehh dukeleto: that's for  make -j test TEST_JOBS=40
12:14 mikehh dukeleto: elapsed also includes my typing time
12:45 iblechbot joined #parrot
12:52 JimmyZ smolder.plusthree.com was down?
12:56 mikehh jimmyZ: it worked for me about an hour ago - haven't tried since - let me see
12:57 mikehh JimmyZ: I can connect to it now
12:59 joeri joined #parrot
13:00 JimmyZ mikehh: still down here :)
13:05 mikehh JimmyZ: I sometimes fail to connect after a smolder test - you can resend with the following (from parrot)
13:06 mikehh JimmyZ: perl -Ilib -MParrot::Harness::Smoke -e'Parrot::Harness::Smoke::send_arch​ive_to_smolder(Parrot::Harness::Smok​e::collect_test_environment_data())'
13:08 mikehh JimmyZ: if that was the problem?
13:09 JimmyZ mikehh: I think it may be blocked by the Chinese Great Fire Wall.
13:10 JimmyZ though I hate it. :)
13:12 JimmyZ yes, It is blocked
13:13 mikehh you should get an acc on feather.perl6.nl and work through that
13:14 mikehh why on earth would they block smolder.plusthree.com
13:17 JimmyZ the Great Fire Wall blocks many sites, such as  twitter, blogspot, facebook.
13:17 JimmyZ the gov doesn't like them. :)
13:19 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 kid51 joined #parrot
13:26 JimmyZ hello, kid51
13:27 kid51 Hi JimmyZ
13:27 JimmyZ I had post comment to the patch ticket. :)
13:29 kid51 Yes, I saw that.
13:29 kid51 I knew of only 8 patches; I didn't see the other 3.
13:30 kid51 The actual subject matter of the patches is beyond my scope.
13:30 kid51 You'll need other people to evaluate whether they *should* be applied.
13:30 kid51 I was simply trying to see whether they compiled or not.
13:31 kid51 You ask in TT:  "Could you applied which maked succeeded?"
13:32 kid51 Do you mean: "On which individual patches did make succeed?"
13:53 dalek tpfwiki: Garry Wertu | Parrot
13:53 dalek tpfwiki: http://www.perlfoundation.o​rg/parrot/index.cgi?parrot
14:04 JimmyZ joined #parrot
14:05 JimmyZ kid51: yes
14:05 JimmyZ it's non-english, but I could edit it again. ;)
14:05 JimmyZ s/could/couldn't/
14:12 kid51 JimmyZ:  If we should no longer be looking at this patch, you can remove it from the TT:  http://trac.parrot.org/parrot/at​tachment/ticket/1346/cage.patch
14:14 JimmyZ kid51: I have no access. :(
14:14 JimmyZ kid51: I can add it but I can't edit :)
14:17 kid51 okay; deleted
14:26 JimmyZ kid51: So could you  create a branch for testing my patches?
14:27 JimmyZ I will continue to work for these pmcs to provide new patches.
14:29 JimmyZ kid51: there is a problem for me to test them between two different places.
14:32 nopaste "kid51" at 70.85.31.226 pasted "3 test failures after applying 7 patches" (987 lines) at http://nopaste.snit.ch/18980
14:32 kid51 JimmyZ:  Please take a look at those test failures first.
14:36 JimmyZ kid51: well, I will take a look
14:41 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:51 JimmyZ kid51: thanks
14:52 JimmyZ kid51: I will do it tomorrow, good night ;)
14:52 kid51 The Vtable.pm patch passes make test when applied by itself.
14:53 kid51 afk
14:54 JimmyZ yes, kid51 just removed some unused macros
14:54 Essobi joined #parrot
14:54 JimmyZ s/kid51/it/
14:57 dalek parrot: r42915 | fperrad++ | trunk/src/pmc (18 files):
14:58 dalek parrot: [cage] improve C indentation, see TT #1329
14:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42915/
14:58 dalek parrot: r42916 | fperrad++ | trunk/src (13 files):
14:58 dalek parrot: [cage] improve C indentation, see TT #1329
14:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42916/
14:58 dalek parrot: r42917 | fperrad++ | trunk/src (31 files):
14:58 dalek parrot: [cage] improve C indentation, see TT #1329
14:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42917/
14:59 flh joined #parrot
15:01 flh hi!
15:03 flh 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 flh or was there a deeper reason?
15:04 naypalm is there a function that does similar?
15:15 dalek parrot: r42918 | fperrad++ | trunk (30 files):
15:15 dalek parrot: [cage] improve C indentation, see TT #1329
15:15 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42918/
15:29 pmichaud good morning, #parrot
15:34 jan joined #parrot
15:49 moritz the IRC logs seem to have lost some data today, sorry for the inconvenience
15:49 Psyche^ joined #parrot
15:51 kid51 msg Coke Someone spammed your last post on perlfoundation blog
15:51 purl Message for coke stored.
15:54 tetragon joined #parrot
16:09 payload joined #parrot
16:10 Zak joined #parrot
16:14 Zak joined #parrot
16:16 mikehh All tests PASS (pre/post-config, smoke (#30656), fulltest) at r42918 - Ubuntu 9.10 amd64 (gcc with --optimize)
16:43 kid51 purl coverage
16:43 purl i heard coverage was http://cv.perl6.cz
16:52 plobsing_ hmm looks like src/ops/*.ops aren't getting their coverage attributed correctly.
16:52 plobsing_ is there an easy way to fix that?
16:58 kid51 I don't know -- but ISTR a Trac ticket on that subjet.
16:58 kid51 s/subjet/subject/
17:00 kid51 TT #1181
17:00 kid51 http://trac.parrot.org/parrot/ticket/1181
17:01 kid51 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
17:02 plobsing_ s/dynopslibs/dynoplibs/
17:03 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:05 kid51 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
17:05 plobsing_ and dynops
17:06 plobsing_ I think it works using #line preprocessor statements
17:14 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:16 kid51 Could we say 'gcov *.c *.ops'?
17:18 plobsing_ I've got it
17:19 plobsing_ dynops run ops2c in the $(ROOT)/src/dynops directory
17:19 plobsing_ ops run ops2c in the $(ROOT) directory
17:19 plobsing_ thats the only diff I can see
17:19 plobsing_ it affects the #line statements, which might in turn affect gcov
17:23 theory joined #parrot
17:23 brrant joined #parrot
17:23 mikehh joined #parrot
17:26 dalek parrot: r42919 | jkeenan++ | trunk/include/parrot/pobj.h:
17:26 dalek parrot: Applying part of patch submitted by jimmy++ in �http://trac.parrot.org/parrot/ticket/1346.
17:26 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42919/
17:26 Zak joined #parrot
17:31 fperrad japhb, see http://github.com/TiMBuS/fun/​blob/master/plumage/fun.json
18:02 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
18:03 dukeleto 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:07 dukeleto flh: do you have a branch somewhere?
18:10 flh only my local copy of parrot's trunk
18:10 dukeleto flh: svn or git branch ?
18:11 colomon joined #parrot
18:11 flh svn: the only thing I've done for the moment is a checkout of the trunk
18:14 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:15 dukeleto colomon: --debugging=1 is default
18:17 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
18:18 colomon Is this most easily done by hacking the top-level Makefile?
18:19 dukeleto colomon: yes
18:19 colomon Groovy.  Thanks!
18:19 dukeleto flh: you can try to get http://github.com/notbenh/euler_bench on your system, or you can push a public branch somewhere and i can benchmark it. your call.
18:19 dukeleto colomon: no worries
18:20 ttbot joined #parrot
18:21 flh dukeleto, git complains about your URI, I'm trying to find why
18:21 Zak joined #parrot
18:22 flh ok, my mistake, I found the clone URI
18:25 dukeleto flh: :)
18:29 plobsing_ config/gen/platform/ansi/exec.c Parrot_Exec_OS_Comman()
18:29 plobsing_ shouldn't that be Parrot_Exec_OS_Comman*d*()
18:30 plobsing_ ?
18:30 flh dukeleto, ok, git cloned euler_bench, and installed dependencies: what's my next move?
18:31 mikehh joined #parrot
18:32 dalek parrot: r42920 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
18:32 dalek parrot: [distutils] throws an exception when a command system fails
18:32 dalek parrot: review: http://trac.parrot.org/parrot/changeset/42920/
18:34 dukeleto flh: write a yaml file
18:35 dukeleto flh:  there is an example in examples/
18:36 dukeleto 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 dukeleto 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
18:36 dalek tpfwiki: unregisteredlewis@gmail.com | Parrot
18:36 dalek tpfwiki: http://www.perlfoundation.o​rg/parrot/index.cgi?parrot
18:37 dukeleto flh: then you should be good to go
18:37 dukeleto flh: i would recommend at least --count=100 to get good results
18:37 dukeleto flh: and look out for outliers
18:39 dukeleto fucking spammers
18:41 mikehh joined #parrot
18:42 dukeleto can we just delete http://www.perlfoundation.org/parrot/ ?
18:42 dukeleto or make it read only?
18:42 moritz deletion +1
18:42 dukeleto dealing with spammers on wiki we don't care about anymore is just fucking insane
18:42 moritz making it RO seems like a bad idea, because it will be outdated very soon
18:42 moritz (or is already, dunno)
18:43 dalek tpfwiki: jonathan@leto.net | Parrot
18:43 dalek tpfwiki: http://www.perlfoundation.o​rg/parrot/index.cgi?parrot
18:43 dukeleto moritz: it consists of a single page with no content linking to our current wiki
18:44 dukeleto moritz: which can be vandalized
18:44 dukeleto like it just was, by Zend people
18:44 dalek parrot-plumage: 5313c87 | japhb++ | metadata/fun.json:
18:44 dalek parrot-plumage: [METADATA] add fun, care of fperrad++
18:44 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/5313c87e2dc0e0da99b8b606a3ae1d1f3ad92bbb
18:44 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.
18:45 moritz ok, RO then
18:46 mikehh joined #parrot
18:47 dukeleto japhb: redirect would be better
18:48 dukeleto japhb: i just sent an email to tpf-steering. we shall see
18:48 japhb dukeleto, if that works in that particular system, great
18:48 japhb I just assumed it would be easier to set RO than 302
18:48 japhb (or actually, 301, come to think of it)
19:38 colomon__ joined #parrot
19:42 integral joined #parrot
19:43 Zak joined #parrot
20:12 cognominal joined #parrot
20:29 Whiteknight joined #parrot
20:35 Whiteknight good afternoon #parrot
20:36 pmichaud good afternoon, whiteknight
20:37 Whiteknight I'm looking through your email now, pmichaud
20:37 pmichaud thanks :)
20:38 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.
20:38 Whiteknight True, but you still have semantics beyond what little you've shown that need to be satisfied
20:38 pmichaud it's any language that needs to be able to have loop "continue" or "break" from within a nested lexical block.
20:39 pmichaud so my example applies at least to PHP, Perl 5, and Perl 6
20:39 pmichaud I suspect to python also, but I'm not familiar enough with python to say for sure.
20:41 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.
20:44 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.
20:45 pmichaud I just figured that the loop control breaks illustrated the problem more directly.
20:46 bacek joined #parrot
20:47 Whiteknight in Perl6, can people define custom handlers for last/next?
20:47 pmichaud yes.
20:48 pmichaud and next/last are indeed functions, not keywords.
20:48 Whiteknight see, all my ideas heretofore don't satisfy that
20:50 pmichaud tcl has the same issue as well, I believe.
20:50 lucian joined #parrot
20:50 Whiteknight Let me recap really quick:
20:51 Whiteknight 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)
20:51 Whiteknight pmichaud: whether you agree or not, those two factors together are the "inferior runloop problem"
20:51 pmichaud no, I think the inferior runloop is independent of label-based exception handlers.
20:52 pmichaud 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
20:52 Whiteknight no, sub-based handlers will be immune from those problems. They were conceived as being a solution
20:52 pmichaud I'd like to see how a sub-based exception handler resolves the inferior runloop problem.
20:52 pmichaud I don't think it does.
20:53 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 Whiteknight but in short, I have no doubt about it
20:53 pmichaud as I said, an example would really help.
20:54 pmichaud 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?
20:54 purl the PIR version is probably gone i think
20:54 Whiteknight purl forget the PIR version
20:54 purl Whiteknight: I forgot pir version
20:55 pmichaud TT #833
20:55 moritz http://groups.google.com/group/parrot-dev/b​rowse_thread/thread/b87325c1113d15c6?pli=1
20:56 pmichaud I can come up with an even smaller example.
21:01 nopaste "pmichaud" at 66.25.4.52 pasted "smaller inferior runloop example (for whiteknight++)" (28 lines) at http://nopaste.snit.ch/18981
21:03 pmichaud actually, let me revise that a bit.
21:05 nopaste "pmichaud" at 66.25.4.52 pasted "smaller inferior runloop example #2 (for whiteknight++)" (31 lines) at http://nopaste.snit.ch/18982
21:06 Whiteknight yes, that's a very concise example
21:06 pmichaud let me add a small complicating factor
21:08 nopaste "pmichaud" at 66.25.4.52 pasted "smaller inferior runloop example #3 (for whiteknight++)" (36 lines) at http://nopaste.snit.ch/18983
21:09 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 kurahaupo joined #parrot
21:10 Whiteknight result would have to be a lexical
21:11 Whiteknight 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 Whiteknight or, within the context where they are defined, I mean
21:11 pmichaud even assuming it's a lexical, I don't see how control returns to 'main' when an exception occurs.
21:12 Whiteknight a continuation
21:12 purl a continuation is probably builded inside the opcode, there is no way to pass a differente location.
21:12 Whiteknight purl forget a continuation
21:12 purl Whiteknight: I forgot continuation
21:12 pmichaud isn't that what we have now... a continuation?
21:14 Whiteknight okay, let me rephrase a little
21:14 pmichaud a complete example of the above would be far more illustrative :)
21:14 Whiteknight something has to give. What we have now is broken, so we need to change *something*
21:14 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.
21:14 pmichaud or, if they are, I don't see how sub-based continuations resolve that.
21:14 Whiteknight we could prohibit that exceptions thrown in a nested runloop cannot be handled by a handler defined in an external runloop
21:14 Whiteknight but you've already said that option is unacceptable
21:15 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
21:15 Whiteknight I'm talking about 3.0, and there's no guarantee we would even completely solve it
21:16 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
21:17 Whiteknight aligned
21:17 Whiteknight here's what we need: (more)
21:17 mikehh joined #parrot
21:17 pmichaud having every handler end with explicit rethrow or continue-at isn't exclusive to label-based exception handlers, though.
21:18 pmichaud 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
21:18 Whiteknight you find a way, we;ll do it
21:18 pmichaud we don't have to enforce it (more)
21:18 pmichaud the enforcement is  "if you don't do this, then you get inferior runloops"
21:18 Whiteknight we need to enforce it. That's the problem in a nutshell
21:19 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
21:19 pmichaud ...note that I didn't get a segfault, I got an exception.
21:19 pmichaud getting an exception is valid.
21:19 Whiteknight then you won the crapshoot
21:19 Whiteknight because more often than not segfaults happen in these cases
21:20 pmichaud I'm not sure that's true anymore.
21:20 Whiteknight maybe somebody wallpapered over that nasty effect
21:20 pmichaud all of the inferior runloops we've been getting lately are exceptions, not segfaults.
21:20 pmichaud anyway, all I'm saying is that the solution (require rethrow or continue-at semantics)  doesn't absolutely require sub-based exceptions to work
21:21 pmichaud beyond that, this problem exists for more than just exceptions -- it exists for any form of continuation
21:21 pmichaud i.e., anytime an inferior runloop invokes a continuation from a superior runloop
21:21 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
21:22 Whiteknight and what we need to do is limit the number of cases where we even need to check
21:22 Whiteknight otherwise the fix is intractably complicated
21:22 pmichaud I think that goes against parrot's underlying model.
21:22 pmichaud (limit the number of cases where we check)
21:22 pmichaud but you'd have to discuss that part with allison.
21:22 Whiteknight parrot's underlying model is broke
21:22 pmichaud no, I mean the model of having continuation-based control.
21:23 pmichaud 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 pmichaud 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
21:23 Whiteknight no, not get rid of continuations
21:25 pmichaud anyway, I have to head off to my soccer playoffs
21:27 Andy joined #parrot
21:27 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:29 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:30 dukeleto 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:31 pmichaud dukeleto: perhaps you weren't, but japhb did.
21:32 bacek joined #parrot
21:34 pmichaud my fear is mainly that it gets people to look at the wrong things and draw the wrong conclusions.
21:41 Whiteknight build with --maintainer is broken
21:41 Whiteknight at least on my system
21:44 Whiteknight hmmm...nevermind It seems to work now
21:45 NotFound Winxed also uses label based exception handlers.
21:47 Whiteknight everybody uses them right now
21:47 Whiteknight it's the only real option
21:52 chromatic joined #parrot
21:52 mikehh All tests PASS (pre/post-config, smoke (#30663), fulltest) at r42920 - Ubuntu 9.10 amd64 (g++ with --optimize)
22:08 cotto chromatic, ping
22:15 dalek parrot-linear-algebra: 4c9c5dc | Whiteknight++ |  (3 files):
22:15 dalek parrot-linear-algebra: Merge branch 'master' of git@github.com:Whiteknight/parrot-linear-algebra
22:15 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/4c9c5dce9802b017cfbb32a818f0f9003938b864
22:15 dalek parrot-linear-algebra: c8a29fd | Whiteknight++ | t/harness:
22:15 dalek parrot-linear-algebra: harness now exits with non-zero status on failure. This makes the sanity test chaining do the right thing
22:15 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/c8a29fdd15c4ad164a2cdb5e343cbe1106e32075
22:15 dalek parrot-linear-algebra: 30ff9cc | Whiteknight++ | t/00-sanity.t:
22:15 dalek parrot-linear-algebra: fix the sanity test so that things are sane on failure
22:15 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/30ff9ccaf5a90d95136c7a4052da7b86650d02d8
22:15 dalek parrot-linear-algebra: 201b7b2 | Whiteknight++ | t/ (2 files):
22:15 dalek parrot-linear-algebra: rename 00-sanity to just sanity
22:15 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/201b7b25f9487995996b331c14b34891d796d12f
22:29 chromatic pong
22:31 dalek winxed: r246 | julian.notfound++ | trunk/ (3 files):
22:31 dalek winxed: return in stage 1
22:31 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=246
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.
22:31 cotto 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.
22:31 cotto 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.
22:32 chromatic As long as you don't cause allocations from Parrot's GC, that should be okay.
22:33 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.
22:33 cotto yes
22:34 chromatic There'll be some hash reallocations, but those amortize out.
22:36 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:37 colomon_ joined #parrot
22:37 chromatic Makes sense.
22:38 naypalm can't we just have an extremely slow language with an awesome data type?!
22:38 cotto naypalm, atm we call that "Rakudo" ;)
22:39 naypalm well maybe! I do love the pmc though
22:39 Zak joined #parrot
22:42 cotto chromatic, thanks.
22:46 dalek matrixy: c3c9dc8 | Whiteknight++ | t/ (2 files):
22:46 dalek matrixy: move the operators test to the syntax folder
22:47 dalek matrixy: review: http://github.com/Whiteknight/matrixy/commi​t/c3c9dc8daf44cd9aba5531f4fdb6b5d3e82af57f
22:47 dalek matrixy: d8fc170 | Whiteknight++ |  (8 files):
22:47 dalek matrixy: start breaking the 303-matrix-operations test file into individual files for different operations
22:47 dalek matrixy: review: http://github.com/Whiteknight/matrixy/commi​t/d8fc170c30679c5adc83f977d9ec5173cdf35c49
22:47 dalek matrixy: db4b1db | Whiteknight++ | t/ (7 files):
22:47 dalek matrixy: break the remaining function tests out of the matrix-operations conglomerate file
22:47 dalek matrixy: review: http://github.com/Whiteknight/matrixy/commi​t/db4b1db98ad890768d534bb4e23d753e9a1140da
22:47 dalek matrixy: abf0b10 | Whiteknight++ | t/functions/mtimes.t:
22:47 dalek matrixy: fix the mtimes function tests
22:47 dalek matrixy: review: http://github.com/Whiteknight/matrixy/commi​t/abf0b10d37fc4daa2eac5ea7f7e55a22576c0d9b
23:30 Zak joined #parrot
23:34 jan joined #parrot
23:39 mikehh joined #parrot
23:45 cotto headerizer's error messages leave much to be desired
23:46 payload joined #parrot
23:49 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."
23:50 Whiteknight cotto: in other news, headerizer has error messages?
23:51 Whiteknight I thought it failed silently
23:51 mikehh joined #parrot
23:53 cotto it are dum
23:53 davidfetter joined #parrot
23:55 cotto It gives error messages about things that aren't there

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

Parrot | source cross referenced