www.parrot.org | Parrot 1.6.0 "half-pie" released: PCC branch hackathon all $localtime Saturday | Testing priorities: pcc_reapply branch
Set by moderator on 4 October 2009.
00:01 payload joined
whiteknight bacek isn't lost, he is only resting 00:06
bacek whiteknight: I wish... 00:09
whiteknight is there any major difference in the logic between the results passing and argument passing logic? 00:14
why can't we just use fill_params for each, with different accessors? 00:15
they both support the same kinds of values and flags 00:17
and in the end, they're both just invocations (Sub vs RetContinuation) 00:18
bacek yeah... 00:24
but even fill_params doesn't fit in my head.
whiteknight I think we can use fill_params instead, if we add a src and dest context to it 00:27
bacek I would prefer just normal FSM instead of this 200+ lines of code... 00:28
similar to Parrot_str_to_num. 00:29
with small static functions to handle each state. 00:30
whiteknight we will refactor it down, I hop 00:31
hope
bacek: I think the clone key args commit broke some tests 00:33
kid51 At r41721, make smolder_coretest now fails completely at \t t/compilers/imcc/syn/pasm.t 00:34
bacek whiteknight: I know. Looking right now
whiteknight ok 00:35
kid51: yes, intentionally broken to refactor some things.
kid51 slinks off for more beer ... 00:36
whiteknight okay, the CallSignature contains information about the returns. It contains an ordered list of results. 00:40
so in fill_params we move items from the CallSignature into the local Context 00:41
and in fill_results, we move items from the loca Context into the CallSignature
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 /
GeJ huh, I'm synced with bacek now. Those DST thingies are too confusing. 00:45
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
I'm trying to fix it
whiteknight what are you fixing? Tene's commit or r41717? 00:53
bacek fill_results 00:54
clone_key_arg already "fixed"... 00:55
whiteknight ok 00:56
I'll give you all the time you need 00:57
you are the magical coding robot :)
dalek rrot: r41722 | bacek++ | branches/pcc_reapply/src/call/args.c:
"Fix" fetching caller_ctx in clone_key_arg.
rrot: r41723 | bacek++ | branches/pcc_reapply/src/call/args.c:
Intvals are stored directly in bytecode, not in constants. Fix

C++ comment intentionally left to verify it by someone else.
rrot: r41724 | bacek++ | branches/pcc_reapply/src/call/args.c:
More accurate handling of Nulls in fill_results.
00:59 hercynium joined
whiteknight still a lot more test failures then there were a few commits ago 00:59
yeah, it hangs 01:04
bacek ok... way to much for me to fix it... 01:07
especially because I can't comprehend logic behind this code. 01:08
whiteknight right
bacek whiteknight: fell free to revert it.
whiteknight okay, will do
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
we can reapply the good things after that 01:10
bacek let me revert just 2 commits.
whiteknight okay, if you can get us back to a low number of failed tests 01:13
bacek r41725
dalek rrot: r41725 | bacek++ | branches/pcc_reapply/src/call/args.c:
Revert "[pcc] The start of the fill_results refactor. Doesn't work well yet."
 01:14
purl It's a Y2K error! Panic! Sue!
01:20 kjeldahl joined 01:23 Zak joined
whiteknight okay, I'm going to sleep now. Goodnight 01:25
01:28 zak_ joined
dalek rrot: r41726 | bacek++ | branches/pcc_reapply/src/call/args.c:
Disable clone_key_arg. Need more information how to get caller_ctx properly to clone it.
 01:30
nopaste "kid51" at 70.85.31.226 pasted "pcc_reapply branch: --buildframes=0: current failures verbose output" (1463 lines) at nopaste.snit.ch/18221 01:32
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.
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.
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.
pmichaud ooc, why is "set results before getting the returns" odd? 01:49
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
I think the set results might've been to provide context to the called function
e.g., if someone wants to implement the equivalent of P5's want()
the caller function would need to say what it wants before it calls the callee 01:51
Tene Hmm. Could be. 01:52
01:52 Zak joined
Tene Allison was under the impression that it was arbitrary, and plans to change it back after 2.0 01:52
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
langauges that want a want() will likely have to communicate that information out-of-band somehow, then.
*languages 01:56
01:56 TiMBuS joined
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
I'm reall yuncomfortable with huge chunks of repeated code like that, though.
pmichaud oh, I agree, I think the whole pcc stuff is pretty ugly :)
Tene If I can get things set up for my class tomorrow, I'll dive back in for a few hours. 02:15
02:17 zak_ joined
bacek sigh... 02:20
We can use single code path for all argument passing.
bacek finally wrapped head around PCC
1. Implement single fill_params function.
2. Drop fill returns 02:21
3. "op returncc" will use fill_params
Tene bacek: if you can do it, go ahead.
bacek: what changes to fill_params do you expect will make that possible? 02:22
bacek fill_params will not changed at all.
Tene I don't see how to do that, but maybe I've got too narrow a view of the problem. 02:23
02:25 Zak joined
bacek op set_returns can just remember "raw_returns" in Context. op returncc will pass it to fill_params 02:25
Tene bacek: are you planning to implement this tonight, or just discussing? 02:27
bacek clock?
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 /
bacek There is a lot of time till "tonight" :)
Tene Well, looks like I'll have a couple of hours available in maybe 24 minutes. 02:28
GeJ seconds bacek in his statement. 02:30
Tene Bah, time zones. :P 02:31
GeJ seconds that too :)
02:38 zak_ joined
bacek oookey. fill_params need 2 Context arguments. 02:41
Tene See? I'm not crazy! 02:42
02:42 Zak joined
bacek but I am 02:43
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:44
02:48 janus joined
dalek ose: r177 | Austin++ | trunk/ (12 files):
Class-ified Visitor, restarted on PrettyPrint.nqp
 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
codetest 03:05
purl hmmm... codetest is part of fulltest, distro_tests is part of fulltest, but not of codetest
dalek rrot: r41727 | mikehh++ | branches/pcc_reapply/src/call/args.c:
codetest fixes - remove C++ comment, linelength
 03:06
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
dalek TT #1092 created by geraud++: Remove NQP leftovers during 'make realclean' 03:12
03:16 Zak joined
mikehh pcc_reapply - smolder.plusthree.com/app/public_pr...ails/28571 03:23
shorten mikehh's url is at xrl.us/bfqgvq
mikehh failures up on last time I ran it - 6,430 ok, 67 failed, 100 todo, 162 skipped and 1 unexpectedly succeeded 03:24
03:32 zak_ joined 04:01 Zak joined 04:41 bacek joined 05:06 bacek joined 05:21 Zak joined
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 /
cotto bacek is unusually ephemeral today 05:25
05:27 bacek joined 05:43 patspam1 joined 06:04 uniejo joined 06:37 jrtayloriv joined 06:41 fperrad joined
Tene bacek: any progress? 06:43
allison bacek/Tene: fill_params cannot work for set_returns 06:47
bacek/Tene: the logic is backwards
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.
allison bacek/Tene: fill_returns pulls values from registers/varargs and stores them in the call object 06:49
Tene: we will be able to unify them after we fix the order of set_returns/get_results
Tene Yeah, that's what i told him.
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:50
allison Tene: cool 06:52
Tene: was some of it reverted later?
Tene: or is 'svn up' enough to get it?
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:53
I sent you a message via purl with the revision numbers you want to look at. 06:54
allison Tene: ah, the joy of time zones 06:55
Tene: I'm about to leave for class, will take a look and be back on in a couple of hours 06:56
Tene: I suspect we can start with your patches and get the details fixed up and ready to go later today 06:57
Tene :)
I'm sleeping shortly.
allison Tene: right, so if I have questions I'd better ask them soon?
Tene I'll be glad to look at it after teaching class tomorrow, so... 17 hours or so.
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.
allison: It started as a copy of fill_params.
allison Tene: I don't know yet if I'll have network access in class (first day)
Tene: gotta run to catch my bus 07:00
Tene Have fun. :)
07:13 hiroyuki_y joined 07:22 iblechbot joined
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 07:40 mikehh joined 07:56 allison joined
allison apparently I do have network access 07:57
Tene O HAI allison 08:12
allison Tene: hai 08:16
mikehh bris.ac.uk? 08:26
japhb use.perl.org/~geoffrey/journal/39713 # Plumage "Day" 8
allison mikehh: aye
mikehh it's about as far from me as you can get in the uk - sw vs ne 08:27
allison mikehh: where are you? 08:28
mikehh aberdeen in scotland
allison mikehh: ah, I hear it's lovely up there, never been
mikehh: we might have to plan a parrot hacking session 08:29
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:30
moritz though you have to add that some scottish cities even have countryside within the city borders :-) 08:31
allison moritz: always a good quality for a city to have 08:32
moritz: Portland is known for the US's largest "city park"
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
moritz sounds very nice
allison golf courses are nice too 08:35
mikehh gotta take someone into town bbiab 08:36
dukeleto forrest park in portland is something like 5000 acres (sorry for the imperial units)
which is about 2000 hectares 08:37
allison www.forestparkconservancy.org/ 08:38
dukeleto allison: are you in pdx?
allison dukeleto: not any more, I live in Bristol, UK
dukeleto: but that was the last place I lived, before South Africa
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
allison moving, class over 08:50
08:54 einstein joined 09:40 masak joined 09:56 DrForr_ joined 09:57 allison joined 10:09 slavorgn joined, cconstantine joined 10:10 bacek joined 10:14 kurahaupo joined 10:31 quek joined 10:58 jsut joined 11:06 cconstantine joined
nopaste "bacek" at 110.175.161.144 pasted "Use fill_params to get_results/set_results ops for allison" (210 lines) at nopaste.snit.ch/18222 11:20
11:21 bacek joined
bacek msg allison 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
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:36
bacek: so, if we mangle the fill_params code now, it'll just make more work for us later 11:37
dalek kudo: d91717d | masak++ | src/ (2 files):
moved Array.delete to setting

