POLL: Tcl changes over last 1.5 years - and the future
Jeffrey Hobbs
wanted to have an informal poll from other Tcl developers on what you
think the biggest changes are to Tcl and the Tcl community over the
last 1.5 years (since the last conference - we were at 8.1 alpha).
In conjunction, I'd like to get a preliminary list on what people
would like to see for the future, both in the core and for the
community.
Please keep the lists short, keeping to the big topics. I'll try
and address as much of the input as I can during the Tcl Update talk
or at some time during the conference.
Thanks,
Jeffrey Hobbs Tcl Ambassador
jeffrey.hobbs at scriptics.com Scriptics Corp.
Stefaan A Eeckels
Jeffrey Hobbs <jeffre...@scriptics.com> writes:
> I'm preparing the Tcl Update talk for the Tcl2K conference, and just
> wanted to have an informal poll from other Tcl developers on what you
> think the biggest changes are to Tcl and the Tcl community over the
> last 1.5 years (since the last conference - we were at 8.1 alpha).
for use in the European Union, and good support for national
character sets is a major boon.
> In conjunction, I'd like to get a preliminary list on what people
> would like to see for the future, both in the core and for the
> community.
Having struggled with a VB program that needed to be deployed
on localized Windows NT/9x boxes, I'd really appreciate the
provision as part of the core, of a tool such as J Nijtmans'
wrap, to build stand-alone versions of an application:
- not influenced by localized OSes
- not influenced by other Tcl installations, if any
- not influenced by library differences
- easy to install.
VB proved to be an unmitigated disaster, as installing the
program meant:
- unexpectedly bi-lingual PCs, and irate customers.
- broken applications (either this program, Office, or other
VB programs), and irate customers
- installation programs that freak because they want to
open "standard" libraries for writing whilst checking
version numbers, and irate customers
- Program that doesn't run because later versions of
libraries are incompatible with the one packaged with
the program, and irate customers...
etc.
Thanks, and kudos for a job well done,
--
Stefaan
--
--PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)--
Ninety-Ninety Rule of Project Schedules:
The first ninety percent of the task takes ninety percent of
the time, and the last ten percent takes the other ninety percent.
Mark Patton
>
> I'm preparing the Tcl Update talk for the Tcl2K conference, and just
> wanted to have an informal poll from other Tcl developers on what you
> think the biggest changes are to Tcl and the Tcl community over the
> last 1.5 years (since the last conference - we were at 8.1 alpha).
>
> would like to see for the future, both in the core and for the
> community.
>
> and address as much of the input as I can during the Tcl Update talk
> or at some time during the conference.
>
> Thanks,
>
> Jeffrey Hobbs Tcl Ambassador
> jeffrey.hobbs at scriptics.com Scriptics Corp.
In the future:
- Tk fully objectified (already done in 8.3?).
- Make Tk easier to use as an extension ie. I just
have to use "package require Tk" to get it loaded (done in 8.3?).
- Cruft cleaned out of Tcl. For example, collect all the list commands
into one "list" command.
- More list commands. "list match" takes arguments like "lsearch"
and returns a list of elements in a list matching a pattern.
- More widgets in Tk. Tree and notebook widgets come to mind.
- Tcl commands for manipulating byte code. At the very least
you should be able to right bytecode to a file, such that it
can be loaded again.
- Tcl should be broken up into seperate modules (extensions) such
that the needed functionality can be loaded with "package require".
The major modules would be something like networking, threads,
TK, additional complex Tk widgets, etc.
- Better Tk performance in Windows.
- Cross-platform printing support.
I know that some of these can be done in pure Tcl and some available
as extensions, but core support would be nice.
Mark
Brian
Great list Mark! I sent my list directly to Jeff, but you hit most of my
points and more I hadn't thought of. I know Jeff and others are addressing
many of them already but feedback from the community helps prioritize.
Thanks!
"Mark Patton" <mpa...@jhu.edu> wrote in message
news:388E1C5D...@jhu.edu...
David Gravereaux
>what you
>think the biggest changes are to Tcl and the Tcl community over the
>last 1.5 years
Stubs!! It replaced monstrous amounts of obnoxious glue code I once wrote
(about a year ago) and worked better :)
A wonderful solution to load-time linking on Win32.
--
* David Gravereaux *
Tomahawk Software Group
"Things should be as simple as possible, but not simpler." -- Albert E.
Petasis George
>
> I'm preparing the Tcl Update talk for the Tcl2K conference, and just
> think the biggest changes are to Tcl and the Tcl community over the
Natural language processing and unicode for me is the most powerful feature
of tcl, except of course the ability to run on every OS I have tried...
>
> In conjunction, I'd like to get a preliminary list on what people
> would like to see for the future, both in the core and for the
> community.
is that you need much much time with tk to write a real GUI (that means both
nice looking, easy to use and to have all the things that the user is used
to
and expects to). Ok, I aggree that with all the basic widgets that tk has
you can do almost everything, but that takes *time*. What I want to see is
the addition of new (more complex) tk widgets (like menus with text+image,
butttons
with text+image, tree widget, notebook widget, multi column listbox that can
also display images, toolbar widget, statusbar, drag and drop, combobox
etc...)
George
af_...@my-deja.com
Jeffrey Hobbs <jeffre...@scriptics.com> wrote:
> I'm preparing the Tcl Update talk for the Tcl2K conference, and just
> wanted to have an informal poll from other Tcl developers on what you
> think the biggest changes are to Tcl and the Tcl community over the
> last 1.5 years (since the last conference - we were at 8.1 alpha).
>
> would like to see for the future, both in the core and for the
> community.
>
With all respect for excisting pakages...but good printing facilities
for windows OS would be very nice.
Alain
> Please keep the lists short, keeping to the big topics. I'll try
> and address as much of the input as I can during the Tcl Update talk
> or at some time during the conference.
>
> Thanks,
>
> Jeffrey Hobbs Tcl Ambassador
> jeffrey.hobbs at scriptics.com Scriptics Corp.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
Alexandre Ferrieux
>
> the biggest changes are to Tcl and the Tcl community over the
> last 1.5 years (since the last conference - we were at 8.1 alpha).
Core: Stubs, and fixed fileevents on 'doze.
Community: You, Jeff !
> preliminary list on what people
> would like to see for the future, both in the core and for the
> community.
Core: -Modularization (tiny kernel + package require)
-Interfaces (this includes a true registration of types,
rather than the silent storing of a new pointer to a TclObjType struct
in an object's type field. With registration, I could write my dreamed
ShimmerView tool as a loadable extension :^)
-A smaller and simpler (eg Forth) bytecode system
-JIT (native) compilation (may need the previous item)
Community: -Several other Jeffs at Scriptics !
-World access to the Holy Bug Database on dev.scriptics.com
(may need the previous item :^)
-Alex
Tinto
<pet...@iit.demokritos.gr> wrote:
>is that you need much much time with tk to write a real GUI (that means both
>nice looking, easy to use and to have all the things that the user is used
>to and expects to).
I agree and I think it is quite time-wasting to modify what I've done
if necessary.
But is possible that's because I haven't yet the ability to organize
my program in the correct way ;)
--
ciao da Alessandro (aka Tinto)
e-mail: tin...@bigfoot.com
SMS (100 chars): ti...@wappi.com
http://utenti.tripod.it/Tinto/
Volker Hetzer
>
> I'm preparing the Tcl Update talk for the Tcl2K conference, and just
> wanted to have an informal poll from other Tcl developers on what you
> last 1.5 years (since the last conference - we were at 8.1 alpha).
- Packages
- Packages as shared libraries
- namespaces
- The change in the internal list representation
As to important progress from 8.1 alpha, we still use 8.0.4 around here.
The next change will probably be to 8.3 because of the megawidgets.
> In conjunction, I'd like to get a preliminary list on what people
> would like to see for the future, both in the core and for the
> community.
- Make it easy for embedded developers to cut out I/O and file system
stuff. Even in the source tree.
Perhaps you could restructure tcl as a base interpreter with two
statically loaded packages (core and i/o). Then it would be easy
to leave out any of the two packages.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
Chang LI
Alexandre Ferrieux wrote in message <388EB0...@cnet.francetelecom.fr>...
>Core: -Modularization (tiny kernel + package require)
This is the most important task. It is possible to have file, network,
thread, ... packages.
Nat Pryce
Jeffrey Hobbs wrote:
> ...I'd like to get a preliminary list on what people
> would like to see for the future, both in the core and for the
> community.
In order of importance:
- Standard API packages, outside the core but distributed with it.
E.g. for networking (various protocols), databases, email,
XML and HTML parsing, image and sound processing etc. Something
like the standard APIs defined by and/or shipped with Java.
- A minimal, modularised Tcl for easier embedding into apps
- Better support for defining data structures and abstract
data types or objects. Preferably a prototype-based
object system.
--
+------------------------------------------+---------------------+
| 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 |
+------------------------------------------+---------------------+
William H. Duquette
wrote:
>
>
>Jeffrey Hobbs wrote:
>> ...I'd like to get a preliminary list on what people
>> would like to see for the future, both in the core and for the
>> community.
>
>In order of importance:
>
>- Standard API packages, outside the core but distributed with it.
> E.g. for networking (various protocols), databases, email,
> XML and HTML parsing, image and sound processing etc. Something
> like the standard APIs defined by and/or shipped with Java.
Yes. This is where Python and Perl are beating Tcl hands down
at the moment: the quantity of useful, interesting packages from
the community that are delivered with them. We need to make
this easier to do. For enterprise work, it doesn't matter
as much---you can pick and choose what extensions you want.
But for writing small, open source tools, the current situation
is a pain. "Hey, so-and-so, I've written this wonderful tool,
but you need to get this extension from over there, and this one
from over here, and oh, you need those patches as well...."
By the time the reader gets that far, they've already said
"Forget it."
>- A minimal, modularised Tcl for easier embedding into apps
Especially if this minimal, modularised Tcl had no necessary
dependence on external Tcl source libraries (e.g., init.tcl).
>- Better support for defining data structures and abstract
> data types or objects. Preferably a prototype-based
> object system.
Absolutely. This is an area where Python dominates Tcl by
several orders of magnitude, and where Tcl could really shine.
We need support for real record structures and objects in the
core. (I'm sick of explicitly mimicking records with arrays.
Yeah, it works; functional it is; pretty it ain't. Any solution
would probably do the same thing under the hood, and that's fine.)
Oh, and one last little thing that's been annoying me ever since
I started to use Tcl: can we get rid of the old, crufty csh-style
command line editing in tclsh and wish, and put in something
more like GNU readline? I spend a fair amount of time at the
tclsh prompt, and not being able to use the cursor keys is a major
pain. Yes, I know about tkCon and all of that; I still don't
think it's too much to ask to have it in the core interpreters
if the platform supports it.
Will Duquette
--------------------------------------------------------------------------
Will Duquette, JPL | William.H...@jpl.nasa.gov
But I speak only | http://eis.jpl.nasa.gov/~will (JPL Use Only)
for myself. | It's amazing what you can do with the right tools.
Bryan Oakley
news:388DFE91...@scriptics.com...
> In conjunction, I'd like to get a preliminary list on what people
> would like to see for the future, both in the core and for the
> community.
I think we need an easy way for the community to contribute to the core
distribution (though, not necessarily "the core"). Tcl needs more
functionality "out of the box". Things like a unix "find"-like package,
maybe an emulation of sed, a "foreach-file" package, etc. And there needs to
be an easy and straight-forward mechanism for those of us who might want to
write such things to get them included in the distribution.
I would like to see better "megawidget support", and more Tk widgets. Both
of those, I suspect, are already being worked on. Specifically, I think we
need a combobox, labelled frames, a notebook widget, and a hierarchical
listbox / tree widget. Additionally, but less important IMO, a simpler
method of creating a scrolling frame of widgets would be nice, as would be a
paned widget.
I would like to see the byte code loader part of the core. I understand that
tclpro needs to have some added value, but I think adding this to the free
part of Tcl would add value to tclpro rather than remove value. Right now
there isn't a lot of incentive to byte-compile third-party stuff since not
everyone can use it. If the byte code loader were built in to the core we
might see more pre-compiled extensions, as extension writers could feel more
comfortable with the fact third parties won't have access to their source.
Zach Frey
"Chang LI" <cha...@neatware.com> wrote in message
news:_%Bj4.13453$MI4.1...@newscontent-01.sprint.ca...
>
> Alexandre Ferrieux wrote in message
<388EB0...@cnet.francetelecom.fr>...
>
> >Core: -Modularization (tiny kernel + package require)
>
>
> This is the most important task. It is possible to have file, network,
> thread, ... packages.
Once upon a time, I was going to try to do this. There is a web page and a
mailing list set up at http://www.bright.net/~zfrey/smalltcl.html. This
list has
generated no traffic in over a year.
Much of that is my fault, since I was not able to put the time into
modularizing
Tcl that I thought I would be able to. However, no one else has stepped up
to do the work either.
Given the number of people who seem to be interested in a "leaner and
meaner"
Tcl core, is there anyone interested in (1) actually trying to factor out
Tcl features
into packages, and (2) in taking over any sort of leadership for "Smaller
Tcl," since
I don't seem to be providing enough?
Zach Frey
Jeffrey Hobbs
That's on the laundry list for 9.0, and I will be drumming up
community support for it when I get the bandwidth. 8.4 will come
first though, with other changes.
--
Jeffrey Hobbs The Tcl Guy
Jeffrey Hobbs
> I would like to see the byte code loader part of the core. I understand that
> tclpro needs to have some added value, but I think adding this to the free
> part of Tcl would add value to tclpro rather than remove value.
The bytecode loader is freely redistributable, so its "added value
for TclPro" is not a factor for whether it should be in the core.
I'd like to see the core have a new EvalFile that allows one to
load in files that are either bytecodes, compressed sources, etc
without having to change any Tcl coding. As in:
source old.tcl
source bytecode.tbc
source compressed.zip
all working happily together.
Andreas Kupries
Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> writes:
>Jeffrey Hobbs wrote:
>> the biggest changes are to Tcl and the Tcl community over the
>> last 1.5 years (since the last conference - we were at 8.1 alpha).
> Core: Stubs, and fixed fileevents on 'doze.
> Community: You, Jeff !
Ah, at last. Or I would have had to write this line. The shorter
meaning of this: Seconded.
>> preliminary list on what people
>> would like to see for the future, both in the core and for the
>> community.
> Core: -Modularization (tiny kernel + package require)
> -Interfaces (this includes a true registration of types,
> rather than the silent storing of a new pointer to a TclObjType struct
> in an object's type field. With registration, I could write my dreamed
> ShimmerView tool as a loadable extension :^)
> -A smaller and simpler (eg Forth) bytecode system
> -JIT (native) compilation (may need the previous item)
Ok, with these in the fray, let us add 'Stackless Tcl' too
(See other thread). Reworking the core to support this should
be no problem when it is already ripped apart to do the others
above :-), and it opens a whole slew of new directions.
A minor thing: Extending the parser and backend to generate
and remember line/column information for tokens, and maybe the
bytecode itself.
> Community: -Several other Jeffs at Scriptics !
> -World access to the Holy Bug Database on dev.scriptics.com
> (may need the previous item :^)
> -Alex
--
Sincerely,
Andreas Kupries <a.ku...@westend.com>
<http://www.purl.org/NET/akupries/>
<http://www.usenix.org/events/tcl2k/> You are coming too ?
-------------------------------------------------------------------------------
Chang LI
That is a good news. Few people in the community would like
to modify the Tcl kernel because nobody want to create a
new kernel to compete to Scriptics. That will be waste time.
And it is better to have a unique kernel that is scalable.
Chang
>
>That's on the laundry list for 9.0, and I will be drumming up
>community support for it when I get the bandwidth. 8.4 will come
>first though, with other changes.
>
Don Libes
significant (and unrecognized):
- Ball's continuing XML work
- Newman's TLS (SSL) work
- Rose's Mime work
- Spencer's regexp work (yes, this qualifies since much has been
done after 8.1)
- Wippler's Wiki (more use of it, anyway)
What I would like:
- Official Mac support (now that Apple is booming again, what will
it take to get Scriptics to support the Mac officially?)
- More investment related fun such as Poindexter's TclTicker
(a great tool for seducing several more of my colleagues who
could never be bothered to look at Tcl before :-)
- Several more Jeffrey Hobbs.
Don
Cary O'Brien
William H. Duquette <William.H...@jpl.nasa.gov> wrote:
>On Wed, 26 Jan 2000 12:13:23 +0000, Nat Pryce <n...@doc.ic.ac.uk>
>wrote:
>
>>
>>
>>Jeffrey Hobbs wrote:
>>> would like to see for the future, both in the core and for the
>>> community.
>>
>>
>>- Standard API packages, outside the core but distributed with it.
>> E.g. for networking (various protocols), databases, email,
>> XML and HTML parsing, image and sound processing etc. Something
>> like the standard APIs defined by and/or shipped with Java.
>
>Yes. This is where Python and Perl are beating Tcl hands down
>at the moment: the quantity of useful, interesting packages from
>the community that are delivered with them. We need to make
Strongly seconded.
I still use Tcl primaraly, simply because it gets the job done.
But the handling of support libraries is quite different. My
take is that the library support probably breaks down like this:
java: Sure, Sun has announced the new Java-Enterprise-Vesicles
that do enterprise exactly what you enterprise want. But
You need java 1.2.7 which is only available for Solaris
and NT. (Cross platform my foot!). 128MB recommended.
python: probably already in the standard library, or go to
www.python.org and get it. It will work.
perl: Get it from CPAN. It will probably work, but will
require 2 support libraries, which intern will require
2 support libraries each... (But DBD:DBI is awesome).
tcl: Search around, find two or three libraries that seem
to do what you want. One will be at a dead ftp site
one will be for tcl 7.0, and the one that works will
take more effort to understand than to code yourself.
(Pretty much what happened when I went looking for a
pop client).
There are exceptions. Nothing at all comes even close to Scotty/TNM
for doing SNMP. (Why is SNMPY dead?). But Tcl is falling behind in
the app library support area.
[snip]
-- cary
Steve Ball
>
> In article <388DFE91...@scriptics.com>,
> Jeffrey Hobbs <jeffre...@scriptics.com> wrote:
> > would like to see for the future, both in the core and for the
> > community.
> >
>
> for windows OS would be very nice.
I believe the big problem with printing (in fact, with any extension)
is not getting it working on one platform, but getting it working
*across all platforms*. When my programs run on Mac and Unix,
I'd like them to be able to print too.
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
Selim Issever
A kind of Tcl-Blast CD over the net. It is quite painful, if you write an
application (tcl only, crossplatform) that relies on extensions and you want
to distribute it. A billion problems arise, because customers arent
programmers and are just lost, if they have to compile/install extensions.
For my current project I am using the itcl extension and already now about
half of the support I am giving is how to install tcl/itcl. I would like to
have sound and the img extension, but am hesitating, because the install
instruction would freighten most users.
Tcl is great from the programmers side of view, but for the user it seems to
be too complicated. Distributing your work is just a pain, if you go outside
of the core tcl community. This is already now harming tcl (I get _many_
requests to program in a real language). Also its kind of slow,.. (also many
complains, but may be a problem of my kind of programming)
2) Better PR,.. tcl has a bad reputation somehow,.. It takes me much effort to
convince people here at my work to use tcl instead of
perl/phyton/c(++)/shell/etc... but once they have a look into it, use it once
or twice, they dont give it up again; smile dreamingly, when they talk about
tcl:) Better PR would help a lot.
/selim
--
Selim Issever | Tel: 040 8998-2843 +- It is nothing; they are only -
DESY-F15 | Fax: 040 8998-4033 +- killing my husband. -----
Notkestr. 85 | selim....@desy.de +----- Portuguese Proverb -------
22603 Hamburg/Germany | http://www.physik.uni-dortmund.de/~issevers
<< S M M + +: Your new mapping mud client @ http://smm.mudcenter.com >>
Michael I. Schwartz
Selim Issever <selim....@desy.de> wrote:
>1) Support for distributing your work to the outside community:
I'd like to second this one in a strong, but slightly different way:
A simple, cross-platform, foolproof, easy-to-use, graphical and "background"
command line installation tool for Tcl packages.
This tool should understand what version(s) of Tcl are installed and whether a
version of the requested package is installed for selected Tcl versions.
Preferably it should integrate with the software packaging mechanism of the
host platform (e.g., pkgadd and its database).
Things I've enjoyed from Tcl more than I can say:
1) Tom Poindexter's oratcl
2) scotty (though I got some mileage out of tkined as well)
3) STUBS!
4) Integration of the dash- and visitor- patches!!
I have also enjoyed message catalogs, though I have mandated them on fewer
projects than I anticipated.
Things I plan to enjoy over the next 12 months:
1) XML and CORBA scripting (thanks for tclmico and Steve Ball)
2) The object system (yes, I'm a slow convert)
3) TEA
Feats I hope to read about in the next 12 months:
Scriptics growth exceeding all projections
Jeff Hobbs cloning experiment successful
X raster printer implementation successful
Embedded Tcl/PDA Tk
Cross-platform print solution in Tcl (I think, if nothing else, printer and gdi
extensions can get there for Sun, Windows, and Mac in that timeframe)
Cheers
Michael
--
Michael Schwartz "Expect everything...
and the unexpected never happens"
msch...@nyx.net The Phantom Tollbooth
Donal K. Fellows
Steve Ball <Steve...@zveno.com> wrote:
> I believe the big problem with printing (in fact, with any extension)
> is not getting it working on one platform, but getting it working
> *across all platforms*. When my programs run on Mac and Unix,
> I'd like them to be able to print too.
The same problem occurs with drag-and-drop. Sure, it's quite easy to
get it working on one platform, or even on each platform, but each
platform insists on providing a completely different (and often very
poorly documented[*]) programming interface. And is usually bound up
utterly in that platform's standard system object model. Gack!
I am sorely tempted to state that it is better to just get it working
with one interaction model and then shoehorn everything else in...
Donal.
[* Especially when it comes the business of the philosophy of the
interface. Why do you need to call this function? Why does this
argument need to be passed? ]
--
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>
Frederic BONNET
Mark, your list is perfect to me! I've added some comments below, as well as a
link to my related work.
Mark Patton wrote:
> In the future:
[...]
> - Cruft cleaned out of Tcl. For example, collect all the list commands
> into one "list" command.
>
> - More list commands. "list match" takes arguments like "lsearch"
> and returns a list of elements in a list matching a pattern.
I'll add full interface'ing of objects. Something related to Paul Duffin's work
on Feather. This would allow different object types, such as lists and
dictionary (a baby of mine...), to coexist peacefully without sacrificing
performances by avoiding shimmering.
[...]
> - Better Tk performance in Windows.
>
> - Cross-platform printing support.
I try to address both issues in my TkGS project:
http://www.multimania.com/fbonnet/Tcl/TkGS/specs.htm
The web page is a bit outdated now, since I'm too busy to write decent doc, but
I have a prototype that works quite well.
Basically, the idea behind TkGS is to give up using the Xlib API on all
platforms, native on Unix and emulated on Windows and Mac. TkGS provides a
device-independent model that allows transparent access to native drawing
capabilities, as well as other devices such as printers. Using
device-independent primitives, the same code can display stuff on the screen,
send it to a printer, generate a metafile or a PostScript, all that with optimal
performances on each device thanks to a caching model inspired by Tcl_Objs.
My prototype currently allows the same code to draw primitives on a window on X
and Windows, generate a Tk canvas script (such that you can source the script
and get the same result displayed in a canvas widget), or generate a PostScript
file. TkGS is made of a device-independent core, and of loadable device drivers.
The big work is done in the core such that device driver writing is made easier.
For example, once the core and X and Win32 drivers were written, it took me only
one hour to write the canvas script driver, and a couple more to write the
PostScript driver. I must say that for now TkGS only provides limited features:
rectangle and ellipse drawing, and color selection. But implementing other
primitives won't be too much work once the core is working. Complex features
such as text drawing will be based on existing Tk code.
TkGS tries to unify access to any graphics device. So I believe it would ease
the implementation of cross-platform printing extensions: such an extension
would have device- and platform-independent parts (eg. Tcl commands), some
system-dependent parts (eg. printer selection), and several TkGS drivers would
be provided for low-level access to printers. For example, a Win32 GDI driver on
Windows and a PostScript generator on Unix.
TkGS also tries to address performance problems on Windows. As pointed out by
Leo Schubert for his tkspeedup patch, the Xlib model doesn't suit Win32 very
well and adds too much overhead by calling expensive primitives repeatedly. TkGS
defines a model that gives optimal performances on all drawing models.
Finally, TkGS opens the way to implementations of Tk on handheld devices or
other systems (such as BeOS). In the current state, porting Tk to these systems
would require writing a new Xlib emulation layer or using an existing X server.
I believe the modular architecture of TkGS will ease device driver writing. Only
the windowing part would have to be written. Besides, TkGS can be improved over
time, whereas Xlib is frozen.
The main drawback of TkGS is its being a complete rewrite of the API (hopefully
we can reuse many existing parts such as fonts and text handling), and thus
introduces major incompatibilities. However I really think this is the way to
go, that's why I hope it (or something similar) will be integrated in Tk9.0.
This will induce a rewrite of widget drawing code in the Tk core and in other
major extensions (TkTable, BLT...) but hopefully the TkGS API is close enough to
Xlib to make porting easier.
See you, Fred
--
Frédéric BONNET frederi...@ciril.fr
---------------------------------------------------------------
"Theory may inform, but Practice convinces"
George Bain
Richard.Suchenwirth
>
> I'd like to see the core have a new EvalFile that allows one to
> load in files that are either bytecodes, compressed sources, etc
> without having to change any Tcl coding. As in:
>
> source old.tcl
> source bytecode.tbc
> source compressed.zip
>
> all working happily together.
... and, in the case of text sources, recognize Unicode files when it
sees it (U+FEFF, what even Notepad can do; swap bytes if it sees
U+FFFE...). For other encodings, it could be envisioned that the file
"fconfigures itself", e.g.
fconfigure "" -encoding cp737 ;# ex DOS cp437 Greek
where the empty string as file handle would be substituted to that of
the file being sourced. Just an idea ;-)
--
Schoene Gruesse/best regards, Richard Suchenwirth - +49-7531-86 2703
RC DT2, Siemens Electrocom, Buecklestr. 1-5, D-78467 Konstanz,Germany
-------------- http://purl.org/thecliff/tcl/wiki//Richard*Suchenwirth
Scott Redman
intellectual property more than anything else. There are concerns
that if we open up the source code for "tbcload", that customers
using it will have their IP opened up as well.
Also, tbcload isn't as fast as it could be if it were open source.
It does some mangling of text that doesn't get compiled, which
doesn't need to happen in an open source product (this slows
down the loading). If someone were to build an open bytecode
loader that was different from the TclPro Bytecode Loader, they
wouldn't need to worry about this (and maybe it could be added
to the core...hmmm).
-- Scott
Jeffrey Hobbs wrote:
>
> Bryan Oakley wrote:
> > I would like to see the byte code loader part of the core. I understand that
> > tclpro needs to have some added value, but I think adding this to the free
> > part of Tcl would add value to tclpro rather than remove value.
>
> The bytecode loader is freely redistributable, so its "added value
> for TclPro" is not a factor for whether it should be in the core.
> I'd like to see the core have a new EvalFile that allows one to
> load in files that are either bytecodes, compressed sources, etc
> without having to change any Tcl coding. As in:
>
> source old.tcl
> source bytecode.tbc
> source compressed.zip
>
> all working happily together.
>
Steve Blinkhorn
: In conjunction, I'd like to get a preliminary list on what people
: would like to see for the future, both in the core and for the
: community.
One thing that is really exercising us at the moment is how to put
thin clients on remote machines. Tcl/Tk is next to ideal so far as
we are concerned for building tools for our business customers, where
we in effect have control of what software they have loaded. One
thing which discourages us from making things available over the WWW
is the amount of stuff customers would have to download. We have
some pretty neat things that would have a one-time use for large
numbers of people, but at the moment they would have to download a
megabyte or more. Of course if the plugin were shipped bundled with
all browsers there wouldn't be a problem. Or maybe others have
already solved this one?
--
Steve Blinkhorn <st...@prd.co.uk>
Stavros Kassinos
1. Make Tcl/Tk as truly object-oriented as possible.
2. Make it easier to include extensions in stand-alone (wrapped)
applications.
3. Speed up Tk in MS-Windows.
4. Better support for printing.
Jeffrey Hobbs wrote:
>
> I'm preparing the Tcl Update talk for the Tcl2K conference, and just
> wanted to have an informal poll from other Tcl developers on what you
> think the biggest changes are to Tcl and the Tcl community over the
> last 1.5 years (since the last conference - we were at 8.1 alpha).
>
> In conjunction, I'd like to get a preliminary list on what people
> would like to see for the future, both in the core and for the
> community.
>
> Please keep the lists short, keeping to the big topics. I'll try
> and address as much of the input as I can during the Tcl Update talk
> or at some time during the conference.
>
> Thanks,
>
> Jeffrey Hobbs Tcl Ambassador
> jeffrey.hobbs at scriptics.com Scriptics Corp.
--
--------------------------------------------------------------------
Stavros C. Kassinos | e-mail: kass...@eddy.stanford.edu |
| Office: (650)-723-0546 |
Center for Turbulence Research | Fax: (650)-723-4548 |
Stanford University | http://www.stanford.edu/~kassinos |
--------------------------------------------------------------------
Bryan Oakley
news:38908664...@scriptics.com...
> The bytecode loader (and the TclPro compiler) are used to protect
> intellectual property more than anything else. There are concerns
> that if we open up the source code for "tbcload", that customers
> using it will have their IP opened up as well.
>
> Also, tbcload isn't as fast as it could be if it were open source.
> It does some mangling of text that doesn't get compiled, which
> doesn't need to happen in an open source product (this slows
> down the loading). If someone were to build an open bytecode
> loader that was different from the TclPro Bytecode Loader, they
> wouldn't need to worry about this (and maybe it could be added
> to the core...hmmm).
Maybe scriptics needs to de-couple the loading of bytecodes from the
obfuscation of plain text. In other words, build the byte code loader into
the core, and have the scriptics "save-your-intellectual-property-here" tool
work on top of that.
Won't it be rather difficult for an open source project to get underway,
since the bytecode specification isn't available (or have I not been paying
attention and it has been published somewhere)?
Not trying to pick a fight, just tossing out an opinion I don't get to use
very often...
lvi...@cas.org
According to William H. Duquette <William.H...@jpl.nasa.gov>:
:Oh, and one last little thing that's been annoying me ever since
:I started to use Tcl: can we get rid of the old, crufty csh-style
:command line editing in tclsh and wish, and put in something
Or for that matter, replace the csh-likeness in Tcl with either a
ksh/bash like notation or invent something more useful to tcl.
Not only is the csh style editing a nuisance, but so is the redirection
of stderr ... I suspect there are other csh vestigates which could
go away without causing me any heartache.
--
<URL: mailto:lvi...@cas.org> <URL: http://www.usenix.org/events/tcl2k/>
<*> O- <URL: http://www.purl.org/NET/lvirden/> Tcl2K - Austin, Texas, US
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
lvi...@cas.org
According to Cary O'Brien <cob...@Radix.Net>:
:tcl: Search around, find two or three libraries that seem
: to do what you want. One will be at a dead ftp site
: one will be for tcl 7.0, and the one that works will
: take more effort to understand than to code yourself.
: (Pretty much what happened when I went looking for a
: pop client).
:
:There are exceptions. Nothing at all comes even close to Scotty/TNM
:for doing SNMP. (Why is SNMPY dead?). But Tcl is falling behind in
:the app library support area.
What are some ideas for dealing with this issue? Java has JavaSoft -
a large group of paid employees grinding out APIs. Python - I don't know
that community well enough. How do they force people who no longer have
time to work on code to do so? Because that's why you get dead ftp sites,
old ports, etc. Perl - they have a group of volunteers working hard
to do a lot, plus I still run into dead ftp sites, abandoned code, etc. even
there.
I'm not saying there is no solution - a solution would be great. Expecting
that solution from Scriptics is unrealistic. Until people on this newsgroup,
etc. step forward and volunteer, what we have is what we get...
lvi...@cas.org
According to Bryan Oakley <boa...@vignette.com>:
:I think we need an easy way for the community to contribute to the core
:distribution (though, not necessarily "the core"). Tcl needs more
Jeff, How many software items have been submitted to Scriptics via the
web form and then been put on hold awaiting some decision on distribution?
I know it seems each week I check the netcvs repository I see new extensions
available there.
In my mind, we need more people WRITING code that could eventually be
contributed. As more contributions start arriving on Scriptics door,
documented and with test cases, demo code modules, etc. I suspect the
need will rise in priority.
Jeffrey Hobbs
>
> According to Bryan Oakley <boa...@vignette.com>:
> :I think we need an easy way for the community to contribute to the core
> :distribution (though, not necessarily "the core"). Tcl needs more
>
> Jeff, How many software items have been submitted to Scriptics via the
> web form and then been put on hold awaiting some decision on distribution?
> I know it seems each week I check the netcvs repository I see new extensions
> available there.
>
> In my mind, we need more people WRITING code that could eventually be
> contributed. As more contributions start arriving on Scriptics door,
> documented and with test cases, demo code modules, etc. I suspect the
> need will rise in priority.
For the former, I'm not quite sure what kind of submissions you are
referring to. What sort of distribution decision is required? We
have in netcvs pretty much anything we used, or other authors asked
to put in. The authors maintain write access and control.
There is a lack of full modules, with full docs, tests, demos and
such in general. We're going to start working on this more in the
future here, as far as organization, but the community has to
provide the (well-tested and documented) code.
--
Jeffrey Hobbs The Tcl Guy
Cameron Laird
Cary O'Brien <cob...@Radix.Net> wrote:
.
.
.
>java: Sure, Sun has announced the new Java-Enterprise-Vesicles
> that do enterprise exactly what you enterprise want. But
> You need java 1.2.7 which is only available for Solaris
> and NT. (Cross platform my foot!). 128MB recommended.
.
.
.
>There are exceptions. Nothing at all comes even close to Scotty/TNM
>for doing SNMP. (Why is SNMPY dead?). But Tcl is falling behind in
starbase.neosoft.com/~claird/comp.lang.tcl/nm_and_scotty.html>.
Why is SNMPY
<URL:http://starbase.neosoft.com/~claird/comp.lang.python/snmpy.html>
dead? Just the breaks; no one happens to combine enough motivation
and expertise to push it forward. Juergen is very, *very* knowledge-
able, and it's better not to think how Tcl-ers would do SNMP without
him.
.
.
.
--
Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Jan Nijtmans
> Things I've enjoyed from Tcl more than I can say:
> 1) Tom Poindexter's oratcl
> 2) scotty (though I got some mileage out of tkined as well)
> 3) STUBS!
> 4) Integration of the dash- and visitor- patches!!
The visitor's patch is not included in 8.3. Reasons:
- Not supported by Matthew Rice any more
- Highly dependant on internal canvas represenstion,
therefore very probably to break in future Tk
versions.
- The new option database stuff probably gives
better possibilities to implement similar behavior.
- Currently there is only one extension (Visrotate)
using it.
If I'm wrong, and someone is really in a big need for the
visitor's patch, please come forward with a suggestion
how to go on with it in the future. Otherwise, it
will probably die. Sorry,
Regards,
--
Jan Nijtmans, CMG Arnhem B.V.
email: j.nij...@chello.nl (private)
jan.ni...@cmg.nl (work)
url: http://purl.oclc.org/net/nijtmans/
Petasis George
>
> In article <86o7an$ige$1...@saltmine.radix.net>,
> Cary O'Brien <cob...@Radix.Net> wrote:
> .
> .
> .
> >java: Sure, Sun has announced the new Java-Enterprise-Vesicles
> > that do enterprise exactly what you enterprise want. But
> > You need java 1.2.7 which is only available for Solaris
> > and NT. (Cross platform my foot!). 128MB recommended.
> (How is it that so few people seem to notice this?)
Nat Pryce
lvi...@cas.org wrote:
>
> According to Cary O'Brien <cob...@Radix.Net>:
> :tcl: Search around, find two or three libraries that seem
> : to do what you want. One will be at a dead ftp site
> : one will be for tcl 7.0, and the one that works will
> : take more effort to understand than to code yourself.
> : (Pretty much what happened when I went looking for a
> : pop client).
> :
> :There are exceptions. Nothing at all comes even close to Scotty/TNM
> :for doing SNMP. (Why is SNMPY dead?). But Tcl is falling behind in
> :the app library support area.
>
> What are some ideas for dealing with this issue? Java has JavaSoft -
> a large group of paid employees grinding out APIs....
The Java solution is to define standard APIs, in cooperation with
industrial partners. The W3C does the same thing with its
standards, and it only provides reference implementations.
I think this fits well to Tcl's development model. APIs could
be defined in cooperation with the Tcl community, and then
made into Tcl standards (the W3C only release "reccomendations")
by Scriptics.
Cheers,
Nat.
--
+------------------------------------------+---------------------+
| 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 |
+------------------------------------------+---------------------+
Steve Bellenot
>
>According to William H. Duquette <William.H...@jpl.nasa.gov>:
>:Oh, and one last little thing that's been annoying me ever since
>:I started to use Tcl: can we get rid of the old, crufty csh-style
>:command line editing in tclsh and wish, and put in something
>
>Or for that matter, replace the csh-likeness in Tcl with either a
>ksh/bash like notation or invent something more useful to tcl.
>Not only is the csh style editing a nuisance, but so is the redirection
>of stderr ... I suspect there are other csh vestigates which could
>go away without causing me any heartache.
I must admit that I too dislike the csh-likeness in Tcl and would
prefer a more ksh/bash like tclsh.
--
http://www.math.fsu.edu/~bellenot
bellenot <At/> math.fsu.edu
+1.850.644.7189 (4053fax)
Alexandre Ferrieux
>
> Jeffrey Hobbs (jeffre...@scriptics.com) wrote:
> : In conjunction, I'd like to get a preliminary list on what people
> : would like to see for the future, both in the core and for the
> : community.
>
> thin clients on remote machines. Tcl/Tk is next to ideal so far as
> we are concerned for building tools for our business customers, where
> we in effect have control of what software they have loaded. One
> thing which discourages us from making things available over the WWW
> is the amount of stuff customers would have to download. We have
> some pretty neat things that would have a one-time use for large
> numbers of people, but at the moment they would have to download a
> megabyte or more. Of course if the plugin were shipped bundled with
> all browsers there wouldn't be a problem. Or maybe others have
> already solved this one?
Since Scriptics is showing absolutely no willingness to make the plugin
truly usable in the foreseeable future, I've switched to making my own
thin client. So I used Jan Nijtman's wrap, which even at version 0.3 is
fully usable and generates very tight (816K for wish) executables. In
particular, the ability to WinZip and modify the archive allows to
really minimize the footprint (eg you can remove entire parts of the Tcl
library that you knwo you won't be using).
And yes, the plugin is a sad undershoot.
-Alex
lvi...@cas.org
According to Jeffrey Hobbs <jeffre...@scriptics.com>:
:lvi...@cas.org wrote:
:>
:> According to Bryan Oakley <boa...@vignette.com>:
:> :I think we need an easy way for the community to contribute to the core
:> :distribution (though, not necessarily "the core"). Tcl needs more
:>
:> Jeff, How many software items have been submitted to Scriptics via the
:> web form and then been put on hold awaiting some decision on distribution?
:For the former, I'm not quite sure what kind of submissions you are
:referring to. What sort of distribution decision is required? We
I am talking about contributions that are like the http extension, or
Img, etc. Things specifically contributed to Scriptics that are more
than a bug fix or slight enhancement, but have not yet been integrated.
There are occasions where, like Bryan, people have said to me that it
should be easier to add things to the basic distribution tars. I am
wondering if people are contributing, and things are not being added,
or if the problem is that people are not contributing. I certainly
don't see many postings from the scriptics forms onto the newsgroup.
Of course, it MIGHT be that people just don't think about speaking up
about the issue, since there's no clear mechanism. However, I would
argue that with the examples for instance of STUBs, Img, the dash patch
and a few other things, you have already shown the community that with
some patience and effort, new code continues to make it into the basic
distribution of Tcl.
lvi...@cas.org
According to Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr>:
:Since Scriptics is showing absolutely no willingness to make the plugin
:truly usable in the foreseeable future, ...
Alex, while you are certainly free to couch things in these terms, I am not
certain that Scriptics sees things in those terms. What I saw, at the last
Tcl conference, was what appeared to me to be a bit of surprise on John's
part that there was as much interest in the plugin as the conference attendees
expressed. And yet, when I search the past 3 years of Deja postings for
the term "tcl plug in" in comp.lang.tcl, there have been only 45 postings.
Yet the source code is available and free for people to fix, enhance and
extend, etc.
Why is it that things are always the fault of Scriptics? Why can we not
say "Since the Tcl community, including myself, is showing absolutely no
interest in making the plugin truly usable..." ?
Alexandre Ferrieux
>
> According to Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr>:
> :Since Scriptics is showing absolutely no willingness to make the plugin
> :truly usable in the foreseeable future, ...
>
> Alex, while you are certainly free to couch things in these terms, I am not
> certain that Scriptics sees things in those terms. What I saw, at the last
> Tcl conference, was what appeared to me to be a bit of surprise on John's
> part that there was as much interest in the plugin as the conference attendees
> expressed. And yet, when I search the past 3 years of Deja postings for
> the term "tcl plug in" in comp.lang.tcl, there have been only 45 postings.
> Yet the source code is available and free for people to fix, enhance and
> extend, etc.
Yes but it is in a kind of deadlock state: not many people actually
deploy it because it is not yet reliable (esp. with IE). Hence it's
seldom seen or heard of by end users, hence the reduced interest from
Scriptics.
> Why is it that things are always the fault of Scriptics? Why can we not
> say "Since the Tcl community, including myself, is showing absolutely no
> interest in making the plugin truly usable..." ?
This is an interesting question, but the answer is different in the case
of the plugin: the plugin is a gateway to a new universe (to say it
provocatively: walk on Java's toes !), which is highly significant for
the overall acceptance of Tcl. So it would make sense for Scriptics to
support it more directly. Even better, it could be sold ! I know at
least one large organization where a nationwide system with thin clients
has started out with the Tcl plugin and is now switching to Java because
of the bugs. They would have been happy to buy a 10,000-user (or site-)
license for a *working* plugin. Too bad, eh ?
And to answer your last question, neither Jan, nor David, nor me, have
the time to debug it. It happens to be quite a hard task, effectively
reducing the rate of spontaneous volunteers in the community... Given
(for example) the business model sketched above, Scriptics, instead
could *invest* that hard work !
-Alex
Jeffrey Hobbs
> lvi...@cas.org wrote:
> > According to Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr>:
> > :Since Scriptics is showing absolutely no willingness to make the plugin
> > :truly usable in the foreseeable future, ...
Alex, I think you better make sure you read all the articles I
post before posting such wording... Search especially for the
recent posts about the plugin.
> > Why is it that things are always the fault of Scriptics? Why can we not
> > say "Since the Tcl community, including myself, is showing absolutely no
> > interest in making the plugin truly usable..." ?
>
> This is an interesting question, but the answer is different in the case
> of the plugin: the plugin is a gateway to a new universe (to say it
> provocatively: walk on Java's toes !), which is highly significant for
> the overall acceptance of Tcl. So it would make sense for Scriptics to
> support it more directly. Even better, it could be sold ! I know at
> least one large organization where a nationwide system with thin clients
> has started out with the Tcl plugin and is now switching to Java because
> of the bugs. They would have been happy to buy a 10,000-user (or site-)
> license for a *working* plugin. Too bad, eh ?
That's interesting, especially since noone ever bothered to contact
Scriptics about such an opportunity. Scriptics is, after all, a
commercial company, and if someone were to wave that much interest
in front of a VP's nose, you'd bet they'd jump. BTW, are you implying
that Java doesn't have bugs, or have these guys just not explored that
far yet?
The same goes for any and all support of various parts of Tcl
and/or related extensions. Scriptics provides support for what
has been determined to be items of high interest. How do they
reach that conclusion? Based on direct input to Scriptics. I
can only convey so much interest about certain items the right
parties. When 40 people contact Scriptics wanting support for an
extension instead of filtering it all through me as 1, it really
does have greater effect.
> And to answer your last question, neither Jan, nor David, nor me, have
> the time to debug it. It happens to be quite a hard task, effectively
> reducing the rate of spontaneous volunteers in the community... Given
Is the fact that it's a hard task make it any easier for Scriptics?
Especially when the real hard problems have to do with dealing with
the MS demons that make browsers with their own standards?
Peter V. Morch
> >- Better support for defining data structures and abstract
> > data types or objects. Preferably a prototype-based
> > object system.
>
> Absolutely. This is an area where Python dominates Tcl by
> several orders of magnitude, and where Tcl could really shine.
> We need support for real record structures and objects in the
> core. (I'm sick of explicitly mimicking records with arrays.
> Yeah, it works; functional it is; pretty it ain't. Any solution
> would probably do the same thing under the hood, and that's fine.)
Here here.
> Oh, and one last little thing that's been annoying me ever since
> I started to use Tcl: can we get rid of the old, crufty csh-style
> command line editing in tclsh and wish, and put in something
> more like GNU readline? I spend a fair amount of time at the
> tclsh prompt, and not being able to use the cursor keys is a major
> pain. Yes, I know about tkCon and all of that; I still don't
> think it's too much to ask to have it in the core interpreters
> if the platform supports it.
I end up using wish and tclsh under emacs just to achieve this. I agree
100% completely. Command line editing!! A missing final touch that is a
little annoying very, very often.
My $0.02 anyway.
Oeter
ldup...@sprint.ca
> Alexandre Ferrieux wrote:
>> lvi...@cas.org wrote:
>> > According to Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr>:
>> > :Since Scriptics is showing absolutely no willingness to make the plugin
>> > :truly usable in the foreseeable future, ...
>> Even better, it could be sold ! I know at
>> least one large organization where a nationwide system with thin clients
>> has started out with the Tcl plugin and is now switching to Java because
>> of the bugs. They would have been happy to buy a 10,000-user (or site-)
>> license for a *working* plugin. Too bad, eh ?
> That's interesting, especially since noone ever bothered to contact
> Scriptics about such an opportunity. Scriptics is, after all, a
> commercial company, and if someone were to wave that much interest
> in front of a VP's nose, you'd bet they'd jump.
What's even more interesting is that such a company would consider using the
plugin in such a large number but would never attempt to contact Scriptics to
know what their plans were for the plugin. Unless someone told them it was
useless because Scriptics didn't care about it. Hmmm...
L
David Cuthbert
> Won't it be rather difficult for an open source project to get underway,
> since the bytecode specification isn't available (or have I not been
> paying attention and it has been published somewhere)?
I haven't seen any specs on the bytecode for Tcl, but it's not that hard to
puzzle out. Pull up generic/tclCompile.c for more information.
Also, setting TCL_COMPILE_DEBUG when building Tcl helps considerably.
Dave
David Gravereaux
>Is the fact that it's a hard task make it any easier for Scriptics?
>Especially when the real hard problems have to do with dealing with
>the MS demons that make browsers with their own standards?
Isn't defensive programming fun? Or how about trying to emulate bugs so you can
call your own copy "compatible"? Sorry, i don't mean to change the topic.
Jeff, if the plugin was on the Scriptics netcvs it sure would help. Maybe give
write access to me and Jan. I have a bunch of unfinished code for it that
handles the threading issues (it almost works). I could do the initial import
if you like.
--
* David Gravereaux *
Tomahawk Software Group
"It has not escaped our notice that the structure we have proposed
immediately suggests a possible copying mechanism for the genetic
material." -- Watson and Crick 1953
Mike Hoegeman
>
> af_...@my-deja.com wrote:
> >
> > In article <388DFE91...@scriptics.com>,
> > Jeffrey Hobbs <jeffre...@scriptics.com> wrote:
> > > In conjunction, I'd like to get a preliminary list on what people
> > > would like to see for the future, both in the core and for the
> > > community.
> > >
> >
> > for windows OS would be very nice.
>
> I believe the big problem with printing (in fact, with any extension)
> is not getting it working on one platform, but getting it working
> *across all platforms*. When my programs run on Mac and Unix,
> I'd like them to be able to print too.
as has been metioned before. you could get a long way
in the cross-pltform arena, by supplying PDF output.
-mike
>
> 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
Chang LI
Alex may suggest that plugin may have big market.
One function I need in the plugin is to replace the
JavaScript by Tcl. If we did not push Tcl plugin more
widely in browsers, Tcl/Tk may have difficult exist in
the web client. I like PDF plugin. Can we have a
Tcl/Tk plugin like that?
Jeffrey Hobbs wrote in message <3891D6AF...@scriptics.com>...
>Alexandre Ferrieux wrote:
>> lvi...@cas.org wrote:
>> > According to Alexandre Ferrieux
<alexandre...@cnet.francetelecom.fr>:
>> > :Since Scriptics is showing absolutely no willingness to make the
plugin
>> > :truly usable in the foreseeable future, ...
>
>Alex, I think you better make sure you read all the articles I
>post before posting such wording... Search especially for the
>recent posts about the plugin.
>
>> > Why is it that things are always the fault of Scriptics? Why can we
not
>> > say "Since the Tcl community, including myself, is showing absolutely
no
>> > interest in making the plugin truly usable..." ?
>>
>> This is an interesting question, but the answer is different in the case
>> of the plugin: the plugin is a gateway to a new universe (to say it
>> provocatively: walk on Java's toes !), which is highly significant for
>> the overall acceptance of Tcl. So it would make sense for Scriptics to
>> support it more directly. Even better, it could be sold ! I know at
>> least one large organization where a nationwide system with thin clients
>> has started out with the Tcl plugin and is now switching to Java because
>> of the bugs. They would have been happy to buy a 10,000-user (or site-)
>> license for a *working* plugin. Too bad, eh ?
>
>That's interesting, especially since noone ever bothered to contact
>Scriptics about such an opportunity. Scriptics is, after all, a
>commercial company, and if someone were to wave that much interest
>in front of a VP's nose, you'd bet they'd jump. BTW, are you implying
>that Java doesn't have bugs, or have these guys just not explored that
>far yet?
>
>The same goes for any and all support of various parts of Tcl
>and/or related extensions. Scriptics provides support for what
>has been determined to be items of high interest. How do they
>reach that conclusion? Based on direct input to Scriptics. I
>can only convey so much interest about certain items the right
>parties. When 40 people contact Scriptics wanting support for an
>extension instead of filtering it all through me as 1, it really
>does have greater effect.
>
>> And to answer your last question, neither Jan, nor David, nor me, have
>> the time to debug it. It happens to be quite a hard task, effectively
>> reducing the rate of spontaneous volunteers in the community... Given
>
>Is the fact that it's a hard task make it any easier for Scriptics?
>Especially when the real hard problems have to do with dealing with
>the MS demons that make browsers with their own standards?
>
Chang LI
Scott Redman wrote in message <38908664...@scriptics.com>...
>The bytecode loader (and the TclPro compiler) are used to protect
>intellectual property more than anything else. There are concerns
>that if we open up the source code for "tbcload", that customers
>using it will have their IP opened up as well.
>
I disagree. Java opened its bytecode compiler entirely, the Java users also
have their IP opened up as well?
>Also, tbcload isn't as fast as it could be if it were open source.
>It does some mangling of text that doesn't get compiled, which
>doesn't need to happen in an open source product (this slows
>down the loading). If someone were to build an open bytecode
>loader that was different from the TclPro Bytecode Loader, they
>wouldn't need to worry about this (and maybe it could be added
>to the core...hmmm).
>
>-- Scott
>
>Jeffrey Hobbs wrote:
>>
>> Bryan Oakley wrote:
>> > I would like to see the byte code loader part of the core. I understand
that
>> > tclpro needs to have some added value, but I think adding this to the
free
>> > part of Tcl would add value to tclpro rather than remove value.
>>
>> The bytecode loader is freely redistributable, so its "added value
>> for TclPro" is not a factor for whether it should be in the core.
>> I'd like to see the core have a new EvalFile that allows one to
>> load in files that are either bytecodes, compressed sources, etc
>> without having to change any Tcl coding. As in:
>>
>> source old.tcl
>> source bytecode.tbc
>> source compressed.zip
>>
>> all working happily together.
>>
Jeffrey Hobbs
...
> Jeff, if the plugin was on the Scriptics netcvs it sure would help. Maybe give
> write access to me and Jan. I have a bunch of unfinished code for it that
> handles the threading issues (it almost works). I could do the initial
Yes, putting it into CVS is the first item on the list, and then
I can make it available for a select few to write to. The reason
that isn't simple, is that it's never been in CVS, so I have to
jumpstart that whole process. Time leading up to Tcl2K is precious,
so I'll likely get to it after that.
Hmmm, I suppose that the latest sources are the on the Scriptics
FTP site (plus minor mods by others)?
David Gravereaux
>David Gravereaux wrote:
> ...
>> Jeff, if the plugin was on the Scriptics netcvs it sure would help. Maybe give
>> write access to me and Jan. I have a bunch of unfinished code for it that
>> handles the threading issues (it almost works). I could do the initial
>
>Yes, putting it into CVS is the first item on the list, and then
>I can make it available for a select few to write to. The reason
>that isn't simple, is that it's never been in CVS, so I have to
>jumpstart that whole process. Time leading up to Tcl2K is precious,
>so I'll likely get to it after that.
>
>Hmmm, I suppose that the latest sources are the on the Scriptics
>FTP site (plus minor mods by others)?
Ohh, a complete tagged version history. That's a great idea. Jan has the patch
against the last plugin made for his stub'd beta. I forget the version number.
And I have some stuff against his patch that I need to gen a diff of. Actually
get it finished...
--
* David Gravereaux *
Tomahawk Software Group
"It has not escaped our notice that the structure we have proposed
immediately suggests a possible copying mechanism for the genetic
material." -- Watson and Crick 1953 on their theory of DNA
Alexandre Ferrieux
>
> Alexandre Ferrieux wrote:
> > lvi...@cas.org wrote:
> > > According to Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr>:
> > > :Since Scriptics is showing absolutely no willingness to make the plugin
> > > :truly usable in the foreseeable future, ...
>
> Alex, I think you better make sure you read all the articles I
> post before posting such wording... Search especially for the
> recent posts about the plugin.
I did read them. Putting the plugin on CVS sure helps, but the note
about the need for help from the community (which is an obvious common
factor of anything we do), did elicit that slight overreaction of
mine... Of course you can't do that alone, and of course we're all ready
to help. I'm just complaining that the plugin is not higher up on
Scriptics official todo list, despite its obvious link with the success
of Tcl in enterprise contexts (read: $$$).
> That's interesting, especially since noone ever bothered to contact
> Scriptics about such an opportunity. Scriptics is, after all, a
> commercial company, and if someone were to wave that much interest
> in front of a VP's nose, you'd bet they'd jump.
Again, vicious circle. To try you need hope. Epsilon, not zero.
> BTW, are you implying
> that Java doesn't have bugs,
It turns out that projected on the specific hyperplane of their
applications, the Java bugs have a smaller footprint. At least it seems
so (cause such basic bugs as an unusable browser::geturl in Java+IE
would have been famous by now). Now the switch is not over yet. Maybe
there's still room for a last-minute operation. I'll check.
> Is the fact that it's a hard task make it any easier for Scriptics?
Yes it does, because considering what's at stake, Scriptics can put real
money on it. None of us can.
> Especially when the real hard problems have to do with dealing with
> the MS demons that make browsers with their own standards?
Are you suggesting that you're short of Windows experts ? David, are you
available ?
From what I gathered, it looks like the problem is that IE calls back
from outer threads, and the plugin doesn't expect that. I don't know if
the culprit is the plugin ignoring a constraint of the API (being
reentrant), or the standard omitting to specify that constraint, or IE
violating the opposite (that callbacks be made from the main thread), or
a blend of these...
-Alex
Steve Blinkhorn
Seriously, though, I've been working on much the same sorts of
applications for a good few years, since before there was a Windoze
version (or at least an official Windoze version) of Tcl/Tk. The
issue is always the same: how to build applications for technically
ignorant audiences who have a one-time use for a piece of software and
don't want to go through the pain of installing a whole language
system to support it. From hand crafting stand-alone executables to
ProWrap and FreeWrap, I've tried them all. It's not that they don't
work, they do. But it's all a bit heavy weather.
I've taken another look at the plugin recently, to find that
many of the links to Tclets on the Scriptics site are dead.
I've also looked at the NASA version, but find I have to correspond
with the maintainers because there are problems building a BSD/OS version.
And it's 4Mbytes of download for the end-user.
Good software systems are invisible to end-users: they shouldn't have
to know or care what the application needs to run. I have this
concern that Scriptics are chasing big bucks business-to-business
opportunities, and the rest of the user community is very computer
literate. In between, there is the market for easy to load, easy to
run, quick to develop applications, where scripting is the right
approach.
--
Steve Blinkhorn <st...@prd.co.uk>
Scott Redman
Chang LI wrote:
>
> Scott Redman wrote in message <38908664...@scriptics.com>...
> >The bytecode loader (and the TclPro compiler) are used to protect
> >intellectual property more than anything else. There are concerns
> >that if we open up the source code for "tbcload", that customers
> >using it will have their IP opened up as well.
> >
>
> I disagree. Java opened its bytecode compiler entirely, the Java users also
> have their IP opened up as well?
>
These are very different situations. The issue is being revisited,
but I would push for a (separate) open source bytecode loader.
-- Scott
Cary O'Brien
Steve Blinkhorn <st...@sole.prd.co.uk> wrote:
>It looks like I touched a nerve mentioning the plugin....
>
>
>Good software systems are invisible to end-users: they shouldn't have
>to know or care what the application needs to run. I have this
>concern that Scriptics are chasing big bucks business-to-business
>opportunities, and the rest of the user community is very computer
>literate. In between, there is the market for easy to load, easy to
>run, quick to develop applications, where scripting is the right
>approach.
>
I'm really perplexed at the lack of, well I guess resources directed
toward getting the plugin to work. One place I work has made a (good,
I think) business decision that the user interface for the entire
product family will be via HTML, using as vanilla approach as is
possible. But you can only go so far with forms. This app *really
needs* the sort of interface that can be created with a couple of
hundred lines of tcl and a canvas widget. Just dragging nodes
that are rubber-banded together. The only other hope for
this company is to dig deep and try and implement the stuff with Java.
I *really* wish I could point them toward a working TCL plugin and
say "This will solve your problems".
I don't understand why Scriptics doesn't take the plugin under their
wing and clean it up. Having a browser based GUI has *got* to increase
their access to business apps. How broken is the plugin? Is it really
man-years of work to fix it? I just don't get it.
Comments? (besides "fix it yourself").
-- cary