gzip/zlib in tcl

[vit...@gmail.com]

Anybody knows where to find and how to use gzip/zlib compression in
TCL? (to compress/uncompress any data, not just files). I thought
there was an extension available as part of tcllib but I don't see it
there, at least not in the latest 8.4 release by ActiveState unless it
is a part of some other package.

[MartinLemburg@Siemens-PLM]

Hi,

here a tcl 8.4 example:

package require vfs;
package require vfs::zip;

proc extractFromZip {fileName destination {pattern *}} {
set mount [file join \
$::env(TEMP) \
mountPoint \
[file rootname [file tail $fileName]] \
];

if {[catch {
set fd [vfs::zip::Mount $fileName $mount];
} reason] == 1} {
error $reason $::errorInfo $::errorCode;
}

if {[file exists $destination]} {
if {![file isdirectory $destination]} {
vfs::filesystem unmount $mount
close $fd;
error "no such directory \"$destination\"" \
"" \
[list ENOENT $destination];
}
} else {
if {[catch {
file mkdir $destination;
} reason] == 1} {
vfs::filesystem unmount $mount
close $fd;
error $reason $::errorInfo $::errorCode;
}
}

if {[catch {
eval file copy -force \
[glob -nocomplain -directory $mount -- $pattern] \
[list $destination];
} reason] == 1} {
vfs::filesystem unmount $mount
close $fd;
error $reason $::errorInfo $::errorCode;
}

vfs::filesystem unmount $mount
close $fd;

return;
}

And the same a bit changed for tcl 8.5:

package require vfs;
package require vfs::zip;

proc extractFromZip {fileName destination {pattern *}} {
set mount [file join \
$::env(TEMP) \
mountPoint \
[file rootname [file tail $fileName]] \
];

if {[catch {
set fd [vfs::zip::Mount $fileName $mount];
} reason options] == 1} {
return -options $options $reason;
}

if {[file exists $destination]} {
if {![file isdirectory $destination]} {
vfs::filesystem unmount $mount
close $fd;

error "no such directory \"$destination\"" \
"" \
[list ENOENT $destination];
}
} else {
if {[catch {
file mkdir $destination;
} reason options] == 1} {
vfs::filesystem unmount $mount
close $fd;

return -options $options $reason;
}
}

if {[catch {
file copy -force \
{*}[glob -nocomplain -directory $mount -- $pattern] \
$destination;
} reason options] == 1} {
vfs::filesystem unmount $mount
close $fd;

return -options $options $reason;
}

vfs::filesystem unmount $mount
close $fd;

return;
}

As far as I know the tcl 8.4 distribution includes the extension
tclvfs, the VirtualFileSystem.
And a "sub" package is the ZIP handling vfs::zip package.

Best regards,

Martin Lemburg

[schlenk]

There is some pure Tcl gzip code inside the amsn chat client IIRC, but
it is gpl licensed. For C based extensions there is Trf and a zlib
based extension (the latter one is included in all tclkit binaries).
See for example http://wiki.tcl.tk/4610

Michael

[vit...@gmail.com]

Thanks for your replies.

This is so weird. There are all kinds of encryption/encoding packages
included with ActiveTcl by default but no STANDALONE zlib/gzip/bzip2/
lzw packages. You have to go through all kinds of dancing to find them
and make them work. (I am talking about C coded binary packages, not
pure TCL, which would be too slow, and they need to work on data
streams, not just files)

[schlenk]

Its only partially weird. There was a TIP in the Tcl 8.5 timeline to
bundle a zlib extension with the core, but people were unsure about
the right API to do it and the person doing it got distracted by other
stuff so it wasn't finished.

The zlib TIP should be revived for the 8.6 series..., but needs
someone to push it.

Michael

[Eric Hassold]

schlenk wrote :

> vit...@gmail.com wrote:
>> Thanks for your replies.
>>
>> This is so weird. There are all kinds of encryption/encoding packages
>> included with ActiveTcl by default but no STANDALONE zlib/gzip/bzip2/
>> lzw packages. You have to go through all kinds of dancing to find them
>> and make them work. (I am talking about C coded binary packages, not
>> pure TCL, which would be too slow, and they need to work on data
>> streams, not just files)
>
> Its only partially weird. There was a TIP in the Tcl 8.5 timeline to
> bundle a zlib extension with the core, but people were unsure about
> the right API to do it and the person doing it got distracted by other
> stuff so it wasn't finished.

Isn't this an example of "le mieux est l'ennemi du bien" ("the perfect
is the enemy of the good") ?

I believe there is a very large demand for supporting inflate/deflate,
in all kind of areas (deflate transfer in http and httpd, png support,
ZIP VFS, ...), and this can be performed decently only natively. TIP
with reference implementation exists since 2004, there is AFAIK no
license or export issue, code is very portable, and induces a very small
overhead. So we end up with many distributions (tclkit, etcl, ...)
providing support for it, but core integration still missing for
portability.

I'm kindly wondering if this doesn't reveal Tcl is lacking some focus on
final users' usage and needs when prioritizing TIPs inclusions. I'm
personaly faced to many more applications (and users) in need for
deflate than for bignums.

Eric

[keithv]

On Apr 8, 3:07 am, vit...@gmail.com wrote:
> Anybody knows where to find and how to use gzip/zlib compression in
> TCL? (to compress/uncompress any data, not just files).

There's a tcl only clone of unzip at http://wiki.tcl.tk/17433.

Keith

[Donald G Porter]

Eric Hassold wrote:
> I'm kindly wondering if this doesn't reveal Tcl is lacking some focus on
> final users' usage and needs when prioritizing TIPs inclusions. I'm
> personaly faced to many more applications (and users) in need for
> deflate than for bignums.

The development process is not secret, and not beyond your influence.

