tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Tcl/Tk 8.3.2 is FINAL - going out today

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

After looking into the issues, the confusion about whether the use
of TCL_DBGX is correctly created or not is not going to delay the
8.3.2 release.  I ran a test build of Tcl, Tk and TLS (as a sample
outside extension) and all worked fine with the use of --enable-symbols.

There may be improvements that we can still make, but I'm very
hesitant to touch such a sensitive spot so soon before a release.

Andreas also had another note about enhancing the docs, but that is
just as easy to go into 8.3.3/8.4 as a doc enhancement.

We should have the release out later today, barring any further
trouble reports.

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

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

[TCLCORE] Re: Tcl/Tk 8.3.2 (core-8-3-1-branch) should be considered FINAL

[Brent W. <we...@aj...>]

I'd be extremely cautious about changing the way TCL_DBGX works -
it's pretty delicate.  I am continually building both debug and non-debug
versions of Tcl and loads of extensions for TclPro, and never have a problem.
I suspect it may be in the way tkgs tries to use the macros more than
the way Tcl defines them.  

If the tclConfig.sh contains
TCL_STUB_LIB_FLAG='-ltclstub8.3${TCL_DBGX}'

then you need to have TCL_DBGX be set to "g" to pick up the right library.
It would be best to understand why you've built a tclstub8.3g.a but
are using a tclConfig.sh that doesn't define TCL_DBGX to be "g".
On possibility is that you've done multiple compiles of tcl, both with
and without debugging symbols.  Watch out here because the last compile
will install something into the installed lib directory 
(win32-ix86/lib/tclConfig.sh)
but for most reliable results you'll want the tclConfig.sh from
the Tcl build directory that matches the configuration you want.

In otherwords, for my TclPro builds, I'm always doing
--with-tcl=<the build directory>
and never letting this default to the installed lib directory.


Also, you suggest evaling the reference to TCL_DBGX in the Tcl configure,
but the whole point of quoting it is that you can tweak the TCL_DBGX setting
much later when you compile your extention to select exactly what you want.
Perhaps you just need to hammer in the value you want for TCL_DBGX
in the tkgs configure, and then do the eval on it.  This'll let you
select an arbitrary combination of debugging/non-debugging Tcl libraries
and debugging/non-debugging tkgs libraries.

Please - let's not change this right now for 8.3.2

