tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] zlib push and fcopy

[Pat T. <pat...@us...>]

I've been pursuing a problem on some platforms with the http package
handling compressed http streams. The problem is something to do with
fcopy and pushed zlib channels. Now I've come up with the following
proposed test:

test zlib-9.4 "socket fcopy (gzip)" -constraints zlib -setup {
    set srv [socket -server {apply {{c a p} {
        puts "connect from $a:$p"
        chan configure $c -encoding binary -translation binary
        puts -nonewline $c [zlib gzip [string repeat a 81920]]
        close $c
    }}} 0]
    set file [makeFile {} test.gz]
} -body {
    lassign [chan configure $srv -sockname] addr name port
    set sin [socket $addr $port]
    chan configure $sin -translation binary
    zlib push gunzip $sin
    update
    set fout [open $file wb]
    after 1000 {set ::total timeout}
    fcopy $sin $fout -command {apply {{c {e {}}} {
        set ::total [expr {$e eq {} ? $c : $e}]
    }}}
    vwait ::total
    close $sin; close $fout
    list read $::total size [file size $file]
} -cleanup {
    close $srv
} -returnCodes {ok error} -result {read 81920 size 81920}

If you comment out the zlib push line in the test body this will work
but the size of the copied data is the compressed size (obviously)
of 115 bytes. Note that this is under the size of the buffering size
of 4K.
When the zlib push is in effect fcopy will be expecting to be provided
with 81920 bytes. However it always hangs up and the timeout
terminates the test.
This matches what I see in the http package where the combination of
the -channel option and compression causes us to use fcopy from the
socket (including zlib pushed transform) to the output channel. In the
http case I see one block followed by an eof but there are more blocks
to be copied. If I ignore the eof and keep repeating the fcopy I
eventualy get all the data.
So my guess is that the channel framework recieves one chunk of 115
and generates a fileevent for the zlib transform which pushes a
buffersize block. Then its got eof but also has data buffered. For
some reason I reckon it is never generating further events for fcopy.

So. Is the above invalid for some reason? Should I be expecting this
to work differently. The only real difference between the above test
and what is used in the http package is that the http code uses style
3 from the fcopy man page (watches the progress by repeating the fcopy
call from the -command).

-- 
Pat Thoyts                            http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD

[TCLCORE] TDBC 1.0b12 released

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

I am happy to announce release 1.0b12 of TDBC.  This is the most
recent of the frequent beta releases of the TDBC core and driver code.

Source code of TDBC, and all the drivers, can be obtained by the
following steps:

(1) Open a browser and go to http://tdbc.tcl.tk/index.cgi/login

(2) Log in as 'anonymous' - the password is shown on that page.

(3) Once you are logged in, go to the page for the 1.0b12 release:
     http://tdbc.tcl.tk/index.cgi/ci/26f1376281

(4) Download the source code by clicking on the [ZIP Archive] link
     in the 'Commands:' line at the bottom of the first paragraph.

Win32 binaries and HTML documentation for the 1.0b11 release are
available from SourceForge at:

https://sourceforge.net/project/showfiles.php?group_id=10894&package_id=305160

The files to be found there are:

tdbc1.0b12-win32.zip:

This file contains Win32 binaries of the database drivers for TDBC. To
install it, unzip the file, and then run 'wish86.exe' passing it the
INSTALL.TCL file in the resulting directory. Thereafter, tclsh and
wish should be able to do

     [package require tdbc::mysql]

     [package require tdbc::odbc]

and

     [package require tdbc::sqlite3]

tdbc1.0b12-doc.zip:

This file contains HTML documentation for the TDBC drivers. The
'contents.html' file in its root directory is the entry point to the
documentation and contains the links to everything else.

----

Significant changes since the 1.0b11 release:

tdbc:
         A bug in an adapter for drivers that have yet to adopt method
         forwarding to define their statement and result set classes
         was fixed.  http://tdbc.tcl.tk/index.cgi/tktview?name=e70d9fdce1

tdbc::odbc:
         Several bugs in interfacing with SQL Server Express were fixed,
         and the test suite was upgraded so that SQL Server interfacing
         can be tested routinely.
         http://tdbc.tcl.tk/index.cgi/tktview?name=e70d9fdce1

Packaging:
	Missing code for tdbc::odbc was returned to the binary
         distributions.

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] [MACTCL] Merging TkAqua Cocoa port into Tk HEAD

[Kevin W. <kw...@co...>]

Daniel A. Steffen wrote:

> 
> the TkAqua Cocoa merge has now been committed
> 
> 	http://fisheye.categorifiedcoder.info/changelog/Tk?cs=MAIN:das:20090629143501
>
Bravo, Daniel. Thanks for your superb work.

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [TCLCORE] [MACTCL] Merging TkAqua Cocoa port into Tk HEAD

[Tim J. <tj...@to...>]

On Jun 29, 2009, at 11:26 AM, Russell E. Owen wrote:

> Thank you very much for writing the Cocoa port.

Agreed!

> Thank you also for providing 10.4 backwards compatibility via  
> making the old Carbon code accessible. (I can't make my code 10.5- 
> only yet, but look forward to the day that I can.) That seems like  
> an excellent solution to a tricky problem. With any luck Snow  
> Leopard will encourage more folks to upgrade past 10.4 (as an an  
> inexpensive upgrade that is primarily performance enhancements and  
> bug fixes).

Unfortunately, it's only cheap if upgrading from Leopard.  It's full  
price for Tiger or Panther users :-(.

Tim

Re: [TCLCORE] Merging TkAqua Cocoa port into Tk HEAD

[<lm...@bi...>]

As one of the loudest complainers about the compat issue, my heartfelt 
thanks.  If santa needs to bring you a new laptop (or whatever), his
email is lm...@bi....

On Mon, Jun 29, 2009 at 07:10:34PM +0200, Daniel A. Steffen wrote:
> On Sun, May 17, 2009 at 10:43, Daniel A.
> Steffen<da...@us...> wrote:
> > The Cocoa port has now been feature complete for about a month and I
> > believe is of equal or better quality than the existing TkAqua
> > implementation, it has been built, tested and is already being used
> > successfully by various parties, and IMO is now ready to be merged
> > into the Tk mainline.
> 
> the TkAqua Cocoa merge has now been committed
> 
> 	http://fisheye.categorifiedcoder.info/changelog/Tk?cs=MAIN:das:20090629143501
> 
> sorry for the delay, it took longer than expected to find time for the
> buildsystem modifications needed to make the legacy implementation a
> configure option: indeed, given the reactions to my initial plan to
> drop pre-10.5 support completely, I have now preserved the legacy
> tk/macosx codebase in the new tk/carbon directory. The --enable-aqua
> Tk configure flag turns on the new Cocoa implementation by default,
> use --enable-aqua=carbon to fallback to the Carbon implementation.
> 
> As announced previously, I will however not continue to maintain the
> Carbon code on HEAD (except possibly for parallel application of Tk
> 8.5 bugfixes), I have included the warning below in the
> tk/carbon/README to make this explicit (if a new maintainer for this
> code were to step forward, they can of course amend that statement as
> they see fit).
> 
> Cheers,
> 
> Daniel
> 
> --
> ** Daniel A. Steffen                   **
> ** <mailto:da...@us...>  **
> 
> 
> Tcl/TkAqua Carbon Mac OS X README
> ---------------------------------
> 
> RCS: @(#) $Id: README,v 1.1 2009/06/26 01:42:46 das Exp $
> 
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> ! This is the README for tk/carbon, the legacy version of TkAqua based on the  !
> ! Carbon API. This version of TkAqua is deprecated and no longer actively      !
> ! supported, it will be removed in a future release of Tk. It is only useful   !
> ! for users requiring support of Mac OS X releases older than 10.5.            !
> ! The supported version of TkAqua is located in tk/macosx and is based on the  !
> ! Cocoa API. It requires Mac OS X 10.5 or later.                               !
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [TCLCORE] Merging TkAqua Cocoa port into Tk HEAD

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

On Sun, May 17, 2009 at 10:43, Daniel A.
Steffen<da...@us...> wrote:
> The Cocoa port has now been feature complete for about a month and I
> believe is of equal or better quality than the existing TkAqua
> implementation, it has been built, tested and is already being used
> successfully by various parties, and IMO is now ready to be merged
> into the Tk mainline.

the TkAqua Cocoa merge has now been committed

	http://fisheye.categorifiedcoder.info/changelog/Tk?cs=MAIN:das:20090629143501

sorry for the delay, it took longer than expected to find time for the
buildsystem modifications needed to make the legacy implementation a
configure option: indeed, given the reactions to my initial plan to
drop pre-10.5 support completely, I have now preserved the legacy
tk/macosx codebase in the new tk/carbon directory. The --enable-aqua
Tk configure flag turns on the new Cocoa implementation by default,
use --enable-aqua=carbon to fallback to the Carbon implementation.

As announced previously, I will however not continue to maintain the
Carbon code on HEAD (except possibly for parallel application of Tk
8.5 bugfixes), I have included the warning below in the
tk/carbon/README to make this explicit (if a new maintainer for this
code were to step forward, they can of course amend that statement as
they see fit).

Cheers,

Daniel

--
** Daniel A. Steffen                   **
** <mailto:da...@us...>  **


Tcl/TkAqua Carbon Mac OS X README
---------------------------------

RCS: @(#) $Id: README,v 1.1 2009/06/26 01:42:46 das Exp $

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! This is the README for tk/carbon, the legacy version of TkAqua based on the  !
! Carbon API. This version of TkAqua is deprecated and no longer actively      !
! supported, it will be removed in a future release of Tk. It is only useful   !
! for users requiring support of Mac OS X releases older than 10.5.            !
! The supported version of TkAqua is located in tk/macosx and is based on the  !
! Cocoa API. It requires Mac OS X 10.5 or later.                               !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Re: [TCLCORE] 8.6b2 Approaches...

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

On Fri, Jun 12, 2009 at 10:36 PM, Vasiljevic Zoran<zv...@ar...> wrote:
>
> On 11.06.2009, at 17:26, Donal K. Fellows wrote:
>
>>   * Thread extension as a "standard contributed package" (i.e., like
>>     TDBC and itcl). In conjunction with this, the default
>> configuration
>>     for Tcl will probably be changed to be thread-enabled; users of
>>     expect and TclX's [fork] may need to be more proactive in the
>>     future.
>
> Interesting...
> So... what (and when, most importantly) I need to do?

Since you're asking ;-)
I would appreciate a review of 2001201 with GPS's patch. George and I
believe it is the rational way out of a whole family of nasty
exit+thread related bugs (filter by keyword "exit" on open bugs on
SF). The POV of the Thread extension would usefully complement this
core view.

-Alex

Re: [TCLCORE] 8.6b2 Approaches...

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

Jan Nijtmans wrote:
> 2009/6/11 Donal K. Fellows <don...@ma...>:
>> So what's left before b2? As far as I'm aware, there are only two key
>> issues that we need to fix first:
> 
> 
> How about:
>   <http://sourceforge.net/tracker/?func=detail&atid=110894&aid=2487771&group_id=10894>
> ?

I did say that bug fixing was always on topic. I also said that we 
wouldn't hold the b2 release for it. (That particular issue is tough to 
tackle and isn't one that I've been able to make headway on; the issue 
is that there are two internal APIs for evaluating a script, one of 
which supports NRE and the other gets [source]-originated annotations 
correct.)

Donal.

Re: [TCLCORE] 8.6b2 Approaches...

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

Vasiljevic Zoran wrote:
> On 11.06.2009, at 17:26, Donal K. Fellows wrote:
> 
>>   * Thread extension as a "standard contributed package" (i.e., like
>>     TDBC and itcl). In conjunction with this, the default  
>> configuration
>>     for Tcl will probably be changed to be thread-enabled; users of
>>     expect and TclX's [fork] may need to be more proactive in the
>>     future.
> 
> Interesting...
> So... what (and when, most importantly) I need to do?

Other than fixing bugs (especially ones that cause crashes)? :-)

It might be an idea to think about a synchronized release so that the 
version that goes out with 8.6b2 will also be available to previous 
versions of Tcl.

There's no plan to make changes to Thread's code or management for b2 
(assuming we get an integrated build going) and about the only thing 
that we might really tinker with for final is the documentation, which 
will have to be delivered in nroff format primarily (like that we 
process it into our "house style" HTML). That's truly trivial stuff. 
Given that it's already in the Tcl repository, I don't think this is a 
big change.

Donal.

Re: [TCLCORE] 8.6b2 Approaches...

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

2009/6/11 Donal K. Fellows <don...@ma...>:
> So what's left before b2? As far as I'm aware, there are only two key
> issues that we need to fix first:


How about:
  <http://sourceforge.net/tracker/?func=detail&atid=110894&aid=2487771&group_id=10894>
?

Regards,
          Jan Nijtmans

Re: [TCLCORE] 8.6b2 Approaches...

[Vasiljevic Z. <zv...@ar...>]

On 11.06.2009, at 17:26, Donal K. Fellows wrote:

>   * Thread extension as a "standard contributed package" (i.e., like
>     TDBC and itcl). In conjunction with this, the default  
> configuration
>     for Tcl will probably be changed to be thread-enabled; users of
>     expect and TclX's [fork] may need to be more proactive in the
>     future.

Interesting...
So... what (and when, most importantly) I need to do?

Cheers,
Zoran

[TCLCORE] 8.6b2 Approaches...

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

Hi everyone...

This is just a quick note to let everyone know that it's not that long 
before we get Tcl/Tk 8.6b2 released. It's been rather a long time since 
b1 and we really ought to have another release before .0 gets shipped 
(where the plan is to have that for the Tcl Conference).

So what's left before b2? As far as I'm aware, there are only two key 
issues that we need to fix first:

   * Thread extension as a "standard contributed package" (i.e., like
     TDBC and itcl). In conjunction with this, the default configuration
     for Tcl will probably be changed to be thread-enabled; users of
     expect and TclX's [fork] may need to be more proactive in the
     future.

   * Dan Steffen's Tk-on-Cocoa updates for OSX.

These are selected because they answer specific strategic requirements 
going forward (i.e., threads are needed to take good advantage of modern 
multicore hardware, and Apple are strongly signalling that Carbon — the 
library we've been using for Tk — will be going away soon). There are 
other potential "nice to have"s out there, but these are the ones that 
will need proper in-service testing for 8.6.0.

Of course, we want as many crash-bugs fixed as possible too, but we 
won't hold the b2 release for them.

Cue the flak. :-)

Donal.

[TCLCORE] TDBC 1.0b11 released

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

I am happy to announce release 1.0b11 of TDBC.  This is the most
recent of the frequent beta releases of the TDBC core and driver code.

Source code of TDBC, and all the drivers, can be obtained by the
following steps:

(1) Open a browser and go to http://tdbc.tcl.tk/index.cgi/login

(2) Log in as 'anonymous' - the password is shown on that page.

(3) Once you are logged in, go to the page for the 1.0b11 release:
     http://tdbc.tcl.tk/index.cgi/ci/26bb9fcd1e

(4) Download the source code by clicking on the [ZIP Archive] link
     in the 'Commands:' line at the bottom of the first paragraph.

Win32 binaries and HTML documentation for the 1.0b11 release are
available from SourceForge at:

https://sourceforge.net/project/showfiles.php?group_id=10894&package_id=305160

The files to be found there are:

tdbc1.0b11-win32.zip:

This file contains Win32 binaries of the database drivers for TDBC. To
install it, unzip the file, and then run 'wish86.exe' passing it the
INSTALL.TCL file in the resulting directory. Thereafter, tclsh and
wish should be able to do

     [package require tdbc::mysql]

     [package require tdbc::odbc]

and

     [package require tdbc::sqlite3]

tdbc1.0b11-doc.zip:

This file contains HTML documentation for the TDBC drivers. The
'contents.html' file in its root directory is the entry point to the
documentation and contains the links to everything else.

----

The only significant change since the 1.0b10 release is that large
character objects in the tdbc::odbc interface no longer include extra
NUL characters in the middle of their data. [Bug ticket 04d164f7d0]


-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] Tk embedding and xembed

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

