View · Search · Index
No registered users in community xowiki
in last 10 minutes

Weblog Page

Showing 1371 - 1380 of 1561 Postings (summary)

Re: [Xotcl] Problem with per-object mixins?

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Wed, 5 Sep 2001 23:48:56 +0300 (EEST)

On Wed, 5 Sep 2001, Sheik Yussuff wrote:

> Consider the following program fragment:(Win 98 ver 0.85) where:
> 1. X has subclasses B and C
> 2. X has instproc m
> 3. object a mixes in {C B}
> 4. message p sent to object a(see code below)
>
> The code produces as answer:
> method p of A
> method m
> method m of A
>
> I expected:
> method p of A
> method m
> method m
> method m of A

I think your confusion is because class B and C both have the superclass
X, you expect method 'm' to be passed twice to class X. This is apparently
how C++ does it, and leads to substantial complexities in the
language. XOTcl never goes to the same superclass twice in method calls
(so if you increase an index in a super-class, you will be assured it wont
be increased twice by mistake!). I think this is explained rather well in
the XOTcl tutorial. At least it was when I read it through (a while back
now..).

         - ---------- = = ---------//--+
         | / Kristoffer Lawson | www.fishpool.fi|.com
         +-> | setok_at_fishpool.com | - - --+------
             |-- Fishpool Creations Ltd - / |
             +-------- = - - - = --------- /~setok/

Re: [Xotcl] Re: Bug: configure step chooses wrong tclsh [REASONING]

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Jim Lynch <jim_at_jam.sessionsnet.org>
Date: Sat, 10 Apr 2004 16:19:28 -0700

On Sat, 10 Apr 2004 21:01:53 +0200
"Gustaf Neumann" <neumann_at_wu-wien.ac.at> wrote:

> I was not on the chat, but:
>
> - Jeffs suggestion was to use the TEA_* macros instead of the
> stuff we use currently. I was not aware of these new TEA macros.
> the sample extension (sampleextension-0.2) in http://www.tcl.tk/doc/tea/
> contains only SC_* macros, and no TEA_ at all. the same is with tcl8.4.6
> find tcl8.4.6 -type f | xargs fgrep TEA_
> On the other hadm it still uses SC_PROG_TCLSH, determined by
> find tcl8.4.6 -type f | xargs fgrep PROG_TCLSH

OK; right. Those macros are in tcl.m4, which xotcl also has a copy of.
Are they actually copies of each other? Which one is actually used by
autoconf, and under what circumstances?

> By googling around, i found
> http://cvs.sourceforge.net/viewcvs.py/tcl/sampleextension/configure.in?rev=1.37
> which is quite different from the macros.
>
> so... i come to think that SC_PROG_TCLSH is currently the way to go,
> but TEA2 will at some time do everything better with new TEA_* macros

But the order of checking is wrong... if you -happen- to have the right
tclsh in your path before any other, that's when it will find the tclsh
that was built with the right stuff.

> - It is not arbitray, which PROG_TCLSH is used for xotcl:
> Since xotcl depends on some tclInt.h structures, which change from time
> to time, it is highly recommend to use a tclsh, which was compiled with the
> same tclInt.h as the xotcl extension (except you use the xotlc shells, which
> is deprecated). Mixing shells is as well a problem if you use theads e.g.
> for xotcl.

OK, given that, is not the best tclsh the one specified in the
tclConfig.sh file? The SC_PROG_TCLSH does not look for that one first.
Further, if any macro finds a different tclsh, you're saying here that
it shouldn't be used, for at least all the reasons you just gave.

So, I contend it shouldn't use a macro with any search path which
would bottom out to any ol' tclsh that might be found in the $PATH;
if it doesn't find a tclsh specified in tclConfig.sh, that should
be an error which can and should be caught right there.

> on my fedora system i have tcl and xotcl in the same directory, configure
> finds the source version and places e.g.
> TCLSH_PROG = /home/neumann/tcl8.4.6/unix/tclsh
> to the Makefile. is this on your system different?

I can't count the number of different situations I have :) I also
can't count the situations I'm going to have in the future :) But
if the configure/build process is to be stablized, it should work
with all of them. I think this is a good possibility, assuming
after the initial work is done, that it's maintained.

