Re: Problem linking sample application (possible tcl/Tk version problem?)

[Unknown]

Folks,

More on the ongoing saga....

I compiled and linked tcl 7.4 and Tk 4.0 and the market application now links 
without any problems (after recompiling libtclobjc and BLT). The next step will 
be to try 7.5 and 4.1 without the patch, but I will do this when I have some 
time.

Looks as if libtclobjc has some disaggreement with tcl/Tk versions 7.5p1/4.1p1

Regards

Karl


----- End Included Message -----



--------------------------------------------------------------------
Karl Nissen                            Phone:  (+61 6) 249 4613 
Department of Geography, SRMES         Fax:    (+61 6) 249 3770
The Australian National University     e-mail: address@hidden     
--------------------------------------------------------------------

From the R-help mailing list, two people suggested me using an
alternative package called rhdf5. I haven't looked at it yet though.

Thanks again for any information.

E.

P> Norberto Eiji Nawa wrote:
>> (I posted this to address@hidden; since the HDF5 package for
>> R was born within the swarm community (thanks, Marcus!) I thought I
>> should give it a try here as well. E.)
>> 
>> Hello:
>> 
>> Has anyone successfully installed the package hdf5-1.4.7 in R version
>> 1.7.1? I get a fatal error with a core dump (see below) whenever I try
>> to use hdf5load.
>> 
>> Since I'm in the process of moving to a new machine, I'm not sure
>> whether this is due to (my installations of) the HDF5 libs or the hdf5
>> package for R. Just for the record, the HDF5 data files were correctly
>> generated in the new machine (therefore, I assume the HDF5 libs are
>> good at least for outputting data). I could read them in my old
>> machine (R version 1.2.2).
>> 
>> Thanks for any help!
>> 
>> Eiji

From a thread in 2000:
http://www.swarm.org/pipermail/support/2000-August/009036.html

The switch to disable java is  --without-jdkdir

Can you suggest where the installbook should be changed to make this more 
clear?



>===== Original Message From Artem Baguinski <address@hidden> =====
>hello
>
>emacs is a 20M text editor. i don't want it ;)
>
>in installbook of swarm, chapter "Prerequisite Programs" i see the
>following:
>
>  GNU Emacs. ... Emacs is needed if you want to build Swarm for Java
>  from source code...
>
>Well, i don't per se want java support either. It would be nice to have
>--disable-java switch in configure.
>
>then, AC_PATH_PROG([EMACS],[emacs],[missing]), is definitelly not the
>way to go: missing being called with emacs' arguments gets confused and
>breaks build. may be the better solution would have been to forget
>altogether about doing all elisp compilation / running (whatever you
>need emacs for) if it wasn't found. i suppose that's what you tried to
>do substituting it with missing but it aint worked.
>
>i guess the reason was that you all (swarm developers / users) do have
>emacs installed and didn't notice that it doesn't work. in a mailing
>list i saw somebody earlier this year complaining about related problem,
>but this particular piece of configure.in weren't modified.
>
>now, the question is: Is it possible, theoretically speaking, to build
>swarm without having emacs installed?
>
>if no - a change in installbook is necessary, so people like me won't
>get false hopes :)
>
>if yes - i could try to come up with patch to confugure.in /
>Makefile.am's that allows to switch emacs/java off. i can test it easily
>for i have no emacs on my machine. just don't wanna start to work on
>that if it makes no sence.
>
>cheers,
>artm
>_______________________________________________
>Support mailing list
>address@hidden
>http://www.swarm.org/mailman/listinfo/support

////////////////////////////////////////
// Paul Box
// Aquatic, Watershed, and Earth Resources
// Utah State University


From your description, "nested functions" sounds like the old Pascal
functionality of defining procedures whose scopes were contained
within another procedure. This has never been a feature of standard C,
so it must be a GNU extension.

One can do something very similar in C++ - methods are nested within
classes, and class instance variables are global to the group of
methods belonging to that class. There are no performance implications
in using a method over a standard global function call. Obviously the
same is possible in Objective C, however I'm not sure of the
performance implications, since Obj C uses dynamic binding of methods
to objects...

                                                Cheers

