Jump to content

Nicolas Goutte

Member
  • Content Count

    336
  • Joined

  • Last visited

Everything posted by Nicolas Goutte

  1. Or use ulimit -s directly. (from https://stackoverflow.com/questions/10214363/increase-stack-size-in-os-x-lion)
  2. For the bug itself, I have just two further ideas: - does it crash too if you give an invalid, but non-empty string? - Is your string in the form "" or is it an empty TXString? Does it make a difference? As for stack size, may be you can change it on system level. sysctl(8) seems ti have two values concerning stacks: kern.stack_size: 16384 kern.stack_depth_max: 10096
  3. It seem consistent with https://stackoverflow.com/questions/18909395/how-do-i-increase-the-stack-size-when-compiling-with-clang-on-os-x However, you are not controlling the main program (VW), so I do not know if it makes any sense to try it for a plug-in. Also exceeding the stack should be uncommon. Are you sure you have not an endless recursion somewhere? Or may be the crash is really in VW, because of what the plug-in has done just before.
  4. I have taken the time to check that Default-Tool-Project. (Sorry I had no time to spare before.) This one has still a real Debug target; something that does not work since a few VW major versions ago. See the previous discussion:
  5. Also the problem of releasing a Release target is that the compiler is allow to change the code. So it could happen that the line where you set the breakpoint is not in the generated plug-ins anymore, so that the debugger does not stop.
  6. You are sure to have the Release plug-ins seen by VW. And only that one, not both.
  7. Mostly it happens when you are not debugging what you think you are debugging. (The exakt version of what you start differs from what is in your IDE (Xcode or Visual Studio)
  8. Even in C++-Code, it can happen that you do not see the text if VW has no time to draw it.
  9. Yes you can use the Fake-Debug trick. As long as the C++ code is not optimized, the breakpoints should work correctly and be at the right place.
  10. https://developer.vectorworks.net/index.php/SDK:Parametric_Extended_Properties
  11. Most are text files, so you could compare.between your two machines, what they have for settings.
  12. See the "Setting" folder in your VW user folder. There are all settings.
  13. On Windows, you cannot use the Debug mode, as on Windows the C(++) runtime for Debug and Release differ, but VW is available for us (third party developers) only as Release mode. See what I had written months ago:
  14. Double check that the "'pip list' " you have written as a parameter to subprocess.Popen has no special character.
  15. Well, I did not start with VisiCalc like @Pat Stanford did, but I had the chance to use one day Multiplan. (Otherwise I have really started with old Excels, the successor.) However for me too, it is standard not to use SUM. I am not sure that using =SUM(B2*C2) would work on such old spreadsheet (e.g. old Excel) either, as if I remember well (but only very vaguely), SUM needed at least 2 parameters.
  16. The ground rule (also in VW 2020) is: open everything, export to the last 5 versions
  17. As written above, I do not think you can define an object in a Plug-In that is not a Parametric object. Otherwise a Parametric object that would not be a Plug-In would be needed to be defined in VW itself. I am not sure if there is any. (If it is defined in VW, it could have its own object type.) Thanks too. This thread makes a few things clear for me too, that were not so clear before.
  18. Yes, I think you are getting closer. However an object would be a Plug-in too. You can see Plug-ins as something that tells VW: "Here are some extensions: this tool ATool, this object A, this menu B, this code library C". Normally a file containing code file, especially from C++, defines more that one "thing" (that is my naming).
  19. You could define it in another way (a bit simplified perhaps): - a plug-in is something listed in the Plug-In Manager - an object listed there is parametric.
  20. For me, they are not parametric, as they have other object types. (And they are no Plug-Ins either, as there are defined in VW itself, as far as I know. Wall is very internal in VW too, so it is not a Plug-In. Also it has a separate object type too. However Door and Window are parametric objects and Plug-Ins. I would say anything that is an object which is defined as Plug-Ins. Thinking about it, I think you cannot defined any other type of object that a parametric in a plug-in (alternatively you can define a menu, a tool or library code). So at the end a PIO is probably the same as a Parametric object (unlike what I have written in the meantime).
  21. No, it is the object which is Parametric. The tool is just a tool to be able to place it into the document. (Sorry, for the recursive definition. ūüėÉ) My definition comes from the internal object types. Sure that would be another point of view. That is probably why it is not easy for somebody not knowing object types to see a difference. However seen that way, every object of VW has a OIP where something can be changed (be it its position). (That is probably the definition of a PIO.)
  22. Internally in VW, all those are not Parametric objects, as they have other object types.
  23. There is also the term PIO, which is mostly used in the sense Parametric Object
  24. A Parametric object is a VW object of type 86 (constant kParametricNode in C++). As for "plug-in", I would say anything that is in the folder Plug-Ins, to add functionality in VW. A tool, especially a third-party one, is probably going to have parametric object associated to it, but it does not need too. (E.g. you could have a tool creating a polygon.) A parametric object alone cannot be placed in a VW document, you need a tool, a menu (or a call by a script or other code).

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

√ó
√ó
  • Create New...