tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] 8.3.2 almost finished - expect an 8.3.3

[Andreas K. <a.k...@we...>]

--------; charset=us-ascii
> FYI,
 
> 8.3.2 has some more testing to be done, and then some backporting of
> items that went into the main branch (8.4).  It should be out by
> mid-August.
 
> In working with 8.3.2, we realized that there will be a need for and
> 8.3.3 to work on limitations inherent in the Windows OS and how we
> manage sockets with Tcl.  Currently we can only service 64
> simultaneous socket requests because that's what the Windows select
> can manage per thread.

What an OS :(. Now there was that slip of paper ... Ah, here.

~~~~~~~~~~~~~~~~~~
Windows 95: n.
	32-bit extensions and a graphical shell for a 16-bit patch to
	an 8-bit operating system originally coded for a 4-bit
	microprocessor, written by a 2-bit company that can't stand
	for 1 bit of competition.
~~~~~~~~~~~~~~~~~~

> The solution will be to spin a thread per socket instead (as
> lightweight as possible).

Questions coming to my mind:

	Would it be much more complex to spin new threads only as the
	limit on the previous ones is reached, i.e. only every 64
	sockets ?

	Or would that complexity outweigh the benefits we can get from
	having less threads around ?

	I'm worried that we will run into some limit on the number of
	threads supported by Win* instead.


> At the same time we have to solve the problem with the memory leak
> in using Windows threads when the C runtime is accessed (leading to
> things like the 4K mem leak per exec call on Windows).
 
> We already have some thoughts, but it will take some time to get the
> solution right.  We want to get the 8.3.2 changes out because it
> will be important for everybody to have a real distributed version
> of Tcl with the corrected stacked channel code, among other changes
> that will be in 8.3.2.  No release date for 8.3.3 at this time.

-- 
So long,
	Andreas Kupries <a.k...@we...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

Re: [TCLCORE] Porting 8-3-1-branch IO changes to 8-4

[Andreas K. <a.k...@we...>]

> OK, so the major IO rewrite for 8.3.2 is mostly finished (the new
> interfaces need to be doc'ed).  Now we have to deal with moving
> those code changes up into the mainline (8.4).
 
> One of the conflicts is that generic declarations were added to both
> 8.3 (Tcl_Channel* funcs) and 8.4 (funcs for sharing channels among
> threads, some UniChar and HashTable funcs).  Since the 8.4 only saw
> one alpha, the 8.3 entries will have precedence and keep their
> numbers.  I'll renumber the 8.4 entries.  This means that extensions
> compiled against 8.4a1 stubs may have incompatabilities and should
> be recompiled with 8.4a2 if they use the new stub calls.

The only extension I currently know of using the new calls is
'Thread'.


> Of course, we managed to focus new development in both branches on
> the IO layer (8.4 getting work in the sharing of channels between
> threads).  Since 8.3 is by far the larger of the rewrites, I'd like
> to basically move the IO changes complete up from 8.3 and then
> regraft the 8.4 changes onto the new system.
 
> Anyone forsee further complications with this, or has comments, or
> would like to help?

I see no big complications with that. ... Ok, the changes I did are in

	2000-05-03-20-24.diff.gz 

of my cvs snapshots. There are some other changes in as well (joinable
threads), but it should be possible to trim it down to contain just
the changes to the IO-system. We'll have to see how many chunks are
still applicable. File attached.

~~~~~~~~~~~~~~~

Excerpt of ChangeLog of the lastest 8.3.2-io-rewrite.

* tests/all.tcl: corrected additional sets by Kupries for testing.

I'm chagrined. My apologies for that oversight.

I truly wish there was some way to set such things separately during
development without having to modify the distributed files
themselves. => Some idea for Jennifer Hom and her planned changes to
tcltest.


-- 
So long,
	Andreas Kupries <a.k...@we...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

[TCLCORE] 8.3.2 almost finished - expect an 8.3.3

[Jeffrey H. <jef...@aj...>]

FYI,

8.3.2 has some more testing to be done, and then some backporting
of items that went into the main branch (8.4).  It should be out
by mid-August.

In working with 8.3.2, we realized that there will be a need for
and 8.3.3 to work on limitations inherent in the Windows OS and
how we manage sockets with Tcl.  Currently we can only service 64
simultaneous socket requests because that's what the Windows
select can manage per thread.  The solution will be to spin a
thread per socket instead (as lightweight as possible).  At the
same time we have to solve the problem with the memory leak in
using Windows threads when the C runtime is accessed (leading to
things like the 4K mem leak per exec call on Windows).

We already have some thoughts, but it will take some time to get
the solution right.  We want to get the 8.3.2 changes out because
it will be important for everybody to have a real distributed
version of Tcl with the corrected stacked channel code, among
other changes that will be in 8.3.2.  No release date for 8.3.3
at this time.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Porting 8-3-1-branch IO changes to 8-4

[Jeffrey H. <jef...@aj...>]

OK, so the major IO rewrite for 8.3.2 is mostly finished (the new interfaces
need to be doc'ed).  Now we have to deal with moving those code changes up
into the mainline (8.4).

One of the conflicts is that generic declarations were added to both 8.3
(Tcl_Channel* funcs) and 8.4 (funcs for sharing channels among threads,
some UniChar and HashTable funcs).  Since the 8.4 only saw one alpha, the
8.3 entries will have precedence and keep their numbers.  I'll renumber
the 8.4 entries.  This means that extensions compiled against 8.4a1 stubs
may have incompatabilities and should be recompiled with 8.4a2 if they
use the new stub calls.

Of course, we managed to focus new development in both branches on the
IO layer (8.4 getting work in the sharing of channels between threads).
Since 8.3 is by far the larger of the rewrites, I'd like to basically
move the IO changes complete up from 8.3 and then regraft the 8.4 changes
onto the new system.

Anyone forsee further complications with this, or has comments, or
would like to help?

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] *-io-rewrite branches merged in

[Jeffrey H. <jef...@aj...>]

After finally coming to a point a very high (but not complete)
satisfaction with the Tcl IO channel / TLS rewrite, I have merged
the branches I was working on back in.  For Tcl, this means that
people shouldn't work with the core-8-3-1-io-rewrite branch anymore,
just core-8-3-1-branch or the mainline.  Note that the mainline
is Tcl 8.4, and I have not yet up-ported the IO rewrite code.

For Tls, this means use the mainline (cvs up -A, or checkout fresh),
please don't use tls-1-3-io-rewrite anymore.

Following these changes, Tcl is at 8.3.2 and TLS is at 1.4.

For those testing this, I also have numerous simple but severe
stress-testing scripts (note that there are also lots of tests
to go with the new code).  I'm going to figure out where to add
the stress testing scripts as examples into the CVS of Tls.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: modifying generic/tclExecute.c

[Eric M. <er...@aj...>]

On Tue, 25 Jul 2000, <Miguel Sofer wrote:

> Point (a) implies inlining some code which is in other files
> (tclVar.c, tclBasic.c, maybe tclCompile.c). I have been "copying and
> pasting" in my preliminary tests, but realise that this is not very
> good - difficult maintenance, even if well documented. For instance,
> any change in the Var type may have severe implications in the
> executor, the decoupling is lost ...
> 
> A solution might be to put some of that code in macros in a common
> header file. I kind of liked the idea of touching a single file
> (actually, a single function!); this option would imply modifying also
> the other files ... and maybe making life difficult for their
> maintainers/updaters. I'd rather not ...

I'm generally opposed to using macros for anything but fairly small (less
than about 4 lines of code) functions.  I think overuse of macros can lead
to badly structured code.  Perhaps there are a few small, critical
sections of code that would benefit from this, however.  I'd like to see
what code you are specifically considering modifying this way.

This sort of leads into a related issue with TclExecuteByteCode, which is
that there is substantial duplication of functionality between
TclExecuteByteCode/Tcl_*CompCmd and the various Tcl_*ObjCmd
implementations.  I don't know of a good solution to this, but it would
surely make Tcl easier to maintain (not that it is really that bad right
now) if we could consolidate that code.

I'd like to get some other peoples brains working on this problem; maybe
we can come up with something reasonable for 9.0.

   Eric Melski                            The Other Tcl Guy
   ericm at ajubasolutions.com            Ajuba Solutions

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] modifying generic/tclExecute.c

[<Miguel S. <mi...@ut...>]

I am testing a few optimisations of TclExecuteByteCode, with
initially promising results.

It consists mainly of
(a) avoiding calls outside of TclExecuteByteCode and reducing the
    amount of recursive calls
(b) using (if available) the gcc "Labels as Values" extension,
    making a single indirect jump to the new opcode instead of a jump 
    back to "for (;;)" and then switch (an indirect jump as compiled by
    gcc) 
(c) a few other smaller things 

Point (a) implies inlining some code which is in other files
(tclVar.c, tclBasic.c, maybe tclCompile.c). I have been "copying and
pasting" in my preliminary tests, but realise that this is not very
good - difficult maintenance, even if well documented. For instance,
any change in the Var type may have severe implications in the
executor, the decoupling is lost ...

A solution might be to put some of that code in macros in a common
header file. I kind of liked the idea of touching a single file
(actually, a single function!); this option would imply modifying also
the other files ... and maybe making life difficult for their
maintainers/updaters. I'd rather not ...

I appreciate any suggestions you might have on this point.

Thanks

Miguel Sofer

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Tcl bugfixes to backport for 8.3.2

[Eric M. <er...@aj...>]

Here's my list of fixes to backport for 8.3.2.  Unlike the Tk fixes, most
of these are not as interesting (doc fixes, etc).  There's a couple of
good ones in there, though (build cleanup, clock bugs, http bugs).

