tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Compiler error on Windows/CVS HEAD

[Jeremy C. <je...@co...>]

I filed a bug report for this as I am 99.9% sure it's a bug not a problem with my local development environment.

Jeremy Cowgar


From: Jeremy Cowgar 
Sent: Friday, November 20, 2009 8:25 PM
To: tcl...@li... 
Subject: [TCLCORE] Compiler error on Windows/CVS HEAD


I am trying to compile CVS head for 8.6 for the first time ever. I downloaded and installed MSYS and MinGW for this task. I can compile 8.5.8 with no problem however I get the following error when trying to compile 8.6 CVS HEAD (as of 11/20 @ 8:23PM EST).

gcc -shared -O2 -fomit-frame-pointer  -o tcltest86.dll -Wl,--out-implib,libtcltest86.a tclTest.o tclTestObj.o tclTestProcBodyObj.o tclThreadTest.o tclWinTest.o libtclstub86.a -lws2_32 /home/Jeremy/TclTk_CVS/tcl/compat/zlib/win32/zdll.lib
Creating library file: libtcltest86.a
tclThreadTest.o:tclThreadTest.c:(.text+0x119d): undefined reference to `Tcl_PackageRequire'
collect2: ld returned 1 exit status
make: *** [tcltest86.dll] Error 1

I hesitated to create a bug report for this since it is the first time I have compiled Tcl 8.6 but I do believe it's not my setup.

Any thoughts on this problem?

Jeremy Cowgar



--------------------------------------------------------------------------------


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july 


--------------------------------------------------------------------------------


_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] Compiler error on Windows/CVS HEAD

[Jeremy C. <je...@co...>]

I am trying to compile CVS head for 8.6 for the first time ever. I downloaded and installed MSYS and MinGW for this task. I can compile 8.5.8 with no problem however I get the following error when trying to compile 8.6 CVS HEAD (as of 11/20 @ 8:23PM EST).

gcc -shared -O2 -fomit-frame-pointer  -o tcltest86.dll -Wl,--out-implib,libtcltest86.a tclTest.o tclTestObj.o tclTestProcBodyObj.o tclThreadTest.o tclWinTest.o libtclstub86.a -lws2_32 /home/Jeremy/TclTk_CVS/tcl/compat/zlib/win32/zdll.lib
Creating library file: libtcltest86.a
tclThreadTest.o:tclThreadTest.c:(.text+0x119d): undefined reference to `Tcl_PackageRequire'
collect2: ld returned 1 exit status
make: *** [tcltest86.dll] Error 1

I hesitated to create a bug report for this since it is the first time I have compiled Tcl 8.6 but I do believe it's not my setup.

Any thoughts on this problem?

Jeremy Cowgar

[TCLCORE] ActiveTcl 8.5.8.0 released

[Jeff H. <je...@ac...>]

ActiveState is pleased to announce the release of ActiveTcl 8.5.8.0, a 
patchlevel release of the complete, ready-to-install Tcl distribution 
for Windows, Mac OS X, Linux, Solaris, AIX and HP-UX; based on the 
Tcl/Tk 8.5.8 core.

For detailed information or to download these releases, see:
       http://www.activestate.com/activetcl/

== New in ActiveTcl 8.5.8.0 ==

A core patchlevel release with updates, including:

* Updated Tcl/Tk core to 8.5.8
* Updated teacup package management application
* Updated packages
** Bwidget 1.9
** snit 1.4 / 2.3
** struct::tree 2.4
** comm 4.6.1
** log 1.3
** fileutil 1.14.1
** Tablelist 4.12.1
** widget::calendar 0.94
** Treectrl 2.2.9
** Sqlite 3.6.20

Download ActiveTcl 8.5.8.0 now:
       http://www.activestate.com/activetcl

For access to more packages, use the included [teacup] application.

=== Getting Started ===

Whether you're a first-time user or a long-time fan, our free resources 
will help you get the most from ActiveTcl.

User forums and FAQs:
       http://community.activestate.com/products/ActiveTcl

Mailing list archives:
       http://aspn.activestate.com/ASPN/Mail/?topic=Tcl

Documentation:
       http://docs.activestate.com/activetcl/8.5/

=== Feedback ===

