RE: Yodii Happy Debugging

[Olivier Spinelli]

Bonjour,

La branche « develop » est ok, avec deux choses :

1 - Le cas ci-dessous est fixed :
/**
* +--------+
* +---------->| S1 |
* | | |
* | +---+----+
* | |
* | |
* | +---+-----+
* +---+-----+ | P |
* | S.1.1 | | |
* | Running | +---------+
* +----+----+
*
*/
Merci de l'avoir trouvé, c'était un cas trivial qui a montré que le Disabling d'un Service lorsque celui-ci était LE Family.RunningService n'était pas géré correctement.

2 - On ne comprenait pas grand-chose car les Debug.Assert n'étaient pas honorés dans Yodii.Lab.

Voici comment il faut travailler :

- Dans Yodii.Engine.Tests, il FAUT COCHER Tools >> Options... >> Debugging >> Enable Just My Code

- Quand on travaille dans Yodii.Lab.exe, il FAUT DECOCHER Tools >> Options... >> Debugging >> Enable Just My Code

Et pouf.

Spi


From: Olivier Spinelli
Sent: mardi 1 avril 2014 10:37
To: 'FINKEL Martin'
Cc: SIMONARD Emilie; BONTEMPS Franck
Subject: RE: Yodii Happy Debugging

C'est normal que l'on ne comprenne rien : Les Debug.Assert ne fonctionnent pas... toujours... dans Yodii.Lab.
On regarde.

En attendant, j'ai reproduit le test dans f-runnable (que je viens de push), dans
Yodii.Engine.Tests.ConfigurationSolverTests.CurrentFailureTests.RunningServiceWithNoPlugin

Et dans NUnit.Runners, ce

Debug.Assert( Family.RunningService != this || _inheritedServicesWithThis.All( s => s.Disabled ), "If we were the RunningService, no one else is running." );


Pète dans ce cas, ce qui est normal et qui montre que l'on a pas disabled S1. On aurait dû.

Spi


From: FINKEL Martin [mailto:fin...@intechinfo.fr]
Sent: lundi 31 mars 2014 14:00
To: Olivier Spinelli
Cc: SIMONARD Emilie; BONTEMPS Franck
Subject: Yodii Happy Debugging


Hi,



Petite matinée de plongée sympathique avec Emilie, enfiles ton casque, gants, palmes, coque et machettes.



Pour le graphe PNG en pièce jointe, on y est allé en Step by Step:

1. S1.1 est running donc S1 devient Running.

2. S1.1 devient Disabled car il n'a pas de plugin (mais il a tout de même propagé son status Running à son papa !).



En théorie, on devrait s'arrêter là. Un item (S1.1) était Running by config et il se retrouve taggé Disabled donc bloquant.



Comme on en parlait Vendredi dernier, l'idéal serait de sortir dès qu'un problème bloquant a été détecté. Ce n'est pas encore le cas et voici ce qui se passe:



On déclenche le debug.Assert suivant :
line: 320

file: ServiceData.Static

question: _inheritedServicesWithThis.All( s => s.Disabled ) - Pourquoi à cet endroit là?

=> on ne comprend pas le but de cette ligne dans ce cas précis.



Ayant passé le debug.Assert, là où ça commence à bien bien déconner, c'est ici : le passage suivant désactive le root sans raison (il y a 1 plugin dispo) valable.

line: 90-100

file: ServiceData.ServiceFamily.Static



if( !_runningService.IsStrictGeneralizationOf( s ) )
{
ServiceDisabledReason r = Solver.Step == ConfigurationSolverStep.RegisterServices ? ServiceDisabledReason.AnotherServiceIsRunningByConfig : ServiceDisabledReason.AnotherServiceRunningInFamily;
s.SetDisabled( r );
if( !Root.Disabled ) Root.SetDisabled( ServiceDisabledReason.AtLeastTwoSpecializationsMustRun );
return false;
}



BTW: 2ème fois que l'on rentre dans cette fonction(la 1ère fois étant avant de passer dans l'Assert d'en haut).



On est en PFH cet aprem et demain matin mais ce serait peut être cool qu'on se coordonne pour passer à Invenietis bientôt, si tu as le temps.



Bon aprem!



PS: Franck est en copie parce qu'il est curieux.