hey, all the old tests pass, plus two TODO'd ones.		 11:42
shorten dalek's url is at xrl.us/bfqhu6
11:44 jrtaylor joined
bacek allison: how that? I don't use fill_returns in nopasted code at all. 11:45
allison: and fill_params wasn't touched either.
allison bacek: fill_params stores arguments in the args array and hash 11:49
bacek allison: yes. And...?
purl i guess yes. and is 5.5.3 under new naming
allison bacek: fill_returns stores them in the returns
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
allison bacek: yes, your code is doing the wrong thing 11:50
bacek: it doesn't work
purl It's a Y2K error! Panic! Sue!
bacek allison: unfortunately it does :)
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
allison bacek: yes, and can only ever be for _op versions
bacek: after 2.0 we'll change it to use a separate call signature for call and return 11:52
bacek: it's not possible now
bacek allison: indeed. But I doubt that we need complex returns from c code.
allison bacek: the code has to be the same for C and PIR 11:53
bacek: and, yes we do have complex returns for C code, because any method can be called from C
bacek sigh...
allison including PIR methods/subs with complex returns 11:54
bacek afk # rl
allison bacek: I understand the frustration, and I appreciate the work to unify things
masak what does a PIR line such as "$S0 = tokentable[$S0;'precedence']" do? tokentable is a Hash, but what does the semicolon signify? 12:04
12:06 whiteknight joined
allison masak: it's a second-level key 12:06
masak allison: ok. what does that mean under the hood?
a hash of hashes?
allison aye, or a hash of arrays,
or an array of arrays
masak: not all PMC's implement it the same way 12:07
masak ok.
thanks.
I looked around in docs/ but couldn't find any information about this.
allison needs something more prominent 12:09
(I can't even find it)
whiteknight good morning #parrot
allison masak: ah, there's a mention docs/book/pir/ch04_variables.pod 12:11
hi whiteknight
whiteknight hello allison
I didn't manage to do anything productive after you left last night
allison whiteknight: ah well, it was a very productive hackathon weekend
whiteknight backlogging now to see if anybody else was more successful
yes it was! 12:12
masak allison: ok. I missed that one when grepping.
allison masak: yeah, it's a hard one to grep for
whiteknight: I need to pull Tene's patches and fix up the last details. Looking them over, they're quite close 12:16
whiteknight I was looking at them too, but I didn't know enough to complete them 12:17
I made a few changes and broke the living hell out of them, but that's hardly the same thing
12:17 quek joined
allison whiteknight: could be considered progress :) 12:17
whiteknight so what's really the logical difference between returns passing and arguments passing? 12:19
I kept hoping that, Parrot being CPS-based, they would be the same
I was wrong
allison whiteknight: they are the same... or they were 12:22
whiteknight "theoretically"
allison whiteknight: sometime back, and I think it was Chip's refactor, it was changed so that "get_results" is called *before* "set_returns"
whiteknight right, you mentioned that
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
whiteknight or, "un-refactor" it?
allison whiteknight: aye, we'll have to change the IMCC syntactic sugar to work the other way
whiteknight changing IMCC? Sounds fun and easy 12:24
</sarcasm>
allison whiteknight: but, more importantly, we'll have to change the way PASM works
whiteknight yes, and then it's all grand unification for Parrot 12:26
allison Whoot 12:29
whiteknight I'll start updating the CallingConventionsTasklist to reflect some of these long-term TODO items
dalek rrot: r41728 | jkeenan++ | trunk/config/gen/makefiles/root.in:
Applying patch submitted by Geraud in trac.parrot.org/parrot/ticket/1092: clean up parrot_nqp* files in 'realclean'.
 12:30
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 12:40 quek joined 12:42 quek left, quek joined 12:47 quek left
dalek tracwiki: v7 | whiteknight++ | CallingConventionsTasklist 12:53
tracwiki: Add some new items to the task list
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfqh6d
dalek tracwiki: v8 | whiteknight++ | CallingConventionsTasklist 13:00
tracwiki: regroup items in this tasklist into individual refactors starting with the current PCC refactors and moving down to other items
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfqh6s
dalek TT #1094 created by whiteknight++: Unify VTABLE_invoke semantics between PMC types 13:05
13:10 bluescreen joined
whiteknight those stages probably need to be reordered 13:10
dalek tracwiki: v9 | whiteknight++ | CallingConventionsTasklist
tracwiki: rearrange stuff, move some task metadata to a ticket
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfqh7n
whiteknight cotto: ping 13:14
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.
whiteknight Getting good, concise lists of TODO items and arrnaging them into a nice roadmap is a very good idea, I think 13:19
dalek tracwiki: v5 | whiteknight++ | StringsTasklist 13:23
tracwiki: cleanup. Add note about the need to properly encapsulate things. 13:24
tracwiki: trac.parrot.org/parrot/wiki/String...ction=diff
shorten dalek's url is at xrl.us/bfqh8q
TiMBuS hey whiteknight, i got bored and decided to try and implement that NCI in C/asm. has anyone else tried it? 13:28
whiteknight I had one guy submit a solution with libJIT, but nothing for pure ASM 13:29
TiMBuS kewl 13:31
13:35 iblechbot joined 13:56 mberends joined
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
13:57 PacoLinux joined
TiMBuS whiteknight, i keep debating between a C implementation and an ASM one. 13:59
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
except inline assembly, of course
TiMBuS well, id build the bytecode 14:01
whiteknight ah, okay. So a home-brew JIT?
TiMBuS for the express purpose of calling functions
i figured it was a better solution 14:02
14:02 payload joined
TiMBuS its a lot better than having to deal with gcc's inline asm, if anything. 14:03
whiteknight The only inline ASM that you really need is to push arguments onto the stack 14:04
everything else can be normal C
TiMBuS actually im on amd64
whiteknight oh, that does complicate things a little bit 14:05
TiMBuS i have the ABI for it
whiteknight I actually don't know as much about the x64 ABI as I should
TiMBuS its not too hard really
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:12
TiMBuS oh, i see. 14:15
im not really familiar with what selinux does 14:16
whiteknight it basically takes all our hard work and craps on it
TiMBuS lol 14:17
NotFound One of the thing it does, if configured that way, is to set execution permissions to mapped memory.
forbid to set, I mean.
TiMBuS well i can see how that would prevent malware 14:19
14:21 Psyche^ joined 14:31 davidfetter joined 14:46 fperrad joined
particle www.youtube.com/watch?v=9T1vfsHYiKY 14:53
particle repeats 100 times, "the perl debugger is not gdb." 14:56
maybe now i'll stop typing 'bt' there
14:57 AndyA joined 15:03 Eevee joined
whiteknight has actually never used the parrot debugger 15:03
eventually I feel like I should try it 15:04
15:04 payload joined
whiteknight and the profiler too, I never used that 15:04
particle whiteknight: have a few minutes to catch me up on pcc changes?
whiteknight particle: sure thing
particle what are the goals of the current branch? 15:05
whiteknight I've got a few bullet points on the wiki, CallingConventionsTasklist
particle what's the expected merge-to-trunk date?
moritz "when it works" :-)
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
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...
whiteknight We're still failing tests at this point, but we went from >400 failures to ~60 15:07
so we're making very good progress.
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
particle before 1.7 would be better.
15:08 theory joined
whiteknight yes, it would 15:08
particle this has dragged on a very long time. it has been promised since before 1.0.
whiteknight I just don't want to make promises 15:09
particle i know, time flies like bananas.
whiteknight What's lacking now is that the returns logic doesn't handle all the necessary options
once that gets in, everything should pass again
moritz and PGE should build again?
whiteknight PGE I believe is only blocking on :named and :slurpy returns
so yes, once we get those working again things should work 15:10
there are a few semantic issues we probably need to work out too, but nothing major
particle top priority, please. 15:13
i'll give you a cookie.
seriously, though, and i'll bring this up tomorrow (assuming i can attend #parrotsketch)... 15:14
rakudo *needs* this done asap, or their schedule for a spring release of Rakudo * is blown. 15:15
our hlls are our most important customers, and they've been ignored too long.
progress has been made lately: it's nice to see tcl getting some love. 15:16
15:22 ruoso joined
whiteknight particle: I'll give the issue my full attention. We've got a team of devs doing the same 15:30
and our bus number on that branch is quite large now
particle hoarde++
15:32 iblechbot joined
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:34
particle which way are you going with VTABLE_invoke? 15:38
whiteknight what do you mean?
particle args first, or after?
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.
whiteknight because we can pass arguments into a CallSignature first, and then callee can unpack those args whenever necessary 15:40
so PIR funcs can unpack it after invoke, while NCI can unpack it during invoke
all the processing happens in the get_params opcode now, so after the Sub bytecode starts executing anyway 15:41
the biggest problem with VTABLE_invoke is getting a "self" variable to show up in the PIR, which CallSignature should also neatly solve 15:42
pmichaud fwiw, I'm not sure that Rakudo needs :lookahead now (more) 15:59
we're already expecting to have to do our own argument unpacking into parameters 16:00
it's more important for us to have :capture available
whiteknight what's :capture? 16:01
pmichaud just a sec-- finding relevant thread/conversation
whiteknight (add anything else you need to the CallingConventionsTasklist on the wiki too, so it doesn't get lost)
pmichaud irclog.perlgeek.de/parrotsketch/200...#i_1404773 16:02
whiteknight ah okay, I know what you're talking about 16:03
the thing that I was referring to as :signature
pmichaud :signature is the wrong name for this 16:04
should be :callsignature, :callsig, or :arglist
whiteknight regardless of the name, the idea is the same
we can bikeshed the name of it all day
pmichaud "signature" is traditionally something that attaches to the called sub
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
pmichaud that would be great 16:06
whiteknight the bus number on the argument processing code is high enough now
pmichaud basically we just need to be able to introspect the arguments and do our own parameter binding
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
or gotcha
I also want to get :invocant working too. That shouldn't take long after the refactors either 16:11
pmichaud aha, looks like it ended up being ":call_sig". 16:13
whiteknight okay 16:14
pmichaud irclog.perlgeek.de/parrot/2009-08-18#i_1405216 # important discussion
whiteknight the token that we match in IMCC is hardly as important as the underlying mechanic of it
pmichaud I'm simply pointing out that the thread there identifies exactly what rakudo needs from the flag 16:15
whiteknight gotchar
pmichaud not the name of the flag
whiteknight has stupid fingers today
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
tracwiki: +info about :call_sig and :invocant
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfqi6p
dalek tracwiki: v11 | whiteknight++ | CallingConventionsTasklist 16:22
tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff
shorten dalek's url is at xrl.us/bfqi7b
whiteknight pmichaud: if you had :lookahead, would you still need to be doing all your own argument processing? 16:25
pmichaud likely yes
right now our argument processing is being done in PIR 16:26
which is really slow
whiteknight okay.
pmichaud we'd like that to be in C, for obvious reasons
we not only have to bind arguments to the correct parameters, but we also have to perform type checks
whiteknight Is there any combination of things we could give you that would enable you not to have to do all your own processing?
pmichaud sure, if Parrot wants to implement a smart-matching vtable :)
(short answer: unlikely) 16:27
whiteknight you assign arguments to parameters using smart matching?
pmichaud we do type checks with smart matching, yes.
sub foo(Int $x) { ... } has an implicit "$x ~~ Int" in order to do the type checking
fwiw, we've just had another instance where someone has a Rakudo failure because of TT #389 16:31
whiteknight I was hoping to tackle that issue during the hackathon this weekend too, but PCC took up all the time 16:40
I was too optimistic
16:40 theory joined
dukeleto 'ello 16:41
whiteknight good morning duke!
dukeleto whiteknight: top of the localtime() to you as well
16:47 mokurai joined
dukeleto how did the pcc_reapply hackathon go? 16:56
16:56 szabgab joined
dukeleto szabgab: howdy 16:57
purl salut, dukeleto.
szabgab hi dukeleto
dukeleto we need a new topic, unless it is still saturday somewhere
whiteknight working on it... 16:59
moderator 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:00
whiteknight dukeleto: hackathon went great! Branch isn't 100% still but much closer 17:02
cotto_work good morning 17:03
whiteknight and our bus number on that code is significantl improved 17:04
dalek ose: r178 | Austin++ | trunk/ (14 files):
Object-ified Visitors. Got PrettyPrint.nqp, TypeResolution.nqp working as
 17:07