>>>Mo DeJong said:
 > On Tue, 8 Aug 2000, Mo DeJong wrote:
 > 
 > > On Mon, 7 Aug 2000, Jeffrey Hobbs wrote:
 > > 
 > > > The code in the core-8-3-1-branch (readying for 8.3.2) should be
 > > > considered final.  Eric and I will be putting the code through
 > > > its drills on Tuesday, with the hope that we'll have a Wednesday
 > > > release of Tcl/Tk 8.3.2.
 > > > 
 > > > A few files related to release work (tcl.wse.in and such) may be
 > > > edited, as will 'changes' for the release notes, but aside from
 > > > that I expect everything is ready to go.
 > > > 
 > > > If anyone spots any serious problems with the current state of
 > > > core-8-3-1-branch (for tcl or tk), raise the red flag before
 > > > Wednesday morning.
 > > 
 > > 
 > > Well, this really is down to the wire, but...
 > > 
 > > There is a problem with the tclConfig.sh file generated by
 > > Tcl 8.3.2.
 > > 
 > > (from tclConfig.sh)
 > > 
 > > # -l flag to pass to the linker to pick up the Tcl stub library
 > > TCL_STUB_LIB_FLAG='-ltclstub8.3${TCL_DBGX}'
 > > 
 > > (from tkConfig.sh)
 > > TK_STUB_LIB_FLAG='-ltkstub8.3g'
 > > 
 > > This means that if you compile with debug symbols enabled,
 > > an extension that tries to link to Tcl's stub libs will
 > > generate an error like so:
 > > 
 > > gcc -shared -o libtkgs.so tkgs.o tkgsColor.o tkgsDrawable.o tkgsDriver.o 
 > > tkgsFont.o tkgsInit.o tkgsObj.o tkgsUnixInit.o drivers/ps/libtkgs_ps.a 
 > > drivers/canvas/libtkgs_canvas.a drivers/xlib/libtkgs_xlib.a 
 > > -L/home/mo/project/build/tcl_83 -ltclstub8.3 
 > > -L/home/mo/project/build/tk_83 -ltkstub8.3g
 > > /usr/bin/ld: cannot find -ltclstub8.3
 > > collect2: ld returned 1 exit status
 > 
 > 
 > Looks like I was a bit too quick with that patch.
 > This one should really fix the problem.
 > 
 > Index: configure.in
 > ===================================================================
 > RCS file: /home/cvs/external/tcl/unix/configure.in,v
 > retrieving revision 1.57.2.1
 > diff -u -r1.57.2.1 configure.in
 > --- configure.in        2000/07/27 01:39:22     1.57.2.1
 > +++ configure.in        2000/08/09 06:57:10
 > @@ -527,12 +527,12 @@
 >  
 >  MAKE_STUB_LIB="ar cr \${STUB_LIB_FILE} \${STUB_LIB_OBJS}"
 >  
 > -TCL_STUB_LIB_FILE=${STUB_LIB_FILE}
 > +eval TCL_STUB_LIB_FILE=\"${STUB_LIB_FILE}\"
 >  
 >  if test "${TCL_LIB_VERSIONS_OK}" = "ok"; then
 > -    TCL_STUB_LIB_FLAG="-ltclstub${TCL_VERSION}\${TCL_DBGX}"
 > +    eval TCL_STUB_LIB_FLAG="-ltclstub${TCL_VERSION}${TCL_DBGX}"
 >  else
 > -    TCL_STUB_LIB_FLAG="-ltclstub`echo ${TCL_VERSION} | tr -d .`\${TCL_DBGX}
     "
 > +    eval TCL_STUB_LIB_FLAG="-ltclstub`echo ${TCL_VERSION} | tr -d .`${TCL_D
     BGX}
 > "
 >  fi
 >  
 >  TCL_BUILD_STUB_LIB_SPEC="-L`pwd` ${TCL_STUB_LIB_FLAG}"
 > 
 > 
 > 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.
 > 

--	Brent Welch	<we...@aj...>
	http://www.ajubasolutions.com
	Scriptics changes to Ajuba Solutions
	scriptics.com => ajubasolutions.com


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

[TCLCORE] Something is very wrong in Tcl_InitHashTable.

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

There seems to be a core dumping bug in Tcl_InitHashTable that
it only appears in 8.4. I can run the exact same code
in Tcl 8.3 with no problems.

Here is the bit that crashes:

static Tcl_HashTable driverTable;

int TkGSInitDriverTable() {
  Tcl_InitHashTable(&driverTable, TCL_STRING_KEYS);
}

This is from the tkgs module, you can check it out
of the Net CVS using the module name "tkgs".


GDB prints a backtrace like this from the crash:

#0  0x401ab967 in TclDatedef () from 
/usr/local/project/install/Tcl/lib/libtcl8.4g.so
#1  0x403a1e1b in TkGSInitDriverTable () at 
/home/mo/project/tkgs/src/generic/tkgsDriver.c:14


I think this was caused by Paul's recent Hashtable
changes.

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: stacked channel docs

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

> I've rewritten the docs related the Tcl_CreateChannel (CrtChannel.3) and
> Tcl_StackChannel (ChnlStack.3) to reflect the "new way" of things.  Those
> concerned might want to check them out just in case I sound off-my-rocker.
> They are in the core-8-3-1-branch, not yet in the HEAD.

I think the section about the HandlerProc should mention that the return
value is the mask minus all the events processed by the transformation itself.

The rest looks good.

-- 
So long,
	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: Tcl/Tk 8.3.2 (core-8-3-1-branch) should be considered FINAL

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

On Tue, 8 Aug 2000, Mo DeJong wrote:

