freenode/#clasp - IRC Chatlog
Search
12:50:53
drmeister
The travis build failed because it failed trying to include #include <rti_dds/rti_dds.h> ?????
12:57:33
drmeister
I think I know what is going on. I added attila's travis code and so travis started working but it's still working in drmeister.
12:58:31
drmeister
I connected travis to the 'clasp-developers' account - we need to migrate the clasp repo to 'clasp-developers'
14:31:58
drmeister
I forked clasp and cando into clasp-developers - don't do anything with them for now. I just want to test travis.
14:43:48
frgo
drmeister: Q: In file include/clasp/gctools/gc_interface.h there is an #include <project_headers.h> when building extensions. Do you use/need that project_headers.h in Cando? Where does it live there?
14:45:13
drmeister
I think it's this: ~/Development/cando/extensions/cando/include/cando/main/project_headers.h
14:46:12
drmeister
Now - this is more (exclusively?) for classes that you define that subclass from core::General_O
14:47:06
drmeister
This is all referenced from here: https://github.com/drmeister/cando/blob/dev/wscript#L16
14:47:35
drmeister
It's that Python code that hooks the extension header file into the clasp build system.
14:49:03
drmeister
These extensions are more for when you add classes that you want managed by the garbage collector - are you doing that?
14:50:05
drmeister
Ok - there is no fundamental reason why we can't support multiple extensions simultaneously but there is a challenge to overcome.
14:51:55
drmeister
The static analyzer will need to be run on any permutation of clasp+extensions that are compiled into the single cclasp-mps executable that clasp builds.
14:52:53
frgo
One is the Data Distribution Standard messaging system for realtime message exchange between systems.
14:53:58
frgo
So I set up the wscript machinery to include them if the respective subdirs in extensions/ are found.
14:54:05
drmeister
Will they both contain GC managed classes? Nanogui seems kind of lightweight and may not require any GC management.
14:54:53
drmeister
Nanogui can just be a library that is dynamically loaded and exposed to clasp without ever needing GC managed classes.
14:55:45
drmeister
The idea is that you drop any number of extensions into that directory and then you build a clasp that incorporates them all.
14:56:46
drmeister
It's using the waf 'recurse' facility to find extensions in clasp/extensions and accumulate all the information necessary to create a single executable.
14:58:52
drmeister
Rest assured though that I designed all of this so that any number of extensions can be merged together into one super clasp system.
14:59:11
drmeister
If it doesn't support that now - it's a bug and we should fix it. I only had one extension (cando) when I started this.
15:00:05
drmeister
The reason everything needs to be together is because the GC needs to have unique header stamp (integer index values to identify each C++ class that is GC managed) for every class in the system.
15:00:59
drmeister
It was mind bogglingly difficult to figure out how to do this in a modular way so that extensions could be added piecemeal at load time.
15:01:57
drmeister
You will notice in the clasp/src/main/ directory there is a clasp_gc.cc and a clasp_gc_cando.cc file.
15:02:30
drmeister
That is a massive wart in my current scheme - that the clasp source code needs to know about clasp_gc_cando.cc
15:02:55
drmeister
When you use the static analyzer and you generate one of those files yours will be named...
15:04:30
drmeister
Ok - with the present scheme (before we figure out how to fix this wart) when you use the static analyzer on clasp plus your rti_dds and nanogui extensions - the static analyzer will generate a clasp_gc_nanogui_rti_dds.cc file.
15:05:35
drmeister
Currently (the wart) means you will need to generate that file and we put it into clasp/src/main/clasp_gc_nanogui_rti_dds.cc
15:06:22
drmeister
In the future we might have a repository of combinations of extensions that can be added to clasp for which there exist GC descriptions.
15:07:04
drmeister
None of this is needed by the Boehm GC mind you - the Boehm GC gets all of its information from the scraper - the scraper runs every time you build clasp.