If a final user of Tcl has priorities that are not getting addressed
(and I'm sure that is the case), then get onto TCLCORE or into the
Tracker and start making noise about it. Be kind; it's rare that
something can be immediately completed, and long-languishing requests
often indicate that something is either hard or not believed to be a
good idea. Be open to alternative solutions and perspectives as well.
But persistent reminders that something is important to you
do have an influence and will increase the likelihood that your
concerns will get addressed sooner.

As a very current positive example, there have been bug reports about
problems with some uses of [fcopy] languishing for years. In the
last month Alexandre Ferrieux got interested and motivated about the
matter, contributed a fix, and it's now on track to be in the 8.4.19
release, due soon, and 8.5.3 and 8.6a1 releases as they come.

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

[Eric Hassold]

Donald G Porter wrote :

> Eric Hassold wrote:
>> I'm kindly wondering if this doesn't reveal Tcl is lacking some focus
>> on final users' usage and needs when prioritizing TIPs inclusions. I'm
>> personaly faced to many more applications (and users) in need for
>> deflate than for bignums.
>
> The development process is not secret, and not beyond your influence.
>
> If a final user of Tcl has priorities that are not getting addressed
> (and I'm sure that is the case), then get onto TCLCORE or into the
> Tracker and start making noise about it. Be kind; it's rare that
> something can be immediately completed, and long-languishing requests
> often indicate that something is either hard or not believed to be a
> good idea.

Which one applies to this specific (i.e. gzip/zlib support) case ?

I understand that nothing can be done without people contributing. When
a feature is requested, or a bug is reported, things will improve only
thanks to persons offering expertise and, often, lot of time, just like
Alexandre did on the fcopy issue. But does it really apply here? Or is
it only a political issue?

From a technical point of view, Pascal Scheffers already did all the
hard part. TIP and (robust) reference implementation exist since 2004,
and this implementation doesn't interfere with other part of core (so
even in worst case, it won't introduce regressions or incompatibilities).

So, perhaps adding support for zlib into Tcl core is "not believed to be
a good idea" ? This is something I may understand, if adopting the usual
philosophy "keep core small, and put as much as possible into
extensions". And pros and cons of core inclusion is a long standing
debate. However, when observing things like arbitrary precision integers
(and its dependencies) ended up in Tcl core (which is fine! I'm just
using it as a reference, to try to understand motivation), I'm little
perplexed about what was showstoppers for deflate support inclusion in
8.5, and if supporting it wouldn't have contributed in turning Tcl into
a more practical (hence more popular) language.

In a similar way, let's consider PNG support inclusion. It's little bit
disrupting to look back into c.l.t archives, and find post from J.
Ousterhout back to 1995:

http://groups.google.fr/group/comp.lang.tcl/browse_thread/thread/6fc7234148da58ac/0a9cd60ffb9f40ee

"Tk will support any and all widely used standards. Today, GIF is
really important because it's the most common image type on the Web; if
PNG becomes widely used then Tk will support it. I'd be delighted for
someone to code PNG support as an extension to the photo image type, so
it's ready for inclusion into the core when PNG becomes popular."

And indeed, PNG became very popular. Then, back to 2003, same kind of
discussion in c.l.t.:

http://groups.google.fr/group/comp.lang.tcl/browse_thread/thread/1b9bc5fdda0a8b60/28e78ae744e7b0e5

which, BTW, leads to an interesting comment from Jeff Hobbs:

"Ah, zlib. This is something that should possibly be added to the
core for many other reasons. Other languages have zlib in their
cores, as it is useful for so many things. Even when you have to
track it. We could enable zlib-packed starkits in the core, simple
compression on sockets, etc, etc, etc. "

From then, TIP and reference implementation exist, for both zlib and
PNG support, but inclusion has not been considered.

So, my question wasn't really "how to work on adding extra features in
Tcl ?", but a way to revisit this other longstanding debate:

"Does Tcl need a richer set of core distributed functionality?"
http://groups.google.fr/group/comp.lang.tcl/browse_thread/thread/6248ffbdc6019e04/3223be0d92d3914a

and, more exactly, since Tcllib provides nowadays already much of what
can be written in pure Tcl, "Does Tcl need a richer set of core
elementary native functionalities?" (say, zlib, ipv6, udp, png).

Eric

[Donald G Porter]

Eric Hassold wrote:
>>> I'm kindly wondering if this doesn't reveal Tcl is lacking some focus
>>> on final users' usage and needs when prioritizing TIPs inclusions.

Donald G Porter wrote :

>> If a final user of Tcl has priorities that are not getting addressed
>> (and I'm sure that is the case), then get onto TCLCORE or into the
>> Tracker and start making noise about it. Be kind; it's rare that
>> something can be immediately completed, and long-languishing requests
>> often indicate that something is either hard or not believed to be a
>> good idea.

Eric Hassold wrote:
> Which one applies to this specific (i.e. gzip/zlib support) case ?

You raise a good and fair specific question. Allow me to temporarily dodge it.

This thread of articles did start on the specific topic of gzip/zlib.
But in your paragraph I quoted, you moved to a more general point
that something in the Tcl development process is broken to the extent
that it prioritizes improvements poorly. I responded to this more general
point only. Perhaps I should have changed the subject line then. I
have now.

I agree the work that gets done isn't a 100% match to some Platonic ideal
of the work that ought to get done.

It's even easier to agree that the work that gets done will not match up with
the priorities of any particular Tcl stakeholder drawn at random.

It's also a certainty that there are more proposals, even keeping only the
good ones, than I can possibly imagine getting done, so something worthwhile
is simply going to get left out. It can't be avoided.

In my work both as a Maintainer and on the TCT, I don't see any sense
of malicious intent to deny people things they want or need. I think
we're all trying to do a good job, choosing things to work on based on
a complex combination of what we think we're best suited to work on, what
we're interested in, how difficult something is, how entangled it is with
other improvements, as well as how beneficial the improvement is perceived
to be and how popular the demand for it is, with all of those matters
of judgment then further filtered through our available time and talents.

It's on the latter points that I think Tcl users at large have an ability
to influence matters. Your specific criticism was that we "lack focus on
final users' usage and needs," and I think the remedy is for us to be
confronted with those needs. Regular reminders that "you know, that TIP
really is important to me" do help. Also helpful are messages that "if
only I had the improvements in that TIP, I could do amazing things like
X and Y." You may think the merits of your own top priority improvements
are self-evident, and perhaps they are with focus and attention, but
focus and attention on several dozen proposals at once cannot be maintained.

I think it's best myself if the reminders are fairly narrowly targeted.
If a bug fix is important, but not getting done, a followup comment
on the Tracker report is best. If a TIP is languishing without an
apparent reason, contact either the author, or some TCT member who has
at some time expressed positive interest in the proposal, and nicely
inquire about why things aren't progressing. Absent such narrow channels,
a message to TCLCORE can be useful. Demanding an answer every day
or even every week is excessive, but a ping every few months should
prevent something getting lost.

I think such reminder messages can be especially powerful when other
possible blocking matters have already been cleared away. For example,
I think a targeted message "Hey maintainer, could you please review and
commit patch X?" is more likely to be the tipping point to action than
the broadcast "I'd sure like someone to invent an implementation for TIP N".
You get the idea.

Having said that, I was and am aware that my message could get
misinterpreted as instructions to "Shout louder and your demands will be
met!" That's what I was thinking when I added the caveats about
some proposals be hard or ill-advised. I didn't mean that as a
description of the gzip/zlib proposal.

I'll try to address your specific question in another followup soon.

[vit...@gmail.com]

> Having said that, I was and am aware that my message could get

> misinterpreted as instructions to "Shout LOUDER and your demands will be

> met!" That's what I was thinking when I added the caveats about
> some proposals be hard or ill-advised. I didn't mean that as a
> description of the gzip/zlib proposal.

Money speaks LOUDER than words --- perhaps this could be a better
route to go.
I propose establishing a fund (using PayPal, perhaps) for each
important addition/modification/creation to TCL core or one of it's
packages.
No matter how philanthropically inclined the TCT members or
contributors, they still have their personal lives to take care of and
many other (personal) priorities. Many of my personal projects take
years to finish where time-wise they should have taken month's or
weeks or even days to complete, all because I am swamped with other
priorities.

The people would vote for each project with dollars (one dollar, one
vote). The more votes the project gets the more priority it has, as
simple as that.

---Victor

[Donal K. Fellows]

Victor wrote:
> Money speaks LOUDER than words --- perhaps this could be a better
> route to go.

For some people, yes. Not everyone though. Case in point: If you want
to hire me, you'll have to go through my employer, and it'll probably
be horrendously expensive; I know them well. It's much simpler (and
cheaper!) to just persuade me that it's interesting. :-)

> The people would vote for each project with dollars (one dollar, one
> vote). The more votes the project gets the more priority it has, as
> simple as that.

No, one patch one vote. Those who actually produce some code get a big
say in what gets done. And not every improvement to Tcl/Tk needs C
skills to get done; off the top of my head, there's always making the
test suite better and more robust, the demos more jaw-dropping, or the
docs more informative.

I don't want people without spare cash to feel disenfranchised. Tcl is
not directed by a plutocracy!

Donal.

[vit...@gmail.com]

On Apr 8, 5:24 pm, "Donal K. Fellows" <donal.k.fell...@man.ac.uk>
wrote:

> Victor wrote:
> > Money speaks LOUDER than words --- perhaps this could be a better
> > route to go.
>
> For some people, yes. Not everyone though. Case in point: If you want
> to hire me, you'll have to go through my employer, and it'll probably
> be horrendously expensive; I know them well. It's much simpler (and
> cheaper!) to just persuade me that it's interesting. :-)

Well, lots of people do it as a personal contribution to others, but
the only
reason they do it because they CAN :)
Don't forget there are hungry people out there who would do that for a
reward.
Not everyone has the privilege, luxury, you name it, to be employed
and
make good money AND spend the free time on personal hobbies like
programming.

> > The people would vote for each project with dollars (one dollar, one
> > vote). The more votes the project gets the more priority it has, as
> > simple as that.
>
> No, one patch one vote. Those who actually produce some code get a big
> say in what gets done. And not every improvement to Tcl/Tk needs C
> skills to get done; off the top of my head, there's always making the
> test suite better and more robust, the demos more jaw-dropping, or the
> docs more informative.

There is the TCT team and there are the individual contributors.
TCT team might form a foundation similar to Mozilla
foundation and reward the individual contributors who sign up for a
specific project that has the PUBLIC funds behind it.
Forming a foundation is for the right people though. Mostly nobody
would want to do it, I suppose.

> I don't want people without spare cash to feel disenfranchised. Tcl is
> not directed by a plutocracy!

Let's scrap the idea of voting because it has the smell of politics.
Just have people donate to a specific project and if somebody agrees
to do it or does it, he will get paid. The donations are voluntary.
The work will be done faster.
Although, it would be better here if the individual contributors
solicited the donations themselves (donate link on their web site).
I have personally donated money to various projects, so I know it
works. It would probably require way too much effort to make this work
for a team of developers (politics, personal agenda, feelings will get
in the way).
Also, you would know that the project has real merit, interest,
excitement, appeal etc when people are willing to donate to it.

---Victor

[Torsten Berg]

On 8 Apr., 09:07, vit...@gmail.com wrote:

I have used the reference implementation that comes with TIP 234
(http://tip.tcl.tk/234) and it works nicely. If the API naming/
functionality is the only thing preventing this TIP from being voted
on/finished (as outlined in this thread elsewhere), this could indeed
be pushed with some postings to the TCL CORE mailing list.

[Torsten Berg]

> Money speaks LOUDER than words --- perhaps this could be a better
> route to go.
> I propose establishing a fund (using PayPal, perhaps) for each
> important addition/modification/creation to TCL core or one of it's
> packages.

I have indeed thought about this for the BLT extension. This is the
only extension holding me back from using Tcl 8.5 on a regular basis.
I just need the graphs from BLT, nothing else right now, but I didn't
succeed to extract this part because there are lots of dependencies
and my knowledge of C is too poor for that. There is a proposal for
Google Summer Code 2008 but I doubt it gets enough attention. My
thought was to offer some amount I can afford to get someone working
on this and then perhaps others chime in and add a little more. And
even if these amounts are ridiculously low compared to a real salary,
they may increase the motivation somewhere ...

Torsten

[Dennis LaBelle]

Torsten Berg wrote:

Yes, it sure would be nice if we got BLT into a condition where it was
relatively quick to update it for new releases of TCL/TK.

I've thought of tackling the project myself. I'm thinking that we just need
a "BLT leftovers" edition: A version containing only those features that
are not yet provided in the core. This would reduce some of the work.

I'm certain that some actual money could spur someone (perhaps myself) to
finally work on such a project.

Dennis LaBelle

[pwe...@zonnet.nl]

If you're looking for BLT (and on windows), try
http://reddog.s35.xrea.com/wiki/A%20Stub-enabled%20BLT2.4z%20for%20Windows.html.
Although I haven't tried it extensively, it seems to work with the
latest version of etcl, it just complains about an invalid command
"Blt_Zoomstack", but the graps of the demo are drawn.

Peter

Torsten Berg schreef:

[Torsten Berg]

On Apr 10, 8:32 am, pwel...@zonnet.nl wrote:
> If you're looking for BLT (and on windows), tryhttp://reddog.s35.xrea.com/wiki/A%20Stub-enabled%20BLT2.4z%20for%20Wi....

> Although I haven't tried it extensively, it seems to work with the
> latest version of etcl, it just complains about an invalid command
> "Blt_Zoomstack", but the graps of the demo are drawn.

Yes, I know that patch and it will surely serve as a basis for further
work. But, alas, I use a Mac now and although BLT is running using X11
there, there is no Aqua port.

The BLT_ZoomStack command is written in pure Tcl, so there is no
problem getting that one in.

Dennis LaBelle wrote:
> I've thought of tackling the project myself. I'm thinking that we just need
> a "BLT leftovers" edition: A version containing only those features that
> are not yet provided in the core. This would reduce some of the work.

Right. Looking at the current 3.0 development of BLT in SF cvs, there
are even more widgets which, at first glance, seem to duplicate some
effort that is already done elsewhere. What are the leftovers? Only
graph, barchart, vector, and perhaps spline. What would be needed for
a portable BLT? Perhaps only making it stubs-enabled and getting rid
of the inherent X-calls (just by enhancing the X emulation layer with
the missing functions??) so it will run under Aqua also? It does not
seem to be too much work, but I am not the one who can tell.

>
> I'm certain that some actual money could spur someone (perhaps myself) to
> finally work on such a project.

All right. This sounds promising. Let me think a little about this. A
fund may really be the best way forward. At least I get the
impression, if no-one starts a project/fund for this issue, it will
likely not get done. But who knows. Maybe the Google Summer of Code
2008 will tackle this.

Who out there, likes the idea of a fund for BLT overhaul? What does
the author of BLT say??

Torsten

[Torsten Berg]

OK, let's at least wait until April 21, when a decision has been made
for Goggle Summer of Code. Then we know, if BLT made it and we need
action at all.

To repeat my question: Who else needs/uses BLT and want's it for Tcl/
Tk 8.5. Who else want's a port to Aqua?

Torsten

[Tim Wallace]

We need it, we use it, and we will need it for 8.5, but really just the
vectors and graphs. We had some difficulty way back when we moved to
8.4 with the then-available BLT. We ended up going with a CVS snapshot
from a few years ago, slightly tweaked and bug fixed. Since then people
have patched 2.4z, but we're still using our "3.0" successfully. Later
CVS snapshots haven't compiled successfully, although more recent ones
look better. We'll probably just port our "3.0" source to 8.5, but we'd
certainly like an official release of this working with 8.5! We're
not as interested in a port of 2.4z, since a few graph things work
differently. Aqua we don't do now but you never know about the future.

--Tim

[Daniel Sidobre]

Torsten Berg <be...@typoscriptics.de> writes:
>
> To repeat my question: Who else needs/uses BLT and want's it for Tcl/
> Tk 8.5. Who else want's a port to Aqua?
>
> Torsten

I'm also interested in BLT graph for Tcl/Tk 8.5.

Daniel.

[Larry W. Virden]

On Apr 9, 6:26 pm, Dennis LaBelle <label...@nycap.rr.com> wrote:
>
> Yes, it sure would be nice if we got BLT into a condition where it was
> relatively quick to update it for new releases of TCL/TK.
>

Please remember, however, that BLT continues to be owned by its
creator. I would hope that communication with the owner would occur,
and concensus can be reached regarding forking the code or some other
action. I believe there has been at least one case in Tcl history
where an extension languished, a fork occurred, and the owner had
concerns about the resulting situation. Perhaps if a fork is
necessary, people could change the extension name, etc. just to
prevent future confusion.

[Uwe Klein]

George Howlett seems to be busy on a regular basis moving changes
into the SourceForge cvs ( it still does not build, but there seem
to be only 1/2 files missing now ).

Perhaps asking him if assistance would be of help?

uwe

[Torsten Berg]

Larry W. Virden wrote:
> Please remember, however, that BLT continues to be owned by its
> creator. I would hope that communication with the owner would occur,
> and concensus can be reached regarding forking the code or some other
> action. I believe there has been at least one case in Tcl history
> where an extension languished, a fork occurred, and the owner had
> concerns about the resulting situation. Perhaps if a fork is
> necessary, people could change the extension name, etc. just to
> prevent future confusion.

You are right. If we really have a stab at this, I would love to hear
from George Howlett first. And, all though not strictly needed judging
from the license, I would like to get his permission to do what we
want. We absolutely also need to change the name of the extension,
because the outcome will not be BLT any more, it will be a subset of
BLT. BLTlite is already taken, that would have been a good candidate.

On 12 Apr., 09:46, Uwe Klein <uwe_klein_habertw...@t-online.de> wrote:
> George Howlett seems to be busy on a regular basis moving changes
> into the SourceForge cvs ( it still does not build, but there seem
> to be only 1/2 files missing now ).
>
> Perhaps asking him if assistance would be of help?

George Howlett is quite regularly updating the cvs and this is one of
the reasons we should contact him, before we really start something.
It would of course be best, if we got a BLT 3.0 soon that meets all
needs, but I will not urge George to speed up. That would be unfair at
least. But it would be nice to hear about his plans.

Torsten

[MH]

In article <8da99781-c8f1-4b87...@s50g2000hsb.googlegroups.com>,

If my start-up succeeds/continues, we'll probably move to Tcl 8.5 at some
point, and then we'll need/want BLT for 8.5.

So, it's not a definite yes, but, we're hopeful :-)

