tcllib-devel — Discussion of development for tcllib

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

[Christian H. D. <da...@da...>]

Thanks for the feedback.

Let me go through your comments


"Larry W. Virden" wrote:

> From: Christian Heide Damm <da...@id...>
> > # geometry.tcl --
> > # See the file "license.terms" for information on usage and redistribution
> > # of this file, and for a DISCLAIMER OF ALL WARRANTIES.
>
> Remember that the current Tcllib policy is for code included to be covered
> in a BSD or very VERY similar license...

That's ok.



> > # ::math::geometry::calculateDistanceToMultiline
> > #
> > #       Calculate the distance between p and multiline.
> > #
> > # Arguments:
> > #       p           a point (x,y)
> > #       multiline   a list of points (x,y) constituting a line
>
> 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. For example, a
multiline could have the coordinates

    10 10 20 20 20 0

and this would be a line starting in 10,10 going north-east to 20,20 and then continuing
south to 20,0.

Does anybody have a better name?

There are basically three types of lines:

   * line segment: a _finite_ line between two points A and B
   * line: an _infinite_ line going through two points A and B
   * multiline: a sequence of connected line segments

> > # Results:
> > #       dist        the smallest distance between p and any point
> > #                   on the multiline
>
> What is dist?  a single floating point value?

Yes, I'll clarify that in the code.



> > proc ::math::geometry::calculateDistanceToMultiline {p multiline} {
> >     ...
> > }
> >
> > # ::math::geometry::findClosestPointOnMultiline
> > #
> > #       Return the point on $multiLine which is closest to $p.
> > #
> > # Arguments:
> > #       p           a point (x,y)
> > #       multiline   a list of points (x,y) constituting a line
> > #
> > # Results:
> > #       q           the point on the multiline that has the smallest
> > #                   distance to p
> > #
>
> I assume that q is also an x and y?  Is it one of the points listed in
> multiline, or a point calculated to exist on the line that includes the
> points of multiline.

If you draw q in a coordinate system, and then draw the multiline, then the multiline
will "hide" q.

For example, q could be 15,15 in the example above, since 15,15 is on the line segment
between 10,10 and 20,20.



> > # ::math::geometry::calculateDistanceToLineSegmentImpl
> > #
> > #       PRIVATE FUNCTION USED BY OTHER FUNCTIONS.
>
> So this function will not be one that developers would be needing to call
> in general?

No, it contains code that is shared by 2 or more other functions in the package.



> > # ::math::geometry::calculateDistanceToLine
> > #
> > #       Calculate the distance between C and the infinite line
> > #       that goes through A and B.
>
> How is this different than the first distance calculating?

calculateDistanceToLineSegment and calculateDistanceToLine are different, because a line
segment is finite.

The distance between (0,0) and the "line segment" (10,10)->(20,20) is sqrt(200).

The distance between (0,0) and the "line" (10,10)->(20,20) is 0 (because the line is
infinite and goes through (0,0)).



> > # ::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.



> > # ::math::geometry::angle
> > #
> > #       Calculates angle from the horizon to the line (x1,y1)->(x2,y2).
> > #
> > # Arguments:
> > #       x1,y1,x2,y2   the line
> > #
> > # Results:
> > #       angle         the angle between the line (0,0)->(1,0) and (x1,y1)->(x2,y2).
> > #                     angle is in 360-degrees going counter-clockwise
> > #
>
> Is angle returned in degrees?  radians?  some other unit?

This time, the documentation is precise enough: it is returned in degrees.



> > # ::math::geometry::findLineSegmentIntersection
> > #
> > #       Returns the point where the two line segments intersect.
> > #       Note: may also return "coincident" and "none".
> > #
> > # Arguments:
> > #       line1        the first line segment
> > #       line2        the second line segment
>
> What are these arguments?  2 or more x,y pairs?

Yes.



> > # Results:
> > #       p            the point where line1 and line2 intersect.
>
> So p's value is a list, consisting either of one of two words or an x,y pair?

p can be

   * none
   * coincident
   * 10 20  (if the intersection point is 10,20)

> > # ::math::geometry::findLineIntersection {line1 line2}
> > #
> > #       Returns the point where the two lines intersect.
> > #       Note: may also return "coincident" and "none".
> > #
> > # Arguments:
> > #       line1        the first line
> > #       line2        the second line
>
> What are these arguments?  2 or more x,y pairs?

A line is always defined by exactly two points.



> > unsure_about_these {
>
> unsure in what way - whether you will do them?  whether they belong here?
> whether these are the right names?  whether these are the right interfaces?

We have already done them. First of all, I'm not sure that they are general enough to be
in a tcllib module. The next problem is the names and interfaces, but I'll worry about
that when we have decided whether they should be in the module.

Many of your questions are related to

   * the difference between line, line segment, and multiline
   * the types of parameters and return values

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

     # Arguments:
     #       line1        the first line
     #       line2        the second line

and everyone will know that I'm talking about an infinite line, and that line1 is a list
of 4 numbers?

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?

Christian

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

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

From: Christian Heide Damm <da...@id...>

> # geometry.tcl --
> # See the file "license.terms" for information on usage and redistribution
> # of this file, and for a DISCLAIMER OF ALL WARRANTIES.

Remember that the current Tcllib policy is for code included to be covered 
in a BSD or very VERY similar license...

> 
> # ::math::geometry::calculateDistanceToMultiline
> #
> #       Calculate the distance between p and multiline.
> #
> # Arguments:
> #       p           a point (x,y)
> #       multiline   a list of points (x,y) constituting a line

How many points in multiline?  How many lines (multiline sounds like
multiple lines...)


> #
> # Results:
> #       dist        the smallest distance between p and any point
> #                   on the multiline

What is dist?  a single floating point value?

> #
> proc ::math::geometry::calculateDistanceToMultiline {p multiline} {
>     ...
> }
> 
> # ::math::geometry::findClosestPointOnMultiline
> #
> #       Return the point on $multiLine which is closest to $p.
> #
> # Arguments:
> #       p           a point (x,y)
> #       multiline   a list of points (x,y) constituting a line
> #
> # Results:
> #       q           the point on the multiline that has the smallest
> #                   distance to p
> #

I assume that q is also an x and y?  Is it one of the points listed in
multiline, or a point calculated to exist on the line that includes the
points of multiline.


> # ::math::geometry::calculateDistanceToLineSegmentImpl
> #
> #       PRIVATE FUNCTION USED BY OTHER FUNCTIONS.


So this function will not be one that developers would be needing to call
in general?

> # ::math::geometry::calculateDistanceToLine
> #
> #       Calculate the distance between C and the infinite line
> #       that goes through A and B.

How is this different than the first distance calculating?

> # ::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" ?



> # ::math::geometry::angle
> #
> #       Calculates angle from the horizon to the line (x1,y1)->(x2,y2).
> #
> # Arguments:
> #       x1,y1,x2,y2   the line
> #
> # Results:
> #       angle         the angle between the line (0,0)->(1,0) and (x1,y1)->(x2,y2).
> #                     angle is in 360-degrees going counter-clockwise
> #

Is angle returned in degrees?  radians?  some other unit?

> # ::math::geometry::findLineSegmentIntersection
> #
> #       Returns the point where the two line segments intersect.
> #       Note: may also return "coincident" and "none".
> #
> # Arguments:
> #       line1        the first line segment
> #       line2        the second line segment

What are these arguments?  2 or more x,y pairs?

> #
> # Results:
> #       p            the point where line1 and line2 intersect.


So p's value is a list, consisting either of one of two words or an x,y pair?



> # ::math::geometry::findLineIntersection {line1 line2}
> #
> #       Returns the point where the two lines intersect.
> #       Note: may also return "coincident" and "none".
> #
> # Arguments:
> #       line1        the first line
> #       line2        the second line

What are these arguments?  2 or more x,y pairs?


> unsure_about_these {

unsure in what way - whether you will do them?  whether they belong here?
whether these are the right names?  whether these are the right interfaces?

-- 
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] Functions in ::math::geometry

[Christian H. D. <da...@id...>]

Hi all,

I have attached my proposal for the new ::math::geometry module.

I would appreciate your comments about:

   * which functions should be in the module? (in the last part of the
     file, there are a number of functions that might go in the module)
   * any comments on style (naming conventions, splitting into several
     files, how to handle private implementation functions, other coding
     conventions, etc. etc.)
   * anybody wants to contribute with other functions?

Thanks,

Christian

RE: [Tcllib-devel] Re: Adding a geometry module to tcllib?

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

> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Christian
> Heide Damm
> Sent: Tuesday, December 11, 2001 10:55 AM
> To: Tcllib Devel
> Subject: [Tcllib-devel] Re: Adding a geometry module to tcllib?
>
>
> Andreas Kupries wrote:
>
> > ...
> > > What is the procedure for adding a new module to tcllib?
> >
> > We have no real process for adding new modules to tcllib right now.
> >
> > I would recommend as a first step to add yourself to the mailing
> > list <tcl...@li...> and ask there. Most
> > developers for tcllib are now on this list and then ask this
> > question there.
>
> I'm now on the mailing list.
>
> So... how should we go about adding a new module?
>
> I'm new at this, so I don't know any of the procedures for modifying
> code, writing test cases, who is allowed to modify what code, who is the
> main responsible for Tcllib, etc. etc.


We have no one who is the main responsible for tcllib. Right now we are
just a bunch of developers woth no big/real organization. Although the
last releases were done/generated by Bob Techentin, making him sort of
an unofficial release manager.

Who is allowed to modify what code: SourceForge allows every developer
for a project to modify everything in that project. We haven't set up
guidelines to restrict this yet.

What SF does is that we can not only define categories for bugs, etc.,
but are also able to associate a single developer per category so that
new items with that category are automatically assigned to that developer.
In this way we can make a developer responsible for the handling of a
category.

In tcllib the categories we have are equivalent to module names (and
in some places subpackages of a module). I for example have set up myself
to be assigned all bugs for the graph structure in the module 'struct'.

So, in your case we could create a category 'math :: geometry', associate
you with that category and thus make you responsible for the handling of
items having that category.

Regarding the writing of testcases, a lot of modules come with a testsuite
(not all unfortunately), so there are plenty of examples.

Also see
http://sourceforge.net/docman/display_doc.php?docid=8147&group_id=12883
for general guidelines for writing code, although the discussion in that
article concentrates on math.



> > It would also make things easier if you have an account at SF so
> > that we can add you as developer to tcllib, to the trackers and
> > auto-assign items in the geometry area to you.
>
> My username at SF is 'chdamm'.

Ok. I will set you up as a tcllib developer.


>
> > ... Question on the module itself:
> >
> >         Would it make sense to add the geometry functionality
> >         as a subpackage to "math" instead as a separate module ?
> >
> >                 [package require math::geometry]
>
> I think this makes good sense.


> > ...
> > Ideogramic, you guys do XML and UML with Tcl, right ?
> > I guess I now know where the geometry functionality is
> > required :)
>
> Correct, although we don't actually need any new geometry functions
> ourselves. I just thought that it was time to give something back to
> the Tcl community. The geometry functions seemed a good place to start,
> since there was apparently no such functions anywhere I looked.


