tcl-core — Tcl Core Team discussions about Tcl development

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

[TCLCORE] Re: [Fwd: tk dialog texts, german translaton, umlaut changes]

[Laurent D. <lau...@uf...>]

-- 
Laurent Duperval                   "Montreal winters are an intelligence test,
U|Force - Java Center                     and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:lau...@uf...      Penguin Power!

[TCLCORE] Re: Labeled frames (fwd)

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

Peter Spjuth is working on labeled frames for Tk 8.4.  Please read over
his thoughts on this below, and let's try to get some constructive
criticism back to him quickly.  My own comments follow Peter's proposal.

-------------------------------------------------------------------------
Hi!

I've started to work on adding labels to frames in Tk, and would appreciate
some input of what features people want. I've thought some about it and
below are my views of the subject.


1. Label contents.

This can be all from supporting a simple text to supporting all options of 
a normal label. I.e. some subset of the following standard options:
-text -font -justify -wraplength -underline
-textvariable -fg -bitmap -image

Instead of "-text", "-label" can be used, even though I can't understand
why one would want that. Personally I find it confusing that menuitems and
scales use "-label" when every other widget uses "-text" for the same thing.

Since I prefer a general solution, my goal is to support all of them.


2. Label placement.

I have looked at some widget sets to get a view of what is needed.
These widgets have the following settings for label placement:

BWidget, LabelFrame    : top, bottom, left, right
BWidget, TitleFrame    : left, center, right  
tixLabelFrame          : top, left, right, bottom, none, acrosstop
Iwidgets, labeledframe : ne,n,nw,se,s,sw,en,e,es,wn,w,ws

In addition, "TitleFrame" has a -baseline argument to set if the label
should be above, on, or below the border, and "labeledframe" has
-labelmargin to further control the placement.

I would choose to use -labelpos (ne,n,nw,se,s,sw,en,e,es,wn,w,ws) from 
Iwidgets and a variation of -baseline (inner, center, outer) from BWidget, 
which would be a nice general solution that covers all cases.

With "nw" as default for "-labelpos" and "center" as default for
"-baseline", a labeled frame as they are often used would be:
frame .f -text Hej -relief groove -bd 2


3. Frame padding

I think it's a useful feature to be able to add padding between the
frame border and the "child area". For this, these widgets use the
following options:

BWidget, TitleFrame    : -ipadx, -ipady
tixLabelFrame          : -padx, -pady
Iwidgets, labeledframe : -ipadx, -ipady

I think we should have them, and call them -padx/y. They are standard 
options and the behaviour here matches what I expect from them.


Comments?

/Peter

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

My primary concern with this proposal is that it seems too complex.  I
think that the support for labels on frames should be fairly minimalistic
-- specify an anchor (nw, n, ne, etc.), the text, and the font.  This
should address the most common uses (probably > 95% of all instances of
labeled frame usage).  I can't think of an instance of a labeled frame
that doesn't have the text vertically centered on the frame border, at
the top left side of the frame.  I don't think it's necessary to add
support for specifying the baseline for the label, or additional label
positioning tweaks.  I think that support for those features will just
make the widget harder to learn, harder to implement, and harder to
maintain.  If a programmer needs more flexibility in the positioning of
the label, they can always use the current method ([place] a label in the
right spot). I'm also not sure that we should immediately support
bitmap/images for the label.  This adds more complexity again, and I'm not
sure it's worth it.  I don't think I have ever seen a labeled frame that
used anything but text for the label.

   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: TkGS & TkDND imported into Tcl Dev Xchange NetCVS

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

TkGS, maintained by Bonnet and DeJong, and TkDND, maintained by Petasis,
have been imported and correctly added to the module list so that they
can be checked out under the names 'tkgs' and 'tkdnd' respectively.

One change was made to TkDND - the 'src' dir was renamed to 'generic'
to note that it has generic sources (next to the 'unix' and 'win'
sibling dirs that were already there).  I updated all instances of
'src/' that I could find before importing.

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: Does anyone see a problem with this threads related configure change?

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