MH

[Torsten Berg]

> >OK, let's at least wait until April 21, when a decision has been made
> >for Goggle Summer of Code. Then we know, if BLT made it and we need
> >action at all.

All right then. BLT did not make it. So, here we are, step 2 then. In
the next week I will try to contact George Howlett, the author of BLT,
and see what information I can get and what he thinks about the plan
outlined in this thread.

Stay tuned!

Torsten

[Bob Techentin]

On Apr 24, 3:50 pm, Torsten Berg <b...@typoscriptics.de> wrote:
> All right then.BLTdid not make it. So, here we are, step 2 then. In

> the next week I will try to contact George Howlett, the author ofBLT,
> and see what information I can get and what he thinks about the plan
> outlined in this thread.

Any word yet, Torsten? I'm really interested in BLT vector/graph for
Tcl 8.5 too. I wrote the Google Summer of Code project description.
I'm about to pitch it as a possible project to some senior college
undergraduates.

I tried to contact George Howlett several months ago through the
sourceforge email, but got not response. I hope you're having better
luck.

Bob Techentin

[EKB]

I use graph heavily (one very nice feature is bar charts with
numerical x-axis labels -- BLT places the bars at the proper x-axis
location).

I also use the "busy" feature. This is really handy, being able to put
a "busy" cursor over the entire app at once and suspending input. Is
there anything else equivalent to this?

Eric

[Torsten Berg]

> Any word yet, Torsten?  I'm really interested in BLT vector/graph for
> Tcl 8.5 too.  I wrote the Google Summer of Code project description.
> I'm about to pitch it as a possible project to some senior college
> undergraduates.

This sounds promising!

> I tried to contact George Howlett several months ago through the
> sourceforge email, but got not response.  I hope you're having better
> luck.

Only now I found the time to write him. I sent the mail to all
addresses of him I could find, including the sf account. Let's see
then.

Torsten

[Torsten Berg]

> If my start-up succeeds/continues, we'll probably move to Tcl 8.5 at some
> point, and then we'll need/want BLT for 8.5.
>
> So, it's not a definite yes, but, we're hopeful :-)

Good luck for you on that road!

While learning a bit more about BLT inner workings, it appears to me,
we also need the bitmap command. The functions for bitmap are needed
to make axis labels that are composed of rotated text (vertical text
for the y-axis).

And what about TIP 69 (http://tip.tcl.tk/69)? These improvements on
the hash table are like the custom hash table used by BLT, so could it
ease updating BLT to have this TIP discussed in the TCT??

Torsten

[Alexandre Ferrieux]

On May 6, 8:11 am, Torsten Berg <b...@typoscriptics.de> wrote:
>
> And what about TIP 69 (http://tip.tcl.tk/69)?These improvements on

> the hash table are like the custom hash table used by BLT, so could it
> ease updating BLT to have this TIP discussed in the TCT??

Can you give details on which of these improvements you're after
exactly ?
Indeed, part of them may already be covered by the lighter-weight
hashtable glue in Dicts.
Donal, shouldn't the TIP be updated at least to show only what's left
to be done ?

-Alex

[Donal K. Fellows]

Torsten Berg wrote:
> While learning a bit more about BLT inner workings, it appears to me,
> we also need the bitmap command. The functions for bitmap are needed
> to make axis labels that are composed of rotated text (vertical text
> for the y-axis).

Actually, you need real rotated text (text isn't just monochrome any
more) and you *might* need more options for bitmap images. But you don't
need BLT's notion of bitmaps; there are some real nasties lurking in the
depths there (e.g. how to deallocate them properly).

> And what about TIP 69 (http://tip.tcl.tk/69)? These improvements on
> the hash table are like the custom hash table used by BLT, so could it
> ease updating BLT to have this TIP discussed in the TCT??

Those proposals got shelved for the rest of the 8.* series because they
were incompatible with existing binary extensions. But if someone wants
to re-evaluate them in the light of 7 years more Tcling, please do! (I
doubt I'll have time in the near future...)

Donal.

[Donal K. Fellows]

Alexandre Ferrieux wrote:
> Donal, shouldn't the TIP be updated at least to show only what's left
> to be done ?

Quite possibly. Feel free to do so.

Donal.

[Alexandre Ferrieux]

On May 6, 3:51 pm, "Donal K. Fellows"

:-}

I was indirectly asking you "what's left to be done" as I believe
you're in a position to know better than I do, thinking about Dicts
among other things...

-Alex

[Torsten Berg]

On 6 Mai, 08:43, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
wrote:

> Can you give details on which of these improvements you're after
> exactly ?
> Indeed, part of them may already be covered by the lighter-weight
> hashtable glue in Dicts.

Well, BLT defines an in-memory hash table that is build upon the Tcl
hash table (as it were back in perhaps 2002 or 2004). The source file
(bltHash.c) states, that it adds pool allocation 64-bit address
handling and an improved array hash function.

TIP 69 (written by the BLT author back in 2001) wants to do all this
(and perhaps more?). Now, if this can be achieved with the
implementation used by BLT and brings some advantages to Tcl, why not
promote this TIP?

bltHash.c is one of the BLT source files that includes tclInt.h which
could thus be avoided here. Alas, I do not know C well enough to say
something about the effort needed here and if the comments by dgp in
TIP 69 mean, there is actually nothing to do (i.e. the TIP is
superfluous).

Torsten

[Pat Thoyts]

Torsten Berg <be...@typoscriptics.de> writes:

Go for it! TIPs need to be driven by someone with an interest in the
change. Its not enough to just write the TIP - you have to push it
along. Or someone does. If no-one pushes it then it will languish
forever.

--
Pat Thoyts http://www.patthoyts.tk/
To reply, rot13 the return address or read the X-Address header.
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD

[tom.rmadilo]

On Apr 8, 7:45 am, schlenk <schl...@uni-oldenburg.de> wrote:
> vit...@gmail.com wrote:
> > Thanks for your replies.
>
> > This is so weird. There are all kinds of encryption/encoding packages
> > included with ActiveTcl by default but no STANDALONE zlib/gzip/bzip2/
> > lzw packages. You have to go through all kinds of dancing to find them
> > and make them work. (I am talking about C coded binary packages, not
> > pure TCL, which would be too slow, and they need to work on data
> > streams, not just files)
>
> Its only partially weird. There was a TIP in the Tcl 8.5 timeline to
> bundle a zlib extension with the core, but people were unsure about
> the right API to do it and the person doing it got distracted by other
> stuff so it wasn't finished.
>
> The zlib TIP should be revived for the 8.6 series..., but needs
> someone to push it.

I haven't looked at the TIP, but something like gzip is not really
part of a programming language. You could have a package which does
compression of files or 'buffers', but this has nothing to do with the
Tcl language.

As an example of buffer to Tcl_DString compression you can look at:

http://rmadilo.com/files/nszlib/nszlib/nszlib.c

The function ZlibGzip does in memory compression. File compression is
best left to an [exec] call to the local shell command.

[Darren New]

tom.rmadilo wrote:
> I haven't looked at the TIP, but something like gzip is not really
> part of a programming language.

Neither is recursing through directory listings. But it's the sort of
thing lots of people need to do.

--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."

[USCode]

Darren New wrote:
> tom.rmadilo wrote:
>> I haven't looked at the TIP, but something like gzip is not really
>> part of a programming language.
>
> Neither is recursing through directory listings. But it's the sort of
> thing lots of people need to do.
>

I have to respectfully disagree. The concepts of directories, files,
etc. are a pretty universal thing to operating systems. However, there
are TONS of file compression schemes out there and supporting them
sounds like a perfect example of what should be extensions.

[Donal K. Fellows]

USCode wrote:
> I have to respectfully disagree.  The concepts of directories, files,
> etc. are a pretty universal thing to operating systems.  However, there
> are TONS of file compression schemes out there and supporting them
> sounds like a perfect example of what should be extensions.

Including gzip/zip support is not about satisfying everyone's
compression needs. It's about seeding the space (and demonstrating
best-practices to other compression providers) so that people can get
started with something that's good enough for most purposes without
having to start searching all over. Plus, we really ought to have some
built in way of making and working with packaged filesystems so that
rich Tcl Modules aren't restricted to people using ActiveTcl (despite
that being very good).

Donal.

[Donal K. Fellows]

Pat Thoyts wrote:
> Go for it! TIPs need to be driven by someone with an interest in the
> change. Its not enough to just write the TIP - you have to push it
> along. Or someone does. If no-one pushes it then it will languish
> forever.

Most particularly, someone needs to commit to doing the
implementation. Following bad experiences, we won't vote on stuff that
isn't yet implemented (unless the change is genuinely trivial, and in
that case it's probably just sitting in someone's sandbox). If you can
write the TIP (about as hard as writing a Wiki page that says what you
want to do and why) and get the patch ready, the rest of the process
shouldn't be a problem.

