Dear XOTcl Community,
i am proud to announce the availability of XOTcl 1.3.0. Major changes relative to 1.2.0 are:
- Qualitative Improvements * Improved portability: + TEA3 compatible build + Much more polished configure+makefile (many thanks to Jim Lynch for his help)
* Improved code quality: + fixed 2 possible segmentation violations (error handling) + fixed free memory reads (many thanks to Zoran Vasiljevic for his help with purify)
* Less intrusive usage of XOTcl components: + XOTcl procs and instprocs use now the namespace in which they were defined. One can use XOTcl packages without having the need to import xotcl globally or to use the xotcl-prefix in all xotcl procs/instprocs.
- Functional Improvements * New forwarding mechanisms for fast delegation: new methods 'forward' and 'instforward' (many thanks to Bryan Schofield for fruitful discussions and suggestions). This method is a superset of tclcmd/insttclcmd, which has been marked as deprecated. See the tutorial for more details.
* Nonpositional arguments for xotcl procs/instprocs; this is a flexible way to check arguments, to provide defaults etc for every xotcl proc/instproc. It uses a similar syntax as ad_proc and ad_page_contract in OACS. See the tutorial for more details.
* Extended methods filter, mixin, instfilter, instmixin as discussed in the XOTcl mailing list. These commands can be used more flexibly as follows
obj mixin same as: obj info mixin obj mixin {C1 C2} same as: obj mixin set {C1 C2} obj mixin set {C1 C2} sets the mixins for obj obj mixin get same as: obj info mixin obj mixin add C3 adds a mixin on front of the mixin list obj mixin add C3 end adds a mixin at the end the mixin list obj mixin add C3 3 adds a mixin at the 3rd position obj mixin delete ::C3 removes the mixin from the mixin list
The same semantics are available as well for filter, instmixin and instfilter. This change is fully backward compatible. {filter,instfilter,mixin,instmixin}append are deprecated now.
For more details about the changes, please consult the ChangeLog and documentation.
MORE INFO General and more detailed information about XOTcl and its components can be found at http://www.xotcl.org
Best regards,
Gustaf Neumann Uwe Zdun
On Wed, 18 Aug 2004, Gustaf Neumann wrote:
* Nonpositional arguments for xotcl procs/instprocs; this is a flexible way to check arguments, to provide defaults etc for every xotcl proc/instproc. It uses a similar syntax as ad_proc and ad_page_contract in OACS. See the tutorial for more details.
Interesting... I wonder if something like that could be TIPped into Tcl itself? What about if I don't define any nonpositional arguments, can I pass arguments beginning with a dash? I kind of hope so, or otherwise it may be necessary to pass "--" everywhere, and it adds incompatibility with older XOTcls.
On Wednesday 18 August 2004 16:17, Kristoffer Lawson wrote:
On Wed, 18 Aug 2004, Gustaf Neumann wrote:
* Nonpositional arguments for xotcl procs/instprocs; this is a flexible way to check arguments, to provide defaults etc for every xotcl proc/instproc. It uses a similar syntax as ad_proc and ad_page_contract in OACS. See the tutorial for more details.Interesting... I wonder if something like that could be TIPped into Tcl itself?
sure, it can. It can be implemented as well fully in Tcl, as done in ad_proc (or ad_page_contract) in Open ACS. Uwe implemented a fast c-based version, borrowing the syntax from OACS.
What about if I don't define any nonpositional arguments, can I pass arguments beginning with a dash? I kind of hope so, or otherwise it may be necessary to pass "--" everywhere, and it adds incompatibility with older XOTcls.
one can define procs/instprocs with non-positional arguments and without. If you have nonposistional arguments defined, and you want to pass e.g. -a as "traditional" argument, you must use "--".
Since existing scripts have no nonpositional arguments defined, nothing changed there, older scripts continue to work unmodified.
-gustaf
/ http://www.fishpool.com/~setok/
Xotcl mailing list - Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
On Wed, 18 Aug 2004, Gustaf Neumann wrote:
What about if I don't define any nonpositional arguments, can I pass arguments beginning with a dash? I kind of hope so, or otherwise it may be necessary to pass "--" everywhere, and it adds incompatibility with older XOTcls.
one can define procs/instprocs with non-positional arguments and without. If you have nonposistional arguments defined, and you want to pass e.g. -a as "traditional" argument, you must use "--".
Since existing scripts have no nonpositional arguments defined, nothing changed there, older scripts continue to work unmodified.
This is what I meant. That if no nonpositional args are defined, arguments beginning with "-" will be sent as-is to the procedure. I understand from your explanation, that this is indeed what happens.
Hi Kristoffer,
there should be no incompatibilities with older versions. non-pos args are a pure extension by one additional argument if there is none, you have no non-pos arguments. See the tutorial for examples.
Uwe
Kristoffer Lawson wrote:
On Wed, 18 Aug 2004, Gustaf Neumann wrote:
* Nonpositional arguments for xotcl procs/instprocs; this is a flexible way to check arguments, to provide defaults etc for every xotcl proc/instproc. It uses a similar syntax as ad_proc and ad_page_contract in OACS. See the tutorial for more details.Interesting... I wonder if something like that could be TIPped into Tcl itself? What about if I don't define any nonpositional arguments, can I pass arguments beginning with a dash? I kind of hope so, or otherwise it may be necessary to pass "--" everywhere, and it adds incompatibility with older XOTcls.
/ http://www.fishpool.com/~setok/
Xotcl mailing list - Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
Hi.
I'm Jim Lynch, and I have started making improvements to the configure/ build process for xotcl. As Gustaf mentions in his letter, my work is incorporated into xotcl-1.3.0, mostly in the files called configure.in and Makefile.in.
Executive summary: Big immprovement; not finished. Separate build dirs do not work yet. xotclConfig.sh gets installed in $libdir; please read it, especially if you are an embedder or similar. Lots more work to do, but it works for most cases when you build in the source tree root.
On Wed, 18 Aug 2004 11:44:02 +0200 Gustaf Neumann neumann@wu-wien.ac.at wrote:
Dear XOTcl Community,
i am proud to announce the availability of XOTcl 1.3.0. Major changes relative to 1.2.0 are:
- Qualitative Improvements
- Improved portability:
- TEA3 compatible build
- Much more polished configure+makefile (many thanks to Jim Lynch for his help)
[snip]
Best regards,
Gustaf Neumann Uwe Zdun
Thank you :)
But I still have things to do and things to ask for, which I will: some now, some later :)
I have to learn how to make separate build dirs work, or what the prevailing standard is, and make that work, so that people can do
mkdir build cd build ../configure --with-all make make install (read the xotclConfig.sh to see which tcl has the package installed) (run the shell from that tcl) % package require XOTcl
and have the shell load xotcl. Added complication is there are several nested build trees; the configure and build steps work for this except when trying to use a separate build dir.
I would like to ask embedders of xotcl, if there is a chance you'd be able to use a tclsh where you do the package require of xotcl and other packages you need, rather than use xotclsh and xowish... it's been suggested that this might be the more portable approach, but I want to ask all of the embedders first before I ask Gustaf whether it'd be ok to deprecate them in favor of having the embedders prepare a plain tclsh.
Also to embedders!! The file xotclConfig.sh is now installed, and has -relevent- information about where the install of xotcl is! I ask you to please read this file; it gets installed in $libdir. In addition, this file only covers posix shells, not csh. Any csh-using embedders here? If so, I'll figure out how to deshellify this script; all it does is set some variables in the environment.
There will be a lot more later... but this is enough for now :)
Comments please :)
-Jim
-- Jam sessions community web site: http://jam.sessionsnet.org
I have to learn how to make separate build dirs work, or what the prevailing standard is, and make that work, so that people can do
Hi Jim, yes, this is still an issue (see below), it effects only people configuring the subdirs (e.g. via --with-all or --with-actiweb). It is not an issue, if the default configuration is used.
... I would like to ask embedders of xotcl, if there is a chance you'd be able to use a tclsh where you do the package require of xotcl and other packages you need, rather than use xotclsh and xowish... it's been suggested that this might be the more portable approach, but I want to ask all of the embedders first before I ask Gustaf whether it'd be ok to deprecate them in favor of having the embedders prepare a plain tclsh.
Jim, xotclsh and xowish are already deprecated and are not build by default. Techically there is no need to use xotclsh at all. Note also, that xotclsh is a tclsh doing a "package req XOTcl" + "namespace import" from the C-level. This means that if package require does not work from a tclsh (e.g. due to paths), xotclsh would not work as well. xotclsh is not used in the build/test/install cycle, so i don't see the connection the subdir/build issue. What do you mean by "preparing" a plain tclsh?
i have sent you with a separate mail a slightly updated version of xotcl, where mkdir build cd build ../configure --with-all make make test make install works. It is still not perfect, since the binaries of the configured subdirs (sdbm/gdbm/expat) are still built in the source tree, not in the build tree. maybe you have an idea how to get these into the build tree as well.
best regards -gustaf PS: i'll be on vacation for 14 days starting in the mid of next week.
-
Gustaf Neumann -
Jim Lynch -
Kristoffer Lawson -
Uwe Zdun