Fr/A local weather system: Difference between revisions

Fr/A local weather system (view source)

Revision as of 13:50, 30 October 2012

77 bytes added , 30 October 2012

m

no edit summary

Sahliyoussef

32

edits

@@ Line 110: / Line 110: @@
 == Dévelopemment ==
-* Some users have expressed having problems when using the reset/new location facility, the local weather system should probably register listeners to /sim/signals/* and suspend/reset itself accordingly, so that all operations are gracefully interrupted? This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=165#p94765]
+* Quelques utilisateurs ont affirmé avoir des problèmes en utilisant l'outil recommencer/nouveau lieu; le système de météo locale devrait enregistrer dans /sim/signals/* et se suspendre/remettre à zéro lui-même, de sorte que toutes les opérations soient correctement mises en pause. This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=165#p94765]
-* Dynamically examining the FG/Nasal APIs by running code that may cause exceptions, may also cause errors printed to the console, it would probably be a good idea to expose logging related variables to the property tree, so that the log system can be optionally muted in such cases, i.e. by introducing a "NONE" or "MUTE" logging priority [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&p=96439#p96370].
+* Dynamiquement examiner les APIs FG/Nasal en faisant marcher le code responsable d'exceptions, peut aussi causer certaines impressions d'erreurs sur la console, cela serait une bonne idée d'exposer les variables à l'arbre de propriétés, de sorte que le système log peut quelques fois être dans de tels cas, c'est à dire en introduisant une priorité "nulle" ou "muette" : [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&p=96439#p96370].
 * The feature-checking approach used by "compat_layer.nas" should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&p=96439#p96358]
 * we could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized.