November 2017 - Pharo-dev - lists.pharo.org

Esteban's ChangeLog week of 20 November 2017

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 20 November 2017 to 26 November 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=20/11/2017&to=26/11/2017 ChangeLog ========= 24 November 2017: ----------------- * I spent some time working on the health of CI for some projects. So far, I restored the green status to: * [Tonel](https://github.com/pharo-vcs/tonel) * [Libgit2-bindings](https://github.com/pharo-vcs/libgit2-pharo-bindings) Now I need to work on the hardest (and most important) one: [Iceberg](https://github.com/pharo-vcs/iceberg) Some of this broken status were because we needed a functionality on smalltalkCI who was missing: the ability to execute some scripts before loading, and we need to cleanup the images (since I am testing things that are already there). Now, thanks to Fabio is fixed so we can move on. 23 November 2017: ----------------- * after spend last two days fixing bugs on the parser, I finally could integrate * Iceberg 0.6.3 * Tonel 1.0.4 * Libgit2-bindings 1.0 Into Pharo 7.0a. Now... I need to prepare an update to backport to Pharo 6.1. 21 November 2017: ----------------- * I released iceberg version [0.6.3](https://github.com/pharo-vcs/iceberg/releases/tag/v0.6.3) . And I released also tonel version [1.0.4](https://github.com/pharo-vcs/tonel/releases/tag/v1.0.4) Along, that will bring a better iceberg for everybody ;) (now I need to integrate to Pharo 7.0a and backport to 6.1) 20 November 2017: ----------------- * Back from holidays. During my freetime, I worked on Iceberg a bit... there was an ugly bug, [commit&push can lead to lose data](https://github.com/pharo-vcs/iceberg/issues/516) and fix it took more time than expected. Now is done, I will prepare a release today with some other issues. cheers! Esteban

Nov. 27, 2017

Would it be possible to also launch templates in PharoLauncher?

by Mariano Martinez Peck

Hi guys, Thank you Christophe for continue pushing this useful tool! One small request which might be easy to do... Quite frequently I want to do something and re-save an image I have previosuly saved as a custom template (under Local root tree). Right now what I have to do so: 1) Make a new image from that template 2) remove template 2) do the thing and save the opened image. 3) go back to laucher and save that image as a new template (with the same name of the one I deleted) 4) delete the created image All that would be simplified if I could also launch my local templates. Is there any reason why is that not allowed? (at least for Local tree). Thanks in advance, -- Mariano http://marianopeck.wordpress.com

Nov. 27, 2017

Re: [Pharo-dev] Bloc Feedback

by Sean P. DeNigris

Aliaksei Syrel wrote > No, they don't. You have a very old version of Gt-Examples :) How do I get an image with the behavior in the video? I documented my steps. Where am I going wrong? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 26, 2017

Re: [Pharo-dev] Bloc Feedback

by Sean P. DeNigris

Aliaksei Syrel wrote > There are so many complains about absence of class comments, but no one > reads them. Looks like it is easier to remove experimental examples > completely :) I don't understand. I specifically skipped reporting BlExperimentalExamples failures because of that comment. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 26, 2017

Re: [Pharo-dev] Pharo 32bit on debian 9 stretch 64bit

by js16r7b4

