Weblog Page

From: Adrian Wallaschek <adrian_wallaschek_at_be.ibm.com>
Date: Wed, 8 Jan 2003 16:37:47 +0100

Hi there!

I do like version numbers, but there is a "too much" in everything.

What is the deeper benefit of having the version number for xotcl
recursively even inside the source-tree?

What actually happens for me is that now I seem to have problems building
the code because in 1.0.1
When running xotcl-1.0.1/xotclsh I do find ..../xotcl-1.0 in the auto_path
instead of the required/expected .../xotcl-1.0.1.

I haven't yet found out where it goes wrong but it looks like the $VERSION
doesn't use the revision counter in some Makefile.

The question is: why all this fuzz?

Didn't anybody else see this occurring, did I mess up anything?


Regards,
         Adrian Wallaschek

"Just when you think, life can't possible get worse,
it suddenly does!"
The Hitchhiker's guide to the galaxy - Douglas Adams

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Wed, 7 Feb 2001 17:25:03 +0100

Dear XOTcl Community,

Annoucing new init+destroy scheme: Due to constant questions and problems
regarding object destroy + creation + recreate, we have decided to provide
a new destroy scheme in XOTcl 0.84. It will have only slight observable
differences to the current destroy scheme, but is more flexible and
allows for recreation.

I'll explain how it is currently implemented:

"create" and "alloc" are both now Class instprocs handling creation for their
instances. I.e.
  [self] alloc
is wrong ... correct is now:
  <className> alloc [self]

There is a new method "instdestroy" on Class that handles physical destruction
of an object. The method "destroy" on Object has now the behavior:

  Object instproc destroy args {
    [[self] info class] instdestroy [self]
  }

Everything is written in C ... I'll use XOTcl code just for explanation...

"create" now distinguishes between:

1) creating a new object:
  calls alloc + <doInitializations>
   
2) recreating an existing object
  calls:
    [self] class <givenClass>
    [self] cleanup ;# resets <self> into a state
                                 as after original <init>
    <givenClass> recreate [self]


"recreate" is a new method that can be customized. Its default behaviour
is:
    <doInitializations>

<doInitializations> is called in C and is the same for recreate and (1):
  - search for parameter default values
  - call "-" initialization methods
  - call "init"

each of those will have a method call that can be changed, intercepted, etc.
Of course, you can also overload or intercept cleanup, recreate, instdestroy,
etc.
  
Comments?

Greetings, Uwe

-- 
Uwe Zdun
Specification of Software Systems, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_xotcl.org, uwe.zdun_at_uni-essen.de

From: Kristoffer Lawson <setok_at_scred.com>
Date: Wed, 4 Aug 2010 15:14:08 +0300

On 4 Aug 2010, at 12:37, Gustaf Neumann wrote:

> without knowing the length of the argument list (which is in the general
> case not possible in Tcl due to args). For me it is sometimes surprising,
> how well it works even for large projects, with several thousand lines
> of code and many developers involved. The XOTcl serializer
> uses the dash notation as well, but analyses the arguments and adds the
> lists
> as needed.

Yes, this is the first time I came across this, and it took a while to debug :-) However I'm almost certain a lot of code I have stored around is susceptible to the same thing. That's the danger with this: it's very easy to get by by just passing in arguments in the normal way, and then end up with a severe security hole. It's very easy to miss, as it's quite natural for a coder to pass in arguments directly to constructors.

> Anyhow, the next incarnation of XOTcl, on which we are hard working
> right now, has this feature dropped, and provides a much more orthogonal
> parameterization for objects and methods. As the new framework
> supports multiple object systems in one interpreter, one can use classical
> XOTcl and the new object system in parallel.

I think dropping it is a good decision. It'll be interesting to see what the next XOTcl is like.

How much complexity will the new version be adding? The beauty with XOTcl, especially the earlier versions, was that despite the power of it, it was quite simple (unlike C++). Much like Tcl itself: power, but simplicity. I would be concerned if that gets lost along the way.

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

From: jim <j_marvin_at_localnet.com>
Date: Wed, 10 Dec 2003 13:22:41 -0500

hi-

in my script at the beginning i added a line like this

global widget
lappend auto_path /Program Files/Tcl/lib/xotcl1.1/xotcl/ ;
package require XOTcl;
    namespace import -force xotcl::*

etc. etc. etc. <rest of script(s)>

i thought this was the way to do it but i guess not.
is putting lappend auto_path ... going to fill up the auto_path
contents with a redundant path values making it huge?
the widgets in visualTcl i use i believe are in libraries. how come
they are wrapped in the binary exe file and xotcl is not?

if it is required that i have xotcl installed on the computer i am
distributing to i guess that is ok.
is there a way to make it so with the programs i mentioned all i have to
do is distribute the exe file?

i finished my program i was working on that simulates a fake elevator.
i used some xotcl code the mailing list helped me
with and integrated it into a visualTcl GUI program with events. I
wanted to put a download link on my website to show
people.
I was hoping they could just download the exe from the link but if not
it is not that important.
thanks,
marvin

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Tue, 20 Jan 2015 10:11:35 +0100

A more complete solution (preserving any pre-existing superclass lists)
is as follows:

package req nx

namespace eval ::vitick {

   Class create Object -superclasses nx::Object

   Class create Class -superclasses nx::Class {
     :method init {} {
       ##
       ## Rewire the default superclass
       ##
       if {[:info superclasses] eq "::nx::Object"} {
        :configure -superclasses [namespace current]::Object
       }

     }
   }

   namespace export Object Class
}

namespace import -force ::vitick::*

puts [[Class create MyClass] info superclasses]; # default is:
::vitick::Object
puts [[Class create AnotherClass -superclasses MyClass] info
superclasses]; # ::MyClass
puts [[Class create AnotherClass -superclasses MyClass] info
superclasses -closure]; # ::MyClass ::vitick::Object ::nx::Object

//stefan

> Hi Victor,
>
> > Any suggestions?
>
> As always, there are several options. One way of nursing our custom
> Object/Class is to use proper specializations of nx::Object/nx::Class:
>
> package req nx
>
> namespace eval ::vitick {
>
> Class create Object -superclass nx::Object
>
> Class create Class -superclass nx::Class {
> :method init {} {
> :configure -superclasses [namespace current]::Object
> }
> }
>
> namespace export Object Class
> }
>
> namespace import -force ::vitick::*
>
> This is less invasive and you have the benefit of monitoring any
> changes/additions to nx::Object/nx::Class for free.
>
> Cheers,
> Stefan
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Institute for Information Systems and New Media
Vienna University of Economics and Business
Welthandelsplatz 1, Building D2, A-1020 Vienna
Austria
http://nm.wu.ac.at/en/sobernig
stefan.sobernig_at_wu.ac.at
ss_at_thinkersfoot.net
t. +43-1-31336-4878
f. +43-1-31336-746

From: Vasiljevic Zoran <zv_at_archiware.com>
Date: Thu, 8 May 2008 18:14:10 +0200

On 08.05.2008, at 18:02, Matthew Smith wrote:

> set s1 [Stack new]
>
> s1 push a
> s1 push b
>
> set x [s1 pop]
> puts "The popped value is $x"

Try this:

Stack s1

s1 push a
s1 push b

set x [s1 pop]
puts "The popped value is $x"

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 08 Apr 2010 12:05:52 +0200

Announcing XOTcl 1.6.6
*************************

Dear XOTcl Community,

We are pleased to announce the availability of XOTcl 1.6.6

Major changes relative to 1.6.5 are:

     * improved 64-bit compatibility (expat)
     * fixed minor memory leaks (info methods, forward error case)
     * fixed potential cyclic dependencies via namespace imports
       during cleanup
     * fixed potential crash with var-traces being fired twice
     * compatibility with Tcl 8.6b1
     * fix for debian packaging

  For more details about the changes, please consult the ChangeLog and
  documentation. The planned next release will be 2.0.0

