Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 28 Sep 2010 11:49:06 +0200

  On 02.09.10 07:28, Victor Mayevski wrote:
> I am wondering if it will be possible to somehow implement coroutines in XOTcl? Is it feasible? Would it be worth it?
Sorry for the late answer. With XOTcl 1.6.* there is no
special support
for coroutines (one can certainly create Tcl-coroutines and
use it).

With 2.0 one can write object oriented coroutines.
The new regression test contains already the classical
number generator
example based on coroutines (see below).

-gustaf neumann

=========================================================
Test case number-generator {

   Object create numbers {

     # set instance variable used in coroutine
     set :delta 2

     :public method ++ {} {
       yield
       set i 0
       while 1 {
         yield $i
         incr i ${:delta}
       }
     }
   }

   # create coroutine
   coroutine nextNumber numbers ++
   set ::j 0

   # use coroutine
   for {set i 0} {$i < 10} {incr i} {
     incr ::j [nextNumber]
   }

   # remove coroutine
   rename nextNumber {}

   ? {set ::j} 90
}

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Thu, 22 Apr 2004 17:29:52 -0700

> In fact, I'd be pleased to see Snit in the core - I really like the
> delegation model and I intend to start using Snit more in the future.

I'm not sold on snit, although we do use it. I want to have
the opportunity to look into xotcl more in actual use. It
has had a lot more large applications built with it, and has
been "harder hit" (at least that's my impression).

Why? Because it is similar to snit, similarly it is a
"Tcl-friendly OO model", but already done in C, even to the
point of performance tweaking. People like snit because the
model is good, and they can drop it in anywhere because it is
pure Tcl.

However, a true core OO should be done in C. xotcl is that
already. Sure, you can code parts of snit in C - but xotcl
is already there *and tested*. It has active developers and
interested users. It's even gone so far as to have an alpha
"itcl compatability" mode that actually faster than the C
coded itcl!

So why have I been slow in including it? Well, until v1.2
the build system was not TEA friendly. I strongly believe
in extensions that behave as extensions, and it behaved as if
xotcl was the world. Also, key to AS work in usage only, the
TDK Compiler does not know how to precompile (hide/obfuscate)
xotcl methods, so it wouldn't be too hard to go poking in our
code (which we don't want ;) ).

Please note that this message crosses 3 mailing lists, so be
conscious of who is on the to/cc for your replies.

Jeff

PS - Of course we still love Will's snit, which is why it
actually made it into our code, but when we talk "core OO",
there are different criteria to go by.

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 22 Jan 2001 15:58:09 +0200 (EET)

On Mon, 22 Jan 2001, Gustaf Neumann wrote:

> During the output of the error message, XOTcl tries to provide
> the backtrace (callstack), but it this case it contains a command
> from an non-existing object.
>
> on my system, i do not get an segfault, but an output containing freed
> memory. if you remove the "blah" argument from the constructor of
> Bar, i would expect a graceful behavior on your system as well.

Exactly. That's why I had the "blah" argument there. Actually on
another system it segfaulted immediately while on this other system
I had to create the object twice. I guess it's just a matter of
when the freed memory gets used.
>
> If you are interested, i could send you a quick fix for the problem.
> However, I experimented with the problem, you are addressing, and
> found another related problem, for which i have no fix yet....

No rush. As I mentioned, it was actually a bug in my own code that
triggered this (and it would actually be an uncommon thing to do
anyway). So better to spend the time fixing it properly than getting
in a quick fix.

What about the instvar alias problem? Not exactly critical either
as I can work around it, but is there a fix coming up/available?

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

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Mon, 20 Mar 2006 09:41:48 -0700

xotcl-bounces_at_alice.wu-wien.ac.at wrote on 03/20/2006 07:21:27 AM:

> Kristoffer Lawson schrieb:
>
> > I'm also wondering what the name should be, to make it really clear.
> > Is [my var] clear enough? or should it be [my normalisedVar]?
>
> "my var" is not a good option, "my varname" would be better,
>
> furthermore, "my method" is already defined, getting a good name with
> method seems messy. how about:

There's some semantic relationship between the two accessors, so it would be nice to have some
overlap in their names. How about "my varname" and "my methodname"?

      Scott

From: Victor Mayevski <vitick_at_gmail.com>
Date: Fri, 21 May 2010 14:20:40 -0700 (PDT)

Kristoffer,

Your project reminds me of another project someone else is doing using TCL, which tries to emulate the way Ruby-on-Rails works. It also claims simplicity and ease of use. The trouble is that in order to start using it one has to learn Ruby-on-Rails first.

With your project people need to learn what MVC is, how it works etc. I tried to look at your examples and I could not understand at all how it works. I suspect that there is prior knowledge of other things required to grasp what you are trying to accomplish. And your assumption is that most people already have that knowledge. I don't know about others, but I probably don't have that knowledge, although I understand the http/html very well.

My suggestion is that you provide very simple examples that explain what each example does (what/how/why).

Thanks and good luck with your project.


----- Original Message -----
From: "Kristoffer Lawson" <setok_at_scred.com>
To: "XOTcl developers" <xotcl_at_alice.wu-wien.ac.at>
Sent: Monday, May 17, 2010 2:46:14 PM GMT -08:00 US/Canada Pacific
Subject: [Xotcl] Announcing: Spindle v0.1 — An MVC web framework for Tcl/XOTcl

I've grown to hate all the web frameworks I've used (non-Tcl), and
OpenACS was always impenetrable for me, so I decided to create one
that reflects how I think a framework should operate. It's very early
development stuff, but it works and has some hopefully intriguing
ideas. And yes, it's all XOTcl. Check it out:

http://github.com/Setok/Spindle

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/
_______________________________________________
Xotcl mailing list
Xotcl_at_alice.wu-wien.ac.at
http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Thu, 2 Sep 2004 21:55:11 +0300 (EEST)

% package require XOTcl
1.3
% xotcl::Class Foo
::Foo
% Foo instproc bar {a} {puts $a}
% Foo ob
::ob
% ob info args bar
% ob info body bar

Or have I misunderstood something about what should be going on? I would
assume args to return 'a' and body to return 'puts $a'?

Do they only work on procs? Does that not slightly go against the 'slot'
idea?


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

From: Neil Madden <nem_at_cs.nott.ac.uk>
Date: Tue, 25 May 2004 14:13:05 +0100

Thanks for the reply. Comments below.

On 25 May 2004, at 09:43, Gustaf Neumann wrote:
> On Monday 24 May 2004 22:57, Neil Madden wrote:
>> Hello all,
>>
>> Small feature request: could XOTcl be made to automatically [namespace
>> import] the ::xotcl::* commands into every object it creates?
>> ...
>> 1) Fully qualify everything - lots of xotcl::my, xotcl::self etc
>> everywhere
>> 2) Import xotcl namespace manually into each object namespace.
>
> or 3) do a gobal namespace import.

