Weblog Page

From: Victor Mayevski <vitick_at_gmail.com>
Date: Sun, 19 Dec 2010 12:37:27 -0800

Hello Gustaf,

Although your examples do seem to work on Object objects, the Class
instances do not work right. Here is a snippet from your examples:


nx::Class create C {
 # Create attributes "x" and "y" and script the initialization of
 # these attributes.
 :attribute x {
   set :timestamp [clock clicks]
 }
 :attribute y {
   set :timestamp [clock clicks]
 }
 :create c1
}

# Print for every slot object the value of the timestamp, if it
# exists.
proc print_slots_and_timestamps {obj} {
 foreach slot [$obj info lookup slots] {
   if {[$slot eval {info exists :timestamp}]} {
     puts "$slot created at [$slot eval {set :timestamp}]"
   }
 }
}
print_slots_and_timestamps c1

######################################################

if I do [C create c2] and then [print_slots_and_timestamps c2], the
actual output is still for instance c1, not c2, also all instances of
C class have the following slot in them, which doesn't seem right:
::C::slot::x . Shouldn't it be something like ::c1::slot::x,
::c2::slot::x ?

Thanks










On Thu, Dec 16, 2010 at 2:31 AM, Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote:
> Dear Victor,
>
> here is a scripted writeup to address your questions.
>
> -gustaf neumann
> ===========================================================
> package req nx::test
> nx::Object create o
>
> # The method setter registers an accessor method for instance
> # variables. It provides "set" and "get" operations and value
> # checking.
>
> # Register accessor named x
> o setter x
>
> # Use the accessor method x as setter
> # (set instance variable x to 1; returns 1)
> ? {o x 1} 1
>
> # Use the accessor method x as getter
> # (get the value of the instance variable x; returns 1)
> ? {o x 1} 1
>
> # Define a setter with a value constraint
> o setter x:int
> ? {o x 3} 3
> ? {o x a} {expected integer but got "a" for parameter "x"}
>
> # The accessor function can be realized with some more typing as well
> # via the following method. So, the method "setter" does not provide
> # any additional functionality in terms of expressability of the
> # language.
>
> o public method y {value:int,optional} {
>  if {[info exists value]} {
>    return [set :y $value]
>  } else {
>    return [set :y]
>  }
> }
>
> ? {o y 3} 3
> ? {o y a} {expected integer but got "a" for parameter "value"}
>
> # Why are accessor function at all provided since instance variables
> # can be accessed as well without these?  In nx it is easy for an
> # object to access the own instance variables via variable resolvers
> # (variable names starting with a single colon), butmore work to
> # access the variables of other objects. One can use e.g. the method
> # "eval" to execute a script in the context of an object (and to be
> # able to use the variable resolver).
>
> ? {o eval {set :x 2}} 2
>
> # So, an accessor method makes the access of public variables easy, it
> # provides the value constraints, one can use interceptors for
> # tracing, refinement, etc.
>
> # Ok, why do we need attributes?
>
> # Attributes (as defined by nx) provide all functionalities provided
> # by the setter methods plus
> #  - some attribute life-cycle management (e.g. default values), and
> #  - arbitrary meta-data
>
> # For example, we can define an integer attributed named "z" with a
> # default value.
>
> o attribute {z:int 123}
> # return the default value
> ? {o z} 123
> ? {o z a} {expected integer but got "a" for parameter "z"}
>
> # The example above is an object specifc attribute. In most
> # situations, attributes are defined on the class level. Attributes
> # are inherited to subclasses (setters certainly as well).
>
> nx::Class create Employee {
>  :attribute serial_number:int,required
> }
> nx::Class create Manager -superclass Employee {
>  # Project names are upper case, provided as an list, which might be
>  # empty and are per default initialized to the empty list.
>  :attribute {projects:upper,0..n {}}
> }
>
> Manager create joe -serial_number 4711
>
> # What about the meta-data? I want to use e.g. very special meta-data,
> # such as e.g. time-stamps.
>
> # The method "attribute" creates so-called slot objects, which are in
> # turn nx objects. These slot objects can be initialized like all
> # other nx objects in a scripted way.
>
> nx::Class create C {
>  # Create attributes "x" and "y" and script the initialization of
>  # these attributes.
>  :attribute x {
>    set :timestamp [clock clicks]
>  }
>  :attribute y {
>    set :timestamp [clock clicks]
>  }
>  :create c1
> }
>
> # Print for every slot object the value of the timestamp, if it
> # exists.
> proc print_slots_and_timestamps {obj} {
>  foreach slot [$obj info lookup slots] {
>    if {[$slot eval {info exists :timestamp}]} {
>      puts "$slot created at [$slot eval {set :timestamp}]"
>    }
>  }
> }
> print_slots_and_timestamps c1
>
> #
> # Ok. What if I want to use a time-stamp for every attribute of my
> # application without having to write this for every occurance?
> #
> # Well, use the force, luke. Remember, we have quite a powerful
> # underlying framework, supporting e.g. mixin, dynamic call
> # definitions, etc.
>
> ::nx::Attribute mixin [Class new {
>  :method init {} {
>    set :timestamp [clock clicks]
>    next
>  }
> }]
>
> nx::Class create D {
>  # Create attributes "x" and "y" and script the initialization of
>  # these attributes.
>  :attribute x
>  :attribute y
>  :create d1
> }
>
> print_slots_and_timestamps d1
>
> #
> # What if i want to use different kinds of attributes, such as
> # e.g. persistent attributes and non-persistent attributes, etc.?  How
> # can i define my on slotclasses if i need?
> #
> # Per default, attributes are of the class ::nx::Attribute. One can
> # certainly define subclasses of this class and specify these classes
> # during attribute creation. Since "attribute" is technically a
> # method, the syntax is slightly different to the usual object
> # creation.
> #
> # We define now "MyAttribute" as a subclass of ::nx::Attribute with an
> # additional attribute named timestamp. The timestamp has the actual
> # timestamp as default.
> #
> ::nx::MetaSlot create MyAttribute -superclass ::nx::Attribute {
>  :attribute {timestamp "[clock clicks]"}
> }
>
> # Use this type of attribute:
> nx::Class create E {
>  :attribute x -slotclass MyAttribute
>  :attribute y -slotclass MyAttribute
>  :create e1
> }
>
> print_slots_and_timestamps e1
>
> # A final question: i see that "attribute" is more powerful then
> # "setter". Do I need as an enduser the method "setter" at all?
> #
> # No. I think, we could safely remove it from the default method set
> # for the final release.
> #
> # One other observation during this writeup: maybe "slotclass" is to
> # crude, we could use "class" or "type" instead (at some earlier
> # state, we could not use technically "class"). We will overthink
> # this.
>
>
>
>
>

