Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 10 Apr 2004 21:33:41 +0200

On Friday 09 April 2004 17:10, Jim Lynch wrote:
> Hi,
>
> Subject says just about all: (fuzzy, but:) some aolservim Lyncher support
> included even if configure determines no aolserver

 i truely doubt it. can it be that you forgor a mat clean between different
 configures? i would recoemment to make a "distclean", since this
 removes the config.* files as well.

> Can't fix today; this will take a bit of digging to find all the aolserver
> stuff in xotcl, and make it subject to non-inclusion when user says no.

 there is no need to dig deep. Do:
   grep '#if.*AOL' xotcl*/generic/*.[ch]

 how comes that you believe this?

 -gustaf neumann

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

From: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Mon, 6 May 2002 11:16:00 +0200

int
XOTclSelfDispatchCmd(ClientData cd, Tcl_Interp *in, int objc, Tcl_Obj *CONST objv[]) {
  XOTclObject *self;
  int result;
  
  if ((self = GetSelfObj(in))) {
    result = callMethod((ClientData)self, in, objv[1], objc, objv+2, 0);
  } else {
    result = TCL_ERROR;
    panic("Self Dispatch: could not resolve self"); /** Urks !? **/
  }
  return result;
}


Do we need to trigger panic (i.e. crash program) when self cannot be
resolved ? Or is is sufficient just to return error ?

Cheer's
Zoran

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 26 Jan 2012 13:59:54 +0100

On 26.01.12 13:54, Gustaf Neumann wrote:
> The new parameters are more powerful and general than the
> xotcl-style "assign" method; so i tend to believe the
> latter is obsolete.
i should have added... at least for checking/conversion
purposes. -gn

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 05 Aug 2010 09:59:08 +0200

Dear all,

In my understanding, Kristoffers point was that although he is using
XOTcl since many
years (i see postings from him more than 10 years ago) and although he
is a experienced
programmer, he was not aware of the problem with argument values
starting with a dash
(certainly not all, e.g. negative numbers are fine), and he was not
aware of the escape
mechanism (which was added to XOTcl early 2003, see Changelog).

The primarily problem is external input, unfortunately, one weak element
of most
scripting languages. Similar problems lurk around in Tcl in scripts like

   set file1 -force
   set file2 -violence
   file delete $file1 $file2

where one should certainly use "--" to avoid the problem ... once the
developer is are aware of the danger. If a developer is not aware it,
the tests he is writing are most likely not covering it properly.
But a developer frequently writing tests is most likely aware it.

Btw, google codesearch returns more than 5 times more hits for "file
delete $"
than for "file delete --". It is not unlikely, that there are many
such problem lurking around in may tcl scripts. The problem is not
only "file delete" but as well "file copy", "file rename,
any many other tcl commands supporting "--" (switch, lsearch, ...).
And the problem is not only about flags starting with a dash (just
syntactic sugar),
but as well with all other cases, where the interpretation of a <value>
depends
on an interpretation of a <keyword>, especially, when the <keyword> is
optional. In Tcl, one cannot distinguish between "-force" passed as a
literal
or "-force" passed via variable. If we could, life would be in this respect
easier. Compiled languages have it easier, when they require that the
<keywords> are available at compile time.

The case with the dash arguments in XOTcl is especially nasty to the
unaware, since the standard configure method determines on the "-"
(a) where the last argument list ends, and (b), what to call as a method.
If user-data is passed to the object creation, using the list notation is
therefore a must (as mentioned by Artur)

People fully aware of the XOTcl flexibility have no big problem with this,
since they can write their own "configure" method (this method
implements the dash interpretation) and use this (e.g. via mixins)
where appropriate.

-gustaf neumann

From: Jonathan Kelly <jonkelly_at_fastmail.fm>
Date: Sun, 29 Jul 2012 09:38:21 +1000

Stephan and others,

