Weblog Page

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Tue, 30 Nov 2004 13:27:12 -0800

The patches I send are cumulative, so you just need this
patch against pristine xotcl-1.3.3. This patch adds to
the previous with fixes for compiling against 8.5 on
Windows. There was header management changes in 8.5 which
force a different order of includes, and this causes
several redefine issues. In general though, enums with
names like INIT, ALLOC, EMPTY and ZERO should not be
considered very exclusive. ;)

  Jeff Hobbs, The Tcl Guy
  http://www.ActiveState.com/, a division of Sophos

From: Neil Hampton <neil.hampton_at_rostrvm.com>
Date: Mon, 27 Sep 2010 14:02:55 +0100

I am having a problem/have found a bug with slots created with an
-initcmd.
If I set a value on an object containing a slot with an initcmd and then
move it an error gets thrown every time I read the value.
 

        Class Fred -slots { Attribute a -initcmd { set _ 4 } }
        Fred x
        x a 4
        x move y
        y a
        can't read "a": invalid command name "::x"

Are there any simple work arounds for this other than having to write a
method for 'a'?

Neil Hampton
www.rostrvm.com

From: Artur Trzewik <mail_at_xdobry.de>
Date: Sun, 5 Aug 2001 15:10:42 +0200

Hi!

There is new 0.18 version of XotclIDE

http://www.xdobry.de/xotclide

Main Changes:
1. test framework and small GUI for automatic unit tests.
2. same test classes for xotclIDE (many bugs could be found and destroyed)
3. changes browser. (do diff like work for objects versions)
4. Same new function for method editing. Next Prev functions to browse methods
like in hypertext browser (with viewing history). Spawned windows for method
editing.
5. Wizard dialog for creating or redefining classes
6. Many additional small functions.


Artur Trzewik

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 12 Dec 2006 11:38:43 +0100

Scott Gargash schrieb:
>
> Perhaps it would make sense to break the download into two parts, a
> runtime environment and an SDK. I'm unsure what other extensions have
> a binary interface, but for XOTcl (at least) all that needs to be
> shipped is a couple of headers and the stubs lib. It seems equivalent
> to Tcl proper. In fact, perhaps even the base Tcl libs/headers ought
> to be in an SDK package. I'd think than many, perhaps even a majority
> of, users don't need the Tcl headers & libs.
>
> But if it's not there, it's not there. Oh well, back to building my
> own version.
>
Another option is to use the windows binary version built with MinGE
provided by Martin Matuska at

   http://wintcltk.berlios.de/

This verison contains the stublib and header files.

best regards

-gustaf neumann

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 12 Apr 2006 11:42:07 +0200

Scott,

my recommendation is to define a mixin-class overloading create,
where you can specify conveniantly what should be done after
each object is created. register this mixin class before you perform
the eval of the serialized code, and deregister it after it.

concerning point 1, there is as well a -map option for deepSerialize
for conveniance (see http://media.wu-wien.ac.at/doc/Serializer-xotcl.html)

best regards
-gustaf neumann


Scott Gargash schrieb:
>
> I'm using XOTcl objects to control hardware, and I'm trying to use the
> Serializer to persist hardware configurations. However, I've run into
> a couple of issues.
>
> 1) Not all of the object state is the consistent across
> serialization/deserialization. The hardware handle, for instance, may
> not be the same at deserialization time as it was when serialization
> occurred. What I'd like to do is remap some member variables to
> un-substituted variables ("-set hwhandle $handle" instead of "-set
> hwhandle 0x1234"), and then I'll set the variable to the correct value
> when restoring the configuration. I see a way to ignore variables and
> a way to remap object names, but is there a way to remap variables?
> Short of a global regsub on "Serializer deepSerialize" return result,
> that is?
>
> 2) The serializer bypasses initialization (-noinit), and basically
> just restores the internal state of the object. But in my application,
> I need to bring the hardware state into sync with the xotcl object, so
> just setting xotcl state variables doesn't suffice. Is there an easy
> way when deserializing to have some code executed after the object's
> state has all been restored? Something like a -noinit flag, but
> instead have a custom -init?
>
> Maybe instead of "-noinit", objects should have a "-init method" flag
> that determines the initialization mechanism? If the flag is not set,
> or is set to "init", the "init" method is invoked (default behavior),
> if the flag is set to some arbitrary method ("-init hwsync"), that
> arbitrary method gets invoked, and if the flag is set to an empty list
> ("-init {}"), no init method is invoked.
>
> Scott
>
> ------------------------------------------------------------------------
> *Notice*
> The information in this message is confidential and may be legally
> privileged. It is intended solely for the addressee. Access to this
> message by anyone else is unauthorized. If you are not the intended
> recipient, any disclosure, copying or distribution of the message, or
> any action taken by you in reliance on it, is prohibited and may be
> unlawful. If you have received this message in error, please delete it
> and contact the sender immediately. Thank you.
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

