Request for Input -- trees

9 views
Skip to first unread message

Al Biggerstaff

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
We at Scriptics are considering augmenting the core with additional data
structures, and
are curious as to what the demand is, and how they might be used.

Are there applications that could use trees? Multi-level associative
arrays?

--

Al Biggerstaff
Scriptics Corporation

Nat Pryce

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to

Al Biggerstaff wrote:
>
> We at Scriptics are considering augmenting the core with additional data
> structures, and
> are curious as to what the demand is, and how they might be used.

How about collaborating on the Feather package?

--
+------------------------------------------+---------------------+
| Name: Nat Pryce MEng ACGI | Dept. of Computing, |
| Email: n...@doc.ic.ac.uk | Imperial College, |
| Tel: +44 (0)171 594 8394 | 180 Queen's Gate, |
| Fax: +44 (0)171 581 8024 | London SW7 2BZ, |
| WWW: http://www-dse.doc.ic.ac.uk/~np2 | United Kingdom |
+------------------------------------------+---------------------+

Mike Tiller

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Nat Pryce <n...@doc.ic.ac.uk> writes:

> Al Biggerstaff wrote:
> >
> > We at Scriptics are considering augmenting the core with additional data
> > structures, and
> > are curious as to what the demand is, and how they might be used.
>
> How about collaborating on the Feather package?

Sounds like a good idea to me too.

As for the original question, I think trees would be valuable because
they would provide a mechanism for getting data into and out of
hierarchy widgets. I would also like the ability to have keyed lists
like in TclX.

--
Michael Tiller
Ford Motor Company

Christopher Nelson

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Al Biggerstaff wrote:
>
> ...
>
> Al Biggerstaff
> Scriptics Corporation

I'm sorry, I gotta ask -- "Biggerstaff"? Was he hired in the same group with
John Smallberries?

Chris
--
Rens-se-LEER is a county. RENS-se-ler is a city. R-P-I is a school!

James Ingham

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Al,

If you are going to do this, PLEASE coordinate your efforts with
George Howlett. His hierarchy widget is nice, and he is working on
abstracting the data part of the hierarchy widget out of it to make a
tree object. It would be a real shame if you produced something that
could not be used in BLT. By the way, trees would be useful for many
things, for instance I would love to have a good tree data structure
to use to display variables in GDBTk...

Jim

> We at Scriptics are considering augmenting the core with additional data
> structures, and
> are curious as to what the demand is, and how they might be used.
>

> Are there applications that could use trees? Multi-level associative
> arrays?
>
> --
>
> Al Biggerstaff
> Scriptics Corporation

--
++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
Jim Ingham jin...@cygnus.com
Cygnus Solutions Inc.

Harald Kirsch

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
In article <3770EFCE...@scriptics.com> Al Biggerstaff <a...@scriptics.com> writes:
> We at Scriptics are considering augmenting the core with additional data
> structures, and
> are curious as to what the demand is, and how they might be used.

1) "Invertible" arrays or maybe it can be called two-way associative
arrays, i.e. for a given value, I want to ask the array for all
indexes which store that element.


2) Binary Typed Arrays. They would be something similar to
blt::vector, however they would not be restricted to type `double'.
Don't forget to implement byte-swapping also for float and double
values.

These type of arrays are pretty well suited to quick-hack conversion
scripts for any type of strange binary file format you meet.

An excerpt from an extension which never really made it into the
public reads like:


BITA(N) TCL/TK Extension Manual BITA(N)

NAME
Bita - Binary Typed Arrays for Tcl/Tk

SYNOPSIS
Short name ?name ...?

UShort name ?name ...?

Int name ?name ...?

Unsigned name ?name ...?

Float name ?name ...?

Double name ?name ...?

Bitas are designed to efficiently store and manipulate
large numbers of binary values of a given type. Initially,
a Bita contains no values and has length zero. As values
are added or deleted, the length varies accordingly.

The following commands are implemented (name is the name of a bita).

name copy dstIndex srcBita ?from? ?to?
name get ?from? ?to?
name insert dstIndex values
name length
(name minmax ?from? ?to?)
name pop
name push value
name read dstIndex file count
name remove ?from? ?to?
name set dstIndex newValues
name trunc length
name write file ?from? ?to?

Harald Kirsch
--
---------------------+------------------+--------------------------
Harald Kirsch (@home)| | Now I rebooted.
k...@iitb.fhg.de | | --- Jerry Pournelle, BYTE
gegen Punktfilitis hilft nur `chmod u-w ~'

Alexandre Ferrieux

unread,
Jun 24, 1999, 3:00:00 AM6/24/99
to
Al Biggerstaff wrote:
>
> We at Scriptics are considering augmenting the core with additional data
> structures, and
> are curious as to what the demand is, and how they might be used.
>
> Are there applications that could use trees? Multi-level associative
> arrays?

Please please before thinking about new and exotic bells and whistles,
do strengthen the internals. By this I mean, make sure you synchronize
with Paul Duffin and know all the nasty spots that he has discovered
when developing his Feather package (which BTW is an obvious candidate
for the new-types contest).

For example, there are many places where hard-coded calls (ie NOT
through the stubs table) inside the core made it difficult to extend
today's types.

IOW some things require a core patch, while with a better design they
could have been done in a loadable extension. So if all these mistakes
are setteled first, it will be a much better ground for all future
evolutions.

-Alex

Cameron Laird

unread,
Jun 24, 1999, 3:00:00 AM6/24/99
to
In article <3771E3...@cnet.francetelecom.fr>,

Alex makes sense to me. While I'd doubtless use
the features under consideration at least occasi-
onally, strengthening the core with stubifying
rewrites and such would help every project, every
day.
--

Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 281 996 8546 FAX

Paul Alexander

