tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Build problem with 8.6b1 on XP if dirs have whitespace

[Ashok P. N. <apn...@ya...>]

Trying to build 8.6b1 on XP, I got the following error message:

makefile.vc(1006) : fatal error U1087: cannot have : and :: dependents 
for same target

It was of course immediately obvious from the message that the problem 
was caused by spaces in the source directory path :-)

8.5.2 had no problems with spaces in directory paths. The changes in 8.6 
that cause it to break are the setting of ROOT and BINROOT in 
makefile.vc to be absolute paths using $(MAKEDIR)\.. rather than 
relative paths using ".." as in 8.5.2

My questions are - is this known/expected behaviour or should I log a 
bug? If the former, is there a way to check for whitespace and exit with 
a more appropriate error message so folks like me don't spend half the 
afternoon trying to figure out what's wrong? I couldn't figure out how 
one might do this within NMAKE's very limited capabilities.

Also, setting the variables as in 8.5.2 completed the build fine. So is 
the use of $(MAKEDIR) really necessary? I can understand the logic 
behind trying to make paths absolute to protect against changing 
directories within the build process but at least right now it does not 
appear necessary.

/Ashok

Re: [TCLCORE] build problem with amsn and 8.6b1

[Youness A. <kak...@ka...>]

On Sat, Jan 03, 2009 at 04:01:43PM -0800, Adam Williamson wrote:
> On Sun, 2008-12-28 at 17:50 -0500, Youness Alaoui wrote:
> 
> > Hi,
> > I'm KaKaRoTo, project manager and developer of aMSN.
> > I've just registered to this list so we can discuss this
> > issue further.
> > 
> > >  Yeah, well, it's amsn, it's not noted for its incredibly
> > >  code quality ;)
> > >  
> > Thanks :(
> 
> I'm sorry about that, it was a bad way to put it. What I really meant is
> that amsn is a fast-moving project dealing with an inherently tricky
> area (MSN) and with a lot of developers, and (as you said later in the
> thread) it tries to maintain wide compatibility with various versions of
> Tcl and other stuff - so it's probably inevitable that it will be more
> about code that works than code that is whiter than snow :)
> 
hehe, don't worry about it, I know exactly what amsn's code
looks like, and I can only agree! I was just kidding, no
problems there and no need for justifications! :)

> BTW, for my situation - packaging AMSN in our development branch, on Tcl
> 8.6 - would you recommend using SVN rather than 0.97.2? I had a few
> problems building SVN when I tried, but I could go back and give it
> another shot.
> 

Humm.. for 8.6.. I think neither 0.97.2 or SVN will compile
at this point, I'll keep in touch with you in private when
we fix the 8.6 compilation issues in SVN.
When it's done, you should package farsight2 and libnice
with it so you can do audio calls with aMSN out of the box
(see http://amsn-project.net/wiki/Farsight)

> Thanks a lot for all the work you do on AMSN.
Thanks! :)

> -- 
> adamw
> http://www.happyassassin.net

Re: [TCLCORE] build problem with amsn and 8.6b1

[Youness A. <kak...@ka...>]

On Wed, Dec 31, 2008 at 01:26:21PM +0100, Jan Nijtmans wrote:
> 2008/12/31 Youness Alaoui <kak...@ka...>:
> > ok, I see, I'll look into it... copy the structure, then
> > modify it, and replace the existing clientData seems easy
> > enough.. taking care of the cleanup might be a bit tricky
> > though.. however, I don't see why it would be necessary..
> > wouldn't the core already clean the structure itself with a
> > ckfree ? so if we allocate it with a ckalloc, then to Tk,
> > it's just a heap allocated pointer that needs to be freed,
> > right ? We would however need to free the original structure
> > after we replace it with our own.
> 
> You cannot free the original structure, because it is
> shared between all images with the same handler!
> What amsn could do is copy the structure, make
> the modifications, and keep that structure
> globally fore each image where it is needed.
> Just don't copy it for each image separately,
> then I think it would work.
> 
Humm.. ok, thanks for the advices, we'll look into it!

> However, after jan. 5 I will have a look at it
> more closely. At least I will change the
> name field to use CONST86 in stead of
> const, so aMSN will compile out of the
> box when compliling it with -DCONST86=""
> 
ok, well it's not really necessary because the name field
has to stay as a const. using the -DCONST86 trick will only
hide bugs. Anyways, it's fixed in SVN already so it's not a
problem, and if anyone tries to compile the latest stable on
8.6, I prefer that he gets a compilation error instead of a
bug once he launches aMSN. Which is what's currently
happening with tk 8.5.6 because it doesn't strdup the name
anymore but it didn't set the field as const.. 

Thanks,
KaKaRoTo

> Regards,
>         Jan Nijtmans

[TCLCORE] ANN: TDBC 1.0b5 with driver for MySQL

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

I am pleased to announce that the current baseline of TDBC,
tagged '1.0b5' and bearing the ID, 46df70f083, is available.
This release includes what I believe to be functionally
complete versions of the TDBC base classes and tokenizer
(matching the versions on the Tcl HEAD), together with the
following three drivers:

tdbc::odbc - A bridge that allows connection to any ODBC-compliant
              database.  This module builds on Windows, and is
              expected to build on any Unix system with the 'unixodbc'
              package.

tdbc::sqlite3 - A connector that joins TDBC to SQLite3. This
                 connector is written in pure Tcl (using the 'sqlite3'
                 extension), and is expected to run anywhere that
                 SQLite3 runs.