From: Michael Schlenker <schlenk_at_uni-oldenburg.de>
Date: Wed, 19 May 2004 18:07:56 +0200

Kristoffer Lawson wrote:

>On Wed, 19 May 2004, Michael Schlenker wrote:
>
>
>
>>Its similar in tcl, where you have [info commands] and not a magic
>>$commands variable as you might have in other languages.
>>
>>Using traces it should be possible to provide such an interface if
>>anyone really wants it.
>>
>>
>
>So what is so problematic about just getting a list, manipulating it and
>then setting it back? Seems like a lot of copied effort for what is
>basically just list manipulation.
>
>
Yep. I refer to Adam and Neil who both wanted to have mutable objects
instead of accessor functions.
Its the usual problem with mutable list objects and the tradional value
based list operations in Tcl.

For the typically short list of mixins and filters its mostly a
reduction of some characters to type, not more.

But i think Adam is right in his direction that it would probably more
natural to add the Mixin to the head of the list instead of the tail.

So what to do?
a) keep it as it is and use tradtional Tcl list semantics to make changes
b) add a primitive to prepend a Mixin
c) add something so the Mixin List is applied in the inverse direction,
from last to first

I think option b) isn't the right thing to do. c) is attractive but has
semantic consequences. a) is do nothing

Michael

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 21 Oct 2006 11:32:37 +0200

Kristoffer Lawson schrieb:
>
> On 21 Oct 2006, at 11:33, Gustaf Neumann wrote:
>
>> Kristoffer Lawson schrieb:
>>>
>>> I don't mean the state of the object at time of calling, in the
>>> sense of slots, but the values passed to the constructor on object
>>> creation. The args to 'init'. The reason for this is that it might
>>> not be enough to just create the object with the appropriate state,
>>> but it might need to go through the 'init' stage as well, so the
>>> proper initialisation chain is done (f.ex. might be calls to other
>>> things taking place there, registration with managers etc). After
>>> that, slots can be set.
>> i see, you mean the per-object parameterization; the arguments to the
>> object/class creation are not stored explicitely
>> in XOTcl. However, the simplest way to save these is to provide a
>> per-class mixin for overloading the standard
>> configure behavior.
>>
>> Does this help?
>
> No, I didn't mean per-object parametrisation, but the arguments passed
> to the constructor itself. F.ex.
>
> Class Foo
>
> Foo instproc init {name parent} {
> ....
> }
configure gets all arguments, including the values passed to init. Use
the one-liner of my last mail, and you
will see that this works for your example as well. if you pass the saved
values to object creation, you achieve
both, configuring the attributes and calling the constuctor with the
saved values.
>
> Mixins are probably risky here as the 'init' method does not have to
> call [next]. I could do this with a filter, I guess, or perhaps by
> overloading [create].
mixins are in no way more "risky" than a filter or overloading "create".
The mixins are in the precedence order
before the intrinsic class tree. So, it does not matter whether or not
someone has overloaded in the intrinsic
class tree "configure", and/or forgotten to write a next there.