Donal.

[Torsten Berg]

> Most particularly, someone needs to commit to doing the
> implementation. Following bad experiences, we won't vote on stuff that
> isn't yet implemented (unless the change is genuinely trivial, and in
> that case it's probably just sitting in someone's sandbox). If you can
> write the TIP (about as hard as writing a Wiki page that says what you
> want to do and why) and get the patch ready, the rest of the process
> shouldn't be a problem.

Well, I didn't write the TIP. But I had now a closer look at it. At
least the part "Better Memory Performance" cannot be done before Tcl9,
because it would mean a change in the public Tcl API, specifically
changing Tcl_DeleteHashEntry(entryPtr) to
Tcl_DeleteHashEntry(tablePtr,entryPtr). The change itself is easy
enough (even I could do it with my limited Tcl core knowldge) but it
would mean an incompatibility. Nevertheless, I think it is something
to definitely keep in mind doing for Tcl9.

The "Improved Array/Structure Hashing" part seems to be implemented in
BLT and even some MIX64 thing This could easily be transferred to Tcl.
Bob Jenkins has newer infos at
http://www.burtleburtle.net/bob/hash/doobs.html which are worth a
look. It seems to me, this is not too much work either.

The rest of the TIP seems to have been done somehow already at first
glance, but I'm not the one to finally assess this. I'd love to help
out, but lack of time and resources won't let me do much. But I can
hold up a banner saying "Adopt a TIP!" and hope someone else to go
tingly all over and start coding.

Torsten

[Darren New]

USCode wrote:
> Darren New wrote:
>> tom.rmadilo wrote:
>>> I haven't looked at the TIP, but something like gzip is not really
>>> part of a programming language.
>>
>> Neither is recursing through directory listings. But it's the sort of
>> thing lots of people need to do.
>>
> I have to respectfully disagree. The concepts of directories, files,
> etc. are a pretty universal thing to operating systems.

The ones based on UNIX, at least. Not most of the others.

Given that we already have encoding in the core, and given that we have
sockets in the core, and given that sockets default to following
internet standards (i.e., they default to CRLF line endings), and given
that internet standards published in the last 15 years or so all use
base64 any time they need encoding, it would seem to make sense to put
base64 in the core, especially as how it's about 10 lines of C code that
really benefits speed-wise from being in C.

gzip you could argue about, I'll grant.

[USCode]

Darren New wrote:
>
> Given that we already have encoding in the core, and given that we have
> sockets in the core, and given that sockets default to following
> internet standards (i.e., they default to CRLF line endings), and given
> that internet standards published in the last 15 years or so all use
> base64 any time they need encoding, it would seem to make sense to put
> base64 in the core, especially as how it's about 10 lines of C code that
> really benefits speed-wise from being in C.
>

It could also be in tcllibc and benefit speed-wise.

Couldn't we apply the same above logic to other things as well such as
XML parsing, generating HTML, etc. Would we someday then want to add
those to the core? I hope not.

[EL]

vit...@gmail.com schrieb:

> [donate for TIPs]

I like this idea a lot! Maybe I would actually be on both sides, but
probably at least on the donator side. And the first TIP that I'd donate
for was lexical scoping... or integrated debugging ;-)

--
Eckhard

[Donal K. Fellows]

USCode wrote:
> Couldn't we apply the same above logic to other things as well such as
> XML parsing, generating HTML, etc. Would we someday then want to add
> those to the core? I hope not.

It benefits the core http package, which isn't dependent on any part
of tcllib.

Donal.

[Torsten Berg]

> I tried to contact George Howlett several months ago through the
> sourceforge email, but got not response.  I hope you're having better
> luck.

Unfortunately, I have not heard from George until now. I tried all
kind of old and new email addresses, and had only luck with the email
address mentioned in the 3.0 sources. All other addresses were
unresponsive (mail returnning or failing, also the sf account). But no
answer from George yet. I'll wait a little more then or does anyone
here know an address, he is actually checking?

Torsten?

[Torsten Berg]

On 12 Mai, 22:34, Torsten Berg <b...@typoscriptics.de> wrote:
> > I tried to contact George Howlett several months ago through the
> > sourceforge email, but got not response.  I hope you're having better
> > luck.
>
> Unfortunately, I have not heard from George until now. I tried all
> kind of old and new email addresses, and had only luck with the email
> address mentioned in the 3.0 sources. All other addresses were
> unresponsive (mail returnning or failing, also the sf account).

All right. Still no answer. So I must assume, he does not want to
answer for whatever reason. George is actively working on BLT though,
the cvs shows activity all the time. Unfortunately, the cvs version
still does not compile.

So, question to the audience. What should we do at this point?

Torsten

[EL]

Torsten Berg schrieb:

>> Unfortunately, I have not heard from George until now. I tried all
>> kind of old and new email addresses, and had only luck with the email
>> address mentioned in the 3.0 sources. All other addresses were
>> unresponsive (mail returnning or failing, also the sf account).
>
> All right. Still no answer. So I must assume, he does not want to
> answer for whatever reason.

Maybe he has a "good" spam filter :-)?

> George is actively working on BLT though,
> the cvs shows activity all the time. Unfortunately, the cvs version
> still does not compile.
>
> So, question to the audience. What should we do at this point?

Tried to reach him over the mailing list or sourceforge tracker / forum?

--
Eckhard

[Larry W. Virden]

On Jun 2, 6:05 am, Torsten Berg <b...@typoscriptics.de> wrote:
> So, question to the audience. What should we do at this point?

