Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 18 Apr 2005 10:47:43 +0200

Ben Thomasson schrieb:

>Hi Gustaf,
>
>Have you fixed or considered fixing this issue?
>
Hi Ben,

we have discussed this here, but we have not released any code in this
direction yet.
The included patch will be in 1.3.7 and prevents overwriting of objects
through new.

   cd xotcl-1.3.6
   patch -p0 < /tmp/new-patch

best regards
-gustaf


--- generic/xotcl.c-1.3.6 Mon Apr 18 10:37:42 2005
+++ generic/xotcl.c Mon Apr 18 10:27:57 2005
_at_@ -8874,7 +8902,7 @@
 #if REFCOUNTED
     isrefcount = 0,
 #endif
- i;
+ i, prefixLength;
   Tcl_DString dFullname, *dsPtr = &dFullname;
   XOTclStringIncrStruct *iss = &RUNTIME_STATE(in)->iss;
 
_at_@ -8906,8 +8934,16 @@
   } else {
     Tcl_DStringAppend(dsPtr, "::xotcl::__#", 12);
   }
- (void)XOTclStringIncr(iss);
- Tcl_DStringAppend(dsPtr, iss->start, iss->length);
+ prefixLength = dsPtr->length;
+
+ while (1) {
+ (void)XOTclStringIncr(iss);
+ Tcl_DStringAppend(dsPtr, iss->start, iss->length);
+ if (!Tcl_FindCommand(in, Tcl_DStringValue(dsPtr), NULL, 0)) {
+ break;
+ }
+ Tcl_DStringSetLength(dsPtr, prefixLength);
+ }
 
   fullname = Tcl_NewStringObj(Tcl_DStringValue(dsPtr), Tcl_DStringLength(dsPtr));
 

From: Victor Mayevski <vitick_at_gmail.com>
Date: Sun, 20 Mar 2011 19:56:48 -0700

Well, that makes sense. It turned out that handling spaces in object
names is a complete nightmare. I decided that it is much easier to get
rid or replace the spaces than try to predict and catch every event of
spaces in object names breaking my script.

On Tue, Mar 15, 2011 at 10:29 PM, Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote:
> Dear Victor,
>
> i don't think, nx/xotcl should brace a scalar return values. Look at plain
> Tcl:
> Tcl does not brace a string with a space either:
>
> % set x "a b"
> a b
>
> For what reason should nx/xotcl do it? There are many other commands in nx,
> doing the same, such as e.g. "create"
>
> % nx::Object create "a b"
> ::a b
> % nx::Object create "a b::c d"
> ::a b::c d
> % nx::Object create "a b::e"
> ::a b::e
>
> ... and therefore "info parent" has no reason to add braces:
>
> % "a b::c d" info parent
> ::a b
>
> In situations, where a list is returned (potentially multiple elements) the
> elements have to be are proper list elements and therefore these elements
> are escaped, even if the result is a list with a single element:
>
> % "a b" info children
> {::a b::e} {::a b::c d}
>
> This is the same in plain Tcl as well: "info commands" returns a list of
> elements:
>
> % info commands "::a *"
> {::a b}
> % info commands "::a b::*"
> {::a b::e} {::a b::c d}
>
> again, the command as a scalar:
>
> % lindex [info commands "::a b::*"] 0
> ::a b::e
> %
>
> So, the rule is: list are properly escaped, scalars are the plain values.
>
> all the best
> -gustaf
>
> On 16.03.11 01:48, Victor Mayevski wrote:
>>
>> Hello Gustaf,
>>
>> I encountered an issue with [info parent] and where parent's name
>> contains a space. While [info children] behaves correctly by returning
>> a list:
>> {::pa rent::child}
>> [info parent] just returns the name:
>> ::pa rent
>> instead of:
>> {::pa rent}
>> This is fixable by using [list [info parent]] but I wonder if that
>> should be the default behavior in NX anyway?
>>
>> Thanks,
>>
>> Victor
>
>

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Fri, 09 Jul 2010 18:25:41 +0200

> Has anyone done any code or a framework for managing per-class permissions? Basically a way to do rules describing which other objects, or which roles users must have, in order to call the different methods provided by instances of the class (plus any class procs). This is kind of like an expanded approach to Java style simple permissions (private/protected/public), which of course could also be incorporated into that, if wanted.

Nope, speaking for myself, I have never done anything into this
direction. (And never really felt the need for doing so.)

In the upcoming major release, there will be some "access properies"
(like the UML2 private, for instance) to manipulate the publicly
accessible signature interface of an object whereas these can then still
be tweaked (removed or set) through a lower-level API at any time).

//stefan

From: <andreask_at_activestate.com>
Date: 08 Jun 2015 21:05:55 -0700

Hello XOTcl Developers, fyi ...

22nd Annual Tcl/Tk Conference (Tcl'2015)
http://www.tcl.tk/community/tcl2015/

October 19 - 23, 2015
Comfort Suites Manassas
7350 Williamson Blvd, 20109
Manassas, Virginia, USA

Important Dates:

[[ Attention! Registration is open! Please have a look at
   http://www.tcl.tk/community/tcl2015/register.html
]]

Abstracts and proposals due August 24, 2015
Notification to authors August 31, 2015
WIP and BOF reservations open July 27, 2015
Author materials due September 28, 2015
Tutorials Start October 19, 2015
Conference starts October 21, 2015

Email Contact: tclconference_at_googlegroups.com

Submission of Summaries

Tcl/Tk 2015 will be held in Manassas, Virginia, USA from October 19, 2015 to October 23, 2015.

The program committee is asking for papers and presentation proposals
from anyone using or developing with Tcl/Tk (and extensions). Past
conferences have seen submissions covering a wide variety of topics
including:

* Scientific and engineering applications
* Industrial controls
* Distributed applications and Network Managment
* Object oriented extensions to Tcl/Tk
* New widgets for Tk
* Simulation and application steering with Tcl/Tk
* Tcl/Tk-centric operating environments
* Tcl/Tk on small and embedded devices
* Medical applications and visualization
* Use of different programming paradigms in Tcl/Tk and proposals for new
  directions.
* New areas of exploration for the Tcl/Tk language

Submissions should consist of an abstract of about 100 words and a
summary of not more than two pages, and should be sent as plain text
to tclconference_at_googlegroups.com no later than August 24, 2015. Authors of accepted
abstracts will have until September 28, 2015 to submit their final
paper for the inclusion in the conference proceedings. The proceedings
will be made available on digital media, so extra materials such as
presentation slides, code examples, code for extensions etc. are
encouraged.

Printed proceedings will be produced as an on-demand book at lulu.com

The authors will have 30 minutes to present their paper at
the conference.

The program committee will review and evaluate papers according to the
following criteria:

* Quantity and quality of novel content
* Relevance and interest to the Tcl/Tk community
* Suitability of content for presentation at the conference

Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.

Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application. Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.

Papers accompanied by non-disclosure agreements will be returned to
the author(s) unread. All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.

The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.

Other Forms of Participation

The program committee also welcomes proposals for panel discussions of
up to 90 minutes. Proposals should include a list of confirmed
panelists, a title and format, and a panel description with position
statements from each panelist. Panels should have no more than four
speakers, including the panel moderator, and should allow time for
substantial interaction with attendees. Panels are not presentations
of related research papers.

Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather
sessions (BOFs) are available on a first-come, first-served basis
starting in July 27, 2015. Specific instructions for reserving WIP
and BOF time slots will be provided in the registration information
available in July 27, 2015. Some WIP and BOF time slots will be held open
for on-site reservation. All attendees with an interesting work in
progress should consider reserving a WIP slot.

Registration Information

More information on the conference is available the conference Web
site (http://www.tcl.tk/community/tcl2015/) and will be published on
various Tcl/Tk-related information channels.

To keep in touch with news regarding the conference and Tcl events in
general, subscribe to the tcl-announce list. See:
http://code.activestate.com/lists/tcl-announce to subscribe to the
tcl-announce mailing list.


Conference Committee

   * Andreas Kupries ActiveState Inc
   * Arjen Markus Deltares
   * Brian Griffin Mentor Graphics
   * Clif Flynt Noumena Corp
   * Cynthia Lilagan National Museum of Health & Medicine, Chicago
   * Donal Fellows University of Manchester
   * Gerald Lester KnG Consulting LLC
   * Jeff Hobbs ActiveState Inc
   * Joe Mistachkin Mistachkin Systems
   * Kevin Kenny GE Global Research Center
   * Larry Virden
   * Mike Doyle National Museum of Health & Medicine, Chicago
   * Ronald Fox CAEN Technologies
                      NSCL _at_ Michigan State University
   * Steve Landers Digital Smarties
   * Steve Redler, IV SR Technology

Contact Information tclconference_at_googlegroups.com

Tcl'2015 would like to thank those who are sponsoring the conference:

   * ActiveState Inc
   * Buonacorsi Foundation
   * Mentor Graphics
   * Noumena Corp
   * SR Technology
   * Tcl Community Association

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 21 Mar 2003 17:27:18 +0100

 Dear XOTcl community

 XOTcl 1.0.2 is available! Below is the full announcement text!

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

Announcing XOTcl 1.0.2
**********************

WHAT IS XOTCL?

  XOTcl is an object-oriented extension of Tcl that was derived from
  OTcl. In short, XOTcl tries to provide a highly flexible,
  reflective, component-based, and object-oriented environment. It
  integrates language support for high level concepts which are not
  found in other languages, with reasonable performance. It prevails
  the Tcl programming style and the dynamic/introspective nature of
  the language, rather than introducing other language's styles and
  rigidness (such as C++) into Tcl.


CHANGES relative to 1.0.1 are:

  - fixes:
 
     * fixes for copying/moving objects to same name

     * works out of the box with AOL-server 4.0
       (no patch for AOL-server needed)

     * various small fixes and code cleanup

     * new directory structure (no nested version numbers)

     * improved object and class serializer

  - new functionality and improvements:

     * new method "ismixin": Test whether the argument is a
       mixin or instmixin of the object.

     * new method "hasclass": Test whether the argument is either
       a mixin or instmixin of the object or if it is on the class
       hierarchy of the object. This method combines the
       functionalities of istype and ismixin.

     * arguments of configure methods can start now
       with a leading "-" without ambiguity. In previous versions

         Class C -parameter {name counter}
         C c1 -name -x -counter 123

       the configuration of c1 was interpreted as follows

          method argc
          name 0
          x 0
          counter 1

       Starting with XOTcl 1.0.2 arguments can be protected
       by putting it into a list:

         C c1 [list -name -x] -counter 123

       which is interpreted as follows:

          method argc
          name 1
          counter 1

 For more details, please consult the ChangeLog

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

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

From: Murr, Florian <florian.murr_at_siemens.com>
Date: Mon, 29 Oct 2007 14:42:18 +0100

Dear XOTcl-guys!
I tried to upgrade from Tcl8.4+XOTcl1.5.3 (all my projects worked fine
here!) to Tcl8.5b1, but my projects won't run due to some XOTcl
problems.
The following snippet is extracted from my project and I tested it with
XOTcl1.5.5 (from WinTclTk) and XOTcl1.5.6 from ActiveState-Teacup.
But both failed with the same error message.
My guess: Non-positional Arguments don't work!

#
************************************************************************
*****
# The script:


Class X
X instproc ListOfStringsOption {{-default {}} {-cb {}} name} {
    if {$cb eq {}} { set cb "::set ::$name " } ;# global variable
    eval $cb \$default
}
::X create x1
::x1 ListOfStringsOption uu


#
************************************************************************
*****
# Error message:
can't read "default": no such variable
    while executing
"::set ::uu $default"
    ("eval" body line 1)
    invoked from within
"eval $cb \$default"
    (procedure "ListOfStringsOption" line 5)
    ::x1 ::X->ListOfStringsOption
    invoked from within
"::x1 ListOfStringsOption uu"

From: Donal K. Fellows <donal.k.fellows_at_manchester.ac.uk>
Date: Wed, 28 Sep 2005 16:49:01 +0100

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

The TIP is (totally!) light on C-level API, largely because I've no idea
what needs to go there. I'd even be happy (personally speaking) with an
OO system that did not provide any C-level API at all. Other people will
probably disagree. :-D

> b) We have discussed splitting xotcl classes into smaller components
> about two years ago. We did not do this mostly since xotcl users
> would most likely use Obect and Class as it is today.
[...]
> Having said this, i am certainly not sure that "define" leads
> the right way by moving the methods to manipulate the MR
> to the top.

Having the metadata manipulators outside the primary object hierarchy is
pretty much a requirement, and it comes from what's needed for
supporting multiple OO "looks and feels" on top. Whether it is a single
command is quite negotiable as is the precise name of the command(s) of
course.

> c) the concern with "clean interfaces" is certainly valid but addresses
> not only the number of methods, but as well orthogonality
> (so, define is neither orthogonal with tcl or xotcl).

I admit it; I don't treat orthogonality as holy. It's nice, but it's not
the only goal I have. :-)

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

Again, that's driven by supporting other OO systems too.

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

The best place to discuss things is really the tcl-core mailing list.

BTW, I was wondering what happens when you do this in XOTcl (ignoring
the syntax for now):

   class A derived from Object
      defines instproc foo
   class B derived from A
      defines instproc bar
   class C derived from Object
      defines instprocs foo, bar and move

   object D is a C with B mixed in
      call: D foo
      call: D move

Which implementation of foo gets called first? Which implementation of
move gets called first?

Donal.

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 14 Jan 2007 15:22:52 +0100

Kristoffer Lawson schrieb:
> Here is some code that worked before:

Kristoffer, yes this was a bug, error message propagation from methods
called by configure did not work properly. This bug was introduced
by making xotcl more robust against panics that might occure, when
append result is called with a shared object, resetting the result and
the inner error message in this case.

Below is a small patch, that will go into the next versions of xotcl.

Many thanks for the report...
-gustaf neumann


--- generic/xotcl.c-orig 2006-11-24 12:54:10.000000000 +0100
+++ generic/xotcl.c 2007-01-14 15:09:39.000000000 +0100
_at_@ -9141,8 +9141,11 @@
     methodName, argc+1, obj, result); */
 
   if (result != TCL_OK) {
- XOTclVarErrMsg(in, " during '", ObjStr(obj->cmdName), " ",
+ Tcl_Obj *res = Tcl_DuplicateObj(Tcl_GetObjResult(in)); /* save the
result */
+ INCR_REF_COUNT(res);
+ XOTclVarErrMsg(in, ObjStr(res), " during '", ObjStr(obj->cmdName), " ",
                    methodName, "'", (char *) NULL);
+ DECR_REF_COUNT(res);
   }
   return result;
 }

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Tue, 30 Nov 2004 15:21:36 -0800

> 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.

Understood. We are doing wide testing now in order to
try and get this in ActiveTcl.

> > 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?

It didn't actually matter whether it was gcc or HP cc, both
failed at the same spot. Unfortunately this machine is
behind a firewall, so I couldn't give access regardless. I
am still working on some other issues (just fixed the Windows
doc building), so I haven't looked into this abnormality at
this point. If you have an idea, I'll test it.

> > 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,

Actually, I have one more patch coming down the pipe - it
only has more Makefile changes, but I will make it the same
bulk-style patch as before. Actually, it changes makeDoc.xotcl
as well to remove Windows-isms and be more error-sturdy.

Should be done with that shortly.

Jeff

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 21 Mar 2006 10:28:15 +0100

Kristoffer Lawson schrieb:
> It's only really necessary for variables which are linked to other
> systems as for callbacks you can generally do f.ex.:
>
> after 100 [list [self] doStuff]
>
> which is what I actually do. I mean, presumably the problem with using
> a method by its direct namespace is also that filters get avoided, or?
> (at least I think it was that way at some point in XOTcl's history).
> That, to me, would mean it's not a good method except for very
> specific cases.
please, check more carefully, what has been posted and discussed. Koen's
original "myproc"
(renamed to "mymethod") is NOT about prepending a namespace prefix to a
method name,
but is nothing more than a shortform for "list [self] ..."). In your
example one would be able
to register the callback to after with

    after 100 [mymethod foo 1 2 3]

or by the method variant

    after 100 [my callback foo 1 2 3]

Since the idiom [list [self] .... ] is used for registering callbacks,
naming suggestions like "methodName" or variants
with "namespace" are not appropriate.

i do not like the &-suggestions for the xotcl-core, since it looks
like an operator, not like a name. The &-operator is not
about fully qualifying a name, but about providing a reference
in general.

i get the impression that adding these cmds/methods do not reduce
significantly the clarity. myvar/myvarname makes sense for the
snitters.

-gustaf neumann