That's generally not considered good style when writing a package - the
global namespace is "owned" by the application author, and so packages
shouldn't put stuff there unless explicitly asked.

>
>> 2 is better than 1, but is still a bit of a pain to remember to do,
>> and
>> I seem to remember trying it and it not always working (I could be
>> wrong about that).
>
> (2) does not help too much, since xotcl is "namespace transparent",
> which means that it simply keeps the current namespace.
> This means that if you do a "namespace eval xxx {o m}"
> the method is evaled in the namespace xxx (and not o}.

OK. That's good to know. But this namespace transparency does not
extend all the way. For instance:

package require XOTcl
namespace eval foo {
     proc bar {} { puts "ns = [namespace current]" }
     xotcl::Class Bar
     Bar instproc foo {} { puts "ns = [namespace current]" }
     Bar a
}
foo::bar ;# prints "ns = ::foo"
foo::a foo ;# prints "ns = ::"

I would expect that any object I create in a namespace will always be
evaluated in that namespace, as is the case for procs. Given the
namespace transparency you describe above, this would solve all my
problems.

<snip memory usage discussion>

>> So, my feature request would be that all Objects [namespace import]
>> the
>> xotcl namespace automatically.[1]
>
> we had something like this in earlier versions of xotcl, but it was
> quite
> a pain, where it was quite easy to run into inifine loops, since
> procs of objects were resolved without the object name. To be on
> the safe side, every reference to a gobal tcl command had to be
> prefixed by a :: (eg: ::set x 1), otherwise an "obj proc set .."
> was overruling the tcl command.

I'm not sure what you mean here. I wasn't suggesting that methods
should be able to be called without passing a message to self, just
that "my", "self" etc should be imported into each object.

