On Sun, May 7, 2017 at 7:45 PM, <raffaello.giulietti@lifeware.ch> wrote:
On 07/04/17 18:28, Dimitris Chloupis wrote:
Do you guys received my CPU exceptions solution message ? Because the issue you described is already resolved by hardware. Simple and elegant solution too On Fri, 7 Apr 2017 at 11:03, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>> wrote:
2017-04-07 8:22 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>:
But then the problem is on "how to not lose your code", not in FFI...
Restarting image is a problem. For any other "smalltalk" problems we got suitable debugger but not in that case.
Also when image crashed we need to recover all objects state for the script which produce crash
FFI is a border. Once you start working with it, you are in C world. And C world is nasty, hard and cumbersome.
Yes. And my remark was about possibility to catch C error to prevent image crash, why it will make FFI less hard.
My experience with the UFFI so far is quite positive. Of course, a lot of care needs to go to the C part, but that's a fact of life with C's unsafe computational model.
So, if the C code is well written and thoroughly tested, possibly outside Pharo, then integrating it by means of the UFFI is rather straightforward. I agree that small errors using the UFFI can lead to spurious or catastrophic outcomes, so unit (or even smaller scoped) testing really becomes vital.
From what I can tell so far, the UFFI is fast, well performing and, with some care, not even so hard as it might seem at first sight.
Greetings Raffaello
btw, I started a UFFI / Clang tutorial here (that I need to get back to) http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-1-preamble/ cheers -ben