From: Andreas Kupries <andreask_at_activestate.com>
Date: Tue, 13 Aug 2013 11:43:42 -0700

20'th Annual Tcl/Tk Conference (Tcl'2013)
http://www.tcl.tk/community/tcl2013/

September 23 - 27, 2013
Bourbon Orleans Hotel
New Orleans, Louisiana, USA
http://www.bourbonorleans.com/

Hello all.

This is a general reminder that the offer of reduced rates for rooms
at the conference hotel expires on August 19, i.e. in a week.

        Book Now! (if you haven't already).

Of course registration for the Conference is still open at

        http://www.tcl.tk/community/tcl2013/reg.html

To book a room at the conference hotel at reduced rates please follow
the instructions on that page.

Our schedule can be found at

        http://www.tcl.tk/community/tcl2013/schedule.html

Conference Committee

Clif Flynt Noumena Corp General Chair, Website Admin
Andreas Kupries ActiveState Software Inc. Program Chair
Gerald Lester KnG Consulting, LLC Site/Facilities Chair
Arjen Markus Deltares
Brian Griffin Mentor Graphics
Cyndy Lilagan Nat. Museum of Health & Medicine, Chicago
Donal Fellows University of Manchester
Jeffrey Hobbs ActiveState Software Inc.
Kevin Kenny GE Global Research Center
Larry Virden
Mike Doyle National Museum of Health & Medicine, Chicago
Ron Fox NSCL/FRIB Michigan State University
Steve Landers Digital Smarties

Contact Information tclconference_at_googlegroups.com


Tcl'2013 would like to thank those who are sponsoring the conference:

ActiveState Software Inc.
Buonacorsi Foundation
Mentor Graphics
Noumena Corp.
SR Technology
Tcl Community Association

From: <MichaelL_at_frogware.com>
Date: Mon, 20 Sep 2004 11:33:19 -0400

I have a class I use to manage collections of aggregated objects. I'm
trying to use it with the -Class parameter option and instforwarding so
that I can do things like this:

        Test x
        x apples add Z
        x apples items

*That* part I can get to work as expected. But I can't get the default
option of instforwarding to work for this case:

        x apples

Some (simplified) sample code follows.

================================


package require XOTcl 1.3

namespace import ::xotcl::*

# Collection

Class Collection

Collection instproc new {className args} {
    eval $className [self]::[[self] autoname -instance $className] $args
}

Collection instproc add {args} {
    foreach objName $args {
        $objName move [self]::[[self] autoname -instance [namespace tail
[$objName info class]]]
    }
}

Collection instproc items {} {
    return [[self] info children]
}

Collection instproc remove {objName} {
    [self]::$objName destroy
}

# CollectionParameter

::xotcl::Class::Parameter CollectionParameter -superclass Collection

# Test

Class Test -parameter {
    {_apples_ -Class CollectionParameter -default 1}
    {_oranges_ -Class CollectionParameter -default 1}
}

# TestItem

Class TestItem

# Examples

Test instforward apples {%my _apples_}
Test instforward oranges {%my _oranges_}

Test x
x apples new TestItem
x apples new TestItem

# this works
puts [x apples items]

Test instforward apples -default {items add} {%my _apples_}
Test instforward oranges -default {items add} {%my _oranges_}

Test z
z apples new TestItem
z apples new TestItem

# this works
puts [z apples items]

# this doesn't
puts [z apples]

From: Victor Mayevski <vitick_at_gmail.com>
Date: Fri, 1 Oct 2010 12:06:16 -0700 (PDT)

I will wait for the announcement to see the entire picture.

I wish I participated in those 10+ years of discussions so I could understand things better. Time to catch up. I am sure that people coming from C++ or Java backgrounds will find NX more appealing. For me, even looking at code like "public void method" is painful. I like short, readable code. But, again, NX seems to be flexible enough to make all of us happy. May be it will even warm me up to C++ or Java, so I finally learn at least one of them. Not that I have too much time on my hands. :)

Thank you.



----- Original Message -----
From: "Gustaf Neumann" <neumann_at_wu-wien.ac.at>
To: xotcl_at_alice.wu-wien.ac.at
Sent: Thursday, September 30, 2010 11:44:58 PM GMT -08:00 US/Canada Pacific
Subject: Re: [Xotcl] XOTcl 2.0 and NX

  On 01.10.10 06:50, vitick_at_gmail.com wrote:
> Dear Gustaf,
>
> What is the reason for having XOTcl 2.0 and NX at the same time?
we will make a larger announcement in the near future
explaining the background, relationships in detail.

For now: we have a large XOTcl code base, for which it is
unrealistic to switch to the new language in short time.
Both, XOTcl 2.0 and our next scripting language are fully
scripted (loaded via package require), so they are much
easier to maintain.
> In NX, method declaration is private by default where it seems to me that it is more natural for it to be public by default (since the majority method declarations will be public) and it is the private method that should be declared explicitly.
many experiences and comments from 10+ years of xotcl were
brought into the design of nx (e.g. issues about naming,
large set of base methods, experiences from bug tracking,
etc.). One experience from larger projects (more than
500.000 tcl/xotcl code, larger and changing programmer team)
is that forcing developer to declare interfaces helps to
improve comprehensibility for starters. btw, nx has a weak
form of protection, one can call protected methods via "obj
eval .....", but these should be reminders to provide a
public interface for that functionality. Furthermore, the
default protection can be changed from the scripting level.

-gustaf neumann

_______________________________________________
Xotcl mailing list
Xotcl_at_alice.wu-wien.ac.at
http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: <uwe.zdun_at_uni-essen.de>
Date: Thu, 30 Nov 2000 21:08:29 +0100 (CET)

Hi all,

for the XOTcl release 0.83, which is just announced, I've produced a
simple introductory example for our tutorial. Since we have read quite
often the demand for examples in the object-oriented extensions, we
decided to post this example to the mailing list. Hopefully it gives
you an impression of XOTcl without requiring you to read through the
whole tutorial. We hope that it can demonstrate that XOTcl is (a) an
dynamic object-oriented language in the style of Tcl and that XOTcl is
(b) not "just another object-oriented extension."

In fact XOTcl's language constructs explicitly aim at the complexity
in a component glueing layer, that *IS NOT* solved by traditional
object-orientation in the style C++ or Java. The expression power of
the constructs is shown the best, when they work on a lot of classes,
which wrap substantial real-world software components ... this
obviously cannot not be achieved with an introductory example.

