Jason Harris | 1 Aug 20:13

KDE feature freeze

Hello,

As you may know, KDE4.0-beta1 is currently being tagged in preparation for 
release.  This means that trunk is now feature-frozen, and it will be 
message-frozen on August 20th.  

So, no more feature commits in trunk until after KDE4.0 is released.  I had 
some things I had wanted to add for 4.0, but I simply didn't have time to 
work on KStars at all the past several weeks. :(

Time to work on bugfixing and optimization for 4.0.  I could really use help 
with this; is anyone available?  Even simply testing the program to identify 
problems would be a big help.  At some point we'll need to write our usual QA 
list of KStars expected behaviors, and test each of them.  

Since we can still change strings until Aug 20th, it would be a good idea to 
go through the manual to make sure everything there is up to date.  Anyone 
want to volunteer for this?

thanks,
Jason

--

-- 
KStars: KDE Desktop Planetarium
kstars <at> 30doradus.org
Akarsh Simha | 1 Aug 20:23
Picon
Gravatar

Re: KDE feature freeze

Hi Jason.

I can handle some simple testing / debugging.

I don't know much about the manual.

By the way, me being new to development, can you tell me what the "trunk" is and what "message-frozen" and "feature-frozen" mean?

Thanks.

On 8/1/07, Jason Harris <kstars <at> 30doradus.org> wrote:
Hello,

As you may know, KDE4.0-beta1 is currently being tagged in preparation for
release.  This means that trunk is now feature-frozen, and it will be
message-frozen on August 20th.

So, no more feature commits in trunk until after KDE4.0 is released.  I had
some things I had wanted to add for 4.0, but I simply didn't have time to
work on KStars at all the past several weeks. :(

Time to work on bugfixing and optimization for 4.0.  I could really use help
with this; is anyone available?  Even simply testing the program to identify
problems would be a big help.  At some point we'll need to write our usual QA
list of KStars expected behaviors, and test each of them.

Since we can still change strings until Aug 20th, it would be a good idea to
go through the manual to make sure everything there is up to date.  Anyone
want to volunteer for this?

thanks,
Jason

--
KStars: KDE Desktop Planetarium
kstars <at> 30doradus.org
_______________________________________________
Kstars-devel mailing list
Kstars-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel



--
Regards,
     Akarsh
http://www.bas.org.in
http://www.nascent-technologies.com
_______________________________________________
Kstars-devel mailing list
Kstars-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel
Jason Harris | 1 Aug 20:33

Re: KDE feature freeze

Hi Akarsh,

On Wednesday 01 August 2007 11:23, Akarsh Simha wrote:
> Hi Jason.
>
> I can handle some simple testing / debugging.
>
Thanks, that would be great.

> I don't know much about the manual.
>
> By the way, me being new to development, can you tell me what the "trunk"
> is and what "message-frozen" and "feature-frozen" mean?
>
"trunk" is the main branch of development in the SVN repository; it is the 
codebase that will eventually be tagged and released as KDE-4.0.  
"feature-frozen" simply means that no new features can be committed to trunk, 
only bugfixes.  Trunk is frozen in order to ensure that developers spend time 
fixing and optimizing their code prior to a release, so that the release is 
stable and polished.  When trunk is "message-frozen" on Aug. 20th, it means 
that no user-visible strings can be changed anymore, except to fix typos or 
other problems.  This is done in order to give the 40+ translation teams time 
to localize all of KDE into their language, without having to work against a 
moving target.

See the KDE-4.0 release schedule here:
http://techbase.kde.org/Schedules/KDE4/4.0_Release_Schedule

We can create branches in which feature development can continue while trunk 
is frozen (e.g., James's kdeedu_kstars_htm branch).  However, I would rather 
we concentrate on fixing/polishing kstars in trunk.

HTH,
Jason

> Thanks.
>
> On 8/1/07, Jason Harris <kstars <at> 30doradus.org> wrote:
> > Hello,
> >
> > As you may know, KDE4.0-beta1 is currently being tagged in preparation
> > for release.  This means that trunk is now feature-frozen, and it will be
> > message-frozen on August 20th.
> >
> > So, no more feature commits in trunk until after KDE4.0 is released.  I
> > had
> > some things I had wanted to add for 4.0, but I simply didn't have time to
> > work on KStars at all the past several weeks. :(
> >
> > Time to work on bugfixing and optimization for 4.0.  I could really use
> > help
> > with this; is anyone available?  Even simply testing the program to
> > identify
> > problems would be a big help.  At some point we'll need to write our
> > usual QA
> > list of KStars expected behaviors, and test each of them.
> >
> > Since we can still change strings until Aug 20th, it would be a good idea
> > to
> > go through the manual to make sure everything there is up to date. 
> > Anyone want to volunteer for this?
> >
> > thanks,
> > Jason
> >
> > --
> > KStars: KDE Desktop Planetarium
> > kstars <at> 30doradus.org
> > _______________________________________________
> > Kstars-devel mailing list
> > Kstars-devel <at> kde.org
> > https://mail.kde.org/mailman/listinfo/kstars-devel

--

-- 
Jason Harris
jharris <at> 30doradus.org
Jasem Mutlaq | 2 Aug 11:32

Re: KDE feature freeze

> So, no more feature commits in trunk until after
> KDE4.0 is released.  I had 
> some things I had wanted to add for 4.0, but I
> simply didn't have time to 
> work on KStars at all the past several weeks. :(
> 
> Time to work on bugfixing and optimization for 4.0. 
> I could really use help 
> with this; is anyone available?  Even simply testing
> the program to identify 
> problems would be a big help.  At some point we'll
> need to write our usual QA 
> list of KStars expected behaviors, and test each of
> them.  
> 
> Since we can still change strings until Aug 20th, it
> would be a good idea to 
> go through the manual to make sure everything there
> is up to date.  Anyone 
> want to volunteer for this?

I'll be sending my Q&A shortly, and I'll handle the
manual.

Cheers,
Jasem

> 
> thanks,
> Jason
> 
> -- 
> KStars: KDE Desktop Planetarium
> kstars <at> 30doradus.org
> _______________________________________________
> Kstars-devel mailing list
> Kstars-devel <at> kde.org
> https://mail.kde.org/mailman/listinfo/kstars-devel
> 
James Bowlin | 2 Aug 20:04
Picon

branches/work/kdeedu_kstars_htm/kstars/kstars

SVN commit 695703 by jbowlin:

NOTE: this is the HTM branch, not the trunk.

Preparing for primetime. 

The indexing needed three tweaks in order to be ready for the masses:

 1) Reverse precession correction in the SkyMesh::aperture() call.
 2) Fine tuning of the LineList JIT updating.
 3) Re-indexing of stars every 150 years.

The first one is done.  The second is almost done and I expect to have
the third one done by the end of today.

The reason the 2nd task is unfinished is because I don't know if the
constellation boundaries should precess along with the stars or if
they should be fixed to the Earth's axis like the coordinate grid.

If anyone knows if the constellation boundaries should precess or
not, please let me know and I will implement it that way.  Currently
the boundaries drawn on the screen precess but the polygons we use
to determine which constellation a point is in don't precess.
It is easy to do it either way but I can't do it both ways at the
same time (unless someone provides me with an Options::function() to
let the users choose :-).

Also, added prioritization to SkyLabeler so the most important labels
get drawn first and have a better chance of showing up since we no
longer draw labels that would overlap existing labels.  The priority
is currently:

  Planets (SolarSystemSingleComponent)
  Jupiter's Moons
  Asteroids
  Comets (which aren't being labeled ATM)
  Constellation Names
  Stars

SkyLabeler prevents labels from overlapping.  You can adjust the
vertical density with "F" and "G".  The "B" keys prints brief
statistics.  These key actions are probably for development only.
The speed and size of the SkyLabeler both scale linearly with
the number of screenRows (part of the "B" key output).

CCMAIL: kstars-devel <at> kde.org

 M  +0 -1      CMakeLists.txt  
 M  +34 -35    htmesh/HTMesh.h  
 M  +6 -5      htmesh/MeshBuffer.h  
 M  +5 -4      htmesh/MeshIterator.h  
 M  +1 -3      skycomponents/README.indexing  
 M  +3 -5      skycomponents/asteroidscomponent.cpp  
 M  +2 -4      skycomponents/cometscomponent.cpp  
 M  +17 -0     skycomponents/constellationlines.cpp  
 M  +5 -0      skycomponents/constellationlines.h  
 M  +4 -4      skycomponents/constellationnamescomponent.cpp  
 M  +11 -0     skycomponents/coordinategrid.cpp  
 M  +2 -0      skycomponents/coordinategrid.h  
 M  +2 -6      skycomponents/jupitermoonscomponent.cpp  
 D             skycomponents/linelist.cpp  
 M  +5 -5      skycomponents/linelist.h  
 M  +26 -32    skycomponents/linelistindex.cpp  
 M  +4 -4      skycomponents/linelistindex.h  
 M  +2 -2      skycomponents/polylistindex.cpp  
 M  +6 -2      skycomponents/skylabel.h  
 M  +72 -1     skycomponents/skylabeler.cpp  
 M  +62 -14    skycomponents/skylabeler.h  
 M  +13 -10    skycomponents/skymapcomposite.cpp  
 M  +24 -6     skycomponents/skymesh.cpp  
 M  +23 -17    skycomponents/skymesh.h  
 M  +2 -2      skycomponents/solarsystemsinglecomponent.cpp  
 M  +4 -19     skycomponents/starcomponent.cpp  
 M  +9 -0      starobject.cpp  
 M  +5 -0      starobject.h  
James Bowlin | 3 Aug 01:36
Picon

branches/work/kdeedu_kstars_htm/kstars/kstars

SVN commit 695797 by jbowlin:

I implemented re-indexing of the stars every 150 years.  I'm haven't
run extensive tests yet to verify it is doing exactly what it is
supposed to but it seems to be working and hasn't broken anything. The
only big surprise was that it only takes 3 to 4 seconds to re-index
all the stars on a single core of an amd64 3600+.

I'm working on precessing the constellation boundary polygons but this
has turned out to be a little messy because the data is stored in
QPointF's, not SkyPoints so I need to create a new SkyPoint for every
point on the boundaries in order to do the precession.

I also need to re-index the constellation lines every 150 years just
like I do for the stars because stars form the vertices of the
constellation lines.  To do this the right way I will have to change
the data members that hold the index in LineListIndex into pointers
(instead of simply values).  I'll probably do this tomorrow.

I fixed a minor bug I had created in KStarsData where I was updating
m_updateNum more frequently than necessary.

Finally, I found a bug in the constellation lines that I don't
understand.  You can see it by zooming in on Markab, Homan, and Baham
in PEGASUS and setting the time step to one minute.  The stars will
jump away from the constellation line just a bit.  I'm a little
baffled by this because the vertices of the lines are supposed to be
the actual stars so I don't understand how they could ever not line
up.  Also, you can jump back in time 1000 years and the stars are all
attached to the lines again but if you march time forward at one
minute steps, the little jumps appear again.  I don't think this is an
Earth shattering problem, it is probably due to my lack of
understanding of the subtleties of updating StarObjects and SkyPoints.
I'll try to figure this out tomorrow.

CCMAIL: kstars-devel <at> kde.org

 M  +3 -3      kstarsdata.cpp  
 M  +28 -2     skycomponents/constellationboundarypoly.cpp  
 M  +6 -3      skycomponents/constellationboundarypoly.h  
 M  +6 -0      skycomponents/constellationlines.cpp  
 M  +5 -0      skycomponents/constellationlines.h  
 M  +1 -1      skycomponents/polylist.h  
 M  +5 -2      skycomponents/polylistindex.h  
 M  +4 -1      skycomponents/skymapcomposite.cpp  
 M  +6 -0      skycomponents/skymesh.cpp  
 M  +2 -0      skycomponents/skymesh.h  
 M  +45 -6     skycomponents/starcomponent.cpp  
 M  +10 -3     skycomponents/starcomponent.h  
 M  +9 -0      starobject.cpp  
 M  +8 -0      starobject.h  

--- branches/work/kdeedu_kstars_htm/kstars/kstars/kstarsdata.cpp #695796:695797
@@ -54,7 +54,7 @@

 KStarsData::KStarsData(KStars* kstars) : locale(0),
 		LST(0), HourAngle(0), initTimer(0), m_kstars(kstars), 
-        m_updateID(0), m_updateNumID(0), m_updateNum(0)
+        m_updateID(0), m_updateNumID(0), m_updateNum( J2000 )
 {
 	startupComplete = false;
 	objects++;
@@ -274,8 +274,7 @@
 	}

 	KSNumbers num( ut().djd() );
-    m_updateNum = num;
-
+   
 	//TIMING
 	QTime t;

@@ -285,6 +284,7 @@
 		//		t.start();

         m_updateNumID++;
+        m_updateNum = num;
 		skyComposite()->update( this, &num );

 		//TIMING
---
branches/work/kdeedu_kstars_htm/kstars/kstars/skycomponents/constellationboundarypoly.cpp #695796:695797
@@ -34,8 +34,7 @@

 ConstellationBoundaryPoly::ConstellationBoundaryPoly( SkyComponent *parent )
   : PolyListIndex( parent )
-{   
-}
+{}

 
 //-------------------------------------------------------------------
@@ -64,6 +63,33 @@
 	return false;
 }

+// We don't need the rotation update but we still need to precess (I think).
+// This is a minor nightmare.  If we need to precess the boundaries then
+// we may want to rethink the data storage.
+void ConstellationBoundaryPoly::update( KStarsData *data, KSNumbers *num )
+{
+    /** -jbb need to use an iterator over the PolgonF in order to
+     * update then inclosed ra, dec values.
+
+    if ( ! num ) return;
+    PolyIndex* index = polyIndex();
+    for (int i = 0; i < index->size(); i++ ) {
+        PolyListList* listList = index->at( i );
+        for ( int j = 0; j < listList->size(); j++ ) {
+            QPolygonF poly = listList->at( j )->poly();
+            for ( int k = 0; k < poly->size(); k++ ) {
+                QPointF p = 
+                double ra = poly->at( k ).x();
+                double dec = poly->at( k ).y();
+                SkyPoint p( ra, dec );
+                p->updateCoords( num );
+
+            }
+        }
+    }
+    **/
+}
+
 /**
 const QPolygonF& ConstellationBoundaryPoly::boundary( const QString &name ) const
 {
--- branches/work/kdeedu_kstars_htm/kstars/kstars/skycomponents/constellationboundarypoly.h #695796:695797
@@ -37,9 +37,6 @@

 class ConstellationBoundaryPoly : public PolyListIndex
 {
-
-	private:
-
 	public:
 	/**
 		*@short Constructor
@@ -47,12 +44,18 @@
 		*/
 		ConstellationBoundaryPoly( SkyComponent *parent );

+        /* @short this is now required to precess the boundaries.
+         */
+        void update( KStarsData *data, KSNumbers *num );
+
 		const QPolygonF& boundary( const QString &name ) const;

 		QString constellationName( SkyPoint *p );

     	bool inConstellation( const QString &name, SkyPoint *p );

+    private:
+
 };

 
--- branches/work/kdeedu_kstars_htm/kstars/kstars/skycomponents/constellationlines.cpp #695796:695797
@@ -125,3 +125,9 @@
 }

 
