tcllib-devel — Discussion of development for tcllib

[Tcllib-devel] missing man pages on tcllib.sf.net/doc?

[Virden, L. W. <lv...@ca...>]

I was noticing today that the bench man pages aren't available at sf.net.
Is bench considered an 'internal' module that people shouldn't use?
-- 
Tcl - The glue of a new generation.  <URL: http://wiki.tcl.tk/ >
Larry W. Virden <mailto:lv...@ca...><URL: http://www.purl.org/NET/lvirden/ >
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

Re: [Tcllib-devel] status of tcllib modules calendar, imap4, and page

[Kevin K. <ke...@re...>]

> I notice that currently tcllib cvs head doesn't appear
> to be installing calendar and impa4 modules. Are these deprecated?

Calendar definitely is; any useful functionality in it is long since
duplicated by the 8.5 [clock] command (which is also available as
an 8.4 loadable extension).

-- 
73 de ke9tv/2, Kevin

[Tcllib-devel] status of tcllib modules calendar, imap4, and page

[Virden, L. W. <lv...@ca...>]

Are these three modules considered current, supported, active,
and intended to continue to be installed tcllib modules?

I notice that currently tcllib cvs head doesn't appear
to be installing calendar and impa4 modules. Are these deprecated?

The reason this came up is that I happened across the fact that these
three modules don't have a .man file in the module directory.
Do we want to install modules without docs?
-- 
Tcl - The glue of a new generation.  <URL: http://wiki.tcl.tk/ >
Larry W. Virden <mailto:lv...@ca...><URL: http://www.purl.org/NET/lvirden/ >
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

Re: [Tcllib-devel] Microsoft lawsuit? [Re: pure tcl bmp reader/writer]

[Cameron L. <Ca...@ph...>]

On Wed, May 16, 2007 at 11:09:54AM -0400, Kenny, Kevin B (GE, Research) wrote:
			.
			.
			.
> All that Microsoft has done is to *threaten* suit in a press release.
> Even the number and distribution of the patents mentioned in the
> release were taken from a report from Open Source Risk Management.
> If Microsoft wants to go around threatening to sue its customers
> (how many deep-pocketed open source users aren't mixed shops, anyway?)
> it is committing corporate suicide in a particularly painful manner.
> OIN, backed by IBM, Sony, Philips, Novell, Red Hat, NEC, and 
> Sun, is waiting in the wings to attempt to enjoin Microsoft from
> infringing on the hundred or so patents in its portfolio; if
> Microsoft actually fires a shot in this war, several commentators
> have compared the likely result to "patent Armageddon", where
> everyone sues everyone else and nobody can ship product until
> the legislature intervenes.
> 
> In any case, it's virtually impossible even for a well-heeled
> corporation to do due diligence on Microsoft's seven thousand or
> so issued patents (to say nothing of its pending applications).
> Until and unless Microsoft identifies the specific patents for
> which it claims infringement, it's all posturing.
> 
> Stephen Vaughan-Nichols of E-Week has a fair summary of this non-story:
> http://www.eweek.com/article2/0,1895,2129586,00.asp
			.
			.
			.
SJVN's great, of course.  Here's more: <URL:
http://www.groklaw.net/article.php?story=20070515125107293 >;
and especially <URL:
http://www.groklaw.net/article.php?story=20070513234519615 >,
where PJ warms up with the heavy artillery square on-target.

[Tcllib-devel] Microsoft lawsuit? [Re: pure tcl bmp reader/writer]

[Kenny, K. B \(G. Research\) <ke...@cr...>]

TGFycnkgVmlyZGVuOg0KPiBBIHNlY29uZCB0aGluZywgc29ydCBvZiB1bnJlbGF0ZWQsIHRoYXQg
dGhlIFRDVCBhcyB3ZWxsIGFzIGV2ZXJ5IG90aGVyDQo+IFRjbCBkZXZlbG9wZXIgbmVlZHMgdG8g
a2VlcCBpbiBtaW5kIGlzIHRoZSBNaWNyb3NvZnQgbGF3c3VpdCwgZmlsZWQgaW4NCj4gdGhlIHBh
c3Qgd2VlaywgYWdhaW5zdCBvcGVuIHNvdXJjZSBkZXZlbG9wZXJzIHdobyBtYWtlIHVzZSBvZiB0
ZWNobm9sb2d5DQo+IGZvciB3aGljaCBNaWNyb3NvZnQgaGFzIHBhdGVudHMuIA0KDQpMYXJyeSwN
Cg0KQWxsIHRoYXQgTWljcm9zb2Z0IGhhcyBkb25lIGlzIHRvICp0aHJlYXRlbiogc3VpdCBpbiBh
IHByZXNzIHJlbGVhc2UuDQpFdmVuIHRoZSBudW1iZXIgYW5kIGRpc3RyaWJ1dGlvbiBvZiB0aGUg
cGF0ZW50cyBtZW50aW9uZWQgaW4gdGhlDQpyZWxlYXNlIHdlcmUgdGFrZW4gZnJvbSBhIHJlcG9y
dCBmcm9tIE9wZW4gU291cmNlIFJpc2sgTWFuYWdlbWVudC4NCklmIE1pY3Jvc29mdCB3YW50cyB0
byBnbyBhcm91bmQgdGhyZWF0ZW5pbmcgdG8gc3VlIGl0cyBjdXN0b21lcnMNCihob3cgbWFueSBk
ZWVwLXBvY2tldGVkIG9wZW4gc291cmNlIHVzZXJzIGFyZW4ndCBtaXhlZCBzaG9wcywgYW55d2F5
PykNCml0IGlzIGNvbW1pdHRpbmcgY29ycG9yYXRlIHN1aWNpZGUgaW4gYSBwYXJ0aWN1bGFybHkg
cGFpbmZ1bCBtYW5uZXIuDQpPSU4sIGJhY2tlZCBieSBJQk0sIFNvbnksIFBoaWxpcHMsIE5vdmVs
bCwgUmVkIEhhdCwgTkVDLCBhbmQgDQpTdW4sIGlzIHdhaXRpbmcgaW4gdGhlIHdpbmdzIHRvIGF0
dGVtcHQgdG8gZW5qb2luIE1pY3Jvc29mdCBmcm9tDQppbmZyaW5naW5nIG9uIHRoZSBodW5kcmVk
IG9yIHNvIHBhdGVudHMgaW4gaXRzIHBvcnRmb2xpbzsgaWYNCk1pY3Jvc29mdCBhY3R1YWxseSBm
aXJlcyBhIHNob3QgaW4gdGhpcyB3YXIsIHNldmVyYWwgY29tbWVudGF0b3JzDQpoYXZlIGNvbXBh
cmVkIHRoZSBsaWtlbHkgcmVzdWx0IHRvICJwYXRlbnQgQXJtYWdlZGRvbiIsIHdoZXJlDQpldmVy
eW9uZSBzdWVzIGV2ZXJ5b25lIGVsc2UgYW5kIG5vYm9keSBjYW4gc2hpcCBwcm9kdWN0IHVudGls
DQp0aGUgbGVnaXNsYXR1cmUgaW50ZXJ2ZW5lcy4NCg0KSW4gYW55IGNhc2UsIGl0J3MgdmlydHVh
bGx5IGltcG9zc2libGUgZXZlbiBmb3IgYSB3ZWxsLWhlZWxlZA0KY29ycG9yYXRpb24gdG8gZG8g
ZHVlIGRpbGlnZW5jZSBvbiBNaWNyb3NvZnQncyBzZXZlbiB0aG91c2FuZCBvcg0Kc28gaXNzdWVk
IHBhdGVudHMgKHRvIHNheSBub3RoaW5nIG9mIGl0cyBwZW5kaW5nIGFwcGxpY2F0aW9ucykuDQpV
bnRpbCBhbmQgdW5sZXNzIE1pY3Jvc29mdCBpZGVudGlmaWVzIHRoZSBzcGVjaWZpYyBwYXRlbnRz
IGZvcg0Kd2hpY2ggaXQgY2xhaW1zIGluZnJpbmdlbWVudCwgaXQncyBhbGwgcG9zdHVyaW5nLg0K
DQpTdGVwaGVuIFZhdWdoYW4tTmljaG9scyBvZiBFLVdlZWsgaGFzIGEgZmFpciBzdW1tYXJ5IG9m
IHRoaXMgbm9uLXN0b3J5Og0KaHR0cDovL3d3dy5ld2Vlay5jb20vYXJ0aWNsZTIvMCwxODk1LDIx
Mjk1ODYsMDAuYXNwDQoNCi0tIA0KNzMgZGUga2U5dHYvMiwgS2V2aW4NCg==

Re: [Tcllib-devel] pure tcl bmp reader/writer

[David W. <dav...@gm...>]

> A second thing, sort of unrelated, that the TCT as well as every other
> Tcl developer needs to keep in mind is the Microsoft lawsuit, filed in
> the past week, against open source developers who make use of technology
> for which Microsoft has patents. If bmp is one of those technologies,
> then we might not want to have it in any of our distributed
> libraries....

Microsoft did not file a lawsuit last week.  They suggested that Linux
and other open source systems infringe on their patents.

I wouldn't worry about it in any case.  They are not going to go after tcllib.

-- 
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/

Re: [Tcllib-devel] pure tcl bmp reader/writer

[Virden, L. W. <lv...@ca...>]

If the ico package has all the same functionality of the bmp package,
then I don't see a need to add bmp. On the other hand, ico is in the
tklib set, which, I presume, means it requires Tk.  The bmp package
doesn't _seem_ to require Tk, from what I can tell.

A second thing, sort of unrelated, that the TCT as well as every other
Tcl developer needs to keep in mind is the Microsoft lawsuit, filed in
the past week, against open source developers who make use of technology
for which Microsoft has patents. If bmp is one of those technologies,
then we might not want to have it in any of our distributed
libraries....


--=20
<URL: http://wiki.tcl.tk/ >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lv...@gm... > <URL: http://www.purl.org/NET/lvirden/
>
=20

-----Original Message-----
From: tcl...@li...
[mailto:tcl...@li...] On Behalf Of Aaron F
Sent: Tuesday, May 15, 2007 4:46 PM
To: Tcllib Devel
Subject: Re: [Tcllib-devel] pure tcl bmp reader/writer

just fyi the ico package includes this capability. however im not sure
that is an argument against inclusion of a bmp specific package.

--Aaron

----- Original message -----
From: "Andreas Kupries" <and...@ac...>
To: "Tcllib Devel" <tcl...@li...>
Sent: Tue, 15 May 2007 13:48:17 -0700
Subject: [Tcllib-devel] pure tcl bmp reader/writer

>=20
> http://wiki.tcl.tk/18083
>=20
> --
> 	Andreas Kupries <and...@Ac...>
> 	Developer @ http://www.ActiveState.com
> 	Tel: +1 778-786-1122
> =20
>=20

------------------------------------------------------------------------
-
This SF.net email is sponsored by DB2 Express Download DB2 Express C -
the FREE version of DB2 express and take control of your XML. No limits.
Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Tcllib-devel mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcllib-devel

Re: [Tcllib-devel] pure tcl bmp reader/writer

[Aaron F <ro...@fe...>]

just fyi the ico package includes this capability. however im not sure that is an argument against inclusion of a bmp specific package.

--Aaron

----- Original message -----
From: "Andreas Kupries" <and...@ac...>
To: "Tcllib Devel" <tcl...@li...>
Sent: Tue, 15 May 2007 13:48:17 -0700
Subject: [Tcllib-devel] pure tcl bmp reader/writer

> 
> http://wiki.tcl.tk/18083
> 
> --
> 	Andreas Kupries <and...@Ac...>
> 	Developer @ http://www.ActiveState.com
> 	Tel: +1 778-786-1122
>  
> 

[Tcllib-devel] pure tcl bmp reader/writer

[Andreas K. <and...@ac...>]

http://wiki.tcl.tk/18083

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122
 

Re: [Tcllib-devel] Tcl based XBM reader /Wiki

[Andreas K. <and...@ac...>]

> Brett Schwarz schrieb:
> > sure, but why not tcllib? Can't this be used for other non GUI
> things (web stuff comes to mind)?
> > http://wiki.tcl.tk/18030
> >
> > Something we can put into 'Tklib' ?
> > We already have 'ico', so 'xbm' would not be out of the qestion, IMHO.
>
> Hmm, we have some image packages in tcllib, some in tklib? Any specific
> reasoning why tiff is in tcllib and ico is in tklib for example?

IIRC ico has dependencies on Tk for some ops (direct conversion to photo for
example).
tiff anmd jpeg don't do that, therefore no deps on Tk, therefore they can be
in tcllib.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

Re: [Tcllib-devel] Tcl based XBM reader /Wiki

[Michael S. <sc...@un...>]

Brett Schwarz schrieb:
> sure, but why not tcllib? Can't this be used for other non GUI things (web stuff comes to mind)?
> 
> ----- Original Message ----
> From: Andreas Kupries <and...@ac...>
> To: Tcllib Devel <tcl...@li...>
> Sent: Tuesday, May 8, 2007 8:58:54 AM
> Subject: [Tcllib-devel] Tcl based XBM reader /Wiki
> 
> 
> http://wiki.tcl.tk/18030
> 
> Something we can put into 'Tklib' ?
> We already have 'ico', so 'xbm' would not be out of the qestion, IMHO.

Hmm, we have some image packages in tcllib, some in tklib? Any specific
reasoning why tiff is in tcllib and ico is in tklib for example?

Michael

Re: [Tcllib-devel] Tcl based XBM reader /Wiki

[Brett S. <bre...@ya...>]

sure, but why not tcllib? Can't this be used for other non GUI things (web stuff comes to mind)?

----- Original Message ----
From: Andreas Kupries <and...@ac...>
To: Tcllib Devel <tcl...@li...>
Sent: Tuesday, May 8, 2007 8:58:54 AM
Subject: [Tcllib-devel] Tcl based XBM reader /Wiki


http://wiki.tcl.tk/18030

Something we can put into 'Tklib' ?
We already have 'ico', so 'xbm' would not be out of the qestion, IMHO.

--
    Andreas Kupries <and...@Ac...>
    Developer @ http://www.ActiveState.com
    Tel: +1 778-786-1122
 

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Tcllib-devel mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcllib-devel




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Tcllib-devel] Tcl based XBM reader /Wiki

[Andreas K. <and...@ac...>]

http://wiki.tcl.tk/18030

Something we can put into 'Tklib' ?
We already have 'ico', so 'xbm' would not be out of the qestion, IMHO.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122
 

Re: [Tcllib-devel] Test coverage

[Arjen M. <arj...@wl...>]

Virden, Larry W. wrote:

>I definitely think packages like this are valuable.  In this particular
>case, it would allow us to determine how much of tcllib the tcllib test
>suite is testing, just as an example. I suspect this package is only
>relevant to testing tcl scripts though, right?
>
>  
>
Hi Larry,

yes, it simply analyses the Tcl code and insert some statements to register
that the code has been executed. Some procedures are overloaded to load
the instrumented code and to save the results.

Things it does not handle well are statements like:

    if { $cond } continue

as there you have the conditional statement (if) and a branching
statement (continue) on the same line. It would work if you did:

   if { $cond } {
       continue
   }

as then it can simply insert a few lines. (That is much easier than
inserting the statements in the right place - the analysis is much
more complicated then, you would have to do a complete or
almost complete analysis of the Tcl code. With the second form
it is a mere matter of applying regexp.)

You could use the same technique to produce instrumented code
written in other languages, but I have not looked into that (at least
not in the context of this particular package/application).

Regards,

Arjen

Re: [Tcllib-devel] Test coverage

[Virden, L. W. <lv...@ca...>]

I definitely think packages like this are valuable.  In this particular
case, it would allow us to determine how much of tcllib the tcllib test
suite is testing, just as an example. I suspect this package is only
relevant to testing tcl scripts though, right?

--=20
<URL: http://wiki.tcl.tk/ >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lv...@gm... > <URL: http://www.purl.org/NET/lvirden/
>
=20


-----Original Message-----
From: tcl...@li...
[mailto:tcl...@li...] On Behalf Of Arjen
Markus
Sent: Wednesday, April 18, 2007 8:09 AM
To: Tcllib Devel
Subject: [Tcllib-devel] Test coverage


Hello,

I very recently updated an old application that can register which=20
statements have
been executed and how many times (see the Wiki: http://wiki.tcl.tk/8638=20
- the link
mentioned there is no longer available). I can add this application=20
after some cleanup
to Tcllib, if there is interest. If so, would that be an application=20
(under tclapp) or a
package of sorts (tcllib proper)?

What it does, roughly is:
- Instrument the source code, so that it is registering what parts of=20
the code are run
- Report this information via an annotated source listing.

It is not 100% accurate - it will miss certain constructs due to the way

the code is
analysed - but it should give a fair impression.