- eric

	* doc/memory.n: Man page for Tcl "memory" command, which is
	created when TCL_MEM_DEBUG is defined at compile time.

	* doc/TCL_MEM_DEBUG.3: Man page with overall information about
	TCL_MEM_DEBUG usage.

	* doc/DumpActiveMemory.3: Man page for Tcl_DumpActiveMemory,
	Tcl_InitMemory, and Tcl_ValidateAllMemory [Bug: 1816, 1835].

	* generic/tclCkalloc.c: Fixed some function headers.

	* unix/mkLinks: Regen'd with new mkLinks.tcl.

	* unix/mkLinks.tcl: Fixed indentation, made link setup more
	intelligent (only do one existance test per man page, instead of
	one per function).

	* doc/library.n: Fixed .SH NAME macro to include each function
	documented on the page, so that mkLinks will know about the
	functions listed there, and so that the Windows help file index
	will get set up correctly [Bug: 1898, 5273].

	* doc/library.n: Added entries for auto_qualify and auto_import
	[Bug: 1271].

	* doc/Init.3: Manual entry for Tcl_Init [Bug: 1820].

	* doc/expr.n: Added documentation for each of the math library
	functions that expr supports [Bug: 1054].

	* unix/Makefile.in: add tclsh.ico and tcl.spec to dist target

	* generic/tclPosixStr.c (Tcl_SignalMsg): clarified #defines for
	Linux on Sparc to compile correctly. [Bug: 5364]

	* library/history.tcl: Corrected an off-by-one error in HistIndex,
	which was causing [history redo] to start its search at the wrong
	event index. [Bug: 1269].

	* library/init.tcl (auto_import): added check to see if a valid
	pattern was coming in, to avoid simple error cases [Bug: 3326]

	* doc/regsub.n: correct regsub docs [Bug: 5346]

	* win/{tcl.m4,Makefile.in,configure.in}: added support for mingw
	compile env and cross-compiling. [Bug: 5499]

	* generic/tclClock.c (FormatClock): correct code to handle locale
	specific return values from strftime, if any. [Bug: 3345]

	* unix/tclUnixInit.c (TclpSetInitialEncodings): attempt to
	correct setlocale calls for XIM support and locale issues.
	[BUG: 5422 3345 4236 2522 2521]

	* tests/clock.test: Added test for "2 days 2 hours ago" style
	specifications.

	* generic/tclDate.c: Regenerated from tclGetDate.y.

	* generic/tclGetDate.y: Tweaked grammar to properly handle the
	"ago" keyword when it follows multiple relative unit specifiers,
	as in "2 days 2 hours ago".  [Bug: 5497].

	* doc/scan.n: 
	* doc/array.n: minor doc fixes [Bug: 5396]

	* generic/tclEnv.c: cast cleanup [Bug: 5624]
	* win/tclWinConsole.c: cast and header cleanup [Bug: 5625]
	* win/tclWinSerial.c: cast cleanup [Bug: 5626]
	* win/tclWinFCmd.c: cast cleanup [Bug: 5627]

	* tests/http.test
	* doc/http.n
	* library/http2.3/http.tcl: Fixed bug 5741, where unsuccessful
	geturl calls sometimes leaked memory and resources (sockets).  
	Also, switched around some of the logic so that http::wait never 
	throws an exception.  This is because in an asynchronous geturl, 
	the command callback will probably end up doing all the error 
	handling anyway, and in an asynchronous situation, the user
	expects to check the state when the transaction completes, as
	opposed to being thrown an exception.	For the http package, this
	menas the user can check http::status for "error" and http::error
	for the error message after doing the http::wait.

	* generic/tclIndexObj.c (Tcl_GetIndexFromObjStruct): Corrected
	caching of the index ptr to account for offsets != sizeof(char *).
	[Bug: 5153]

	* win/tcl.m4:
	* win/configure.in:
	* win/Makefile.in: Applied patch from [RFE: 5844], to extend
	support for mingw compile environment on Windows.

	* win/tclWinDde.c:
	* win/tclWinInit.c:
	* win/tclWinNotify.c:
	* win/tclWinPipe.c:
	* win/tclWinReg.c:
	* win/tclWinThrd.c: Applied patch from [Bug: 5794], to fix
	compiler warnings when using mingw on Windows.

	* doc/RegExp.3: Replaced instances of "Tcl_GetRegExpInfo" with
	"Tcl_RegExpGetInfo", the correct name of the function [Bug: 5901].

	* library/opt0.4/optparse.tcl: Applied patch from [Bug: 5922],
	which corrected an incorrect use of [string match].

	* unix/tclConfig.sh.in:
	* win/tclConfig.sh.in: Applied patch from [Bug: 5921], which
	corrects a typo in the comments in these files.

	* doc/package.n: Corrected information about [package forget]
	arguments [Bug: 5418].

	* tests/stringObj.test: Tweaked tests to avoid hardcoded
	high-ASCII characters (which will fail in multibyte locales);
	instead used \uXXXX syntax. [Bug: 3842].




