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

Weblog Page

Filtered by date 2017-01-02, 731 - 740 of 1541 Postings (all, summary)

[Xotcl] Non-pos arguments with args

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

From: Kurt Stoll <kstoll_at_echelon.com>
Date: Fri, 17 Feb 2006 08:24:04 -0800

 

I am having difficulty getting non-positional arguments to behave correctly
with args. The simple example below shows what I have found. This does not
appear to be appropriate behavior. Am I doing something wrong?

 

Object obj

obj proc pr1 { {-npos default} args } {

    puts "npos: $npos"

    puts "args: $args"

}

 

> ## This works:

> obj pr1 a

npos: default

args: a

>

> ## As does this:

> obj pr1 -npos 3 a

npos: 3

args: a

>

> ## But this does not:

> obj pr1 -npos 3

npos: 3

args: -npos 3

>

> ## I expected args to be {}, but instead it contains the non-positional
parameter

 

Thanks for any insight you can provide.

 

-Kurt Stoll

 

[Xotcl] Classes and namespace

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, 30 Jan 2001 00:54:05 +0200 (EET)

[~] package require XOTcl
0.83
[~] namespace eval Foo {
>Class MyClass
>MyClass instproc init {} {
>AnotherClass newChild
>}
>Class AnotherClass
>}
AnotherClass
[~] Foo::MyClass new
invalid command name "AnotherClass"
while evaluating {Foo::MyClass new}

Ie. it appears as if methods aren't run in the same namespace as
where classes exist (or a child namespace of this). I know this isn't
exactly a bug (as I don't think it's specified anywhere?), but I believe
the natural behaviour would be for AnotherClass to be found in the example
above, as it's specified within the same namespace as Foo.

Is the any chance the current behaviour could be altered to one that I
think is more intuitive? Or is there a good reason why not?


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

[Xotcl] Status of the bugs I reported/could people resend their replies to those bugs

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: Thu, 1 Apr 2004 19:37:56 -0800

Hi,

Last month I reported three bugs in the configure step of the xotcl
build process. While I was reporting those bugs and for a few days
after, I was working on my mail, and so turned off the list's replying
to me at first.

Is there a different way to report bugs? Could someone tell me the
status of these bugs? Would anyone like copies of the bug reports
sent to them?

Anyway, I got my mail working, but I discovered a problem in the
list as well... During the period I had replies from the list turned
off, I expected to see all my bug reports in the archive, but each
time I sent the next bug, I checked the archive, and only my last one
showed up. To make matters worse, someone else posted to the list
in March after I did, and his/her message replaced mine.

Could the archive be configured to only accept 5 messages? But if
that's the case, the behavior of replacing the last message doesn't
make much sense. Could there be a bug in the software? Maybe the
HD where the archives are kept is out of space?

If anyone replied to my reports, could you resend the replies just
to me, at jim_at_jam.sessionsnet.com?

-Jim

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

[Xotcl] Bug in filter processing?

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

From: Kristoffer Lawson <setok_at_scred.com>
Date: Sun, 29 Aug 2010 04:02:04 +0300

Take a look at this code:

package require XOTcl 1.6
namespace import xotcl::*

Class Foo

Foo instproc hello {} {
    puts hello
}

Foo instproc myfilter {args} {
    puts "\nme: [self]"
    ::set targetclass [my info class]
    puts "targetclass: $targetclass"
    puts "calledproc: [self calledproc]"
    ::set r [next]
    puts "back from next"
    puts "paramcmds: [$targetclass info instparametercmd]"
}

Foo instfilter myfilter

Foo ob
ob hello
ob foo


So first I have a filter installed which does nothing but print some information, and checks something using the [info] method afterwards. I call an instantiated object with [hello] (an existing method) and again with [foo] (a non-existing method). The latter is when things get interesting. Check the output:


me: ::ob
targetclass: ::Foo
calledproc: configure
back from next
paramcmds:

me: ::ob
targetclass: ::Foo
calledproc: init
back from next
paramcmds:

me: ::ob
targetclass: ::Foo
calledproc: hello
hello
back from next
paramcmds:

me: ::ob
targetclass: ::Foo
calledproc: foo
back from next

me: ::alloc
::alloc: unable to dispatch method 'info'
    while executing
"my info class"
    (procedure "cleanup" line 4)
    ::alloc ::Foo->myfilter
    ::Foo ::xotcl::Class->recreate
    ::Foo ::xotcl::Class->create
    ::Foo ::xotcl::Class->unknown
    ::Foo ::xotcl::Class->create
    ::Foo ::xotcl::Class->unknown
    ::Foo ::xotcl::Class->create
    ::Foo ::xotcl::Class->unknown
    invoked from within
"$targetclass info instparametercmd"
    (procedure "foo" line 9)
    ::ob ::Foo->myfilter
    invoked from within
"ob foo"
    (file "filtertest.tcl" line 24)

me: ::alloc
targetclass: ::Foo
calledproc: destroy
back from next
paramcmds:

me: ::info
targetclass: ::Foo
calledproc: destroy
back from next
paramcmds:

me: ::ob
targetclass: ::Foo
calledproc: destroy
back from next
paramcmds:

...
So while the [hello] method works as expected, things get totally weird for [foo]. The first thing we notice is that it doesn't jump out at [next] (which should give an error as it does not exist). It continue execution of the filter after [next]. This may or may not be intended, I don't know. The documentation is not clear on this.

More interesting still, we end up with a totally unexpected error. The thing I believe is happening is that, for some reason or other [$targetclass info instparametercmd] is not ending up calling [info] for $targetClass, but creating an object called ::info (and thus overriding the original Tcl command). How [alloc] gets involved in the filter chain too, I am not sure. My guess is that the "unknown method" that resulted from [foo] is being interpreted by the XOTcl $targetclass C implementation as an error that occurred there, and that a new instance called "info" or possibly "alloc" should be created.

This causes major havoc as soon as an unknown method is called. Does the filter code look correct?

This happens with 1.6.2. I had a quick look at CHANGES for later versions and while there was some mention of memory leaks in [info] I wasn't sure if there was anything that would have fixed this.

Any ideas?

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

XOTcl/NX mailing list by object move?

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

From: Koen Danckaert <koen_at_retarget.com>
Date: Mon, 27 Mar 2006 18:33:04 +0200

> haveing listed these options, "::xotcl::mycmd" looks reasonale
> to me, since it constructs a tcl command and avoids the "[self]"
> in a similar way as "::xotcl::my".

I agree with this. "myvar" and "mymethod" are at the same level as "my", which has the advantage that there is a clear semantical distinction from "my". E.g. an easy explanation in a tutorial would be:

"my foo args" calls a method on the current object, "mycmd foo args" constructs the same command as a list but does not execute it.

This is more difficult to explain for the methodname variant, since it is clear that "my cmd foo args" actually _does_ execute a method.

The argument that "myvar/mycmd" can only be used for the current object, also holds for "my". In that case you have to use the non-shorthand notation.

Concerning the choice between myproc/mymethod/mycmd/mycode/... that I'll leave up to Gustaf ;-)

Koen

Re: [Xotcl] ensemble alias

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

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Thu, 05 Jan 2012 23:22:28 +0100

Victor,

> Is it possible to have an alias to ensemble or multi-word commands?

Well, namespace ensembles are straight forward; you may find out the
ensembled Tcl commands using e.g. [namespace ensemble configure string
-map] and then use the fully-qualified command names as alias target:

package req nx::test

Object create o {
   :public alias stringLength ::tcl::string::length
}

? {o stringLength "xyz"} [string length "xyz"]

If you don't have an ensemble command at hand (e.g., the [string is]
classes such as "integer", "boolean"), you want to bind in terms of a
method, consider a forwarder:

o public forward stringIsBoolean string is boolean

? {o stringIsBoolean "false"} [string is boolean "false"]

A forwarder is needed, because the "boolean" selector does not map to a
Tcl command, rather is an argument to a paramteric Tcl command
(::tcl::string::is).

A mixed alternative would be ...

o public alias stringIs ::tcl::string::is
o public forward stringIsBoolean2 %self stringIs boolean

? {o stringIsBoolean2 "false"} [string is boolean "false"]

//stefan

Re: [Xotcl] Help with Filters. Resubmission.

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

From: Sheik Yussuff <sheik_at_carib-link.net>
Date: Mon, 17 Dec 2001 16:39:04 -0400

Sorry guys. The problem as described was with ver 0.85.
Version 0.91 now behaves as Uwe explained!!
For ver 0.85, the behaviour as originally described (my problem) fits
with the reply from Rick Hedin.
Things seems to have changed from ver 0.85 to 0.91 with regards to filters
- now instfilters. I prefer the previous behaviour, if I am correct with in
my
conception, of course.
Thanks for your help.
--sheik

----- Original Message -----
From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
To: <Xotcl_at_alice.wu-wien.ac.at>
Sent: Monday, December 17, 2001 12:40 PM
Subject: Re: [Xotcl] Help with Filters. Resubmission.


> The problem below is that a filter (like a mixin) is only called if a
method
> to be dispatched exists for an object ... maa does not exist for A's
objects,
> therefore, the filter is not called, but unknown is called. The standard
> unknown raises the error here. You can test this by adding a custom
unknown
> to A (of course you can also handle the delegation in unknown):
>
> A instproc unknown args {
> puts "unknown $args --> error"
> next
> }
>
>
> On Saturday 15 December 2001 16:28, Sheik Yussuff wrote:
> > Below is nonsensical sample code to illustrate a problem I
> > am having with filters. On invocation of:
> > a mb (see code section below)
> > 1. Object a is sent the message mb(not an instproc) of A
> > 2. Filter af of object a intercepts and
> > dispatches message mbb to object b
> > 3. Filter bf of object b intercepts and
> > redispatches message maa to object a
> > This time the filter af does not intercept message maa!!
> > The message maa is sent directly to object a with
> > the resulting error: object a unable to dispatch
> > method maa.
> >
> > Can anyone assist me in explaining what is happening here?
> > ------------------------------------------------------------
> > #Code: Win 98 version 0.91; got same problem with ver 0.85 3 months ago.
> >
> > Class A -parameter {delegate}
> >
> > A instproc af args {
> > set method [self calledproc]
> > if {[[self] exists delegate]} {
> > set del [[self] set delegate]
> > if {$method == "maa"} {
> > return [eval $del mbb]
> > }
> > if {$method != "ma"} {
> > return [eval $del $method $args]
> > }
> > }
> > next
> > }
> >
> > A instfilter {af}
> >
> > A instproc ma args {
> > puts "method ma of A"
> > }
> >
> >
> > Class B
> > B instproc bf args {
> > set sender [self callingobject]
> > set method [self calledproc]
> > puts "method is: $method"
> > if {$method == "mb"} {
> >
> > return [eval $sender maa]
> > }
> > next
> > }
> >
> > B instfilter bf
> >
> > B instproc mb args {
> > puts "method mb of B"
> > }
> >
> > B instproc mbb args {
> > puts "method mbb of B"
> > }
> >
> > B b
> > A a
> > a delegate b
> > #a ma ; #works ok
> > a mb
> >
> >
> >
> > _______________________________________________
> > Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> > http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>
> --
> Uwe Zdun
> Institute for Computer Science, University of Essen
> Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
> zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_uni-essen.de
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

XOTcl/NX mailing list by object move?

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, 18 Mar 2006 21:39:35 +0100

Scott Gargash schrieb:
>
> xotcl-bounces_at_alice.wu-wien.ac.at wrote on 03/18/2006 01:45:12 AM:
>
> >
> > On 18 Mar 2006, at 02:48, Gustaf Neumann wrote:
> >
> > > so, now we can test the aliased content. it behaves in many respects
> > > the same, but when it comes to refer to "self" or to namespaces
> > > one would notice a different behavior:
> >
> > Could this kind of system be used throughout XOTcl and thus have
> > [self] return the alias too, instead of the actual instance? As
> > mentioned, this could potentially solve the issue with object movement.
>
try it out, make up your mind. As shown, a few lines of code can already
implement most of the work,
"self" can be reimplemented in tcl as well with little effort to return
the (or one of the) aliases.
the xotcl regression test is already a good benchmark and testing base.
>
>
> I was wondering the same thing. What would be the impact on XOTcl's
> implementation if an object's location in Tcl's namespace hierachy was
> invariant, and user access to the object was always indirected through
> an alias? I would guess that it's not worthwhile just for "move"
> functionality, but would this guarantee make any other things
> possible, easier, or more efficient?
>
I do not see much evidence of a speed increase when adding a layer of
indirection for every object access.

if the goal of such a project is "everything should be the same as in
xotcl now, but move should be faster",
then i would estimate a man-month of work of somebody with some
tcl/xotcl c-level experience (like uwe or me).
without looking into the details, i would expect problems from
instrospection (including call stack),
namespace handling (namespace import/exports, namespace completion),
dynamic aggregation
(creation, cleanup, semantics, when e.g. an alias is moved), and most
probably many more hurldes
will show up when going into the details. In general, it is possible to
have multiple aliases (references) pointing
to a physical object, in some cases you are interested in the namespace
of the reference(s), in others in the
namespace of the object.

alltogether, it is certainly an interesting exercise considering such a
strucure in general (therefore
i wrote the simple example). However, one could go much further:
Thinking loudly:
Since xotcl objects/classes are tcl_objs pointing to a c-structure
representing the object/classes in c,
and the tcl_objs are refcounted refcounted, i would think there could be
ways achieving the flexibiliy
even without indirection. Currently, these tcl_objs are bound to a
single tcl-command. The aliasing
effect could be achived in theory by using these tcl_objs in multiple
tcl commands. I would
expect some deeper changes here: what happens, if a child object is
added under one name of
the object; will this be visible for another name of the same object as
well? If we continue to
see an object as a object tree, it should. i expect here the same
problems with namespaces as
indicated earlier with the namespace rename command.

-gustaf neumann

>
> Scott
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

Re: [Xotcl] psnm - aufgabe 1c

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

From: Irene Fellner <irene_at_fellner.at>
Date: Thu, 7 Nov 2002 20:33:19 +0100

hallo,

ja das mit dem sortieren ist mir auch aufgefallen, man kanns aber dann auch beim methodenaufruf machen:
lsort[lunique $liste]

bei aufgabe2 (tcl arrays) wurde auch nicht die teil-aufgabe gelöst: geben sie alle worte am bildschirm mit anzahl der vorkommnisse aus.
es ist zwar kein problem, alle worte am bildschirm auszugeben, aber dass dazu auch noch jeweils gezählt wird, wie oft das wort insges. vorkommt, habe ich nicht geschafft.

falls also jemand eine lösung dazu hat, wärs nett, sie hier zu veröffentlichen :-)

grüsse
irene
  ----- Original Message -----
  From: Arthur Fleischmann
  To: xotcl_at_alice.wu-wien.ac.at
  Sent: Thursday, November 07, 2002 7:56 PM
  Subject: Re: [Xotcl] psnm - aufgabe 1c


  Hi Irene + alle anderen,

  Mir ist bei diesem Bspl aufgefallen, daß die Liste nicht - wie in der Angabe verlangt - sortiert wird. Man müßte also in der Methode lunique statt return $resultat beispielsweise return [lsort $result] einfügen.

  if $memberArray($elt) {.....} bedeutet wohl, so wie Ferdinand geschrieben hat, wenn die Variable "true" ist (also einen Wert anders als 0 hat)

  Deine Lösung funktioniert auch!

  ----- Original Message -----
    From: Irene Fellner
    To: xotcl_at_alice.wu-wien.ac.at
    Sent: Thursday, November 07, 2002 4:56 PM
    Subject: Re: [Xotcl] psnm - aufgabe 1c


    hi,

    danke für die antwort, die bedingung ist hier also dass $elt true (1 ist), oder?

    ich frage mich nur, ob man die methode lunique nicht viel einfacher lösen könnte mit:
    proc lunique l {
     foreach elt $l {
        set memberArray($elt) 1
    }
    return [array names memberArray]
    }

    sie bringt bei mir auf jeden fall das gleiche ergebnis, und ist kürzer und verständlicher ....

    lg
    irene
      ----- Original Message -----
      From: Ferdinand Eckert
      To: Irene Fellner
      Sent: Thursday, November 07, 2002 4:42 PM
      Subject: Re: [Xotcl] psnm - aufgabe 1c


      hi,

      genau weiß ich's leider nicht (hatte leider noch keine zeit zu lernen), aber ich würde folgendes vermuten:

      die bedingung ist der term "$memberArray($elt)"
      nachdem eine bedingung immer "true" oder "false" (bzw. 0 oder 1 ist !!!)
      wird hier der wert von memberArray and der stelle $elt abgefragt (und als true/false interpretiert)
      --> ist dieser 0 --> false
      --> ist er != 0 --> true

      zumindest in C ist es so, wenn ich mich richtig erinnere ;-)

      lg Ferdinand


      Irene Fellner wrote:

        hallo,

        bin grad am üben für den test nächste woche :-)
        die lösung von aufgabe 1c (liste - jedes wort nur einmal) versteh ich nicht ganz.
        dh insbesondere folgenden teil der methode lunique:
        foreach elt $l {
        if $memberArray($elt) {
        lappend result $elt
        set memberArray($elt) 0
        }

        ganz konkret kapier ich die if-methode nicht - hier fehlt doch die bedingung oder??
        vielleicht kennt sich ja jemand aus, und kann mir es erklären ...

        danke,
        lg
        irene

RE: [Xotcl] Filters on classes

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

From: Schofield, Bryan \(GE Transportation\) <"Schofield,>
Date: Mon, 15 Nov 2004 10:54:52 -0500

hmm.. I just tried this with Gustaf's 1.3.3 version and it works for me... Give this a try and see if this works for you:
  http://media.wu-wien.ac.at/download/xotcl-1.3.3.tar.gz
It's pre-release build that I've been testing for several weeks now that has some bug fixes in it.
-- bryan


> -----Original Message-----
> From: xotcl-bounces_at_alice.wu-wien.ac.at
> [mailto:xotcl-bounces_at_alice.wu-wien.ac.at]On Behalf Of
> MichaelL_at_frogware.com
> Sent: Monday, November 15, 2004 10:33 AM
> To: xotcl_at_alice.wu-wien.ac.at
> Subject: [Xotcl] Filters on classes
>
>
> I'm using XOTcl 1.3.1.
>
> This code:
>
> Object instproc someFilter {args} {
> puts "self class = [self class]"
> puts "self called class = [self calledclass]"
> puts "self = [self]"
> puts "self calledproc = [self calledproc]"
> puts "args = $args"
> puts ""
> next
> }
>
> Class TestA -parameter {{x 0}}
> TestA filter someFilter
>
> TestA a
> a x
> a x 10
>
> produces this output:
>
> self class = ::xotcl::Object
> self called class =
> self = ::TestA
> self calledproc = a
> args =
>
> self class = ::xotcl::Object
> self called class = ::xotcl::Class
> self = ::TestA
> self calledproc = unknown
> args = a
>
> self class = ::xotcl::Object
> self called class = ::xotcl::Class
> self = ::TestA
> self calledproc = create
> args = a
>
> self class = ::xotcl::Object
> self called class = ::xotcl::Class
> self = ::TestA
> self calledproc = alloc
> args = a
>
> invalid command name "a"
>
> Note that filtering on "TestA a" seems to prevent the
> creation of an obj
> named "a". Any ideas?
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

Next Page