Everyone is encouraged to participate in making Tcl an even better 
language. For bugs related to ActiveTcl, please use:

http://bugs.ActiveState.com/enter_bug.cgi?product=ActiveTcl&version=8.5.8.0

Tcl/Tk is maintained by the Tcl community, with the sources and bug
database at SourceForge:
       http://tcl.SourceForge.net/

Enjoy!

- The Tcl Team
    ActiveState Software Inc.

Re: [TCLCORE] What's good form?

[Jeff H. <je...@ac...>]

On 17/11/2009 5:35 PM, Brian Griffin wrote:
> I'm having a somewhat esoteric debate with a colleague about the
> following code fragment:
>
>      Tcl_DStringResult(interp,&dstr);
>      Tcl_DStringFree(&dstr);
>      return TCL_OK;
>
> Fact 0:  Tcl_DStringResult takes ownership of the dstring memory and
> gives it to interp.
> Fact 1:  Tcl_DStringResult re-initializes dstr.
>
> Claim A:  Since ownership has been given up in the first call, dstr
> should be considered dead and not be used unless explicitly initialized
> by the code.  So the code should be:
>
>      Tcl_DStringResult(interp,&dstr);
>      return TCL_OK;
>
>
> Claim B: Since dstr has been re-initialized by the first call, it should
> be free'd for completeness.
>
> A scan of the 8.4 Tcl/Tk code base turns up  ~12 instances of case A and
> ~2 instances of case B.  A few of the code samples have the form:
>
>      if (cond)
>         Tcl_DStringResult
>      else
>         Tcl_DStringFree
>
> So which code fragment illustrates good form?

I would argue claim A, because it encompasses claim B already, and this 
is noted in the docs.  The 2nd DStringFree is thus unnecessary.

The if (cond) case makes sense because you have to free the result one 
way or the other - either to the interp (via DSR) or directly because of 
an error cond (so use DSF).

Jeff

[TCLCORE] What's good form?

[Brian G. <bgr...@mo...>]

I'm having a somewhat esoteric debate with a colleague about the 
following code fragment:

    Tcl_DStringResult(interp, &dstr);
    Tcl_DStringFree(&dstr);
    return TCL_OK;

Fact 0:  Tcl_DStringResult takes ownership of the dstring memory and 
gives it to interp.
Fact 1:  Tcl_DStringResult re-initializes dstr.

Claim A:  Since ownership has been given up in the first call, dstr 
should be considered dead and not be used unless explicitly initialized 
by the code.  So the code should be:

    Tcl_DStringResult(interp, &dstr);
    return TCL_OK;


Claim B: Since dstr has been re-initialized by the first call, it should 
be free'd for completeness.

A scan of the 8.4 Tcl/Tk code base turns up  ~12 instances of case A and 
~2 instances of case B.  A few of the code samples have the form:

    if (cond)
       Tcl_DStringResult
    else
       Tcl_DStringFree

So which code fragment illustrates good form?

-Brian

[TCLCORE] Tcl/Tk 8.5.8 RELEASED

[Donald G P. <dg...@ni...>]

Tcl/Tk 8.5.8 Release Announcement
November 16, 2009

The Tcl Core Team is pleased to announce the 8.5.8 releases of the Tcl
dynamic language and the Tk toolkit.  This is the eighth patch release
of Tcl/Tk 8.5.  More details can be found below.  We would like to
express our gratitude to all those who submit bug reports and patches.
This information is invaluable in enabling us to identify and eliminate
problems in the core.

Where to get the new releases:
------------------------------

Tcl/Tk 8.5.8 sources are freely available as open source from the
Tcl Developer Xchange web site at:

         http://www.tcl.tk/software/tcltk/8.5.html

This web page also contains additional information about the releases,
including new features and notes about installing and compiling the
releases.  Sources are always available from the Tcl SourceForge
project's file distribution area:

         http://sourceforge.net/project/showfiles.php?group_id=10894

Binaries for most major platforms are available from:

         http://www.activestate.com/Tcl

For additional information:
---------------------------

Please visit the Tcl Developer Xchange web site:

         http://www.tcl.tk/

This site contains a variety of information about Tcl/Tk in general, the
core Tcl and Tk distributions, Tcl development tools, and much more.

Summary of Changes since Tcl/Tk 8.5.7:
--------------------------------------

The following were the main changes in Tcl/Tk 8.5.8.  A complete list
can be found in the changes file at the root of the source tree.  The
more complete ChangeLog is also included with each source release.  This
is a patch release, so it primarily includes bug fixes and corrections
to erratic behavior.  Below are only the most notable changes.

    * Resized mp_digit / mp_int storage on 64-bit systems.
         *** POTENTIAL INCOMPATIBILITY see http://wiki.tcl.tk/24693 ***

    * Vista Ttk theme support.

    * [tk_chooseDirectory] has newer style on Windows.

    * Tk 8.5.8 can now [load] into a Tcl 8.6 or later interp.

    * Updated [send] security for compatibility with Fedora 8 systems.

    * Corrected scope of [tk_get*File -typevariable].

    * [glob */foo] now returns ./~x/foo and not ~x/foo .

    * [wm iconphoto] now works on non-32-bit displays and big endian 
systems.

    * Safe Base now permits access to complete TM search path.

    * [info frame] now accounts for continuation lines.

    * [chan create]d channels can now signal EAGAIN.

    * Repaired broken "tclTomMath.h" header file.

    * New version 1.0.5 of platform package:
      - accounts for ia64_32

    * New version 2.7.5 of http package:
      - accept "quoted" charset value in headers
      - RFC 3986 compliance for ? in URLs

    * New version 2.3.2 of tcltest package.

    * Fixed nested event loop problems with TkAqua Cocoa and CoreFoundation.

    * Fixed Core Foundation memory bug in Tiger.

    * Fixed [checkbutton] state confusion on Windows.

    * Update [tk_messageBox] to work with Ttk buttons.

    * Fixed buffer overflows in [format].

    * Fixed EIAS failures in filesystem paths like ~foo.

    * Fixed XLFD font parse of {-family sans-serif ...}.

    * Fixed keyboard traversal of Windows menus.

    * Stop [grab .] preventing minimization.

    * Stop "tiny fonts" problem on Russian Windows.

    * Fixed tearoff menu operations on Windows.

    * Fixed underline and overstrike in Xft fonts.

    * Fixed crash when [exec] redirects to [chan create]d channel.

    * Fixed incorrect ** results like [expr {7**9 == 7**65545}] => 1.

    * Enable image data transfer through [selection get].

    * Proper tcl_platform(user) value on Windows when run as SYSTEM.

    * Repaired many segfaults and panics due to integer overflow on long 
values.

    * Fixed crashes sending focus to windows dead or not yet born.

    * Fixed crash drawing sash on panedwindow.

    * Fixed crash allocating fonts.

    * Fixed X crash on overlong color name.

    * Stopped hang in [fcopy -size] with mismatched translations/encodings.

    * Repaired memory leak in Tcl_ThreadQueueEvent().

    * Repaired memory leak in [dict incr].

    * Fixed crash in self-deleting variable unset traces.

    * Fixed crash in nested compiles (traces on ::errorInfo).

    * MIPS FPU settings for floating point underflow.

    * Support for portability to gcc 2.95 on Haiku OS.

    * Corrections and updates to timezone data and DST calculations.

    * Several Tk appearance corrections.

--
Tcl Core Team and Maintainers
Don Porter, Tcl Core Release Manager


-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

[TCLCORE] Release 8.5.8 and prio9 bug 2891556

[Alexandre F. <ale...@gm...>]

Hello Don,

I know you said you weren't likely to take last-days fixes onboard
unless something big showed up. I just wanted to bring to your
attention the fact that 2891556:

  - is now fixed and committed to core-8-5-branch HEAD
  - is well understood
  - has a trivial and preventive fix (a Tcl_Panic is we wreak it again).
  - is not restricted to debug-threaded builds
  - is platform-agnostic
  - could crash just about anybody on [exit] with a hard-to-track
symptom, as soon as an escape encoding has been used => well-deserved
prio9 IMO.

Your call, then :}

-Alex

[TCLCORE] Tcl/Tk 8.5.8 Release Candidates

[Donald G P. <dg...@ni...>]

Release Candidate downloads of the 8.5.8 releases of Tcl and Tk may
now be found at

     ftp://ftp.tcl.tk/pub/tcl/tcl8_5/

