Weblog Page

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Thu, 01 Apr 2004 11:21:52 +0200

Hi,

you shouldn't have to install/uninstall Tcl ... first check whether the
XOTcl RPM
works for you. If not, you can get the Tcl version that is installed on
your system,
unpack it and run

./configure --prefix=/usr --exec-prefix=/usr

there. Perhaps you need make as well. Now you can compile XOTcl against
these
sources and only install XOTcl ...

Uwe



Alexandre Dehne wrote:

>Hello,
>
>In order to use biok, I have to install xotcl. My problem with xotcl
>installation is that my system is under Fedora and there is no tclInt.h
>file under this distribution (even with the tcl-devel package). Of
>course, I can uninstall the tcl package and install tcl manually but, by
>uninstalling tcl package, other packages are going out and that put me
>in trouble ...
>
> Any suggestion on the way to manage my tclInt.h problem ?
> Does anyone have an rpm for fedora ?
>
>Thanks in advance
>Alexandre
>
>
>
>_______________________________________________
>Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
>http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>
>

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 9 Apr 2002 16:43:41 +0200

Dear XOTcl community,

here comes the announcement of XOTcl 0.9.4.
This is supposed to be the last patch release
before XOTcl 1.0. We fixed a lot of problems in
this patch release, so we hope that the migration
to 1.0 will be smooth...

best regards
-gustaf neumann
=======================================================================
Announcing XOTcl 0.9.4
**********************

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 0.9.3 are:

  - fixes:
 
     * separate reference counting for XOTcl objects and classes
       to avoid references from tcl_obj's internal representation
       to freed memory

     * fixes for AOL-Server (many thanks to Zoran Vasiljevic for
       that and for his great help during fixing the problems above)

     * improved portability: horrible macro substitution
       bug, when USE_ALLOCA or USE_MALLOC was specified; these
       are used for some platforms such as AIX

     * fixing path search for XOTcl library (bug was introduced in
       0.9.3 in connection with TEA compliance)

     * fixed a bug in copy/move (many thanks for Artur Trzewik
       for reporting this) in connection with constructors
       (constructors are not called automatically in copy/move
       operations anymore)

     * various small fixes in libraries (e.g. HTTP support,
       generation of pkgIndex-files, using "my", ...)

  - enhancements:

     * new global command "my":
       one can use now:

         Class Counter -parameter {{n 0}}
         Counter instproc ++ {} { my incr n }
         Counter instproc print {} { puts "actual value: [my n]"}

         Counter c1
         c1 ++
         c1 print

       In earlier versions it was neccessary to use "[self]"
       instead of "my". This change reduces the number of
       special characters in XOTcl programs.
       "[self]" will continue to be supported by XOTcl.
      
     * extended semantics of "new"

        a) Object new ...
        b) Object new -childof ...
        c) Object new -volatile ...
        d) Object new -volatile -childof ...

       where (a) creates now "global" objects not in the global
       namespace anymore, but in the ::xotcl namespace, (b) can
       be used to create objects as child of other objects
       (e.g. as children of the actual object [self]; the objects
       are deleted, when the specified object is deleted). (c)
       creates are "global" objects as in (a), but they are
       deleted, when the scope of the current
       tcl-proc/object-proc/instproc is left and (d) is a
       combination of (b) and (c).

  - optimizations:

     * XOTcl is trying to keep Tcl_Objs of type tclCmdNameType
       instead of converting it to XOTclObjectType agressively.

     * A patch for Tcl 8.4a3 is available from the XOTcl web site
       for performance hungry applications to provide special
       byte-code-support for xotcl, that yields for classical
       benchmark programs up to 40%. This patch is not likely to
       be integrated into the general Tcl core in the new or
       distant future.
  
 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

From: John McGlaughlin <jmcglaug_at_cisco.com>
Date: Tue, 05 Apr 2005 15:17:06 -0400

Jeff,

Can an extension be added to tkcon so that the interpreter becomes aware
of XOTcl proc, instprocs and associated vars for type ahead capability.

Lazy,

John

From: Mark Harrison <markh_at_usai.asiainfo.com>
Date: Thu, 7 Jun 2001 05:13:09 +0800

Zoran Vasiljevic <zoran_at_archiware.com> wrote:
> This "BitKeeper" is a commercial product requiring license ?

Not for open-source software. The license is quite interesting...
If you are willing for your transaction logs to be mirrored to
their site, then it is free. If you wish to disable public
accessibility of your log files, then you must pay.

BTW, they say some nice things about Tcl/Tk on their website.

Rgds,
Mark

--
Mark Harrison           markh_at_usai.asiainfo.com "the arms merchant of choice
Chief Software Architect markh_at_markharrison.net  for virtually every combatant
AsiaInfo Holdings, Inc.       +86-1390-138-3470  in China's network wars..."
Beijing/Santa Clara/Hong Kong     icq:106821430         - Wall Street Journal

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Thu, 21 Oct 2004 14:17:53 +0200

Hi Artur,

if you invoke the object command (==ID) without any arguments, it
returns the fully qualified name:

Object a
puts [a]

-> ::a

Uwe


mail_at_xdobry.de wrote:

>Hi!
>
>I work currently with 1.3.2 and have one problem
>that relate to namespace handling.
>I would need new object method that could return full name of
>object
>(similar to "namespace origin" command)
>
>I could not find any possibility to get it from
>build-in Object methods.
>I would expect that "self" or "my" on object would work.
>
>So I must programm new global Object instproc:
>
>Object instproc fullname {} { self }
>
>so it work
>
>Object a
>a fullname
>
>
>>::a
>>
>>
>
>Is were any better possibility to get the same result?
>If not it could be idee to extend object base interface (for example
>info command)
>
>Artur Trzewik
>_______________________________________________
>Xotcl mailing list
>Xotcl_at_alice.wu-wien.ac.at
>http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>
>

-- 
Uwe Zdun
Department of Information Systems, Vienna University of Economics
Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746
zdun_at_acm.org, uwe.zdun_at_wu-wien.ac.at

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 15 Jul 2006 16:00:10 +0200

Kristoffer,

the following might help you...
-gustaf


# a little helper
Object instproc apply {list args} {foreach o $list {eval $o $args}}

# turn off checking for all objects
Object apply [::xotcl::Object allinstances] check ""



Kristoffer Lawson schrieb:
>
>>
>>
>> On 11 Jul 2006, at 19:24, Uwe Zdun wrote:
>>
>>> The method "check" can be used to turn off assertions. The example
>>> from the tutorial:
>>
>> That is per-object. I am wondering if there is anything that would be
>> for everything.

From: Rick Hedin <rhedin_at_aquifer.geology.uiuc.edu>
Date: Mon, 5 Feb 2001 08:18:16 -0600

Hello all.

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

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

Or maybe I should:

pack [icanvas tkpath] -fill both -expand true

Or give my object a truly wicked name:

Icanvas .f.icanvas ;# Will this work?

Or wrap every tk command in my xotcl object.

What is your thinking regarding widgets from XOTcl?


        Regards,

        Rick

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Fri, 24 Jan 2003 18:03:45 +0200 (EET)

On Fri, 24 Jan 2003, Gustaf Neumann wrote:

> > Oh, I meant to say that an option to [new] is not necessarily the best.
> > Often (at least in my case) it is a method of an object which creates
> > an instance and returns it, like:
> >
> > set msg [$cmdReader getNewMessage]
> >
> > So at the level where I want the automisation I don't directly call new.
> > Naturally this could be changed to accommodate the use of new, but then
> > my interface wouldn't be as cleanly split up.
>
> i don't get your point: getNewMessage has to create the Object,
> so it can use certainly new (with all variants). is your argument:
> the caller of newmessage should decide, whether the created
> object should be dynamically reclaimed or not?

Yes, obviously getNewMessage will use [new], but it wont be using [new
-bind] for obvious reasons! The caller is the one that wants to bind it to
a variable, so yes my argument is that the caller should decide. In fact,
it could be argued that the same applies to -volatile. That there are
cases when a new object should be returned by some method other than [new]
but the caller is generally the one that wants to decide the dynamics of
the object.

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

From: Schofield, Bryan \(GE Transportation\) <"Schofield,>
Date: Wed, 10 Nov 2004 09:17:19 -0500

Gustaf/Uwe -

I found a little bug in 1.3.3 that I downloaded on October 15th from=20
  http://media.wu-wien.ac.at/download/xotcl-1.3.3.tar.gz

The following causes a core dump on my Solaris workstation:

Object o
o proc foo {{-foo 1}} {} {
   puts "foo: $foo"
}

o foo
#--> "foo: 1"

o foo -foo 0
#--> "foo: 0"

o foo -foo
#--> BOOM!



Just thought I'd pass that on. Regards
-- bryan

From: jim <j_marvin_at_localnet.com>
Date: Thu, 11 Dec 2003 06:29:43 -0500

jim wrote:
>i still wonder if there is a way to wrap some xotcl files into the exe
>so i dont have to rely on having the whole xotcl install on the users
>machine . since i am using just the very basic
>features of xotcl right now it seems that i wouldnt need all of those
>files.
>
>i have some documentation now with freewrap that explains this process
>i'm wondering about and i might be able to get it to work but dont know

>what xotcl files need to get wrapped.
>
>
Hi,
While I cant speak for freewrap, (its been years..), I think that the
whole point of "wrapping" is to avoid relying on having xotcl installed
on the users machine. Maybe I am missing something...
But anyway, I can speak for tclkit and starkits, maybe you could grab
the XotclIde starkit/pack and "unwrap it" and see whats is going on..
For sure, as a minimum, you would need to include the the xotcl dll, ~
120Kbytes. If you are using some of the xotcl library procs, eg comm,
then you would add those as well...
Let me know if you some quick instructions on getting starkits up and
running...
regards,
nicolas boretos

Hi Nicolas-

thanks for the tip. it seems to be working. I deleted the xotcl
directories off my system to test it.
I have one directory set up called c:/elevatorApp that contains 3
files... pkgIndex.tcl libxotcl1.1.dll and
elevator6.tcl .... and of course the elevator6.exe file.

seems to be all the files I need. now after I error trap I can
distribute my first small gui xotcl/tcl app on my website.

thanks,
marvin