tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Development on bundled packages

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

As noted recently, we now have a directory tcl/pkgs where we can
distribute bundled packages.  A checkout of the "tcl" module
from CVS will checkout copies of the sources of these packages.

Please note that the packages to be placed here have a life separate
from their bundling with the Tcl core.  They have their own developers,
their own Changelogs, their own Trackers, etc.

If changes need to be made to these bundled packages, they should be
made through the upstream that provides us the packages.  Then when
a corrected release is available, we can bundle that instead.

As much as possible we want to avoid getting into the game of doing
development or maintenance on the packages we bundle.  We want to limit
our role to distributing the work of others.

I'll be reverting Jan's latest entry in the tcl/ChangeLog.  At least
it belongs in tcl/pkgs/tdbc/ChangeLog.  Even better is for it to come
to us in a corrected release of tdbc.

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

[TCLCORE] tip50 accepted

[Arnulf W. <ar...@wi...>]

I am pleased to announce that tip50, which has been a long time at state 
deferred, has yesterday changed to accepted. Thanks to all who have helped to 
make that happen.

As a consequence you will find itcl 4.0 (the current version of itcl-ng) 
bundled to Tcl core distributions (looks like it will be in Tcl 8.6b2)

WARNING! It is only itcl which is bundled to TCL core for itk and itclWidget 
you will still need to use the packages provided here:

http://sourceforge.net/project/showfiles.php?group_id=13244&package_id=295641

I don't know about the plans concerning itcl/itclWidget/itk from ActiveState 
distributions, I think Jeff Hobbs will make a statement to that topic.

Arnulf Wiedemann (apw)

[TCLCORE] musings about tclkit

[Rene Z. <r.z...@fr...>]

Hi everyone,

jcw has give us the great opportunity to run the complete
tcl and tk environment with only one file: tclkits.

Now it seems he has abandoned the further development.
http://groups.google.com/group/vlerq/msg/85a1191cc66bd97c

After nearly one year maintaining kbskit I'm a little bit concerned.
Which way to go?

1. Let everything as is and try to build as long as the
   existing software works and live with readonly kit files.
2. Using metakit means additional C++ hassles. And there
   seems also no further development.
3. Use the basekit's from ActiveState and hope for progress on
   this side. Are there any plans here?
4. Try to tip the kit feature in tcl/tk (something like tommath
   and now tdbc) as an additional/optional feature. The concrete
   implementation (p.e. sqlite as database) is open for discussion.
   No more concerns about the right tclkit. Everyone can use it.
   But there is still the question about the underlying architecture.
   And what do the TCT think about it? Is it possible?
   It could be a long term process without concerns about compatibility.
Some other possibilities?

Regards,
rene

Re: [TCLCORE] zlib redistribution requirements

[Jan N. <jan...@gm...>]

2008/12/19  <dg...@ni...>:

> Have we altered this copy of zlib in any way
> that triggers these requirements?  If so, has
> anyone already taken the required steps to
> prepare for re-distribution of the altered
> source code?

So far, everything is unaltered. However on win32
there is a problem that two neccessary functions
are missing from the dll export. Therefore I
submitted this problem, but didn't receive an
answer yet. Yesterday I registered to be a
zlib developer, so I could contribute this
change (however small) to zlib.

> Should the tcl/compat/zlib directory that we
> distribute include the "license.terms" file
> that goes in (all?) other directories of a
> Tcl source code distribution?

I don't know, but I'll take that up with Mark
Adler and check in the necessary changes.
Below the mail I received from him and my answer.

I'm interested in this because tkImg could
in time use the same zlib1.dll that Tcl
is using. And if people download a new
zlib1.dll from zlib.net (1.2.4, with those
fixes, hopefully) they should not have to
wait for a new Tcl build to make use of it,
just replace the dll.

Regards,
         Jan Nijtmans

