I would say it's a good idea, given what you have explained. Not that it's my place to say such things... :)
Completely random thought. Is there some sort of design document/model/random scribblings that describe the whole model for cylinders? Or am I dragging too much of a work attitude into this? Benjamin On 2 Jul 2014 06:57, "Rodrigo Severo" <[email protected]> wrote: > Please do it. > > > Rodrigo > > > On Wed, Jul 2, 2014 at 12:24 AM, Dirk Hohndel <[email protected]> wrote: > >> Hi there... >> >> I have spent three hours this evening reading and debugging our code >> around cylinders and editing. >> >> It is insane and broken and terrible in more ways that I am able to >> describe here. Terrible is actually way too kind. >> >> The fundamental design how we do things is just simply wrong. For example, >> when displaying a dive, we don't display the cylinders of that dive, but >> we copy them into the editedDive and display those cylinders. So part of >> what you see is current_dive, part is editedDive. >> >> If we then start editing a dive, depending on whether we are adding a new >> dive, planning a dive, editing a regular dive or editing a manually added >> dive we do different magic things involving not one but TWO other dive >> pointers, one is "current" inside the CylindersModel, the other one is >> stagingDive inside the DivePlannerPointsModel. So at any point in time >> there is current_dive (or master_dive), the editedDive, the stagingDive >> and the "current" variable pointing to a dive. Oh, did I mention there is >> another "current" variable in the WeightModel that at times is out of sync >> with the one in the CylindersModel? >> >> Add to that that the diveplanner also does magic things with cylinders and >> dives. We recreate a new dive for every diveplan divepoint as we plan the >> dive (Tomaz has complained about that many times). And we track the gas >> consumption in the cylinders of the dive we are assembling in ways that >> potentially overwrites data when we edit a manually added dive. >> >> Are you confused, yet? >> >> Now let's make this clear - a TON of this breakage was done by me and I am >> not yelling at anyone here for bad design. I am pointing out that this >> code is in frightening shape and that I'm uncomfortable doing a 4.2 >> release based on what's there. Bugs #553 and #582 are simply symptoms of >> the mess we (I) have created... >> >> What do people think about two weeks for fixing the outstanding bugs >> including this mess and delaying 4.2 until the end of the month? I know >> that several people (cough, Tomaz, cough) are itching to work on new >> things for 4.3... but this would give us more time to polish the planner, >> the UI, and clean up our logic and data strctures. >> >> Thoughts, praise, disagreement? >> >> /D >> >> >> _______________________________________________ >> subsurface mailing list >> [email protected] >> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface >> > > > > -- > > *Rodrigo Severo* | DIRETOR DE TECNOLOGIA > Tel. *+55 61 3030-1515 <%2B55%2061%203030-1515>* > Siga a Fábrica no twitter:*@empautaclipping* > > fabricadeideias.com <http://www.fabricadeideias.com/> > 12 ANOS DE TECNOLOGIA E COMUNICAÇÃO > NUMA COMBINAÇÃO PERFEITA > > _______________________________________________ > subsurface mailing list > [email protected] > http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface > >
_______________________________________________ subsurface mailing list [email protected] http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
