freenode/#clasp - IRC Chatlog

13:34:16 drmeister selwyn: clasp May be trying to run constructors on load. Where is the bitcode coming from?

13:35:24 drmeister I’ve not loaded random bitcode - it’s usually set up by clasp.

13:36:52 drmeister In the clasp-cxx-demo repo there is a macro that I add to make that c++ compile to bitcode that loads

14:40:13 selwyn drmeister: i tried to load double-vector-cxx.bc from demo-clasp-cxx-interoperation. also i tried to load some generated bitcode from the build process build/boehm/fasl/cclasp-boehm-bitcode/generated/cl-wrappers.bc since i figured that must work

14:40:52 selwyn what is the macro in question? CLASP_REGISTER_STARTUP?

17:56:37 drmeister Yes I think so

17:56:58 drmeister It’s whatever is in those cc files

18:01:01 drmeister I've added a facility to clasp extensions that lets them take over command line argument processing.

18:01:32 drmeister This way I can copy iclasp-boehm to icando-boehm and ileap-boehm and they behave differently depending on their filename.

18:01:38 drmeister Check this out...

18:02:14 drmeister https://www.irccloud.com/pastebin/GdqJXhcL/

18:02:47 drmeister The parser isn't complete - but it's simulating "leap" - the computational chemistry setup program I wrote 27 years ago.

18:04:14 drmeister The script it is evaluating is ...

18:04:26 drmeister https://www.irccloud.com/pastebin/NvrQ6Hne/

18:05:10 drmeister icando-boehm (and ccando-boehm) start up clasp and load all of the cando chemistry code but they drop you into a Common Lisp repl.

18:05:44 drmeister ileap-boehm starts clasp, loads all of the cando chemistry code and then starts a leap repl.

18:06:06 drmeister ileap-boehm handles command line arguments differently than clasp does - so it takes control at startup and sets things up for itself.

18:17:35 selwyn why is cando a clasp extension? does it need to be built alongside clasp at clasp build time?

18:28:08 drmeister selwyn: Long ago I decided to split clasp from the chemistry code. Clasp is an implementation of Common Lisp and Cando is the code that enhances clasp with lots of chemistry functionality.

18:28:35 drmeister To build them together all you do is you clone cando into the clasp/extensions/cando and then you build as normal.

18:29:00 drmeister There is no why to it really - it's a simplest solution to a difficult problem of merging to large code bases.

18:29:19 selwyn i see

18:29:21 drmeister Clasp builds and runs completely on its own.

18:29:26 drmeister Cando is nothing without clasp.

18:30:55 drmeister I generalized the idea of an extension - other people could write extensions for clasp.

18:31:08 drmeister Nobody has - but the capability is there.

18:31:32 drmeister frgo started one - I'm not sure what the status of it is though.

18:32:54 selwyn i am wondering whether the extensions mechanism is right for me - i am interested not so much in writing c++ code but integrating large c++ libraries that are already there. doing the exposure at build time would be convenient

19:14:42 drmeister I would take https://github.com/clasp-developers/demo-clasp-cxx-interoperation and start by exposing your library and then make it an extension later.

19:15:24 drmeister You can move it to an extension anytime - it's just some extra fiddly bits (wscript files) to deal with.

19:15:34 drmeister The cando extension is a prototype

19:15:52 drmeister I've taken pains to keep things general enough that others could create their own extensions.

19:16:42 drmeister Extensions are more for C++ classes that you want to have managed completely by the GC. Extensions merge their class hierarchy into the clasp class hierarchy. Exposed C++ libraries don't need (or want) this.

19:16:52 drmeister The classes need some GC awareness for this to work.

19:18:48 drmeister Bike: This thing with defclass at compile time - I'm about to reproduce the problem and then I'll get you a backtrace.

19:19:27 Bike alright.