I completely agree that we need to rework thst part, too many indirections making the code very fragile. For that I can hold on doing code for 4.3 =p Em 02/07/2014 01:25, "Benjamin" <[email protected]> escreveu:
> 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 > >
_______________________________________________ subsurface mailing list [email protected] http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