Marcelo Taube wrote:
> I would like to know if XEMBED was not implemented in Tk as ideological 
> decision or just because noone is willing to write it. If that is the 
> case i would like to volunteer to do the job, since i really need that 
> feature.

I can say, without a shadow of a doubt, that it was due to nobody having
written the code so far. There are no ideological constraints, and I
know that inaction here reveals just that the current maintainers are
not focussed on this area. :-) We would definitely welcome a patch.

As a matter of interest, which version of Tk will you be targeting? I
only ask because this is the sort of thing that will probably be worth
backporting quite far (and that should be easy; as you know this is not
a part that's changed frequently...)

The official patch submission mechanism is via SourceForge.
    https://sourceforge.net/tracker/?func=add&group_id=12997&atid=312997
Please use Category #55; you'll see why. :-)

Donal.

[TCLCORE] Tk embedding and xembed

[Marcelo T. <mai...@gm...>]

Hello,
I am a developer trying to embed a tk application inside a gtk application.
It doesn't work that well, specially there are focus problems.

I have done some debugging of the problem. Gtk assumes that the embedded
window will implement the XEMBED conventions protocol, but Tk uses a model
which is more based on the older concepts of focus of X11.

Gtk usually grabs the XServer focus to its main window and passes keyboard
events down to the subwindows holding the "gtk focus" by its own subsystems,
in contrast Tk respects much more the original meaning of the XServer focus.

I think Tk is right in some way, because the original intention of the X
protocol was to have toolkits use the X focus as their focus. However since
the release of the original protocol specification, most of the x11 experts
agreed that is logical to expect applications to grab the focus to their
main window. Thats why the XEMBED protocol was released.

GTK respects XEMBED and sends X_EMBED_FOCUS_IN and X_EMBED_FOCUS_OUT
messages instead of regular FocusIn and FocusOut events to the X server. Tk
insists on recieving the regular events and they just cannot communicate
well.

I would like to know if XEMBED was not implemented in Tk as ideological
decision or just because noone is willing to write it. If that is the case i
would like to volunteer to do the job, since i really need that feature.

Thanks
Marcelo

[TCLCORE] Be a voice of OSS Scan Community

[Jasmine T. <ja...@pa...>]

Hi TCL Core -

At, Daniel Steffen's suggestion, I'd like to see if any of you are  
willing to participate in this. We would like to get at least one  
person to speak on behalf of TCL...

Three years ago, the Scan Program was established to discern a  
baseline for software quality and security in open source software.  
Over the years, the latest innovations in automated defect detection  
have been applied to open source projects to uncover some of the most  
critical types of defects found in software.

Each year, Coverity releases a Scan Report containing information  
about the changing integrity of various  of open source projects, and  
this year Coverity would like to invite leaders from participating  
projects to contribute to the conversation.

Now that the Scan Project has run successfully for three years, the  
media is paying closer attention to what the overall open source  
software community has learned and how they've been able to use Scan  
to improve the quality and security of code.

In conjunction with the release of the 2009 Scan Report, we'd like to  
interview you as a leading member of the Postfix community, and we'd  
like to share your opinions on Scan and Postfix's growth as a secure  
code base with the media who consistently cover the Scan Report.

We believe the success of the Scan Project has been because of  
involvement like yours, which drives increasingly higher standards for  
open source software code, and for that, we would like to bring  
publicity to what the Postfix community has accomplished under Scan.

Please consider being a voice of the Scan community. If you are  
willing to participate, please respond to this email. If you have any  
questions, we'd be happy to answer them.

Best regards,
Jasmine Teer
Coverity Public Relations/ Page One



Jasmine Teer
PageOne San Francisco
ja...@pa...
415.321.2348 office
510.387.0384 mobile
415.398.3886 fax

Re: [TCLCORE] Be a voice of OSS Scan Community

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

Hi Jasmine,

apologies, I have been very busy and hadn't gotten around to respond  
yet.
Unfortunately I don't think I have the time at the moment to  
participate. However, I know that there are other Coverity users among  
the Tcl core team and the Tcl maintainers that have handled/fixed bugs  
detected by Scan, so I would suggest you contact the Tcl core team as  
a whole, it is very possible another team member would be willing to  
participate. The address to use is tcl...@li... (CCd).

Thanks!

Cheers,

Daniel

-- 
** Daniel A. Steffen                   **
** <mailto:da...@us...>  **

On 28/05/2009, at 0:40, Jasmine Teer wrote:

> I just wanted to reach out to you again to see if you'd be willing  
> to participate in the release of the 2009 Scan Report by being a  
> voice of the Scan community. Please see my note below and let me  
> know. If you have any questions, I'd be more than happy to answer  
> them.
>
> Best regards,
> Jasmine Teer
>
> On May 22, 2009, at 4:56 PM, Jasmine Teer wrote:
>
>> Hi Daniel-
>>
>> Three years ago, the Scan Program was established to discern a  
>> baseline for software quality and security in open source software.  
>> Over the years, the latest innovations in automated defect  
>> detection have been applied to open source projects to uncover some  
>> of the most critical types of defects found in software.
>>
>> Each year, Coverity releases a Scan Report containing information  
>> about the changing integrity of various  of open source projects,  
>> and this year Coverity would like to invite leaders from  
>> participating projects to contribute to the conversation.
>>
>> Now that the Scan Project has run successfully for three years, the  
>> media is paying closer attention to what the overall open source  
>> software community has learned and how they've been able to use  
>> Scan to improve the quality and security of code.
>>
>> In conjunction with the release of the 2009 Scan Report, we'd like  
>> to interview you as a leading member of the TCL community, and we'd  
>> like to share your opinions on Scan and TCL's growth as a secure  
>> code base with the media who consistently cover the Scan Report.
>>
>> We believe the success of the Scan Project has been because of  
>> involvement like yours, which drives increasingly higher standards  
>> for open source software code, and for that, we would like to bring  
>> publicity to what the TCL community has accomplished under Scan.
>>
>> Please consider being a voice of the Scan community. If you are  
>> willing to participate, please respond to this email, and we'll  
>> schedule time to speak to you next week. If you have any questions,  
>> we'd be happy to answer them.
>>
>> Best regards,
>> Jasmine Teer
>> Coverity Public Relations/ Page One
>>
>> <logo_pageonepr.gif>
>>
>> Jasmine Teer
>> PageOne San Francisco
>> ja...@pa...
>> 415.321.2348 office
>> 510.387.0384 mobile
>> 415.398.3886 fax
>>
>

Re: [TCLCORE] The end for Tcl_PrintDouble in Tk?

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

Jeff Hobbs wrote:

> On 20/05/2009 7:26 AM, Donal K. Fellows wrote:
> > That sort of shortening looks good, but you might also consider using %g
> > instead of %f so that very large text and canvas widgets can still scroll.
>
> I tried that, which causes test failures of a different variety (you get
> "1"/"0" instead of "1.0"/"0.0").

See also #2112563.  The test suite *used* to expect "1" / "0",
and when #2112563 was fixed the test suite had to be updated to
expect "1.0" / "0.0" instead.

This is arguably a bug in the test suite.

> Don noted that that could cause issues
> with expr as dividing by float 0.0 (non-error Inf) has different
> behavior than int 0 (error).

My 2c: I don't think it matters *which* error you get if
you divide by zero.  [$sb set Inf Inf] is going to do the wrong
thing anyway.


--Joe English

Re: [TCLCORE] The end for Tcl_PrintDouble in Tk?

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

Michael Kirkham wrote:
>
> This may not be a direct opinion as to your specific question, but both of
> those look (IMHO) like throwbacks from the days before objects. Assuming
> the precision change isn't an issue, why wouldn't you use...
>
>       EntryVisibleRange(entryPtr, &first, &last);
>       objPtr = Tcl_DuplicateObj(entryPtr->scrollCmd);
>       Tcl_ListObjAppendElement(interp, objPtr, Tcl_NewDoubleObj(first));
        ^^^^^^^^^^^^^^^^^^^^^^^^

Because the -[xy]scrollcommand is a script prefix (i.e., a string),
not a command prefix (i.e., a list).

In the vast overwhelming majority of cases, -[xy]scrollcommand
is indeed a proper list, but it's also possible to do stuff like:

    listbox .l -yscrollcommand { puts "I've been scrolled!" ; .sb set }


--Joe English

Re: [TCLCORE] The end for Tcl_PrintDouble in Tk?

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

Jeff Hobbs wrote:

> In looking into the best solution for 2790615
> https://sourceforge.net/tracker/?func=detail&atid=112997&aid=2790615&group_id
> =12997
> Don noted that Tcl_ObjPrintf (added in 8.5) or Tcl_AppendFormatToObj
> would be good alternatives to the coding changes I was using.
>
> This would change, eg tkEntry.c:EntryUpdateScrollbar from (partial):
> [ ... Tcl_PrintDouble ... ]
> to:
>      EntryVisibleRange(entryPtr, &first, &last);
>      objPtr = Tcl_ObjPrintf("%s %f %f", entryPtr->scrollCmd, first, last);
>      Tcl_IncrRefCount(objPtr);
>      code = Tcl_EvalObjEx(interp, objPtr, TCL_EVAL_GLOBAL|TCL_EVAL_DIRECT);
> ...


See also #2112563:

<URL: http://sourceforge.net/tracker/index.php?func=detail&aid=2112563&group_id=12997&atid=112997 >


> the problem is that Tcl_PrintDouble takes into account the (now
> deprecated) tcl_precision variable.  The above causes errors in the test
> suite for where "scrollCmd 0.0 1.0" was expected, it now receives
> "scrollCmd 0.000000 1.000000".  These are error cases that have exact
> expectations on the string output.

The format should be "%s %g %g" instead of "%s %f %f".
That's what Tk used to use -- but see also #2112563.

> Most uses of the ~25 Tcl_PrintDoubles in Tk relate to scrolling, and
> that the values passed are moved through Tcl_PD, whereas the above goes
> to the raw sprintf handling of %f.

The problem with *that* is, if a buggy extension (or buggy
Windows printer driver, or buggy embedder...) calls setlocale(),
then sprintf(... "%g" ...); can -- depending on LC_NUMERIC --
produce output that can't be reparsed by Tcl as a floating point number.

The ::tcl_precision-induced breakage is a less severe problem --
in fact, it's not really even breakage, it only affects code
(like the test suite) that compares numbers as strings instead
of as numbers.  And there is a simple fix for any applications
that might be affected by this: stop setting ::tcl_precision,
and stop comparing numbers as strings.

The setlocale()-induced breakage is much harder to work around.
For one, it _completely_ breaks the application -- scrollbars
simply stop working.  And although calling setlocale() is also
a "Don't Do That" situation, applications don't always have
as much control over that.  (Buggy Windows printer drivers
have been known to cause this problem a couple times in the past.)



--Joe English

Re: [TCLCORE] The end for Tcl_PrintDouble in Tk?

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

On 20/05/2009 7:26 AM, Donal K. Fellows wrote:
> Jeff Hobbs wrote:
>> In looking into the best solution for 2790615
>> https://sourceforge.net/tracker/?func=detail&atid=112997&aid=2790615&group_id=12997 
>>
>> Don noted that Tcl_ObjPrintf (added in 8.5) or Tcl_AppendFormatToObj 
>> would be good alternatives to the coding changes I was using.
>>
>> This would change, eg tkEntry.c:EntryUpdateScrollbar from (partial):
>>
>>      EntryVisibleRange(entryPtr, &first, &last);
>>      Tcl_PrintDouble(NULL, first, firstStr);
>>      Tcl_PrintDouble(NULL, last, lastStr);
>>      objPtr = Tcl_NewStringObj(entryPtr->scrollCmd, -1);
>>      Tcl_IncrRefCount(objPtr);
>>      Tcl_AppendStringsToObj(objPtr, " ", firstStr, " ", lastStr, NULL);
>>      code = Tcl_EvalObjEx(interp, objPtr, 
>> TCL_EVAL_GLOBAL|TCL_EVAL_DIRECT);
>> ...
>>
>> to:
>>
>>      EntryVisibleRange(entryPtr, &first, &last);
>>      objPtr = Tcl_ObjPrintf("%s %f %f", entryPtr->scrollCmd, first, 
>> last);
>>      Tcl_IncrRefCount(objPtr);
>>      code = Tcl_EvalObjEx(interp, objPtr, 
>> TCL_EVAL_GLOBAL|TCL_EVAL_DIRECT);
>> ...
> 
> That sort of shortening looks good, but you might also consider using %g 
> instead of %f so that very large text and canvas widgets can still scroll.

I tried that, which causes test failures of a different variety (you get 
"1"/"0" instead of "1.0"/"0.0").  Don noted that that could cause issues 
with expr as dividing by float 0.0 (non-error Inf) has different 
behavior than int 0 (error).

Jeff

Re: [TCLCORE] The end for Tcl_PrintDouble in Tk?

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

Quoting Jeff Hobbs <je...@ac...>:
>      objPtr = Tcl_ObjPrintf("%s %f %f", entryPtr->scrollCmd, first, last);
> ...
> ... where "scrollCmd 0.0 1.0" was expected, it now receives
> "scrollCmd 0.000000 1.000000".

I think %f is the wrong tool for the job.  In your example,
the differences are mere formatting matters, but try again
with the values 0.0000001 and 0.0000004 .  The precision
of %f formatting -- whether you take the default of 6, or
whether you specify something else -- is the number of digits
printed after the decimal point, and takes no account of
significant digits.  I think you will see the first and
last values collapse into one value 0.000000 and I'd expect
scroll commands to be unhappy with that.

DGP

Re: [TCLCORE] The end for Tcl_PrintDouble in Tk?

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

On 19/05/2009 8:08 PM, Michael Kirkham wrote:
> This may not be a direct opinion as to your specific question, but both 
> of those look (IMHO) like throwbacks from the days before objects. 
> Assuming the precision change isn't an issue, why wouldn't you use...
> 
>      EntryVisibleRange(entryPtr, &first, &last);
>      objPtr = Tcl_DuplicateObj(entryPtr->scrollCmd);
>      Tcl_ListObjAppendElement(interp, objPtr, Tcl_NewDoubleObj(first));
>      Tcl_ListObjAppendElement(interp, objPtr, Tcl_NewDoubleObj(last));
>      code = Tcl_EvalObjEx(interp, objPtr, TCL_EVAL_GLOBAL|TCL_EVAL_DIRECT);
> ...?

This is a very good question with a very good answer.

For the long version see the very recent discussion on tcl chat logs 
again, but the short of it is this works for command prefixes, where you 
might do:
	-scrollcmd [list myCommand opt1 opt2]
or	-scrollcmd [list $widget xview]

but it would break for the (currently legal) script prefix case of:
	-scrollcmd "puts foo ; # ignore the rest"

There is relatively strong agreement amongst Tk dev that Tk 9 should 
disallow the latter (if we can't sneak it in earlier ...).

Jeff

> On Tue, 19 May 2009, Jeff Hobbs wrote:
> 
>> Date: Tue, 19 May 2009 19:57:06 -0700
>> From: Jeff Hobbs <je...@ac...>
>> To: Tcl Core List <tcl...@li...>
>> Subject: [TCLCORE] The end for Tcl_PrintDouble in Tk?
>>
>> In looking into the best solution for 2790615
>> https://sourceforge.net/tracker/?func=detail&atid=112997&aid=2790615&group_id=12997 
>>
>> Don noted that Tcl_ObjPrintf (added in 8.5) or Tcl_AppendFormatToObj
>> would be good alternatives to the coding changes I was using.
>>
>> This would change, eg tkEntry.c:EntryUpdateScrollbar from (partial):
>>
>>     EntryVisibleRange(entryPtr, &first, &last);
>>     Tcl_PrintDouble(NULL, first, firstStr);
>>     Tcl_PrintDouble(NULL, last, lastStr);
>>     objPtr = Tcl_NewStringObj(entryPtr->scrollCmd, -1);
>>     Tcl_IncrRefCount(objPtr);
>>     Tcl_AppendStringsToObj(objPtr, " ", firstStr, " ", lastStr, NULL);
>>     code = Tcl_EvalObjEx(interp, objPtr, 
>> TCL_EVAL_GLOBAL|TCL_EVAL_DIRECT);
>> ...
>>
>> to:
>>
>>     EntryVisibleRange(entryPtr, &first, &last);
>>     objPtr = Tcl_ObjPrintf("%s %f %f", entryPtr->scrollCmd, first, last);
>>     Tcl_IncrRefCount(objPtr);
>>     code = Tcl_EvalObjEx(interp, objPtr, 
>> TCL_EVAL_GLOBAL|TCL_EVAL_DIRECT);
>> ...
>>
>> the problem is that Tcl_PrintDouble takes into account the (now
>> deprecated) tcl_precision variable.  The above causes errors in the test
>> suite for where "scrollCmd 0.0 1.0" was expected, it now receives
>> "scrollCmd 0.000000 1.000000".  These are error cases that have exact
>> expectations on the string output.
>>
>> Most uses of the ~25 Tcl_PrintDoubles in Tk relate to scrolling, and
>> that the values passed are moved through Tcl_PD, whereas the above goes
>> to the raw sprintf handling of %f.
>>
>> The Tcl_PDs exist from the time that we sanitized everything and EIAS
>> was always true in Tk.  Would changing this be considered a compat
>> issue, or just clean-up?
>>
>> Jeff

Re: [TCLCORE] The end for Tcl_PrintDouble in Tk?

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

This may not be a direct opinion as to your specific question, but both of 
those look (IMHO) like throwbacks from the days before objects. Assuming 
the precision change isn't an issue, why wouldn't you use...

      EntryVisibleRange(entryPtr, &first, &last);
      objPtr = Tcl_DuplicateObj(entryPtr->scrollCmd);
      Tcl_ListObjAppendElement(interp, objPtr, Tcl_NewDoubleObj(first));
      Tcl_ListObjAppendElement(interp, objPtr, Tcl_NewDoubleObj(last));
      code = Tcl_EvalObjEx(interp, objPtr, TCL_EVAL_GLOBAL|TCL_EVAL_DIRECT);

...?

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

On Tue, 19 May 2009, Jeff Hobbs wrote:

> Date: Tue, 19 May 2009 19:57:06 -0700
> From: Jeff Hobbs <je...@ac...>
> To: Tcl Core List <tcl...@li...>
> Subject: [TCLCORE] The end for Tcl_PrintDouble in Tk?
> 
> In looking into the best solution for 2790615
> https://sourceforge.net/tracker/?func=detail&atid=112997&aid=2790615&group_id=12997
> Don noted that Tcl_ObjPrintf (added in 8.5) or Tcl_AppendFormatToObj
> would be good alternatives to the coding changes I was using.
>
> This would change, eg tkEntry.c:EntryUpdateScrollbar from (partial):
>
>     EntryVisibleRange(entryPtr, &first, &last);
>     Tcl_PrintDouble(NULL, first, firstStr);
>     Tcl_PrintDouble(NULL, last, lastStr);
>     objPtr = Tcl_NewStringObj(entryPtr->scrollCmd, -1);
>     Tcl_IncrRefCount(objPtr);
>     Tcl_AppendStringsToObj(objPtr, " ", firstStr, " ", lastStr, NULL);
>     code = Tcl_EvalObjEx(interp, objPtr, TCL_EVAL_GLOBAL|TCL_EVAL_DIRECT);
> ...
>
> to:
>
>     EntryVisibleRange(entryPtr, &first, &last);
>     objPtr = Tcl_ObjPrintf("%s %f %f", entryPtr->scrollCmd, first, last);
>     Tcl_IncrRefCount(objPtr);
>     code = Tcl_EvalObjEx(interp, objPtr, TCL_EVAL_GLOBAL|TCL_EVAL_DIRECT);
> ...
>
> the problem is that Tcl_PrintDouble takes into account the (now
> deprecated) tcl_precision variable.  The above causes errors in the test
> suite for where "scrollCmd 0.0 1.0" was expected, it now receives
> "scrollCmd 0.000000 1.000000".  These are error cases that have exact
> expectations on the string output.
>
> Most uses of the ~25 Tcl_PrintDoubles in Tk relate to scrolling, and
> that the values passed are moved through Tcl_PD, whereas the above goes
> to the raw sprintf handling of %f.
>
> The Tcl_PDs exist from the time that we sanitized everything and EIAS
> was always true in Tk.  Would changing this be considered a compat
> issue, or just clean-up?
>
> Jeff
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables
> unlimited royalty-free distribution of the report engine
> for externally facing server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

[TCLCORE] The end for Tcl_PrintDouble in Tk?

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

In looking into the best solution for 2790615
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=2790615&group_id=12997
Don noted that Tcl_ObjPrintf (added in 8.5) or Tcl_AppendFormatToObj 
would be good alternatives to the coding changes I was using.

This would change, eg tkEntry.c:EntryUpdateScrollbar from (partial):

     EntryVisibleRange(entryPtr, &first, &last);
     Tcl_PrintDouble(NULL, first, firstStr);
     Tcl_PrintDouble(NULL, last, lastStr);
     objPtr = Tcl_NewStringObj(entryPtr->scrollCmd, -1);
     Tcl_IncrRefCount(objPtr);
     Tcl_AppendStringsToObj(objPtr, " ", firstStr, " ", lastStr, NULL);
     code = Tcl_EvalObjEx(interp, objPtr, TCL_EVAL_GLOBAL|TCL_EVAL_DIRECT);
...

to:

     EntryVisibleRange(entryPtr, &first, &last);
     objPtr = Tcl_ObjPrintf("%s %f %f", entryPtr->scrollCmd, first, last);
     Tcl_IncrRefCount(objPtr);
     code = Tcl_EvalObjEx(interp, objPtr, TCL_EVAL_GLOBAL|TCL_EVAL_DIRECT);
...

the problem is that Tcl_PrintDouble takes into account the (now 
deprecated) tcl_precision variable.  The above causes errors in the test 
suite for where "scrollCmd 0.0 1.0" was expected, it now receives 
"scrollCmd 0.000000 1.000000".  These are error cases that have exact 
expectations on the string output.

Most uses of the ~25 Tcl_PrintDoubles in Tk relate to scrolling, and 
that the values passed are moved through Tcl_PD, whereas the above goes 
to the raw sprintf handling of %f.

The Tcl_PDs exist from the time that we sanitized everything and EIAS 
was always true in Tk.  Would changing this be considered a compat 
issue, or just clean-up?

Jeff