I would like to remove the --enable-threads option from Tk
(and any other extensions for that matter). It does not
seem logical to be able to build Tcl without thread support
and Tk with thread support. Here is a patch that implements
this change, I want to make sure anyone that thinks it is
a bad idea gets a chance to object. This patch also
adds a TCL_THREADS variable to tclConfig.sh so that
extensions can find out if Tcl was compiled with
thread support.

Mo DeJong
Red Hat Inc

Index: unix/configure.in
===================================================================
RCS file: /cvsroot/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/03 14:20:53
@@ -567,6 +567,7 @@
 AC_SUBST(LDFLAGS)
 AC_SUBST(MAKE_LIB)
 AC_SUBST(TCL_SHARED_BUILD)
+AC_SUBST(TCL_THREADS)
 AC_SUBST(SHLIB_CFLAGS)
 AC_SUBST(SHLIB_LD)
 AC_SUBST(STLIB_LD)
Index: unix/tcl.m4
===================================================================
RCS file: /cvsroot/tcl/unix/tcl.m4,v
retrieving revision 1.22
diff -u -r1.22 tcl.m4
--- tcl.m4	2000/04/14 06:42:41	1.22
+++ tcl.m4	2000/07/03 14:20:54
@@ -223,6 +223,27 @@
     AC_SUBST(TCL_BIN_DIR)
     AC_SUBST(TCL_SRC_DIR)
     AC_SUBST(TCL_LIB_FILE)
+
+
+    # We need to find out if Tcl was compiled with thread
+    # support. We can not build an extension with thread
+    # support if Tcl is not built with thread support.
+
+    AC_MSG_CHECKING([to see if Tcl was compiled with thread support])
+
+    if test "$TCL_THREADS" = "1"; then
+        # Define the following option so that they will
+        # be passed in the CFLAGS variable. We do not
+        # need to worry about THREADS_LIBS because that
+        # gets added to the LIBS variable.
+
+        AC_MSG_RESULT([yes])
+        AC_DEFINE(TCL_THREADS)
+        AC_DEFINE(_REENTRANT)
+        AC_DEFINE(_THREAD_SAFE)
+    else
+        AC_MSG_RESULT([no])
+    fi
 ])
 
 #------------------------------------------------------------------------
@@ -331,7 +352,10 @@
 #------------------------------------------------------------------------
 # SC_ENABLE_THREADS --
 #
-#	Specify if thread support should be enabled
+#	Specify if thread support should be enabled for Tcl. This
+#	macro can not be called from an extension's configure.in
+#	because it is not possible to build an extension with thread
+#	support if Tcl itself is not compiled with thread support.
 #
 # Arguments:
 #	none
@@ -347,6 +371,7 @@
 #	Defines the following vars:
 #		TCL_THREADS
 #		_REENTRANT
+#		_THREAD_SAFE
 #
 #------------------------------------------------------------------------
 
@@ -354,6 +379,13 @@
     AC_MSG_CHECKING(for building with threads)
     AC_ARG_ENABLE(threads, [  --enable-threads        build with threads],
 	[tcl_ok=$enableval], [tcl_ok=no])
+
+    # Make sure this macro is not getting include in an extensions
+    # configure.in by checking for the tcl.h include file.
+
+    if test ! -f ${TCL_SRC_DIR}/generic/tcl.h ; then
+        AC_MSG_ERROR([The --enable-threads macro can only be used in 
Tcl's configure.in])
+    fi
 
     if test "$tcl_ok" = "yes"; then
 	AC_MSG_RESULT(yes)
Index: unix/tclConfig.sh.in
===================================================================
RCS file: /cvsroot/tcl/unix/tclConfig.sh.in,v
retrieving revision 1.14
diff -u -r1.14 tclConfig.sh.in
--- tclConfig.sh.in	2000/06/20 21:30:34	1.14
+++ tclConfig.sh.in	2000/07/03 14:20:54
@@ -38,6 +38,9 @@
 # Flag, 1: we built a shared lib, 0 we didn't
 TCL_SHARED_BUILD=@TCL_SHARED_BUILD@
 
+# Flag, 1: we built Tcl with threads support, 0 we didn't
+TCL_THREADS=@TCL_THREADS@
+
 # The name of the Tcl library (may be either a .a file or a shared library):
 TCL_LIB_FILE='@TCL_LIB_FILE@'

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

[TCLCORE] Re: Tk patch

[<ldu...@sp...>]

Hi,

The following patch fixes a problem that was reported by George Petasis.

L

[TCLCORE] Re: tkDND release...

[Giorgos P. <pe...@II...>]

Dear Mr. Hobbs,

As both developers of the tkDND extension (me and Laurent) are
leaving for vacations, we have decided to make a release of our current
code in order to be in time for the tk8.4a2 release. We will be back
by the mid of August...

I also think that this is a good time to add tkDND to your cvs server.
Please inform me for the necessary steps I have to do before tomorrow 
(if any :-))

The current status of tkDND is as follows:

Currently only unix & windows versions are available.

Unix:
Everything is working. A few things missing from the Motif protocol.
No known bugs :-)

Windows:
Main functionality working. There are some known problems.

Code for both platforms is compiling with out warnings and does not
cause wish to crash.
Unix side is in C only and is TEA compliant (I hope :-)).
Tested under solaris & linux. Supported protocol is XDND
extended with Motif drops. Motif drag is not fully functional yet.

There is a man page and a few tutorials in the demo directory.
Currently no tests (how can something like this be tested?)

The windows code is not as well structured as the unix code, but we
plan a re-write from scratch. We are now at the process of reading 
the OLE dnd manuals :-)

Please inform me (pe...@ii...) what your plans for the extension are
ASAP. Is it going to actually be in tk8.4a2? My opinion is that at least the unix
code should be in order to gain feedback from end users...

The home page for tkDND is at http://www.iit.demokritos.gr/~petasis/tcl

Best regards,

George

RE: Translations strings in CVS

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

> In Dai, 13 Eiye 2000, Jeffrey Hobbs wrote:
> > There is a limitation on exactly how some characters can be sent to
> > the event mechanism, because it requires the X-style translated
> > name, but this seems to have been accepted OK for me (via C&P because
> > I can't directly type in that character):
> >
> > (tkcon) 53 % bind .t \373 { puts "K %K A %A"}
> > (tkcon) 54 % bind .t ? { puts "K %K A %A"}
> > (tkcon) 55 %
> 
> Well for me, under tkcon 1.6, 31 March 1999 does not work.
	...
> bad event type or keysym "?"

Actually, I fooled myself.  My original thoughts were correct in that
it requires the X-style name.  Eric added the new 'keysyms' page to
show all these.  This doesn't work in 8.3.1 WinHelp, but you can see
it in the Unix docs of 8.4a1 at:
	http://dev.scriptics.com/man/tcl8.4/TkCmd/keysyms.htm

>Main< (tkcon) 60 % puts \374
u
>Main< (tkcon) 61 % bind .t \374 { puts " u umlaut " }
>Main< (tkcon) 62 % bind .t <Alt-\374> { puts " u umlaut " }
bad event type or keysym "u"
>Main< (tkcon) 63 % format %o 252
374
>Main< (tkcon) 64 % bind .t <Alt-udiaeresis> { puts " u umlaut " }

You'll have to find out what the correct mapping for that greek
character is.  If I do:

>Main< (tkcon) 71 % scan ? %c
240

Then I can see that 240 in the table in the URL above gives 'eth',
and then we have:

>Main< (tkcon) 73 % bind .t <Alt-eth> { puts " eth " }
>Main< (tkcon) 74 % 

Of course, I can't type in the eth here...

This will be something that everybody has to deal with.  One heuristic
is that if [scan $char %c] >= 127, then you'll need to have a mapping
for that character.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (nee Scriptics)

[TCLCORE] Re: RE: Translations strings in CVS

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

There is a limitation on exactly how some characters can be sent to
the event mechanism, because it requires the X-style translated
name, but this seems to have been accepted OK for me (via C&P because
I can't directly type in that character):

(tkcon) 53 % bind .t \373 { puts "K %K A %A"}
(tkcon) 54 % bind .t ð { puts "K %K A %A"}
(tkcon) 55 %

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

> -----Original Message-----
> From: Giorgos Petasis [mailto:pe...@ii...]
	...
> But the "Retry" button was now in greek. Tkcon, underlined the first character
> and while trying to impose a binding on the first letter (the greek
> p), an error
> occured: "bad event type or keysym "ð"".

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

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

Here are some responses to more comments from Jeff Law (former maintainer
of gcc development).  Insightful.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (nee Scriptics)

-----Original Message-----
From: Jeffrey A Law [mailto:la...@cy...]
Sent: Monday, July 10, 2000 9:07 PM
To: Jeffrey Hobbs
Subject: Re: Q about managing open source development 



  In message <NDB...@aj...>you
 write:
  > > So we contacted a group of folks, not necessarily all developers, that ha
  > d
  > > a long term interest in seeing GCC succeed and who were well respected
  > > in different communities that used GCC.   The steering committee basicall
  > y
  > > deals with political issues, not technical ones (which we leave in the ha
  > nds
  > > of the developers, where it belongs).  We've been very happy with the res
  > ults.
  > 
  > What is the difference between "political" and "technical" issues for you?
Political is anything non-technical :-)

ie, stuff like who's in charge of releases, when/who do we give global 
write access to the tree, how to deal with problem posters and dealing with
making sure that nobody's taking advantage of their position within the
project to push an agenda that is not in the project's best interest.

ie if Cygnus/Red Hat was to try and close development to not include its
competitors it's the steering committee's responsiblity to step in and
take appropriate action -- which would likely be revoking any write privs
for Cygnus/Red Hat folks that were taking advantage of their positions within
the project.

They're the 'or else'  behind the "play by the rules we've established or
else ..." way we run the project.


  > In creating the steering committee, is it functionally a figure-head group?
Nope.  They're not a figure-head group, but the hope is that there aren't
a lot of political kinds of things to do on a regular basis.  ie, most of
the work in a free software project *should* be technical.  Make the code
better (by whatever measurement of better is appropriate) -- not dealing with
infighting between developers :-)

  > We are trying to determine how to set up the technical future decision
  > making process, and thought that the steering committee would be used for
  > that.