Regards,

Arjen

------------------------------------------------------------------------
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Tcllib-devel mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcllib-devel

[Tcllib-devel] Test coverage

[Arjen M. <arj...@wl...>]

Hello,

I very recently updated an old application that can register which 
statements have
been executed and how many times (see the Wiki: http://wiki.tcl.tk/8638 
- the link
mentioned there is no longer available). I can add this application 
after some cleanup
to Tcllib, if there is interest. If so, would that be an application 
(under tclapp) or a
package of sorts (tcllib proper)?

What it does, roughly is:
- Instrument the source code, so that it is registering what parts of 
the code are run
- Report this information via an annotated source listing.

It is not 100% accurate - it will miss certain constructs due to the way 
the code is
analysed - but it should give a fair impression.

Regards,

Arjen

Re: [Tcllib-devel] Question about the test utilities

[Arjen M. <arj...@wl...>]

Andreas Kupries wrote:

>useLocal ...
>
>When you have a tcllib package FOO depending on a Tcllib package BAR the
>testsuite cannot simply do 'package require BAR'.
>
>Because if you do you are in the danger of not getting the version of BAR
>which is in the Tcllib you are working with, but some previously installed
>version of BAR, likely older, likely different.
>
>So I added commands to devtools/testutilities which allow you to load a
>Tcllib package directly, without going through the regular package
>management.
>
>The main commands are 'useLocal' and 'use'.
>
>The first of these assumes that the package BAR you want is in the same
>module as the using package FOO. This is the case for mvlinreg and linalg,
>both are in the math module. 'use' OTOH just assumes the BAR is somewhere in
>Tcllib, and you have to specify the module as well, as part of the path to
>the file you are loading. I.e. if BAR is in mode ZAT you say
>
>	use ZAT/BAR bar ...
>
>Does the above make sense ?
>  
>
Hi Andreas,

it makes perfect sense! I was imagining things about cleaning up etc, 
but this
is a much simpler explanation.

Thanks for the above (and the software it talks about - it is such a 
pleasure to
use sak, especially due to its extensive online help).

Regards,

Arjen

Re: [Tcllib-devel] Question about the test utilities

[Andreas K. <and...@ac...>]

> I ran into an issue with the statistics package that
> has to do with the test utilities, most notably the
> useLocal command.
>
> The introduction of the multivariate linear regression
> procedures by Eric Kemp-Benedict made the statistics package
> depend on the linear algebra package. This is not a problem,
> but it made it necessary to _explicitly_ load the package
> via "useLocal" in the preamble to the tests (despite the
> package require command).
>
> Can anyone explain under what circumstances this useLocal
> command is needed and why?
>
> (I get error messages about an unknown namespace otherwise).

useLocal ...

When you have a tcllib package FOO depending on a Tcllib package BAR the
testsuite cannot simply do 'package require BAR'.

Because if you do you are in the danger of not getting the version of BAR
which is in the Tcllib you are working with, but some previously installed
version of BAR, likely older, likely different.

So I added commands to devtools/testutilities which allow you to load a
Tcllib package directly, without going through the regular package
management.

The main commands are 'useLocal' and 'use'.

The first of these assumes that the package BAR you want is in the same
module as the using package FOO. This is the case for mvlinreg and linalg,
both are in the math module. 'use' OTOH just assumes the BAR is somewhere in
Tcllib, and you have to specify the module as well, as part of the path to
the file you are loading. I.e. if BAR is in mode ZAT you say

	use ZAT/BAR bar ...

Does the above make sense ?

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

[Tcllib-devel] Question about the test utilities

[Arjen M. <arj...@wl...>]

Hello,

I ran into an issue with the statistics package that
has to do with the test utilities, most notably the
useLocal command.

The introduction of the multivariate linear regression
procedures by Eric Kemp-Benedict made the statistics package
depend on the linear algebra package. This is not a problem,
but it made it necessary to _explicitly_ load the package
via "useLocal" in the preamble to the tests (despite the
package require command).

Can anyone explain under what circumstances this useLocal
command is needed and why?

(I get error messages about an unknown namespace otherwise).

Regards,

Arjen

Re: [Tcllib-devel] dictutil commands on the wiki ...

[Neil M. <ne...@Cs...>]

On 13 Feb 2007, at 19:21, Andreas Kupries wrote:
...
>> Problem is the format -- should it be a simple [eq? $a $b]
>> or include the index too [eq? $i $a $b]? The first is simpler (and
>> allows using things like {string equal}), whereas the latter is
>> perhaps more flexible (e.g., if a list is being used like a tuple).
>
> Hm. My gut feeling just after reading the above is have it with  
> index, with
> the antagonistic part of me asking for a concrete example where it  
> would
> truly be useful. Which I don't have, causing me overall to sit on  
> the fence
> here. I wonder how much of a problem having the index would be,  
> given that
> 8.5 also has apply and thus the ability to write anon wrapper  
> commands to
> get something like 'string equal' to work.

It's hard to say. The only good cases I can think of, it'd be just as  
easy to write a new equality check anyway, doing something like:
   foreach type $types a $as b $bs {
       if {![$type equal $a $b]} { return 0 }
   }

>> I've some other bits of code that could be contributed to tcl/tklib
>> at some point:
>>
>> * A higher level channel API (http://wiki.tcl.tk/17012) -- I have a
>> bunch of updates/changes to this that I want to finish up, then I
>> think it might be worth adding.
>
> Hm. Interesting. Note that I recently added some higher-level  
> channel stuff
> as well, see the 'transfer' packages (transfer::connect ,  
> transfer::copy ,
> transfer::data::destination , transfer::data::source ,  
> transfer::receiver ,
> transfer::copy::queue , transfer::transmitter)

Great. I'll have a look and see whether my stuff fits in with any of  
that.

>> * A thread-safe message queue (http://wiki.tcl.tk/17652) -- might be
>> better bundled directly with the Thread extension, but could also go
>> in tcllib. I have some tests and docs for this too, so it could go
>> straight in (subject to review).
>
> I agree with the sentiment that this belongs more with Thread than  
> tcllib.

Yes. Are tcllib modules even allowed to depend on Thread?

>
> Hm. ... It seems you are using the 'shared var' facility of Thread to
> implement them. I wonder if it might be easier to use  
> 'thread::send' as a
> basis instead, i.e. the C-level event (message) queue as the  
> foundation.

Not really. With thread::send the consumer thread must enter the  
event loop, either by calling vwait or by unwinding to a top level  
event loop. Sometimes you want more control than that. For instance,  
you might not want posted jobs to start processing just because you  
called tk_messageBox. Similarly you might not want other events to be  
processed when you need a message from a queue. You might also want  
to accept messages from different queues at different times:

  set msg1 [mqueue pop $queue1]
  ...
  set msg2 [mqueue pop $queue2]

Or you might want to filter which messages you actually accept. You  
can't have that control with a single big event queue. (This is a  
pain I've felt even in single threaded Tk apps on occassion --  
wanting more control over exactly which events get processed).

...
>> I also have a variety of other bits and pieces sitting on my laptop
>> that could be polished up -- e.g., an "article" widget for  
>> displaying/
>> composing email/usenet articles,
>
> Interesting. A new mail/news reader in Tcl/Tk ?

A fairly substantial rewrite of the code in http://wiki.tcl.tk/11104  
that never really got finished.

>
>> various implementations of algebraic
>> datatypes
>
> Which types ? And what advantages do we get from their algebraic- 
> ness ?

No types in particular (probably a BST and some others). More the  
framework, which allows you to do things like:

   datatype cons BST = Leaf
   datatype cons BST = Branch left val right
   set tree [Branch [Leaf] 3 [Branch [Leaf] 5 [Branch [Leaf] 6 [Leaf]]]]
   proc toList tree {
       datatype case BST $tree {
           Leaf            -> { return {} }
           {Branch l v r}  -> { concat [toList $l] [list $v] [toList  
$r] }
       }
   }

Note the "BST" here is just sugar -- no type checking goes on (yet).

-- Neil

Re: [Tcllib-devel] dictutil commands on the wiki ...

[Andreas K. <and...@ac...>]

> On 12 Feb 2007, at 19:07, Andreas Kupries wrote:
> > http://wiki.tcl.tk/17686
> >
> > 	Good enough for adding them to tcllib ?
> > 	(Under struct, I would say, should our answer be 'yes')
>
> I'm certainly happy to see them added to tcllib. A test-suite is
> needed, of course. If it goes in to tcllib alongside struct::list,
> then it might be worth examining the API. For instance, struct::list
> equal assumes that its elements are either strings or sub-lists,
> whereas dictutils equal requires an explicit equality predicate for
> the elements. You could probably add a predicate to list equality, as
> an optional first argument, and let it default to the current
> behaviour.

Huh. Didn't notice that. One thing I am doing slowly at the side is working
a bit on Critcl implementations for the struct::list ops. List equality I
found to be one of the harder ones. Because it is looking for sublists, and
checking for the difference between a plain string and a list is awkward at
the C level. I haven't completed that one yet. Of course, the LCS and
various db-related joins ops will be hard as well, however there the problem
is more the size of the algorithm, and not the conceptual underpinnings.


> Problem is the format -- should it be a simple [eq? $a $b]
> or include the index too [eq? $i $a $b]? The first is simpler (and
> allows using things like {string equal}), whereas the latter is
> perhaps more flexible (e.g., if a list is being used like a tuple).

Hm. My gut feeling just after reading the above is have it with index, with
the antagonistic part of me asking for a concrete example where it would
truly be useful. Which I don't have, causing me overall to sit on the fence
here. I wonder how much of a problem having the index would be, given that
8.5 also has apply and thus the ability to write anon wrapper commands to
get something like 'string equal' to work.


> I've some other bits of code that could be contributed to tcl/tklib
> at some point:
>
> * A higher level channel API (http://wiki.tcl.tk/17012) -- I have a
> bunch of updates/changes to this that I want to finish up, then I
> think it might be worth adding.

Hm. Interesting. Note that I recently added some higher-level channel stuff
as well, see the 'transfer' packages (transfer::connect , transfer::copy ,
transfer::data::destination , transfer::data::source , transfer::receiver ,
transfer::copy::queue , transfer::transmitter)


> * A thread-safe message queue (http://wiki.tcl.tk/17652) -- might be
> better bundled directly with the Thread extension, but could also go
> in tcllib. I have some tests and docs for this too, so it could go
> straight in (subject to review).

I agree with the sentiment that this belongs more with Thread than tcllib.

Hm. ... It seems you are using the 'shared var' facility of Thread to
implement them. I wonder if it might be easier to use 'thread::send' as a
basis instead, i.e. the C-level event (message) queue as the foundation.


> * Simple download progress widget (http://wiki.tcl.tk/10571) -- with
> a bit of polish this could find its way into tklib. I have some half-
> finished code generalising this into a task-progress dialog.

Yes, tklib definitely ... Jeff has a number of things under the widget
module,
maybe it fits in there ? (Note: Jeff's stuff is snit based. Ah, yours too,
good).


> I also have a variety of other bits and pieces sitting on my laptop
> that could be polished up -- e.g., an "article" widget for displaying/
> composing email/usenet articles,

Interesting. A new mail/news reader in Tcl/Tk ?

> various implementations of algebraic
> datatypes

Which types ? And what advantages do we get from their algebraic-ness ?

> and pattern matching, a couple of unification algorithms, a
> scrolling ticker widget, etc. If any of these appeal I could be
> tempted into packaging them up.

Yes.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

Re: [Tcllib-devel] test suite for tcllib

[Andreas K. <and...@ac...>]

> A bug item was opened yesterday regarding the fact that the tar module
> is missing a test suite. Today, I decided to run the cvs head tcllib's
> test suite interactively. So far, what I am seeing is that the
> following modules are missing test suites:
>
> bench
> ftp
> ftpd
> grammar_peg
> http
> irc
> javascript
> jpeg
> nmea
> nntp
> page
> pluginmgr

Yes, that looks about right.

> (I also see that there were failures in cmdline , grammar_me, and didn't
> get through the test suite - things just sort of "stopped" at
> sha1 (probably
> just didn't wait long enough)

sha1 in pure Tcl is slow. It is especially slow when it tests the higher
orders, i.e. sha256.

> I'm still not certain where to look for the results of the test suite -
> sure would be nice if the output was logged somewhere... there is that
> log module in tcllib ...).

./sak.tcl test run -l LOG_stem

	=> LOG.stem.log
	   LOG_stem.summary
	...

Or

./sak.tcl test run -v | tee LOG

Still, thanks for the reminder that I want to work on the test output for
make files, etc.

> Anyways, there are a number of modules which need test suites. If someone
> on this mailing list feels motivated (if you live on the east coast,
> you probably are snowed in today and have plenty of time on your hands
> ;-)

Heh.

> then perhaps you can code up a test or two and submit it.  Don't
> feel that you have to figure out every test. Just begin testing the
> basics, and more tests can be added in as time goes by.

I agree with the sentiment, very much so. Testsuites are one of the best
examples of things we can add incrementally to our packages.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

Re: [Tcllib-devel] dictutil commands on the wiki ...

[Andreas K. <and...@ac...>]

> Virden, Larry W. wrote:
>
> >For annealing, that might go into a module for collecting various
> >combinatoric/permutation operations? Or do we have those some place
> >else?
> >
> We have a few procedures in the math module, but they are more concerned
> with the number of combinations/permutations/... not with searching the
> solution space.

Regarding permutations, we have list operations in struct::list for them as
well, to enumerate all permutations of a set (see firstperm, nextperm,
permutations).

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

Re: [Tcllib-devel] Test

[Neil M. <ne...@cs...>]

Thanks to those that replied, and thanks to Andreas for passing  
through my messages. I figured out the problem: I was subscribed to  
the list using my @users.sourceforge.net email address, which just  
forwards to my university address. Thus I was receiving messages from  
the list fine but the list didn't recognise my address when I  
replied. I've re-subscribed using my uni account now.

-- Neil

On 13 Feb 2007, at 16:33, Neil Madden wrote:
> Testing...
>
> Can someone email me if this gets through? I don't think my emails
> are getting through to the list.
>
> Cheers,
>
> -- Neil
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Tcllib-devel mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcllib-devel

Re: [Tcllib-devel] dictutil commands on the wiki ...

[<ke...@cr...>]

lv...@ca... said:
> Also, we would, of course, want to contact the appropriate authors,
> and get their okay before adding the code.  We don't want another one
> of _those_ reactions...

For the simulated annealing on http://wiki.tcl.kt/3835, I'm the author,
and (as with anything I put on the Wiki) the answer is, "oh, go ahead."

When developing the page, I worked from the descriptions of the algorithms
in the Metropolis paper, _Numerical Recipes_ (1st ed), and Sedgewick's
_Algorithms in C++_.  The cryptanalysis algorithm is an attempt to simplify a
half-remembered approach from a paper that I read once about twenty
years ago; the paper was likely J. Carrol and S. Martin. "The automated 
cryptanalysis of substitution ciphers. Cryptologia, 10(4):193--209, 1986.
http://citeseer.csail.mit.edu/context/548964/0

(Since I haven't a copy handy, I can't check readily.)

I won't say that nobody will accuse me of plagiarism, simply because
anyone can come up with a wild accusation.  But those were the chief
references.

--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
ke...@cr...           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA