tcllib-devel — Discussion of development for tcllib

[Tcllib-devel] Major changes/enhancements to the tcllib ldap package

[Michael S. <sch...@is...>]

Hi all,

just committed some major enhancements to the tcllib ldap package
(version 1.6), which should see some broader testing, so if you
use the ldap package, please test those new features and your old code,
so nothing breaks too horribly.

New features:
- SASL support based on the tcllib SASL package
- StartTLS support to upgrade existing connections to TLS
- "Who am I?" extension support to check the authzId
- Some more info subcommands to detect server features
- Async operation. The protocol engine is now fileevent based instead
of the blocking operation before.
- multiple value support

In the light of those changes i would like your oppinion if the version
number should stay at 1.6 or if i should move the package to 2.0.

Michael

[Tcllib-devel] ANNOUNCE: KHIM 1.0 added to tklib

[Kevin K. <kk...@ny...>]

I finally managed to get around to bundling up a releasable
version of KHIM (Kevin's Hacky Input Manager).  KHIM is a hack
(as the name suggests) to allow for entry of Unicode characters
on a keyboard that lacks them.  Rather than interact with any
host's input methods, it designates one ordinary key (the library
as released uses Pause, but  often change it to L2 [the F12 key on
a Windows keyboard]) as a "Compose" key.  This key must be distinct
from the system's "Compose" key (if there is one).

When KHIM is active, pressing the "Compose" key followed by
a two-character sequence enters a Unicode character corresponding to
the two-character sequence.  Pressing the "Compose" key twice
in succession brings up a Unicode character map from which a
character may be selected and inserted into the application.

A text or entry widget may be configured to use KHIM by adding KHIM
to its bindtags in front of the class binding:

     package require khim
     text .t -width 80 -height 24
     bindtags .t {.t KHIM Text . all}
     entry .e -width 30
     bindtags .e {.e KHIM Entry . all}

There are commands that an application can call to bring up a
control panel for KHIM (allowing for changes to the key bindings),
to bring up user help for KHIM, and to save and restore the KHIM
key bindings.

I wrote KHIM for several reasons:
    - On some machines, I'm not allowed, or don't know how, to change
      the system's input method to get the characters I want.
    - I don't want to have to learn the input methods for all the systems
      I use.
    - I occasionally have use for some pretty bizarre characters, and
      an "Insert Symbol"-style function comes in handy in most
      applications that deal with Unicode text.

It's not intended to replace a system input method, but rather to
allow for entry of the occasional character that the system input
method doesn't support.

As always, comments are welcome.  Particularly welcome are
translations of the message catalog.

--
73 de ke9tv/2, Kevin

Re: [Tcllib-devel] A proposal for a new "ldapx" package

[Pierre D. <Pie...@cr...>]

On Thu, Aug 24, 2006 at 02:25:20PM +0200, Pierre DAVID wrote:
> Hi,
> 
> Here is "ldapx", a proposal for a new Tcllib package.
> 
> This package provides a new, extended high-level interface to LDAP
> diretories and LDIF files. It makes use of the Snit object type to
> provide three classes: ldap directories, ldif files and individual
> entries.
> 
> This new package is built upon existing packages: uri.tcl, asn.tcl
> and ldap.tcl (to provide low level access).
> 
> Here is the proposed documentation (both in .man format and in PDF)
> and the ldapx.tcl code. The ldapx.tcl code needs a very current
> Tcllib (uri.tcl patch committed, asn.tcl patch committed, and
> ldap.tcl patches currently being reviewed by Michael Schlenker).
> 
> I am requesting comments, reviews and advices from the Tcllib
> community, and if everybody agrees, I would be delighted to donate
> this code for inclusion in Tcllib.
> 

I forgot to add the files. They are available on SF, patch 1545931:
http://sourceforge.net/tracker/index.php?func=detail&aid=1545931&group_id=12883&atid=312883

Pierre David

[Tcllib-devel] A proposal for a new "ldapx" package

[Pierre D. <Pie...@cr...>]

Hi,

Here is "ldapx", a proposal for a new Tcllib package.

This package provides a new, extended high-level interface to LDAP
diretories and LDIF files. It makes use of the Snit object type to
provide three classes: ldap directories, ldif files and individual
entries.

This new package is built upon existing packages: uri.tcl, asn.tcl
and ldap.tcl (to provide low level access).

Here is the proposed documentation (both in .man format and in PDF)
and the ldapx.tcl code. The ldapx.tcl code needs a very current
Tcllib (uri.tcl patch committed, asn.tcl patch committed, and
ldap.tcl patches currently being reviewed by Michael Schlenker).

I am requesting comments, reviews and advices from the Tcllib
community, and if everybody agrees, I would be delighted to donate
this code for inclusion in Tcllib.

Pierre David

Re: [Tcllib-devel] CVS and SVN

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