purl hmmm... visitors is a log analysis app
dukeleto perhaps we should add a link to the pcc_reapply page on the wiki in the topic? 17:08
moritz sure 17:09
dalek TT #1092 closed by jkeenan++: Remove NQP leftovers during 'make realclean' 17:11
moderator half-pie" released! | pcc_reapply branch still needs your love! Let's get that sucker locked and merged! | Testing priorities: pcc_reapply branch 17:11
moderator half-pie" released! | pcc_reapply branch still needs your love! trac.parrot.org/parrot/wiki/Callin...nsOverview | Testing priorities: pcc_reapply branch 17:12
moderator half-pie" released! | pcc_reapply branch still needs your love! trac.parrot.org/parrot/wiki/Callin...nsOverview
dukeleto what about this page? trac.parrot.org/parrot/wiki/Callin...nsTasklist 17:14
shorten dukeleto's url is at xrl.us/bfqjf4
moritz is it linked from the overview-page? 17:16
cotto_work looks like a calling conventions task list of some kind
whiteknight that is THE calling conventions task list 17:19
17:19 hercynium joined
dukeleto i don't think they are inter-linked 17:19
the tasklist is on the front page, the other is not
whiteknight what othre? 17:20
dukeleto trac.parrot.org/parrot/wiki/Callin...nsOverview is not linked to on the wiki home page 17:25
you have to search for it
allison dukeleto: the overview I wrote because people were asking about the whys and hows of what the branch was about 17:26
dukeleto: to help people get started working in ot
on it
dalek ose: r179 | Austin++ | trunk/ (5 files):
Got SymbolResolution visitor working object-style.
 17:35