It could.  It does to a small extent for GCC -- mostly in areas where
technical decisions have the potential for significant political consequences.

For example a technical direction which would ultimately undermine the FSF's
core goals/values would be one where the steering committee would have to 
step in and say "sorry, you can't do example, making sure that Cygnus/Red Hat
doesn't take advantage of having a large number of contributors and steer
the project away from its core goals.

It's definitely not a figure-head group, though in theory a steering
committee to deal with political issues shouldn't have a whole lot to
do in a technical free software project :-)  Though they do come up from
time to time.

Consider if there was some patches which made it easy for people to write
new front-ends or optimization passes that where not part of GCC (ie they
communicated with GCC via pipes/files).  That would undermine the FSF's
stated goals and the steering committee would have to get involved and
prevent such patches from being installed (and take appropriate action if
someone violated that decree).

  >   One model that the Apache Software Foundation uses is that incoming
  > ideas can be vetoed by a single member, and otherwise ideas must get at
  > least two supporting votes before getting in.  Who controls those kind of
  > feature related issues in gcc?
That's mostly hashed out on the development lists.  Sometimes the arguments
get a little heated, but they usually work themselves out.  We do not allow
a single member of either the technical community or the steering committee
to block actions.  That was done on purpose to prevent one person from 
instigating gridlock by just vetoing everything they didn't like.

That takes some time for people to get used to, but I think it's worked out
reasonably well.

Basically the core ideas behind the project stem from what was so badly
messed up in GCC development before the EGCS project was started.  Single
personalities were able to control/stall development simply by being
jerks and were able to move the project in what most developers considered
the wrong direction simply because those one or two people ultimately
controlled every aspect of the project including dissemination of information.

jeff

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

[TCLCORE] Re: Translations strings in CVS

[Giorgos P. <pe...@ii...>]

Hi all,

I have found a typo in the greek translations.
Attached you will find the updated file.

Also, in the version of tk I downloaded from cvs server 2 days ago,
when an error occurs, the button labeled "Details >>" does not
use the translated string. Is this now fixed?

Well, to say the truth it is a surpise to see messages in your native language.
I like it. And tk probably looks the LANG & LC_* vars under unix to automatically
use the correct language! If only the system encoding was set automatically too :-)

George