unread,
Jun 24, 1999, 3:00:00 AM6/24/99
to
In article <3771E3...@cnet.francetelecom.fr>, Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> writes:
>Al Biggerstaff wrote:
>>
>> We at Scriptics are considering augmenting the core with additional data
>> structures, and
>> are curious as to what the demand is, and how they might be used.
>>
>> Are there applications that could use trees? Multi-level associative
>> arrays?
>
>Please please before thinking about new and exotic bells and whistles,
>do strengthen the internals. By this I mean, make sure you synchronize
>with Paul Duffin and know all the nasty spots that he has discovered
>when developing his Feather package (which BTW is an obvious candidate
>for the new-types contest).
>
>For example, there are many places where hard-coded calls (ie NOT
>through the stubs table) inside the core made it difficult to extend
>today's types.
>
>IOW some things require a core patch, while with a better design they
>could have been done in a loadable extension. So if all these mistakes
>are setteled first, it will be a much better ground for all future
>evolutions.
>
>-Alex

If scriptics were to develop such things as extensions it would have two
benefits (1) avoid the core growing, but much more importantly (2) enable
scriptics to debug/enhance the core so that the public API enabled such
extensions to be built without core patches.


Dr. Paul Alexander
Department of Physics, Cavendish Laboratory,
University of Cambridge, Cambridge, UK.

FAX: 44 1223 354 599
Tel: 44 1223 337 308

Wolf-Dietrich Ihlenfeldt

unread,
Jun 24, 1999, 3:00:00 AM6/24/99
to
In article <3770EFCE...@scriptics.com>,

Al Biggerstaff <a...@scriptics.com> writes:
> We at Scriptics are considering augmenting the core with additional data
> structures, and
> are curious as to what the demand is, and how they might be used.
>
> Are there applications that could use trees? Multi-level associative
> arrays?
>

Yes, trees would be a great addition. On a more elementary level,
I'd like to see 64 bit ints and unsigned ints. This is important
if you want to link, for example, the size of a large file to
a variable. 2/4 Gb is not sufficient anymore. Having Tcl_Objs
which retain their 'unsigned' characteristics until forced
into a signed representation would be nice in general.


--
Dr. Wolf-D. Ihlenfeldt
Computer Chemistry Center, University of Erlangen-Nuernberg
Naegelsbachstrasse 25, D-91052 Erlangen (Germany)
Tel (+49)-(0)9131-85-26579 Fax (+49)-(0)9131-85-26566
---
The three proven methods for ultimate success and fame:
1) Nakanu nara koroshite shimae hototogisu
2) Nakanu nara nakasete miseyou hototogisu
3) Nakanu nara naku made matou hototogisu

Doug Hughes

unread,
Jun 24, 1999, 3:00:00 AM6/24/99
to
In article <7kt7ln$g9m$1...@rznews.rrze.uni-erlangen.de>, w...@ccc.uni-erlangen.de (Wolf-Dietrich Ihlenfeldt) writes:
>
> Yes, trees would be a great addition. On a more elementary level,
> I'd like to see 64 bit ints and unsigned ints. This is important
> if you want to link, for example, the size of a large file to
> a variable. 2/4 Gb is not sufficient anymore. Having Tcl_Objs
> which retain their 'unsigned' characteristics until forced
> into a signed representation would be nice in general.
>

Count me in on the 64 bit stuff. I'm writing a backup app that uses
Tcl and I have to do all my math in C for filesystems greater than
2G (and there are quite a few these days).

64 bitedness has become rather imperative. That, and for SNMP where
signed 32bit math won't work on busy networks very well once
you get up to the range where the signed vs. unsigned makes a difference.

Trees would also be useful.

--
____________________________________________________________________________
Doug Hughes Engineering Network Services
System/Net Admin Auburn University
do...@eng.auburn.edu

Scott Redman

unread,
Jun 24, 1999, 3:00:00 AM6/24/99
to
We have been looking at Feather. And, yes, we know that the core will
need some changes (Feather provides a good example of some things we
may want to do). A new data type could be a loadable extension,
shipped with the Tcl/Tk core (a "core" extension like DDE or Registry).

-- Scott

Alexandre Ferrieux wrote:


>
> Al Biggerstaff wrote:
> >
> > We at Scriptics are considering augmenting the core with additional data
> > structures, and
> > are curious as to what the demand is, and how they might be used.
> >
> > Are there applications that could use trees? Multi-level associative
> > arrays?
>

Scott Redman

unread,
Jun 24, 1999, 3:00:00 AM6/24/99
to
Correct me if I'm wrong, doesn't Tcl support 64bit ints when
built on 64bit systems such as Solaris 7 with the --enable-64bit
flag to configure, or any Alpha Unix platform?

The long data type in Tcl is a "long", but could potentially be
changed to "long long" for C compilers that support it, but I
don't know what other implications this may have.

-- Scott

Colin Macleod

unread,
Jun 24, 1999, 3:00:00 AM6/24/99
to
Al Biggerstaff <a...@scriptics.com> wrote in
<3770EFCE...@scriptics.com>:

>We at Scriptics are considering augmenting the core with additional data
>structures, and
>are curious as to what the demand is, and how they might be used.
>
>Are there applications that could use trees? Multi-level associative
>arrays?
>

About a year ago I posted a suggestion to convert Tcl arrays
to "first-class" values. This didn't get much response, and
I didn't have time to develop it further myself, but I still
think it could be worth doing, and would be relatively simple.

A whole array could be treated as a single value (internally,
another type of Tcl_Obj) whose string value would be the list
of pairs used in "array get/set", but could also have its elements
accessed using the usual array syntax. This would allow us
to build structures such as a list whose elements are arrays,
or real multi-dimensional arrays, ie. an array whose elements
are arrays. Currently we can nest lists inside an array, but
not the other way around.

We could also pass a whole array to a procedure by value or
make it the return value of a procedure, avoiding the usual
tricks with "upvar".

Last year Andreas Kupries (I think) pointed out that this is
similar to the keyed lists in TclX, but when I examined them
I found that they do lookups by sequential search, not through
a hash table, so they would not scale up well.

--
Colin Macleod, SW Eng, Alcatel Telecom.
Email (remove added spaces to use): Colin . 2 . Macleod @ bt . com