Gary Polhill wrote:
> 
> 
> Hi,
> 
> A while ago I put a message to Swarm Support about gcc putting executable 
> code on the stack, because sysadmins had disabled this on a machine that 
> needed Swarm putting on it for security reasons 
> (http://www.swarm.org/pipermail/support/1999-May/006024.html). The replies I 
> got were largely to the effect that the sysadmins were being paranoid and 
> that doing anything about it would be a lot of hassle. In the end I persuaded 
> them to disable the security fix on the machine I needed to run Swarm on, but 
> now I have to run a different model on a 10 CPU Sun box and there is *no way* 
> they are going to disable any security features on 0.5M GBP worth of kit!
> 
> These problems all related to an earlier version of Swarm (1.0.2 & 1.4.1) and 
> gcc (2.7.2 & 2.8.1), so it may be that they no longer apply. If they do:
> 
> 1. As I recall, Swarm uses something called closures (nested functions), and 
> this is what was causing gcc to put executable code on the stack 
> (http://www.swarm.org/pipermail/support/1999-May/006026.html). The advantage 
> is that the nested function inherits all the local variables of the enclosing 
> function. (Please correct me if I'm wrong!) So, theoretically speaking, could 
> the problem be fixed by taking the nested functions outside of their 
> enclosing functions and giving them more arguments? Where, and how often do 
> the Swarm libraries do this anyway? Do any of the Swarm needed-software 
> packages do it as well?
> 
> 2. I thought nested functions were something fairly standard in C. Do all C 
> compilers put executable code on the stack to implement this? Does the C 
> language really stipulate something that requires a breach of security? 
> 
> Looking forward to any replies...
> 
> Gary
> 
> 
> Gary Polhill
> Research Scientist
> The Macaulay Institute
> Craigiebuckler
> Aberdeen AB15 8QH
> UK
> Tel: +(44) (0)1224 498200 Ext 2238
> Fax: +(44) (0)1224 311556
> e-mail: address@hidden
> http://www.macaulay.ac.uk/
> http://www.macaulay.ac.uk/fearlus/
> 
> 
> _______________________________________________
> Support mailing list
> address@hidden
> http://www.swarm.org/mailman/listinfo/support
> 



----------------------------------------------------------------------------
A/Prof Russell Standish                  Director
High Performance Computing Support Unit, Phone 9385 6967, 8308 3119 (mobile)
UNSW SYDNEY 2052                         Fax   9385 6965, 0425 253119 (")
Australia                                address@hidden             
Room 2075, Red Centre                    http://parallel.hpc.unsw.edu.au/rks
            International prefix  +612, Interstate prefix 02
----------------------------------------------------------------------------

From what I understand "element" is just a generic, temporary object to use 
when using an index and that's all I'm trying to do with it.  Also, later in 
the code I do have the same problem with the same error.  The methods 
-getDepth, -getXPos, -getYPos are written like the -getXPos method I described 
above.  Incidently, I tried forcing the conversion:

elementX = (float)[element getXPos];

like you said and got a different error: "pointer value used where a floating 
point value was expected"

I'm not sure if I'm using the index incorrectly or if there is something weird 
going on with the compiler.  It's probably me :)

Let me try to explain more about what my program is trying to do.  In 
modelswarm in the -buildObjects method I create a flowfield and a single fish 
using input files.  Each flow node is added to flowfieldList and when the fish 
is created, I allow it to have access to the flowfieldList by the 
-setFlowfieldList method.  All of my get and set methods in my Flowfield.m and 
BrownTrout.m files follow the form of the swarm user guide.  The -step method 
is what I first posted and is where my problem is.  It is part of the 
BrownTrout.m file.  In modelSwarm -buildActions I send a message to the 
brownTroutList to execute the -step method.  Here are the relavent parts of my 
-buildObjects and -buildActions methods:
...
flowfieldList = [List create: self];
flowfield = [Flowfield createBegin: self];
[flowfield setHydroNode: worldCanvas xPos: xNew yPos: yNew];
[flowfield setDepth: depth];
[flowfield setXDim: xCoord];
[flowfield setYDim: yCoord];
[flowfield setXPos: xNew];
[flowfield setYPos: yNew];
flowfield = [flowfield createEnd];
[flowfieldList addLast: flowfield];

...

brownTroutList = [List create: self];
brownTrout = [BrownTrout createBegin: self];
brownTrout = [brownTrout createEnd];
[brownTrout setNode: worldCanvas];
[brownTrout setXPos: 177];
[brownTrout setYPos: 381];
[brownTrout setLength: length];
[brownTrout setFlowfieldList: flowfieldList];
[brownTroutList addLast: brownTrout];
...

[modelActions createActionForEach: brownTroutList message: M(step)];

....
I hope that explains more clearly what I'm trying to do.  Any more ideas?

Thanks,
Eric


///////////////////////////////////////////////////////////////////
Eric,

The code looks okay; what is the return type for -getXPos and -getYPos, 
int or float or something else?  If the compiler does not know the 
return type, then it may assume it is type "id" in which case putting an 
"id" into a float is a funky type conversion.  The compiler may not know 
the return type if it has not seen the method defined; what class is 
element?  I suppose you could force the conversion with:

elementX = (float)[element getXPos];

Later on in the code you use the same methods to get newX and newY, do 
they work fine?  or do you get the same errors with those?

cheers
Scott

Eric McLeskey wrote:

>First, I'm relatively new to this so please bear with me...
>
>I'm getting a complile error while trying to so what seems to be a fairly
>basic routine with a list.  (What I think I am doing...) is creating an
>index and creating a generic object (element) to be assigned to each
>successive item in a previously created flowfieldList.  What I've done is
>very similar to what is described in the swarm user guide.  When I complile,
>I get an "incompatible types in assignment" error when I try to use
>"element" to access a value from the object in the list.  For example, the
>following lines receive the error:
>
>elementX = [element getXPos]
>elementY = [element getYPos]
>
>I've attached my code.  I've been staring at this for almost 8 hours trying
>to figure it out and I'm close to beating my head against the wall.  I'm
>running swarm 2.2 pretest 11 on windows XP using cygwin if this may be
>relevant...
>
>Thanks for any help,
>Eric
>
>
>-step{
> id <List> nodesICanSee;
> id <Index> flowfieldIndex;
> id element = nil;
>
> id <Index> localNodeIndex;
> id localElement;
> id idealNode;
>
> float extentOfView = 10.5;
> float xLow, xHigh, yLow, yHigh, newX, newY;
> float elementX, elementY;
>
> xLow = [brownNode getX] - extentOfView;
> xHigh = [brownNode getX] + extentOfView;
> yLow = [brownNode getY] - extentOfView;
> yHigh = [brownNode getY] + extentOfView;
>
> nodesICanSee = [List create: [self getZone]];
> flowfieldIndex = [flowfieldList begin: [self getZone]];
>
> while((element = [flowfieldIndex next]) != nil){
>        elementX = [element getXPos];
>        elementY = [element getYPos];
>
>        if(elementX > xLow && elementX < xHigh && elementY > yLow &&
>elementY < yHigh)
>                [nodesICanSee addLast: element];
> }
> [flowfieldIndex drop];
>
> localNodeIndex = [nodesICanSee begin: [self getZone]];
> float nodeDepth = 1.0;
>
> while((localElement = [localNodeIndex next]) != nil){
>         if (nodeDepth < [localElement getDepth]){
>                nodeDepth = [localElement getDepth];
>                idealNode = localElement;
>         }
> }
> newX = [idealNode getXPos];
> newY = [idealNode getYPos];
>
> [brownNode moveX: newX Y: newY];
>
> return self;
> }
>
>
>Eric McLeskey
>Graduate Student
>Institute for Natural Systems Engineering
>Utah State University
>1600 Canyon Road
>Logan, UT  84321
>
>phone: (435) 797-8039
>fax:  (435) 797-8038
>address@hidden