The actual releases of these files should come on Monday, Nov. 16.
Until then, enjoy this advance preview, and if you find anything
catastrophically wrong with them, please inform me so we can fix
the problem before the true release.

Thanks!

DGP

[TCLCORE] Tcl/Tk 8.5.8 release notes and update

[Donald G P. <don...@ni...>]

Testing of the 8.5.8 release candidates uncovered a few important
bugs as well as some memleaks.  Thanks to those who have been chasing
them down.

I expect to be able to post RC1 tarballs later today, with the intent
of making them the actual releases on Monday unless some important
issue with them is discovered.

While waiting for the next RCs to test, please have a look at the draft
release notes

http://sourceforge.net/projects/tcl/files/Tcl/8.5.8/tcltk-release-notes-8.5.8.txt/view

and offer whatever corrections or amendments are needed.

Thanks!

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

[TCLCORE] zlib push - corrupted

[Barry S. <at...@me...>]

Hi:

I have been working on using zlib in various methods for some file transfers between clients running a TCLTK app and a server running Apache PHP.

In my testing I have noticed that zlib push does not work correctly with fcopy -command, it also appears that zlib stream suffers from the same issues.

Using zlib push I can not gunzip inflate or decompress any file that is created wether on the machine it is created on or the server.
[ PHP execs a tcl script to extract the original file after it is posted to the server ]

If I open the file, read it in, zlib {compress gzip or deflate} then save to a new file it always works correctly.

---

I tried using zlib stream to read in chunks of the original and stream it into a new file channel.  I get the same result as with zlib push.
[ Meaning if I zlib push compress a.txt I get a file that exactly matches the result of using zlib stream compress. ]

---

In local testing (not transmitting to the server) I was able to get zlib push to correctly compress a file with fcopy but only if I was not using the fcopy -command option.
[ Hence a blocking solution and unacceptable for network transmissions ]

If I compiled the same code using ActiveTcl Compiler the script would then fail to create a proper file.

---

Has anyone else run into any of these issues and/or is there a known work around?

Thanks,
Barry

[TCLCORE] Safe Base update

[Andreas K. <and...@ac...>]

I sliced and diced my big blob of a patch to SafeBase I had sitting on my disk, 
updated it to work for head, and committed the slices now. Each change should 
be easy to read and understand (*), and SafeBase should be easier to maintain 
now as well, and more efficient too.

Below is the ChangeLog entry. Each (.) is a slice, committed separately. Each 
slice passed the full Tcl testsuite.

Anybody wishing to review see

	http://tcl.cvs.sourceforge.net/viewvc/tcl/tcl/library/safe.tcl?view=log

and start at revision 1.20. Anybody wishing to test and play with it, just get 
CVS Head.

	* library/safe.tcl: A series of patches which bring the SafeBase
	up to date with code guidelines, Tcl's features, also eliminating
	a number of inefficiencies along the way.
	(1) Changed all procedure names to be fully qualified.
	(2) Moved the procedures out of the namespace eval. Kept their
	locations. IOW, broke the namespace eval apart into small sections
	not covering the procedure definitions.
	(3) Reindented the code. Just lots of whitespace
	changes. Functionality unchanged.
	(4) Moved the multiple namespace eval's around. Command export at
	the top, everything else (var decls, argument parsing setup) at
	the bottom.
	(5) Moved the argument parsing setup into a procedure called when
	the code is loaded. Easier management of temporary data.
	(6) Replaced several uses of 'Set' with calls to the new procedure
	'InterpState' and direct access to the per-slave state array.
	(7) Replaced the remaining uses of 'Set' and others outside of the
	path/token handling, and deleted a number of procedures related to
	state array access which are not used any longer.
	(8) Converted the path token system to cache normalized paths and
	path <-> token conversions. Removed more procedures not used any
	longer. Removed the test cases 4.3 and 4.4 from safe.test. They
	were testing the now deleted command "InterpStateName".
	(9) Changed the log command setup so that logging is compiled out
	completely when disabled (default).
	(10) Misc. cleanup. Inlined IsInterp into CheckInterp, its only
	user. Consistent 'return -code error' for error reporting. Updated
	to use modern features (lassign, in/ni, dicts). The latter are
	used to keep a reverse path -> token map and quicker check of
	existence.
	(11) Fixed bug 2854929. Recurse into all subdirs under all TM root
	dirs and put them on the access path.

(*) Modulo slice (3), which is just big gob of whitespace changes due to 
re-indenting the whole file (compare 'diff -u' vs 'diff -wu' results).

-- 
Sincerely,
     Andreas Kupries <an...@ac...>
     Developer @    <http://www.activestate.com/>

[TCLCORE] Tcl/Tk 8.5.8 Release Candidates

[Donald G P. <don...@ni...>]

The RC0 tarballs for Tcl/Tk 8.5.8 are now ready for download at:

     ftp://ftp.tcl.tk/pub/tcl/tcl8_5/

These will not be the actual release, but my hope is that the RC1
tarballs will be.

If there is some important bug in these RCs and you can provide a fix
within a few days, report it so we can get the fix into 8.5.8.

I might move to RC1 as early as Friday if there are no reports of
trouble.

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] CFV TIP #348 - Substituted 'errorStack' / 'traceback'

[Alexandre F. <ale...@gm...>]

On 11/3/09, Donald G Porter <don...@ni...> wrote:
>
>  Alexandre Ferrieux wrote:
>  > > Now, maybe it is time for the final CFV ?
>  > > (meeting the 8.6b2 deadline -- if any -- would be very cool from my
> standpoint)
>
>  As I told you, I have not and will not review the proposal until I get
>  8.5.8 out the door.

OK I can wait a few days yet ;-)

>  One thing I ran across that may or may not be relevant is the comment
>  on Tcl Patch 1047543 about lazy building of the -errorinfo entry.
>  Depending on what you've done, it may be the answer to that, or it may
>  have gone in a different direction, and by consuming the space may
>  foreclose on that idea.

The truth of the matter is that I have explored the lazy techniques in
the vicinity of the current implementation, and exposed the timings
here, but the only feedback I got is "forget about this 5% slowdown of
[catch]". Now I agree it makes sense to let it be that way for 8.6b2,
and optimize later when/if evidence gathers that it's wanted, possibly
in time for 8.6.0.

One thing to note is that the mechanism for laziness will be identical
for errorinfo/errorstack in its interaction with the options dict:
values are stored there, hence no trace can do the just-in-time
conversion, which must thus be done through shimmering. So in both
cases I'd create an new obj type with shortcuts in SetListFromAny
(like for dicts).

-Alex

Re: [TCLCORE] CFV TIP #348 - Substituted 'errorStack' / 'traceback'

[Donald G P. <don...@ni...>]

Alexandre Ferrieux wrote:
 > > Now, maybe it is time for the final CFV ?
 > > (meeting the 8.6b2 deadline -- if any -- would be very cool from my 
standpoint)

As I told you, I have not and will not review the proposal until I get
8.5.8 out the door.

You may have enough support now without me that that does not matter.

One thing I ran across that may or may not be relevant is the comment
on Tcl Patch 1047543 about lazy building of the -errorinfo entry.

Depending on what you've done, it may be the answer to that, or it may
have gone in a different direction, and by consuming the space may
foreclose on that idea.

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] CFV TIP #348 - Substituted 'errorStack' / 'traceback'

[Alexandre F. <ale...@gm...>]

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

Re: [TCLCORE] CFV TIP #348 - Substituted 'errorStack' / 'traceback'

[Daniel A. S. <da...@us...>]

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

Re: [TCLCORE] CFV TIP #348 - Substituted 'errorStack' / 'traceback'

[Alexandre F. <ale...@gm...>]

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

Re: [TCLCORE] CFV TIP #348 - Substituted 'errorStack' / 'traceback'

[Joe E. <jen...@fl...>]

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...

Re: [TCLCORE] CFV TIP #348 - Substituted 'errorStack' / 'traceback'

[Alexandre F. <ale...@gm...>]

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

Re: [TCLCORE] CFV TIP #348 - Substituted 'errorStack' / 'traceback'

[Donald G P. <dg...@ni...>]

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 |
|______________________________________________________________________|

Re: [TCLCORE] CFV TIP #348 - Substituted 'errorStack' / 'traceback'