Silvano Catinella schrieb:
> Hello,
> 
> I have written a software package manager that starting from a CVS-working-copy
> calcules the version and generates the appropriate software package.
> Originally it was a Bash script and it was based on command-ouput analyzing.
> Now I have rewritten that in Tcl language, but I have seen that tclib does not
> provide CVS and SVN access functions. So, I can develop these features, let me
> know if you are interested to include these functions in tclib.
> 
Are you talking about implementing the CVS and SVN protocol in Tcl for
inclusion in Tcllib?

If yes, those are surely welcome as packages, provided you can donate
them under the appropriate license.

There would be some code to get you started for CVS, take a look at:
http://wiki.tcl.tk/12676

Michael

[Tcllib-devel] CVS and SVN

[Silvano C. <cat...@ya...>]

Hello,

I have written a software package manager that starting from a CVS-working-copy
calcules the version and generates the appropriate software package.
Originally it was a Bash script and it was based on command-ouput analyzing.
Now I have rewritten that in Tcl language, but I have seen that tclib does not
provide CVS and SVN access functions. So, I can develop these features, let me
know if you are interested to include these functions in tclib.

Regards

Silvano Catinella <cat...@ya...>

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

Re: [Tcllib-devel] Name server (RE: A proposed new package ... Asking for comments.)

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

> Andreas Kupries schrieb:
> > One of the services I wanted to put into Tcllib, based on the 'safe' comm
> > foundation
> > is the primitive nameserver I did years ago, see
> >
> > 	http://www.oche.de/~akupries/soft/pool/f_net_ns_server.tcl.html
> >
> > Except when I started the docs/spec for the new implementation I
> found myself
> > quickly on the road to complexity, because of a number of questions
> I came up
> > with in need answers ... For now the doc/spec is quite incomplete
> and actually
> > more a set of notes I started to make to organize my thoughts and
> get something
> > coherent out of of whatever notions are tumbling through my subconscious.
>
> Keep it basically simple. What would be the main usecase? comm services
> which need to detect each other?

That is what I use the old service for at home (popeyemon to discover popeye
[1]).

[1] popeye is my pop client (See Pool package)
    popeyemon is a small monitor application (also in Pool) for it.
    It uses the log output of popeye to drive its UI ... That log
    system is the ancestor of 'log' in Tcllib.

> > 	Actually, before writing the last sentence, a different
> > 	thought bubbled up out of my subconscious, that I am
> > 	apparently re-inventing LDAP, where the stored records have
> > 	complex structure with many keyes, attributes, possibly
> > 	nesting, and can be searched for by any component. That made
> > 	me realize that my questions had put me really well on the
> > 	road to higher complexity.
>
> Your basically not only solving similar problems to LDAP/X.500, you also
> dabble in the field of UDDI
> (http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration)

Huh.

> or even the naming conventions/name discovery used by things like DBUS
> or Apples Bonjour/Rendevouzs.

I should note that I use TCP here. Bonjour/Rendevouzs is UDP, so for a Tcl
binding to that you need either tclUDP, or ceptcl. Any takers ?

Sidenote: The TCP port the server will use will be '[phonecode
<packagename-without-colons>] % 65536'. The modulo is needed as port numbers are
apparently 'short'.


> > 	Still. What would we use in the Tcl world as records ? My
> > 	guess would be nested dictionaries.
>
> Yes to nested dictionaries for storing the records.
>
> Michael


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

Re: [Tcllib-devel] Name server (RE: A proposed new package ... Asking for comments.)

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

Andreas Kupries schrieb:
> One of the services I wanted to put into Tcllib, based on the 'safe' comm
> foundation
> is the primitive nameserver I did years ago, see
> 
> 	http://www.oche.de/~akupries/soft/pool/f_net_ns_server.tcl.html
> 
> Except when I started the docs/spec for the new implementation I found myself
> quickly on the road to complexity, because of a number of questions I came up
> with in need answers ... For now the doc/spec is quite incomplete and actually
> more a set of notes I started to make to organize my thoughts and get something
> coherent out of of whatever notions are tumbling through my subconscious.

Keep it basically simple. What would be the main usecase? comm services
which need to detect each other?

> 
> 	Actually, before writing the last sentence, a different
> 	thought bubbled up out of my subconscious, that I am
> 	apparently re-inventing LDAP, where the stored records have
> 	complex structure with many keyes, attributes, possibly
> 	nesting, and can be searched for by any component. That made
> 	me realize that my questions had put me really well on the
> 	road to higher complexity.

Your basically not only solving similar problems to LDAP/X.500, you also
dabble in the field of UDDI
(http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration)
or even the naming conventions/name discovery used by things like DBUS
or Apples Bonjour/Rendevouzs.


> 	Still. What would we use in the Tcl world as records ? My
> 	guess would be nested dictionaries.

Yes to nested dictionaries for storing the records.

Michael

[Tcllib-devel] JSON package added to tcllib

[Jeff H. <je...@ac...>]

v1.0 with man page, tests and the source.  I also updated
http://wiki.tcl.tk/13419.

Jeff

[Tcllib-devel] Name server (RE: A proposed new package ... Asking for comments.)

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

One of the services I wanted to put into Tcllib, based on the 'safe' comm
foundation
is the primitive nameserver I did years ago, see

	http://www.oche.de/~akupries/soft/pool/f_net_ns_server.tcl.html

