Parrot 3.0.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: write GettingStartedWithPlumage, review html documentation, test HLLs, review deprecations | merge at will
Set by moderator on 18 January 2011.
00:01 kid51 joined
dalek rrot: 7b57371 | dukeleto++ | / (3 files):
Merge branch 'leto/embed_grant'
 00:03
rrot: f82c288 | dukeleto++ | t/src/extend_vtable.t:
Add a coda to t/src/extend_vtable.t
rrot: 947dcf8 | dukeleto++ | t/src/extend_vtable.t:
Comment out test so that POD syntax tests don't fail
rrot/exceptions_subclass: ed2c343 | Whiteknight++ | / (88 files):
Merge branch 'master' into exceptions_subclass
 00:09
00:20 mtk left 00:27 mtk joined
nopaste "kid51" at 192.168.1.3 pasted "t/src/extend_vtable.t: new failures" (114 lines) at nopaste.snit.ch/28229 00:38
00:42 dalek left, elmex left, rurban_ joined
kid51 The failures in that paste were with g++ all around 00:42
00:42 Maddingue left, snarkyboojum_ joined, whiteknight left, rurban left, perlite left, pmichaud left, jjore left, simcop2387 left, TonyC left, Khisanth left, Kulag left, aloha left, slavorg left, shortcir1uit left, GeJ left, krunen left, bacek_at_work left, dngor left, slavorgn left, snarkyboojum left, eternaleye left, ascent left, ingy left, edenc left, snarkyboojum_ is now known as snarkyboojum, kid51 left, bacek left, particle left, nwellnhof left, Tene left, NotFound left, confound left, Kovensky left, KaeseEs left, hatseflats left, estrabd left, Kapace left, frodwith left, sECuRE_ left, mj41 left, Infinoid left, PacoLinux left, tadzik left, rblackwe_ left, Util left, AzureStone left, davidfetter left, theory left, Myhrlin_ left, Patterner left, chromatic left, TimToady left, cosimo left 00:43 PerlJam left, snarkyboojum left, mtk left, cogno left, wagle left, p6eval left, athomason left, Coke left, TiMBuS left, allison left, jan left, workbench left, sjn left, extreme left, dip left, he left, dukeleto left, jnthn left, sri left, rurban_ is now known as rurban, sri joined 00:46 snarkyboojum joined, mtk joined, kid51 joined, cogno joined, bacek joined, particle joined, wagle joined, davidfetter joined, nwellnhof joined, theory joined, Myhrlin_ joined, Patterner joined, chromatic joined, KaeseEs joined, p6eval joined, TimToady joined, Tene joined, NotFound joined, cosimo joined, PerlJam joined, confound joined, athomason joined, Kovensky joined, frodwith joined, hatseflats joined, estrabd joined, Kapace joined, sECuRE_ joined, AzureStone joined, mj41 joined, rblackwe_ joined, Infinoid joined, tadzik joined, PacoLinux joined, Util joined, Coke joined, TiMBuS joined, allison joined, jan joined, workbench joined, sjn joined, extreme joined, dip joined, he joined, dukeleto joined, jnthn joined, dalek joined, elmex joined, whiteknight joined, perlite joined, pmichaud joined, jjore joined, simcop2387 joined, TonyC joined, Khisanth joined, Kulag joined, aloha joined, shortcir1uit joined, GeJ joined, krunen joined, bacek_at_work joined, dngor joined, slavorgn joined, eternaleye joined, ascent joined, ingy joined, edenc joined 00:47 Maddingue joined 00:50 slavorg joined
kid51 Here's a smolder reporting the failures I recently pasted with a g++ build: smolder.parrot.org/app/projects/rep...tails/4044 01:01
01:04 davidfetter left
whiteknight nwellnhof: ping 01:08
dalek rrot: 07fbbcf | Whiteknight++ | / (8 files):
Merge branch 'exceptions_subclass'
 01:10
