Camelia, the Perl 6 bug

IRC log for #parrot, 2009-10-05

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 payload joined #parrot
00:06 whiteknight bacek isn't lost, he is only resting
00:09 bacek whiteknight: I wish...
00:14 whiteknight is there any major difference in the logic between the results passing and argument passing logic?
00:15 whiteknight why can't we just use fill_params for each, with different accessors?
00:17 whiteknight they both support the same kinds of values and flags
00:18 whiteknight and in the end, they're both just invocations (Sub vs RetContinuation)
00:24 bacek yeah...
00:24 bacek but even fill_params doesn't fit in my head.
00:27 whiteknight I think we can use fill_params instead, if we add a src and dest context to it
00:28 bacek I would prefer just normal FSM instead of this 200+ lines of code...
00:29 bacek similar to Parrot_str_to_num.
00:30 bacek with small static functions to handle each state.
00:31 whiteknight we will refactor it down, I hop
00:31 whiteknight hope
00:33 whiteknight bacek: I think the clone key args commit broke some tests
00:34 kid51 At r41721, make smolder_coretest now fails completely at       t/compilers/imcc/syn/pasm.t
00:34 bacek whiteknight: I know. Looking right now
00:35 whiteknight ok
00:35 whiteknight kid51: yes, intentionally broken to refactor some things.
00:36 * kid51 slinks off for more beer ...
00:40 whiteknight okay, the CallSignature contains information about the returns. It contains an ordered list of results.
00:41 whiteknight so in fill_params we move items from the CallSignature into the local Context
00:41 whiteknight and in fill_results, we move items from the loca Context into the CallSignature
00:43 GeJ clock?
00:43 purl GeJ: LAX: Sun 5:43pm PDT / CHI: Sun 7:43pm CDT / NYC: Sun 8:43pm EDT / LON: Mon 1:43am BST / BER: Mon 2:43am CEST / IND: Mon 6:13am IST / TOK: Mon 9:43am JST / SYD: Mon 11:43am EST /
00:45 GeJ huh, I'm synced with bacek now. Those DST thingies are too confusing.
00:51 whiteknight bacek: I'm going to roll back Tene's commit. Too much to look at right now but we have the patchset
00:51 bacek whiteknight: give me 5 minutes
00:51 bacek I'm trying to fix it
00:53 whiteknight what are you fixing? Tene's commit or r41717?
00:54 bacek fill_results
00:55 bacek clone_key_arg already "fixed"...
00:56 whiteknight ok
00:57 whiteknight I'll give you all the time you need
00:57 whiteknight you are the magical coding robot :)
00:57 dalek parrot: r41722 | bacek++ | branches/pcc_reapply/src/call/args.c:
00:57 dalek parrot: "Fix" fetching caller_ctx in clone_key_arg.
00:57 dalek parrot: I don't quite understand why do we have 2 levels of caller_ctx here...
00:57 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41722/
00:57 dalek parrot: r41723 | bacek++ | branches/pcc_reapply/src/call/args.c:
00:57 dalek parrot: Intvals are stored directly in bytecode, not in constants. Fix
00:57 dalek parrot: intval_constant_from_op.
00:57 dalek parrot: C++ comment intentionally left to verify it by someone else.
00:57 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41723/
00:57 dalek parrot: r41724 | bacek++ | branches/pcc_reapply/src/call/args.c:
00:57 dalek parrot: More accurate handling of Nulls in fill_results.
00:57 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41724/
00:59 hercynium joined #parrot
00:59 whiteknight still a lot more test failures then there were a few commits ago
01:04 whiteknight yeah, it hangs
01:07 bacek ok... way to much for me to fix it...
01:08 bacek especially because I can't comprehend logic behind this code.
01:08 whiteknight right
01:08 bacek whiteknight: fell free to revert it.
01:08 whiteknight okay, will do
01:09 bacek you have to revert my commit about "handling Null" too
01:09 whiteknight I'm going to roll all the way back to r41714, since that's our low-point for test failres
01:10 whiteknight we can reapply the good things after that
01:10 bacek let me revert just 2 commits.
01:13 whiteknight okay, if you can get us back to a low number of failed tests
01:13 bacek r41725
01:14 dalek parrot: r41725 | bacek++ | branches/pcc_reapply/src/call/args.c:
01:14 dalek parrot: Revert "[pcc] The start of the fill_results refactor.  Doesn't work well yet."
01:14 dalek parrot: It doesn't work...
01:14 purl It's a Y2K error!  Panic!  Sue!
01:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41725/
01:20 kjeldahl joined #parrot
01:23 Zak joined #parrot
01:25 whiteknight okay, I'm going to sleep now. Goodnight
01:28 zak_ joined #parrot
01:30 dalek parrot: r41726 | bacek++ | branches/pcc_reapply/src/call/args.c:
01:30 dalek parrot: Disable clone_key_arg. Need more information how to get caller_ctx properly to clone it.
01:30 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41726/
01:32 nopaste "kid51" at 70.85.31.226 pasted "pcc_reapply branch: --buildframes=0: current failures verbose output" (1463 lines) at http://nopaste.snit.ch/18221
01:39 Tene purl: msg whiteknight The problem is that invocation and returns happen in the opposite order, so we can't just reuse the same logic.
01:39 purl Message for whiteknight stored.
01:40 Tene purl: msg whiteknight After 2.0, we'll be able to change that bad decision and unify all of the processing into one function, but until then, we have this silly situation where we set results before getting the returns, so we have to save all these cpointers to the registers, and other silly gymnastics.
01:40 purl Message for whiteknight stored.
01:46 Tene purl: msg allison I was able to get fill_results working for some simple cases, as well as slurpy results, but wasn't able to get it working well enough to pass tests. Look at r41721, r41723 and 41724, which have been reverted. I had trouble trying named returns, because writing named results causes an assert failure in Parrot_pcc_build_sig_object_returns_from_op
01:46 purl Message for allison stored.
01:49 pmichaud ooc, why is "set results before getting the returns" odd?
01:50 Tene pmichaud: 1) It's different from how we call functions, so we can't use the same codepath, because 2) it makes us do some weird gymnastics.
01:50 pmichaud hmmm
01:50 pmichaud I think the set results might've been to provide context to the called function
01:50 pmichaud e.g., if someone wants to implement the equivalent of P5's  want()
01:51 pmichaud the caller function would need to say what it wants before it calls the callee
01:52 Tene Hmm.  Could be.
01:52 Zak joined #parrot
01:52 Tene Allison was under the impression that it was arbitrary, and plans to change it back after 2.0
01:55 pmichaud I'm pretty sure Chip had a reason for designing it that way.  Anyway, it matters little to me, I think, since P6 doesn't have a want().
01:55 pmichaud langauges that want a want() will likely have to communicate that information out-of-band somehow, then.
01:56 pmichaud *languages
01:56 TiMBuS joined #parrot
02:06 Tene for the record, I also find fill_params and fill_results to be way too big.  I don't have a good enough handle on them to refactor them out appropriately, though.  I want to get fill_results working first, and then I'll see what I can safely factor out of both.
02:06 Tene I'm reall yuncomfortable with huge chunks of repeated code like that, though.
02:06 pmichaud oh, I agree, I think the whole pcc stuff is pretty ugly :)
02:15 Tene If I can get things set up for my class tomorrow, I'll dive back in for a few hours.
02:17 zak_ joined #parrot
02:20 bacek sigh...
02:20 bacek We can use single code path for all argument passing.
02:20 * bacek finally wrapped head around PCC
02:20 bacek 1. Implement single fill_params function.
02:21 bacek 2. Drop fill returns
02:21 bacek 3. "op returncc" will use fill_params
02:21 Tene bacek: if you can do it, go ahead.
02:22 Tene bacek: what changes to fill_params do you expect will make that possible?
02:22 bacek fill_params will not changed at all.
02:23 Tene I don't see how to do that, but maybe I've got too narrow a view of the problem.
02:25 Zak joined #parrot
02:25 bacek op set_returns can just remember "raw_returns" in Context. op returncc will pass it to fill_params
02:27 Tene bacek: are you planning to implement this tonight, or just discussing?
02:27 bacek clock?
02:27 purl bacek: LAX: Sun 7:27pm PDT / CHI: Sun 9:27pm CDT / NYC: Sun 10:27pm EDT / LON: Mon 3:27am BST / BER: Mon 4:27am CEST / IND: Mon 7:57am IST / TOK: Mon 11:27am JST / SYD: Mon 1:27pm EST /
02:27 bacek There is a lot of time till "tonight" :)
02:28 Tene Well, looks like I'll have a couple of hours available in maybe 24 minutes.
02:30 * GeJ seconds bacek in his statement.
02:31 Tene Bah, time zones. :P
02:31 * GeJ seconds that too :)
02:38 zak_ joined #parrot
02:41 bacek oookey. fill_params need 2 Context arguments.
02:42 Tene See?  I'm not crazy!
02:42 Zak joined #parrot
02:43 bacek but I am
02:44 Tene I don't really feel comfortable enough with the context in which these are used to be comfortable changing how they're being called.  I was just trying to implement something that fit the existing API.
02:48 janus joined #parrot
03:04 dalek close: r177 | Austin++ | trunk/ (12 files):
03:04 dalek close: Class-ified Visitor, restarted on PrettyPrint.nqp
03:04 dalek close: review: http://code.google.com/p/close/source/detail?r=177
03:04 mikehh bacek: I don't think it's a good idea to use coedtest errors for attention calling - the XXX should be sufficient
03:05 mikehh codetest
03:05 purl hmmm... codetest is part of fulltest,  distro_tests is part of fulltest, but not of codetest
03:06 dalek parrot: r41727 | mikehh++ | branches/pcc_reapply/src/call/args.c:
03:06 dalek parrot: codetest fixes - remove C++ comment, linelength
03:06 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41727/
03:08 Tene purl: msg allison bacek has a plan for using fill_params for returns that he's pretty confident in.  I'll wait for his attempt at that before trying returns myself.
03:08 purl Message for allison stored.
03:11 zak_ joined #parrot
03:12 dalek TT #1092 created by geraud++: Remove NQP leftovers during 'make realclean'
03:16 Zak joined #parrot
03:23 mikehh pcc_reapply - http://smolder.plusthree.com/app/pu​blic_projects/report_details/28571
03:23 shorten mikehh's url is at http://xrl.us/bfqgvq
03:24 mikehh failures up on last time I ran it - 6,430 ok, 67 failed, 100 todo, 162 skipped and 1 unexpectedly succeeded
03:32 zak_ joined #parrot
04:01 Zak joined #parrot
04:41 bacek joined #parrot
05:06 bacek joined #parrot
05:21 Zak joined #parrot
05:24 cotto clock?
05:24 purl cotto: LAX: Sun 10:24pm PDT / CHI: Mon 12:24am CDT / NYC: Mon 1:24am EDT / LON: Mon 6:24am BST / BER: Mon 7:24am CEST / IND: Mon 10:54am IST / TOK: Mon 2:24pm JST / SYD: Mon 4:24pm EST /
05:25 cotto bacek is unusually ephemeral today
05:27 bacek joined #parrot
05:43 patspam1 joined #parrot
06:04 uniejo joined #parrot
06:37 jrtayloriv joined #parrot
06:41 fperrad joined #parrot
06:43 Tene bacek: any progress?
06:47 allison bacek/Tene: fill_params cannot work for set_returns
06:47 allison bacek/Tene: the logic is backwards
06:48 allison bacek/Tene: fill_params pulls values from a call_object and stores them in registers/varargs
06:48 Tene allison: bacek had some ideas about adding an extra parameter to fill_params and saving thigns into contexts and changing the arguments passed.  I'm a little bit skeptical, but he was confident.
06:49 allison bacek/Tene: fill_returns pulls values from registers/varargs and stores them in the call object
06:49 allison Tene: we will be able to unify them after we fix the order of set_returns/get_results
06:49 Tene Yeah, that's what i told him.
06:50 Tene allison: I got fill_results working for some basic cases... you might want to pull the patches out of svn history and try it.
06:52 allison Tene: cool
06:52 allison Tene: was some of it reverted later?
06:52 allison Tene: or is 'svn up' enough to get it?
06:53 Tene allison: it was all reverted.  It wasn't finished, and so caused massive test failures, and nobody awake at the time was able to understand the logic.
06:54 Tene I sent you a message via purl with the revision numbers you want to look at.
06:55 allison Tene: ah, the joy of time zones
06:56 allison Tene: I'm about to leave for class, will take a look and be back on in a couple of hours
06:57 allison Tene: I suspect we can start with your patches and get the details fixed up and ready to go later today
06:57 Tene :)
06:57 Tene I'm sleeping shortly.
06:57 allison Tene: right, so if I have questions I'd better ask them soon?
06:57 Tene I'll be glad to look at it after teaching class tomorrow, so... 17 hours or so.
06:58 allison Tene: ah well, looking at the code will be good enough
06:58 Tene allison: I'll be awake in about 9 hours, but I'll still be awake for another hour or two.
06:58 Tene allison: It started as a copy of fill_params.
06:58 allison Tene: I don't know yet if I'll have network access in class (first day)
07:00 allison Tene: gotta run to catch my bus
07:00 Tene Have fun. :)
07:13 hiroyuki_y joined #parrot
07:22 iblechbot joined #parrot
07:28 dalek TT #1093 created by fperrad++: t/pmc/env.t segfaults on Windows
07:28 japhb Tene, darbelo, dukeleto, Austin: I'm not sure which one of you was complaining that Plumage was checking out projects to the current directory, but that is now fixed.  (Build root defaults to ~/.parrot/plumage/build/ now)
07:33 mokurai left #parrot
07:40 mikehh joined #parrot
07:56 allison joined #parrot
07:57 allison apparently I do have network access
08:12 Tene O HAI allison
08:16 allison Tene: hai
08:26 mikehh bris.ac.uk?
08:26 japhb http://use.perl.org/~geoffrey/journal/39713   # Plumage "Day" 8
08:26 allison mikehh: aye
08:27 mikehh it's about as far from me as you can get in the uk - sw vs ne
08:28 allison mikehh: where are you?
08:28 mikehh aberdeen in scotland
08:28 allison mikehh: ah, I hear it's lovely up there, never been
08:29 allison mikehh: we might have to plan a parrot hacking session
08:30 mikehh Aberdeen is the third largest city in Scotland after Glasgow and Edinburgh, but in less than 10 minutes you can be in amazing countryside.
08:31 moritz though you have to add that some scottish cities even have countryside within the city borders :-)
08:32 allison moritz: always a good quality for a city to have
08:32 allison moritz: Portland is known for the US's largest "city park"
08:33 moritz I never got around to counting the golf courts in Edinburgh :-)
08:33 allison moritz: it's actually a protected wildlife area that stretches from the center of town miles out through the suburbs, it's huge
08:33 moritz sounds very nice
08:35 allison golf courses are nice too
08:36 mikehh gotta take someone into town bbiab
08:36 dukeleto forrest park in portland is something like 5000 acres (sorry for the imperial units)
08:37 dukeleto which is about 2000 hectares
08:38 allison http://www.forestparkconservancy.org/
08:38 dukeleto allison: are you in pdx?
08:38 allison dukeleto: not any more, I live in Bristol, UK
08:38 allison dukeleto: but that was the last place I lived, before South Africa
08:39 allison dukeleto: I was in Portland almost 7 years, the longest I've ever lived anywhere
08:39 dukeleto allison: i can see why, it is a pretty awesome city
08:50 * allison moving, class over
08:54 einstein joined #parrot
09:40 masak joined #parrot
09:56 DrForr_ joined #parrot
09:57 allison joined #parrot
10:09 slavorgn joined #parrot
10:09 cconstantine joined #parrot
10:10 bacek joined #parrot
10:14 kurahaupo joined #parrot
10:31 quek joined #parrot
10:58 jsut joined #parrot
11:06 cconstantine joined #parrot
11:20 nopaste "bacek" at 110.175.161.144 pasted "Use fill_params to get_results/set_results ops for allison" (210 lines) at http://nopaste.snit.ch/18222
11:21 bacek joined #parrot
11:21 bacek msg allison  http://nopaste.snit.ch/18222 shows how to use fill_params for get_results/set_returns ops. It is definitely possible.
11:21 purl Message for allison stored.
11:34 patspam joined #parrot
11:36 allison bacek: the thing is, we plan to rip out the fill_returns code in 3 months and replace it with the fill_params code
11:37 allison bacek: so, if we mangle the fill_params code now, it'll just make more work for us later
11:42 dalek rakudo: d91717d | masak++ | src/ (2 files):
11:42 dalek rakudo: moved Array.delete to setting
11:42 dalek rakudo: It's not likely that 'undef' will work as intended for typed arrays but,
11:42 dalek rakudo: hey, all the old tests pass, plus two TODO'd ones.
11:42 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​91717dffe6662a3d2b9014e3229d0b61278af96
11:42 shorten dalek's url is at http://xrl.us/bfqhu6
11:44 jrtaylor joined #parrot
11:45 bacek allison: how that? I don't use fill_returns in nopasted code at all.
11:45 bacek allison: and fill_params wasn't touched either.
11:49 allison bacek: fill_params stores arguments in the args array and hash
11:49 bacek allison: yes. And...?
11:49 purl i guess yes. and is 5.5.3 under new naming
11:49 allison bacek: fill_returns stores them in the returns
11:50 allison bacek: fill_returns has to set the CPointer arguments so the values can be set on the varargs
11:50 bacek allison: may be. I don't use fill_returns
11:50 tetragon joined #parrot
11:50 allison bacek: yes, your code is doing the wrong thing
11:50 allison bacek: it doesn't work
11:50 purl It's a Y2K error!  Panic!  Sue!
11:50 bacek allison: unfortunately it does :)
11:51 allison bacek: it can't, there's no way for the return value to get back to the C code
11:51 bacek it for _op versions only atm
11:51 allison bacek: yes, and can only ever be for _op versions
11:52 allison bacek: after 2.0 we'll change it to use a separate call signature for call and return
11:52 allison bacek: it's not possible now
11:52 bacek allison: indeed. But I doubt that we need complex returns from c code.
11:53 allison bacek: the code has to be the same for C and PIR
11:53 allison bacek: and, yes we do have complex returns for C code, because any method can be called from C
11:53 bacek sigh...
11:54 allison including PIR methods/subs with complex returns
11:54 bacek afk # rl
11:54 allison bacek: I understand the frustration, and I appreciate the work to unify things
12:04 masak what does a PIR line such as "$S0 = tokentable[$S0;'precedence']" do? tokentable is a Hash, but what does the semicolon signify?
12:06 whiteknight joined #parrot
12:06 allison masak: it's a second-level key
12:06 masak allison: ok. what does that mean under the hood?
12:06 masak a hash of hashes?
12:06 allison aye, or a hash of arrays,
12:06 allison or an array of arrays
12:07 allison masak: not all PMC's implement it the same way
12:07 masak ok.
12:07 masak thanks.
12:07 masak I looked around in docs/ but couldn't find any information about this.
12:09 allison needs something more prominent
12:09 allison (I can't even find it)
12:09 whiteknight good morning #parrot
12:11 allison masak: ah, there's a mention docs/book/pir/ch04_variables.pod
12:11 allison hi whiteknight
12:11 whiteknight hello allison
12:11 whiteknight I didn't manage to do anything productive after you left last night
12:11 allison whiteknight: ah well, it was a very productive hackathon weekend
12:11 whiteknight backlogging now to see if anybody else was more successful
12:12 whiteknight yes it was!
12:12 masak allison: ok. I missed that one when grepping.
12:12 allison masak: yeah, it's a hard one to grep for
12:16 allison whiteknight: I need to pull Tene's patches and fix up the last details. Looking them over, they're quite close
12:17 whiteknight I was looking at them too, but I didn't know enough to complete them
12:17 whiteknight I made a few changes and broke the living hell out of them, but that's hardly the same thing
12:17 quek joined #parrot
12:17 allison whiteknight: could be considered progress :)
12:19 whiteknight so what's really the logical difference between returns passing and arguments passing?
12:19 whiteknight I kept hoping that, Parrot being CPS-based, they would be the same
12:19 whiteknight I was wrong
12:22 allison whiteknight: they are the same... or they were
12:22 whiteknight "theoretically"
12:22 allison whiteknight: sometime back, and I think it was Chip's refactor, it was changed so that "get_results" is called *before* "set_returns"
12:22 whiteknight right, you mentioned that
12:23 whiteknight so we're going to have to re-refactor it?
12:23 allison whiteknight: to work the same going both ways, you have to set the returns before you fetch them
12:23 whiteknight or, "un-refactor" it?
12:23 allison whiteknight: aye, we'll have to change the IMCC syntactic sugar to work the other way
12:24 whiteknight changing IMCC? Sounds fun and easy
12:24 whiteknight </sarcasm>
12:24 allison whiteknight: but, more importantly, we'll have to change the way PASM works
12:26 whiteknight yes, and then it's all grand unification for Parrot
12:29 allison Whoot
12:29 whiteknight I'll start updating the CallingConventionsTasklist to reflect some of these long-term TODO items
12:30 dalek parrot: r41728 | jkeenan++ | trunk/config/gen/makefiles/root.in:
12:30 dalek parrot: Applying patch submitted by Geraud in https://trac.parrot.org/parrot/ticket/1092:  clean up parrot_nqp* files in 'realclean'.
12:30 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41728/
12:32 whiteknight and we can start breaking all these TODO items down into refactor groups and order them
12:32 allison whiteknight: that's a good idea
12:36 quek left #parrot
12:40 quek joined #parrot
12:42 quek left #parrot
12:42 quek joined #parrot
12:47 quek left #parrot
12:53 dalek tracwiki: v7 | whiteknight++ | CallingConventionsTasklist
12:53 dalek tracwiki: Add some new items to the task list
12:53 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingC​onventionsTasklist?version=7&amp;action=diff
12:53 shorten dalek's url is at http://xrl.us/bfqh6d
13:00 dalek tracwiki: v8 | whiteknight++ | CallingConventionsTasklist
13:00 dalek tracwiki: regroup items in this tasklist into individual refactors starting with the current PCC refactors and moving down to other items
13:00 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingC​onventionsTasklist?version=8&amp;action=diff
13:00 shorten dalek's url is at http://xrl.us/bfqh6s
13:05 dalek TT #1094 created by whiteknight++: Unify VTABLE_invoke semantics between PMC types
13:10 bluescreen joined #parrot
13:10 whiteknight those stages probably need to be reordered
13:10 dalek tracwiki: v9 | whiteknight++ | CallingConventionsTasklist
13:10 dalek tracwiki: rearrange stuff, move some task metadata to a ticket
13:10 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingC​onventionsTasklist?version=9&amp;action=diff
13:10 shorten dalek's url is at http://xrl.us/bfqh7n
13:14 whiteknight cotto: ping
13:15 whiteknight purl msg cotto can you take a look at the PMCUnionDeprecationTasklist page on the wiki, and update the current status of things? I'm pretty certain all these tasks are completed, but I want to get a second pair of eyes to make sure.
13:15 purl Message for cotto stored.
13:19 whiteknight Getting good, concise lists of TODO items and arrnaging them into a nice roadmap is a very good idea, I think
13:23 dalek tracwiki: v5 | whiteknight++ | StringsTasklist
13:24 dalek tracwiki: cleanup. Add note about the need to properly encapsulate things.
13:24 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Str​ingsTasklist?version=5&amp;action=diff
13:24 shorten dalek's url is at http://xrl.us/bfqh8q
13:28 TiMBuS hey whiteknight, i got bored and decided to try and implement that NCI in C/asm. has anyone else tried it?
13:29 whiteknight I had one guy submit a solution with libJIT, but nothing for pure ASM
13:31 TiMBuS kewl
13:35 iblechbot joined #parrot
13:56 mberends joined #parrot
13:57 whiteknight TiMBuS: I would be very very interested to see an ASM implementation. I was planning to write one up myself but have had no time
13:57 PacoLinux joined #parrot
13:59 TiMBuS whiteknight, i keep debating between a C implementation and an ASM one.
14:00 TiMBuS im thinking of maybe building a callframe for each signature as its requested and storing it as a function pointer
14:00 whiteknight TiMBuS: the problem is that you need to be able to push things onto the system stack, which you can't really do in C
14:00 whiteknight except inline assembly, of course
14:01 TiMBuS well, id build the bytecode
14:01 whiteknight ah, okay. So a home-brew JIT?
14:01 TiMBuS for the express purpose of calling functions
14:02 TiMBuS i figured it was a better solution
14:02 payload joined #parrot
14:03 TiMBuS its a lot better than having to deal with gcc's inline asm, if anything.
14:04 whiteknight The only inline ASM that you really need is to push arguments onto the stack
14:04 whiteknight everything else can be normal C
14:04 TiMBuS actually im on amd64
14:05 whiteknight oh, that does complicate things a little bit
14:05 TiMBuS i have the ABI for it
14:05 whiteknight I actually don't know as much about the x64 ABI as I should
14:05 TiMBuS its not too hard really
14:12 NotFound TiMBuS: I think that we are looking for a way to to the call without building a callframe. Otherwise we don't get rid of the problems of selinux or equivalent forbidding to create executable blocks of memory.
14:15 TiMBuS oh, i see.
14:16 TiMBuS im not really familiar with what selinux does
14:16 whiteknight it basically takes all our hard work and craps on it
14:17 TiMBuS lol
14:17 NotFound One of the thing it does, if configured that way, is to set execution permissions to mapped memory.
14:17 NotFound forbid to set, I mean.
14:19 TiMBuS well i can see how that would prevent malware
14:21 Psyche^ joined #parrot
14:31 davidfetter joined #parrot
14:46 fperrad joined #parrot
14:53 particle http://www.youtube.com/watch?v=9T1vfsHYiKY
14:56 * particle repeats 100 times, "the perl debugger is not gdb."
14:56 particle maybe now i'll stop typing 'bt' there
14:57 AndyA joined #parrot
15:03 Eevee joined #parrot
15:03 * whiteknight has actually never used the parrot debugger
15:04 whiteknight eventually I feel like I should try it
15:04 payload joined #parrot
15:04 whiteknight and the profiler too, I never used that
15:04 particle whiteknight: have a few minutes to catch me up on pcc changes?
15:04 whiteknight particle: sure thing
15:05 particle what are the goals of the current branch?
15:05 whiteknight I've got a few bullet points on the wiki, CallingConventionsTasklist
15:05 particle what's the expected merge-to-trunk date?
15:05 moritz "when it works" :-)
15:05 whiteknight basically, we're unifying much of the code path to use CallSignature PMCs to hold arguments, instead of doing things in a lot of ad hoc ways
15:06 bluescreen joined #parrot
15:06 whiteknight That way calls from PIR and C can call into PIR and C without callee having to know who caller was
15:06 particle viewing now...
15:07 whiteknight We're still failing tests at this point, but we went from >400 failures to ~60
15:07 whiteknight so we're making very good progress.
15:08 particle wonderful!
15:08 whiteknight If we can keep up momentum, I think we could be mergable within a week. Probably leave another week for HLL testing and we're in after 1.7
15:08 particle before 1.7 would be better.
15:08 theory joined #parrot
15:08 whiteknight yes, it would
15:08 particle this has dragged on a very long time.  it has been promised since before 1.0.
15:09 whiteknight I just don't want to make promises
15:09 particle i know, time flies like bananas.
15:09 whiteknight What's lacking now is that the returns logic doesn't handle all the necessary options
15:09 whiteknight once that gets in, everything should pass again
15:09 moritz and PGE should build again?
15:09 whiteknight PGE I believe is only blocking on :named and :slurpy returns
15:10 whiteknight so yes, once we get those working again things should work
15:10 whiteknight there are a few semantic issues we probably need to work out too, but nothing major
15:13 particle top priority, please.
15:13 particle i'll give you a cookie.
15:14 particle seriously, though, and i'll bring this up tomorrow (assuming i can attend #parrotsketch)...
15:15 particle rakudo *needs* this done asap, or their schedule for a spring release of Rakudo * is blown.
15:15 particle our hlls are our most important customers, and they've been ignored too long.
15:16 particle progress has been made lately: it's nice to see tcl getting some love.
15:22 ruoso joined #parrot
15:30 whiteknight particle: I'll give the issue my full attention. We've got a team of devs doing the same
15:30 whiteknight and our bus number on that branch is quite large now
15:30 particle hoarde++
15:32 iblechbot joined #parrot
15:34 whiteknight We've already got plans in the air to add :lookahead and also to fix up VTABLE_invoke so that it's properly subclassible. Both things that should make Rakudo quite happy
15:38 particle which way are you going with VTABLE_invoke?
15:38 whiteknight what do you mean?
15:38 particle args first, or after?
15:39 whiteknight args first, I think. That's what it's going to have to be if we want to unify codepaths with NCI
15:39 particle ok, that's what i figured, didn't want to assume.
15:40 whiteknight because we can pass arguments into a CallSignature first, and then callee can unpack those args whenever necessary
15:40 whiteknight so PIR funcs can unpack it after invoke, while NCI can unpack it during invoke
15:41 whiteknight all the processing happens in the get_params opcode now, so after the Sub bytecode starts executing anyway
15:42 whiteknight the biggest problem with VTABLE_invoke is getting a "self" variable to show up in the PIR, which CallSignature should also neatly solve
15:59 pmichaud fwiw, I'm not sure that Rakudo needs :lookahead now (more)
16:00 pmichaud we're already expecting to have to do our own argument unpacking into parameters
16:00 pmichaud it's more important for us to have :capture available
16:01 whiteknight what's :capture?
16:01 pmichaud just a sec-- finding relevant thread/conversation
16:01 whiteknight (add anything else you need to the CallingConventionsTasklist on the wiki too, so it doesn't get lost)
16:02 pmichaud http://irclog.perlgeek.de/parr​otsketch/2009-08-18#i_1404773
16:03 whiteknight ah okay, I know what you're talking about
16:03 whiteknight the thing that I was referring to as :signature
16:04 pmichaud :signature is the wrong name for this
16:04 pmichaud should be :callsignature, :callsig, or :arglist
16:04 whiteknight regardless of the name, the idea is the same
16:04 whiteknight we can bikeshed the name of it all day
16:04 pmichaud "signature" is traditionally something that attaches to the called sub
16:05 pmichaud anyway, if we have a way to get to the signature, we can handle the argument bindings on Rakudo's end without Parrot having to implement our needed semantics
16:05 whiteknight pmichaud: luckily, I think we could have :callsignature implemented in less then 30 minutes after the branch lands
16:06 pmichaud that would be great
16:06 whiteknight the bus number on the argument processing code is high enough now
16:06 pmichaud basically we just need to be able to introspect the arguments and do our own parameter binding
16:07 pmichaud i.e., rakudo may have a custom version of the "get_params" opcode to unpack the argument list into local registers
16:07 whiteknight gotchar
16:07 whiteknight or gotcha
16:11 whiteknight I also want to get :invocant working too. That shouldn't take long after the refactors either
16:13 pmichaud aha, looks like it ended up being ":call_sig".
16:14 whiteknight okay
16:14 pmichaud http://irclog.perlgeek.de/p​arrot/2009-08-18#i_1405216   # important discussion
16:14 whiteknight the token that we match in IMCC is hardly as important as the underlying mechanic of it
16:15 pmichaud I'm simply pointing out that the thread there identifies exactly what rakudo needs from the flag
16:15 whiteknight gotchar
16:15 pmichaud not the name of the flag
16:15 * whiteknight has stupid fingers today
16:18 whiteknight if we can get all the items on this task list completed, Parrot will have quite an imprssive call system indeed
16:18 dalek tracwiki: v10 | whiteknight++ | CallingConventionsTasklist
16:18 dalek tracwiki: +info about :call_sig and :invocant
16:18 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingCo​nventionsTasklist?version=10&amp;action=diff
16:18 shorten dalek's url is at http://xrl.us/bfqi6p
16:22 dalek tracwiki: v11 | whiteknight++ | CallingConventionsTasklist
16:22 dalek tracwiki: https://trac.parrot.org/parrot/wiki/CallingCo​nventionsTasklist?version=11&amp;action=diff
16:22 shorten dalek's url is at http://xrl.us/bfqi7b
16:25 whiteknight pmichaud: if you had :lookahead, would you still need to be doing all your own argument processing?
16:25 pmichaud likely yes
16:26 pmichaud right now our argument processing is being done in PIR
16:26 pmichaud which is really slow
16:26 whiteknight okay.
16:26 pmichaud we'd like that to be in C, for obvious reasons
16:26 pmichaud we not only have to bind arguments to the correct parameters, but we also have to perform type checks
16:26 whiteknight Is there any combination of things we could give you that would enable you not to have to do all your own processing?
16:26 pmichaud sure, if Parrot wants to implement a smart-matching vtable :)
16:27 pmichaud (short answer:  unlikely)
16:27 whiteknight you assign arguments to parameters using smart matching?
16:27 pmichaud we do type checks with smart matching, yes.
16:27 pmichaud sub foo(Int $x)  { ... }     has an implicit   "$x ~~ Int"  in order to do the type checking
16:31 pmichaud fwiw, we've just had another instance where someone has a Rakudo failure because of TT #389
16:40 whiteknight I was hoping to tackle that issue during the hackathon this weekend too, but PCC took up all the time
16:40 whiteknight I was too optimistic
16:40 theory joined #parrot
16:41 dukeleto 'ello
16:41 whiteknight good morning duke!
16:41 dukeleto whiteknight: top of the localtime() to you as well
16:47 mokurai joined #parrot
16:56 dukeleto how did the pcc_reapply hackathon go?
16:56 szabgab joined #parrot
16:57 dukeleto szabgab: howdy
16:57 purl salut, dukeleto.
16:57 szabgab hi dukeleto
16:57 dukeleto we need a new topic, unless it is still saturday somewhere
16:59 whiteknight working on it...
17:00 Topic for #parrotis now Parrot 1.6.0 "half-pie" released! | pcc_reapply branch still needs your love! Let's get that sucker locked and merged! | Testing priorities: pcc_reapply branch
17:02 whiteknight dukeleto: hackathon went great! Branch isn't 100% still but much closer
17:03 cotto_work good morning
17:04 whiteknight and our bus number on that code is significantl improved
17:07 dalek close: r178 | Austin++ | trunk/ (14 files):
17:07 dalek close: Object-ified Visitors. Got PrettyPrint.nqp, TypeResolution.nqp working as
17:07 dalek close: Visitors.
17:07 purl hmmm... visitors is a log analysis app
17:07 dalek close: review: http://code.google.com/p/close/source/detail?r=178
17:08 dukeleto perhaps we should add a link to the pcc_reapply page on the wiki in the topic?
17:09 moritz sure
17:11 dalek TT #1092 closed by jkeenan++: Remove NQP leftovers during 'make realclean'
17:11 Topic for #parrotis now half-pie" released! | pcc_reapply branch still needs your love! Let's get that  sucker locked and merged! | Testing priorities: pcc_reapply branch
17:12 Topic for #parrotis now half-pie" released! | pcc_reapply branch still needs your love! https://trac.parrot.org/parrot/​wiki/CallingConventionsOverview | Testing priorities: pcc_reapply branch
17:12 Topic for #parrotis now half-pie" released! | pcc_reapply branch still needs your love! https://trac.parrot.org/parrot/​wiki/CallingConventionsOverview
17:14 dukeleto what about this page? https://trac.parrot.org/parrot/​wiki/CallingConventionsTasklist
17:14 shorten dukeleto's url is at http://xrl.us/bfqjf4
17:16 moritz is it linked from the overview-page?
17:16 cotto_work looks like a calling conventions task list of some kind
17:19 whiteknight that is THE calling conventions task list
17:19 hercynium joined #parrot
17:19 dukeleto i don't think they are inter-linked
17:19 dukeleto the tasklist is on the front page, the other is not
17:20 whiteknight what othre?
17:25 dukeleto https://trac.parrot.org/parrot/​wiki/CallingConventionsOverview is not linked to on the wiki home page
17:25 dukeleto you have to search for it
17:26 allison dukeleto: the overview I wrote because people were asking about the whys and hows of what the branch was about
17:26 allison dukeleto: to help people get started working in ot
17:26 allison on it
17:35 dalek close: r179 | Austin++ | trunk/ (5 files):
17:35 dalek close: Got SymbolResolution visitor working object-style.
17:35 dalek close: review: http://code.google.com/p/close/source/detail?r=179
17:44 bacek joined #parrot
17:55 joeri joined #parrot
18:00 kurahaupo joined #parrot
18:00 einstein joined #parrot
18:00 jsut_ joined #parrot
18:01 kurahaupo Good morning all
18:01 einstein I just hanged my linux kernel while building my parrot build (containing a bug) :)
18:04 whiteknight good morning kurahaupo
18:04 whiteknight einstein: what rev? in trunk?
18:05 einstein it is my own build, it is caused by a bug in my code, when it was running miniparrot my mouse stopped moving
18:05 cotto_work einstein, that's a much more interesting failure mode than we usually see. ;)
18:06 cotto_work The nice thing about parrot hacking is that I'm not likely to hang my system.
18:06 einstein i could retry running it
18:07 Tene allison: any luck on fill_results?
18:08 NotFound einstein: it can be just trashing.
18:08 allison Tene: haven't gotten much time to hack on it
18:08 allison Tene: (I've applied the patch, but not made any edits yet)
18:08 Tene allison: that's fine.  no rush.  My morning has been unbelievably hectic.
18:09 allison Tene: I know the feeling :)
18:09 Tene It's noon, and I'm still recovering. ><
18:09 allison Tene: are you teaching this week?
18:09 einstein notfound: it can be, but that is also not correct if I can not move my mouse for over 10 sec then I call it a kernel/kerneldriver bug
18:10 Tene Yes.  Teaching an online class.  I tried to teach from home, but my internet connection failed, had to run into the office, problems with the online labs, problems with the phone server...
18:10 allison Tene: oh, goodness, nightmare
18:10 NotFound einstein: yeah, but in that case the kernel isn't hanged
18:11 NotFound einstein: just set a limit to the process memory
18:12 einstein notfound: that migth help, but it is still not what I expect to happen i had to reboot the system, but i will retry to see what really happens
18:14 NotFound einstein: if you have a lot of swap space, a process eating lots of it, and a hard disk not lightning fast, that is the usual result.
18:14 NotFound I got that result lots of time testing lua in my laptop, for example.
18:16 einstein ok, good to know, but then it's still a problem in the linux kernel to me, I see it as a starvation of all other processes. :)
18:16 kurahaupo einstein: isn't Xorg at least partly still user-space? So it can be deprived of resources just like any other process...
18:17 japhb joined #parrot
18:18 NotFound einstein: I think there is no known solution to the thrashing problem other than limiting process memory.
18:18 einstein yes it can be, but I just look from a user point of view, this behavior is what all the time happens in m$ windows
18:18 whiteknight how do you limit process memory on linux?
18:18 NotFound whiteknight: ulimit
18:19 whiteknight ok
18:20 NotFound -d     The maximum size of a process’s data segment
18:22 NotFound einstein: the classic unix point of view is that a user doesn't have to care, a nice sysadmin sets the limit for him, and the user must cry to get more memory if needed ;)
18:24 kurahaupo whitenight: your ticket #1091 proposes to deprecate continuation-based exception handlers. How will this interact with exception handling in hand-crafted PIR -- such as the test suite?
18:24 einstein ah ok
18:25 einstein thanks for the ulimit info :)
18:25 whiteknight kurahaupo: very negatively :(
18:25 whiteknight actually, we're going to support both styles during the transition
18:25 kurahaupo What's the new style going to look like?
18:25 whiteknight at least, that's the plan
18:26 whiteknight not exactly sure about all the details. allison and chromatic had talked about it I think
18:26 whiteknight basically like a normal .sub, probably with a :handles() tag to specify what types and severities of exceptions it handles
18:27 NotFound whiteknight: can't we just set up a continuation that invokes the sub?
18:27 kurahaupo Does PIR care whether you enter a subroutine "from the top"? Or does any label count as an entry point?
18:28 whiteknight NotFound: I don't think I understand
18:28 whiteknight kurahaupo: Subs enter from the top. Coroutines can enter from where they last left off
18:29 NotFound whiteknight: build a ExceptionHandler that calls the sub, instead of using the sub as ExceptionHandler
18:29 pmichaud whiteknight:  I don't quite understand.... how does one "catch" an exception, then, and alter behavior?
18:30 kurahaupo And how does one get from the "return" of the exception handler back into the original sub, but past the try/catch rather than back at the point where the exception was thrown? Surely you still need a jump label *somewhere*? In which case, can we allow a "null handler"?
18:30 whiteknight NotFound: I would have to think about that. What we're mostly trying to avoid is the inferior runloop that comes when we conflate an exception handler with the sub where it's defined
18:30 pmichaud I don't think that's the correct avoidance strategy (more)
18:30 whiteknight pmichaud: push_eh and pop_eh to specify active handlers, jhust like now
18:30 whiteknight but instead of push_eh a label that is the handler, we push_eh the sub PMC
18:31 NotFound BTW we lack a way of getting the exception object in a C exception handler.
18:31 whiteknight kurahaupo: execute a "resume" to return to the point of the throw, or rethrow to go to the next handler
18:31 pmichaud whiteknight: so how does the original sub catch the exception?
18:32 whiteknight pmichaud: I'm thinking about a sub-based handler as being lexically scoped where it is push_eh'd
18:32 kurahaupo whitenight: or what, to get to point just *past* the catch block?
18:32 whiteknight kurahaupo: yes
18:32 pmichaud whiteknight: so all registers that you might want to modify have to be lexicals?
18:32 kurahaupo err, yes what?
18:32 pmichaud whiteknight: what if I need to modify an int/num/str register?
18:33 whiteknight pmichaud: all very good questions. Nothing is set in stone
18:33 pmichaud whiteknight: I think the inferior runloop problem is symptomatic of a design issue other than in the exceptions themselves
18:33 whiteknight I don't necessarily doubt that
18:33 kurahaupo It seems to me there are not two but three possible outcomes from an exception handler:
18:33 kurahaupo (1) not handled, so chain to next handler
18:33 kurahaupo (2) have fixed everything, so try operation again
18:33 kurahaupo (3) have done a "catch", so skip to some point past where the operation was tried
18:33 whiteknight but it's a BIG design issue
18:34 pmichaud I keep saying we need a "rollup" primitive
18:34 whiteknight kurahaupo: the handler is the "catch"
18:34 whiteknight pmichaud: never heard of that before. What is it?
18:34 pmichaud a way to roll back the call change to a given point
18:34 pmichaud *call chain
18:35 kurahaupo whitenight: understood. How does it indicate whether the operation should be retried, or branch past the end of the try/catch blocks?
18:35 pmichaud so that when an exception occurs and is caught, the handler (which can be in the original sub) has some mechanism to "roll up" the intermediate callers
18:36 pmichaud because we have at least two situations that can occur with an exception
18:36 NotFound Taking into account that some of that itermaediate callers can be inside inner runloops
18:36 pmichaud NotFound: yes
18:36 dukeleto kurahaupo: did you see my comments to your patches on trac?
18:36 whiteknight pmichaud: in the current situation exception handlrs do not have a finite "end". They simply continue executing in the context of the sub where they are defined
18:36 pmichaud (1)  exception occurs, and handler wants to resume execution from the point where the exception was thrown.  In this case, all of the intermediate callers have to be preserved
18:37 whiteknight every exception handler should explicitly resume or rethrow
18:37 pmichaud false
18:37 pmichaud I think there's a third possibility
18:37 pmichaud which is to abandon the path that caused the exception and continue on a new one
18:37 pmichaud that's neither "resume" nor "rethrow"
18:37 whiteknight so a "finally" block?
18:38 pmichaud perhaps... not sure what "finally" does
18:38 whiteknight keep in mind that a resume is just a continuation, so we can "resume" to anywhere
18:38 pmichaud which means I should be able to resume back to the block that set up the handler
18:38 whiteknight yes, or even further up
18:38 pmichaud but "resume" also needs an ability to "roll up" intervening contexts
18:38 whiteknight or wherever
18:38 purl i heard wherever was cheapest
18:38 pmichaud that's what we're missing
18:38 whiteknight a continuation will do that
18:39 pmichaud ...continuations roll up intervening contexts?
18:39 whiteknight at least, I think so. What do you mean by "roll up"?
18:39 pmichaud I don't think they do.
18:39 pmichaud okay, here's an example (writing nopaste)
18:39 whiteknight ok
18:39 NotFound whiteknight: no, a continuation does not abandon inner runllops
18:40 whiteknight oh, he's talking about runloops
18:40 whiteknight no, continuations do not roll those up
18:40 pmichaud and contexts as well
18:40 pmichaud some contexts are generated by new runloops, some are not
18:40 whiteknight although obviously rolling up a runloop is a priority to add, yes
18:41 NotFound But the runloops are the hard part, because involves the C stack
18:41 whiteknight there are two separate things: the dynamic execution environment (PIR, Contexts, etc) and the underlying mechanism that runs it (the C stack)
18:41 pmichaud sure
18:41 whiteknight the two should be less tightly related
18:41 pmichaud regardless, we need a "rollup" operation that allows us to return to a given caller
18:41 whiteknight and we should be able to jump up a runloop withou necessarily destroying contexts associated with it
18:42 whiteknight ideally we should never recurse runloops at all, but that's some time away
18:43 NotFound It can be done, but we need a clear design on how and why we do it. Otherwise we get a debugging nightmare.
18:44 kurahaupo dukeleto: 1089 -- points taken; will revise and split into two patches.
18:44 dukeleto kurahaupo: sounds good, let me know if you have questions
18:44 jdv79 in the last week did anyone noticed if any of the smoke targets cause any "excessive resource burden"?
18:45 dukeleto jdv79: what do you mean?
18:45 jdv79 my smoker too a dive and never came back.  not sure if its related.
18:45 jdv79 it never crashed, just buried itself it seems and stayed that way.
18:46 nopaste "kurahaupo" at 118.92.156.63 pasted "Three different ways to exit an exception handler" (16 lines) at http://nopaste.snit.ch/18223
18:46 dukeleto jdv79: a smolder client or server?
18:46 jdv79 i'll try restarting the smoking tonight
18:46 jdv79 smolder client
18:47 jdv79 been running fine for a month or so
18:47 dukeleto there are some memory leaks/weirdness in the smolder server. if it is not restarted occasionally, it craps the bed
18:48 jdv79 yeah, that's mpeter's problem:)
18:48 kurahaupo pmichaud: the "roll up" would be used to remove the "try" block from the return chain, so that when the handler returns, it would to the containing block (presumably just past the "catch" block?)?
18:48 jdv79 or is it mpeters's?
18:48 dukeleto jdv79: yeah, well I run my own smolder server too, so i know about it
18:48 dukeleto jdv79: mpeters'
18:48 pmichaud kurahaupo: remove the exception context and any intervening contexts from the return chain
18:48 jdv79 that's plural possesive, isn't it?
18:49 pmichaud (and invoke the intervening context's "leave" semantics, if they have any)
18:50 kurahaupo So if you had a "leave" section inside a try block, that would be invoked after the "catch" block?
18:50 kurahaupo Or at least, at the point in the catch block where the "roll up" was invoked?
18:51 kurahaupo pmichaud: by "exception context", do you mean what would be the containing "try" block in a HLL?
18:52 pmichaud kurahaupo: when an exception handler is invoked, it currently creates a new call frame
18:52 pmichaud and the caller of that call frame is whatever sub threw the exception
18:52 pmichaud which *isn't* necessarily the sub that defined the try block
18:53 kurahaupo Yes. I think we're both agreeing, we need 3 ways to exit from the handler?
18:54 kurahaupo Most HLL's these days would have "abort original operation" as the normal way to exit a handler; shouldn't we be optimizing for that?
18:57 kurahaupo Perhaps as a boolean parameter to "pop_eh"?
18:57 pmichaud I'm thinking a method on the thrown exception.  or an opcode
18:58 masak joined #parrot
18:58 dukeleto masak: good localtime()
18:59 NotFound kurahaupo: better we first make it work, and think about optimizing later.
19:00 dukeleto NotFound++
19:00 pmichaud it might be useful to consider something like Perl 6:
19:01 pmichaud sub foo() {   try { bar() };   say 'hello'; };    sub bar() { #`(throws exception) }
19:01 kurahaupo The resume=retry and resume=abort models have quite different relationships between the exception object, thrower, and catcher. In the resume=retry model, the catcher has to understand intimately the innermost point of the call chain, whereas in the resume=abort model, the catcher has to understand the try-block, but doesn't have to understand anything further in. So they have different places where you'd want to flag the behaviour.
19:02 pmichaud in this case, note that to get to say 'hello';   we neither resume nor rethrow the exception
19:02 kurahaupo pmichaud: my point exactly.
19:02 pmichaud right
19:02 whiteknight in that case, we "resume" to a contnuation after the try() block
19:02 kurahaupo Have a look at my nopaste snippet
19:02 whiteknight but it's still an "invoke a continuation"
19:03 pmichaud right, but we still need to get rid of the intervening calls
19:03 whiteknight that's a behavior that a continuation *should* do, if it doesn't already
19:03 pmichaud I'll check
19:03 whiteknight and if we need to implement a new type of continuation or a subclass of it, we do that
19:04 kurahaupo what about visual basic's "on error retry" (or somesuch) ?
19:04 pmichaud have to check in a bit... dinner prep
19:04 NotFound whiteknight: if we get rid if the intervening call to invoke the continuation, we can't resume
19:04 whiteknight is there currently a way to associate a "leave" semantic with a block?
19:05 kurahaupo So the new "push_eh" will take two parameters: the handler (as a sub), and its preferred return point (as a label in the current scope)?
19:07 whiteknight kurahaupo: no, just the handler
19:07 whiteknight the exception object will contain information about where to resume to
19:07 kurahaupo dukeleto: are you OK with my other patch 1090?
19:08 whiteknight One handler could handle exceptions from multiple places
19:08 NotFound A way can be to store a longjmp target in the exception handler, and providing a method that jumps to it. That way doesn't requeire a new opcode.
19:09 whiteknight at the PIR level we shouldn't need longjmps
19:09 NotFound whiteknight: we need longjmp as long as we have inner runloops
19:10 whiteknight NotFound: with sub-based handlers we don' need to care about that
19:10 whiteknight because the sub executes in the inner runloop entirely, and returns to a place in the inner runloop
19:11 pmichaud whiteknight: I'm not aware of a way to associate "leave" semantics with blocks.  We really ought to have one.
19:12 pmichaud the closest thing we have is "pushaction", I think.
19:12 NotFound whiteknight: i fail to see how can that handle all use cases.
19:12 kurahaupo whitenight: push_eh behaves a little like a PIR version of "setjump". Without that, every time one writes try/catch in the HLL, we'd need 3 subs in PIR: one for the "try", one for each "catch", and one that encloses them, just so we can unwind to and return from it.
19:13 whiteknight pmichaud: that sounds a lot like functionality that could be added to the Context PM
19:13 whiteknight PMC*
19:13 pmichaud whiteknight: agreed
19:13 whiteknight when the context is executing, see if it has an array of actions and execute them if so
19:13 pmichaud the problem is that we need something that triggers "I'm exiting"
19:13 whiteknight of course, there is a LOT of design work that would have to go into that
19:13 pmichaud that's what the "rollup" needs to do
19:14 whiteknight pmichaud: a context would know when we execute a return that it's executing
19:14 pmichaud whiteknight: but we also need a way to force a caller to exit
19:14 pmichaud and also to force a caller "n levels up" to exit
19:15 pmichaud which would cause exits from all of the callers between the current level and the one "n levels up"
19:15 whiteknight NotFound: we enter the inner runloop, perform our executions there exclusively, and then return to the outer runloop when we are done
19:15 whiteknight pmichaud: that sounds like a type of continuation, and I've already suggested that a continuation *should* shut down all intervening contexts
19:16 NotFound whiteknight: I don't think there is a way to return to the outer runloop other than a lonjmp
19:16 whiteknight again, I use the magic word "should"
19:16 pmichaud right
19:16 masak dukeleto: oh hai :)
19:16 whiteknight NotFound: the way to return to the outer loop isthe same way we do it now: the "end" opcode ends the loop and the C function returns like normal
19:16 NotFound And BTW, longjmp is a stone in the way to executing things when leaving contexts
19:16 whiteknight NotFound: all we need to do is add semantics that an inner runloop ALWAYS calls end
19:17 whiteknight an inner runloop represents an encapsulated subset of program code. Make it correspond to a boundary in PIR.
19:17 whiteknight Crossing into the new PIR enters the new runloop, and exiting out of that PIR exits the runloop
19:18 NotFound whiteknight: we do it that way in pir, but the exception handler can be invoked from c.
19:18 whiteknight the inferior runloop problem happens because we can exit from the subset of PIR but not exit the runloop
19:18 whiteknight we do not do it that way in PIR, currently
19:18 whiteknight a PIR->PIR thrown exception can jump out of our segment
19:19 NotFound Anyway, end or return doesn't signal to a C caller that it must terminate
19:20 whiteknight yes it does. the end opcode returns a NULL pc which ends the runloop
19:20 whiteknight calls the macro HALT()
19:21 NotFound whiteknight: and the C caller doesn't know that the callee has terminated exceptinally, and tries to get his results anyway.
19:21 whiteknight that's what the inferior runloop is: the inner runloop reaches the end of the program, calls "end", unwinds to the outer runloop and attempts to continue execution
19:21 whiteknight NotFound: well that's a slightly different issue. runloops don't currently check return values
19:22 whiteknight but they could
19:22 NotFound whiteknight: they could... and probably the only to handle that situation is again a longjmp
19:23 whiteknight I don't agree. No longjmps
19:23 NotFound Then we need to change all functions that enter runloops
19:24 whiteknight Yes
19:24 whiteknight which should only be Parrot_pcc_invoke_sub_*
19:25 whiteknight Parrot_pcc_invoke_sub_* checks the runloop return value, and if it contains an exception, rethrows in the current runloop
19:27 whiteknight but look at the alternatives with sub-based handers:
19:27 whiteknight 1) If code throws an exception that is not handled, parrot exits (regardles of which runloop)
19:27 whiteknight 2) if an inner runloop throws an exception, the handler is run in that runloop
19:28 whiteknight the ONLY case where we need to worry about crossing the runloop boundary is if we invoke a continuation from one code segment to another
19:28 whiteknight and we can catch that case easily: queue the continuation, unwind the runloop, invoke the continuation again
19:29 whiteknight Any C stack frames in between get discarded anyway
19:29 whiteknight so no special handling is needed
19:29 theory joined #parrot
19:31 kurahaupo ping dukeleto
19:31 purl I can't find dukeleto in the DNS.
19:32 NotFound whiteknight: suppose I have a C function that calls VTABLE_get_integer on some PMC. How can that function knows that the vtable call has throwing an exception and it must return to let the runloop that called it to end?
19:33 whiteknight NotFound: can't happen. Thrown exceptions are handled in the runloop where they are thrown
19:33 pmichaud huh?
19:33 whiteknight exceptions don't cross the boundary, only contnuations do
19:33 whiteknight pmichaud: (not currently, in my fanciful world of sub-based handlers)
19:34 NotFound whiteknight: yes, but what happens when the handler finishes?
19:34 pmichaud how does the handler get back to the code that created it?
19:34 whiteknight NotFound: either resumes or rethrows to anew handler
19:34 pmichaud "resumes" meaning "continues from the point where the exception was thrown"?
19:34 whiteknight (again, with a permissive defnition of "resume")
19:35 whiteknight resume = "continues at a continuation"
19:35 pmichaud which continuation?
19:35 pmichaud (noting that exceptions also contain continuations)
19:35 whiteknight the resume continuation (a fanciful construct that doesn't currently exist)
19:36 pmichaud exceptions already have a "resume continuation".  that's not the continuation you're looking for, is it?
19:36 whiteknight then yes, that's what we use
19:36 pmichaud that would be wrong
19:36 NotFound whiteknight: for the C function case I don't think we can be permissive. Either it continues normal excution, or is longjmp'ed out.
19:36 pmichaud going back to my original example
19:36 whiteknight but with the flexibility that the resume continuation can be directed anywhere
19:36 pmichaud can it be directed back to the sub that created the handler?
19:37 pmichaud (the sub that is actually running from a different runloop?)
19:37 whiteknight Let's say that the resume continuation is part of the exception object. So then I see no reason why the handler could not replace that continuation with one of it's own choosing
19:37 allison pmichaud: it's a continuation, it can be captured anywhere
19:37 pmichaud how does the handler get control back to the sub that created it?
19:37 whiteknight exception.'set_resume_continuation'(foo)
19:37 pmichaud I understand that part
19:38 pmichaud I'm curious how this avoids the inferior runloop problem
19:38 whiteknight pmichaud: the handler has a hard-coded or lexically-scoped variable with the continuation in it
19:38 NotFound But how you persuade the intermediate C function to gracefully terminate?
19:38 whiteknight reads where it should send control flow to, update the exception, send it on it's way
19:38 pmichaud if the handler (in an inferior runloop) invokes a continuation coming from a superior runloop, how do we .... what NotFound said
19:39 dukeleto kurahaupo: pong
19:39 allison pmichaud: it provides a sane escape from the an inferior runloop at the end of the exception handler invocation
19:39 whiteknight NotFound: if we need a longjmp there I won't fight it
19:39 NotFound whiteknight: I don't like it, but don't see other way.
19:39 whiteknight but that's an implementation detail that Parrot_pcc_invoke_sub can worry about
19:40 allison pmichaud: we could accomplish the same by adding a lot more boilerplate around the current "handlers as labels"
19:40 pmichaud allison: I'm fine with that; all I need to know is what the boilerplate is.
19:40 allison pmichaud: but, it's a lot cleaner to use the known and familiar sub model
19:40 whiteknight much cleaner
19:41 allison pmichaud: the point is, you can't navigate back into the body of the sub using a label anymore
19:41 allison pmichaud: that's what's killing us
19:41 pmichaud not even with a continuation?  ;-)
19:41 whiteknight NotFound: What if execution NEVER jumped up to the parent runloop?
19:41 whiteknight when we exit the program, we just exit
19:41 allison pmichaud: there's no marker of when the handler actually ends
19:41 NotFound whiteknight: stack overflow
19:41 purl stack overflow is probably great
19:41 pmichaud that's why I think we ought to have an "end handler" opcode or the like
19:41 allison pmichaud: it's all just a mess of labels
19:42 pmichaud the problem with the handler-as-sub approach is that the handler cannot easily get to the registers
19:42 darbelo joined #parrot
19:42 whiteknight however we do it, we need a finite demarcation between "handler" and "everything else"
19:42 whiteknight a Sub provides that already
19:42 allison pmichaud: they can get to the registers through the caller's context
19:42 pmichaud and I haven't seen how the sub containing the handler figures out that an exception occurred
19:42 pmichaud allison: (registers through caller's context)   okay, that's a new detail I was unaware of
19:43 allison pmichaud: same way they do now
19:43 whiteknight pmichaud: if the handler was lexically scoped, you could set a flag
19:43 pmichaud whiteknight: that only works for pmc registers
19:43 whiteknight or we could try to execute the handler sub in the existing context
19:43 allison pmichaud: throwing an exception scans through the set handlers in the context and back the all chain
19:43 whiteknight a little tricker but not undoable
19:43 pmichaud "execute the handler sub in the existing context" is what happens now with the label-based handlers.
19:43 whiteknight pmichaud: yes, but without the "I'm done handling" demarcation
19:43 pmichaud allison: I understand how we get the exception to the handler
19:43 whiteknight and it's that lack that kills us
19:44 pmichaud what I don't understand is how the sub that created the handler learns of the exception
19:44 allison executing in the current context isn't what's broken
19:44 NotFound What is the "existing"? The one that push_eh, or the one that has thrown?
19:44 allison the handler needs to execute in it's own context
19:44 allison (with access to the context where the exception was thrown)
19:44 pmichaud I'm fine with that.
19:45 pmichaud it's the "access to the context" part that I'm missing
19:45 pmichaud wait
19:45 pmichaud no
19:45 pmichaud false
19:45 pmichaud I'm not worried about access to the context where the exception was thrown
19:45 pmichaud I'm asking about access to the context where the handler was created
19:45 whiteknight if Contexts are PMCs and ExceptionHandlers are Subs, we can just pass the various contexts in as parameters
19:45 whiteknight :created_context, :called_context, etc
19:45 pmichaud ouch
19:46 pmichaud subclassing Sub might end up being problematic, also.
19:46 whiteknight pmichaud: My point is that there are lots of ways to do it, no one particular way is important
19:46 pmichaud that sounds like the came issue we had when we had separate Sub and Closure PMCs
19:46 pmichaud *same
19:46 allison pmichaud: the context where the handler was created is irrelevant
19:46 NotFound I don't think that ExceptionHandler isa Sub is the way to go, I'd like better ExceptionHandler has a Sub
19:46 whiteknight the capability exists, all we need to do is find the syntax that is least obnoxious
19:46 allison pmichaud: do you mean the context where the handler was set?
19:46 pmichaud allison: yes.
19:46 whiteknight NotFound: that's an implementation issue, not a design issue
19:47 whiteknight there are lots of ways to implement it, we find the one that people dislike the least
19:47 allison pmichaud: you're looking for how, for example, to resume after the close of the scope of the try block if the exception was cleanly handled?
19:48 NotFound whiteknight: sure, I was just saying whay way I dislike ;)
19:48 NotFound s/whay/what
19:48 whiteknight we can put together a wiki page to hash out details
19:48 pmichaud I'm asking how to know that the exception was cleanly handled, and how to know how it was handled
19:49 whiteknight and maybe next time I post about it to the list I won't be Warnocked. :)
19:49 allison pmichaud: the handler has to decide if it was cleanly handled and take the appropriate action
19:49 allison generally that action is "invoke the resume continuation"
19:49 pmichaud and the only mechanism the handler has for communicating back to the "outer sub" is via lexicals or other global symbol channels?
19:50 pmichaud which "resume continuation"?
19:50 pmichaud the one in the exception, or the one that returns me back to the sub that set the handler?
19:50 pmichaud there are two resume continuations at play
19:50 allison pmichaud: the one that was passed in the exception
19:50 pmichaud the one that is passed in the exception returns me back to the place where the exception was thrown
19:50 NotFound Toooooo much coupling
19:50 allison pmichaud: if that's what was requested, yes, but it can go anywhere
19:51 pmichaud how do I get the "go anywhere" part?
19:51 pmichaud that's what I'm asking
19:51 purl asking is just polite demanding. or seeking confirmation of an answer to which one has a partial clue because without a clue there is no question
19:51 pmichaud here's an example:
19:51 pmichaud try { bar(); say 'abc'; };   say 'def';    sub bar() { die 'throw';  say 'ghi'; }
19:51 pmichaud bar() is the one that throws the exception
19:51 allison pmichaud: it should be an optional argument to throw
19:51 whiteknight pmichaud: imagine a "newhandler" opcode that is like a mix between newclosure and push_eh
19:52 pmichaud the exception's "resume" continuation is the one that returns me back to bar()
19:52 * allison checks
19:52 pmichaud that's not the one I want.
19:52 allison yes, the two argument form of throw is implemented
19:52 allison pmichaud: you can pass in any continuation
19:52 pmichaud how does bar() know which continuation it's to use?!?
19:53 allison it can go anywhere
19:53 pmichaud bar() just knows to throw an exception, it knows nothing about the handler being used to handle it
19:53 pmichaud or where it's supposed to return
19:53 allison pmichaud: it's not automatic, it has to be told
19:53 pmichaud how?!?
19:53 pmichaud when I'm generating the code for bar(), how am I supposed to know what exception handlers are in effect and where they're supposed to resume to?
19:54 allison I would guess, the HLL is tracking scopes like try, and determines that throws within a particular scope resume at a particular location
19:54 pmichaud that's a runtime issue, though
19:54 particle that's my guess, too
19:54 pmichaud it's neither static nor lexical
19:54 NotFound The resume continuation is created by throw, the sub that push_eh the handler can't know about it, in general.
19:54 particle it's contextual
19:54 allison exceptions are neither static or lexical
19:54 allison they're dynamic
19:54 pmichaud right
19:54 pmichaud it's the *handler* that knows where it should resume
19:54 pmichaud not the exception, and not the sub that throws the exception
19:55 allison the handler won't know where to resume until it's told
19:55 whiteknight pmichaud: so then the handler should tell the exception where to resume to
19:55 allison pmichaud: let me try to echo
19:55 pmichaud whiteknight: which is the same as saying that the handler should do the resuming
19:55 allison pmichaud: you would like a way to set a resume continuation on the handler when you set it?
19:55 allison (when you set the handler)
19:56 whiteknight potato, potato. Internally it happens one way, externally it may look like something different
19:56 whiteknight the default is that the Exception object has a continuation and knows where to return to
19:56 allison so, "I'm setting this handler, if it catches an exception and successfully handles it, I want it to go <here> next"
19:56 pmichaud whiteknight: I would rephrase that
19:56 whiteknight that continuatin is not read-only and anybody can come along and meddle with it
19:56 whiteknight I wouldn't
19:57 pmichaud the exception object has a continuation that is initialized to return to the point from which the exception was thrown
19:57 kurahaupo allison: did I mention having two operands to "push_eh" about 20 minutes ago?
19:57 particle when building an exception handler, set the resume point.
19:57 whiteknight right, and the exception object carries that information into the handler
19:57 whiteknight and the next hander, if it's rethrown
19:57 pmichaud whiteknight: correct, I have no problem with that
19:57 whiteknight okay. Everything else is just vocabulary
19:57 pmichaud vocabulary and definitions matter. :)
19:58 NotFound We have three ways of finishing the handling: resume, rethrow, or continue at some point in the context that pushed the handler. Calling 'resume' two of them doesn't help clarity.
19:58 pmichaud allison: it's not only "I want it to go <here> next", it's also "I want to know that an exception occurred"
19:59 particle pmichaud: just that an exception occurred, or that it was handled successfully?
19:59 NotFound pmichaud: the fact of reach <here> can be used as a way to know.
19:59 pmichaud NotFound: not in the example I gave above
19:59 allison pmichaud: you want to write exception handling code outside the exception handler?
19:59 whiteknight NotFound: there are only two ways. Rethrow or invoke the resume continuation
20:00 allison pmichaud: could you give me a practical example?
20:00 kurahaupo pmichaud: you get <here> next only happens if the exception happened
20:00 pmichaud allison: I'm asking how the exception handler can affect things in the block that set it.  The answer seems to be "use lexicals or globals".
20:00 pmichaud I'm fine with that.
20:00 NotFound whiteknight: Who set that return continuation?
20:01 NotFound s/return/resume
20:01 whiteknight NotFound: depends
20:01 allison pmichaud: sounds like you want asynchronous execution more than an exception handler
20:01 whiteknight $P0 = new 'Exception' \n $P0['resume'] = WhateverIWant
20:01 NotFound whiteknight: it doesn't depend, throw sets it.
20:01 whiteknight throw $P0
20:01 allison pmichaud: i.e. "here's some code, let me know when it executes and return some values"
20:01 pmichaud no, that's not it at all.
20:01 whiteknight in future parrot, throw only sets it if it hasn't been set already
20:02 pmichaud I'm not talking at all about async execution
20:02 pmichaud let me find an example -- just a moment
20:02 NotFound whiteknight: you can't "real resume" in that case, then.
20:02 whiteknight NotFound: forget the word "resume" then. Call it something else if the word is a problem
20:02 purl whiteknight, I didn't have anything matching word "resume" then. call it something else if the word is a problem
20:03 NotFound whiteknight: the word is a problem because it hides the problem.
20:03 whiteknight NotFound: there is no problem!
20:03 NotFound Then what are we discussing?
20:04 whiteknight There are two flows: "normal" flow and "exceptional" flow. "Resume" jumps from exceptional flow back to normal flow
20:04 pmichaud there are three flows
20:04 whiteknight and throw jumps from normal flow to exceptional flow
20:04 pmichaud *that's* what I keep pointing out that you're ignoring
20:04 pmichaud you keep saying there are two, but there are three
20:04 NotFound whiteknight: there is no "normal". Either you go back to the thrower, or to the push_eh'd
20:04 whiteknight I haven' seen anything different
20:05 pmichaud whiteknight:    try { bar(); say 'abc'; };   say 'def';    sub bar() { die 'throw';  say 'ghi'; }
20:05 allison pmichaud: I don't see three
20:05 whiteknight me either
20:05 allison pmichaud: either the exception wasn't handled and you die
20:05 pmichaud okay, I'll rephrase
20:05 allison or it was handled and you resume *somewhere*
20:05 pmichaud whiteknight:    try { bar(); say 'abc'; CATCH { $!.resume if rand() < 0.5; } };   say 'def';    sub bar() { die 'throw';  say 'ghi'; }
20:06 NotFound allison: yes, but we have two somewheres
20:06 kurahaupo At first I'd come to the same conclusion as pmichaud (about having 3 cases). But  case of resume taking you back to the point just after the throw could be done by setting an additional handler at that point. (And it's only useful if the code doing the throw knows that throw might "return", so it's really the better way to do it anyway.) So we're back to only needing two ways of exiting from a handler: rethrow, or resume, and by defaul
20:06 allison NotFound: any given exception handler has only two options
20:06 allison NotFound: die or resume
20:06 whiteknight pmichaud: still only two. There's the flow where no errors happen, and the flow where errors happen
20:06 pmichaud whiteknight: there's a third.... an error happens, but where we go next depends on a randome number
20:06 pmichaud *random
20:07 NotFound allison: resume to the thrower, or resume to the tryer.
20:07 whiteknight pmichaud: that's not different in terms of underlying control flow
20:07 pmichaud it's very different
20:07 pmichaud the "resume" continuation in the exception is different from where we go if we don't invoke it
20:07 allison NotFound: the exception handler never decides whether to resume to the thrower or the tryer
20:07 whiteknight look at the mechanism: You either have no exception and continue like normal, or you have an exception and go someplace exceptional
20:07 pmichaud allison: it does in my example above!
20:07 whiteknight how that "someplace" is defined has nothing to do with the mechanism
20:08 NotFound allison: who decides?
20:08 kurahaupo pmichaud: your random number could be in an inferior exception handler, which can then either resume or rethrow (to reach the outer exception handler)
20:09 pmichaud kurahaupo: then what does the outer handler do?  does it resume the exception? or does it rethrow again?
20:09 NotFound The sub way of handler shows it: it can rethrow, resume, or return.
20:09 whoppix joined #parrot
20:09 kurahaupo allison: yes. It should *always* resume to the trier. If the thrower wants it to come back, it should set its own try block as well.
20:09 whiteknight pmichaud: we are obviously talking about two very different meanings of the word "flow"
20:09 allison pmichaud: I don't see it. which example and I'll try to decipher it with indentation
20:09 pmichaud I'll write with indentation
20:09 pmichaud one moment
20:09 whiteknight no need for indentation
20:09 whiteknight we're talking about different things
20:10 nopaste "pmichaud" at 72.181.176.220 pasted "try example #1" (18 lines) at http://nopaste.snit.ch/18225
20:10 kurahaupo pmichaud: where you had one handler that tossed a coin to decide whether it wanted to rethrow, retry or finish, that could be split into two handlers. The inner one gets to choose "retry" or not, and the outer one gets to choose "rethrow" or "finish".
20:11 NotFound The problem is simple: the try block may need a resume point. The thrower needs another. But we have just one.
20:11 allison pmichaud: what does $!.resume do?
20:11 pmichaud resumes at the point of the thrown exception
20:11 whiteknight pmichaud: and you still don't have a third option, it is still between "resume" and "rethrow"
20:11 pmichaud whiteknight: rethrow is a third option here
20:11 pmichaud watch
20:11 whiteknight two options: resume, rethrow
20:12 allison pmichaud: always, with no chance to tell it to resume to any other point?
20:12 nopaste "pmichaud" at 72.181.176.220 pasted "try example #2" (19 lines) at http://nopaste.snit.ch/18226
20:12 allison pmichaud: always the line after the die?
20:12 kurahaupo NotFound: the try block doesn't need a resume point. If it needs one, it can set an additional inner handler
20:12 pmichaud isn't the "line after the die" what we normally mean by "resume an exception"?
20:12 kurahaupo NotFound: s/try/throw
20:12 pmichaud whiteknight: three possibilities
20:13 allison pmichaud: there are all kinds of places where you might resume an exception
20:13 pmichaud allison: which means there are more than just two
20:13 allison pmichaud: following a try block is a sensible one
20:13 kurahaupo me hears $DAYJOB calling; bye everyone
20:13 allison pmichaud: only one for each exception
20:13 allison (but where that one is can vary)
20:13 pmichaud whiteknight: do you see my three possibilities yet?
20:14 pmichaud one possibility is to resume after the point of the exception
20:14 pmichaud one possibility is to rethrow the exception
20:14 NotFound kurahaupo: maybe can be done that way, but looks overcomplicated to me.
20:14 pmichaud one possibility is to neither resume nor rethrow, but to simply exit the handler and return to the block that set it
20:14 pmichaud "exit the handler" may in fact be "invoke a continuation"
20:15 allison pmichaud: the third is "resume"
20:15 pmichaud but it's not the "resume continuation" that was put into the Exception
20:15 pmichaud then what is the first?
20:15 allison a curious feature of Perl 6 exceptions
20:16 pmichaud huh?
20:16 NotFound allison: is hard to see examples in other languages because few allow resume.
20:16 pmichaud we wouldn't have a case where a called function might throw an exception and an outer handler takes care of it and says "okay, continue from where you left off?"
20:16 Tene while we're discussing exceptions...
20:16 allison a resumable exception is one that allows the code to continue executing in some way
20:17 Tene one thing that I've really wanted is the ability to *return* something when resuming.
20:17 allison having both a line-level and a block level resume is odd
20:17 NotFound allison: then C++ has resumable exceptions... don't tell that to Bjarne ;)
20:17 Tene you can kind of hack around it by replacing the payload of the exception... but that sucks.
20:17 pmichaud in Parrot, this is why the "throw" opcode automatically fills in the 'resume' attribute with a continuation to return to the point where the exception was thrown
20:17 moritz from the old quick basic times, "ON ERROR RESUME NEXT"
20:17 pmichaud ...line level resume?
20:17 allison pmichaud: yes, but it's also why the "throw" opcode allows you to set a different continuation
20:18 pmichaud allison: but as in this case, the thrower has no clue
20:18 pmichaud the thrower can't know how to resume the exception, because that's up to the handler to decide
20:18 pmichaud all the thrower can do is say "if you want to come back here, here's a continuation you can use to do it"
20:19 particle a self-addressed stamped envelope
20:19 NotFound allison: if we need to couple all possible throwers with all his possible callers that sets handlers, we are in big trouble.
20:19 allison pmichaud: well, the compiler can provide any information it want there
20:19 allison this is generated code
20:19 pmichaud counter example coming up
20:19 nopaste "pmichaud" at 72.181.176.220 pasted "try example #2" (27 lines) at http://nopaste.snit.ch/18227
20:19 AndyA joined #parrot
20:20 pmichaud sorry, that should be #3
20:20 pmichaud #4 coming up
20:21 nopaste "pmichaud" at 72.181.176.220 pasted "try example #2" (31 lines) at http://nopaste.snit.ch/18228
20:21 allison pmichaud: that one assumes that the static scope determines the continuation, but it's the dynamic scope that determines it
20:21 pmichaud I'm not assuming static scoping here at all
20:21 allison pmichaud: the call to bar() from the first try and the second try are two different calls
20:21 allison (with two different call chains)
20:21 pmichaud I know that.
20:21 pmichaud I know that.
20:22 pmichaud but you're saying that the thrower (bar) is supposed to set a different continuation
20:22 NotFound moritz: the old Basic is a good counter example: it needs to know exactly were the error is thrown and what error is to decide if it can RESUME, RESUME NEXT, or die.
20:22 pmichaud I'm asking how is the thrower (bar) supposed to know what continuation it's to set?
20:22 allison pmichaud: no, I'm saying there is runtime code that detects entry into a try block and sets throws within that block to resume at the try
20:22 purl okay, allison.
20:23 pmichaud wait
20:23 pmichaud that sentence reads all wrong
20:23 pmichaud in my code, there are no throws statically within the try block
20:23 allison I'm saying it's dynamic not static
20:24 pmichaud I know that.
20:24 pmichaud in my example, what is "the thrower"?
20:24 pmichaud I claim it's "bar()"
20:24 allison the die statement
20:24 pmichaud right
20:24 pmichaud the die statement within bar
20:25 pmichaud okay.  The PIR code that gets generate for that is     die "throw exception"
20:25 pmichaud or if we want to be more precise
20:25 pmichaud $P0 = new ['Exception']
20:25 pmichaud $P0['message'] = "throw exception"
20:25 pmichaud throw $P0
20:25 pmichaud (modulo syntax)
20:25 pmichaud correct?
20:26 allison in the simplest case, yes
20:26 pmichaud or are you saying that what we should instead be doing at the point of the "die" is introspecting up the caller chain to find a try block?
20:26 allison depends on how complex your exception semantics are
20:26 pmichaud in the above case
20:27 pmichaud to me, creating a try block is "push_eh"
20:27 allison you could do that
20:27 allison you could also do something similar within the handler
20:27 pmichaud the thing that I push is a handler
20:27 pmichaud in my example, I'd be pushing the CATCH block
20:27 pmichaud i.e., the CATCH block is my handler
20:27 pmichaud because that's where control goes when an exception is thrown
20:28 allison but, push_eh doesn't create a scope
20:28 NotFound allison: the exception can be thrown from C code in a vtable function, for example. That can't depend on how complex pmichaud's current code semantics.
20:28 pmichaud it will in what you're describing though, yes?
20:28 pmichaud if all handlers are subs
20:28 pmichaud handler == sub  implies "new scope"
20:28 allison technically, at the moment, every block is should be a sub
20:28 pmichaud correct
20:28 pmichaud no problem
20:28 allison anything less is fudging
20:29 allison (though fudging can work)
20:29 allison NotFound: exceptions thrown from C can't resume anyway
20:29 theory joined #parrot
20:30 pmichaud allison: "can't resume" there doesn't match your definition of resume above
20:30 pmichaud this is what I find difficult to understand
20:30 pmichaud 20:15 <allison> pmichaud: the third is "resume"
20:30 allison NotFound: which, oddly enough is one thing I find compelling about the possibility of resume continuations on handlers instead of exception objects
20:30 pmichaud 20:14 <pmichaud> one possibility is to neither resume nor rethrow, but to simply exit the handler and return to the block that set it
20:31 pmichaud clearly we can catch a C example and resume execution after handler, which is what you just said is "resume"
20:31 allison pmichaud: C exceptions can't do any form of resume
20:31 pmichaud we can't catch C exceptions at all?
20:31 allison pmichaud: sure we can, and we run the handler
20:31 allison the handler decides what to run next
20:31 pmichaud and all that the handler can do is rethrow then?
20:32 NotFound allison: I think that clearly shows that two resume points are required. The C throw can't resume to the throw point, but can resume to the push_eh'd
20:32 pmichaud because whiteknight was saying that our only two options are "rethrow" and "resume"
20:32 pmichaud but if C exceptions can't resume, then we can only rethrow
20:32 pmichaud I have to leave for 15 mins to pick up kids
20:32 pmichaud bbi15
20:33 allison I should be more semantically precise
20:33 allison C exceptions can't "line-level" resume
20:34 NotFound That shows that we have 3 cases, not 2
20:36 GeJ Good morning everyone
20:37 cotto_work hi GeJ
20:37 GeJ Hi cotto
20:39 pmichaud "semantically precise" is what I've been asking for here, yes.
20:40 pmichaud so my three possibilities are:
20:40 pmichaud (1)  rethrow the exception  (to another handler)
20:40 pmichaud (2)  return to the point where the exception was thrown ("line-level resume")
20:41 pmichaud (3)  return to the sub that created the handler
20:41 pmichaud you're saying that (3) could in fact be "return to anywhere"
20:41 pmichaud I'm fine with that
20:41 pmichaud but the point is that whatever information is in (3) doesn't belong in the Exception object
20:41 pmichaud the Exception object should have the information for (2)
20:42 pmichaud and if it's not "line-level" resumable (such as an exception thrown from C), then the Exception object doesn't have a resume continuation
20:45 NotFound And if is "line-level" resumable, it has only one resume action, that way can't provide the 2 and 3 ways.
20:45 NotFound Either 2 or 3.
20:45 pmichaud correct
20:46 pmichaud granted, a handler could replace the Exception's line-level resume continuation with one of its own
20:46 pmichaud but in that case, it's the handler that is setting the resume point, not the thrower
20:46 allison pmichaud: yes, I'm saying that 2 and 3 are "return to anywhere"
20:47 pmichaud formulating a new code-based question....
20:48 pmichaud actually, it's a one liner:
20:48 pmichaud suppose I have      try bar(my $a = 5);
20:48 pmichaud i.e., I'm doing a try operation but not introducing a new scope
20:48 pmichaud how should that look in PIR?
20:48 pmichaud in this case I'm not interested in doing anything with the thrown exception except ignore it
20:49 pmichaud currently I would do:
20:49 pmichaud push_eh label
20:49 pmichaud # code for bar(my $a = 5)
20:49 pmichaud pop_eh
20:49 pmichaud er,
20:49 pmichaud starting over
20:49 pmichaud push_eh label
20:49 pmichaud # code for bar(my $a = 5)
20:49 pmichaud label:
20:49 pmichaud pop_eh
20:50 pmichaud ... rest of block here
20:51 pmichaud i.e., if my exception handler is invoked, I want it to resume at 'label'
20:51 allison basically, you're looking for a replacement for the fact that handlers used to be part of the normal flow of execution
20:51 pmichaud no
20:51 allison you want an.... "anchor"
20:51 allison which a second continuation can provide
20:51 pmichaud okay
20:51 pmichaud fine
20:51 pmichaud so how do I do that?  speculation is fine.
20:51 pmichaud note that my "handler" in this case is empty
20:52 pmichaud and it's actually irrelevant to the fact that I need to resume at a label
20:52 pmichaud I'm asking about the "resume at a label" part
20:52 allison here's a question, if you set a handler and it's invoked twice, do you want it to continue at the same point both times?
20:53 pmichaud I think the answer is "yes" but I don't see how it applies here
20:53 pmichaud I have to pick up another kid, bbi10
20:54 allison pmichaud: well, that would be a handler that only resumes at a given point
20:58 NotFound I fail to understand how the "return to anywhere" approach can work. The thow point can set up a continuation. How to return to any other place? Walking the continuation chain?
21:01 Tene Hehe, I love the logwatch messages I get after a night of parrot hacking. :D
21:01 Tene WARNING:  Segmentation Faults in these executables
21:01 Tene parrot :  29 Time(s)
21:01 Tene WARNING:  General Protection Faults in these executables
21:01 Tene parrot :  12 Time(s)
21:05 pmichaud okay, after driving a bit, here's my current guess
21:05 pmichaud $P0 = new ['ExceptionHandler']
21:05 pmichaud .const 'Sub' $P1 = 'myhandler'
21:05 pmichaud $P0.'set_handler'($P1)
21:05 pmichaud $P2 = new ['Continuation']
21:05 pmichaud set_addr $P2, label
21:06 pmichaud $P0.'set_resume'($P2)
21:06 pmichaud push_eh $P0    # set handler
21:06 pmichaud # code that might throw an exception
21:06 pmichaud label:
21:06 pmichaud pop_eh
21:08 pmichaud $P0 is the exception handler, it contains a sub to be invoked upon catching an exception, and it contains a continuation indicating where to resume by default after the exception has been handled
21:09 pmichaud note that the sub to be invoked has at least three options available to it by default
21:09 pmichaud (1) it can line-level resume using the continuation stored in the caught exception
21:09 pmichaud (2) it can rethrow the exception to a different handler
21:10 pmichaud (3) it can resume using the continuation given to it when it was created
21:10 NotFound I like that way
21:10 pmichaud it can of course resume to any continuation it wishes, but these are the three common cases
21:11 NotFound And (3) can be invoked just by returning from the sub
21:11 pmichaud I'm not sure about that part
21:12 pmichaud in essence you're saying to set the handler's return continuation
21:12 NotFound We need to decide what to do if it returns, anyway.
21:12 pmichaud correct
21:12 pmichaud and for (3) we need it to "roll up" any intermediate inferior loops
21:12 pmichaud if invoking a continuation does that, that's great.
21:12 NotFound Set a continuation that is set_addr has been used go for it, and if not dies horribly.
21:13 joeri left #parrot
21:13 NotFound s/is/if
21:14 NotFound ExceptionHandler can be a Continuation that does that when invoked.
21:15 pmichaud not exactly
21:15 pmichaud rolling up occurs at the end of the handler, not at the invocation of the handler
21:15 pmichaud because we might line-level resume
21:16 NotFound In the current implementation, yes, but the invocation of the sub handler can be done other way than VTABLE_invoke.
21:19 pmichaud regardless, we can't throw away the intermediate runloops until the handler exists
21:19 pmichaud *exits
21:19 NotFound Yes
21:21 NotFound If we go the way that the real handler is a Sub we set, maybe a name other than ExceptionHandler will be cleaner for the controller object.
21:24 NotFound Something like: $P0 = new 'TryBlock' | .const 'Sub' $P1 = 'myhandler' | $P0.'set_handler'($P1) | set_addr $P0, label | push_eh $P0
21:24 allison NotFound: any point can set up a continuation, not just the throw point
21:24 pmichaud please not 'TryBlock'
21:24 pmichaud not all try invocations are blocks
21:24 pmichaud handlers might be blocks, but some try invocations are not
21:25 pmichaud really we're creating a handler, not a try block
21:25 pmichaud a try block is what is in effect between the push_eh and pop_eh opcodes
21:25 NotFound pmichaud: but if we say that the sub handles the exception, calling 'Handler' to the other thing is confusing
21:26 pmichaud Handler is an object that describes how an exception is handled
21:26 pmichaud that object can be a sub, or it can contain a sub (equivalent design choices)
21:26 pmichaud Handler could also be a continuation that contains a sub
21:26 pmichaud but that's semantically weird, the names will confuse people
21:28 NotFound allison: What point?
21:28 purl well, point is if the drive dies
21:28 dukeleto http://google-opensource.blogspot.com/2009/10​/perls-of-wisdom-perl-foundation-parrots.html
21:28 shorten dukeleto's url is at http://xrl.us/bfqku7
21:28 dukeleto The Perl Foundation and Parrot Foundation are on the Google Open Source Blog. w00t
21:28 allison NotFound: any random point in the code can be a continuation
21:29 NotFound allison: yes, but random points in the code usually don't look at the ExceptionHandler active chain.
21:30 allison NotFound: I think you mean the reverse "ExceptionHandlers don't usually look at random points in the code"
21:31 NotFound Both
21:31 allison the first doesn't make any sense
21:31 pmichaud the thing that creates the ExceptionHandler is likely the thing that needs to be able to set the resume point
21:31 pmichaud in this case, the "try" statement
21:32 NotFound The things that usually need to set some sort of resume point in the ExceptionHandler are the push_eh'd and the exception thrower.
21:33 NotFound If other parts of the code want to set another continuation, they push_eh his own ExceptionHandler
21:34 NotFound We can make an overgeneralized mechanic, sure. But I don't whink we want.
21:35 nopaste "pmichaud" at 72.181.176.220 pasted "Continuations do not currently resolve the inferior runloop problem (for whiteknight)" (134 lines) at http://nopaste.snit.ch/18230
21:35 pmichaud (for scrollback)
21:36 pmichaud whiteknight:  http://nopaste.snit.ch/18230  shows that Continuations as implemented now aren't sufficient to resolve the inferior runloop problem -- we still have the same issue. (more)
21:36 NotFound pmichaud: yes, but a special purpose Continuation can longjmp to the runloop of the push_eh context
21:36 pmichaud NotFound: why a special purpose Continuation, though?  shouldn't all Continuations do that?
21:37 NotFound pmichaud: good question
21:37 purl Yeah, it is. I'm stumped.
21:37 pmichaud and if we do need a special purpose Continuation for that purpose, I suspect it's "RetContinuation" :)
21:38 pmichaud or something like it.
21:38 NotFound Mmmm... I think no, no, that way wil
21:38 dalek tracwiki: v23 | cotto++ | PMCUnionDeprecationTasklist
21:38 dalek tracwiki: add a note that this task is complete
21:38 dalek tracwiki: https://trac.parrot.org/parrot/wiki/PMCUnionD​eprecationTasklist?version=23&amp;action=diff
21:38 shorten dalek's url is at http://xrl.us/bfqkyc
21:38 pmichaud whiteknight:  And whatever is done to solve the problem for Continuations and inferior runloops would likely be sufficient to fix the existing exception handler issues
21:38 NotFound Mmmm... I think no, that way wil kill runloops just by invoking a sub
21:40 NotFound Maybe not any sub, but a coroutine for example.
21:46 allison Continuations don't pay any attention to the C runloop, and they shouldn't
21:47 allison pmichaud: and, runloops aren't the primary problem with the current exception handlers
21:47 pmichaud allison: what is the primary problem?
21:47 purl rumour has it the primary problem is power
21:47 allison pmichaud: encapsulation
21:47 purl encapsulation is not letting the data be modified directly; that is providing mutator methods and whatnot
21:48 pmichaud that's a design problem, and implementation problem, or ...?
21:48 allison the design was modified to accomodate the way people were used to using exception handlers
21:49 allison (as simple labels)
21:49 allison but, it's a poor result
21:49 pmichaud at this point I have no problem with switching to something else
21:49 pmichaud but the discussion of changing the current model is based on TT #1091
21:50 NotFound But we have the runloop problem, one way or the other
21:50 pmichaud and TT #1091 explicitly identifies the inferior runloop problem as being a major issue with exception handlers
21:50 pmichaud i.e., that's the problem that led to today's conversation
21:50 allison it marks it as "most notably" but doesn't really go into much detail
21:51 pmichaud sure.  but it's the source of today's conversation :)
21:51 pmichaud and it says we're eliminating continuation-based exception handlers.  That's ripe for misinterpretation, I think.  Or are we really eliminating continuation-based exception handlers?
21:52 allison it's the source of the latest round on the discussion, aye
21:52 pmichaud (yes, we may be deprecating exception handlers that jump to a label in the current sub)
21:52 allison but the move to exception handlers as subs has been pending for a couple of years now
21:53 pmichaud (that's okay with me... I'm just curious what we're replacing it with.  If getting rid of the current model doesn't resolve the inferior runloop problem, I'm not sure I'm in favor of a change.)
21:53 allison pmichaud: nothing will ever "solve" the inferior runloop problem
21:53 allison well, nothing except for never dropping out into C code
21:54 pmichaud can I attach those two comments to the relevant tickets?
21:54 allison (hence some of the push for Lorito)
21:54 pmichaud because I think the push has been an attempt to get rid fo the segfaults associated with the inferior runloop problem.
21:55 hercynium_ joined #parrot
21:55 allison yes, we can eliminate segfaults
21:55 NotFound allison: I think that for the particular case of ExceptionHandler it can.
21:55 NotFound be solved
21:55 pmichaud and stack overflow, also?
21:55 allison we can improve the way we deal with inferior runloops
21:55 pmichaud okay, I think that's been today's discussion
21:55 allison but inferior runloops themselves aren't the problem
21:56 allison Parrot actually deals with them pretty transparently
21:56 pmichaud except for exceptions :)
21:56 pmichaud and continuations from within vtable subs
21:56 allison the tricky part about the current exception handlers is that there isn't a clear point for the inferior runloop to terminate
21:57 NotFound I'm testing an idea... one moment...
21:57 pmichaud allison: right, agreed.
21:57 allison if exception handlers were subs, then the inferior runloop would terminate when the sub terminates
21:57 allison clean and simple
21:57 pmichaud allison: why/how?
21:58 pmichaud I mean, what's the mechanism to terminate the inferior runloop?
21:58 allison the inferior runloop is started to execute the sub
21:58 allison to execute the handler
21:58 allison (to be clearer)
21:58 pmichaud but the sub has to invoke a continuation to get back to the label set for the handler
21:58 pmichaud note:  the resume label, not the handler label
21:58 nopaste "NotFound" at 213.96.228.50 pasted "Avoid inner runloops in exception handling" (18 lines) at http://nopaste.snit.ch/18231
21:59 allison pmichaud: sure, but the user doesn't much care how its invoked
21:59 NotFound This way works and pass tests... but we don't have good test for exception resumes
21:59 pmichaud NotFound: sure we do....
22:00 allison that is, it determines what code will run after the handler is finished, but that could just as well be back in the original runloop
22:00 NotFound pmichaud: I don't doubt we have tests, I doubt they are good enough
22:00 pmichaud NotFound: I think we can create some tests
22:01 pmichaud allison: I'm a little confused... just a sec
22:02 pmichaud allison: in http://nopaste.snit.ch/18230, the inferior runloop occurs at the point of #5  0xb7d804b7 in Parrot_pcc_invoke_sub_from_c_args (interp=0x8909040, yes?
22:02 allison <sigh> more longjmps
22:03 NotFound allison: Parrot_ex_throw_from_op doesn't create a runloop, unless the handler is an NCIç
22:03 allison NotFound: yes, that's true, that's why it exists
22:04 NotFound But the runloop can be already created, for example by a pir overriden vtable call
22:05 allison pmichaud: that inferior runloop seems to be something other than an exception handler, the signature is P->I
22:06 allison pmichaud: most inferior runloops are short-lived
22:06 allison pmichaud: they're called, they run the code, they return, they end
22:06 NotFound And Parrot_ex_throw_from_c doesn't create a runloop, it longjmp to the push_eh context runloop
22:06 Whiteknight joined #parrot
22:07 NotFound In the from_c that doesn't harm, because it doesn't need to be resumable.
22:07 allison NotFound: I vaguely remember someone making a change like that
22:08 NotFound allison: that was me
22:09 allison I also vaguely remember sighing "more longjmps" then too :)
22:09 Whiteknight hello again
22:09 allison but, that goes away if exception handlers are subs
22:10 NotFound If we do the same in from_op, as the nopasted patch does, we can't safely resume in all cases. The runloop jump must be done after handling, not before.
22:10 allison (that's still not the primary reason for making exception handlers subs, it's just an added benefit)
22:11 allison NotFound: the longjmp is unnecessary in from_op, it can just make the exception handler the next instruction in the current runloop
22:11 allison that's why the variant exists
22:11 NotFound allison: I don't like longjmp, but the current way gives no other option.
22:13 allison ah, interestingly, whiteknight was talking about a completely different runloop scenario when he raised this again
22:13 NotFound allison: yes, is unnecessary, but it gives us the inner runloop problem.
22:13 allison the problem wasn't terminating the runloop of the exception handler
22:14 allison it was with resuming into the context where the handler was set
22:14 * Whiteknight is usually by himself in left field
22:14 NotFound The problem IMO is terminating all runloops created between the push_eh point and the throw point.
22:14 allison instead of creating a new context for the handler
22:14 allison which is a problem that making exception handlers subs really will fix
22:15 NotFound Well, runloops and contexts et al, but now that contexts are garbage collected that's not a problem.
22:16 allison NotFound: maybe runloops should be garbage collected :)
22:16 NotFound allison: yes, we just need a C compiler that handles that ;)
22:16 allison maybe runloops should be PIR subs instead of C functions
22:17 NotFound The runloop structs and all his data sure can be garbage collected, but the real problem is the C stack.
22:17 allison we're trying to emulate continuations with longjmp, and it's painful
22:18 patspam joined #parrot
22:21 pmichaud I don't understand how making exception handlers into subs will fix the problem
22:22 pmichaud could someone patiently walk me through it?
22:22 Whiteknight pmichaud: sure!
22:22 allison pmichaud: the problem of handlers needing to run in their own context?
22:22 NotFound allison: I was trying to find a way to handle vtable overrides without entering runloops, buy got trapped by pcc. When the branch lands, I'll take another look to it.
22:23 Whiteknight pmichaud: the inferior runloop problem happens because we have two notions of state: dynamic state (contexts, interpreter, etc) and machine state (C stack frame)
22:24 pmichaud allison: I don't have a problem with the idea that handlers run into their own context
22:24 pmichaud *in
22:24 pmichaud that part I understand
22:24 pmichaud but when a handler needs to resume to its outer sub... I don't see how that happens
22:24 Whiteknight inferior runloop happens when we call down into a new runloop (C stack), then jump up to a previous context. We end up in the previous context but with a different machine state
22:24 Whiteknight pmichaud: gotcha
22:24 pmichaud Whiteknight: you weren't here for my comments while you were out of line
22:25 pmichaud er, offline
22:25 pmichaud just a sec
22:25 cotto_work dukeleto++'s writeup of TPF and Parrot's GSoC projects is on Googles open source blog
22:25 cotto_work http://google-opensource.blogspot.com/2009/10​/perls-of-wisdom-perl-foundation-parrots.html
22:25 shorten cotto_work's url is at http://xrl.us/bfqku7
22:25 pmichaud 21:36 <pmichaud> whiteknight:  http://nopaste.snit.ch/18230  shows that Continuations as implemented now aren't sufficient to resolve the inferior runloop problem -- we  still have the same issue. (more)
22:25 cotto_work (nothing surprising, but good pr)
22:25 pmichaud 21:38 <pmichaud> whiteknight:  And whatever is done to solve the problem for Continuations and inferior runloops would likely be sufficient to fix the existing exception  handler issues
22:26 NotFound The problem mainly is: to resume to the throw point runloops must be preserved. To return to the try point, they must be discarded.
22:26 pmichaud Whiteknight: the problem isn't strictly that exception handlers return to the context in which they were created.  yes, that's a problem, but it's not the fundamental problem
22:26 Whiteknight NotFound: runloops don't need to be preserved because we can't preserve C stacks state
22:27 Whiteknight the underlying problem is the PIR->C->PIR control flow paths
22:27 pmichaud Whiteknight: the problem occurs anytime we want to jump from an inferior runloop into a superior runloop... this happens even when invoking Continuations, as my nopaste illustratges
22:28 Whiteknight yes, that's what I was saying earlier
22:28 pmichaud so, even if the exception handler runs in an inferior runloop in its own context, when that handler attempts to resume back to the context that created it, we have no existing mechanism to exit the inferior runloop
22:28 Whiteknight pmichaud: but such a mechanism could be added, so long as we limit the number of cases where it happens
22:28 pmichaud Whiteknight: I'm fine with that.
22:28 Whiteknight a very general solution is difficult, but if it's just continuations trying to bridge the gap, that's fine
22:29 NotFound Whiteknight: discarding the runloop is a longjmp to the original runloop, that gets rid of all intermediate C stacks
22:29 Whiteknight Again, the underlying problem is the C system stack, and so long as we are using it for our control flow, we are bound by it's semantics
22:29 pmichaud but whatever mechanism gets used for that could also be used for our existing ExceptionHandler implementation (more)
22:29 Whiteknight NotFound: there are lots of implementations for it
22:29 pmichaud I'm not saying that's a strong argument for keeping the existing implementation; I'm just saying that what works for one likely works for the other
22:30 Whiteknight pmichaud: adding that functionality to our existing exceptions implemetatin will be VERY difficult
22:30 Whiteknight not impossible, but hard
22:30 pmichaud not at all
22:30 pmichaud if you can solve it for continuations at any level, you can solve it for this one
22:30 pmichaud if nothing else, introduce a new opcode that does the longjmp
22:31 Whiteknight it's not so simple as just performing the longjmp, it's a matter of knowing when to longjump and where to longjmp to
22:31 pmichaud then the exception handler can perform whatever operation is needed to effectuate the longjmp
22:31 NotFound We alredy can use longjmp, the problem with the current implementation is to know when we can do it.
22:31 pmichaud the handler can know when to do the longjmp
22:31 pmichaud it doesn't have to be automatic
22:31 japhb joined #parrot
22:31 Whiteknight Right, ExceptionHandlers need to have a record of the runloop_id where it was created
22:31 Whiteknight which means runloop_id needs to be unique
22:32 pmichaud actually, I think it needs the runloop_id of whatever its return continuation is going to be
22:32 pmichaud which might not be the same as where it's created
22:32 pmichaud or the same as where it's established as an active handler
22:34 Whiteknight can't be. C stack state is tied to dynamic execution state
22:34 Whiteknight to avoid inferior runloops, the handler MUST be executed where it was defined
22:34 theory joined #parrot
22:34 Whiteknight otherwise there is a mismatch between dynamic state and C state
22:34 pmichaud wait
22:34 pmichaud the handler is a separate sub now, right?
22:34 pmichaud oh, I see your point
22:34 pmichaud fair nuff
22:35 pmichaud yes, for handlers as they exist now, we'd have to store the runloop of the handler's continuation
22:35 NotFound Not where it was created, but where ir was pushed
22:35 pmichaud "where it was pushed" is the handlers continuation, if using   push_eh label
22:36 pmichaud if using push_eh $P0, then the continuation could be somewhere else entirely
22:36 pmichaud (i.e., then it would be using set_addr)
22:37 pmichaud at any rate, since I'm not implementing any of this I guess I should shut up now.
22:37 pmichaud thanks for the explanations.
22:37 pmichaud I still maintain that ultimately we need a longjmp, and once we accept that we find that it can be used with the current implementation.
22:37 pmichaud actually, wait, I have another question
22:37 pmichaud (sorry)
22:38 pmichaud in today's Parrot
22:38 pmichaud I create a handler using push_eh label
22:38 NotFound pmichaud: yes, but I think the runloop involved will be always the one from the push_eh point.
22:38 pmichaud I call some stuff that creates an inferior runloop that throws an exception
22:38 pmichaud that exception ends up invoking my handler
22:38 pmichaud what runloop is currently running my handler?
22:39 pmichaud the inferior one, yes?
22:39 NotFound pmichaud: the problem is the runloop to return, not the actually running the handler.
22:39 pmichaud NotFound: yes, I agree.
22:39 pmichaud the answer to my question is "yes" then, correct?
22:39 NotFound pmichaud: yes
22:40 NotFound pmichaud: if not, resume can't work in all cases
22:40 pmichaud so why is it a problem for there to be an opcode that the handler can use to longjmp back to the superior runloop?
22:40 pmichaud i.e., if a continuation can do it, why can't an opcode?
22:40 NotFound I think the only problem is to remember to use it.
22:40 pmichaud or, if not an opcode, a method.
22:41 pmichaud remembering to use that opcode is not hard....  it's generated code anyway.
22:41 NotFound pmichaud: yes, but we have a lot of tests to fix.
22:41 NotFound Not a big problem, anyway.
22:43 ruoso joined #parrot
22:43 pmichaud "lot of tests to fix"  not really
22:43 pmichaud existing code would continue to work as it does now
22:43 pmichaud with the potential segfault
22:44 pmichaud but new code could properly avoid the segfault
22:44 NotFound A method in the Exception or in the ExceptionHandler can be a way, and easier to quick test than an opcode.
22:44 pmichaud i.e., the change I'm describing doesn't require changing any existing code... the old code continues to be broken in exactly the same ways as before
22:44 NotFound pmichaud: yes, but tests that are currently todoed or skipped.
22:45 tetragon joined #parrot
22:45 pmichaud besides, having done it before, it's not all that hard to do  "ack push_eh t"  :)
22:45 NotFound Or even not written X-)
22:46 pmichaud okay, I'm satisfied for now then.  Thanks.  :)
22:51 kthakore joined #parrot
22:53 Whiteknight (sorry i disappeared again)
22:53 Whiteknight I have a bad habit of doing that
22:54 darbelo Is anyone else seeing failures in t/examples/pir.t ?
22:56 kthakore darbelo: thanks man I am now :(
22:57 kthakore let me update
22:57 NotFound darbelo: just a TODOed one for me.
22:57 cconstantine joined #parrot
22:57 NotFound Eh, no one, two.
22:58 darbelo Hmm. I have two TODO failures (17 and 18)
22:58 darbelo And a failure in test 9
22:59 dukeleto darbelo: can you nopaste the failures ?
23:00 nopaste "darbelo" at 200.49.154.173 pasted "failure in t/examples/pir.t" (13 lines) at http://nopaste.snit.ch/18232
23:01 darbelo I spent about a hour chasing that sucker before noticing it still failed without my changes.
23:02 dukeleto darbelo: this happens in trunk?
23:02 darbelo dukeleto: Yep. OpenBSD i386 trunk.
23:02 dukeleto darbelo: that is for t/examples/pir/io.t, BTW
23:03 dukeleto darbelo: i thought you were talking about t/pir/*.t, sorry, I don't know what that is about
23:04 kthakore darbelo: error:imcc:syntax error, unexpected IDENTIFIER, expecting $end ('use')
23:04 kthakore I get that
23:05 darbelo kthakore: Can you nopaste the output of prove -v t/examples/pir.t ?
23:05 kthakore ok
23:05 kthakore whats the nopaste link again?
23:05 kthakore first time on here
23:05 darbelo purl: nopaste?
23:05 purl nopaste is, like, at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/ or http://paste.scsys.co.uk (for #catalyst, #dbix-class, #moose  and others) or http://gist.github.com/ or paste or gtfo or tools/dev/nopaste.pl or https://trac.parrot.org/parrot/br​owser/trunk/tools/dev/nopaste.pl
23:05 darbelo http://nopaste.snit.ch/parrot
23:06 kthakore ok
23:08 nopaste "kthakore" at 99.234.159.149 pasted "parrot -v t/examples/pir.t (oct 05 2009 7:00 pm revision from SVN)" (8 lines) at http://nopaste.snit.ch/18233
23:08 kthakore done
23:08 kthakore do you want make test output?
23:08 dukeleto kthakore: there is a command line script to post to nopaste, tools/dev/nopaste.pl in the parrot repo
23:08 kthakore oooh
23:08 kthakore thats so cool
23:08 PacoLinux joined #parrot
23:09 Whiteknight dukeleto++ # GSOC blog post
23:09 kthakore so  cmd > tools/dev/nopaste.pl ?
23:09 dukeleto Whiteknight: thanks
23:09 darbelo kthakore: "prove -v" not "parrot -v"
23:09 kthakore ah
23:09 kthakore sorry first time using parrot and not rakudo
23:09 kthakore ok
23:09 dukeleto kthakore: cmd &> cmd.out && nopaste -t "my title" cmd.out
23:09 kthakore ok
23:10 kthakore thanks dukeleto
23:11 kthakore dukeleto: I don't have nopaste.pl in tools/dev
23:11 kthakore I got latest svn
23:12 dukeleto kthakore: it is there for me, you sure?
23:12 kthakore yup
23:12 kthakore did svn up
23:13 nopaste "kthakore" at 99.234.159.149 pasted "prove -v t/examples/pir" (28 lines) at http://nopaste.snit.ch/18234
23:13 kthakore ok dukeleto still don't have it but I gotta go back to #sdl
23:13 kthakore darbelo: its up there
23:13 kthakore hope it helps
23:13 kthakore kthxbye
23:14 dukeleto kthakore: https://trac.parrot.org/parrot/br​owser/trunk/tools/dev/nopaste.pl
23:14 shorten dukeleto's url is at http://xrl.us/bfqmdb
23:14 kthakore thanks
23:15 nopaste "darbelo" at 200.49.154.173 pasted "Remove 'fake' STRING from Parrot_io_flush_buffer()" (30 lines) at http://nopaste.snit.ch/18235
23:15 * Whiteknight hasn't even looked at trunk in days
23:15 dukeleto Whiteknight: that is good. make believe it doesn't exist and keep hacking on pcc_reapply :)
23:16 darbelo Can someone test http://nopaste.snit.ch/18235 please? OpenBSD has gremlins in it's io.
23:20 cotto_work darbelo, Ubuntu/x64 is happy
23:20 dalek parrot: r41729 | coke++ | trunk/DEPRECATED.pod:
23:20 dalek parrot: fix deprecation notices.
23:20 dalek parrot: Items are eligible for removal /after/ a stable/supported release, not /in/ one.
23:20 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41729/
23:24 darbelo Good enough for me. cotto++
23:27 kthakore left #parrot
23:27 dalek parrot: r41730 | darbelo++ | trunk/src/io/buffer.c:
23:27 dalek parrot: Remove 'fake' STRING from the Parrot_io_flush_buffer() function.
23:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41730/
23:27 Whiteknight allison, Tene: ping!
23:27 Tene Whiteknight: PONG
23:27 Whiteknight Tene: any progress on the returns passing code?
23:28 Tene Whiteknight: I'm just about done with work for the day, and then i have some errands to run.
23:28 Tene AKA... no.
23:29 cotto_work Tene, is your wip committed?
23:29 Tene cotto_work: I committed it, and then everyone hated it and reverted it, because nobody could understand it.
23:30 darbelo ouch.
23:30 Tene cotto_work: allison says it's good, though, and almost finished, so I'm going to try again to finish it tonight, if allison doesn't beat me to it.
23:30 Tene Well, it was the right thing to do.  I was leaving for the night, and it made all of the tests fail, so nobody could work on anything else.
23:30 cotto_work I notice that people keep doing that with bacek++'s c++-style comments too, even when he leaves explicit notes about them in the commit messages.
23:31 Whiteknight We looked at the code and had the patch set
23:31 Whiteknight but no, I didn't know enough to make it work in place
23:31 Tene I have no objections.  I would have reverted it too.
23:31 Tene I just wanted to get it out there somehow so it was recorded.
23:32 darbelo Tene++ # going on the record :)

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

Parrot | source cross referenced