weekly meeting at 18:30 UTC, Tuesday | logged at irclog.perlgeek.de/parrotsketch/today
Set by moderator on 30 September 2008.
05:49 TimToady joined 10:58 tewk_ joined 13:14 particle joined 15:48 davidfetter joined 17:31 allison joined 17:39 pmichaud joined 17:48 rdice joined 18:14 cotto joined 18:16 cjfields joined 18:21 masak joined 18:23 NotFound joined, jhorwitz joined 18:24 moritz joined 18:26 kj joined 18:27 Croke joined 18:28 chromatic joined
pmichaud hello. 18:30
NotFound H
kj hiya
moritz hi
jhorwitz yo
chromatic greetz
Tene OHAI
cotto ohio
masak salut
spinclad
.oO( ho from peanut gallery )
 18:31
chromatic Let's go in order.
Though I see no allison.
I... fixed some bugs.
I'm working on some segfaults, and hope to clear those up in the next day.
allison hi
particle hi-o 18:32
davidfetter hai
chromatic I have a patch against Test::More that's almost finished. It may require some changes in other PIR tests, because it's more accurate now.
That's it.
allison?
allison - Started the I/O branch.
- Did a code review of the I/O subsystem and expanded the I/O milestone tasklist with more details. (www.parrot.org/wiki/io-tasklist)
- Finished an initial draft of the FileHandle PMC, and some of the core C files for the subsystem.
- Worked on closing more MMD tickets.
EOR
chromatic Croke? 18:33
Croke started to work on partcl, sidetracked by a GC bug:
and then 2 more. opened tickets for all three. no actual progress, however.
EOR
chromatic davidfetter? 18:34
davidfetter still too lazy
EOR :(
chromatic japhb? 18:35
japhb chromatic: nr
tewk_ vi
18:36 PacoLinux joined
chromatic jhorwitz? 18:36
japhb (catching me actually at my desk in this time period is a fluke, by the way -- I'm only around for logs and questions)
jhorwitz helped chromatic++ debug segfault with "use Foo::Bar", which unblocked mod_perl6.
partial implementation of mod_perl6 method handlers, but blocking because i can't pass flattened args to a sub in rakudo yet.
writing pure-perl6 versions of Apache::Const, Apache::RequestRec, etc.
brainstorming for a tutorial on writing an HLL layer for mod_parrot
EOR
chromatic kj? 18:37
kj == work on PIRC
* integrated the macro processor into pirc lexer (no separate specification)
* integrated the heredoc preprocessor into pirc executable (still separate specification)
* works very nicely
== other
<<EOF>>
chromatic masak? 18:38
masak - haven't done anything to decrease ticket count during the past week
- increased it a bit, though
- went into a Rakudo bug hunt/reporting spree during weekend
- also failed to build Parrot and reported that, #60178
- so far fails only on my machine, so I will investigate further
EOR
chromatic moritz? 18:39
moritz fighting troubles with the server on which the #perl6 evalbot runs on, no time for much more.
EOR.
chromatic NotFound?
NotFound - Some fixing and cleaning
- Working in some EH problems
- A question about that
EOR 18:40
chromatic particle?
particle ~ attended gsoc mentor summit. it was of great benefit. i'll write up a use.perl post about it when time permits.
~ all my tuits since the release are now devoted to the parrot developer summit
~ looking forward to it, an to someday getting back to hacking
.end
chromatic pmichaud? 18:41
pmichaud ** Rakudo spectest_regression: 206 files, 4433 passing, 2 failing
== Parrot stuff
: started new 'lex' branch to work on new lexicals implementation
: eliminated the Closure PMC -- all Subs can have outers
: implemented capture_lex opcode, updated newclosure opcode
: currently 16 failing core tests, most due to needing "autoclose" semantics
: two options:
--> 1. eliminate autoclose from Parrot entirely (and tests)
--> 2. design sane autoclose semantics
: I'm currently working on #2 in the branch
: Found/fixed a number of issues with adding/removing opcodes
: Added various comments to tickets and discussions
== Rakudo stuff
: Commented and provided notes on lots of tickets and patches
EOR
chromatic Tene? 18:42
Tene I have negligible memory of the past week. I don't see any commits in the repo from me, so I don't think I did anything.
EOR, I guess
chromatic tewk_?
tewk_ * Fixed consting of strings in the nci_info struct.
* The only jitted NCI failures left involve t/pmc/threads.t
* Going to try to ncigen parrot headers, haven't done that yet.
* Going to look at the IO branch, I like doing IO work, I don't know why.
EOR
chromatic Did I miss anyone (besides cotto, who had no report)?
Question time. 18:43
NotFound, go ahead.
NotFound RT#60166
Some opcodes use throw_from_c_args, for convenience of the _args part. 18:44
Is cretaing the function Parrot_ex_throw_from_op_args a correct solution?
creating 18:45
chromatic Seems sane to me.
Tene I endorse it.
allison well, that's for creating an exception from C arguments 18:46
chromatic It seems like there are two behaviors. 18:47
allison (going back and reading the ticket)
NotFound allison: yes, that is the problem. When used from an opcode, it enters a new runloop for no benefit.
chromatic One is which runloop to use to dispatch the exception and the other is how you pass arguments to it.
allison on the exact subject of the ticket, exception handling isn't supposed to unwind the stack
pmichaud the notion of "unwind stack" bothers me. 18:48
what allison just said.
there's an assumption that activating an exception handler should remove it from the list of handlers, and that's not true
i.e., I'd claim that the code in the original is wrong. 18:49
NotFound The problem in that case is that it enters a new runloop from C, growing the C stack.
pmichaud (it's current practice, but not current design)
allison NotFound: yes, that's expected
NotFound allison: but no need to do that from an opcode.
pmichaud as far as entering a new runloop from C, that sounds more like a different ticket.
(looking up that different ticket now) 18:50
allison (pulling up the code for find_method)
NotFound find_method is just an example, a lot of opcodes does the same 18:51
particle pmichaud: the 'inferior runloop' ticket?
pmichaud particle -- the one I posted an update to last week. 18:52
(rt is very slow today)
NotFound allison: here are yesterday's tests: nopaste.snit.ch/14406 18:53
pmichaud RT #59778 18:54
allison NotFound: okay, I see where you're going now (after poking through the code)
Croke (inferior runloop) another IR ticket at #57088, though it's a different symptom. 18:56
allison NotFound: okay, let's add 'Parrot_ex_throw_from_op_args'
NotFound This is not a general solution for inner runloops problems, is for some particular cases. 18:57
allison NotFound: abstract the exception building code from 'Parrot_ex_throw_from_c_args' into a separate function
yes, this isn't about runloop problems
it's just a matter of using the appropriate function in the appropriate place
the 'throw_from_op' variants return an opcode_t 18:58
allowing for clean continuation of the runloop
NotFound allison: ok, i have it almost ready and applied to the majority of opcodes, will finish and commit it today.
EOQ 18:59
pmichaud my guess is that Parrot_ex_throw_from_op_args doesn't completely resolve the stated problem in RT#60166, though.
each iteration of the loop is adding another exception handler that is never reclaimed. 19:00
(i.e., memory leak)
allison pmichaud: yes, that is a problem in the code example
NotFound pmichaud: this is an ortogonal problem IMO
pmichaud NotFound: I agree it's orthogonal, but it's also the one stated in the ticket title. 19:01
allison and, it's not a problem of the same size as it used to be
since exception handlers are now local, they will all be cleaned up on scope exit
pmichaud fair enough. I just think we need a note somewhere that says "this is not the way to do this."
NotFound pmichaud: yes, but I think it will be easier to analyse after the change.
allison (so, we've at least contained the damage of poor coding practices)
yes, agreed, that should go in a tutorial 19:02
particle it should go in the PDD 19:03
*AND* a tutorial
allison well, there are contexts where you *want* to create a new exception handler on every iteration through the loop 19:04
this is more about usage
and understanding the consequences of using particular features
pmichaud imo, it's that most of us have assumed that invoking an exception handler causes it to be removed from the list of handlers, which is not the case. 19:05
allison pmichaud: it used to be the case
pmichaud correct.
we need to update the docs to indicate the correct usage, and provide some examples, and convert existing code to the correct usage 19:06
right now I'm not entirely certain what the correct PIR would be for creating an exception handler on every iteration through a loop
allison it was still the case when the exceptions branch was merged in, I'd have to look at the code to see what it's doing now
NotFound What I do in pirric runloop is creating the EH one time, and creating again when handling a control flow exception. I'm not sure is a correct way. 19:07
pmichaud that creates a new handler on each exception, as opposed to each iteration. 19:08
Tene allison: it's still behaving the same unless a type or severity filter is set.
pmichaud (in current implementation)
allison Tene: we should probably be consistent and either always remove it or never remove it 19:09
Tene I haven't removed the "only invoke once" code yet because I haven't felt up to tryint o track down everything that can currently break.
allison Tene: we're working towards the "never remove" direction, but that will involve more code changes
Tene I left it at "only invoke once" for the case where no filters are set to avoid breaking old code. 19:10
pmichaud I'm in favor of never remove
at least, never remove automatically
that *is* in fact what is happening now. :-)
allison pmichaud: yes, that's what's currently spec'd, but not what's currently implemented (last I checked)
Tene I can nopaste the relevant patch for you if someone wants to work on it.
pmichaud what's currently implemented is that the handler is disabled (but not removed)
allison Tene: make it an RT ticket
pmichaud (if I read the code correctly.)
allison pmichaud: yes, that's accurate 19:11
pmichaud: it was a cheap way of mimicing the old behavior
pmichaud so really what we're talking about is turning off "auto-disable"
allison pmichaud: yes, the auto-disable feature was only put in place to support legacy exception code
pmichaud allison: correct. So, we ought to be able to go ahead and move existing code to the "assume the handler is already there" without any code changes 19:12
sorry, that was unclear
we should be able to migrate legacy PIR code to work assuming the handler remains present without having to change the underlying exception system
allison pmichaud: yeah, should be possible
NotFound A .get_results variant that removes the handler can be useful.
allison pmicaud: the main thing it involves is having exception handlers check to see if the exception they're getting is one they can handle, and rethrowing if they can't 19:13
pmichaud I don't think we have any legacy code that depends on this
allison it's basically a mini preamble to every handler
Tene adding a type or severity filter should be more appropriate than rethrowing. 19:14
That's what the 'can_handle' check is for.
pmichaud what we're really looking at is any exception handling code that assumes the handler is automatically pop_eh'd should explicitly do a pop_eh.
allison pmichaud: the problems I was getting before I added auto-disable were segfaults from exception handlers that were trying to handle exceptions they didn't know what to do with
Croke can we define our own exception types at runtime, or declare that we handle only a specific exception class?
NotFound But in label handler there is no way to add a can_handle 19:15
Tene the other problem is if code in an EH throws an exception.
allison pmichaud: that is, the first handler wouldn't be removed, and another exception would be thrown and passed to the first handler again
Croke (if not, then we're still going to need to catch and rethrow)
pmichaud allison: correct -- however, we can change the legacy code so that the first handler is removed (explicitly, not automatically)
allison pmichaud: yes, that's true, the handler could do 'pop_eh' as a quick fix 19:16
pmichaud to date there's been no official word that this is in fact what handlers are supposed to do.
allison pmichaud: In general, handlers shouldn't do 'pop_eh'
handlers should just handle the exception
chromatic How would a handler know which EH is on top of the stack?
Tene exactly
allison the calling code is what decides the scope of the handler
NotFound Croke: you can inherit from ExceptionHandler and add a can_handle method 19:17
allison think of it like a 'try' block
pmichaud ....then how should handlers get removed (in the case of creating a handler for each iteration, for example)
allison push_eh is the start of the 'try' block, and 'pop_eh' is the end of the block
Tene Croke: propose an API for setting class-based filters and I'll implement it.
Croke: if you can provide some example PIR, even better. 19:18
I've heard several times that we want to support that as well.
Croke Tene: very low on my list of priorities.
Tene Croke: would .handle_classes work for you? 19:19
allison pmichaud: I suppose what we're really missing is scopes smaller than a subroutine
pmichaud I understand that push_eh is conceptually the start of a 'try' block, and pop_eh is the end of the block. But when/where should pop_eh be done if a handler block is invoked?
allison pmichaud: in a real 'try' block, the handler would be cleared at the close of the block scope
(because handlers are always stored in a scope)
pmichaud: but here, they won't be cleared until the close of the subroutine scope 19:20
pmichaud so, if we're looping over a try statement, we'd end up clearing all of the handlers when the outer loop exits?
allison pmichaud: I mean, ideally, the 'pop_eh' opcode goes away, and handlers are just cleared on scope exit
pmichaud: but that does mean refining our implementation of scope 19:21
pmichaud: (which we probably need to do anyway, but perhaps not before 1.0)
pmichaud okay. I'll leave it here, with a request that we see the "best practice" for creating handlers within a loop. 19:22
s/see/publish/
NotFound So a way to avoid this problems in pir is to enclose the conceptual try/catch block in an inner sub?
allison pmichaud: looping over a try block would (ideally) clear the handler each time through the loop, since 'try' is its own scope
pmichaud I have my own thought on this at the moment, which I can publish to the list.
spinclad (next iteration, EH becomes inaccessible when new EH bound to its name: collect it then?)
pmichaud allison: would 'try' have to be its own scope in every language?
allison: (yes, it's that way in Perl 6, but I can imagine languages where 'try' doesn't modify scope.) 19:23
allison pmichaud: not necessarily, ('try' its own scope) Parrot would just provide EH features and scope features. Different HLLs can combine them any way they want.
that is, if you want try to be scoped to the whole subroutine, just don't wrap it in a smaller scope 19:24
pmichaud I'm simply talking about the case where try doesn't introduce a scope that the handler is attached to (and would be cleared from).
allison spinclad: actually, it becomes inaccessible at the end of scope, so GC'd at the next sweep 19:25
NotFound: yes, enclosing a try/catch block in a sub would work for now, but a bit expensive for long-term
spinclad (good)
allison pmichaud: the two are orthogonal features 19:26
pmichaud spinclad: notice that it's inaccessible at end of sub scope, though, not when the new EH is created
allison pmichaud: push_eh (or whatever), simply adds an exception handler to the current scope, whatever that scope is
spinclad (end of scope: end of sub, then, not end of try or loop scope)
pmichaud allison: and if try is being iterated 1e6 times within the current scope, we end up with 1e6 handlers? 19:27
allison pmichaud: languages that want a specific scope for 'try' emit the code for marking off a scope (which is completely hypothetical)
pmichaud: yes, because you could be creating a completely different handler each time, based on code within the loop 19:28
NotFound A quick test with RT#60166 example shows that with a pop_eh it does not leak (or at least, it leaks a lot less)
allison pmicaud: that is, the handler could be eval'd code
but, you can always put the 'try' block outside the loop
pmichaud allison: that would be different semantics, however.
allison pmichaud: yes, it would resume after the loop 19:29
particle at this point, is seems more appropriate for the mailing list.
unless there are no other questions
pmichaud NotFound: that's what I expected, and what I'm likely to write to the list (i.e., always do a pop_eh for every push_eh) 19:30
allison yes, mailing list it is
(this is largely hypothetical futures we're talking at this point)
pmichaud (except that it occurs in reality in #60166.)
NotFound However, with a .get_results added it leaks a lot.
allison pmichaud: yes, the immediate answer is "don't do that", but there are definitely some more refined tools we could give HLL developers in the future 19:31
pmichaud allison: I'm simply saying that the immediate answer ought to be "don't do it that way, do it this other way instead" 19:32
where "this other way" isn't well defined yet.
or "this other way" could be "...and Parrot doesn't support that yet."
iterating over exception handlers is very common and very important at the moment: next, last, redo 19:33
so it's not even completely hypothetical.
in fact, I'll say it's not hypothetical at all. 19:34
allison pmichaud: in theory, what should happen now is that the successfully handled exception should resume, and go on to the 'pop_eh', which is the next instruction after the one that threw the exception
pmichaud "and go on to the pop_eh" is effectively the same as saying that the handler resumes at the pop_eh, yes?
i.e., within a Parrot sub, the handler could fall-through to the pop_eh? 19:35
chromatic I'm not sure that can work for control flow exceptions.
allison pmichaud: effectively, but if there was another statement between the one that threw an exception handler and the 'pop_eh' it would resume at that one
pmichaud: if the handler *doesn't* resume, or continues at some other location, they, yes, it should take responsibility for the 'pop_eh' it skipped 19:36
s/they/then/
pmichaud I guess what I'm saying is that handlers should not assume that they are automatically removed from the list. Whatever creates the handler should also make sure the handler is removed (if not being automaticallyremoved by scope exit)
rephrasing
scopes that create handlers should not assume that the handler is automatically removed when it is invoked.
allison pmichaud: yes, entirely agreed
pmichaud the scope that creates the handler should make sure that the handler is effectively removed, e.g. in an iteration 19:37
if that's the case, then I can write an example for that and we can publish it.
allison wonderful, thanks!
pmichaud and we can start moving existing code to follow that guideline
allison we may have to do it in a short-lived branch 19:38
that is, the current 'auto-disable' feature may interfere with the implementation of how it should work
pmichaud I don't think it will. 19:39
auto-disable is simply making it "appear" that the handler has been removed -- in reality it's still there. Explicitly removing it won't change that.
allison I'm thinking that pop_eh currently skips disabled handlers
pmichaud it does not.
allison ok, good
pmichaud I was very surprised to see that.
allison then no problems
(it probably should have)
pmichaud yes, but that's also why I know that we have a leak. :-) 19:40
allison (but, it's convenient that it didn't)
pmichaud (within a loop)
Tene allison: if it skipped disabled handlers, then pop_eh would behave differently based on whether there was an exception or not.
push_eh;...maybe_throw_exception;...pop_eh;
allison given that the auto-disable feature was put in place to support legacy code, I'm surprised that popping a disabled handler didn't break legacy code (since they would have expected it to be completely removed already) 19:41
Tene Hm.
pmichaud as I said, I don't think there are many places that make use of pop_eh in that way.
allison but then, our use of exceptions wasn't all that extensive before, since they didn't really work
spinclad push_eh; ... maybe_throw_exception; maybe_resume_here: ... pop_eh;
pmichaud it's rare to have push_eh in a loop to begin with. 19:42
Croke make use of pop_eh in which way, now?
Tene spinclad: no need for a label, just invoke the return continuation.
pmichaud Croke: this only matters in the case of doing multiple push_eh/pop_eh's in a scope
Croke: and I don't think there are many instances of that
spinclad (right, just naming a place)
allison spinclad: yes, that the general code order 19:43
wrapping up: pmichaud has volunteered to put together a code example of good exception use, and we'll gradually migrate legacy exception code to take responsibility for clearing exception handlers when they're no longer needed 19:44
spinclad (it's the juggling maybe's with pop_eh's i'm unsure of. if those that matter understand them, good enough)
pmichaud we'd have to have a case where we do two push_eh instructions, then the second handler is invoked (disabling it, assuming removal), and we later do a pop_eh to remove the first one, and then another exception triggers that.
in other words, it'd be pretty rare.
and that's why we didn't/wouldn't see much breakage from popping a disabled handler, because it probably doesn't happen in practice. 19:45
19:46 masak left
pmichaud I'll put together the example, post to the list, and also a request for official interface to re-enable a handler (to be documented in pdd23) 19:46
Tene wait, re-enable? we're sticking with auto-disable?
allison to re-enable a handler? after the transition, we'll stop auto-disabling 19:47
pmichaud oh, that's correct.
never mind.
allison (that is, as soon as we can get the tests to pass without auto-disabling)
pmichaud I'll keep testing that.
I suspect I can have many/most of these cleaned up in just a couple of hours.
Croke Welp, I'm just as confused about what this means for writing PIR as I was before. =-)
pmichaud Croke: my example should make it clear. 19:48
Croke I look forward to your email.
allison IIRC PGE was the biggest source of failures without auto-disabling
pmichaud right, and PGE is one of the easiest to fix. :-)
allison PGE is the biggest user of exceptions in general, so it's a good test case
Tene particle was talking earlier about a need for a PDS attendees page.
pmichaud especially since I now know the "correct" approach.
(PDS attendees page) I'd say just create one. :-)
it's a wiki. 19:49
Tene If it was THAT easy, ANYONE could do it.
allison (PDS attendees page) sounds useful, go for it
pmichaud do we need a deprecation cycle for auto-disable? 19:50
allison pmichaud: yes, just in case outside languages are using it
pmichaud okay. I'll make sure it gets into DEPRECATED then. 19:51
I'm done. 19:52
NotFound BTW, what is the section in DEPRECATED where PARROT_API functions must go?
allison NotFound: we haven't been subjecting C functions to the same DEPRECATION requirements as user facing code 19:53
NotFound: Possibly we should 19:54
s/possibly/probably/
certainly we will after 1.0
so, it's a good habit to start
chromatic Only if they're marked with PARROT_API.
(and we mark too many with PARROT_API) 19:55
particle the three functions in core not marked with PARROT_API are exempt.
NotFound There is a Functions subsection inside Parrot Compiler Tools section. Is this correct, or is a typo in the heading?
pmichaud typo somewhere -- possibly a missing =head1 19:56
chromatic donde es mi =cabesa? 19:57
NotFound chromatic: cabeza
spinclad está
pmichaud I'd change the =head2 to =head1 for now.
Croke (outside languages) there are, like, 2 of us. =-) 19:58
allison NotFound: yes, we've randomly listed some functions in particular subsystems, but haven't had a top-level for all deprecated functions. in favor of promoting the header 19:59
Croke: yes, but also includes any external users of Parrot 20:00
chromatic Are there any other questions? 20:04
Croke Thanks for providing a release which partcl was able to target.
chromatic We'll call it a week then. CLOSE MORE TICKETS (especially Coke's segfaults) 20:05
20:16 Croke left, jhorwitz left 20:17 chromatic left 20:18 cotto left 20:36 NotFound left 21:06 PacoLinux left

Powered by Cro and the Raku® Programming Language.

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

Thank you!