typedefs - TANGO Controls

# 6 years ago
EnricoSegre	This one might seem cosmetic, but on the long run such things pay off and well in programming discipline. I see that there are some typedefs in tango.lvlib, but I'm not sure if they are consistently used in the VIs themselves. For one, _TangoDevicesAttributesInfo.vi doesn't use _AttributeInfo_t.ctl. Which in turn doesn't use enumerator typedefs for datatype, format, access and level, which imho would be proper. As an exercise I quickly typed in the latter, based on the comments on the FP, attached (LV17). However I note that the existing llb contains also an _AttributeDataType.ctl, with different items than what I created. Why? Edited 6 years ago Attachments: 10Kb

# 6 years ago

This one might seem cosmetic, but on the long run such things pay off and well in programming discipline.
I see that there are some typedefs in tango.lvlib, but I'm not sure if they are consistently used in the VIs themselves. For one, _TangoDevicesAttributesInfo.vi doesn't use _AttributeInfo_t.ctl. Which in turn doesn't use enumerator typedefs for datatype, format, access and level, which imho would be proper.

As an exercise I quickly typed in the latter, based on the comments on the FP, attached (LV17). However I note that the existing llb contains also an _AttributeDataType.ctl, with different items than what I created. Why?

Edited 6 years ago

# 6 years ago
nleclercq	> which imho would be proper. The world is full of things that could be better than they are. Tango itself is made of that kind of things. But, you're right, it would have been a good idea to use a ctl in this case. That's a pure historical story. I started to write this binding 10 years ago without having any LabVIEW skills - e.g. even I didn't know what a .ctl was. Some VIs are consequently not as well written as they should. But, believe me, it could have been worse than that :) We could change that as far as we maintain backward compatibility. In case you have a solution respecting that contraint, please, let me know. I can't devote a single second this kind of stuff. > attached (LV17) Please save your VI for LV14 so that I can open it. Anyway, I guess you opened the C++ header in which the corresponding enums are defined and started to copy/paste each field in you .ctl. The binding is free to reorganize (and even rename) the fields and that's what it does. Moreover, it implements a subset of the Tango data types. DEV_ENCODED and PIPES are not currently supported cause we don't have any request from our users to support them - and, again, I have no time to devote to such task. But I'm sure you do. Don't you? One more thing, I think you're focusing on a minor and cosmetic problem. The VI related to 'attribute info' works nicely but is almost 'useless' in fact. Real users, don't want to rewrite Jive in LabVIEW or even try to write 'dynamic code'. The LabVIEW binding has been mainly written to develop GUIs for specific applications - by specific I mean applications I which the developper has a clear knowledge of the devices he/she wants to communicate with - no introspection required in such a case. LabVIEW might not be the appropriate tool/language for your use case. Python could be a better choice. Edited 6 years ago

# 6 years ago

nleclercq

> which imho would be proper.
The world is full of things that could be better than they are. Tango itself is made of that kind of things. But, you're right, it would have been a good idea to use a ctl in this case. That's a pure historical story. I started to write this binding 10 years ago without having any LabVIEW skills - e.g. even I didn't know what a .ctl was. Some VIs are consequently not as well written as they should. But, believe me, it could have been worse than that :) We could change that as far as we maintain backward compatibility. In case you have a solution respecting that contraint, please, let me know. I can't devote a single second this kind of stuff.

> attached (LV17)
Please save your VI for LV14 so that I can open it.
Anyway, I guess you opened the C++ header in which the corresponding enums are defined and started to copy/paste each field in you .ctl. The binding is free to reorganize (and even rename) the fields and that's what it does. Moreover, it implements a subset of the Tango data types. DEV_ENCODED and PIPES are not currently supported cause we don't have any request from our users to support them - and, again, I have no time to devote to such task. But I'm sure you do. Don't you?

One more thing, I think you're focusing on a minor and cosmetic problem. The VI related to 'attribute info' works nicely but is almost 'useless' in fact. Real users, don't want to rewrite Jive in LabVIEW or even try to write 'dynamic code'. The LabVIEW binding has been mainly written to develop GUIs for specific applications - by specific I mean applications I which the developper has a clear knowledge of the devices he/she wants to communicate with - no introspection required in such a case. LabVIEW might not be the appropriate tool/language for your use case. Python could be a better choice.

Edited 6 years ago