2008/12/18 Jan Nijtmans <nij...@us...>:
> 2008/12/18 Mark Adler <ma...@al...>:
>> Hi,
>>
>> Before I sign you up, please let me know how you can contribute to the
>> testing of new versions of zlib.  Thanks for your offer to help.
>
> Starting with version 8.6, zlib will be standard part of Tcl/Tk. See:
>  <http://www.tcl.tk/cgi-bin/tct/tip/234.html>
> Therefore, zlib 1.2.3 has been imported in the Tcl repository
> in sourceforge.
>
> I am currently working in getting everything to build under Windows
> (both msvc and mingw), when I discovered that two symbols were
> missing from win32/zlib.def. I mailed you about that, but didn't
> receive a reaction yet. However, we will try to integrate zlib's
> build into Tcl's build, that's why I'm interested to follow the
> current developments of zlib, and test the build in combination
> with Tcl.
>
> Regards,
>         Jan Nijtmans

[TCLCORE] zlib redistribution requirements

[<dg...@ni...>]

We have a copy of (some subset of?) the zlib sources
now in tcl/compat/zlib, and I believe the
aim is that (some subset of?) these source
files are meant to go into the Tcl source
code distribution.

The zlib project has requirements for anyone
redistributing an altered source distribution.
Have we altered this copy of zlib in any way
that triggers these requirements?  If so, has
anyone already taken the required steps to
prepare for re-distribution of the altered
source code?

See tcl/compat/zlib/FAQ .

Should the tcl/compat/zlib directory that we
distribute include the "license.terms" file
that goes in (all?) other directories of a
Tcl source code distribution?

DGP

[TCLCORE] CVS module redefinitions

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

As part of completing TIP 308 - TDBC, I have redefined the set of
"modules" which can be checked out from the tcl project CVS repository.

The "tcl" module has been redefined, so that if you make a fresh
checkout of it, you will get an additional directory tcl/pkgs/tdbc
containing the bundled copy of the tdbc package.  Any existing checkouts
you have of the "tcl" module won't notice the change.  You have to do
a fresh checkout to get a local copy as defined by the new module
definition.  (Something similar happened when the libtommath directory
was added, you may recall).

The intent is that as more packages get bundled with the Tcl source code
distro, their sources will be added to the "tcl" module with more future
redefinitions of the "tcl" module.  So "tcl" is the name of the
"Tcl + bundled packages" collection that is to be the standard source
code release.

A new module now available for checkout is "tcl_only".  This module
adds the new directory tcl/pkgs but has no subdirectories below that,
so it is effectively a checkout of Tcl only, with none of the bundled
packages.  This new module won't suffer the disruption of needed fresh
checkouts each time a new package joins the bundle.  Also, for
development tasks narrowly focused on improvements to Tcl itself, this
"Tcl only" checkout should be easier to work with as `make` and
`make test` and the like won't be burdened with a lot of building and
testing of packages.

The "tcl_only" module will also make it easy for us to release
a source code distribution with Tcl only, if we determine there's
some value in doing so.

Let me know what questions you have about this change.

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

Re: [TCLCORE] TIPs looking for implementations

[Koen D. <ko...@re...>]

Joe English wrote:
> Kevin Kenny wrote:
>> Donal K. Fellows wrote:
>>>   * TIP#171 should be easy to act on; I've not done it yet because I'm
>>>     not the relevant maintainer.
>> Didn't we do these changes already? Why not? Jeff??
> 
> I (for one) still have unanswered questions about the
> proposed TIP#171 implementation.  Specifically:
> 
> | instead of going through all sorts of rigamarole at
> | the scripting level to redirect MouseWheel events
> | to the widget under the pointer on Windows, wouldn't
> | it make more sense to simply not redirect them to
> | the focus window in the first place (see tkEvent.c,
> | InvokeFocusHandlers)?  That's how it's currently done
> | on OSX.  I suspect it also interferes with some of
> | the ttk::* widgets.
> 
> I agree with the TIP#171 Rationale (paraphrased: "On
> Windows, mouse wheel scrolling should affect the widget
> under the pointer [just like it does on X11 and OSX]
> instead of the widget with keyboard focus.")  But the
> proposed implementation smells really bad to me.
> 
> (The proposed implementation looks like a usable stopgap
> solution for Tk <= 8.5, but long-term it is -- I suspect --
> something we're just going to have to undo later.)

In case anyone is interested in it, I use the C patch below to achieve basically the same as TIP 171, but whithout all the [focus] voodoo going on in that TIP's implementation.


Index: generic/tkEvent.c
===================================================================
RCS file: /cvsroot/tktoolkit/tk/generic/tkEvent.c,v
retrieving revision 1.37
diff -u -r1.37 tkEvent.c
--- generic/tkEvent.c   8 Nov 2008 18:44:39 -0000       1.37
+++ generic/tkEvent.c   25 Nov 2008 11:34:05 -0000
@@ -246,17 +246,7 @@
        return 1;
     }
 