Except when I started the docs/spec for the new implementation I found myself
quickly on the road to complexity, because of a number of questions I came up
with in need answers ... For now the doc/spec is quite incomplete and actually
more a set of notes I started to make to organize my thoughts and get something
coherent out of of whatever notions are tumbling through my subconscious.

Below is the relevant section of the spec to be. Question is, how far should I
go in complexity. What is the most simple yet general use case ? In the worst
case I could even do a series of services with different complexities and data
models ... Gods, now I have started thinking about pluggability, one API,
different databases underneath ... Stop! ...

	______________________________________________________________
	The simplest database, relationally speaking, would be a table

	    table {
		  name : string
		  id   : list (host port)
	    }

	This leaves the structure and semantics of 'name' to the
	clients of the service. Not the client objects, but the users
	of these objects.

	Is this the application name ?		Example: Tkcon
	The name of a service provided ?	Example: log

	Do we allow multiple ids per name ? I.e. do we want 'name' to
	be a unique key or not ? What about situation where we have
	multiple instances of a service or application, but 'name' has
	to be unique. Registration then either disallows the multiple
	instances, or the name gets internal structure to distinguish
	between instances. When we have structure it starts to make
	sense to make it explicit, i.e. instead of storing a string
	representation we break it apart and store components
	explicitly. And now we have begun sliding down the slippery
	slope of complexity.

	Actually, before writing the last sentence, a different
	thought bubbled up out of my subconscious, that I am
	apparently re-inventing LDAP, where the stored records have
	complex structure with many keyes, attributes, possibly
	nesting, and can be searched for by any component. That made
	me realize that my questions had put me really well on the
	road to higher complexity.

	Still. What would we use in the Tcl world as records ? My
	guess would be nested dictionaries.
	______________________________________________________________



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


> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Andreas
> Kupries
> Sent: Wednesday, August 16, 2006 9:28 PM
> To: Hemang Lavana; Tcllib Devel
> Subject: Re: [Tcllib-devel] A proposed new package ... Asking for
> comments.
>
>
>
> > > Andreas Kupries wrote:
> > > >
> > > > What is the problem with 'ip' ?
> > > >
> > > Maybe it's just me: when I see ip I think of internet protocol,
> > > intellectual property, etc but never "interp".
> >
> > I see. I could see the second, forgot the first.
> >
> > > Just -events is fine with me.
> >
> > Ok. That it will be.
>
> The new options -interp and -events have been implemented, and the
> testsuite extended as well. Package version is now 4.3.1.
>
> --
> So long,
> 	Andreas Kupries <aku...@sh...>
> 			<http://www.purl.org/NET/akupries/>
> 	Developer @	<http://www.activestate.com/>
> ----------------------------------------------------------------------
> ---------
>
>
> -------------------------------------------------------------------------
> 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] 8.5+ packages?

[Andreas K. <aku...@sh...>]

> On Wed, Aug 16, 2006 at 09:44:05PM -0700, Andreas Kupries wrote:
> 			.
> 			.
> 			.
> > The only packages currently in Tcllib which exclusively require 8.5
> > are version 2 of snit and math::bigfloat. The treeql package has two
> > different implementations for 8.4 and 8.5. Some other packages, like
> > sha1, math::optimize, and struct::list do minor tweaking when loaded
> > into 8.5.
> 			.
> 			.
> 			.
> "The requested URL /~akupries/soft-cvs-snapshots/ was not found on this server."
> Did you know, Andreas, that it's not-found?

It is       /~akupries/soft/cvs-snapshots/
Where is is written as soft-cvs-snapshots ?


> Slight correction:  as I read it, bigfloat requires 8.4, and bigfloat2
> expects 8.5.

Also:

package ifneeded math::bigfloat          1.2   [list source [file join $dir 
bigfloat.tcl]]

if {![package vsatisfies [package provide Tcl] 8.5]} {return}
package ifneeded math::bigfloat          2.0 [list source [file join $dir 
bigfloat2.tcl]]


So bigfloat v2, the package, and bigfloat2, the file.


-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

Re: [Tcllib-devel] 8.5+ packages?

[<Lar...@re...>]

2006-08-17 kl. 06.44 skrev Andreas Kupries:
> Regarding the dict package in AciveTcl, it is possible to write a
> replacement in pure Tcl if we do not wish the dependency. If we do
> that Pascal's 'dict' compat package in ActiveTcl can be an accelerator
> for the pure Tcl version.

The quote below is from =20
http://alphatcl.cvs.sourceforge.net/alphatcl/Tcl/SystemCode/=20
coreFixes.tcl?revision=3D1.215&view=3Dmarkup (line 2219f.). Licence is =20=

Tcl-style. There might be other (better?) pure-Tcl implementations =20
around, though.

/Lars Hellstr=F6m

##
  # =20
------------------------------------------------------------------------=20=

--
  #
  # "dict" -- option arg ?arg ...?
  #
  # Manipulate dictionaries.  Performs one of several operations on =20