--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] tk bugfixes to backport to 8.3.2

[Eric M. <er...@aj...>]

I suggest that the following Tk bugfixes be backported from the mainline
to 8.3.2.  Many of them fix (potential) core dump issues; others (like the
redefine of the GIF87a/GIF89a strings) just fix bug that have a high
annoyance factor.

- eric

	* generic/tkText.c (TextSearchCmd): Added a test for a NULL
	segment pointer when doing backwards searches for "" on an empty
	text widget. [Bug: 6007].

	* generic/tkCursor.c: Added initialization for nextPtr field of
	TkCursor, patch from Nijtmans/Howlett.

	* generic/tkMenu.c (DeleteMenuCloneEntries): Applied fix from
	[Bug: 5275], which corrected a segfault-causing indexing problem
	when deleting entries from torn-off menus.

	* generic/tkImgGIF.c: Changed defines for GIF87a/GIF89a to be
	static char arrays with integer initialization, to address EBCIDIC
	vs. ASCII encoding issues and to handle compilers that don't deal
	with "\xAB" syntax for specifying hex values in strings.

	* generic/tkPlace.c (Tk_PlaceCmd): reworked place master/slave
	table init'n to prevent seg fault when using place on multiple
	displays.

	* canvas.test: added test for 5783.
	* generic/tkCanvPoly.c (DisplayPolygon): added checks for the
	polygon fillGC not being empty to prevent segfault. [Bug: 5783]

	* win/tkWinMenu.c (ReconfigureWindowsMenu): Added code to add the
	MF_SEPARATOR bit for SEPARATOR_ENTRY menu items.  This causes
	separator entries on the system menu to be drawn correctly [Bug:
	5451].

	* win/tkWinWm.c (RaiseWinWhenIdle): added TK_DONT_DESTROY_WINDOW
	to flag check to prevent timing related core dump. [Bug: 5438]

	* tests/menu.test:
	* generic/tk3d.c:
	* generic/tkColor.c:
	* generic/tkCursor.c: corrected handling of 3DBorder, Cursor and
	Color objects on multiple screens. [Bug: 5454]

	* win/tkWinMenu.c (GetMenuSeparatorGeometry): Tweaked height
	requested for separator bars to be (linespace - (2*descent))
	instead of just (linespace); this makes the separator occupy a
	more correct amount of vertical space. [Bug: 5303].

	* library/focus.tcl: fixed calling of takeFocus proc [Bug: 5372]

	* generic/tkButton.c: Added -activeforeground, -activebackground
	for labels, for the -state option.

	* doc/label.n: Added documentation for -state option,
	-activeforeground, -activebackground.


--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: trace command patch

[Vince D. <vin...@bi...>]

> Variable traces support read, write, and unset operations; 
> command traces
> support rename and delete operations; execution traces are 
> used to trace
> command execution, and have several additional options:
> 
> trace add execution name ops ?-minlevel m -maxlevel n 
> -truncate t -depth d?
> 
> The full patch is at
> 
> ftp://ftp.ucsd.edu/pub/alpha/tcl/tracecommand.patch.gz
> 
> If you are so inclined, please take a look at it and give us some
> comments.  I think the patch looks very good; I've tested it 
> out and it
> works as advertised, has tests, and doc's.  My only concern 
> is with the
> syntax of the execution traces.  I think that "execution" 
> should just be
> another operation for command traces, rather than an entirely 
> separate set
> of traces.  My guess is that Vince split it out because of 
> the need for
> the extra options.  But I don't feel strongly that it should 
> be changed.
> Does anybody else have any comments on this, or on any other 
> parts of the
> patch?

Indeed, I split it out because 'execution' and 'command' traces are
semantically very different.  'command' traces simply notify you when a
command is renamed/deleted, whereas 'execution' traces give you ongoing
information about what is happening while a command is being executed.  The
only commonality between the two is that both take a 'name' parameter which
is a valid command in the current interpreter.  Beyond that the ops and
options allowed are completely incompatible between execution/command. 

I'd be happy to help clarify this issue, or anything else with the patch.

Please note that trace.n needs some work.  My nroff skills were not up to
the job (the information is all there, I believe, but not the formatting).
I'd be more than happy to look over a redone trace.n to make sure all the
docs are correct and/or clarify any remaining issues.

cheers,

Vince.

[TCLCORE] RE: [TCLCORE] Re: 64 bit numbers

[Don B. <do...@pi...>]

I guess I misunderstood what the intent of the roadmap
was, but I'm not sure I agree with you here. Let me 
explain my reasoning.

I am running tcl on a 64-bit platform that uses 32-bit
addressing (64-bit addresses are quite large after
all). This isn't that uncommon, there's lots of Unix
systems running with 32-bit addressing that have 64-bit
integer instructions available. The Pentium on which
Windows is based has some 64-bit integer abilities.

