Camelia, the Perl 6 bug

IRC log for #parrot, 2011-01-20

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:01 kid51 joined #parrot
00:03 dalek parrot: 7b57371 | dukeleto++ | / (3 files):
00:03 dalek parrot: Merge branch 'leto/embed_grant'
00:03 dalek parrot: review: https://github.com/parrot/parrot/commit/7b573714cd
00:03 dalek parrot: f82c288 | dukeleto++ | t/src/extend_vtable.t:
00:03 dalek parrot: Add a coda to t/src/extend_vtable.t
00:03 dalek parrot: review: https://github.com/parrot/parrot/commit/f82c2880fd
00:03 dalek parrot: 947dcf8 | dukeleto++ | t/src/extend_vtable.t:
00:03 dalek parrot: Comment out test so that POD syntax tests don't fail
00:03 dalek parrot: review: https://github.com/parrot/parrot/commit/947dcf8410
00:09 dalek parrot/exceptions_subclass: ed2c343 | Whiteknight++ | / (88 files):
00:09 dalek parrot/exceptions_subclass: Merge branch 'master' into exceptions_subclass
00:09 dalek parrot/exceptions_subclass: review: https://github.com/parrot/parrot/commit/ed2c343069
00:20 mtk left #parrot
00:27 mtk joined #parrot
00:38 nopaste "kid51" at 192.168.1.3 pasted "t/src/extend_vtable.t: new failures" (114 lines) at http://nopaste.snit.ch/28229
00:42 dalek left #parrot
00:42 elmex left #parrot
00:42 rurban_ joined #parrot
00:42 kid51 The failures in that paste were with g++ all around
00:42 Maddingue left #parrot
00:42 snarkyboojum_ joined #parrot
00:42 whiteknight left #parrot
00:42 rurban left #parrot
00:42 perlite left #parrot
00:42 pmichaud left #parrot
00:42 jjore left #parrot
00:42 simcop2387 left #parrot
00:42 TonyC left #parrot
00:42 Khisanth left #parrot
00:42 Kulag left #parrot
00:42 aloha left #parrot
00:42 slavorg left #parrot
00:42 shortcir1uit left #parrot
00:42 GeJ left #parrot
00:42 krunen left #parrot
00:42 bacek_at_work left #parrot
00:42 dngor left #parrot
00:42 slavorgn left #parrot
00:42 snarkyboojum left #parrot
00:42 eternaleye left #parrot
00:42 ascent left #parrot
00:42 ingy left #parrot
00:42 edenc left #parrot
00:42 snarkyboojum_ is now known as snarkyboojum
00:42 kid51 left #parrot
00:42 bacek left #parrot
00:42 particle left #parrot
00:42 nwellnhof left #parrot
00:42 Tene left #parrot
00:42 NotFound left #parrot
00:42 confound left #parrot
00:42 Kovensky left #parrot
00:42 KaeseEs left #parrot
00:42 hatseflats left #parrot
00:42 estrabd left #parrot
00:42 Kapace left #parrot
00:42 frodwith left #parrot
00:42 sECuRE_ left #parrot
00:42 mj41 left #parrot
00:42 Infinoid left #parrot
00:42 PacoLinux left #parrot
00:42 tadzik left #parrot
00:42 rblackwe_ left #parrot
00:42 Util left #parrot
00:42 AzureStone left #parrot
00:42 davidfetter left #parrot
00:42 theory left #parrot
00:42 Myhrlin_ left #parrot
00:42 Patterner left #parrot
00:42 chromatic left #parrot
00:42 TimToady left #parrot
00:42 cosimo left #parrot
00:43 PerlJam left #parrot
00:43 snarkyboojum left #parrot
00:43 mtk left #parrot
00:43 cogno left #parrot
00:43 wagle left #parrot
00:43 p6eval left #parrot
00:43 athomason left #parrot
00:43 Coke left #parrot
00:43 TiMBuS left #parrot
00:43 allison left #parrot
00:43 jan left #parrot
00:43 workbench left #parrot
00:43 sjn left #parrot
00:43 extreme left #parrot
00:43 dip left #parrot
00:43 he left #parrot
00:43 dukeleto left #parrot
00:43 jnthn left #parrot
00:43 sri left #parrot
00:43 rurban_ is now known as rurban
00:43 sri joined #parrot
00:46 snarkyboojum joined #parrot
00:46 mtk joined #parrot
00:46 kid51 joined #parrot
00:46 cogno joined #parrot
00:46 bacek joined #parrot
00:46 particle joined #parrot
00:46 wagle joined #parrot
00:46 davidfetter joined #parrot
00:46 nwellnhof joined #parrot
00:46 theory joined #parrot
00:46 Myhrlin_ joined #parrot
00:46 Patterner joined #parrot
00:46 chromatic joined #parrot
00:46 KaeseEs joined #parrot
00:46 p6eval joined #parrot
00:46 TimToady joined #parrot
00:46 Tene joined #parrot
00:46 NotFound joined #parrot
00:46 cosimo joined #parrot
00:46 PerlJam joined #parrot
00:46 confound joined #parrot
00:46 athomason joined #parrot
00:46 Kovensky joined #parrot
00:46 frodwith joined #parrot
00:46 hatseflats joined #parrot
00:46 estrabd joined #parrot
00:46 Kapace joined #parrot
00:46 sECuRE_ joined #parrot
00:46 AzureStone joined #parrot
00:46 mj41 joined #parrot
00:46 rblackwe_ joined #parrot
00:46 Infinoid joined #parrot
00:46 tadzik joined #parrot
00:46 PacoLinux joined #parrot
00:46 Util joined #parrot
00:46 Coke joined #parrot
00:46 TiMBuS joined #parrot
00:46 allison joined #parrot
00:46 jan joined #parrot
00:46 workbench joined #parrot
00:46 sjn joined #parrot
00:46 extreme joined #parrot
00:46 dip joined #parrot
00:46 he joined #parrot
00:46 dukeleto joined #parrot
00:46 jnthn joined #parrot
00:46 dalek joined #parrot
00:46 elmex joined #parrot
00:46 whiteknight joined #parrot
00:46 perlite joined #parrot
00:46 pmichaud joined #parrot
00:46 jjore joined #parrot
00:46 simcop2387 joined #parrot
00:46 TonyC joined #parrot
00:46 Khisanth joined #parrot
00:46 Kulag joined #parrot
00:46 aloha joined #parrot
00:46 shortcir1uit joined #parrot
00:46 GeJ joined #parrot
00:46 krunen joined #parrot
00:46 bacek_at_work joined #parrot
00:46 dngor joined #parrot
00:46 slavorgn joined #parrot
00:46 eternaleye joined #parrot
00:46 ascent joined #parrot
00:46 ingy joined #parrot
00:46 edenc joined #parrot
00:47 Maddingue joined #parrot
00:50 slavorg joined #parrot
01:01 kid51 Here's a smolder reporting the failures I recently pasted with a g++ build:  http://smolder.parrot.org/app​/projects/report_details/4044
01:04 davidfetter left #parrot
01:08 whiteknight nwellnhof: ping
01:10 dalek parrot: 07fbbcf | Whiteknight++ | / (8 files):
01:10 dalek parrot: Merge branch 'exceptions_subclass'
01:10 dalek parrot: review: https://github.com/parrot/parrot/commit/07fbbcfb7d
01:11 nwellnhof whiteknight: pong
01:13 whiteknight nwellnhof: false alarm.
01:13 whiteknight I was failing some unicode tests in NQP, but I don't have ICU on this box
01:16 kid51 Those tests passed with a regular gcc build
01:16 kid51 http://smolder.parrot.org/app​/projects/report_details/4050
01:18 whiteknight dukeleto: ping
01:18 kid51 is now known as kid51_at_dinner
01:34 whiteknight blah. I need an op that's a no-op but won't get optimized out by IMCC
01:39 sorear imcc optimizes out nop?
02:00 kid51_at_dinner is now known as kid51
02:01 plobsing joined #parrot
02:01 cosimo left #parrot
02:05 nwellnhof left #parrot
02:35 whiteknight sorear: IMCC optimizes out some constant operations
02:36 whiteknight this rethrow bug is turning out to be very difficult to track down
02:40 whiteknight whatever, I'm going to bed now
02:40 whiteknight goodnight
02:40 whiteknight left #parrot
03:03 cotto ~~
03:03 cotto aloha, clock?
03:03 aloha cotto: LAX: Wed, 19:03 PST / CHI: Wed, 21:03 CST / NYC: Wed, 22:03 EST / UTC: Thu, 03:03 UTC / LON: Thu, 03:03 GMT / BER: Thu, 04:03 CET / TOK: Thu, 12:03 JST / SYD: Thu, 14:03 EST
03:11 spinclad joined #parrot
03:43 Yuki`N joined #parrot
03:45 Yuki`N I was using gist.
03:45 cotto I'm sure you were.
03:45 Yuki`N And I see there's a "Parrot Internal Representation" language in the syntax highlight options.
03:46 cotto istr dukeleto having something to do with that
03:50 kid51 Yuki`N: Were you the person who was working on pretty-printing for gdb?
03:51 Yuki`N Yes.
03:51 Yuki`N Does it not work?
03:52 Yuki`N Or is this the whole codestd explosion I saw on the mailing list.
03:52 kid51 Can you give it a try?  We added copyright notices to all .py files in the distro -- including those two you added for that purpose.
03:52 Yuki`N Ummm.
03:52 kid51 I just have to see if I did no harm.
03:52 Yuki`N Let me start my vm up.
03:52 Yuki`N You added comments, it really shouldn't matter.
03:52 kid51 Agreed, but I want to be 100% sure.
03:53 Yuki`N Let me start my VM.
04:09 kid51 Yuki`N:  Can you post your findings here? I have to go to sleep now but will backscroll in the a.m.
04:11 kid51 left #parrot
04:13 Yuki`N OK.
04:17 bacek left #parrot
04:21 Yuki`N I verified that it still works.
04:22 cotto Yuki`N, is python built in to the proper versions of gdb or is it a separate dependency?
04:23 Yuki`N If gdb is not built with python it will not run the pretty-printers.
04:23 Yuki`N So it's built-in.
04:24 cotto ok
04:24 Yuki`N My eyes are suddenly killing me.
04:24 Yuki`N I'm going to sleep, night all.
04:24 Yuki`N left #parrot
04:24 cotto 'night
04:25 JimmyZ joined #parrot
04:28 bacek joined #parrot
05:13 JimmyZ left #parrot
05:45 Patterner left #parrot
05:45 Psyche^ joined #parrot
05:45 Psyche^ is now known as Patterner
05:46 dukeleto ~~
05:50 cotto hio dukeleto
05:50 rurban_ joined #parrot
05:52 rurban left #parrot
05:53 rurban_ is now known as rurban
05:54 dukeleto cotto: wazzup
05:55 dukeleto whiteknight: pong
05:56 dukeleto i see that i caused some g++ failures
05:56 * dukeleto will now test with both gcc and g++ before pushing
05:57 dukeleto cotto: we can update the /topic, yes? The plumage wiki page is written
05:58 cotto dukeleto, sure
05:59 dukeleto cotto: what other goal should we put in the /topic ?
05:59 * dukeleto forgot what they were
06:18 cogno left #parrot
06:19 cogno joined #parrot
06:20 Topic for #parrot is now Parrot 3.0.0 Released | http://parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: Deprecations as data, merge/cleanup, AutomatedHLLTesting, clean up false test failures
06:22 rurban left #parrot
06:22 TimToady left #parrot
06:22 chromatic left #parrot
06:22 Myhrlin_ left #parrot
06:22 PerlJam left #parrot
06:22 theory left #parrot
06:26 rurban joined #parrot
06:26 theory joined #parrot
06:26 Myhrlin_ joined #parrot
06:26 chromatic joined #parrot
06:26 TimToady joined #parrot
06:26 PerlJam joined #parrot
06:35 cogno left #parrot
06:36 cogno joined #parrot
06:42 cogno left #parrot
06:43 dukeleto c_output_is doesn't respect $TODO and that is very annoying
06:46 * cotto hands dukeleto a yak razor
06:47 cogno joined #parrot
06:53 cogno left #parrot
07:04 dukeleto i've uncovered another bug, methinks
07:04 dukeleto Parrot_PMC_is_equal_num is broken
07:06 * dukeleto sharpens his trusty yak razor
07:08 dukeleto actually, reading the docs is much easier
07:08 dukeleto c_output_is takes a todo => "foo" argument
07:09 cotto I think I'm proud of Parrot for joining the 323 club.
07:16 dukeleto cotto: ?
07:17 dukeleto I think tonight is the first case where I saw tests pass in gcc, but fail with typecast warnings in g++, and then realized that the typecasts were dead wrong and made the test pass for the wrong reason.
07:17 dukeleto I guess I have seen the g++ light
07:18 cotto dukeleto, gcc bug 323
07:18 cotto the floating point excess precision bug
07:22 dalek parrot: c8cbcb6 | dukeleto++ | t/src/extend_vtable.t:
07:22 dalek parrot: [t] Fix extend_vtable tests, make them g++-clean and properly TODO two tests
07:22 dalek parrot: review: https://github.com/parrot/parrot/commit/c8cbcb6d6d
07:24 * dukeleto looks at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 in amazement
07:27 cotto I saw it earlier last week on a PHP bug were a certain floating point number could freeze the PHP interp.
07:31 dukeleto wow
07:31 dukeleto cotto: you have a link for that?
07:34 cotto dukeleto, sure.  just a sec
07:35 cotto http://bugs.php.net/bug.php?id=53632
07:35 cotto They made a point release to fix it.
07:36 cotto It's pretty epic.
07:39 dalek TT #1982 created by dukeleto++: Parrot_PMC_thaw and Parrot_PMC_freeze broken
07:39 dalek TT #1982: http://trac.parrot.org/parrot/ticket/1982
07:50 dukeleto cotto: Parrot_PMC_set_string_native and Parrot_PMC_assign_string_native both do the same thing. Why?
07:54 * cotto looks
07:55 chromatic left #parrot
07:55 dalek TT #1983 created by dukeleto++: Parrot_PMC_is_equal_num seems broken
07:55 dalek TT #1983: http://trac.parrot.org/parrot/ticket/1983
07:55 dalek TT #1928 closed by cotto++: get_bool function of Rational dynpmc
07:55 dalek TT #1928: http://trac.parrot.org/parrot/ticket/1928
07:55 cotto Maybe it was an early attempt at sane assignment semantics.
07:57 dukeleto cotto: can you give me an example of a valid call to the clone_pmc vtable ?
07:57 dukeleto cotto: i don't understand what the second argument pmc needs to be
07:57 sorear cotto: did one of them clone the string back when strings were mutable?
07:57 dukeleto sorear: ah, that might be it. they were different before immutable strings
07:58 cotto dukeleto, there's exactly one PMC that implements that slot.
07:58 cotto I guess it's supposed to be a modifier to the clone.
07:58 cotto -1 to keeping it
07:59 dukeleto cotto: would you like to make the TT to remove it?
08:00 cotto I will soon have just done it.
08:04 dalek Heuristic branch merge: pushed 17 commits to parrot/leto/embed_grant by leto
08:04 cotto actually, Rakudo seems to be using it
08:04 dalek parrot: 4abcaa1 | dukeleto++ | / (99 files):
08:04 dalek parrot: Merge branch 'master' into leto/embed_grant
08:04 dalek parrot: review: https://github.com/parrot/parrot/commit/4abcaa12df
08:04 dalek parrot: 7e78673 | dukeleto++ | t/src/extend_vtable.t:
08:04 dalek parrot: [t] Exercise Parrot_PMC_assign_string_native
08:04 dalek parrot: review: https://github.com/parrot/parrot/commit/7e78673dad
08:04 cotto or not.  It looks generated.
08:04 dalek parrot: 65325aa | dukeleto++ | t/src/extend_vtable.t:
08:04 dalek parrot: [t] Parrot_PMC_clone
08:04 dalek parrot: review: https://github.com/parrot/parrot/commit/65325aaa93
08:07 mtk left #parrot
08:11 dalek TT #1984 created by cotto++: Remove clone_pmc VTABLE slot
08:11 dalek TT #1984: http://trac.parrot.org/parrot/ticket/1984
08:13 cotto dukeleto, is there a nice way to partially revert a commit?
08:14 mtk joined #parrot
08:19 theory left #parrot
08:20 dalek parrot/rethrow_madness: 3db4060 | cotto++ | t/op/rethrow.t:
08:20 dalek parrot/rethrow_madness: try to make the rethrow test easier to follow
08:20 dalek parrot/rethrow_madness: review: https://github.com/parrot/parrot/commit/3db40606bd
08:20 dukeleto cotto: hmmm
08:21 dukeleto cotto: depends
08:21 cotto all the changes are limited to one fie
08:21 cotto file
08:25 cotto I think I got it, though I'm not entirely sure what I did.
08:29 dalek parrot: 572deb0 | cotto++ | src/pmc/capture.pmc:
08:29 dalek parrot: revert removal of dead VTABLE functions, since a proper PIR compiler will generate code to call them
08:29 dalek parrot: review: https://github.com/parrot/parrot/commit/572deb0943
08:32 cotto That git/trac integration was definitely worthwhile.
08:36 dukeleto cotto: indeed. did you figure out the revert issue?
08:36 cotto more or less
08:38 dukeleto cotto: you can do "git checkout branchname/sha1 -- filename" to checkout a version of a file from a sha1/branch
08:38 dukeleto cotto: good
08:38 cotto I'll remember that.
08:39 * cotto wonders if he can get 1 net ticket closed
08:39 dukeleto cotto: it is useful if you want to revert part of a commit that is confined to a single file
08:39 dukeleto cotto: there is also git add -p , but it is more black-magic-ish
08:45 dalek TT #1914 closed by cotto++: Dead code in src/pmc/Capture.pmc
08:45 dalek TT #1914: http://trac.parrot.org/parrot/ticket/1914
08:47 cotto dukeleto, is there a way to pass a cli option to a PIR script from a test?
08:47 cotto #800 should be nearly trivial to test
08:53 * cotto finally found a ticket
08:53 dukeleto cotto: probably
08:53 dukeleto cotto: depends if the test is PIR or Perl
09:01 cotto Either the Nigerian Lottery is legitimate or I need to go to bed.
09:01 cotto 'night
09:01 dalek TT #765 closed by cotto++: zero-length files from "make html"
09:01 dalek TT #765: http://trac.parrot.org/parrot/ticket/765
09:01 dalek TT #820 closed by cotto++: dynops should show up in docs/ops...
09:01 dalek TT #820: http://trac.parrot.org/parrot/ticket/820
09:16 TiMBuS left #parrot
09:31 TiMBuS joined #parrot
10:34 cogno joined #parrot
10:50 dalek parrot/nqp_pct: 64d13f5 | bacek++ | compilers/pct/src/POST/Compiler.pm:
10:50 dalek parrot/nqp_pct: Rewrite POST::Compiler.to_pir in nqp.
10:50 dalek parrot/nqp_pct: review: https://github.com/parrot/parrot/commit/64d13f579a
10:56 fperrad joined #parrot
11:30 dalek TT #1934 closed by jkeenan++: Some Python programs added to tools/dev
11:30 dalek TT #1934: http://trac.parrot.org/parrot/ticket/1934
11:48 cogno left #parrot
11:48 cogno joined #parrot
12:07 cogno left #parrot
12:07 dalek parrot: 8d7363d | jkeenan++ | lib/Parrot/BuildUtil.pm:
12:07 dalek parrot: [codingstd] Fix 3 Perl weaknesses detected by 'make cagecritic'.
12:07 dalek parrot: review: https://github.com/parrot/parrot/commit/8d7363d9d7
12:07 dalek parrot: c52bfa4 | jkeenan++ | lib/Parrot/Configure/Options/Test.pm:
12:07 dalek parrot: [codingstd] Fix 2 Perl weaknesses detected by 'make cagecritic'.
12:07 dalek parrot: review: https://github.com/parrot/parrot/commit/c52bfa4dbc
12:07 dalek parrot: 63312b2 | jkeenan++ | lib/Parrot/Headerizer.pm:
12:07 dalek parrot: [codingstd] Fix 1 Perl weakness detected by 'make cagecritic'.
12:07 dalek parrot: review: https://github.com/parrot/parrot/commit/63312b215e
12:08 kid51 joined #parrot
12:15 cogno joined #parrot
12:22 he_ joined #parrot
12:37 JimmyZ joined #parrot
12:40 JimmyZ left #parrot
13:05 cogno left #parrot
13:22 dalek parrot: 84b5e3b | jkeenan++ | lib/Parrot/ (2 files):
13:22 dalek parrot: [codingstd] Fix several Perl weaknesses detected by 'make cagecritic'.
13:22 dalek parrot: review: https://github.com/parrot/parrot/commit/84b5e3b1e0
13:24 kid51 It's too bad I didn't know about 'make cagecritic' during GCI.  We could have made up to 1,224 tasks from it!
13:24 kid51 left #parrot
13:27 fperrad_ joined #parrot
13:31 fperrad left #parrot
13:31 fperrad_ is now known as fperrad
13:37 whiteknight joined #parrot
13:39 whiteknight good morning, #parrot
13:41 whiteknight msg NotFound I've figured out that rethrow issue, and it's probably WONTFIX. The rethrow takes the list of handlers at the time the rethrow happens. ExceptionHandlers added to the stack after the rethrow are not included in the handler_iter. A throw resets that list
13:41 aloha OK. I'll deliver the message.
13:41 whiteknight msg plobsing I've figured out that rethrow issue, and it's probably WONTFIX. The rethrow takes the list of handlers at the time the rethrow happens. ExceptionHandlers added to the stack after the rethrow are not included in the handler_iter. A throw resets that list
13:41 aloha OK. I'll deliver the message.
13:43 plobsing whiteknight: I'm starting to think that the ephemeral information contained in exceptions should be hidden by the internals as much as possible
13:43 whiteknight plobsing: right, you said something like that yesterday and I'm not sure what you mean by that
13:44 whiteknight somethings, like an iterator of exception handlers, really has to be kept with the exception object. There's no where else to keep it since it's not really reusable
13:44 plobsing exactly
13:45 plobsing so that shouldn't live in the thrown object. that way, thrown objects can be reused. the internals can build exception objects (or whatever they want to use to store this info) themselves and not burden the thrower.
13:46 whiteknight so you're of the opinion that Exception should be broken up into two objects?
13:46 plobsing as soon as that happens, we no longer need to subclass Exception, because *any* object can be thrown (because there are no more requirements put on it by the internals)
13:47 whiteknight but any object then would need to be decorated with an extra pointer to the underlying exception object
13:47 plobsing why?
13:48 whiteknight maybe I don't really understand what you are talking about
13:48 whiteknight Exceptions have a lot of stuff that an ExceptionHandler might need to access.
13:48 whiteknight resume continuation, severity, message
13:49 whiteknight I can't just hand you an object of type Foo and say "here is your exception payload, this is all you get"
13:49 plobsing true. the exception handler needs access to the exception object. can exception handlers accept 2 arguments?
13:49 whiteknight they can be made to
13:49 whiteknight they are just continuations that go through normal PCC. Arguably they could take any number of arguments
13:50 plobsing wait. they are exceptions that go through pcc? can we pass them in the return continuation?
13:50 rurban_ joined #parrot
13:50 whiteknight what do you mean "pass them in the return continuation"?
13:50 whiteknight check out src/exceptions.c:Parrot_ex_throw_from_op
13:50 plobsing I had that backwards. I thought you were saying the exceptions were continuations.
13:51 plobsing need moar coffee
13:51 whiteknight no, ExceptionHandlers are continuations
13:52 whiteknight if we had a throw function or a throw method instead of a throw opcode, we could potentially pass as much data to the handler as we wanted, and the user could decide it on a case-by-case basis
13:52 whiteknight then we wouldn't need to burden Exception with all sorts of attributes that are rarely used
13:52 rurban left #parrot
13:52 rurban_ is now known as rurban
13:54 whiteknight better yet, if we had something like this: $P0 = new ['Exception'], $P2 = ctx.get_handlers_for($P0), $P3 = $P2[0], $P3($P0, ctx, ...)
13:54 whiteknight or $P2 = exception.find_handler_in_ctx(ctx)
13:54 plobsing whiteknight: ewwwww. users should not be required to do that much
13:55 whiteknight it's two lines more than they do right now, but gives infinitely more flexibility
13:55 whiteknight if you have a specific handler you want to use, you take the reference to it and just invoke it
13:56 whiteknight maybe $P0 = new ['Exception'], $P0.throw_to_first_handler(args ...)
13:56 whiteknight Adding in a method call or two here isn't a big deal since the scheduler already abuses method calls throughout
13:56 plobsing all of this is exposing Exception to the thrower, which continues the problem of users wanting to subclass exception (which they should not need to be doing)
13:57 whiteknight plobsing: Okay, take the exception object out of the equation.
13:57 whiteknight $P0 = ctx.find_exception_handler(), $P0(args, ...)
13:57 whiteknight no exception needed explicitly
13:58 whiteknight we override ExceptionHandler.invoke to take a stack trace and maybe create an Exception object for internal use only
13:58 whiteknight or silently push the Exception onto the front of the list of arguments
14:00 whiteknight I haven't really put any prior thought into this, so I'm just brain-dumping
14:01 plobsing throw as an opcode could be made variadic. I am aware you dislike variadic opcodes, but if we made, and consistently used, a convention, it should not be nearly as bad as it is now.
14:01 whiteknight that seems like it just puts a different face on an ugly pig
14:02 whiteknight if ExceptionHandlers are invokable continuations, we should just ask for a reference to an ExceptionHandler and invoke it
14:02 whiteknight instead of having an opcode with a variadic argument list that we then have to turn into a CallContext manually and perform the PCC call internally
14:02 plobsing throwing is something that people do sufficiently often that we should encapsulate the action
14:02 whiteknight exception.'throw'() seems very clean to me
14:03 whiteknight or exceptionhandler.'throw_to'(exception)
14:03 whiteknight having the benefit that method calls are designed to take variadic argument lists, and that the whole mechanism then becomes pluggable and subclassable
14:04 whiteknight exceptionhandler.'catch'(exception)
14:04 plobsing once we separate the thrown objects out, why do we need anything to be sublcassable?
14:04 whiteknight because an HLL could completely rewrite the entire exceptions mechanism to do what they want
14:05 whiteknight something like Perl6's resumable exceptions no longer need to be accounted for in our system, they add that functionality in a subclass
14:05 plobsing and as soon as they do that, they become incompatable with everything else running on parrot exception-wise
14:06 whiteknight that would be the case as soon as ExceptionHandlers start taking variadic parameter lists. a Tcl exception thrown with only one argument would cause a problem in a Rakudo handler that expects several
14:07 whiteknight we have a list of active handlers in the context. Default behavior, fallback behavior in the case of a subclass, is to ask the context for a suitable handler, and then pass the exception to that
14:07 plobsing we could have a convention for optional, named parameters
14:08 whiteknight plobsing: Conventions are fine, but if we enable that we would have to expose the entirety of PCC to it. Once you give features to users, they are going to use them
14:08 whiteknight and we are going to have to support them
14:09 plobsing OK, so back to basics then. why do exception handlers need arbitrary parameters. I proposed 2, I don't see a case for more.
14:10 whiteknight Let's say we want to set up a system with a try/catch/finally block. To the handler we would pass the exception object (stacktrace, etc), the payload, and a reference to the finally block to take over at the very end
14:10 whiteknight arguably that's a stretch, and still only brings the total up to 3 arguments
14:10 whiteknight it's something I would probably want to ask about at #ps or on parrot-users
14:12 whiteknight It's my intuition that there is win to be had by treating exceptionhandlers like normal continuations, and simply exposing a common interface. If we wanted to add restrictions on invoke to ExceptionHandler only, that would be an ugly special case to worry about
14:12 plobsing finally blocks, and more general methods like unwind-protect, are something I don't think our current system covers. I think the closest thing we have is attaching a destructor to an object in a register (so when the frame dies, the destructor/finally-block runs)
14:12 whiteknight the implementation becomes much cleaner if we just open it up and say "ExceptionHandlers are invokable. You have PCC. Use it however you see fit"
14:14 whiteknight the question still becomes how users fetch exception handlers for a particular exception
14:15 whiteknight You're definitely acting hesitant about all this. What problems are you seeing?
14:16 plobsing for one, I'm not sure I want to push the convention-selection on to users
14:17 plobsing one language has finally blocks and expects them to run on exception. another language doesn't, and doesn't bother handling them as a result. lang1 throws to a handler in lang2... boom!
14:17 plobsing plus, is there much value in finally blocks in a garbage collected language?
14:18 whiteknight finally blocks can be used for more than just destroying objects
14:18 arnsholt Closing files and such is one use-case I can see off the top of my head
14:18 whiteknight for instance, pushing a terminal delimiter to an output stream
14:19 plobsing I thought their primary use was resource-cleanup after a failed operation
14:19 arnsholt Sure, they'll be closed on GC, but in some cases you'll definitely want to ensure timely closing
14:19 whiteknight I will admit that this is the most common use, but it's certainly not the only one
14:20 plobsing is there a reason for desiring timely closing beyond file descriptor exhaustion?
14:20 atrodo Knowing that the file is close before you start another process that needs to interact with the file?
14:21 plobsing but if you failed the operation, you don't want to do that
14:21 whiteknight It's not really our job to say "these are the only use-cases that we can imagine right now, therefore we're going to insert special-case code into our software to prevent anything else"
14:22 atrodo But you may not have failed.  It might be optional.  You clean up the trailer and close the file
14:22 whiteknight like I said, the implementation is much cleaner if we simply treat ExceptionHandlers like any other invokable
14:23 * plobsing commutes
14:23 whiteknight okay
14:29 plobsing left #parrot
14:31 JimmyZ joined #parrot
14:44 ambs joined #parrot
15:08 cognominal joined #parrot
15:40 plobsing joined #parrot
15:49 cognominal left #parrot
15:57 cognominal joined #parrot
16:01 JimmyZ left #parrot
16:06 dmalcolm joined #parrot
16:28 bacek left #parrot
16:37 plobsing left #parrot
17:01 theory joined #parrot
17:08 plobsing joined #parrot
17:15 cognominal left #parrot
17:29 whiteknight P==NP proof on slashdot is pretty interesting
17:30 whiteknight and, best of all, comes with example software to prove it
17:37 Coke url?
17:37 whiteknight http://science.slashdot.org/story/11/01/20/1546​206/Polynomial-Time-Code-For-3-SAT-Released-PNP
17:38 whiteknight the PDF is free to download, which is awesome. It's written very russian english and is very dense with terminology which is not so great
17:38 whiteknight code is on github: https://github.com/anjlab/sat3
17:45 whiteknight also, the rereference software is written in Java, which isn't so great
17:47 whiteknight everything should be written on Parrot!
17:49 whiteknight of course then it would run in O(n^10) instead of O(n^4), but still
17:52 hercynium joined #parrot
17:54 plobsing whiteknight: we could add a 3sat op. ;)
17:57 chromatic joined #parrot
18:23 dukeleto ~~
18:23 cotto_work ~~
18:24 cotto_work plobsing: perfect.  "NP-complete out of the box" would be a great bit of marketing.
18:28 chromatic Parrot's only O(n^10) because I reduced parts of IMCC from O(n^18).
18:29 dukeleto chromatic: thanks for that :)
18:29 whiteknight I can't wait to decrease it to O(0)
18:29 ambs left #parrot
18:30 dukeleto chromatic: szabgab was looking for you, did he find you?
18:30 ambs joined #parrot
18:30 dukeleto chromatic: also, welcome back, stranger
18:30 whiteknight cotto: (572deb0943d80a7f7e6bb2b5fdb869eea08c9365) it's not the PIR compiler, no ops exist to call those vtables
18:31 whiteknight no compiler can generate calls to them unless we add a metric crapton more ops
18:31 cogno joined #parrot
18:31 whiteknight and that's a big -1 from me
18:33 cotto_work whiteknight: according to bacek, it's only an imcc bug that prevents those VTABLE functions from being called
18:33 whiteknight cotto_work: in so far as the collection of PIR ops is the responsibility of IMCC
18:34 whiteknight nwellnhof: ping
18:34 whiteknight if nwellnhof isn't working on IMCC soon, I'll start my next branch to continue the defenestration
18:34 dukeleto whiteknight++
18:36 plobsing cotto_work: IMCC is perfectly capable of generating a keyed-string op. you might need to drop the keyed syntax and go with '$P0 = get_pmc_keyed_str $P1, $S0', but it *is* possible.
18:37 whiteknight do those ops exist? When I was looking around at the list I didn't see any
18:37 plobsing they do not
18:37 plobsing which is why the keyed_str vtables are inaccessible
18:38 whiteknight okay, so it's still a problem of missing ops, not IMCC
18:38 jnthn huh, what
18:38 jnthn $P0 = $P1[$S0] calls that v-table, no?
18:38 * jnthn has loads of uses from C of VTABLE_get_pmc_keyed_str too
18:39 whiteknight jnthn: calls get_pmc_keyed, not get_pmc_keyed_str
18:39 jnthn whiteknight:
18:39 whiteknight default PMC may translate an unimplemented get_pmc_keyed VTABLE to get_pmc_keyed_str
18:39 jnthn What?
18:39 jnthn You mean it boxes the string just to make the call?
18:40 whiteknight https://github.com/parrot/parrot/​blob/master/src/ops/set.ops#L339
18:40 mtk left #parrot
18:40 whiteknight IMCC boxes the string into a Key PMC, yes
18:40 whiteknight that's what the [] bracket syntax does
18:40 plobsing except for ints sometimes
18:41 whiteknight yeah, an int can be an INTKEY
18:41 whiteknight which is not treated as stupidly
18:41 jnthn It's still an extra throw-away GCable though
18:41 plobsing no. those keys are static
18:41 jnthn Ah, OK
18:41 plobsing they are references to the registers
18:41 jnthn Just get populated with the passed string each time?
18:41 whiteknight yeah, the keys are constant. Kept in the constants table and repeatedly marked over and over and over again
18:42 whiteknight no, the string is constant too
18:42 whiteknight well, it could be
18:42 jnthn Yeah, it still seems a tad wasteful when the vtable could be called too :)
18:42 jnthn er, :(
18:42 whiteknight jnthn: a tad wasteful?
18:42 plobsing it is a single pointer-dereference in most cases
18:42 whiteknight unfortunately, "a bajillion wasteful" is bad grammar, or I would say that
18:44 plobsing whiteknight: if you want to get into wastefulness in the constant table, lets talk about PCC
18:44 whiteknight lets do
18:44 whiteknight PCC needs a hell of a lot of work
18:44 whiteknight the ideas are there, but we need to cut a lot of fat off the bone
18:46 plobsing because every PCC signature exists as its own constant FIA, they are de-dupped by IMCC within a single PBC, but there is no mechanism for de-duping them between PBCs
18:46 mtk joined #parrot
18:47 whiteknight if we still have set_args being a variadic opcode taking a constant FIA by the 4.0 release, I'll eat my foot
18:48 plobsing but const-table wastefullness becomes much less important if and when we get a GC that can cope with long-lived objects
18:48 whiteknight yeah, we are going to need to get that GC up and running soon
18:48 mtk left #parrot
18:48 whiteknight after this IMCC/packfile stuff, I may need to focus on that for a while
18:48 whiteknight we all may need to
18:49 plobsing whiteknight: we could get rid of the variadicity right now if you like. you can replace the variable number of registers with a key. keys are, after all, a variable list of references to registers and constants.
18:50 plobsing however, I have a sneaking suspicion you won't like that solution
18:50 whiteknight plobsing: We've been slowly planning a new type for the purpose. CallSignature or the like.
18:50 whiteknight but basically, yes. It would be like a Key
18:51 whiteknight I am only hesitant about using Keys for it because bacek has been trying to deprecate Keys
18:51 whiteknight Needs to be a little more full-featured to handle argument flags, :named, :flat and the like
18:51 ambs left #parrot
18:52 ambs joined #parrot
18:52 plobsing I don't mind keys, or a superset thereof, so long as we can reduce (or at least keep constant) the number of types that must be understood to correctly interpret the meaning of an arbitrary segment of bytecode
18:52 jnthn One issue we have now is that HLLs often like to bind stuff into the lexpad
18:53 jnthn Rather than registers.
18:53 mtk joined #parrot
18:53 jnthn Rakudo's binder binds straight into the lexpad
18:53 jnthn Unfortunately, it has to do that by name at the moment.
18:53 whiteknight jnthn: so why's that an issue?
18:54 jnthn But what'd be nice is if it could do that in a cheaper way, like I got to work on nqpclr.
18:54 plobsing because you can't use them as arguments. but that's just shifting the complexity and cost from explicit ops reading values from the lexpad into the calling conventions
18:54 whiteknight plobsing: if we deprecate keys (probably replace them with FPA, FSA, and/or FIA), and use CallSignature to encapsulate an entire call site, I don't think that should hurt us
18:54 jnthn plobsing: No, I mean on the callee side.
18:55 jnthn plobsing: In nqpclr there's a single instance of a hash associated with a block that maps string names to indexes, and the lexpad itself is just an array
18:55 jnthn plobsing: All the statically known lookups and binds - including those done by the signature binder - just use the index.
18:56 jnthn The named way is just a fallback for dynamic situations.
18:56 jnthn I didn't get to making all lookups be like that yet, but have most of the stuff in place.
18:56 whiteknight jnthn: I suspect that the lexicals implementation is going to be a hot button issue sooner than later
18:56 jnthn whiteknight: Indeed.
18:57 jnthn whiteknight: I've got plenty of metamodel stuff to worry about for now though. :)
18:57 plobsing hmmm... that resembles an idea I've been pondering regarding more efficient lexicals. if we had find_lex_p_i_i, we wouldn't have to do $N hash lookups for every lexical access, greatly reducing the cost for heavily nested accesses.
18:57 jnthn plobsing: Exactly.
18:57 whiteknight plobsing: good idea. We could translate out the names during compilation
18:58 plobsing whiteknight: I oppose the idea that PIR should handle the names. the HLL can and should make the determination as to how to manage lexicals.
18:58 plobsing less magic in PIR
18:58 jnthn +1
18:58 whiteknight in an ideal world, PIR is just another HLL
18:58 jnthn 6model is basically intended to be used from a HLL
18:58 whiteknight and it's compiler can manipulate constants for optimization however it sees fit
18:59 plobsing whiteknight: how does FxA replace Keys? FxAs cannot make references into the registers.
18:59 jnthn Because maintaining code that uses 6model in PIR (as PIR stands today) and takes advantage of the optimizations available is going to be a horror to maintain.
18:59 jnthn er, sentence fail :)
19:00 whiteknight plobsing: it's not my plan. Ask bacek for details
19:01 whiteknight jnthn: it's unlikely that PIR code would use the optimizations,
19:01 whiteknight jnthn: it's unlikely that people will be using PIR in a few years
19:01 whiteknight in a few months, I wish
19:01 plobsing whiteknight: remember that our most stable language implementation is implemented in PGE and PIR.
19:02 whiteknight which one is that?
19:02 cogno left #parrot
19:02 plobsing lua. I love it. It hardly ever breaks, no matter what I do.
19:02 whiteknight plobsing: that's fine. PIR will still exist and will still work. I just don't want most people to be using it
19:03 whiteknight if lua works, no need to rewrite it
19:04 bacek joined #parrot
19:04 NotFound What is the plan? Replacing a language with an API?
19:04 whiteknight NotFound: HLLs should output PBC directly, when the time comes for that to be possible
19:05 whiteknight outputting PIR and then compiling that to PBC is twice the effort
19:05 whiteknight bacek!
19:06 NotFound whiteknight: the word 'directly' explains nothing
19:06 NotFound Unless you mean write the file byte by byte.
19:08 atrodo Correct me if I'm wrong, but it's my understanding that most compilers today, gcc and llvm included, output asm as one of the last steps
19:09 whiteknight atrodo: Most modern C compilers don't generate asm as an intermediate step unless asked to
19:09 whiteknight GCC may be the exception, with GAS. I don't remember what it does
19:09 whiteknight MSVC or ICC, for instance, don't generate asm unless you specifically ask
19:09 NotFound Both are monoplatform compilers, isn't it?
19:10 plobsing almost every C compiler abuses the fact that they are only required to *appear* to do things in certain steps.
19:10 whiteknight NotFound: no, I use ICC on linux and windows
19:11 NotFound whiteknight: let's say mono-intel, then ;)
19:11 whiteknight it's hard to name too many compilers that have multiple backends
19:11 cogno joined #parrot
19:11 whiteknight I don't know if clang outputs LLVM-asm or LLVM-bytecode
19:12 whiteknight NotFound: Any any compiler on Parrot will be mono-parrot
19:13 NotFound whiteknight: that's the problem. Given the rate of parrot changes being mono-parrot implies frequent chanegs.
19:13 plobsing whiteknight: indeed. jnthn's nqp is mono-parrot.
19:14 whiteknight "almost any"
19:14 Coke ? I think jnthn's nqp was parrot +/or clr.
19:14 Coke s/think/thought/
19:14 plobsing my pun was too subtle
19:14 NotFound Coke: and mono is clr ;)
19:14 Coke ah.
19:23 whiteknight plobsing: I don't like the implementation of Keys containing register references and needing to automatically pull values in from them when necessary
19:23 whiteknight so asking how FxAs are going to duplicate an operation we shouldn't be doing is not the right question
19:24 plobsing whiteknight: so how would you replace that usage? populate throw-away objects beforehand?
19:25 whiteknight When we see something like ["foo";$S0;"baz"] at compile time, we store an FSA in the constants table with a dummy 2nd entry, and generate an extra instruction to populate that field. $P0[1] = $S0 before the key is used
19:26 nwellnhof joined #parrot
19:26 whiteknight then we cut out branches in the code to extract the value from it, and always assume we have a value, not a reference
19:26 plobsing re-entrancy problems?
19:28 nwellnhof i'm going to merge nwellnhof/platform_src now
19:28 whiteknight nwellnhof++
19:28 whiteknight plobsing: Blah. I wasn't thinking about that. I feel like I had this issue figured out a few months ago
19:28 nwellnhof whiteknight: i'll merge nwellnhof/unicode_filenames soon after, so you can hack on IMCC without conflicts.
19:29 whiteknight awesome pawesome
19:32 whiteknight plobsing: With CallSignature, the reverse is true because we can keep CallSignature constant and always assume all it's value are register pointers
19:32 whiteknight because we can load constants into registers before a call
19:33 whiteknight I crunched the numbers on it a while back, and it turns into a net win for us to load constants into registers and use them from there instead of repeatedly fetching them from the constants table
19:33 whiteknight although the performance characteristics of that may have changed
19:36 plobsing "repeatedly"??? where do we repeatedly fetch them?
19:36 dalek parrot: 8e23a94 | nwellnhof++ | / (19 files):
19:36 dalek parrot: Merge branch 'master' into nwellnhof/platform_src
19:36 dalek parrot: review: https://github.com/parrot/parrot/commit/8e23a9431e
19:36 dalek parrot: f18aa63 | nwellnhof++ | / (161 files):
19:36 dalek parrot: Merge branch 'nwellnhof/platform_src'
19:36 dalek parrot: review: https://github.com/parrot/parrot/commit/f18aa63128
19:36 whiteknight I need to go look back at the code. I did this experiment at least a year ago
19:40 plobsing although, looking at the PCC code, it appears the way we support constants is by using double-branching. that could be inefficient (unless the optimizer is moderately smart, but I don't trust them to be).
19:41 whiteknight right, maybe that's where my numbers come from. If we always assume that we're passing values in registers and not as constants we cut out all that branching logic and the weird accessors
19:42 whiteknight we do a lot of branching based on whether we have a constant or not throughout PCC
19:43 plobsing that's because the flags are split up in an artificial and silly way.
19:44 plobsing if you combine the const-ness into the type (as should be done), we'd have a single branch on type in stead of a branch on type and then, immediately following, a branch on const-ness
19:47 chromatic Seems reasonable to me.
19:48 plobsing ATM, I'm trying to determine whether my optimizer is smart enough to unify the branching or not. long, optimized dissassemblies are hard to disect
19:52 plobsing the answer is "no, not even close"
19:55 cogno left #parrot
19:58 plobsing left #parrot
19:58 cogno joined #parrot
20:04 NotFound Maybe a little rearranging of the operations will allow better optimization.
20:05 dalek TT #1944 closed by nwellnhof++: t/src/checkdepend.t should not skip thr_ files.
20:05 dalek TT #1944: http://trac.parrot.org/parrot/ticket/1944
20:05 NotFound For example: VTABLE_push_integer(interp, call_object, constant ? raw_index : CTX_REG_INT(ctx, raw_index));
20:08 cogno left #parrot
20:09 ambs left #parrot
20:15 whiteknight nwellnhof++ Great commit
20:24 cogno joined #parrot
20:28 whiteknight nwellnhof: What's the ETA on unicode_filenames?
20:29 nwellnhof whiteknight: i'm working on a strange wrt output filenames right now.
20:29 nwellnhof s/strange/strange bug/
20:29 whiteknight okay. I won't start a new branch for IMCC garbage until tonight at least. Maybe later. Take your time
20:34 fperrad left #parrot
20:36 plobsing_ joined #parrot
20:42 ambs joined #parrot
20:46 cogno left #parrot
20:48 cogno joined #parrot
20:52 nwellnhof aargh. imcc freopens stdout to write pasm files.
20:56 cotto_work It says a lot about Parrot's early history that imcc was made a core component.
21:00 whiteknight how so?
21:00 dukeleto cotto_work: in the beginning, there is only "core"
21:02 NotFound Sometimes "core dump"
21:04 cogno left #parrot
21:07 dalek parrot: 9d91d36 | NotFound++ | src/call/args.c:
21:07 dalek parrot: shorten a bit the build sig object code
21:08 dalek parrot: review: https://github.com/parrot/parrot/commit/9d91d365ce
21:09 particle left #parrot
21:10 particle joined #parrot
21:13 cotto_work whiteknight: because it was (and still is to a decreasing extent) prototype code that was never intended to be a long-term solution.
21:14 NotFound Long-term like, say, ten years? ;)
21:15 particle that's not long term in parrot-land. we're only at 3.0.
21:16 particle macaws can live over 100 years
21:20 dukeleto particle: there you are :)
21:21 particle and here i remain
21:22 whiteknight If IMCC were as bad as it is, but wasn't part of core, it wouldn't be a problem
21:22 whiteknight the real problem with it is that it has a privileged status in Parrot, and we make defaults and assumptions about it to the detriment of other compilers
21:22 whiteknight we don't have any other binary-level interfaces besides IMCC because we can't
21:23 whiteknight break that link, and allow IMCC to be treated like any other compiler, and we are much better off
21:23 dukeleto whiteknight: yes please and thank you
21:24 particle can parrot be built/tested/installed without imcc yet?
21:24 whiteknight particle: no
21:24 whiteknight particle: I suspect we are about a month away from that, at current development velocity
21:24 dukeleto whiteknight: do we have a task list for what is needed to isolate IMCC ?
21:24 particle joy!
21:24 whiteknight dukeleto: in my head
21:25 whiteknight basic steps I am following:
21:25 whiteknight 1) Improve IMCC's public-facing interface functions so they are simple and sane
21:25 whiteknight 2) Create a new compiler PMC type to encapsulate IMCC
21:25 dalek tracwiki: v75 | cotto++ | ParrotQuotes
21:25 dalek tracwiki: dukeleto explains it
21:25 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Pa​rrotQuotes?version=75&action=diff
21:26 whiteknight 3) Use this PMC type exclusively for interfacing with IMCC, registering it in the frontend like a normal compiler
21:26 whiteknight 4) cut the cord
21:26 whiteknight I'm starting a branch for #1 tonight probably
21:27 NotFound Getting rid of automatic .pir search and compiling in load_bytecode isn't part of the plan?
21:27 plobsing_ left #parrot
21:27 whiteknight Notfound: it is, I just don't quite know where/when/how to do that
21:28 whiteknight we are going to need a deprecation notice. I think we can replace it with a method on the new PIR compiler PMC, then deprecate the .pir handling logic in the opcode
21:29 NotFound If we are to going that way, we can start the deprecation and check the ".pir" ending to emit a warning.
21:29 particle it would be very nice to be able to specify which compilers you want built at configure time and which you want to use at runtime
21:30 whiteknight this is true. I want to have an alternative in place first though
21:30 whiteknight particle: yes
21:30 particle and what the default is at build time, too
21:30 * whiteknight has to pack up and go home now. Later
21:30 whiteknight left #parrot
21:31 plobsing_ joined #parrot
21:38 ambs left #parrot
21:38 ambs joined #parrot
21:39 dukeleto particle: do we have a wiki page to keep track of these feature requests?
21:40 particle we have http://damnyouautocorrect.com
21:40 particle does that count?
21:40 particle dukeleto: that's part of my "pluggable everything" vision from back in the day. don't know if that's still a roadmap item or trac ticket
21:41 dukeleto particle: roadmap items have evolved
21:41 dukeleto particle: we have pretty much agreed that unless 2 people say they are devoted to making a roadmap item happen, it isn't a roadmap item
21:42 dukeleto particle: we don't want to make unicorn wishes into roadmap items, we want things that we are actually going to accomplish
21:42 particle sure, saw that from kid51++
21:42 dukeleto particle: but i want these compiler features to be written down somewhere, because we need to think about them when redesigning/burning IMCC
21:42 particle my vision is that parrot's core should be an extensible plugin engine
21:42 particle every subsystem should be pluggable
21:42 dukeleto particle: i like that vision
21:43 dukeleto particle: and we are slowly but surely getting there
21:43 particle and appropriately configurable at configure, build, and runtime
21:43 dukeleto particle: can you identify other subsystems that need to be made pluggable?
21:44 particle well, back when, compilers was the big one, but threads, io, gc, events, bytecode generators/loaders all qualify.
21:45 particle define an interface for each subsystem. pmc's are a natural way.
21:45 dukeleto particle: yep, we have come a long way on making the GC pluggable recently
21:45 dukeleto particle: packfiles are getting some fierce refactoring currently
21:46 dukeleto particle: threads are still a mess, IO is improving greatly due to nwellnhof
21:46 dukeleto particle: plobsing and bacek_at_work are also kicking ass lately
21:46 particle during configure, one should be able to specify which subset of available gc plugins should be built, with an appropriate default.  during runtime, one should be able to specify which gc plugin should be used.
21:46 particle same for any other pluggable subsystem.
21:46 particle awesome progress.
21:46 dukeleto particle: IMCC is the big hill at the end of the marathon
21:47 particle i'm at the summit waving you all on
21:48 dukeleto particle: i am almost half-way done with my TPF grant to document and test our embed subsystem, and whiteknight just made great improvements on creating a new, sane embedding api
21:48 dukeleto particle: i am finding lots of sharp edges on our VTABLE interface and some bugs too
21:49 dukeleto particle: we have redundant VTABLEs now, since some VTABLEs were different before immutable strings, and some VTABLEs are seemingly never tickled from PIR, or only accessible from a single PMC
21:49 particle have our opcode names regularized their syntax yet?
21:49 dukeleto particle: in what way?
21:49 particle get_something, getsomethingelse
21:50 dukeleto particle: good question. i think we are going the route of get_*, but there could still be some stragglers
21:51 rurban_ joined #parrot
21:51 particle i hate php for that.
21:51 dukeleto particle: also, perl 6 is creating a new MOP (called 6model) and parrot is considering using it as well, since our current OO/MOP system is a bit brittle
21:51 particle well, it's a natural fit
21:51 mj41 TapTinder update: Running final testing on http://tapir1.ro.vutbr.cz:​2000/buildstatus/pr-parrot and  irc://irc.freenode.org/taptinder-bottest1 . Good night.
21:52 dukeleto mj41++
21:52 particle perl6 is trying to be every language, and parrot is trying to run every language
21:52 particle taptinder + git! mj41++
21:52 rurban left #parrot
21:52 dukeleto particle: yep. so jnthn++ is writing a really nice MOP and then parrot will steal it and then rakudo should scream since parrot understands the MOP under the hood
21:52 rurban_ is now known as rurban
21:54 particle how close is 6model to complete? it's been in the works for a while
21:54 dukeleto then there is that whole Lorito thing...
21:55 jnthn particle: 6model on Parrot has been moving very fast recently.
21:55 dukeleto particle: from what I hear from jnthn++, it is within a few weeks from being in Rakudo master
21:55 jnthn particle: I expect to branch Rakudo in about two weeks.
21:55 dukeleto particle: and there is CLR implementation as well
21:55 dukeleto jnthn: good day, fine sir.
21:55 jnthn o/
21:55 jnthn Currently bothering my brane with natively typed attributes. :)
21:56 dukeleto jnthn: i saw a recent commit by you that obviated the need to allocate an RPA for every nqp-rx variable. That is huge!
21:56 jnthn dukeleto: Every object
21:56 jnthn dukeleto: But yes
21:56 dukeleto jnthn: yes, but most things are objects in Rakudo's setting, yes?
21:56 jnthn dukeleto: Well, it basically computes how to structure a signle chunk of memory to store all the stuff it needs to.
21:56 jnthn Yes, they are.
21:56 jnthn And yes, it should make a big difference.
21:57 * dukeleto is excited
21:57 particle jnthn++
21:57 jnthn I'm currently very close to handling natively typed attributes too.
21:58 jnthn Actually my problem isn't the memory layout bit but dealing with the inherent circularity that arises when defining boxed types and their relationship with unboxed types.
21:58 dukeleto jnthn: are you planning on being at YAPC::EU this year? Will there be a Perl 6/Parrot hackathon?
21:58 jnthn dukeleto: I always do YAPC::EU :)
21:58 dukeleto jnthn: choosing where to break the metacircularity chain is an art
21:59 dukeleto jnthn: awesome! I have actually never been to a YAPC conf. I plan to invalidate this year, multiple times :)
21:59 dukeleto jnthn: what other perl confs do you plan on going to this year? I am thinking about organizing some Parrot/Perl 6 hackathons
21:59 jnthn I like them so much I plan to do 2 of them. :)
22:00 jnthn dukeleto: Planning to be at OSDC.TW, Dutch Perl Workshop, YAPC::Russia, French Perl Workshop, YAPC::EU.
22:01 jnthn dukeleto: (metacircularity) Yeah, things can get a tad loopy. I also need to make sure I handle parametricity right. Think the path I'm going down will work fine.
22:02 jnthn (parametricity as in parametric types, or from the Perl 6 point of view, parametric roles...)
22:06 * cotto_work sees exciting-looking things to backscroll through
22:17 chromatic -1 to a pluggable GC
22:18 plobsing_ pluggable GC requires running code before GC is set up. that is *very* problematic.
22:19 chromatic More than that, the abstractions necessary to make a GC pluggable are measurably expensive.
22:21 plobsing_ I wonder if LD_PRELOAD could be abused to efficiently swap in a separately compiled GC
22:21 cotto_work plobsing_: I was wondering something similar.
22:22 chromatic Seems like a lot of work for an academic point right now though.
22:22 cotto_work That and the other CLI options that require very early processing could be effectively moved into environment variables.
22:23 cotto_work now, yes
22:23 chromatic Compile-time swapping, perhaps.
22:24 chromatic Runtime swapping? I have my doubts as to its value right now.
22:24 chromatic I'd rather get one good GC that's efficient and effective and, more importantly, tunable without recompilation first.
22:25 ambs left #parrot
22:29 dukeleto chromatic: i like that idea. It seems that you are not -1 to a pluggable GC, but -1 to a runtime pluggable GC, yes?
22:31 chromatic Yes.
22:32 chromatic I measured the cost of all of the abstraction functions in the current pluggable GC and you can speed up Parrot measurably -- a few percent, if not more -- by removing them.
22:35 dukeleto chromatic: is the GC the only subsystem that shoulnd't be fully pluggable, or are there others?
22:35 chromatic I have only thought about the implications of the GC.
22:37 dukeleto chromatic: ok, just wondering. I think holding off on GC pluggability until we have a good benchmark infrastructure is probably a good idea.
22:38 cotto_work +1
22:38 chromatic Also we should consider the costs of pluggability abstractions versus their benefits.
22:39 cotto_work Yeah.  Blindly chasing after pluggable everything without thinking about why/where it's beneficial won't help us.
22:41 cotto_work It's an attractive idea to say that Parrot doesn't force any particular anything on users, but that's not much good if users are stuck with a very flexible and very slow VM.
22:41 chromatic That, and using function pointers in C hurts optimization.
22:42 dalek nqp-rx/nom: 4d75922 | jonathan++ | src/metamodel/knowhow_bootstrapper.c:
22:42 dalek nqp-rx/nom: The find_method op throws method not found exceptions, and the API is for find_method v-table not to; make the KnowHOW.^find_method play that way.
22:42 dalek nqp-rx/nom: review: https://github.com/perl6/nqp-rx/commit/4d759228f4
22:42 dalek nqp-rx/nom: 26ac097 | jonathan++ | src/metamodel/reprs/P6opaque.c:
22:42 dalek nqp-rx/nom: Get P6opaque most of the way to consuming the storage spec provided by a REPR. In theory, this means it can allocate storage for natively typed attributes. In practice, there's no way to test this just yet.
22:42 dalek nqp-rx/nom: review: https://github.com/perl6/nqp-rx/commit/26ac097bf7
22:42 jnthn chromatic: Do they tend to have bad effects on branch prediction, cache coherence and other such things, from what you've observed?
22:43 chromatic They do.
22:43 chromatic Worse, the compiler has to assume that it can't inline across them, for example.
22:43 plobsing_ in the case of GC, they should have ~100%-effective branch-predict. we don't swap out those functions midway through.
22:44 chromatic Perhaps with an aggressive optimizer and const structs.
22:45 chromatic But we still have the problem that our API is a C function which calls a function pointer into a function elsewhere which may or may not call the functions it needs by pointer or through the API function.
22:45 plobsing_ what do optimizer and const-ness have to do with branch prediction? that's a processor feature
22:46 chromatic I assume the generated assembly should contain some hints to the branch predictor.
22:47 chromatic At least hoist some of the fetches into invariants.
22:47 plobsing_ there could be hinting. but even without hinting, a branch that always goes the same way should have a very good prediction hit-rate.
22:48 plobsing_ otherwise your chip just plain sucks
22:48 chromatic Branch prediction isn't the biggest efficiency problem in the code though.
22:48 plobsing_ I agree the subsystem could benefit from agressive inlining.
22:50 chromatic There's probably an easy 5-7% improvement in better inlining possibilities.
22:54 particle gc is probably the worst example i could have used for a plugin subsystem, agreed.
22:54 particle the more important part of 'extensible plugin architecture' is extensible.
22:55 particle make it straightforward for someone to add value to parrot in a manageable chunk, by having well-defined interfaces.
22:55 plobsing_ pluggable pluggability!
22:59 NotFound left #parrot
23:06 dalek Heuristic branch merge: pushed 22 commits to parrot/nwellnhof/unicode_filenames by nwellnhof
23:13 plobsing_ left #parrot
23:17 NotFound joined #parrot
23:25 Coke wow, chromatic & particle on the same day. My cup ... damn, who's gonna clean that up?
23:26 particle howdy, coke! just like old times... anybody seen leo?
23:28 thundergnat joined #parrot
23:32 whiteknight joined #parrot
23:34 Coke he's got this extra t these days. we don't talk about it
23:40 bacek_at_work ~~
23:44 whiteknight I've been thinking for a while that the system of the gc function pointer structures and selecting a GC core at the commandline is needlessly expensive
23:47 whiteknight There simply isn't enough benefit to justify the continuous expense
23:48 cotto_work whiteknight: were you backscrolling?
23:48 whiteknight yessir
23:48 whiteknight like a mammajamma

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

Parrot | source cross referenced