Weblog Page

From: Uwe Zdun <bm0005_at_sp2.power.uni-essen.de>
Date: Tue, 19 Mar 2002 22:25:59 +0100 (MEZ)

Hi,

the basic idea is to re-define the _at_ token at runtime, if needed, before
the code wit the metadata ist exectuted, and then a dynamic object
structure is build that can be queried. staticMetaDataAnaylzer.xotcl does
the same but it does only look at the metadata (and class dependencies,
methods). It uses the dynamic script metadataAnalyzer.xotcl.

here's an example use of this script (from its documentation):

    package require xotcl::metadataAnalyzer

    # instantiate metadata analyzer object
    MetadataAnalyzer _at_::m
    # make this object be known to _at_ and turn @ metadata processing on
    _at_ analyzerObj @::m
    _at_ onOff 1

    # read in some metadata tags (in sample file) & execute the file
    source lib/testx.xotcl

    # turn _at_ metadata processing off again
    _at_ onOff 0

    # print out all collected metadata
    puts [_at_::m print]


It should have more handy info options etc. but this has to be still
implemented ... perhaps you like to volunteer ...
of course, you can also implement other interpretations of _at_ for your own
purposes. If so, please let us know, so that other users
benefit from these functionalities as well.

--uwe




On Tue, 19 Mar 2002, Catherine Letondal wrote:

>
> Hi,
>
> I believe the only way to document code is now through the _at_ object
> and the makeDoc.xotcl script, which uses several utilities from the
> library/system directory (the old one was the metadata mechanism).
> Am I right?
>
> My question is about the introspective aspect of this feature: how
> do you get the documentation for a class, method, ...?
> By parsing its file?
>
> Thanks a lot for any help,
>
> --
> Catherine Letondal -- Pasteur Institute Computing Center
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

From: <seva_at_design.kiev.ua>
Date: Thu, 28 Dec 2000 19:13:37 +0200 (EET)

On Thu, 28 Dec 2000, Uwe Zdun wrote:

> Hi,
>
> On Tue, 26 Dec 2000 seva_at_design.kiev.ua wrote:
> >
> > I split my application in several source files. Each of files
> > implements one of fsm's or helper functions, and when I need to change logic
> > of work, i simply source all files.
> >
> > There are several problems with this:
> > 1) when I execute command Class Some, previous instance of this
> > class deleted, and all objects move to ::Object class.
>
> this behavior is intended: from a "programming language point of view" you
> can not predict whether a destroyed class is going to be redefined or not.
> There could be another class with the same name, but with different
> semantics.

Ok, I agree with that point :)) (But does'nt like it too much :)) )

> In cases like your application, that require a class redefinition, there
> are several ways to tell the language to behave like this:
>
> - you can use the filter, as you have done to overload create.
> - you can use a subclass or a mixin to change create bahavior
> - or you use introspection to find out which instances are currently
> there and re-class these instances after sourcing to the new classes
> (same-named) classes
>
> Probably a combination would work here, like a instmixin on object that
> checks whether a class-to-be-created exists. If yes all instances are
> stored in a variable. After create, the instances are re-classed back
> to the old class.
>
> Or you build an instmixin tht simply does not execute the "create" on
> certain existing classes?

Yes, it is a solution which I use now. But probably I switch to
instmixin with create overloaded.

> It depends on your application case which solution is the best here ...
>
> > This problem I solve by using filter for create command on ::Object (idea
> > stolen from recoverypoint class :)) ). But with that second problem
> > arrives:
> > 2) when some instproc used as a filter, and redefined, it's filter become
> > inactive. (so first problem arrives again, when I source recover.tcl which
> > has recoverfilter definition)
> > after setting filter again, all works as expected
> >
>
> for the same reason as we have to re-class exisiting instances, we have to
> set the filters to an empty list, when the method is redefined (the same
> is done for mixins, when the class is redefined). E.g., we can
> not say that in any case with "Object instproc filter" the same method is
> defined. But again you can easily change this behavior for certain cases
> with a filter or instmixin or a subclass of Object, by redefining "mixin",
> "instmixin", "filter", etc. so that they check whether a certain filter,
> mixin, or instmixin is still there. A filter on Object is probably not the
> best solution here, because it performs the check on every call in the
> system. This is a heavy performance overhead. Presumably a mixin solution
> is more well-suited, because it only checks for certain methods and can be
> used object-specifically.
>
> In your example code a "mixin" on "Class", that just checks the
> Class->create method could be sufficient.

Ok, I tried another test case. Class A with two filters f1 and f2

   Class A

   A instproc f1 {args} {
        puts ">> filter f1"
        next
   }

   A instproc f2 {args} {
        puts ">> filter f2"
        next
   }

   A filter {f1 f2}

