tcllib-devel — Discussion of development for tcllib

FW: [Tcllib-devel] Http module, organization of modules

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

-----Original Message-----
From: Joe English [mailto:jen...@fl...]
Sent: Friday, February 01, 2002 11:46 AM
To: Andreas Kupries
Subject: Re: [Tcllib-devel] Http module, organization of modules



On tcllib-devel, you wrote:
>
> 	I like and endorse the proposal of having a base http package
> 	distributed with tcl and an expanded version in tcllib. [...]
> [...]
> Anybody else out there agreeing or disagreeing with me ?

I think this would be a good idea.


> My second topic is the internal organization of the tcllib modules
> directory. Currently we have a flat directory approach where all
> modules are immediate siblings of each other. I begin to believe
> that modules is becoming a bit crowded now and that we should try
> and organize the modules in a more hierarchical fashion. [...]

That too.

One attempt to organize the modules is the TOC at
<URL: http://tcllib.sourceforge.net/doc/ >, though
I'm not entirely happy with that structure either.

I like the idea of putting all the hash packages in a
single category.


--Joe English

  jen...@fl...



--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com

Re: [Tcllib-devel] Http module, organization of modules

[Donald G P. <dg...@em...>]

> I begin to believe
> that modules is becoming a bit crowded now and that we should try
> and organize the modules in a more hierarchical fashion.

It doesn't matter much to me how the directories of the source
distribution form of tcllib are laid out.

When it comes to installation directory layout and namespace
hierarchies, though, I think hierarchies should only exist when there
is a corresponding package dependency.  If there is no dependency
relationship between packages A and B, they should be installed
in sibling directories and given namespaces that are children
of the global namespace so that one or the other can be loaded
into an interp (or installed) without caring whether the other
one is as well.

Note that I'm not claiming the converse.

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

Re: [Tcllib-devel] Http module, organization of modules

[Larry W. V. <lv...@ca...>]

I myself would prefer to see the code remain in one place.  If the Tcl
core distribution is not going to be a 'Batteries Included' type tar/zip
file, then I myself would prefer to see http/windows/mac/etc. specific
stuff - things unrelated to tcl itself, moved out of the tcl distribution
and into tcllib, etc.

I think that having two http packages - one in the core and one in tcllib -
is just going to make things confusing.
-- 
Never apply a Star Trek solution to a Babylon 5 problem.
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.
-><-

[Tcllib-devel] Http module, organization of modules

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

Regarding the latest thread on c.l.t about support for HTTP/1.1
in the http package distributed with tcl.

	I like and endorse the proposal of having a base http package
	distributed	with tcl and an expanded version in tcllib. I always
	wanted to have support for http in tcllib to get a more complete
	set of supported protocols but was also loath to move http.

	That way we get http in tcllib without leaving users of the core
	distribution hanging in the wind.

Anybody else out there agreeing or disagreeing with me ?


My second topic is the internal organization of the tcllib modules
directory. Currently we have a flat directory approach where all
modules are immediate siblings of each other. I begin to believe
that modules is becoming a bit crowded now and that we should try
and organize the modules in a more hierarchical fashion. Examples:

*	The modules md5, sha1, crc all generate a hash
	and could be placed into a directory 'hash'.

*	nntp, pop3, mime (smtp), ftp, ftpd, smtpd
	all deal with networt protocols. A directory for
	them could be 'net', 'inet', 'network', or similar.

Partially we are seeing such aggregation already, albeit done in a
different fashion: One module directroy containing several packages,
either independent (mime), or in hierarchically organized namespaces
(math, textutil).

And yes, the proposed reorg. of the directory structure below 'modules'
might be a precursor to a reorg. of the packages names to make more use
of hierarchical namespaces.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com

RE: [Tcllib-devel] Tcllib development and release policy discussion ...

[Jeff H. <Je...@Ac...>]

I think that you are asking for a lot of extra management work
that will in the end be placed on the maintainer without a very
significant benefit.  Was the current system to anarchic to
find good checkpoints?

Jeff

> *	Whenever a maintainer for a module and/or package is
> 	satisified with the current state of his module/package
> 	an internal release is done which merges the relevant
> 	parts of the HEAD into RELEASE.
> 
> 	After the internal release the version number of the merged
> 	packages and/or modules is incremented to distinguish the
> 	current development version from the released version.
> 
> 	For each internal release the developer doing the release
> 	has to add a note to the file MERGES (in the RELEASE branch).
> 
> *	The release manager (RM) of tcllib uses the MERGES file to
> 	determine if enough or important changes have accumulated
> 	to warrant a patch, minor, or major release of Tcllib itself.

