Esteban's ChangeLog week of 13 February 2017

Hello!

This is my weekly ChangeLog, from 13 February 2017 to 19 February 2017.
You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=13/2/2017&to=19/2/2017

ChangeLog
=========

17 February 2017:
-----------------

*    I spent sometime working on UFFI and 64bits.
   
    Sometime ago I started this and found a problem that I talked with Eliot, you can found the rational
    [here](http://forum.world.st/Support-for-LP64-amp-LLP64-in-FFI-Kernel-td4929946.html) (we need to model
    in some way the fact that longs have different sizes in different platforms, notably LP64 and LLP64).
   
    In that discussion, with Eliot we proposed to add a new FFI type, a +platformLong+ who will behave as
    expected. I started to implement but didn't have the time to finish it and I needed to jump to other
    stuff. In the mean time, Ronie found a different workaround: instead adding support in the VM, just map
    in image the type to correct size.
   
    This is how it will work:
   
    |===
    |Platform
    |type
    |size
    |FFI type
    |
   
    |i386
    |long
    |4
    |long
    |
   
    |LP64
    |long
    |8
    |long long
    |
   
    |LLP64
    |long
    |4
    |long
    |
    |===
    Ensuring this mappings happens when compiling an UFFI method (and a structure, etc.) we can workaround
    the plugin limitation.
   
    So I worked taking Ronie's work, extended it to structures and added my own work on mapping structures
    in a 'platform-agnostic' way: the idea is to take values by 'offset' instead the constant value as
    it was done up to now. On 'structure-compilation time' (it happens first time structure is used on a
    session), it calculates also the correct field access offsets and structure size.
   
    This is mostly working, it just lacks some testing and pushing it to image... then I can start prepare
    Athens, SDL2 and libgit2 bindings to work both in 32 and 64 bits :)
   

16 February 2017:
-----------------

*    I continue enhancing [iceberg](https://github.com/npasserini/iceberg/pull/277) as much as I can, waiting to
    +0.4 release+ (that should be very soon).
   
    I added a couple of new things:
   
    * capability of plugins to extend "remotes panel" of repositories browser (so we can have options there)
    * added a new GitHub option: remove old branches dialog.
    * and I started a refactor of GitHub plugin to use a command-pattern hierarchy instead polluting the plugin.
   
    Rationale of plugin action addition is simple: if we receive a lot of bugfixes in the form of a pull request,
    it means people will be spawning branches all over the place, those branches can stay there a lot of time
    but eventually, is good to clean up a bit. Now we can do this cleaning from Pharo :)
   
    This is not just useful but it shows the power we can achieve by extending iceberg with plugins for different
    purposes ;)
   

15 February 2017:
-----------------

*    I spent some time bringing back some functionality I implemented for [voyage](https://github.com/pharo-nosql/voyage)
    a lot of time ago (like 4 years) that went missing because of lack of use.
   
    This is a "dinamic singleton access strategy"... something like that, more or less...
   
    The idea of this is, sometimes you need to have more than one repository active in an image, but you still
    want to use the singleton strategy (because is a lot cooler doing something like +Person selectOne: [ ... ]+
    instead of +myRepository selectOne: Person where: [...]+.
   
    Voyage always allowed different container strategies, even if in master implementation there is just one,
    +VOSingletonContainer+. Now I added another called +VODynamicContainer+ and this allow to take the
    repostory from a 'dynamic variable' called +VOCurrentRepository+.
   
    So, for instance, when you have a seaside application where each user works on his own database, you can create
    a filter of the way:
   
    ----
    VoyageFilter>>handleFiltered: aRequestContext
    VOCurrentRepository
    value: self obtainUserRepository
    during: [ self next handleFiltered: aRequestContext ]
   
    VoyageFilter>>obtainUserRepository
    ^ self session
    propertyAt: #voyageRepository
    ifAbsentPut: [ VOMongoRepository database: (self session propertyAt: #username) ]
    ----
   
    ... adn you will handle your application as if your repository would be a singleton.
   
    To make this work, the only thing you need is to configure your repository this way:
   
    ----
    VORepository repositoryContainer: VODynamicContainer new
    ----
   

14 February 2017:
-----------------

*    I lost all day digging the problem with +FFICallbackTests+ on windows platforms.
   
    The problem occurs when going back to the image from a callback context 'when calling the tests'. Is
    important to remark this because other systems using a lot of callbacks are working fine (notably iceberg,
    the libgit2 bindings use callbacks as an important part of his design). Also +Athens+ (who uses callbacks
    to provide some values cairo lib needs) is working correctly too.
   
    So, I'm tempted to think it may be a problem with +MinGW+ implementation of +qsort+ function, and we use it
    to test the callbacks... anyway, I will keep digging when I find some more time, for now is enough to constate
    it is not being a problem for windows users (unless, of course, they need to use qsort ;) )
   

13 February 2017:
-----------------

*    I worked on a plugin for iceberg that will take the place of the old "create SLICE"... so far is a very simple
    plugin that does exactly wjat the slice creator did: takes an issue number and gets the title from it, to
    conform a branch name called +12345-issue-title-here+.
   
    With this change (pull request [here](https://github.com/npasserini/iceberg/pull/277)), all pieces to replace
    the old fix process are there:
   
    * adding remotes (so you can clone pharo and use your remote as temporal destination)
    * creating pull requests (so you can submit your changes in a fancy way)
    * creating branches that conforms to our convention (so you can create branches as we like them ;)
   
    ... all this in an easy way (at least for me, heh).
   
    It remains, of course, test everything and enhance it with user feedback, but we will be starting that next
    week.
   
*    I finally finished restoring testing phase to [VM building](https://github.com/pharo-project/pharo-vm).
    The purpose of this is, of course, to notice regressions on VMs as soon as we can, and of course, I found
    some regressions I needed to fix before being able to have a green build. Most of them were details but:
   
    * there was an important problem with +String+ primitives I needed to dealt with.
    * there is a problem on +FFICallback+ for windows who make the test crash (but callbacks works most of the time)
   
    There are, however, still some important problems to fix:
   
    * threaded VM linux cannot be tested because they requiere changing some linux configuration.
    * 64bits VMs still cannot be tested because I need to prepare a special image for it.
   
    I will try to fix some of this problems soon, but at least now we are "as we were before" :)
   

cheers!
Esteban

I guess I need to work on the exporter for tables ;)