June 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 5, seaside 3.2 and magritte 3

by Paul DeBruicker

The Seaside HTML5 package was eliminated in Seaside 3.2 because it switched to HTML5 by default. How are you loading Magritte? There is a Seaside specific list here: http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside you should join and send your Seaside related questions to. Hope this helps Paul francescoagati wrote > Hi, > i have try yo use magritte 3 and seaside 3.2 inside pharo 5. With seaside > works all good. But when i try to install magritte 3. Magritte say that > need the seaside html5 canvas package. > > There is compatibility between magritte3 and seaside 3.2 on pharo 5? > Thanks > Francesco -- View this message in context: http://forum.world.st/Pharo-5-seaside-3-2-and-magritte-3-tp4902903p4903091.… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 24, 2016

Better color contrast for class extensions in dark theme

by Offray Vladimir Luna CÃ¡rdenas

Hi :), I'm enjoying the Pharo Dark Theme a lot (in fact my tweet on a 10 minutes hack about it[1] have more impact that the tweets with month and a half work behind for Panama Papers[2]... that's life :-P), but I still have some suggestions on color contrast, particularly when you're doing class extensions and the light gray over blue makes the reading really difficult (see screenshot at bottom). [1] https://twitter.com/offrayLC/status/738828257680850944 [2] https://twitter.com/offrayLC/status/729069808684285953 Hope this helps to improve this theme. Cheers, Offray

June 24, 2016

Re: [Pharo-users] The myth of a small deployment image using metacello

by Stephan Eggermont

On 24/06/16 15:28, Norbert Hartl wrote: > The main problem to me is that the maintainer of the configuration > defines the granularity of pieces to load forcing me to do stupid > workarounds to achieve what I want. Who else should do that? Dependency management with Metacello is uni-directional. I agree that it is important to define those dependencies as specific as possible, and have to recognize that they will always err on the side of loading too much. Please update BootstrapMagritte to be more granular. I've only used it with lots of dependencies. Stephan

June 24, 2016

Re: [Pharo-users] Styling a Pharo UI application

by Dimitris Chloupis

I dont see what Bloc and Bric have to do with sexiness. The only thing I see is Athens which Morphic already has access to. To be truly custom GUI friendly the API needs to at least offer some GPU acceleration and access to a myriad of graphical effects. I have not seen anything in Bloc and Bric that would make me abandon Morphic. Actually the one thing that I am waiting for with some excitement is SDL support which would make things easier for someone like that loves to create custom GUIs. On Fri, Jun 24, 2016 at 11:51 AM Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Itâs kind of a pity that to make something sexy we still have to use > Morphicâ¦ Hopefully this will change with Bloc & Bric > > On 24 Jun 2016, at 10:25, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > In my case is just personal preference none the less Spec has ways to wrap > morphs to Spec widgets so you should be able to build Spec widgets using > Morphic for more flexibility. You dont have to decide to use Spec or > Morphic, you can use both. Last time I checked Spec came with examples on > how to do this and I think Spec docs also mention this. > > Also I think Athens is very good at rendering text (because its wraps > around the Cairo library) , so maybe you can take advantage of that though > I suspect Bloc may be even better choice in this case because it is based > on Athens and it is fully compatible with Morphic. > > There is also a text widget that is being build that is much more flexible > with handling text > > https://vimeo.com/67752734 > > Be advised though that both Bloc and TxText are far from finished > > On Fri, Jun 24, 2016 at 1:28 AM Tommaso Dal Sasso < > tommaso.dalsasso(a)gmail.com> wrote: > >> Personally I don't dislike the Spec approach, but the API still looks not >> expressive enough for doing things beyond the standard. >> >> I am deepening my knowledge of Morphic now, thanks for your answer! >> Tommaso >> >> >> >> On 22/06/16 17:11, Dimitris Chloupis wrote: >> >> Documentation is always a problem. >> >> I dont use Spec because I dont like it , but I use Morphic for my project >> ChronosManager. I do some "styling" for example use different fonts for >> different labels , different sizes , I format strings to time stamps and >> even offer easy ways for user to change them without modifying the whole >> string. >> >> You can do a lot with Morphic, though I have not played with layout stuff >> since this GUI is static and image (PNGs) based but yeah Morphic can do >> that as well. My project is on Catalog browser and it has class comments , >> dont know if this exactly what you want but it may be a good start. >> >> Obviously there are a ton of things you can do with a web page that >> Morphic will not offer you out of the box. >> >> You can use Html as the front end / GUI and keep Pharo as the backend, >> thats how most web apps made with Pharo work. This you get the full power >> of Html/JS and Pharo. Seaside has classes that map html to pharo methods so >> you dont have to write html and js, and also I remember a pharo library >> dealing with CSS. >> >> Another option is to use a GUI API like QT , I have tried this with my >> python bridge and it works at least on a very basic level, again similar >> recipe to the above solution. >> >> But yeah if you are not too demanding I think Morphic will serve you >> well. Personally I only like Morphic , its the only GUI API that does not >> kill my inner child. >> >> On Wed, Jun 22, 2016 at 5:44 PM Tommaso Dal Sasso < >> tommaso.dalsasso(a)gmail.com> wrote: >> >>> Hello everybody, >>> >>> I have a question about the UI toolkits available for Pharo. I already >>> asked something about this on Slack, but since I saw that there was a >>> recent discussion about UI in the mailing list, I think this is a better >>> place to discuss the matter. >>> >>> I am writing an application for Pharo where I am displaying some >>> structured text. The structure is similar to the one of a web page: A >>> main title with a list of paragraphs, where each paragraph has a title >>> and a description. >>> >>> What I would like to do is to format the text to present the contents in >>> a meaningful way: For example, I would like a bigger font for the title, >>> and change the background of the text, to give a better separation >>> between the paragraphs. Basically I would like to manipulate and display >>> my contents as I would do in a web page. >>> >>> To write UI widgets I usually use Spec, but I found that going beyond >>> easy formatting (e.g. bold text and emphasis) is harder than I thought. >>> I saw there were discussion about the styling text and the role of the >>> theme class, using TextStyle but that part is not really documented. >>> >>> So far, the easiest way to solve my problem seems to be to use Morphic >>> to display the contents as I want it, and then include my widget in my >>> spec application. >>> >>> Do you have any suggestions about how to do that? I think that styling >>> the UI widgets is an important part of the application development, but >>> it is really hard to find documentation about this. >>> >>> Thanks, have a nice day! >>> Tommaso >>> >>> >>> >> >

June 24, 2016

Re: [Pharo-users] [Pharo-dev] catalog will be down 1hr

by Serge Stinckwich

When informations in the catalog are updated ? I made some modifications yesterday and apparently they didn't appear, but maybe I just have to wait more :-) On 6/21/16, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > I will apply some updates to catalog (backend, they will not be visible) > > cheers, > Esteban > > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

June 24, 2016

The myth of a small deployment image using metacello

by Norbert Hartl

I have a seaside project that will be installed in a typical fashion headless on a server somewhere on the net. The project is in its final stage so I started to care about the size of the image. Or better: The size of the image is not my main concern but the number of packages installed. The less packages you load the better it is, it is that simple. This time I encountered a problem that I often see but this particular one explains in a very good way that how we use metacello can be improved. In my project I load only Seaside-Core. This has the advantage of loading far less packages and I don't have the need to remove a bunch of registered web applications that registered themselves when being loaded. I make use of a bootstrap template bought somewhere on the net. I use magritte a lot so I was happy to see that there is a package called BootstrapMagritte. The package extends some magritte ui classes and overwrites some methods to add specific classes to HTML tags. Basically not very much code. What happended after I added the package as a dependency to my own project you can see here in the load directive of metacello linear load : explicit load : 0.2.3 [ConfigurationOfBootstrapMagritte] linear load : 0.2.3 [ConfigurationOfBootstrapMagritte] linear load : 3.5.0 [ConfigurationOfMagritte3] linear load : 1.1.0 [ConfigurationOfMagritteGlamourForPharo40] load : Glamour-Presentations.issue_1126-SeanDeNigris.178 load : Glamour-Morphic-Renderer.issue_1126-SeanDeNigris.325 explicit load : 3.1.5 [ConfigurationOfSeaside3] linear load : 3.1.5 [ConfigurationOfSeaside3] explicit load : 0.26 [ConfigurationOfParasol] linear load : 0.26 [ConfigurationOfParasol] linear load : 3.2.0 [ConfigurationOfSeaside3] load : Seaside-Tests-REST-Core-EstebanMaringolo.34 This is wrong in so many ways. I load a little extensions to my web application and end up loading _all_ of seaside which loads beach parasol (a ui testing framework), _all_ of magritte which in turn loads glamour packages (a ui toolkit). So at this point I think WTF? Why does this happen? Because the "default" group in many projects contains all of the packages and dependencies of the project. I thought at first this is wrong but in the meantime I think it is right. Whenever a configuration is loaded without additional parameters the "default" group gets loaded. This is the best scenario for newcomers (e.g. using the catalog to load). They don't know better but want to see what the package has to offer. Fine, we should support that. For managing projects this gets annoying really quick like you can see above. It would always load all dependencies and all packages of every project that your own project depends. This is a no-go. To circumvent this a lot of people add a "core" group to their configurations (loading the essential parts). This is great because in my own project I can add a dependency to a project and load only the "core" group. This works if the dependency chain is not very long (at best it works in depth 1 ;) ). As soon as a project has two interesting groups the problem gets worse. A good example is magritte. It is useful for describing your model as well as it contains useful seaside components. The moment I add a dependency from my model package to magritte seaside I know it is wrong. I find myself sometimes duplicating dependencies just to mitigate the effect. I do something like project: 'Magritte3Seaside' with: [ spec className: #ConfigurationOfMagritte3; versionString: #'stable'; loads: #('Seaside' ); repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/' ]; project: 'Magritte3Core' with: [ spec className: #ConfigurationOfMagritte3; versionString: #'stable'; loads: #('Core' ); repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/' ]; andâ¦ package: #'MyProject-Model-Core' with: [ spec requires: #( 'Magritte3Core' ). ]; package: #'MyProject-UI-Core' with: [ spec requires: #( 'Seaside3' 'Magritte3Seaside' 'BootstrapMagritte' ). ]; just to be able to put the right dependencies. But this way is cumbersome to do and not support by tools like Versionner. The main problem to me is that the maintainer of the configuration defines the granularity of pieces to load forcing me to do stupid workarounds to achieve what I want. To me the problem is that the separation is not done properly. I think the logic of having loads() in the baseline and a pure string like "Magritte3Core" in the dependency spec is reversed. It should be project: 'Magritte3' with: [ spec className: #ConfigurationOfMagritte3; versionString: #'stable'; repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/' ]; andâ¦ package: #'MyProject-Model-Core' with: [ spec requires: #( 'Magritte3:Core' ). ]; package: #'MyProject-UI-Core' with: [ spec requires: #( 'Seaside3' 'Magritte3:Seaside' 'BootstrapMagritte' ). ]; Note the "Magritte3:Core" in the dependency spec. The meaning is that there is a dependency to Magritte3 and group Core. This way dependencies can be properly aligned. Or are there other way to deal with it? What do you think? Norbert

June 24, 2016

Re: [Pharo-users] Coral?

by Valentin Ryckewaert

Hi, if there is any documentation I didn't see it sorry :( The syntax may change in the future) :) 2016-06-24 14:50 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi, thanks. > > Is there any documentation left? Like what is the syntax and so on? > > Cheers. > Uko > > On 24 Jun 2016, at 13:24, Valentin Ryckewaert < > valentin.ryckewaert(a)gmail.com> wrote: > > Hello, > > I'm the trainee responsible of it, i'm currently working on it by > searching the points of interaction between Pharo and his files(changeslog > etc...) to block them. > You can find my work on > Metacello new > smalltalkhubUser: 'Uryon' project: 'FilePolicy'; > configuration: 'Coral'; > version: #development; > onConflictUseIncoming; > load. > > 2016-06-24 11:23 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > >> Hi, >> >> what is the status of Coral? Iâve heard that someone is supposed to work >> on it, but even the main webpage I know is down: >> http://rmod.lille.inria.fr/coral/ >> >> Uko >> > > >

June 24, 2016

Re: [Pharo-users] Coral?

by Yuriy Tymchuk

Hi, thanks. Is there any documentation left? Like what is the syntax and so on? Cheers. Uko > On 24 Jun 2016, at 13:24, Valentin Ryckewaert <valentin.ryckewaert(a)gmail.com> wrote: > > Hello, > > I'm the trainee responsible of it, i'm currently working on it by searching the points of interaction between Pharo and his files(changeslog etc...) to block them. > You can find my work on > Metacello new > smalltalkhubUser: 'Uryon' project: 'FilePolicy'; > configuration: 'Coral'; > version: #development; > onConflictUseIncoming; > load. > > 2016-06-24 11:23 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: > Hi, > > what is the status of Coral? Iâve heard that someone is supposed to work on it, but even the main webpage I know is down: http://rmod.lille.inria.fr/coral/ <http://rmod.lille.inria.fr/coral/> > > Uko >

June 24, 2016

Re: [Pharo-users] Pharo crashing under new Fedora 24 (64bits plus 32bits libraries)

by Esteban Lorenzano

is a 64bits system? then maybe you want to give it a try to 64bits image/vm (again, not everything will work, but is good to have a test :P) http://files.pharo.org/get-files/60/pharo-64.zip https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_linux64x64… thanks, Esteban > On 24 Jun 2016, at 14:12, casimiro barreto <casimiro.barreto(a)gmail.com> wrote: > > It is a Samsung with NVIDIA but Optimus ... And primusrun won't work because of dynamically linked libraries.... > > Em 23/06/2016 23:27, "Renaud de Villemeur" <renaud.devillemeur(a)free.fr <mailto:renaud.devillemeur@free.fr>> escreveu: > Hi. > > Pharo5 can run properly on Fedora 24, with Seaside3.2, OpenGL, or default image. > What kind of graphic card do you have ? Is it a NVidia ? The default driver in Fedora, "Nouveau", is 64 bit only. I had to install the proprietary NVidia driver lib in 32 bit to be able to run pharo, They are still from fedora 23, as rpm-fusion didn't update its repo yet (xorg-x11-drv-nvidia-cuda-358.16-2.fc23.i686 and xorg-x11-drv-nvidia-libs-358.16-2.fc23.i686). > > Here is a list of all 32 bits library I have. My system is not a fresh install, but Pharo is the only 32 bit apps, so I guess this list is quite accurate. Can you check if you have a similar list on your system ? > $ rpm -qa | grep i686 | grep -v devel | sort -u > alsa-lib-1.1.1-1.fc24.i686 > bzip2-libs-1.0.6-20.fc24.i686 > cairo-1.14.6-1.fc24.i686 > clang-libs-3.8.0-1.fc24.i686 > elfutils-libelf-0.166-2.fc24.i686 > expat-2.1.1-2.fc24.i686 > fontconfig-2.11.94-6.fc24.i686 > freetype-2.6.3-2.fc24.i686 > gamin-0.1.10-22.fc24.i686 > glib2-2.48.1-1.fc24.i686 > glibc-2.23.1-8.fc24.i686 > keyutils-libs-1.5.9-8.fc24.i686 > krb5-libs-1.14.1-6.fc24.i686 > libcom_err-1.42.13-4.fc24.i686 > libdrm-2.4.68-1.fc24.i686 > libedit-3.1-14.20150325cvs.fc24.i686 > libffi-3.1-9.fc24.i686 > libgcc-6.1.1-2.fc24.i686 > libICE-1.0.9-5.fc24.i686 > libpciaccess-0.13.4-3.fc24.i686 > libpng-1.6.23-1.fc24.i686 > libselinux-2.5-3.fc24.i686 > libsepol-2.5-3.fc24.i686 > libSM-1.2.2-4.fc24.i686 > libssh2-1.7.0-5.fc24.i686 > libstdc++-6.1.1-2.fc24.i686 > libuuid-2.28-3.fc24.i686 > libvdpau-1.1.1-3.fc24.i686 > libverto-0.2.6-6.fc24.i686 > libwayland-client-1.10.0-1.fc24.i686 > libwayland-server-1.10.0-1.fc24.i686 > libX11-1.6.3-3.fc24.i686 > libXau-1.0.8-6.fc24.i686 > libxcb-1.11.1-2.fc24.i686 > libXdamage-1.1.4-8.fc24.i686 > libXext-1.3.3-4.fc24.i686 > libXfixes-5.0.2-2.fc24.i686 > libXrender-0.9.9-3.fc24.i686 > libxshmfence-1.2-3.fc24.i686 > libXxf86vm-1.1.4-3.fc24.i686 > llvm-libs-3.8.0-1.fc24.i686 > mesa-libEGL-11.2.2-2.20160614.fc24.i686 > mesa-libgbm-11.2.2-2.20160614.fc24.i686 > mesa-libGL-11.2.2-2.20160614.fc24.i686 > mesa-libglapi-11.2.2-2.20160614.fc24.i686 > mesa-libOpenCL-11.2.2-2.20160614.fc24.i686 > ncurses-libs-6.0-5.20160116.fc24.i686 > nss-softokn-freebl-3.24.0-1.0.fc24.i686 > ocl-icd-2.2.8-3.git20151217.0122332.fc24.i686 > opencl-utils-1-2.svn16.fc24.i686 > openssl-libs-1.0.2h-1.fc24.i686 > pcre-8.39-2.fc24.i686 > pixman-0.34.0-2.fc24.i686 > pkgconfig-0.29-2.fc24.i686 > pyzy-0.1.0-12.fc24.i686 > readline-6.3-8.fc24.i686 > SDL2-2.0.4-4.fc24.i686 > sqlite-libs-3.11.0-3.fc24.i686 > xorg-x11-drv-nvidia-cuda-358.16-2.fc23.i686 > xorg-x11-drv-nvidia-libs-358.16-2.fc23.i686 > xz-libs-5.2.2-2.fc24.i686 > zlib-1.2.8-10.fc24.i686 > > and for display: > > $ ldd vm-display-X11 > linux-gate.so.1 (0xf778f000) > libpthread.so.0 => /lib/libpthread.so.0 (0xf7729000) > libGL.so.1 => /usr/lib/nvidia/libGL.so.1 (0xf7622000) > libX11.so.6 => /lib/libX11.so.6 (0xf74e1000) > libc.so.6 => /lib/libc.so.6 (0xf7313000) > /lib/ld-linux.so.2 (0x565d0000) > libnvidia-tls.so.358.16 => /usr/lib/nvidia/tls/libnvidia-tls.so.358.16 (0xf730d000) > libnvidia-glcore.so.358.16 => /usr/lib/nvidia/libnvidia-glcore.so.358.16 (0xf50b8000) > libXext.so.6 => /lib/libXext.so.6 (0xf50a4000) > libdl.so.2 => /lib/libdl.so.2 (0xf509f000) > libxcb.so.1 => /lib/libxcb.so.1 (0xf5079000) > libm.so.6 => /lib/libm.so.6 (0xf5022000) > libXau.so.6 => /lib/libXau.so.6 (0xf501e000) > > Beware that under Fedora, SSL in Pharo is not available. I think that's a known issue, due to library mismatch: Pharo is compiled with openssl v1.0.0, while Fedora use v1.0.2h. > $ ldd libSqueakSSL.so > linux-gate.so.1 (0xf7754000) > libssl.so.1.0.0 => not found > libc.so.6 => /lib/libc.so.6 (0xf7551000) > /lib/ld-linux.so.2 (0x5659f000) > > $ rpm -qa | grep ssl | grep i686 | grep -v devel > openssl-libs-1.0.2h-1.fc24.i686 > > $ rpm -ql openssl-libs.i686 | grep libssl | grep -v hmac > /usr/lib/libssl.so.1.0.2h > /usr/lib/libssl.so.10 > > Regards > Renaud > > > > 2016-06-23 16:31 GMT-04:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > Iâm sorry, but this is not enough informationâ¦ normally crash should let a crash.dmp fileâ¦ also a way to reproduce the problem would be coolâ¦ a description of what you are doing, etc. > > cheers, > Esteban > > >> On 23 Jun 2016, at 22:10, Casimiro - GMAIL <casimiro.barreto(a)gmail.com <mailto:casimiro.barreto@gmail.com>> wrote: >> >> Pharo 5 crashes. VM does a SIGSEGV 0x00000000 at start >> >> Running GDB I got: >> >> (gdb) run >> Starting program: /home/CdAB63/Downloads/pharo5.0/bin/pharo >> Missing separate debuginfos, use: dnf debuginfo-install glibc-2.23.1-8.fc24.i686 >> [Thread debugging using libthread_db enabled] >> Using host libthread_db library "/lib64/libthread_db.so.1". >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x00000000 in ?? () >> (gdb) backtrace full >> #0 0x00000000 in ?? () >> No symbol table info available. >> #1 0xf7f3dd7e in __pthread_once_slow () from /lib/libpthread.so.0 >> No symbol table info available. >> #2 0xf7aa9c05 in ?? () from /lib/libGL.so.1 >> No symbol table info available. >> #3 0xf7a722ab in ?? () from /lib/libGL.so.1 >> No symbol table info available. >> #4 0xf7fe8da1 in call_init.part () from /lib/ld-linux.so.2 >> No symbol table info available. >> #5 0xf7fe8f00 in _dl_init () from /lib/ld-linux.so.2 >> No symbol table info available. >> #6 0xf7fed80f in dl_open_worker () from /lib/ld-linux.so.2 >> No symbol table info available. >> #7 0xf7fe8c91 in _dl_catch_error () from /lib/ld-linux.so.2 >> No symbol table info available. >> #8 0xf7fecd89 in _dl_open () from /lib/ld-linux.so.2 >> No symbol table info available. >> #9 0xf7f4dc05 in dlopen_doit () from /lib/libdl.so.2 >> No symbol table info available. >> #10 0xf7fe8c91 in _dl_catch_error () from /lib/ld-linux.so.2 >> No symbol table info available. >> #11 0xf7f4e35d in _dlerror_run () from /lib/libdl.so.2 >> No symbol table info available. >> #12 0xf7f4dcae in dlopen@@GLIBC_2.1 <mailto:dlopen@@GLIBC_2.1> () from /lib/libdl.so.2 >> No symbol table info available. >> #13 0x080bd60f in tryLoading () >> No symbol table info available. >> #14 0x080bd751 in ioLoadModule () >> No symbol table info available. >> #15 0x080bf18b in queryLoadModule () >> No symbol table info available. >> #16 0x080bf27f in queryModule () >> No symbol table info available. >> #17 0x080bf2c7 in loadImplicit () >> No symbol table info available. >> #18 0x0805ccd7 in main () >> No symbol table info available. >> (gdb) >> >> >> -- >> The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions. >> >> == >> >> This email may be signed using PGP key ID: 0x4134A417 > >

June 24, 2016

Re: [Pharo-users] Pharo crashing under new Fedora 24 (64bits plus 32bits libraries)

by casimiro barreto

It is a Samsung with NVIDIA but Optimus ... And primusrun won't work because of dynamically linked libraries.... Em 23/06/2016 23:27, "Renaud de Villemeur" <renaud.devillemeur(a)free.fr> escreveu: > Hi. > > Pharo5 can run properly on Fedora 24, with Seaside3.2, OpenGL, or default > image. > What kind of graphic card do you have ? Is it a NVidia ? The default > driver in Fedora, "Nouveau", is 64 bit only. I had to install the > proprietary NVidia driver lib in 32 bit to be able to run pharo, They are > still from fedora 23, as rpm-fusion didn't update its repo yet > (xorg-x11-drv-nvidia-cuda-358.16-2.fc23.i686 and > xorg-x11-drv-nvidia-libs-358.16-2.fc23.i686). > > Here is a list of all 32 bits library I have. My system is not a fresh > install, but Pharo is the only 32 bit apps, so I guess this list is quite > accurate. Can you check if you have a similar list on your system ? > $ rpm -qa | grep i686 | grep -v devel | sort -u > alsa-lib-1.1.1-1.fc24.i686 > bzip2-libs-1.0.6-20.fc24.i686 > cairo-1.14.6-1.fc24.i686 > clang-libs-3.8.0-1.fc24.i686 > elfutils-libelf-0.166-2.fc24.i686 > expat-2.1.1-2.fc24.i686 > fontconfig-2.11.94-6.fc24.i686 > freetype-2.6.3-2.fc24.i686 > gamin-0.1.10-22.fc24.i686 > glib2-2.48.1-1.fc24.i686 > glibc-2.23.1-8.fc24.i686 > keyutils-libs-1.5.9-8.fc24.i686 > krb5-libs-1.14.1-6.fc24.i686 > libcom_err-1.42.13-4.fc24.i686 > libdrm-2.4.68-1.fc24.i686 > libedit-3.1-14.20150325cvs.fc24.i686 > libffi-3.1-9.fc24.i686 > libgcc-6.1.1-2.fc24.i686 > libICE-1.0.9-5.fc24.i686 > libpciaccess-0.13.4-3.fc24.i686 > libpng-1.6.23-1.fc24.i686 > libselinux-2.5-3.fc24.i686 > libsepol-2.5-3.fc24.i686 > libSM-1.2.2-4.fc24.i686 > libssh2-1.7.0-5.fc24.i686 > libstdc++-6.1.1-2.fc24.i686 > libuuid-2.28-3.fc24.i686 > libvdpau-1.1.1-3.fc24.i686 > libverto-0.2.6-6.fc24.i686 > libwayland-client-1.10.0-1.fc24.i686 > libwayland-server-1.10.0-1.fc24.i686 > libX11-1.6.3-3.fc24.i686 > libXau-1.0.8-6.fc24.i686 > libxcb-1.11.1-2.fc24.i686 > libXdamage-1.1.4-8.fc24.i686 > libXext-1.3.3-4.fc24.i686 > libXfixes-5.0.2-2.fc24.i686 > libXrender-0.9.9-3.fc24.i686 > libxshmfence-1.2-3.fc24.i686 > libXxf86vm-1.1.4-3.fc24.i686 > llvm-libs-3.8.0-1.fc24.i686 > mesa-libEGL-11.2.2-2.20160614.fc24.i686 > mesa-libgbm-11.2.2-2.20160614.fc24.i686 > mesa-libGL-11.2.2-2.20160614.fc24.i686 > mesa-libglapi-11.2.2-2.20160614.fc24.i686 > mesa-libOpenCL-11.2.2-2.20160614.fc24.i686 > ncurses-libs-6.0-5.20160116.fc24.i686 > nss-softokn-freebl-3.24.0-1.0.fc24.i686 > ocl-icd-2.2.8-3.git20151217.0122332.fc24.i686 > opencl-utils-1-2.svn16.fc24.i686 > openssl-libs-1.0.2h-1.fc24.i686 > pcre-8.39-2.fc24.i686 > pixman-0.34.0-2.fc24.i686 > pkgconfig-0.29-2.fc24.i686 > pyzy-0.1.0-12.fc24.i686 > readline-6.3-8.fc24.i686 > SDL2-2.0.4-4.fc24.i686 > sqlite-libs-3.11.0-3.fc24.i686 > xorg-x11-drv-nvidia-cuda-358.16-2.fc23.i686 > xorg-x11-drv-nvidia-libs-358.16-2.fc23.i686 > xz-libs-5.2.2-2.fc24.i686 > zlib-1.2.8-10.fc24.i686 > > and for display: > > $ ldd vm-display-X11 > linux-gate.so.1 (0xf778f000) > libpthread.so.0 => /lib/libpthread.so.0 (0xf7729000) > libGL.so.1 => /usr/lib/nvidia/libGL.so.1 (0xf7622000) > libX11.so.6 => /lib/libX11.so.6 (0xf74e1000) > libc.so.6 => /lib/libc.so.6 (0xf7313000) > /lib/ld-linux.so.2 (0x565d0000) > libnvidia-tls.so.358.16 => /usr/lib/nvidia/tls/libnvidia-tls.so.358.16 > (0xf730d000) > libnvidia-glcore.so.358.16 => /usr/lib/nvidia/libnvidia-glcore.so.358.16 > (0xf50b8000) > libXext.so.6 => /lib/libXext.so.6 (0xf50a4000) > libdl.so.2 => /lib/libdl.so.2 (0xf509f000) > libxcb.so.1 => /lib/libxcb.so.1 (0xf5079000) > libm.so.6 => /lib/libm.so.6 (0xf5022000) > libXau.so.6 => /lib/libXau.so.6 (0xf501e000) > > Beware that under Fedora, SSL in Pharo is not available. I think that's a > known issue, due to library mismatch: Pharo is compiled with openssl > v1.0.0, while Fedora use v1.0.2h. > $ ldd libSqueakSSL.so > linux-gate.so.1 (0xf7754000) > libssl.so.1.0.0 => not found > libc.so.6 => /lib/libc.so.6 (0xf7551000) > /lib/ld-linux.so.2 (0x5659f000) > > $ rpm -qa | grep ssl | grep i686 | grep -v devel > openssl-libs-1.0.2h-1.fc24.i686 > > $ rpm -ql openssl-libs.i686 | grep libssl | grep -v hmac > /usr/lib/libssl.so.1.0.2h > /usr/lib/libssl.so.10 > > Regards > Renaud > > > > 2016-06-23 16:31 GMT-04:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> Iâm sorry, but this is not enough informationâ¦ normally crash should let >> a crash.dmp fileâ¦ also a way to reproduce the problem would be coolâ¦ a >> description of what you are doing, etc. >> >> cheers, >> Esteban >> >> >> On 23 Jun 2016, at 22:10, Casimiro - GMAIL <casimiro.barreto(a)gmail.com> >> wrote: >> >> Pharo 5 crashes. VM does a SIGSEGV 0x00000000 at start >> >> Running GDB I got: >> >> (gdb) run >> Starting program: /home/CdAB63/Downloads/pharo5.0/bin/pharo >> Missing separate debuginfos, use: dnf debuginfo-install >> glibc-2.23.1-8.fc24.i686 >> [Thread debugging using libthread_db enabled] >> Using host libthread_db library "/lib64/libthread_db.so.1". >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x00000000 in ?? () >> (gdb) backtrace full >> #0 0x00000000 in ?? () >> No symbol table info available. >> #1 0xf7f3dd7e in __pthread_once_slow () from /lib/libpthread.so.0 >> No symbol table info available. >> #2 0xf7aa9c05 in ?? () from /lib/libGL.so.1 >> No symbol table info available. >> #3 0xf7a722ab in ?? () from /lib/libGL.so.1 >> No symbol table info available. >> #4 0xf7fe8da1 in call_init.part () from /lib/ld-linux.so.2 >> No symbol table info available. >> #5 0xf7fe8f00 in _dl_init () from /lib/ld-linux.so.2 >> No symbol table info available. >> #6 0xf7fed80f in dl_open_worker () from /lib/ld-linux.so.2 >> No symbol table info available. >> #7 0xf7fe8c91 in _dl_catch_error () from /lib/ld-linux.so.2 >> No symbol table info available. >> #8 0xf7fecd89 in _dl_open () from /lib/ld-linux.so.2 >> No symbol table info available. >> #9 0xf7f4dc05 in dlopen_doit () from /lib/libdl.so.2 >> No symbol table info available. >> #10 0xf7fe8c91 in _dl_catch_error () from /lib/ld-linux.so.2 >> No symbol table info available. >> #11 0xf7f4e35d in _dlerror_run () from /lib/libdl.so.2 >> No symbol table info available. >> #12 0xf7f4dcae in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2 >> No symbol table info available. >> #13 0x080bd60f in tryLoading () >> No symbol table info available. >> #14 0x080bd751 in ioLoadModule () >> No symbol table info available. >> #15 0x080bf18b in queryLoadModule () >> No symbol table info available. >> #16 0x080bf27f in queryModule () >> No symbol table info available. >> #17 0x080bf2c7 in loadImplicit () >> No symbol table info available. >> #18 0x0805ccd7 in main () >> No symbol table info available. >> (gdb) >> >> >> -- >> The information contained in this message is confidential and intended to >> the recipients specified in the headers. If you received this message by >> error, notify the sender immediately. The unauthorized use, disclosure, >> copy or alteration of this message are strictly forbidden and subjected to >> civil and criminal sanctions. >> >> == >> >> This email may be signed using PGP key *ID: 0x4134A417* >> >> >> >

June 24, 2016