Tom Poindexter

unread,
Jun 24, 1999, 3:00:00 AM6/24/99
to
In article <1999Jun2...@netman.eng.auburn.edu>,

Doug Hughes <do...@eng.auburn.edu> wrote:
>In article <7kt7ln$g9m$1...@rznews.rrze.uni-erlangen.de>,
>w...@ccc.uni-erlangen.de (Wolf-Dietrich Ihlenfeldt) writes:
>
>Count me in on the 64 bit stuff. I'm writing a backup app that uses
>Tcl and I have to do all my math in C for filesystems greater than
>2G (and there are quite a few these days).

Hi Doug,

Just curious, have you tried my Mpexpr extension for Tcl? It's still
a C extension, but you should be able to do all of the math in Tcl.


--
Tom Poindexter
tpoi...@nyx.net
http://www.nyx.net/~tpoindex/

Gerald W. Lester

unread,
Jun 25, 1999, 3:00:00 AM6/25/99
to
Harald Kirsch wrote:
In article <3770EFCE...@scriptics.com> Al Biggerstaff <a...@scriptics.com> writes:
> We at Scriptics are considering augmenting the core with additional data
> structures, and
> are curious as to what the demand is, and how they might be used.

1) "Invertible" arrays or maybe it can be called two-way associative

arrays, i.e. for a given value, I want to ask the array for all
indexes which store that element.

This would be useful.

--
+--------------------------------+---------------------------------------+
| Gerald W. Lester               | "The man who fights for his ideals is |
| gerald...@mtolive-lcms.org  |  the man who is alive." -- Cervantes  |
|               Webmaster for http://www.mtolive-lcms.org                |
+--------------------------------+---------------------------------------+
 

Gerald W. Lester

unread,
Jun 25, 1999, 3:00:00 AM6/25/99
to
Scott Redman wrote:
We have been looking at Feather.  And, yes, we know that the core will
need some changes (Feather provides a good example of some things we
may want to do).  A new data type could be a loadable extension,
shipped with the Tcl/Tk core (a "core" extension like DDE or Registry).
I woould like to see some things moved out of the core and into core extension. I think the socket code would be one good canidate for such a move.

The idea behind this is to make the core as small as possible (what ever is needed for package require) and then have scripts require the addons. This allows for a smaller footprint most of the time and also documents (via the package require) what segments of tcl are being used.

Nat Pryce

unread,
Jun 25, 1999, 3:00:00 AM6/25/99
to
"Gerald W. Lester" wrote:
> I woould like to see some things moved out of the core and into core
> extension. I think the socket code would be one good canidate for such
> a move.
>
> The idea behind this is to make the core as small as possible (what
> ever is needed for package require) and then have scripts require the
> addons. This allows for a smaller footprint most of the time and also
> documents (via the package require) what segments of tcl are being
> used.

I agree. This would be very nice. In fact, I think the event
loop should be pulled out of the core to make it easier to
embed a very minimal Tcl interpreter into a program.

Cheers,
Nat.

Jean-Claude Wippler

unread,
Jun 25, 1999, 3:00:00 AM6/25/99
to
Nat Pryce wrote:
>
> "Gerald W. Lester" wrote:
> > I woould like to see some things moved out of the core and into core
> > extension. I think the socket code would be one good canidate for
> > such a move.
> >
> > The idea behind this is to make the core as small as possible (what
> > ever is needed for package require) and then have scripts require
> > the addons. This allows for a smaller footprint most of the time and
> > also documents (via the package require) what segments of tcl are
> > being used.
>
> I agree. This would be very nice. In fact, I think the event
> loop should be pulled out of the core to make it easier to
> embed a very minimal Tcl interpreter into a program.

Me three.

FWIW, here's a small Tcl interpreter (rewritten from scratch, in C++):
http://mini.net/pub/ts1/
It's called "TinyTCL" (TinyTCL Is Not Yet TCL) for good reason: it's
only a start, and lacks several things such as namespaces and traces.
But it looks, walks, and quacks like Tcl nevertheless :)

-- Jean-Claude

Wolf-Dietrich Ihlenfeldt

unread,
Jun 25, 1999, 3:00:00 AM6/25/99
to
In article <37725B02...@scriptics.com>,

Scott Redman <red...@scriptics.com> writes:
> Correct me if I'm wrong, doesn't Tcl support 64bit ints when
> built on 64bit systems such as Solaris 7 with the --enable-64bit
> flag to configure, or any Alpha Unix platform?
>
> The long data type in Tcl is a "long", but could potentially be
> changed to "long long" for C compilers that support it, but I
> don't know what other implications this may have.

I do not know about Solaris, but on IRIX you can use 32-bit longs
and a 64-bit file system in parallel, if you do not want to use 64 bit
for all ints, which has significant consequences to program size
and memory requirements, and tends to introduce nasty
problems with numerous 3rd-party libraries. I'd prefer to have a basic
32-bit Tcl core with dedicated code to handle those 64-bit
entities.

>
> -- Scott


>
> Doug Hughes wrote:
>>
>> In article <7kt7ln$g9m$1...@rznews.rrze.uni-erlangen.de>, w...@ccc.uni-erlangen.de (Wolf-Dietrich Ihlenfeldt) writes:
>> >

>> > Yes, trees would be a great addition. On a more elementary level,
>> > I'd like to see 64 bit ints and unsigned ints. This is important
>> > if you want to link, for example, the size of a large file to
>> > a variable. 2/4 Gb is not sufficient anymore. Having Tcl_Objs
>> > which retain their 'unsigned' characteristics until forced
>> > into a signed representation would be nice in general.
>> >
>>

>> Count me in on the 64 bit stuff. I'm writing a backup app that uses
>> Tcl and I have to do all my math in C for filesystems greater than
>> 2G (and there are quite a few these days).
>>

