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

[Akarsh Simha]

> If every star had an HD index number then we could use that for a unique
> identifier.  Since (as I understand) some stars don't have an HD index
> number, we can put our own negative numbers in the HDIndex field for 
> those stars so we can use that field as a unique ID for every star.
> The number is unique for every star.  If it is positive, it is the 
> actual HD index.  If it is negative then it is a number we created in
> order to get a unique ID for every star.

Ok. Thanks for clarifying that.

> The only other alternative I see is adding an addition int32 to create
> our own unique ID for every star.  My scheme above means we don't have
> to add another field to StarData.

I'd prefer not to add anything to starData, because that will cause
alignment issues with struct starData. We have 12 bits free in the HD
number field (which is int32, if I amn't mistaken), 8 bits free in
'unused', and 5 bits free in flags.  If required, we could use this to
extend the HD numbers to provide UIDs to all stars. So I'd prefer to
go with your solution.

> > 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.
> 
> Yes, I thought of this too.  The thing is that for most objects, we 
> don't need to go to the trouble of going through a hash if we just 
> create the AuxInfo objects as needed as I described below.

Yes. I agree on that.

> > 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 misunderstood.

Thanks for clarifying that. As you say, it might cause problems
sometime. Right now everything seems to be ok - the logs of different
objects aren't getting mixed up. Probably QStringList doesn't use
pointers, but I'll need to look into that.


> Jason may already be working on changing SkyObject so please coordinate 
> with him.  

Okay.

> Perhaps you have a slightly different vision of the way it would work, 
> but the way I see it the unique ID we create from the HD index is only
> needed to keep an AuxInfo tied to a particular star while KStars is 
> running.  Therefore you could just use negative numbers for every star
> (for now) and then when the HD index numbers arrive we can change the 
> field to the combined HD index / negative number that I suggest above.  
> I don't see where these numbers get saved to disk (except in the binary
> star data file) so even if they all changed every time KStars started,
> there wouldn't be a problem.

Fine. That seems ok.

> On the other hand, I see no problem with delaying the implementation of
> the AuxInfo hash.  As long as we aren't doing a memcpy of structures we
> are going to write to, I'm happy.

Agreed.


> If we do nothing it still seems to me there still might be problems 
> because the QStrings and QStringLists that we memcpy will have internal 
> pointers and references that are now all pointing / referring to the 
> same memory.  It is possible that the internal structure of QString and 
> QStringList is robust enough to withstand this kind of abuse but I 
> would hate to assume it is all just going to work complaint free.  Even 
> if it doesn't fail catastrophically, it certainly won't do what we want 
> it to do.  There would be just one userLog, etc for all of the dynamic 
> stars.

Agreed here. We shouldn't be abusing QStringList as we currently are.

Some clarifications - I probably overlooked something when I last
tested it. The saving of user data on the disk seems to be working
fine. I thought it was buggy. I'm sorry form spamming Jason on that!

Another thing I notice is that we currently provide Observation Log /
User Link entries only for named objects [Named Stars, cataloged DSOs,
comets, asteroids and planets]. We could as well continue with that,
or extend it to all stars having HD numbers.

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/c3a111a1/attachment-0001.pgp