Filtered by date 2017-01-02, 521 - 530 of 1541 Postings (
all,
summary)
Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM
On Thu, 27 Dec 2001, Gustaf Neumann wrote:
> what are the general opinions:
> - add it again to the predefined set
> - add it as a separate package
> - do nothing (hope for better "set" methods)
> - others?
Personally I'd like to see the XOTcl core kept as small as possible.
You could maybe have an XOTcl utilities package which includes stuff
like cset and other often used useful functions. OTOH it's not maybe good
to wait for better "set" methods in Tcl itself. My guess is that will
take a while, if not already in 8.4a3, or planned for a4? Haven't heard
anything about them myself.
/
http://www.fishpool.com/~setok/
Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM
I built a small class called Cacheable that can be joined with other
classes and objects. With it you can specify certain methods from which
the returned result should be cached (and for how long). You can also
specify invalidation methods which cause the object's cache to be
empties. All this happens transparently from the methods' point of view.
I put the code up at the Tcler's Wiki:
http://mini.net/cgi-bin/wikit/1298.htmlIf anyone else has some neat examples, it might be a good idea to add them
to the XOTcl page I put up there:
http://mini.net/cgi-bin/wikit/1297.html - ---------- = = ---------//--+
| / Kristoffer Lawson | www.fishpool.fi|.com
+-> | setok_at_fishpool.com | - - --+------
|-- Fishpool Creations Ltd - / |
+-------- = - - - = --------- /~setok/
Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM
Does anyone have an xotcl.dll built against Tcl 8.4 they are willing to
share? I would like to use XOTcl with tclkit on windows. The latest tclkit
is based on Tcl8.4b1 but the xotcl.dll available on the xotcl web page is
built agains Tcl 8.3.
There was a thread about xotcl and tclkit back in October
(
http://alice.wu-wien.ac.at/pipermail/xotcl/2001-October/thread.html). It
seems that the stubs enabled shared library works only when used with the
same version of Tcl that it was built against. That still seems to be the
case.
I tried building myself and was successful in Linux. I get compile errors
using mingw on windows (The error is something like "initializer element is
not constant" in many places in xotclStubInit.c. They look like constants
to me as they are just references to function names). I also tried
cross-compiling from Linux with the same compile errors.
Thanks,
Brian Theado
Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM
Dear XOTcl Community,
Below is the announcement of XOTcl 1.3.5. This is mostly a maintenance
and fix release.
Besides these fixes, the biggest change makes the non positional
argument processing
more compliant to the one of OpenACS. One can write now
% Object o
% o proc foo {-x:boolean -y a b} { ...}
instead of
% ...
% o proc foo {-x:boolean -y} {a b} { ...}
Currently, both variants are supported, the latter variant is deprecated and
will be removed in the future.
This version is also a prerequirement of the soon to be released XOTcl
package for OpenACS (integrated with the api and code browser of OpenACS).
best regards
-gustaf neumann
-----
Major changes relative to 1.3.4 are:
- Qualitative Improvements
* Improved code quality:
+ fixed possible segmentation violations in non positional
argument handling
+ moved the Serializer into a namespace such that
% package req XOTcl
% package req xotcl::serializer
Serialize ....
works without namespace imports (the Serializer is
still auto-exported, but this will change in the future)
+
* Improved Functionality
+ Non-positional arguments can be used in the same argument
list as positional ones (more compliant with OpenACS).
One can write now
% Object o
% o proc foo {-x:boolean -y a b} { ...}
instead of
% ...
% o proc foo {-x:boolean -y} {a b} { ...}
All introspection commands will work like before.
The old syntax (with the additional argument) is deprecated
and will be dropped in the future.
+ Serializer: support for objects with parent namespaces, which are
not xotcl objects
+ additional instproc for ::xotcl::Class allinstances
to return all instances for the actual class
Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM
Hi again,
well the problem here is the same as before. "eval" passes the control
to the Tcl eval command implementation.
That is, all what is called inside an "eval" in an object's namespace
bypasses the XOTcl dispatcher.
So the callstack entries are not correct. also filters/mixins do not
work here.
You should always use the XOTcl invocation syntax "objName methodName
args", like:
$newOb eval {
$newOb doStuff
}
I would like to make it impossible to call doStuff directly here, as in
the example below, but this would
require changes to the Tcl core or has a performance impact; so we chose
to live with the problem that
procs can be called directly via the namespace
Uwe
Kristoffer Lawson wrote:
>
> Still looking for an official explanation for the operations of [eval]
> (and other stuff I posted), but here's another one. The code follows:
>
> package require XOTcl 1.3
> namespace import xotcl::*
>
> Class Foo -parameter doors
>
> Foo instproc init {req} {
> puts $req
> }
>
>
> Object ob
>
> set newOb [Foo new -childof ob hello -doors 4]
> puts "Doors: [$newOb doors]"
>
> $newOb proc doStuff {} {
> puts "class: [self class]"
> set newOb [[self class] new -childof [self] whatevah -doors 3]
> puts "Doors: [$newOb doors]"
> }
>
>
> $newOb doStuff
>
> #$newOb eval {
> # doStuff
> #}
>
> This version correctly states that the class for [self class] is an
> empty string. However, if I comment out the "eval" version and use it
> instead, [self class] gives me "::xotcl::Object".
>
> / http://www.fishpool.com/~setok/
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
--
Uwe Zdun
Department of Information Systems, Vienna University of Economics
Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746
zdun_at_acm.org, uwe.zdun_at_wu-wien.ac.at
Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM
Hi,
How do you enforce abstract methods? For example:
Class Foo
Foo abstract instproc procdef args
Class Bar -superclass
Bar instproc proc2
Bar barObj
I would like an error to be thrown at the "Bar barObj" line because the Bar
object doesn't define the procdef instproc. Is this rule enforceable? Is my
only way at it to use assertions?
Thanks,
L
--
MY EMAIL ADDRESS HAS CHANGED --> UPDATE YOUR ADDRESSBOOK
Laurent Duperval "Montreal winters are an intelligence test,
Netergy Networks - Java Center and we who are here have failed it."
Phone: (514) 282-8484 ext. 228 -Doug Camilli
mailto:laurent.duperval_at_netergynet.com Penguin Power!
Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM
That's correct Jeff,
I thought perhaps it might be possible but could see how it might be a
performance hit
cept on the dual opterons it is quite fast.
perhaps if it were to be implemented it could be a switch to enable it?
Though it sounds like there are no cycles for such a feature.
XOTcl is cool and becoming more popular.
Thanks
John
Jeff Hobbs wrote:
>John McGlaughlin wrote:
>
>
>>Can an extension be added to tkcon so that the interpreter becomes aware
>>of XOTcl proc, instprocs and associated vars for type ahead capability.
>>
>>
>
>tkcon only does the "first" level of expansion for procs. I
>assume you are looking for object instrospection that will
>expand methods and/or vars then?
>
>
>
>>Lazy,
>>
>>
>
>That I understand well. ;)
>
>Jeff
>
>
>
Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM
Thank you, Gustaf. Makes sense.
Is there anyway to call a method besides doing a "puts".
Putting in:
s1 push a
results in an error, however I can do:
puts [s1 pop]
I would think that there would be a way to call a method without
outputiing. Is there one?
Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM
Hi!
What I want to achieve is to get informed each time a Class is getting
destroyed. I do need to know the name of the class and its calling
environment (namespace).
What I did is:
Class create ::xotcl::_destroyer -instproc destroy {args} {
puts "DESTROY '[self class]'"
puts "DESTROY '[self calledclass]'"
puts "DESTROY '[self callingclass]'"
next
}
Class instmixin ::xotcl::_destroyer
Now...
Class Dummy
Dummy destroy
... gives ...
DESTROY '::xotcl::_destroyer'
DESTROY '::xotcl::Object'
DESTROY ''
What I expected to get was "DESTROY 'Dummy'" or "DESTROY '::Dummy'"
but this does not happen. Why?
Thanks,
Zoran
Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM
Dear XOTcl developers,
I'm trying to use XOTcl (1.6.5) with Tcl8.6.
Apparently XOTcl does not compile with Tcl8.6, but on Linux, I can get it to work by using a version compiled for Tcl8.5.4.
However, this is not the case on Windows: loading XOTcl will make Tcl8.6 crash there.
I also tried to use the xotcl165.dll provided by Activestate in the Tcl8.6b1 distribution. This seems to work with Tcl8.6b1 indeed, but not with newer versions of Tcl fetched from CVS (which I need).
Is it possible today to use XOTcl in a recent Tcl8.6 ?
Or are there any plans to update XOTcl ?
Best regards,
Koen Danckaert