>> 64 bitedness has become rather imperative. That, and for SNMP where
>> signed 32bit math won't work on busy networks very well once
>> you get up to the range where the signed vs. unsigned makes a difference.
>>
>> Trees would also be useful.
>>
>> --
>> ____________________________________________________________________________
>> Doug Hughes Engineering Network Services
>> System/Net Admin Auburn University
>> do...@eng.auburn.edu

--

Christopher Nelson

unread,
Jun 25, 1999, 3:00:00 AM6/25/99
to
Paul Alexander wrote:
>
> In article <3771E3...@cnet.francetelecom.fr>, Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> writes:
> >Al Biggerstaff wrote:
> >>
> >> We at Scriptics are considering augmenting the core with additional data
> >> structures, and are curious as to what the demand is, and how they might
> >> be used.

> If scriptics were to develop such things as extensions it would have two


> benefits (1) avoid the core growing, but much more importantly (2) enable
> scriptics to debug/enhance the core so that the public API enabled such
> extensions to be built without core patches.

AMEN!

brent...@my-deja.com

unread,
Jun 25, 1999, 3:00:00 AM6/25/99
to
In article <37737A69...@equi4.com>,
Jean-Claude Wippler <j...@equi4.com> wrote:

> FWIW, here's a small Tcl interpreter (rewritten from scratch, in C++):
> http://mini.net/pub/ts1/
> It's called "TinyTCL" (TinyTCL Is Not Yet TCL) for good reason: it's
> only a start, and lacks several things such as namespaces and traces.
> But it looks, walks, and quacks like Tcl nevertheless :)

Cool - what parts of the Tcl test suite does it pass?
The test suite gives us a nice fixed point to talk about
functional subsets of Tcl.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Don Porter

unread,
Jun 25, 1999, 3:00:00 AM6/25/99
to
Paul Alexander <p...@mrao.cam.ac.uk> wrote:
> If scriptics were to develop such things as extensions it would have two
> benefits (1) avoid the core growing, but much more importantly (2) enable
> scriptics to debug/enhance the core so that the public API enabled such
> extensions to be built without core patches.

and 3) those extensions would be great examples for other extension
writers to follow.

--
| Don Porter, D.Sc. Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/mcsd/Staff/DPorter/ NIST |
|______________________________________________________________________|

Cameron Laird

unread,
Jun 25, 1999, 3:00:00 AM6/25/99
to
In article <3773145D...@home.com>,
Gerald W. Lester <gwle...@home.com> wrote:
.
.

.
>> 1) "Invertible" arrays or maybe it can be called two-way associative
>> arrays, i.e. for a given value, I want to ask the array for all
>> indexes which store that element.
>
>This would be useful.
.
.
.
... and also a LOT slicker coded in C than pure Tcl.
I've asked for it in the past.

I can live without it, though; I'll keep building my
own inverting arrays or other hacks as performance
requires. What I want are the Big Core Issues--error
corrections, improving modularizability methods, that
sort of thing.

Cameron Laird

unread,
Jun 25, 1999, 3:00:00 AM6/25/99
to
In article <37731559...@home.com>,

Gerald W. Lester <gwle...@home.com> wrote:
.
.
.
>I woould like to see some things moved out of the core and into core extension.
>I think the socket code would be one good canidate for such a move.
Seconded.

>
>The idea behind this is to make the core as small as possible (what ever is
>needed for package require) and then have scripts require the addons. This
Me, too.
.
.

Christopher Nelson

unread,
Jun 25, 1999, 3:00:00 AM6/25/99
to
Cameron Laird wrote:
>
> modularizability

Look THAT up in your Funk and Wagnall's!

Jean-Claude Wippler

unread,
Jun 25, 1999, 3:00:00 AM6/25/99
to
Brent,


> In article <37737A69...@equi4.com>,
> Jean-Claude Wippler <j...@equi4.com> wrote:
>
> > FWIW, here's a small Tcl interpreter (rewritten from scratch, in C++):
> > http://mini.net/pub/ts1/
> > It's called "TinyTCL" (TinyTCL Is Not Yet TCL) for good reason: it's
> > only a start, and lacks several things such as namespaces and
> > traces. But it looks, walks, and quacks like Tcl nevertheless :)
>
> Cool - what parts of the Tcl test suite does it pass?
> The test suite gives us a nice fixed point to talk about
> functional subsets of Tcl.

Thanks :)

Well, I wanted to start out at the low end, and took a few Tcl 7.6 tests
as a first step. For now, quoting the readme:
- passes some basic Tcl 7.6 tests from "concat.test" and "list.test"
- still fails on a handful of these, but several dozen pass
- needed kludges in "all" to make tests work, other files unmodified

It was an exercise, which made it clear that a lot of work is needed to
churn out support for all the commands currently in Tcl (of couse, why
else would it have taken a decade to evolve Tcl to where it is now...).

