Esteban's ChangeLog week of 27 February 2017

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Esteban's ChangeLog week of 27 February 2017

EstebanLM
Hello!

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

ChangeLog
=========

3 March 2017:
-------------

*    And now I made +libssh2.so+ compile on linux too :)
   
    I think Iceberg is fixed now for linux, can someone with linux try +vmLatest60+.
   
*    I worked on VM for linux, this time fixing dependencies for libgit2: it was not working because it was trying
    to link libssh2 existing in the system instead the one we provide (a problem with rpath)... I figured out I
    need to add some CMAKE options:
   
    ----
    -DCMAKE_SKIP_BUILD_RPATH=FALSE
    -DCMAKE_INSTALL_RPATH="."
    ----
   
    otherwise +make install+ was ignoring the +-Wl,rpath,.+ configuration. With this it seems to be working,
    but now I have a problem with +libssh2+ compilation.
   
    I'll see this next.
   
*    I took some moments to fix a problem on new UFFI version (0.26): Now, structures use a class variable to keep
    the offset value of a field. So now, instead having an accessor to a field of the form (for example):
   
    ----
    MyStructure>>myField
    ^ handle unsignedLongAt: 42
    ----
   
    ... now you have an accessor of the form:
   
    ----
    MyStructure>>myField
    ^ handle unsignedLongAt: OFFSET_MYFIELD
    ----
   
    this is necesary to allow different platforms to use same structures (because sizes of fields, and in
    consequence of offsets of them inside a stricture are different). This 'offsets' are calculated (as
    structure compiled specs) at first access to +#compiledSpec+ of structure, which usually happens when
    you use it first time... but now always, as [case: 19788](https://pharo.fogbugz.com/f/cases/19788) shows.
   
    Well, now I fixed that :)
   

2 March 2017:
-------------

