Esteban's ChangeLog week of 16 January 2017
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
yeah, Iâm aware I need to iterate on the text exporter to have some better output :P Esteban
On 23 Jan 2017, at 09:00, 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>>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
Tx a lot esteban! This is so great. Showing what you are doing is important. Can you send this mail to the consortium mailing-list too? On Mon, Jan 23, 2017 at 9:22 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
yeah, Iâm aware I need to iterate on the text exporter to have some better output :P
Esteban
On 23 Jan 2017, at 09:00, 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>>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
On 23 Jan 2017, at 10:02, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Tx a lot esteban! This is so great.
thanks :)
Showing what you are doing is important. Can you send this mail to the consortium mailing-list too?
of course, this is a Pharo script after all ;) Esteban
On Mon, Jan 23, 2017 at 9:22 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: yeah, Iâm aware I need to iterate on the text exporter to have some better output :P
Esteban
On 23 Jan 2017, at 09:00, estebanlm@gmail.com <mailto: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 <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
I like the "talk to yourself" format :P On Mon, Jan 23, 2017 at 10:05 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 23 Jan 2017, at 10:02, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Tx a lot esteban! This is so great.
thanks :)
Showing what you are doing is important. Can you send this mail to the consortium mailing-list too?
of course, this is a Pharo script after all ;)
Esteban
On Mon, Jan 23, 2017 at 9:22 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
yeah, Iâm aware I need to iterate on the text exporter to have some better output :P
Esteban
On 23 Jan 2017, at 09:00, 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>>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
Very good idea Esteban I think I will steal it On Mon, 23 Jan 2017 at 11:38, Guillermo Polito <guillermopolito@gmail.com> wrote:
I like the "talk to yourself" format :P
On Mon, Jan 23, 2017 at 10:05 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 23 Jan 2017, at 10:02, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Tx a lot esteban! This is so great.
thanks :)
Showing what you are doing is important. Can you send this mail to the consortium mailing-list too?
of course, this is a Pharo script after all ;)
Esteban
On Mon, Jan 23, 2017 at 9:22 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
yeah, Iâm aware I need to iterate on the text exporter to have some better output :P
Esteban
On 23 Jan 2017, at 09:00, 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>>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
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>>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
participants (6)
-
Ben Coman -
Dimitris Chloupis -
Esteban Lorenzano -
estebanlm＠gmail.com
-
Guillermo Polito -
Stephane Ducasse