To add some random notes about what TinyTcl is and isn't:
- it does upvars using C++ overloading (there's no upvar flag)
- namespaces are not in yet, but it looks like a natural fit
- maybe traces can be implemented as an option (derived class?)
- bytecode compilation might be added as extension (seriously!)
- lists/arrays are implemented as STL vectors/maps for now
- internally, array are first-class objects, it could be exposed
- TinyTcl has been gathering dust on my disk for months now :(

One goal of TinyTcl was to experiment with shared strings and memory-
mapped files. None of that is in there, but that is why the string
mechanism used is based on <ptr,len> tuples, not zero-terminated data.
It lays the groundwork for doing things like a "split" command which
works incrementally on a memory mapped file, i.e. as generator, instead
of reading all data first and splitting an entire file. The logical
next step would be to allow things like "foreach x [generator] {}".

Another goal was to see how far one could take the stubs approach, by
using C++ vtables as the natural equivalent of that mechanism. I did
not get that far with it, especially in terms of trying to also cross
shared-lib boundaries with it. Then again, even of those few primitives
now in TinyTcl, some 90% are implemented as seperate modules, using C++
derived classes. Also, TinyTcl has a minor/major mechanism which lets
one mix Tcl and C++ code - even within the same major command. So, yes,
TinyTcl is very, very modular.

In the end, I got bogged down by the amount of work needed to add all
the primitives. Which was to be expected.

More importantly, it led to some new ideas about how to handle the core
data structures and strings. And that's as far as it went back then...

-- Jean-Claude

Doug Hughes

unread,
Jun 25, 1999, 3:00:00 AM6/25/99
to
In article <93024379...@iris.nyx.net>, tpoi...@nyx10.nyx.net (Tom Poindexter) writes:
> In article <1999Jun2...@netman.eng.auburn.edu>,
> Doug Hughes <do...@eng.auburn.edu> wrote:
> >In article <7kt7ln$g9m$1...@rznews.rrze.uni-erlangen.de>,
> >w...@ccc.uni-erlangen.de (Wolf-Dietrich Ihlenfeldt) writes:
> >
> >Count me in on the 64 bit stuff. I'm writing a backup app that uses
> >Tcl and I have to do all my math in C for filesystems greater than
> >2G (and there are quite a few these days).
>
> Hi Doug,
>
> Just curious, have you tried my Mpexpr extension for Tcl? It's still
> a C extension, but you should be able to do all of the math in Tcl.
>

Not yet. I planned on looking for an mp extension one of these days
but hadn't gotten around to it yet. Still support for unsigned longs
would be a useful thing to have in the core.

I'll definitely try it out though, thanks.

Heribert Dahms

unread,
Jun 25, 1999, 3:00:00 AM6/25/99
to
In <377364FE...@doc.ic.ac.uk> n...@doc.ic.ac.uk (Nat) writes:

: "Gerald W. Lester" wrote:
: > I woould like to see some things moved out of the core and into core


: > extension. I think the socket code would be one good canidate for such
: > a move.

: >
: > The idea behind this is to make the core as small as possible (what


: > ever is needed for package require) and then have scripts require the

: > addons. This allows for a smaller footprint most of the time and also


: > documents (via the package require) what segments of tcl are being
: > used.
:
: I agree. This would be very nice. In fact, I think the event
: loop should be pulled out of the core to make it easier to
: embed a very minimal Tcl interpreter into a program.

In consequence of the other thread about implementing wish as a script
calling tclsh, you could in turn have a tclsh *script* invoking the real
bare bones core executable (e.g. tclcore8.3) plus some package require ...


Bye, Heribert (da...@ifk20.mach.uni-karlsruhe.de)

Bryan Oakley

unread,
Jun 25, 1999, 3:00:00 AM6/25/99
to
"Gerald W. Lester" wrote:
> I woould like to see some things moved out of the core and into core
> extension. I think the socket code would be one good canidate for such
> a move.
>
> The idea behind this is to make the core as small as possible (what
> ever is needed for package require) and then have scripts require the
> addons. This allows for a smaller footprint most of the time and also
> documents (via the package require) what segments of tcl are being
> used.

Most definitely. I like the idea that a sequence of "package require"
statements would help document exactly what is required for a script to
run. This would be really nice for things like wrappers (tools that make
stand alone executables out of tcl scripts), by allowing only what the
script actually needs to run to be wrapped.

Do we have a quorum yet? :-)

--
Bryan Oakley mailto:oak...@channelpoint.com
ChannelPoint, Inc. http://purl.oclc.org/net/oakley

Education is full of oversimplified lies which can be
refined into the truth later.

David N. Lombard

unread,
Jun 26, 1999, 3:00:00 AM6/26/99
to
Scott Redman <red...@scriptics.com> wrote in message
news:37725B02...@scriptics.com...

> Correct me if I'm wrong, doesn't Tcl support 64bit ints when
> built on 64bit systems such as Solaris 7 with the --enable-64bit
> flag to configure, or any Alpha Unix platform?
>
> The long data type in Tcl is a "long", but could potentially be
> changed to "long long" for C compilers that support it, but I
> don't know what other implications this may have.

Supporting 64-bit files on a 32-bit system is unrelated to building an LP-64
or ILP-64 program.

Most of the UNIXes now support 64-bit files either through a feature test
macro that allows your everyday open(), lseek(), fcntl() calls to work for
64-bit of_t values, or by explicit use of open64(), lseek64(), and
fcntl64(). An important item of this second version was to provide a
typedef for the 64-bit type on a 32-bit system (long long is an example of
the underlying type, there are others), and a macro for a fomat
specification for said typedef.

Scriptics would be well advised to:

1) Support 64-bit files on a 32-bit system. This just requires a little bit
of clear coding and recognition that any off_t value will now be an off64_t.

2) Permit either ILP-32 or LP-64 builds. I don't know that an ILP-64 build
is necessary, especially if a 64-bit int is available.


BTW - Windows supports a 64-bit files size, but doesn't have a 64-bit
integral type, making coding a pain -- don't to it that way...

--
David N. Lombard
(Change "_" to "." in address)


Scott Redman

unread,
Jun 26, 1999, 3:00:00 AM6/26/99
to
<snip>


> Most of the UNIXes now support 64-bit files either through a feature test
> macro that allows your everyday open(), lseek(), fcntl() calls to work for
> 64-bit of_t values, or by explicit use of open64(), lseek64(), and
> fcntl64(). An important item of this second version was to provide a
> typedef for the 64-bit type on a 32-bit system (long long is an example of
> the underlying type, there are others), and a macro for a fomat
> specification for said typedef.
>
> Scriptics would be well advised to:
>
> 1) Support 64-bit files on a 32-bit system. This just requires a little bit
> of clear coding and recognition that any off_t value will now be an off64_t.

Please file a feature request on our website for this. It's level of importance
will depend on the number/types of requests for a new feature such as this.
This "feature" may be better off as a loadable extension, in which case
anyone can implement it, not necessarily Scriptics (_I_ haven't heard any
grumblings about this until this week in this thread on c.l.t.). Actually,
probably not Scriptics in the near future.

Personally, I like the idea of this being a loadable extension. It doesn't
create unnecessary baggage on systems that are not LP-64 systems. With all of
the grumbling about the core being too large, we really don't need anything
like this inside the core that will only be used by a few people. On LP-64
systems, file operations are already 64bit (someone correct me if I'm wrong).



> 2) Permit either ILP-32 or LP-64 builds. I don't know that an ILP-64 build
> is necessary, especially if a 64-bit int is available.

We already do this, except on Alpha systems which are currently forced
into LP-64 builds (we don't have one and nobody has sent a patch to allow
32bit compiles) and probably a few other LP-64 systems. We (Scriptics) do
not support ILP-64 systems until someone sends us a patch for them. Most
inexpensive 64bit machines are LP-64. On Solaris 7/64bit, you have the
--enable-64bit option to configure, but only works with Sun's compiler
so far.

> BTW - Windows supports a 64-bit files size, but doesn't have a 64-bit
> integral type, making coding a pain -- don't to it that way...

Yes, it does, at least with VC++: __int64



> --
> David N. Lombard
> (Change "_" to "." in address)

-- Scott

Christopher Nelson

unread,
Jun 26, 1999, 3:00:00 AM6/26/99
to
Scott Redman wrote:
>
> <snip>

> Please file a feature request on our website for this. It's level of importance
> will depend on the number/types of requests for a new feature such as this.

So, once a request is in the write-only store of the BugForm database, how do we
add our voice to support the request? We need to be able to 1) review the
database, 2) click a button on the review form to say, "Me, too!"

Scott Redman

unread,
Jun 26, 1999, 3:00:00 AM6/26/99
to
We _are_ working on a mechanism to view the database. #2 is another story,
I don't remember what our decision was, but you can (if all else fails)
file another bug report and reference the original. If the bug report
was echoed to c.l.t., someone will be reading the responses. I'll mention
this to the Customer Service & Web people.

-- Scott

David N. Lombard

unread,
Jun 26, 1999, 3:00:00 AM6/26/99
to
Scott Redman <red...@scriptics.com> wrote in message
news:3774FCAE...@scriptics.com...> > 1) Support 64-bit files on a

32-bit system. This just requires a little bit
> > of clear coding and recognition that any off_t value will now be an
off64_t.
> Personally, I like the idea of this being a loadable extension. It
doesn't
> create unnecessary baggage on systems that are not LP-64 systems. With
all of

Just to make sure you understand this:

64-bit file support and 64-bit system OS's are UN-RE-LA-TED.

Bryan Oakley

unread,
Jun 27, 1999, 3:00:00 AM6/27/99
to
Andreas Kupries wrote:

>
> Christopher Nelson <ch...@pinebush.com> writes:
>
> > Cameron Laird wrote:
> > >
> > > modularizability
> >
> > Look THAT up in your Funk and Wagnall's!
>
> .... crrk ... Guru meditation error ...
>
> Please explain this reference ...

That was a bit from the '60's "Rowen and Martin's Laugh-In" TV show in
the US. I suppose it was intended to be a bit risque. Say "Funk and"
fast enough and it sounds a bit rude.

Anyone know for certain that that is where it originated, or did it
predate Laugh-In?

Andreas Kupries

unread,
Jun 28, 1999, 3:00:00 AM6/28/99
to
cmac...@mcs.dundee.ac.uk (Colin Macleod) writes:

> About a year ago I posted a suggestion to convert Tcl arrays
> to "first-class" values. This didn't get much response, and
> I didn't have time to develop it further myself, but I still
> think it could be worth doing, and would be relatively simple.

[...good reasons for arrays as first-class values...]

> Last year Andreas Kupries (I think) pointed out that this is similar
> to the keyed lists in TclX, but when I examined them I found that
> they do lookups by sequential search, not through a hash table, so
> they would not scale up well.

Oh. That is a pity. I thought that in this times of having Tcl_Obj an
implementation based on hashtables would be the natural thing.

--
Sincerely,
Andreas Kupries <a.ku...@westend.com>
<http://www.westend.com/~kupries/>
-------------------------------------------------------------------------------

Andreas Kupries

unread,
Jun 28, 1999, 3:00:00 AM6/28/99
to
Christopher Nelson <ch...@pinebush.com> writes:

> Cameron Laird wrote:
> >
> > modularizability
>
> Look THAT up in your Funk and Wagnall's!

.... crrk ... Guru meditation error ...

Please explain this reference ...

--

Andreas Kupries

unread,
Jun 28, 1999, 3:00:00 AM6/28/99
to
Bryan Oakley <oak...@channelpoint.com> writes:

> "Gerald W. Lester" wrote:

>> The idea behind this is to make the core as small as possible (what
>> ever is needed for package require) and then have scripts require
>> the addons. This allows for a smaller footprint most of the time
>> and also documents (via the package require) what segments of tcl
>> are being used.

> Most definitely. I like the idea that a sequence of "package
> require" statements would help document exactly what is required for
> a script to run. This would be really nice for things like wrappers
> (tools that make stand alone executables out of tcl scripts), by
> allowing only what the script actually needs to run to be wrapped.

> Do we have a quorum yet? :-)

How many people do we need for that ?

Whatever number, I am in on this.

Paul Duffin

unread,
Jun 28, 1999, 3:00:00 AM6/28/99
to
Al Biggerstaff wrote:
>
> We at Scriptics are considering augmenting the core with additional data
> structures, and
> are curious as to what the demand is, and how they might be used.
>
> Are there applications that could use trees? Multi-level associative
> arrays?
>

http://purl.org/thecliff.tcl/wiki/Feather
http://purl.oclc.org/net/pduffin/home/feather/feather.htm

--
Paul Duffin
DT/6000 Development Email: pdu...@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880 International: +44 1962-816880

Volker Hetzer

unread,
Jun 28, 1999, 3:00:00 AM6/28/99
to
Cameron Laird wrote:
>
> In article <37731559...@home.com>,
> Gerald W. Lester <gwle...@home.com> wrote:
> .
> .
> .
> >I woould like to see some things moved out of the core and into core extension.
> >I think the socket code would be one good canidate for such a move.
> Seconded.
Thirded.
Same for I/O in general.

> >
> >The idea behind this is to make the core as small as possible (what ever is
> >needed for package require) and then have scripts require the addons. This

> Me, too.
Ditto.

Tcl could be reduced to a core with the interpreter and the important concepts
like events, arrays, the "types" and the package mechanism plus modules for list manipulation,
arithmetic stuff, control structures, ...

Greetings!
Volker

Volker Hetzer

unread,
Jun 28, 1999, 3:00:00 AM6/28/99
to
brent...@my-deja.com wrote:
>
> In article <37737A69...@equi4.com>,
> Jean-Claude Wippler <j...@equi4.com> wrote:
>
> > FWIW, here's a small Tcl interpreter (rewritten from scratch, in C++):
> > http://mini.net/pub/ts1/
> > It's called "TinyTCL" (TinyTCL Is Not Yet TCL) for good reason: it's
> > only a start, and lacks several things such as namespaces and traces.
> > But it looks, walks, and quacks like Tcl nevertheless :)
>
> Cool - what parts of the Tcl test suite does it pass?
> The test suite gives us a nice fixed point to talk about
> functional subsets of Tcl.
Absolutely great!
Could you please keep us posted?
Greetings!
Volker

Donal K. Fellows

unread,
Jun 28, 1999, 3:00:00 AM6/28/99
to
In article <8DEFB42A6Coli...@news.intra.bt.com>,

Colin Macleod <cmac...@mcs.dundee.ac.uk> wrote:
> About a year ago I posted a suggestion to convert Tcl arrays
> to "first-class" values. This didn't get much response, and
> I didn't have time to develop it further myself, but I still
> think it could be worth doing, and would be relatively simple.
[...]

Now *that* is something that I'd find useful. You can sort-of do it
using [array get] and [array set] but it is horrendously inefficient
in the case where you want to ship some data into a procedure. And
all too often [upvar] is too slow too (and it doesn't have call by
value semantics either...)

> Last year Andreas Kupries (I think) pointed out that this is
> similar to the keyed lists in TclX, but when I examined them
> I found that they do lookups by sequential search, not through
> a hash table, so they would not scale up well.

In many ways, keyed lists and arrays are spiritual "brothers", both
being implementations (assoclists and hashes respectively) of the
general concept of a map (which is the big-boys' version of a
function.) They have slightly different properties (assoclists can
retain ordering, hashes provide fast general-case lookup, insertion,
update and deletion) and so I'd say there is plenty of room for both.


Onwards to my personal Tcl wishlist. :^)

* What I would really like in the core is a mechanism whereby I could
register a command to be called when another (particular) command
is deleted. A bit like [trace variable $var u $script] offers for
variables.

* Closures would be *ultra-neat* too. Namespaces and stack contexts
are only half-hearted versions of this...

Neither of them are new datatypes, I'm afraid (OK, so I've never
really felt incredibly constrained by the current situation.) Both
would be very useful. And the first (if you ignore the case of where
the interpreter is itself being deleted) is also quite easy to do, I
think.

Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>

lvi...@cas.org

unread,
Jun 28, 1999, 3:00:00 AM6/28/99
to

According to Andreas Kupries <a.ku...@westend.com>:

:Christopher Nelson <ch...@pinebush.com> writes:
:
:> Cameron Laird wrote:
:> >
:> > modularizability
:>
:> Look THAT up in your Funk and Wagnall's!
:
:.... crrk ... Guru meditation error ...
:
:Please explain this reference ...

Funk and Wagnall's was (is?) a popular encylopedia/dictionary (frequently
sold door to door earlier in this century). Bryan's mentioned the
pop cultural reference to the phrasing itself...
--
<URL: mailto:lvi...@cas.org> Quote: Saving the world before bedtime.
<*> O- <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.

Scott Redman

unread,
Jun 28, 1999, 3:00:00 AM6/28/99
to
Yes, I do, but how many people on 32bit systems need access
to 64bit file systems? Not many (yet), so keeping this as
a loadable extension reduces the extra code in the core.
If people don't mind that extra code, then someone should
send us the patch to provide this support.

-- Scott

Donal K. Fellows

unread,
Jun 29, 1999, 3:00:00 AM6/29/99
to
In article <377778FD...@abg1.siemens.de>,
Volker Hetzer <volker...@abg1.siemens.de> wrote:

> Cameron Laird wrote:
>> Gerald W. Lester <gwle...@home.com> wrote:
>>> I woould like to see some things moved out of the core and into
>>> core extension. I think the socket code would be one good
>>> canidate for such a move.
>> Seconded.
> Thirded.

Fourthed. (Yuck phrase!)

Serial-line I/O too? OK, it'd be a really small package...

> Same for I/O in general.

You need at least some I/O in order to load scripts and extensions.
Otherwise you cannot load packages...

Paul Duffin

unread,
Jun 29, 1999, 3:00:00 AM6/29/99
to
Colin Macleod wrote:
>
> Al Biggerstaff <a...@scriptics.com> wrote in
> <3770EFCE...@scriptics.com>:

>
> >We at Scriptics are considering augmenting the core with additional data
> >structures, and
> >are curious as to what the demand is, and how they might be used.
> >
> >Are there applications that could use trees? Multi-level associative
> >arrays?
> >
>
> About a year ago I posted a suggestion to convert Tcl arrays
> to "first-class" values. This didn't get much response, and
> I didn't have time to develop it further myself, but I still
> think it could be worth doing, and would be relatively simple.
>
> A whole array could be treated as a single value (internally,
> another type of Tcl_Obj) whose string value would be the list
> of pairs used in "array get/set", but could also have its elements
> accessed using the usual array syntax. This would allow us
> to build structures such as a list whose elements are arrays,
> or real multi-dimensional arrays, ie. an array whose elements
> are arrays. Currently we can nest lists inside an array, but
> not the other way around.
>
> We could also pass a whole array to a procedure by value or
> make it the return value of a procedure, avoiding the usual
> tricks with "upvar".