+void ConstellationLines::update( KStarsData *data, KSNumbers *num )
+{
+    
+}
+
+
--- branches/work/kdeedu_kstars_htm/kstars/kstars/skycomponents/constellationlines.h #695796:695797
@@ -59,6 +59,11 @@
          */
         void update( KStarsData *data, LineList* lineList );

+        /* @short we use the update hook to re-index the constellation lines
+         * every 150 years to account for proper motion of the stars.
+         */
+        void update( KStarsData *data, KSNumbers *num );
+
        /* @short Set the QColor and QPen for drawing.
         */
         void preDraw( KStars *ks, QPainter &psky );
--- branches/work/kdeedu_kstars_htm/kstars/kstars/skycomponents/polylist.h #695796:695797
@@ -44,7 +44,7 @@

         /* @short returns the QPolygonF that holds the points.
          */
-        const QPolygonF& poly() { return m_poly; }
+const QPolygonF& poly() { return m_poly; }

         /* @short we need a new append() method to append QPointF's
          * instead of SkyPoints.
--- branches/work/kdeedu_kstars_htm/kstars/kstars/skycomponents/polylistindex.h #695796:695797
@@ -25,7 +25,8 @@

 class PolyList;

-typedef QVector<PolyList*> PolyListList;
+typedef QVector<PolyList*>        PolyListList;
+typedef QVector<PolyListList*>    PolyIndex;
 typedef QHash<QString, PolyList*> PolyNameHash;

 /* @class PolyListIndex
@@ -53,13 +54,15 @@

         PolyList* ContainingPoly( SkyPoint *p );

+        PolyIndex* polyIndex() { return & m_polyIndex; }
+
         const PolyNameHash& nameHash() { return m_nameHash; }

         void summary();

 	private:
         SkyMesh*                 m_skyMesh;
-        QVector<PolyListList*>   m_polyIndex;
+        PolyIndex                m_polyIndex;
         int                      m_polyIndexCnt;
 		PolyNameHash             m_nameHash;

--- branches/work/kdeedu_kstars_htm/kstars/kstars/skycomponents/skymapcomposite.cpp #695796:695797
@@ -127,7 +127,7 @@
 	//m_CoordinateGrid->update( data, num );
 	//3. Constellation boundaries
 	//m_CBounds->update( data, num );
-	m_CBoundsBoundary->update( data, num );  // FIXME: -jbb do we need this???
+	m_CBoundsBoundary->update( data, num );
 	//4. Constellation lines
 	//m_CLines->update( data, num );
 	//5. Constellation names
@@ -142,6 +142,9 @@
 	m_CustomCatalogs->update( data, num );
 	//10. Stars
 	m_Stars->update( data, num );
+
+    //m_CLines->update( data, num );  // MUST follow stars.
+
 	//12. Solar system
 	m_SolarSystem->update( data, num );
 	//13. Satellites
--- branches/work/kdeedu_kstars_htm/kstars/kstars/skycomponents/skymesh.cpp #695796:695797
@@ -66,6 +66,12 @@
     return HTMesh::index( p->ra()->Degrees(), p->dec()->Degrees() );
 }

+Trixel SkyMesh::index( double ra, double dec)
+{
+    return HTMesh::index( ra, dec );
+}
+
+
 void SkyMesh::index(SkyPoint *p, double radius)
 {
     HTMesh::intersect( p->ra()->Degrees(), p->dec()->Degrees(), radius);
--- branches/work/kdeedu_kstars_htm/kstars/kstars/skycomponents/skymesh.h #695796:695797
@@ -129,6 +129,8 @@
         */
         Trixel index( SkyPoint *p );

