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

Weblog Page

Showing 191 - 200 of 1561 Postings (summary)

Re: [Xotcl] Static member functions?

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, 17 Apr 2003 13:08:50 +0200

On Wednesday 16 April 2003 22:35, Michael A. Cleverly wrote:
> Very interesting. But, I'm confused by the results I'm seeing (both
> before & after applying the patch). It seems that even though [o1 test0]
> and [o1 test1] throw an error the variable is updated.

 This is the semantics of variable traces in tcl (the trace is called afted the fact).
 It is possible to keep shadow-values of the variable contents and to restore
 the variable after a write operation to the original content, but my feeling was
 that the purpose was rather trapping unwanted access than prohibiting it...
 
> And [o1 test3] does unset the variable.

 i mentioned that in the maybe cryptical sentence at the end of my last mail.
 the xotcl method unset uses the tcl c function Tcl_UnsetVar2. If unset
 triggers a trace, and the trace ends with an error, the error is not returned
 by the Tcl_UnsetVar2 command. This is different to the case of set, where
 Tcl_ObjSetVar2 returns the error.

 I'll try to make a simple example and post it to c.l.t, let us see, what the
 community thinks...

 best regards
-gustaf

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien

[Xotcl] Annonce: XOTcl 0.85 released - compatible with XOTcl 2.0

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

From: Artur Trzewik <mail_at_xdobry.de>
Date: Sat, 11 Feb 2012 22:28:23 +0100

Hi XOTcl Friends!

The new release of XOTclIDE 0.85 is ready on
http://www.xdobry.de/xotclIDE

Changes:
1. Compatible with XOTclI 2.0 (nxf based XOTcl). Many thanks to Gustaf
Neumann for patches.
Indeed XOTcl 2.0 seems to be the most backward compatible version ever
of XOTcl. I was quite surprised that my many thousand of XOTcl code runs
without problems with XOTcl 2.0. So version difference 1.6 to 2.0 seems
to be most internal nature.

But there is small change in XOTcl 2.0 that make problem with old
XOTclIDE 0.84.
The method names can not start with : but it was used in _at_ Object to
store meta information for IDE.

If you have all XOTclIDE components, you will need to load and write all
components with XOTclIDE 0.85 (if you use file system components) and
XOTcl 1.6
and then you can use them with XOTclIDE 0.85 and XOTcl 2.0.

All just remove the colons from meta descriptions

For example
_at_ ::IDE::Browser idemeta component IDEBaseGUI

to

_at_ IDE::Browser idemeta component IDEBaseGUI

2) Improvements in tcl syntax checker. Now it knows new tcl 8.5 commands
(for example dict)

3) New namespace browser

4) New interpreter browser. You can create slave interperter run and
inspect the state of interpreter

5) Modified wiki reaper. It can list wiki pages with tcl code, run it in
slave interpreter and inspect it.

6) Code completion knowns also tcl commands options.

7) Many other improvements and bug fixes.

Artur

Re: [Xotcl] ensemble alias

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: Fri, 06 Jan 2012 03:04:51 +0100

In cases, where no ensemble command is available from tcl,
one can use as an additional option to the forward an interp
alias like in the following example:

% package req nx
% interp alias {} foo {} string is boolean
% foo true
1
% foo hi
0
% Object create o { :public alias stringIsBoolean foo }
::o
% o stringIsBoolean true
1

-gustaf neumann

On 05.01.12 23:22, Stefan Sobernig wrote:
> 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
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

[Xotcl] XOTcl method call precedence order

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

From: Neil Madden <nem_at_Cs.Nott.AC.UK>
Date: Thu, 5 Oct 2006 18:01:36 +0100

Hi Gustaf et al.,

I have a quick query regarding the precise method call order used in
XOTcl. The basic concepts involved seem to be filters, mixins, object
methods and inheritance. If I understand things correctly, these
apply in the following order:

     filters -> mixins -> instance methods -> "unknown"

and for each of the first three, lookup is done using the inheritance
hierarchy, i.e.:

     object -> class -> [superclass -> ...]

So, e.g. a per-object filter happens before a class-filter, but a
class-filter still happens before a per-object mixin. "instance
method" refers to procs when we are examining the actual object
instance, and "instprocs" when we are searching its class/superclasses.

Is this description correct? The only two mechanisms that I don't
know where to put are assertions and forwarders. Are these
implemented using e.g. mixins? Or are they a special-purpose
mechanism? If so, where do they come in the order?

Cheers,

-- Neil

Re: [Xotcl] Xotcl SOAP/Ramblings..

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, 15 May 2003 12:22:03 +0200

 Hi,
 to give you a short answer: we have currently no special
 soap support from xotcl. Uwe has started some work some
 time ago, i started from his work to use it for teaching purposes,
 but it is by no means a general SOAP support. The way we
 should go is to use tDOM as a basis and build a reasoable
 support on top of it. It is not particularly hard, but requires
 certainly some work (this looks like a fun project to me,
 working towards automatic generated WSDL descriptions
 from some meta-data).

 If you are on a project time-line, i would recommend
 to use XML-RPC if this is an option for you. I can
 send you some xotcl-code based on tDOM as starting point,
 if you are interested...

 best regards
-gustaf neumann
-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien

[Xotcl] Persistence in XOTcl (was Re: pb in src/package distribution configure)

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

From: <uwe.zdun_at_uni-essen.de>
Date: Wed, 22 Nov 2000 12:03:02 +0100 (CET)

>>>>> "CL" == Catherine Letondal <letondal_at_pasteur.fr> writes:
>> > 3) What is GDBM required for? Is it a general purpose persistence package that
>> > I could use for my own needs? How can I use it within XOtcl?
>> >
>>
>> gdbm is a nice persistence store, which allows you to make any
>> XOTcl object persistent (by specifying, which vars are persistent). There
>> is no documentation yet, but you can see in the counter examples in
>> apps/actiweb-apps how it works. the necessary packages are in the
>> packages/store dir. at the moment we are relying on gdbm, but plan to use
>> also several other persistent stores soon

CL> The problem is that gdbm il old (according to colleagues) and does does not install
CL> easily on my workstation - so I guess there will be problems on other platforms?
CL> Actually I had pbs with their ./libtool script for installing files and nobody could help!

We are aware of these problems. But Gdbm is in most Linux
Distributions. For Windows we provide a pre-compiled DLL. The
other platforms (like Solaris) sometimes require some hand-crafting.

There are several other persistent store (and databases), which we
possibly will support soon behind one common object interface (like
Berkley DB, MetaKit, etc.)


CL> Persistence interests me *a lot*, since the environment I'm currently programming is a
CL> programming environment, where 'programming exploration' is allowed by adding procs to
CL> objects during the normal use session. Several types of customization - like graphic
CL> attributes, bindings configuration - have also to be saved of course.

CL> The idea is also to have the already existing objects and their user interface (widget) to be
CL> automatically displayed when the application is restarted.
CL> Saving will be done by default, I mean without the user being required to ask for it.

CL> All this is realted to what you call 'programmable interfaces' in the paper 'Design and
CL> Implementation Constructs for the Devlopment of Flexible, Component-Oriented Software
CL> Architectures' - except that it is the so-called 'end-user programming'.

CL> What's the main idea to save an object? I have seen the persistent keyword in the
CL> counter examples, but how do you say: save this object, save this object's proc, etc...?

There are basically two things to do in order to make an object
persistent:

1. you have to set up a Persistence Manager. That is an object wrapper
   for the database/persistent store instance. E.g. with Gdbm it
   represents a GDBM file

2. you have to say which variables of which objects should be made
   persistent. This is done by calling the method "persistent" ...


"persistent" is an instproc of the class Persistent, which you can
find in store/Persistence.xotcl. This class (or one of its subclasses)
has to be made per-object mixin (or per-class mixin or superclass) of
the instance that should be made persistent.

The subclasses of the Class Persistent are the ones you actually
use. They determine the persistence strategy. Actually we have two
persistence strategies at the moment: Eager and Lazy. The Eager
strategy stores everything when it is written, the Lazy strategy
stores the vars when the xotclsh terminates.

This may sound more complicated than it actually is. Here is a simple
example:


####################################
# load the persistence component
package require Persistence

# Two example objects
Object o
# set two variables to default values
o set x 1
o set y 1

Object p
# set two variables to default values
p set x 1
p set y 1

####################################
# now we make these vars persistent
####################################


# 1. we need the PersistenceMgr (for gdbm we have to specify a file
# name). If we want to get rid of the current setting and start again
# we default values, we have to delete this file
PersistenceMgr pmgr -persistenceDir . -persistenceFile example-db

# 2. we have to make the objects persistent. We register the
# persistence strategy as per-object mixin on the two objects
#
# one uses the lazy, one the eager strategy

o mixin Persistent=Eager
p mixin Persistent=Lazy

# 3. tell the objects, which PersistenceMgr to use

o persistenceMgr pmgr
p persistenceMgr pmgr

# 4. make the vars persistent

o persistent {x y}
p persistent {x y}

#####################################

# now the vars are loaded from the persistence store
#
# we incr them to demonstrate the persistency; and print the results

o incr x 2
o append y 1
p incr x 3
p append y 2

puts "Values:"
puts " o->x: [o set x]"
puts " o->y: [o set y]"
puts " p->x: [p set x]"
puts " p->y: [p set y]"

# now run the program several times to see the results

####################################



I will include this example in the store dir of the XOTcl
distribution.

Note, for XOTcl WebObjects, Agents, etc. several of the tasks
demonstrated above are performed automatically ... therefore, the
Counter examples look even much more simple. The WebObjects
automatically associates with the PersistenceMgr of the place.

Therefore a simple:
  [self] persistent varXXX
makes the variable varXXX persistent eagerly.

CL> BTW, I have already develop small things, like a spreadsheet (using a mixin class
CL> to implement the dependencies between cells - see
CL> http://www.pasteur.fr/~letondal/tmp/mvc-depend.html) implemented thanks to tktable.

great! we have an applications web site on the XOTcl homepage and
encourage everyone to put up a web site for their XOTcl apps. If you
have something to reference please inform us.


Regards,

Uwe

-- 
Uwe Zdun
Specification of Software Systems, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_xotcl.org, uwe.zdun_at_uni-essen.de

[Xotcl] segmentation faults and bus errors

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

From: Ben Thomasson <ben.thomasson_at_gmail.com>
Date: Fri, 20 Jul 2007 13:34:35 -0400

Hello again,

I bring bad news. I am receiving seg faults and bus errors while
running XOTcl code. I am running XOTcl 1.5.3 and Tcl 8.4 on both
Linux x86 and OS X PPC. I received the errors randomly on both
platforms. This started occuring when I reloaded the source code. At
first I thought it was related to Tcl packaging, but I mostly removed
calls to package require and package forget. Currently I just use
source to load most files. I am writing code generation libraries
and using Object eval so I may be doing new things with XOTcl. How
should I go about debugging these seg faults? Are core dumps useful?
  I'll try to write a script that reproduces the problem, but I
haven't really narrowed the problem down yet.

Any help is much appreciated.

Thanks,

Ben

Fwd: Re: [Xotcl] philosophical Q on slot approach

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: Sun, 20 Jul 2003 03:17:52 +0200

---------- Forwarded Message ----------

Subject: Re: [Xotcl] philosophical Q on slot approach
Date: Sun, 20 Jul 2003 02:41:04 +0200
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
To: Kristoffer Lawson <setok_at_fishpool.com>

On Friday 18 July 2003 17:41, Kristoffer Lawson wrote:
> I like the way XOTcl lacks the concept of private and public methods and I
> also thought that it is unnecessary for fields. I also very much like
> multiple inheritance as, while I don't use it very often, sometimes it is
> just quite the most natural way to go about business.
>
> ....

 just for terminology issues: i think you are refering by "fields" to
 instance variables. let me re-iterate the basic "philosophical" point of
 view. Languages like xotcl are object-oriented, while languages like java
 (and most of UML) is class-oriented.

 Class-oriented means: look at the class an you
 know exactly, how all of the instances look alike. The class is the first
 and primary language construct; the class is well the place where
 you specify the instance variables (there are no instance variables
 except those specified in the class). The only kind of individualism
 left in the objects is to let them differ by their state (the values of
 their instance variables). Changing classes (class migration) is
 conceptionally quite hard for this setup.

 Object-oriented (in this distinction) means that the primary elements
 are objects, which keep all instance variables. classes my be used
 to specify the behavior of objects, they are container for methods and
 they control the life-cycle of objects. Objects are like the facts, and
 objects are like rules, that determine the behavior of the objects. Since
 the connection between objects and classes is rather loose, it is
 sufficient to define their relation through an association. Therefore
 it is quite easy to change the relation between objects and classes
 (and between classes and classes) dynamically. Objects have
 arbitrary individualism, they may have variables never used in
 any class, they may have private procs etc.

 From the expressiveness, object-oriented languages can - in principle - be
 restricted to behave like class-oriented languages, but the other way
 around is much harder.

> I do see the latter as much less of a problem but the first could be a
> real issue. It's probably just pure luck that I haven't had to debug it.

 I have the same experience. Name clashes between instance variables
 within objects do happen only very seldomly. More often classes from
 MI or mixin classes want to collaborate and to share state by using the
 same instance variables.

> I see two solutions to the problem:
>
> 1) A way to specify that you wish to modify or use a field and guarantee
> that it is the one from "your own" class. Possibly the same for a method.

 This is one of the reasons why there is a "instvar" method. A method
 specifies that it wants to modify a certain instance variable if it is only
 called by its variable name. It is quite easy to use traces to flag
 unwanted access (e.g. by using [self callingclass]).

 If there have is a situation, where the unstructured instance variable
 namespace of an object is not sufficient, aggregation is the instrument of
 choice (e.g. a "Person" has many "Projects" aggregated).

> 2) Define that instance variables cannot be used from outside the class.
> That they are always "private" and thus cannot conflict. This I sort of do
> anyway. I never access fields directly from outside the class.

 look at the code of my posting about "static member functions" in
 http://alice.wu-wien.ac.at/pipermail/xotcl/2003-April/000383.html
 It is quite easy to change the policy form "callingobject" to "callingclass"
 or "callingproc" to to a combination of these. This way you can
 detect "abuses" of certain variables.

 Another goal might be to avoid name clashes (e.g. the instance variable
 name of method m1 should be a different variable than the instance
 variable name of method m2). This way the names cannot clash, but
 the state cannot be shared. Approaches to avoid clashes are
 aggragations or to use an indirection layer
 for accessing instance variables. You can define a method
 "getinstvar context name" that might allocate and return the
 variable name (something like __instvar223-mycontext). This
 method could be used like in
   set name [getinstvar [self proc]-[self class] name]
   my set $name "K. Lawson"

 i am still not sure whether i understood your question correctly.

> Maybe a combination of the two. In Java, or any language with only single
> inheritance, this is not an issue (and thus private-protected-public is
> mostly unnecessary).
>
> Opinions? (wondering if I'm still on the list as I haven't seen any emails
> from there in ages)

Check out
   http://alice.wu-wien.ac.at/pipermail/xotcl/
 whether you have missed something.

 all the best
-gustaf

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

--
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien
-------------------------------------------------------
-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien

[Xotcl] Re: [Xotcl] Widgets

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, 5 Feb 2001 22:42:11 +0100 (CET)

>>>>> "RH" == Rick Hedin <rhedin_at_aquifer.geology.uiuc.edu> writes:
RH> Hello all.

RH> I want to build an object on top of a canvas. The object adds
RH> some internationalized features. I'm not clear how to manage the
RH> XOTcl object in conjunction with the Tk object. For now, I'm just
RH> managing the two as separate entities.

RH> Icanvas icanvas .f ;# I pass the path for the tk object.
RH> pack .f.icanvas -fill both -expand true ;# And manipulate the tk object
RH> with tk commands.

RH> Or maybe I should:
RH> pack [icanvas tkpath] -fill both -expand true

RH> Or give my object a truly wicked name:
RH> Icanvas .f.icanvas ;# Will this work?

  yes, if the intention is that the Tk widget instance has the name
  ".f". but i would not recommend to determine from the XOTcl object name
  the name of the Tk widget.
 
RH> Or wrap every tk command in my xotcl object.

  Sometimes, this is a straight forward solution to keeps the
  XOTcl objects and the tk widget in separate trees. Architecturally,
  this is not a beauty.

RH> What is your thinking regarding widgets from XOTcl?

  For now, we have not definite answer.
  You might check the following solution, that is conceptionally
  quite simple. For each "XOTcl Widget" an tk object with a leading
  dot is created. It handles [self], xotcl methods, instance variables
  and should be easy extensible for most purposes.

 best regards
-gustaf
=====================================================================

#!/usr/local/bin/xowish

# make generation of tk widgets easy configurable
Class parameter tk

# Widget is a metaclass, that provides the generic create method to
# the Widget classes. For each XOTcl object, a Tk widget with a
# leading dot is created.
Class Widget -superclass Class
Widget instproc create {name args} { eval [[self] set tk] .$name; next }

# The Class TkWidget handles the flags, that are useful to redefine
# for XOTcl. We want to be able to work with self in callbacks, we
# want to sent instances variables of Objects, and so on. Everything
# unknown is delegated to Tk configure.
Widget TkWidget
TkWidget instproc s {} {string trimleft [self] :}
TkWidget instproc invoke cmd { eval $cmd }
TkWidget instproc command cmd {
  .[[self] s] configure -[self proc] [list [self] invoke $cmd]
 }
TkWidget instproc textvariable v {
  .[[self] s] configure -[self proc] [self]::$v
 }
TkWidget instproc unknown {m args} {
  puts stderr "UNKNOWN eval .[[self] s] $args"
  eval .[[self] s] configure -$m $args
}

# we want to support the following widget classes
Widget Button -superclass TkWidget -tk button
Widget Label -superclass TkWidget -tk label
Widget Entry -superclass TkWidget -tk entry

# well, now our application:
Button hello -text "hello world" -command {[self] text [self]}
Label l -text "Enter some text:"
Entry e -width 20 -textvariable input
Button quit -text "exit" -command {[self] print}
pack .hello .l .e .quit

quit proc print {} {
  puts "entry var: '[e set input]'"
  exit
}

Re: [Xotcl] Bug: Empty arglist and body throws error

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, 27 Oct 2004 23:54:19 +0200

Dear Bryan,

> I'm afraid I found a bug that will generate an "unable to dispatch" error
if the argument list & body of an >instproc are both empty. You will notice
that as long as either contain something, it's ok. Notice the body of >"Bar
notpuke", it's just a single comment. See the code below:

we have a behavior in xotcl that we inherited from otcl: when instproc is
invoked
with an empty argument list and an empty body, this instproc is deleted.
Most probably, we should do the following:
  a) produce an error, when someone tries to delete a non.existing
proc/instproc
  b) document this behavior somewhere more visible.

-gustaf

Next Page