Type not defined for TopTools_ListIteratorOfListOfShape

[mmiscool]

It seems that the type definition for TopTools_ListIteratorOfListOfShape is yet to be defined.

[donalffons]

Thanks for the note!

TopTools_ListIteratorOfListOfShape is defined here. What makes this tricky (and is probably part of the reason it is not auto-generated) is that it is a template specialization of NCollection_List::Iterator, which is yet another typedef'd template specialization of NCollection_TListIterator.

I will look at this (and some other "tricky" bindings) at some point in more detail. Until then, your best option might be to create a custom build and add a helper class in an additionalCppCode block, which lets you avoid using those problematic types in JavaScript (you can use them in C++ as much as you want, of course). Then also add that class name to the "bindings" block.

[mmiscool]

@donalffons When I run a custom build specifying the bindings in the yaml file, only those symbols are going to be available to me from JS and I loose the auto-generated ones. Is there any way to grab the original auto-generated bindings and add my custom ones to them?

I was following these instructions: https://github.com/donalffons/opencascade.js/blob/master/doc/README.md#creating-a-custom-build

Right now we are working on swapping over from our own old custom build of open cascade with hand written bindings for all functionality over to this library in this project. https://github.com/xibyte/jsketcher Hopefully any thing on the bindings and library side we do can be up-streamed.

[donalffons]

If you just leave out the the bindings property (or make it an empty array), the build system will generate bindings for anything it can currently understand (including your "custom" class definitions). Have a look at the super simple custom build definition for the official opencascade.js build (which includes "everything").

It's super nice to hear about your plans of migrating to this project! :slightly_smiling_face: I know about jsketcher and have played with it before. Great piece of software!

If you run into any other issues, feel free to ping me (like you already did). I'll try to help. I'll be quite busy for the next few weeks, but I'll do my best. Cheers.

[mmiscool]

I tried to run a custom build with the following yml file:

  mainBuild:
    name: rocketExample.js
    emccFlags:
      - -O3
      - -sEXPORT_ES6=1
      - -sUSE_ES6_IMPORT_META=0
      - -sEXPORTED_RUNTIME_METHODS=['FS']
      - -sINITIAL_MEMORY=100MB
      - -sMAXIMUM_MEMORY=4GB
      - -sALLOW_MEMORY_GROWTH=1
      - -sUSE_FREETYPE=1
  additionalCppCode: |
    #include <iostream>
    class CustomClass {
    public:
      static void SayHello() {
        std::cout << "Hello, World" << std::endl;
      }
    };

I used this as the shell comand to run the build:

docker run \
  --rm \
  -it \
  -v $(pwd):/src \
  -a STDIN \
  -a STDOUT \
  -a STDERR \
  -u $(id -u):$(id -g) \
  donalffons/opencascade.js \
  test.yml

It builds the WASM file but fails to create the js file needed. I omitted the bindings property as you suggested. I am attaching a log file capturing stdout and stderr results.log .

[donalffons]

Hmm, this works fine on my system. It completes without error messages and produces the expected build results (js / wasm / d.ts).

Maybe your system is running out of memory during the build? The build actually needs quite a large amount of memory. The amount consumed seems to grow with on the number of bindings that are included in your build. For a "full" build, as in your example, it uses somewhere in the order of 40GB - 45GB, I believe. If you're on linux (or MacOS I guess), you might be able to create and mount a swap file that your system can use as extra memory during the build.

I should probably add a note about this in the docs...

[mmiscool]

I wanted to reach out and see if there was a chance we might be able to hop on a call. On our end we have been working on the build process and the missing bindings. It would probably be a good idea to have a conversation about how best to collaborate on these things. The primary developer for jsketch (xibyte) would be on the call. He has some some thoughts and notes on the python scripts being used to do the bindings and it would be best to discuss so that we are all on the same page before we move forward especially for any changes that we would want to upstream in to this project if you are open to it.

It's super nice to hear about your plans of migrating to this project! 🙂 I know about jsketcher and have played with it before. Great piece of software!

If you run into any other issues, feel free to ping me (like you already did). I'll try to help. I'll be quite busy for the next few weeks, but I'll do my best. Cheers.