View · Search · Index
No registered users in community xowiki
in last 10 minutes

Weblog Page

Showing 21 - 30 of 1561 Postings (summary)

Re: [Xotcl] Asserts off/on

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 15 Jul 2006 17:02:38 +0200

Kristoffer Lawson schrieb:
>
>>
>> Object instmixin [Class new -instproc init args {my check all; next}]
>
> Yeah, giving that some thought, that should work too.
i would not write it, if i were not sure it works :)
>
> But would it be useful to have this kind of functionality in the core
> too?
>
well, as long we can do such kind of things with a few lines of code in
xotcl
i see not need for hacking this into C. xotcl is sometimes criticised
for having
already a too large set of predefined methods...

greetings
-gustaf

Re: [Xotcl] Re: serialize usage

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Ben Thomasson <ben.thomasson_at_gmail.com>
Date: Tue, 29 Mar 2005 08:35:45 -0500

Gustaf,

It is possible to handle autogenerated names, but maybe not in an
efficient way. The serializer can walk the object-graph of
associations and build a list of objects that exist in that graph.
With this list you can provide a mapping from one "reference-space" to
another. I have written a prototype serializer that handles
associations in this fashion. It uses an intermediate
reference-space. Ex.

original -> intermediate -> new reference-space
::xotcl::__#0 -> ::xoserialize::serial0 -> ::xotcl::__#5

However walking the object graph is somewhat inefficient as I am
looking through the
data for references to objects. It would be much faster if Object provided an
info associations, but I am not sure how this could be implemented.

Because Tcl lacks explicit pointers or references and instead uses
handles which are just strings, serializiation using associations will
be very inefficient. However can the included serializer which
supports composition handle an arbitrary object graph? Or am I
restricted to tree structures?

Thanks,

Ben


