[copied to stardev since I'll be asking a question at the end
concerning CVS access for AAO]
On Thu, 5 Aug 2004, Tony Farrell wrote:
>
> On 04/08/2004, at 10:00, Tim Jenness wrote:
>
> >
> > We can provide help in autoconfing your existing starlink apps.
> >
>
> Yes please.
>
One thing I forgot to say in our release notes was that this is not simply
a port of starlink to OSX. It's an entirely new build system.
How do you want to go about this? Norman's SSN/78 document is an excellent
place to start. Alternatively, you could send me a source tar file and
I could send you an autoconfed tar file back for you to examine.
> >
> > I've not had any problems with pgplot. The CCDPACK problems are
> > relating
> > to the tcl/tk guis and are not anything to do with graphic display.
> >
> > Are you using pgplot_link or pgplot_link_adam for your link?
>
> It is a C application, so we don't use these commands. It is linking
> using
>
> -L/star/lib `cfitsio_link` \
> -lpgp -lref `ndf_link` `ast_link` `fio_link` `sla_link` `err_link` \
> $(LIB_X11) `gns_link`
>
> Which appears to be the Starlink version. I will try a little later
> replacing the two -l specs with `pgp_link` and `ref_link`, but I
> suspect the result will be the same.
Does it really use GKS and GNS? If not, you should be using pgplot_link
rather than pgp_link. 'pgplot_link -star' will also include the
X11 libraries. Although I see you explicitly link against GNS...
>
> >
> > We have completely autoconfed PGPLOT and we are intending to include
> > the
> > aqua driver at some point. pgplot_link is meant to be the completely
> > standard pgplot library. If you want the gwm driver but no adam then
> > you
> > need to run pgplot_link as `pgplot_link -star`
> >
> > If you've been expecting the aqua driver then there would be a problem.
> > Does kappa display work for you okay? ORAC-DR displays fine for us so
> > it
> > seems that kappa is displaying on pgplot correctly. We haven't done
> > more
> > extensive tests though [GKS does work!]
>
> No - I was not expecting aqua.
>
It is in the plan [but would be faster if I had my own Mac -
currently Brad and I are sharing a slow powerbook. Starlink have two
programmers with Macs now].
> I got Kappa to display - but it was a little strange (but note, I have
> not been a Kappa user so this may be normal). I used the following
> command.
>
> display 11may0001 data true xwindows scale \\
>
> Where "11may0001.sdf" is a 1024x1028 2dF raw CCD image.
>
> If the image window was not up, it was brought up and looked ok. But,
> if I left it alone I see no image on the image window until about the
> time display program exits.
>
KAPPA display does the display and then exits so I wouldn't expect it to
display earlier. Pipeline display from oracdr works fine for us.
> Now I believe that I am supposed to see the image come up are few lines
> at a time, as it does the scaling. If I started playing with the
> scroll bar, it would display like this - suggesting the normal update
> is not work correctly (which sounds a bit like my problem).
>
What scroll bar? The above command works for me [with a different file]
I don't see the image drawing up.
> Additionally, if these was already an image up on the display, the
> "clear" operation is not perfect, leaving a strip down the side of the
> window.
That's not right either. Can you send a photo?
> I have an additional problem. I have instances where NDF_MAP is not
> returning the expected data but is also not setting status bad. It
> seems to be returning all the same value (often but not always, zero).
> We have compared the behavior of the same version of the program under
> linux and so are confidant it should return something else at these
> points.
Can you try fiddling with the HDS_MAP environment variable in case there
is a problem with hds picking up the wrong function somewhere [HDS hasn't
really been autoconfed all that extensively so on mac it might be falling
through a bad ifdef somewhere]
> I suspect that either a previous error is not being picked up or some
> type of system error is not detected. Unless you have any other
> suggestions, what I would like to do is compile NDF and HDS with
> debugging enabled. Is everything I would need be in the starlink CVS,
> or do you have Mac OS X versions which not yet got back into CVS?
The starlink cvs is fully up-to-date. There is no OSX branch and so HEAD
is what you need.
Do you have an account at Starlink? If so then cvs checkout is trivial
:ext:cvs.starlink.ac.uk:/cvs
and then follow the instructions in SSN/78. IF you haven't got an account
then it might be simpler to get you an account so that you can access the
repository. I don't know what the timescale for anonymous cvs access is,
but clearly it'd be preferable for you to be able to commit patches
directly to the repository.
There is also a starlink wiki containing porting notes. [you'll need a
password for that too]
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|