Instance of this class

   A a

anything works ok:
   a set b 1

>> filter f1
>> filter f2

redefine f2:

   A instproc f2 {args} {
        puts ">> new filter f2"
        next
   }

still 2 filters:
   A info filter
f1 f2

test:
   a set b 1

>> filter f1
interesting:
   A info filter
f1

seems like ok, but when I put it in file and execute it, I get:
a set b 1
>> filter f1
>> filter f2
A filters: f1 f2
a set b 1
>> filter f1
>> filter f2
redefine f2
a set b 1
>> filter f1

    while executing
"a set b 1"
    (file "./a.tcl" line 35)
>> filter f1

Contents of file:
===================================================
#!/usr/local/bin/tclsh8.2

package require XOTcl

Class A

A instproc f1 {args} {
        puts ">> filter f1"
        next
}

A instproc f2 {args} {
        puts ">> filter f2"
        next
}

A a
A filter {f1 f2}

puts "a set b 1"
a set b 1

puts "A filters: [A info filter]"

puts "a set b 1"
a set b 1
puts "redefine f2"

A instproc f2 {args} {
        puts ">> new filter f2"
        next
}

puts "a set b 1"
a set b 1
puts "A filters: [A info filter]"
puts "a set b 1"
a set b 1
puts "A filters: [A info filter]"

=============================================
seems that first execution of a filter after redefining leads to error

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 23 Dec 2002 01:18:08 +0100

 Dear XOTcl community,
 
 i am pleased to announce xotcl 1.0.1 shortly before christmas.
 The announcement is for now only on this mailing list, since
 we will deliver the windows binary version in a couple
 of days, when Uwe is back from vacation.

 have a nice christmas

-gustaf neumann

CHANGES relative to 1.0 are:

  - fixes:
 
     * fixed installation bug on windows (when installed on
       drives different to c:)

     * fixes for aolserver 3.5.*

     * fix for "object info default arg var" in connection
       with filters

     * Serializer handles filter guards now

  - new functionality and improvements:

     * improved recreate semantics, makes it easier to
       overload recreation logic.

     * new method "noinit" to create objects without
       calling the constructor

  - optimizations:

     * general speedup (10 to 15%) by using client data of
       namespace instead of Tcl_AssocData for interpreter state
      
     * faster and more flexible Serializer
     
For downloads see http://www.xotcl.org.

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 09 May 2006 11:54:49 +0200

Scott Gargash schrieb:
>
>
> I did a little more experimenting, and it's a little stronger than
> that. You also can't remove a mixin from anything invoked by the
> active mixin.
>
in the BEFORE part (this concerns everything that directly on indirectly).
>
> I.e., you can't forward the "mixin delete" to an object of another
> class. If the mixin to be deleted is present in the call stack, it
> appears that the mixin can't be deleted. Not that I expected it to
> work, but it seems worth noting.
>
if you have a case that goes beyond "do not remove actvive mixins from
the before part of active mixin classes"), please send an example.
>
>
> > It looks quite easy to give a reasonable error message, when the
> > currently active
> > mixin class is deleted, it will be more expensive to handle this
> problem in
> > a friendly way.
>
> Is the expense something that would be encountered on every method
> invocation, or would it only be paid when deleting a mixin?
>
a simple solution, not costing anything, would be to restart the mixin
chain when the active
mixin is removed. This would work with your example but might lead to
unexpeted cases in
other situations and is no big improvement to the current situation.

We have to deal with the following cases when we have e.g. a precedence
order M1 M2 M3 M4, and the following happens in the BEFORE part of M2:

a chain is set to: M1 M3 M4 (your case, you want to continue with M3)
b chain is set to: M1 M4 defensible M4
c chain is set to: M2 M1 M3 M4 under current semantics, continue
with M1
d chain is set to: M4 M2 M3 M1 continue with M3, M4 will never by
invoked

