It looks like you're new here. If you want to get involved, click one of these buttons!
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.
Wonderful work! Much appreciated.
You should expect I have some long discussion post in response :-) So here goes.
A few notes/questions:
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?
"Apply to all" doesn't always work as I'd expect -- I think we have different interpretations of it.
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.
"Apply to all" doesn't work on certain operations. Steps to reproduce the problem:
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?
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...
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
to the other selected paths.
A consequence of that is:
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,
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 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.
I didn't think of having an option in File > Setup, but that is a great idea!
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: *** [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.
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.
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
I think it may be due to the funtion "def triggered" fail
Could you also help to check these error?
Change this line (47)
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.
Thanks, Best regards,
@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.
Thank you, the 0.24.1 solves the problems.
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.
I guess you have built KLayout without Qt binding support, right?
If you build KLayout yourself (on Linux), you'll need to add
--with-qtbindingto 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.
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:
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:
Yes, we built Klayout in Linux without Qt binding support
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 ?
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.
Without Qt binding support the Qt classes such as QDialog are not available. Please build again with -with-qtbinding.
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
Program Version: KLayout 0.24.1 (2015-08-26 r2982)
I'm not sure if this bug has been reported and fixed
this is a known bug. Please use the most recent version 0.24.3, where this bug was fixed.
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
Program Version: KLayout 0.24.3 (2015-11-05 r3062)
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?
The platform we use is RHEL6.2
The Qt vesion we use is 4.6.2-20
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?
Sorry, I can't reproduce this issue, even in the same Linux environment.
does that mean it's gone? Or does it happen sporadically?
Yes, it's gone.
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
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.
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?