Reading the latest posting in the c.l.t. thread I realize that your code
is [incr Tcl] based. Do you believe that it is possible to make this
functionality independent of this extension ?

As long as TIP #50 is not 'final' tcllib code may not have a dependency
on this extension.


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

[Tcllib-devel] Re: Adding a geometry module to tcllib?

[Christian H. D. <da...@id...>]

Andreas Kupries wrote:

> ...
> > What is the procedure for adding a new module to tcllib?
>
> We have no real process for adding new modules to tcllib right now.
>
> I would recommend as a first step to add yourself to the mailing
> list <tcl...@li...> and ask there. Most
> developers for tcllib are now on this list and then ask this
> question there.

I'm now on the mailing list.

So... how should we go about adding a new module?

I'm new at this, so I don't know any of the procedures for modifying
code, writing test cases, who is allowed to modify what code, who is the
main responsible for Tcllib, etc. etc.



> It would also make things easier if you have an account at SF so
> that we can add you as developer to tcllib, to the trackers and
> auto-assign items in the geometry area to you.

My username at SF is 'chdamm'.



> ... Question on the module itself:
>
>         Would it make sense to add the geometry functionality
>         as a subpackage to "math" instead as a separate module ?
>
>                 [package require math::geometry]

I think this makes good sense.



> ...
> Ideogramic, you guys do XML and UML with Tcl, right ?
> I guess I now know where the geometry functionality is
> required :)

Correct, although we don't actually need any new geometry functions
ourselves. I just thought that it was time to give something back to the
Tcl community. The geometry functions seemed a good place to start,
since there was apparently no such functions anywhere I looked.

Christian

[Tcllib-devel] RE: Adding a geometry module to tcllib?

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

> -----Original Message-----
> From: Christian Heide Damm [mailto:da...@id...]
> Sent: Tuesday, December 11, 2001 7:56 AM
> To: and...@ac...
> Subject: Adding a geometry module to tcllib?
> 
> 
> Hi Andreas,
> 
> You may have seen the thread "2D trigonometry functions" on
> comp.lang.tcl?

Yep.

> What is the procedure for adding a new module to tcllib?

We have no real process for adding new modules to tcllib right now.

I would recommend as a first step to add yourself to the mailing
list <tcl...@li...> and ask there. Most
developers for tcllib are now on this list and then ask this
question there.

It would also make things easier if you have an account at SF so
that we can add you as developer to tcllib, to the trackers and
auto-assign items in the geometry area to you.

... Question on the module itself:

	Would it make sense to add the geometry functionality
	as a subpackage to "math" instead as a separate module ?

		[package require math::geometry]

	The current math functionality is actually more like

		math::statistics


> Christian Heide Damm - M.Sc. Computer Science
> Ideogramic ApS, Denmark - http://www.ideogramic.com

Ideogramic, you guys do XML and UML with Tcl, right ?
I guess I now know where the geometry functionality is
required :)

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

RE: [Tcllib-devel] How would tcllib developers prefer to hear about problems in the development branches of the code?

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

> During development, one commits code changes to the CVS as work progresses.
> How would you developers like to learn about problems with this code? 
> Not at all?
> Private email messages?
> Formally submitted bug reports ?

It depends on the problems.  Minor problems with commited changes
should likely be just addressed to the commiter.  Problems that
expose design weaknesses should be sent to the list as a whole.

Don't ignore problems.  Don't assume the commiter will be aware
of them.

Jeff

RE: [Tcllib-devel] How would tcllib developers prefer to hear about problems in the development branches of the code?

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

> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Larry W.
> Virden
> Sent: Wednesday, November 28, 2001 1:27 AM
> To: tcl...@li...
> Subject: Re: [Tcllib-devel] How would tcllib developers prefer to hear
> about problems in the development branches of the code?
>
>
> From: "Andreas Kupries" <and...@ac...>
>
> > > [mailto:tcl...@li...]On Behalf Of Larry W.
> > > Virden
> > >
> > > During development, one commits code changes to the CVS as work
> > progresses.
> > > How would you developers like to learn about problems with this code?
> > > Not at all?
> > > Private email messages?
> > > Formally submitted bug reports ?
> >
> > > Just curious as to what the preferred mode of operation should be.
> >
> > Can you give us a bit more context to this general question ?
>
> I am uncertain exactly how much more context I can give.  Let's see.
> Often I see people on comp.lang.tcl and elsewhere recommended to get the
> latest version of tcl/tk/tcllib/etc. from the CVS when they are
> seeing problems.
> In this way, they can see if their problems are fixed in the
> latest version.
>
> However, I have also seen times in the past when someone says "Oh, such
and
> such a doc/example/demo/test case/aspect of the extension or  language
doesn't
> work" and when they indicate they are using the latest code from CVS there
> is almost a shrug and "oh well, that code isn't released you know  -
perhaps
> all the changes haven't been checked back in, the code checked into the
> CVS isn't intended to be a real distribution - there are files  that need
to
> be generated, etc." .
>
> These latter are all fair and true statements.  However, I know that I,
> as a part time developer, am left wondering exactly what procedure I
should
> follow with regards to reporting the large number of problems in tcllib's
> test suite for instance.

Ok. For me I would dismiss the "Not at all" option. Problems are problems,
even if they are in code under ongoing development. There is no way to
predict
if the author will see the same problem.

So at least a private email should be send IMHO. If there is a place for
formal
bug reports I would log one at that too ...

Regarding the tcllib testsuite ... Format bug reports are in order.


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

Re: [Tcllib-devel] How would tcllib developers prefer to hear about problems in the development branches of the code?

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

From: "Andreas Kupries" <and...@ac...>

> > [mailto:tcl...@li...]On Behalf Of Larry W.
> > Virden
> >
> > During development, one commits code changes to the CVS as work
> progresses.
> > How would you developers like to learn about problems with this code?
> > Not at all?
> > Private email messages?
> > Formally submitted bug reports ?
> 
> > Just curious as to what the preferred mode of operation should be.
> 
> Can you give us a bit more context to this general question ?

I am uncertain exactly how much more context I can give.  Let's see.
Often I see people on comp.lang.tcl and elsewhere recommended to get the
latest version of tcl/tk/tcllib/etc. from the CVS when they are seeing problems.
In this way, they can see if their problems are fixed in the latest version.

However, I have also seen times in the past when someone says "Oh, such and
such a doc/example/demo/test case/aspect of the extension or language doesn't
work" and when they indicate they are using the latest code from CVS there
is almost a shrug and "oh well, that code isn't released you know - perhaps
all the changes haven't been checked back in, the code checked into the
CVS isn't intended to be a real distribution - there are files that need to
be generated, etc." .

These latter are all fair and true statements.  However, I know that I,
as a part time developer, am left wondering exactly what procedure I should 
follow with regards to reporting the large number of problems in tcllib's
test suite for instance.





-- 
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] How would tcllib developers prefer to hear about problems in the development branches of the code?

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

> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Larry W.
> Virden
> Sent: Tuesday, November 27, 2001 4:09 AM
> To: tcl...@li...
> Subject: [Tcllib-devel] How would tcllib developers prefer to hear about
> problems in the development branches of the code?
>
>
>
> During development, one commits code changes to the CVS as work
progresses.
> How would you developers like to learn about problems with this code?
> Not at all?
> Private email messages?
> Formally submitted bug reports ?

> Just curious as to what the preferred mode of operation should be.

Can you give us a bit more context to this general question ?

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

[Tcllib-devel] How would tcllib developers prefer to hear about problems in the development branches of the code?

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

During development, one commits code changes to the CVS as work progresses.
How would you developers like to learn about problems with this code? 
Not at all?
Private email messages?
Formally submitted bug reports ?

Just curious as to what the preferred mode of operation should be.
-- 
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] distribution & installation problems

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

The current master makefile is a maintenance hotspot.

Every speciality in any module has to be reflected in that makefile,
in several locations: 'install' and 'dist' targets, plus changes in
'mkInstallScripts'. As such it does serve as deterence for module
writers to not to deviate from the prescribed path (to much).

Still, there are modules which will require the installation of more
files outside of the existing set (*.n, *.tcl, and tclIndex).

Example:
	The foundations of the memchan manpage system are the expand
	macro processor and a set of rules for the conversion of a
	manpage marked up in tcl into nroff, HTML and TMML.

	The heart of the expand processor is now part of the
	'textutil' module of tcllib and can be installed in a regular
	manner.

	The rules files driving the conversion however, and a
	mini-expand using them, are outside of the regular
	installation procedures provided by the master maskefile and
	the script generating the install scripts.