-    /*
-     * MouseWheel events are not focus specific on Mac OS X.
-     */
-
-#ifdef MAC_OSX_TK
-#define FOCUS_DIRECTED_EVENT_MASK (KeyPressMask|KeyReleaseMask)
-#else
-#define        FOCUS_DIRECTED_EVENT_MASK (KeyPressMask|KeyReleaseMask|MouseWheelMask)
-#endif
-
-    if (mask & FOCUS_DIRECTED_EVENT_MASK) {
+    if (mask & (KeyPressMask|KeyReleaseMask)) {
        (*winPtrPtr)->dispPtr->lastEventTime = eventPtr->xkey.time;
        *winPtrPtr = TkFocusKeyEvent(*winPtrPtr, eventPtr);
        if (*winPtrPtr == NULL) {
Index: win/tkWinX.c
===================================================================
RCS file: /cvsroot/tktoolkit/tk/win/tkWinX.c,v
retrieving revision 1.58
diff -u -r1.58 tkWinX.c
--- win/tkWinX.c        27 Apr 2008 22:39:17 -0000      1.58
+++ win/tkWinX.c        25 Nov 2008 11:34:08 -0000
@@ -1006,6 +1006,16 @@
     ThreadSpecificData *tsdPtr = (ThreadSpecificData *)
            Tcl_GetThreadData(&dataKey, sizeof(ThreadSpecificData));
 
+    /* Redirect mousewheel events to the window containing the cursor. */
+    if (message == WM_MOUSEWHEEL) {
+        POINTS rootPoint = MAKEPOINTS(lParam);
+        POINT pos;
+        pos.x = rootPoint.x;
+        pos.y = rootPoint.y;
+        hwnd = WindowFromPoint(pos);
+        winPtr = (TkWindow *) Tk_HWNDToWindow(hwnd);
+    }
+
     if (!winPtr || winPtr->window == None) {
        return;
     }
@@ -1103,11 +1113,6 @@
        break;
 
     case WM_MOUSEWHEEL:
-       /*
-        * The mouse wheel event is closer to a key event than a mouse event
-        * in that the message is sent to the window that has focus.
-        */
-
     case WM_CHAR:
     case WM_UNICHAR:
     case WM_SYSKEYDOWN:

Re: [TCLCORE] TIPs looking for implementations

[Donal K. F. <don...@ma...>]

Michael Kirkham wrote:
> I've started stubbing out TkPNG to work with-or-without the API specified 
> by TIP#234, though I can't guarantee to get that done by Dec 19 
> (especially with Pascal's site still down so I don't have 234's sample 
> implementation to work with or reference).

I had a lot of trouble with Pascal's site too. Luckily, I discovered
that Google Code Search had a cached copy. :-) I've greatly cleaned up
the code and included it in the HEAD of Tcl.

> Mainly this involves changing the ckalloc'ed buffers to byte array 
> Tcl_Objs and implementing versions of some of the 234 APIs within 244, but 
> wrapped in #ifdefs so that TkPNG can be built standalone or against zlib 
> in the core.  It may then need minor changes depending on how 234 actually 
> gets implemented to deal with partial reads/writes (e.g. whether it keeps 
> a copy of leftover data for the next call or holds a reference to the 
> input data Tcl_Obj may affect where I can store the next chunk of data to 
> feed to StreamPut).

It retains references to Tcl_Objs according to the "Hairy Monster"
style, so you'll need to both a) avoid passing refcount 0 objects in,
possibly by wrapping and Incr/Decr pair around the StreamPut, and b) not
reuse objects that you pass in. Don't be afraid to use new objects
though; their allocation path is reasonably optimized...

(No, I don't think I can change how it does reference management. It's
moderately tricky. Do badger me to put some notes on this in the C-level
documentation...)

> TIP#244 shouldn't require changes in Tcl to handle the building that I can 
> think of--that's all on the #234 (zlib) side, unless zlib being optional 
> at build time was still on the table (I though it wasn't) and you for some 
> reason still want to build #244 into Tk with #234 disabled in Tcl.  That 
> wouldn't be my recommendation. :P
> 
> ...or, maybe you meant #234 rather than #244 in your statement.

Right now, the #234 implementation isn't yet done to the degree to which
it should be. In particular, there's a need for more autogoo and a
compatibility inclusion of the zlib sources from a known good version.
(I've done enough that it can detect whether what is available on the
system is sufficient to support #234's features, but not actually the
replacement stuff yet: I'm not on a platform where I need to do that...)
Oh, and there's one feature not yet done.

But from your comments I think you're able to get on and use the APIs
that are there and working already. Well, so long as you are on a
platform with a good enough system zlib. :-)

Donal.

Re: [TCLCORE] TIPs looking for implementations

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

Kevin Kenny wrote:
> Donal K. Fellows wrote:
> >   * TIP#171 should be easy to act on; I've not done it yet because I'm
> >     not the relevant maintainer.
>
> Didn't we do these changes already? Why not? Jeff??

I (for one) still have unanswered questions about the
proposed TIP#171 implementation.  Specifically:

| instead of going through all sorts of rigamarole at
| the scripting level to redirect MouseWheel events
| to the widget under the pointer on Windows, wouldn't
| it make more sense to simply not redirect them to
| the focus window in the first place (see tkEvent.c,
| InvokeFocusHandlers)?  That's how it's currently done
| on OSX.  I suspect it also interferes with some of
| the ttk::* widgets.

I agree with the TIP#171 Rationale (paraphrased: "On
Windows, mouse wheel scrolling should affect the widget
under the pointer [just like it does on X11 and OSX]
instead of the widget with keyboard focus.")  But the
proposed implementation smells really bad to me.

(The proposed implementation looks like a usable stopgap
solution for Tk <= 8.5, but long-term it is -- I suspect --
something we're just going to have to undo later.)


--JE

Re: [TCLCORE] TIP #330 and (void) Tcl_GetStringResult(interp) calls in the core

[Andreas K. <aku...@sh...>]

> Jan Nijtmans wrote:
> > In 7 places in the core I find calls like:
> >      (void) Tcl_GetStringResult(interp)

> > but interp->result is not used afterwards. I'm refering to
> > tclBasic.c (6) and tclHistory.c (1).

> > Shouldn't these calls have been removed as part of the TIP #330
> > implementation? If extensions are not allowed any more to access
> > interp->result directly, then those calss serve no purpose other
> > than slowing down Tcl. It might break extensions which still use
> > interp->result, but due to TIP #330, that's exactly what users of
> > Tcl 8.6 should expect.
 
> If we had made the Tcl_Interp data structure opaque in 8.5, I'd
> agree with you wholeheartedly.  We've moved too slowly on this, and
> been too quiet about the initial warnings.  Since we didn't vote to
> take out interp->result altogether, I'm a little nervous about
> taking out the code that makes it useful, particularly since there's
> not much field experience left (unless Andreas has reported
> something that I've missed) about what this does to currently
> fielded extensions. (He maintains the largest extension distribution
> that I'm aware of.) Andreas, have you tried building the AT
> extension set against 8.6-post-TIP#330?

My apologies for the delay. My win workstation in the office broke
down during the night (suspecting the motherboard) and the majority of
the day was spent getting myself running on a new box. No mail for
most of the day, and right now the shiny new Thunderbird is busy
importing mail from the old LookOut setup.

To the question:

The last AT 8.6 build was done last Sunday against the CVS head as of
Friday afternoon Pacific.

This failed completely. The culprit was an extension critical to the
build which had not been adapted to the missing 'interp->errorLine'
field (TIP #336) yet.

This has all been fixed now (including three more extensions with the
same problem, but not critical to the build) and the next 8.6 build is
this night, using the same Friday afternoon Tcl 8.6.


 
-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

Re: [TCLCORE] TIPs looking for implementations

[Michael K. <mi...@mu...>]

On Tue, 16 Dec 2008, Donal K. Fellows wrote:

>  * TIP#244 requires a chunk of effort to get done, especially as it
>    might result in changes in Tcl too to handle the building. This is
>    probably the biggest single concern right now.

I've started stubbing out TkPNG to work with-or-without the API specified 
by TIP#234, though I can't guarantee to get that done by Dec 19 
(especially with Pascal's site still down so I don't have 234's sample 
implementation to work with or reference).

Mainly this involves changing the ckalloc'ed buffers to byte array 
Tcl_Objs and implementing versions of some of the 234 APIs within 244, but 
wrapped in #ifdefs so that TkPNG can be built standalone or against zlib 
in the core.  It may then need minor changes depending on how 234 actually 
gets implemented to deal with partial reads/writes (e.g. whether it keeps 
a copy of leftover data for the next call or holds a reference to the 
input data Tcl_Obj may affect where I can store the next chunk of data to 
feed to StreamPut).

TIP#244 shouldn't require changes in Tcl to handle the building that I can 
think of--that's all on the #234 (zlib) side, unless zlib being optional 
at build time was still on the table (I though it wasn't) and you for some 
reason still want to build #244 into Tk with #234 disabled in Tcl.  That 
wouldn't be my recommendation. :P

...or, maybe you meant #234 rather than #244 in your statement.

--
Michael Kirkham
President & CEO
Muonics, Inc.
http://www.muonics.com/

Re: [TCLCORE] TIPs looking for implementations

[Kevin K. <ke...@ac...>]

Donal K. Fellows wrote:

>   * TIP#141 is a hold-over from 8.5; we need to decide if we're going to
>     act on this by implementing it, withdrawing it, or do something else.

What's lacking is a Windows implementation, as I understand it.
The other platforms are done.  I looked at what it would take on
Windows, and it's very, very nasty; the native dialog just doesn't
appear to be intended to be driven that way. (It looks *possible*,
but involves ugly reaching into the guts of that dialog box.)

>   * TIP#171 should be easy to act on; I've not done it yet because I'm
>     not the relevant maintainer.

Didn't we do these changes already? Why not? Jeff??

>   * TIP#308 isn't constrained to the same extent as the other TIPs on
>     this list because of its non-standard status: it can be allowed to
>     slip to later than 8.6b1.

TIP #308 also is still holding precisely *because* of that status.
Reasonably complete, documented, implementations (with test suites)
of the TDBC base classes, and the tdbc::odbc and tdbc::sqlite3 sample
drivers are all ready to go; what remains is to sort out the
toolchain issues of building independent packages. I believe dgp
is committed to working on that, and I'm of course willing to
give him whatever help I can.

-- 
73 de ke9tv/2, Kevin

[TCLCORE] TIPs looking for implementations

[Donal K. F. <don...@ma...>]

We're getting there!

After much hard work by many people, the massive tranche of TIPs that
have been voted through are nearly all implemented. There are a few left
at this stage though, so I'm shaking the tree...

These are the TIPs in the Accepted state (where there's implementation
involved; there are non-implementation TIPs in that state too).

   141: Multiple Initial-Files in tk_getOpenFile
   171: Change Default <MouseWheel> Bindings Behavior
   244: PNG Photo Image Support for Tk
   308: Tcl Database Connectivity (TDBC)
   332: Half-Close for Bidirectional Channels

(This is based of http://wiki.tcl.tk/20966 which is where we're keeping
a work-roster of Accepted TIPs and critical bugs...)

Now, to dig into the details of each of them. (They're all different
from each other; you can't generalize.)

  * TIP#141 is a hold-over from 8.5; we need to decide if we're going to
    act on this by implementing it, withdrawing it, or do something else.

  * TIP#171 should be easy to act on; I've not done it yet because I'm
    not the relevant maintainer.

  * TIP#244 requires a chunk of effort to get done, especially as it
    might result in changes in Tcl too to handle the building. This is
    probably the biggest single concern right now.

  * TIP#308 isn't constrained to the same extent as the other TIPs on
    this list because of its non-standard status: it can be allowed to
    slip to later than 8.6b1.

  * TIP#332 has an implementation promised, probably by the end of
    tomorrow (it's in the tests-and-docs stage). I'm not worried about
    it.

Maintainers! If you can help out with any of these, please do!

Is your favourite TIP not on that list? Well, that means one of two
things. Either it's done (modulo implementation issues) or its not going
into Tcl/Tk 8.6 (well, not without a very hard argument).

Donal

Re: [TCLCORE] Another path to case-tolerant package names

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

Jan Nijtmans wrote:
> I am stubborn enough to experiment with a solution that doesn't need
> a second hash table. 

I think I spoke unclearly before.  The real constraint I had
imposed on myself was to achieve what was needed completely at
script level.  Essentially prove that the existing [package]
command was flexible enough (with minimal recasting in ensemble
form) to provide the desired function.  That limitation implies
sticking to one table, but that's not all.

Certainly dropping into C and changing the structures held in
the table, one can achieve what's needed without a second hash table.

> The resulting patch is available at:
> https://sourceforge.net/tracker2/?func=detail&aid=2432057&group_id=10894&atid=310894
> but I'll outline the idea here.

The patch crashes in the test suite.  Not commit ready.

> The idea is, not trying to make package handling case-insensitive, but
> in stead only handle the situation that someone provides a package
> "FooBar" and we want to make it available under the name "foobar"
> as well. 

Ok, so fundamentally the approach is leave [package] unchanged in its
most internal details -- keep it as a fundamentally case sensitive
system -- but add on just enough more to provide illusion of
case insensitivity as a crutch for folks more comfortable with that.
If it worked, I think I could accept that.

However, it doesn't currently work, so I'll mention that I think the
opposite aim would be better.  The momentum as I perceive it is that
package names should have been case insensitive, and packages should
have always been provided all lowercase, and we'd be best to move to a
scheme that in its fundamentals is a case insensitive system, with the
addition of just enough more so that we break as little existing
code as we can.  Then, if the aim is for [package] in, say Tcl 9,
to really become completely case insensitive, we've built a better
bridge to that endpoint.

I have some ideas how to do that, but I don't have a patch to offer,
and I don't know when I can promise time to produce one.  So, if
patch 2432057 can get corrected quickly, I'll defer to that.

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

Re: [TCLCORE] TIP #330 and (void) Tcl_GetStringResult(interp) calls in the core.

[Jan N. <jan...@gm...>]

2008/12/16 Alexandre Ferrieux <ale...@gm...>:
> I'd be happy with a Tcl freezing in 8.x, without a new quantum leap.
> And then rule for 1000 years. Just like the Bourne Shell has been
> frozen for eons, and will rule longer than mankind.

Then how do you explain the existance of
bash (Bourne Again Shell?)  .....  ;-)

(I shouldn't continue this discussion, just couldn't
resist answering that.......I don't really expect an answer..)

Regards,
         Jan Nijtmans

Re: [TCLCORE] TIP #330 and (void) Tcl_GetStringResult(interp) calls in the core.

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

On Tue, Dec 16, 2008 at 4:48 PM, Donald G Porter <dg...@ni...> wrote:
>
> And others might disagree that Tcl 9 is something we will be waiting
> for. :):):)

Indeed :)

I'd be happy with a Tcl freezing in 8.x, without a new quantum leap.
And then rule for 1000 years. Just like the Bourne Shell has been
frozen for eons, and will rule longer than mankind.

-Alex

Re: [TCLCORE] TIP #330 and (void) Tcl_GetStringResult(interp) calls in the core.

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

Jan Nijtmans wrote:
> OK. Looks too dangerous to do it now, but it definitely should be
> considered in a future Tcl version. (In my view it doesn't need to wait
> for Tcl 9, but others might disagree on that)

And others might disagree that Tcl 9 is something we will be waiting 
for. :):):)

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

Re: [TCLCORE] TIP #330 and (void) Tcl_GetStringResult(interp) calls in the core.

[Jan N. <jan...@gm...>]

2008/12/16 Donald G Porter <dg...@ni...>:
> Relevant to this is the message from Adam Williamson several days ago
> reporting Tcl package updates for 8.6 for Mandriva:
>
> https://sourceforge.net/mailarchive/message.php?msg_id=1228554157.29250.12.camel%40lenovo.local.net

OK. Looks too dangerous to do it now, but it definitely should be
considered in a future Tcl version. (In my view it doesn't need to wait
for Tcl 9, but others might disagree on that)

Regards,
          Jan Nijtmans

Re: [TCLCORE] TIP #330 and (void) Tcl_GetStringResult(interp) calls in the core.

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

Kevin Kenny wrote:
> it useful, particularly since there's not much field
> experience left (unless Andreas has reported something
> that I've missed) about what this does to currently fielded
> extensions. (He maintains the largest extension distribution
> that I'm aware of.) Andreas, have you tried building the
> AT extension set against 8.6-post-TIP#330?

Relevant to this is the message from Adam Williamson several days ago
reporting Tcl package updates for 8.6 for Mandriva:

https://sourceforge.net/mailarchive/message.php?msg_id=1228554157.29250.12.camel%40lenovo.local.net

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

Re: [TCLCORE] TIP #330 and (void) Tcl_GetStringResult(interp) calls in the core.

[Kevin K. <ke...@ac...>]

Jan Nijtmans wrote:
> In 7 places in the core I find calls like:
>      (void) Tcl_GetStringResult(interp)
> but interp->result is not used afterwards. I'm
> refering to tclBasic.c (6) and tclHistory.c (1).
> 
> Shouldn't these calls have been removed as part
> of the TIP #330 implementation? If extensions
> are not allowed any more to access interp->result
> directly, then those calss serve no purpose other than
> slowing down Tcl. It might break extensions which still
> use interp->result, but due to TIP #330, that's exactly
> what users of Tcl 8.6 should expect.

If we had made the Tcl_Interp data structure opaque in
8.5, I'd agree with you wholeheartedly.  We've moved too slowly
on this, and been too quiet about the initial warnings.
Since we didn't vote to take out interp->result altogether,
I'm a little nervous about taking out the code that makes
it useful, particularly since there's not much field
experience left (unless Andreas has reported something
that I've missed) about what this does to currently fielded
extensions. (He maintains the largest extension distribution
that I'm aware of.) Andreas, have you tried building the
AT extension set against 8.6-post-TIP#330?

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] TIP #330 and (void) Tcl_GetStringResult(interp) calls in the core.

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

Jan Nijtmans wrote:
> In 7 places in the core I find calls like:
>      (void) Tcl_GetStringResult(interp)
> but interp->result is not used afterwards. I'm
> refering to tclBasic.c (6) and tclHistory.c (1).
> 
> Shouldn't these calls have been removed as part
> of the TIP #330 implementation? 

No.  TIP 330 called for #define USE_INTERP_RESULT
to permit one last path of reprieve for direct access
to interp->result.  Such code needs to remain present
to make that mode work.

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

Re: [TCLCORE] [Fwd: TCL CORE TEAM ANNOUNCES: John Ousterhout retires from Tcl Core Team]

[Donal K. F. <don...@ma...>]

Kevin Kenny wrote:
> Trying again, since the last post has been astray for nearly five hours.

It got through in the end, but it seems that the original was stuck in
your ISP, not SF. (Nearly 6 hours? Yowch!) Can't tell if that was due to
greylisting or just general indigestion.

Donal.

Re: [TCLCORE] Another path to case-tolerant package names

[Jan N. <nij...@us...>]

2008/12/16 Jan Nijtmans <nij...@us...>:
> The only problem there is left, is that autoMkindex.test crashes, I'm
> still trying to debug that (if someone has a good debugger, I appreciate
> help in tracing this down, somewhere still is a bug).

Found the bug: forgot to check pkgPtr->version != NULL before
trying to ckfree() it....

Uploaded a new patch to:
https://sourceforge.net/tracker2/?func=detail&aid=2432057&group_id=10894&atid=310894
which passes all tests, including a few added ones.

Any feedback is welcome. Is this a valid alternative to TIP #339?

Regards,
      Jan Nijtmans

[TCLCORE] TIP #330 and (void) Tcl_GetStringResult(interp) calls in the core.

[Jan N. <jan...@gm...>]

In 7 places in the core I find calls like:
     (void) Tcl_GetStringResult(interp)
but interp->result is not used afterwards. I'm
refering to tclBasic.c (6) and tclHistory.c (1).

Shouldn't these calls have been removed as part
of the TIP #330 implementation? If extensions
are not allowed any more to access interp->result
directly, then those calss serve no purpose other than
slowing down Tcl. It might break extensions which still
use interp->result, but due to TIP #330, that's exactly
what users of Tcl 8.6 should expect.

Regards,
         Jan Nijtmans

[TCLCORE] [Fwd: TCL CORE TEAM ANNOUNCES: Daniel Steffen named to Tcl Core Team.]

[Kevin K. <kk...@ny...>]

A second attempt at sending this message; the first has not
shown up in over four hours, and I suspect that it went astray.

-- 
73 de ke9tv/2, Kevin