search

sardana-org / sardana

Moved to GitLab: https://gitlab.com/sardana-org/sardana
39 stars 52 forks source link

'NoneType' object has no attribute 'getType' on editing macro in a new location (SF#455) #300

Open sf-migrator-bot opened 8 years ago

sf-migrator-bot commented 8 years ago

Hi,

When I try to edit a macro in a new location (e.g. /home/jkotan/sardanaMacros/nxsmacros.py) I get the following error:

p09/door/haso228k.01 [1]: %edmac lsprof /home/jkotan/sardanaMacros/nxsmacros.py
Opening /home/jkotan/sardanaMacros/nxsmacros.py.lsprof...
Editing... 
Do you want to apply the new code on the server? [y] y
Storing... [DONE]

p09/door/haso228k.01 [2]: TaurusTP.W003  ERROR    2016-04-05 13:53:49,407 haso228k.desy.de:10000.p09/macroserver/haso228k.01: Exception occurred processing elements
TaurusTP.W003  ERROR    2016-04-05 13:53:49,407 haso228k.desy.de:10000.p09/macroserver/haso228k.01: Details:
Traceback (most recent call last):
  File "/home/jkotan/testsar/lib/python2.7/site-packages/sardana/taurus/core/tango/sardana/macroserver.py", line 811, in on_elements_changed
return self._on_elements_changed(evt_src, evt_type, evt_value)
  File "/home/jkotan/testsar/lib/python2.7/site-packages/sardana/taurus/core/tango/sardana/macroserver.py", line 836, in _on_elements_changed
element = self._removeElement(element_data)
  File "/home/jkotan/testsar/lib/python2.7/site-packages/sardana/spock/spockms.py", line 555, in _removeElement
element = BaseMacroServer._removeElement(self, element_data)
  File "/home/jkotan/testsar/lib/python2.7/site-packages/sardana/taurus/core/tango/sardana/macroserver.py", line 850, in _removeElement
self.getElementsInfo().removeElement(element)
  File "/home/jkotan/testsar/lib/python2.7/site-packages/sardana/taurus/core/tango/sardana/sardana.py", line 163, in removeElement
elem_type = e.getType()
AttributeError: 'NoneType' object has no attribute 'getType'

where previously nxsmacros.py where loaded from diffrent MacroPath (e.g. from /usr/lib/python2.7/dist-packages/sardana/sardana-macros/DESY_general/nxsmacros.py).

After then I get also the same error when I try to run

 relmaclib nxsmacros

To cure this situation I have to exit the spock session and run spock again. Then everything works till I change the location of my macros again.

Bests, Jan

Reported by: jkotan ( http://sf.net/u/jkotan )

Original Ticket: sardana/tickets/455

sf-migrator-bot commented 8 years ago

Hi,

it seems that in this case sardana tries to remove the old macro from a new location. One of the possible quick fix could be:

diff --git a/src/sardana/taurus/core/tango/sardana/macroserver.py b/src/sardana/taurus/core/tango/sardana/macroserver.py
index f886bb3..9b8c122 100644
--- a/src/sardana/taurus/core/tango/sardana/macroserver.py
+++ b/src/sardana/taurus/core/tango/sardana/macroserver.py
@@ -833,7 +833,10 @@ class BaseMacroServer(MacroServerDevice):
             element = self._removeElement(element_data)
             removed.add(element)
         for element_data in elems.get('change', ()):
-            element = self._removeElement(element_data)
+            try:
+                element = self._removeElement(element_data)
+            except:
+                pass
             element_data['manager'] = self
             element = self._addElement(element_data)
             changed.add(element)

Bests, Jan

Original comment by: jkotan (http://sf.net/u/jkotan)

sf-migrator-bot commented 8 years ago

Hi, could it be that the error happens because one try to create a macro lib with the same name than an existing one?. In this case the error message would not be clear, but I think it is fine that one get an error.

                          Regards,
                                                  Teresa

Original comment by: teresanunez (http://sf.net/u/tere29)

sf-migrator-bot commented 8 years ago

Hi,

Yes, but in my opinion a behavior of sardana should not depend on the fact if you restart spock or not. Moreover, in older versions such overwriting of macro is possible and it does not raise any errors. But if overwriting of macros from different location is an error it should be sent a clear information for user, i.e. a clear error message that the old macrolib already exists and it cannot be overwrite by the new macrolib.

Bests, Jan

Original comment by: jkotan (http://sf.net/u/jkotan)

sf-migrator-bot commented 8 years ago

Teresa and Jan, I've done the following test.

My MacroServer has MacroPath configured to: /home/zreszela/workspace/macros /home/zreszela/workspace/sardana/src/sardana/macroserver/macros/examples

I executed: edmac mv /home/zreszela/workspace/macros/plotting.py and I saved it applying the code on the server.

In theory this should:

What it did:

The problem probably resides on the server side. In all this operation the server emits ElementsChanged event with "change" elements:

First of all do you agree that what I describe as "theory" is the desired behavior?

Original comment by: reszelaz (http://sf.net/u/zreszela)

sf-migrator-bot commented 8 years ago

Hi Zibi, many thanks for checking this. But we don't want a behavior like the one you describe in 'theory', as I wrote above, the macroserver should avoid (with an error) that a macro or a macro library are overwritten, otherwise it can be really a mess. We had already problems with users that use already existing names (of standard macros) for defining own macros and then nobody knows any more what they are using. It is true that one can check it with prdef or another ways, but I think it is not clean.

                      Regards,
                                              Teresa

Original comment by: teresanunez (http://sf.net/u/tere29)

sf-migrator-bot commented 8 years ago

Original comment by: reszelaz (http://sf.net/u/zreszela)

sf-migrator-bot commented 8 years ago

Teresa, I see your point and of course it is valid. For sure one could find ocassions where macros/macrolibraries get accidentaly overridden. But from the other hand macro (controllers and recorders as well) overriding is a Sardana feature.

In this case, I checked what the addmaclib macro was doing. If one tries to add a library that would override the already existing one, it rejects it. And I recalled the same doubt from the past, and we have done it this way on the same purpose.

It has sense to me, that the more end-user-like tools like edmac or addmaclib are more strict than more administrator-like ways of overriding by:

I've sent patches to the develop mailing list.

Original comment by: reszelaz (http://sf.net/u/zreszela)

sf-migrator-bot commented 8 years ago

Hi Zibi, many thanks. I have checked your patch and it works fine, it does not allow to create macros or macrolibraries with already existing names (using edmac). The behaviour of addmaclib was already fine, it doesn't allow to add a macrolibrary with the same name like an existing one, it keeps the already existing. But with relmaclib there is still something a bit problematic: if I edit per hand (not using edmac) a macro library with the name of a library that already exist, but in other of the directories of the MacroPath, and then I run in spock, for ex. with standard.py

relmaclib standard.py

I get the error:

TaurusTP.W003 ERROR 2016-04-12 09:02:46,607 haso111n.desy.de:10000.p09/macroserver/haso111n.01: Exception occurred processing elements TaurusTP.W003 ERROR 2016-04-12 09:02:46,607 haso111n.desy.de:10000.p09/macroserver/haso111n.01: Details: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/sardana/taurus/core/tango/sardana/macroserver.py", line 812, in on_elements_changed return self._on_elements_changed(evt_src, evt_type, evt_value) File "/usr/lib/python2.7/dist-packages/sardana/taurus/core/tango/sardana/macroserver.py", line 837, in _on_elements_changed element = self._removeElement(element_data) File "/usr/lib/python2.7/dist-packages/sardana/spock/spockms.py", line 555, in _removeElement element = BaseMacroServer._removeElement(self, element_data) File "/usr/lib/python2.7/dist-packages/sardana/taurus/core/tango/sardana/macroserver.py", line 851, in _removeElement self.getElementsInfo().removeElement(element) File "/usr/lib/python2.7/dist-packages/sardana/taurus/core/tango/sardana/sardana.py", line 163, in removeElement elem_type = e.getType() AttributeError: 'NoneType' object has no attribute 'getType' standard successfully (re)loaded (found 1 macros)

But my library standard.py was loaded and then I do not have any more the macros in the official standard.py but the ones in my standard.py. Do you want this to stay like this?. Perhaps it also depends on the order of the MacroPath directories, I could check it, but in any case the behaviour is this.

                        Regards,
                                               Teresa

Original comment by: teresanunez (http://sf.net/u/tere29)

sf-migrator-bot commented 8 years ago

I've just checked it, and could reproduce the error. I will get back to it soon, maybe we should exclude it from Jan16 release. What do you think?

Original comment by: reszelaz (http://sf.net/u/zreszela)

sf-migrator-bot commented 8 years ago

Hi Zibi, thanks for checking. I think we can exclude it from the Jan16 release, don't worry.

                                   Regards,
                                                      Teresa

Original comment by: teresanunez (http://sf.net/u/tere29)

sf-migrator-bot commented 8 years ago

Original comment by: reszelaz (http://sf.net/u/zreszela)