[Alexandre F. <ale...@gm...>]

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

Re: [TCLCORE] CFV TIP #348 - Substituted 'errorStack' / 'traceback'

[Joe E. <jen...@fl...>]

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...

Re: [TCLCORE] CFV TIP #348 - Substituted 'errorStack' / 'traceback'

[Alexandre F. <ale...@gm...>]

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
>

Re: [TCLCORE] Slave interpreters, events and atomicity of callbacks

[Alexandre F. <ale...@gm...>]

On Sat, Oct 24, 2009 at 12:56 AM, k2k2e6 <pa...@pi...> wrote:
>
> I will post this on tcl.lang.
>
> But what we are seeing intermittently is that "slaveInterp eval foo" will
> get executed inside the timer event handler's stack. That causes trouble
> because timer event handler could be in a different namespace as well as
> completely different variable scope.

You won't get better or faster help by posting to this list, instead
of properly following up to the answers you already got on
comp.lang.tcl.

-Alex

Re: [TCLCORE] Slave interpreters, events and atomicity of callbacks

[k2k2e6 <pa...@pi...>]

I will post this on tcl.lang.

But what we are seeing intermittently is that "slaveInterp eval foo" will
get executed inside the timer event handler's stack. That causes trouble
because timer event handler could be in a different namespace as well as
completely different variable scope.

My understanding was that if I did:
interp create foo
foo eval do-something-to-set-up-a-regular-timer-callback
foo eval statement
foo eval statement
foo eval statement
...

The statements should all get evaluated at "stack level 0". We can ascertain
that by doing "foo eval {puts "[info level]"}". But sometimes we see that
the statement is executing at a stack level inside the timer event handler
as well as namespace.

We would like more clarity on this because we would like the Timer callback
to be executed by slave interpreter in an atomic fashion. But clearly, it is
not doing that.

-Pawan



Mark Janssen-6 wrote:
> 
> Hi,
> 
> First of all, these types of questions are probably better posed in
> comp.lang.tcl. This mailing list is for discussion regarding
> development of the Tcl core.
> Secondly, in absense of threads Tcl will only execute one thing at a
> time (even if Tcl is thread enabled). This also means any proc used as
> a callback will be ran till completion before anything else happens.
> The behaviour you are seeing seems caused by the fact that variables
> in a proc are not available globally. And global variables are not
> available in a proc. The whole slave interp seems a red herring. If
> you have a complete script that is confusing you please post it to
> comp.lang.tcl.
> 
> HTH,
> Mark
> 
> On Fri, Oct 23, 2009 at 8:59 PM, k2k2e6 <pa...@pi...> wrote:
>>
>> Guys
>>
>> I have a question about timer events and their atomicity in slave
>> interpreters.
>>
>> Assume that I do the following:
>> interp create slave
>> slave eval after 1000 proc_foo   # proc foo does some work and repeats
>> the
>> after 1000 proc_foo at the end to repeat
>>
>> slave eval set  i 0
>> slave eval puts $i
>> slave eval set  i 0
>> slave eval puts $i
>> ...
>>
>> My question is, when the proc_foo is called, does it execute to
>> completion
>> before any of my subsequent statements get executed or my subsequent
>> statements are interleaved with the statements of proc_foo?
>>
>> We are seeing a problem with interleaving because one can set the
>> variable
>> in the context of proc_foo and then try to get the variable "i" outside
>> the
>> context and one gets "variable not found error".
>>
>> So in slave interpreters, are timer callbacks executed "atomically"?
>>
>> We are seeing that it is not using ActiveState Tcl 8.4.19.2 threaded
>> distribution. The documentation does not clearly state what will happen
>> in
>> this case.
>> --
>> View this message in context:
>> http://www.nabble.com/Slave-interpreters%2C-events-and-atomicity-of-callbacks-tp26031628p26031628.html
>> Sent from the tcl-core mailing list archive at Nabble.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...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
> 
> ------------------------------------------------------------------------------
> 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...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> 
> 

-- 
View this message in context: http://www.nabble.com/Slave-interpreters%2C-events-and-atomicity-of-callbacks-tp26031628p26034375.html
Sent from the tcl-core mailing list archive at Nabble.com.