*    I added a Discord link on [http://pharo.org/community](http://pharo.org/community)... I want to slowly start moving our community there.
    I know Slack is very popular among us this days but Dicords offers some advantages (like no 10k limit on
    messages and a powerful search).
   

1 March 2017:
-------------

*    ... and now I made the [case:19783](https://pharo.fogbugz.com/f/cases/19783), to make SDL2 work on 64bits (it works!) :)
   
*    Yesterday I spent the full day debugging a VM to see why Athens was not working for 64bits and I finally
    figured out the problem was in image and not in VM :P
   
    As a result of the work, I produced this fixes:
   
    * [case:19781](https://pharo.fogbugz.com/f/cases/19781) to fix a problem answering pointers on callbacks.
    * [case:19782](https://pharo.fogbugz.com/f/cases/19782) to actually prepare Athens.
   
    With this two cases, Athens works in 64bits (almost) :)
   
    Now there is a problem in 64bits callbacks that makes the +VGTigerDemo runDemo+ to fail after
    some cycles. Since this problem does not happens on 32bits, I assume there is a problem on how callbacks
    work on 64bits. I'm not working on that (I will work also in migrating SDL2).
   

27 February 2017:
-----------------

*    Well, I spend some time trying to blindly figure out why athens may crash time to time when drawing surfaces,
    basically testing the apprachs [Ronie proposes](http://forum.world.st/Too-frequent-crashes-td4927143i20.html#a4934027).
   
    First approach consists on copying data to not rely on a surface at all. Problem with this is that it involves
    a whole full copy, that causes a lot of GC that pauses a lot the image... so smoothness is gone.
   
    Second approach seems a lot more doable, but I still don't know if it works:
   
    ----
    Form subclass: #AthensCairoSurfaceForm
    instanceVariableNames: 'surface'
    classVariableNames: ''
    package: 'Athens-Cairo'
   
    AthensCairoSurfaceForm>>surface
    ^ surface
   
    AthensCairoSurfaceForm>>surface: anObject
    surface := anObject
   
    AthensCairoSurface>>asForm
    "create a form and copy an image data there"
    self checkSession.
    self flush.
    ^ (AthensCairoSurfaceForm extent: (self width@self height) depth: 32 bits: id)
    surface: self;
    yourself
    ----
   
    this will prevent surfaces to be garbage collected before it's time and seems to be working fine (at least
    in my machine).
   

cheers!
Esteban

Reply | Threaded
Open this post in threaded view
|

Re: Esteban's ChangeLog week of 27 February 2017

EstebanLM
btw, this means both Athens and SDL2 should be working on 64bits :)
I think there is a problem around the tiger demo (and SDL2 examples are not the best...), but if you all can test and give feedback, it would be cool ;)

Esteban

On 6 Mar 2017, at 08:00, [hidden email] wrote:

1 March 2017:
-------------

*    ... and now I made the [case:19783](https://pharo.fogbugz.com/f/cases/19783), to make SDL2 work on 64bits (it works!) :)

*    Yesterday I spent the full day debugging a VM to see why Athens was not working for 64bits and I finally 
   figured out the problem was in image and not in VM :P

   As a result of the work, I produced this fixes: 

   * [case:19781](https://pharo.fogbugz.com/f/cases/19781) to fix a problem answering pointers on callbacks. 
   * [case:19782](https://pharo.fogbugz.com/f/cases/19782) to actually prepare Athens. 

   With this two cases, Athens works in 64bits (almost) :)

   Now there is a problem in 64bits callbacks that makes the +VGTigerDemo runDemo+ to fail after 
   some cycles. Since this problem does not happens on 32bits, I assume there is a problem on how callbacks 
   work on 64bits. I'm not working on that (I will work also in migrating SDL2).

Reply | Threaded
Open this post in threaded view
|

libssh2.so was: Re: Esteban's ChangeLog week of 27 February 2017

alistairgrant
In reply to this post by EstebanLM
Hi Esteban,

On Sun, Mar 05, 2017 at 11:00:02PM -0800, [hidden email] wrote:
> *    And now I made +libssh2.so+ compile on linux too :)
>    
>     I think Iceberg is fixed now for linux, can someone with linux try +vmLatest60+.

I've done some quick ad-hoc testing of this and haven't found any
problems (just refreshing, synchronising and pulling incoming commits).


$ ./pharo --version
5.0-201703081637  Wed Mar  8 17:38:04 UTC 2017 gcc 4.6.3 [Production Spur ITHB VM]
CoInterpreter * VMMaker.oscog-eem.2143 uuid: fe064b6b-e530-4766-837d-799ffe1e8dcd Mar  8 2017
StackToRegisterMappingCogit * VMMaker.oscog-eem.2143 uuid: fe064b6b-e530-4766-837d-799ffe1e8dcd Mar  8 2017
VM: 201703081637 https://github.com/pharo-project/pharo-vm.git $ Date: Wed Mar 8 17:37:29 2017 +0100 $
Plugins: 201703081637 https://github.com/pharo-project/pharo-vm.git $
Linux testing-docker-2c74524e-0bce-41a0-905e-309e215345ee 4.8.12-040812-generic #201612020431 SMP Fri Dec 2 09:33:31 UTC 2016 i686 i686 i386 GNU/Linux
plugin path: /home/alistair/pharo6/pharo/pharo-vm/ [default: /home/alistair/pharo6/pharo/pharo-vm/]


HTH,
Alistair


Reply | Threaded
Open this post in threaded view
|

Re: libssh2.so was: Re: Esteban's ChangeLog week of 27 February 2017

Max Leske
NICE!!

> On 8 Mar 2017, at 20:23, Alistair Grant <[hidden email]> wrote:
>
> Hi Esteban,
>
> On Sun, Mar 05, 2017 at 11:00:02PM -0800, [hidden email] wrote:
>> *    And now I made +libssh2.so+ compile on linux too :)
>>
>>    I think Iceberg is fixed now for linux, can someone with linux try +vmLatest60+.
>
> I've done some quick ad-hoc testing of this and haven't found any
> problems (just refreshing, synchronising and pulling incoming commits).
>
>
> $ ./pharo --version
> 5.0-201703081637  Wed Mar  8 17:38:04 UTC 2017 gcc 4.6.3 [Production Spur ITHB VM]
> CoInterpreter * VMMaker.oscog-eem.2143 uuid: fe064b6b-e530-4766-837d-799ffe1e8dcd Mar  8 2017
> StackToRegisterMappingCogit * VMMaker.oscog-eem.2143 uuid: fe064b6b-e530-4766-837d-799ffe1e8dcd Mar  8 2017
> VM: 201703081637 https://github.com/pharo-project/pharo-vm.git $ Date: Wed Mar 8 17:37:29 2017 +0100 $
> Plugins: 201703081637 https://github.com/pharo-project/pharo-vm.git $
> Linux testing-docker-2c74524e-0bce-41a0-905e-309e215345ee 4.8.12-040812-generic #201612020431 SMP Fri Dec 2 09:33:31 UTC 2016 i686 i686 i386 GNU/Linux
> plugin path: /home/alistair/pharo6/pharo/pharo-vm/ [default: /home/alistair/pharo6/pharo/pharo-vm/]
>
>
> HTH,
> Alistair
>
>