nwellnhof whiteknight: pong 01:11
whiteknight nwellnhof: false alarm. 01:13
I was failing some unicode tests in NQP, but I don't have ICU on this box
kid51 Those tests passed with a regular gcc build 01:16
smolder.parrot.org/app/projects/rep...tails/4050
whiteknight dukeleto: ping 01:18
01:18 kid51 is now known as kid51_at_dinner
whiteknight blah. I need an op that's a no-op but won't get optimized out by IMCC 01:34
sorear imcc optimizes out nop? 01:39
02:00 kid51_at_dinner is now known as kid51 02:01 plobsing joined, cosimo left 02:05 nwellnhof left
whiteknight sorear: IMCC optimizes out some constant operations 02:35
this rethrow bug is turning out to be very difficult to track down 02:36
whatever, I'm going to bed now 02:40
goodnight
02:40 whiteknight left
cotto ~~ 03:03
aloha, clock?
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 03:43 Yuki`N joined
Yuki`N I was using gist. 03:45
cotto I'm sure you were.
Yuki`N And I see there's a "Parrot Internal Representation" language in the syntax highlight options.
cotto istr dukeleto having something to do with that 03:46
kid51 Yuki`N: Were you the person who was working on pretty-printing for gdb? 03:50
Yuki`N Yes. 03:51
Does it not work?
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.
Yuki`N Ummm.
kid51 I just have to see if I did no harm.
Yuki`N Let me start my vm up.
You added comments, it really shouldn't matter.
kid51 Agreed, but I want to be 100% sure.
Yuki`N Let me start my VM. 03:53
kid51 Yuki`N: Can you post your findings here? I have to go to sleep now but will backscroll in the a.m. 04:09
04:11 kid51 left
Yuki`N OK. 04:13
04:17 bacek left
Yuki`N I verified that it still works. 04:21
cotto Yuki`N, is python built in to the proper versions of gdb or is it a separate dependency? 04:22
Yuki`N If gdb is not built with python it will not run the pretty-printers. 04:23
So it's built-in.
cotto ok 04:24
Yuki`N My eyes are suddenly killing me.
I'm going to sleep, night all.
04:24 Yuki`N left
cotto 'night 04:24
04:25 JimmyZ joined 04:28 bacek joined 05:13 JimmyZ left 05:45 Patterner left, Psyche^ joined, Psyche^ is now known as Patterner
dukeleto ~~ 05:46
cotto hio dukeleto 05:50
05:50 rurban_ joined 05:52 rurban left 05:53 rurban_ is now known as rurban
dukeleto cotto: wazzup 05:54
whiteknight: pong 05:55
i see that i caused some g++ failures 05:56
dukeleto will now test with both gcc and g++ before pushing
cotto: we can update the /topic, yes? The plumage wiki page is written 05:57
cotto dukeleto, sure 05:58
dukeleto cotto: what other goal should we put in the /topic ? 05:59
dukeleto forgot what they were
06:18 cogno left 06:19 cogno joined
moderator Parrot 3.0.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: Deprecations as data, merge/cleanup, AutomatedHLLTesting, clean up false test failures 06:20
06:22 rurban left, TimToady left, chromatic left, Myhrlin_ left, PerlJam left, theory left 06:26 rurban joined, theory joined, Myhrlin_ joined, chromatic joined, TimToady joined, PerlJam joined 06:35 cogno left 06:36 cogno joined 06:42 cogno left
dukeleto c_output_is doesn't respect $TODO and that is very annoying 06:43
cotto hands dukeleto a yak razor 06:46
06:47 cogno joined 06:53 cogno left
dukeleto i've uncovered another bug, methinks 07:04
Parrot_PMC_is_equal_num is broken
dukeleto sharpens his trusty yak razor 07:06
actually, reading the docs is much easier 07:08
c_output_is takes a todo => "foo" argument
cotto I think I'm proud of Parrot for joining the 323 club. 07:09
dukeleto cotto: ? 07:16
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
I guess I have seen the g++ light
cotto dukeleto, gcc bug 323 07:18
the floating point excess precision bug
dalek rrot: c8cbcb6 | dukeleto++ | t/src/extend_vtable.t:
[t] Fix extend_vtable tests, make them g++-clean and properly TODO two tests
 07:22
dukeleto looks at gcc.gnu.org/bugzilla/show_bug.cgi?id=323 in amazement 07:24
cotto I saw it earlier last week on a PHP bug were a certain floating point number could freeze the PHP interp. 07:27
dukeleto wow 07:31
cotto: you have a link for that?
cotto dukeleto, sure. just a sec 07:34
bugs.php.net/bug.php?id=53632 07:35
They made a point release to fix it.
It's pretty epic. 07:36
dalek TT #1982 created by dukeleto++: Parrot_PMC_thaw and Parrot_PMC_freeze broken 07:39
TT #1982: trac.parrot.org/parrot/ticket/1982
dukeleto cotto: Parrot_PMC_set_string_native and Parrot_PMC_assign_string_native both do the same thing. Why? 07:50
cotto looks 07:54
07:55 chromatic left
dalek TT #1983 created by dukeleto++: Parrot_PMC_is_equal_num seems broken 07:55
TT #1983: trac.parrot.org/parrot/ticket/1983
TT #1928 closed by cotto++: get_bool function of Rational dynpmc
TT #1928: trac.parrot.org/parrot/ticket/1928
cotto Maybe it was an early attempt at sane assignment semantics.
dukeleto cotto: can you give me an example of a valid call to the clone_pmc vtable ? 07:57
cotto: i don't understand what the second argument pmc needs to be
sorear cotto: did one of them clone the string back when strings were mutable?
dukeleto sorear: ah, that might be it. they were different before immutable strings
cotto dukeleto, there's exactly one PMC that implements that slot. 07:58
I guess it's supposed to be a modifier to the clone.
-1 to keeping it
dukeleto cotto: would you like to make the TT to remove it? 07:59
cotto I will soon have just done it. 08:00
dalek Heuristic branch merge: pushed 17 commits to parrot/leto/embed_grant by leto 08:04
cotto actually, Rakudo seems to be using it
dalek rrot: 4abcaa1 | dukeleto++ | / (99 files):
Merge branch 'master' into leto/embed_grant
rrot: 7e78673 | dukeleto++ | t/src/extend_vtable.t:
[t] Exercise Parrot_PMC_assign_string_native
cotto or not. It looks generated.
dalek rrot: 65325aa | dukeleto++ | t/src/extend_vtable.t:
[t] Parrot_PMC_clone
08:07 mtk left
dalek TT #1984 created by cotto++: Remove clone_pmc VTABLE slot 08:11
TT #1984: trac.parrot.org/parrot/ticket/1984
cotto dukeleto, is there a nice way to partially revert a commit? 08:13
08:14 mtk joined 08:19 theory left
dalek rrot/rethrow_madness: 3db4060 | cotto++ | t/op/rethrow.t:
try to make the rethrow test easier to follow
 08:20
dukeleto cotto: hmmm
cotto: depends 08:21
cotto all the changes are limited to one fie
file
I think I got it, though I'm not entirely sure what I did. 08:25
dalek rrot: 572deb0 | cotto++ | src/pmc/capture.pmc:
revert removal of dead VTABLE functions, since a proper PIR compiler will generate code to call them
 08:29
cotto That git/trac integration was definitely worthwhile. 08:32
dukeleto cotto: indeed. did you figure out the revert issue? 08:36
cotto more or less
dukeleto cotto: you can do "git checkout branchname/sha1 -- filename" to checkout a version of a file from a sha1/branch 08:38
cotto: good
cotto I'll remember that.
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
cotto: there is also git add -p , but it is more black-magic-ish
dalek TT #1914 closed by cotto++: Dead code in src/pmc/Capture.pmc 08:45
TT #1914: trac.parrot.org/parrot/ticket/1914
cotto dukeleto, is there a way to pass a cli option to a PIR script from a test? 08:47
#800 should be nearly trivial to test
cotto finally found a ticket 08:53
dukeleto cotto: probably
cotto: depends if the test is PIR or Perl
cotto Either the Nigerian Lottery is legitimate or I need to go to bed. 09:01
'night
dalek TT #765 closed by cotto++: zero-length files from "make html"
TT #765: trac.parrot.org/parrot/ticket/765
TT #820 closed by cotto++: dynops should show up in docs/ops...
TT #820: trac.parrot.org/parrot/ticket/820
09:16 TiMBuS left 09:31 TiMBuS joined 10:34 cogno joined
dalek rrot/nqp_pct: 64d13f5 | bacek++ | compilers/pct/src/POST/Compiler.pm:
Rewrite POST::Compiler.to_pir in nqp.
 10:50
10:56 fperrad joined
dalek TT #1934 closed by jkeenan++: Some Python programs added to tools/dev 11:30
TT #1934: trac.parrot.org/parrot/ticket/1934
11:48 cogno left, cogno joined 12:07 cogno left
dalek rrot: 8d7363d | jkeenan++ | lib/Parrot/BuildUtil.pm:
[codingstd] Fix 3 Perl weaknesses detected by 'make cagecritic'.
 12:07
rrot: c52bfa4 | jkeenan++ | lib/Parrot/Configure/Options/Test.pm:
[codingstd] Fix 2 Perl weaknesses detected by 'make cagecritic'.
rrot: 63312b2 | jkeenan++ | lib/Parrot/Headerizer.pm:
[codingstd] Fix 1 Perl weakness detected by 'make cagecritic'.
12:08 kid51 joined 12:15 cogno joined 12:22 he_ joined 12:37 JimmyZ joined 12:40 JimmyZ left 13:05 cogno left
dalek rrot: 84b5e3b | jkeenan++ | lib/Parrot/ (2 files):
[codingstd] Fix several Perl weaknesses detected by 'make cagecritic'.
 13:22
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
13:24 kid51 left 13:27 fperrad_ joined 13:31 fperrad left, fperrad_ is now known as fperrad 13:37 whiteknight joined
whiteknight good morning, #parrot 13:39
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.
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
aloha OK. I'll deliver the message.
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
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
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:45
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)
whiteknight but any object then would need to be decorated with an extra pointer to the underlying exception object 13:47
plobsing why?
whiteknight maybe I don't really understand what you are talking about 13:48
Exceptions have a lot of stuff that an ExceptionHandler might need to access.
resume continuation, severity, message
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?
whiteknight they can be made to
they are just continuations that go through normal PCC. Arguably they could take any number of arguments
plobsing wait. they are exceptions that go through pcc? can we pass them in the return continuation? 13:50
13:50 rurban_ joined
whiteknight what do you mean "pass them in the return continuation"? 13:50
check out src/exceptions.c:Parrot_ex_throw_from_op
plobsing I had that backwards. I thought you were saying the exceptions were continuations.
need moar coffee 13:51
whiteknight no, ExceptionHandlers are continuations
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
then we wouldn't need to burden Exception with all sorts of attributes that are rarely used
13:52 rurban left, rurban_ is now known as rurban
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
or $P2 = exception.find_handler_in_ctx(ctx)
plobsing whiteknight: ewwwww. users should not be required to do that much
whiteknight it's two lines more than they do right now, but gives infinitely more flexibility 13:55
if you have a specific handler you want to use, you take the reference to it and just invoke it
maybe $P0 = new ['Exception'], $P0.throw_to_first_handler(args ...) 13:56
Adding in a method call or two here isn't a big deal since the scheduler already abuses method calls throughout
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)
whiteknight plobsing: Okay, take the exception object out of the equation. 13:57
$P0 = ctx.find_exception_handler(), $P0(args, ...)
no exception needed explicitly
we override ExceptionHandler.invoke to take a stack trace and maybe create an Exception object for internal use only 13:58
or silently push the Exception onto the front of the list of arguments
I haven't really put any prior thought into this, so I'm just brain-dumping 14:00
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
if ExceptionHandlers are invokable continuations, we should just ask for a reference to an ExceptionHandler and invoke it 14:02
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
plobsing throwing is something that people do sufficiently often that we should encapsulate the action
whiteknight exception.'throw'() seems very clean to me
or exceptionhandler.'throw_to'(exception) 14:03
having the benefit that method calls are designed to take variadic argument lists, and that the whole mechanism then becomes pluggable and subclassable
exceptionhandler.'catch'(exception) 14:04
plobsing once we separate the thrown objects out, why do we need anything to be sublcassable?
whiteknight because an HLL could completely rewrite the entire exceptions mechanism to do what they want
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
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:06
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
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
and we are going to have to support them
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:09
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
arguably that's a stretch, and still only brings the total up to 3 arguments
it's something I would probably want to ask about at #ps or on parrot-users
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)
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"
the question still becomes how users fetch exception handlers for a particular exception 14:14
You're definitely acting hesitant about all this. What problems are you seeing? 14:15
plobsing for one, I'm not sure I want to push the convention-selection on to users 14:16
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
plus, is there much value in finally blocks in a garbage collected language?
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
whiteknight for instance, pushing a terminal delimiter to an output stream
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
whiteknight I will admit that this is the most common use, but it's certainly not the only one
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?
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"
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
plobsing commutes 14:23
whiteknight okay
14:29 plobsing left 14:31 JimmyZ joined 14:44 ambs joined 15:08 cognominal joined 15:40 plobsing joined 15:49 cognominal left 15:57 cognominal joined 16:01 JimmyZ left 16:06 dmalcolm joined 16:28 bacek left 16:37 plobsing left 17:01 theory joined 17:08 plobsing joined 17:15 cognominal left
whiteknight P==NP proof on slashdot is pretty interesting 17:29
and, best of all, comes with example software to prove it 17:30
Coke url? 17:37
whiteknight science.slashdot.org/story/11/01/20...leased-PNP
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
code is on github: github.com/anjlab/sat3
also, the rereference software is written in Java, which isn't so great 17:45
everything should be written on Parrot! 17:47
of course then it would run in O(n^10) instead of O(n^4), but still 17:49
17:52 hercynium joined
plobsing whiteknight: we could add a 3sat op. ;) 17:54
17:57 chromatic joined
dukeleto ~~ 18:23
cotto_work ~~
plobsing: perfect. "NP-complete out of the box" would be a great bit of marketing. 18:24
chromatic Parrot's only O(n^10) because I reduced parts of IMCC from O(n^18). 18:28
dukeleto chromatic: thanks for that :) 18:29
whiteknight I can't wait to decrease it to O(0)
18:29 ambs left
dukeleto chromatic: szabgab was looking for you, did he find you? 18:30
18:30 ambs joined
dukeleto chromatic: also, welcome back, stranger 18:30
whiteknight cotto: (572deb0943d80a7f7e6bb2b5fdb869eea08c9365) it's not the PIR compiler, no ops exist to call those vtables
no compiler can generate calls to them unless we add a metric crapton more ops 18:31
18:31 cogno joined
whiteknight and that's a big -1 from me 18:31
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
nwellnhof: ping 18:34
if nwellnhof isn't working on IMCC soon, I'll start my next branch to continue the defenestration
dukeleto whiteknight++
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:36
whiteknight do those ops exist? When I was looking around at the list I didn't see any 18:37
plobsing they do not
which is why the keyed_str vtables are inaccessible
whiteknight okay, so it's still a problem of missing ops, not IMCC 18:38
jnthn huh, what
$P0 = $P1[$S0] calls that v-table, no?
jnthn has loads of uses from C of VTABLE_get_pmc_keyed_str too
whiteknight jnthn: calls get_pmc_keyed, not get_pmc_keyed_str 18:39
jnthn whiteknight:
whiteknight default PMC may translate an unimplemented get_pmc_keyed VTABLE to get_pmc_keyed_str
jnthn What?
You mean it boxes the string just to make the call?
whiteknight github.com/parrot/parrot/blob/mast...t.ops#L339 18:40
18:40 mtk left
whiteknight IMCC boxes the string into a Key PMC, yes 18:40
that's what the [] bracket syntax does
plobsing except for ints sometimes
whiteknight yeah, an int can be an INTKEY 18:41
which is not treated as stupidly
jnthn It's still an extra throw-away GCable though
plobsing no. those keys are static
jnthn Ah, OK
plobsing they are references to the registers
jnthn Just get populated with the passed string each time?
whiteknight yeah, the keys are constant. Kept in the constants table and repeatedly marked over and over and over again
no, the string is constant too 18:42
well, it could be
jnthn Yeah, it still seems a tad wasteful when the vtable could be called too :)
er, :(
whiteknight jnthn: a tad wasteful?
plobsing it is a single pointer-dereference in most cases
whiteknight unfortunately, "a bajillion wasteful" is bad grammar, or I would say that
plobsing whiteknight: if you want to get into wastefulness in the constant table, lets talk about PCC 18:44
whiteknight lets do
PCC needs a hell of a lot of work
the ideas are there, but we need to cut a lot of fat off the bone
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
18:46 mtk joined
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:47
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
whiteknight after this IMCC/packfile stuff, I may need to focus on that for a while 18:48
we all may need to
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:49
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.
but basically, yes. It would be like a Key
I am only hesitant about using Keys for it because bacek has been trying to deprecate Keys 18:51
Needs to be a little more full-featured to handle argument flags, :named, :flat and the like
18:51 ambs left 18:52 ambs joined
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
Rather than registers. 18:53
18:53 mtk joined
jnthn Rakudo's binder binds straight into the lexpad 18:53
Unfortunately, it has to do that by name at the moment.
whiteknight jnthn: so why's that an issue?
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
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
jnthn plobsing: No, I mean on the callee side.
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
plobsing: All the statically known lookups and binds - including those done by the signature binder - just use the index.
The named way is just a fallback for dynamic situations. 18:56
I didn't get to making all lookups be like that yet, but have most of the stuff in place.
whiteknight jnthn: I suspect that the lexicals implementation is going to be a hot button issue sooner than later
jnthn whiteknight: Indeed.
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.
jnthn plobsing: Exactly.
whiteknight plobsing: good idea. We could translate out the names during compilation
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
less magic in PIR
jnthn +1
whiteknight in an ideal world, PIR is just another HLL
jnthn 6model is basically intended to be used from a HLL
whiteknight and it's compiler can manipulate constants for optimization however it sees fit
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.
er, sentence fail :)
whiteknight plobsing: it's not my plan. Ask bacek for details 19:00
jnthn: it's unlikely that PIR code would use the optimizations, 19:01
jnthn: it's unlikely that people will be using PIR in a few years
in a few months, I wish
plobsing whiteknight: remember that our most stable language implementation is implemented in PGE and PIR.
whiteknight which one is that? 19:02
19:02 cogno left
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
if lua works, no need to rewrite it 19:03
19:04 bacek joined
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
outputting PIR and then compiling that to PBC is twice the effort 19:05
bacek!
NotFound whiteknight: the word 'directly' explains nothing 19:06
Unless you mean write the file byte by byte.
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:08
whiteknight atrodo: Most modern C compilers don't generate asm as an intermediate step unless asked to 19:09
GCC may be the exception, with GAS. I don't remember what it does
MSVC or ICC, for instance, don't generate asm unless you specifically ask
NotFound Both are monoplatform compilers, isn't it?
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
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
whiteknight I don't know if clang outputs LLVM-asm or LLVM-bytecode 19:11
NotFound: Any any compiler on Parrot will be mono-parrot 19:12
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.
whiteknight "almost any" 19:14
Coke ? I think jnthn's nqp was parrot +/or clr.
s/think/thought/
plobsing my pun was too subtle
NotFound Coke: and mono is clr ;)
Coke ah.
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
so asking how FxAs are going to duplicate an operation we shouldn't be doing is not the right question
plobsing whiteknight: so how would you replace that usage? populate throw-away objects beforehand? 19:24
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:25
19:26 nwellnhof joined
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?
nwellnhof i'm going to merge nwellnhof/platform_src now 19:28
whiteknight nwellnhof++
plobsing: Blah. I wasn't thinking about that. I feel like I had this issue figured out a few months ago
nwellnhof whiteknight: i'll merge nwellnhof/unicode_filenames soon after, so you can hack on IMCC without conflicts.
whiteknight awesome pawesome 19:29
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
because we can load constants into registers before a call
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
although the performance characteristics of that may have changed
plobsing "repeatedly"??? where do we repeatedly fetch them? 19:36
dalek rrot: 8e23a94 | nwellnhof++ | / (19 files):
Merge branch 'master' into nwellnhof/platform_src
rrot: f18aa63 | nwellnhof++ | / (161 files):
Merge branch 'nwellnhof/platform_src'
whiteknight I need to go look back at the code. I did this experiment at least a year ago
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:40
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:41
we do a lot of branching based on whether we have a constant or not throughout PCC 19:42
plobsing that's because the flags are split up in an artificial and silly way. 19:43
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:44
chromatic Seems reasonable to me. 19:47
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:48
the answer is "no, not even close" 19:52
19:55 cogno left 19:58 plobsing left, cogno joined
NotFound Maybe a little rearranging of the operations will allow better optimization. 20:04
dalek TT #1944 closed by nwellnhof++: t/src/checkdepend.t should not skip thr_ files. 20:05
TT #1944: trac.parrot.org/parrot/ticket/1944
NotFound For example: VTABLE_push_integer(interp, call_object, constant ? raw_index : CTX_REG_INT(ctx, raw_index));
20:08 cogno left 20:09 ambs left
whiteknight nwellnhof++ Great commit 20:15
20:24 cogno joined
whiteknight nwellnhof: What's the ETA on unicode_filenames? 20:28
nwellnhof whiteknight: i'm working on a strange wrt output filenames right now. 20:29
s/strange/strange bug/
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 20:36 plobsing_ joined 20:42 ambs joined 20:46 cogno left 20:48 cogno joined
nwellnhof aargh. imcc freopens stdout to write pasm files. 20:52
cotto_work It says a lot about Parrot's early history that imcc was made a core component. 20:56
whiteknight how so? 21:00
dukeleto cotto_work: in the beginning, there is only "core"
NotFound Sometimes "core dump" 21:02
21:04 cogno left
dalek rrot: 9d91d36 | NotFound++ | src/call/args.c:
shorten a bit the build sig object code
 21:07
21:09 particle left 21:10 particle joined
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:13
NotFound Long-term like, say, ten years? ;) 21:14
particle that's not long term in parrot-land. we're only at 3.0. 21:15
macaws can live over 100 years 21:16
dukeleto particle: there you are :) 21:20
particle and here i remain 21:21
whiteknight If IMCC were as bad as it is, but wasn't part of core, it wouldn't be a problem 21:22
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
we don't have any other binary-level interfaces besides IMCC because we can't
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
particle can parrot be built/tested/installed without imcc yet? 21:24
whiteknight particle: no
particle: I suspect we are about a month away from that, at current development velocity
dukeleto whiteknight: do we have a task list for what is needed to isolate IMCC ?
particle joy!
whiteknight dukeleto: in my head
basic steps I am following: 21:25
1) Improve IMCC's public-facing interface functions so they are simple and sane
2) Create a new compiler PMC type to encapsulate IMCC
dalek tracwiki: v75 | cotto++ | ParrotQuotes
tracwiki: dukeleto explains it
tracwiki: trac.parrot.org/parrot/wiki/ParrotQ...ction=diff
whiteknight 3) Use this PMC type exclusively for interfacing with IMCC, registering it in the frontend like a normal compiler 21:26
4) cut the cord
I'm starting a branch for #1 tonight probably
NotFound Getting rid of automatic .pir search and compiling in load_bytecode isn't part of the plan? 21:27
21:27 plobsing_ left
whiteknight Notfound: it is, I just don't quite know where/when/how to do that 21:27
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:28
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
whiteknight this is true. I want to have an alternative in place first though 21:30
particle: yes
particle and what the default is at build time, too
whiteknight has to pack up and go home now. Later
21:30 whiteknight left 21:31 plobsing_ joined 21:38 ambs left, ambs joined
dukeleto particle: do we have a wiki page to keep track of these feature requests? 21:39
particle we have damnyouautocorrect.com 21:40
does that count?
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
dukeleto particle: roadmap items have evolved 21:41
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
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++
dukeleto particle: but i want these compiler features to be written down somewhere, because we need to think about them when redesigning/burning IMCC
particle my vision is that parrot's core should be an extensible plugin engine
every subsystem should be pluggable
dukeleto particle: i like that vision
particle: and we are slowly but surely getting there 21:43
particle and appropriately configurable at configure, build, and runtime
dukeleto particle: can you identify other subsystems that need to be made pluggable?
particle well, back when, compilers was the big one, but threads, io, gc, events, bytecode generators/loaders all qualify. 21:44
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
particle: packfiles are getting some fierce refactoring currently
particle: threads are still a mess, IO is improving greatly due to nwellnhof 21:46
particle: plobsing and bacek_at_work are also kicking ass lately
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.
same for any other pluggable subsystem.
awesome progress.
dukeleto particle: IMCC is the big hill at the end of the marathon
particle i'm at the summit waving you all on 21:47
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
particle: i am finding lots of sharp edges on our VTABLE interface and some bugs too
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?
dukeleto particle: in what way?
particle get_something, getsomethingelse
dukeleto particle: good question. i think we are going the route of get_*, but there could still be some stragglers 21:50
21:51 rurban_ joined
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
particle well, it's a natural fit
mj41 TapTinder update: Running final testing on tapir1.ro.vutbr.cz:2000/buildstatus/pr-parrot and irc://irc.freenode.org/taptinder-bottest1 . Good night.
dukeleto mj41++ 21:52
particle perl6 is trying to be every language, and parrot is trying to run every language
taptinder + git! mj41++
21:52 rurban left
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
21:52 rurban_ is now known as rurban
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...
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
jnthn particle: I expect to branch Rakudo in about two weeks.
dukeleto particle: and there is CLR implementation as well
jnthn: good day, fine sir.
jnthn o/
Currently bothering my brane with natively typed attributes. :)
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
dukeleto: But yes
dukeleto jnthn: yes, but most things are objects in Rakudo's setting, yes?
jnthn dukeleto: Well, it basically computes how to structure a signle chunk of memory to store all the stuff it needs to.
Yes, they are.
And yes, it should make a big difference.
dukeleto is excited 21:57
particle jnthn++
jnthn I'm currently very close to handling natively typed attributes too.
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?
jnthn dukeleto: I always do YAPC::EU :)
dukeleto jnthn: choosing where to break the metacircularity chain is an art
jnthn: awesome! I have actually never been to a YAPC conf. I plan to invalidate this year, multiple times :) 21:59
jnthn: what other perl confs do you plan on going to this year? I am thinking about organizing some Parrot/Perl 6 hackathons
jnthn I like them so much I plan to do 2 of them. :)
dukeleto: Planning to be at OSDC.TW, Dutch Perl Workshop, YAPC::Russia, French Perl Workshop, YAPC::EU. 22:00
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:01
(parametricity as in parametric types, or from the Perl 6 point of view, parametric roles...) 22:02
cotto_work sees exciting-looking things to backscroll through 22:06
chromatic -1 to a pluggable GC 22:17
plobsing_ pluggable GC requires running code before GC is set up. that is *very* problematic. 22:18
chromatic More than that, the abstractions necessary to make a GC pluggable are measurably expensive. 22:19
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.
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.
now, yes 22:23
chromatic Compile-time swapping, perhaps.
Runtime swapping? I have my doubts as to its value right now. 22:24
I'd rather get one good GC that's efficient and effective and, more importantly, tunable without recompilation first.
22:25 ambs left
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:29
chromatic Yes. 22:31
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:32
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.
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:37
cotto_work +1 22:38
chromatic Also we should consider the costs of pluggability abstractions versus their benefits.
cotto_work Yeah. Blindly chasing after pluggable everything without thinking about why/where it's beneficial won't help us. 22:39
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.
dalek p-rx/nom: 4d75922 | jonathan++ | src/metamodel/knowhow_bootstrapper.c:
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
p-rx/nom: 26ac097 | jonathan++ | src/metamodel/reprs/P6opaque.c:
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.
jnthn chromatic: Do they tend to have bad effects on branch prediction, cache coherence and other such things, from what you've observed?
chromatic They do. 22:43
Worse, the compiler has to assume that it can't inline across them, for example.
plobsing_ in the case of GC, they should have ~100%-effective branch-predict. we don't swap out those functions midway through.
chromatic Perhaps with an aggressive optimizer and const structs. 22:44
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
chromatic I assume the generated assembly should contain some hints to the branch predictor. 22:46
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.
otherwise your chip just plain sucks 22:48
chromatic Branch prediction isn't the biggest efficiency problem in the code though.
plobsing_ I agree the subsystem could benefit from agressive inlining.
chromatic There's probably an easy 5-7% improvement in better inlining possibilities. 22:50
particle gc is probably the worst example i could have used for a plugin subsystem, agreed. 22:54
the more important part of 'extensible plugin architecture' is extensible.
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
dalek Heuristic branch merge: pushed 22 commits to parrot/nwellnhof/unicode_filenames by nwellnhof 23:06
23:13 plobsing_ left 23:17 NotFound joined
Coke wow, chromatic & particle on the same day. My cup ... damn, who's gonna clean that up? 23:25
particle howdy, coke! just like old times... anybody seen leo? 23:26
23:28 thundergnat joined 23:32 whiteknight joined
Coke he's got this extra t these days. we don't talk about it 23:34
bacek_at_work ~~ 23:40
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:44
There simply isn't enough benefit to justify the continuous expense 23:47
cotto_work whiteknight: were you backscrolling? 23:48
whiteknight yessir
like a mammajamma

Powered by Cro and the Raku® Programming Language.

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

Thank you!