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>>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>>x
^ handle unsignedLongAt: 1
StructPoint>>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>>x
^ handle unsignedLongAt: OFFSET_X
StructPoint>>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