Other problems:

	There are essentially three different directory layouts
	present in the system:

	a)	The sourcecode from the CVS
	b)	The sourcecode distribution as generated by 'make dist'
	c)	and the installed tcllib.

	This makes maintenance unduly complex as different code has to
	be written and kept in sync for the various transitions:

	(a -> c)	make install
	(a -> b)	make dist
	(b -> c)	script generated by mkInstallScripts.tcl in (a -> b)

	Note aside: The generated sourcecode distribution (b) does not
	contain the examples! This is a major deficiency for users of the
	tcllib distribution as they do not have any demos.



Possibilites:

1)	The tcllib configure is extended to generate not only the
	master makefile but also module makefiles. This is added on a
	case by case basis.

	The master makefile is extended to look out for and use module
	makefiles if present. This essentially means that targets like
	'install' and 'dist' do their regular work and also call upon
	the module makefile (same target) for any specialities.

	The generator script 'mkInstallScripts' is extended to look
	out for and use module makefiles to generate any special code
	required by a module. Or alternatively they look for plugin
	code in the module which is then used to genrate the installation
	commands.

	** This way of doing things should allow us to extend tcllib
	** with modules requiring special things for quite some
	** time. In the end however this approach does not scale as
	** there is still the central 'configure.in' script to maintain,
	** i.e. it is a central location containing module information.

2)	Instead of extending the configure(.in) file we write small
	tool which can extract the configuration information out of a
	'config.status' file and apply this to any file we desire.

	The master makefile uses this to automtically generate all
	module makefiles out of their .in counterparts, if
	present. Together with the rest of (1) we now have unchanging
	master configure(.in), Makefile(.in) and mkInstallScripts.tcl
	while still preserving the extensibility we desire.

	The tool mentioned above can be implemented using the expand
	functionality from the textutil module.


Regarding the other problems I propose to make the source distribution
structurally identical to the raw cvs layout, with just the
development files stripped (Makefile*, configure*, CVS
directories). This alone would make the layouts (a) and (b) similar
enough to allow us to rewrite the 'install' target of the master
makefile in terms of the script generated by 'mkInstallScripts.tcl',
thus reducing the size of the code to maintain. A side benefit would
be that the examples would now be part of the source distribution.
They would not get installed, but they would at least be available.



Comments, opinions ?

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

RE: [Tcllib-devel] More on mime processing

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

> From and...@Ac...  Mon Nov 12 17:06:57 2001
> 		.
> 		.
> 		.
> Is is possible to send me the whole modified mime.tcl, or a unified diff ?
> I would like to integrate this change into the current sources.
> 		.
> 		.
> 		.
Dirty, dirty, dirty.

All I do is append what follows to mime.tcl.
There are dozens of better ways to do this,
none of which I have the time now to explain.
So, my answer is, yes, it's possible, but please
understand this is very much in the "at your own
risk" category.

When I can make time, I'll describe more of what's
going on.

Most important:  it's only the "while {$moreP} ..."
loop that matters; and, in that neighborhood,
$string is "disposable", in a sense I can make pre-
cise.  
======================================================================


# CL is experimenting with this on 12 November 2001.
# mime::parsepart --
#
#       Parses the MIME headers and attempts to break up the message
#       into its various parts, creating a MIME token for each part.
#
# Arguments:
#       token  The MIME token to parse.
#
# Results:
#       Throws an error if it has problems parsing the MIME token,
#       otherwise it just sets up the appropriate variables.