I need to have 64-bit integer arithmetic available
in expr & format for interoperability with external
tools that use 64-bit results. In my case its part
of a network testing environment where 64-bit counters
are used, and I need to do rate calculations. I can
do this using mpexpr, but its quite slow, and I can't
get the performance I need. I think there are a few
packages that could use this, scotty & tclblend are 2 
that spring to mind.

Also, it would be nice if a script could be portable
between systems with 64-bit and 32-bit capabilities
without having to worry about the precision of
an integer.

What I would like to do is take on the work to
formalise the use of integer types in Tcl to a new
typedef, so that the size of the integer does not
change based on the host platform it is compiled for.
This means that I have to fix the places that 'int'
is used, 'long' is used, unsafe casts are made, implement
a 64-bit safe strtoul, strtol, format, etc.
The two obvious approachs are binary-compatible (keep
int & long as the current platform size, add a new
set of 64-bit functions), or binary-incompatible
(force the 'int' to 32-bit, the 'long' to 64-bit or
somesuch). The pro & cons for each are fairly
obvious: binary-incompatible -> need to recompile extension,
but all extensions can get 64-bit without code change,
binary-compatible -> more work, extensions need
code changes to use, but don't have to be recompiled.

So far the votes seem to indicate the binary 
compatible approach is prefered.

Checking Tcl user-group history, the 64-bit integer
capability is asked about fairly often.

Being 64-bit addressing safe is also a valuable thing 
to have, unfortunately its not an area I have the equipment
to contribute in.

-----Original Message-----
From: Eric Melski [mailto:er...@aj...]
Sent: July 23, 2000 2:47 PM
To: Don Bowman
Cc: tc...@po...
Subject: [TCLCORE] Re: 64 bit numbers on IA32



I don't think it's necessary or advisable to make Tcl support 64-bit
integers on a 32-bit platform.  It seems like the amount of effort and the
degree to which backwards compatibility would be affected does not justify
the benefits.  If you need 64-bit integers, you should move (or are
probably already running on) a 64-bit platform.  Our focus for extending
64-bit support in Tcl should be on making sure that Tcl works properly on
64-bit platforms.  This means that code that uses integers as pointers,
for example, has to be corrected to use real pointers (since pointers on a
64-bit platform are 64-bit, while integers are likely 32-bit).  Similarly,
code that uses integers for file offsets should use size_t instead, for
the same reasons.  This is really what the intention of the "improve
64-bit support" line-item on the 8.4 roadmap was referring to, I believe.

   Eric Melski                            The Other Tcl Guy
   ericm at ajubasolutions.com            Ajuba Solutions




--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] FW: Python 'Batteries Included' proposal and more...

[Jeffrey H. <jef...@aj...>]

Dan sent this, but I thought it would have wider interest.

Note that a "batteries included" Tcl distribution is one of the
biggest items I (and others) see as necessary to revitalize the
community.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

-----Original Message-----
From: Dan Kuchler [mailto:ku...@aj...]
Subject: Python 'Batteries Included' proposal and more...



The proposals for how to extend python are on the web at:

http://python.sourceforge.net/peps/

The '2.0 Batteries Included' proposal was interesting.

The proposal involved including 7-10 'libraries' in
the distribution:

zlib -- http://www.info-zip.org/pub/infozip/zlib/zlib.tar.gz
expat -- ftp://ftp.jclark.com/pub/xml/expat.zip
Tcl -- http://dev.scriptics.com:80/download/tcl/tcl8_3/tcl8.3.1.tar.gz
Tk -- http://dev.scriptics.com:80/download/tcl/tcl8_3/tk8.3.1.tar.gz
PIL -- http://www.pythonware.com/downloads/Imaging-1.1.tar.gz
libjpeg -- ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6b.tar.gz
ncurses -- ftp://dickey.his.com/ncurses/ncurses.tar.gz

TBD, the following three:

NumPy -- http://download.sourceforge.net/numpy/Numerical-15.3.tgz
Pmw --  ftp://ftp.dscpl.com.au/pub/pmw/Pmw.0.8.4.tar.gz
BLT -- ftp://ftp.tcltk.com/aa004735/pub/blt/BLT2.4u.tar.gz

Hmm... BLT, Tcl, and Tk..

:)

--Dan

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: 64 bit numbers on IA32

[Eric M. <er...@aj...>]

I don't think it's necessary or advisable to make Tcl support 64-bit
integers on a 32-bit platform.  It seems like the amount of effort and the
degree to which backwards compatibility would be affected does not justify
the benefits.  If you need 64-bit integers, you should move (or are
probably already running on) a 64-bit platform.  Our focus for extending
64-bit support in Tcl should be on making sure that Tcl works properly on
64-bit platforms.  This means that code that uses integers as pointers,
for example, has to be corrected to use real pointers (since pointers on a
64-bit platform are 64-bit, while integers are likely 32-bit).  Similarly,
code that uses integers for file offsets should use size_t instead, for
the same reasons.  This is really what the intention of the "improve
64-bit support" line-item on the 8.4 roadmap was referring to, I believe.

   Eric Melski                            The Other Tcl Guy
   ericm at ajubasolutions.com            Ajuba Solutions