However -- for your amusement -- here is the soccer club example with
many comments (you can also find it on
  http://www.xotcl.org/doc/tutorial.html#soccerClub
in html format, which is perhaps more readable):


##############################################################################


# This is a simple introductory example for the language XOTcl.
# It demonstrates the basic language constructs on the example of
# a soccer club.
 
# All the characters in this example are fictitious, and any
# resemblance to actual persons, living or deceased, is coincidental.

# In XOTcl we do not have to provide the above file description
# as a comment, but we can use the _at_ object, which is used generally
# to provide any kind of information, metadata, and documentation on
# a running program. Here, we just give a file description.
# Now makeDoc.xotcl will automatically document this file for us.
_at_ @File {
  description {
    This is a simple introductory example for the language XOTcl.
    It demonstrates the basic language constructs on the example of
    a soccer club.
  }
}

#
# All things and entities in XOTcl are objects, a special kind of objects
# are classes. These define common properties for other objects. For a
# soccer club, we firstly require a common class for all kinds of members.
#
# Common to all members is that they have a name. Common properties defined
# across all instances of a class are called "parameter" in XOTcl.
#
Class ClubMember -parameter {name}

# A special club member is a Player. Derived classes can be build with
# inheritance (specified through 'superclass'). Players may have a
# playerRole (defaults to NONE):
Class Player -superclass ClubMember -parameter {{playerRole NONE}}

# Other club member types are trainers, player-trainers, and presidents
Class Trainer -superclass ClubMember
Class President -superclass ClubMember

# the PlayerTrainer uses multiple inheritances by being both a player
# and a trainer
Class PlayerTrainer -superclass {Player Trainer}

#
# Now we define the SoccerTeam class.
#
Class SoccerTeam -parameter {name location type}

# We may add a player. This is done by a method. Instance methods are
# in XOTcl defined with 'instproc'. All club members are aggregated in
# the team (denoted by :: namespace syntax).
SoccerTeam instproc newPlayer args {
  # we use a unique autoname for the object to prevent name
  # collisions, like <soccerteam>::player01, <soccerteam>::player02, ...
  eval Player [self]::[[self] autoname player%02d] $args
}

# A player can be transfered to another team. The player object does
# not change internally (e.g. the playerRole stays the same). Therefore we
# 'move' it to the destination team.
SoccerTeam instproc transferPlayer {playername destinationTeam} {
  # We use the aggregation introspection option 'children' in order
  # to get all club members
  foreach player [[self] info children] {
    # But we only remove matching playernames of type "Player". We do
    # not want to remove another club member type who has the same
    # name.
    if {[$player istype Player] && [$player name] == $playername} {
      # We simply 'move' the player object to the destination team.
      # Again we use a unique autoname in the new scope
      $player move [set destinationTeam]::[$destinationTeam autoname player%02d]
    }
  }
}

# Finally we define two convenience methods to output the members or players:
SoccerTeam instproc printMembers {} {
  puts "Members of [[self] name]:"
  foreach m [[self] info children] {puts " [$m name]"}
}
SoccerTeam instproc printPlayers {} {
  puts "Players of [[self] name]:"
  foreach m [[self] info children] {
    if {[$m istype Player]} {puts " [$m name]"}
  }
}
      
# Now let us build two example soccer teams:
SoccerTeam chelsea -name "Chelsea FC" -location "Chelsea"
SoccerTeam bayernMunich -name "F.C. Bayern München" -location "Munich"

# With 'addPlayer' we can create new aggregated player objects
#
# Let us start some years in the past, when "Franz Beckenbauer" was
# still a player.
set fb [bayernMunich newPlayer -name "Franz Beckenbauer" \
  -playerRole PLAYER]

# 'playerRole' may not take any value. It may either be NONE, PLAYER,
# or GOALY ... such rules may be given as assertions (here: an instinvar
# gives an invariant covering all instances of a class). In XOTcl
# the rules are syntactically identical to 'if' statements
Player instinvar {
    {[[self] set playerRole] == "NONE" ||
        [[self] set playerRole] == "PLAYER" ||
        [[self] set playerRole] == "GOALY"}
}

# If we break the invariant and turn assertions checking on, we should
# get an error message:
$fb check all
if {[catch {$fb set playerRole SINGER} errMsg]} {
  puts "CATCHED EXCEPTION: playerRole has either to be NONE, PLAYER, or TRAINER"
  # turn assertion checking off again and reset to PLAYER
  $fb check {}
  $fb set playerRole PLAYER
}

# But soccer players may play quite different, orthogonal
# roles. E.g. Franz Beckenbauer was also a singer (a remarkably bad
# one). However, we can not simply add such orthogonal, extrinsic
# extensions with multiple inheritance or delegation. Otherwise we
# would have either to build a lot of unnecessary helper classes, like
# PlayerSinger, PlayerTrainerSinger, etc., or we would have to build
# such helper objects. This either leads to an unwanted combinatorial
# explosion of class or object number.
#
# Here we can use a per-object mixin, which is a language construct
# that expresses that a class is used as a role or as an extrinsic
# extension to an object.

# First we just define the Singer class.
Class Singer
Singer instproc sing text {
  puts "[[self] name] sings: $text, lala."
}

# Now we register this class as a per-object mixin on the player object:
$fb mixin Singer

# And now Franz Beckenbauer is able to sing:
$fb sing "lali"

# But Franz Beckenbauer has already retired. When a player retires, we
# have an intrinsic change of the classification. He *is* not a player
# anymore. But still he has the same name, is club member, and
# is a singer (brrrrrr).

# Before we perform the class change, we extend the Player class to
# support it. I.e. the playerRole is not valid after class change
# anymore (we unset the instance variable).
Player instproc class args {
  [self] unset playerRole
  next
}

# Now we can re-class the player object to its new class (now Franz
# Beckenbauer is President of Bayern Munich.
$fb class President
# Check that the playerRole isn't there anymore.
if {[catch {$fb set playerRole} errMsg]} {
  puts "CATCHED EXCEPTION: The player role doesn't exist anymore (as it should be after the class change)"
}

# But still Franz Beckenbauer can entertain us with what he believes
# is singing:
$fb sing "lali"

# Now we define some new players for Bayern Munich:
bayernMunich newPlayer -name "Oliver Kahn" -playerRole GOALY
bayernMunich newPlayer -name "Giovanne Elber" -playerRole PLAYER

# if we enlist the players of Munich Franz Beckenbauer is not enlisted
# anymore:
bayernMunich printPlayers

# But as a president he still appears in the list of members:
bayernMunich printMembers

# Now consider an orthogonal extension of a transfer list. Every
# transfer in the system should be notified. But since the transfer
# list is orthogonal to SoccerTeams we do not want to interfere with
# the existing implementation at all. Moreover, the targeted kind of
# extension has also to work on all subclasses of SoccerTeam. Firstly, we
# just create the extension as an ordinary class:
Class TransferObserver
TransferObserver instproc transferPlayer {pname destinationTeam} {
  puts "Player '$pname' is transfered to Team '[$destinationTeam name]'"
  next
}

# Now we can apply the class as a per-class mixin, which functions
# exactly like a per-object mixin, but on all instances of a class and
# its subclasses. The 'next' primitive ensures that the original
# method on 'SoccerTeam' is called after notifying the transfer (with
# puts to stdout)
SoccerTeam instmixin TransferObserver

# If we perform a transfer of one of the players, he is moved to the new
# club and the transfer is reported to the stdout:

bayernMunich transferPlayer "Giovanne Elber" chelsea

# Finally we verify the transfer by printing the players:
chelsea printPlayers
bayernMunich printPlayers


##############################################################################

-- 
Uwe Zdun
Specification of Software Systems, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_xotcl.org, uwe.zdun_at_uni-essen.de

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 7 Mar 2005 21:14:06 +0200 (EET)

It says the latest release was from January 2004. I imagine it means 2005
;-)

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

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Thu, 10 May 2001 21:37:31 +0300 (EEST)

With small patches like these that are probably beneficial to everyone,
would it be possible to start having patch releases of XOTcl? Like 0.84.1
etc.

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

From: Kristoffer Lawson <setok_at_scred.com>
Date: Tue, 18 May 2010 00:53:05 +0300

Continuing on where Spindle leaves off, I created a system which again
reflects how I believe storage should work. After endless problems
with RDBMS and the object-relational mismatch, I decided to hell with
that, and built a transparent persistence layer which can use a file
or Sqlite backend (no reason why others could not be used too). The
idea is that any class created from the basic PersistenceClass
metaclass can be attached to storage. Changes are automatically
written out. Even more interestingly objects which are referred to,
but which do not exist in memory, are automatically loaded as well.
You can even destroy them at will and, when required, they'll happily
be loaded back in. There is also a simple query language for getting
objects from their class.

It's not perfect, and a lot could be done with it still, but I like
the idea. For many things full blown direct RDBMS access is just not
necessary, and can cause major headaches. I also think that a lot
could be done to optimise the Storm system so that performance
differences wouldn't be huge, for many cases. Spindle (the web
framework) does not require Storm in any way, and you can use any
storage backend you want with it. I did, however, create them
simultaneously so perhaps they subconsciously share some fabric.

http://github.com/Setok/Storm

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Mon, 20 Mar 2006 18:54:38 -0700

xotcl-bounces_at_alice.wu-wien.ac.at wrote on 03/20/2006 12:29:57 PM:

>
> On 20 Mar 2006, at 18:13, Koen Danckaert wrote:
>
> >>>> I have added "::xotcl::mymethod" and "::xotcl::myvar" to my
> >>>> development version. i guess, you would you prefer to have
> >>>> these exported. Opinions?
> >>>
> >>> On giving it some thought I think I actually prefer the version
> >>> that would be part of Object. After all, it is that object's
> >>> variable that we want.

I also think it should be methods. An object owns its methods/variables, you should have to ask the
object for a reference. Just reach in from outside and grabbing a reference feels...rude.

Asking the object also gives it a chance to overload it. I can't imagine why, but an object might
want to know that something has a reference to its internal state.

> It's only really necessary for variables which are linked to other
> systems as for callbacks you can generally do f.ex.:
>
> after 100 [list [self] doStuff]
>
> which is what I actually do. I mean, presumably the problem with
> using a method by its direct namespace is also that filters get
> avoided, or? (at least I think it was that way at some point in
> XOTcl's history). That, to me, would mean it's not a good method
> except for very specific cases.

I would expect that [list [self] dostuff] is what [my &method doStuff] returns. Isn't that the
desired behavior to return a list that when evaluated acts as though you have invoked the method on
the object?

At least, that's what snit does with "mymethod". Although snit doesn't have nearly the same design
space as XOTcl, so maybe it's not comparable.

      Scott

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 08 Dec 2010 06:51:16 +0100

i just retrieved the current version from head, did run a
"configure",
"make", "make test" , ... everything is fine.

Maybe, you have the stubs-files generated with tcl 8.5 and
you are compiling
against tcl 8.6 now. make sure to run configure, when you
compile against
different versions.

-gustaf neumann

On 08.12.10 01:05, Victor Mayevski wrote:
> Trying to compile the latest NX/XOTcl 2.0 against Tcl CVS Head:
>
> gcc -DPACKAGE_NAME=\"nsf\" -DPACKAGE_TARNAME=\"nsf\"
> -DPACKAGE_VERSION=\"2.0.0\" -DPACKAGE_STRING=\"nsf\ 2.0.0\"
> -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1
> -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1
> -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\
> __attribute__\(\(__visibility__\(\"hidden\"\)\)\)
> -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
> -DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1
> -DHAVE_TYPE_OFF64_T=1 -DUSE_TCL_STUBS=1 -DCOMPILE_NSF_STUBS=1
> -DNSF_VERSION=\"2.0\" -DNSF_PATCHLEVEL=\"2.0.0\"
> -DHAVE_TCL_COMPILE_H=1 -I"/root/TCL/tcl/generic"
> -I"/root/TCL/tcl/unix" -I./generic -pipe -O2 -fomit-frame-pointer
> -Wall -fPIC -c `echo ./generic/nsfStubLib.c` -o nsfStubLib.o
> ./generic/nsfStubLib.c:40: error: conflicting types for ‘nsfStubsPtr’
> ./generic/nsfDecls.h:262: note: previous declaration of ‘nsfStubsPtr’ was here
> ./generic/nsfStubLib.c:41: error: conflicting types for ‘nsfIntStubsPtr’
> ./generic/nsfIntDecls.h:41: note: previous declaration of
> ‘nsfIntStubsPtr’ was here
> ./generic/nsfStubLib.c:43: error: conflicting types for ‘nsfStubsPtr’
> ./generic/nsfDecls.h:262: note: previous declaration of ‘nsfStubsPtr’ was here
> ./generic/nsfStubLib.c:44: error: conflicting types for ‘nsfIntStubsPtr’
> ./generic/nsfIntDecls.h:41: note: previous declaration of
> ‘nsfIntStubsPtr’ was here
> make: *** [nsfStubLib.o] Error 1