On Tue, 29 Mar 2005 11:36:24 +0200, Gustaf Neumann
<neumann_at_wu-wien.ac.at> wrote:
> Dear Aamer,
>
> the general problem is quite tricky, when one serializes and saves some
> objects
> (e.g. containing ::xotcl::__#0), ends and restarts xotcl, creates again
> global
> objects with 'new' and restores the saved state containing the object
> mentioned
> above. 'Serialize all' does not save objects from the ::xotcl namespace,
> but certainly
> people can use -childof...
>
> The most simple solution is to remember the highest allocated id with the
> saved state in serialize all, to provide a function to reset it and
> leave the problem
> to the programmer. But still, this is no good solution, if multiple save
> states are
> used and loaded in arbitary order.
>
> A better solution is to
> a) check in 'new', whether an object with the generated autoname
> exists already, and
> b) provide a wrapper for loading the serialized code that extracts all
> patterns
> of autonames, and remaps some or all symbols if necessary (for
> handling preexisting
> objects with autonames). This could be done by searching for
> autoname patterns
> during serialization and using similar to the -map option of the
> Serializer....;
> but still, this only works, when the autonamed objects are
> serialzed; for references
> in variables we would need a global map table, which is still
> depending on the
> restore order of the serialized code if multiple pieces are saved.....
>
> What are you trying? would (a) be sufficient for you? It is slightly
> slower than the
> current version, but i don't think it is worth adding another option to
> new for checking
> on demand...
>
> best regards
> -gustaf neumann
> Aamer Akhter schrieb:
>
> >I just tried this with 1.3.6 and it appears to be working. Sort of
> >related question, how do people handle the swizzling/unswizzling of
> >autogenerated object names (eg ::xotcl__#0) when restoring an object?
> >
> >
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

Re: [Xotcl] Problem with automatic variable unsetting upon return from an instproc?

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Wed, 19 Nov 2003 14:56:59 +0100

Jim,

at first glance, the behavior seems ok to me. You're setting 2 traces to the
local scope variable "f" which get unset in reverse order -> so
the two "f" outputs should be ok.

The rhs traces "2" and "3" are for the two inner invocations. For the outer
invocations, the callframe is deleted before the Trace is executed. The
problem here is that Tcl does not print the error that occurs.

Consider the following plain Tcl example:

proc tracecb { name1 name2 op } {
   if {[catch {
     upvar $name1 var
     puts "tracecb \"$name1\" \"$name2\" \"$op\" \"$var\""
   } err]} {
     puts $err
   }
}
proc x {a} {
  ::trace add variable a [list unset] ::tracecb
  if {$a == 0} {return}
  incr a -1
  x $a
}

x 4

This prints:
tracecb "a" "" "unset" "0"
tracecb "a" "" "unset" "1"
tracecb "a" "" "unset" "2"
tracecb "a" "" "unset" "3"
can't read "var": no such variable

so you cannot rely on the "upvar" in the trace to a local scope variable.

You can try to refer to an XOTcl variable (an instance variable)
with "[self] trace ..." instead.

Uwe


On Tuesday 18 November 2003 22:39, Jim Russell wrote:
> I've compiled XOTcl 1.0.2 with Tcl 8.4.4 to create a xotclsh. When I
> execute the script below, the traced variables are unset once too few
> times. Also, the order of the unsetting seems odd. Am I just confused,
> or I have discovered a problem?
>
> Here's the sample output:
>
> russell> xotclsh factorial.xotcl
> rhs = 3
> rhs = 2
> rhs = 1
> tracecb "rhs" "" "unset" "2"
> tracecb "rhs" "" "unset" "3"
> tracecb "f" "" "unset" "::factorial-1"
> tracecb "f" "" "unset" "::factorial-0"
> 3! = 6
>
> >>>> File factorial.xotcl <<<<
>
> proc tracecb { name1 name2 op } {
> upvar $name1 var
> puts "tracecb \"$name1\" \"$name2\" \"$op\" \"$var\""
> }
>
> xotcl::Class factorial;
> factorial proc new { args } {
> eval my [ my autoname factorial- ] $args
> }
>
> factorial instproc compute { rhs } {
> puts "rhs = $rhs"
> if { $rhs > 1 } {
> set f [ factorial new ]
>
> ::trace add variable f [list unset] tracecb
>
> set lhs [ $f compute [ expr $rhs - 1 ] ]
> } else {
> set lhs 1
> }
> set product [ expr $lhs * $rhs ]
>
> ::trace add variable rhs [ list unset ] tracecb
>
> return $product
> }
>
> proc main { value } {
> set f [ factorial new ]
> puts "${value}! = [ $f compute $value ]"
> }
>
> main [expr [ llength $argv ] ? [ lindex $argv 0 ] + 0 : 3 ]
>
> _______________________________________________
> 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_{xotcl,computer,acm}.org, uwe.zdun_at_wu-wien.ac.at

[Xotcl] Abstract method f args called

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Thu, 08 Feb 2001 15:13:44 +0100

Hi,

Say I have the following class hierarchy:

Class C0
C0 instproc f args {
    puts "(C0) I am [self] class [[self] info class] in method [self proc]"
}

Class C1 -superclass C0
C1 abstract instproc f args

Class C2 -superclass C1
C2 instproc f args {
    puts "(C1) I am [self] class [[self] info class] in method [self proc]"
    next
}

So, the method f is:
 - defined at the top of the hierarchy
 - abstract in the middle of the hierarchy.
 - redefined at the bottom

When I run:
C2 c2
c2 f

I get:
(C1) I am ::c2 class ::C2 in method f
Abstract method f args called

and I cannot reach the top method?

Is this on purpose?

-- 
Catherine Letondal -- Pasteur Institute Computing Center

Re: [Xotcl] "tie" command

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Fri, 24 Jan 2003 10:32:47 +0100

nice idea, I've played a bit with var traces to make some tie functionality
work; is this what you were thinking of?

--Uwe


####################################################### TIE code

Object instproc tie {varname objname} {
    my set $varname $objname
    my trace variable $varname wu "Object tie_cb $objname [self]"
}
Object proc tie_cb {tieobj obj n1 n2 mode} {
    ## delete the tieobj
    if {[my isobject $tieobj]} {
        $tieobj destroy
    }
    ## delete the trace for this tieobj
    if {$mode == "w" && [my isobject $obj]} {
        foreach t [$obj trace vinfo $n1] {
            set mode [lindex $t 0]
            set cmd [lindex $t 1]
            if {[string equal $cmd "Object tie_cb $tieobj $obj"]} {
                $obj trace vdelete $n1 $mode $cmd
            }
        }
    }
}

####################################################### Test

Object x
x proc test {} {
    set n 0
    while {$n < 10} {
        my tie myVar [Object new]
        incr n
    }
}
x test

### test unset
#x unset myVar
#x set myVar abc

### only one should have survived
puts [Object info instances]

### it gets killed when the obj gets killed
x destroy
puts [Object info instances]

###############################################################



On Friday 24 January 2003 04:32, Kristoffer Lawson wrote:
> Been thinking if this would make sense:
>
> while {$stuff} {
> tie myVar [MyClass new]
> ...
> }
>
> And the instance created from MyClass would be automagically collected on
> each iteration. Ie. [tie] would tie an object to a variable: when the
> variable's value is changed, or when the variable is destroyed, the object
> is too -- or at least the refcount decreased. I often have Message objects
> which are used once (after some data is read from somewhere) and then
> destroyed. Quite often I forget the latter part ;-)
>
> / 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_{xotcl,computer,acm}.org, uwe.zdun_at_wu-wien.ac.at

