Weblog Page

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sun, 29 Jan 2006 16:16:58 +0200

On 29 Jan 2006, at 15:26, Gustaf Neumann wrote:

> maybe you are interested in joining the frappr group of xotcl to
> locate the people based
> on the google map... See: http://www.frappr.com/xotcl

I guess that system sucks. I put my city as Helsinki and it said
'Invalid City'. You have to press tab or wait for a dropdown to get
your correct city identifier.

Oh well, added myself anyway.

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

From: Schofield, Bryan \(GE Transportation\) <"Schofield,>
Date: Tue, 19 Oct 2004 11:10:28 -0400

I've cut a bunch of the older email content out for brevity.

> -----Original Message-----
> From: Jeff Hobbs [mailto:jeffh_at_ActiveState.com]
> Sent: Monday, October 18, 2004 4:44 PM
> To: Schofield, Bryan (GE Transportation); xotcl_at_alice.wu-wien.ac.at
> Subject: RE: [Xotcl] xotcllib?
>
>
[...]
> While I don't want to discourage good coding exercises, I
> do want to encourage others to use code based on all the
> best practices. We don't have a perfect megawidget
> framework to rely on yet, but hopefully you'll be willing
> to take part when we get around to it, or maybe work on
> yours until it is that system. ;)
This actually started out as a coding exercise just to play with the new forwarding features of xotcl. I look forward to day that there is an "official" megawidget framework, but in the mean time, I do plan on enhancing mine to cover it's short comings.


[...]
>
> Hmmmm ... ok, you have created something more for users to
> define their own themes, whereas 'style' says "these are
> better overall alternate themes". I must say that I
> personally encourage the latter. It's a pity you couldn't
> make it to Tcl'2004 last week, because I had a tutorial
> and talk on these points. I don't mean to pick on you, I
> just want to give my ideas and how they may affect your
> current efforts.
>
> The whole idea of themeing, which will be core in 8.5, is
> to enable a better look for Tk. However, it is not
> intended for the user (in the common case) to change this
> theme. The functionality is there merely for Tk to better
> adapt to current styles. Thus, the 'style' code defines
> styles for users to just use, rather than providing a
> framework to create their own.

First, I don't take any of your comments personally. While I consider myself a good developer, I know that I'm not perfect and can be blinded my own intentions, motivations, and enthusiasm to create something new. Not to mention the fact that I know I don't know everything. I welcome your comments, as well as the comments of so many others.

Just clear up my intentions with xcentuate, it isn't really meant to be used for each application to define it's own look and feel. While it is very easy to do so, I'd hope that developers will respect the look and feel of the platform on which they will deploy. My main motivation was to improve how tk looks on my unix workstation. Currently, xcentuate only changes the theme on unix, by default it's a light grey theme which is suitable for brighter environments. It also provides a dark grey theme which works nicely in darker office settings. I think that xcentuate and 'style' share the same goal. Xcentuate, too, provides some "better alternate themes", it just goes one step further by making it very easy to define what the themes are. That makes it easy for corporate branding. For example, the system I work on is beige in color during normal operation. However, the same application can be launched in a training mode which is aqua in color. I can also have a "development" color mode to distinguish application
 instances that are in beta against those that running live. With xcentuate, the application look is simplified to:

  switch -- $mode {
    TRAINING { aquaLook apply }
    DEVELOP { devLook apply }
    default { normalLook apply }
  }


[...]
> OK, I've dealt with this before. There is nothing in the
> naming of that test that requires it be numbers, that is
> just convention. It makes it easier for grouping and such,
> and is handy when searching through the test suite after
> failures. In your example below:
>
> > file would be structured as follows:
> >
> > TestSuite foo \
> > -description "blah" \
> > -setup {set file [makeFile {} test]} \
> > -cleanup {removeFile test}
> > foo test \
> > -description "test file existence"
> > -result 1 \
> > -script {file exists $file}
>
> What happens when you don't provide a description? This
> should be a required field, as it is in tcltest, so why
> have it an option? Otherwise, I see the structure you
> have chosen could make it easier to build tests.

By the default, the description is "No Description Available". So nothing happens if it is not provided. Much like the following:

  test foo-1.1 {} \
     -result 1 \
     -body { set x 1 }

Sure, tcltest makes it a required field, but it doesn't ensure there is anything meaningful in it. If you really think about, the description is optional in tcltest, too.

Now... having spent the time to write xout and the ui that goes with it, I've (begrudgingly) accepted the following:

 1. Tcl does not need another another a testing framework. Choice is not always beneficial, and in this case I think it would hurt tcl overall. It's hard enough to get people to write tests; no point in muddying up the water with something else.
 2. Having to name my tests (example-1.1) isn't that much more work. Calling "cleanupTests" isn't a big deal either, so I'll just do it and quit whining.
 3. My efforts would have been better spent adding a ui to tcltest. I think I'll do that.
 4. It took suprisingly little time to convert my xout test files to tcltest files.

[...]

> I like the UI you added to it.

Thanks, I think I'll redo it to work with tcltest.


[...]
> No problem, and I don't want to sound negative. I'm just
> trying to assist constructively. As I've told Gustaf and
> Uwe before, xotcl (or some close variant) could be the OO
> for the core, if it provided 100% itcl compatability (for
> the many many folks that rely on itcl).
>
> Jeff

You don't sound negative.
Thanks, I appreciate your opinion, Jeff.

Didn't Gustaf whip up something that was itcl compatible, at least to some degree? And does it need to be 100% itcl or 100% itcl/itk?

-- bryan

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sun, 29 Oct 2006 10:25:06 +0200

On 29 Oct 2006, at 03:54, Shishir Ramam wrote:

> Hi,
> Was wondering why it's not possible to import namespaces when XOTcl
> objects are involved.
> The shortest example that I could rustle up is included below.
> Help in understanding what prevents this from working is much
> appreciated.

I didn't test your example, but could it be because you did not
export 'Foo' from the namespace?

Ie. "namespace export Foo" could possibly help.

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

From: <MichaelL_at_frogware.com>
Date: Mon, 15 Nov 2004 10:32:47 -0500

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?

From: Victor Mayevski <vitick_at_gmail.com>
Date: Tue, 15 Mar 2011 17:48:07 -0700

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: Aamer Akhter <aakhter_at_gmail.com>
Date: Thu, 16 Feb 2006 11:45:30 -0500

Critcl allows us to easily create tcl callable C procs. Is there
something similar avaliable for xotcl?

Is there any C api documentation?

--
Aamer Akhter / aakhter_at_gmail.com

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Tue, 30 Nov 2004 11:57:22 -0800

I found this oddity in XOTcl_DeleteCommandFromToken:

   XOTclCallStackContent *csc = cs->top;
 
   for (; csc > cs->content; csc--) {
- if (csc->cmdPtr == cmd)
- csc->cmdPtr = NULL;
- break;
+ if (csc->cmdPtr == cmd) {
+ csc->cmdPtr = NULL;
+ break;
+ }
   }
   return Tcl_DeleteCommandFromToken(in, cmd);
 }

Is my fix correct, or is there some magic reason why you
would want to break after the first 'if' check no matter
what?

BTW - any conditionals without { } is BAD CODE, for exactly
the above reason.

  Jeff Hobbs, The Tcl Guy
  http://www.ActiveState.com/, a division of Sophos

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 12 Oct 2007 21:31:31 +0200

Dear XOTcl Community,

XOTcl 1.5.6 is available. This version is mostly a fix release for
some problems that were apparently quite long in the code and could
cause crashes for threaded applications.

best regards
-gustaf neumann

Announcing XOTcl 1.5.6
*************************

We are pleased to announce the availability of XOTcl 1.5.6.

Major changes relative to 1.5.4 are:

   * Fixes for treating global volatile objects (many thanks to Zoran
     for his concise reports). The problem was that XOTcl uses
     C-level var traces containing pointers to objects.
     If for some reason, these objects are destroyed earlier, this
     results in dangling references. This problem caused especially
     problems in the automatic cleanup of variables at the end
     of a thread.

   * Fix for Tcl 8.4.* for situations, where Tcl variables
     contained references to deleted XOTcl objects. The problem
     was introduced by the VarReform changes between 1.5.3 and
     1.5.4 by a bad side effect of a Tcl_Obj based command
     to look up Tcl command structurs. The problem did not
     exist for xotcl compiled against Tcl 8.5 and is as well
     fixed on the Tcl side in CVS (might become available,
     when one more Tcl 8.4 release is eventually released)

   * Serializer:
      - Added dependency rule in serializer to ensure slots of
        super-classes are listed before subclasses. (Thanks to Stefan
        Sobernig for reporting the problem)

     - Moved deactivation of traces into "Serializer all"
        to get simpler results on "o serialize".

   * Extended regression tests


 For more details about the changes, please consult the ChangeLog and
 documentation.

MORE INFO
  General and more detailed information about XOTcl and its components
  can be found at http://www.xotcl.org

From: Nicolas Boretos <nicolas_at_maich.gr>
Date: Thu, 15 May 2003 12:17:22 +0300

Hello again,

We are at the onset of a Web based project to be built on, at least the
current thinking is,
on XML/SOAP. Basically, a Web browser interface calling SOAP methods on
a SOAP server.
Initial trials using tcl soap along with the the package's SOAP::domain
stuff under tclhttpd seem
promising, if possibly a bit cludgey and slow...We also work with
Aolserver, but have not looked at ns_soap..

Most of the application are requests for Eurosta data (living in a
postgres db), calculations, and
generating charts, pies, graphs, XML reports etc.

I was wondering as to what efforts, if any are being done along these
lines. I found some tclhttpd/soap etc wrappings
on Mr. Zdun's site, but could not really get these to work (cleanly, at
least). I also found the link below but have not

http://nm.wu-wien.ac.at/Lehre/oo2/04-39.html

had a chance to look at it.

Is there anything newer/other along these lines available? Most of our
thinking is to eventually move towards your
ActiWeb/Active Web Objects, but we are still in the exploration phase.
I also have a gut feeling that tis project will grow/change as time
goes, which infers maintainability issues, which is
why we are shying away from our intial tcl/tclsoap approach and more
towards XOTcl/objects....

regards,

nicolas boretos

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Thu, 26 Jul 2012 10:50:54 +0200

Dear Jon,

up to my knowledge, cygwin + the head version of nx from git
is supposed
to compile together with the source tree of tcl).

-gustaf