thanks for the input. I actually spent some hours yesterday having
another go on my laptop at home (which is Windows 7).

Before I got started I thought I should make my cygwin was up to date,
and as I was having a look at the setup, I noticed a set of packages
mingw-cc-* in development. After a little googling these looked like new
packages... so always one to do things the difficult way, I thought I'd
give it a go, seeing as I'm already using cygwin.

So I installed the mingw-gcc-{core,binutils,g++,pthreads,runtime}
packages in cygwin. (I don't know that I needed all those packages, I
just took a guess).

I downloaded TCL and TK source which was the new 8.5.12 release.

Setup my destination directory
mkdir /cygdrive/c/Tcl
mkdir /Tcl
mount c:/Tcl /Tcl

I ran configure:

./configure --build=i686-pc-mingw32 --host=i686-pc-mingw --prefix=/Tcl

make test came out with

all.tcl: Total 27048 Passed 26164 Skipped 870 Failed 14

and that seemed like a good result. From what I could see the failures
were about linking (to be expected) and some stuff about character
encoding and unicode.

So I compiled TK and ran the demo test. All good.

Now onto NX.

I got the source from git, and tried a configure ... and then my head
started to hurt. Eventually I worked out this is the configure I needed

  ./configure --build=i686-pc-mingw32 --build=i686-pc-mingw32
--host=i686-pc-mingw32 --prefix=/Tcl
--with-tcl=/cygdrive/c/tcl8.5.12/win
--with-tclinclude=/cygdrive/c/tcl8.5.12/generic

I did have to tweak the configure script and Makefile.in to get it all
working though.

The issue is that configure wasn't working out that it needed to use
cygpath when it was "checking for cygwin variant". It was looking for
*-mwin32*|*-mno-cygwin* in TCL_EXTRA_CFLAGS but that is not used in this
build. So this is what I came up with - My addition is the case
${TCL_CC} bit ...

     case "`uname -s`" in
     *CYGWIN_*)
         { $as_echo "$as_me:${as_lineno-$LINENO}: checking for cygwin
variant" >&5
$as_echo_n "checking for cygwin variant... " >&6; }
         case ${TCL_EXTRA_CFLAGS} in
         *-mwin32*|*-mno-cygwin*)
             TEA_PLATFORM="windows"
             CFLAGS="$CFLAGS -mwin32"
             { $as_echo "$as_me:${as_lineno-$LINENO}: result: win32" >&5
$as_echo "win32" >&6; }
             ;;
         *)
           case ${TCL_CC} in
             *mingw*)
             TEA_PLATFORM="windows"
             ac_cv_prog_CYGPATH="cygpath -w"
             CYGPATH=$ac_cv_prog_CYGPATH
             ;;
             *)
             TEA_PLATFORM="unix"
             ;;
           esac
             { $as_echo "$as_me:${as_lineno-$LINENO}: result: unix" >&5
$as_echo "unix" >&6; }
             ;;
         esac
         EXEEXT=".exe"
         ;;
     *)
         ;;
     esac


Also, in the Makefile.in ... I changed the genstubs rule to use the
CYGPATH ... as the build is using the new Windows executable to run the
getStubs.tcl .. but the new build doesn't know about cygwin paths...

genstubs:
     $(TCLSH) `_at_CYGPATH@ $(TCL_SRC_DIR)/tools/genStubs.tcl` \
         `_at_CYGPATH@ $(src_generic_dir)` \
         `_at_CYGPATH@ $(src_generic_dir)/nsf.decls` \
         `_at_CYGPATH@ $(src_generic_dir)/nsfInt.decls`

so make ran through OK, and a make test *seemed* to work ... though i
couldn't see any stats ... but nothing that looked like errors either.

I did a make install ... and fired up the new shell and the Greeter
test and it worked! Ta Dah!

Again, I'm happy to be the guinea pig if you want to get this working
"officially".

Now, have to get onto learning nx.
next