>
> Last year Andreas Kupries (I think) pointed out that this is
> similar to the keyed lists in TclX, but when I examined them
> I found that they do lookups by sequential search, not through
> a hash table, so they would not scale up well.
>

It is not quite as easy as all of that. Take a look at
http://purl.oclc.org/net/pduffin/home/tcl.htm
Specifically at the "Mutable object" and "Feather" pages (still under
construction).

quaz...@hotmail.com

unread,
Jun 30, 1999, 3:00:00 AM6/30/99
to
On 29 Jun 1999 08:18:44 GMT, fell...@cs.man.ac.uk (Donal K. Fellows)
wrote:

>In article <377778FD...@abg1.siemens.de>,
>Volker Hetzer <volker...@abg1.siemens.de> wrote:
>> Cameron Laird wrote:
>>> Gerald W. Lester <gwle...@home.com> wrote:
>>>> I woould like to see some things moved out of the core and into
>>>> core extension. I think the socket code would be one good
>>>> canidate for such a move.
>>> Seconded.
>> Thirded.
>
>Fourthed. (Yuck phrase!)
>
>Serial-line I/O too? OK, it'd be a really small package...
>
>> Same for I/O in general.
>
>You need at least some I/O in order to load scripts and extensions.
>Otherwise you cannot load packages...
>
>Donal.

You could build this functionality using peek & poke :-)

Victor Wagner

unread,
Jul 2, 1999, 3:00:00 AM7/2/99
to
Al Biggerstaff <a...@scriptics.com> wrote:
: We at Scriptics are considering augmenting the core with additional data

: structures, and
: are curious as to what the demand is, and how they might be used.

: Are there applications that could use trees? Multi-level associative
: arrays?

How about "NULL" or "undef" value? I find this thing very handy in Perl,
and it is certainly much easier to implement than complex data types.

Multi-level associative arrays are very handy too, but they seems a bit
too dangerous - they are too much like pointers.
: --

: Al Biggerstaff
: Scriptics Corporation
--
--------------------------------------------------------
Victor Wagner @ home = vi...@wagner.rinet.ru
I don't answer questions by private E-Mail from this address.

Steve Ball

unread,
Jul 5, 1999, 3:00:00 AM7/5/99
to
Al Biggerstaff wrote:
>
> We at Scriptics are considering augmenting the core with additional data
> structures, and
> are curious as to what the demand is, and how they might be used.

I was going to prototype a Tree data structure for use in an
implementation of
the Document Object Model (DOM) - the W3C standard for manipulating XML
or HTML
documents. A standard Tcl tree type which could then be fed into a hierarchy
widget, such as that in BLT, would be ideal.

There has been some discussion of this on the TclXML mailing list -
interest is high.

Cheers,
Steve Ball

--
Steve Ball | Swish XML Editor | Training & Seminars
Zveno Pty Ltd | Web Tcl Complete | XML XSL
http://www.zveno.com/ | TclXML TclDOM | Tcl, Web Development
Steve...@zveno.com +-----------------------+---------------------
Ph. +61 2 6242 4099 | Mobile (0413) 594 462 | Fax +61 2 6242 4099

Paul Duffin

unread,
Jul 5, 1999, 3:00:00 AM7/5/99
to
Steve Ball wrote:
>
> Al Biggerstaff wrote:
> >
> > We at Scriptics are considering augmenting the core with additional data
> > structures, and
> > are curious as to what the demand is, and how they might be used.
>
> I was going to prototype a Tree data structure for use in an
> implementation of
> the Document Object Model (DOM) - the W3C standard for manipulating XML
> or HTML
> documents. A standard Tcl tree type which could then be fed into a hierarchy
> widget, such as that in BLT, would be ideal.
>

Obviously if this is to happen the widget must understand the basic tree
type plus have some means of controlling how the various properties
associated with each node are made visible.

> There has been some discussion of this on the TclXML mailing list -
> interest is high.
>

--

Steve Ball

unread,
Jul 6, 1999, 3:00:00 AM7/6/99
to
Paul Duffin wrote:

>
> Steve Ball wrote:
> >
> > I was going to prototype a Tree data structure for use in an
> > implementation of
> > the Document Object Model (DOM) - the W3C standard for manipulating XML
> > or HTML
> > documents. A standard Tcl tree type which could then be fed into a hierarchy
> > widget, such as that in BLT, would be ideal.
> >
>
> Obviously if this is to happen the widget must understand the basic tree
> type plus have some means of controlling how the various properties
> associated with each node are made visible.

I was thinking that there might be a callback associated with displaying
a node,
or some conventions to make it easier/faster.

Cheers,
Steve

Scott Redman

unread,
Jul 6, 1999, 3:00:00 AM7/6/99
to
Another thought:

If each node stored "viewer-specific client data" and a list of callbacks
or "watchers", the tree widget should have enough to work properly.
The viewer of the data needs to annotate the tree (without messing up
other views) in order to keep the viewing as efficient as possible.

-- Scott

Bob Techentin

unread,
Jul 6, 1999, 3:00:00 AM7/6/99
to
Scott Redman wrote:
>
> Another thought:
>
> If each node stored "viewer-specific client data" and a list of callbacks
> or "watchers", the tree widget should have enough to work properly.
> The viewer of the data needs to annotate the tree (without messing up
> other views) in order to keep the viewing as efficient as possible.

Beware of mixing widget view information into a tree data structure. It
would make the data structure much less generally useful. You might
take a look at the 'observer' pattern documented by Gamma et. al. in
"Design Patterns."

Bob

--
Bob Techentin techenti...@mayo.edu
Mayo Foundation (507) 284-2702
Rochester MN, 55905 USA http://www.mayo.edu/sppdg/sppdg_home_page.html

Reply all
Reply to author
Forward
0 new messages