> Note that we have multiple
> command sets in xotcl, not only in the procs, but in the instprocs
> of classes (superclasses, mixins) as well.
>
> you can do the following as other alternatives:
> a) you can import the xotcl commands into your
> components workspace, and do a namespace eval
> there
> b) you can eval the object in the ::xotcl namespace

Neither of these alternatives are particularly appealing, as they
require the consumer of my package to know to do this, and it would
clutter up their code quite a bit. I suppose I could write a wrapper
proc for each object:

xotcl::Class MyClass -superclass xotcl::Class
MyClass instproc create {name args} {
     eval [linsert $args 0 next ${name}_]
     uplevel 1 [list proc $name {args} "uplevel 1 \[linsert \$args 0
${name}_\]"]
}

But this still feels like something XOTcl should be doing for me.

> ... and, you can write a global unknown handler, but that is not
> better than importing xotcl (or at least self+my) globally, what
> still looks like the best option to me.

In 8.5 (hopefully) my [namespace unknown] TIP (181) will get in, so you
could do this per-namespace. But it is still a hack. For now, I will
import into my package namespace, and use wrapper procs.

Neil.

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 10 Apr 2004 23:16:06 +0200

On Saturday 10 April 2004 22:51, Jeff Hobbs wrote:
> Gustaf Neumann wrote:
> > i get the impression you are fixing things that are not broken
> > in the general distribution. The configure stuff is
> > defined to produces always a file xotclsh or xowish, no
> > matter whether you compile with or without --with-xotclsh.
>
> This is just plain wrong. Drop the mega-binary idea. It is
> dead, dead, dead, dead.

 flame down, i know this, we have adressed this. per default,
 xotcl creates a file called "xotclsh", which is a tclsh script,
 and NOT the binary you are talking about. Do you oppose
 as well a tclsh script, having such a name?

> Tcl has had a very good dll mechanism
> for 7 years - all extensions should use it. So IMO Jim is
> fixing a configure system that *is* broken, at its very core
> design.

 look at our configure stuff, it has changend substantially
 in the last year. I would say, that i have personally invested
 over the last year more time into making xotcl's build system
 TEA compatible than into xotcl itself. We went through tough
 exercises such as building xotcl from outside directoris
            % mkdir -p /tmp/xotcl/unix
            % cd /tmp/xotcl/unix
            % ~/xotcl-1.2.0/unix/configure --with-all
            % make
            % make test
            % make install DESTDIR=/tmp
 as a result, xotcl was added to the tcl/tk distro for max OS X (Aqua).
 Correct me, if i am wrong, but I got the impression you are taking
 about the build system of xotcl, as it was about 2 years ago, and
 not about our current stuff.

-gustaf

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

From: Nicola E L'INSALATA (UniPI ) <"Nicola>
Date: Thu, 5 Jun 2008 16:42:36 +0200 (CEST)

Hi guys, I have a similar question.

So far, I developed a set of software components using XOTcl. These
components are deployed in a (third-party) C application equipped with a
Tcl interpreter.

Now project requirements are changing and they asked me to migrate the
whole framework to Java(!). I was then looking for a simple migration path
that would allow me:
1. to execute the code (as possible) as is in a Java environment
2. to progressively substitute XOTcl Classes with Java ones (the way I
used XOTcl mostly resemble Java paradigms, so I don't expect a hard
translation process)

What would you suggest? I gave a look to Jacl, but it seems to me that I
won't be able to run XOTcl code unless a Jacl XOTcl extension exist.

After Stefan answer, I also gave a look to Frag. Am I wrong, or the
underlying idea of Frag is to run Java code from a Tcl shell? Do things
work the other way round? Is Frag a porting of XOTcl or does it only use a
similar programming paradigm?

Thank you very much for your help and hope this is not too much off topic.

n.

On Gio, 5 Giugno 2008 12:25 pm, Stefan Sobernig wrote:
>> BTW, have you or somebody else already considered to make an XOTcl
>> implementation for Jacl (Tcl on Java)?
>
> Well, there is a cool piece of (on-going) work which is an
> amalgam of Tcl/XOTcl + Hecl/Jacl, mastered by Uwe Zdun:
>
> see http://frag.sourceforge.net/

From: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Wed, 31 Oct 2001 21:02:19 +0100

IOW, if I would like to write a C-level extensions to XOTcl
(which I desperately need to!) what functions from the
xotcl.c file should be taken into consideration ?

I know that the public API is (still) not supported
but I'd need some solution pretty fast.

Any ideas ?


Thanks,
Zoran Vasiljevic