Hi,
Good work :)
{ #category : #finalization }
HdBufferOpaque class >> finalizeResourceData: aHandle [
HdFFILibrary uniqueInstance
ffiCall: #(void hoedown_buffer_free (ExternalAddress aHandle))
]
wow… does this works at all?
I admit it is not how it is intended to work :P
> On 3 Jan 2020, at 06:24, Pierce Ng <pie...@samadhiweb.com> wrote:
>
> On Thu, Jan 02, 2020 at 12:56:55PM -0600, Sean P. DeNigris wrote:
>> bugs seem to be
>> more severe and difficult to diagnose, so we'll see how it goes as FFI use
>> becomes more and more common...
>
> There's a saying about (aspects of) building software which source I
> cannot recall:
>
> If it hurts, do it more frequently.
>
> I believe FFI should be pushed as much as possible to work out bugs and
> develop new capabilities. Looking forward to playing with threaded FFI.
+1
FFI introduces a whole new universe of possibilities we cannot reasonable cover
in-image nowadays.
Now, while *there are* problems still to solve, I think people have the wrong
impression the FFI layer is causing most of the bugs around (TTF for example)
while this is not true at all :)
For example, recent bug around memory corruption was claimed several times it
was because of FFI (and even I thought it was around it at the beginning) while
in fact it was a problem on how compaction was working.
Other example, TTF itself: problems were around when we had a plugin and we
still have some with the FFI implementation. But the problem is not around the
plugin or the FFI implementation but around the bad usage (not thread safe) we
do of it in-image.
The reason why people think some problems are FFI related is because we are
pushing Pharo in directions not-fully-tested before. The usage of FFI just
unveils a lot of problems on how we handle things there were present before,
but they were not as visible as they are now.
Esteban
>
> Pierce
>
