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

Weblog Page

Filtered by date 2017-01-02, 791 - 800 of 1541 Postings (all, summary)

[Xotcl] How do I get a parameters default-value?

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

From: Murr, Florian <florian.murr_at_siemens.com>
Date: Tue, 18 Jul 2006 14:40:52 +0200

    package require XOTcl
    namespace import xotcl::*

    # Let's say, I got:

    Class X -parameter {
        {p1 val1A}
    }
    X create x1 -p1 x1val1

    # ...

    # Now I change the default-values
    X parameter {
        {p1 val1B}
    }
    X create x2 -p1 x2val1

    # How do I get the current default-value 'val1B' for p1?
    # Note 'X info parameter' is no option, since after:

    X parameter {}
    puts "X parameter = [X info parameter]"
    X create x3
    puts "x3 p1 --> [::x3 p1]" ;# still works.

    # So the default-values are remembered somewhere!
    # My guess was somewhere around '::xotcl::Class::Parameter', but I
just
    # could not find, where? - and how to access them?
    #
    # Somehow there must be a better way to access the current
default-values
    # then via some newly created dummy object?!
    
    # (May be even the "old" default-values 'val1A, val2A' (for ::x1)
are still remembered somewhere?)
    #
    # regards,
    # - Florian

[Xotcl] Missing Linux Binaries

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

From: <MichaelL_at_frogware.com>
Date: Mon, 20 Sep 2004 11:33:11 -0400

The XOTcl 1.3.1 Linux binary distribution file
(xotcl-1.3.1-bin-linux-i686-glibc.tar.gz) is missing

        libxotclexpat1.3.so
        libxotclgdbm1.3.so
        libxotclsdbm1.3.so

all of which were present in (at least) the 1.2 and 1.1.1 files (in the
appropriate version, of course).

Re: [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 17:52:48 +0300

On 29 Aug 2010, at 15:09, Gustaf Neumann wrote:

> ... forgot to mention:
> You have to return the result of "next" as return of the filter (in the case of your example $r).

Yeah, I do that in my actual code which runs into the bug. Forgot it from the clip I posted here.

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

[Xotcl] Missing introspection methods for class methods

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

From: Arthur Schreiber <schreiber.arthur_at_googlemail.com>
Date: Fri, 25 May 2012 11:28:57 +0200

Hello Gustaf,

as far as I can see, nx is currently missing any methods to introspect
class level methods. (I know there is info lookup, but that's not exactly
what I want to do).

Also, as classes can be treated as objects, it's confusing that that
calling `MyClass info methods` returns the instance methods of the class,
whereas `$my_object info methods` returns the objects callable methods.

Thus, I propose the following changes to bring these two in line:

 * `info methods` should return the callable methods of an object, no
matter whether it is a class or an object instance.
 * `info methods -self` should return the callable methods defined in this
object, no matter whether it is a class or an object instance. This should
not include inherited methods. So for objects, this would only return
methods defined on that object directly, and for classes, this would only
return class methods directly defined on it.
 * `info method $subcmd $method` should work as in the current
implementation for objects, but when called on a class, it should not
target its instance methods but only directly callable methods.

Only for classes (and mixins):

 * `info instance_methods` should return all instance methods defined in
the class/mixin and it's ancestors.
 * `info instance_methods -self` should return all instance methods defined
in the class/mixin.
 * `info instance_method $subcmd $method` should work as `info method`, but
for instance methods of the class/mixin and it's ancestors.

What's your opinion on this?

Kind regards,
Arthur

Re: [Xotcl] parameters vs slots and use of "-initcmd"

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

From: Artur Trzewik <mail_at_xdobry.de>
Date: Tue, 03 Jul 2007 21:56:16 +0100

> After spending few weeks in understanding the basic concepts of the
> language, I decided to use it to model one component of the software I'm
> developing as part of my PhD project (basically, configuration of
> complex digital hardware macrocells). I've been attracted by XOTcl due
> to its "aspect oriented" features which are today very common in the
> hardware design industry.
>
> I need some clarifications regarding the use of Class parameters and
> Class slots (I will refer to v.1.5.2 of the XOTcl tutorial).
> Parameters are used throughout the introduction of the tutorial to model
> Class attributes, then slots are introduced in a later section. Are
> slots and parameters actually the same thing? Is there some reason to
> prefer one over the other?
>
>
In early version of XOTcl perameter are just a clever shortcut for method
Definition
Class A -paramter a

has leaded to method

# setter and getter in one method
# something like this
A instproc a {args} {
        if {[llength $args]==0} {
            my set a
       } else {
             my set a [lindex $args 0]
       }
}

It was pure XOTcl and also visible per info instbody.
Now parameters are C-coded and probably faster.
But it could be better to use old fashioned getter and setter methods, which
are well known from Java and Smalltalk.
(in Smalltalk all instance variables are private.)
Using only method for accessing objects has some advantages (It is more
OOP method=message).

A instproc getA {
     my set a
}
A instproc setA value {
    my set a $value
}

Methods could be better managed and intercepted per mixins or inheritance.
I use XOTcl parameters almost only for true value objects, where I do not
need any control about accessing them.
Parameters are only syntactic sugar but you do not need to use it.

Artur

Re: [Xotcl] updated patch for xotcl 1.3.3

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: Wed, 1 Dec 2004 00:15:31 +0100

On Tuesday 30 November 2004 21:46, Jeff Hobbs wrote:
> I have updated my patch from yesterday. This has been tested
> across a much more elaborate set of platforms. My guess is
> that xotcl has not been compiled against anything but gcc, or
> installed on non-linux systems.

 unfortunately, we de not have a wide range of machines
 available. Our normal testing cycle starts with development
 under linux/gcc, then test under win with visual cc, for most
 releases zoran tests under sun with purify.

> This patch builds and installs on the following variants:
>
> * Windows-x86 (cygwin/MSVC build)
> * Linux-x86 and x86_64 (gcc)
> * HP-UX 11 pa-risc (gcc and cc)
> * HP-UX 11 ia64 (cc)
> * AIX 4.3.3 (xlc)
> * Solaris 2.8 (gcc and cc)

 great. many thanks.

> test-core fails on HP-UX 11 pa-risc with:
>
> FAILED: FAILED - UpLevel Test 2
> Got: ::o
> Expected: ::s
> 0 g='::o' e='::s'
> make: *** [test-core] Error 255

 was this with gcc or cc? Is it possible to get a guest account
 for the hpux machine?

> and on some other platforms it can fail on exit (bad cleanup?),
> but this gets things a lot further.
>
> I don't think the ALLOC checks are being done properly, as I
> said before - there is too much expectation that gcc-isms can
> be the default, which isn't correct, IMO.

 i have changed the logic to use the gcc-ism only when gcc is
 used, and nobody explicitely stated to use alloca or malloc.
 
> Part of this patch is the for loop break fix in xotcl.c that
> I mentioned in my last message - that seems to have no effect
> on the test-core for the platforms.
>
> It's probably best to just take this patch directly and call
> it xotcl-1.3.4, unless you want to further clean up based on
> my other suggestions (like ALLOC stuff).

 We will do so,
-gustaf
-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik und Neue Medien
Wirtschaftsuniversität Wien, Augasse 2-6, 1090 Wien

[Xotcl] Re: XOTcl 0.83 questions (bugs?)

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

From: Gustaf Neumann <Gustaf.Neumann_at_wu-wien.ac.at>
Date: Mon, 20 Nov 2000 13:54:58 +0100 (CET)

>>>>> "Zoran" == Zoran Vasiljevic <zoran_at_munich.com> writes:

Zoran> Hi Uwe and Gustaf !
Zoran> This is one of the first messages in sequence, you're going
Zoran> to receive from me. I'm sorry for (eventual) inconvenience
Zoran> but I have to master this great package and there is nobody
Zoran> else to ask !

Dear Zoran,

many thanks for your feedback. i am pretty sure, uwe is currently
preparing an email concerning the assertion issues.... so i all
address the later issues.

Zoran> subject. Also, need some examples for "parameterclass".
Zoran> Reference mentions it but the tutorial is silent abut it ???
Zoran> Have any working code which uses them ?

The basic idea is to make the parameter mechanism in a similar way
extensible as the extension mechanisms work for normal oo-methods. One
can extend the predefined Class::Parameters class with someInstproc
and use later

    C c1 {{a -default 1 -someInstproc x} ...}

or subclcass it like

    Class MyParameters -superclass Class::Parameters
    Class X -parameterclass MyParameters -parameters ......
The parameter classes are still in an early state, we are not happy
about the need to specify -parameterclass for interesting cases, and
we hope to find more elegant ways to express these semantics. Here is
an simple example for illustration:

===========================================================================
Class::Parameter instproc comments {param args} {
  puts "[self] [self class] parameter: $param args: $args"
}
Class::Parameter instproc values {param args} {
  set ci [[self class] info instinvar]
  set valueTest {}
  foreach a $args {
    lappend valueTest "\[\[self\] set $param\] == [list $a]"
  }
  lappend ci [join $valueTest " || "]
  [self] instinvar $ci
}
 
Class X -parameter {
  {a 1 2 3 -comments a b c d e}
  {b -default 2 -comments 1 2 3 4}
  {e -default 3 -values 1 2 3}
  {Self -default [self]}
}
X instproc checkInvar {} {
  [self] check instinvar
  [self] set e 9
}
X x -checkInvar

 
Class C -superclass {Class::Parameter Class}
C instproc comments {param args} {
  puts "[self] [self class] parameter: $param args: $args"
  next
}
Class Y -superclass X -parameterclass C -parameter {
    {a 1 2 3 -comments a b c d e}
    {b -default 2 -comments 1 2 3 4}
    {e -default 3 -values 1 2 3}
    {Self -default [self]}
}
Y y -checkInvar
===========================================================================

Zoran> What the heck is the "_at_" good for ???
Zoran> I notice such constructs in your code pretty often...

Zoran> Class SomeClass
Zoran> _at_ @File {description {
Zoran> This is a file which provides a blablablabla....
Zoran> }
Zoran> }

Zoran> What does this mean ?

the _at_ is used for documentation issues: check out
xotcl/doc/langRef.xotcl for the largest example. The basic ideas
behind xoDoc are:

  - the comments are first class xotcl commands; by defining
    alternate _at_ commands (e.g. via per object mixins etc),
    one can do different things with the comments;
    currently, we have only the HTML backend, but the basic idea is to
    provide support for several other usages as well (e.g. XML, RDF,
    online help, documentation of dynamic structures, etc).
 
  - We have an Object "_at_" that handles comments via
    its unknown method. xoDoc adds the appropriate instprocs to _at_
    to produce HTML output. The appropriate command is:
      xotclsh src/lib/makeDoc.xotcl <DOCDIR> <DOCFILES>
 
  - The source of a documentation is structurally very similar to
    the xotcl constructs being commented. e.g. one can copy an
    instproc and add comments at the right places. eg.
 
    Class C
    C instproc m {a1 a2} {
       return [expr {$a1+$a2}]
    }
 
    can be commented as follows
 
    _at_ Class C { description { "my sample class"} }
    _at_ C instproc m {a1 "first number" a2 "second number"} {
       description "add two numbers"
       return "sum of a1 and a2"
    }
 
   One can do essentially a copy+paste of the source and add
   the comments via attribute value pairs, every basic language
   construct can have a "description". If you want to include
   other properties to the description, you can add e.g.

    _at_ C instproc m {a1 "first number" a2 "second number"} {
       author "GN+UZ"
       date "Feb 31"
       description "add two numbers"
       return "sum of a1 and a2"
    }
 
    This way, author and date are added automatically to the generated
    HTML file.
    
    In addition, there is a _at_File hook for a per file description.

Zoran> Cheer's (and thanks for help!)
Zoran> Zoran

Hope this helps
-gustaf

Zoran> ______________________________________________
Zoran> FREE Personalized Email at Mail.com
Zoran> Sign up at http://www.mail.com/?sr=signup

Re: [Xotcl] info method behaviour

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: Mon, 13 Aug 2001 15:40:03 +0200

On Saturday 11 August 2001 00:00, Kristoffer Lawson wrote:
> Situation:
>
> I create a class "C" with instproc "foo".
> An object is created from C called "ob".
>
> Problem:
>
> The commands "ob info procs", "ob info args" and "ob info body" do not
> work as I would expect them to. In particular, there doesn't seem to be a
> way of finding out the body and arguments for the instproc "foo" from the
> object. I could do this by asking the class, but I specifically would
> like a uniform way to do this, without caring whether the methods are
> inherited or not. Is this intended? Why?

 Much of the answers have been said already.

 The right way to query instprocs is via "info instargs" and
 "info instbody" rather than "info args" and "info body" or
 the tcl counterparts...

===================================================
> Class C
::C
> C instproc foo {a b c} {puts foo}
> C c1
::c1
> C info instprocs
foo
> C info instargs foo
a b c
> C info instbody foo
puts foo
====================================================

 on our todo-list for 0.85 we have an issue for returning
 names of procs/instprocs/mixins/filters etc. in a consistent
 way, that also effects procsearch. This becomes neccessary
 for [self next], which lets a user query, what will be
 called next (filter, mixin, proc, instproc).

 in the best of all possible worlds, we treat whatever comes
 back fron the query an an object which has an orthogonal
 query interface for instrospection. speedwise an object
 is rather heavyweight, so we think about list notations
 as well. OTH, we the xotcl-objects are not necessarily
 tcl-based, these can be c-based as well (we have a mostly
 working SWIG bindig for xotcl), therefore the speed penalty
 wont be large....

 greeting
 -gustaf
PS: hopefully, i can put 0.85.3 this evening on the server.

[Xotcl] Re: performance

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

From: Gustaf Neumann <Gustaf.Neumann_at_wu-wien.ac.at>
Date: Tue, 13 Feb 2001 16:02:24 +0100 (CET)

>>>>> "KL" == Kristoffer Lawson <setok_at_fishpool.com> writes:
KL> Just for interest I implemented one of the OO tests from Doug's shootout
KL> (http://www.bagley.org/~doug/shootout/) in XOTcl to see how it would
KL> fare. Specifically it was the method call speed test
KL> (http://www.bagley.org/~doug/shootout/bench/methcall/). I have attached my
KL> code to this email.

KL> According to my own tests, it didn't do terribly well, but it's difficult
KL> to say whether this is a limitation of Tcl (which doesn't do very well in
KL> several of those speed tests) or just a sign that there might be some room
KL> for optimisation in XOTcl itself. Now what would be interesting would
KL> be a comparison with iTcl -- but as I don't know it I'll leave that for
KL> someone else. Any comments?

 Dear Kristoffer,

 this test is not a very good test for xotcl, but one should not
 complain about other people's benchmarks.

 Our forthcoming version will have some significant performance
 improvements (which will be for this example in the range of 5-10%,
 for other examples we have seen up to 50%). Some of the changes were
 over-aggressive, we might have to take some of these back.

 however, i tried the example of yours in itcl, and the result was
 about 30% slower than the current development version of xotcl. i am
 not an itcl expert, so i would not wonder, if if have done something
 wrong, of if someone else get some better figures by using
 a different implementation.

 best regards
-gustaf

=============================================================================
class Toggle {
  variable state
  constructor startState {
    set state $startState
  }
  method value {} {
    return $state
  }
  method activate {} {
    set state [expr {! $state}]
    return $this
  }
}


class NthToggle {
  inherit Toggle
  variable counter
  variable countMax
  
  constructor {startState maxCounter} {
    Toggle::constructor $startState
  } {
    set countMax $maxCounter
    set counter 0
  }
  method activate {} {
    incr counter
    if {$counter >= $countMax} {
      set state [expr {! $state}]
      set counter 0
    }
    return $this
  }
}

proc main {} {
  global argv

  set n [lindex $argv 0]
  set val 1
  set toggle [Toggle t $val]

  for {set i 0} {$i < $n} {incr i} {
    set val [[$toggle activate] value]
  }
  if {$val} {
    puts "true"
  } else {
    puts "false"
  }

  set val 1
  set ntoggle [NthToggle nt 1 3]
  for {set i 0} {$i < $n} {incr i} {
    set val [[$toggle activate] value]
  }
  if {$val} {
    puts "true"
  } else {
    puts "false"
  }
}

main

Re: [Xotcl] Incorrect behavior?

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

From: Victor Mayevski <vitick_at_gmail.com>
Date: Wed, 29 Jun 2011 21:27:27 -0700

Thank you Gustaf for detailed explanation. My primary reason for using
attributes and such is to reduce verbosity in my code. I like clean,
short and simple code. With XOTcl/NX it is often a trade off between
flexibility/power and simplicity. So, I am trying to find that middle
ground. :) I will probably end up eventually rewriting my code to use
TCL variables, but it is good enough for now.

Thanks again,

Victor

On Wed, Jun 29, 2011 at 12:11 PM, Gustaf Neumann <neumann_at_wu.ac.at> wrote:
> Dear Victor,
>
> an attribute and an instance variable are two different things with
> potentially different life-times.
>
> - The attribute provides information about instance variables
>   and their properties (such as e.g. default values, which are
>   used when variables are to be created, or methods to access
>   the variable, etc.).
> - The instance variables keep the actual value, they can be
>  independently set and unset by standard Tcl commands.
>
> Therefore, changing the default value of an attribute does not change its
> actual value.
> The same holds for class-level attributes and object-level attributes.
>
> See e.g.
> ========================
> % Object create o {set :a 1}
> ::o
> %  o attribute {a oldvalue}
> ::o::a
> % o a
> 1
> ========================
>
> However, in some respects the object-level attributes are different from the
> class level attributes: In contrary to the class-level attributes, the
> object-level attributes check at definition time of the attribute, if an
> according instance variable exists. If not, it creates the instance variable
> with the default value. Probably therefore, you assumed, that the provided
> value is used to set always the instance variable (maybe influenced by Tcl's
> "variable" command).
>
> Since the attribute and the instance variable have different life-times,
> deleting the attribute does the fuzz with the the instance variable. Note
> that after deleting the attribute, the instance variable still exists (see
> last command below).
> ====================================
> % Object create o {:attribute {x 1}}
> ::o::per-object-slot::x init methodname=x
> ::o
> % o eval {set :x}
> 1
> % o x
> 1
> %  o delete attribute x
> % o x
> ::o: unable to dispatch method 'x'
>    while executing
> "o x"
> % o eval {set :x}
> 1
> ====================================
>
> Note, that the same holds as well for class-level attributes (changing
> default values, deleting attributes in class level attributes does not
> effect the variables in already created instances).
>
> One can certainly argue, that the behavior for object-level and class-level
> attributes does not have to be the same, and that e.g. the life-time of
> object-level attributes and instance variables should be stronger tied
> together (defining a object-level attribute should immediately
> create/overwrite instance variables, altering the default should change its
> value, deleting object-level attributes should remove the variables, etc.).
>
> One could define currently mixins that could achieve this strong binding.
> Note, that the other way round, if we hard-wire the strong binding, it is
> much more effort to get rid of this strong interaction. Note as well, that
> per-object attributes are a quite heavy-weight machinery for setting
> variables. I would certainly not recommend to use per-object attributes each
> time a variable has to be created, at least not in in performance critical
> or memory critical situations.
>
> I could see at least 3 scenarios for objects, that require sometimes
> instance attributes:
>
> a) lightweight: just use tcl-variables, no attributes
>
>      Object create o {
>         set :x 1
>         :public method foo {} {return ${:x}}
>       }
>
> b) middleweight: just tcl-variables + setters/checkers, no attributes
>
>      Object create o {
>         set :x 1
>         ::nsf::method::setter [self] x:integer
>         :public method foo {} {return ${:x}}
>       }
>       % o x
>        1
>        % o x a
>         expected integer but got "a" for parameter "x"
>
> c) heavyweight: use attributes
>
>      Object create o {
>         set :x 1
>         :attribute {x:integer,1..n 0} {set :incremental 1}
>         :public method foo {} {return ${:x}}
>       }
>
>       % o x
>       1
>       % o x add 10
>       10 1
>        % o x add 100
>        100 10 1
>        % o x
>        100 10 1
>        % o x {1 hello 2}
>        invalid value in "1 hello 2": expected integer but got "hello" for
> parameter "value"
>
> For (b) the middleweight version, we have currently no nice method-based
> interface.
> Just in the case of (c) with the incremental interface, slot objects are
> needed
> (as well in other cases, where some additional meta-data is needed, such as
> e.g. persistency data, etc.).
>
> We could do
>  (1) bind the life-time of per-object attributes to the life-time of
> instance variables
>  (2) create not always slots, when attribute is used, but only when needed.
>
> The case (2) could be tricky for "delete attribute", but at least, for often
> used per-object attributes this could be a win. What is your primary reason
> for using "attribute" instead of tcl vars? do you use the incremental
> setters?
>
>
> -gustaf neumann
>
>
> Am 29.06.11 19:52, schrieb Victor Mayevski:
>>
>> In my code I have objects that need some attributes only sometimes.
>> So, that was my attempt to reduce the code and not have to test for
>> the existence of that attribute but just re-create it. In this case, I
>> ended up just having that attribute permanently in all objects at all
>> times. It is not that I didn't have any other way of doing it, it is
>> just that I thought it would have been an elegant and short way of
>> doing it.
>>
>>
>> Here is another curious code that could be a bug, at least it doesn't
>> seem to behave as expected:
>>
>> % Object create o
>> ::o
>> % o attribute {a oldvalue}
>> ::o::a
>> % o a
>> oldvalue
>> % o delete attribute a
>> % o a
>> ::o: unable to dispatch method 'a'
>> % o attribute {a newvalue}
>> ::o::a
>> % o a
>> oldvalue
>>
>>
>>
>> Also, is it possible for "object delete attribute a" to not complain
>> if the attribute does not exist, may be via "-nocomplain" switch or
>> just by default?
>>
>> Thanks,
>>
>> Victor
>>
>>
>> On Wed, Jun 29, 2011 at 3:51 AM, Stefan Sobernig
>> <stefan.sobernig_at_wu.ac.at>  wrote:
>>>
>>> Victor,
>>>
>>>>> %Object create o
>>>>> ::o
>>>>> %o attribute {a oldvalue}
>>>>> ::o::a
>>>>> %o a
>>>>> oldvalue
>>>>> %o attribute {a newvalue}
>>>>> ::o::a
>>>>> %o a
>>>>> oldvalue
>>>
>>> Forgot to ask: Why do you take this path (changing the default of the
>>> attribute slot) in the first place? If you want "a" to have the value
>>> "newvalue" assigned, why don't you simply say:
>>>
>>> o a newvalue
>>>
>>> //s
>>>
>>>
>>>
>> _______________________________________________
>> Xotcl mailing list
>> Xotcl_at_alice.wu-wien.ac.at
>> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>
>
> --
> Univ.Prof. Dr. Gustaf Neumann
> Institute of Information Systems and New Media
> WU Vienna
> Augasse 2-6, A-1090 Vienna, AUSTRIA
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

Next Page