Request for Input -- trees
Al Biggerstaff
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
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
> 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
>
> ...
>
> 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
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
> 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
>
> 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.
>
> 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
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
>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
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
>
> 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
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
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
<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
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
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
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).
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
> 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
>
> "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
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
>
> In article <3771E3...@cnet.francetelecom.fr>, Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> writes:
> >Al Biggerstaff wrote:
> >>
> >> 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
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
> 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
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
>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
.
.
Christopher Nelson
>
> modularizability
Look THAT up in your Funk and Wagnall's!
Jean-Claude Wippler
> 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
> In article <1999Jun2...@netman.eng.auburn.edu>,
> >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).
>
>
> 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
: "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
> 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
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
> 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
>
> <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
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
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.
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
>
> Christopher Nelson <ch...@pinebush.com> writes:
>
> > Cameron Laird wrote:
> > >
> > > modularizability
> >
> > Look THAT up in your Funk and Wagnall's!
>
>
> 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?