--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: 64 bit numbers on IA32

[Don B. <do...@pi...>]

FYI I am looking at improving the 64-bit support in TCL.
Specifically I am looking at making 64-bit integers work
regardless of whether the machine is 32 or 64 bit.
(ie using __int64 / long long).

I need some opinions.

The simplest way to do that is simply to raise the size
of the value in a Tcl_Obj. This doesn't change the size of
a Tcl_Obj, its already got the space. However, there's
an issue with binary compatibility because things like
Tcl_ExprLong, Tcl_NewIntObj, etc now would have
a pointer to a wider type. I've got this all prototyped,
I created a new type, Tcl_IntegerType, and throughout
made references use only this type.
(* There's actually a lot of changes, strtoul, strtol,
all the explicit casts to (int), (long), (void *), etc).

This would work for compiling new extensions with the
tcl.h, C rules would apply for promotion to larger values
(sign extending and so on) so the extensions could be
rebuilt without trouble.

However, there's a break to binary compatibility.

Another way to do this is to define a set of new API,
and deprecate the old ones, but keep them at the current
size (32-bits in most cases).

This means there would be:
Tcl_NewIntObj,
Tcl_NewLongObj,
Tcl_New???Obj

This is quite a bit more work, and extensions and so on
need to be reworked if they wish to get access to larger precision
types.

My personal preference is the first approach, Tcl_NewIntObj should
be used to create a new integer, and that shouldn't need to specify the
size. When compiled as 64-bit, an integer would be 64-bits throughout
tcl. This is also the least prone to creating bugs.

However, I don't want to go through and do all the work if the patches
won't be accepted.

If you have an opinion, please email me as do...@pi....

Thanks very much.

--don

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: 64 bit numbers on IA32

[Mo D. <md...@cy...>]

On Sat, 22 Jul 2000, Don Bowman wrote:

> FYI I am looking at improving the 64-bit support in TCL.
> Specifically I am looking at making 64-bit integers work
> regardless of whether the machine is 32 or 64 bit.
> (ie using __int64 / long long).
> 
> I need some opinions.
> 
> The simplest way to do that is simply to raise the size
> of the value in a Tcl_Obj.

That might seem like a logical thing to do, but I
don't think it is a good idea. You are going to
run into portability issues. Besides, using 64
bit numbers means every math operation would be
done as a 64 bit operation, that could slow down
every integer operation in Tcl.

> Another way to do this is to define a set of new API,
> and deprecate the old ones, but keep them at the current
> size (32-bits in most cases).
> Tcl_NewIntObj
> Tcl_NewLongObj
...
> This is quite a bit more work, and extensions and so on
> need to be reworked if they wish to get access to larger precision
> types.

Yes but at least extensions would have a choice. There
could also be an expr func long() to go with the int() one.
I have run into this same problem in Jacl and Tcl Blend.
Java supports a 64 bit long type, but there is no way
to store it as a TclInteger object. I had to just
punt and pass 64 bit ints around as strings. It would
be better if there was a TclLong type in addition to
a TclInteger. I don't want to have to recompile Tcl
and all my extensions to make use of it.

Mo DeJong
Red Hat Inc

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Patch to fix CFLAGS problems.

[Mo D. <md...@cy...>]

On Thu, 20 Jul 2000, Eric Melski wrote:

> Looks OK to me.
> 
> - eric

The only part about this patch that I am not sure
about is the LDFLAGS_DEFAULT variable. 

# Flags to pass to the compiler when linking object files into
# an executable tclsh or tcltest binary.
TCL_LD_FLAGS='@LDFLAGS@'

It was "sort of" getting used in tclConfig.sh, but
as far as I could tell it was always set to the
empty string in tcl.m4. Should it just be removed
or should I rework it that same as CFLAGS? If you
take a look at Makefile.in you will notice that
only @LDFLAGS@ is used.

Mo DeJong
Red Hat Inc

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: FW: Q about managing open source development

[Andreas K. <a.k...@we...>]

I got this from the Python-URL! for this week (Jul 18).

http://www.python.org/pipermail/python-dev/2000-July/013059.html

-- 
Sincerely,
	Andreas Kupries <a.k...@we...>
		<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: FW: Q about managing open source development

[Andreas K. <a.k...@we...>]

I got this from the Python-URL! for this week.

http://www.python.org/pipermail/python-dev/2000-July/013059.html

-- 
Sincerely,
	Andreas Kupries <a.k...@we...>
		<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

