Thanks Esteban. This is interesting to tune in on whats happening in vm and FFI.
cheers -ben

On Mon, Jan 23, 2017 at 4:00 PM, <estebanlm@gmail.com> wrote:
Hello!

This is my weekly ChangeLog, from 16 January 2017 to 22 January 2017.
You can see it in a better format by going here: http://log.smallworks.eu

ChangeLog
=========

20 January 2017:
----------------

�� * I'm still fixing a couple of final failing tests on iceberg,
�� �� multi-remotes branch. Problem is that there are still somethings to understand
�� �� on the "command line
�� �� backend" (we need to find a better name for this), and the #pushTo: method: if I
�� �� do it as I
�� �� think is correct, a couple of failing tests appear... but then, I need to
�� �� reflect if this is
�� �� a problem on the functionality or on the tests.

19 January 2017:
----------------

�� * I think I finally got the problem with FT2Plugin!
�� �� Yesterday night talking in slack I realised that there was actually duplicated
�� �� instances of
�� �� FT2Handle hierarchy with exactly same handle�� (pointer address). This, of
�� �� course, causes a double free when those instances are released... and
�� �� that's the VM crash :)
�� �� So I quickly sketched a workaround, that you can see here:
�� �� FT2Handle&gt;&gt;pvtDestroyHandle
�� �� "This should only be sent from the finalizer.
�� �� It runs inside a mutex because in strange cases it can happen that this is
�� �� executed twice,
�� �� causing a primitiveFailed to be raised."
�� �� self class destroyMutex critical: [ | handleToRelease |
�� �� self isValid ifFalse: [ ^self ].
�� �� handleToRelease := self handle copy.
�� �� self primDestroyHandle.
�� �� "This is super-ugly, but it will prevent duplicated handles to be released"
�� �� FT2Handle allSubInstancesDo: [ :each |
�� �� (handleToRelease = each handle) ifTrue: [ each beNull ] ] ]
�� �� and so far nobody who is testing it crashed!
�� �� This can be important, but of course... now we need to realise why the
�� �� duplicated instances are happening.
�� * I spent some time preparing a new way to annoy people :)
�� �� I prepared a way to send a digest mail about my activity (this stream) to
�� �� pharo-dev list.
�� �� I hope it will not be too much.

18 January 2017:
----------------

�� * ... and still some more work on iceberg, this time making some test
�� �� pass on the command line backend (who is just a fallback, but well... we still
�� �� need it around).
�� * Still working on UFFI 64bits. Now I introduced a new hierarchy, FFIArchitecture
�� �� for now with two children:
�� �� * FFI_i386
�� �� * FFI_x86_64
�� �� the purpose is obvious: to allow UFFI to handle differences between different
�� �� architectures (for example,
�� �� long has to be parsed to FFIInt32 in i386 and to FFIInt64 in x86_64).

17 January 2017:
----------------

�� * I'm working on the UFFI support for 64bits.
�� �� In general, it works fine, but there is a huge problem with structures. What's
�� �� this problem? Well, let's take
�� �� this simple structure as example:
�� �� struct point {
�� �� unsigned long x;
�� �� unsigned long y;
�� �� }
�� �� Well, thing is in 32bits sizeof(struct point) = 8 while in 64bits sizeof(struct
�� �� point) = 16, and of
�� �� course this breaks our current implementation which would be something like this
�� �� StructPoint&gt;&gt;x
�� �� ^ handle unsignedLongAt: 1
�� �� StructPoint&gt;&gt;y
�� �� ^ handle unsignedLongAt: 5
�� �� and of course, this is not correct for 64bits.
�� �� My solution is quite simple, instead hardcoding the field offsets, I store those
�� �� values into class variables
�� �� that can be calculated each session (but just once).
�� �� So, this structure would end looking like this:
�� �� StructPoint&gt;&gt;x
�� �� ^ handle unsignedLongAt: OFFSET_X
�� �� StructPoint&gt;&gt;y
�� �� ^ handle unsignedLongAt: OFFSET_Y
�� �� this would solve the problem for most of the cases, but there is still the issue
�� �� that emerges when complete
�� �� implementation of the struct changes between platforms. I'm planning to
�� �� implement a strategy pattern to solve
�� �� this, but not yet (probably I will wait until having a concrete case).
�� �� This seems to be working, but now I have other problems not related to UFFI:
�� �� many people has implemented
�� �� void * parameters of funtions as unsigned long (including me, time ago) which
�� �� was correct in 32bits but
�� �� it is not in 64bits. So now I need to review this implementations to see where a
�� �� fix is needed.
�� �� But this is not directly a problem of UFFI, I think.
�� * I worked with Nico on fixing libgit2 backend tests for iceberg.
�� �� Now (more thanks to Nico than me, heh), test for multi-remotes branch are
�� �� passing for linux but
�� �� still not for macOS (and forget it about Pharo 5.0).
�� �� I suspect a problem with VM, I need to review if I can configure smalltalkci
�� �� to work with latest vm instead stable.

15 January 2017:
----------------

�� * ... and now I restored the posix permissions to windows platform. Next latest VM
�� �� will have this change, I
�� �� hope that will end the problems with FilePlugin, but we'll see.
�� * I just fixed a problem with FilePlugin on macOS: the problem was when
�� �� determining if a symlink is also a
�� �� directory:
�� �� ���/tmp��� asFileReference isDirectory
�� �� was answering false, because it is a symlink and when trying to resolve the
�� �� symlink to obtain the
�� �� attributes, there was a cyclic condition that was transforming ���/tmp��� into
�� �� ���/private/tmp��� and then
�� �� back to ���/tmp���, and because of that the test for directory was failing.

cheers!
Esteban