Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 07 Sep 2006 18:24:35 +0200

Scott Gargash schrieb:
> Thanks, but in my particular case I don't have knowledge of Derived,
> only Base. By that, I mean I'm actually adding BaseMixin (the HW
> simulator) to Base (the HW) before Derived has even been created. I'd
> like for Derived to remain ignorant of BaseMixin because BaseMixin
> only exists for testing purposes. I prefer to avoid having code paths
> that exist only for testing purposes. (Which mixins are particualrly
> well-suited for).
well, that are your requirements, but for others it might be different.
Another question is, whether one would like to have the mixin added in
for a certain class tree, or for each class tree. Using the multiple
superclass approach
allows/forces one to be specific (first case). it is however possible,
to add
on the xotcl level the superclass to the precedence order of all
subclasses of the Base.
Isn't this an option for you?
>
> My current solution is to make Derived a mixin as well. This then
> forces it to the head of the precedence order regardless of the
> existence of BaseMixin so I don't have different code paths for
> BaseMixin vs. Base. It works, but it's not really correct from a
> design standpoint. Derived should be a derived class (it's a unique
> type), not a mixin.
as you said, if you want finer control, move more behavior into
[inst]mixins.
everything done with superclasses can be done with mixins alone as well,
since
the class structure is linearized anyhow. However, this leads to a unusual
programming style.
>
> This is what I meant about the current precedence order breaking
> encapsulation. I wish to modify a single class, but the precedence
> order makes it be global. In order to get things to work, I have to
> distribute knowledge of BaseMixin to places in the hierarchy that (I
> believe) shouldn't have to know or care.
>
> What's the scenario where it's desireable for BaseMixin to be ahead of
> Derived?
One can argue in different directions. If one says, the class tree is
the behavior,
you do not want to know, in which class(es) exactly the methods are defined,
but you want to decorate the behavior, the current mixin approach is
appropriate.

Do you have a technical reason, why you want the instmixin BaseMixin in the
precedence order between Base and Derived? I have developed many
applications with mixins/instmixin, and i never had this need.

-gustaf

From: Kristoffer Lawson <setok_at_scred.com>
Date: Wed, 7 Jan 2009 17:20:05 +0200

On 7 Jan 2009, at 15:45, Gustaf Neumann wrote:

> i do agree with you, that the default unknown handler for
> classes/metaclasses is harmful. i prefer as well the explicit
> create/new statement for various reasons.
>
> The handler is a heritage from OTcl, and the reason XOTcl
> keeps the heritiage is backward compatibility. Many programs
> simply use unknown....
>
> However, maybe we should mark its usage as deprecated and
> remove it in future versions, such as XOTcl 2.0....

As someone who has stumbled across this as well, I would vote for
deprecation. I always use 'new' anyway.

            / http://www.scred.com/
            / http://www.fishpool.com/~setok/

From: Jeff Hobbs <jeffh_at_activestate.com>
Date: Tue, 14 Aug 2007 11:38:22 -0700