CyrilFerlicot wrote > I would like to use Pharo on a Debian 9, 64bits. > ... > Does someone know what should I do to get the right dependencies? Hi Cyril, >From a fresh debian live CD (xfce) running in a virtual machine user@debian:~$ uname -a Linux debian 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64 GNU/Linux All I did that seemed really required: sudo apt-get update sudo apt-get install libx11-6:i386 sudo apt-get install libgl1-mesa-glx:i386 sudo apt-get install libfontconfig1:i386 Then I downloaded the MOOC specific version of Pharo + the latest 6.1 version (32bit) available at: https://pharo.org/gnu-linux-installation Once I extracted both archives, I copied the Pharo 5.0 shared files in the Pharo 6.1 shared folder. user@debian:~/pharo6.1/shared$ ls Pharo5.0.changes Pharo6.1.changes PharoV50.sources Pharo5.0.image Pharo6.1.image PharoV60.sources ...switched back to the root of the pharo6.1 directory, ran the script that launches pharo... user@debian:~/pharo6.1$ ls bin icons pharo README.txt shared user@debian:~/pharo6.1$ ./pharo Pharo asked me which image I wanted; I chose the Pharo5.0.image for the MOOC and voila! The smell of victory? Just to double check I ran the unit tests for the class ZdcSecureSocketStreamTests -- All green. Long story short, a pre-compiled libssl, libcrypto and a whole bunch of other libraries are included with the pharo6.1 download. user@debian:~/pharo6.1/bin/lib/pharo/5.0-201707201942$ ls AioPlugin.so libgit2.so.25 RePlugin.so B3DAcceleratorPlugin.so libSDL2-2.0.so.0 SqueakSSL.so EventsHandlerPlugin.so libSDL2-2.0.so.0.4.1 SurfacePlugin.so FT2Plugin.so libSDL2.so vm-display-fbdev.so InternetConfigPlugin.so libssh2.so vm-display-null.so JPEGReaderPlugin.so libssh2.so.1 vm-display-X11.so JPEGReadWriter2Plugin.so libssh2.so.1.0.1 vm-sound-ALSA.so libcrypto.so.1.0.0 libssl.so vm-sound-null.so libgit2.so libssl.so.1.0.0 vm-sound-OSS.so libgit2.so.0.25.1 pharo And the problematic ones seem to be effectively used user@debian:~/pharo6.1$ lsof | grep libssl.so.1.0.0 pharo 2893 user mem REG 0,20 463137 106008 /home/user/pharo6.1/bin/lib/pharo/5.0-201707201942/libssl.so.1.0.0 pharo 2893 2924 user mem REG 0,20 463137 106008 /home/user/pharo6.1/bin/lib/pharo/5.0-201707201942/libssl.so.1.0.0 user@debian:~$ lsof | grep libcrypto.so.1.0.0 pharo 2893 user mem REG 0,20 2157708 106036 /home/user/pharo6.1/bin/lib/pharo/5.0-201707201942/libcrypto.so.1.0.0 pharo 2893 2924 user mem REG 0,20 2157708 106036 /home/user/pharo6.1/bin/lib/pharo/5.0-201707201942/libcrypto.so.1.0.0 Give it another shot! :-) -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 26, 2017

VoxelSpace

by Pavel Krivanek

Hi, I tried to port and optimize the extremely simple VoxelSpace engine into Pharo. https://github.com/pavel-krivanek/VoxelSpace How to load Metacello new baseline: 'VoxelSpace'; repository: 'github://pavel-krivanek/VoxelSpace/src'; load. How to run Copy maps into the image directory and then evaluate: VoxelSpaceMorph new openInWindow. [image: VloÅ¾enÃ½ obrÃ¡zek 2] No external library is required. If you have some next ideas how to improve the rendering performace with the same image quality, please let me know. Cheers, -- Pavel

Nov. 26, 2017

Re: [Pharo-dev] Bloc Feedback

by Sean P. DeNigris

Tudor Girba-2 wrote > I am not sure I understand What I mean is that I followed that process before when I reported all those bugs and if IIUC the responses I wasted my time because I was using old versions and reporting bugs that had already been fixed. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 26, 2017

Re: [Pharo-dev] Pharo 64bit VM and image for 6.1 on CentOS 7

by phil＠highoctane.be

I have found the http://files.pharo.org/get-files/61/ with a 64 bit version but the VM I have on CentOS is making bad artefacts on the text. [image: Inline image 1] Phil On Sun, Nov 26, 2017 at 10:22 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I have installed the rpms provided by Norbert and Holger. > > Now, I have a working 60 in 64 bit. > > But I'd like to get a 61 in 64 bit. > > I can rebuild the rpms from source and currently stand at version 1.13.1 > (seems to be an update). > > I also find it annoying to not have an image provided, we have the 60 > sources. I can understand why but this requires one to go through the > download of a 64 bit image from the site. On servers that is a pain to do > vs yum install pharo6-64-60-image for example. > > Also, I noticed that the MATE desktop I use requires icons from > /usr/share/icons/hicolor/scalable/apps and there is no svg in there. > > I also wonder how we can se the mimetype of image files appropriately so > that a click on a .image would open the pharo6-64-ui on it. > > Is there a 61 64 bit image? > Is there a VM compatible with that image? > > I would like to do a software collection for pharo so that we could have a > software collection for 60, one for 61, one for 70 etc, and they would all > be cleanly separated. > > Usage like: scl enable pharo61 bash > > Phil >

