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
