On Sun, May 7, 2017 at 7:45 PM, <raffaello.giulie...@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 <dionisi...@gmail.com >> <mailto:dionisi...@gmail.com>> wrote: >> >> >> 2017-04-07 8:22 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com >> <mailto:esteba...@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