Nov. 26, 2017

Pharo 64bit VM and image for 6.1 on CentOS 7

by phil＠highoctane.be

I have installed the rpms provided by Norbert and Holger. Now, I have a working 60 in 64 bit. But I'd like to get a 61 in 64 bit. I can rebuild the rpms from source and currently stand at version 1.13.1 (seems to be an update). I also find it annoying to not have an image provided, we have the 60 sources. I can understand why but this requires one to go through the download of a 64 bit image from the site. On servers that is a pain to do vs yum install pharo6-64-60-image for example. Also, I noticed that the MATE desktop I use requires icons from /usr/share/icons/hicolor/scalable/apps and there is no svg in there. I also wonder how we can se the mimetype of image files appropriately so that a click on a .image would open the pharo6-64-ui on it. Is there a 61 64 bit image? Is there a VM compatible with that image? I would like to do a software collection for pharo so that we could have a software collection for 60, one for 61, one for 70 etc, and they would all be cleanly separated. Usage like: scl enable pharo61 bash Phil

Nov. 26, 2017

Re: [Pharo-dev] [Vm-dev] FFI Struct Argument Pass By Value Fails on Mac 64 bit

by Stephane Ducasse

It would be wonderful! On Sun, Nov 26, 2017 at 5:24 PM, Todd Blanchard <tblanchard(a)mac.com> wrote: > i'm getting the idea that we should probably write a test suite/library for > FFI > > On Nov 24, 2017, at 12:54 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > > On 24 November 2017 at 13:16, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> On 22 November 2017 at 21:59, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> >>> >>> On 22 November 2017 at 13:38, Todd Blanchard <tblanchard(a)mac.com> wrote: >>>> >>>> >>>> I've been trying to track this down for a couple weeks now. >>>> >>>> I have concluded that structs passed by value to functions on the 64 bit >>>> VM are not properly populated. The struct's memory is all zero'd. >>>> >>>> I found this while trying to work with LibClang and found that functions >>>> that fetched code locations from code ranges always returned invalid zero'd >>>> locations. After spending some time with lldb I have traced the problem >>>> into the native code and found that the argument is not correct. >>>> >>>> I've carved out the wee bit of clang to reproduce this in a tiny >>>> library. >>>> >>>> The gist of it is below and the entire file is included. Basically the >>>> struct passed to the function clang_getRangeStart is zero'd memory >>>> regardless of the data I send from the image side. >>>> >>>> The build command I used on sierra is clang -shared -undefined >>>> dynamic_lookup -o microclang.dylib microclang.c >>> >>> >>> On Ubuntu 16.04 I used... >>> $ clang -shared -fPIC -o libmicroclang.so microclang.c >>> >>> $ clang test.c -L. -l microclang >>> test.c:6:53: error: no member named 'begin_int_data' in >>> 'CXSourceLocation' >>> if(clang_getRangeStart(clang_getArbitraryRange()).begin_int_data == 0) >>> >>> I presume you meant... >>> if(clang_getRangeStart(clang_getArbitraryRange()).int_data == 0) >>> so correcting and continuing... >>> >>> $ clang test.c -L. -l microclang >>> $ LD_LIBRARY_PATH=. ./a.out >>> That failed >>> >>> So I'm not sure how to proceed. >>> I was expecting that would work while Pharo failed. >>> >>> Now interestingly... >>> $ clang test.c microlang.c >>> $ ./a.out >>> That worked >>> >>> >>> So it seems a similar problem exists outside our FFI. >>> >>> cheers -ben >>> >>> P.S. I refactored you code to extract a header file (attached) >> >> >> The issue is still beyond my ken, but I've made some progress towards >> isolating/understanding the issue. >> Attached zip exploded here for easy reference... >> >> >> ___microlang.h___ >> typedef unsigned uintptr_t; >> >> typedef struct { >> const void *ptr_data[2]; >> } CXSourceRange_; >> >> CXSourceRange_ clang_getArbitraryRange_(); >> int clang_getRangeEnd_(CXSourceRange_ range); >> >> >> >> ___microclang.c___ >> #include "microclang.h" >> const char* libraryString = "library_pointer"; >> >> CXSourceRange_ clang_getArbitraryRange_() >> { CXSourceRange_ range = {0}; >> range.ptr_data[0] = (void*)libraryString; >> return range; >> } >> >> int clang_getRangeEnd_(CXSourceRange_ range) >> { // Special decoding for CXSourceLocations for CXLoadedDiagnostics. >> if ((uintptr_t)range.ptr_data[0] & 0x1) >> { return 0; } >> else >> { return 1; } >> } >> >> >> >> >> ___test.c___ >> #include <stdio.h> >> #include "microclang.h" >> const char* localString = "local_pointer"; >> >> void test( CXSourceRange_ range, char *note ) >> { int result = clang_getRangeEnd_(range); >> if(result == 0) >> { printf("That failed (%s)\n", note); } >> else >> { printf("That worked (%s)\n", note); } >> } >> >> int main() >> { CXSourceRange_ range1 = clang_getArbitraryRange_(); >> test(range1, "library string"); >> >> CXSourceRange_ range2 = {0}; >> range2.ptr_data[0] = (void*)localString; >> test(range2, "local string"); >> } >> >> >> >> ___Makefile___ >> default: clean static shared >> >> clean: >> rm -f *so *App >> @echo >> >> shared: >> clang -g -o libmicroclang.so -shared -fPIC microclang.c >> clang -g -o sharedApp test.c -L. -lmicroclang >> LD_LIBRARY_PATH=. ./sharedApp >> @echo >> >> static: >> clang -g -o staticApp test.c microclang.c >> ./staticApp >> @echo >> >> >> >> Now running... >> $ make > report >> >> gives... >> ___report___ >> rm -f *so *App >> >> clang -g -o staticApp test.c microclang.c >> ./staticApp >> That worked (library string) >> That worked (local string) >> >> clang -g -o libmicroclang.so -shared -fPIC microclang.c >> clang -g -o sharedApp test.c -L. -lmicroclang >> LD_LIBRARY_PATH=. ./sharedApp >> That failed (library string) >> That worked (local string) > > > > Further simplification dealing *only* with strings (see attached > sharedLibString.zip) > (also attached is clang3.zip as a step along the way) > > ___microclang.c___ > typedef unsigned uintptr_t; > const char* myLibraryString = "library_pointer"; > > const char * lib_getLibraryString() > { return myLibraryString; > } > > int lib_testString( const char *aString ) > { unsigned test = (uintptr_t)aString & 0x1; > printf("\n test=%d, aString-->%d\n", test, (uintptr_t)aString); > if (test) > { return 0; } > else > { return 1; } > } > > > ___test.c___ > #include <stdio.h> > int lib_testString( const char *aString ); > const char *lib_getLibraryString(); > const char *localString = "local_pointer"; > > void test( int result, char *note ) > { if(result == 0) > { printf("That failed (%s)\n", note); } > else > { printf("That worked (%s)\n", note); } > } > > int main() > { const char * libraryString = lib_getLibraryString(); > test(lib_testString(libraryString), "library string"); > > test(lib_testString(localString), "local string"); > } > > > $ make > report > > ___report___ > rm -f *so *App > > clang -g -o staticApp test.c microclang.c > ./staticApp > > test=0, aString-->4196150 > That worked (library string) > > test=0, aString-->4196068 > That worked (local string) > > clang -g -o libmicroclang.so -shared -fPIC microclang.c > clang -g -o sharedApp test.c -L. -lmicroclang > LD_LIBRARY_PATH=. ./sharedApp > > test=1, aString-->-792512599 > That failed (library string) > > test=0, aString-->4196484 > That worked (local string) > > > cheers -ben > > <sharedLibString.zip><clang3.zip> > >

Nov. 26, 2017