[Tcllib-devel] bwidget-1-4-0 tagged

[Jeff H. <Je...@Ac...>]

see subject ...

RE: [Tcllib-devel] Looking for htmlparse help

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

I would modify treeprint so that it (or rather the big switch you
see) ignores everything except PCDATA, and also change the code in
that section to print the data completely instead of logging only
the first twenty characters.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com

> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Larry W.
> Virden
> Sent: Tuesday, January 22, 2002 8:11 AM
> To: Tcllib Development
> Subject: [Tcllib-devel] Looking for htmlparse help
>
>
> Hello,
> I have cobbled together a small script that demonstrates a technique I =
am
> trying.
>
> The goal - given a 'page' of html, I would like to print out the text
> portion of the page.
>
> Here's my script and the output I have so far:
>
>
> $ cat trial.tcl
>    package require http
>    package require htmlparse
>    package require struct
>    package require textutil
>    package require log
>
> proc treeprint {t n} {
>     set  tp  [$t get $n -key type]
>     set  d   [$t depth $n]
>     set idx ""
>     catch {set  idx [$t index $n]}
>     incr d  $d
>     incr d  $d
>
>     switch -exact -- $tp {
>         a {
>             log::log debug "[textutil::strRepeat " " $d]$idx $tp
> ([$t get $n -key data]...)"
>         }
>         PCDATA {
>             log::log debug "[textutil::strRepeat " " $d]$idx $tp
> ([string range [$t get $n -key data] 0 20]...)"
>         }
>         default {
>             log::log debug "[textutil::strRepeat " " $d]$idx $tp"
>         }
>     }
> }
>
>    set html {<HTML><BODY><hr>test &eacute;<br>data</BODY></HTML>}
>
>    # Convert the resulting html
>
>    set html2 [::htmlparse::mapEscapes $html]
>     ::struct::tree::tree t
>    ::htmlparse::2tree $html t
>    ::htmlparse::removeVisualFluff t
>    ::htmlparse::removeFormDefs t
>
>    puts $html
>    puts $html2
>
>    # what do I put here to see the resulting $t ?
>    t walk root -command {treeprint %t %n}
> $ /usr/tcl84/bin/tclsh trial.tcl
> <HTML><BODY><hr>test &eacute;<br>data</BODY></HTML>
> <HTML><BODY><hr>test =E9<br>data</BODY></HTML>
> debug      root
> debug         0 body
> debug             0 hr
> debug                 0 PCDATA (test &eacute;...)
> debug             1 br
> debug             2 PCDATA (data...)
>
> So I am getting pretty close.  Can someone give me a tip as how I could
> get just those PCDATA types and then get out just the text information?
> --
> Never apply a Star Trek solution to a Babylon 5 problem.
> 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.
-><-

_______________________________________________
Tcllib-devel mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcllib-devel

[Tcllib-devel] Looking for htmlparse help

[Larry W. V. <lv...@ca...>]

Hello,
I have cobbled together a small script that demonstrates a technique I am
trying.

The goal - given a 'page' of html, I would like to print out the text
portion of the page.

Here's my script and the output I have so far:


$ cat trial.tcl
   package require http
   package require htmlparse
   package require struct
   package require textutil
   package require log

proc treeprint {t n} {
    set  tp  [$t get $n -key type]
    set  d   [$t depth $n]
    set idx ""
    catch {set  idx [$t index $n]}
    incr d  $d
    incr d  $d

    switch -exact -- $tp {
        a {
            log::log debug "[textutil::strRepeat " " $d]$idx $tp ([$t get $n -key data]...)"
        }
        PCDATA {
            log::log debug "[textutil::strRepeat " " $d]$idx $tp ([string range [$t get $n -key data] 0 20]...)"
        }
        default {
            log::log debug "[textutil::strRepeat " " $d]$idx $tp"
        }
    }
}

   set html {<HTML><BODY><hr>test &eacute;<br>data</BODY></HTML>}

   # Convert the resulting html

   set html2 [::htmlparse::mapEscapes $html]
    ::struct::tree::tree t
   ::htmlparse::2tree $html t
   ::htmlparse::removeVisualFluff t
   ::htmlparse::removeFormDefs t

   puts $html
   puts $html2

   # what do I put here to see the resulting $t ?
   t walk root -command {treeprint %t %n}
$ /usr/tcl84/bin/tclsh trial.tcl
<HTML><BODY><hr>test &eacute;<br>data</BODY></HTML>
<HTML><BODY><hr>test é<br>data</BODY></HTML>
debug      root
debug         0 body
debug             0 hr
debug                 0 PCDATA (test &eacute;...)
debug             1 br
debug             2 PCDATA (data...)

So I am getting pretty close.  Can someone give me a tip as how I could
get just those PCDATA types and then get out just the text information?
-- 
Never apply a Star Trek solution to a Babylon 5 problem.
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] Tcllib 1.2 released

[Reinhard M. <ma...@su...>]

On Mon, 21 Jan 2002 at 08:54, Andreas Kupries wrote:

> Solution(s)
> 	I see no real problem in adding the build system back into the
> 	released source distribution. Neither in changing the 'dist'
> 	command to use the same archive and directory names as before.
>
> 	I would not make this a 1.2.1 release. Rather regenerate the
> 	archives currently placed on SF.

Great, thanks.

>  .. No downloads yet.

I've downloaded it twice today. This must be either a bug of the SF
software or they update the statistics only once a day or so.

cu
	Reinhard

RE: [Tcllib-devel] Tcllib 1.2 released

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

> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Reinhard
> Max
> Sent: Monday, January 21, 2002 4:08 AM
> To: Andreas Kupries
> Cc: Tcllib Development
> Subject: Re: [Tcllib-devel] Tcllib 1.2 released
> 
> 
> Hi Andreas,
> 
> thanks, for creating this release just in time for being included in
> SuSE Linux 8.0 :)
> 
> But let me ask a few questions about it:
> 
> 1. Why is the build system (configure, Makefile.in, etc.) not included
> anymore? I noticed install.sh, but that doesn't suffice the needs of
> current LSB and FHS complient Linux distributions, because they need
> 
> 	./configure --prefix=/usr --mandir=/usr/share/man
> 
> Although I could patch install.sh to fit my needs it would be more
> convenient to have the build system at hand.
> 
> 2. Is it intentional, that the naming scheme has changed? Name and
> version of the archive and the top level directory inside it used to
> be separated by a dash.
> 
> cu
> 	Reinhard

(General comments)

	Most of the changes come from the fact that I started out with
	the makefile target 'dist'.

	In the earlier releases Bob essentially took the raw sources from
	the CVS, generated the install scripts and zipped this then up.

	Unfortunately the generated install scripts would not work with a
	raw distribution, because of the different directory structure.

	In my effort to make this easier and to unify things I modified
	the 'dist' target. Instead of creating a completely different
	directory structure I basically create a copy of the raw sources
	with selected parts removed.

(Ad 1)
	Given the install scripts I had seen no need for them anymore.
	Thanks for pointing out my error.

(Ad 2)
	Not intentional. I neither touched the commands in 'make dist'
	which create the toplevel directory for the archives nor the
	ones actually generating the archives.

	I missed the fact that they were not the same ones as used by
	Bob for the earlier releases.


Solution(s)
	I see no real problem in adding the build system back into the
	released source distribution. Neither in changing the 'dist'
	command to use the same archive and directory names as before.

	I would not make this a 1.2.1 release. Rather regenerate the
	archives currently placed on SF. .. No downloads yet.



--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com

Re: [Tcllib-devel] Tcllib 1.2 released

[Reinhard M. <ma...@su...>]

Hi Andreas,

thanks, for creating this release just in time for being included in
SuSE Linux 8.0 :)

But let me ask a few questions about it:

1. Why is the build system (configure, Makefile.in, etc.) not included
anymore? I noticed install.sh, but that doesn't suffice the needs of
current LSB and FHS complient Linux distributions, because they need

	./configure --prefix=/usr --mandir=/usr/share/man

Although I could patch install.sh to fit my needs it would be more
convenient to have the build system at hand.

2. Is it intentional, that the naming scheme has changed? Name and
version of the archive and the top level directory inside it used to
be separated by a dash.

cu
	Reinhard

[Tcllib-devel] Tcllib 1.2 released

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

Tcllib resides at
	http://sourceforge.net/projects/tcllib/