> On Mon, 7 Aug 2000, Jeffrey Hobbs wrote:
> 
> > The code in the core-8-3-1-branch (readying for 8.3.2) should be
> > considered final.  Eric and I will be putting the code through
> > its drills on Tuesday, with the hope that we'll have a Wednesday
> > release of Tcl/Tk 8.3.2.
> > 
> > A few files related to release work (tcl.wse.in and such) may be
> > edited, as will 'changes' for the release notes, but aside from
> > that I expect everything is ready to go.
> > 
> > If anyone spots any serious problems with the current state of
> > core-8-3-1-branch (for tcl or tk), raise the red flag before
> > Wednesday morning.
> 
> 
> Well, this really is down to the wire, but...
> 
> There is a problem with the tclConfig.sh file generated by
> Tcl 8.3.2.
> 
> (from tclConfig.sh)
> 
> # -l flag to pass to the linker to pick up the Tcl stub library
> TCL_STUB_LIB_FLAG='-ltclstub8.3${TCL_DBGX}'
> 
> (from tkConfig.sh)
> TK_STUB_LIB_FLAG='-ltkstub8.3g'
> 
> This means that if you compile with debug symbols enabled,
> an extension that tries to link to Tcl's stub libs will
> generate an error like so:
> 
> gcc -shared -o libtkgs.so tkgs.o tkgsColor.o tkgsDrawable.o tkgsDriver.o 
> tkgsFont.o tkgsInit.o tkgsObj.o tkgsUnixInit.o drivers/ps/libtkgs_ps.a 
> drivers/canvas/libtkgs_canvas.a drivers/xlib/libtkgs_xlib.a 
> -L/home/mo/project/build/tcl_83 -ltclstub8.3 
> -L/home/mo/project/build/tk_83 -ltkstub8.3g
> /usr/bin/ld: cannot find -ltclstub8.3
> collect2: ld returned 1 exit status


Looks like I was a bit too quick with that patch.
This one should really fix the problem.

Index: configure.in
===================================================================
RCS file: /home/cvs/external/tcl/unix/configure.in,v
retrieving revision 1.57.2.1
diff -u -r1.57.2.1 configure.in
--- configure.in        2000/07/27 01:39:22     1.57.2.1
+++ configure.in        2000/08/09 06:57:10
@@ -527,12 +527,12 @@
 
 MAKE_STUB_LIB="ar cr \${STUB_LIB_FILE} \${STUB_LIB_OBJS}"
 
-TCL_STUB_LIB_FILE=${STUB_LIB_FILE}
+eval TCL_STUB_LIB_FILE=\"${STUB_LIB_FILE}\"
 
 if test "${TCL_LIB_VERSIONS_OK}" = "ok"; then
-    TCL_STUB_LIB_FLAG="-ltclstub${TCL_VERSION}\${TCL_DBGX}"
+    eval TCL_STUB_LIB_FLAG="-ltclstub${TCL_VERSION}${TCL_DBGX}"
 else
-    TCL_STUB_LIB_FLAG="-ltclstub`echo ${TCL_VERSION} | tr -d .`\${TCL_DBGX}"
+    eval TCL_STUB_LIB_FLAG="-ltclstub`echo ${TCL_VERSION} | tr -d .`${TCL_DBGX}
"
 fi
 
 TCL_BUILD_STUB_LIB_SPEC="-L`pwd` ${TCL_STUB_LIB_FLAG}"


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: Tcl/Tk 8.3.2 (core-8-3-1-branch) should be considered FINAL

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

On Mon, 7 Aug 2000, Jeffrey Hobbs wrote:

> The code in the core-8-3-1-branch (readying for 8.3.2) should be
> considered final.  Eric and I will be putting the code through
> its drills on Tuesday, with the hope that we'll have a Wednesday
> release of Tcl/Tk 8.3.2.
> 
> A few files related to release work (tcl.wse.in and such) may be
> edited, as will 'changes' for the release notes, but aside from
> that I expect everything is ready to go.
> 
> If anyone spots any serious problems with the current state of
> core-8-3-1-branch (for tcl or tk), raise the red flag before
> Wednesday morning.


Well, this really is down to the wire, but...

There is a problem with the tclConfig.sh file generated by
Tcl 8.3.2.

(from tclConfig.sh)

# -l flag to pass to the linker to pick up the Tcl stub library
TCL_STUB_LIB_FLAG='-ltclstub8.3${TCL_DBGX}'

(from tkConfig.sh)
TK_STUB_LIB_FLAG='-ltkstub8.3g'

This means that if you compile with debug symbols enabled,
an extension that tries to link to Tcl's stub libs will
generate an error like so:

gcc -shared -o libtkgs.so tkgs.o tkgsColor.o tkgsDrawable.o tkgsDriver.o 
tkgsFont.o tkgsInit.o tkgsObj.o tkgsUnixInit.o drivers/ps/libtkgs_ps.a 
drivers/canvas/libtkgs_canvas.a drivers/xlib/libtkgs_xlib.a 
-L/home/mo/project/build/tcl_83 -ltclstub8.3 
-L/home/mo/project/build/tk_83 -ltkstub8.3g
/usr/bin/ld: cannot find -ltclstub8.3
collect2: ld returned 1 exit status

(Note how the g is not added in the Tcl case)

% ls /home/mo/project/build/tcl_83/libtclstub8.3g.a 
/home/mo/project/build/tcl_83/libtclstub8.3g.a

( This same problem shows up in 8.4 CVS by the way ).

So the question is, do we really want to use \${TCL_DBGX}
in configure.in?

if test "${TCL_LIB_VERSIONS_OK}" = "ok"; then
    TCL_STUB_LIB_FLAG="-ltclstub${TCL_VERSION}\${TCL_DBGX}"
else
    TCL_STUB_LIB_FLAG="-ltclstub`echo ${TCL_VERSION} | tr -d .`\${TCL_DBGX}"
fi


Note how Tk's configure.in uses an eval, which would
do the same thing (without escaping the $).

if test "${TCL_LIB_VERSIONS_OK}" = "ok"; then
    eval TK_STUB_LIB_FLAG="-ltkstub${TK_VERSION}\${TK_DBGX}"
else
    eval TK_STUB_LIB_FLAG="-ltkstub`echo ${TK_VERSION} | tr -d .`\${TK_DBGX}"
fi


After making this change, I was able to compile and run tkgs with Tcl 8.3.

Index: configure.in
===================================================================
RCS file: /home/cvs/external/tcl/unix/configure.in,v
retrieving revision 1.57.2.1
diff -u -r1.57.2.1 configure.in
--- configure.in        2000/07/27 01:39:22     1.57.2.1
+++ configure.in        2000/08/09 04:58:13
@@ -530,9 +530,9 @@
 TCL_STUB_LIB_FILE=${STUB_LIB_FILE}
 
 if test "${TCL_LIB_VERSIONS_OK}" = "ok"; then
-    TCL_STUB_LIB_FLAG="-ltclstub${TCL_VERSION}\${TCL_DBGX}"
+    TCL_STUB_LIB_FLAG="-ltclstub${TCL_VERSION}${TCL_DBGX}"
 else
-    TCL_STUB_LIB_FLAG="-ltclstub`echo ${TCL_VERSION} | tr -d .`\${TCL_DBGX}"
+    TCL_STUB_LIB_FLAG="-ltclstub`echo ${TCL_VERSION} | tr -d .`${TCL_DBGX}"
 fi
 
 TCL_BUILD_STUB_LIB_SPEC="-L`pwd` ${TCL_STUB_LIB_FLAG}"

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.

Re: stacked channel docs

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

--------
> I've rewritten the docs related the Tcl_CreateChannel (CrtChannel.3) and
> Tcl_StackChannel (ChnlStack.3) to reflect the "new way" of things.  Those
> concerned might want to check them out just in case I sound off-my-rocker.
> They are in the core-8-3-1-branch, not yet in the HEAD.

I think the section about the HandlerProc should mention that the return
value is the mask minus all the events processed by the transformation itself.

The rest looks good.

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

[TCLCORE] Tcl/Tk 8.3.2 (core-8-3-1-branch) should be considered FINAL

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

The code in the core-8-3-1-branch (readying for 8.3.2) should be
considered final.  Eric and I will be putting the code through
its drills on Tuesday, with the hope that we'll have a Wednesday
release of Tcl/Tk 8.3.2.

A few files related to release work (tcl.wse.in and such) may be
edited, as will 'changes' for the release notes, but aside from
that I expect everything is ready to go.

If anyone spots any serious problems with the current state of
core-8-3-1-branch (for tcl or tk), raise the red flag before
Wednesday morning.

Thanks,

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] stacked channel docs

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

