[Kstars-devel] Great minds think alike: AuxInfo Hash

[Akarsh Simha]

Hi James,

> My suggestion of using essentially the location of a star in the 
> stardata file as a unique key to the AuxInfo hash won't work because we 
> are planning to duplicate a few stars to deal with proper motion.  If 
> the current HD index is non-negative then we can covert it to a unique 
> ID by using negative numbers to uniquely identify stars that are not in 
> the index.  The brightest star not in the index would get an index 
> of -1, the next brightest would get an index of -2 and so on.  This 
> gets us a unique ID without needlessly increasing the size of the 
> StarData struct.

I don't understand what you mean here, epsecially about stars that are
not in the index. Which index are we talking about?

There is one more issue - the links / log apply to not only stars, but
all kinds of objects - stars, comets, asteroids, planets, DSOs, and
sattelites!

I think the best way to handle this is to have a UID for every object
in the sky. For stars, this could be the HD number in the files on the
disk. If not all stars have HD numbers, we could extend it (int32 can
store far more than HD numbers) and have a flag telling us whether the
star's UID is a HD number or something that we cooked up. Once we read
a star's HD number, we could prefix it with some sort of identifier
that tells you that this SkyObject is a StarObject. This will help
distinguish HD 001000 from NGC 1000 and IC 1000.

Anyway, this can wait, unless we want to fix it for the KDE 4.1
release.

> Even if we want to disable the AuxInfo fields for unnamed stars for now,
> I think we may need to do something in order to prevent segfaults and 
> memory leaks when we dynamically load stars.  I think either unnamed 
> stars will have to no longer subclass from SkyObject or we are going to 
> have to change the SkyObject data structure.

Why will the current setup cause segfaults when we dynamically load
stars?

Currently, I do not encounter a segfault at all. Things seem to go on
very smoothly, but the logs aren't saved, as used to be the case even
earlier.

I would prefer to go with the latter of the two options and dissociate
the user data and the info from the SkyObject.

> I think the best thing to do is to create a new AuxInfo struct/class 
> that contains these fields that are currently in SkyObject:
> 
>     QStringList ImageList, ImageTitle;
>     QStringList InfoList, InfoTitle;
>     QString userLog;
> 
> In the SkyObject class, these fields would be replaced by a single 
> pointer to an AuxInfo object.   By default the pointer will be NULL
> indicating that no AuxInfo object yet exists.  For most things, the
> AuxInfo object could be created at construction time, although we could 
> save a little RAM by only creating AuxInfo objects when they are 
> needed.

The RAM that we will save might be quite large, because we are going
to create ~ 100000 such objects with the former solution of doing this
in construction time, whereas only about 500 objects might actually
use this data.

I find both the idea of putting a pointer, and the idea of having a
hash very good. I wouldn't want to inherit UnnamedStar from SkyPoint,
though.

I somehow prefer the hash solution, because it keeps the data that we
will keep together on the disk together even during runtime, but the
problem of generating UIDs for all the objects will need to be
tackled. The good thing is that we need not have the bits for
identifying object type uniquely on the disk, but we can assign those
during runtime.

> There may be a better way of handling this problem but that is the best 
> that I've come up with so far.  I think what I've outlined above could 
> be done in less than a day.

Yep. I guess it can be done in a day. I need the HD numbers for our
existing catalog beforehand, though.

> This also creates the hooks needed for implementing a hash of AuxInfo
> objects for unnamed stars.  When an AuxInfo object is required for an 
> unnamed star, instead of simply creating a new AuxInfo object, we first 
> check the hash to see if an AuxInfo object for this star already 
> exists.  If so, we set the AuxInfo pointer to the location of the 
> existing AuxInfo object.  If not, we create a new AuxInfo object, add 
> it to the hash and set the pointer.

Ahh... this looks perfect.

> I think we may have to implement the AuxInfo class and pointer now in 
> order to prevent problems with dynamically loading stars even if we 
> decide to hold off on implementing the AuxInfo hash.

I still don't understand how it will affect dynamic loading.

Regards
Akarsh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.kde.org/pipermail/kstars-devel/attachments/20080606/3d6a72a3/attachment.pgp