Please report bugs at
	http://sourceforge.net/tracker/?group_id=12883&atid=112883

The distribution archives for this release are available at

    http://sourceforge.net/project/showfiles.php?group_id=12883&release_id=7097
3

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Changes since the last release 1.1:

2002-01-20  Andreas Kupries  <and...@us...>

	* Tagging branch tcllib-1-2-0 as subbranch of RELEASES now.
	  This fixes the release.

	* Tagged branch RELEASES. control/rswitch is not officially
	  released according to Don Porter, and thus not part of this
	  branch. Additional documentation about its usage will be added
	  to the HEAD branch.

	* control 0.1 was never released, bumping version back to this.

2002-01-18  Andreas Kupries  <and...@us...>
	
	* Bumped version to 1.2, new release. Summary of changes here. See
	  the individual Changelogs to see the detailed changes in each
	  module.

	  New modules: calendar, crc, doctools, irc, smtpd, and stooop.

	  calendar:	Version is	0.1
	  crc:		Version is	1.0
	  doctools:	Version is	1.0
	  irc:		Version is	0.1
	  smtpd:	Version is	1.0
	  stooop:	Version is	4.3

	  Changed modules: base64, comm, control, csv, fileutil, ftp,
	  html, math, mime, ncgi, nntp, pop3, struct, textutil, and uri.

	  base64:	Version stays @	2.2, but got new subpackage.
	  comm:		Version up to	3.7.1
	  control:	Version up to	0.2
	  csv:		Version up to	0.2
	  fileutil:	Version up to	1.3
	  ftp:		Version up to	2.3
	  html:		Version up to	1.2
	  math:		Version up to	1.2
	  mime:		Version up to	1.3.1
	  ncgi:		Version up to	1.2.1
	  nntp:		Version up to	0.2
	  pop3:		Version up to	1.5.1
	  struct:	Version up to	1.2
	  textutil:	Version up to	0.4
	  uri:		Version up to	1.1

2002-01-18  Andreas Kupries  <and...@us...>

	* Makefile.in (dist): Fixed bug #495976.

2002-01-17  Pat Thoyts  <pat...@us...>

	* crc module: added sum manual page
	* base64 module: added uuencode manual page

2002-01-17  Andreas Kupries  <and...@us...>

	* examples/csv/csvdiff: New example for csv module. FR #485717.

	* mime: Fixed bug #499242.

2002-01-16  Andreas Kupries  <and...@us...>

	* mime: Implemented FR #503336
 	* ftp:  Fixed bug #503471.
	* nntp: Fixed bug #502250

2002-01-16  Pat Thoyts  <pat...@us...>

	* base64 module: added uuencode package
	* crc module: added sum and cksum packages.

2002-01-11  Pat Thoyts  <pat...@us...>

	* mkInstallScripts.tcl:
	* Makefile.in: Added crc and smtpd modules to the installation files.
	
2002-01-11  Kevin Kenny  <ke...@us...>

	* mkInstallScripts.tcl: Changed the installation process for
	Windows to avoid the unimplemented [file permissions] in favor of
	[file attributes].
	
2002-01-11  Kevin Kenny  <ke...@us...>

	* New module: calendar.
	
2002-01-11  Pat Thoyts  <pat...@us...>

	* New module: crc. From patch #501339

2002-01-11  Andreas Kupries  <and...@us...>

	* Makefile.in (install-doc): Fixed bug #500655. Using the code
	  from the tcl "Makefile.in" as template equivalent code for
	  tcllib was created and added to the file "Makefile.in". The
	  modified makefile now includes the contents of "man.macros" into
	  every installed manpage.

	* html: Applied patch #484117.

2001-12-14  Andreas Kupries  <and...@us...>

	* New module: doctools. FR #492234.

2001-12-13  Andreas Kupries  <and...@us...>

	* texturil: Applied patch #492156.

2001-12-11  Andreas Kupries  <and...@us...>

	* pop3:     Bugfix for item #490151.

	* textutil: Bugfix for item #476988.

2001-12-10  Andreas Kupries  <and...@us...>

	* textutil: Update from William, 'evalcmd' callback.

2001-12-06  Andreas Kupries  <and...@us...>

	* fileutil: Bugfix for item #486572.

2001-11-28  Reinhard Max  <ma...@su...>

	* split.tcl: Speed improvement.

2001-11-23  Andreas Kupries  <and...@us...>

	* struct.matrix: Implemented FR #481022.

2001-11-19  Andreas Kupries  <and...@us...>

	* irc: Added IRC example to examples section. Patch #481479.

	* struct/graph: Applied patch #483125
	
	* smtpd: Example consolidation: Moved the smtpd example to
	  'examples' directory.

	* ftp: Implemented FR #481161.

	* ftpd: Added example ftp server used for testing the
	  functionality of FR #481161.

2001-11-17  Pat Thoyts  <pat...@us...>

	* smtpd: New module.

2001-11-16  Andreas Kupries  <and...@us...>

	* csv: Applied patch #482570.

	* comm: Fixed bug #480227.

	* ftp, uri: Implemented FR #476804.

	* ftp: Applied patch #428053.

2001-11-12  Andreas Kupries  <and...@us...>

	* irc: New module. Internet protocol handling. Internet Relay Chat
	  (IRC). Author David N. Welton <da...@de...>.

	* examples/nntp: Moved example applications out of the nntp module
	  into the example space.

	* examples/ftpd: Moved example applications out of the ftpd module
	  into the example space.

	* examples/ftp: Moved example applications out of the ftp module
	  into the example space.

	* csv: Implemented FR #481023.

	* textutil: Added 'expander' code by William H. Duquette
	  <wi...@wj...>. Added option -strictlength to
	  adjust. Code by Dan Kuchler <da...@ku...>.

2001-11-09  Joe English  <jen...@us...>

	* comm: Replaced nroff macro trickery in comm.n manpage.

2001-11-07  Andreas Kupries  <and...@us...>

	* mime: Fixed bug #479174.

	* mkInstallScripts.tcl: Added code to install tclIndex files.

	* Makefile.in (install-libraries, dist): Added commands to copy
	  'tclIndex' files into installation and distribution. This fixes
	  the remainder of #475846.
	  (dist): Fixed error in generation of tar/zip files too.

2001-11-07  Andreas Kupries  <and...@us...>

	* examples/ftp/ftpvalid: New example, using ftp and uri
	  modules. Validation of ftp urls.

	* fileutil: Accepted Patch #477805.
	* ftp:      Accepted Patch #478478.

2001-11-07  Reinhard Max  <ma...@su...>

	* control: added implementation for a 'do ... while/until' loop.

2001-11-04  Andreas Kupries  <and...@us...>

	* ftp: Fixed bug #476729.

2001-11-01  Andreas Kupries  <and...@us...>

	* mime: Fixed bugs #477088, #472009.

2001-10-21  Andreas Kupries  <and...@us...>

	* uri: Accepted patch #470211.

2001-10-20  Andreas Kupries  <and...@us...>

	* ncgi: Fixed bug #464560.
	* ftp:  Fixed bug #466746.

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

[Tcllib-devel] Tcllib development and release policy discussion ...

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

At the end of this mail is a discussion Don Porter and I had on the
Tcl'ers Chat today. The gist of the discussion (and also proposed
modus operandi for the future) is:

*	Create a branch named RELEASE, now.

*	All future development on tcllib happens in the branch HEAD
	(or developer-derived subbranches of HEAD)

*	Whenever a maintainer for a module and/or package is
	satisified with the current state of his module/package
	an internal release is done which merges the relevant
	parts of the HEAD into RELEASE.

	After the internal release the version number of the merged
	packages and/or modules is incremented to distinguish the
	current development version from the released version.

	For each internal release the developer doing the release
	has to add a note to the file MERGES (in the RELEASE branch).

*	The release manager (RM) of tcllib uses the MERGES file to
	determine if enough or important changes have accumulated
	to warrant a patch, minor, or major release of Tcllib itself.

	When doing such a release the RM

	-	branches the new release of RELEASES
	-	updates the version information in the new branch
	-	and generates distributions.

We are not yet quite on the same page when it comes to the version
number of Tcllib itself.

Diagram ...

	----\-----------\------------------------ HEAD
	     \           \ aperiodic merges
		\           V
             \------\-----------\-------------- RELEASES
                     \           \
                     tcllib-1.2   tcllib-x.y


If there is no veto, or a better idea, this model will start just
before tagging 1.2.


--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dgp	aku here?
steveo	later all, everyone have a good weekend!
	steveo has left the chat!