What is it you want to accomplish? Would it be better, rather than
struggle over the BLT code, to just begin a new project, gather
requirements, write some new code to do what you want, and know that
the licensing, maintenance, compatibility, etc. meets your
requirements?

[Torsten Berg]

> Tried to reach him over the mailing list or sourceforge tracker / forum?

Hm. No. I tried ony the sf email account, not the tracker. So here we
go:

https://sourceforge.net/tracker/index.php?func=detail&aid=1982659&group_id=18616&atid=218616

Torsten

[Torsten Berg]

> What is it you want to accomplish?

Essentially, what is stated for the GSoC at http://wiki.tcl.tk/20832
under "BLT Vector / Graph Refactor" about 2/3 down the page.

> Would it be better, rather than
> struggle over the BLT code, to just begin a new project, gather
> requirements, write some new code to do what you want, and know that
> the licensing, maintenance, compatibility, etc. meets your
> requirements?

Hm, no. The BLT license is ok and the code meets my requirements. BLT
is great (apart from having no Aqua support). The only thing missing
is an update to the current Tk version 8.5.
I see no need to reinvent the wheel that has been running so well for
many years now. I would like a solution, that can be achieved in a
short time, not a new project, that has to mature over (perhaps)
years.

That said, I see the advantage of starting all over. But I doubt, the
reources are there.

Torsten

[Dennis LaBelle]

Torsten Berg wrote:

At this point, I consider support for BLT to be at best unreliable and at
worst non-existent. For any part of BLT to survive, we need more than a
programmer who won't talk to anyone.

We need to develop some requirements, determine whether the current BLT code
is a good starting point, decide on a software support model, etc.

Dennis

[Uwe Klein]

Working by committee are we?

You will need battalions of slaves to reproduce all worthy parts of blt.

uwe
who never has quite understood the big disconnect between tcl-main and
george howlett('s blt).
http://wiki.tcl.tk/274
would this require a feast of eating crow?

>
> Dennis
uwe

[Dennis LaBelle]

Uwe Klein wrote:

I'm most interested in vectors and the graph widgets. I'd rather have those
things working with TCL/TK 8.5 and well supported instead of the level of
BLT support we have had in the last few years.

We may not need a battalion of slaves for that level of effort.

Dennis

[Uwe Klein]

Dennis LaBelle wrote:

> I'm most interested in vectors and the graph widgets. I'd rather have those
> things working with TCL/TK 8.5 and well supported instead of the level of
> BLT support we have had in the last few years.
>
> We may not need a battalion of slaves for that level of effort.

With George Howletts ongoing ( but a bit in the walls ) effort to bring blt
up to 8.5 ( and blt 3.0 ) I'd put more effort into getting
George Howlett back "into the fold" than ripping out parts of
blt that will have to be maintained as an extra effort.
( And imho it's just plain impolite )

Isn't there anybody around who has a working comm path?

uwe

[Jeff Hobbs]

On Jun 4, 12:27 am, Uwe Klein <uwe_klein_habertw...@t-online.de>
wrote:

More time has been spent trying to get George back "into the fold"
than would be required to update BLT. Nobody is being impolite -
indeed, you are being naive to not accept maybe he'd prefer to be left
alone.

> Isn't there anybody around who has a working comm path?

People have been trying for years. Stop fighting that battle and move
on.

Jeff

[EL]

Dennis LaBelle schrieb:

> I'm most interested in vectors and the graph widgets. I'd rather have those
> things working with TCL/TK 8.5 and well supported

If that helps, I have put up some code a long time ago to have a 2D plot
widget inside a Tk canvas. It works with Tcl lists, so there is no extra
"vector" type necessary.
There is no official download, since I never got it finished and
polished for a release. But if you are interested, you can check it out
from SVN at the Tloona project page:
http://tloona.svn.sourceforge.net/viewvc/tloona/canvasplot/trunk/

As you see it is called "canvasplot". A working example is my small
1-day home hacking effort "stocky", which can also be downloaded from
the Tloona page:
https://sourceforge.net/project/showfiles.php?group_id=190798&package_id=225784
It fetches stock quotes from yahoo and displays an intraday chart
(nothing more).

Currently there are only line plots supported, but it would well be
possible to have other plot types too. Canvasplot could even be turned
into a fully fledged 2D graphing library with some effort (there is even
code to turn the plots into postscript). I was planning to do so a few
years ago, but never found the time.
The extension is based on code from another extension called "tkgraph",
which I found elsewhere before. Tkgraph was not working on windows and
was also not supported anymore, so I took it and made it work for me.

--
Eckhard

[EL]

EL schrieb:

> As you see it is called "canvasplot". A working example is my small
> 1-day home hacking effort "stocky", which can also be downloaded from
> the Tloona page:

Ah, don't rely on stocky.kit to be executable with a Tclkit. I don't
know if that works. It's better to unwrap it and look at the source code
/ try to start it with ActiveTcl or so...

--
Eckhard

[Uwe Klein]

EL wrote:
> Dennis LaBelle schrieb:
>
>> I'm most interested in vectors and the graph widgets. I'd rather have
>> those
>> things working with TCL/TK 8.5 and well supported
>
>
> If that helps, I have put up some code a long time ago to have a 2D plot
> widget inside a Tk canvas. It works with Tcl lists, so there is no extra
> "vector" type necessary.

The interesting thing with blt vector/graph is that it has
excelent abstraction lots of functionality
( vector expr is absolutely great see :
http://wiki.tcl.tk/15000 Example 3
) is very fast, provides live update,
has good scalability and a usefull c representation.

The vector type is not superfluous.

uwe

[EL]

Uwe Klein schrieb:

> The vector type is not superfluous.

Certainly not, if you need it. But there are cases where simple plotting
of values in a list is enough.
Your example could be well handled with [expr]. But when it comes to
more complicated numeric computation problems (ODE solving, statistics,
plotting, optimization etc.) I would use MATLAB. And evtl. the Tclmatlab
binding. This environment provides a lot more than a vector type...

--
Eckhard

[Gerald W. Lester]

The vector type was added to BLT, and is still required, for real time
"strip chart" type plotting of data. I.e. the set of data grows as the
application continues to run (think of a plot of the outside temp. that
updates every 5 minutes).

--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

[Uwe Klein]

EL wrote:
> Uwe Klein schrieb:
>
>> The vector type is not superfluous.
>
>
> Certainly not, if you need it. But there are cases where simple plotting
> of values in a list is enough.
> Your example could be well handled with [expr]. But when it comes to

expr won't do math on a 100++k array in reasonable time.
forget it.

uwe

[EL]

Uwe Klein schrieb:

> expr won't do math on a 100++k array in reasonable time.
> forget it.

But MATLAB will ;-). Anyway, you have the choice...

--
Eckhard

[Joe English]

Gerald W. Lester wrote:

> The vector type was added to BLT, and is still required, for real time
> "strip chart" type plotting of data. I.e. the set of data grows as the
> application continues to run (think of a plot of the outside temp. that
> updates every 5 minutes).

FWIW, I've been able to do realtime stripcharts -- with
up to ~10 plots, ~300 points per plot, updating at 5 Hz --
using the Tk canvas widget and plain old Tcl lists of doubles.

It took some tuning to get reasonable performance out of it,
but on modern hardware it runs just fine with plenty
of CPU to spare (including the process that's generating
the data).

So BLT vectors aren't *absolutely* necessary for this sort
of thing nowadays (although they probably still make it easier.)

--JE

[Uwe Klein]

Why should I move away from a working setup?
And why should I insert MATLAB warts into it?

OK i once added gnuplot warts ( using bgexec from blt ;-)
to have easy parameter fitting for large datasets.

>
uwe

[EL]

Uwe Klein schrieb:

>> But MATLAB will ;-). Anyway, you have the choice...
>>
> Why should I move away from a working setup?
> And why should I insert MATLAB warts into it?