tdbc::mysql - A connector that joins TDBC to MySQL. This connector
               demands headers and libraries for MySQL 5.1 or better.
               It is all-new C code, not directly derived from Artur
               Trzewik's fine 'mysqltcl' binding. It uses the MySQL
               prepared statement interface, so it is expected to be
               relatively immune to SQL insertion attacks, without
               depending on mysql_real_escape_string or relatives.

These modules are all obtainable as as single ZIP archive at
http://tdbc.tcl.tk/

All three of these modules can be built and installed on Unix
with a typical Posix toolchain, and on Windows with msys/mingw.

Obviously, more work needs to be done for TDBC to achieve world
domination.  Important further work that is needed:

(1) Revise the 'errorCode' lists returned by the various TDBC
     commands to make more sense with Tcl's new [try] command.
     This is a fairly mechanical project. Contact me directly
     if you're interested in taking it on, and I'll advise about
     what needs to be done.

(2) All three of these modules need Makefile.vc, for building
     with Visual Studio on Windows systems.

(3) Binary distributions for the various platforms need to be
     packaged.

(4) More drivers are needed!  I know that various people over
     the last few months have volunteered to work on drivers, but
     I haven't been maintaining a registry of who's doing what.
     I think that the project Wiki at tdbc.tcl.tk would be a
     good place to do that.  In particular, people have requested:

       - pgsql
       - Sql Server native API
       - Oracle

     and several less popular databases.

(5) Packaging advice is needed from downstream distributors,
     particularly as regards the package dependencies. The database
     drivers usually have complex dependencies; for instance,
     tdbc::sqlite depends at run time on TDBC itself, and on
     the 'sqlite3' Tcl extension. (Being a pure Tcl solution,
     it has no build-time dependencies.) tdbc::mysql depends
     on mysql 1.5 or better (built with threads), and this is
     a build-time dependency because it needs #include files
     and a link library.  Clearly, we don't want to bundle
     all the dependencies with Tcl itself.

Bugs and feature requests can be logged at http://tdbc.tcl.tk/
I welcome broader exposure of all three of these modules,
which while still 'experimental', should be considered as
being on track for release.

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] build problem with amsn and 8.6b1

[Adam W. <awi...@ma...>]

On Sun, 2008-12-28 at 17:50 -0500, Youness Alaoui wrote:

> Hi,
> I'm KaKaRoTo, project manager and developer of aMSN.
> I've just registered to this list so we can discuss this
> issue further.
> 
> >  Yeah, well, it's amsn, it's not noted for its incredibly
> >  code quality ;)
> >  
> Thanks :(

I'm sorry about that, it was a bad way to put it. What I really meant is
that amsn is a fast-moving project dealing with an inherently tricky
area (MSN) and with a lot of developers, and (as you said later in the
thread) it tries to maintain wide compatibility with various versions of
Tcl and other stuff - so it's probably inevitable that it will be more
about code that works than code that is whiter than snow :)

BTW, for my situation - packaging AMSN in our development branch, on Tcl
8.6 - would you recommend using SVN rather than 0.97.2? I had a few
problems building SVN when I tried, but I could go back and give it
another shot.

Thanks a lot for all the work you do on AMSN.
-- 
adamw
http://www.happyassassin.net

Re: [TCLCORE] build problem with amsn and 8.6b1

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

2008/12/31 Youness Alaoui <kak...@ka...>:
> ok, I see, I'll look into it... copy the structure, then
> modify it, and replace the existing clientData seems easy
> enough.. taking care of the cleanup might be a bit tricky
> though.. however, I don't see why it would be necessary..
> wouldn't the core already clean the structure itself with a
> ckfree ? so if we allocate it with a ckalloc, then to Tk,
> it's just a heap allocated pointer that needs to be freed,
> right ? We would however need to free the original structure
> after we replace it with our own.

You cannot free the original structure, because it is
shared between all images with the same handler!
What amsn could do is copy the structure, make
the modifications, and keep that structure
globally fore each image where it is needed.
Just don't copy it for each image separately,
then I think it would work.

However, after jan. 5 I will have a look at it
more closely. At least I will change the
name field to use CONST86 in stead of
const, so aMSN will compile out of the
box when compliling it with -DCONST86=""

Regards,
        Jan Nijtmans

Re: [TCLCORE] build problem with amsn and 8.6b1

[Youness A. <kak...@ka...>]

Apparently, I need to group-reply for your mailing list..
sorry!

----- Forwarded message from Youness Alaoui <kak...@ka...> -----

From: Youness Alaoui <kak...@ka...>
To: Jan Nijtmans <jan...@gm...>
Subject: Re: [TCLCORE] build problem with amsn and 8.6b1

On Tue, Dec 30, 2008 at 11:31:38AM +0100, Jan Nijtmans wrote:
> 2008/12/28 Youness Alaoui
> > Well, first problem was that Tk was doing a copy on the
> > image format, now it doesn't anymore, it requires it to be
> > const. This also broke aMSN with tk 8.5.6.. it compiled but
> > the image formats were screwed so the extension wasn't
> > working correctly anymore with [image create
> > photo -format cximage ..]
> 
> The reason why this was changed is that the client
> data for an image is shared between all images in
> the same thread. So changing the image format
> for one image is changing it for all images created
> for the image handler as well. That's tricky, and
> asking for trouble. I didn't know any extension
> doing that, now I do.
> 
ok, no problem.. actually, we only that did because
TkCximage uses one single library for all those formats, so
that structure was exactly the same for all formats, it's
just the name that changed, so we just had one structure and
a list of char* that we strduped + free-ed after adding the
format to Tk...
Now, I just created multiple copies of the structure... not
much worse, just less 'nice' in the code to read...

