Menu
▾
▴
tcllib-devel — Discussion of development for tcllib
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(15) |
Nov
(37) |
Dec
(15) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(13) |
Feb
(58) |
Mar
(61) |
Apr
(8) |
May
|
Jun
(18) |
Jul
(51) |
Aug
(11) |
Sep
(41) |
Oct
(19) |
Nov
(39) |
Dec
(14) |
| 2003 |
Jan
(46) |
Feb
(28) |
Mar
(3) |
Apr
(132) |
May
(93) |
Jun
(46) |
Jul
(22) |
Aug
(55) |
Sep
(13) |
Oct
(6) |
Nov
(8) |
Dec
(6) |
| 2004 |
Jan
(28) |
Feb
(60) |
Mar
(9) |
Apr
(28) |
May
(39) |
Jun
(40) |
Jul
(36) |
Aug
(13) |
Sep
(21) |
Oct
(38) |
Nov
(25) |
Dec
(8) |
| 2005 |
Jan
(6) |
Feb
(14) |
Mar
(1) |
Apr
(2) |
May
(17) |
Jun
(9) |
Jul
(7) |
Aug
(90) |
Sep
(44) |
Oct
(40) |
Nov
(22) |
Dec
(1) |
| 2006 |
Jan
(31) |
Feb
(10) |
Mar
(1) |
Apr
(3) |
May
(8) |
Jun
(28) |
Jul
(5) |
Aug
(42) |
Sep
(40) |
Oct
(40) |
Nov
(27) |
Dec
(26) |
| 2007 |
Jan
(14) |
Feb
(13) |
Mar
(3) |
Apr
(3) |
May
(22) |
Jun
|
Jul
|
Aug
(17) |
Sep
(10) |
Oct
|
Nov
(24) |
Dec
(5) |
| 2008 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
(4) |
May
(18) |
Jun
(10) |
Jul
(1) |
Aug
(10) |
Sep
(5) |
Oct
(3) |
Nov
(5) |
Dec
(3) |
| 2009 |
Jan
(17) |
Feb
(31) |
Mar
(5) |
Apr
(6) |
May
(15) |
Jun
(52) |
Jul
(48) |
Aug
(39) |
Sep
(6) |
Oct
(11) |
Nov
(8) |
Dec
(6) |
| 2010 |
Jan
(2) |
Feb
(3) |
Mar
(1) |
Apr
|
May
(3) |
Jun
(12) |
Jul
(1) |
Aug
|
Sep
(4) |
Oct
|
Nov
(4) |
Dec
(1) |
| 2011 |
Jan
(3) |
Feb
(21) |
Mar
(17) |
Apr
(8) |
May
(10) |
Jun
(7) |
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(5) |
Dec
(3) |
| 2012 |
Jan
(1) |
Feb
(1) |
Mar
(3) |
Apr
(1) |
May
(6) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
(8) |
| 2013 |
Jan
(3) |
Feb
(7) |
Mar
(3) |
Apr
(1) |
May
(2) |
Jun
(1) |
Jul
(1) |
Aug
(3) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2014 |
Jan
(1) |
Feb
(12) |
Mar
(4) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(3) |
Oct
(9) |
Nov
(4) |
Dec
(1) |
| 2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
(3) |
May
(17) |
Jun
(4) |
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2016 |
Jan
(9) |
Feb
(4) |
Mar
(1) |
Apr
(1) |
May
|
Jun
(8) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(2) |
Feb
(10) |
Mar
|
Apr
(1) |
May
(2) |
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2019 |
Jan
|
Feb
(3) |
Mar
|
Apr
(17) |
May
|
Jun
(1) |
Jul
|
Aug
(4) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2020 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
(11) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
(4) |
| 2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(6) |
Jun
|
Jul
(2) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Virden, L. W. <lv...@ca...> - 2007-08-30 16:16:22
|
=20 Re: imap4 Sorry about that - I thought I recalled reading some discussion regarding the imap4 module that sounded as if it were released. I apologize for misremembering. Re: empty test cases I don't know, for certain. I just thought it might be worthwhile to make certain we state that , just in case someone "clever" decided to submit their package with an empty test suite (or man page file, or a man page file that basically said "no documentation is available at this time"). --=20 <URL: http://wiki.tcl.tk/ > Even if explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. <URL: mailto:lv...@gm... > <URL: http://www.purl.org/NET/lvirden/ > =20 -----Original Message----- From: Andreas Kupries [mailto:and...@ac...]=20 Sent: Thursday, August 30, 2007 12:04 PM To: Virden, Larry W.; tcl...@li... Subject: RE: [Tcllib-devel] question about tcllib imap4 and page modules > the tcllib README file says > > > * the module should have both documentation ([*]) and a test suite > (in the form of a group of *.test files in the module directory). > > [*] Possible forms: doctools, TMML/XML, nroff (man), or HTML. > The first format is the most preferred as it can be processed with > tools provided by tcllib itself (See module doctools). The first > two are preferred in general as they are semantic markup and thus > easier to convert into other formats. > > * the module must have either documentation or a test suite. It can > not have neither. > > > However, the imap4 and page modules have neither documentation or a=20 > test suite. > > It seems to me that either these two modules should not be released=20 > with Tcllib or documentation should be added. imap4 is not released ... It may be in the distribution archives, it will not be installed however, as it is not listed in support/installation/modules.tcl. It does not even have a pkgIndex.tcl file. Nobody seems to be willing to clean it up and make it working. The page module however is installed, and my responsibility. I better start working on the documentation for its packages then. > I also would argue that the README should state that if a *.test file=20 > is provided, it needs to actually test something. A *.test file that=20 > is empty or performs no tests is the same as not having a test suite... True. Do we have packages/modules where that is the case ? -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com Tel: +1 778-786-1122 |
|
From: Andreas K. <and...@ac...> - 2007-08-30 16:08:00
|
> the tcllib README file says > > > * the module should have both documentation ([*]) and a test suite > (in the form of a group of *.test files in the module directory). > > [*] Possible forms: doctools, TMML/XML, nroff (man), or HTML. > The first format is the most preferred as it can be processed with > tools provided by tcllib itself (See module doctools). The first > two are preferred in general as they are semantic markup and thus > easier to convert into other formats. > > * the module must have either documentation or a test suite. It can > not have neither. > > > However, the imap4 and page modules have neither documentation or a test > suite. > > It seems to me that either these two modules should not be released > with Tcllib or documentation should be added. imap4 is not released ... It may be in the distribution archives, it will not be installed however, as it is not listed in support/installation/modules.tcl. It does not even have a pkgIndex.tcl file. Nobody seems to be willing to clean it up and make it working. The page module however is installed, and my responsibility. I better start working on the documentation for its packages then. > I also would argue that the README should state that if a *.test file > is provided, it needs to actually test something. A *.test file that > is empty or performs no tests is the same as not having a test suite... True. Do we have packages/modules where that is the case ? -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com Tel: +1 778-786-1122 |
|
From: Virden, L. W. <lv...@ca...> - 2007-08-30 13:52:47
|
the tcllib README file says
* the module should have both documentation ([*]) and a test suite
(in the form of a group of *.test files in the module directory).
[*] Possible forms: doctools, TMML/XML, nroff (man), or HTML.
The first format is the most preferred as it can be processed with
tools provided by tcllib itself (See module doctools). The first
two are preferred in general as they are semantic markup and thus
easier to convert into other formats.
* the module must have either documentation or a test suite. It can
not have neither.
However, the imap4 and page modules have neither documentation or a test
suite.
It seems to me that either these two modules should not be released
with Tcllib or documentation should be added.
I also would argue that the README should state that if a *.test file
is provided, it needs to actually test something. A *.test file that
is empty or performs no tests is the same as not having a test suite...
--
Tcl - The glue of a new generation. <URL: http://wiki.tcl.tk/ >
Larry W. Virden <mailto:lv...@ca...><URL: http://www.purl.org/NET/lvirden/ >
Even if explicitly stated to the contrary, nothing in this posting should
be construed as representing my employer's opinions.
-><-
|
|
From: Andreas K. <and...@ac...> - 2007-08-28 19:15:16
|
As we are now in the two week bug-fixing phase before actual release I am starting to provide RC archives for us to play with. The first, RC0, is now available, see ftp://ftp.ftp.tcl.tk/pub/incoming/tcllib-rc0-1.10.kit ftp://ftp.ftp.tcl.tk/pub/incoming/tcllib-rc0-1.10.tar.bz2 ftp://ftp.ftp.tcl.tk/pub/incoming/tcllib-rc0-1.10.tar.gz ftp://ftp.ftp.tcl.tk/pub/incoming/tcllib-rc0-1.10.zip -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com Tel: +1 778-786-1122 |
|
From: Virden, L. W. <lv...@ca...> - 2007-08-27 15:51:52
|
Yes, I believe that (1) is the reasonable choice, given that back-porting the fixes for 8.3's 64 bitness is out :-D --=20 <URL: http://wiki.tcl.tk/ > Even if explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. <URL: mailto:lv...@gm... > <URL: http://www.purl.org/NET/lvirden/ > =20 -----Original Message----- From: Andreas Kupries [mailto:and...@ac...]=20 Sent: Monday, August 27, 2007 11:44 AM To: Virden, Larry W.; Tcllib Devel Subject: RE: [Tcllib-devel] Trouble for Tcl 8.2/8.3, 64bit machines,seeking solution > > Other ideas ? Preferences ? (I am currently favoring (2)). > > Are there things that could be done to the packages so that they=20 > worked correctly on the older versions of Tcl? Just to make sure that we are on the same page, the situation is this: 8.3- 8.4+ 32bit OK OK 64bit * OK For 32bit machines everything is fine for all versions of Tcl, it is only 64bit + 8.3- combination which has a problem. > If not, then whatever the lowest > version of Tcl is on which the packages can correctly operation should > be the value of the value. IOW, you are advocating (1). > If the problem is just the test suite, then just mark THAT as=20 > requiring the newer version... No, I am fairly sure the problem is the package and how it is implemented. -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com Tel: +1 778-786-1122 |
|
From: Andreas K. <and...@ac...> - 2007-08-27 15:48:05
|
> > Other ideas ? Preferences ? (I am currently favoring (2)).
>
> Are there things that could be done to the packages so that they worked
> correctly on the older versions of Tcl?
Just to make sure that we are on the same page, the situation is this:
8.3- 8.4+
32bit OK OK
64bit * OK
For 32bit machines everything is fine for all versions of Tcl, it is only
64bit + 8.3- combination which has a problem.
> If not, then whatever the lowest
> version of Tcl is on which the packages can correctly operation should
> be the value of the value.
IOW, you are advocating (1).
> If the problem is just the test suite, then just mark THAT as requiring
> the newer version...
No, I am fairly sure the problem is the package and how it is implemented.
--
Andreas Kupries <and...@Ac...>
Developer @ http://www.ActiveState.com
Tel: +1 778-786-1122
|
|
From: Virden, L. W. <lv...@ca...> - 2007-08-27 10:51:18
|
-----Original Message----- From: Andreas Kupries > Other ideas ? Preferences ? (I am currently favoring (2)). Are there things that could be done to the packages so that they worked correctly on the older versions of Tcl? If not, then whatever the lowest version of Tcl is on which the packages can correctly operation should be the value of the value. If the problem is just the test suite, then just mark THAT as requiring the newer version... |
|
From: Donald G P. <dg...@ni...> - 2007-08-24 21:41:05
|
Andreas Kupries wrote: > (1) The packages currently declares Tcl 8.2 as their minium version. > Move that up to Tcl 8.4. > > Disadvantage. Users of Tcl 8.2 on still wide-spread 32bit machines > cannot use the packages any longer, at least not without editing > the 'package require Tcl' statement. > > On the other hand, Tcl 8.2 is how old now ? > > (2) Like above, but make the Tcl 8.4 requirement dependent on detecting > execution on a 64-bit machine (via tcl_platform(wordSize)). > > Other ideas ? Preferences ? (I am currently favoring (2)). > tcl_platform(wordSize) also requires Tcl 8.4 That leaves (1) as your only option. DGP |
|
From: miguel <ms...@us...> - 2007-08-24 20:20:15
|
Andreas Kupries wrote: > A number of packages have trouble on 64-bit machines, when running against > Tcl 8.2 or Tcl 8.3. There is no trouble with Tcl 8.4+. I believe this is > because of incomplete/buggy 64-bit support in the 8.2/8.3 cores. > > This means that the testsuites go read all over for this combination and I > am getting tired of it. > > The question, what to do ? > > (1) The packages currently declares Tcl 8.2 as their minium version. > Move that up to Tcl 8.4. > > Disadvantage. Users of Tcl 8.2 on still wide-spread 32bit machines > cannot use the packages any longer, at least not without editing > the 'package require Tcl' statement. > > On the other hand, Tcl 8.2 is how old now ? > > (2) Like above, but make the Tcl 8.4 requirement dependent on detecting > execution on a 64-bit machine (via tcl_platform(wordSize)). > > Other ideas ? Preferences ? (I am currently favoring (2)). I would go with (1) myself. It is cleaner, and sends the real message a bit louder: upgrade Tcl. Whatever reason users that can't/won't upgrade Tcl may have, it should also apply to tcllib. We support "upgrade both" (without insisting on anything newer than 5 years, mind you), or don't upgrade at all and keep working as you were. According to the SF download page: 8.4.0 is Sep 2002, 8.3.0 is Feb 2000, 8.2.0 is Aug 1999. Miguel |
|
From: Andreas K. <and...@ac...> - 2007-08-24 20:07:34
|
> On the other hand, Tcl 8.2 is how old now ? Putting in some facts, according to http://wiki.tcl.tk/678 it is 8 years since its release (Aug 17, 1999), and seven for 8.3. -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com Tel: +1 778-786-1122 |
|
From: Andreas K. <and...@ac...> - 2007-08-24 19:48:09
|
A number of packages have trouble on 64-bit machines, when running against
Tcl 8.2 or Tcl 8.3. There is no trouble with Tcl 8.4+. I believe this is
because of incomplete/buggy 64-bit support in the 8.2/8.3 cores.
This means that the testsuites go read all over for this combination and I
am getting tired of it.
The question, what to do ?
(1) The packages currently declares Tcl 8.2 as their minium version.
Move that up to Tcl 8.4.
Disadvantage. Users of Tcl 8.2 on still wide-spread 32bit machines
cannot use the packages any longer, at least not without editing
the 'package require Tcl' statement.
On the other hand, Tcl 8.2 is how old now ?
(2) Like above, but make the Tcl 8.4 requirement dependent on detecting
execution on a 64-bit machine (via tcl_platform(wordSize)).
Other ideas ? Preferences ? (I am currently favoring (2)).
An example of a failing test:
==== aes-fips-C.1e Test vector for AES-128 from FIPS-197 Appendix C.1 FAILED
==== Contents of test case:
list [catch {
set txt [binary format H* 00112233445566778899aabbccddeeff]
set key [binary format H* 000102030405060708090a0b0c0d0e0f]
set enc [aes::aes -mode ecb -dir enc -key $key $txt]
binary scan $enc H* r
set r
} msg] $msg
---- Result was:
1 {integer value too large to represent as non-long integer}
---- Result should have been:
0 69c4e0d86a7b0430d8cdb78070b4c55a
==== aes-fips-C.1e FAILED
--
Andreas Kupries <and...@Ac...>
Developer @ http://www.ActiveState.com
Tel: +1 778-786-1122
|
|
From: Andreas K. <and...@ac...> - 2007-08-20 23:00:25
|
> This year's Tcl conference is only 5 weeks away now and I have > been prodded > to make a release of Tcllib. > > [...] while I start the process > of going over the modules, collect past changes and write updated README, > CHANGES, etc. files. Basic administrative stuff has been done, i.e. fixing version numbers. Most of them were already in sync this time around. I guess due to most people beginning to update the version information when they commit a change. That is good. I also ran a quick test on linux, against 4 shells linux-ix86/8.2.3/bin/wish8.2 linux-ix86/8.3.5/bin/wish8.3 linux-ix86/8.4.13/bin/wish8.4 linux-ix86/8.5a7/bin/wish8.5 Only three problem zones. [8.3.5] snit ~~ FAILS T 628 P 590 S 35 F 3 [8.5a7] mime ~~ FAILS T 91 P 87 S 0 F 4 [8.5a7] textutil ~~ FAILS T 161 P 149 S 0 F 12 The mime/textutil problems seem to be encoding related, and possibly indicate a core bug. I saw them in a test I ran a few weeks ago, and using a lot more different 8.5 shells saw the problem appear and disappear as the core changed. This one will need bi-section search to find out what changes make it appear. The snit failures are my responsibility, in code I introduced. Apparently the 8.3 backport is not quite right. -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com Tel: +1 778-786-1122 |
|
From: Andreas K. <and...@ac...> - 2007-08-20 17:41:10
|
> > Should we expect that Tcl/Tk 8.5 will be released by conference time? I have no idea, this is more a question for tcl-core, and JeffH. > If so, then tcllib needs to test cleanly against it. Well, as clean as possible, even if not released. > This year's Tcl conference is only 5 weeks away now and I have been > prodded to make a release of Tcllib. > > To have a buffer of at least two weeks between Tcllib release and > conference start, i.e. enough time to get the release into ActiveTcl and > the Conference CD we have to start now. This will give us one week for > of relatively normal work, two weeks CVS freeze to make, test and fix > release-candidates and then the two-week buffer. > > So, anybody who has time please have a look over the CVS head for > show-stoppers, be it their own modules, or others, while I start the > process of going over the modules, collect past changes and write > updated README, CHANGES, etc. files. -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com Tel: +1 778-786-1122 |
|
From: Virden, L. W. <lv...@ca...> - 2007-08-20 17:33:10
|
Should we expect that Tcl/Tk 8.5 will be released by conference time? If so, then tcllib needs to test cleanly against it.=20 --=20 <URL: http://wiki.tcl.tk/ > Even if explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. <URL: mailto:lv...@gm... > <URL: http://www.purl.org/NET/lvirden/ > =20 -----Original Message----- From: tcl...@li... [mailto:tcl...@li...] On Behalf Of Andreas Kupries Sent: Monday, August 20, 2007 12:48 PM To: Tcllib Devel Subject: [Tcllib-devel] Tcllib release / Tcl conference This year's Tcl conference is only 5 weeks away now and I have been prodded to make a release of Tcllib. To have a buffer of at least two weeks between Tcllib release and conference start, i.e. enough time to get the release into ActiveTcl and the Conference CD we have to start now. This will give us one week for of relatively normal work, two weeks CVS freeze to make, test and fix release-candidates and then the two-week buffer. So, anybody who has time please have a look over the CVS head for show-stoppers, be it their own modules, or others, while I start the process of going over the modules, collect past changes and write updated README, CHANGES, etc. files. -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com Tel: +1 778-786-1122 ------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Tcllib-devel mailing list Tcl...@li... https://lists.sourceforge.net/lists/listinfo/tcllib-devel |
|
From: Andreas K. <and...@ac...> - 2007-08-20 16:51:56
|
This year's Tcl conference is only 5 weeks away now and I have been prodded to make a release of Tcllib. To have a buffer of at least two weeks between Tcllib release and conference start, i.e. enough time to get the release into ActiveTcl and the Conference CD we have to start now. This will give us one week for of relatively normal work, two weeks CVS freeze to make, test and fix release-candidates and then the two-week buffer. So, anybody who has time please have a look over the CVS head for show-stoppers, be it their own modules, or others, while I start the process of going over the modules, collect past changes and write updated README, CHANGES, etc. files. -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com Tel: +1 778-786-1122 |
|
From: Andreas K. <and...@ac...> - 2007-08-01 21:14:03
|
Two packages enabling us to write multi-file operations without having to redo globs and foreach loops over and over again. A core package which provides this functionality as objects, and a package which provides the same as a single command (with a standard singleton object underneath). Example: fileutil::multi move the * from /sources to /scratch except for *.html More structure: fileutil::multi \ move \ the * \ from /sources \ to /scratch \ except \ for *.html Or, less readable, still valid fileutil::multi \ to /scratch \ from /sources \ move \ exclude *.html \ the * The first package which had this type of specification was 'treeql', also in Tcllib, to select nodes in a tree based on relationships and attributes. q query root children get data The interpreter mechanism underlying 'treeql's implementation was generalized a bit and put into its own module and package, 'wip', the 'word interpreter'. 'fileutil::multi' is the first user of this re-packaged system. Ideas for fileutil::multi I haven't done yet: * recursive operation * change file attributes, like permissions * extract/save/ the set of files the last command operated on. * inject/load a set of files to operate on A multi-rename like 'rename *.c *.cc' would be interesting, however I am not sure yet how to specify that (the example to the left would semi-require to parse the glob pattern). OTOH, the example is only a change of the file extension, and that we should be able to specify and do. Hm ... fileutil::multi \ replace_extension_of the *.c in /wherever except for foo* with CC -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com Tel: +1 778-786-1122 |
|
From: Andreas K. <and...@ac...> - 2007-05-22 21:59:01
|
> > Can you send me the TMML master ? > > It's in CVS in the TMML SF project: > > <URL: > http://tmml.cvs.sourceforge.net/tmml/coredocs/tcllib/TCLLIB.XML > > > > And maybe some of your scripts so that I > > can see how it fits into your workflow ? > > The scripts are also in CVS, but they're pretty much WOMM-only [1], Ok, will get them from there and play around ... Won't be quick ... I might try to go directly to HTML instead of via TMML ... Wonder if we can do automated upload to SF ... No promises however. Just throwing out unfiltered musings and thoughts right now. > even *I* can't get them to work anywhere but on my home machine > anymore. Ah, _that_ certificate. > [1] > http://s3.amazonaws.com/codinghorrorimg/works-on-my-machine-starburst.png -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com Tel: +1 778-786-1122 |
|
From: Joe E. <jen...@fl...> - 2007-05-22 21:50:50
|
Andreas Kupries wrote:
> [I wrote]
> > The main drawback is that when new manpages appear, someone
> > has to determine where they fit in the TOC by hand. I was
> > hoping that you were already maintaining this as a doctools::toc
> > document.
>
> I had forgotten that we havethis format. Well, at least it did not come to
> mind when I was thinking about this ... So, no, currently I do not have such
> a document. However I see nothing against writing such a toc document and
> testing if that can be made to work.
>
> Can you send me the TMML master ?
It's in CVS in the TMML SF project:
<URL: http://tmml.cvs.sourceforge.net/tmml/coredocs/tcllib/TCLLIB.XML >
> And maybe some of your scripts so that I
> can see how it fits into your workflow ?
The scripts are also in CVS, but they're pretty much WOMM-only [1],
even *I* can't get them to work anywhere but on my home machine
anymore.
[1] http://s3.amazonaws.com/codinghorrorimg/works-on-my-machine-starburst.png
--JE
|
|
From: Andreas K. <and...@ac...> - 2007-05-22 21:09:06
|
> It's maintained by hand as a TMML master document. > > If so, we could maybe put the category information into the manpages, as > > proper markup using a new 'category' command, or as temp. hack using > > 'comment' with special contents. > In my experience, this usually isn't the best way to go -- > it's easier to maintain the TOC if the overall structure > is stored in a single file. (For example: splitting up > subsections when they get too big, making sure that "intro" > manpages appear first in each subsection, that sort of thing.) > > The main drawback is that when new manpages appear, someone > has to determine where they fit in the TOC by hand. I was > hoping that you were already maintaining this as a doctools::toc > document. I had forgotten that we havethis format. Well, at least it did not come to mind when I was thinking about this ... So, no, currently I do not have such a document. However I see nothing against writing such a toc document and testing if that can be made to work. Can you send me the TMML master ? And maybe some of your scripts so that I can see how it fits into your workflow ? Another thing to try is to extend SAK to tell us which manpages, if any, are not listed in the TOC yet. -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com Tel: +1 778-786-1122 |
|
From: Joe E. <jen...@fl...> - 2007-05-22 20:58:25
|
Andreas Kupries wrote: > [I wrote] > > Keeping the table of contents up-to-date still takes rather more > > manual work than I'd like. Andreas -- does the tcllib Swiss Army Knife > > tool have a better solution? > > Currently not, I think. How are you generating the TOC again ? > > We are speaking about http://tcllib.sourceforge.net/doc/, right ? > > Where the various packages/modules are sorted into various > categories ? It's maintained by hand as a TMML master document. > If so, we could maybe put the category information into the manpages, as > proper markup using a new 'category' command, or as temp. hack using > 'comment' with special contents. In my experience, this usually isn't the best way to go -- it's easier to maintain the TOC if the overall structure is stored in a single file. (For example: splitting up subsections when they get too big, making sure that "intro" manpages appear first in each subsection, that sort of thing.) The main drawback is that when new manpages appear, someone has to determine where they fit in the TOC by hand. I was hoping that you were already maintaining this as a doctools::toc document. > The latter is however not something I want > to do. Whatver way we go, at the end we can pull the information directly > out of the manpages, or the TMML conversion (I seem to remember that you go > TMML first before going to HTML). Documentation with the information goes to > 'Unfiled' or other category of similar meaning. Then we only have to update > all existing manpages with the current categories to recreate the current > result, and new pages are incrementally assigned a category when created ... That approach works well for keyword-based indexes like [1] and [2], but not as well for the table of contents, since in the TOC order and grouping is more important. [1] <URL: http://tmml.sourceforge.net/doc/tcllib/keyword-index.html > [2] <URL: http://tmml.sourceforge.net/doc/tcllib/category-index.html > --JE |
|
From: Andreas K. <and...@ac...> - 2007-05-22 19:27:05
|
> AKU wrote: > > [LV wrote]: > > > I was noticing today that the bench man pages aren't > available at sf.net. > > > Is bench considered an 'internal' module that people shouldn't use? > > > > No. It just means that Joe hasn't triggred the regeneration of > the doc pages > > for a while. While the building of the docs from the .man files > in tcllib is > > (mostly) automatic, the process has to be triggered by hand. > > Also, it turns out I've been running 'cvs update' instead of > 'cvs update -d' for the last several months and so missed the > new modules. > > Keeping the table of contents up-to-date still takes rather more > manual work than I'd like. Andreas -- does the tcllib Swiss Army Knife > tool have a better solution? Currently not, I think. How are you generating the TOC again ? We are speaking about http://tcllib.sourceforge.net/doc/, right ? Where the various packages/modules are sorted into various categories ? If so, we could maybe put the category information into the manpages, as proper markup using a new 'category' command, or as temp. hack using 'comment' with special contents. The latter is however not something I want to do. Whatver way we go, at the end we can pull the information directly out of the manpages, or the TMML conversion (I seem to remember that you go TMML first before going to HTML). Documentation with the information goes to 'Unfiled' or other category of similar meaning. Then we only have to update all existing manpages with the current categories to recreate the current result, and new pages are incrementally assigned a category when created ... -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com Tel: +1 778-786-1122 |
|
From: Joe E. <jen...@fl...> - 2007-05-19 00:02:16
|
AKU wrote: > [LV wrote]: > > I was noticing today that the bench man pages aren't available at sf.net. > > Is bench considered an 'internal' module that people shouldn't use? > > No. It just means that Joe hasn't triggred the regeneration of the doc pages > for a while. While the building of the docs from the .man files in tcllib is > (mostly) automatic, the process has to be triggered by hand. Also, it turns out I've been running 'cvs update' instead of 'cvs update -d' for the last several months and so missed the new modules. Keeping the table of contents up-to-date still takes rather more manual work than I'd like. Andreas -- does the tcllib Swiss Army Knife tool have a better solution? --Joe English jen...@fl... |
|
From: Virden, L. W. <lv...@ca...> - 2007-05-18 16:24:52
|
=20 Thanks everyone for the update. I was updating the wiki pages for the tcllib modules to point to docs and that's when I noticed the three modules. --=20 <URL: http://wiki.tcl.tk/ > Even if explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. <URL: mailto:lv...@gm... > <URL: http://www.purl.org/NET/lvirden/ > =20 |
|
From: Andreas K. <and...@ac...> - 2007-05-18 16:11:05
|
> Are these three modules considered current, supported, active, > and intended to continue to be installed tcllib modules? > > I notice that currently tcllib cvs head doesn't appear > to be installing calendar and impa4 modules. Are these deprecated? > > The reason this came up is that I happened across the fact that these > three modules don't have a .man file in the module directory. > Do we want to install modules without docs? Ok, I don't have to talk about 'calendar', Kevin has already done that, thank you. I remembered him as the person most responsible for the module. With regard to 'imap4', that module is not deprecated. But simply only because it never was in a state where it could be called a module which we could deprecate. The code in that directory is something we imported from <I do not remember anymore> about I think 2 years ago. With the intention/hope that someone understanding IMAP would take the code and beat it into shape for Tcllib. This has not happened. As such this is, from our POV, pre-alpha code, and not a module fit for installation. Page, aka parsergen, is the support code for apps/page application of mine. This stuff is working. I agree that it should get documentation and a testsuite ... As I have/find time. -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com Tel: +1 778-786-1122 |
|
From: Andreas K. <and...@ac...> - 2007-05-18 16:03:01
|
> I was noticing today that the bench man pages aren't available at sf.net. > Is bench considered an 'internal' module that people shouldn't use? No. It just means that Joe hasn't triggred the regeneration of the doc pages for a while. While the building of the docs from the .man files in tcllib is (mostly) automatic, the process has to be triggered by hand. -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com Tel: +1 778-786-1122 |
31 messages has been excluded from this view by a project administrator.
