Weblog Page

From: Clinciu Andrei <the.lostone_at_yahoo.com>
Date: Wed, 18 Mar 2015 08:55:16 +0000 (UTC)

Hi
I was wondering if anyone uses NSF/NX in VIM so that it detects methods (like Vim detects proc tags) so you can jump to a definition and see the colouring when editing? Does anyone have a modified version that works with the tag generation & detection?

I have been searching for a while and tried modifying the existing (old) Tcl vim file but it doesn't seem to do the job, while the namespaces and procs work wonderfully it's very inconvenient when working with NX because of the time lost in searching for the function to see the headers, etc..
Thanks in advance. With regards,
Clinciu Andrei George

"Vorba buna, zambetul si fapta binefacatoare sunt raze ale soarelui rasfrante in sufletul omului."
"A good word, a smile and a good deed are just like rays of the sun reflected in man's soul."   by Nicolae Iorga

From: <mail_at_xdobry.de>
Date: Wed, 06 Jun 2007 17:36:45 +0200

Hi!

There is no full documentation but the API is quite simpel if
you know how Tcl base C-Api works (So you can see into Tcl C-Api documentation first)

See C Header File
xotclDecl.h where you can find public API to XOTcl

As Examples see file
\xotcl-1.5.3\library\store\XOTclGdbm
It is programmed as XOTcl based C-Extension

I have also developed one XOTcl C-Extension (bridge to C++ lib)
as another example
http://www.xdobry.de/esperantoedit/xotclhunspell1.0.tar.gz

Artur

Hi All   I have just started exploring XOTcl but I am unable to find the documentation for XOTcl’s C API.   Can anybody point me to any documentation available on the web or do I have to explore the .h files to gather that   thanks

From: Rene Zaumseil <r.zaumseil_at_freenet.de>
Date: Mon, 30 Jul 2012 21:28:32 +0200

Am Montag, 30. Juli 2012, 11:10:05 schrieb Gustaf Neumann:
> On 28.07.12 22:23, Rene Zaumseil wrote:
> > Am Freitag, 27. Juli 2012, 12:32:20 schrieb Gustaf Neumann:
> >
> > - got an error that wget is not installed;
> >
> > installed wget, added GnuWin32/bin to the path
> >
> > Ok, I have the sources downloaded under unix and then copied to windows.
>
> maybe, your kbs.tcl script could obtain wget automatically?
> This would
> make life for newbies easier. i had the impression, the
> script was
> supposed to work under win.
I will remember this suggestion for the next version. Thank you.
>
> > I have installed the 20110211 version last year because my older
> > installation from the tcl sourceforge side was not working anymore.
> > I think it was a problem with missing libraries.
>
> For the record, the version " mingw-get-inst-20120426" works
> fine.
>
> > Oh,may be here. I have put the kbs directory under:
> > C:\MinGW\msys\1.0\home\rene
> >
> > Could you also try to put the kbs directory under these path?
>
> See the previous mail, the "path" in general was not the
> problem, but the drive.
> After the copy, the script kbs.tcl continued nicely until it
> run again into
> troubles in the compilation of vfs.c (trying to access
> incomplete type
> Tcl_StatBuf, see below). According to the sources,
> definition of
> Tcl_StatBuf has changed in tcl 8.5.12 (most likely it will work
> with 8.5.11). I hacked locally vfs.c by defining a type
> Tcl_StatBuf_ (using the
> definition of pat thoyts in [1]. Then vfs compiled fine.
Oh, I'm currently only have 8.5.11 checked. 8.5.12 will be in the
next release (after my vacation). And I will add nsf and may be even 8.6 ;)
There is always something to change with new versions. So you
have the first thing resolved.
BTW. if you only want to build nsf and it depends only on tcl/tk you
could try:
 ./kbs.tcl install tcl8.5 tk8.5 nsf2.0
>
> Then I run than into the problem:
>
> --2012-07-30 10:28:40-- http://equi4.com/pub/tk/tars/zlib.tar.gz
> Auflösen des Hostnamen »equi4.com«.... 188.142.57.184
> Wiederverwendung der bestehenden Verbindung zu www.equi4.com:80.
> HTTP Anforderung gesendet, warte auf Antwort... 200 OK
> Länge: 502488 (491K) [text/plain]
> In »zlib.tar.gz« speichern.
>
> 100%[========================================================> ] 502.488
> 606K/s in 0,8s
>
> 2012-07-30 10:28:41 (606 KB/s) - »zlib.tar.gz« gespeichert [502488/502488]
>
> === Configure
> C:/Users/neumann/Downloads/kbs/buildWindowsNT/zlib1.2.3-static
> /usr/bin/env: ./configure: No such file or directory
> === Require error: zlib1.2.3-static
> child process exited abnormally
> Error in execution of 'install kbskit8.5':
> === Package failed for: zlib1.2.3-static
> Require failed for: zlib1.2.3-static
Was it your second attempt? If there is an error in the Configure
script you should remove the build*/<package> dir and then start
again. Because configure can take some time the Configure script
will only be called if the build*/<package> dir doesn't exists.

So try to remove the dir and start again. You should have a copy
of the zlib1.2.3/* files insisde the build*/<package> dir. The
line in kbs.tcl Package zlib1.2.3-static, Configure script is:
  eval file copy [glob [Get srcdir]/*] .

HTH
rene

From: <j_marvin_at_localnet.com>
Date: Tue, 9 Dec 2003 06:19:27 -0500

Hi-

In the simple code below I'm working on to simulate an elevator I am
having a little trouble with the
constructor initializing. I get an error that says "cant read
currentFloor...no such variable."
I thought I had set up the constructor right. I tried following this
format from the manual ---

Room instproc setCeilingColor color {
    my set ceilingColor $color
  }

 Room instproc init args {
    my setCeilingColor white
    next
  }

Here is the code. It bombs out in the body of the method named request
when it tries to read the first
$currentFloor variable. I hope I am getting the idea and it is
something kind of simple I am missing.
Please offer a suggestion if what I am doing wrong is apparent to you.

thank you,
marvin

 package require XOTcl;
    namespace import -force xotcl::*
    
    Class Elevator
    
    
   Elevator instproc setInitFloor floor {
   my set currentFloor $floor ;
  }
    
   Elevator instproc init args {
  my set setInitFloor 1;
    next;
   }
    
    Elevator instproc getFloor args {
    puts $currentFloor;
    
    }
    
    Elevator instproc request requestFloor {
        
       
        my set request $requestFloor;
       
    while {$requestFloor > 0} {
        
         if {$currentFloor < $requestFloor} {
            set currentFloor [[Ride getFloor] + 1];
            puts "going up...current floor is $currentFloor";
    }
        if {$currentFloor > $requestFloor} {
            set currentFloor [[Ride getFloor] - 1];
        }
        
        if {$currentFloor == $requestFloor} {
            set requestFloor 0;
            
        }
     }
    
    puts "current floor is $currentFloor";
}

set requestFloor 4;

Elevator Ride;

Ride request $requestFloor;

Ride destroy ;

From: Victor Mayevski <vitick_at_gmail.com>
Date: Wed, 29 Jun 2011 10:52:03 -0700

In my code I have objects that need some attributes only sometimes.
So, that was my attempt to reduce the code and not have to test for
the existence of that attribute but just re-create it. In this case, I
ended up just having that attribute permanently in all objects at all
times. It is not that I didn't have any other way of doing it, it is
just that I thought it would have been an elegant and short way of
doing it.


Here is another curious code that could be a bug, at least it doesn't
seem to behave as expected:

% Object create o
::o
% o attribute {a oldvalue}
::o::a
% o a
oldvalue
% o delete attribute a
% o a
::o: unable to dispatch method 'a'
% o attribute {a newvalue}
::o::a
% o a
oldvalue



Also, is it possible for "object delete attribute a" to not complain
if the attribute does not exist, may be via "-nocomplain" switch or
just by default?

Thanks,

Victor


On Wed, Jun 29, 2011 at 3:51 AM, Stefan Sobernig
<stefan.sobernig_at_wu.ac.at> wrote:
> Victor,
>
>>> %Object create o
>>> ::o
>>> %o attribute {a oldvalue}
>>> ::o::a
>>> %o a
>>> oldvalue
>>> %o attribute {a newvalue}
>>> ::o::a
>>> %o a
>>> oldvalue
>
> Forgot to ask: Why do you take this path (changing the default of the
> attribute slot) in the first place? If you want "a" to have the value
> "newvalue" assigned, why don't you simply say:
>
> o a newvalue
>
> //s
>
>
>

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Mon, 01 Sep 2003 16:18:02 +0200

Zoran Vasiljevic wrote:
> On Monday 01 September 2003 11:56, Catherine Letondal wrote:
> >
> > > You should compile wish with symbols (./configure --enable-symbols).
> > > The same appiles for xotcl as well.
> >
> > When I compile xotcl after a ./configure --enable-symbols the compilation
> > just fails to compile because it looks for a libtcl8.3g.so file (or maybe I
> > should have built the tcl library before?):
>
> Of course, you need to compile Tcl with --enable-symbols.
> This will produce the libtcl8.3g.so library.
>
> > I don't remember how it is I still have a libxotcl1.o.so built!!
> >
> > No wonder there is a segmentation fault.
> >
> > Thanks a lot for any help,
>
> No problem. Just get a clean compilation of xotcl first.
> If the problems persist, then recompile all with --enable-symbols
> and give it another try.
>

Ok: everything is recompiled with --enable-symbols and the compilation of Xotcl
went without pbs.
I still have the seg fault:

% gdb ~/Work/TclTk/proto/mywish2/mywish core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.7"...
Core was generated by `/home/letondal/Work/TclTk/proto/mywish2/mywish'.
Program terminated with signal 9, Killed.
Reading symbols from /local/lib/libGLU.so.1...done.
Reading symbols from /local/lib/libGL.so.1...done.
Reading symbols from /local/lib/libglut.so.3...done.
Reading symbols from /home/letondal/packages/seqiotcl/seqiotcl.so...done.
Reading symbols from /local/lib/libxotcl1.0g.so...done.
Reading symbols from /local/lib/libtk8.3.so...done.
Reading symbols from /local/lib/libtcl8.3g.so...done.
Reading symbols from /usr/lib/libX11.so.4...done.
Reading symbols from /usr/lib/libm.so.1...done.
Reading symbols from /usr/lib/libc.so.1...done.
Reading symbols from /usr/openwin/lib/libSM.so.6...done.
Reading symbols from /usr/openwin/lib/libICE.so.6...done.
Reading symbols from /usr/openwin/lib/libXmu.so.4...done.
Reading symbols from /usr/openwin/lib/libXext.so.0...done.
Reading symbols from /usr/openwin/lib/libXi.so.5...done.
Reading symbols from /usr/lib/libpthread.so.1...done.
Reading symbols from /local/lib/libtcl8.2.so...done.
Reading symbols from /usr/lib/libsocket.so.1...done.
Reading symbols from /usr/lib/libnsl.so.1...done.
Reading symbols from /usr/lib/libdl.so.1...done.
Reading symbols from /usr/openwin/lib/libXt.so.4...done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/lib/libmp.so.2...done.
Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...done.
Reading symbols from /usr/lib/libthread.so.1...done.
Reading symbols from /home/letondal/Work/TclTk/proto/iMol/iMol.so...done.
Reading symbols from /home/letondal/Work/TclTk/proto/i3DMol/lib/i3D.so...done.
#0 Tcl_PopCallFrame (interp=0x19c380) at ./../generic/tclNamesp.c:359
359 iPtr->framePtr = framePtr->callerPtr;
(gdb) l
354 * of call frames before deleting local variables, so that traces
355 * invoked by the variable deletion don't see the partially-deleted
356 * frame.
357 */
358
359 iPtr->framePtr = framePtr->callerPtr;
360 iPtr->varFramePtr = framePtr->callerVarPtr;
361
362 /*
363 * Delete the local variables. As a hack, we save then restore the



Any idea about the problem?

Thanks a lot in advance,

--
Catherine Letondal

From: Michael A. Cleverly <michael_at_cleverly.com>
Date: Thu, 17 Apr 2003 12:11:20 -0600 (MDT)

Since every class is also an object, its possible to define both procs &
instprocs for it. The instprocs define methods that objects of this class
will have, while the proc (as I understand it) proc would define a method
on the class object, but not for objects of the class. (Yes?)

However, during my interactive playing around trying different things I've
found that as soon as I define a proc on the class object any subsequent
use of [info classchildren] leads to a segfault.

$ tclsh
% package require XOTcl
1.0
% namespace import xotcl::*
% Class C
::C
% C info classchildren
% C proc foo args {}
% C info classchildren
Segmentation fault

Is it better to avoid defining procs on the class object, or am I
misunderstanding when & where to use [info classchildren]?

Michael

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Fri, 10 Aug 2012 09:47:57 +0200

On 10.08.12 03:39, Jonathan Kelly wrote:
> Hi,
>
> I'm trying to get my head into the "named object" space. I was looking
> at the container example for a way in and now I'm stuck (again).
>
> nx::Class create SimpleContainer {
> :property {memberClass ::MyItem}
> :property {prefix member}
>
> # Require the method "autoname" for generating nice names
> :require method autoname
>
> # The method new is responsible for creating a child of the current
> # container.
> :public method new {args} {
> set item [${:memberClass} create [:]::[:autoname ${:prefix}] {*}$args]
> }
> }
>
> What does the ":require method autoname" do?
One can load the definition of single method via the
"require method".
It is somewhat similar to traits, but brings in just a
single method (might
be an alias, or a scripted defintion, etc.). See e.g.
tests/method-require.test

In this case, the predefined method "autoname" is registered
as a method
of "SimpleContainer".

> I think I understand what [:autoname ${:prefix}] is/does but what on
> earth is "[:]::[:autoname ${:prefix}]" ?
The single colon ":" is used to parameterize the method
invocation.
See Listing 33 in
http://www.next-scripting.org/docs/2.0b3/doc/nx/tutorial/index1#_method_resolution
When called without arguments, it returns the current object.

the line in question is unabbreviated

    "[self]::[[self] autoname ${:prefix}]"

and is after substitution a name consisting of the current
object
appended by "::" and an autonamed enity (using the variable
"prefix" as a stem).

The method autoname is the same as
http://media.wu.ac.at/doc/langRef-xotcl.html#Object-autoname

If one does not care about the names of the created subobjects,
one could use as well:

     SimpleContainer public method new {args} {
        ${:memberClass} new -childof [self] {*}$args
      }

Hope this helps
-gustaf

From: Neil Madden <nem_at_cs.nott.ac.uk>
Date: Wed, 19 May 2004 21:20:23 +0100

On 19 May 2004, at 21:05, Michael Schlenker wrote:
>> Woah there! I said nothing about mutable objects/values.
>
> You talked about adding instance variables which are mutable objects
> by definition, while Adam talked about mutable objects directly.

What do you mean here? Variables are mutable, yes. They're not
"objects" though (they're neither XOTcl objects, or even Tcl_Objs
(values) - I assume they're normal Tcl namespaced variables, but XOTcl
might implement them differently). I'm proposing a change of interface
that's all. At present we have a "special" variable (the mixin list)
which is hidden behind the [$obj mixin] and [$obj info mixin] commands.
All I am saying is to bring that variable into the limelight to be an
actual instance variable of the object, and use the usual methods to
alter it. It's always been mutable, just not in place.

(By "immutable" I would be referring to something like a "final"
variable in Java - you can assign to it once, but never again.)

>
>> Mutable variables are all that is needed, and they exist already (in
>> fact, you have to go an extra step to get immutable variables).
>
> Of course, mutability is what variables are all about... ;-)

Not in all languages! C.f. prolog, various rule interpreters etc. Of
course, that's probably an abuse of the term "variable", but I
digress... :^)

>
>> The idea is to reuse things like [lappend], [linsert], [lreplace]
>> etc, without creating lots of [mixin_append], [mixin_replace] etc
>> etc. That's the duplication of effort.
>
> You can reuse them, correct me if I'm wrong:
>
> set mixins [$obj info mixins]
> # use standard list operations as you like
> set mixins [linsert $mixins 0 $newMixin]
> lappend mixins $anotherMixin
> $obj mixin $mixins
>
> Where is the huge benefit of a magic instance variable containing the
> list of mixins? I just don't see the benefit, but i see that you would
> add a magic variable name to objects where none existed before.

Well, you have magic variables now - they're just hidden behind the
[$obj info mixins]/[$obj mixin]. The difference I was proposing was to
get rid of these special methods, and replace them with a regular
instance variable:

$obj lappend mixinlist $somemixin
$obj set mixinlist [linsert [$obj set mixinlist] 0 $newMixin]
etc

Just a trade off between altering the list in the "standard" way using
the normal variable methods, or via a set of additional mixin-specific
methods (the mixin_prepend etc that were proposed). Note this has
nothing to do with mutable values vs accessor methods: the only way you
can get/set an instance variable is via [$obj set] so it's already
hidden behind accessor functions (oh, there's the instvar stuff, but
I've never really looked at that).

Yes, it would add a "magic" variable name, but remove some "magic"
methods. I was just seeing what appeared to be a proposal to mirror all
of the variable manipulation commands with special ones to deal with
mixins, which seemed a bit of a waste.

Cheers,

Neil.

From: SImon Millward <simon_at_tcbventures.com>
Date: Thu, 5 Aug 2010 00:05:44 +0100

I agree there was a case for raising this. I'm sorry if I gave any other impression. ( I don't know why u raised this with me only and not the list? But I have)

But, I don't think the case is a valid one, because you are finding difficulty with a dynamic language. Dynamic languages offer power. With power comes responsibility. Responsibility in my book equals things like comprehensive UT. If you don't test you fail.... please demonstrate another industry that doesn't consider testing an essential element of what they do?

> 1) This particular one is a hobby project, and I don't really fancy spending my free time writing unit tests.


I'm sorry to be contrary... but... if you are a hobbyist... should you really be commenting on the semantic or operational aspects of a language?.... if you are not writing unit tests then you are not behaving like a professional... if you are not, then why should a language implementation adhere to you? If you think that not being a professional excuses you from doing a good job then that is equally worrying.... UT is not a pro Vs hobbyist choice... its how one builds good software... QED... if u can't be bothered then what r u doing?

I hate to bang the drum.. but I am tired of silly crap....

> 2) Unit tests, by their nature, don't cover everything. What if the unit tests never passed in a value beginning with "-"?

Then they are crap unit tests (and probably crap code).. if failed to expect 'dirty' inputs....

I fail to see how someone who admits to not being professional can then create a justification for a language change..... I'm more surprised anyone's taking it seriously!

Regards

Simon


On 4 Aug 2010, at 18:43, Kristoffer Lawson wrote:

>
> On 4 Aug 2010, at 19:50, SImon Millward wrote:
>
>> Isn't it fair to say that by design, any dynamic language has such possible traps and pitfalls... (although this one is especially awkward). You don't need to try very hard to make TCL fall over in all sorts of ways like this.
>
> Absolutely, dynamic languages do have these (and static languages do too, just in a different way). However I think for many things Tcl is probably reasonably OK. PHP is notorious for holes.
>
> But yes, this a particularly bad one because one normally assumes you can send variables as parameters to methods and constructors quite freely. It's common to be initialising with random pieces of string, for various purposes. It's obvious that something like [eval] or [after] is going to be dangerous. Perhaps even [switch] (although I think there'd be a case against that too). But creating a new ob with initial data passed as a variable?
>
>> The question I always ask my teams when something like this comes up is
>> - Why didn't the unit tests catch it
>> - What 'stock' unit test will we add in future to catch it
>
> 1) This particular one is a hobby project, and I don't really fancy spending my free time writing unit tests.
>
> 2) Unit tests, by their nature, don't cover everything. What if the unit tests never passed in a value beginning with "-"?
>
> The flipside to this, as mentioned, is that the resolution is actually quite ugly, and would need to be utilised for safety reasons almost every time a class is instantiated. I think there is definitely a case for raising some concern over this.
>
> --
> Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/
>