aku	I'm here
dgp	I'm bumping control back to 0.1.
aku	Reason ?
tclguy	what went wrong?
dgp	control 0.1 has never been released.
aku	Not even as part of Tcllib 1.1 ?
tclguy	ah, who cares about the start number though.
dgp	tcllib 1.1 included control 0(.0)
aku	Oh.
aku	Sure, do it. It is not tagged yet.
dgp	This is the issue we need to sort out about releases of the packages in
tcllib.
dgp	It's unlikely that all packages will be in releasable state at the same
time.
dgp	Unless they're all stagnant.
tclguy	how so
dgp	So, we need a branch where we can do development, and then be able to
internally "release" them as able to be included in tcllib releases.
tclguy	ah, well that's ok.
dgp	As an example, I'd prefer that control::rswitch not be included in any
real releases.
dgp	But I do want it on the HEAD so we can keep working on it.
aku	So we should have HEAD for development, and also a general RELEASE
branch and for each new release things are merged from HEAD to RELEASE,
tagged and new branch created for that particular release ?
dgp	Yes.
dgp	I'd say that as the "co-ordinator" of tcllib, your job would be just to
package up the tip of the RELEASE branch, on whatever time-table is good for
you.
dgp	Then each package maintainer can decide when they've got a stable
snapshot to move over to RELEASE, completely asynchronously with tcllibs's
release schedule.
aku	And the developers do the merges at their leisure.
aku	cross-message
dgp	I've meant to get this mentioned several times, but my focus hasn't been
on tcllib lately. Sorry.
aku	Whe should have a file where maintainers record the merges they have
done since the last release of the RELEASE branch. That way the release
manager just has to look there to decide if there is enough for a new
release.
aku	Well, we can start after 1.2 using that scheme if the others agree. I
will post to tcllib-devel.
dgp	Makes sense to me.  Also, the tcllib RM might have to "beat the bushes"
if there's been no new release for a while, yet new features are on the
HEAD.
dgp	On the version number, I like the pattern of bumping numbers right after
a release so that CVS snapshots are distintinguished from released versions
by [package].
dgp	For tcllib 1.2, is it too much trouble to have control/rswitch.* removed
before release?
aku	So, initial import is for example 1.0. Release ... Bump to 1.1 ... Devel
... Release .. Bump 1.2 ... Devel ...
aku	How to do this ?
aku	Special branch right now ?
dgp	Note that we are working on Tcl 8.4a4 on the HEAD; that's all I mean.
dgp	Yes, now that you mention it.
dgp	You will tag the files that make up the tcllib-1.2 release.
dgp	Make that tag the branch point for creating the RELEASE branch.
aku	Yes, that should work.
dgp	sadly CVS merging off the HEAD doesn't work well at all..
dgp	Simplest approach seems to be just copying file between 2 sandboxes.
dgp	Or there may be a way to make cvs update -j work, I'll need to
experiment.
aku	IOk.
aku	Slightly different topic: The process we have just discussed should be
good enough for patch and minor releases. But what about changes which
warrant a major release of tcllib ? I believe that for these more
coordination is necessary.
dgp	Keep in mind that tcllib is not a package.
dgp	It's just the umbrella name of a distribution of packages.
dgp	As such, I think you can use whatever numbering system you like, for
whatever purpose you need to fulfill.
dgp	If you want to keep similar spirit as the package numbers, though...
aku	We can do "package require Tcllib" right now. It is treated as a sort of
virtual or super package
dgp	I'd increment tcllib's major version number whenever you drop from it a
package that was in previous releases.
dgp	Hmmm.... well, then stop that.  That makes little sense, and leads to
crap like we encountered in tclhttpd.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

RE: [Tcllib-devel] Tcllib release

[Jeff H. <Je...@Ac...>]

Rheinhard Max wrote:
> Do you have an estimation when it will be ready?
> I've still 1-2 weeks left to update packages for SuSE Linux 8.0 . :)

That's probably enough time.  We'd like to release an updated
ActiveTcl 8.3.4.x, along with a beta 8.4 in that timeframe as
well.  Exactly what are the packages that SuSE uses?

Jeff

Re: [Tcllib-devel] Tcllib release

[Reinhard M. <ma...@su...>]

Hi,

On Tue, 15 Jan 2002 at 15:33, Andreas Kupries wrote:

