CFV TIP #348 - Substituted 'errorStack' / 'traceback'

[Andreas Kupries-2]

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 <andreas@...>
     Developer @    <http://www.activestate.com/>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Jeff Hobbs]

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Joe English-2]

> 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

  jenglish@...

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Daniel A. Steffen]

On Thu, Oct 8, 2009 at 14:55, Joe English <jenglish@...> 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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Kevin Kenny-6]

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Alexandre Ferrieux]

On 10/9/09, Daniel A. Steffen <das@...> wrote:

> On Thu, Oct 8, 2009 at 14:55, Joe English <jenglish@...> 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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Alexandre Ferrieux]

On 10/9/09, Kevin Kenny <kevin.b.kenny@...> 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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Reinhard Max-3]

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Donal K. Fellows-2]

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.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Andreas Kupries-2]

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 <andreas@...>
     Developer @    <http://www.activestate.com/>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Jeff Hobbs]

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.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Joe English-2]

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

  jenglish@...

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Alexandre Ferrieux]

On 10/9/09, Joe English <jenglish@...> 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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Alexandre Ferrieux]

On 10/11/09, Alexandre Ferrieux <alexandre.ferrieux@...> 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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Alexandre Ferrieux]

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Alexandre Ferrieux]

On 10/20/09, Alexandre Ferrieux <alexandre.ferrieux@...> 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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Alexandre Ferrieux]

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
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Joe English-2]

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

  jenglish@...

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Alexandre Ferrieux]

On 10/30/09, Joe English <jenglish@...> 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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Donald G Porter]

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 |
| donald.porter@...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core