Menu
▾
▴
tcllib-devel
|
From: Andreas K. <aku...@sh...> - 2009-10-29 04:47:32
Attachments:
tepam_introduction.pdf.gz
|
> Dear Tcllib administrators, The TCL language doesn't provide any
> native support to handle easily sub commands and procedure arguments
> and options, even if these features are heavily used by the standard
> TCL and TK commands.
> To eliminate this lack of native language support, I have written
> TEPAM, the 'Tcl's Enhanced Procedure and Argument Manager'. Attached
> to this mail you can find a short introduction into TEPAM and an
> overview of its major features.
> I would like to publish TEPAM as open source and am checking if I
> can include TEPAM into an existing project. Do you think that the
> Tcllib would be an adequate project to include TEPAM?
Yes in general, with the form generator part more something for Tklib,
which however is in the same SF project.
One question which does not seem to be ansewered by the introduction
is the license you plan to release the package under. The tcllib
project would strongly prefer release under a BSD license.
> If yes, what would be the way how I should proceed? I guess I cannot
> just commit my module to the Tcllib's CVS repository, but I think
> that this module should certainly first be reviewed by a project
> admin, and then cleaned up by myself to fit into the project's
> framework.
The main entry for new features is the 'bug' tracker of the project on
SourceForge, although this is not a bug but a Feature Request (FR).
Not having seen the sources yet, I can only give general advice regarding
cleanup, etc.:
- We would like to have one or more files ending .test, containing a
testsuite for the features of the package.
- Documentation is preferably written in doctools format (x).
The .test and .man files in existing packages can serve as examples.
I have directed my answer to not only you directly, but also the
tcllib-devel mailing list of the project, which is the main list for
discussing all things related to Tcllib, including new packages.
I also re-attached your introduction so that the list members will be
able to read it as well, assuming that the attachment won't get
stripped off by SF's mail software.
> If you think that Tcllib is not the adequate hosting project, would
> you have a recommendation for a more suitable project?
> Thank you very much.
> Best regards,
> Andreas Drollinger
(x) Language introduction
http://docs.activestate.com/activetcl/8.5/tcllib/doctools/doctools_lang_int
ro.html
Language Syntax Reference
http://docs.activestate.com/activetcl/8.5/tcllib/doctools/doctools_lang_syn
tax.html
Language Command Reference
http://docs.activestate.com/activetcl/8.5/tcllib/doctools/doctools_lang_cmd
ref.html
--
So long,
Andreas Kupries <aku...@sh...>
<http://www.purl.org/NET/akupries/>
Developer @ <http://www.activestate.com/>
-------------------------------------------------------------------------------
|
|
From: Gerald W. L. <Ger...@co...> - 2009-10-29 17:15:19
|
Andreas Kupries wrote: >> Dear Tcllib administrators, The TCL language doesn't provide any >> native support to handle easily sub commands and procedure arguments >> and options, even if these features are heavily used by the standard >> TCL and TK commands. >> Does not ensembles provide for the sub-commands? -- +------------------------------------------------------------------------+ | Gerald W. Lester | |"The man who fights for his ideals is the man who is alive." - Cervantes| +------------------------------------------------------------------------+ |
|
From: Andreas K. <and...@ac...> - 2009-10-29 17:34:32
|
Gerald W. Lester wrote:
> Andreas Kupries wrote:
>>> Dear Tcllib administrators, The TCL language doesn't provide any
>>> native support to handle easily sub commands and procedure arguments
>>> and options, even if these features are heavily used by the standard
>>> TCL and TK commands.
>>>
> Does not ensembles provide for the sub-commands?
Andreas Dollinger (the original submitter) might be better able to answer here.
My understanding from the introductory pdf is that he provides snit
hierarchical methods, just for procedures.
procedure {a sub1} {...} {...}
procedure {a sub2} {...} {...}
=> We get a single command a which has sub commands sub1 and sub2
Internally this may be very be done with namespace ensembles.
I am guessing that the point for him is the ease of declaring them, which is
the point in snit as well (I very recently converted a switch-style sub command
handling in a snit class to hierachical methods, which made things much easier).
--
Sincerely,
Andreas Kupries <an...@ac...>
Developer @ <http://www.activestate.com/>
|
|
From: Lars H. <Lar...@re...> - 2009-10-29 18:16:20
|
Andreas Kupries skrev: > Gerald W. Lester wrote: >> Andreas Kupries wrote: >>>> Dear Tcllib administrators, The TCL language doesn't provide any >>>> native support to handle easily sub commands and procedure arguments >>>> and options, even if these features are heavily used by the standard >>>> TCL and TK commands. >>>> >> Does not ensembles provide for the sub-commands? They can also be used to provide for options: http://wiki.tcl.tk/21443 ;-) > Andreas Dollinger (the original submitter) might be better able to answer here. > > My understanding from the introductory pdf is that he provides snit > hierarchical methods, just for procedures. You mean "hierarchical methods, like in snit" (concept) or "the hierarchical methods of snit" (implementation)? I guess the former from what came next, but it sounded like you were saying the latter. Lars Hellström |
|
From: Andreas K. <and...@ac...> - 2009-10-29 18:19:21
|
Lars Hellström wrote: >>> Does not ensembles provide for the sub-commands? > They can also be used to provide for options: http://wiki.tcl.tk/21443 > ;-) >> Andreas Dollinger (the original submitter) might be better able to answer here. >> My understanding from the introductory pdf is that he provides snit >> hierarchical methods, just for procedures. > You mean "hierarchical methods, like in snit" (concept) or "the > hierarchical methods of snit" (implementation)? I guess the former from > what came next, but it sounded like you were saying the latter. I meant the former, concept. -- Sincerely, Andreas Kupries <an...@ac...> Developer @ <http://www.activestate.com/> |
|
From: Andreas D. <an...@dr...> - 2009-10-29 22:40:40
Attachments:
tepam_sub_commands.pdf
andreas.vcf
|
Dear all, Thanks for your first feedbacks to my initial mail. I will try to answer all your questions in this single mail: 1) License: I have already planned to use the BSD license for this package 2) Tklib for the form generator: It may be wise to separate the graphical parts from the procedure and argument manager and to place them into Tklib. There is certainly no problem to use inside the Tcllib packages other packages from Tklib, isn't there? The core TEPAM package would also relay on the form generator package in Tklib. 3) There is already a comprehensive regression test in place for the non-graphical part of TEPAM. Nevertheless, in case Tcllib is using an own test framework, this regression test has certainly to be adapted to the Tcllib test framework. For the graphical part of the TEPAM package there is no regression test for the moment available. 4) It should be fine to write the command reference documentation in the doctool format. Nevertheless, I am not sure if this format is adequate for a tutorial (like the TEPAM introduction) that will also include some pictures. 5) Concerning the sub-commands, TEPAM is basically providing an easy way to declare them. Sub-commands can be declared individually each from the other with individual procedure bodies like normal procedures, and TEPAM will then call the right procedure body in function of the selected sub-command. The attached document provides an example of the declaration and usage of sub-commands with TEPAM. I hope I could answer your questions. Best regards, Andreas Drollinger |
|
From: Andreas D. <an...@dr...> - 2009-11-03 22:12:43
Attachments:
andreas.vcf
|
Hello, TEPAM uses an own regression test framework. But I like the TclTest package and its futures and will check the effort to use this package. The introduction you have seen has been written in M$ Word. But just for consistency reasons between the different Tcllib package it is a need to write any reference documentation in the doctool format and I will do this. But when I check the tcllib source package I can also find packages that have some HTML files. Such a HTML formated tutorial could be part of the provided examples, couldn't it? Well, the tutorial can certainly also be written in pure text using the doctool format. In this case the TEPAM package will probably have the following man pages: - tepam::tutorial (or tepam::introduction) - tepam::procedure - tepam::argument_dialogbox I guess any other pages can be added to the tcllib documentation, if this is required, can't it? Concerning the question if the graphical part (the argument dialogbox) should be placed into the tklib, or if the entire existing tepam package should be part of the tcllib can be decided later. I suggest to perform now first some cleanup on the package, to use for the regression test the TclTest package and to write an initial reference documentation in the doctool format. The package can then be reviewed and it can be decided if it meets the tcllib's quality standard, and if it should be split into two parts or not. I definitively need a couple of days to find the time to do this cleanup. Best regards, Andreas Drollinger |
|
From: Andreas D. <an...@dr...> - 2010-01-18 22:28:00
|
Dear all, The necessary changes of the TEPAM module (Tcl's Enhanced Procedure and Argument Manager) to make it compliant with Tcllib could finally be completed. The following adaptations and modifications have been made on the module: * Writing the documentation in the Doctools style: Three documents are provided: 1) TEPAM introduction, 2) tepam::procedure manual page, 3) tepam::argument_dialogbox manual page. * Change of the regression test: It is now compliant with the Tcllib test framework. * Completion of the regression test: Also most features of the graphical argument_dialogbox function are now tested. * Validation of TEPAM using several Tcl/Tk versions: The regression test passes now on Linux Tcl/Tk 8.3.0, 8.3.5, 8.4.7, 8.5.6 and 8.6b1, as well as on Windows Tcl 8.4.7 and 8.5.8. Since the Tcllib's test framework doesn't seam to be compliant with Tcl 8.3.x, a simplified framework has been used for Tcl 8.3.x. * Cleanup: Code and documents have generally been cleaned-up. * Demo: The demo has been completed and is presenting now most features of TEPAM's procedure and argument_dialogbox commands. What would be now the next steps to submit this new module into the Tcllib package? Is there an acceptance committee that is voting about the incorporation of new modules into Tcllib? Is there a review committee that checks the quality and completenesses of a new module, before the new code is checked into the version control system? Thanks for indicating me the next steps for the submission of this module. Best regards, Andreas |
|
From: Andreas K. <and...@ac...> - 2010-01-22 19:03:50
|
Andreas Drollinger wrote:
> Dear all,
With nobody else answering it seems to fall to me.
> The necessary changes of the TEPAM module (Tcl's Enhanced Procedure and
> Argument Manager) to make it compliant with Tcllib could finally be
> completed. The following adaptations and modifications have been made on
> the module:
>
> as on Windows Tcl 8.4.7 and 8.5.8. Since the Tcllib's test framework
> doesn't seam to be compliant with Tcl 8.3.x,
This is quite possible (*). I haven't run the tcllib testsuite against 8.3 for
quite some time now, only 8.4.19, 8.5.8, 8.6/cvs-head.
> a simplified framework has been used for Tcl 8.3.x.
> What would be now the next steps to submit this new module into the
> Tcllib package? Is there an acceptance committee that is voting about
> the incorporation of new modules into Tcllib? Is there a review
> committee that checks the quality and completenesses of a new module,
> before the new code is checked into the version control system? Thanks
> for indicating me the next steps for the submission of this module.
No, we have no commitees for either acceptance, or review. There are some
semi-automatic review simply by using
sak.tcl test run
and sak.tcl validate
for the new module.
In essence now either
(a) one of the Tcllib admins makes you a developer for Tcllib, i.e. giving
you CVS write access and you can then do the commit, or
(b) you create a new entry in the Tcllib Tracker on SF, with your work
attached, and then any of the existing developers can do the
integration.
I personally prefer (a), because then the admin can set the trackers up so that
the notifications when entries for the module are added to the trackers are
directed to you, i.e. you will be(come) the maintainer for this part of Tcllib.
The admins are (alphabetically sorted by sf id):
* andreas_kupries (thats me)
* dev_null42a
* ericm
* hobbs
* kennykb
* kuchler
* rmax
* techentin
* welch
How do you wish to go forward ?
--
Sincerely,
Andreas Kupries <an...@ac...>
Developer @ <http://www.activestate.com/>
|
|
From: Andreas D. <dr...@us...> - 2010-02-15 21:17:49
|
Dear Tcllib developer, I finally could complete the cleanup work on the new Tcllib module TEPAM (Tcl's Enhanced Procedure and Argument Manager) and check-in a first version into the repository. The interested people can find the documentation of this new module attached to this mail. Please start with the 'tepam_introduction.html' document that provides an informal overview about the module. the other two files are then the reference manuals of the two major commands provided by TEPAM. You can also run the demo 'tepam_demo.tcl' from Tcllib's example folder that will open a tiny graphical environment from which you can select several demos that are visualizing TEPAM's features. Please let me know if you can find any issues with this new module, or if you have any recommendations or suggestions either for the main package file, for the documentation, the examples or the regression test. Any feedback will be appreciated. Best regards, Andreas Drollinger |
|
From: Andreas K. <and...@ac...> - 2010-02-16 16:47:46
|
Andreas Drollinger wrote:
> Dear Tcllib developer,
> I finally could complete the cleanup work on the new Tcllib module TEPAM
> (Tcl's Enhanced Procedure and Argument Manager) and check-in a first
> version into the repository.
> The interested people can find the documentation of this new module
> attached to this mail.
Actually we will not. The SF mailing lists strip attachments of mails going
through them.
--
Sincerely,
Andreas Kupries <an...@ac...>
Developer @ <http://www.activestate.com/>
|
|
From: Andreas D. <dr...@us...> - 2010-02-16 21:42:17
|
Hello, It seems that mail attachements are generally removed by the SF mail distribution system. The TEPAM documentation is of course also part of the TEPAM module that has been checked into the repository. You have to generate yourself the documentation from the Doctools format into your preferred format. Sorry for the inconvenience! Best regards, Andreas Drollinger On 16.02.10 17:43, Andreas Kupries wrote: > Andreas Drollinger wrote: >> Dear Tcllib developer, >> I finally could complete the cleanup work on the new Tcllib module >> TEPAM (Tcl's Enhanced Procedure and Argument Manager) and check-in a >> first version into the repository. > >> The interested people can find the documentation of this new module >> attached to this mail. > > Actually we will not. The SF mailing lists strip attachments of mails > going through them. > |
|
From: Andreas K. <and...@ac...> - 2009-10-30 20:55:15
|
Andreas Drollinger wrote:
> Dear all,
> Thanks for your first feedbacks to my initial mail.
> I will try to answer all your questions in this single mail:
>
> 1) License: I have already planned to use the BSD license for this package
Ok.
> 2) Tklib for the form generator: It may be wise to separate the
> graphical parts from the procedure and argument manager and to place
> them into Tklib. There is certainly no problem to use inside the Tcllib
> packages other packages from Tklib, isn't there?
Such a dependency would be new, no other package has such (IIRC).
My take is that having it should be no problem.
> The core TEPAM package
> would also rely on the form generator package in Tklib.
> 3) There is already a comprehensive regression test in place for the
> non-graphical part of TEPAM. Nevertheless, in case Tcllib is using an
> own test framework,
Tcllib uses Tcl's tcltest package as the basis of its test framework.
If your test framework is also based on tcltest then the main issue/difference
may be the way the package under test, and support code, are loaded.
In tcllib we use semi-bolilerplate code like
# --------------------------------------------------------------------
source [file join \
[file dirname [file dirname [file join [pwd] [info script]]]] \
devtools testutilities.tcl]
testsNeedTcl 8.2
testsNeedTcltest 1.0
testing {
useLocal aes.tcl aes
}
# --------------------------------------------------------------------
for this.
> this regression test has certainly to be adapted to
> the Tcllib test framework. For the graphical part of the TEPAM package
> there is no regression test for the moment available.
That is ok.
>
> 4) It should be fine to write the command reference documentation in the
> doctool format. Nevertheless, I am not sure if this format is adequate
> for a tutorial (like the TEPAM introduction) that will also include some
> pictures.
True, doctools currently does not support pictures as part of the manual. We
have some semi-support in a related format (TIP's), and its rendering system.
We may be able to adopt a similar strategy for doctools. The strategy of
tiprender is to have the basename of the image in the document sources, and
then have the renderer select the specific format of the image, assuming that
such exists. Example
Sources.
#img foo
Renderers
HTML looks for foo.gif
Text looks for foo.text
etc.
where it is assumed that these files are all containing the same image, in
different representations. Like foo.text some ascii-art representation of the
foo.gif).
What format are you using for your introduction which then gets converted into
PDF ? Assuming that there is a source format different than PDF.
>
> 5) Concerning the sub-commands, TEPAM is basically providing an easy way
> to declare them. Sub-commands can be declared individually each from the
> other with individual procedure bodies like normal procedures, and TEPAM
> will then call the right procedure body in function of the selected
> sub-command. The attached document provides an example of the
> declaration and usage of sub-commands with TEPAM.
I believe declaration and usage were not in doubt, the original question
pointed more to the implementation. However that is more for Gerald, as he put
up the original question about this.
--
Sincerely,
Andreas Kupries <an...@ac...>
Developer @ <http://www.activestate.com/>
|
|
From: Andreas D. <an...@dr...> - 2009-11-09 20:53:22
Attachments:
andreas.vcf
|
Andreas,
I have some troubles with the semi-bolilerplate code you are using as
test harness for the tcllib packages:
# --------------------------------------------------------------------
source [file join \
[file dirname [file dirname [file join [pwd] [info script]]]] \
devtools testutilities.tcl]
testsNeedTcl 8.2
testsNeedTcltest 1.0
testing {
useLocal aes.tcl aes
}
# --------------------------------------------------------------------
Calling my tests with source <TestFile> fails, since one of the first
executed commands of the testutilities.tcl file is 'if {![package
vsatisfies [package provide tcltest] 2.0]} {...'.
But because the tcltest package is only loaded later with the
'testsNeed'Tcltest' command, 'package provide tcltest' return an empty
string and this creates an error with the 'package vsatisfies' command.
When I add 'package require tcltest' in front of the semi-bolilerplate
code my tests can be executed. But I guess this additional statement
should not be required using the correct test launch approach.
So, could you tell me how exactly you are launching the test suite for
that the Tcltest package is already loaded before the test file is sourced?
Thanks!
Andreas
|
|
From: Andreas K. <and...@ac...> - 2009-11-09 21:22:11
|
Andreas Drollinger wrote:
> Andreas,
> I have some troubles with the semi-bolilerplate code you are using as
> test harness for the tcllib packages:
>
> # --------------------------------------------------------------------
> source [file join \
> [file dirname [file dirname [file join [pwd] [info script]]]] \
> devtools testutilities.tcl]
> testsNeedTcl 8.2
> testsNeedTcltest 1.0
> testing {
> useLocal aes.tcl aes
> }
> # --------------------------------------------------------------------
>
> Calling my tests with source <TestFile> fails,
How exactly are you invoking your tests ?
The standard way of testing a module is (*),
% ./sak.tcl test run ... modules/<yourmodule>
where ... stands for additional options you may specify (**).
This invokes the tests of <yourmodule> indirectly through the main driver
script/application
support/devel/all.tcl
This driver loads tcltest, and also generates all the standard output sak.tcl
is parsing for its display.
I hope that helps.
~~~~~~~
(*) As documented in the file README.developer.
(**) More information regarding the acceptable options can be had via
% sak.tcl help test
> since one of the first
> executed commands of the testutilities.tcl file is 'if {![package
> vsatisfies [package provide tcltest] 2.0]} {...'.
>
> But because the tcltest package is only loaded later with the
> 'testsNeed'Tcltest' command, 'package provide tcltest' return an empty
> string and this creates an error with the 'package vsatisfies' command.
>
> When I add 'package require tcltest' in front of the semi-bolilerplate
> code my tests can be executed. But I guess this additional statement
> should not be required using the correct test launch approach.
>
> So, could you tell me how exactly you are launching the test suite for
> that the Tcltest package is already loaded before the test file is sourced?
>
> Thanks!
> Andreas
>
--
Sincerely,
Andreas Kupries <an...@ac...>
Developer @ <http://www.activestate.com/>
|
|
From: Larry W. V. <lv...@gm...> - 2009-11-01 04:55:11
|
I had two thoughts while reading the paper today. 1. there's a third mode of the package that might be useful - basically, a text version of the package, except when an error arises, when, at that point, the interactive tk widget would open up as a way for the user to provide missing info or correct something wrong. 2. I wonder if the interactive mode is so integrated into the package that it would be better for the whole package to be a part of tklib, rather than tcllib. |
|
From: Johann O. <joh...@go...> - 2009-11-01 11:52:22
|
Hi Larry, I would like to pack you up in your opinion and would vote for 2.) - as it sounds more clean logic for me. Also regarding version handling, it's easier to maintain tcllib / tklib separately, without the need to raise a version here *and* there. Rgds. and have a nice sunday, Johann On Nov 1, 2009, at 5:55 AM, Larry W. Virden wrote: > I had two thoughts while reading the paper today. > > 1. there's a third mode of the package that might be useful - > basically, a text version of the package, except when an error arises, > when, at that point, the interactive tk widget would open up as a way > for the user to provide missing info or correct something wrong. > > 2. I wonder if the interactive mode is so integrated into the package > that it would be better for the whole package to be a part of tklib, > rather than tcllib. > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Tcllib-devel mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcllib-devel |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X