dictionary
  # values or variables containing dictionary values.
  #
  # See <http://www.tcl.tk/man/tcl8.5/TclCmd/dict.htm> for more =20
information.
  #
  # =20
------------------------------------------------------------------------=20=

--
  #
  # This is a "poor man's [dict]" -- a pure tcl [dict] emulation.  Very =20=

slow,
  # but complete.  Implementation is based on lists, [array set/get] and
  # recursion.  Similar to Tcl 8.5's [dict] command, abbreviations will =20=

work.
  #
  # Not all error checks are implemented!  e.g.
  #
  #     dict create odd arguments here
  #
  # will work.
  #
  # =20
------------------------------------------------------------------------=20=

--
  ##

if {![llength [info commands dict]]} {
     alpha::stderr {Defining the core command [dict]}

     proc dict {cmd args} {
         set validCmds [list "append" "create" "exists" "filter" "for" \
           "get" "incr" "info" "keys" "lappend" "merge" "remove" \
           "replace" "set" "size" "unset" "update" "values" "with"]
         if {([set idx [lsearch -glob $validCmds "${cmd}*"]] =3D=3D -1)} =
{
             error "bad option \"$cmd\": must be [join $validArgs {, }]"
         }
         set cmd [lindex $validCmds $idx]
         uplevel 1 [linsert $args 0 _dict_$cmd]
     }
     proc _dict_append {dvar key {args}} {
         upvar 1 $dvar dv
         if {![info exists dv]} {
             set dv [list]
         }
         array set dvx $dv
         eval [linsert $args 0 append dvx($key) ]
         set dv [array get dvx]
     }
     proc _dict_create {args} {
         if {([llength $args] % 2)} {
             return -code error \
               {wrong # args: should be "dict create ?key value ...?"}
         }
         return $args
     }
     proc _dict_exists {dv key args} {
         array set dvx $dv
         set r [info exists dvx($key)]
         if {!$r} {
             return 0
         }
         if {[llength $args]} {
             return [eval [linsert $args 0 _dict_exists $dvx($key) ]]
         } else {
             return 1
         }
     }
     proc _dict_filter {dv ftype args} {
         set r [list]
         foreach {globpattern} $args {break}
         foreach {varlist script} $args {break}

         switch $ftype {
             key {
                 foreach {key value} $dv {
                     if {[string match $globpattern $key]} {
                         lappend r $key $value
                     }
                 }
             }
             value {
                 foreach {key value} $dv {
                     if {[string match $globpattern $value]} {
                         lappend r $key $value
                     }
                 }
             }
             script {
                 foreach {Pkey Pval} $varlist {break}
                 upvar 1 $Pkey key $Pval value
                 foreach {key value} $dv {
                     if {[uplevel 1 $script]} {
                         lappend r $key $value
                     }
                 }
             }
             default {
                 error "Wrong filter type"
             }
         }
         return $r
     }
     proc _dict_for {kv dict body} {
         uplevel 1 [list foreach $kv $dict $body]
     }
     proc _dict_get {dv args} {
         if {![llength $args]} {
             return $dv
         } else {
             array set dvx $dv
             set key [lindex $args 0]
             set dv $dvx($key)
             set args [lrange $args 1 end]
             return [eval [linsert $args 0 _dict_get $dv]]
         }
     }
     proc _dict_incr {dvar key {incr 1}} {
         upvar 1 $dvar dv
         if {![info exists dv]} {
             set dv [list]
         }
         array set dvx $dv
         if {![info exists dvx($key)]} {
             set dvx($key) 0
         }
         incr dvx($key) $incr
         set dv [array get dvx]
     }
     proc _dict_info {dv} {
         return "Dictionary is represented as plain list"
     }
     proc _dict_keys {dv {pat *}} {
         array set dvx $dv
         return [array names dvx $pat]
     }
     proc _dict_lappend {dvar key args} {
         upvar 1 $dvar dv
         if {![info exists dv]} {
             set dv [list]
         }
         array set dvx $dv
         eval [linsert $args 0 lappend dvx($key)]
         set dv [array get dvx]
     }
     proc _dict_merge {args} {
         foreach dv $args {
             array set dvx $dv
         }
         array get dvx
     }
     proc _dict_remove {dv args} {
         foreach k $args {
             _dict_unset dv $k
         }
         return $dv
     }
     proc _dict_replace {dv args} {
         if {([llength $args] % 2)} {
             return -code error \
               {wrong # args: should be "dict replace ?key value ...?"}
         }
         foreach {k v} $args {
             _dict_set dv $k $v
         }
         return $dv
     }
     proc _dict_set {dvar key value args } {
         upvar 1 $dvar dv
         if {![info exists dv]} {
             set dv [list]
         }
         array set dvx $dv
         if {![llength $args]} {
             set dvx($key) $value
         } else {
             eval [linsert $args 0 _dict_set dvx($key) $value]
         }
         set dv [array get dvx]
     }
     proc _dict_size {dv} {
         return [expr {[llength $dv]/2}]
     }
     proc _dict_unset {dvar key args} {
         upvar 1 $dvar mydvar
         if {![info exists mydvar]} {
             set mydvar [list]
         }
         array set dv $mydvar
         if {![llength $args]} {
             if {[info exists dv($key)]} {
                 unset dv($key)
             }
         } else {
             eval [linsert $args 0 _dict_unset dv($key) ]
         }
         set mydvar [array get dv]
         return {}
     }
     proc _dict_update {dvar args} {
         set name [string map {: {} ( {} ) {}} $dvar]
         upvar 1 $dvar dv
         upvar 1 _my_dict_array$name local

         array set local $dv
         foreach {k v} [lrange $args 0 end-1] {
             if {[info exists local($k)]} {
                 if {![uplevel 1 [list info exists $v]]} {
                     uplevel 1 [list upvar 0 _my_dict_array${name}($k) =20=

$v]
                 } else {
                     uplevel 1 [list set $v $local($k)]
                 }
             }
         }
         set code [catch {uplevel 1 [lindex $args end]} res]

         foreach {k v} [lrange $args 0 end-1] {
             if {[uplevel 1 [list info exists $v]]} {
                 set local($k) [uplevel 1 [list set $v]]
             } else {
                 unset -nocomplain local($k)
             }
         }
         set dv [array get local]
         unset local

         return -code $code $res
     }
     proc _dict_values {dv {gp *}} {
         set r [list]
         foreach {k v} $dv {
             if {[string match $gp $v]} {
                 lappend r $v
             }
         }
         return $r
     }
     proc _dict_with {dvar script} {
         set name [string map {: {} ( {} ) {}} $dvar]
         upvar 1 $dvar dv
         upvar 1 _my_dict_array$name local

         array set local $dv
         foreach k [array names local] {
             if {[info exists local($k)]} {
                 if {![uplevel 1 [list info exists $k]]} {
                     uplevel 1 [list upvar 0 _my_dict_array${name}($k) =20=

$k]
                 } else {
                     uplevel 1 [list set $k $local($k)]
                 }
             }
         }
         set code [catch {uplevel 1 $script} res]

         foreach k [array names local] {
             if {[uplevel 1 [list info exists $k]]} {
                 set local($k) [uplevel 1 [list set $k]]
             } else {
                 unset -nocomplain local($k)
             }
         }
         set dv [array get local]
         unset local

         return -code $code $res
     }
}

Re: [Tcllib-devel] 8.5+ packages?

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

On Wed, Aug 16, 2006 at 09:44:05PM -0700, Andreas Kupries wrote:
			.
			.
			.
> The only packages currently in Tcllib which exclusively require 8.5
> are version 2 of snit and math::bigfloat. The treeql package has two
> different implementations for 8.4 and 8.5. Some other packages, like
> sha1, math::optimize, and struct::list do minor tweaking when loaded
> into 8.5.
			.
			.
			.
"The requested URL /~akupries/soft-cvs-snapshots/ was not found on this server."
Did you know, Andreas, that it's not-found?

Slight correction:  as I read it, bigfloat requires 8.4, and bigfloat2
expects 8.5.

Re: [Tcllib-devel] 8.5+ packages?

[Andreas K. <aku...@sh...>]

> Any comments on packages that require 8.5 in tcllib so far?  I think 
> this discussion came up, but I couldn't find it.

The only packages currently in Tcllib which exclusively require 8.5
are version 2 of snit and math::bigfloat. The treeql package has two
different implementations for 8.4 and 8.5. Some other packages, like
sha1, math::optimize, and struct::list do minor tweaking when loaded
into 8.5.

 
> I have fixed the JSON parser that is on the wiki, and would like to add 
> it to tcllib.  It uses dict (and it only gets sticky if you don't want 
> to use dict).  I have coded it to fall back on trying to package require 
> dict below 8.5 (ActiveTcl includes dict).

snit v2 uses dict commands as well ...

Regarding the dict package in AciveTcl, it is possible to write a
replacement in pure Tcl if we do not wish the dependency. If we do
that Pascal's 'dict' compat package in ActiveTcl can be an accelerator
for the pure Tcl version.

 
> Any objections to my adding it?

No objection from me.

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

Re: [Tcllib-devel] A proposed new package ... Asking for comments.

[Andreas K. <aku...@sh...>]

> > Andreas Kupries wrote:
> > >
> > > What is the problem with 'ip' ?
> > >
> > Maybe it's just me: when I see ip I think of internet protocol,
> > intellectual property, etc but never "interp".
> 
> I see. I could see the second, forgot the first.
> 
> > Just -events is fine with me.
> 
> Ok. That it will be.

The new options -interp and -events have been implemented, and the
testsuite extended as well. Package version is now 4.3.1.

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

[Tcllib-devel] 8.5+ packages?

[Jeff H. <je...@ac...>]

Any comments on packages that require 8.5 in tcllib so far?  I think 
this discussion came up, but I couldn't find it.

I have fixed the JSON parser that is on the wiki, and would like to add 
it to tcllib.  It uses dict (and it only gets sticky if you don't want 
to use dict).  I have coded it to fall back on trying to package require 
dict below 8.5 (ActiveTcl includes dict).

Any objections to my adding it?

Jeff

[Tcllib-devel] FW: A proposed new package ... Asking for comments.

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

For the record

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

> -----Original Message-----
> From: Donald G Porter [mailto:dg...@ni...]
> Sent: Tuesday, August 15, 2006 5:19 AM
> To: and...@ac...
> Subject: Re: [Tcllib-devel] A proposed new package ... Asking for
> comments.
> 
> 
> > ... I guess it will be an "interp" package in
> > Tcllib. Maybe with overloading the core command, in anticipiation 
> of the move
> > you proposed. Yes.
> 
> I don't think any package should replace any core commands.  Just have
> the package create an alternative extended version of the command, and
> permit each caller module to [namespace import] the one that suits them.
> 
> | Don Porter          Mathematical and Computational Sciences Division |
> | don...@ni...             Information Technology Laboratory |
> | http://math.nist.gov/~DPorter/                                  NIST |
> |______________________________________________________________________|

Re: [Tcllib-devel] A proposed new package ... Asking for comments.

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

> Andreas Kupries wrote:
> >
> > What is the problem with 'ip' ?
> >
> Maybe it's just me: when I see ip I think of internet protocol,
> intellectual property, etc but never "interp".

I see. I could see the second, forgot the first.

> Just -events is fine with me.

Ok. That it will be.

> >>> The protocol command of the original proposal also reduces to 'create
> >>> an empty interpreter and set aliases into it'. For the case of linking
> >>> the aliases to a second interpreter 'interp alias' is still the best
> >>> way of doing it, reducing this further to 'create an empty interp'. We
> >>> can do a command for that, this is however quite general and unrelated
> >>> to comm. Anybody with an idea where to place such command ? (Maybe a
> >>> package "interp" ?)
> >>>
> >>>
> >> Can you provide an example of how you intend to use this. As such, it
> >> could be just a sub-command "comm::comm link ..." but I can't say much
> >> without understanding how it is going to be used.
> >>
> [thanks for the examples]
>
> Ok, now I understand and agree that it is completely unrelated to comm
> package. One possibility is to extend the [interp create] itself to
> support a -empty option. It already supports -safe option and a -empty
> option would restrict it even further by creating an empty interpreter.

True. However right now I wish to keep this in pure Tcl. Moving stuff like that
into the core can come later. ... I guess it will be an "interp" package in
Tcllib. Maybe with overloading the core command, in anticipiation of the move
you proposed. Yes.

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

Re: [Tcllib-devel] A proposed new package ... Asking for comments.

[Hemang L. <hl...@ci...>]

Andreas Kupries wrote:
>
> What is the problem with 'ip' ?
>   
Maybe it's just me: when I see ip I think of internet protocol,
intellectual property, etc but never "interp". Just -events is fine with me.
>   
>>> The protocol command of the original proposal also reduces to 'create
>>> an empty interpreter and set aliases into it'. For the case of linking
>>> the aliases to a second interpreter 'interp alias' is still the best
>>> way of doing it, reducing this further to 'create an empty interp'. We
>>> can do a command for that, this is however quite general and unrelated
>>> to comm. Anybody with an idea where to place such command ? (Maybe a
>>> package "interp" ?)
>>>   
>>>       
>> Can you provide an example of how you intend to use this. As such, it
>> could be just a sub-command "comm::comm link ..." but I can't say much
>> without understanding how it is going to be used.
>>     
[thanks for the examples]

Ok, now I understand and agree that it is completely unrelated to comm
package. One possibility is to extend the [interp create] itself to
support a -empty option. It already supports -safe option and a -empty
option would restrict it even further by creating an empty interpreter.

Hemang.

Re: [Tcllib-devel] A proposed new package ... Asking for comments.

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

> > > >        comm::comm new FOO -interp [interp create -safe]
> > > > or     comm::comm new FOO -interp [safe::interpCreate]
> > > >   
> > > Looks good. Just rename -ipevents option to -interp_events or 
> > > -ievents.
> > 
> > What is the problem with 'ip' ?
> 
> 'ip' has different achronym connotations. Just using -events would work as
> well, since it is contextual.

Of the three -interp_events, -ievents, and -events I like the last one best.

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

Re: [Tcllib-devel] A proposed new package ... Asking for comments.

[Jeff H. <je...@ac...>]

Andreas Kupries wrote:
> > Andreas Kupries wrote:
> > > The new proposal basically provides communication channels with an 
> > > option to set an interpreter for execution. This is the link command 
> > > of the original proposal. The implementations of safeBasic and safe 
> > > commands of the original become so trivial in the new scheme that 
> > > providing special commands for them is not worthwhile. I.e.
> > >
> > >        comm::comm new FOO -interp [interp create -safe]
> > > or     comm::comm new FOO -interp [safe::interpCreate]
> > >   
> > Looks good. Just rename -ipevents option to -interp_events or 
> > -ievents.
> 
> What is the problem with 'ip' ?

'ip' has different achronym connotations.  Just using -events would work as
well, since it is contextual.

Jeff

Re: [Tcllib-devel] A proposed new package ... Asking for comments.

[Andreas K. <aku...@sh...>]

> Andreas Kupries wrote:
> > The new proposal basically provides communication channels with an
> > option to set an interpreter for execution. This is the link command
> > of the original proposal. The implementations of safeBasic and safe
> > commands of the original become so trivial in the new scheme that
> > providing special commands for them is not worthwhile. I.e.
> >
> >        comm::comm new FOO -interp [interp create -safe]
> > or     comm::comm new FOO -interp [safe::interpCreate]
> >   
> Looks good. Just rename -ipevents option to -interp_events or
> -ievents.

What is the problem with 'ip' ?

> > The protocol command of the original proposal also reduces to 'create
> > an empty interpreter and set aliases into it'. For the case of linking
> > the aliases to a second interpreter 'interp alias' is still the best
> > way of doing it, reducing this further to 'create an empty interp'. We
> > can do a command for that, this is however quite general and unrelated
> > to comm. Anybody with an idea where to place such command ? (Maybe a
> > package "interp" ?)
> >   
> Can you provide an example of how you intend to use this. As such, it
> could be just a sub-command "comm::comm link ..." but I can't say much
> without understanding how it is going to be used.

The case of 'create an empty interpreter and set aliases into it',
subcase 'the are aliases into the main interp, and a snit object'

snit::type FOO {

    component comm

    constructor {...} {
        set comm [comm::comm new ${selfns}::comm \
	    -interp [XXXX $self {list of methods}]]
	return
    }

}

where XXXX is the command creating a an interpreter, clearing it of
all commands, procedures, and namespaces, and then creating aliases
for all methods in the list which redirect the commands to the newly
created FOO instance.


The other case, 'create an empty interp' is for the general case,
where the aliases go into some other interpreter, and not an object.

    set empty [XXXX]
    set execution [interp create ...]
    interp alias $empty .... $execution ...
    ...
    comm::comm new FOO -interp $empty

Here XXXX is the command to create an interpreter and clear it of all
commands, procedures, and namespaces.



> > +
> > +This isecure setup can be changed by the user via the two options
> >   
> Typo: isecure -> insecure.

Fixed in my local copy.

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

Re: [Tcllib-devel] A proposed new package ... Asking for comments.

[Hemang L. <hl...@ci...>]

Andreas Kupries wrote:
> The new proposal basically provides communication channels with an
> option to set an interpreter for execution. This is the link command
> of the original proposal. The implementations of safeBasic and safe
> commands of the original become so trivial in the new scheme that
> providing special commands for them is not worthwhile. I.e.
>
>        comm::comm new FOO -interp [interp create -safe]
> or     comm::comm new FOO -interp [safe::interpCreate]
>   
Looks good. Just rename -ipevents option to -interp_events or -ievents.
> The protocol command of the original proposal also reduces to 'create
> an empty interpreter and set aliases into it'. For the case of linking
> the aliases to a second interpreter 'interp alias' is still the best
> way of doing it, reducing this further to 'create an empty interp'. We
> can do a command for that, this is however quite general and unrelated
> to comm. Anybody with an idea where to place such command ? (Maybe a
> package "interp" ?)
>   
Can you provide an example of how you intend to use this. As such, it
could be just a sub-command "comm::comm link ..." but I can't say much
without understanding how it is going to be used.
> +
> +This isecure setup can be changed by the user via the two options
>   
Typo: isecure -> insecure.

Hemang.

Re: [Tcllib-devel] A proposed new package ... Asking for comments.

[Andreas K. <aku...@sh...>]

> Andreas Kupries wrote:
> >
> > I am still not convinced. Maybe we have simply too different visions for what we
> > want to do with this.
> >
> > When I wrote these commands I wanted to have convenient setup functionality
> > specifically for and only for the eval hook. The other hooks simply did not
> > enter the picture, they were out of scope. To put them into scope I need a very
> > clear picture/vision on how they are used in such a situation.

[explanation and examples snipped -- Thank you for them]

I have now redone my proposal under the assumption that it becomes new
features of comm itself ... This collapsed and removed most of the
stuff in the original proposal. 

The new proposal basically provides communication channels with an
option to set an interpreter for execution. This is the link command
of the original proposal. The implementations of safeBasic and safe
commands of the original become so trivial in the new scheme that
providing special commands for them is not worthwhile. I.e.

       comm::comm new FOO -interp [interp create -safe]
or     comm::comm new FOO -interp [safe::interpCreate]

The protocol command of the original proposal also reduces to 'create
an empty interpreter and set aliases into it'. For the case of linking
the aliases to a second interpreter 'interp alias' is still the best
way of doing it, reducing this further to 'create an empty interp'. We
can do a command for that, this is however quite general and unrelated
to comm. Anybody with an idea where to place such command ? (Maybe a
package "interp" ?)

Still, the use case of linking the execution interpreter to a snit
object may warrant a command to make this easier. Create empty interp,
link to method in the object, specified through a list of names. Or a
snit type ... snit::comm-listener, snit::comm, snit::listener, ... ?


Here is the documentation of the new features of comm. Note that there
is a second option to control the execution of event/hook scripts, for Hemang

_______________________________________________________________________________
--- comm.man.orig	2005-10-03 21:03:19.000000000 -0700
+++ comm.man	2006-08-11 23:16:24.000000000 -0700
@@ -185,6 +185,9 @@
 [lst_item "[option -local]  [opt [arg 0|1]]"]
 [lst_item "[option -port]   [opt [arg port]]"]
 [lst_item "[option -silent] [opt [arg 0|1]]"]
+
+[lst_item "[option -interp]   [opt [arg interpreter]]"]
+[lst_item "[option -ipevents] [opt [arg eventlist]]"]
 [list_end]
 
 [para]
@@ -198,11 +201,12 @@
 
 [para]
 
-When [cmd config] changes the parameters of an existing channel, it
-closes and reopens the listening socket.  An automatically assigned
-channel [emph id] will change when this happens.  Recycling the socket
-is done by invoking [cmd {::comm::comm abort}], which causes all
-active sends to terminate.
+When [cmd config] changes the parameters of an existing channel (with
+the exception of [option -interp] and [option -ipevents]), it closes
+and reopens the listening socket. An automatically assigned channel
+[emph id] will change when this happens. Recycling the socket is done
+by invoking [cmd {::comm::comm abort}], which causes all active sends
+to terminate.
 
 [subsection {ID/PORT ASSIGNMENTS}]
 [para]
@@ -238,6 +242,51 @@
 attempts where the protocol negotiation phase failed, instead of
 throwing an error.
 
+[subsection {EXECUTION ENVIRONMENT}]
+
+A communication channel in its default configuration will use the
+current interpreter for the execution of all received scripts, and of
+the event scripts associated with the various hooks.
+
+[para]
+
+This isecure setup can be changed by the user via the two options
+[option -interp], and [option -ipevents].
+
+[para]
+
+When [option -interp] is set all received scripts are executed in the
+slave interpreter specified as the value of the option. This
+interpreter is expected to exist before configuration. I.e. it is the
+responsibility of the user to create it. However afterward the
+communication channel takes ownership of this interpreter, and will
+destroy it when the communication channel is destroyed.
+
+Note that reconfiguration of the communication channel to either a
+different interpreter or the empty string will release the ownership
+[emph without] destroying the previously configured interpreter.  The
+empty string has a special meaning, it restores the default behaviour
+of executing received scripts in the current interpreter.
+
+[para]
+
+[emph {Also of note}] is that replies and callbacks (a special form of
+reply) are [emph not] considered as received scripts. They are
+trusted, part of the internal machinery of comm, and therefore always
+executed in the current interpreter.
+
+[para]
+
+Even if an interpreter has been configured as the execution
+environment for received scripts the event scripts associated with the
+various hooks will by default still be executed in the current
+interpreter. To change this use the option [option -ipevents] to
+declare a list of the events whose scripts should be executed in the
+declared interpreter as well. The contents of this option are ignored
+if the communication channel is configured to execute received scripts
+in the current interpreter.
+
+
 [subsection {REMOTE INTERPRETERS}]
 [para]
 
_______________________________________________________________________________

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

Re: [Tcllib-devel] A proposed new package ... Asking for comments.

[Hemang L. <hl...@ci...>]

Andreas Kupries wrote:
>
> I am still not convinced. Maybe we have simply too different visions for what we
> want to do with this.
>
> When I wrote these commands I wanted to have convenient setup functionality
> specifically for and only for the eval hook. The other hooks simply did not
> enter the picture, they were out of scope. To put them into scope I need a very
> clear picture/vision on how they are used in such a situation.

I have one server process and several client processes which are
connected via comm channels. The server process is the master which
hands off commands to execute on the client processes and keeps track of
their execution progress in a global array. Each client is identified by
a unique name and periodically sends signals to the server process to
indicate its status. Sometimes a client process may get terminated
either gracefully or abnormally say via kill command invoked by the
user. The master process will know about it via "lost connection" hook
and will perform cleanup. For debugging purposes, I use tcllib's logger
package in the eval hook -- ${log}::debug API to print the name of the
client, the status of global array for the corresponding client and the
commands it has received over the comm channel. See below:


    # Setup event handler to do a cleanup whenever any socket
    # connection to the client process is lost.
    ::comm::comm hook lost "::foo::_cleanup \$id [list $client_id]"

    # Log all commands before evaluating them
    ::comm::comm hook eval {::foo::log::debug "Cmd eval: $buffer id:
$client_id\n\[parray data($client_id)]"}

    # Log all command replies before evaluating them
    ::comm::comm hook reply {::foo::log::debug "Cmd reply: $buffer id:
$client_id\n\[parray data($client_id)]"}

With your proposal for comm/interp enhancements, I can use it to
restrict the commands executed by the clients in the master process. I
hope you get the idea.

Hemang.