Smalltalk › Pharo › Pharo Smalltalk Developers

Esteban's ChangeLog week of 23 July 2018

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

EstebanLM

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

Nicolas Cellier

Re: Esteban's ChangeLog week of 23 July 2018

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-squeak-ffi

https://stackoverflow.com/questions/49784522/how-one-supports-both-32-and-64-bits-target-in-squeak-ffi

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-pointer-level-like-char-in-squeak-ffi

https://stackoverflow.com/questions/49783443/how-one-defines-a-fixed-size-array-member-in-a-struct-in-squeak-ffi

https://stackoverflow.com/questions/49783126/how-one-defines-a-union-type-in-squeak-ffi

https://stackoverflow.com/questions/49782651/how-one-aligns-structure-fields-in-squeak-ffi

Cheers

2018-07-30 8:00 GMT+02:00 <[hidden email]>:

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

EstebanLM

Re: Esteban's ChangeLog week of 23 July 2018

Hi Nico,

On 30 Jul 2018, at 09:02, Nicolas Cellier <[hidden email]> 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-squeak-ffi
https://stackoverflow.com/questions/49784522/how-one-supports-both-32-and-64-bits-target-in-squeak-ffi

Thankfully this is kind of trivial with UFFI (once identified the problem), look at: 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-pointer-level-like-char-in-squeak-ffi
https://stackoverflow.com/questions/49783443/how-one-defines-a-fixed-size-array-member-in-a-struct-in-squeak-ffi
https://stackoverflow.com/questions/49783126/how-one-defines-a-union-type-in-squeak-ffi
https://stackoverflow.com/questions/49782651/how-one-aligns-structure-fields-in-squeak-ffi

Solved in UFFI.

Cheers,

Esteban

Cheers

2018-07-30 8:00 GMT+02:00 <[hidden email]>:
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