> On 20 Feb 2017, at 08:00, esteba...@gmail.com wrote: > > 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 > | > |===
I guess I need to work on the exporter for tables ;) > 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