# 6 years ago
EnricoSegre	Here come the files again for LV2014, not to let this drop, but I agree that this is not an effective way of contributing, nor that it is something you can't live without. I would gladly create pull requests in future, suggesting code changes and perhaps a more structured organization of the files. However, to make it confidently I need to be sure that I can handle the complete build, and in first place propose something working (at least for me). Otherwise, it would be just random shooting files. As of now I'm stumbling in to the fact that a specific version of gcc is needed (I read what written in the README and acknowledge that it may be well justified). The quick and dirty copying .so's from the runtime/ and vis/ directories of the built package tango-binding-3.0.0-for-labview-2014-linux-x86 didn't cut on my system, not unsurprisingly. I'm not sure that in the near future I'll have the time to sort things out, if I'll do you'll probably hear from me again. >I guess you opened the C++ header Not even, I just typed in what is in the comment boxes on the FP of _TangoDevicesAttributesInfo.vi. Really trivial exercise which doesn't bring any far. >no introspection required in such a case Conceded. I might be taking it backwards in the sense that I'll be learning tango from its visibility from the labview binding. My coming responsibility will just be to interface an existing and respectable tango installation with another medium size LV application which I'm building. So, even for me, the specific devices are taken as fixed and known a priori. Attachments: 10Kb

# 6 years ago

EnricoSegre

Here come the files again for LV2014, not to let this drop, but I agree that this is not an effective way of contributing, nor that it is something you can't live without. I would gladly create pull requests in future, suggesting code changes and perhaps a more structured organization of the files. However, to make it confidently I need to be sure that I can handle the complete build, and in first place propose something working (at least for me). Otherwise, it would be just random shooting files. As of now I'm stumbling in to the fact that a specific version of gcc is needed (I read what written in the README and acknowledge that it may be well justified). The quick and dirty copying .so's from the runtime/ and vis/ directories of the built package tango-binding-3.0.0-for-labview-2014-linux-x86 didn't cut on my system, not unsurprisingly. I'm not sure that in the near future I'll have the time to sort things out, if I'll do you'll probably hear from me again.

>I guess you opened the C++ header
Not even, I just typed in what is in the comment boxes on the FP of _TangoDevicesAttributesInfo.vi. Really trivial exercise which doesn't bring any far.

>no introspection required in such a case
Conceded. I might be taking it backwards in the sense that I'll be learning tango from its visibility from the labview binding. My coming responsibility will just be to interface an existing and respectable tango installation with another medium size LV application which I'm building. So, even for me, the specific devices are taken as fixed and known a priori.

# 6 years ago
nleclercq	FYI, I added the 'proper' enums to _AttributeInfo_t.ctl. Will be committed asap on GitHub. Edited 6 years ago

# 6 years ago
nleclercq	> as of now I'm stumbling in to the fact that a specific version of gcc is needed What is your target platform finally? Windows, Linux, both? Under linux, the tricky stuff is to 'find' the right gcc version. Here, 'right' means a gcc version which is able to produce a shared lib which is itself binary compatible with labview. The core problem is the libstdc++ version that comes with the compiler.. Have a look to compilation instructions for details. Useful info here also. Edited 6 years ago

# 6 years ago

nleclercq

> as of now I'm stumbling in to the fact that a specific version of gcc is needed
What is your target platform finally? Windows, Linux, both? Under linux, the tricky stuff is to 'find' the right gcc version. Here, 'right' means a gcc version which is able to produce a shared lib which is itself binary compatible with labview. The core problem is the libstdc++ version that comes with the compiler.. Have a look to compilation instructions for details. Useful info here also.

Edited 6 years ago

# 6 years ago
EnricoSegre	Windows for deployment of my LV application, which relies on features of LV available only there, like Shared Variables. Linux for compiling the repo snapshot, as it is the only environment in which I have a vague knowledge of development tools. From what I understand, the wrapper VI part should be OS agnostic, and that is what I'm concentrating onto. See, I'm not a tango expert and wont have time and motivation to become one in the near future. If there is something I can contribute to, that's in the LV part.

# 6 years ago

EnricoSegre

Windows for deployment of my LV application, which relies on features of LV available only there, like Shared Variables.
Linux for compiling the repo snapshot, as it is the only environment in which I have a vague knowledge of development tools.

From what I understand, the wrapper VI part should be OS agnostic, and that is what I'm concentrating onto. See, I'm not a tango expert and wont have time and motivation to become one in the near future. If there is something I can contribute to, that's in the LV part.

# 6 years ago
nleclercq	Nobody around you with some Visual C++ knowledge? The binding is actually easier to compile and use under windows than under linux. > From what I understand, the wrapper VI part should be OS agnostic It is. There's nothing OS specific on the VI side of the binding. > If there is something I can contribute to, that's in the LV part. Ok. Let's go. Could you help me to factorize some code in the polymorphic VIs? For instance, let's take the _TangoReadAttritute.vi. What would you do to factorize the underlying code? BTW, did you notice my previous post (n-2)? I was mentionning that I added the 'proper' enums to _AttributeInfo_t.ctl. It's available on the GitHub repo. Backward compatibility cause labview let you select that data representation associated to an enum - 16 bits integers in this case. Hope you appreciate… I will certainly release it as 3.0.3 later today.

# 6 years ago

nleclercq

Nobody around you with some Visual C++ knowledge? The binding is actually easier to compile and use under windows than under linux.

> From what I understand, the wrapper VI part should be OS agnostic
It is. There's nothing OS specific on the VI side of the binding.

> If there is something I can contribute to, that's in the LV part.
Ok. Let's go. Could you help me to factorize some code in the polymorphic VIs? For instance, let's take the _TangoReadAttritute.vi. What would you do to factorize the underlying code?

BTW, did you notice my previous post (n-2)? I was mentionning that I added the 'proper' enums to _AttributeInfo_t.ctl. It's available on the GitHub repo. Backward compatibility cause labview let you select that data representation associated to an enum - 16 bits integers in this case. Hope you appreciate… I will certainly release it as 3.0.3 later today.

# 6 years ago
EnricoSegre	I'll have a look at all in the next days, it won't be before sunday. Probably the way to go is to fork the repo on github to my personal area, find a way to make the labview part work with some combination of the dynamical libraries taken from either the older package or the newest releases, and carry on on the VIs, then request pull. First thing I'll certainly do is to split the llb into individual directories and remove compiled code, there is really no sense in source control llbs otherwise.

# 6 years ago

EnricoSegre

I'll have a look at all in the next days, it won't be before sunday. Probably the way to go is to fork the repo on github to my personal area, find a way to make the labview part work with some combination of the dynamical libraries taken from either the older package or the newest releases, and carry on on the VIs, then request pull. First thing I'll certainly do is to split the llb into individual directories and remove compiled code, there is really no sense in source control llbs otherwise.

# 6 years ago
nleclercq	I'm afraid I will not be able to accept any files reorganization without having a clear idea of the potential side effects on existing applications. We, for instance, have tens of them in our control room and I definitively don't want to ask our operators to relink each Vi by hand just because the files could be better organized. Any chance to reorganize the .llb without breaking anything? I don't think so. I already tried to but the impact was unacceptable. IHMO, it's really not a priority. In case it's for you, please fork the VIs part of the binding and reorganize it as you want. To conclude, I really don't see why you just don't recompile the binding (if you need to) and use it as it is. Tens of guys did that during the last 10 years. I think I reached the limits of my support capabilities. You're on your own now. Good luck. Edited 6 years ago

# 6 years ago

nleclercq

I'm afraid I will not be able to accept any files reorganization without having a clear idea of the potential side effects on existing applications. We, for instance, have tens of them in our control room and I definitively don't want to ask our operators to relink each Vi by hand just because the files could be better organized.

Any chance to reorganize the .llb without breaking anything? I don't think so. I already tried to but the impact was unacceptable. IHMO, it's really not a priority. In case it's for you, please fork the VIs part of the binding and reorganize it as you want.

To conclude, I really don't see why you just don't recompile the binding (if you need to) and use it as it is. Tens of guys did that during the last 10 years. I think I reached the limits of my support capabilities. You're on your own now. Good luck.

Edited 6 years ago

# 6 years ago
EnricoSegre	nleclercq Any chance to reorganize the .llb without breaking anything? Well, I don't have the overview of what would break and how, but there is a way to get both the hierarchy and the flat llb, if you look at my fork of the github project. I created a .lvproj with a build specification which generates the llb again from the file hierarchy. The build step could be a part of generating the release package. For now I did no [intentional] code change, nor I could test any effect in action. Even less, check if the idea coexists with existing applications. I perfectly understand the caution. I don't know how far I'd bring it from here, at least this is a beginning. Btw in doing the split I found that the llb contains some one hundred VIs not cathegorized in the lvlib. Some 50 of them are polymorph instances, other are probably dependencies of the Server stuff. I dumped all of them in an Orphans folder, it would be minimal work to distribute them in properly named subfolders. Edited 6 years ago

# 6 years ago

EnricoSegre

nleclercq
Any chance to reorganize the .llb without breaking anything?

Well, I don't have the overview of what would break and how, but there is a way to get both the hierarchy and the flat llb, if you look at my fork of the github project. I created a .lvproj with a build specification which generates the llb again from the file hierarchy. The build step could be a part of generating the release package.

For now I did no [intentional] code change, nor I could test any effect in action. Even less, check if the idea coexists with existing applications. I perfectly understand the caution.
I don't know how far I'd bring it from here, at least this is a beginning.

Btw in doing the split I found that the llb contains some one hundred VIs not cathegorized in the lvlib. Some 50 of them are polymorph instances, other are probably dependencies of the Server stuff. I dumped all of them in an Orphans folder, it would be minimal work to distribute them in properly named subfolders.

Edited 6 years ago