> I am currently going through the tcllib ChangeLog and believe that
> there is enough material (bugfixes, enhancements, new modules) to
> allow for another release. Given that there are a number of new
> modules (and other modules are significantly extended (textutil
> for example)) I propose that we do a new minor release instead of
> a patch release.
>
> That would be 1.2.

Agreed.

Do you have an estimation when it will be ready?
I've still 1-2 weeks left to update packages for SuSE Linux 8.0 . :)

cu
	Reinhard

[Tcllib-devel] Tcllib release

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

Hi all.

I am currently going through the tcllib ChangeLog and believe that
there is enough material (bugfixes, enhancements, new modules) to
allow for another release. Given that there are a number of new modules
(and other modules are significantly extended (textutil for example))
I propose that we do a new minor release instead of a patch release.

That would be 1.2.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com

[Tcllib-devel] bwidget-1-3-1-branch created

[Jeff H. <Je...@Ac...>]

I created a branch for bwidgets back based on the pre-1.4
patches that I applied.  This can be used for those that want
some variant of 1.3.  However, 1.4 should be compatible and
is the way to go IMO.

  Jeff Hobbs                     The Tcl Guy
  Senior Developer               http://www.ActiveState.com/
      Tcl Support and Productivity Solutions

[Tcllib-devel] Addition to math module

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

Hello,

I have completed a first version of a set of procedures that
will allow the user to:
- Integrate functions (1D, 2D and 3D) over a definite interval
- Integrate a system of ordinary differential equations
- Solve a (simple) boundary value problem (linear second-order ODE)

I would like to submit this for inclusion in the math module.
Please let me know what you think about it.

(The attachment contains the documentation sofar, in raw form)

Regards,

Arjen Markus

[Tcllib-devel] RE: Contributing tcllib

[Jeff H. <Je...@Ac...>]

Francisco,

I've added you to the list of developers.  You should be
able to check out tcllib via CVS/SSH under your username
and add to it.  Also join tcl...@li...
	http://lists.sourceforge.net/lists/listinfo/tcllib-devel

to talke with others about naming considerations for modules
and other dev stuff on tcllib.

Thanks,

  Jeff Hobbs                     The Tcl Guy
  Senior Developer               http://www.ActiveState.com/
      Tcl Support and Productivity Solutions


> -----Original Message-----
> From: nobody [mailto:no...@so...]On Behalf Of Francisco
> Rodriguez
	...
> I posted a message on comp.lang.tcl offering a
> telnet client, and you redirected me to the
> tcllib project here, at SourceForge.
> 
> Well, I've got my SourceForge account.
> I think some admin from tcllib (like you) have
> to activate my account to perform changes in the
> CVS tree (to become a contributor).
> Am I right?
> 
> What's exactly the procedure, can you point me
> to some explanation?
> 
> Best regards
> 
> Francisco Rodriguez
> 

[Tcllib-devel] Vacation reminder

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

Hi all,

just a reminder that I am on christmas vacation from

     Tuesday,  December 18 2001
to   Wednesday January   3 2002

Have a nice christmas


         \|/					       \|/
         -o-					       -x-
         /|\		 Happy christmas	       /|\
       \ /*	       and a good new year	      |	* |
        0 *					     -x-*-x-
       /|\ *					      |* *|
        * * *					      * * *
         * * \ /				    |  * *  |
        * * * 0					   -x-* * *-x-
       *  *  /|\				    |*  *  *|
      *  * *  *					    *  * *  *
   \ /  * * *					  |   * * *   |
    0  *  *  *	\ /				|-x- *  *  * -x-|
   /|\*  * *  *   0			       -x-| *  * *  * |-x-
    *   ** **   */|\				| *   ** **   * |
  *   *  * *  *   *				*   *  * *  *   *
        * * *					      * * *
  -----------------				-----------------

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

[Tcllib-devel] Documentation toolbox, manpages

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

Well, when I moved memchan to sourceforge I reworked the documentation
and developed a tcl-based manpage markup language for it which made
writing manpages much easier. Using the expand macro processor by Will
Duquette I then wrote converters of manpages this format to HTML and
nroff. Joe English provided me with a converter to TMML, his XML-based
Tcl Manpage Markup Language.

As the core of expand is now part of tcllib (textutil) I used this to
work on a specialized macro processor just for my markup language.

The result of this work can be seen here

	http://sourceforge.net/tracker/?func=detail&
		aid=492234&group_id=12883&atid=362883

    Note that I broke the url into 2 parts.

I named this new module for tcllib 'doctools' instead of 'manpage' as
I have the hope to add other documentation related applications to it,
for example a parser for ChangeLogs.

I would like to get a bit more feedback on this before I add this
module to tcllib.

Note. Anyone who wants to actually use the applications in this module
has to get the current head of tcllib and the patch at

	http://sourceforge.net/tracker/?func=detail&\
		aid=492156&group_id=12883&atid=312883

The manpages for doctools are written using the format specified in
it. Use

	./mpexpand.all -verbose doctools
or	./mpexpand.all doctools

to generate the nroff, html, and tmml versions.

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

[Tcllib-devel] math::geometry etc.

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

Saw that Christian added geometry.tcl/test to math.

Just created the "math :: geometry" category for the
trackers "Bugs", "Patches" and "Feature Requests".
Items with that category are auto-assigned to Christian.

Notes in general
*	Yesterday I went through all categories in Bugs and Patches
	and brought them uptodate with respect to modules and
	submodules in tcllib.

*	Another change is that now only three categories have no
	developer associated with them. These are app:taip', 'math',
	and 'profiler'. Everything else auto-assigns items to some
	developer.

*	As I did not knew the interests of many of us most
	I assigned most unspoken for categories to me. If someone
	else wants to have a category feel free to change the
	auto-assignment.

*	The categories where people should ask about a transfer are
	csv, htmlparse, log, report, struct :: graph/matrix/tree
	because I wrote these. Everything else with my name on it
	is free for all.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com

RE: [Tcllib-devel] Functions in ::math::geometry

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

> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Larry W.
> Virden
> Sent: Wednesday, December 12, 2001 5:32 AM
> To: tcl...@li...
> Subject: Re: [Tcllib-devel] Functions in ::math::geometry
>
>
>
> From: Christian Heide Damm <da...@da...>
> >> How many points in multiline?  How many lines (multiline sounds like
> >> multiple lines...)
> >
> >I know 'multiline' is a bad name. What it meant is a line with bends.
>
> >Does anybody have a better name?
>
> Would "polyline" be appropriate?

The vector drawing application xfig (http://www.xfig.org) uses the name
'polyline'.
And a closed polyline is a polygon.


--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com

Re: [Tcllib-devel] Functions in ::math::geometry

[Cameron L. <cl...@st...>]

> From tcl...@li...  Wed Dec 12 07:43:18 2001
> 		.
> 		.
> 		.
> From: Christian Heide Damm <da...@da...>
> >> How many points in multiline?  How many lines (multiline sounds like
> >> multiple lines...)
> >
> >I know 'multiline' is a bad name. What it meant is a line with bends. 

> >Does anybody have a better name?

> Would "polyline" be appropriate?  
> 		.
> 		.
> 		.
Yes.

Re: [Tcllib-devel] Functions in ::math::geometry

[Larry W. V. <lv...@ca...>]

From: Christian Heide Damm <da...@da...>
>> How many points in multiline?  How many lines (multiline sounds like
>> multiple lines...)
>
>I know 'multiline' is a bad name. What it meant is a line with bends. 

>Does anybody have a better name?

Would "polyline" be appropriate?  



>> > # ::math::geometry::length
>> > #
>> > #       Find the length of the line (x1,y1),(x2,y2),...,(xn,yn).
>>
>> I assume that this is "find the length of the line segment
>> from x1,y1 -> xn,yn" ?
>
>No, it is the sum of the lengths of the individual line segments.

So then this is a multiline, and not technically a line?  Or is this yet
another kind of figure?



> A line is always defined by exactly two points.

If the routines are going to require that one only provide two, and not more,
points, it would be worthwhile mentioning that restriction/requirement/
basic assumption, in light of all the multiline alternatives also supported.  




> How about if I put something at the top of the file about lines, line segments, and
> multilines, and that they are defined by so many points. Then I can just write

That's a wonderful idea.  It would really be helpful to also provide examples
of what valid values are for each of the items.  Also , I highly recommend
that you document what is returned in error conditions as well.  


> The second problem: I could put the type float/int at all relevant places, or I could
> again just write at the top of the file that everything related to coordinates and
> distances are floating point values?

Again, a one time mention is fine - but examples showing what to expect are
going to be very helpful.
-- 
Never apply a Star Trek solution to a Babylon 5 problem.
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.
-><-