Re: [TCLCORE] Re: FW: Q about managing open source development

[Andreas K. <a.k...@we...>]

--------

I got this from the Python-URL! for this week (Jul 18).

http://www.python.org/pipermail/python-dev/2000-July/013059.html

-- 
Sincerely,
	Andreas Kupries <a.k...@we...>
		<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

gnome canvas paper

[Andreas K. <a.k...@we...>]

--------

http://www.usenix.org/events/usenix2000/freenix/quintero.html

Thought it of interest since the Gnome canvas started from the Tk one.
Maybe it contains some ideas we could backport.


-- 
So long,
	Andreas Kupries <a.k...@we...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

[TCLCORE] Re: Joe English given CVS access

[Eric M. <er...@aj...>]

FYI:

Joe has CVS access to the documentation trees for Tcl/Tk, to do various
cleanup and work on the XML documentation project.

   Eric Melski                            The Other Tcl Guy
   ericm at ajubasolutions.com            Ajuba Solutions


--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: improved 64-bit support

[Don B. <do...@pi...>]

It seems that no-one's name is beside the
"improved 64-bit support".
What is the status of this? Is someone working
on it, or has someone got some notes on what
needs to be done?

If no one is working on this currently I will
volunteer to work on it.



 


begin 600 Don Bowman (E-mail).vcf

