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