MORE INFORMATION
  General and more detailed information about XOTcl and its
  components can be found at http://www.xotcl.org

best regards
-gustaf neumann

From: <MichaelL_at_frogware.com>
Date: Mon, 15 Nov 2004 12:51:32 -0500

Ok, I've found a temporary workaround using

        TestB create ::b -x 5

rather than

        TestB ::b -x 5

Still, why doesn't the second approach work?

xotcl-bounces_at_alice.wu-wien.ac.at wrote on 11/15/2004 12:41:25 PM:

> I'm using XOTcl 1.3.1. (I haven't upgraded to the 1.3.3 beta yet.)
>
> I have a filter that does work before and after calls to "next". I'd
like
> to make sure that the "after" code always gets called, so I'm using
> "catch" around my call to "next," a bit like this:
>
> # do something before
>
> set err [catch {next} result]
>
> # do something after
>
> The problem is that in specific circumstances (when objects are
> constructed) the fact that "next" is called within "catch" is screwing
> things up. (The error I'm getting is "5", which is defined in XOTcl as
> "XOTCL_UNKNOWN".)
>
> I can see why "catch" would get in the way, but so far I haven't found a

> way around the problem. Does anyone have any ideas?

<snip>

From: Jim Russell <Jim.Russell_at_dynetics.com>
Date: Tue, 18 Nov 2003 15:39:58 -0600

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 ]

From: Stefan Sobernig <stefan.sobernig_at_wu-wien.ac.at>
Date: Mon, 23 Jul 2007 18:23:51 +0200

I attached two scripts, each reproducing bugs
I found with most recent versions of XOTcl
(1.5.2/1.5.3).

Bug -1-: Argument declarations to proc/instproc
containing a single empty tcl string yield a segfault/bus error.

Bug -2-: Nesting objects through per-object evals (evals
in the object scope) yields segfaults/bus errors under
certain conditions.

all the best,

//stefan

-- 
Stefan Sobernig
Institute of Information Systems and New Media
Vienna University of Economics	
Augasse 2-6
A - 1090 Vienna
`- +43 - 1 - 31336 - 4878 [phone]
`- +43 - 1 - 31336 - 746 [fax]
`- stefan.sobernig_at_wu-wien.ac.at <mailto:stefan.sobernig_at_wu-wien.ac.at>
`- ss_at_thinkersfoot.net <mailto:ss_at_thinkersfoot.net>

package req XOTcl
# / / / / / / / / / / / / / / / / / / / / /
# Bug trace -1-
# empty tcl string as argument declaration
# - - -
# stefan.sobernig_at_wu-wien.ac.at
# reproducable/observed for 1.5.2/1.5.3
::xotcl::Object o
o proc m1 {{}} {;}






# / / / / / / / / / / / / / / / / / / / / /
# Bug trace -2-
# Nesting through "objscoped" evals
# - - - - - - - - - - - - - - - - - - - - -
# stefan.sobernig_at_wu-wien.ac.at
# reproduceable/observe for 1.5.2/1.5.3

package req XOTcl
namespace import ::xotcl::*

Object o
o eval {set x [::xotcl::self]}
o set x
o eval {set x [::xotcl::self]::nested}
o set x
set cmd {::xotcl::Object [::xotcl::self]::nested}
o eval $cmd

# yields bus error
# - - -
# However, strange enough, when uncommenting lines 12-14
# the nested object is created without any
# fatal error?!

Object o
# o eval {set x [::xotcl::self]}
# o set x
# o eval {set x [::xotcl::self]::nested}
# o set x
set cmd {::xotcl::Object [::xotcl::self]::nested}
o eval $cmd

# works as expected
# - - -
# Injecting a requireNamespace makes
# the issue vanish, even with the
# pre-nesting operations being
# evaluated

Object o
o eval {set x [::xotcl::self]}
o set x
o eval {set x [::xotcl::self]::nested}
o set x
o requireNamespace
set cmd {::xotcl::Object [::xotcl::self]::nested}
o eval $cmd

# works as expected
# - - -