Esteban's ChangeLog week of 27 February 2017
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
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, estebanlm@gmail.com wrote:
1 March 2017: -------------
* ... and now I made the [case:19783](https://pharo.fogbugz.com/f/cases/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 <https://pharo.fogbugz.com/f/cases/19781>) to fix a problem answering pointers on callbacks. * [case:19782](https://pharo.fogbugz.com/f/cases/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).
Hi Esteban, On Sun, Mar 05, 2017 at 11:00:02PM -0800, estebanlm@gmail.com 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
NICE!!
On 8 Mar 2017, at 20:23, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Esteban,
On Sun, Mar 05, 2017 at 11:00:02PM -0800, estebanlm@gmail.com 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
participants (4)
-
Alistair Grant -
Esteban Lorenzano -
estebanlm@gmail.com -
Max Leske