-gustaf neumann

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Sat, 10 Apr 2004 13:51:45 -0700

Gustaf Neumann wrote:
> i get the impression you are fixing things that are not broken
> in the general distribution. The configure stuff is
> defined to produces always a file xotclsh or xowish, no
> matter whether you compile with or without --with-xotclsh.

This is just plain wrong. Drop the mega-binary idea. It is
dead, dead, dead, dead. Tcl has had a very good dll mechanism
for 7 years - all extensions should use it. So IMO Jim is
fixing a configure system that *is* broken, at its very core
design. You can do so much more with a pure extension, that
should always be the default.

-- 
     Jeff Hobbs, The Tcl Guy
     http://www.ActiveState.com/, a division of Sophos

From: Gustaf Neumann <Gustaf.Neumann_at_wu-wien.ac.at>
Date: Wed, 13 Dec 2000 11:41:01 +0100 (CET)

>>>>> "Z" == Zoran Vasiljevic <zoran_at_munich.com> writes:
Z> ------Original Message------
>> 2. However, in the "mixin" case we could enable argument passing,
>> because "mixin" has just one argument? The rest could be passed > to
Z> "init". any objections?

Z> obj mixin Foo arg1 arg2 arg3
Z> would pass arg1-arg3 to init of Foo. Right?

Z> obj mixin [list Foo Bar] arg1 arg2 arg3

Z> would pass arg1-arg3 to init of Foo AND of Bar. Right again?

Z> Is so, then I think it should be done, if possible. 0.85 ? 0.9 ?

 from the implementation point of view this is not a big issue.
 however, from my experience, i should note that i switched from a
 style of "passing arguments to init" to the "-parameter style of
 configuring objects", which is in almost all cases the more elegant
 solution.

 With your example, you will run into a similar problem when
 multiple mixins are registered.

a) Consider the following example:
 
[Class C] instproc init {a} {puts "[self class] $a"; next}
[Class M1] instproc init {b} {puts "[self class] $b"; next}
[Class M2] instproc init {c} {puts "[self class] $c"; next}

 C c1 3 -mixin {M1 M2}

 here passing one argument to the mixin method should work
 (weirdly enough, the argument is before the -mixin, but would
 have similar semantics as
 
   C c1 3
   c1 mixin {M1 M2} 3

 but who says, that the arguments a b and c have the same
 intended semantics? ... using -parameter is much clearer

b) Then we have the factoring problem: what, if M1 and M2 have the
  different argument lists. we could use something like:

   c1 mixin {M1 M2} {3 {a b}}

 but isn't that ugly?
 
 this makes the manipulation of the mixin list (eg. automatically
 inserting a mixin, if it is not there) by a program over-complicated.

c) From the idea, mixins are orthogonal to the intrinsic classes
  and can used for different classes as well. Should not the following
  work somehow as well?

    [Class D] instproc init {x y} {puts "[self class] $x $y"; next}
     D d1 a b -mixin M1

I see your issue, bit we should not rush into implementation.

Greetings,
-gustaf

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 25 Feb 2008 15:32:46 +0100

Great, many thanks!
-gustaf neumann

Martin Matuska schrieb:
> *XOTcl ver. 1.6.0 is now available for Windows and FreeBSD users*
>
> ------------------------------------------------------------------------
> For users of Microsoft Windows:
>
> WinTclTk distribution for Microsoft Windows, versions 8.5.1 and 8.4.18
> URL: http://wintcltk.sourceforge.net
>
> Single-file Tkcon executable (no need to install anything, just run &
> try)
> based on Tcl/Tk 8.5.1 or 8.4.18 including XOTcl 1.6.0 can be
> downloaded from:
> URL: http://wintcltk.sourceforge.net/tkwrap.html
>
> ------------------------------------------------------------------------
> For users of FreeBSD:
>
> FreeBSD ports tree (packages will be built in the next days)
> URL: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/xotcl/
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>