Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 23 Feb 2006 18:08:54 +0100

For now, the best coming up my mind is:

   Class Queue -parameter {{queue [self]::queue}}
   Queue instproc init {} {
     ::struct::queue [my queue]
   }
   foreach cmd {clear get peek put unget size} {
     Queue instforward $cmd {%my queue} %proc
   }
   Queue instproc destroy {} {
     [self]::queue destroy
     next
  }

or you can try this road:

  Class Queue
   Queue instproc init {} {
     set queue [self]::queue
     ::struct::queue $queue
     my forward clear $queue %proc
     my forward get $queue %proc
     my forward put $queue %proc
     my forward peek $queue %proc
     my forward unget $queue %proc
     my forward size $queue %proc
   }
   Queue instproc destroy {} {
     [self]::queue destroy
     next
   }

guess, we have currently no shortcut to address a child of the current
instance. suggestions for making things nicer are always welcome...

-gustaf

From: <iifat_at_mail.ru>
Date: Tue, 12 May 2009 09:32:15 +1100 (VLAST)

> Object instproc F args {
> puts "CALL [self] [self calledclass]->[self calledproc] $args"
> set r [next]
> puts "EXIT [self] [self calledclass]->[self calledproc] ($r)"
> return $r
> }

Better, imho

Object instproc F args {
  puts "CALL [self] [self calledclass]->[self calledproc] $args"
  catch next r o
  puts "EXIT [self] [self calledclass]->[self calledproc] ($r)"
  return -options $o $r
}

From: Matthew Smith <chedderslam_at_gmail.com>
Date: Thu, 8 May 2008 11:17:07 -0500

That got it. Thank you.

On Thu, May 8, 2008 at 11:14 AM, Vasiljevic Zoran <zv_at_archiware.com> wrote:

>
> 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: <jim_at_jam.sessionsnet.org>
Date: 29 Mar 2004 01:55:30 -0000

Hi,

When configuring xotcl in any way whatsoever, it checks the $CWD variable
to determine if the string "aolserver" is anywhere in it. If so, it assumes
mistakenly in many cases that the build should include aolserver extensions.

The right way to do this is to add to configure.in a switch that allows the
builder to tell the configure step whether or not it should build with
aolserver extensions.

-Jim

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Thu, 16 Jul 2015 11:47:24 +0200

> PS: For novices the "mixture" of ::nx and ::xotcl is a bit unexpected, for
> example when serializing ::xotcl::MetaSlot on my OpenACS instance, one can
> see, that e.g. the superclass of ::xotcl::MetaSlot is ::nx::MetaSlot et
> cetera. My intuitive expectation was that both XOTcl 2 and NX exist as
> different languages within NSF, but more or less completely isolated from
> each other.

XOTcl building on NX (esp. slots) is hinted at some spots in the
migration guide at
https://next-scripting.org/xowiki/docs/nx/nx-migration/index1#_parameters_2.

> I suppose the reason is to keep the source code required to
> support the "legacy" XOTcl syntax as small as possible?

So it is.

Stefan

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 27 Sep 2005 13:12:07 +0200

Will Duquette schrieb:

>
>>
>> OK. The essential thing being done here then is to break down the
>> grab-bag of methods defined in Class and Object into a bunch of
>> different interfaces, so that clients of an object don't have to
>> worry about a bunch of extra "proc" and "filter" etc methods that
>> have nothing to do with their problem domain. I can sympathise with
>> that. However, I'm not sure [define] is the right solution, as it
>> just creates another bag of methods elsewhere (somewhat like [info]
>> has become). We could simply change the methods to be class- methods
>> of [class] and [object] (i.e. procs that expect an explicit self
>> argument, rather than instance-methods). That way by default
>> objects don't get lots of public methods that aren't needed by
>> clients, but you can still do, e.g.:
>
First of all, i do not like having define as it is for various reasons.
But having define as
an extra command is for an xotcl person not such a horrible thing, as
long we have
(inst)forward, which can bring it back into business with a one-liner.
The other way
around is more complicated.

But still, i think this issue is more than a matter of taste:
here are a few arguments:

 a) a more radical approach is to move all c-level commands out of
      object and class into one or more method repositories (similar to
      namespaces, but just a hash table containing for commands) and
      let the object system designer link these (private/public, if
      necessary) into the base classes of an object system. One can
      design a SnitClass or an XOTcl class or lsay a Java-kind class
      quite freely, and it provides room for incremental improvement
      without harming others.

 b) We have discussed splitting xotcl classes into smaller components
      about two years ago. We did not do this mostly since xotcl users
      would most likely use Obect and Class as it is today.

      Roughly and abstractly speaking, an xotcl class differs from
      an xotcl object by
       - providing a method repository (MR) for its instances
       - providing a life cycle management (LCM, factory with recycling)
for
         its instances (create, alloc, configure, init, recreate,
destroy, dealloc)

      An xotcl object contains a data repository (DR) with an optional
(from the
      implementation point of view) method repository for itself.
Furthermore,
      objects are commands (which is to some respect nice, but makes it
      very hard to compete in speed with languages which have more
      lightweight objects such as Java).

      A simplified picture of xotcl looks as follows:

         XOTclObject = Cmd + DR + MR(self)
         XOTclClass = XOTclObject + LCM + MR(instances)

      With mixins, a class can have multiple MRs for its instances, and
      an object can have multiple MRs for self.

      Through various recent TIPs, Tcl namespaces are
      converging towards xotcl Objects. As Tcl provides data repositories
      both through namespaces and arrays. I would like to see a
      convergence here, providing
      maybe multiple "views" to the same "data model" (in the MVC
      terminology), allowing e.g. "array names" on namespaces/objects
      or the data store methods (e.g. set, unset, trace, ...) as
      overloadable methods on associative
      arrays and to provide a uniform interface for defining
      procs/methods/instprocs..., not having to use sometimes "proc",
      other times "define method". This issue of having slim
      interfaces continues certainly on the C level where different
      implementation for this isses bloat the code and makes it hard for the
      code to behave consistently.

      Furthermore the bunch of info commands can
      be reduced by specifying in the info command the MR explicitely
      (using e.g. MR(method)), using e.g. one "info args", one rename
      method etc. for all methods/procs/instprocs/commands.

      It would be certainly interesting to have the aspects described
above
      as first class entities on the tcl layer and to provide composition
      functionalities for these similar to mixins for system designers.

      Having said this, i am certainly not sure that "define" leads
      the right way by moving the methods to manipulate the MR
      to the top.

c) the concern with "clean interfaces" is certainly valid but addresses
    not only the number of methods, but as well orthogonality
    (so, define is neither orthogonal with tcl or xotcl). Providing
    a smaller interface can be achieved through good composition
    facilities (having the "right" superclasses, mixins) and
    hiding/protection (don't show helper methods, define explicit
    interfaces, making methods/variables private).

    From earlier discussion about this TIP, i had the impression
    that this discussion is as well about "system matters" vs.
    "application matters".
    when one introspects an object, to see application issues
    (like submit, book, ...) rather than implementation nissues like
    being able to lappend to
    variables, etc. The point of view depends certainly on where
    one is doing the introspection, on the object (info methods is
    large) or on the class of the object with it instprocs. The
    documentation will be in most cases more on the class than
    on the object level, which will be a rather slick interface.

    The TIP writers did not like the fact that general functionality
    is introduced in xotcl from Object (as it is in Ruby or Smalltalk
    or many other OO languages). I never found this a problem
    in real applications. i rather see problems with some low-level
    stuff, when it is not this way, when classes are destroyed, objects
    are reclassed, etc. I would feel better, when Object, Class are
    xtocl-like and and we provide some protection schemes through
    subclasses.

I am not going to repeat all earlier discussions here. Is it OK to
send improvement proposals for the current TIP here, leaving
aside this bigger issues?

-gustaf

From: Artur Trzewik <mail_at_xdobry.de>
Date: Sun, 16 Feb 2003 09:56:14 +0100

Hi!

Now It is possible! Full debugging tool in tcl.

I have written an tcl-extension to support debugging in Tcl
atkdebbuger
see - http://www.xdobry.de/atkdebugger/index.html
unfortunately it requires some patch to tcl8.4.1

This debugger is full supported in XOTclIDE
see
http://www.xdobry.de/xotclIDE/extdebugger.html

this functions are possible now
- invoking debugger in error case (not catched errors)
- breakpoints
- invoking debugger per special atk::halt command

Artur Trzewik

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 02 Feb 2012 09:32:41 +0100

Dear Community,

We are pleased to announce the availability of the Next
Scripting Framework 2.0b3
which can be obtained from http://next-scripting.org

Best regards
- Gustaf Neumann
- Stefan Sobernig

===============================================

Announcing NSF 2.0b3
*************************

Major changes relative to NSF 2.0b2 are:

    * Additional Features:
      - object parameters:
        call method "assign" on slot objects, when it is
provided

      - include "-returns" in introspection for aliases and
        scripted methods. New subcommand "info method returns"
        for nx.

      - better compatibility with XOTcl 1.*:

        * invocation of objects via method interface follows per
          default the XOTcl 1.* conventions. In order to
obtain the
          semantics of ensemble objects, the object properties
          "keepcallerself" and "perobjectdispatch" have to
be used.

        * better handling of XOTcl 1.* configure commands
(starting
          with a "-") when list property is lost (Many
thanks to
          Zoran Vasjljevic for the good example)

        * use different version numbers in serializer to avoid
          mixups between XOTcl 1 and XOTcl 2 when both
          packages are installed

    * Improved Code Quality:
      - improved performance
        * rewrite of alias handling (alias reform)
        * improved branch prediction
        * significant speedup for handling large numbers
          of subclasses (subclass reform), avoid
          repetitious computations
        * significant speedup on mass-destroy (e.g. on
thread exit)
      - provide better protection for deletion/overwriting
        of base classes
      - fixed potential duplicates on diamond inheritance
      - fixed unknown handling for "-local" and "-system"
        dispatches
      - improved compatibility for windows compilations
        (c89, __WIN32__)
      - fixed potential crashes
          * during method caching
          * error messages
          * implicit deletions
      - follow Tcl convention on error messages
        (start always with lower case)
      - better handling of multiple errors in a single command.
      - return GMT dates in Httpd as RFCs require

    * Improved documentation
      - fixed typos, improve wordings

    * Extended regression tests

MORE INFO
   General and more detailed information about the
   Next Scripting Framework and its components can be
   found at http://next-scripting.org

From: Artur Trzewik <mail_at_xdobry.de>
Date: Thu, 10 May 2001 22:00:13 +0200

Hallo

There are new Version 0.15 of xotclIDE
on my site
http://www.xdobry/xotclIDE

New futures:

1. databased control version system. All changes on the xotcl source are
stored persistent to database on the fly. Also CompLoader to load
applications from database. (Currently only mysql are tested)
You can return to every development state in the past, manage editions and
versions of components, classes, objects and methods

2. improved object inspector. To see and invoke mixins methods

3. simply configuration managment browser. To handle components sets and
make a xotcl distributions of your applications

4. improved component modell (currently only better tcl packages) to handle
dependiences

5. more documentation and simple application

There can be many reasonable tools for xotclIDE.
I thing xotclIDE should be rather a set of tools than one application.
If you have any usefull tools for xotcl (tracker, profiler, optimizer,
debugger) send them to me.
Bug reports and suggestions are welcome

Artur Trzewik

From: Jeff Hobbs <jeffh_at_activestate.com>
Date: Thu, 23 Nov 2006 09:21:52 -0800

Cristian Chaparro wrote:
> Has anybody compiled xotcl to be used on a pocketpc with etcl?
> Libraries, instructions... whatever info is welcome.

As xotcl uses the TEA build system, it should inherit the ability to compile
for PocketPC. You will need some core dev libs to build against, but
otherwise it just requires the same build options as the core, as noted here:
        http://wiki.tcl.tk/10103

  Jeff Hobbs, The Tcl Guy, http://www.ActiveState.com/