MATLAB is not a wart ;-).
But to answer the question: It depends. I prefer to use the right tool
for a given task. And if the task is number crunching, parameter
fitting, visualization etc., then MATLAB is the right tool. Since it can
be integrated in Tcl, I can use both in conjunction.
So my choice would be to write and maintain the number crunching code in
MATLAB and integrate it in my Tcl application, depending on the overall
requirements.

Said that, it would even be possible to provide a stubs library from
canvasplot and extend Tclmatlab to plot mexArrays (the MATLAB data type)
directly from C on a Tk canvas...

--
Eckhard

[EL]

Joe English schrieb:

> FWIW, I've been able to do realtime stripcharts -- with
> up to ~10 plots, ~300 points per plot, updating at 5 Hz --
> using the Tk canvas widget and plain old Tcl lists of doubles.
>
> It took some tuning to get reasonable performance out of it,
> but on modern hardware it runs just fine with plenty
> of CPU to spare (including the process that's generating
> the data).
>
> So BLT vectors aren't *absolutely* necessary for this sort
> of thing nowadays (although they probably still make it easier.)

Right.
I used canvasplot to draw between 600k..1000k datapoints on a Tk canvas,
with pure Tcl lists, and also frequent updates of the canvas. That was
running in reasonably fast time and with state of the art hardware from
4-5 years ago.
The bottleneck was to import this data from CSV files. It was necessary
to do this in C directly, not over [read] or [gets].

--
Eckhard

[Torsten Berg]

On 4 Jun., 20:49, Jeff Hobbs <jeff.ho...@gmail.com> wrote:
> Stop fighting that battle and move on.

On the track now.

I had a closer look at BLT and startd with the [vector] command. I was
able to extract a working version with the basic functionality (not
all subcommands yet, just append, clear, delete, length). What did I
change?

- replaced BLT's hash package with Tcl's (loosing a bit memory, and
perhaps 64 bit support -> see also TIP 69)
- converted most code from Tcl's string interface to the Tcl_Obj
interface (where applicalble)
- replaced BLT's alloc package with Tcl's ckalloc and ckfree
- tried to get rid of BLT's copies of Tcl internals, instead
#included tclInt.h

The last point is quite unsatisfying. Why does the vector need Tcl's
internals? The vector package creates new Tcl commands and does this
in namespaces also. At first sight, it seems the public Tcl API does
not provide enough functionality to handle all aspects of this.
Specifically, BLT needs to parse fully qualified names, split the
namespace part from the name part, change the call frame (enter and
leave different namespaces) and such. For this purpose, it uses
Tcl_PushCallFrame, Tcl_PopCallFrame, the Tcl_CallFrame and the Command
structure, all of these are only defined via the internal headers. It
also uses Tcl_FindNamespace which is at least public in Tcl 8.5 now. I
haven't fully analysed what's going on, but cannot at the moment see a
path to avoid the internal functions.

In general, there is quite possibly some more potential to use Tcl API
functions where there are BLT functions now, mostly in parsing command
options.

Why did I do this?

- it was fun
- learnt a lot about Tcl's C API and how it works
- improved my own C knowledge
- learnt a lot about BLT's anatomy

All this is a first step towards lifting the (much larger) graph
package.

Torsten

[rene]

> - replaced BLT's hash package with Tcl's (loosing a bit memory, and
> perhaps 64 bit support -> see also TIP 69)
> - converted most code from Tcl's string interface to the Tcl_Obj
> interface (where applicalble)
> - replaced BLT's alloc package with Tcl's ckalloc and ckfree
> - tried to get rid of BLT's copies of Tcl internals, instead
> #included tclInt.h
>

...

> In general, there is quite possibly some more potential to use Tcl API
> functions where there are BLT functions now, mostly in parsing command
> options.

If you get so far what about TIPing the vector and even better the
graph widget in the core?
The 'tclInt.h is then no more a problem :) The commands should work
with the same syntax on
the script level.

Let me know if you need some help here.

rene

[Donal K. Fellows]

rene wrote:
> If you get so far what about TIPing the vector and even better the
> graph widget in the core?

If you're doing this, vector adds to Tcl and graph adds to Tk. ;-)

Donal.

[USCode]

rene wrote:
> If you get so far what about TIPing the vector and even better the
> graph widget in the core?
>

We don't really want a graph widget in the core, do we? I can see
improving the canvas with text rotation, etc. but an actual graph widget
in the core itself seems inappropriate?

[Uwe Klein]

why?
( I can't remember writing a GUI app that did not
have a blt_graph incorporated)
snack implements a graph item for the canvas.
can it be life linked to a vector ( or similar ).
Afaik currently it creates just a static waveform.

uwe

[USCode]

Uwe Klein wrote:
>
> why?
> ( I can't remember writing a GUI app that did not
> have a blt_graph incorporated)
> snack implements a graph item for the canvas.
> can it be life linked to a vector ( or similar ).
> Afaik currently it creates just a static waveform.
>
> uwe

I'm not sure of the relevance of Snack here, it isn't part of the core
(Tk in this case)? The core should be kept lean and mean and only
provide building blocks. Something like a graph that has a million
different styles/variations, etc. should, IMHO, be kept in a separate
package ... like "Plotchart" in TkLib.

[Donald G Porter]

USCode wrote:
> I'm not sure of the relevance of Snack here, it isn't part of the core
> (Tk in this case)? The core should be kept lean and mean and only
> provide building blocks.

No.

You're not talking about "the core" [*]. You're talking about Tk.

There was once a respectable case to be made that Tk ought to be
incomplete. That it ought to offer only primitives on top of which
someone could build a complete GUI library. Much of the design still
reflects that outdated perspective. But that perspective is outdated.
People expect GUI libraries to provide the complete toolset needed to
create GUIs. Tk must at least aim in that direction.

[*] Term is beyond meaningless. Stop using it. It always adds
more confusion than clarity. Always.

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

[USCode]

Donald G Porter wrote:
> USCode wrote:
>> I'm not sure of the relevance of Snack here, it isn't part of the core
>> (Tk in this case)? The core should be kept lean and mean and only
>> provide building blocks.
>
> No.
>
> You're not talking about "the core" [*]. You're talking about Tk.
>
> There was once a respectable case to be made that Tk ought to be
> incomplete. That it ought to offer only primitives on top of which
> someone could build a complete GUI library. Much of the design still
> reflects that outdated perspective. But that perspective is outdated.
> People expect GUI libraries to provide the complete toolset needed to
> create GUIs. Tk must at least aim in that direction.
>
> [*] Term is beyond meaningless. Stop using it. It always adds
> more confusion than clarity. Always.
>

Ok, so there is no more "the core", there is no long-term need to keep
"the set of libraries formerly know as the core" lean and mean and the
BLT graph widget is needed to provide a complete toolset to create a
GUI. Gotcha, won't happen again. Ever.

[Torsten Berg]

On 19 Jun., 21:00, Donald G Porter <d...@nist.gov> wrote:
> USCode wrote:
> > I'm not sure of the relevance of Snack here, it isn't part of the core
> > (Tk in this case)?  The core should be kept lean and mean and only
> > provide building blocks.
>
> No.
>
> You're not talking about "the core" [*].  You're talking about Tk.
>
> There was once a respectable case to be made that Tk ought to be
> incomplete.  That it ought to offer only primitives on top of which
> someone could build a complete GUI library.  Much of the design still
> reflects that outdated perspective.  But that perspective is outdated.
> People expect GUI libraries to provide the complete toolset needed to
> create GUIs.  Tk must at least aim in that direction.

Hm, I never thought about it that way. Well then, let's see. However,
even under this assumption, the code of BLT needs some reworking. The
work is not yet done.

Torsten

[Torsten Berg]

