Support for old(er) versions of Ruby and KLayout

cgelinek_radlogic

Hi Matthias,

Thank you for sharing your powerful software with this nice community.

I have started to work on a project which is using KLayout's Ruby scripting features. Since this project has grown quite a bit, I am wondering about compatibility in the future, i.e. what needs to be supported in terms of Ruby versions and the KLayout RBA API.

At the moment the code only supports the 0.24-python-preview version with the bundled Ruby 2.1.3, which for example supports a better syntax for keyword arguments than Ruby 1.9.

Since version 0.24 is still a preview, I am wondering if the project should be "backported" to be able to run with the KLayout 0.23 API and Ruby 1.9 and which is officially unsupported by the Ruby community.

The project is still a work-in-progress but I am concerned that Ruby 1.9 is still very common (e.g. on various flavours of GNU/Linux).

Any thoughts on the future of KLayout, Ruby and Qt and how they will affect compatibility of existing (or new) scripts would be appreciated.

Thanks, Chris

Matthias

Hi Chris,

thanks for mentioning this. Here are some statements from my side

• Regarding Ruby: I'll surely shift to 2.x for the binary Windows release for 0.24. On Linux, it will depend on your choice which Ruby version you are building against. I'm even support 1.8, but my recommendation is to build against any 2.1 version at least.
• With respect to the Ruby API, I try to be conservative and preserve existing methods. I had to apply some changes for 0.24 due to the integration of Python. Some concepts could not be translated to Python and I wanted to keep Ruby and Python implementation in sync, so there was some impact on Ruby too. I really think that will remain a special case. I won't integrate many more languages (sorry, Perl and Tcl lovers) ...
• The most stable part of the API is the one related to the database (Layout, Cell, Polygon ...). These classes are widely used now so I want to preserve their API and only extend it.
• The Ruby/Python Qt API is basically stable, but it is generated from Qt's source code and to enable building against older Qt versions and to simplify deployment, I confined the binding to the 4.6 classes and methods. But the underlying library is the one you build KLayout against, so you benefit from bug fixes and enhancements not affecting the API. In general I don't recommend building too complex systems based on the Qt binding since it's likely that at some point you'll run into object lifetime issues leading to application instability. I don't say it's not possible - but it requires a careful design and some workarounds for existing issues.
• The Qt binding saw some changes in 0.24 because of the Python integration. But again, this is a major step and won't happen again.
• A special case is the QFlags mapping in Qt - previously that was possible only through integer values which is hard to maintain. In 0.24 you can use a syntax resembling C++ Qt, so that is far more consistent, readable and matching the Qt documentation. But I had to sacrifice the integer version because it was not possible to maintain both ways.
• Qt5 is not on my roadmap soon. There will be a lot of translation work to be done.

And yes, I know that 0.24 is overdue, but requests are piling up ... I guess I'll have to make a cut soon in order to be able to release.

Matthias

cgelinek_radlogic

Hi Matthias,

Thank you so much for your comments on these items.

As Ruby 2 has definitely some advantages, I will keep using the Windows preview version for now. My only concern is that I wasn't able to install Ruby 2.x under Linux easily, but I think eventually this problem will be solved one way or the other (if nothing else by using a newer release of the OS). I think keeping the Ruby and Python APIs in sync has huge advantages, so I appreciate your decision on that. At the moment I don't have too much Qt code anyway so the 0.24 change hasn't affected me but I noticed that there are some posts in the forum about that... again, I think - especially with regards to the QFlags - that the new API is cleaner.

In short, I will stick to the 0.24-python-eval version for now and look forward to the official 0.24.

Thanks for all your efforts!

Regards, Chris