> > I fixed that in aMSN SVN, You can see the diff here :
> > http://amsn.svn.sourceforge.net/viewvc/amsn?view=rev&revision=10818
> 
> Fine to hear that it is fixed in aMSN now, so it is not
> necessary to revert this "potiential incompatibility" in Tk.
> 

yes, no need to revert it in Tk, we're doing it the right
way now!

> > About the other issue, I'm not very familiar with that
> > code.. but I do remember that aMSN could easily take 100% of
> > CPU because of animated gif images (usually smileys).. so we had to
> > make a hack.. we hook the photo image displayProc and we only update the image
> > of an animated GIF if it is being drawn on screen (so
> > smileys in a conversation won't be refreshed unless they are
> > in the viewable area).
> 
> This problem should be fixed in Tk itself. I suggest you
> to submit a problem report about this one in Tk's tracker
> and assign it to me. Than I will check this out. If
> you could provide a patch for Tk, that would be great,
> then starting with Tk 8.6b2 the aMSN hack will not
> be necessary any more.
> 

well, the problem is that aMSN is 8.4 compatible and we want
to keep it that way, we don't want to force anyone to
upgrade, especially since some people are using some distros
which are still bound to the 8.4 version.
Also, the problem is that, assuming we have 100 anigif
images, each having a 100ms delay between frames, it means
that every 100ms, we'll fire up 100 timers and call
Tk_PhotoPutBlock... I don't see how Tk would be able to fix
this from the core.. those 100 timers, and those 100
memcpy-es are going to cost us a lot in CPU power, and
that's even if Tk does an "if (!mapped) return" in
Tk_PhotoPutBlock... (actually, we also convert the gif image
into an RGBA array on each operation).
I'm not really sure how the hack works, but I think that
instead of doing the img->ConvertToRGBA(..) then
Tk_PhotoPutBlock, it just flags the image as dirty and it
does the Tk_PhotoPutBlock in the displayProc hook.. so if
the image is not viewable, then the displayProc is not
called, and the Tk_PhotoPutBlock doesn't get called... 
It would be nice if it was fixed in the core, but as I said,
I don't really see a way for it to be fixed in the core..
unless you have some design ideas that would help make this
possible.
There's also the problem of it being 8.4 compatible (and not
necessarly the latest 8.4.x), so our hack has to stay there
anyways unfortunately...

> > still cast it... but more importantly,  how can we
> > modify that structure in a thread-safe way?
> 
> The only way is allocate a new structure, copy
> the information and modify it, then change the
> clientData of the image to point to the new
> structure. But then the extension is responsible
> for cleanup the structure. Tricky, but possible.
> However, it would be better to fix this in Tk,
> so aMSN does not need this hack any more.
> 

ok, I see, I'll look into it... copy the structure, then
modify it, and replace the existing clientData seems easy
enough.. taking care of the cleanup might be a bit tricky
though.. however, I don't see why it would be necessary..
wouldn't the core already clean the structure itself with a
ckfree ? so if we allocate it with a ckalloc, then to Tk,
it's just a heap allocated pointer that needs to be freed,
right ? We would however need to free the original structure
after we replace it with our own.

Thanks!

KaKaRoTo

> Regards,
>        Jan Nijtmans

----- End forwarded message -----

[TCLCORE] TIP #344: Bring TCP_NODELAY and SO_KEEPALIVE to socket options

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

 TIP #344: BRING TCP_NODELAY AND SO_KEEPALIVE TO SOCKET OPTIONS 
================================================================
 Version:      $Revision: 1.1 $
 Author:       Alexandre Ferrieux <alexandre.ferrieux_at_gmail.com>
 State:        Draft
 Type:         Project
 Tcl-Version:  8.6
 Vote:         Pending
 Created:      Wednesday, 31 December 2008
 URL:          http://purl.org/tcl/tip/344.html
 WebEdit:      http://purl.org/tcl/tip/edit/344
 Post-History: 

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

 ABSTRACT 
==========

 Just expose to script level, via *fconfigure*, the two most important 
 setsockopt() use cases: TCP_NODELAY (disabling the Nagle agorithm) and 
 SO_KEEPALIVE (sending automatic keepalives). 

 BACKGROUND & RATIONALE 
========================

 Currently, there is no way to set nodefault values to a Tcl socket's 
 underlying socket options TCP_NODELAY and SO_KEEPALIVE. That is 
 frustrating because all TCP stacks support setsockopt(). 

 Of these two options, the most important I guess is TCP_NODELAY. 
 Indeed, the Nagle algorithm being on by default may introduce unwanted 
 latencies in some specific cases. This TIP does not try to argument 
 about the prevalence of these cases; the ubiquity of 
 setsockopt(TCP_NODELAY) suffices to justify exposing it to script 
 level. 

 PROPOSED CHANGE 
=================

 This TIP proposes to add two boolean [fconfigure] options to sockets: 
 *-nodelay* (or *-nonagle*, or *-nagle*, take your pick) and 
 *-keepalive*. 

 REFERENCE IMPLEMENTATION 
==========================

 Pretty trivial; will be provided shortly after validation. The code has 
 even been in place for a long time, though only in the Windows-specific 
 part, and commented/ifdef'ed out... 

 COPYRIGHT 
===========

 This document has been placed in the public domain. 

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

 TIP AutoGenerator - written by Donal K. Fellows 

Re: [TCLCORE] build problem with amsn and 8.6b1

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

2008/12/28 Youness Alaoui
> Well, first problem was that Tk was doing a copy on the
> image format, now it doesn't anymore, it requires it to be
> const. This also broke aMSN with tk 8.5.6.. it compiled but
> the image formats were screwed so the extension wasn't
> working correctly anymore with [image create
> photo -format cximage ..]

The reason why this was changed is that the client
data for an image is shared between all images in
the same thread. So changing the image format
for one image is changing it for all images created
for the image handler as well. That's tricky, and
asking for trouble. I didn't know any extension
doing that, now I do.

> I fixed that in aMSN SVN, You can see the diff here :
> http://amsn.svn.sourceforge.net/viewvc/amsn?view=rev&revision=10818

Fine to hear that it is fixed in aMSN now, so it is not
necessary to revert this "potiential incompatibility" in Tk.

> About the other issue, I'm not very familiar with that
> code.. but I do remember that aMSN could easily take 100% of
> CPU because of animated gif images (usually smileys).. so we had to
> make a hack.. we hook the photo image displayProc and we only update the image
> of an animated GIF if it is being drawn on screen (so
> smileys in a conversation won't be refreshed unless they are
> in the viewable area).

This problem should be fixed in Tk itself. I suggest you
to submit a problem report about this one in Tk's tracker
and assign it to me. Than I will check this out. If
you could provide a patch for Tk, that would be great,
then starting with Tk 8.6b2 the aMSN hack will not
be necessary any more.

> still cast it... but more importantly,  how can we
> modify that structure in a thread-safe way?

The only way is allocate a new structure, copy
the information and modify it, then change the
clientData of the image to point to the new
structure. But then the extension is responsible
for cleanup the structure. Tricky, but possible.
However, it would be better to fix this in Tk,
so aMSN does not need this hack any more.

Regards,
       Jan Nijtmans

Re: [TCLCORE] build problem with amsn and 8.6b1

[Youness A. <kak...@ka...>]

 
>  On Thu, 2008-12-25 at 01:55 +0100, Michael Schlenker wrote:

>  >  > Thanks, but with those changes:
>  >  > 
>  >  > utils/TkCximage/src/TkCximage.cpp: In function int
>  >  > PlaceHook(Tcl_Interp*):
>  >  > utils/TkCximage/src/TkCximage.cpp:227: error:
>  >  > assignment of data-member Tk_ImageType:
>  >  > :displayProc in read-only structure

>  >  Hmm, yes not sure if thats a bug in the CONSTification of
>  >  that API or a
>  >  bug in TkCximage. Basically Tk_GetImageMasterData now
>  >  returns a const
>  >  and the TkCximage code tries to modify it. If i
>  >  understand it correctly
>  >  it should use the ClientData to get at the MasterData
>  >  structure and
>  >  modifiy it instead.
>  >  
>  >  > utils/TkCximage/src/TkCximage.cpp: In function int
>  >  > Tkcximage_Init(Tcl_Interp*):
>  >  > utils/TkCximage/src/TkCximage.cpp:316: error: invalid
>  >  > conversion from const char* 
>  >  > to char*
>  >  > utils/TkCximage/src/TkCximage.cpp:316: error:
>  >  > initializing argument 1 of char* strc
>  >  > py(char*, const char*)
>  >  This is another change in 8.6b1, the structure
>  >  > Tk_PhotoImageFormat
>  >  changed, its name member is now const char*.
>  >  
>  >  Not really awake enough to give better hints how to fix
>  >  it, but the code
>  >  you pasted has some more obvious weaknesses (mismatched
>  >  new[], deletes,
>  >  mispelled variables etc.).

Hi,
I'm KaKaRoTo, project manager and developer of aMSN.
I've just registered to this list so we can discuss this
issue further.