>  - replaced BLT's hash package with Tcl's (loosing a bit memory, and
> perhaps 64 bit support -> see also TIP 69)
>  - converted most code from Tcl's string interface to the Tcl_Obj
> interface (where applicalble)
>  - replaced BLT's alloc package with Tcl's ckalloc and ckfree
>  - tried to get rid of BLT's copies of Tcl internals, instead
> #included tclInt.h
>
> The last point is quite unsatisfying. Why does the vector need Tcl's
> internals? The vector package creates new Tcl commands and does this
> in namespaces also. At first sight, it seems the public Tcl API does
> not provide enough functionality to handle all aspects of this.
> Specifically, BLT needs to parse fully qualified names, split the
> namespace part from the name part, change the call frame (enter and
> leave different namespaces) and such. For this purpose, it uses
> Tcl_PushCallFrame, Tcl_PopCallFrame, the Tcl_CallFrame and the Command
> structure, all of these are only defined via the internal headers. It
> also uses Tcl_FindNamespace which is at least public in Tcl 8.5 now. I
> haven't fully analysed what's going on, but cannot at the moment see a
> path to avoid the internal functions.

Just an update to this. My prototype package is now stubs-enabled and
I was able to get closer on the tclInt.h issue. BLT uses
Tcl_PushCallFrame and Tcl_PopCallFrame as mentioned. It does this
solely because it wants to be compatible with [incr Tcl] 2.x (which
does not like qualifiers in variable names) so this seems a non-issue
after all. If I am interpreting the Tcl Library docs correctly, you
can just pass a qualified (namespaced) name to functions like
Tcl_UntraceVar2, Tcl_SetVar2, and other functions requiring the name
of e.g. a variable name. Is this true?? I think it is. Then, we can
just omit all occurrences of Blt_EnterNamespace and Blt_LeaveNamespace
and stay clean from any usage of tclInt.h so far. Let's see if this is
still true, when I get the time to look at the rest of the code. But
for now, it does work.

Torsten

[Tim Wallace]

Hi Torsten--

This is a very interesting effort. I assume you're using the BLT 2.4z
source to start? We're using a CVS source from a couple of years later
which has a couple of graph improvements. We just tweak it for new tcl
releases, and 8.5 doesn't look like a show-stopper for us. But those
graph issues could probably be retrofitted into 2.4 pretty easily.
Vector and graph are all we need, I'm pretty sure.

[Following George's development on and off for the past 10 years I've
been amazed how much refactoring he will do over a short time. So I
don't think our source looks much like 2.4z!]

--tim

[Torsten Berg]

> This is a very interesting effort.  I assume you're using the BLT 2.4z
> source to start?

Yes, I am using 2.4z, since this is the latest stable release I can
test against. The only change to this is the blt-patch2 for 2.4z, but
this does only affect the graph, not the vector.

Torsten

[Torsten Berg]

Next update:

This is my test script and it all works so far:

vector create vec
vec set {1 2 3 4 5}
set vec(max)
set vec(0)
set vec(min)
set vec(mean)
set vec(sum)
set vec(prod)
set vec(++end) 99
vec length
namespace eval ns {
vector create vec
vec set {1 2 3 6 5}
}
::ns::vec length
set ::ns::vec(max) ;# this will fail with BLT 2.4z (see also SF Bug
651993, link below)
namespace eval v {}
vector create v::h
vector create o(1:3)
o length
vector create p(10)
p length
vector create #auto
v::h append {1 2 3}
v::h length
set v::h(:) ;# this will fail with BLT2.4z
vector create test(3) -variable v::t
array set v::t [list 0 9 1 8 2 7]
test length
set v::t(:) ;# this will fail with BLT2.4z
test delete 1
test length
set v::t(:) ;# this will fail with BLT2.4z
test clear
vector create another -command an -watchunset 1
an append 55 66
an length
set another(:)
unset another
llength [vector names]
test dup test2
test2 length
set test2(end)
test2 index 1
test2 index 1 121
set test2(1)

So I "re-implemented" [vector create] and [vector names] plus the
instance commands "append", "clear", "delete", "dup", "index",
"length", and "set" plus the array access via ':', 'min', 'max',
'end', '++end', 'sum', 'mean', and 'prod', and via numerical indices.

The 'index' subcommand is available in BLT2.4z also, but it is not
documented on the manual page. I made a little speed test using [time]
for this script and I see no slowdown with my modified and ripped-out
version. It compiles on Tcl8.4 (but still needs TclInt.h there because
of the Tcl_Namespace API) and compiles fine using Tcl8.5 (and without
tclInt.h here).

There are a few bugs in my code that I know of, but I am making
progress. When I feel the code is ready to publish, I will do so.

Torsten

-----
BLT bug a SF that could be resolved:
http://sourceforge.net/tracker/index.php?func=detail&aid=651993&group_id=18616&atid=118616

[Bob Techentin]

On Jun 2, 5:05 am, Torsten Berg <b...@typoscriptics.de> wrote:
> All right. Still no answer. So I must assume, he does not want to
> answer for whatever reason. George is actively working on BLT though,
> the cvs shows activity all the time. Unfortunately, the cvs version
> still does not compile.
>
> So, question to the audience. What should we do at this point?

I will be working with a group of undergraduate students this fall to
fork, refactor and update BLT graph and vectors to a stubs-enabled
extension for Tcl 8.5 and beyond. I tried proposing the effort as a
Google Summer of Code project, but got no takers. Then I received an
invitation from the director of the Computer Science and Software
Engineering department at Rose-Hulman Institute of Technology. They
were looking for candidate senior projects. I submitted a proposal,
and was chosen by a team of 4 students.

This project won't get started until September. I expect that we'll
set up a sourceforge project, or similar public repository. While I'm
disappointed that we (collectively) haven't been able to elicit a
response from George, I believe that this is the best approach for
moving forward.

Bob Techentin
--
techenti...@mayo.edu

[Torsten Berg]

On Jul 1, 2:40 pm, Bob Techentin <techentin.rob...@mayo.edu> wrote:
> I will be working with a group of undergraduate students this fall to
> fork, refactor and update BLT graph and vectors to a stubs-enabled
> extension for Tcl 8.5 and beyond.

Hey, this is great news, indeed! Thank you very much for making this
possible.

> While I'm
> disappointed that we (collectively) haven't been able to elicit a
> response from George, I believe that this is the best approach for
> moving forward.

I have not heard a work from George either and also tend to think, he
does want to be left alone (as Jeff said earlier in this thread). This
is the reason I dived into the sources of the vector command to see
what is possible and how much work it would be to work on a fork.

I will (for now) continue to work on the vector command and will
gladly contribute my code to your effort, when the time comes. I am
perhaps not the best C programmer, so you may want to rewrite it again
and apply some kind of style guide to it or refactor it even more.
Until now, I tried to keep as much of the original code as convenient.

If I can be of any help there, please let me know! I have a lot of Tcl
code using the BLT graph so there is a good basis for testing here
(and I would really, really appreciate a port to the Mac's Aqua
environment ... which is the only obstacle my apps face to run
there!).

Torsten

[Torsten Berg]

Hi,

I have now added the 'populate' and 'range' subcommands to the vector
command (I haven't had so much spare time lately so progress is slow).
Did anyone ever use the 'range' subcommand with reversed indices? I
think it was buggy judging from the manual page, so I changed it to
react as I would expect.

If anyone wants to look at my code, here is the current state:

http://tcl.typoscriptics.de/misc/bltVector.zip

It contains the source needed to compile, a crude make.sh script that
compiles the code in my environment (you would have to adopt that; no
TEA yet) and a dylib build with and for Tcl 8.5 for Intel Mac. And
there is a test script using the tcltest package. That's all for now.

If you find errors, please report them to me or better, write a
tcltest that exposes the error and I will give it a try (but cannot
promise anything).

Torsten