POGO protected regions

Dear all,

I am currently using POGO v.9.2.2, for Python code generation.

Let's assume I have created an attribute with POGO, and the code is as below:

    @DebugIt(show_args=True, show_kwargs=True, show_ret=True)
    def read_delimiter(self):
        # PROTECTED REGION ID(Logger_DS.delimiter_read) ENABLED START #
        return self.__delimiter
        # PROTECTED REGION END #    //  Logger_DS.delimiter_read

I have included the Python @DebugIt decorate for my logging, and this is working well with logs output as required. However, any change to the POGO class design regenerates the python code and removes all code lines that are not included in protected regions. Therefore all decorator code is removed and needs to be put back every time. Is there a way around this? smile

Thanks,
Andrea
Dr Andrea DeMarco, BSc (Hons) (Melita), MSc (Melita), DPhil (UEA)
Lecturer | Researcher
Department of Physics
Institute of Space Sciences and Astronomy

Room 220, Maths and Physics Building
University of Malta, Msida MSD2080, MALTA
Hi Andrea,
I confirm there seems to be no way to keep the decorators in the non-protected regions with pogo. If you need this often then make a feature request. How should this be implemented? Should one add a new protected region before every method? This will make the code more verbose. Maybe you have an idea how to introduce decorators in a more elegant manner e.g. adding them in the xmi file via the ui.

I am sure others who are more expert in Python have ideas how to do this better while still using pogo …

I presume you cannot call DebugIt() as the first function in your method?

Cheers

Andy
Hi Andy,

Thanks for the reply. I assumed it wasn't possible, but thought I'd ask anyway.

I guess we have to decide on whether to use POGO-generated code or not. There are some very nice features, even in the Python high-level API that allows for some very clean-looking code. Probably the best way to go about this via POGO is indeed to include decorators via the XMI, where the user checks a list of decorators for the command/attribute in question, and also ticks any boolean arguments required. But of course this can clutter the POGO UI…

We are still developing with Tango 8 since for the time being Tango 9 is not available for Python. Is there anyway we can use the most updated version 8 of POGO rather than a version 9 of POGO? I think it would be POGO v. 8.4.8

Thanks,
Andrea
Dr Andrea DeMarco, BSc (Hons) (Melita), MSc (Melita), DPhil (UEA)
Lecturer | Researcher
Department of Physics
Institute of Space Sciences and Astronomy

Room 220, Maths and Physics Building
University of Malta, Msida MSD2080, MALTA
Hi,

I have developped the new python templates.

Like Andy said, maybe the best option will be a feature request.

I would think of:
- adding a checkbox "Debug_options" in the generate dialog
- when activated, we have a list of possible options like show_args, show_ret… so we can tick the desired option
- when pogo generates the file, it will look at theses flags

But the main problem is that it will be a very "specific for python" option. And we will have to change th xmi file version.

It is possible, but it implies a lot of modifications, and since I'm not the "owner", I would like Pascal and Tiago advices about this.
Hi SGara_Nexeya,

Thanks for your input. I'd agree with your "solution", a set of checkboxes would work. But yes, this is very python specific - and probably will require many changes in POGO code for something so specific. I guess the problem would then turn to the philosophy of "protected regions".

Coincidentally, I am trying out the new POGO v.9 lately, and there is an option to generate python code without protected regions. This in turn removes ALL code every time the XMI file is re-generated. Is this the way it was meant to work? As a sort of skeleton-builder for developers that do not want to use POGO for everything, but just require a nice way to build a skeleton? If that's the case, then this is probably a good middle-ground for the time being. I can use POGO lightly, and write the rest of the code without too much POGO-dependence.

Thanks,
Andrea
Dr Andrea DeMarco, BSc (Hons) (Melita), MSc (Melita), DPhil (UEA)
Lecturer | Researcher
Department of Physics
Institute of Space Sciences and Astronomy

Room 220, Maths and Physics Building
University of Malta, Msida MSD2080, MALTA
drea
Coincidentally, I am trying out the new POGO v.9 lately, and there is an option to generate python code without protected regions. This in turn removes ALL code every time the XMI file is re-generated. Is this the way it was meant to work? As a sort of skeleton-builder for developers that do not want to use POGO for everything, but just require a nice way to build a skeleton? If that's the case, then this is probably a good middle-ground for the time being. I can use POGO lightly, and write the rest of the code without too much POGO-dependence.

Thanks,
Andrea


Exactly.

When you don't want the protected regions, it's up to you to protect your code ;)
We have added this option since some users doesn't really use them and that's a lot of lines if you don't really use them.
It depends how you use Pogo.
Some users use it just for starting and add all the want after.
Some users doesn't really use Pogo and copy the skeleton from a previous development.
I prefer to always use Pogo even if it's just a simple attribute addition.
Because my xmi is up to date, and if I want to change to C++ or Java, it's easy.

One of the ohters addition s to the PythonHL is the "Python Package" option.
With it, you have a complete python package directory. From here, you can:
python setup.py dist –> create a source archive
python setup.py bdist_msi –> create a exe deploying on windows
python setup.py bdist_rpm –> create a rpm package for CentOs/Fedora
python setup.py build_sphinx –> create the sphinx documentation
python setup.py install –> install the package into the python environment
python setup.py test –> do some test using DeviceTest package and mocking possibilities
Thanks Gara!

I'll try work with PythonHL and POGO for some new stuff I'll be developing. I can ignore the decorator issue for the time being. Is there anything in the standard Python API that is missing from the PythonHL API? Or is it more or less all accessible?

Hoping to be able to use PyTango 9 in a finished state soon. But I'll be working with PyTango8 mostly for the time being.

Thanks,
Andrea
Dr Andrea DeMarco, BSc (Hons) (Melita), MSc (Melita), DPhil (UEA)
Lecturer | Researcher
Department of Physics
Institute of Space Sciences and Astronomy

Room 220, Maths and Physics Building
University of Malta, Msida MSD2080, MALTA
There is no real "comparaison" between Python API and PythonHL API.
In fact, Python API was mainly copying the C++ API.
PythonHL API is more pythonic way to do the same.
You have access to all the methods of PyTango from both "API"

For PyTango 9, there is a branch which compile with Tango9, but the features aren't really on par with the C++ and Java Tango 9.
Specific Tango 9 feature (pipes, enums, forwarded attributes…) are still being developed but if you don't use theses features now, you can give it a try.

https://github.com/tiagocoutinho/PyTango/tree/tango9

Since Tiago is working on it, I think we will have a new release version soon.
 
Register or login to create to post a reply.