`
end

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Petasis and Bonnet given extension write access

[Jeffrey H. <jef...@aj...>]

FYI, George Petasis has been given write access to the tkdnd module
(as maintainer) and Frederic Bonnet has been given write access to
tkgs (as maintainer).

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Patch to fix CFLAGS problems.

[Mo D. <md...@cy...>]

I wrote up this patch to fix the problem with Tcl not respecting
the CFLAGS variable set in the users env. If nobody has a problem
with it, I will add commit it to the CVS (along with the equivalent
patch to tk and the windows builds for tcl and tk).

Mo DeJong
Red Hat Inc

Index: unix/Makefile.in
===================================================================
RCS file: /home/cvs/external/tcl/unix/Makefile.in,v
retrieving revision 1.66
diff -u -r1.66 Makefile.in
--- Makefile.in	2000/06/06 04:39:49	1.66
+++ Makefile.in	2000/07/19 00:40:49
@@ -87,7 +87,7 @@
 #CFLAGS			= $(CFLAGS_DEBUG)
 #CFLAGS			= $(CFLAGS_OPTIMIZE)
 #CFLAGS			= $(CFLAGS_DEBUG) $(CFLAGS_OPTIMIZE)
-CFLAGS			= @CFLAGS@
+CFLAGS			= @CFLAGS_DEFAULT@
 
 # To disable ANSI-C procedure prototypes reverse the comment characters
 # on the following lines:
Index: unix/configure.in
===================================================================
RCS file: /home/cvs/external/tcl/unix/configure.in,v
retrieving revision 1.58
diff -u -r1.58 configure.in
--- configure.in	2000/05/03 00:15:10	1.58
+++ configure.in	2000/07/19 00:40:49
@@ -28,6 +28,7 @@
 #------------------------------------------------------------------------
 
 AC_PROG_RANLIB
+SC_ENABLE_SYMBOLS
 SC_ENABLE_GCC
 AC_HAVE_HEADERS(unistd.h limits.h)
 
@@ -408,11 +409,7 @@
 #--------------------------------------------------------------------
 
 SC_CONFIG_CFLAGS
-
-SC_ENABLE_SYMBOLS
-
 TCL_DBGX=${DBGX}
-CFLAGS=${CFLAGS_DEFAULT}
 
 #--------------------------------------------------------------------
 #	The statements below check for systems where POSIX-style
@@ -558,12 +555,16 @@
 
 AC_SUBST(BUILD_DLTEST)
 AC_SUBST(CFLAGS)
+AC_SUBST(CFLAGS_DEFAULT)
+AC_SUBST(CFLAGS_DEBUG)
+AC_SUBST(CFLAGS_OPTIMIZE)
+AC_SUBST(CFLAGS_WARNING)
+AC_SUBST(EXTRA_CFLAGS)
 AC_SUBST(CFG_TCL_SHARED_LIB_SUFFIX)
 AC_SUBST(CFG_TCL_UNSHARED_LIB_SUFFIX)
 AC_SUBST(CFG_TCL_EXPORT_FILE_SUFFIX)
 AC_SUBST(TCL_DBGX)
 AC_SUBST(DL_OBJS)
-AC_SUBST(EXTRA_CFLAGS)
 AC_SUBST(LDFLAGS)
 AC_SUBST(MAKE_LIB)
 AC_SUBST(TCL_SHARED_BUILD)
Index: unix/tcl.m4
===================================================================
RCS file: /home/cvs/external/tcl/unix/tcl.m4,v
retrieving revision 1.23
diff -u -r1.23 tcl.m4
--- tcl.m4	2000/07/17 08:26:31	1.23
+++ tcl.m4	2000/07/19 00:40:50
@@ -408,22 +408,16 @@
 # Arguments:
 #	none
 #	
-#	Requires the following vars to be set:
-#		CFLAGS_DEBUG
-#		CFLAGS_OPTIMIZE
-#		LDFLAGS_DEBUG
-#		LDFLAGS_OPTIMIZE
-#	
 # Results:
 #
 #	Adds the following arguments to configure:
 #		--enable-symbols
 #
 #	Defines the following vars:
-#		CFLAGS_DEFAULT	Sets to CFLAGS_DEBUG if true
-#				Sets to CFLAGS_OPTIMIZE if false
-#		LDFLAGS_DEFAULT	Sets to LDFLAGS_DEBUG if true
-#				Sets to LDFLAGS_OPTIMIZE if false
+#		CFLAGS_DEBUG
+#		CFLAGS_OPTIMIZE
+#		CFLAGS_DEFAULT	Set to $(CFLAGS_DEBUG) or
+#				Set to $(CFLAGS_OPTIMIZE)
 #		DBGX		Debug library extension
 #
 #------------------------------------------------------------------------
@@ -431,14 +425,24 @@
 AC_DEFUN(SC_ENABLE_SYMBOLS, [
     AC_MSG_CHECKING([for build with symbols])
     AC_ARG_ENABLE(symbols, [  --enable-symbols        build with 
debugging symbols [--disable-symbols]],    [tcl_ok=$enableval], [tcl_ok=no])
+    CFLAGS_DEBUG=-g
+    CFLAGS_OPTIMIZE=-O
     if test "$tcl_ok" = "yes"; then
-	CFLAGS_DEFAULT="${CFLAGS_DEBUG}"
-	LDFLAGS_DEFAULT="${LDFLAGS_DEBUG}"
+        if test -z "$CFLAGS" ; then
+            CFLAGS=${CFLAGS_DEBUG}
+            CFLAGS_DEFAULT='$(CFLAGS_DEBUG)'
+        else
+            CFLAGS_DEFAULT=${CFLAGS}
+        fi
 	DBGX=g
 	AC_MSG_RESULT([yes])
     else
-	CFLAGS_DEFAULT="${CFLAGS_OPTIMIZE}"
-	LDFLAGS_DEFAULT="${LDFLAGS_OPTIMIZE}"
+        if test -z "$CFLAGS" ; then
+            CFLAGS=${CFLAGS_OPTIMIZE}
+            CFLAGS_DEFAULT='$(CFLAGS_OPTIMIZE)'
+        else
+            CFLAGS_DEFAULT=${CFLAGS}
+        fi
 	DBGX=""
 	AC_MSG_RESULT([no])
     fi
@@ -512,17 +516,11 @@
 #                       The name of the built export / import file which
 #                       should be used to link to the Tcl shared library.
 #                       Empty if Tcl is unshared.
-#	CFLAGS_DEBUG -
-#			Flags used when running the compiler in debug mode
-#	CFLAGS_OPTIMIZE -
-#			Flags used when running the compiler in optimize mode
 #
 #	EXTRA_CFLAGS
 #
 #	Subst's the following vars:
 #		DL_LIBS
-#		CFLAGS_DEBUG
-#		CFLAGS_OPTIMIZE
 #--------------------------------------------------------------------
 
 AC_DEFUN(SC_CONFIG_CFLAGS, [
@@ -603,8 +601,6 @@
     TCL_TRIM_DOTS='`echo ${VERSION} | tr -d .`'
     ECHO_VERSION='`echo ${VERSION}`'
     TCL_LIB_VERSIONS_OK=ok
-    CFLAGS_DEBUG=-g
-    CFLAGS_OPTIMIZE=-O
     if test "$using_gcc" = "yes" ; then
 	CFLAGS_WARNING="-Wall -Wconversion -Wno-implicit-int"
     else
@@ -1192,9 +1188,6 @@
     fi
 
     AC_SUBST(DL_LIBS)
-    AC_SUBST(CFLAGS_DEBUG)
-    AC_SUBST(CFLAGS_OPTIMIZE)
-    AC_SUBST(CFLAGS_WARNING)
 ])
 
 #--------------------------------------------------------------------

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: XML manpage conversion -- update

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

Hello,

I've done a little more work on the NROFF->XML->HTML
man page conversion; most of the cross-references are
working now.

In the process, a few other markup errors have turned up.
Could I get write access to the CVS repository, or would
you prefer a patch file?  I'd also like to add some of
the missing SEE ALSO sections and enhance the KEYWORDS
listings.

The TMML package (DTD and XSL specs for HTML output)
is close to being (alpha-)releasable; probably next
week sometime.

Haven't worked on back-converting the XML to NROFF --
I'm waiting for the Tcl-XML 2.0 release to stabilize
first.


--Joe English

  jen...@fl...

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.