Menu
▾
▴
tcl-core
|
From: Andreas K. <and...@ac...> - 2009-10-08 19:59:07
|
This is a Call For Votes on TIP #348. TIP #348: Substituted 'errorStack' / 'traceback' Contrary to the information in the headers of the TIP (Tcl 8.7) it is my understanding that Alexandre is asking for inclusion of this feature into Tcl 8.6 The implementation is available at https://sourceforge.net/support/tracker.php?aid=2868499 Please send your votes to the tcl-core mailing list by Thursday, Oct 15, 12:00 Pacific, aka [clock format 1255633200] -- Sincerely, Andreas Kupries <an...@ac...> Developer @ <http://www.activestate.com/> |
|
From: Jeff H. <je...@ac...> - 2009-10-08 20:06:21
|
On 08/10/2009 12:55 PM, Andreas Kupries wrote: > This is a Call For Votes on TIP #348. > > TIP #348: Substituted 'errorStack' / 'traceback' > > Contrary to the information in the headers of the TIP (Tcl 8.7) it is my > understanding that Alexandre is asking for inclusion of this feature into > > Tcl 8.6 > > The implementation is available at > > https://sourceforge.net/support/tracker.php?aid=2868499 TIP #348: YES I feel that the functionality provided can be valuable to end users and should have no chance of compat issues. I know 8.6 is at beta, but this enhancement is minor and contained. This is something tkcon could definitely make use of. At Alex's request we have reviewed and tested the current patch across our entire platform set and it passed. Jeff |
|
From: Joe E. <jen...@fl...> - 2009-10-08 21:55:32
|
> This is a Call For Votes on TIP #348. > > TIP #348: Substituted 'errorStack' / 'traceback' > > Contrary to the information in the headers of the TIP (Tcl 8.7) it is my > understanding that Alexandre is asking for inclusion of this feature into > > Tcl 8.6 TIP#348: SEND IT BACK. The basic idea behind this TIP is good, but there is an IMO fatal flaw as currently specified: it introduces two new magic globals, $::tcl::errorStack and $::tcl::useErrorStack. Tcl already has too many of these (errorInfo, errorCode, tcl_precision, env, ...); this is recognized by now as having been a bad idea in all cases. I'd also suggest targeting this for 8.7. 8.6 is supposed to be in feature-freeze mode, so that it can be released. Every last-minute addition delays the release. If "SEND IT BACK" is (still) not a valid vote, then I'm sadly forced to say: TIP#348: NO. --Joe English jen...@fl... |
|
From: Daniel A. S. <da...@us...> - 2009-10-08 22:11:16
|
On Thu, Oct 8, 2009 at 14:55, Joe English <jen...@fl...> wrote: > >> This is a Call For Votes on TIP #348. >> >> TIP #348: Substituted 'errorStack' / 'traceback' >> >> Contrary to the information in the headers of the TIP (Tcl 8.7) it is my >> understanding that Alexandre is asking for inclusion of this feature into >> >> Tcl 8.6 > > TIP#348: SEND IT BACK. > > The basic idea behind this TIP is good, but there is > an IMO fatal flaw as currently specified: it introduces > two new magic globals, $::tcl::errorStack and $::tcl::useErrorStack. > > Tcl already has too many of these (errorInfo, errorCode, > tcl_precision, env, ...); this is recognized by now as > having been a bad idea in all cases. > > I'd also suggest targeting this for 8.7. 8.6 is supposed to > be in feature-freeze mode, so that it can be released. > Every last-minute addition delays the release. > > If "SEND IT BACK" is (still) not a valid vote, then I'm > sadly forced to say: > > TIP#348: NO. +1 on all counts, i.e. NO for 8.6, sounds good for 8.7 if amended to not introduce yet more magic variable names, e.g. use [info errorstack] or something instead. Cheers, Daniel |
|
From: Alexandre F. <ale...@gm...> - 2009-10-09 07:35:25
|
On 10/9/09, Daniel A. Steffen <da...@us...> wrote:
> On Thu, Oct 8, 2009 at 14:55, Joe English <jen...@fl...> wrote:
> >
> >> This is a Call For Votes on TIP #348.
> >>
> >> TIP #348: Substituted 'errorStack' / 'traceback'
> >>
> >> Contrary to the information in the headers of the TIP (Tcl 8.7) it is my
> >> understanding that Alexandre is asking for inclusion of this feature into
> >>
> >> Tcl 8.6
> >
> > TIP#348: SEND IT BACK.
> >
> > The basic idea behind this TIP is good, but there is
> > an IMO fatal flaw as currently specified: it introduces
> > two new magic globals, $::tcl::errorStack and $::tcl::useErrorStack.
> >
> > Tcl already has too many of these (errorInfo, errorCode,
> > tcl_precision, env, ...); this is recognized by now as
> > having been a bad idea in all cases.
> >
> > I'd also suggest targeting this for 8.7. 8.6 is supposed to
> > be in feature-freeze mode, so that it can be released.
> > Every last-minute addition delays the release.
> >
> > If "SEND IT BACK" is (still) not a valid vote, then I'm
> > sadly forced to say:
> >
> > TIP#348: NO.
>
>
> +1 on all counts, i.e. NO for 8.6, sounds good for 8.7 if amended to
> not introduce yet more magic variable names, e.g. use [info
> errorstack] or something instead.
Of course I have no objection regarding the API. It is trivial to
expose it through the [info] or [interp] ensembles rather than
variables. I'm just surprised to see this as a strong showstopper,
because I seem to recall some of you saying that the ::tcl namespace
was okay for the job.
Now to proceed is:
info errorstack --> gives the list
info errorstack <boolean> --> enables/disables the feature
palatable ?
Minor variations:
- "interp" ensemble instead of "info"
- boolean replaced or extended by "enable/disable"
-Alex
|
|
From: Reinhard M. <ma...@tc...> - 2009-10-09 08:21:02
|
Hi,
On Fri, 9 Oct 2009 at 09:35, Alexandre Ferrieux wrote:
> - "interp" ensemble instead of "info"
yes, "interp" seems to be a better fit, at least for the
enable/disable part, because AFAICS the "info" command is purely
introspective right now. None of the subcommands changes any
script-visible state.
Having it in "interp" would also result in shorter and simpler code
when dealing with the errorStack of slave interpreters:
interp errorstack ?path? ?enable|disable?
slave errorstack ?enable|disable?
vs.
info errorstack ?enable|disable?
slave eval info errorstck ?enable|disable?
slave invokehidden info errorstck ?enable|disable?
cu
Reinhard
|
|
From: Jeff H. <je...@ac...> - 2009-10-09 15:43:22
|
On 09/10/2009 1:05 AM, Reinhard Max wrote: > On Fri, 9 Oct 2009 at 09:35, Alexandre Ferrieux wrote: > >> - "interp" ensemble instead of "info" > > yes, "interp" seems to be a better fit, at least for the > enable/disable part, because AFAICS the "info" command is purely > introspective right now. None of the subcommands changes any > script-visible state. > > Having it in "interp" would also result in shorter and simpler code > when dealing with the errorStack of slave interpreters: > > interp errorstack ?path? ?enable|disable? > slave errorstack ?enable|disable? s/enable|disable/boolean/ and +1. That's also how I implemented a portion of the optional pcre control. |
|
From: Joe E. <jen...@fl...> - 2009-10-09 16:53:14
|
Alexandre Ferrieux wrote:
> Of course I have no objection regarding the API. It is trivial to
> expose it through the [info] or [interp] ensembles rather than
> variables. I'm just surprised to see this as a strong showstopper,
> because I seem to recall some of you saying that the ::tcl namespace
> was okay for the job.
> Now to proceed is:
> info errorstack --> gives the list
> info errorstack <boolean> --> enables/disables the feature
> Minor variations:
> - "interp" ensemble instead of "info"
> - boolean replaced or extended by "enable/disable"
Where this really belongs is in the return options dictionary:
catch $script result options
dict get $options -errorstack
Of course to be truly useful the error stack *also*
needs to be accessible via [info] or [interp],
for the benefit of those who neglected to catch
the return options before making an error :-)
I'd suggest: [info errorstack ?interp?], where ?interp?
defaults to the calling interpreter if omitted.
As for how to turn it on and off -- I think it'd be OK,
preferable even, to just leave this enabled all the time.
The feature doesn't cost anything under normal operations,
the only additional work done is during error propagation,
which is not a time-critical part of any reasonable program.
Also, that way users don't need to remember to turn the feature
on before making a mistake that they will want to debug.
(BTW: I've since had a chance to look at the actual patch,
and agree that the basic mechanism is minimally intrusive;
I think it'd be OK for 8.6 (once amended).)
--Joe English
jen...@fl...
|
|
From: Alexandre F. <ale...@gm...> - 2009-10-10 22:20:49
|
On 10/9/09, Joe English <jen...@fl...> wrote:
>
> Alexandre Ferrieux wrote:
>
> > Of course I have no objection regarding the API. It is trivial to
> > expose it through the [info] or [interp] ensembles rather than
> > variables. I'm just surprised to see this as a strong showstopper,
> > because I seem to recall some of you saying that the ::tcl namespace
> > was okay for the job.
>
> > Now to proceed is:
> > info errorstack --> gives the list
> > info errorstack <boolean> --> enables/disables the feature
>
> > Minor variations:
> > - "interp" ensemble instead of "info"
> > - boolean replaced or extended by "enable/disable"
>
>
>
> Where this really belongs is in the return options dictionary:
>
> catch $script result options
> dict get $options -errorstack
The only concern is that the value will then need to be built all the
time (a dict member cannot have traces), while it might be faster to
build an internal form that is not directly the errorstack Tcl value,
see below.
> Of course to be truly useful the error stack *also*
> needs to be accessible via [info] or [interp],
> for the benefit of those who neglected to catch
> the return options before making an error :-)
>
> I'd suggest: [info errorstack ?interp?], where ?interp?
> defaults to the calling interpreter if omitted.
OK, will do that shortly.
> As for how to turn it on and off -- I think it'd be OK,
> preferable even, to just leave this enabled all the time.
> The feature doesn't cost anything under normal operations,
> the only additional work done is during error propagation,
> which is not a time-critical part of any reasonable program.
>
> Also, that way users don't need to remember to turn the feature
> on before making a mistake that they will want to debug.
Yes, I feel sympathetic with that last remark, as I follow this
strategy all the time (no "debug level", always log, and delete the
logs if nothing went wrong)... as long as it doesn't hamper
performance. Here the overhead is slight but nonzero, so I'm ready to
work a little bit more on optimizing it, if we decide to leave the
feature on by default.
I believe the measured overhead comes from the ckalloc-ed element
arrays of the small lists built to contain argslist at each level; the
"backbone" list costs much less, because careful steps are taken to
modify it in-place whenever possible.
I can see two options to speed this up:
(1) grow a flat list instead of a list of lists, inserting integer
counts of arguments before each argslist: {3 foo a b 1 bar 2 baz
gnats} and transform it into a true error stack only on final [info
errorstack] request: {{foo a b} bar {baz gnats}}
(2) grow a Lisp-like nested linked list based on Tcl_Obj's which are
Cons cells (one car + one cdr). This has the advantage of relying
exclusively on the Tcl_Obj allocator. On final request, it must also
be transformed back into a true Tcl list (2a) , or (2b) at least have
a string representation identical to that of the wanted list (just
like dicts look like lists on strep examination).
If the constraint of landing in the options dict holds, then (2b) is
the way to go.
Please give me your preference.
> (BTW: I've since had a chance to look at the actual patch,
> and agree that the basic mechanism is minimally intrusive;
> I think it'd be OK for 8.6 (once amended).)
Thank you very much. Indeed I would find it very long to wait for 8.7
for a feature that's both really handy and really simple to implement.
-Alex
|
|
From: Kevin K. <kev...@gm...> - 2009-10-09 01:05:18
|
TIP #348: PRESENT Jeff is right that the changes are minimally disruptive, and should be considered for 8.6.0 - after all, it isn't as if release is imminent. On the other hand, Joe's and Daniel's criticisms suggest that the TIP isn't fully baked. And I'm not going to have time in the next few days to enter the fray on this one. (I have my hands full trying to repair 357, which is badly flawed as it stands.) I'll trust Joe and Daniel to thrash it out. -- 73 de ke9tv/2, Kevin |
|
From: Alexandre F. <ale...@gm...> - 2009-10-09 07:42:28
|
On 10/9/09, Kevin Kenny <kev...@gm...> wrote: > > On the other hand, Joe's and Daniel's criticisms suggest that > the TIP isn't fully baked. Yes, I admit the CFV was possibly a bit hurried. It is my fault, I asked Jeff and Andreas for sponsorship, and they were very fast to help me finish it and test it. When they proposed the CFV I didn't react, thinking we had no need for an extra discussion step, since (1) the ::tcl namespace issue had been raised before and (2) I was under the impression that 8.6 was imminent. Now I can see I was wrong, so my proposition is to SEND IT BACK as Daniel says, and enter the discussion step instead. See my answer to Daniel to proceed on the API definition. -Alex |
|
From: Donal K. F. <don...@ma...> - 2009-10-09 12:44:24
|
Andreas Kupries wrote: > This is a Call For Votes on TIP #348. > > TIP #348: Substituted 'errorStack' / 'traceback' So... given the chorus of "not opposed to the principle, but not now/in this way"... are we going ahead with this vote right now? If nothing else, if we are I want to mark the TIP as being voted on. Formal process and all that. :-) Donal. |
|
From: Andreas K. <and...@ac...> - 2009-10-09 15:36:02
|
Donal K. Fellows wrote:
> Andreas Kupries wrote:
>> This is a Call For Votes on TIP #348.
>>
>> TIP #348: Substituted 'errorStack' / 'traceback'
>
> So... given the chorus of "not opposed to the principle, but not now/in
> this way"... are we going ahead with this vote right now? If nothing
> else, if we are I want to mark the TIP as being voted on. Formal process
> and all that. :-)
I am hereby canceling this vote. We can try again after the discussion.
--
Sincerely,
Andreas Kupries <an...@ac...>
Developer @ <http://www.activestate.com/>
|
|
From: Alexandre F. <ale...@gm...> - 2009-10-14 08:05:39
|
On 10/11/09, Alexandre Ferrieux <ale...@gm...> wrote:
>
> Yes, I feel sympathetic with that last remark, as I follow this
> strategy all the time (no "debug level", always log, and delete the
> logs if nothing went wrong)... as long as it doesn't hamper
> performance. Here the overhead is slight but nonzero, so I'm ready to
> work a little bit more on optimizing it, if we decide to leave the
> feature on by default.
>
> I believe the measured overhead comes from the ckalloc-ed element
> arrays of the small lists built to contain argslist at each level; the
> "backbone" list costs much less, because careful steps are taken to
> modify it in-place whenever possible.
>
> I can see two options to speed this up:
>
> (1) grow a flat list instead of a list of lists, inserting integer
> counts of arguments before each argslist: {3 foo a b 1 bar 2 baz
> gnats} and transform it into a true error stack only on final [info
> errorstack] request: {{foo a b} bar {baz gnats}}
>
> (2) grow a Lisp-like nested linked list based on Tcl_Obj's which are
> Cons cells (one car + one cdr). This has the advantage of relying
> exclusively on the Tcl_Obj allocator. On final request, it must also
> be transformed back into a true Tcl list (2a) , or (2b) at least have
> a string representation identical to that of the wanted list (just
> like dicts look like lists on strep examination).
>
> If the constraint of landing in the options dict holds, then (2b) is
> the way to go.
> Please give me your preference.
Let me rephrase.
The principle is roughly
lappend errorstack [info level 0]
The current implementation reuses the optimization of in-place
[lappend] so that it doesn't incur extra allocations in routine use.
But [info level 0] is actually a
Tcl_NewListObj(varFramePtr->objc,varFramePtr->objv);
which means 2 ckallocs (one for the fixed size List intrep, one for
the elements array).
Question: should I
(1) leave it as is with the on/off switch, off by default.
=> trivial code, slight performance cost, must be switched on.
(2) optimize it to a ckalloc-free variant (with two alternatives
sketched earlier)
=> more complex code, zero performance cost, always on.
Please help me decide. I have no problem implementing either choice, I
just don't want to waste time,
-Alex
|
|
From: Alexandre F. <ale...@gm...> - 2009-10-20 16:20:19
|
Hello, I have now updated the patch for TIP #348 (errorStack) at https://sourceforge.net/tracker/index.php?func=detail&aid=2868499&group_id=10894&atid=310894 to comply with Joe's suggestions [info errorstack ?interp?] + [dict get $d -errorstack]. Please review the performance measurements there (and code). TIA, -Alex |
|
From: Alexandre F. <ale...@gm...> - 2009-10-23 06:35:07
|
On 10/20/09, Alexandre Ferrieux <ale...@gm...> wrote: > Hello, > > I have now updated the patch for TIP #348 (errorStack) at > > https://sourceforge.net/tracker/index.php?func=detail&aid=2868499&group_id=10894&atid=310894 > > to comply with Joe's suggestions [info errorstack ?interp?] + [dict > get $d -errorstack]. > > Please review the performance measurements there (and code). > > TIA, > > -Alex > Patch extended to allow measurement of the faster construction of errorstack as a flat list. Timing results at the same place: https://sourceforge.net/tracker/index.php?func=detail&aid=2868499&group_id=10894&atid=310894 Also, an I tried the Lisp-like linked list approach (each cell being a Tcl_Obj), only to discover that it didn't gain any speed. So the final choice is the following: (1) [use==2]: [info errorstack] + options dicts + nested list, <5% slowdown (2a) [use==6]: [info errorstack] + options dicts + flat list, <2% slowdown (2b) [use==6]: [info errorstack] + postprocessed nested list, <2% slowdown I am hereby asking you to argue on this choice, even if you don't have time to review the code. -Alex |
|
From: Alexandre F. <ale...@gm...> - 2009-10-30 17:00:56
|
Hi, Does the absence of reactions mean that #348 moved from half- to fully baked, and that in case a CFV were issued now, it would encounter nothing but heartful YESses ? If not, please express your objections/opinions/extra criteria here and now. (input is needed anyway to decide on the alternative below) -Alex > > Patch extended to allow measurement of the faster construction of > errorstack as a flat list. > Timing results at the same place: > > > https://sourceforge.net/tracker/index.php?func=detail&aid=2868499&group_id=10894&atid=310894 > > > Also, an I tried the Lisp-like linked list approach (each cell being a > Tcl_Obj), only to discover that it didn't gain any speed. So the final > choice is the following: > > (1) [use==2]: [info errorstack] + options dicts + nested list, <5% slowdown > > (2a) [use==6]: [info errorstack] + options dicts + flat list, <2% slowdown > > (2b) [use==5]: [info errorstack] + postprocessed nested list, <2% slowdown > > I am hereby asking you to argue on this choice, even if you don't have > time to review the code. > > -Alex > |
|
From: Joe E. <jen...@fl...> - 2009-10-30 17:37:19
|
Alexandre Ferrieux wrote: > > Does the absence of reactions mean that #348 moved from half- to fully > baked, and that in case a CFV were issued now, it would encounter > nothing but heartful YESses ? The TIP (r1.6) still specifies: | Proposed Change | | This TIP proposes to create a ::tcl::errorStack variable which is a list | of lists, made of the [info level 0] lists of command-and-args at each | proc level at the time of error unwinding. which is the main thing I objected to. Please update the TIP to match the implementation then ask again. Also: the "flat list" representation proposed in the SF Patch does not look worthwhile. If I'm reading the timings correctly, this optimization saves on the order of 3 microseconds in a process that takes on the order of 100 microseconds overall. The claim of "three times faster^H^H^H^H^H^H less overhead!" seems overblown. Optimizing something that takes a small fraction of the overall runtime, isn't slow to begin with, and doesn't even need to be fast in the first place (since it only affects error propagation), just doesn't seem worth it. --Joe English jen...@fl... |
|
From: Alexandre F. <ale...@gm...> - 2009-10-31 16:05:48
|
On 10/30/09, Joe English <jen...@fl...> wrote: > > Alexandre Ferrieux wrote: > > > > Does the absence of reactions mean that #348 moved from half- to fully > > baked, and that in case a CFV were issued now, it would encounter > > nothing but heartful YESses ? > > > The TIP (r1.6) still specifies: > [...] > which is the main thing I objected to. Sigh. Chicken-and-egg... I had hoped the discussion to take place first, to avoid documenting something half-bolted in the TIP ;-) > Please update the TIP to match the implementation then ask again. Done. > Also: the "flat list" representation proposed in the SF Patch > does not look worthwhile. If I'm reading the timings correctly, > this optimization saves on the order of 3 microseconds in a process > that takes on the order of 100 microseconds overall. The claim of > "three times faster^H^H^H^H^H^H less overhead!" seems overblown. > Optimizing something that takes a small fraction of the overall > runtime, isn't slow to begin with, and doesn't even need to be fast > in the first place (since it only affects error propagation), > just doesn't seem worth it. OK. One clarification though: it's saving 3 usecs out of the 5 we're about to lose. That may not be much, but doesn't sound as ridiculous as you make it sound with 3 vs 100 ... (especially when people start whispering about a "slower" 8.6). Anyway, patch updated to your liking. As noted in the comments, now I need to fix the whole test suite wherever the options dictionary value is checked in extenso. This, by the way, makes me wonder whether it is a good idea to let -errorstack (and -errorinfo, for that matter) land in the options dict. I'd bet it clutters the logs when people just print the dict for debugging... -Alex |
|
From: Joe E. <jen...@fl...> - 2009-11-01 18:47:05
|
Alexandre Ferrieux wrote: > > [I wrote]: > > Please update the TIP to match the implementation then ask again. > > Done. Thanks. TIP#348 r1.9 looks good. I'd move that this be included in Tcl 8.6. * * * [ Re: the "flat list" representation ] > > OK. One clarification though: it's saving 3 usecs out of the 5 we're > about to lose. That may not be much, but doesn't sound as ridiculous > as you make it sound with 3 vs 100 ... (especially when people start > whispering about a "slower" 8.6). I'll just mention two things: "Amdahl's law" and "the nanosecond rule". If it takes a user looking at an errorstack traceback even _three seconds longer_ to decipher the encoded form than it would have to understand the natural form, the amortized savings over a _million program errors_ have just been spent. --Joe English jen...@fl... |
|
From: Alexandre F. <ale...@gm...> - 2009-11-02 14:48:58
|
On 11/1/09, Joe English <jen...@fl...> wrote: > > Alexandre Ferrieux wrote: > > > [I wrote]: > > > > Please update the TIP to match the implementation then ask again. > > > > Done. > > > Thanks. TIP#348 r1.9 looks good. I'd move that this be > included in Tcl 8.6. Thank you very much. Any further objection from other TCT members ? -Alex |
|
From: Daniel A. S. <da...@us...> - 2009-11-02 17:10:16
|
Hi Alexandre, apologies for the delay, finally had a chance to look at the latest TIP and patch revisions On Mon, Nov 2, 2009 at 07:48, Alexandre Ferrieux <ale...@gm...> wrote: > Any further objection from other TCT members ? the TIP looks great now, the syntax feels just right to me. Given the consensus that 8.6 is not imminent and the small size of the patch I withdraw my objection about this going into 8.6. The patch looks good, one very minor nit: the comments in the additions to tclInt.h still mention the errorStack variable, would be good to clean that up before committing BTW, I find that diff -p context info makes it a little bit easier to review patches (an easy way to make that automatic is to put 'diff -u -p -N' into your .cvsrc), thanks! Cheers, Daniel |
|
From: Alexandre F. <ale...@gm...> - 2009-11-03 17:23:30
|
Hello Daniel, On 11/2/09, Daniel A. Steffen <da...@us...> wrote: > Hi Alexandre, > > the TIP looks great now, the syntax feels just right to me. Given the > consensus that 8.6 is not imminent and the small size of the patch I > withdraw my objection about this going into 8.6. Thank you very much ! > The patch looks good, one very minor nit: the comments in the > additions to tclInt.h still mention the errorStack variable, would be > good to clean that up before committing > > BTW, I find that diff -p context info makes it a little bit easier to > review patches (an easy way to make that automatic is to put 'diff -u > -p -N' into your .cvsrc), thanks! Both fixed in the SF patch. Thanks for the -p trick ! Now, maybe it is time for the final CFV ? (meeting the 8.6b2 deadline -- if any -- would be very cool from my standpoint) -Alex |
|
From: Donald G P. <dg...@ni...> - 2009-10-31 16:37:49
|
Alexandre Ferrieux wrote: > ...This, by the way, makes me wonder whether it is > a good idea to let -errorstack (and -errorinfo, for that matter) land > in the options dict. That is the one place where it absolutely must be. For the sake of [interp bgerror] callbacks if no other reason. -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Alexandre F. <ale...@gm...> - 2009-10-31 16:40:47
|
On 10/31/09, Donald G Porter <dg...@ni...> wrote: > Alexandre Ferrieux wrote: > > > ...This, by the way, makes me wonder whether it is > > a good idea to let -errorstack (and -errorinfo, for that matter) land > > in the options dict. > > > > That is the one place where it absolutely must be. For the sake > of [interp bgerror] callbacks if no other reason. Ah OK. I withdraw that remark then. And in the meantime the patch now includes the fixed test suite. -Alex |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X