But I can tell you about three of them that I know I do have:

 o There is a system-wide tcl which was installed as a debian
    package; I don't use that myself. I like building, then I
    control what version I use. The tclsh for this tcl is in
    my $PATH, and therefore will be found by SC_PROG_TCLSH.

 o There is a tcl-8.4.5 I built for use in a test jig. This
    is where I'm currently trying to find the build/configure
    problems in xotcl. Happens that the string "aolserver" is
    in the directory path to both the tcl source and its install
    prefix, so a previous but fixed problem would have assumed
    this tcl was for aolserver3.x and therefore compiled in
    support for it. Also happens that there is an aolserver4
    nearby. This tcl was built for use with that aolserver4.
    This aolserver4 is loosely considered part of the test
    jig, but so is a nearby perl interpreter. The tclsh for
    this tcl is -not- in my $PATH, so is unlikely to be
    found first by SC_PROG_TCLSH even though most builds
    of xotcl I'm doing now use its tclConfig.sh.

 o Finally, there is a tcl-8.4.5 built for a different aolserver4
    located in a completely separate dir, /usr/local/aolserver. The
    username that can write to this dir is nsadmin; the tclsh in
    this tcl might be in nsadmin's $PATH; I don't remember for sure.
    This aolserver and tcl are used to support a few test instances
    of openacs, which I hope to try with xotcl, and to allow other
    openacs users to also do. Some openacs users and core developers
    have expressed great interest; it is for this reason I even start
    with xotcl at all. I am dumb as a stump with xotcl, I just know
    some things about building it :)

In summary here, I want to have xotcl be able to build
in all three of these situations and many more. Early
on, I had mentioned that I was unaware if my "help" in
this area (make the configure/build work and be stable)
is actually welcome, and I repose that question here and
now, adding this: Once the build and configure processes
are stable, will they be kept maintained that way?

> -gustaf neumann

-Jim

--
Jam sessions community web site: http://jam.sessionsnet.org

Re: [Xotcl] Very severe limitation in XOTcl

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: <mail_at_xdobry.de>
Date: Wed, 4 Aug 2010 09:08:20 +0200 (CEST)

Hi!
 
I found a work around according to xotcl documentation.
 
Foo new [list -init $a]
 
I had also problems with -_values by parameters.
I often write class methods to create and init instances. (Smalltalk style).
Something like:
 
Foo proc createInstace {a} {
    set a [Foo new]
    $a set arg1 $a
    $a initme
    return $a
}

Artur
 
 

Kristoffer Lawson <setok_at_scred.com> hat am 4. August 2010 um 02:42 geschrieben:

> This is really bad news, guys...
>
> % package require XOTcl
> 1.6.2
> % namespace import xotcl::*
> % Class Foo
> ::Foo
> % Foo instproc init {a} {puts $a}
> % set a "-test"
> -test
> % Foo new $a
> ::xotcl::__#0: unable to dispatch method 'test' during '::xotcl::__#0 test'
>
> In other words: it is totally impossible to pass in a value beginning with "-"
> to an XOTcl constructor using the normal instantiation methods. This means
> absolutely anything where you don't know what is going to be passed beforehand
> is at a huge risk, as obviously any text can thus call random methods. That is
> without doing the whole process manually (ie. alloc, init). And you'd have to
> do it almost always, to be safe.
>
> Even if the usual Tcl "--" style was used, I still think that would not be
> enough, as practically speaking you'd have to use that every single time,
> making the code horribly ugly. It's just about acceptable for [switch], but
> not for a constructor, where people fully expect to be able to pass in any
> variable...
>
> Please tell me I'm dreaming (it's almost 4am here)
>
> --
> Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

Re: [Xotcl] full trace support for XOTcl methods/procs

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 05 Jan 2008 09:25:01 +0100

Kristoffer Lawson schrieb:
> I understand that requirement. That is why I am suggesting you use a
> combination of XOTcl filters and [trace]. It might be that even
> [trace] is enough, if it catches all Tcl command calls (I haven't
> looked at it). If not, have XOTcl filters for the XOTcl stuff and
> [trace] for the rest?
>

one can set enterstep calls on next

   proc CALL args {puts "CALL $args"}
   proc EXIT args {puts "EXIT $args"}
   trace add execution next enterstep CALL
   trace add execution next leavestep EXIT

and maybe add these two traces in the filter once on the first call (e.g.
controlled via a global variable).

Alternatively, one could define a "proc n args {next}", register the traces
on it and use in the filter "set r [n]" instead of "set r [next]". In
this case multiple
filter registrations are not a problem.

It is as well possible to register enterstep on the object/class names,
   trace add execution b1 enterstep CALL
   trace add execution b1 leavestep EXIT
but there you might get as well too much output.

-gustaf neumann
> / http://www.scred.com/
> / http://www.fishpool.com/~setok/
>
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

[Xotcl] broken web links, Tcl stubs

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: BRIAN THEADO <brian.theado_at_usa.net>
Date: 7 Jul 2001 11:08:09 EDT

Hello,

The links to the XOTcl mailing list and mailing list archive seem to be broken
on the page http://media.wu-wien.ac.at/doc/index.html. They seem I found the
link on the main XOTcl page to be O.K.

Also, I was wondering what the chances are that XOTcl be linked against the
Tcl stubs library instead of directly against the Tcl library. This gives the
freedom of using the same build of the extension with multiple versions of the
TCL interpreter. This would be especially nice for the windows distribution.
I don't have a build environment set up in Windows and the dll distributed on
the XOTcl web page requires exactly Tcl 8.3 and doesn't work for me with 8.4.

Thanks,
Brian Theado

____________________________________________________________________
Get free email and a permanent address at http://www.amexmail.com/?A=1

XOTcl/NX mailing list by object move?

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Mon, 20 Mar 2006 18:44:13 -0700

xotcl-bounces_at_alice.wu-wien.ac.at wrote on 03/20/2006 02:26:26 PM:

>
> On 20 Mar 2006, at 18:41, Scott Gargash wrote:
>
> > xotcl-bounces_at_alice.wu-wien.ac.at wrote on 03/20/2006 07:21:27 AM:
> >
> > There's some semantic relationship between the two accessors, so it
> > would be nice to have some overlap in their names. How about "my
> > varname" and "my methodname"?
> How about, to make it totally obvious, "my varNamespace" and "my
> methodNamespace"? Readability and clarity is generally more important
> in programming than cutting a few keystrokes off and at least that
> would be easy for anyone reading the code to decipher.

I agree with you about clarity vs. typing, but I'm still reluctant to entrench namespace. The fact
that it's in a namespace is implementation, and part of the utility of this is to encapsulate that
implementation. What's really happening is you're getting a valid external reference to a variable
or method.

Hmm... "my &var" and "my &method"? Or is it too C++? "my varref" and "my methodref"?

      Scott

[Xotcl] Re: Probable bug: no method calls with "next" & init

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Tue, 6 Feb 2001 00:51:59 +0200 (EET)

On Mon, 5 Feb 2001, Gustaf Neumann wrote:

> i have to admit, that i do not fully understand the problem.
> the following seems to satisfy your needs:
>
> the other approach is to make init more clever. i read a hint from
> your mail, that you want to have different constructors for different
> parameters ("overloading similar to c++"). What's wrong with a switch
> in init handling these cases:

Well this is exactly the approach I'm using. Just that I was slightly
surprised I couldn't control it with [next] by giving those
object parameters to it as I would when creating an ob. It's OK now that I
know that I can't do it. I can do it with other approaches quite easily
in my code. I just wanted to be sure it's not something that's intended
to work.

Btw. any ideas when 8.4 will be out? The bug with the destruction of
objects and error handling is causing some small headaches in the
debugging phase of code here. I really hate to pressure you like this, but
I need to be able to look forward to a bright future when I get into that
situation, so I can say "Oh, it'll be alright soon" when I stumble across
that situation. No panics though.

         - ---------- = = ---------//--+
         | / Kristoffer Lawson | www.fishpool.fi|.com
         +-> | setok_at_fishpool.com | - - --+------
             |-- Fishpool Creations Ltd - / |
             +-------- = - - - = --------- /~setok/

Re: [Xotcl] trace command

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Victor Mayevski <vitick_at_gmail.com>
Date: Thu, 23 Apr 2015 22:10:54 -0700

Hmm, for some reason the trace command did not work for me at first. I
tried it again and now it works (for the delete/destroy event). That's
basically what I needed.

On Thu, Apr 23, 2015 at 2:28 PM, Victor Mayevski <vitick_at_gmail.com> wrote:

> Hello Gustaf,
>
> Is it possible to use the TCL trace on NX objects/methods?
>
> Thanks
>

[Xotcl] XOTcl 1.5.0 available

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 14 Sep 2006 10:35:47 +0200

Dear XOTcl community,

I am pleased to announce the availability of XOTcl 1.5.0.
To sum up, the biggest change is the introduction of slots objects,
which generalize the handling of "parameters" and object class
relations (like e.g. mixins). Slots provide a general and extensible
interface for changing properties of objects and classes. Every
multi-valued slot has e.g. a "<slot> add ..." method to add values
like previously only possible for mixin and filters. Slots contain
as well support for partial and lazy initialization of objects
(important, when e.g. variables are initialized through costly SQL
commands).

Another important change is that it is now possible to attach
the predefined methods of xotcl to arbitrary objects/classes.
For example, the XOTcl class system is created on the C-level
completely without any methods, all methods are attached from
the script initializing XOTcl.

I would like to thank the XOTcl community for many fruitful
inputs and discussions, that contribute significantly to the
development of XOTcl.

Best regards

-gustaf neumann

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

Announcing XOTcl 1.5.0
*************************

Hi everybody. We are pleased to announce the availability of XOTcl 1.5.0.
Major changes relative to 1.4.0 are:

    * Improved Functionality

       + The C-level implementation of XOTcl creates now the basic
         classes ::xotcl::Object and ::xotcl::Class completely without
         any methods. All predefined methods are now registered from
         the initialization script-code (predefined.xotcl) via the new
         command
 
             ::xotcl::alias <class>|<obj> <methodName> \
                      ?-objscope? ?-per-object? <cmdName>

          which is used for registering predefined Tcl commands as
          methods. These aliases are like zero cost forwarders, since
          they lookup the function pointer from the commands and used
          these in the methods.

          This change makes it possible to register the same command
          on different classes (with maybe different names), such that
          for example the predefined set method of ::xotcl::Object can
          be replaced with a different method and the set method can
          be registered on some other classes (maybe some application
          classes).

          This change makes it as well quite easy to develop some
          other object oriented languages based on the XOTcl
          framework, since all methods can be rearrange from the Tcl
          layer .


       + Slots

          A slot is a meta-object that manages property-changes of
          objects. A property is either an attribute or a role of an
          relation.

          In a nutshell, a slot has among other attributes
            - a name (which it used to access it),
            - a domain (object or class on which it can be used) , and
            - can be multivalued or not

          Every slot defines a uniform interface to access its
          content. So has for example, every multivalued slot a
          method "add" to add a value to the list of values and a
          method "remove" to remove it again.

          We distinguish between system slots (predefined slots like
          class, superclass, mixin, instmixin, filter, instfilter) and
          application slots (e.g. attributes of classes).

         System Slots
         ========

         System slots are predefined slots defining e.g. some relations
         between classes, or between objects and classes.

         The predefined system slots are:
         - superclass: every class in XOTcl has one or more superclasses.
            The name of this slot is "superclass", the domain is
"::xotcl::Class",
            the slot is multivalued. One object might have multiple
superclasses.
         - class: every object has a class; therefore, the domain of the
slot
            is "::xotcl::Class", the property is not multivalued.
         - mixin: every object in XOTcl can have one or more mixin classes.
            The name of this slot is "mixin", the domain is
"::xotcl::Object", the slot is
            multivalued.
         - instmixin: same as above, but the domain is "::xotcl::Class"
         - filter, instfilter: similar to "mixin" and "instmixin"

         Every slot can be used set and query the property from its domain.
         The syntax for setting values is
           <object> <property> newValue
         and for getting its values is
           set x [<object> <property>]

         Every multivalued slot has as well a method "add" and "remove"

         Examples for using the system slot "mixin"

            Object o; Class M; class N
            o mixin ::M ;# replacing the per-object mixins of o
with M
            o mixin add ::N ;# add N to the front of the mixin list
            o mixin delete ::M ;# delete M from the mixin list
            puts [o mixin] ;# query the current mixin list
        
 
         Attribute Slots
         =========

         Attribute slots are used to manage the setting and querying
         of instance variables. We define now a person with three
         attributes,"name", "salary" and "projects".
   
           Class Person -slots {
             Attribute name
             Attribute salary -default 0
             Attribute projects -default {} -multivalued true
           }

         Examples for using the slots are

           Person p1 -name "Joe"
           p1 projects add project1

         Some additional features of the slots are:

          - Support for value checking for
               * primitive types (all types from "string is", like integer,
                  boolean, ...)
               * instances of Classes (e.g. value must be an instance
                  of Person)
               * custom value checkers
               * uniform interface for single and multi-valued slots

            - Support for lazy initialization (e.g. when costly
               commands (like SQL) are used to initialize instance
               variables, not all variables are used for each object)
        
             - more experimental low level functionality, like
               * initcmd (executed, whenever the variable is read the
first time)
               * valuecmd (executed, whenever the variable is read)
               * valuechangedcmd (executed, whenever the variable is
altered)
              
           For more details, see
http://media.wu-wien.ac.at/doc/tutorial.html#slots


       + Re-implementation of the method "parameter" based on slots.
           All forms except
               ... -parameter {name1 {name2 default2}} ...
           (I.e. pure accessor parameters and parameters with
           defaults) are deprecated, since slots are the much more
           powerful and orthogonal construct.

           The old c-based parameter support based on "parameterclass"
           is deprecated. It is still in the C-code (the method "parameter"
           is redefined in predefined.xotcl). If someone urgently needs
           it, please remove the parameter instproc from predefined
           for the time being, and write an email to me, in case
           you really need it). The C code for parameter will be removed
           in the next release.

       + Improved introspection though the procsearch method. This
           method reports now in its second argument not only
           [inst]proc but as well [inst]forward, [inst]parametercmd
           and [inst]cmd (the latter for methods implemented in C.

        * Improved introspection through "info"
           - new subcommand "info slots"
           - implemented backwards bug-compatible "info parameter",
              deprecated

       + Improved serializer
           - better handling of cyclical dependencies, when mixins are
involved
           - fix for namespace handling to make the XOTcl communication
              library classes working with the aolserver (thanks for
Stefan Sobernig
              for pointing this out)
           - Now other ::xotcl::* objects can be included in the
aolserver blueprint
              (e.g. non positional argument handlers)
           - handling of slot dependencies
           - more convenient calling of the serializer:
              Method "serialize" for Object is defined when the package
xotcl::serializer
              is loaded.

       + Improved forwarding commands
            - New option for the argument substitution. When the argument
               list of the forward command contains "%argclindex {a b
c}", then
               depending of the number of arguments at invocation "a", "b"
               or "c" is substituted. If more arguments are used at the
invocation
               of the forwarder than values are contained in the list
after %argclindex,
               an error is generated.
            - New options for forwarder:
               * The option -earlybinding can be used to look
                  up the function pointer of the called Tcl command at
                 definition time of the forwarder instead of invocation
time.
                 This option should only be used for calling
C-implemented Tcl commands)
               * The option -verbose prints the substituted command in
the forwarder
                  prior to invocation.

       + New snit-like utility functions:
            - ::xotcl::myvar varName: return the fully qualified
variable name
               of the specified variable.
            - ::xotcl::myproc methodName ?args?: call an xotcl method
without the need
               of using "[list [self] methodName ...]"
            Both commands are namespace exported

       + added "subst" to the set of Tcl imported methods (like e.g.
incr, append, ...)
          On can do now:
            % Object o
            ::o
            % o subst {I am [self]}
            I am ::o

       + added new method for ::xotcl::Object named "contains":
           This method is essentially a value added back-port
           of the OpenACS version. It allows to create a nested
           object structure with little syntactic overhead. See tutorial
           or language reference for more details.

     * Improved code quality:
       + fixed a bug with nonpositional arguments, some
           positional arguments and "args"
       + fixed a bug in nonpositional arguments when called without
           arguments
       + tested with Tcl 8.4.13 and 8.5a4
       + improved error messages in connection with nonpositional arguments
       + fixed a bug in the xotcl trace module (many thanks to jima for
reporting)
       + fixed a namespace bug in ::xotcl::package require in connection
with xotclide
           (many thanks to Bill Paulsen and Artur Trzewik for
identifying the problem and
           suggesting a fix)
       + improved documentation (e.g. new sections added,
           some sections deleted, spelling improved, in total 8 pages
longer)
       + fixed documentation bugs (many thanks for Kristoffer for reporting)
       + more regression tests added

 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

RE: Private methods (was [Xotcl] build problem on solaris)

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Wed, 28 Jul 2004 13:31:42 +0300 (EEST)

On Tue, 27 Jul 2004, Schofield, Bryan \(GE Transportation\) wrote:

> Here is a quick hack example showing how to privatize a method. The
> instproc "priv" simply registers a method name to be considered private.
> Then a filter checks to see if the a method being called from somewhere
> outside of the object has been registered; If so, it throws. There is a
> lot of refinement that could be done, but at least this shows how a
> filter could be used to provide levels of protection. Making variables
> private is a little trickier. That might require the overloading
> variable mutators like "set", "lappend", "append" & so on. But one could
> make all thoses method private and then you've essentially made all
> variable private. Then use "parameters" for publicly accessible data,
> which is probably better any way since you are not allowing outsiders to
> directly change a variable, but rather providing them an interface to
> get & set the value of some piece of data.

Would it be nice if there was something akin to filters, but for
variables? A bit like Tcl variable traces, but better (as they only get
triggered once the change has already been made :P).

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

Next Page