I've been working on Common Lisp bindings to various EFL libraries, since I figured that the best way to learn the APIs is by creating bindings to them and trying them out interactively.
I've run into one major issue, however. My CL implementation did strange things (hang, and then crash). It turns out this was because of Ecore installing signal handlers for every signal out there. Once I commented out the installation of a handler for SIGSEGV in ecore_event_signal_init and #undefd SIGRTMIN in ecore_signal.c, the problems went away and everything started working again. Most dynamic languages with a half-decent garbage collector and threads will need signals. SBCL, which I use, needs SIGSEGV and two SIGRTs. Comments at the top of ecore_signal.c would seem to indicate that people experienced problems with Mono and Valgrind already, so this is likely to become a recurring issue. My humble suggestion would be to make all signal handling an optional feature of Ecore. Not every application that links to Ecore will be a standalone C app that appreciates Ecore handling the signals for it. BTW, the other place where Ecore assumes a lot about the application is the ecore_app_restart() call (and other related ecore_app calls). It's very unlikely that anyone will want to restart a Mono or Lisp application this way, much less that it will succeed. I feel that these functions belong in a separate API, useful for standalone C applications. But at least I have the option of not calling these :) --J. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