The general problem is pretty similar to the "immediate" and "logical"
update view
in logic languages, where the clause base is modified during the
execution of a goal.
The logical view says that modifications are ignored during execution
and only
apply to new invocations (similar to SQL), wheras the immediate view
tries to give
defensible semantics for the active invocations (what you are trying).
It has been
a while since i worked on this stuff, but it goes back to Lindholm and
Richard
O'Keefe (ROK) from 87, */Efficient implementation of a defensible semantics
for dynamic Prolog code/* (unfortunately, could not find this fine paper on
the net). In essence, this says that one can only get declarative
semantics
from the logical update view, which is not acceptible for programmers that
want to change the dynamic structure, preferring the immediate view,
which is more efficiently in terms of memory and computation. Therefore
most Prolog Systems implement the dynamic update view.

So, the underlying problem is well known and not a matter of a trivial
hack.
The situation with xotcl mixins/filters is in some respects more complicated
since we are not dealing with adding/removing clauses but we have to deal
with reordering, adding or removing items to instance specific precedence
chains; we have as well transitive mixin-chains.

Currently, we can even construct loops by reordering the mixins in the
BEFORE part, which i consider as a programmers bug.

The most promissing approach not mentioned yet is to develop a
c-level implementation of mixin/instmixin/filter/instfilter delete,
which simply flags the entry in the chain as deleted.....

cheers
-gustaf

From: <vitick_at_gmail.com>
Date: Thu, 14 Oct 2010 11:36:53 -0700 (PDT)

I have just installed the same 32bit ActiveState Windows version on Windows XP and TCL will also crash at [package req XOTcl]. So, this might be related to the specific build of ActiveState binary.

 
----- Original Message -----
From: "Gustaf Neumann" <neumann_at_wu-wien.ac.at>
To: xotcl_at_alice.wu-wien.ac.at
Sent: Thursday, October 14, 2010 12:29:00 AM GMT -08:00 US/Canada Pacific
Subject: Re: [Xotcl] troubleshooting

  Dear Victor,

many thanks for the short example! i have compiled xotcl
1.6.6 with
my three test releases, the script runs fine in every version,
also valgrind did not report unusual happenings, but i tried
so far only with mac os x with 64bit.

i am slightly confused about the activestate version number
TCL 8.6.0.0b4. There was never a version of Tcl 8.6 b4 released
(or tagged on sourceforge). As you wrote, the tcl_patchLevel
is 8.6b1.2, which is the current HEAD release (and therefore
a moving target). Apparently, activestate uses its own tags.
Have you seen somewhere on activestate a source-release?

-gustaf neumann

On 14.10.10 08:21, Victor Mayevski wrote:
> Thank you Gustaf,
> I am using the ActiveState binary and XOTcl is version 1.6.6, not NX. I don't know where to get the source code for TCL 8.6.0.0b4, it is not available anywhere yet.
>
> I think I have zeroed in where the crash happens. Here is the sample code that causes the crash for me:
>
> tcl_patchLevel 8.6b1.2
> tcl_platform(byteOrder) = littleEndian
> tcl_platform(machine) = x86_64
> tcl_platform(os) = Linux
> tcl_platform(osVersion) = 2.6.35-22-generic
> tcl_platform(pathSeparator) = :
> tcl_platform(platform) = unix
> tcl_platform(pointerSize) = 4
> tcl_platform(threaded) = 1
> tcl_platform(user) = root
> tcl_platform(wordSize) = 4
>
> ####################################
> Object o
> Object o::o
> [o::o info parent] info children
>
> Segmentation fault
> #####################################
>
> I have also installed the 32bit version of the same ActiveState binary (the latest one, 8.6.0.0b4, tcl_patchLevel 8.6b1.2) and it will crash right at [package req XOTcl]
>
> Hope that helps
>
>
>
>
> ----- Original Message -----
> From: "Gustaf Neumann"<neumann_at_wu-wien.ac.at>
> To: xotcl_at_alice.wu-wien.ac.at
> Sent: Wednesday, October 13, 2010 6:56:00 PM GMT -08:00 US/Canada Pacific
> Subject: Re: [Xotcl] troubleshooting
>
> Hi Victor,
>
> our typical test setup is to run the regression test with
> 8.5.9, tcl 8.6b1,
> and with 8.6head version (where i have applied the
> SANE-NRE-patch
> from Miguel). i just double-checked, for me all three test
> settings
> work fine.
>
> does the regression work on your installation with tcl 8.6b4
> (run: make test)?
> If they run fine, and you experience a crash with your
> application,
> the following works probably best:
>
> Strategy a: try to isolate and pinpoint the problem from the
> tcl layer
> by simplifying your script. if the problem can be
> reproduced with
> a few lines of code, send it to me.
>
> Strategy b: mostly for c-literate developers: use gdb.
>
> - compile tcl and nsf with -g enabled (e.g. add it to
> the compile flags in the Makefile and recompile with
> "make clean" and "make")
>
> - start the tcl shell under gdb, like e.g.
> gdb /usr/local/src/tcl8.5.9/unix/tclsh
>
> - start your application from gdb using
> run ..../yourapp.tcl
>
> - when it crashes, type in
> where
> an you will get the backtrace.
> maybe what you see makes sense to you.
> if not, send it to me, i'll try me best on it.
>
> all the best
> -gustaf
>
> On 14.10.10 00:33, Victor Mayevski wrote:
>> I have just tried my application on latest TCL 8.6b4 and it crashes (Segmentation fault). The same application works just fine in TCL 8.5.9. Any idea how I can troubleshoot it? Tools, techniques etc?
>>
>> Thank you
>> _______________________________________________
>> Xotcl mailing list
>> Xotcl_at_alice.wu-wien.ac.at
>> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

_______________________________________________
Xotcl mailing list
Xotcl_at_alice.wu-wien.ac.at
http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Victor Mayevski <vitick_at_gmail.com>
Date: Tue, 7 Dec 2010 20:40:32 -0800

It came to my attention that [namespace import -force nx::*] is a
requirement and not an option, otherwise things don't work right.
Example:

nx::Class create C
C method init args {puts [self]; next}
C create c
#error, commands "self" and "next" do not exist, but if I first do
[namespace import -force nx::*], everything works fine.

This is not how I thought the namespaced commands should work. Is this
a feature or a bug? If not a bug, then it needs to be clearly
documented.

From: Uwe Zdun <bm0005_at_sp2.power.uni-essen.de>
Date: Sat, 17 Feb 2001 09:10:02 +0100 (MEZ)

On Sat, 17 Feb 2001, Kristoffer Lawson wrote:

>
>
> Code:
>
> Class Foo
>
> Foo instproc init {} {
> puts [[self] info args myMethod]
> }
>
> Foo instproc myMethod {anArgument} {}
> Foo ob
> ==> expected a tcl method name but got myMethod
>
>
> This works as expected if I simply create an Object as follows:
>
> Object foo
> foo proc myMethod {anArgument} {}
> foo info args myMethod
> ==> anArgument
>
> Is this behaviour to be expected, and if so, why?
>

it is intented, because args only introspects the arguments for
procs. For instprocs there is a method "instargs" for the class
object. You will get the expected behavior with:

Foo instproc init {} {
  puts [[self class] info instargs myMethod]
}
Foo ob
--> anArgument

with "[self class] info args" you'll get the args of class-specific
procs

--Uwe

From: Martin Matuska <martin.matuska_at_wu-wien.ac.at>
Date: Thu, 16 Aug 2007 15:05:36 +0200

XOTcl ver. 1.5.4 is now available in:

a) FreeBSD ports tree (packages will be built in the next days)
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/xotcl/

b) WinTclTk distribution for Microsoft Windows, version 0.5.2
http://wintcltk.sourceforge.net

A single-file wrapped tkcon.exe that includes XOTcl 1.5.4 can be
downloaded from:
http://wintcltk.sourceforge.net/tkwrap.html

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 30 Apr 2008 10:44:59 +0200

The auxiliary methods of CLOS (:around, :before, :after) are rather
low-level primitives working on functions compared to XOTcl's
mixin classes and filters, operating on classes (method collections).
Can you give a convincing example, where CLOS style auxiliary
methods are an advantage?

-gustaf neumann

Ben Thomasson schrieb:
> Hi,
>
> I was wondering if you had considered implementing before, after, and
> around auxiliary methods similar to their implementation in CLOS? I
> understand that similar things can be done with mixins and filters,
> but there are a few things that are more easily done with auxiliary
> methods.
>
> Thanks,
>
> Ben
>
> Auxiliary methods:
> http://emacspeak.sourceforge.net/raman/publications/web-aster/root-thesisli13.html
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

From: Ben Thomasson <ben.thomasson_at_gmail.com>
Date: Wed, 7 Jan 2009 08:34:47 -0500

Hi XOTcl developers,

I have been using XOTcl for a while and I have discovered that the default
implementation of the Class unknown method is harmful to large scale
development. The default implementation calls create from the unknown
method. Here is an example that shows the problem:

Class A

A nstproc doX {} { puts done}

A intsproc doY {} { puts done }

The problem here is that misspellings of class methods will cause objects to
be created instead of methods to be defined on the class. Here we will have
an object named ::nstproc and one named ::intsproc which are both
misspellings of instproc.

There is a simple fix for this:

Class proc unknown { args } {

error "[ self ] Unknown command: \"$args\""

}

Class instproc unknown { args } {

error "[ self ] Unknown command: \"$args\""

}

This will require classes and objects to be created explicitly with the
create or new method. I find this preferable to having mistakes silently
ignored. I have seen this problem in the wild as well as in my code.
XOTclIDE had several misspellings that were ignored until I loaded with my
fix. Of course existing XOTcl projects will have to be modified to
insert create methods where needed.

Ben Thomasson