Esteban's ChangeLog week of 23 July 2018
Hello! This is my weekly ChangeLog, from 23 July 2018 to 29 July 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=23/7/2018&to=29/7/2018 ChangeLog ========= 27 July 2018: ------------- * I found a problem that was making win64 bit version to crash: size_t implementation on UFFI was not resolving properly there (since it was mapped to a long, which is not correct on win64 architecture). To fix it, I changed FFISizeT type to work as FFILong, with different "real types" depending on architecture. Now, there is a problem to solve because structures using this type (like +LGitStringArray+) need to be regenerated, which may generate some difficulties... will see. 23 July 2018: ------------- * So well. Spent the full day debugging libgit2 without symbol information :( There is some problem with adding paths to an index and I still cannot figure out what's the problem. I'll continue trying tomorrow. cheers! Esteban
Hi Esteban, I encountered this problem a few months ago. I tried to document FFI with a serie of stackoverflow questions https://stackoverflow.com/questions/49783882/how-one-deals-with-typedefs-in-... https://stackoverflow.com/questions/49784522/how-one-supports-both-32-and-64... After a deep analysis, I think that FFI needs a serious refactoring (plugin code + image code). But I have stopped that work in the middle... (no time available for a few months). The next thing I wanted to do is to study all your efforts with UFFI, and how you found workarounds for other pitfalls like https://stackoverflow.com/questions/49784253/how-one-deals-with-multiple-poi... https://stackoverflow.com/questions/49783443/how-one-defines-a-fixed-size-ar... https://stackoverflow.com/questions/49783126/how-one-defines-a-union-type-in... https://stackoverflow.com/questions/49782651/how-one-aligns-structure-fields... Cheers 2018-07-30 8:00 GMT+02:00 <estebanlm@gmail.com>:
Hello!
This is my weekly ChangeLog, from 23 July 2018 to 29 July 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=23/7/2018&to=29/7/2018
ChangeLog =========
27 July 2018: -------------
* I found a problem that was making win64 bit version to crash: size_t implementation on UFFI was not resolving properly there (since it was mapped to a long, which is not correct on win64 architecture).
To fix it, I changed FFISizeT type to work as FFILong, with different "real types" depending on architecture.
Now, there is a problem to solve because structures using this type (like +LGitStringArray+) need to be regenerated, which may generate some difficulties... will see.
23 July 2018: -------------
* So well. Spent the full day debugging libgit2 without symbol information :(
There is some problem with adding paths to an index and I still cannot figure out what's the problem.
I'll continue trying tomorrow.
cheers! Esteban
Hi Nico,
On 30 Jul 2018, at 09:02, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Hi Esteban, I encountered this problem a few months ago. I tried to document FFI with a serie of stackoverflow questions https://stackoverflow.com/questions/49783882/how-one-deals-with-typedefs-in-... <https://stackoverflow.com/questions/49783882/how-one-deals-with-typedefs-in-...> https://stackoverflow.com/questions/49784522/how-one-supports-both-32-and-64... <https://stackoverflow.com/questions/49784522/how-one-supports-both-32-and-64...> Thankfully this is kind of trivial with UFFI (once identified the problem), look at: https://github.com/pharo-project/pharo/pull/1660 <https://github.com/pharo-project/pharo/pull/1660>
After a deep analysis, I think that FFI needs a serious refactoring (plugin code + image code).
Been there, done that :) UFFI is a complete revamp of the image side code. I didnât touch the backend (since our philosophy is to put as much as possible into the image, this was possible) but I think it needs a serious re-think at least in two fields: - basic types needs to be the generic (uint32, uint64, etc.). - external datas have no meaningful use and it adds complexity. - callback logic needs to be moved from Alien to FFI
But I have stopped that work in the middle... (no time available for a few months). The next thing I wanted to do is to study all your efforts with UFFI, and how you found workarounds for other pitfalls like https://stackoverflow.com/questions/49784253/how-one-deals-with-multiple-poi... <https://stackoverflow.com/questions/49784253/how-one-deals-with-multiple-poi...> https://stackoverflow.com/questions/49783443/how-one-defines-a-fixed-size-ar... <https://stackoverflow.com/questions/49783443/how-one-defines-a-fixed-size-ar...> https://stackoverflow.com/questions/49783126/how-one-defines-a-union-type-in... <https://stackoverflow.com/questions/49783126/how-one-defines-a-union-type-in...> https://stackoverflow.com/questions/49782651/how-one-aligns-structure-fields... <https://stackoverflow.com/questions/49782651/how-one-aligns-structure-fields...> Solved in UFFI.
Cheers, Esteban
Cheers
2018-07-30 8:00 GMT+02:00 <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>: Hello!
This is my weekly ChangeLog, from 23 July 2018 to 29 July 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=23/7/2018&to=29/7/2018 <http://log.smallworks.eu/web/search?from=23/7/2018&to=29/7/2018>
ChangeLog =========
27 July 2018: -------------
* I found a problem that was making win64 bit version to crash: size_t implementation on UFFI was not resolving properly there (since it was mapped to a long, which is not correct on win64 architecture).
To fix it, I changed FFISizeT type to work as FFILong, with different "real types" depending on architecture.
Now, there is a problem to solve because structures using this type (like +LGitStringArray+) need to be regenerated, which may generate some difficulties... will see.
23 July 2018: -------------
* So well. Spent the full day debugging libgit2 without symbol information :(
There is some problem with adding paths to an index and I still cannot figure out what's the problem.
I'll continue trying tomorrow.
cheers! Esteban
participants (3)
-
Esteban Lorenzano -
estebanlm@gmail.com -
Nicolas Cellier