>  Yeah, well, it's amsn, it's not noted for its incredibly
>  code quality ;)
>  
Thanks :(

>  Thanks for the pointers, if I still can't get it, I guess
>  I'll bug upstream.

Well, first problem was that Tk was doing a copy on the
image format, now it doesn't anymore, it requires it to be
const. This also broke aMSN with tk 8.5.6.. it compiled but
the image formats were screwed so the extension wasn't
working correctly anymore with [image create
photo -format cximage ..]

I fixed that in aMSN SVN, You can see the diff here :
http://amsn.svn.sourceforge.net/viewvc/amsn?view=rev&revision=10818

About the other issue, I'm not very familiar with that
code.. but I do remember that aMSN could easily take 100% of
CPU because of animated gif images (usually smileys).. so we had to
make a hack.. we hook the photo image displayProc and we only update the image
of an animated GIF if it is being drawn on screen (so
smileys in a conversation won't be refreshed unless they are
in the viewable area).
That's why we had to modify the MasterData... that hack just
saved a lot of CPU cycles.....

Michael said :
>  Hmm, yes not sure if thats a bug in the CONSTification of
>  that API or a bug in TkCximage. Basically Tk_GetImageMasterData now
>  returns a const and the TkCximage code tries to modify it. If i
>  understand it correctly it should use the ClientData to get at the MasterData
>  structure and  modifiy it instead.

Well, I don't know exactly how that's supposed to work, the
man page says that the clientData returned is 'typically'
the master data structure.. but 'typically' doesn't
guarantee that it's always the case... either way, we could
still cast it... but more importantly,  how can we
modify that structure in a thread-safe way?

That's it,

Thanks,
KaKaRoTo

Re: [TCLCORE] build problem with amsn and 8.6b1

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

2008/12/25 Adam Williamson <awi...@ma...>:
> On Wed, 2008-12-24 at 17:16 -0800, Joe English wrote:
>
>> Adam -- for now, try compiling with '-DCONST86=""'.  That may
>> work around the problem.
>
> Indeed, that avoids the first problem, leaving me with only:
>
> utils/TkCximage/src/TkCximage.cpp: In function 'int Tkcximage_Init(Tcl_Interp*)':
> utils/TkCximage/src/TkCximage.cpp:316: error: invalid conversion from 'const char*' to 'char*'
> utils/TkCximage/src/TkCximage.cpp:316: error:   initializing argument 1 of 'char* strcpy(char*, const char*)'

Looks like there is a small compatibility problem.
Defining -DCONST86="" should restore compatibility
in all cases. That can be fixed by defining the
name field as "CONST86 char *" in stead of
¨const char *" in the Tk header file. I just didn't
consider the possibility that anyone would
do a strcpy to this name field, but if that
helps to restore source compatibility
with amsn, then that's a good change.

However, a strcpy to an allocated string of
unknown length, I don't know if that's a
good idea anyway. I definitely would file
this as a bug to the amsn people, and
see what they come up with before
trying to fix it in a place where it
doesn't belong.

Regards,
          Jan Nijtmans

Re: [TCLCORE] build problem with amsn and 8.6b1

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

2008/12/25 Adam Williamson <awi...@ma...>:
> utils/TkCximage/src/TkCximage.cpp: In function 'int Tkcximage_Init(Tcl_Interp*)':
> utils/TkCximage/src/TkCximage.cpp:316: error: invalid conversion from 'const char*' to 'char*'
> utils/TkCximage/src/TkCximage.cpp:316: error:   initializing argument 1 of 'char* strcpy(char*, const char*)'
>
>> [ BTW, Adam: are you subscribed to tcl-core?  If so, I'll stop Cc:ing you. ]

Another reason to make this change was to make Tk's code thread-safe
w.r.t. the registration of image types. The name field is shared between
multiple threads, so it is dangerous to change it. I don´t know
TkCximage, but it looks like it is doing dangerous things with Tk, that
were dangerous before as well.

Line 316 of TkCximage.cpp can probably be fixed by a simple (char *) type
case. But I would have a better look at the code what TkCximage.cpp
is doing really.

Regards,
         Jan Nijtmans

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

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

2008/12/24 Adam Williamson <awi...@ma...>:
> FWIW, I'm against this. The current state of #330 is that 8.6 explicitly
> allows a 'hack' to re-enable interp->result, as a transitional measure,
> and it is stated that 9.0 will remove any possibility to use
> interp->result. Thus changes that would break the use of interp->result
> should only be done in 9.0, not 8.6.

Don´t worry! The reactions convinced me of the same. However,
in the mean time I was thinking about a better way to keep the
current contract, and still improve the curent duality between
interp->result and interp->objResult.

This idea, in short, is a new object type "dstring", which
is nothing more than a DString wrapped in an object. We can
simply change Tcl_GetStringResult() such that it modifies the
current objResult type to be a "dstring". Then we simply
let interp->result point to de dstring of interp->objResult and
the two versions point to the same. It would simplyfy a lot
other functions as well, like Tcl_AppendResult or
Tcl_ObjPrintf, and it can be made such that all StringResult
functions keep the current behavior, only it prevents the
constant conversion between string and Tcl_Obj.

Anyway, it's just an idea that has to be worked out further,
maybe for Tcl 8.7 (maybe not).

Regards,
          Jan Nijtmans

Re: [TCLCORE] build problem with amsn and 8.6b1

[Adam W. <awi...@ma...>]

On Wed, 2008-12-24 at 17:16 -0800, Joe English wrote:

> Adam -- for now, try compiling with '-DCONST86=""'.  That may
> work around the problem.

Indeed, that avoids the first problem, leaving me with only:

utils/TkCximage/src/TkCximage.cpp: In function ‘int Tkcximage_Init(Tcl_Interp*)’:
utils/TkCximage/src/TkCximage.cpp:316: error: invalid conversion from ‘const char*’ to ‘char*’
utils/TkCximage/src/TkCximage.cpp:316: error:   initializing argument 1 of ‘char* strcpy(char*, const char*)’

> [ BTW, Adam: are you subscribed to tcl-core?  If so, I'll stop Cc:ing you. ]

Yes, I am.
-- 
adamw

Re: [TCLCORE] build problem with amsn and 8.6b1

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

Adam Williamson wrote:

> Hi, folks. Well, I thought I had no problems with 8.6b1, but now I
> notice amsn no longer builds. The errors are:
>
> utils/TkCximage/src/TkCximage.cpp: In function ‘int PlaceHook(Tcl_Interp*)’:
> utils/TkCximage/src/TkCximage.cpp:224: error: invalid conversion from ‘Tk_Imag
> eType**’ to ‘const Tk_ImageType**’

Looks like this was the relevant change:

| 2008-11-11  Jan Nijtmans  <nij...@us...>
|	[...]
|       * generic/tk.decls     Modify Tk_Create(Old)ImageType signature,
|       * generic/tk.h         relaxing the constraint that every Tk_ImageType
|       * generic/tkImage.c    can only be passed to this function once. This
|       * generic/tkImgBmap.c  lets tkImg be loaded in multiple interpreters
|       * generic/tkImgPhoto.c in a thread-enabled build of Tk. [Bug 2312027]
|       * generic/tkTest.c     This CONSTification complies with TIP #27. It
|       * doc/CrtImgType.3     is binary compatible with the old interface,
|                              but not fully source compatible (although tkImg
|                              does not suffer).
|       * generic/tkDecls.h (regenerated)
|       *** POTENTIAL INCOMPATIBILITY ***


Despite the comment, I'm not sure that this really is compliant
with TIP#27.  It introduces a contravariant 'const' qualifier,
which breaks source compatibility, which TIP#27 explicitly specified
should not be done unless absolutely necessary.  From a quick look
at [Bug 2312027], it appears that this was not absolutely necessary
in this case.  Suggest we revert the CONSTipation.  (From a quick
scan through the other uses of CONST86, it looks like few if any
of them are absolutely necessary either.)

Adam -- for now, try compiling with '-DCONST86=""'.  That may
work around the problem.

[ BTW, Adam: are you subscribed to tcl-core?  If so, I'll stop Cc:ing you. ]


--Joe English

  jen...@fl...

Re: [TCLCORE] build problem with amsn and 8.6b1

[Adam W. <awi...@ma...>]

On Thu, 2008-12-25 at 01:55 +0100, Michael Schlenker wrote:

> > Thanks, but with those changes:
> > 
> > utils/TkCximage/src/TkCximage.cpp: In function ‘int PlaceHook(Tcl_Interp*)’:
> > utils/TkCximage/src/TkCximage.cpp:227: error: assignment of data-member ‘Tk_ImageType::displayProc’ in read-only structure

> Hmm, yes not sure if thats a bug in the CONSTification of that API or a
> bug in TkCximage. Basically Tk_GetImageMasterData now returns a const
> and the TkCximage code tries to modify it. If i understand it correctly
> it should use the ClientData to get at the MasterData structure and
> modifiy it instead.
> 
> > utils/TkCximage/src/TkCximage.cpp: In function ‘int Tkcximage_Init(Tcl_Interp*)’:
> > utils/TkCximage/src/TkCximage.cpp:316: error: invalid conversion from ‘const char*’ to ‘char*’
> > utils/TkCximage/src/TkCximage.cpp:316: error:   initializing argument 1 of ‘char* strcpy(char*, const char*)’
> This is another change in 8.6b1, the structure Tk_PhotoImageFormat
> changed, its name member is now const char*.
> 
> Not really awake enough to give better hints how to fix it, but the code
> you pasted has some more obvious weaknesses (mismatched new[], deletes,
> mispelled variables etc.).

Yeah, well, it's amsn, it's not noted for its incredibly code quality ;)

Thanks for the pointers, if I still can't get it, I guess I'll bug
upstream.
-- 
adamw

Re: [TCLCORE] build problem with amsn and 8.6b1

[Michael S. <sc...@un...>]

Adam Williamson schrieb:
> On Thu, 2008-12-25 at 01:15 +0100, Michael Schlenker wrote:
> 
>> The compiler is bitching about const correctness, the second error
>> should have nothing to do with Tcl at all, unless you inherit compiler
>> flags from the Tcl build machinery.
> 
> That's odd, as it definitely built with 8.6a3 a couple of weeks ago.
> Maybe something else changed in Cooker in the meantime, though I can't
> think of anything. We haven't changed GCC or anything.
> 
>> So the error in line 316 could probably be fixed by something like this
>> in line 259 of your paste (add an additional const):
>> const char *const KnownFormats[] = {"cximage", "cxgif", "cxpng",
>> "cxjpg", "cxtga", "cxbmp"};
>>
>> or by just casting away the const...
Okay, this was probably wrong on my side. Having a little headache from
a cold..., and not too awake now.
>>
>> The other error is similar, but a new 8.6 issue, the signature for
>> Tk_GetImageMasterData changed to:
>> (from tk.decls)
>> declare 98 generic {
>>   407     ClientData Tk_GetImageMasterData(Tcl_Interp *interp,
>>   408 	    const char *name, CONST86 Tk_ImageType **typePtrPtr)
>>   409 }
>>
>> So changing line 223 to:
>> CONST86 Tk_ImageType *typePhotoPtr = NULL;
>>
>> might fix it.
> 
> Thanks, but with those changes:
> 
> utils/TkCximage/src/TkCximage.cpp: In function ‘int PlaceHook(Tcl_Interp*)’:
> utils/TkCximage/src/TkCximage.cpp:227: error: assignment of data-member ‘Tk_ImageType::displayProc’ in read-only structure
Hmm, yes not sure if thats a bug in the CONSTification of that API or a
bug in TkCximage. Basically Tk_GetImageMasterData now returns a const
and the TkCximage code tries to modify it. If i understand it correctly
it should use the ClientData to get at the MasterData structure and
modifiy it instead.

> utils/TkCximage/src/TkCximage.cpp: In function ‘int Tkcximage_Init(Tcl_Interp*)’:
> utils/TkCximage/src/TkCximage.cpp:316: error: invalid conversion from ‘const char*’ to ‘char*’
> utils/TkCximage/src/TkCximage.cpp:316: error:   initializing argument 1 of ‘char* strcpy(char*, const char*)’
This is another change in 8.6b1, the structure Tk_PhotoImageFormat
changed, its name member is now const char*.

Not really awake enough to give better hints how to fix it, but the code
you pasted has some more obvious weaknesses (mismatched new[], deletes,
mispelled variables etc.).

Michael

Re: [TCLCORE] build problem with amsn and 8.6b1

[Adam W. <awi...@ma...>]

On Thu, 2008-12-25 at 01:15 +0100, Michael Schlenker wrote:

> The compiler is bitching about const correctness, the second error
> should have nothing to do with Tcl at all, unless you inherit compiler
> flags from the Tcl build machinery.

That's odd, as it definitely built with 8.6a3 a couple of weeks ago.
Maybe something else changed in Cooker in the meantime, though I can't
think of anything. We haven't changed GCC or anything.

> So the error in line 316 could probably be fixed by something like this
> in line 259 of your paste (add an additional const):
> const char *const KnownFormats[] = {"cximage", "cxgif", "cxpng",
> "cxjpg", "cxtga", "cxbmp"};
> 
> or by just casting away the const...
> 
> The other error is similar, but a new 8.6 issue, the signature for
> Tk_GetImageMasterData changed to:
> (from tk.decls)
> declare 98 generic {
>   407     ClientData Tk_GetImageMasterData(Tcl_Interp *interp,
>   408 	    const char *name, CONST86 Tk_ImageType **typePtrPtr)
>   409 }
> 
> So changing line 223 to:
> CONST86 Tk_ImageType *typePhotoPtr = NULL;
> 
> might fix it.

Thanks, but with those changes:

utils/TkCximage/src/TkCximage.cpp: In function ‘int PlaceHook(Tcl_Interp*)’:
utils/TkCximage/src/TkCximage.cpp:227: error: assignment of data-member ‘Tk_ImageType::displayProc’ in read-only structure
utils/TkCximage/src/TkCximage.cpp: In function ‘int Tkcximage_Init(Tcl_Interp*)’:
utils/TkCximage/src/TkCximage.cpp:316: error: invalid conversion from ‘const char*’ to ‘char*’
utils/TkCximage/src/TkCximage.cpp:316: error:   initializing argument 1 of ‘char* strcpy(char*, const char*)’
-- 
adamw

Re: [TCLCORE] build problem with amsn and 8.6b1

[Michael S. <sc...@un...>]

Adam Williamson schrieb:
> Hi, folks. Well, I thought I had no problems with 8.6b1, but now I
> notice amsn no longer builds. The errors are:
> 
> utils/TkCximage/src/TkCximage.cpp: In function ‘int PlaceHook(Tcl_Interp*)’:
> utils/TkCximage/src/TkCximage.cpp:224: error: invalid conversion from ‘Tk_ImageType**’ to ‘const Tk_ImageType**’
> utils/TkCximage/src/TkCximage.cpp:224: error:   initializing argument 3 of ‘void* Tk_GetImageMasterData(Tcl_Interp*, const char*, const Tk_ImageType**)’
> utils/TkCximage/src/TkCximage.cpp: In function ‘int Tkcximage_Init(Tcl_Interp*)’:
> utils/TkCximage/src/TkCximage.cpp:316: error: invalid conversion from ‘const char*’ to ‘char*’
> utils/TkCximage/src/TkCximage.cpp:316: error:   initializing argument 1 of ‘char* strcpy(char*, const char*)’
> 
> the code in question:
> 
> http://pastebin.ca/1293142
> 
> what's broken? It looks like something that's likely very obvious to a
> hacker, so I remind the list that I'm not one. :) I tried poking a bit
> randomly at the variable types but only succeeded in breaking things
> more, so I thought I'd quit and ask a grown-up for help ;)

The compiler is bitching about const correctness, the second error
should have nothing to do with Tcl at all, unless you inherit compiler
flags from the Tcl build machinery.

So the error in line 316 could probably be fixed by something like this
in line 259 of your paste (add an additional const):
const char *const KnownFormats[] = {"cximage", "cxgif", "cxpng",
"cxjpg", "cxtga", "cxbmp"};

or by just casting away the const...

The other error is similar, but a new 8.6 issue, the signature for
Tk_GetImageMasterData changed to:
(from tk.decls)
declare 98 generic {
  407     ClientData Tk_GetImageMasterData(Tcl_Interp *interp,
  408 	    const char *name, CONST86 Tk_ImageType **typePtrPtr)
  409 }

So changing line 223 to:
CONST86 Tk_ImageType *typePhotoPtr = NULL;

might fix it.

Michael

[TCLCORE] build problem with amsn and 8.6b1

[Adam W. <awi...@ma...>]

Hi, folks. Well, I thought I had no problems with 8.6b1, but now I
notice amsn no longer builds. The errors are:

utils/TkCximage/src/TkCximage.cpp: In function ‘int PlaceHook(Tcl_Interp*)’:
utils/TkCximage/src/TkCximage.cpp:224: error: invalid conversion from ‘Tk_ImageType**’ to ‘const Tk_ImageType**’
utils/TkCximage/src/TkCximage.cpp:224: error:   initializing argument 3 of ‘void* Tk_GetImageMasterData(Tcl_Interp*, const char*, const Tk_ImageType**)’
utils/TkCximage/src/TkCximage.cpp: In function ‘int Tkcximage_Init(Tcl_Interp*)’:
utils/TkCximage/src/TkCximage.cpp:316: error: invalid conversion from ‘const char*’ to ‘char*’
utils/TkCximage/src/TkCximage.cpp:316: error:   initializing argument 1 of ‘char* strcpy(char*, const char*)’

the code in question:

http://pastebin.ca/1293142

what's broken? It looks like something that's likely very obvious to a
hacker, so I remind the list that I'm not one. :) I tried poking a bit
randomly at the variable types but only succeeded in breaking things
more, so I thought I'd quit and ask a grown-up for help ;)
-- 
adamw

Re: [TCLCORE] Tcl/Tk 8.6b1 Release Candidates

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

Adam Williamson wrote:
>
> OK. So, in sum, for a regular distribution, we should put the .la file
!!-------------------------------------------------------------^^^^^ [*]
> in /usr/lib , but everything else - the tdbcConfig.sh file and even
> the .so - can go to /usr/lib/tcl(version)/tdbc(version), and everything
> normal should work?

Yes.  To the best of my knowledge, that's correct [*].

> And I may as well cut the TDBC_LIB_SPEC line out of
> tdbcConfig.sh entirely as it wouldn't ever be any use in that situation?

I think that should also be safe, insofar as it
would not break anything new.


--Joe English

  jen...@fl...

[*] Assuming that ".la" was a typo and you really meant ".a".
    If you really *did* mean ".la" -- as in "libtool .la file" --
    then something has gone horribly wrong.  I hope it was a typo.

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

[Adam W. <awi...@ma...>]

On Tue, 2008-12-16 at 11:49 +0100, 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.

(after writing this i see that DGP already did, but to add weight, I'll
send it anyway).

FWIW, I'm against this. The current state of #330 is that 8.6 explicitly
allows a 'hack' to re-enable interp->result, as a transitional measure,
and it is stated that 9.0 will remove any possibility to use
interp->result. Thus changes that would break the use of interp->result
should only be done in 9.0, not 8.6.

In practical terms, for the Mandriva 8.6 migration, I could not properly
fix some obscure Tcl packages not to use interp->result, not being a
strong enough coder, so I had to use the hack to re-enable it for those
packages. If it stops working it'd cause me rather a bit of
inconvenience as I have to either a) learn enough to fix that code
myself or b) find someone else to do it. I was rather counting on having
the time until the 9.0 release to do that, not having to try and get it
done for 8.6.
-- 
adamw

Re: [TCLCORE] Tcl/Tk 8.6b1 Release Candidates

[Adam W. <awi...@ma...>]

On Tue, 2008-12-23 at 17:52 -0800, Joe English wrote:
> Adam Williamson wrote:
> >
> > OK. So, in sum, for a regular distribution, we should put the .la file
> !!-------------------------------------------------------------^^^^^ [*]
> > in /usr/lib , but everything else - the tdbcConfig.sh file and even
> > the .so - can go to /usr/lib/tcl(version)/tdbc(version), and everything
> > normal should work?
> 
> Yes.  To the best of my knowledge, that's correct [*].
> 
> > And I may as well cut the TDBC_LIB_SPEC line out of
> > tdbcConfig.sh entirely as it wouldn't ever be any use in that situation?
> 
> I think that should also be safe, insofar as it
> would not break anything new.
> 
> 
> --Joe English
> 
>   jen...@fl...
> 
> [*] Assuming that ".la" was a typo and you really meant ".a".
>     If you really *did* mean ".la" -- as in "libtool .la file" --
>     then something has gone horribly wrong.  I hope it was a typo.

Yes, it was a typo, sorry. :) Thanks for the confirmation. That is how I
have packaged b1 into Mandriva just now.
-- 
adamw