Jonathan.

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sat, 11 Aug 2001 01:00:59 +0300 (EEST)

Situation:

I create a class "C" with instproc "foo".
An object is created from C called "ob".

Problem:

The commands "ob info procs", "ob info args" and "ob info body" do not
work as I would expect them to. In particular, there doesn't seem to be a
way of finding out the body and arguments for the instproc "foo" from the
object. I could do this by asking the class, but I specifically would
like a uniform way to do this, without caring whether the methods are
inherited or not. Is this intended? Why?

% package require XOTcl
0.85

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

From: Martin Kendall <martinkendall_at_email.com>
Date: Fri, 10 Feb 2006 17:03:17 -0000

As there are so many excellent ports of Tcl to the Pocket PC:

http://wiki.tcl.tk/2946

http://wiki.tcl.tk/13487

http://www.evolane.com/software/etcl/

 

I wondered if anyone had compile xotcl to run with one of these before I
embark on evC++

 

Thanks

 

Martin

 

 

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 27 Oct 2010 08:42:37 +0200

Not sure, what's wrong on your side.
i can't see a problem with this code,
and it works for me.

-gustaf

% Object create a
::a
% Object create a::b
::a::b
% a public method tst args {puts [self]};
::a::tst
% a::b public method tst args {puts [self]};
::a::b::tst
% a tst
::a
% a::b tst
::a::b
%


On 26.10.10 22:47, vitick_at_gmail.com wrote:
> I was reading the migration guide, and at the end it talk about the incompatibilities. I have specifically tested the "Calling objects like methods" and I do not understand it. It just doesn't work right.
> Example:
>
> Object create a;
> Object create a::b
>
> a public method tst args {puts [self]};
> a::b public method tst args {puts [self]};
>
> a tst; #works, returns ::a
> a::b tst; #error, invalid command self
>
> a::b eval self; #works, returns ::a::b
>
>
> Thanks
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Will Duquette <will_at_wjduquette.com>
Date: Wed, 28 Sep 2005 19:49:05 -0700

On Sep 28, 2005, at 9:23 AM, Kristoffer Lawson wrote:
>
> On 28 Sep 2005, at 18:49, Donal K. Fellows wrote:
>>
>> 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
>>
>
> Well yeah, I'd disagree in the sense that if any OO framework goes
> somewhere near the core, I'd like to see Tk being implemented in
> terms of it (or indeed any other C-based extension which uses
> objects). Not immediately, of course, but in the long run.

It would be nice to have a C-API; but I think it would be better to
get the Tcl API stable first, and then rationalize the internals
based on where we've gotten to before opening them up.

Will

-------------------------------------------------------------
        will -at- wjduquette.com | Catch our weblog,
http://foothills.wjduquette.com | The View from the Foothills

From: Uwe Zdun <zdun_at_wuw.at>
Date: Tue, 2 Dec 2003 09:55:27 +0100

On Monday 01 December 2003 20:02, Jeff Hobbs wrote:
> > * New build system:
> > - per default no shells are built
> > - new configure switches eg. --with-xotclsh, -with-actiweb
> > --with-all
>
> Am I to understand this means that xotcl from CVS (or source)
> now builds in a somewhat TEA-compatible fashion?
> ./configure --with-tcl=...
> make
> make test
> make install
> and nothing but a stubs-based $tcl_library/../xotcl1.1/* is
> installed (perhaps with docs and demos somewhere)?
>

that's the intent of these changes. Per-default under Unix only the
XOTcllib with stub support is compiled. other (compiled) packages
must be activated with configure flags. under Unix we install:
  libxotcl1.1.so
  libxotclstub1.1.a
  xotcl1.1/*
to /usr/local/lib. Under windows everything goes into xotcl1.1/*, including
libxotcl*.dll.
Having everything in xotcl1.1/* (also the libs) is no problem ...
its just removing a ".." from the generated pkgIndex.tcl file. It this an
issue?

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