Anyone keeping TCL 8.0 wishlist? Please add "random"...
d...@aisb.org
According to the web page at sunlabs, the feature set for TCL 8.0 isn't
frozen yet. Is anyone keeping a wishlist of features for TCL 8.0 for
the dev team? If so, could they add this as a feature request?
The number one simple, little feature I'd like to see in core TCL is a
"random" function (like the one in tclX).
I'd like it to be in the core set because that's the only way I can
see to ensure that apps are portable across all TCL platforms
(Unix/Windows/Mac and potential others). There are two main reasons I
want it. The first is of course games, but that's frivolous.
The second is for software testing -- I want to be able to generate
large amounts of random data for new TCL procs I'm implementing, and I
want to distribute scripts to do regression testing with any packages
I distribute.
I could use an extension like tclX, but then my code won't run
everywhere TCL runs. I could code up a random number generator *in*
TCL, but then its performance would be pretty bad -- plus, a basic
random number generator is part of the ANSI C spec, so I'd feel silly
reimplementing it.
--
Doug DeJulio
d...@aisb.org
Jeffrey Hobbs
In article <5iefhm$b...@bronze.lcs.mit.edu>, <d...@aisb.org> wrote:
>everywhere TCL runs. I could code up a random number generator *in*
>TCL, but then its performance would be pretty bad -- plus, a basic
>random number generator is part of the ANSI C spec, so I'd feel silly
I agree that since it is part of ANSI C, it should be available, but
it is so simple to implement in Tcl:
set _ran [pid]
proc random {range} {
global _ran
set _ran [expr ($_ran * 9301 + 49297) % 233280]
return [expr int($range * ($_ran / double(233280)))]
}
proc random {args} {
global RNG_seed
set max 259200
set argcnt [llength $args]
if { $argcnt < 1 || $argcnt > 2 } {
error "wrong # args: random limit | seed ?seedval?"
}
if [string match [lindex $args 0] seed] {
if { $argcnt == 2 } {
set RNG_seed [lindex $args 1]
} else {
set RNG_seed [expr ([pid]+[clock seconds])%$max]
}
return
}
if ![info exists RNG_seed] {
set RNG_seed [expr ([pid]+[clock seconds])%$max]
}
set RNG_seed [expr ($RNG_seed*7141+54773)%$max]
return [expr int([lindex $args 0]*($RNG_seed/double($max)))]
}
The first is quick and dirty, the second it TclX compatible. Even in
software testing, this is fast enough.
--
Jeffrey Hobbs jho...@cs.uoregon.edu,@or.cadix.com
Software Engineer, Oregon R&D office: 541.683.7891
CADIX International, Inc. fax: 541.683.8325
URL: http://www.cs.uoregon.edu/~jhobbs/
Bernd Hentig
>frozen yet. Is anyone keeping a wishlist of features for TCL 8.0 for
>the dev team? If so, could they add this as a feature request?
I really missed a discussion about tcl 8.0 features for a long time ;)
Now that it's open, I would (again) suggest to add the bgexec
behaviour (from BLT) either as a separate command or as an extension to
the core exec command. The key feature missing from exec(tcl) is the
ability to write stdout/stderr/rc to a tcl variable during/after execution.
I know there must be many people who are using the bgexec extension
and having a hard time due to the desolate condition of the BLT package,
so please post here to support this request.
Bernd
--
+-----------------------------------------------------------+
|Bernd Hentig |email: Bernd....@guug.de|
|Parkstr. 10 |Fon: +49 3335 3233 0 |
|D-16244 Finowfurt (Germany) |FAX: +49 3335 3233 1 |
MOSES R DE_JONG
Bernd Hentig wrote:
>
> In article <5iefhm$b...@bronze.lcs.mit.edu>, <d...@aisb.org> wrote:
> >According to the web page at sunlabs, the feature set for TCL 8.0 isn't
> >frozen yet. Is anyone keeping a wishlist of features for TCL 8.0 for
> >the dev team? If so, could they add this as a feature request?
Another feature that would be cool is a color command that worked like
the font command in tcl8. We could then create a named color and update
the color in more than one widget by changing the named color.
ex:
color create my_col -color blue1
then use this as the color argument to a bunch of widgets
then we could configure the color and it would update in the widgets
color configure my_col -color blue2
mo
Charlie Kempson
Bernd Hentig wrote:
>
> I really missed a discussion about tcl 8.0 features for a long time ;)
> Now that it's open, I would (again) suggest to add the bgexec
> behaviour (from BLT) either as a separate command or as an extension to
> the core exec command. The key feature missing from exec(tcl) is the
> ability to write stdout/stderr/rc to a tcl variable during/after execution.
>
> I know there must be many people who are using the bgexec extension
> and having a hard time due to the desolate condition of the BLT package,
> so please post here to support this request.
I would definitely add my support to this motion. Bgexec is *the* key
reason for the use of BLT in our current situation.
On the subject of wish lists for Tcl8.0, Iwould like to suggest that
it's high time Tk contained support for coloured items in listboxes
a la Motif 2.0, Tix and Windows. Surely this should be in the core?
Regards,
Charlie
--
------------------------------------------------------------
Charlie Kempson kemp...@logica.com
Logica UK Ltd. +49-6155-871-434
lvi...@cas.org
According to Bernd Hentig <be...@finow.snafu.de>:
:In article <5iefhm$b...@bronze.lcs.mit.edu>, <d...@aisb.org> wrote:
:>According to the web page at sunlabs, the feature set for TCL 8.0 isn't
:>frozen yet. Is anyone keeping a wishlist of features for TCL 8.0 for
:>the dev team? If so, could they add this as a feature request?
:
:I really missed a discussion about tcl 8.0 features for a long time ;)
:Now that it's open, I would (again) suggest to add the bgexec
Actually, there hasn't been a call for open season on tcl 8.0 wishes. Checking
the web page for tcl 8.0 will show you what features are going to be there.
I suspect the mention of the feature set not being 'frozen' may be a polite
way of saying 'we may not get to all of the following, so don't be
suprised if something here doesn't show up in the formal release'...
--
Larry W. Virden INET: lvi...@cas.org
<URL:http://www.teraform.com/%7Elvirden/> <*> O- "We are all Kosh."
Unless explicitly stated to the contrary, nothing in this posting should
be construed as representing my employer's opinions.
Frederic BONNET
Hi all,
I'd personally like Postscript output for text widgets, or at least an
extension to the existing canvas text item to support
multi-font/style/color text. Tk's text widget is great but is pretty
useless if we can't print its content.
See you, Fred
--
Frederic BONNET fbo...@irisa.fr
Ingenieur Ecole des Mines de Nantes/Ecole des Mines de Nantes Engineer
IRISA Rennes, France - Projet Solidor/Solidor Project
------------------------------------------------------------------------
Tcl: can't leave | "Il ne faut jamais remettre au lendemain ce
$env(HOME) without it! | qu'on peut faire le surlendemain" (Oscar WILDE)
Frederic BONNET
Hi all,
MOSES R DE_JONG wrote:
> Another feature that would be cool is a color command that worked like
> the font command in tcl8. We could then create a named color and update
> the color in more than one widget by changing the named color.
I second this one. It would allow for easy color scheme changes. But
maybe it would clash with rgb.txt???
Don Libes
In article <5il6fq$o...@srv13s4.cas.org> lvi...@cas.org writes:
According to Bernd Hentig <be...@finow.snafu.de>:
:In article <5iefhm$b...@bronze.lcs.mit.edu>, <d...@aisb.org> wrote:
:>According to the web page at sunlabs, the feature set for TCL 8.0 isn't
:>frozen yet. Is anyone keeping a wishlist of features for TCL 8.0 for
:>the dev team? If so, could they add this as a feature request?
:
:I really missed a discussion about tcl 8.0 features for a long time ;)
:Now that it's open, I would (again) suggest to add the bgexec
Actually, there hasn't been a call for open season on tcl 8.0 wishes. Checking
the web page for tcl 8.0 will show you what features are going to be there.
I suspect the mention of the feature set not being 'frozen' may be a polite
way of saying 'we may not get to all of the following, so don't be
suprised if something here doesn't show up in the formal release'...
Actually, there has been a session at every Tcl conference in which
John presents his ideas for Tcl's future and the audience discusses,
votes on, and prioritizes them and suggests replacements. Last year
we definitely did discuss 8.0 (and later versions) in exactly this
way. If you want to participate in this, I strongly encourage you to
attend the upcoming conference. (See http://www.usenix.org for more
info.)
Not attending doesn't mean you have no voice, but similar discussions
over c.l.t are a lot more chaotic by comparison. The conference
sessions are extremely focused and productive.
Don
Jeffrey Hobbs
In article <s6a912p...@muffin.nist.gov>, Don Libes <li...@nist.gov> wrote:
>Actually, there has been a session at every Tcl conference in which
>John presents his ideas for Tcl's future and the audience discusses,
>votes on, and prioritizes them and suggests replacements. Last year
>we definitely did discuss 8.0 (and later versions) in exactly this way.
Of course, everything has to be run through the OusterVote filter (where
was that posted again?). Some comunity high interest ideas (or solutions)
don't always get high on the list.
The important thing about 8.0 is that it is the first major revision in
years. This is the logical time for adding core features. Some big ones
like namespaces have been acknowledged, but we haven't heard much else.
I would hate to see Tk8 final come out with native LAF being the only
feature addition. That would just be dumb.
Mark A Harrison
Jeffrey Hobbs (jho...@cs.uoregon.edu) wrote:
: In article <5iefhm$b...@bronze.lcs.mit.edu>, <d...@aisb.org> wrote:
: >everywhere TCL runs. I could code up a random number generator *in*
: >TCL, but then its performance would be pretty bad -- plus, a basic
: >random number generator is part of the ANSI C spec, so I'd feel silly
: I agree that since it is part of ANSI C, it should be available, but
: it is so simple to implement in Tcl:
This is nice... can it be incorporated into the next release? I
just *hate* having to cut and paste the same bit of random
number code into every application, and the #2 or #3 frequently
asked question I receive at work is "how do I do random numbers"
followed by "[perl/C/C++/Awk/Java/FORTRAN/whatever] has it, why
doesn't Tcl?"
Mark.
Bryan Oakley
Jeffrey Hobbs wrote:
>
> In article <s6a912p...@muffin.nist.gov>, Don Libes <li...@nist.gov> wrote:
> >Actually, there has been a session at every Tcl conference in which
> >John presents his ideas for Tcl's future and the audience discusses,
> >votes on, and prioritizes them and suggests replacements. Last year
> >we definitely did discuss 8.0 (and later versions) in exactly this way.
>
> Of course, everything has to be run through the OusterVote filter (where
> was that posted again?). Some comunity high interest ideas (or solutions)
> don't always get high on the list.
>
> The important thing about 8.0 is that it is the first major revision in
> years. This is the logical time for adding core features. Some big ones
> like namespaces have been acknowledged, but we haven't heard much else.
> I would hate to see Tk8 final come out with native LAF being the only
> feature addition. That would just be dumb.
Uh, Jeffrey, don't forget the byte compiler. That in and of itself is
worthy of a major new release. Combined with native look and feel and
namespaces, that's more than enough to make me happy.
--
Bryan Oakley mailto:oak...@healthcare.com
Software Engineer http://www1.clearlight.com/~oakley/
Healthcare Communications, Inc. http://www.healthcare.com/
lvi...@cas.org
According to Frederic BONNET <fbo...@irisa.fr>:
:
:Hi all,
:
:MOSES R DE_JONG wrote:
:> Another feature that would be cool is a color command that worked like
:> the font command in tcl8. We could then create a named color and update
:> the color in more than one widget by changing the named color.
:
:I second this one. It would allow for easy color scheme changes. But
:maybe it would clash with rgb.txt???
I vote that someone write one of these as a dynamically loaded extension,
let folk play with it until it works the way everyone wants, then
that the author consider donating it to Sun for incorporation.
Otherwise, the idea would just go onto the bottom of their _very_ long
wish list and might never get implemented.
As for requests for things like random numbers, etc. If these things
can be written without tampering with the core of Tcl, then why not just
make them loadable procs or extensions so that the core doesn't keep
growing with every little function that someone wants. Instead, folk
could just pop over and get what they need.
Perhaps someone could even look into writing an extension which
would go out to a common site, fetch the appropriate files for
building the extensions, and assist the user in building and installing
the code.
d...@aisb.org
In article <5ipvru$m...@srv13s4.cas.org>, <lvi...@cas.org> wrote:
>As for requests for things like random numbers, etc. If these things
>can be written without tampering with the core of Tcl, then why not just
>make them loadable procs or extensions so that the core doesn't keep
>growing with every little function that someone wants. Instead, folk
>could just pop over and get what they need.
Well, let's say I want to write GUI apps that run on Mac, Windows and
Unix. Let's further say that I only have a C compiler on Unix. I
can't really use extensions on the Mac or Windows boxes -- there goes
my portablility.
Random numbers are *so* fundamental to many different things (eg.
cryptography), and the presence of random number functions in ANSI C
makes this *so* easy to add, that IMHO random number generating should
be in the core of TCL.
--
Doug DeJulio
d...@aisb.org
Jeffrey Hobbs
In article <335049DA...@healthcare.com>,
Bryan Oakley <oak...@healthcare.com> wrote:
>Jeffrey Hobbs wrote:
>> I would hate to see Tk8 final come out with native LAF being the only
>> feature addition. That would just be dumb.
>Uh, Jeffrey, don't forget the byte compiler. That in and of itself is
>worthy of a major new release. Combined with native look and feel and
>namespaces, that's more than enough to make me happy.
Note, I specifically said "Tk" (which actually doesn't take advantage of the
byte compiler internally), but I was not mentioning Tcl because numerous
good additions are going into it (namespaces, binary/io - which I hope is
truly incorporated instead of another command, serial/io and more). Tk also
gets a new menu system (mainly to get things working right on Macs), LAF and
the font command.
However, there are a few things that absolutely should not be missed,
primarily because they require core patches. Megawidget support. The bug
with grab in multiple interpreters. True events in Tcl and a truly loadable
Tk (many of the things in Nijtmans well-proven patches). These are the
things that you need to consider for a major release update.
Things like random need to be considered in a different light. Yes, they
can be loaded in dynamically, but so could much of the stuff that is being
added in (like serial/io and binariy/io). rand() would have been much
easier to plug in, especially since TclX already has a (cross-platform?)
working version (they stole clock et al from TclX). Of course, if Sun had
a couple of projects that used it, you might see it... Anyway, you have to
weigh the following factors: %age of community that requires it, difficulty
of programming it, whether it can be loadaed purely dynamically, amount of
bloat it would add, and probably a few others.
Jeffrey Hobbs
In article <5irfj5$a...@bronze.lcs.mit.edu>, <d...@aisb.org> wrote:
>In article <5ipvru$m...@srv13s4.cas.org>, <lvi...@cas.org> wrote:
>>As for requests for things like random numbers, etc. If these things
>>can be written without tampering with the core of Tcl, then why not just
>Well, let's say I want to write GUI apps that run on Mac, Windows and
>Unix. Let's further say that I only have a C compiler on Unix. I
For random, you can write it in pure Tcl, so no problem...
>Random numbers are *so* fundamental to many different things (eg.
>cryptography), and the presence of random number functions in ANSI C
But this is true, so...
Jeffrey Hobbs
In article <5irs3g$9...@rigel.anu.edu.au>,
Steve Ball <st...@surfit.anu.edu.au> wrote:
> package require http://foo.bar/myPackage
Cool idea! Of course, some way to specify a local alternative would be good
for those who grab an extension and cache it because they don't always run
connected to the net. You don't want to require that the user change the
package require line.
>and now for something completely different...
I'd like the spam, spam, spam, spam, eggs, and spam without the spam please.
>several major changes to the core is a good reason NOT to add more features.
>The more features you add, the longer and more complicated it is to test and
>debug them. I'm fairly happy with the changes they are making for this
>release - give them a chance to get them right! Save the random numbers,
>etc., for release 8.1.
That is a very good argument to limit creeping featurism, but not for
everything. Some of the features are either orthogonal or more appropriate
for the major relase rather than a minor release.
Bryan Oakley
Jeffrey Hobbs wrote:
>
> In article <335049DA...@healthcare.com>,
> Bryan Oakley <oak...@healthcare.com> wrote:
> >Jeffrey Hobbs wrote:
> >> I would hate to see Tk8 final come out with native LAF being the only
> >> feature addition. That would just be dumb.
>
> >Uh, Jeffrey, don't forget the byte compiler. That in and of itself is
> >worthy of a major new release. Combined with native look and feel and
> >namespaces, that's more than enough to make me happy.
>
> Note, I specifically said "Tk" (which actually doesn't take advantage of the
> byte compiler internally), but I was not mentioning Tcl because numerous
> good additions are going into it (namespaces, binary/io - which I hope is
> truly incorporated instead of another command, serial/io and more). Tk also
> gets a new menu system (mainly to get things working right on Macs), LAF and
> the font command.
You're right. I didn't notice that you were speaking only of Tk. I
suspect that tk 8.0 isn't a "major release" except in name. I don't
think there is really much of anything planned for Tk. The 8.0
nomenclature is just to get it in sync with tcl. tk 8.0 is probably best
seen as tk 4.3.
> However, there are a few things that absolutely should not be missed,
> primarily because they require core patches. Megawidget support.
Amen.
> The bug with grab in multiple interpreters.
Hallelujah!
> True events in Tcl and a truly loadable
> Tk (many of the things in Nijtmans well-proven patches). These are the
> things that you need to consider for a major release update.
Yeah, kinda hard to figure why a good portion of the plus patches is not
in the core.
Steve Ball
In article m...@srv13s4.cas.org, lvi...@cas.org writes:
>As for requests for things like random numbers, etc. If these things
>can be written without tampering with the core of Tcl, then why not just
>make them loadable procs or extensions so that the core doesn't keep
>growing with every little function that someone wants. Instead, folk
>could just pop over and get what they need.
>
>Perhaps someone could even look into writing an extension which
>would go out to a common site, fetch the appropriate files for
>building the extensions, and assist the user in building and installing
>the code.
My idea is to extend the "package" command to accept a URL for the package name,
eg.
package require http://foo.bar/myPackage
The package subsystem could cache packages locally. This facility would be
especially nifty for Tclets. Extensions to the interpreter should be written in
Java for cross-platform use (the only proper use for Java ;-)
Tcl 8.0 already has the HTP library, so it's not a great leap to achieve the
above.
---
and now for something completely different...
As far as adding more features to Tcl or Tk go, the fact that the Tcl team are making
several major changes to the core is a good reason NOT to add more features.
The more features you add, the longer and more complicated it is to test and debug
them. I'm fairly happy with the changes they are making for this release - give them
a chance to get them right! Save the random numbers, etc., for release 8.1.
Steve
--
Steve Ball, Computer Science Dept., ANU Steve...@surfit.anu.edu.au
Ph. +61 6 2495146 http://surfit.anu.edu.au/steve/
Snail-mail: Canberra ACT 0200, AUSTRALIA
He's not the messiah, he's a very naughty boy!
Andreas Kupries
In article <5irs3g$9...@rigel.anu.edu.au> st...@surfit.anu.edu.au (Steve Ball) writes:
> and now for something completely different...
>
> As far as adding more features to Tcl or Tk go, the fact that the Tcl team are making
> several major changes to the core is a good reason NOT to add more features.
> The more features you add, the longer and more complicated it is to test and debug
> them. I'm fairly happy with the changes they are making for this release - give them
> a chance to get them right! Save the random numbers, etc., for release 8.1.
See ftp://ftp/neosoft.com/pub/tcl/sorted/math/random/
--
Sincerely,
Andreas Kupries <a.ku...@westend.com>
-------------------------------------------------------------------------------
Kongress-Strasse 23/15, 52070 Aachen, Germany
pgp-key: via keyserver
finger print: 3E C8 C9 6B 2A EC 05 B1 EE 49 15 0B 62 DC 23 06
-------------------------------------------------------------------------------
Jeffrey Hobbs
In article <5iud3l$r...@srv13s4.cas.org>, <lvi...@cas.org> wrote:
>:Random numbers are *so* fundamental to many different things (eg.
>:cryptography), and the presence of random number functions in ANSI C
>:be in the core of TCL.
>This argument could be made for so _many_ things that we would never
>come to an end. Tcl already has too _much_ stuff in the core. IMO,
>almost everything in Tcl right now should be in loadable extensions -
This is a good point. It ouwld be nice if Tcl were broken into a small core
and numerous DLLs. It would ease the upgrading of components though. If
this were the case, then things like random should be included in the "core",
where the "core" is a distribution of numerous staple DLLs.
That would fundamentally affect the functionality of Tcl. You would see it
start moving towards Perl5, for better or worse. The overall effect would
have interesting implications that would be worth discussing at the
workshop. Anyway, this would require a complete reengineering of the Tcl
framework and distribution, so put it in the pipe dream category for now.
lvi...@cas.org
According to <d...@aisb.org>:
:In article <5ipvru$m...@srv13s4.cas.org>, <lvi...@cas.org> wrote:
:>As for requests for things like random numbers, etc. If these things
:>can be written without tampering with the core of Tcl, then why not just
:>make them loadable procs or extensions so that the core doesn't keep
:>growing with every little function that someone wants. Instead, folk
:>could just pop over and get what they need.
:
:Well, let's say I want to write GUI apps that run on Mac, Windows and
:Unix. Let's further say that I only have a C compiler on Unix. I
:can't really use extensions on the Mac or Windows boxes -- there goes
:my portablility.
But in this case, the code was written in Tcl, so there's no problem.
Or, if the code _is_ in C, you find one of the kind folk on the MacTcl
or Windows Tcl mailing lists that are willing to build an executable
version for others.
:Random numbers are *so* fundamental to many different things (eg.
:cryptography), and the presence of random number functions in ANSI C
:makes this *so* easy to add, that IMHO random number generating should
:be in the core of TCL.
This argument could be made for so _many_ things that we would never
come to an end. Tcl already has too _much_ stuff in the core. IMO,
almost everything in Tcl right now should be in loadable extensions -
except for the ability to create a safe interpreter and safely dynamically
load other extensions and perhaps a bare few other things. Once the
core gets back down to 50-80k and _fast_ we can get back to embedding
Tcl into other programs. Right now adding a 500-1000k footprint,
even dynamically loaded, is rather significant to folk who want to
put tcl on PDAs, etc.
Jeffrey Hobbs
In article <5j0c4j$4...@engnews2.Eng.Sun.COM>,
Raymond Johnson <rjoh...@Sun.COM> wrote:
>: Yeah, kinda hard to figure why a good portion of the plus patches is not
>: in the core.
>Because they do not work on the Macintosh or Windows platforms and would
True for Mac, but not entirely for Windows. I agree that reliable
cross-platform compatibility is a requirement, but some of the features in
the plus/dash patches rely only on Tcl/Tk or ANSI C. But then again, since
when has that stopped progress before. "send" anyone, not to mention
numerous nit-picky things that aren't reliable on the Mac and/or Windows.
Even the most basic things like proper Postscript support, proper image
transparency (and writing) and the canvas speedups would be welcome and
must be fully cross-platform (although I haven't personally verified that).
Raymond Johnson
Bryan Oakley (oak...@healthcare.com) wrote:
: > True events in Tcl and a truly loadable
: > Tk (many of the things in Nijtmans well-proven patches). These are the
: > things that you need to consider for a major release update.
: Yeah, kinda hard to figure why a good portion of the plus patches is not
: in the core.
Because they do not work on the Macintosh or Windows platforms and would
be rather non-trivial to get working. We would otherwise consider the
patchs - but we must make sure that new code runs on all three platforms.
Nijtmans does not have that constraint - which is certainly a benifit to
X windows users...
Ray
Bryan Oakley
Oh. Good answer :-)
Jonathan Cook
lvi...@cas.org wrote:
: This argument could be made for so _many_ things that we would never
: come to an end. Tcl already has too _much_ stuff in the core.
[...]
: load other extensions and perhaps a bare few other things. Once the
: core gets back down to 50-80k and _fast_ we can get back to embedding
: Tcl into other programs.
Definitely.
: even dynamically loaded, is rather significant to folk who want to
: put tcl on PDAs, etc.
Who's that? I want to work for them! That'd be great! Back in the 80's
I bought a Sharp calculator that had BASIC in it. I'm not going to buy
a PDA until I can *program* it.
JonCook.
Raymond Johnson
Jonathan Cook (jc...@cs.nmsu.edu) wrote:
: Who's that? I want to work for them! That'd be great! Back in the 80's
: I bought a Sharp calculator that had BASIC in it. I'm not going to buy
: a PDA until I can *program* it.
You can program the Newton...
Ray
Sergei Naumov
Once at a time Jeffrey Hobbs <jho...@cs.uoregon.edu> wrote:
> However, there are a few things that absolutely should not be missed,
> primarily because they require core patches. Megawidget support. The bug
> with grab in multiple interpreters. True events in Tcl and a truly loadable
> Tk (many of the things in Nijtmans well-proven patches). These are the
> things that you need to consider for a major release update.
It would also be great to add a long waited smooth scrolling in the
text-like widgets. This should be implemented inside a widget itself.
--
++++++++++++ http://sunsite.oit.unc.edu/sergei/Me/Serge.html ++++++++++
+ Sergei O. Naumov se...@astro.unc.edu tel: (919)962-3998 +
+Department of Physics & Astronomy, UNC-CH, Chapel Hill, NC 27599, USA+
++++++++++++++++++ !! 8 bit (Cyrillic) mail accepted !!++++++++++++++++
Ted E. Dunning
jho...@cs.uoregon.edu (Jeffrey Hobbs) writes:
> Things like random need to be considered in a different light. Yes, they
> can be loaded in dynamically, but so could much of the stuff that is being
> added in (like serial/io and binariy/io). rand() would have been much
> easier to plug in, especially since TclX already has a (cross-platform?)
i have a random package myself which i consider superior to the tclx
version. the major reason i like mine better is that it doesn't just
generate random numbers from a single distribution. instead, it can
also generate permutations, selections and can also sample from a
variety of distributions.
i don't know if i have submitted this package anywhere, but i will if
there are requests for it.
Bryan Oakley
Not only that, but you can actually program it in (*gasp*) BASIC!
--
Bryan "Love my (Newton) Messagepad 2000!" Oakley
Bryan Oakley
Jonathan Cook wrote:
>
> lvi...@cas.org wrote:
>
> : This argument could be made for so _many_ things that we would never
> : come to an end. Tcl already has too _much_ stuff in the core.
> [...]
> : load other extensions and perhaps a bare few other things. Once the
> : core gets back down to 50-80k and _fast_ we can get back to embedding
> : Tcl into other programs.
>
> Definitely.
>
> : even dynamically loaded, is rather significant to folk who want to
> : put tcl on PDAs, etc.
>
> I bought a Sharp calculator that had BASIC in it. I'm not going to buy
> a PDA until I can *program* it.
Then it's time to buy an Apple Messagepad (newton). You can program in
NewtonScript right on the machine; there is even a visual programming
environment that runs on it (no desktop required).
Sadly, no Tcl, but I keep hoping :-)
--
Bryan "Happy Newton Owner" Oakley mailto:oak...@healthcare.com
Jeffrey Hobbs
In article <kqlo6ijz...@newco2.aptex.com>,
Ted E. Dunning <t...@aptex.com> wrote:
>i have a random package myself which i consider superior to the tclx
>also generate permutations, selections and can also sample from a
>variety of distributions.
When people build packages like this, it is best to notify the
appropriate FAQ maintainer (in this case Tcl - lvi...@cas.org)
so that othhers can find it.
Nir Levy
Bryan Oakley <oak...@healthcare.com> saw fit to bestow on us:
>Jeffrey Hobbs wrote:
>>
>> In article <335049DA...@healthcare.com>,
>> Bryan Oakley <oak...@healthcare.com> wrote:
>> >Jeffrey Hobbs wrote:
>> >> I would hate to see Tk8 final come out with native LAF being the only
>> >> feature addition. That would just be dumb.
>>
>> >Uh, Jeffrey, don't forget the byte compiler. That in and of itself is
>> >worthy of a major new release. Combined with native look and feel and
>> >namespaces, that's more than enough to make me happy.
>>
>> Note, I specifically said "Tk" (which actually doesn't take advantage of the
>> byte compiler internally), but I was not mentioning Tcl because numerous
>> good additions are going into it (namespaces, binary/io - which I hope is
>> truly incorporated instead of another command, serial/io and more). Tk also
>> gets a new menu system (mainly to get things working right on Macs), LAF and
>> the font command.
>
>You're right. I didn't notice that you were speaking only of Tk. I
>suspect that tk 8.0 isn't a "major release" except in name. I don't
>think there is really much of anything planned for Tk. The 8.0
>nomenclature is just to get it in sync with tcl. tk 8.0 is probably best
>seen as tk 4.3.
>[...]
What??? Are you nutts?? The Native L&F is the best thing ever
happend to tk. If you're using x/Motif then admit the change does
not look like a major version. But if you're using windows....
I can finnaly create what seems to be Native apps. This defently
counts as a major release IMHO.
Talking about "wish list" - I would REALY like to have a
"Drop-Down-List" or a "Cumbo-Box" integrated to the tk
library - I know, I know, it can be done rather easily at home,
but having this as part of the official package will make
things more consistant in the future ...
/NL
---------------------------------
The above opinions are my own,
not my employer's. NL
---------------------------------
Jan Nijtmans
Jeffrey Hobbs wrote:
> True for Mac, but not entirely for Windows. I agree that reliable
> cross-platform compatibility is a requirement, but some of the features in
> the plus/dash patches rely only on Tcl/Tk or ANSI C. But then again, since
> when has that stopped progress before. "send" anyone, not to mention
> numerous nit-picky things that aren't reliable on the Mac and/or Windows.
>
> Even the most basic things like proper Postscript support, proper image
> transparency (and writing) and the canvas speedups would be welcome and
> must be fully cross-platform (although I haven't personally verified that).
Proper postscript support depends on the functions XGetImage() and
XQueryColor(). Only after these functions are implemented on
Mac/Windows,
the postscript additions of the dash-patch will work for these
ports as well. Dashing depends on XSetDashes() and currently works for
Windows but not yet for the Mac. Other things (transparency, canvas
speedups, "-state" option, line/poly enhancements) are platform
independant.
Currently the plus- and dash-patches compile and run fine on Windows and
Mac,
only not all enhancements are functional yet. tclsh.exe still has the
same
console and still doesn't react properly when Tk is loaded dynamically.
But when scripts are executed without using the console, the event
fixes just work fine!!!!! The Console is just the only problem left.....
Jan Nijtmans
NICI (Nijmegen Institute of Cognition and Information)
email: nijt...@nici.kun.nl
url: http://www.cogsci.kun.nl/~nijtmans/
lvi...@cas.org
According to Jan Nijtmans <nijt...@nici.kun.nl>:
:Currently the plus- and dash-patches compile and run fine on Windows and
:Mac,
:only not all enhancements are functional yet. tclsh.exe still has the
:same
:console and still doesn't react properly when Tk is loaded dynamically.
:But when scripts are executed without using the console, the event
:fixes just work fine!!!!! The Console is just the only problem left.....
I sure wish this could be communicated to Sun. Just recently I seem to recall
seeing someone respond that the reason that the plus and
dash enhancements were not being rolled into the core was because they
were not portable to the Mac and Windows environment.
Jan Nijtmans
lvi...@cas.org wrote:
> Actually, it's my understanding, talking to the author, that the plus
> patches have all been upgraded now to work on both the Mac and Windows
> platforms.
>
> Perhaps the subject could be broached again. Perhaps enhancing
> the code, particularly if the changes now work across all platforms,
> couldn't make things significantly less trans-portable.
An important part of the plus-patches is an enhancement of Tcl's
notifier. Unfortunately Scott Statton just completely restuctured
the notifier (which will appear in Tcl8.0b1) without having a look
at the plus-patch enhancements. This means that this part of the
pluspatch will surely need to be re-written for Tcl8.0b1 :-(
Whether the new notifier will be compatible with the plus-patch
enhancements or not is highly the question. I can only know that
for sure after the release of Tcl8.0b1.
lvi...@cas.org
According to Jeffrey Hobbs <jho...@cs.uoregon.edu>:
:In article <5j0c4j$4...@engnews2.Eng.Sun.COM>,
:Raymond Johnson <rjoh...@Sun.COM> wrote:
:>: Yeah, kinda hard to figure why a good portion of the plus patches is not
:>: in the core.
:
:>Because they do not work on the Macintosh or Windows platforms and would
:
:True for Mac, but not entirely for Windows. I agree that reliable
Actually, it's my understanding, talking to the author, that the plus
patches have all been upgraded now to work on both the Mac and Windows
platforms.
Perhaps the subject could be broached again. Perhaps enhancing
the code, particularly if the changes now work across all platforms,
couldn't make things significantly less trans-portable.
--