Skip to content
Snippets Groups Projects
  1. Dec 03, 2013
    • Christophe Geuzaine's avatar
      Changed behaviour of DefineConstant & co for better symmetry between GetDP/Gmsh · 743ee706
      Christophe Geuzaine authored
      and Python onelab clients.
      
      WARNING WARNING WARNING: This is a major change -- all our onelab-enabled .geo
      and .pro files will need to be (slightly...) modified.
      
      What's new:
      
      1. The name of a onelab variable (in the onelab database) is no more constructed
         from the name of the corresponding GetDP/Gmsh variable. One now needs to
         specify the onelab name explicitely, using the "Name" attribute. The "Name"
         is the actual name of the parameter in the onelab database, i.e., it also
         includes the path.
         
         This makes the "Path" attribute obsolete (it has no effect anymore). The
         "Legend" attribute can still be used (and it can be useful in edge cases,
         e.g. when you want a "/" in the name of a onelab paramater), but in most
         cases it's not necessary.
      
      2. When a DefineConstant[] & co is used and no Name is given
         (e.g. DefineConstant[a=2]), no onelab parameter is created. This allows to
         provide default values to internal parameters without polluting the database.
      
      Why did we change?
      
      1. The new syntax matches what we do in Python, where specifying a name is
         mandatory (there's no way around this in Python, as onelab cannot guess the
         name of a Python variable to which a onelab parameter value will be assigned).
         
         The change will prevent common mistakes where two parameters with the same
         label actually correspond to 2 different onelab parameters, due to a change
         in local getdp/gmsh variable name (which would change the onelab name
         automatically)
      
      2. The new syntax allows to nicely decouple onelab parameters from internal
         variables with default values, that we don't want in the onelab database.
      
      
      743ee706
  2. Nov 30, 2013
  3. Nov 18, 2013
    • Christophe Geuzaine's avatar
      better deletion of subclients · 0b8954ff
      Christophe Geuzaine authored
      0b8954ff
    • Christophe Geuzaine's avatar
      · 9b83d57a
      Christophe Geuzaine authored
      Trying to delete the subclients in the event loop, to prevent leaving sockets open.
      
      The old mechanism would lead to resource starvation when creating many subclients (e.g. in a loop).
      
      Please report any issues with subclients -- this is quite a big change :-)
      
      9b83d57a
  4. Oct 28, 2013
  5. Oct 25, 2013
  6. Oct 23, 2013
  7. Oct 20, 2013
  8. Oct 16, 2013
  9. Oct 03, 2013
  10. Sep 28, 2013
  11. Sep 24, 2013
  12. Sep 23, 2013
  13. Sep 22, 2013
  14. Sep 21, 2013
  15. Sep 16, 2013
  16. Sep 15, 2013
  17. Sep 14, 2013
  18. Sep 13, 2013
  19. Sep 12, 2013
  20. Sep 11, 2013
  21. Sep 10, 2013
  22. Sep 09, 2013
  23. Sep 08, 2013
  24. Sep 07, 2013
Loading