0.24 is alive!

edited July 2015 in General

To all who waited so long ...

0.24 is out finally. I tried to toughen the Ruby/Python implementation and did a lot of improvement on the Qt integration side. Most of the topics have been mentioned in this forum like alignment of Qt concepts with the Ruby/Python binding, object lifetime management issues and so forth.

Thanks for being patient. I know it took longer than expected, but I hope finally it's worth waiting for.

Matthias

«1

Comments

  • edited August 2015

    Matthias,

    Wonderful work! Much appreciated.

    You should expect I have some long discussion post in response :-) So here goes.

    A few notes/questions:

    (A)

    Release notes says "The macro IDE now features watch expressions which are automatically evaluated when in a breakpoint." -- I can't see where to add a watch expression?

    (B)

    "Apply to all" doesn't always work as I'd expect -- I think we have different interpretations of it.

    1. Draw two boxes on two different layers, lowerleft;upperright = (0,0);(1,1) and (0,0);(2,1)
    2. Select both, press 'q'
    3. Click 'Center/Size' tab
    4. Change center 'x' value to 0 and click Apply to All
    5. I would expect both boxes to now be centered in x around x=0, but what happens is that one box is centered in x ('box 1 of 2') while the other box just moves by the same relative amount. So, if "box 1 of 2" was the larger box, then the larger box will now be centered in x while the smaller box will be (-1,0);(0,1)

    Similar things happen when you have several texts and change x or y. I expect all texts to adopt the newly-changed x or the y, but in fact only the 'active' one adopts it while the others move by the same relative amount. Also similar when you select several cells and change x or y.

    I can also see usefulness in keeping it as-is for making relative movements of all objects at once. Perhaps that was your intent. But that it can be done with selection > Move By.

    Actually I think the way I describe is a little more intuitive (i.e. the new x=0um setting is applied to all boxes). I know this can be done with Edit > Selection > Align, but that would then be a two-step process (align center and then move until all centers are at x=0um), which I suppose is a minor point. But I guess the main point is, I think it may make sense to apply x=0um to all centerx's when you set centerx=0um on one box and press Apply To All. And similar for the other textbox inputs.

    (C)

    "Apply to all" doesn't work on certain operations. Steps to reproduce the problem:

    1. Draw several wires with different extension types. Select all and press 'q'. Change extension type to Square, Round, or Flush. Press Apply to All. Only the object "1 of N" changes. I'd expect all to change.
    2. Draw several wires with different extension types. Select all and press 'q'. Change extension type to Variable. The 'start' and 'end' boxes become active, with a default value of half the wire width. Press Apply to All. Only the object "1 of N" changes. I'd expect all to change, with the displayed 'start' and 'end' values.
    3. (slight modification of the above) Draw several wires with different extension types. Select all and press 'q'. Change extension type to Variable. The 'start' and 'end' boxes become active, with a default value of half the wire width. Change 'start' to some other value, say 5um. Press Apply to All. All wires' start extension correctly changes to 5um, but only the selected object "1 of N" changes its end value to what is shown in the 'end' box. I'd expect if one of the things you changed prior to clicking "apply to all" was to choose 'variable' extension type then it should heed the new start and end values and apply these to all wires. As a workaround though, I admit you can change them both to some new value, click Apply all, change them back, click Apply all again.
    4. Minor point. Apply to all is greyed out when you select rulers and attempt to make a change to all of them at once, say, to give them arrow ends. I assume this is just not implemented yet which is fine.

    Favorite features:

    • Debugger toggle button
    • Apply to All
    • User properties of cells available in cell context menu
    • instance properties page showing the cell dimensions (though it would be nice if these boxes were greyed out)
    • shape selection can be manipulated through scripts.

    Thanks again,

    David

  • edited August 2015
    Good to see all the enhancements and new features, nice work, thanks!

    The layer properties work a bit unexpected, though. When I use my existing technologies, a second set of layer properties is added, with default colours and pattern.

    The only way I found so far to avoid this, is disabling add-other-layers in the technology. Which I rather would leave enabled.

    Am I missing something?

    [edit]

    It looks like I found the problem. Recently,I did quick and dirty editing of the lyp files with an text editor and e.g. edited the <source>1/0@1</source> line into <source>L01 1/0@1</source>. In 0.23 this was OK, 0.24 reminds me, that after very quick comes very slowly...

    Michael
  • edited August 2015

    Hi all,

    thanks for your feedback!

    Here are my comments:

    1.) Watch expressions (david): the watch window is only shown when in a breakpoint or the execution is interrupted. In that window you can add watch expressions by right-clicking and chosing "Add Watch".

    2.) Regarding "Apply all" (david), you're right: I was focusing on the "apply relative changes" approach. The reasoning is that it's difficult to tell the actual intent from the change. Assuming relative change intent seemed more natural to me, but to separate both the absolute and relative change intents I'd have to ask the users through a separate dialog box. BTW: "move to" is only a solution for shifting whole things, but with "Apply all" you can shift a single edge only.

    3.) The behaviour of the "apply to all" in the path properties (david) is consistent, but very unintuitive I admit. Here is the explanation:

    the basic path properties are "round flag", "start extension" and "end extension". If the round flag is true, the path ends are drawn round-ended instead of rectangular. Round ends can be combined with any extension and in case of extension != half width, the ends become ellipses. In the extreme case with extension = 0, the ends become flat and the round flag does not have an effect. "Square" and "Flat" are not special types, but they are special cases of "Variable extension" with extension = half width or extension = 0 and vice versa.

    "Apply all" now will apply

    • changes to the round flag
    • changes to the extensions

    to the other selected paths.

    A consequence of that is:

    • Changing "Square" to "Variable extension with extensions = half width" won't have an effect because that is not considered a change
    • Changing to "Round" will not have an effect to flat-ended paths because that only changes the round flag and not the extensions.

    I see that this needs some rework to become intuitive.

    4.) Regarding the layer properties mapping (michael) I think that is actually a bug - when the technology manage adds the missing layers it should not consider "L01 1/0" (named layer L01 or numeric layer 1/0) different from "1/0" (numeric layer 1/0). I'll see that this is going to be fixed.

    Thanks for testing,

    Matthias

  • edited August 2015

    1.) Thanks! I should have tried that..

    2.) How about this: Let's say several boxes are selected, with nonzero centerx's. Let's say centerx = 1 for the first selected box currently.

    RELATIVE: If you change that to centerx = 1 - 1 (i.e. add a "... - 1") and press Apply all then it moves that box and all other boxes' centers by -1 (relative).

    ABSOLUTE: If you put centerx = 0 and press Apply all then all go to the absolute centerx = 0.

    The nice thing about this is there is no change to the default ("Apply") behavior. ie. If you just select one box, it doesn't matter if you make centerx = 1-1 or if you make centerx = 0, then you still get the same behavior you had before. The behavior only varies if you do Apply All, which is the new button anyway. Also nice is that regardless of whether you press Apply or Apply All, the behavior is the same for the 1st box, which the user should expect.

    A down-side is that solution is not so obvious for a new user, but at least it doesn't require another dialog box, and it could be noted in the documentation.

    Personally I have much more use for absolute positioning and I think that's more intuitive (i.e. when you tell it "set leftx = 1.3; Apply All" then it truly sets all leftx's to 1.3), so that is my vote if there's only one function represented -- but if you don't like the above solution and still want it to only do relative movements, that's fine - you're the author! :-) A separate ruby script could do the other function.

    3.) I see - thanks for the explanation. Makes sense, but not obvious before.

    Thanks Matthias,

    David

  • edited November -1

    Hi David,

    thanks for the comments about the relative vs. absolute mode. However, in the "apply all" code, the nature of the input is not available, so I cannot evaluate the way the value is entered.

    I guess the best solution is to provide an option to choose whether to have absolute or relative changes.

    Thanks,

    Matthias

  • edited November -1

    Matthias,

    I didn't think of having an option in File > Setup, but that is a great idea!

    David

  • edited November -1
    Hi, Matthias,

    I am very happy to find that the latest version supports global properties.
    This is what I desired. Thank you very much.

    Let me make small feed backs

    1) In windows, I need to set PYTHONPATH to point python libraries. Without the parameter, the program crashed without any messages.
    I believe this infomation may help the users who build their own binary, because binary package includes its own library set but source set does not.

    2) #include <algorithm> seems lost in pyaUtils.cc

    ... /klayout-0.24/src/pyaUtils.cc:66:7: error: 'reverse' is not a member of 'std'
      std::reverse (backtrace.begin (), backtrace.end ());
    ^
    gmake[1]: *** [pyaUtils.o] Error 1

    3) dbghelp.lib seems not assigned for windows building properties.

    4) I tested gcc4.9.2 on RedHat6.7 with -std=c++11 and MSVS Express 2013 on windows7 64bit.
    To build by same source for both Linux/Windows, I need to replace hash_map/hash_set by unordered_map/unordered_set.

    Thanks again,
    Masaki
  • edited November -1

    Hi Masaki,

    thanks :-)

    regarding the topics:

    1.) thanks for mentioning this. There is a similar issue on Linux when the built-in Python path of the library you link against does not match it's installation path. In that case the file system encoding cannot be loaded and the Python interpreter will refuse to become initialized. On Linux, the problem can be avoided by employing a properly built Python installation (with the right --prefix and using "make install" rather than plain "cp"), but there seems to be some magic in the Python engine which tries to guess the PYTHONPATH in the other cases from the installation. That fails when Python is embedded into the application. I'm not happy with setting the PYTHONPATH since that will influence other applications too, so I shall try to find a solution for that.

    2.) to 4.) Please use the STLPort build configurations. I tried to remove the normal ones but it they are surprisingly sticky. Please see the build notes for details: http://www.klayout.de/build.html. STLPort comes with a compatible hash_map/hash_set and is way more efficient in terms for memory and performance than the STL which comes with Visual C++. With these targets, the issues should be gone.

    BTW: you may want to wait for 0.24.1 because there is a growing list of known issues here: http://klayout.de/issues.html#0.24.

    Thanks,

    Matthias

  • edited November -1
    Hi, Matthias,

    I also suffer the new issue when I use the Klayout 0.24, and I think post it here is suitable.

    We use the useful Ruby Modules you provide here http://www.klayout.de/useful_scripts.html in Klayout 0.21.19, 0.22.*, 0.23.*
    These ruby modules help us a lot, but when we migrate into Klayout 0.24, the ruby module "Compute the total area of all selected shapes" always fails.

    The related error message is

    "Cannot call non-const on a const reference in ObjectInstPath::shape in Action::triggered
    /usr/local/klayout/rb/calc_area.rbm:47:in `shape'
    /usr/local/klayout/rb/calc_area.rbm:47
    /usr/local/klayout/rb/calc_area.rbm:45:in `each_object_selected'
    /usr/local/klayout/rb/calc_area.rbm:45
    /usr/local/klayout/rb/rename_cells.rbm:27:in `call'
    /usr/local/klayout/rb/rename_cells.rbm:27:in `triggered'"

    I think it may be due to the funtion "def triggered" fail
    Could you also help to check these error?
    Thank you.

    Regards,
    Canny
  • edited August 2015

    Canny,

    Change this line (47)

    shape = obj.shape
    

    to this

    shape = obj.dup.shape
    

    It is a 0.24 bug as detailed here (scroll down to "A workaround is to use...").

    I have already updated all TRT scripts to be compatible in this way, as well as this one which is in TRT.

  • edited November -1
    How about the Linux rpm package ? It is so convenient for Redhat installation;

    Thanks, Best regards,
    OkGuy
  • edited November -1

    Hi all,

    @David: once again thanks for taking care of Canny's question.

    Please try the 0.24.1 which I have released yesterday. That should fix the problem too. The "dup" workaround still works but it should not be required and longer. Sorry for the inconvenience!

    Regarding RPM's: I am struggling to make OpenSuSE's build service digest the new builds. Some files require an awful lot of memory to build. The build servers choke on some of these files currently. As soon as I have a working setup I'll provide the RPM's.

    Thanks,

    Matthias

  • edited November -1
    Hi, Matthias,

    Thank you, the 0.24.1 solves the problems.

    Hi, David,

    Thank you the nice suggestion.
    Could the TRT script be put in the other location? Like $HOME/macro ?
    I put it in the $HOME/macro, and set it in custom-macro-paths of the config file
    I read the The Red Toolbox on the manu, but I can't let the function of TRT works.
    It shows error message like "uninitialized constant QDialog"
    I might do something wrong.

    Regards,
    Canny
  • edited November -1

    Hi Canny,

    I guess you have built KLayout without Qt binding support, right?

    If you build KLayout yourself (on Linux), you'll need to add --with-qtbinding to enable it. I admit this option should be default, but it will increase build times considerably, so I did not dare to enable it be default so far.

    Regards,

    Matthias

  • edited September 2015

    Canny,

    I'm not sure I understand. I have only used TRT on Windows, but the process is perhaps simpler than you thought. You don't need to modify custom-macro-paths of the config file. Just:

    1. Copy the entire The Red Toolbox folder to inside 'macros'. So you have a subfolder called 'The Red Toolbox' inside macros.
    2. Restart KLayout

    That's it.

    I have never encountered such an error. But I would like to know more about your setup so I can debug this error. Can you please provide any and all information such as:

    • What OS?
    • What KL version?
    • What TRT version?
    • Exactly where are you copying the The Red Toolbox folder? The whole path. (You can manually remove any usernames or anything)
    • When it gives the error, click on "More" button and tell me what macro, what line number, it reports. This is the most important information I think.

    Thanks Canny!

    David

  • edited September 2015
    Hi, Matthias,

    Yes, we built Klayout in Linux without Qt binding support

    Hi, David,

    The problem I suffered in my previous post :
    The OS is Red Hat 4.4.6-4
    The Klayout version is 0.24.1
    The TRT version is v0p3p4
    The whole path I copied the TRT folder is C:\User\Downloads\TRT_v0p3p4
    The error happens, I clik the "detail" bottom, it only shows "uninitialized constant QDialog", there is no more information. The error message shows when I click the function,
    Selection --> Adjust cell original,
    Cells --> Get Pcell parameters
    Cells --> Pcell array generator
    Layout --> Density calculation

    I don't know if these functions don't work relate to without Qt binding support because I haven't built Klayout with Qt binding support.

    I also put the TRT in Windows Klayout (0.23.10), TRT works very well.
    But I confuse with the error message when I open Windows Klayout with TRT
    "NameError: uninitialized constant RBA::Qt::DockWidgetArea
    C:/ap/exe/KLayout/macros/The Red Toolbox/Core/Quick settings plugin.lym:103:in `<main>'"
    Do you also get this error message ?

    Regards,
    Canny
  • edited September 2015

    On RedHat, I'm not 100% sure - let me look at those scripts you listed closer. In the meantime try putting the whole TRT folder, unzipped, inside the macros folder. So you have a subfolder called 'The Red Toolbox' inside macros. Restart KLayout.

    On Windows, I have seen that error when not using KLayout 0.24.x. e.g. if you use 0.23.x then you will get that error. In that case it is a known bug. Actually it arises because of a difference in the way constants are handled in KLayout 0.24 compared with earlier KLayout versions. Upgrade to KLayout 0.24.1 to fix it.

  • edited November -1

    Hi Canny,

    Without Qt binding support the Qt classes such as QDialog are not available. Please build again with -with-qtbinding.

    Matthias

  • edited November -1
    Hi, Matthias,

    I use the Klayout 0.24.1 and suffer the problme when I use function "mark browser".
    I used the makr browser to open an RVE file with properies.
    When I tried to sort the result by the name of the properties, Klayout crashed.
    And it popped up a message box with the following message :
    Signal number: 11
    Address: 0x0
    Program Version: KLayout 0.24.1 (2015-08-26 r2982)
    Backtrace:
    /usr/local/klayout/bin64/rhel6_test/klayout(_ZN3rdb9ValueBase7compareEPKS0_S2_+0x16) [0x1b51696]
    /usr/local/klayout/bin64/rhel6_test/klayout(_ZN2tl16__introsort_loopIN9__gnu_cxx17__normal_iteratorIPSt20_List_const_iteratorIN3rdb7ItemRefEESt6vectorIS6_SaIS6_EEEElNS4_15ValueIterSorterIS6_EEEEvT_SE_T0_T1_+0x457) [0x1f5b7f7]
    /usr/local/klayout/bin64/rhel6_test/klayout(_ZN2tl16__introsort_loopIN9__gnu_cxx17__normal_iteratorIPSt20_List_const_iteratorIN3rdb7ItemRefEESt6vectorIS6_SaIS6_EEEElNS4_15ValueIterSorterIS6_EEEEvT_SE_T0_T1_+0x38a) [0x1f5b72a]

    I'm not sure if this bug has been reported and fixed

    Regards,
    Canny
  • edited November -1

    Hi Canny,

    this is a known bug. Please use the most recent version 0.24.3, where this bug was fixed.

    Regards,

    Matthias

  • edited November -1
    Hi, Matthias,

    I'm using Klayout v0.24.3 now.
    I get some warning message when I try to import other oasis file into current one.
    I don't know if it is known bug, just paste the message here

    Signal number: 11
    Address: 0x22
    Program Version: KLayout 0.24.3 (2015-11-05 r3062)
    Backtrace:
    /usr/local/klayout/lib64/test/libQtGui.so.4(_ZN14QWidgetPrivate10drawWidgetEP12QPaintDeviceRK7QRegionRK6QPointiP8QPainterP19QWidgetBackingStore+0x871) [0x7f13837fd0e1]
    /usr/local/klayout/lib64/test/libQtGui.so.4(_ZN14QWidgetPrivate22paintSiblingsRecursiveEP12QPaintDeviceRK5QListIP7QObjectEiRK7QRegionRK6QPointiP8QPainterP19QWidgetBackingStore+0x440) [0x7f13837fd830]
    /usr/local/klayout/lib64/test/libQtGui.so.4(_ZN14QWidgetPrivate10drawWidgetEP12QPaintDeviceRK7QRegionRK6QPointiP8QPainterP19QWidgetBackingStore+0x11c) [0x7f13837fc98c]
    /usr/local/klayout/lib64/test/libQtGui.so.4(_ZN14QWidgetPrivate22paintSiblingsRecursiveEP12QPaintDeviceRK5QListIP7QObjectEiRK7QRegionRK6QPointiP8QPainterP19QWidgetBackingStore+0x440) [0x7f13837fd830]
    /usr/local/klayout/lib64/test/libQtGui.so.4(_ZN14QWidgetPrivate10drawWidgetEP12QPaintDeviceRK7QRegionRK6QPointiP8QPainterP19QWidgetBackingStore+0x11c) [0x7f13837fc98c]
    /usr/local/klayout/lib64/test/libQtGui.so.4(_ZN14QWidgetPrivate22paintSiblingsRecursiveEP12QPaintDeviceRK5QListIP7QObjectEiRK7QRegionRK6QPointiP8QPainterP19QWidgetBackingStore+0x440) [0x7f13837fd830]
    /usr/local/klayout/lib64/test/libQtGui.so.4(_ZN14QWidgetPrivate10drawWidgetEP12QPaintDeviceRK7QRegionRK6QPointiP8QPainterP19QWidgetBackingStore+0x11c) [0x7f13837fc98c]
    /usr/local/klayout/lib64/test/libQtGui.so.4(_ZN14QWidgetPrivate22paintSiblingsRecursiveEP12QPaintDeviceRK5QListIP7QObjectEiRK7QRegionRK6QPointiP8QPainterP19QWidgetBackingStore+0x440) [0x7f13837fd830]
    /usr/local/klayout/lib64/test/libQtGui.so.4(_ZN14QWidgetPrivate10drawWidgetEP12QPaintDeviceRK7QRegionRK6QPointiP8QPainterP19QWidgetBackingStore+0x11c) [0x7f13837fc98c]
    /usr/local/klayout/lib64/test/libQtGui.so.4(_ZN14QWidgetPrivate22paintSiblingsRecursiveEP12QPaintDeviceRK5QListIP7QObjectEiRK7QRegionRK6QPointiP8QPainterP19QWidgetBackingStore+0x440) [0x7f13837fd830]
    /usr/local/klayout/lib64/test/libQtGui.so.4(_ZN14QWidgetPrivate22paintSiblingsRecursiveEP12QPaintDeviceRK5QListIP7QObjectEiRK7QRegionRK6QPointiP8QPainterP19QWidgetBackingStore+0x320) [0x7f13837fd710]


    Regards,
    Canny
  • edited November -1

    Hi Canny,

    that looks like a recursive call within Qt. I have never seen that message before. Maybe an issue with the Qt installation? What's your platform and Qt version?

    Matthias

  • edited November -1
    Hi, Matthias,

    The platform we use is RHEL6.2
    The Qt vesion we use is 4.6.2-20

    Regards,
    Canny
  • edited November -1

    Hi Canny,

    I'm sorry, but I can't reproduce that behaviour myself. Did you build Qt yourself? AFAIK RHEL does not come with Qt 4.6.2. Maybe some issue with your Qt build?

    Are you able to reproduce the issue with the Windows binary?

    Regards,

    Matthias

  • edited November -1
    Hi, Matthias,

    Sorry, I can't reproduce this issue, even in the same Linux environment.

    Regards,
    Canny
  • edited November -1

    Hi Canny,

    does that mean it's gone? Or does it happen sporadically?

    Matthias

  • edited November -1
    Hi, Matthias,

    Yes, it's gone.

    Regards,
    Canny
  • edited November -1
    Hi, Matthias,

    I'm using Klayout v0.24.4 now, and I get the following error message when I try to save layout as oas file.

    *** ERROR: /da8450/source/OpenSource/klayout/source/klayout-0.24.4/src/dbOASISWriter.cc,1749,amax >= 2 || bmax >= 2
    *** ERROR: Internal error: /da8450/source/OpenSource/klayout/source/klayout-0.24.4/src/dbOASISWriter.cc:1749 amax >= 2 || bmax >= 2 was not true

    I'm not sure if the above error message are the same as you mentioned in http://klayout.de/issues.html#0.24.4

    Canny
  • edited November -1

    Hi Canny,

    no it's not the same issue. I have no explanation for this assertion.

    Could you send a test case for reproducing that problem to the mail address listed in the Contact page?

    I will have a look at this issue then.

    Regards,

    Matthias

  • edited February 2016
    Hi, Matthias,

    I find out what the problem is.
    If there is an instance exists in the layout as an 1x1 array, then try to save this layout as an oas file, the error message shows.
    Could you also reproduce this error?

    Regards,
    Canny
Sign In or Register to comment.