Weblog Page

From: Uwe Zdun <zdun_at_infosys.tuwien.ac.at>
Date: Tue, 11 Jul 2006 18:24:29 +0200

The method "check" can be used to turn off assertions. The example from
the tutorial:

  $fb check all
  if {[catch {$fb set playerRole SINGER} errMsg]} {
    puts "CATCHED EXCEPTION: playerRole has either to be NONE, PLAYER, or TRAINER"
    # turn assertion checking off again and reset to PLAYER
    $fb check {}
    $fb set playerRole PLAYER
  }

The idea is per default all checks are off. Then you turn them on for the objects, you want to be checked in a development environment,
and simply remove the "turn-on code" for the production environment (or redefine the method check, if you want to do it for all methods
at once).


--uwe


Kristoffer Lawson wrote:

> Have I missed something, or is there no easy way of turning asserts
> off or on for all objects? It's common that during the development
> phase you want all the asserts turned on and, perhaps for performance
> reasons, turn them off when finished. I know it could be possible by
> overwriting the create method, or whatever, but I was looking for
> something... well ... less hacky.
>
> / http://www.fishpool.com/~setok/
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Kristoffer Lawson <setok_at_scred.com>
Date: Thu, 5 Aug 2010 16:31:58 +0300

Apologies for the flood, but I can't get my mind off this. Some more ideas for how this could be made to work:


== Use a brand new command:

set ob [new Car "Land Rover"]

set ob [new -with {-doors 2} Car "Caterham"]

or

set ob [new -with {
        doors 2
} Car "Caterham"]

Here there is no real risk of pre-initialisation getting confused with arguments to the constructor. It doesn't look quite as nice as my earlier suggestion:

set ob [Car -new "Caterham" {
        doors 2
}]

But it would mean not having to have both [new] and [-new]. The current [new] method could then be deprecated, without breaking old scripts.


== Do something a bit like Objective C:

set ob [[Car create] init "Land Rover"]

set ob [[[Car create] conf -doors 2] init "Caterham"]

or possibly:

set ob [Car create]
$ob doors 2
$ob init "Caterham"

This could probably be done in a near backwards compatible way. It's very explicit without any funny logic. In fact you can almost do it right now, except there is no method to create with an autoname, but to not do argument configuration and construction calling.

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

From: Schofield, Bryan \(GE Transportation\) <"Schofield,>
Date: Tue, 2 Nov 2004 15:47:37 -0500

I don't think it is a bug, and I don't think it is unexpected behavior...exactly; more on that in a second. In fact, if it *were* available, as you expected, I'd consider that bad behavior since no package should ever export commands into the root namespace automatically. So, if it's not behaving badly, but still isn't exactly what you expected, where does this discrepancy come from, and how is it resolved? I suggest that documentation is culprit and the solution. I think that an "XOTcl & Namespaces" section or a "General XOTcl Usage" section that describe this situation would beneficial.

Btw, I remember when I first stumbled across this; it made me step back and scratch my head too.

--bryan

> -----Original Message-----
> From: xotcl-bounces_at_alice.wu-wien.ac.at
> [mailto:xotcl-bounces_at_alice.wu-wien.ac.at]On Behalf Of Damon Courtney
> Sent: Tuesday, November 02, 2004 3:27 PM
> To: xotcl_at_alice.wu-wien.ac.at
> Subject: RE: [Xotcl] [Fwd: Bug with namespace'd Class?]
>
>
> I figured as much. I guess I'll just do import the
> commands into the
> root namespace. It doesn't really bother me, but some of the other
> Tcl'ers are real sticklers about namespacing everything. I just use
> what's best. 0-]
>
> So, does this still constitute a bug then, or should I
> just chalk it
> up to expected behavior?
>
> Thanks,
>
> Damon
>
> > because "self" is a command in the xotcl namespace. you
> will also find
> > that there are others, such a "my"
> >
> > If you don't import xotcl, you end up with source that
> looks like this:
> >
> > ::xotcl::Class foo
> > Foo instproc bar {} {
> > puts "[::xotcl::self] is a [::xotcl::my info class]"
> > }
> >
> >
> > I'd suggest, do something like the following...
> >
> > package require XOTcl 1.3
> > namespace eval fooPackage {
> > namespace import ::xotcl::*
> > Class Foo
> > Foo instproc bar {} {
> > puts "[self] is a [my info class]"
> > }
> > }
> >
> >
> > hope that helps.
> > -- bryan
> >
> >> -----Original Message-----
> >> From: xotcl-bounces_at_alice.wu-wien.ac.at
> >> [mailto:xotcl-bounces_at_alice.wu-wien.ac.at]On Behalf Of
> Damon Courtney
> >> Sent: Tuesday, November 02, 2004 2:23 PM
> >> To: xotcl_at_alice.wu-wien.ac.at
> >> Subject: [Xotcl] [Fwd: Bug with namespace'd Class?]
> >>
> >>
> >> Why does this not work?
> >>
> >> package require XOTcl
> >>
> >> ::xotcl::Class Foo
> >>
> >> Foo instproc bar {} {
> >> puts "SELF = [self]"
> >> }
> >>
> >> Foo foo
> >> % Foo foo
> >> ::foo
> >> % foo bar
> >> invalid command name "self"
> >>
> >>
> >> But, if I "namespace import ::xotcl::*" and make the
> >> class with just
> >> the Class command (not ::xotcl::Class), it works.
> >>
> >> Any ideas?
> >>
> >> D
> >>
> >> PS: Windows, Tcl 8.4.3, XOTcl 1.3.1
> >>
> >> _______________________________________________
> >> 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: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 28 Sep 2005 00:51:02 +0200

Dear XOTcl community,

I am pleased to annouce XOTcl 1.3.7.

Major changes relative to 1.3.6 are:

     * Improved Functionality
       + new option "switch" for non positional arguments to be used
           to toggle the default value. A switch is a non positional
argument
           without extra argument.
       + new option "isnextcall" for self
       + new command "::xotcl::configure filter on|off" to turn off filters.
           needed for serializing objects/classes with active filters
       + several improvements for serializer to handle e.g. application
           methods on Object/Class (needed for ad_instproc in oacs)
       + improving namespace resolving in for object/class references
       + moving all library packages into namespaces
       + preventing "new" from overwriting objects
       + allow xotcl to be used in slave interpreters


     * Improved code quality:
       + fixed namespace confusion in forward to expression calling
           xotcl methods
       + fixed possible crash in instvar when empty variable names are used
       + some code cleanup
       + improved documentation

    * new method "method" for defining methods (experimental):
       Instead of using e.g.
      
           Object o1
           Class C

           o proc m1 {} {....}
           C instproc m2 {} {....}
           C proc m3 {} {....}

       one can use now

           o method m1 {} {....}
           C method m2 {} {....}
           C method -per-object m3 {} {....}

       in general, we can support options for method definitions, which
       can be used as well for mixins, filters or info (instead of the
       "inst" prefix). This way the problem of finding appropriate names
for
       distinguishing between object or class matters can be solved,
       in rather rare cases (when referring the to class object)
"-per-object"
       can be used. The according name changes will happen in xotcl 2.0.
       
 For more details about the changes, please consult the ChangeLog and
 documentation.

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


Best regards,

Gustaf Neumann
Uwe Zdun

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Mon, 12 Apr 2004 18:10:44 -0700

> > This is just plain wrong. Drop the mega-binary idea. It is dead,
> > dead, dead, dead.
>
> flame down, i know this, we have adressed this. per default,
> xotcl creates a file called "xotclsh", which is a tclsh
> script, and NOT the binary you are talking about. Do you
> oppose as well a tclsh script, having such a name?

Not really, it's only a bit confusing. I do *prefer* that a
user just knows that they can rely on 'tclsh' and then uses
'package require xotcl'. Note that the xotclsh and xowish
that you build are not actually created +x, which would be
an issue for use (at least not on build, maybe on install).

> look at our configure stuff, it has changend substantially
> in the last year. I would say, that i have personally
> invested over the last year more time into making xotcl's
> build system
        ...
> as a result, xotcl was added to the tcl/tk distro for max OS
> X (Aqua). Correct me, if i am wrong, but I got the
> impression you are taking about the build system of xotcl,
> as it was about 2 years ago, and not about our current stuff.

I had no issue with building 1.2 myself in the normal way that
I expect (which is separate source and build dirs). I'm sorry
that using TEA was so time consuming, but the earlier mods
that I sent a year ago to your build system took me only a day
to make. Of course, I ignored anything but the xotcl package
because I believe everything else was "fluff". I think the
xotcl 1.2 general organization is much improved though.

I see in your other message that you have the TEA3 stuff
working well. I'm glad that you also find the less verbosity
helpful - that was a goal. If you want to make a test build
available, I will review it and send comments, but cannot do
that until Thursday or Friday.

One of the reasons to version TEA_INIT was that upgrading
should be easier. However, TEA3 is certainly not "settled".
If there is something you don't like about it, or something
that would make it easier from your point of view, please
tell me. I haven't propagated TEA3 to a lot of extensions
yet, so it's not "fully refined".

Note that the advantage of being "TEA compatible" is that it
is much easier for distros to add you in (like Steffen did,
and we are planning to do in ActiveTcl). It also means that
you worry less about build system portability - let the core
porters worry about that. For example, with the latest TEA
you should be able to make a Win/CE build without any other
code changes (assuming you don't call some evil Windows APIs).

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

From: Schofield, Bryan \(GE Transportation\) <"Schofield,>
Date: Fri, 22 Oct 2004 16:51:41 -0400

I think you've stumbled on the namespace resolution bug that appeared with 1.3.0. Gustaf & Uwe have been working on fix and appear to close to releasing a new version. I'm testing a 1.3.3 version of XOTcl for Gustaf now.
I added one more combination to your test:
   inner::Inner inner::i2
and I get the following results:

In ::
 o -> GLOBAL EXAMINE
 i -> inner examine
 inner::i2 -> inner examine

In ::inner
 o -> GLOBAL EXAMINE
 i -> inner examine
 inner::i2 -> inner examine

Which seems more inline to what you were expecting to see. Try this test version of XOTcl and see if you get better results. I'm sure the XOTcl guys would appreciate the extra testing anyway.
   http://media.wu-wien.ac.at/download/xotcl-1.3.3.tar.gz


Hope that helps.
-- bryan




> -----Original Message-----
> From: xotcl-bounces_at_alice.wu-wien.ac.at
> [mailto:xotcl-bounces_at_alice.wu-wien.ac.at]On Behalf Of Adam Turoff
> Sent: Friday, October 22, 2004 4:21 PM
> To: xotcl_at_alice.wu-wien.ac.at
> Subject: [Xotcl] XOTcl / Tcl Namespace issues
>
>
> Hi,
>
> Can anyone explain why this program:
>
> package require XOTcl
> namespace import xotcl::*
>
> proc ns {} {return "global"}
> proc examine {} {puts "[ns] EXAMINE"}
>
> Class Outer
> Outer instproc test {} {return [examine]}
>
> namespace eval inner {
> proc ns {} {return "inner"}
> proc examine {} {puts "[ns] examine"}
>
> Class Inner
> Inner instproc test {} {return [examine]}
> }
>
> Outer o
> o test
>
> inner::Inner i
> i test
>
> namespace eval inner {
> ::o test
> ::i test
> }
>
> produces this output:
>
> global EXAMINE
> global EXAMINE
> inner examine
> inner examine
>
> I've defined the class 'Inner' within the namespace 'inner'. I'd
> expect that proc in methods defined within that namespace should first
> look within that namespace before looking in the global namespace.
> Instead, they look in the namespace currently in use when a
> method call
> is made. (Note how ::o test picks up the definition of inner::examine
> when invoked from the inner namespace.)
>
> This is the opposite behavior of how Tcl proc calls work --
> when I land
> on inner::examine, the [ns] is actually shorthand for
> inner::ns, not ::ns.
>
> I'm guessing there's a good reason for this behavior, but I can't seem
> to find it in the docs.
>
> Thanks,
>
> -- Adam
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Wed, 5 Mar 2003 06:26:01 +0200 (EET)

On Tue, 4 Mar 2003, Laurent Duperval wrote:

>
> Oh! I thought it was "A Tk Debugger".

Oh, could b! For me it's always going to be ATK Debugger, though :-)

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

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Fri, 25 May 2012 12:06:52 +0200

Dear Arthur,

What platform and what version are you using?

First of all, "nx::Class create ..." does not necessarily
create a namespace:

    $ ./nxsh
    % nx::Class create A {}
    ::A
    % proc ::A::new {} { return "something" }
    can't create procedure "::A::new": unknown namespace
        while executing
    "proc ::A::new {} { return "something" }"

When i create a class with a tcl namespace, i don't see
the problem either (using the head version)


   $ ./nxsh
   % nx::Class create A {:public class method foo args {}}
   ::A
    % proc ::A::new {} { return "something" }
    % rename ::A::new ""
    % A new
    ::nsf::__#0

-gustaf neumann


On 25.05.12 11:07, Arthur Schreiber wrote:
> Hey Gustaf,
>
> The following is propably a very uncommon use case, but it causes a
> segfault, so I think it's rather serious:
>
> % package require nx
> % nx::Class create A {}
> % proc ::A::new {} { return "something" }
> % A new
> something
> % rename ::A::new ""
> % A new
> [1] 2515 segmentation fault (core dumped) tclsh
>
> Kind regards,
> Arthur
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sat, 4 Feb 2006 12:39:58 +0200

On 3 Feb 2006, at 17:11, Gustaf Neumann wrote:

> Kristoffer Lawson schrieb:
>
>>
>> Well this generally happens automatically anyway. If they are
>> resources for which this does not happen, can we be sure that this
>> is what the programmer wants?
>
> consitency is important.
> in oo-systems, the programmer has a "contract" with the system,
> that for every object
> the life-cycle starts with the constructor and ends for the
> destructors.
> This is simlar to finalize() in java.
> normally, you do not want to distinguish btwn. "manual" and
> "automatic" destroys (which happen
> btw. in various situations).

I would say this depends very much on your point of view. In systems
with prevalent persistence then the existence of an object continues
until it is explicitly destroyed. Ie. automatic destruction does not
occur. You can few objects in two different ways, as in-memory
entities they exist only as long as the application exists. But you
can also take the view that the in-memory entities are just
representations of the actual object, which resides also on disc.

> You cound do e.g.
>
> ::xotcl::Object setExitHandler {set ::xotcl::onEXIT 1}
>
> and check this variable from the destroy method whether or not the
> db-instance
> should be deleted.

Yes, this could be one possible way round that.

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 07 Feb 2005 21:20:28 +0100

Hi Kristoffer,

the bug happens as well under linux. it is not an OS X issue.
Currently, reclassing object to classes is not supposed to work
for xotcl (it is not supposed to crash either).

There are two fixes for that, one simple (don't allow reclassing of
objects to classes)
or a more complex one (do more or less a recreate automatically when
this happens;
it tries to keep the object information as far as possible).

did you try this example out of curiosity or do you have an interesting
example?

-gustaf
PS: i did not know that you are using a Mac...

Kristoffer Lawson schrieb:

> I know this is somewhat obscure but it nonetheless appears to be a bug:
>
> % package require XOTcl
> 1.3
> % xotcl::Object ob
> ::ob
> % ob class xotcl::Class
> % ob info class
> Bus error
>
> (On Mac OS X 10.3.7)
>
> I was interested to find out if it's possible to make an already
> existing object into a class dynamically :-) (Should it be?)
>
> / http://www.fishpool.com/~setok/
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl