 |
 |
On Tue, 1 Aug 2006, Norman Gray wrote: > > TOPCAT 2.2/topcat/bin > > sounds like a reasonable place for the script, but it probably > > won't work because the script needs to know where the topcat-full.jar > > file is, and it doesn't know to look in > > ../../TOPCAT.app/Contents/Resources/Java. > > One way of handling this might be for the script to spot it's on OS X > (test -f /usr/bin/sw_vers && expr "`/usr/bin/sw_vers -productName`" : > '.*OS X') and add the appropriate ../../.... to the PATH. had occurred to me - may be the best thing. > > I probably need to > > take a closer look at what's going on and preferably understand > > a bit more about what .dmg/.app files are supposed to be for > > and how they're organised. If there's an obvious on-line > > reference for that sort of thing maybe you could pass it on, > > otherwise I'm sure I can find something by poking around. > > Apple's developer pages are copious, but somehow it always takes me a > couple of goes to find stuff I'm looking for. > > Try <http://developer.apple.com/documentation/CoreFoundation/ ... thanks much. > > PS apologies for laming out of the debate last week on, er, whatever > > it was we were talking about. I agreed with many of your points > > and disagreed with a few, but arrived at that point where I felt > > like I'd better get back to the day job. > > I think the problem was that it was about several things at once. > > My thing was expressing some puzzled frustration that more folk > aren't using UCDs and UTYPEs. Taking advantage of the descriptions > they represent is certainly _my_ day-job, and inasmuch as it's > concerned with practical communication between applications, I can't > really explain why it's not part of other folks' day jobs, too. My 2p's worth is this: they are not widely used because it's difficult to use them in a way which makes your life easier or provides worthwhile additional functionality. Trying to make sense of UCDs that someone else may or may not have stuck on to columns or tables or groups or whatever requires something uncomfortably close to artificial intelligence. You've got to decide whether you're looking at UCD1 or UCD1+, attempt to make sense of what a load of words separated by semicolons mean, decide whether, say, phot.mag.reddFree is an acceptable stand-in for phot.mag, think about whether you need to perform unit conversions for the quantity that you've identified to mean what you think it means... Worst of all, you can't rely on the UCDs being there, so if you really care about where to find RA and Dec, say, you're still realistically likely to be checking column names etc. IMHO UCDs sound like a good idea, but do not in fact provide machine-readable semantics in any very useful sense. I'm not sure to what extent this is a fundamental limitation of the idea or just that they are implemented in a way which is difficult to work with. Utypes are easier to work with, but I don't think(?) there are the public data models to derive them from. If you're communicating with yourself by reading utypes which you've just written, referencing your own data model, it may make sense to use them, but until/unless that data model is taken up more widely it doesn't really gain you much over just knowing the J mag is in column 4 because that's where you always write it. > See you in Strasbourg? yes. -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK [log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/