Gustaf Neumann wrote:
> Jeff Hobbs schrieb:
>>> + provided compatibility with Tcl 8.5
>>> (currently, this requires the verison of Tcl 8.5
>>> from CVS head, including the changes for VarReform
        ...
>> I know that some extensions poke deeper (especially OO ones), but we
>> were able to maintain binary compat with itcl.
> the stubs of tcl 8.5 are not the same as tcl 8.4. What i have seen, itcl
> requires the same new interfaces that xotcl uses. do you expect that tcl
> 8.5 extensions work for tcl 8.4 and vice versa?

What I expect is that 8.4-compiled extensions work with 8.5. More
importantly, it is not just my expectation, but the expectation of most
Tcl users.

For example, let's say Apple gets the latest xotcl and itcl into the
latest 8.4-based release for Leopard (although in all likelihood, it is
too late to update now). When a user installs 8.5 to test, itcl as
shipped on the machine would work whereas xotcl will not. Not the best
user experience.

While xotcl may rely on whatever stubs officially exports, there are
many tricks around this, both compile-time and runtime tricks to get
what you need. itcl uses these, and I would recommend xotcl doing the
same in order to improve the user experience.

Jeff

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Sun, 19 Mar 2006 05:49:20 -0700

xotcl-bounces_at_alice.wu-wien.ac.at wrote on 03/19/2006 05:32:31 AM:

>
> On 19 Mar 2006, at 14:09, Scott Gargash wrote:
>
> > xotcl-bounces_at_alice.wu-wien.ac.at wrote on 03/19/2006 04:08:40 AM:
> >
> > >
> > > On 19 Mar 2006, at 00:12, Scott Gargash wrote:
> > > >
> > > > When would you need the namespace of the object?
> > > I have only ever needed the namespace of an object which attaching
> > > traces to variables (f.ex. with Tk), but for that it is,
> > > unfortunately quite necessary.
> >
> > I haven't used it yet, but doesn't the "trace" method handle this?
>
> No. Some tk widgets map their values to Tcl variables. Other similar
> interfaces exist. It is handy to map them to an instance variable but
> for that it is necessary to have the namespaced version available.

Snit has a "myvar" method that returns the fully qualified name of a snit member variable. Perhaps
something similiar (a method that returned a "reference" to an instance variable) would be useful in
XOTcl?

      Scott

From: Artur Trzewik <mail_at_xdobry.de>
Date: Sat, 23 Oct 2004 16:02:23 +0200

Hi

There is new version 0.70 of XOTclIDE ready on:
http://www.xdobry.de/xotclIDE

Main changes:
- adapted for XOTcl 1.3.2
- support for non postional arguments (new in XOTcl 1.3.2)
- user preferences setting (for editor and list fonts and background colors)
- many fixes and improvements of user usability (Michael Heca)
- improved class browser (MH)
- all browser supports paned windows (MH and AT)
- bugfixes by syntax parser

XOTclIDE 0.70 was developed and tested with not official version of
XOTcl 1.3.2 but is still backwarts compatible with XOTcl 1.2

Many thanks to Michael Heca for many (more than 30) bug fixes,
improvements of usability and suggestions

starkits for XOTclIDE 0.70 are comming soon.

Artur Trzewik

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Tue, 14 Oct 2014 21:32:39 +0200

Dear Yusuke,

building XOTcl binaries with Tcl 8.5, that work with Tcl 8.6 is actually
not quite simple,
since when XOTcl is compiled under Tcl 8.5 uses the Tcl function
TclObjInterpProcCore(),
which was unfortunately removed from Tcl in 8.6. The commit entry, which
deleted the
stub entry in Tcl 8.6 says:

     "Used to be needed for TclOO-extension; unneeded now that TclOO is
in the core
     and NRE-enabled"

Therefore, when one loads the binary from Tcl 8.5 into Tcl 8.6, this
symbol cannot be
resolved. See as well the discussion in [1].

However, to address this problem, i've added a new configure
option "--enable-forward-compat86", which allows to build binaries of XOTcl
with 8.5, that do not use TclObjInterpProcCore(), and can therefore be
loaded into Tcl 8.6 as well. You can get this version currently just
from git

git clone git://alice.wu.ac.at/nsf
   cd nsf
git branch xotcl1 origin/xotcl1
   git checkout xotcl1

Use "--enable-forward-compat86" only in cases, where you need the forward
compatibility. One will get better performance under Tcl 8.5 or Tcl 8.6
by compiling
exclusively for these versions.

best regards
-gustaf neumann

[1] https://next-scripting.org/list/1207.html



Am 14.10.14 07:05, schrieb Yusuke Yamasaki:
> Hello,
>
> Because the teapot repository has up to XOTcl 1.6.7 for Windows,
> I tried to build 1.6.8 for myself. The easiest way was to use Msys/MinGW.
>
> ./configure --enable-threads --prefix=/c/bin/tcl8.5.16 \
> --with-tcl=/c/src/tcl8.5.16/win --with-tk=/c/src/tk8.5.16/win \
> --with-actiweb=no --with-xotclsh=no --with-xowish=no \
> --without-expat --without-gdbm \
> --with-tclinclude=/c/bin/tcl8.5.16/include \
> --with-tkinclude=/c/bin/tcl8.5.16/include
> make
> make install
>
> However it only works with either 8.5 or 8.6 depending on the version
> which I specified by --with-tcl option. Though I don't have deep
> understanding of the stub mechanism, I know it is a key to make a
> generic version of a C extension. I think XOTcl has -DUSE_TCL_STUBS=1
> by default configuration according to config.log.
>
> Is there anything wrong with my build procedure?
>
> Windows 7 Professional SP1 64bit
> Tcl/Tk 8.5.16
> ---
> Yusuke Yamasaki <tm9233yy_at_gmail.com>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Univ.Prof. Dr. Gustaf Neumann
WU Vienna
Institute of Information Systems and New Media
Welthandelsplatz 1, A-1020 Vienna, Austria

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Wed, 22 Nov 2006 16:48:54 +0200 (EET)

On Wed, 22 Nov 2006, V.K.Vallinayagam wrote:

> Here is a sample code.
>
> Object a
> Object a proc name {} {
> return "I am valli"
> }
> a name # returns "I am valli"
> Object a::name # Child object with same name as the proc
> a name # returns ::a::name and not the previous message
>
> Is this the desired behaviour. Is there any workaround.

It's probably not desirable but if you think about it, you can see why
that is happening. Objects are basically implemented as namespaces (well,
at least they were at some point). A method is a proc inside a namespace.
Thus a::name is the proc for that method. Now, objects are also commands.
Placing it inside the namespace will create, well, the command a::name,
thus overriding the method.

I do agree that this is not perhaps the best of behaviours and not
expected. I'm not sure if child objects could be placed inside their own
'children' namespace. Uwe or Gustaf can probably comment on that.

One workaround is to create a 'children' child object yourself inside a.
Then place all the objects as children of it. The downside is that the
parent of those objects will now be an object called 'children'. The
parent of it will be 'a'.

                               / http://www.fishpool.com/~setok/

From: Nico L'INSALATA (UniPI) <"Nico>
Date: Mon, 23 Jul 2007 19:45:07 +0200

Hi there!
I don't know if the following information will help or will create more
confusion.

I'm using XOTcl 1.5.3 compiled from scratch against Tcl 8.4.5.
I've been able to reproduce the bug using the tcl shell installed on my
system (info patchlevel ==>8.4.9).

Surprisingly, everything works fine if I source your scripts in the Tcl
shell embedded in the commercial software I'm working with (info
patchlevel ==> 8.4.5.1).

> 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
RETURNS /> ::o::nested


II'm at your disposal for providing you any additional info you might
find interesting if you believe this could give hints for debugging,

Regards,
Nico


Stefan Sobernig wrote:
> 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
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
-------------------------------------------
Nicola E. L'Insalata
Ph.D. Candidate
VLSI Systems Research Group
Dept. of Information Engineering
University of Pisa
Via G. Caruso,
I-56122 Pisa, Italy
Tel: +39 050 2217 625
Fax: +39 050 2217 522
E-mail: nicola.linsalata_at_iet.unipi.it
------------------------------------------- 

From: Attilio Dona` <attilio.dona_at_telecomitalia.it>
Date: Fri, 30 Apr 2004 15:05:20 +0200

Hy,

In 1 I report an introspection bug, in 2 an ahestetic bug and in 3 a
personal consideration about a possible XOTcl improvement.

1. Introspection: "info methods" duplicated entry

In the following I report e test case that shows the problem:

Class MetaClass1 -superclass Class -parameter {{a "v1"} {b ""}}
Class MetaClass2 -superclass MetaClass1 -parameter {{a "v2"} {c ""}}

MetaClass1 Class1
MetaClass2 Class2

lsort [Class2 info methods]
result: __next a a abstract ....
expected: __next a abstract ....

Class2 info methods a
result:a a
expected: a


2. Usage string

Object n
n info children -class Interface
wrong # args: should be {::n info children ?pat?}

I expect:
wrong # args: should be {::n info children}

or there is somethig missing in the language reference documentation?

3. Dynamic Object aggregation improvement issues

I think would be useful, especially for performance reasons, that
dynamic object aggregation have more introspection functionalities at
core language level:
for example at the info children command could be added options that
returns children filtered by children class (and object names and ... ?)

More in general,an useful feature could be returning all children that
match some assertions (something like an invariant list)


Attilio




--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster_at_telecomitalia.it.

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 23 Jul 2007 10:45:07 +0200

Hi Ben,

I am not aware of the symptoms, you are describing. we reload scripts
frequently
espesically in the openacs environment (openacs.org, reloading contents
is part
of the normal develoment cycle). I use it here as well under linux and OS X.

a few qestions:
 - are you sure, that you compile and run with the same tcl version?
   (if you have multiple tcl versions on your system, use --with-tcl
   during configure; i doubt this is the problem in your case, since
   you say, it happens on OS X and Linux, but still worth to check).
 - which Tcl version are you using exactly?
 - are you using tcl (and xotcl) with theads enabled?
 - uses the code threads?
 - uses the code tcl traces? (e.g. via slots through type-checker,
   initcmd, valuechangecmd)

The biggest help would be to distill a short script that shows the bug.
It might also help to determine, where the code exactly dies. Compile
tcl and xotcl with -g and run the script under gdb (call "gdb <yourtclsh>"
and source the xotcl code; when the code dies, send me the output,
and type in "where" and send me this output as well).
One might get a hint, what happend.

-gustaf neumann

Ben Thomasson schrieb:
> Hello again,
>
> I bring bad news. I am receiving seg faults and bus errors while
> running XOTcl code. I am running XOTcl 1.5.3 and Tcl 8.4 on both
> Linux x86 and OS X PPC. I received the errors randomly on both
> platforms. This started occuring when I reloaded the source code. At
> first I thought it was related to Tcl packaging, but I mostly removed
> calls to package require and package forget. Currently I just use
> source to load most files. I am writing code generation libraries
> and using Object eval so I may be doing new things with XOTcl. How
> should I go about debugging these seg faults? Are core dumps useful?
> I'll try to write a script that reproduces the problem, but I
> haven't really narrowed the problem down yet.
>
> Any help is much appreciated.
>
> Thanks,
>
> Ben
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>