Menu

#498 Inconsistency with measurement Groups with capital letters

Jan17
resolved
None
sardana-widgets
bug
2016-09-28
2016-08-12
No

There is a inconsistency with the measurement groups that use capital letters.

If the MeasurementGroup is defined with any capital letter, on open the 'expconf' the 'Active Measurement Group' selector appears empty.

Also, the Listener 'onExpConfChanged' (Taurus macrolistener) raise a exception "ActiveMntGrp XXX is not defined" on use it.

The 'ExperimentConfiguracion' Object has a Dictionary with the current experiment configuration, like 'ActiveMntGrp' and the configuration of all MntGrps instantiated, these configurations are saved in a dictionary using the MntGrp names in lowercase letter as keys.

On Open the expConf, it cannot find the 'ActiveMntGrp' value in the configuration dictionary keys, because are differents ('MntGrp' != 'mntgrp').

Related

OLD Tickets: #515

Discussion

  • Daniel Roldan

    Daniel Roldan - 2016-08-12

    A PATCH has been sent to the list.

     
    • Carlos Pascual

      Carlos Pascual - 2016-08-22

      I am not sure about the implementation in the patch. It assumes that the measurement groups are inserted in lower case, and on a first look I do not see that this is the case.

       
  • Zbigniew Reszela

    The measurement group names are indeed casted to lowercase in the expconf (the sardana.taurus.core.tango.sardana.macroserver.ExperimentConfiguration class stores the measurement groups configurations in a CaselessDict).
    In my opinion the measurement group combobox should show the names respecting the case introduced by the user. I have already implemented this (and fixed some other stuff) in the following branch: https://sourceforge.net/u/cmft/sardana-GenericSoftware/ci/bug-498/tree/
    Daniel, could you please check if it satisfies your needs, and after that, Carlos could you please check my solution and integrate it?

    It is related to Taurus bug-333

     
    • Carlos Pascual

      Carlos Pascual - 2016-08-23

      If I am not mistaken, using a CaselessDict is not equivalent to casting to lowercase. CaselessDict preserves the original case and it just overloads the comparisons and the indexing methods to perform caseless matching.

      So I still do not think that the implementation for this (and for Taurus bug-333 is the ideal one.

       
      • Zbigniew Reszela

        I thought exactly the same, but checking that I realized that it does the cast to lowercase. See the following example (using the latest support-3.x):

        In [23]: from taurus.core.util.containers import CaselessDict
        In [24]: d = CaselessDict()
        In [25]: d["TEST"] = "TEST"
        In [26]: d
        Out[26]: {'test': 'TEST'}
        In [27]: d.keys()
        Out[27]: ['test']
        

        I think that the __setitem__ method of the __CaselessDict__ is responsible for that:

        def __setitem__(self, key, value):
            dict.__setitem__(self, key.lower(), value)
        
         
        • Carlos Pascual

          Carlos Pascual - 2016-08-23

          See my snippet here

           
        • Carlos Pascual

          Carlos Pascual - 2016-08-23

          You are right. CaselessDict does not preserve the case (which IMHO is a bad design... but it is probably late for changing it).
          But still, I think that our approach should be based on using:

          name in d
          

          instead of

          name.lower() in d.keys()
          
           
          • Zbigniew Reszela

            I agree, this makes some commits that I posted not necessary (I have not realized that __contains__ and __del__ methods of CaselessDict are also overridden). I will rewrite the history of the previously referenced branch.

             
  • Zbigniew Reszela

    • labels: expconf, mntgrp, measurementgroup -->
    • assigned_to: Zbigniew Reszela
    • Category: ms --> sardana-widgets
    • Milestone: unassigned --> Jul16
     
  • Zbigniew Reszela

    The history of the remote branch was rewritten and now contains only two commits.
    From my side it is ready for tests and integration.

     
  • Zbigniew Reszela

    • Milestone: Jul16 --> Jan17
     
  • Teresa Nunez

    Teresa Nunez - 2016-09-28
    • status: waiting --> resolved