I've rewritten the docs related the Tcl_CreateChannel (CrtChannel.3) and
Tcl_StackChannel (ChnlStack.3) to reflect the "new way" of things.  Those
concerned might want to check them out just in case I sound off-my-rocker.
They are in the core-8-3-1-branch, not yet in the HEAD.

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: Labeled frames (fwd)

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

Comments?

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

---------- Forwarded message ----------
Date: Fri, 28 Jul 2000 10:37:18 +0200 (MET DST)
From: Peter Spjuth <d1...@dt...>
To: Eric Melski <er...@aj...>
Subject: Re: Labeled frames (fwd)

> For
> example, instead of introducing 4 new fields for internal borderwidth, why
> not just two, overrideInternalBorderWidth and
> overrideInternalBorderWidthSide?  The first indicates an overriding value
> for the internal borderwidth, the second indicates to which side that
> value applies.  Only if the second is set to some meaningful value (ie,
> top, bottom, left, or right) is it used; otherwise, everything behaves
> exactly as before.

Yes, that is also possible, and I've thought some about that solution.
Here are my views of it compared to the solution in my patch:

1. A benefit is that it saves memory since only two fields are added to the
   TkWindow struct. 
2. It is still not backwards compatible and writing a geometry manager that
   is both 8.3 and 8.4 compatible would still be about as tricky.
   I can't see any difference between them in this aspect, but if I miss
   something, please let me know.
3. It is more complex and a bit harder to use for the geometry managers.
   To look up the left side width you'd need something like 
   field1 + (field2 == LEFT ? field3 : 0)
   instead of just looking up the left field.
4. It is less general, e.g. it does not allow for adding -padx/y options.
   That I like a general solution should be rather clear by now, but
   specifically I would find -padx/y very useful.

2. is the most important point, but since I can't see any difference there
I let the others decide. I think 1. is too small a benefit to justify 3. and 
4., so I still prefer mine.

Hmm, I'll try to put some of my thoughts about 2. into ascii.

For an extension implementing a geometry manager (which I think is the main
thing that are interested in this) I get the following relationship 
between versions:

One field for each side solution:

Ext  Core  
8.4  8.4 : Works easily.
8.4  8.3 : The extension needs to detect 8.3 and use the deprecated field.
8.3  8.4 : Works, as long as new frame stuff is not used.

Two new fields solution:

Ext  Core  
8.4  8.4 : Works easily, though not as easy as the other.
8.4  8.3 : The extension needs to detect 8.3 and not use the new fields.
8.3  8.4 : Works, as long as new frame stuff is not used.

So, you can see why I don't see much difference there.

I hope the above makes some sense, otherwise ask.

And I agree that this needs more discussion.
 
/Peter

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

[TCLCORE] Re: Documentation

[Larry W. V. <lv...@ca...>]

The only reason I suggested POD is because that is here now - the
XML has been something discussed for what, almost 2 years now.  A number
of people have put effort into it.  Perhaps it is just too large a task
to take on. 

-- 
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden <mailto:lv...@ca...> <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

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

[TCLCORE] Re: Documentation

[Larry W. V. <lv...@ca...>]

Re: what format for doc

The problem with choosing HTML is that currently that makes the 
doc unreadable by TkMan.  It would be much better to provide doc 
in one of the several formats that it reads.

Note that if one doesn't know *roff, there is always the pod2man 
filter that will convert from Perl's relatively simple format 
into a man page...


-- 
Larry W. Virden <URL: mailto:lv...@ca...> 
<URL: http://www.purl.org/net/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.


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

[TCLCORE] Re: Documentation

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

Jeffrey Hobbs wrote:
>
> This is a good question.  I think generally that HTML is a good minimum
> (can be read on all platforms).  It'd be nice to get an XML DTD standard
> in place so that we can start moving towards using XML as the base.
>
> Does anyone know how close we are to that?

The TMML DTD is now in pretty good shape, and the NROFF->TMML 
conversion script is running smoothly for the most part.

See <URL: http://www.flightlab.com/~joe/tmml/> for the current
snapshot.  I'm in the process of finishing the documentation
and putting together a tarball of the DTD, XSL scripts, and
up-conversion utilities.



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

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

As soon as we can get the effort rolling, we want to make XML the
base format for all docs, with converters to man/html/winhelp/etc.

Starting with pod is definitely not an alternative.  Note that
many perl'ers don't even like pod's limitations.  No need to waste
effort there when we can start fresh with XML.

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

> -----Original Message-----
> From: Mo DeJong [mailto:md...@cy...]
	...
> On Thu, 3 Aug 2000, Larry W. Virden wrote:
> 
> > Re: what format for doc
> > 
> > The problem with choosing HTML is that currently that makes the 
> > doc unreadable by TkMan.  It would be much better to provide doc 
> > in one of the several formats that it reads.
> > 
> > Note that if one doesn't know *roff, there is always the pod2man 
> > filter that will convert from Perl's relatively simple format 
> > into a man page...
> 
> I thought the docs were going to be written in XML and then
> get converted to HTML or whatever. It seems that people are
> going to complain about any one format that is picked.

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

[TCLCORE] Re: Documentation

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

On Thu, 3 Aug 2000, Larry W. Virden wrote:

> Re: what format for doc
> 
> The problem with choosing HTML is that currently that makes the 
> doc unreadable by TkMan.  It would be much better to provide doc 
> in one of the several formats that it reads.
> 
> Note that if one doesn't know *roff, there is always the pod2man 
> filter that will convert from Perl's relatively simple format 
> into a man page...

I thought the docs were going to be written in XML and then
get converted to HTML or whatever. It seems that people are
going to complain about any one format that is picked.

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

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

This is a good question.  I think generally that HTML is a good minimum
(can be read on all platforms).  It'd be nice to get an XML DTD standard
in place so that we can start moving towards using XML as the base.

Does anyone know how close we are to that?

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

> -----Original Message-----
> From: Christopher Nelson [mailto:ch...@pi...]
> Sent: Thursday, August 03, 2000 7:30 AM
> To: Jeffrey Hobbs
> Subject: Documentation
>
>
> I've got a couple of widgets that I'm considering contributing to tcllib (or
> tklib, or whatever) but I'm not sure what form you expect or require
> documentation to be in.  I can do HTML fairly easily but nroff would be really
> hard.
>
>                                             Chris
> --
> Rens-se-LEER is a county.  RENS-se-ler is a city.  R-P-I is a school!

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

[TCLCORE] Re: Time to retire tk_menuBar and tk_bindForTraversal?

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

On Tue, 1 Aug 2000, Joe English wrote:

> 
> On 1 Aug 2000, after installing a brand-spanking-new,
> bleeding edge Tcl/Tk 8.4 alpha 1 distribution fresh out
> of the Ajuba CVS repository, you can still type 'man menubar'
> and get:

While we are at it, could we retire the old pack interface too?

pack - Obsolete syntax for packer geometry manager

pack after ...
pack append  ...
pack before ...
pack unpack ...

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] Time to retire tk_menuBar and tk_bindForTraversal?

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

On 1 Aug 2000, after installing a brand-spanking-new,
bleeding edge Tcl/Tk 8.4 alpha 1 distribution fresh out
of the Ajuba CVS repository, you can still type 'man menubar'
and get:

| NAME
|   tk_menuBar,  tk_bindForTraversal - Obsolete  support for menu bars
|
| DESCRIPTION
|   These procedures were used in Tk 3.6 and earlier  releases
|   to  help  manage  pulldown menus and to implement keyboard
|   traversal of menus.  In Tk 4.0 and later releases they are
|   no  longer  needed.   Stubs for these procedures have been
|   retained for backward  compatibility,  but  they  have  no
|   effect.   You should remove calls to these procedures from
|   your code, since eventually the procedures will go away.


The 'menubar' man page from the Tk 4.0 release said the same
thing; that was in late 1994.  I think it's safe to say that
nobody is using these procedures anymore :-) and the following
files can be removed from the Tk distribution without any ill effect:

	library/obsolete.tcl
	doc/menubar.n

The pack-old(n) manpage is in a similar state.  Although
it's no longer even accurate (``this syntax continues
to be supported for backward compatibility'' -- it isn't)
it *might* still be useful to people who need to upgrade their
old Tk 3.3 apps.  Nevertheless, it too can probably be removed
without harm.

On a related note,  Interp(3) still describes the client-visible
fields of the Tcl_Interp structure (interp->result, interp->freeProc,
and interp->errorLine) in detail, even though access
to these fields has been deprecated at least since Tcl 7.4
(released mid-1995) and *strongly* deprecated since Tcl 8.0
(released mid-1997).  Perhaps this should go away as well?

Are there any other deprecated APIs anyone can think of?


--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] Linux Weekly News and Tcl

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

On http://www.lwn.net/2000/0727/devel.php3 I see a section about
'Language Links'. One perl and three python links, but none for tcl :(

Which sites should we submit to them for inclusion ?


Oh, on a side note, if the domains
	http://www.tcltk.org/,
	http://www.tcl-tk.org/

etc. are not available anymore, think about

	http://www.tcl-lang.org/

Ruby uses that format for its toplevel site.

-- 
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: Creative Tcl ChangeLog entries.

[Brent W. <we...@aj...>]

I'm the guilty party - as an old-fart vi user I don't have the fancy
emacs macros to help me generate the ChangeLog file.  I'll be more
standard in the future.

>>>Mo DeJong said:
 > I don't mean to complain, but I have noticed some
 > "creative" entries showing up in Tcl and Tk
 > Changelogs.
 > 
 > Most ChangeLogs entries follow this format:
 > 
 >         * unix/Makefile.in:
 >         * win/Makefile.in: makefile cleanup
 > 
 > But there also seem to be some "creative" ones:
 > 
 >         * win/{Makefile.in,configure.in,tkConfig.sh.in}: 
 >         Cleanup of defines in tkConfig.sh
 > 
 > This conflicts with the GNU coding standards.
 > 
 > http://www.gnu.org/prep/standards.html
 > 
 > Could we please stick to the GNU standards? It really
 > does make you life easier later one. For instance,
 > I might grep the ChangeLog for "win/Makefile.in",
 > that would not match win/{Makefile.in,...
 > 
 > thanks
 > 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.
 > 

--	Brent Welch	<we...@aj...>
	http://www.ajubasolutions.com
	Scriptics changes to Ajuba Solutions
	scriptics.com => ajubasolutions.com


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

Re: [TCLCORE] Linux Weekly News and Tcl

[Brent W. <we...@aj...>]

www.tcltk.org is available and owned by Michael McLennan.
I believe he is waiting until the new Tcl Core Team stuff actually
materializes and has its own website.  While I appreciate the power
of that motivation, I would still love to see it as an alias for
dev.scriptics.com in the meantime.  As creator of the dev.scriptics.com
site I can assure you that we are all eager to see that replaced by
a community-run website.  Also, Ajuba is also ready to pony up the
machine and our ISP connection to host www.tcltk.org.  I'm not really
wedded to any particular Tcl-powered web site: TclHttpd, Velocigen,
AOLserver.  I already use two of those.

>>>Andreas Kupries said:
 > 
 > On http://www.lwn.net/2000/0727/devel.php3 I see a section about
 > 'Language Links'. One perl and three python links, but none for tcl :(
 > 
 > Which sites should we submit to them for inclusion ?
 > 
 > 
 > Oh, on a side note, if the domains
 > 	http://www.tcltk.org/,
 > 	http://www.tcl-tk.org/
 > 
 > etc. are not available anymore, think about
 > 
 > 	http://www.tcl-lang.org/
 > 
 > Ruby uses that format for its toplevel site.
 > 
 > -- 
 > 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.
 > 

--	Brent Welch	<we...@aj...>
	http://www.ajubasolutions.com
	Scriptics changes to Ajuba Solutions
	scriptics.com => ajubasolutions.com

[TCLCORE] Re: TclDomPro?

[Al B. <aw...@aj...>]

There's currently no immediate active development of TclDomPro here at
Ajuba.  Since our goal in making TDP open source was to accomplish
a merge with TclDom, and as the nominal maintainer of TDP here at
Ajuba, I'd say go ahead with your changes.

But let us know first about anything that changes the API.

- Al   

Joe English wrote:
> 
> What's the status of the TclDomPRO package?
> 
> I've fixed some bugs and added a feature to the copy that
> Steve Ball checked in (CVS module external/tcldom/src),
> but haven't applied these to the original copy
> (CVS module external/tcldompro/src).
> 
> I'm about to do some more serious hacking on tcldom/src
> to integrate it with the Zveno tcldom package,
> so I guess I ought to coordinate with whoever
> is maintaining the "Pro" version...
> 
> --Joe English
> 
>   jen...@fl...
> 
> (P.S. Re: Creative ChangeLog entries -- I'm one of the guilty
> parties -- sorry about that -- although I plead ignorance.
> As penance I will re-read the GNU coding standards document :-)

-- 

Albert Biggerstaff           Phone: (650) 210-0142
Ajuba Solutions              Email: aw...@aj...

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

[TCLCORE] Re: friday's "Patch submittal for generic/tclExecute.c"

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

Sorry, stupid mistake: the patch file enclosed on friday's message won't
even compile! So, again, disregard my last message.

I am enclosing a corrected patch with this, only in case you might be
curious ...  This one does compile and pass the tests.

The performance difference being so small, I think it is quite
understndable if you chose to diregard the whole thing anyway. As I
said, I believe the main difference may be to the programmer who wants
to touch TclExecuteByteCode rather than in the program itself.

The next one will be either much much better, or else non-existent; I
fear I may be becoming a candidate for no-spam lists.

Greetings
Miguel

[TCLCORE] Re: Notes about Perl6 ideas - good to read

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

> Also sprach Jeffrey Hobbs:
 
>> ...  Sure, Tcl is great as it is, but for a lot of people its only
>> great when they have itcl, blt, tix, patches for better C++
>> compatibility, more data structures, etc etc.  Fewer and fewer are
>> truly satisfied with what the "core" provides.

> This is just slightly off the point, but I don't understand this
> last couple of sentences.  It seems like you are implying that the
> fact that the core of Tcl, by itself, is an incomplete solution for
> most complicated tasks is a bad thing.  Is that right?
 
> I thought the aim was to get more stuff out of the core (making it
> thereby even LESS satisfactory by itself) and then making the
> process of acquiring & deploying extensions so easy that you would
> never hesitate to do so...  That is still our goal, right?

I can't speak for the others, but for me this is one of the goals to
pursue and quite high on the priority list.


> As for introducing backwards incompatibilities, I agree with Brent a
> bit that we should not break Tcl compatibility unless there is some
> really compelling need.  I don't see any evils of the Tcl language
> that we are likely to cure in a good way (as opposed to, for
> instance, introducing some other comment syntax that breaks the
> current Tcl mold), that would require backwards incompatilibilities
> at the syntax level.  But in any case, this should be approached
> with some caution.

As can be seen in the discussion on c.l.t about {}$ and {}[ by Paul
Duffin.  I certainly like the basic idea behind that but the chosen
syntax was something which felt like syntactic salt to me (in opposition
to the syntactic sugar Richard Suchenwirth is so fond of).

> It would, on the other hand, be nice to rearrange some of the
> commands to be a little more coherent.  It would be good to gather
> all the list commands together,

Part of that is already done through the 'listx' command.

> and maybe even make the open & socket commands return objects, so we
> can get rid of this horrible mess of fconfigure, fblocked, eof...
> But I don't think that any of the subsystems are so badly designed
> right now that we couldn't provide wrappers for the old syntax...
 
> As for C level changes, this should really be a community vote type
> thing.  We need to balance the desire to clean up & make more
> powerful the new internals that were introduced in 8.0 & friends,
> with the need to carry along most of the major extensions.  So
> before we start wholesale changes like this, we should have a
> discussion of the merits, and make sure we have easy transition
> paths for all the many bits of C code out there...
 

-- 
So long,
	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] TclDomPro?

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

What's the status of the TclDomPRO package?

I've fixed some bugs and added a feature to the copy that
Steve Ball checked in (CVS module external/tcldom/src),
but haven't applied these to the original copy
(CVS module external/tcldompro/src).

I'm about to do some more serious hacking on tcldom/src
to integrate it with the Zveno tcldom package,
so I guess I ought to coordinate with whoever
is maintaining the "Pro" version...


--Joe English

  jen...@fl...

(P.S. Re: Creative ChangeLog entries -- I'm one of the guilty
parties -- sorry about that -- although I plead ignorance.
As penance I will re-read the GNU coding standards document :-)

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