proc mime::parsepart {token} {
    variable $token
    upvar 0 $token state

    if {[set fileP [info exists state(file)]]} {
        seek $state(fd) [set pos $state(offset)] start
        set last [expr {$state(offset)+$state(count)-1}]
    } else {
        set string $state(string)
    }

    set vline ""
    while {1} {
        set blankP 0
        if {$fileP} {
            if {($pos > $last) || ([set x [gets $state(fd) line]] <= 0)} {
                set blankP 1
            } else {
                incr pos [expr {$x+1}]
            }
        } else {
            if {[string length $string] == 0} {
                set blankP 1
            } else {
                switch -- [set pos [string first "\n" $string]] {
                    -1 {
                        set line $string
                        set string ""
                    }
    
                    0 {
                        set blankP 1
                        set line ""
                        set string [string range $string 1 end]
                    }
    
                    default {
                        set line [string range $string 0 [expr {$pos-1}]]
                        set string [string range $string [expr {$pos+1}] end]
                    }
                }
                set x [string length $line]
            }
        }

        if {(!$blankP) && ([string last "\r" $line] == [expr {$x-1}])} {
            set line [string range $line 0 [expr {$x-2}]]
            if {$x == 1} {
                set blankP 1
            }
        }

        if {(!$blankP) \
                && (([string first " " $line] == 0) \
                        || ([string first "\t" $line] == 0))} {
            append vline "\n" $line
            continue
        }      

        if {![string compare $vline ""]} {
            if {$blankP} {
                break
            }

            set vline $line
            continue
        }

        if {([set x [string first ":" $vline]] <= 0) \
                || (![string compare \
                             [set mixed \
                                  [string trimright \
                                          [string range \
                                                  $vline 0 [expr {$x-1}]]]] \
                            ""])} {
            error "improper line in header: $vline"
        }
        set value [string trim [string range $vline [expr {$x+1}] end]]
        switch -- [set lower [string tolower $mixed]] {
            content-type {
                if {[info exists state(content)]} {
                    error "multiple Content-Type fields starting with $vline"
                }

                if {![catch { set x [mime::parsetype $token $value] }]} {
                    set state(content) [lindex $x 0]
                    set state(params) [lindex $x 1]
                }
            }

            content-md5 {
            }

            content-transfer-encoding {
                if {([string compare $state(encoding) ""]) \
                        && ([string compare $state(encoding) \
                                    [string tolower $value]])} {
                    error "multiple Content-Transfer-Encoding fields starting with $vline"
                }

                set state(encoding) [string tolower $value]
            }

            mime-version {
                set state(version) $value
            }

            default {
                if {[lsearch -exact $state(lowerL) $lower] < 0} {
                    lappend state(lowerL) $lower
                    lappend state(mixedL) $mixed
                }

                array set header $state(header)
                lappend header($lower) $value
                set state(header) [array get header]
            }
        }

        if {$blankP} {
            break
        }
        set vline $line
    }

    if {![info exists state(content)]} {
        set state(content) text/plain
        set state(params) [list charset us-ascii]
    }

    if {![string match multipart/* $state(content)]} {
        if {$fileP} {
            set x [tell $state(fd)]
            incr state(count) [expr {$state(offset)-$x}]
            set state(offset) $x
        } else {
            set state(string) $string
        }

        if {[string match message/* $state(content)]} {
            variable [set child $token-[incr state(cid)]]

            set state(value) parts
            set state(parts) $child
            if {$fileP} {
                mime::initializeaux $child \
                    -file $state(file) -root $state(root) \
                    -offset $state(offset) -count $state(count)
            } else {
                mime::initializeaux $child -string $state(string)
            }
        }

        return
    }

    set state(value) parts

    set boundary ""
    foreach {k v} $state(params) {
        if {![string compare $k boundary]} {
            set boundary $v
            break
        }
    }
    if {![string compare $boundary ""]} {
        error "boundary parameter is missing in $state(content)"
    }
    if {![string compare [string trim $boundary] ""]} {
        error "boundary parameter is empty in $state(content)"
    }

    if {$fileP} {
        set pos [tell $state(fd)]
    }

    set inP 0
    set moreP 1
     set i 0
     if {!$fileP} {set list [split $string \n]}
    while {$moreP} {
        if {$fileP} {
            if {$pos > $last} {
                error "termination string missing in $state(content)"
            }
            if {[set x [gets $state(fd) line]] < 0} {
                error "end-of-file encountered while parsing $state(content)"
            }
            incr pos [expr {$x+1}]
        } else {
            if {[string length $string] == 0} {
                error "end-of-string encountered while parsing $state(content)"
            }
#             switch -- [set pos [string first "\n" $string]] {
#                 -1 {
#                     set line $string
#                     set string ""
#                 }
# 
#                 0 {
#                     set line ""
#                     set string [string range $string 1 end]
#                 }
# 
#                 default {
#                     set line [string range $string 0 [expr {$pos-1}]]
#                     set string [string range $string [expr {$pos+1}] end]
#                 }
#             }
             if {$i >= [llength $list]} {
                 set line2 ???
                 set string ""
             }
             set line2 [lindex $list $i]
             set line $line2
             incr i
            set x [string length $line]
        }
        if {[string last "\r" $line] == [expr {$x-1}]} {
            set line [string range $line 0 [expr {$x-2}]]
        }

        if {[string first "--$boundary" $line] != 0} {
            if {$inP && !$fileP} {
                append start $line "\n"
            }

            continue
        }

        if {!$inP} {
            if {![string compare $line "--$boundary"]} {
                set inP 1
                if {$fileP} {
                    set start $pos
                } else {
                    set start ""
                }
            }

            continue
        }

        if {([set moreP [string compare $line "--$boundary--"]]) \
                && ([string compare $line "--$boundary"])} {
            if {$inP && !$fileP} {
                append start $line "\n"
            }
            continue
        }

        variable [set child $token-[incr state(cid)]]

        lappend state(parts) $child

        if {$fileP} {
            if {[set count [expr {$pos-($start+$x+3)}]] < 0} {
                set count 0
            }

            mime::initializeaux $child \
                -file $state(file) -root $state(root) \
                -offset $start -count $count

            seek $state(fd) [set start $pos] start
        } else {
            mime::initializeaux $child -string \
                    [string range $start 0 [expr {[string length $start]-2}]]

            set start ""
        }
    }
}

RE: [Tcllib-devel] More on mime processing

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

Is is possible to send me the whole modified mime.tcl, or a unified diff ?
I would like to integrate this change into the current sources.

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

> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Cameron
> Laird
> Sent: Monday, November 12, 2001 3:01 PM
> To: a.k...@we...; dn...@sa...; fel...@cs...;
> fp...@fp...; tcl...@li...
> Subject: [Tcllib-devel] More on mime processing
> 
> 
> of large items:  all the interesting action is in
> the "while {$moreP} {..." loop of mime::parsepart,
> that is, the second one, which parses bodies.  For
> the purposes of this discussion, any benefit to
> splitting mime::parsepart in various ways mentioned
> already is essentially irrelevant; all that matters
> is to improve the second loop, in the case where
> $fileP is zero.
> 
> I'm currently using
>   set list [split $string \n]
>   set i 0
>   while {!moreP} {
>       ...
>       set line [lindex $list $i]
>       incr i
>       ...
>   }
 

[Tcllib-devel] More on mime processing

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

of large items:  all the interesting action is in
the "while {$moreP} {..." loop of mime::parsepart,
that is, the second one, which parses bodies.  For
the purposes of this discussion, any benefit to
splitting mime::parsepart in various ways mentioned
already is essentially irrelevant; all that matters
is to improve the second loop, in the case where
$fileP is zero.

I'm currently using
  set list [split $string \n]
  set i 0
  while {!moreP} {
      ...
      set line [lindex $list $i]
      incr i
      ...
  }
Eventually I'll probably use a more time-efficient
coding.  The multiple orders of magnitude this one
gains me are enough for now, and I feel safer with
a loop that preserves most of the existing source.

If someone else wants to pursue this, note that 
the value of $string coming out of this loop is
immaterial; the only substantive use made of $string
is to compute $line (except for one trivial excepti-
on-handler).

RE: [Tcllib-devel] How frequently do the htmlized tcllib docs get updated?

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

> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Joe
> English
> Sent: Friday, November 09, 2001 12:48 PM
> To: tcl...@li...
> Subject: Re: [Tcllib-devel] How frequently do the htmlized tcllib docs
> get updated?
> 
> 
> 
> Andreas Kupries  wrote:
> >
> > Oh. Which nroff commands are not handled ?
> 
> Mostly the macro definitions; excerpts from 'man.macros' are included
> inline, and there are several macros  (.de i1, .de i2, ...) used
> to keep the the SYNOPSIS in sync with the rest of the manpage.

I am quite sure that the manpages I wrote do not use these commands.
Because of this I come to the conclusion that I did not write the
comm.n manpage but that this is the original manpage by J. R. LoVerso
This is reinforced by the contents.

> The other unrecognized requests aren't too hard to add.
> 
> FWIW, the Tcl core docs for commands with lots of suboptions 
> conventionally
> just use
> 
> 	.SH SYNOPSIS
> 	.nf
> 	\fBcommand\fP  \fIoption ...\fP  ? \fI arg arg... \fB
> 	.SH DESCRIPTION
> 	...
> instead of listing all the subcommands explicitly in the SYNOPSIS.

> I've modified the manpage, expanding all the macro definitions
> and updating it to use this style; it now passes through my converter
> relatively unscathed.  Results at:
> 
>     <URL: http://tcllib.sourceforge.net/doc/comm.html >
> 
> original version at:
> 
>     <URL: http://tcllib.sourceforge.net/doc/comm.n.html >
> 
> If this is acceptable, I'll commit the modified version.

It looks good to me.

When you commit the modified version please enter and assign
a doc bug to me as well, as reminder that the contents have
to be updated too (comm is now in the namspace comm, etc.)

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

Re: [Tcllib-devel] How frequently do the htmlized tcllib docs get updated?

[Joe E. <jen...@fl...>]

Andreas Kupries  wrote:
>
> Oh. Which nroff commands are not handled ?

Mostly the macro definitions; excerpts from 'man.macros' are included
inline, and there are several macros  (.de i1, .de i2, ...) used
to keep the the SYNOPSIS in sync with the rest of the manpage.

The other unrecognized requests aren't too hard to add.

FWIW, the Tcl core docs for commands with lots of suboptions conventionally
just use

	.SH SYNOPSIS
	.nf
	\fBcommand\fP  \fIoption ...\fP  ? \fI arg arg... \fB
	.SH DESCRIPTION
	...
instead of listing all the subcommands explicitly in the SYNOPSIS.

I've modified the manpage, expanding all the macro definitions
and updating it to use this style; it now passes through my converter
relatively unscathed.  Results at:

    <URL: http://tcllib.sourceforge.net/doc/comm.html >

original version at:

    <URL: http://tcllib.sourceforge.net/doc/comm.n.html >

If this is acceptable, I'll commit the modified version.


--Joe English

  jen...@fl...

RE: [Tcllib-devel] How frequently do the htmlized tcllib docs get updated?

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

> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Joe
> English
> Sent: Friday, November 09, 2001 10:58 AM
> To: tcl...@li...
> Subject: Re: [Tcllib-devel] How frequently do the htmlized tcllib docs
> get updated?

> 
> Andreas Kupries wrote:
> >
> > I also wrote a replacement manpage for comm IIRC. If
> > not I should, because of the change namespacing.
> 
> Ah yes, now I remember: there *is* an nroff format manpage
> for the comms package (courtesy Andreas) from which the HTML
> version in CVS is generated.  I used the HTML version instead
> because the source makes much more sophisticated use
> of the nroff macro processor than my poor upconverter can
> handle.


Oh. Which nroff commands are not handled ?

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

Re: [Tcllib-devel] How frequently do the htmlized tcllib docs get updated?

[Joe E. <jen...@fl...>]

Andreas Kupries wrote:
>
> I also wrote a replacement manpage for comm IIRC. If
> not I should, because of the change namespacing.

Ah yes, now I remember: there *is* an nroff format manpage
for the comms package (courtesy Andreas) from which the HTML
version in CVS is generated.  I used the HTML version instead
because the source makes much more sophisticated use
of the nroff macro processor than my poor upconverter can
handle.


--Joe English

  jen...@fl...

RE: [Tcllib-devel] How frequently do the htmlized tcllib docs get updated?

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

I also wrote a replacement manpage for comm IIRC. If
not I should, because of the change namespacing.

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

> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Joe
> English
> Sent: Friday, November 09, 2001 9:32 AM
> To: tcl...@li...
> Subject: Re: [Tcllib-devel] How frequently do the htmlized tcllib docs
> get updated?
> 
> 
> 
> Larry W. Virden  wrote:
> 
> > I was wondering - I notice that tcllib 1.1 has several new modules .
> > However, when I tried to access, for instance, the htmlized version of
> > doc for the comm module I didn't find it.
> 
> 
> Where are you looking?
> 
> 
> There's a copy on the TCLLIB home page:
>     <URL: http://tcllib.sourceforge.net/doc/comm.n.html >
> 
> > Is there some automated process that generates them and it just 
> hasn't gone
> > off yet?
> 
> I've been updating the documentation on the SF web site
> semiautomatically, usually about once a week.  It's not
> done through a cron job because I often need to make
> small corrections to the manpage source by hand after a
> cvs update (plus, my SSH key and all the conversion tools
> are on my laptop).
> 
> Note that the comm.n.html manpage doesn't go through the
> same conversion process as the other pages; I just mirror the
> HTML version straight from CVS.  The FTP and Tcl-MIME modules
> are also treated separately since they use other formats for
> their native documentation (HTML and the IETF RFC DTD (!), resp.)
> 
> (Actually Andreas Kupries has written NROFF manpages for
> these packages, which are also on the SF web site along with
> the original package docs.)
> 
> 
> --Joe English
> 
>   jen...@fl...
> 
> _______________________________________________
> Tcllib-devel mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcllib-devel
> 

Re: [Tcllib-devel] How frequently do the htmlized tcllib docs get updated?

[Joe E. <jen...@fl...>]

Larry W. Virden  wrote:

> I was wondering - I notice that tcllib 1.1 has several new modules .
> However, when I tried to access, for instance, the htmlized version of
> doc for the comm module I didn't find it.


Where are you looking?


There's a copy on the TCLLIB home page:
    <URL: http://tcllib.sourceforge.net/doc/comm.n.html >

> Is there some automated process that generates them and it just hasn't gone
> off yet?

I've been updating the documentation on the SF web site
semiautomatically, usually about once a week.  It's not
done through a cron job because I often need to make
small corrections to the manpage source by hand after a
cvs update (plus, my SSH key and all the conversion tools
are on my laptop).

Note that the comm.n.html manpage doesn't go through the
same conversion process as the other pages; I just mirror the
HTML version straight from CVS.  The FTP and Tcl-MIME modules
are also treated separately since they use other formats for
their native documentation (HTML and the IETF RFC DTD (!), resp.)

(Actually Andreas Kupries has written NROFF manpages for
these packages, which are also on the SF web site along with
the original package docs.)


--Joe English

  jen...@fl...

RE: [Tcllib-devel] How frequently do the htmlized tcllib docs get updated?

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

> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Larry W.
> Virden
> Sent: Friday, November 09, 2001 3:33 AM
> To: tcl...@li...
> Subject: [Tcllib-devel] How frequently do the htmlized tcllib docs get
> updated?
> 
> 
> I was wondering - I notice that tcllib 1.1 has several new 
> modules .  However,
> when I tried to access, for instance, the htmlized version of doc for the
> comm module I didn't find it.
> 
> Is there some automated process that generates them and it just 
> hasn't gone off yet?

There is no automated process. Joe English does it once in a while.


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

RE: [Tcllib-devel] Tclapps question

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

> In the Tclapps cvs snapshots that I have seen, the groupie directory
appears
> to be empty - is there something that should be there but perhaps hasn't
> been checked in yet?

Hmmm, I guess that didn't get removed properly.  That was
another game I thought I could add to the mix, but then
I realized the license was shareware (not compatible), so
I never added the file (and should have cvs rm'ed the dir).
Perhaps you don't have the -P prune option for cvs set by
default?

Jeff

[Tcllib-devel] How frequently do the htmlized tcllib docs get updated?

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

I was wondering - I notice that tcllib 1.1 has several new modules .  However,
when I tried to access, for instance, the htmlized version of doc for the
comm module I didn't find it.

Is there some automated process that generates them and it just hasn't gone
off yet?
-- 
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] Tclapps question

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

In the Tclapps cvs snapshots that I have seen, the groupie directory appears
to be empty - is there something that should be there but perhaps hasn't
been checked in yet?
-- 
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.
-><-