+        Trixel index( double ra, double dec );
+
        /* @short finds the indices of the trixels covering the circle
         * specified by center and radius.
         */
--- branches/work/kdeedu_kstars_htm/kstars/kstars/skycomponents/starcomponent.cpp #695796:695797
@@ -37,13 +37,14 @@

 
 StarComponent::StarComponent(SkyComponent *parent ) 
-: ListComponent(parent), m_FaintMagnitude(-5.0)
+: ListComponent(parent), m_indexDate( J2000 ), m_FaintMagnitude(-5.0)
 {
     m_skyMesh = ((SkyMapComposite*) parent)->skyMesh();
     m_skyLabeler = ((SkyMapComposite*) parent)->skyLabeler();

+    m_starIndex = new StarIndex();
     for (int i = 0; i < m_skyMesh->size(); i++) {
-        m_starIndex.append( new StarList() );
+        m_starIndex->append( new StarList() );
     }

     lastFilePos = 0;
@@ -57,9 +58,47 @@
     return Options::showStars();
 }

+// We use the update hook to re-index all the stars when the
+// date has changed by more than 150 years.
+
 void StarComponent::update( KStarsData *data, KSNumbers *num )
-{}
+{
+    if ( ! num ) return;
+    if (fabs( data->ut().epoch() - m_indexDate.epoch() ) < 150.0 ) return;
+    
+    printf("Now: %.1f\n", data->ut().epoch() );
+    printf("LU : %.1f\n", m_indexDate.epoch() );

+    m_indexDate.setDJD( data->ut().djd() );
+
+    printf("Re-indexing Stars ...\n");
+
+    // Create a new index
+    StarIndex* newIndex = new StarIndex();
+    for (int i = 0; i < m_skyMesh->size(); i++) {
+        newIndex->append( new StarList() );
+    }
+
+    // Fill it with stars from old index
+    double ra, dec;
+
+    for ( int i = 0; i < m_skyMesh->size(); i++ ) {
+        StarList* starList = m_starIndex->at( i );
+        for ( int j = 0; j < starList->size(); j++ ) {
+            StarObject* star = starList->at( j );
+            star->getIndexCoords( num, &ra, &dec );
+            Trixel trixel = m_skyMesh->index( ra, dec );
+            newIndex->at( trixel )->append( star );
+        }
+        delete starList;
+    }
+    delete m_starIndex;
+    m_starIndex = newIndex;
+
+    printf("Done.\n");
+}
+
+
 void StarComponent::init(KStarsData *data)
 {
 	emitProgressText( i18n("Loading stars" ) );
@@ -123,7 +162,7 @@
 	//Loop for drawing star images
     MeshIterator region(m_skyMesh, DRAW_BUF);
     while ( region.hasNext() ) {
-        StarList* starList = m_starIndex[ region.next() ];
+        StarList* starList = m_starIndex->at( region.next() );
         for (int i=0; i < starList->size(); ++i) {
 		    StarObject *curStar = (StarObject*) starList->at( i );

@@ -304,7 +343,7 @@
 	objectList().append(o);

     int starID = m_skyMesh->index( (SkyPoint*) o );
-    m_starIndex[starID]->append( o );
+    m_starIndex->at( starID )->append( o );

     if ( ! gname.isEmpty() ) m_genName.insert( gname, o );

@@ -330,7 +369,7 @@
 	StarObject *oBest = 0;
     MeshIterator region(m_skyMesh, OBJ_NEAREST_BUF);
     while ( region.hasNext() ) {
-        StarList* starList = m_starIndex[ region.next() ];
+        StarList* starList = m_starIndex->at( region.next() );
         for (int i=0; i < starList->size(); ++i) {
 		    StarObject* star =  starList->at( i );
             if ( star->name() == i18n("star") ) continue;  // prevents "star" popups --jbb
--- branches/work/kdeedu_kstars_htm/kstars/kstars/skycomponents/starcomponent.h #695796:695797
@@ -29,6 +29,8 @@
 #define NHIPFILES 127

 #include "listcomponent.h"
+#include "kstarsdatetime.h"
+
 #include "typedef.h"

 class SkyComponent;
@@ -39,6 +41,9 @@
 class StarObject;
 class SkyLabeler;

+
+typedef QVector< StarList* > StarIndex;
+
 class StarComponent: public ListComponent
 {
 	public:
@@ -93,9 +98,11 @@
         SkyObject* findStarByGenetiveName( const QString name );

 	private:
-        SkyMesh*              m_skyMesh;
-        QVector< StarList* >  m_starIndex;
-        SkyLabeler*           m_skyLabeler;
+        SkyMesh*       m_skyMesh;
+        StarIndex*     m_starIndex;
+        SkyLabeler*    m_skyLabeler;
+
+        KStarsDateTime m_indexDate;

         qint64 lastFilePos;

--- branches/work/kdeedu_kstars_htm/kstars/kstars/starobject.cpp #695796:695797
@@ -106,6 +106,15 @@
 	setDec( dec()->Degrees() + pmDec()*num->julianMillenia()/3600. );
 }

+void StarObject::getIndexCoords( KSNumbers *num, double *ra, double *dec )
+{
+    *ra = ra0()->Degrees() + 
+        pmRA() * num->julianMillenia() / cos( dec0()->radians() ) / 3600.0;
+
+    *dec = dec0()->Degrees() + 
+        pmDec() * num->julianMillenia() / 3600.0;
+}
+
 void StarObject::update( KStarsData* data )
 {
     updateID = data->updateID();
--- branches/work/kdeedu_kstars_htm/kstars/kstars/starobject.h #695796:695797
@@ -136,6 +136,14 @@
 	*/
 	virtual void updateCoords( KSNumbers *num, bool includePlanets=true, const dms *lat=0, const dms
*LST=0 );

+    /* @short fills ra and dec with the coordinates of the star with the proper
+     * motion correction but without precesion and its friends.  It is used
+     * in StarComponent to re-index all the stars.
+     *
+     * NOTE: ra and dec both in degrees.
+     */
+    void getIndexCoords( KSNumbers *num, double *ra, double *dec );
+
     /* @short added for JIT updates from both StarComponent and ConstellatoinLines
      */
     void update( KStarsData* data );

Jason Harris | 3 Aug 02:42

Re: branches/work/kdeedu_kstars_htm/kstars/kstars

Hi James,

On Thursday 02 August 2007 16:36, James Bowlin wrote:
> SVN commit 695797 by jbowlin:
>
> I implemented re-indexing of the stars every 150 years.  I'm haven't
> run extensive tests yet to verify it is doing exactly what it is
> supposed to but it seems to be working and hasn't broken anything. The
> only big surprise was that it only takes 3 to 4 seconds to re-index
> all the stars on a single core of an amd64 3600+.
>
Excellent.  Can the re-indexing be performed in the background while the UI 
remains responsive?

> I'm working on precessing the constellation boundary polygons but this
> has turned out to be a little messy because the data is stored in
> QPointF's, not SkyPoints so I need to create a new SkyPoint for every
> point on the boundaries in order to do the precession.
>
Regarding the constellation boundaries: believe it or not, we actually should 
not precess them.  They were defined by the IAU in the 1930s to divide the 
sky into 88 regions, but the vertices of these lines are fixed RA/Dec values.  
They were actually drawn up using epoch 1875.0, so there are already 
significant offsets (for example, the southern border of Canis Minor is just 
below the equator, and is not quite parallel to it).

> I also need to re-index the constellation lines every 150 years just
> like I do for the stars because stars form the vertices of the
> constellation lines.  To do this the right way I will have to change
> the data members that hold the index in LineListIndex into pointers
> (instead of simply values).  I'll probably do this tomorrow.
>
It would probably make more sense to modify ConstellationLineComponent so that 
it stores a QList of pointers to the star objects themselves, rather than 
creating its own copies of these points.  I can try to take care of this if 
you agree it's a good idea.

regards,
Jason

--

-- 
KStars: KDE Desktop Planetarium
kstars <at> 30doradus.org
Jason Harris | 3 Aug 02:46

Re: KDE feature freeze

Hi again,

On Wednesday 01 August 2007 11:13, Jason Harris wrote:
> Hello,
>
> As you may know, KDE4.0-beta1 is currently being tagged in preparation for
> release.  This means that trunk is now feature-frozen, and it will be
> message-frozen on August 20th.
>
FYI, this may not be set in stone yet.  There's been a discussion on the 
release-team mailing list on whether the apps are currently frozen or not, 
and no consensus has been reached yet.

Today I made a proposal on that list[1] that would leave apps in a "soft" 
freeze until the messages freeze hits (currently scheduled for Aug 20th).  
The soft freeze would mean that changes are allowed if approved by the 
module's release coordinator and/or by consensus on the module's mailing 
list.  My proposal hasn't received any replies yet.

I'll keep you posted on further developments.  

regards,
Jason

[1]: http://mail.kde.org/pipermail/release-team/2007-August/000555.html

--

-- 
KStars: KDE Desktop Planetarium
kstars <at> 30doradus.org
James Bowlin | 3 Aug 04:11
Picon

Re: branches/work/kdeedu_kstars_htm/kstars/kstars

On Thu August 2 2007 6:42 pm, Jason Harris wrote:
> Excellent.  Can the re-indexing be performed in the background while
> the UI remains responsive?

I'll think about it.  My gut feeling is to put this off until 4.2
or 4.3. I think a little splash screen might be appropriate explaining
what is going on.  It would be easy for me to update it with the 
percentage completed.  I don't think a 4 second wait to get a very
fast UI is terrible.  I think I can do just what you want but I want
to wait until we know what I've done so far is rock steady first.

If you think this is important, I can start working on it next if
you want.

> Regarding the constellation boundaries: believe it or not, we
> actually should not precess them.  They were defined by the IAU in
> the 1930s to divide the sky into 88 regions, but the vertices of
> these lines are fixed RA/Dec values. They were actually drawn up
> using epoch 1875.0, so there are already significant offsets (for
> example, the southern border of Canis Minor is just below the
> equator, and is not quite parallel to it).

Great!  One less ugly thing to do.

> > I also need to re-index the constellation lines every 150 years
> > just like I do for the stars because stars form the vertices of the
> > constellation lines.  To do this the right way I will have to
> > change the data members that hold the index in LineListIndex into
> > pointers (instead of simply values).  I'll probably do this
> > tomorrow.
>
> It would probably make more sense to modify
> ConstellationLineComponent so that it stores a QList of pointers to
> the star objects themselves, rather than creating its own copies of
> these points.  I can try to take care of this if you agree it's a
> good idea.

This is what baffles me.  I don't make a copy, I put a pointer to the 
star itself into the ConstellationLines LineLists:

SkyObject *star = data->skyComposite()->findStarByGenetiveName( name );
if ( star && lineList ) {
    lineList->points()->append( star );
}

I rewrote FindStarByGenetiveName to use a hash to make the lookup fast
so I'm certain there is no copying going on.  I had originally used
a copy but that quickly broke badly as time advanced.  This is a
different problem because the stars just jump a little and then the
lines eventually catch up.  Is it possible that a StarObject will 
occasionally return different (ra, dec) values depending on whether
it is cast as a SkyPoint or a StarObject?  This seems unlikely.

But I still need to re-index the constellation lines just like the
stars because the stars are at new locations in the index due to
proper motion.

--

-- 
Peace, James
Jason Harris | 3 Aug 06:54

Re: branches/work/kdeedu_kstars_htm/kstars/kstars

Hi,

James Bowlin wrote:
> This is what baffles me.  I don't make a copy, I put a pointer to the 
> star itself into the ConstellationLines LineLists:
> 
> SkyObject *star = data->skyComposite()->findStarByGenetiveName( name );
> if ( star && lineList ) {
>     lineList->points()->append( star );
> }
> 
You want to be careful here.  The SkyLine destructor deletes all the 
SkyPoints in its list; this may cause problems because each star that is 
a constellation vertex will be double-deleted when KStars shuts down.

Maybe it's not a problem, but you should be aware of it.

> I rewrote FindStarByGenetiveName to use a hash to make the lookup fast
> so I'm certain there is no copying going on.  I had originally used
> a copy but that quickly broke badly as time advanced.  This is a
> different problem because the stars just jump a little and then the
> lines eventually catch up.  Is it possible that a StarObject will 
> occasionally return different (ra, dec) values depending on whether
> it is cast as a SkyPoint or a StarObject?  This seems unlikely.
> 
Hmm, that is weird.  I'll have to think about it.

> But I still need to re-index the constellation lines just like the
> stars because the stars are at new locations in the index due to
> proper motion.
> 

Gmane