Hi Kevin...
No 64 bit experience (or machines) here....however....
I did not need cygwin to run ant on windows, but the 64-bit-ed-ness
might make a difference.
I always just use the instructions at
<http://ant.apache.org/manual>...but then again I'm using a
32 bit machine.
I do not believe you need to run this under cygwin (unless, again,
there is a 64 bit issue), since cygwin is an "environment" (like an
operating system). From the ant manual:
"We get lots of support calls from Cygwin users. Either it is incredibly
popular, or it is trouble. If you do use it, remember that Java is a
Windows application, so Ant is running in a Windows process, not a
Cygwin one. This will save us having to mark your bug reports as invalid."
Hope that helps and not hinders...
tom
On 10/10/07, Kevin Manross <kevin.manross@xxxxxxxx> wrote:
>
> Greetings!
>
> I've decided to try to build IDV from the source code on a 64-bit
> computer to try and answer my own question. However, the only 64-bit
> computer that I have access to is a Windoze machine (running a 64-bit
> version of XP).
>
> I know that Ant is required to build the IDV from the source, and it
> looks like you can run Ant on windoze using Cygwin. I have some
> familiarity with Cygwin, but often seem to have problems with setting my
> paths, particularly when it comes to invoking java through Cygwin.
>
> Could anyone help me with either A) "how to build IDV on a windoze box",
> or B) setting up my cygwin path?
>
> Many thanks!!
>
> -kevin.
>
>
> Kevin Manross wrote:
> > Good thread!
> >
> > It sounds as if the caching will at least allow me to load al my data in
> > and it should be sufficient for data analysis. If we want to create
> > long loops, we'll do that through ISL.
> >
> > Getting back to what I understand about the Java heap, and what
> > Valentijn has described, the limitation is dependent on:
> >
> > Physical RAM
> > Architecture (32 bit vs. 64 bit)
> > OS
> > Java Version(?)
> >
> > However, even if I have a 64-bit machine with 4-8 Gb RAM running 64-bit
> > version of WindozeXP (Or linux), the IDV comes with its own JVM.
> >
> > Will this limit my potential heap size?
> >
> > Would I be better off to install the 64-bit version of Java (Java3D?)
> > and then download/build the IDV so it uses the computer's native JVM?
> >
> > Thanks!!
> >
> > -kevin.
> >
> >
> > HansPeter Roesli wrote:
> >
> >> Hi all
> >>
> >> This caching is what I was looking for since some time. Good to know
> >> it is there now. I am currently testing it with a long and heavy
> >> satellite image loop (keep fingers crossed).
> >>
> >> I am running IDV on 2 notebooks, both with 2GB of RAM. One runs under
> >> XP and I cannot safely go beyond 1000m. On the other one under SuSE
> >> Linux 10.1 RAM is set to 1512m.
> >>
> >> Cheers, HP
> >>
> >> Valentijn Venus wrote:
> >>
> >>> Kevin. Jeff,
> >>>
> >>> that new caching facility does sound promising!
> >>>
> >>> As far as i know JAVA Heap spaces can grow unlimited on (OPen)
> >>> Solaris systems, and probably also on Linux 64-bit with JAVA 64-bit
> >>> but maybe someone else would be able to tell you...
> >>>
> >>> Here are some of our experiences assigning space heap sizes all
> >>> running IDV from a Java webstart jnlp:
> >>>
> >>> -Linux 64-bit takes you up to 3.5 Gb
> >>> -Windows 32-bit varies (depending on what dll's are loaded at which
> >>> memory address) roughly 1.5 Gb
> >>>
> >>> see some of the jnlp's at http://adde.itc.nl at the "Download" section.
> >>>
> >>> We'll have to wait for Dolphin JAVA virtual machine for large memory
> >>> addressing to make it into JAVA webstart which by then will also
> >>> support all the 64-bit goodies.
> >>>
> >>> Jeff, would you be able to tell if a 64-bit version of java3d is in
> >>> the making or will these two (32-bit java3d & 64-bit jvm) co-exist
> >>> happily together?
> >>>
> >>> Kind regards, Valentijn V. Venus, M.Sc. Researcher/Lecturer in RS/GIS
> >>> for Food Security ITC
> >>> P.O.Box 6
> >>> 7500 AA Enschede
> >>> The Netherlands
> >>> Tel: +31-53-4874549
> >>> Fax:+31-53-4874388
> >>>
> >>> =============================================================== De
> >>> informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
> >>> uitsluitend bestemd voor de geadresseerde. Indien u dit bericht
> >>> onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en de
> >>> afzender direct te informeren.
> >>> =============================================================== The
> >>> information contained in this message may be confidential and is
> >>> intended to be exclusively for the addressee. Should you receive this
> >>> message unrightfully, please do not use the contents herein and
> >>> notify the sender immediately by return e-mail.
> >>> ===============================================================
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: idvusers-bounces@xxxxxxxxxxxxxxxx on behalf of Jeff McWhirter
> >>> Sent: Wed 10/3/2007 23:18
> >>> To: Kevin L. Manross
> >>> Cc: IDV Users
> >>> Subject: Re: [idvusers] Maximum Heap Size
> >>>
> >>>
> >>> Hi Kevin,
> >>> I'm sure some folks will chime in with their experience with max
> >>> memory size.
> >>>
> >>>
> >>>> Specifically, I'm wanting to display relatively long animations of
> >>>> data displaying isosurfaces.
> >>>>
> >>>>
> >>> We have recently added a facility to cache the data to a local disk
> >>> store. If you are running a recent build - for grids if you go to the
> >>> properties dialog of the data source there is a "Always cache to
> >>> disk" checkbox. Turning that on will result in the IDV reading in the
> >>> data timestep by timestep right when each timestep is accessed, e.g.,
> >>> when the display is rendered. Once we read it we write it to disk and
> >>> get rid of it from memory. Then, when the data is accessed again
> >>> (say, when the display is re-rendered or the data is probed) we read
> >>> it back from the local disk.
> >>>
> >>> The "Delay" field is how long the IDV waits until it gets rid of the
> >>> data from memory. For example, if you are probing the data you might
> >>> want to increase the delay so the IDV doesn't keep going to disk
> >>> every time the probe moves.
> >>>
> >>> This is a user option because you do take a performance hit in the IO
> >>> to local disk. But, it will dramatically reduce memory usage.
> >>>
> >>> A caveat - this is fairly new the past 6 weeks or so but it seems to
> >>> be working pretty well.
> >>>
> >>> -Jeff
> >>>
> >>> _______________________________________________
> >>> idvusers mailing list
> >>> idvusers@xxxxxxxxxxxxxxxx
> >>> For list information, to unsubscribe, visit:
> >>> http://www.unidata.ucar.edu/mailing_lists/
> >>> _______________________________________________
> >>> idvusers mailing list
> >>> idvusers@xxxxxxxxxxxxxxxx
> >>> For list information, to unsubscribe, visit:
> >>> http://www.unidata.ucar.edu/mailing_lists/
> >>>
> >>>
> >>>
> >
> >
>
> --
> +-----------------------------------------------------+
> Kevin L. Manross | ** New Address **
> CIMMS Research Associate | 120 David L. Boren Bvd
> NSSL : WRDD : SWAT | Rm 3923
> <kevin.manross@xxxxxxxx> | 405.325.6385
> www.cimms.ou.edu/~kmanross |
> "My opinions are my own and not representative of
> CIMMS, NSSL, NOAA or any affiliates"
> +-----------------------------------------------------+
>
> _______________________________________________
> idvusers mailing list
> idvusers@xxxxxxxxxxxxxxxx
> For list information, to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
--
Tom Whittaker
University of Wisconsin-Madison
Space Science & Engineering Center (SSEC)
Cooperative Institute for Meteorological Satellite Studies (CIMSS)
1225 W. Dayton Street
Madison, WI 53706 USA
ph: +1 608 262 2759