[Xotcl] results of the poll

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 4 Mar 2002 14:08:36 +0100

 Dear XOTcl community,

 the results of the poll can be summarized as follows:
   - most people favored "names" instead of "symbols"
     for "selfDispatch"
   - the hottest favorite is "my". One can write now

        ...
        my instvar a b c
        my log
        ...

      instead of
        ...
        [self] instvar a b c
        [self] log
        ...

      the variant with [self] will continue to work
      forever..
      If someone is not happy with "my", please react
      soon.

 From the "volatile" front: we have now more-or-less Zoran
 suggestion implemented in C. Actually there is no need
 in general for using tcl-variables to implement volatile
 objects (we could handle this on a pop of stack frames),
 but at least for pure tcl-procs, var traces are the simplest
 implementation. The current implementation (purely in C)
 works as part of the "new" method:
 
    a) Object new ...
    b) Object new -childof ...
    c) Object new -volatile ...
    d) Object new -volatile -childof ...

 (a) creates "global" objects, not in the global
 namespace anymore, but in xotcl. (b) can be used
 to create objects as child of other objects (e.g. [self],
 the objects are deleted, when the specified object is deleted),
 (c) are "global" objects as in (a), but they are deleted,
 when the current tcl-proc/object-proc/instproc is left,
 and (d) is a combination of b and c.

 Needless to say, a-d works for classes as well as e.g.

   Class new -volatile

 in order to create "anonymoes" classes. The implementation
 of new is slightly faster than before, since i changed the
 nameing schema to be the same for all kind new ("__#122", ...),
 such that e.g.
   [Class new -volatile] new -volatile
 works as well. the disadvantage is that the neat
 classname derived names as in earlier versions have
 to be done by hand now...

 that was it for now

 best regrads
-gustaf

Re: [Xotcl] info method behaviour

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 13 Aug 2001 19:46:28 +0200

On Monday 13 August 2001 18:15, Kristoffer Lawson wrote:
> On Mon, 13 Aug 2001, Gustaf Neumann wrote:
> > what is it, that would fit your needs best? what are you doing exactly?
>
> Well for me even more important are the "info args" and "info body" parts.
> As mentioned, I'm doing some meta-programming at the moment.

 meta-programming is a wonderful thing. actually, several years ago, i wrote
 a book about it (in the context of Prolog, see my homepage) covering
 meta-interpreters and partial evaluation in particular....

> I have a method which generates more methods based on a template method (an
> example of this can be found
> at: http://mini.net/cgi-bin/wikit/401.html). Right now
> the method-generators assumes that the template is inherited from a class
> (so checks "args" and "body" from there), but really it should not care
> whether a method is inherited or not. It should just be given the name of
> the method, and it can ask the information regardless of inheritance.
 
 hmm. you mentioned here twice "args" and "body"; you should not use
 these for inherited methods, use instead "instargs" and "instbody".

 i am still confused. Are you trying to use the instprocs as templates
 for procs? if i paraphrase the example from the wiki, this would be

   Class C
   C instproc fooTemplate <argument> <body>

   C c1
   useTemplate c1 fooTemplate foo -msg1 Hi -msg2 bye

 where the object c1 has afterwards a proc foo, and fooTemplate could
 be a proc or an instproc.

 i do not think, that this is a good solution, but this is an example
 where i would like to ignore the differences between procs and instprocs.
 is this similar to what you are working on?

-gustaf
 

[Xotcl] old bug

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sat, 20 Jan 2001 05:39:17 +0200 (EET)

Apparently a bug I think was fixed at one point has managed to creep in:

[~] Class Foo
Foo
[~] Foo instproc init {foo} {
> [self] instvar {foo fooAlias}
> puts "yeah"
>}
[~] Foo ob bar
variable "foo" already exists
while evaluating {Foo ob bar}

Ie. although an alias is created, the foo variable conflicts.

         - ---------- = = ---------//--+
         | / Kristoffer Lawson | www.fishpool.fi|.com
         +-> | setok_at_fishpool.com | - - --+------
             |-- Fishpool Creations Ltd - / |
             +-------- = - - - = --------- /~setok/

Re: [Xotcl] how to track a segmentation fault problem in Xotcl?

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Mon, 1 Sep 2003 13:21:58 +0200

On Monday 01 September 2003 11:56, Catherine Letondal wrote:
>
> > You should compile wish with symbols (./configure --enable-symbols).
> > The same appiles for xotcl as well.
>
> When I compile xotcl after a ./configure --enable-symbols the compilation
> just fails to compile because it looks for a libtcl8.3g.so file (or maybe I
> should have built the tcl library before?):

Of course, you need to compile Tcl with --enable-symbols.
This will produce the libtcl8.3g.so library.

> I don't remember how it is I still have a libxotcl1.o.so built!!
>
> No wonder there is a segmentation fault.
>
> Thanks a lot for any help,

No problem. Just get a clean compilation of xotcl first.
If the problems persist, then recompile all with --enable-symbols
and give it another try.

Cheers,
Zoran

[Xotcl] potential problem in makefile for solaris fixed

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 16 Sep 2006 11:14:16 +0200

Hi everybody,

Andreas Kupries found a small problem with the makefile on solaris.

> The Makefile target "install-shells" (around line 421)
> uses
> 'test -e'

> The '-e' option is not understood by the 'test' command of Solaris.
> I have to use 'test -f', or the installation of xotcl fails.

This is the same code as in prior versions, so it won't effect many
people. I have fixed the tar file on www.xotcl.org without upgrading
the version number.

best regards
-gustaf

Next Page