Re: [TCLCORE] Tcl/Tk 8.6b1 Release Candidates

[Adam W. <awi...@ma...>]

On Mon, 2008-12-22 at 09:25 -0500, Kevin Kenny wrote:

> "Should never ever happen, by policy" is too strong a phrase
> for what's going on.  "Shouldn't happen in a regular old binary
> distribution" is closer to the truth.  There are a few people
> who, for special purposes, build their own applications that
> link everything statically. To do this, they configure Tcl
> and all needed extensions --disable-shared, and then concoct
> a link unit that includes Tcl and all necessary extensions
> as static libraries. The only case where <module>_LIB_SPEC
> would be needed is to support such a build. It appears that
> TEA's configurator fills in <module>_LIB_SPEC in all cases,
> but actually tries to build and install the library only in
> a --disable-shared build.

OK. So, in sum, for a regular distribution, we should put the .la file
in /usr/lib , but everything else - the tdbcConfig.sh file and even
the .so - can go to /usr/lib/tcl(version)/tdbc(version), and everything
normal should work? And I may as well cut the TDBC_LIB_SPEC line out of
tdbcConfig.sh entirely as it wouldn't ever be any use in that situation?
-- 
adamw

[TCLCORE] Tcl/Tk 8.5.6 RELEASED

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

Tcl/Tk 8.5.6 Release Announcement
December 23, 2008

The Tcl Core Team is pleased to announce the 8.5.6 releases of the Tcl
dynamic language and the Tk toolkit.  This is the sixth 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.6 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.5:
--------------------------------------

The following were the main changes in Tcl/Tk 8.5.6.  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 included bug fixes and corrections
to erratic behavior.  Below are only the most notable changes.

    * Keyboard bindings for ttk::scale.

    * [wm manage] now limited to frame-like widgets.

    * Fix ability to join threads on 64-bit Windows.

    * Fixed parser errors expanding literals like: {*}{\{} .

    * New version 2.7.2 of http package:
      - restored ability to read SHOUTcast streams.

    * Permit [text] widget names containing "-".

    * Prevent hang during channel finalization.

    * Stop crash using nondefault visual.

    * Fix [seek] exposing channels to all interps.

    * Tk_Create*ImageType() routines now thread safe.

    * Stop tempfile litter from [load] from VFS.

    * Fixed [file normalize] of some paths returned by [glob].

    * New version 1.1.4 of platform::shell package:
      - compatibility with changes in Tcl Modules.

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