17:44 bacek joined 17:55 joeri joined 18:00 kurahaupo joined, einstein joined, jsut_ joined
kurahaupo Good morning all 18:01
einstein I just hanged my linux kernel while building my parrot build (containing a bug) :)
whiteknight good morning kurahaupo 18:04
einstein: what rev? in trunk?
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. ;)
The nice thing about parrot hacking is that I'm not likely to hang my system. 18:06
einstein i could retry running it
Tene allison: any luck on fill_results? 18:07
NotFound einstein: it can be just trashing. 18:08
allison Tene: haven't gotten much time to hack on it
Tene: (I've applied the patch, but not made any edits yet)
Tene allison: that's fine. no rush. My morning has been unbelievably hectic.
allison Tene: I know the feeling :) 18:09
Tene It's noon, and I'm still recovering. ><
allison Tene: are you teaching this week?
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
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
NotFound einstein: yeah, but in that case the kernel isn't hanged
einstein: just set a limit to the process memory 18:11
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:12
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
I got that result lots of time testing lua in my laptop, for example.
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
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
whiteknight how do you limit process memory on linux?
NotFound whiteknight: ulimit
whiteknight ok 18:19
NotFound -d The maximum size of a process’s data segment 18:20
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:22
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
thanks for the ulimit info :) 18:25
whiteknight kurahaupo: very negatively :(
actually, we're going to support both styles during the transition
kurahaupo What's the new style going to look like?
whiteknight at least, that's the plan
not exactly sure about all the details. allison and chromatic had talked about it I think 18:26
basically like a normal .sub, probably with a :handles() tag to specify what types and severities of exceptions it handles
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?
whiteknight NotFound: I don't think I understand 18:28
kurahaupo: Subs enter from the top. Coroutines can enter from where they last left off
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?
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
pmichaud I don't think that's the correct avoidance strategy (more)
whiteknight pmichaud: push_eh and pop_eh to specify active handlers, jhust like now
but instead of push_eh a label that is the handler, we push_eh the sub PMC
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
pmichaud whiteknight: so how does the original sub catch the exception?
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?
whiteknight kurahaupo: yes
pmichaud whiteknight: so all registers that you might want to modify have to be lexicals?
kurahaupo err, yes what?
pmichaud whiteknight: what if I need to modify an int/num/str register?
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
whiteknight I don't necessarily doubt that
kurahaupo It seems to me there are not two but three possible outcomes from an exception handler:
(1) not handled, so chain to next handler
(2) have fixed everything, so try operation again
(3) have done a "catch", so skip to some point past where the operation was tried
whiteknight but it's a BIG design issue
pmichaud I keep saying we need a "rollup" primitive 18:34
whiteknight kurahaupo: the handler is the "catch"
pmichaud: never heard of that before. What is it?
pmichaud a way to roll back the call change to a given point
*call chain
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
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
pmichaud NotFound: yes
dukeleto kurahaupo: did you see my comments to your patches on trac?
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
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
whiteknight every exception handler should explicitly resume or rethrow 18:37
pmichaud false
I think there's a third possibility
which is to abandon the path that caused the exception and continue on a new one
that's neither "resume" nor "rethrow"
whiteknight so a "finally" block?
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
pmichaud which means I should be able to resume back to the block that set up the handler
whiteknight yes, or even further up
pmichaud but "resume" also needs an ability to "roll up" intervening contexts
whiteknight or wherever
purl i heard wherever was cheapest
pmichaud that's what we're missing
whiteknight a continuation will do that
pmichaud ...continuations roll up intervening contexts? 18:39
whiteknight at least, I think so. What do you mean by "roll up"?
pmichaud I don't think they do.
okay, here's an example (writing nopaste)
whiteknight ok
NotFound whiteknight: no, a continuation does not abandon inner runllops
whiteknight oh, he's talking about runloops 18:40
no, continuations do not roll those up
pmichaud and contexts as well
some contexts are generated by new runloops, some are not
whiteknight although obviously rolling up a runloop is a priority to add, yes
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)
pmichaud sure
whiteknight the two should be less tightly related
pmichaud regardless, we need a "rollup" operation that allows us to return to a given caller
whiteknight and we should be able to jump up a runloop withou necessarily destroying contexts associated with it
ideally we should never recurse runloops at all, but that's some time away 18:42
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:43
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
jdv79 in the last week did anyone noticed if any of the smoke targets cause any "excessive resource burden"?
dukeleto jdv79: what do you mean? 18:45
jdv79 my smoker too a dive and never came back. not sure if its related.
it never crashed, just buried itself it seems and stayed that way.
nopaste "kurahaupo" at 118.92.156.63 pasted "Three different ways to exit an exception handler" (16 lines) at nopaste.snit.ch/18223 18:46
dukeleto jdv79: a smolder client or server?
jdv79 i'll try restarting the smoking tonight
smolder client
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
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?)?
jdv79 or is it mpeters's?
dukeleto jdv79: yeah, well I run my own smolder server too, so i know about it
jdv79: mpeters'
pmichaud kurahaupo: remove the exception context and any intervening contexts from the return chain
jdv79 that's plural possesive, isn't it?
pmichaud (and invoke the intervening context's "leave" semantics, if they have any) 18:49
kurahaupo So if you had a "leave" section inside a try block, that would be invoked after the "catch" block? 18:50
Or at least, at the point in the catch block where the "roll up" was invoked?
pmichaud: by "exception context", do you mean what would be the containing "try" block in a HLL? 18:51
pmichaud kurahaupo: when an exception handler is invoked, it currently creates a new call frame 18:52
and the caller of that call frame is whatever sub threw the exception
which *isn't* necessarily the sub that defined the try block
kurahaupo Yes. I think we're both agreeing, we need 3 ways to exit from the handler? 18:53
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:54
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
dukeleto masak: good localtime() 18:58
NotFound kurahaupo: better we first make it work, and think about optimizing later. 18:59
dukeleto NotFound++ 19:00
pmichaud it might be useful to consider something like Perl 6:
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.
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.
pmichaud right
whiteknight in that case, we "resume" to a contnuation after the try() block
kurahaupo Have a look at my nopaste snippet
whiteknight but it's still an "invoke a continuation"
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
pmichaud I'll check
whiteknight and if we need to implement a new type of continuation or a subclass of it, we do that
kurahaupo what about visual basic's "on error retry" (or somesuch) ? 19:04
pmichaud have to check in a bit... dinner prep
NotFound whiteknight: if we get rid if the intervening call to invoke the continuation, we can't resume
whiteknight is there currently a way to associate a "leave" semantic with a block?
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:05
whiteknight kurahaupo: no, just the handler 19:07
the exception object will contain information about where to resume to
kurahaupo dukeleto: are you OK with my other patch 1090?
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.
whiteknight at the PIR level we shouldn't need longjmps 19:09
NotFound whiteknight: we need longjmp as long as we have inner runloops
whiteknight NotFound: with sub-based handlers we don' need to care about that 19:10
because the sub executes in the inner runloop entirely, and returns to a place in the inner runloop
pmichaud whiteknight: I'm not aware of a way to associate "leave" semantics with blocks. We really ought to have one. 19:11
the closest thing we have is "pushaction", I think. 19:12
NotFound whiteknight: i fail to see how can that handle all use cases.
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.
whiteknight pmichaud: that sounds a lot like functionality that could be added to the Context PM 19:13
PMC*
pmichaud whiteknight: agreed
whiteknight when the context is executing, see if it has an array of actions and execute them if so
pmichaud the problem is that we need something that triggers "I'm exiting"
whiteknight of course, there is a LOT of design work that would have to go into that
pmichaud that's what the "rollup" needs to do
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
and also to force a caller "n levels up" to exit
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
pmichaud: that sounds like a type of continuation, and I've already suggested that a continuation *should* shut down all intervening contexts
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"
pmichaud right
masak dukeleto: oh hai :)
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
NotFound And BTW, longjmp is a stone in the way to executing things when leaving contexts
whiteknight NotFound: all we need to do is add semantics that an inner runloop ALWAYS calls end
an inner runloop represents an encapsulated subset of program code. Make it correspond to a boundary in PIR. 19:17
Crossing into the new PIR enters the new runloop, and exiting out of that PIR exits the runloop
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
we do not do it that way in PIR, currently
a PIR->PIR thrown exception can jump out of our segment
NotFound Anyway, end or return doesn't signal to a C caller that it must terminate 19:19
whiteknight yes it does. the end opcode returns a NULL pc which ends the runloop 19:20
calls the macro HALT()
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
NotFound: well that's a slightly different issue. runloops don't currently check return values
but they could 19:22
NotFound whiteknight: they could... and probably the only to handle that situation is again a longjmp
whiteknight I don't agree. No longjmps 19:23
NotFound Then we need to change all functions that enter runloops
whiteknight Yes 19:24
which should only be Parrot_pcc_invoke_sub_*
Parrot_pcc_invoke_sub_* checks the runloop return value, and if it contains an exception, rethrows in the current runloop 19:25
but look at the alternatives with sub-based handers: 19:27
1) If code throws an exception that is not handled, parrot exits (regardles of which runloop)
2) if an inner runloop throws an exception, the handler is run in that runloop
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
and we can catch that case easily: queue the continuation, unwind the runloop, invoke the continuation again
Any C stack frames in between get discarded anyway 19:29
so no special handling is needed
19:29 theory joined
kurahaupo ping dukeleto 19:31
purl I can't find dukeleto in the DNS.
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:32
whiteknight NotFound: can't happen. Thrown exceptions are handled in the runloop where they are thrown 19:33
pmichaud huh?
whiteknight exceptions don't cross the boundary, only contnuations do
pmichaud: (not currently, in my fanciful world of sub-based handlers)
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?
whiteknight NotFound: either resumes or rethrows to anew handler
pmichaud "resumes" meaning "continues from the point where the exception was thrown"?
whiteknight (again, with a permissive defnition of "resume")
resume = "continues at a continuation" 19:35
pmichaud which continuation?
(noting that exceptions also contain continuations)
whiteknight the resume continuation (a fanciful construct that doesn't currently exist)
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
pmichaud that would be wrong
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.
pmichaud going back to my original example
whiteknight but with the flexibility that the resume continuation can be directed anywhere
pmichaud can it be directed back to the sub that created the handler?
(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
allison pmichaud: it's a continuation, it can be captured anywhere
pmichaud how does the handler get control back to the sub that created it?
whiteknight exception.'set_resume_continuation'(foo)
pmichaud I understand that part
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
NotFound But how you persuade the intermediate C function to gracefully terminate?
whiteknight reads where it should send control flow to, update the exception, send it on it's way
pmichaud if the handler (in an inferior runloop) invokes a continuation coming from a superior runloop, how do we .... what NotFound said
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
whiteknight NotFound: if we need a longjmp there I won't fight it
NotFound whiteknight: I don't like it, but don't see other way.
whiteknight but that's an implementation detail that Parrot_pcc_invoke_sub can worry about
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.
allison pmichaud: but, it's a lot cleaner to use the known and familiar sub model
whiteknight much cleaner
allison pmichaud: the point is, you can't navigate back into the body of the sub using a label anymore 19:41
pmichaud: that's what's killing us
pmichaud not even with a continuation? ;-)
whiteknight NotFound: What if execution NEVER jumped up to the parent runloop?
when we exit the program, we just exit
allison pmichaud: there's no marker of when the handler actually ends
NotFound whiteknight: stack overflow
purl stack overflow is probably great
pmichaud that's why I think we ought to have an "end handler" opcode or the like
allison pmichaud: it's all just a mess of labels
pmichaud the problem with the handler-as-sub approach is that the handler cannot easily get to the registers 19:42
19:42 darbelo joined
whiteknight however we do it, we need a finite demarcation between "handler" and "everything else" 19:42
a Sub provides that already
allison pmichaud: they can get to the registers through the caller's context
pmichaud and I haven't seen how the sub containing the handler figures out that an exception occurred
allison: (registers through caller's context) okay, that's a new detail I was unaware of
allison pmichaud: same way they do now 19:43
whiteknight pmichaud: if the handler was lexically scoped, you could set a flag
pmichaud whiteknight: that only works for pmc registers
whiteknight or we could try to execute the handler sub in the existing context
allison pmichaud: throwing an exception scans through the set handlers in the context and back the all chain
whiteknight a little tricker but not undoable
pmichaud "execute the handler sub in the existing context" is what happens now with the label-based handlers.
whiteknight pmichaud: yes, but without the "I'm done handling" demarcation
pmichaud allison: I understand how we get the exception to the handler
whiteknight and it's that lack that kills us
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
NotFound What is the "existing"? The one that push_eh, or the one that has thrown?
allison the handler needs to execute in it's own context
(with access to the context where the exception was thrown)
pmichaud I'm fine with that.
it's the "access to the context" part that I'm missing 19:45
wait
no
false
I'm not worried about access to the context where the exception was thrown
I'm asking about access to the context where the handler was created
whiteknight if Contexts are PMCs and ExceptionHandlers are Subs, we can just pass the various contexts in as parameters
:created_context, :called_context, etc
pmichaud ouch
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
pmichaud that sounds like the came issue we had when we had separate Sub and Closure PMCs
*same
allison pmichaud: the context where the handler was created is irrelevant
NotFound I don't think that ExceptionHandler isa Sub is the way to go, I'd like better ExceptionHandler has a Sub
whiteknight the capability exists, all we need to do is find the syntax that is least obnoxious
allison pmichaud: do you mean the context where the handler was set?
pmichaud allison: yes.
whiteknight NotFound: that's an implementation issue, not a design issue
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?
NotFound whiteknight: sure, I was just saying whay way I dislike ;) 19:48
s/whay/what
whiteknight we can put together a wiki page to hash out details
pmichaud I'm asking how to know that the exception was cleanly handled, and how to know how it was handled
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
generally that action is "invoke the resume continuation"
pmichaud and the only mechanism the handler has for communicating back to the "outer sub" is via lexicals or other global symbol channels?
which "resume continuation"? 19:50
the one in the exception, or the one that returns me back to the sub that set the handler?
there are two resume continuations at play
allison pmichaud: the one that was passed in the exception
pmichaud the one that is passed in the exception returns me back to the place where the exception was thrown
NotFound Toooooo much coupling
allison pmichaud: if that's what was requested, yes, but it can go anywhere
pmichaud how do I get the "go anywhere" part? 19:51
that's what I'm asking
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
pmichaud here's an example:
try { bar(); say 'abc'; }; say 'def'; sub bar() { die 'throw'; say 'ghi'; }
bar() is the one that throws the exception
allison pmichaud: it should be an optional argument to throw
whiteknight pmichaud: imagine a "newhandler" opcode that is like a mix between newclosure and push_eh
pmichaud the exception's "resume" continuation is the one that returns me back to bar() 19:52
allison checks
pmichaud that's not the one I want.
allison yes, the two argument form of throw is implemented
pmichaud: you can pass in any continuation
pmichaud how does bar() know which continuation it's to use?!?
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
or where it's supposed to return
allison pmichaud: it's not automatic, it has to be told
pmichaud how?!?
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?
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
particle that's my guess, too
pmichaud it's neither static nor lexical
NotFound The resume continuation is created by throw, the sub that push_eh the handler can't know about it, in general.
particle it's contextual
allison exceptions are neither static or lexical
they're dynamic
pmichaud right
it's the *handler* that knows where it should resume
not the exception, and not the sub that throws the exception
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
allison pmichaud: let me try to echo
pmichaud whiteknight: which is the same as saying that the handler should do the resuming
allison pmichaud: you would like a way to set a resume continuation on the handler when you set it?
(when you set the handler)
whiteknight potato, potato. Internally it happens one way, externally it may look like something different 19:56
the default is that the Exception object has a continuation and knows where to return to
allison so, "I'm setting this handler, if it catches an exception and successfully handles it, I want it to go <here> next"
pmichaud whiteknight: I would rephrase that
whiteknight that continuatin is not read-only and anybody can come along and meddle with it
I wouldn't
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?
particle when building an exception handler, set the resume point.
whiteknight right, and the exception object carries that information into the handler
and the next hander, if it's rethrown
pmichaud whiteknight: correct, I have no problem with that
whiteknight okay. Everything else is just vocabulary
pmichaud vocabulary and definitions matter. :)
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"
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.
pmichaud NotFound: not in the example I gave above
allison pmichaud: you want to write exception handling code outside the exception handler?
whiteknight NotFound: there are only two ways. Rethrow or invoke the resume continuation
allison pmichaud: could you give me a practical example? 20:00
kurahaupo pmichaud: you get <here> next only happens if the exception happened
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".
I'm fine with that.
NotFound whiteknight: Who set that return continuation?
s/return/resume 20:01
whiteknight NotFound: depends
allison pmichaud: sounds like you want asynchronous execution more than an exception handler
whiteknight $P0 = new 'Exception' \\n $P0['resume'] = WhateverIWant
NotFound whiteknight: it doesn't depend, throw sets it.
whiteknight throw $P0
allison pmichaud: i.e. "here's some code, let me know when it executes and return some values"
pmichaud no, that's not it at all.
whiteknight in future parrot, throw only sets it if it hasn't been set already
pmichaud I'm not talking at all about async execution 20:02
let me find an example -- just a moment
NotFound whiteknight: you can't "real resume" in that case, then.
whiteknight NotFound: forget the word "resume" then. Call it something else if the word is a problem
purl whiteknight, I didn't have anything matching word "resume" then. call it something else if the word is a problem
NotFound whiteknight: the word is a problem because it hides the problem. 20:03
whiteknight NotFound: there is no problem!
NotFound Then what are we discussing?
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
whiteknight and throw jumps from normal flow to exceptional flow
pmichaud *that's* what I keep pointing out that you're ignoring
you keep saying there are two, but there are three
NotFound whiteknight: there is no "normal". Either you go back to the thrower, or to the push_eh'd
whiteknight I haven' seen anything different
pmichaud whiteknight: try { bar(); say 'abc'; }; say 'def'; sub bar() { die 'throw'; say 'ghi'; } 20:05
allison pmichaud: I don't see three
whiteknight me either
allison pmichaud: either the exception wasn't handled and you die
pmichaud okay, I'll rephrase
allison or it was handled and you resume *somewhere*
pmichaud whiteknight: try { bar(); say 'abc'; CATCH { $!.resume if rand() < 0.5; } }; say 'def'; sub bar() { die 'throw'; say 'ghi'; }
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
allison NotFound: any given exception handler has only two options
NotFound: die or resume
whiteknight pmichaud: still only two. There's the flow where no errors happen, and the flow where errors happen
pmichaud whiteknight: there's a third.... an error happens, but where we go next depends on a randome number
*random
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
pmichaud it's very different
the "resume" continuation in the exception is different from where we go if we don't invoke it
allison NotFound: the exception handler never decides whether to resume to the thrower or the tryer
whiteknight look at the mechanism: You either have no exception and continue like normal, or you have an exception and go someplace exceptional
pmichaud allison: it does in my example above!
whiteknight how that "someplace" is defined has nothing to do with the mechanism
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)
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
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"
allison pmichaud: I don't see it. which example and I'll try to decipher it with indentation
pmichaud I'll write with indentation
one moment
whiteknight no need for indentation
we're talking about different things
nopaste "pmichaud" at 72.181.176.220 pasted "try example #1" (18 lines) at 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".
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?
pmichaud resumes at the point of the thrown exception
whiteknight pmichaud: and you still don't have a third option, it is still between "resume" and "rethrow"
pmichaud whiteknight: rethrow is a third option here
watch
whiteknight two options: resume, rethrow
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 nopaste.snit.ch/18226
allison pmichaud: always the line after the die?
kurahaupo NotFound: the try block doesn't need a resume point. If it needs one, it can set an additional inner handler
pmichaud isn't the "line after the die" what we normally mean by "resume an exception"?
kurahaupo NotFound: s/try/throw
pmichaud whiteknight: three possibilities
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
allison pmichaud: following a try block is a sensible one
kurahaupo me hears $DAYJOB calling; bye everyone
allison pmichaud: only one for each exception
(but where that one is can vary)
pmichaud whiteknight: do you see my three possibilities yet?
one possibility is to resume after the point of the exception 20:14
one possibility is to rethrow the exception
NotFound kurahaupo: maybe can be done that way, but looks overcomplicated to me.
pmichaud one possibility is to neither resume nor rethrow, but to simply exit the handler and return to the block that set it
"exit the handler" may in fact be "invoke a continuation"
allison pmichaud: the third is "resume" 20:15
pmichaud but it's not the "resume continuation" that was put into the Exception
then what is the first?
allison a curious feature of Perl 6 exceptions
pmichaud huh? 20:16
NotFound allison: is hard to see examples in other languages because few allow resume.
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?"
Tene while we're discussing exceptions...
allison a resumable exception is one that allows the code to continue executing in some way
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
NotFound allison: then C++ has resumable exceptions... don't tell that to Bjarne ;)
Tene you can kind of hack around it by replacing the payload of the exception... but that sucks.
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
moritz from the old quick basic times, "ON ERROR RESUME NEXT"
pmichaud ...line level resume?
allison pmichaud: yes, but it's also why the "throw" opcode allows you to set a different continuation
pmichaud allison: but as in this case, the thrower has no clue 20:18
the thrower can't know how to resume the exception, because that's up to the handler to decide
all the thrower can do is say "if you want to come back here, here's a continuation you can use to do it"
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.
allison pmichaud: well, the compiler can provide any information it want there
this is generated code
pmichaud counter example coming up
nopaste "pmichaud" at 72.181.176.220 pasted "try example #2" (27 lines) at nopaste.snit.ch/18227
20:19 AndyA joined
pmichaud sorry, that should be #3 20:20
#4 coming up
nopaste "pmichaud" at 72.181.176.220 pasted "try example #2" (31 lines) at 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
pmichaud I'm not assuming static scoping here at all
allison pmichaud: the call to bar() from the first try and the second try are two different calls
(with two different call chains)
pmichaud I know that.
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.
pmichaud I'm asking how is the thrower (bar) supposed to know what continuation it's to set?
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
purl okay, allison.
pmichaud wait 20:23
that sentence reads all wrong
in my code, there are no throws statically within the try block
allison I'm saying it's dynamic not static
pmichaud I know that. 20:24
in my example, what is "the thrower"?
I claim it's "bar()"
allison the die statement
pmichaud right
the die statement within bar
okay. The PIR code that gets generate for that is die "throw exception" 20:25
or if we want to be more precise
$P0 = new ['Exception']
$P0['message'] = "throw exception"
throw $P0
(modulo syntax)
correct?
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?
allison depends on how complex your exception semantics are
pmichaud in the above case
to me, creating a try block is "push_eh" 20:27
allison you could do that
you could also do something similar within the handler
pmichaud the thing that I push is a handler
in my example, I'd be pushing the CATCH block
i.e., the CATCH block is my handler
because that's where control goes when an exception is thrown
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.
pmichaud it will in what you're describing though, yes?
if all handlers are subs
handler == sub implies "new scope"
allison technically, at the moment, every block is should be a sub
pmichaud correct
no problem
allison anything less is fudging
(though fudging can work) 20:29
NotFound: exceptions thrown from C can't resume anyway
20:29 theory joined
pmichaud allison: "can't resume" there doesn't match your definition of resume above 20:30
this is what I find difficult to understand
20:15 <allison> pmichaud: the third is "resume"
allison NotFound: which, oddly enough is one thing I find compelling about the possibility of resume continuations on handlers instead of exception objects
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
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
pmichaud we can't catch C exceptions at all?
allison pmichaud: sure we can, and we run the handler
the handler decides what to run next
pmichaud and all that the handler can do is rethrow then?
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"
but if C exceptions can't resume, then we can only rethrow
I have to leave for 15 mins to pick up kids
bbi15
allison I should be more semantically precise 20:33
C exceptions can't "line-level" resume
NotFound That shows that we have 3 cases, not 2 20:34
GeJ Good morning everyone 20:36
cotto_work hi GeJ 20:37
GeJ Hi cotto
pmichaud "semantically precise" is what I've been asking for here, yes. 20:39
so my three possibilities are: 20:40
(1) rethrow the exception (to another handler)
(2) return to the point where the exception was thrown ("line-level resume")
(3) return to the sub that created the handler 20:41
you're saying that (3) could in fact be "return to anywhere"
I'm fine with that
but the point is that whatever information is in (3) doesn't belong in the Exception object
the Exception object should have the information for (2)
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:42
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
Either 2 or 3.
pmichaud correct
granted, a handler could replace the Exception's line-level resume continuation with one of its own 20:46
but in that case, it's the handler that is setting the resume point, not the thrower
allison pmichaud: yes, I'm saying that 2 and 3 are "return to anywhere"
pmichaud formulating a new code-based question.... 20:47
actually, it's a one liner: 20:48
suppose I have try bar(my $a = 5);
i.e., I'm doing a try operation but not introducing a new scope
how should that look in PIR?
in this case I'm not interested in doing anything with the thrown exception except ignore it
currently I would do: 20:49
push_eh label
# code for bar(my $a = 5)
pop_eh
er,
starting over
push_eh label
# code for bar(my $a = 5)
label:
pop_eh
... rest of block here 20:50
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
pmichaud no
allison you want an.... "anchor"
which a second continuation can provide
pmichaud okay
fine
so how do I do that? speculation is fine.
note that my "handler" in this case is empty
and it's actually irrelevant to the fact that I need to resume at a label 20:52
I'm asking about the "resume at a label" part
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?
pmichaud I think the answer is "yes" but I don't see how it applies here 20:53
I have to pick up another kid, bbi10
allison pmichaud: well, that would be a handler that only resumes at a given point 20:54
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? 20:58
Tene Hehe, I love the logwatch messages I get after a night of parrot hacking. :D 21:01
WARNING: Segmentation Faults in these executables
parrot : 29 Time(s)
WARNING: General Protection Faults in these executables
parrot : 12 Time(s)
pmichaud okay, after driving a bit, here's my current guess 21:05
$P0 = new ['ExceptionHandler']
.const 'Sub' $P1 = 'myhandler'
$P0.'set_handler'($P1)
$P2 = new ['Continuation']
set_addr $P2, label
$P0.'set_resume'($P2) 21:06
push_eh $P0 # set handler
# code that might throw an exception
label:
pop_eh
$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:08
note that the sub to be invoked has at least three options available to it by default 21:09
(1) it can line-level resume using the continuation stored in the caught exception
(2) it can rethrow the exception to a different handler
(3) it can resume using the continuation given to it when it was created 21:10
NotFound I like that way
pmichaud it can of course resume to any continuation it wishes, but these are the three common cases
NotFound And (3) can be invoked just by returning from the sub 21:11
pmichaud I'm not sure about that part
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.
pmichaud correct
and for (3) we need it to "roll up" any intermediate inferior loops
if invoking a continuation does that, that's great.
NotFound Set a continuation that is set_addr has been used go for it, and if not dies horribly.
21:13 joeri left
NotFound s/is/if 21:13
ExceptionHandler can be a Continuation that does that when invoked. 21:14
pmichaud not exactly 21:15
rolling up occurs at the end of the handler, not at the invocation of the handler
because we might line-level resume
NotFound In the current implementation, yes, but the invocation of the sub handler can be done other way than VTABLE_invoke. 21:16
pmichaud regardless, we can't throw away the intermediate runloops until the handler exists 21:19
*exits
NotFound Yes
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:21
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
pmichaud please not 'TryBlock'
not all try invocations are blocks
handlers might be blocks, but some try invocations are not
really we're creating a handler, not a try block 21:25
a try block is what is in effect between the push_eh and pop_eh opcodes
NotFound pmichaud: but if we say that the sub handles the exception, calling 'Handler' to the other thing is confusing
pmichaud Handler is an object that describes how an exception is handled 21:26
that object can be a sub, or it can contain a sub (equivalent design choices)
Handler could also be a continuation that contains a sub
but that's semantically weird, the names will confuse people
NotFound allison: What point? 21:28
purl well, point is if the drive dies
dukeleto google-opensource.blogspot.com/2009...rrots.html
shorten dukeleto's url is at xrl.us/bfqku7
dukeleto The Perl Foundation and Parrot Foundation are on the Google Open Source Blog. w00t
allison NotFound: any random point in the code can be a continuation
NotFound allison: yes, but random points in the code usually don't look at the ExceptionHandler active chain. 21:29
allison NotFound: I think you mean the reverse "ExceptionHandlers don't usually look at random points in the code" 21:30
NotFound Both 21:31
allison the first doesn't make any sense
pmichaud the thing that creates the ExceptionHandler is likely the thing that needs to be able to set the resume point
in this case, the "try" statement
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:32
If other parts of the code want to set another continuation, they push_eh his own ExceptionHandler 21:33
We can make an overgeneralized mechanic, sure. But I don't whink we want. 21:34
nopaste "pmichaud" at 72.181.176.220 pasted "Continuations do not currently resolve the inferior runloop problem (for whiteknight)" (134 lines) at nopaste.snit.ch/18230 21:35
pmichaud (for scrollback)
whiteknight: 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
pmichaud NotFound: why a special purpose Continuation, though? shouldn't all Continuations do that?
NotFound pmichaud: good question 21:37
purl Yeah, it is. I'm stumped.
pmichaud and if we do need a special purpose Continuation for that purpose, I suspect it's "RetContinuation" :)
or something like it. 21:38
NotFound Mmmm... I think no, no, that way wil
dalek tracwiki: v23 | cotto++ | PMCUnionDeprecationTasklist
tracwiki: add a note that this task is complete
tracwiki: trac.parrot.org/parrot/wiki/PMCUni...ction=diff
shorten dalek's url is at xrl.us/bfqkyc
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
NotFound Mmmm... I think no, that way wil kill runloops just by invoking a sub
Maybe not any sub, but a coroutine for example. 21:40
allison Continuations don't pay any attention to the C runloop, and they shouldn't 21:46
pmichaud: and, runloops aren't the primary problem with the current exception handlers 21:47
pmichaud allison: what is the primary problem?
purl rumour has it the primary problem is power
allison pmichaud: encapsulation
purl encapsulation is not letting the data be modified directly; that is providing mutator methods and whatnot
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
(as simple labels) 21:49
but, it's a poor result
pmichaud at this point I have no problem with switching to something else
but the discussion of changing the current model is based on TT #1091
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
i.e., that's the problem that led to today's conversation
allison it marks it as "most notably" but doesn't really go into much detail
pmichaud sure. but it's the source of today's conversation :) 21:51
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?
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)
allison but the move to exception handlers as subs has been pending for a couple of years now
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
well, nothing except for never dropping out into C code
pmichaud can I attach those two comments to the relevant tickets? 21:54
allison (hence some of the push for Lorito)
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
allison yes, we can eliminate segfaults 21:55
NotFound allison: I think that for the particular case of ExceptionHandler it can.
be solved
pmichaud and stack overflow, also?
allison we can improve the way we deal with inferior runloops
pmichaud okay, I think that's been today's discussion
allison but inferior runloops themselves aren't the problem
Parrot actually deals with them pretty transparently 21:56
pmichaud except for exceptions :)
and continuations from within vtable subs
allison the tricky part about the current exception handlers is that there isn't a clear point for the inferior runloop to terminate
NotFound I'm testing an idea... one moment... 21:57
pmichaud allison: right, agreed.
allison if exception handlers were subs, then the inferior runloop would terminate when the sub terminates
clean and simple
pmichaud allison: why/how?
I mean, what's the mechanism to terminate the inferior runloop? 21:58
allison the inferior runloop is started to execute the sub
to execute the handler
(to be clearer)
pmichaud but the sub has to invoke a continuation to get back to the label set for the handler
note: the resume label, not the handler label
nopaste "NotFound" at 213.96.228.50 pasted "Avoid inner runloops in exception handling" (18 lines) at nopaste.snit.ch/18231
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
pmichaud NotFound: sure we do....
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
pmichaud NotFound: I think we can create some tests
allison: I'm a little confused... just a sec 22:01
allison: in 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
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
NotFound But the runloop can be already created, for example by a pir overriden vtable call 22:04
allison pmichaud: that inferior runloop seems to be something other than an exception handler, the signature is P->I 22:05
pmichaud: most inferior runloops are short-lived 22:06
pmichaud: they're called, they run the code, they return, they end
NotFound And Parrot_ex_throw_from_c doesn't create a runloop, it longjmp to the push_eh context runloop
22:06 Whiteknight joined
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
NotFound allison: that was me 22:08
allison I also vaguely remember sighing "more longjmps" then too :) 22:09
Whiteknight hello again
allison but, that goes away if exception handlers are subs
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)
NotFound: the longjmp is unnecessary in from_op, it can just make the exception handler the next instruction in the current runloop 22:11
that's why the variant exists
NotFound allison: I don't like longjmp, but the current way gives no other option.
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.
allison the problem wasn't terminating the runloop of the exception handler
it was with resuming into the context where the handler was set 22:14
Whiteknight is usually by himself in left field
NotFound The problem IMO is terminating all runloops created between the push_eh point and the throw point.
allison instead of creating a new context for the handler
which is a problem that making exception handlers subs really will fix
NotFound Well, runloops and contexts et al, but now that contexts are garbage collected that's not a problem. 22:15
allison NotFound: maybe runloops should be garbage collected :) 22:16
NotFound allison: yes, we just need a C compiler that handles that ;)
allison maybe runloops should be PIR subs instead of C functions
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
pmichaud I don't understand how making exception handlers into subs will fix the problem 22:21
could someone patiently walk me through it? 22:22
Whiteknight pmichaud: sure!
allison pmichaud: the problem of handlers needing to run in their own context?
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.
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:23
pmichaud allison: I don't have a problem with the idea that handlers run into their own context 22:24
*in
that part I understand
but when a handler needs to resume to its outer sub... I don't see how that happens
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
pmichaud: gotcha
pmichaud Whiteknight: you weren't here for my comments while you were out of line
er, offline 22:25
just a sec
cotto_work dukeleto++'s writeup of TPF and Parrot's GSoC projects is on Googles open source blog
google-opensource.blogspot.com/2009...rrots.html
shorten cotto_work's url is at xrl.us/bfqku7
pmichaud 21:36 <pmichaud> whiteknight: 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)
cotto_work (nothing surprising, but good pr)
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
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
Whiteknight NotFound: runloops don't need to be preserved because we can't preserve C stacks state
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
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
Whiteknight pmichaud: but such a mechanism could be added, so long as we limit the number of cases where it happens
pmichaud Whiteknight: I'm fine with that.
Whiteknight a very general solution is difficult, but if it's just continuations trying to bridge the gap, that's fine
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
pmichaud but whatever mechanism gets used for that could also be used for our existing ExceptionHandler implementation (more)
Whiteknight NotFound: there are lots of implementations for it
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
Whiteknight pmichaud: adding that functionality to our existing exceptions implemetatin will be VERY difficult 22:30
not impossible, but hard
pmichaud not at all
if you can solve it for continuations at any level, you can solve it for this one
if nothing else, introduce a new opcode that does the longjmp
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
NotFound We alredy can use longjmp, the problem with the current implementation is to know when we can do it.
pmichaud the handler can know when to do the longjmp
it doesn't have to be automatic
22:31 japhb joined
Whiteknight Right, ExceptionHandlers need to have a record of the runloop_id where it was created 22:31
which means runloop_id needs to be unique
pmichaud actually, I think it needs the runloop_id of whatever its return continuation is going to be 22:32
which might not be the same as where it's created
or the same as where it's established as an active handler
Whiteknight can't be. C stack state is tied to dynamic execution state 22:34
to avoid inferior runloops, the handler MUST be executed where it was defined
22:34 theory joined
Whiteknight otherwise there is a mismatch between dynamic state and C state 22:34
pmichaud wait
the handler is a separate sub now, right?
oh, I see your point
fair nuff
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
pmichaud "where it was pushed" is the handlers continuation, if using push_eh label
if using push_eh $P0, then the continuation could be somewhere else entirely 22:36
(i.e., then it would be using set_addr)
at any rate, since I'm not implementing any of this I guess I should shut up now. 22:37
thanks for the explanations.
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.
actually, wait, I have another question
(sorry)
in today's Parrot 22:38
I create a handler using push_eh label
NotFound pmichaud: yes, but I think the runloop involved will be always the one from the push_eh point.
pmichaud I call some stuff that creates an inferior runloop that throws an exception
that exception ends up invoking my handler
what runloop is currently running my handler?
the inferior one, yes? 22:39
NotFound pmichaud: the problem is the runloop to return, not the actually running the handler.
pmichaud NotFound: yes, I agree.
the answer to my question is "yes" then, correct?
NotFound pmichaud: yes
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?
i.e., if a continuation can do it, why can't an opcode?
NotFound I think the only problem is to remember to use it.
pmichaud or, if not an opcode, a method.
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.
Not a big problem, anyway.
22:43 ruoso joined
pmichaud "lot of tests to fix" not really 22:43
existing code would continue to work as it does now
with the potential segfault
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.
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
NotFound pmichaud: yes, but tests that are currently todoed or skipped.
22:45 tetragon joined
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-)
pmichaud okay, I'm satisfied for now then. Thanks. :) 22:46
22:51 kthakore joined
Whiteknight (sorry i disappeared again) 22:53
I have a bad habit of doing that
darbelo Is anyone else seeing failures in t/examples/pir.t ? 22:54
kthakore darbelo: thanks man I am now :( 22:56
let me update 22:57
NotFound darbelo: just a TODOed one for me.
22:57 cconstantine joined
NotFound Eh, no one, two. 22:57
darbelo Hmm. I have two TODO failures (17 and 18) 22:58
And a failure in test 9
dukeleto darbelo: can you nopaste the failures ? 22:59
nopaste "darbelo" at 200.49.154.173 pasted "failure in t/examples/pir.t" (13 lines) at nopaste.snit.ch/18232 23:00
darbelo I spent about a hour chasing that sucker before noticing it still failed without my changes. 23:01
dukeleto darbelo: this happens in trunk? 23:02
darbelo dukeleto: Yep. OpenBSD i386 trunk.
dukeleto darbelo: that is for t/examples/pir/io.t, BTW
darbelo: i thought you were talking about t/pir/*.t, sorry, I don't know what that is about 23:03
kthakore darbelo: error:imcc:syntax error, unexpected IDENTIFIER, expecting $end ('use') 23:04
I get that
darbelo kthakore: Can you nopaste the output of prove -v t/examples/pir.t ? 23:05
kthakore ok
whats the nopaste link again?
first time on here
darbelo purl: nopaste?
purl nopaste is, like, at nopaste.snit.ch/ (ask TonyC for new channels) or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others) or gist.github.com/ or paste or gtfo or tools/dev/nopaste.pl or trac.parrot.org/parrot/browser/tru...nopaste.pl
darbelo nopaste.snit.ch/parrot
kthakore ok 23:06
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 nopaste.snit.ch/18233 23:08
kthakore done
do you want make test output?
dukeleto kthakore: there is a command line script to post to nopaste, tools/dev/nopaste.pl in the parrot repo
kthakore oooh
thats so cool
23:08 PacoLinux joined
Whiteknight dukeleto++ # GSOC blog post 23:09
kthakore so cmd > tools/dev/nopaste.pl ?
dukeleto Whiteknight: thanks
darbelo kthakore: "prove -v" not "parrot -v"
kthakore ah
sorry first time using parrot and not rakudo
ok
dukeleto kthakore: cmd &> cmd.out && nopaste -t "my title" cmd.out
kthakore ok
thanks dukeleto 23:10
dukeleto: I don't have nopaste.pl in tools/dev 23:11
I got latest svn
dukeleto kthakore: it is there for me, you sure? 23:12
kthakore yup
did svn up
nopaste "kthakore" at 99.234.159.149 pasted "prove -v t/examples/pir" (28 lines) at nopaste.snit.ch/18234 23:13
kthakore ok dukeleto still don't have it but I gotta go back to #sdl
darbelo: its up there
hope it helps
kthxbye
dukeleto kthakore: trac.parrot.org/parrot/browser/tru...nopaste.pl 23:14
shorten dukeleto's url is at xrl.us/bfqmdb
kthakore thanks
nopaste "darbelo" at 200.49.154.173 pasted "Remove 'fake' STRING from Parrot_io_flush_buffer()" (30 lines) at nopaste.snit.ch/18235 23:15
Whiteknight hasn't even looked at trunk in days
dukeleto Whiteknight: that is good. make believe it doesn't exist and keep hacking on pcc_reapply :)
darbelo Can someone test nopaste.snit.ch/18235 please? OpenBSD has gremlins in it's io. 23:16
cotto_work darbelo, Ubuntu/x64 is happy 23:20
dalek rrot: r41729 | coke++ | trunk/DEPRECATED.pod:
fix deprecation notices.
darbelo Good enough for me. cotto++ 23:24
23:27 kthakore left
dalek rrot: r41730 | darbelo++ | trunk/src/io/buffer.c:
Remove 'fake' STRING from the Parrot_io_flush_buffer() function.
 23:27
Whiteknight allison, Tene: ping!
Tene Whiteknight: PONG
Whiteknight Tene: any progress on the returns passing code?
Tene Whiteknight: I'm just about done with work for the day, and then i have some errands to run. 23:28
AKA... no.
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.
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.
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.
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.
Whiteknight We looked at the code and had the patch set 23:31
but no, I didn't know enough to make it work in place
Tene I have no objections. I would have reverted it too.
I just wanted to get it out there somehow so it was recorded.
darbelo Tene++ # going on the record :) 23:32

Powered by Cro and the Raku® Programming Language.

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

Thank you!