- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] changing default theme to DarkTheme

by news{＠bestley.co.uk

Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > --94eb2c190338e56e92054d34764f > Content-Type: text/plain; charset=UTF-8 > > Wow guys seriously it's a setting , not the end of the world . Completely > agree with Cyril , I find white theme terrible and I never imagined making > such a big fuss for a setting. > The mooc anmd other documentation show the white theme. So when new users start they see the documentation is wrong - so IMMEDIATELY have a problem > You guys need to chill out. > -- Mark

April 17, 2017

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

by Luke Gorrie

On 17 April 2017 at 11:01, Luke Gorrie <luke(a)snabb.co> wrote: > I have only read through once, but isn't it a no-brainer > ^^^ please forgive gratuitously combative tone :) Fighting the VM build in another window. Just now I am able to build the 32-bit VM from master and run both the Pharo 5 and Pharo 6 images. The next problem is the issue of accessing $HOME. The actual error is ExternalLibraryFunction>>invokeWithArguments: failing to call getenv() from libc. Simplest way that I can reproduce it here is Smalltalk os environment at: 'HOME'. Checking for what I can have mucked up in the build... Otherwise I need to supply the "smudged" version information in some reasonable way. I don't have access to the .git folder during build so I can't use the perl script directly. I see that I can't just skip these values either because on startup I am also seeing a warning that my "VM is too old" coming from DiskStore class>>checkVMVersion that wants to see that my VM source is from at least July 2012 :).

April 17, 2017

Missing VMMaker repo in Pharo 6

by K K Subbu

Hi, I couldn't find the http://source.squeak.org/VMMaker repo in Monticello Browser list of repos. I have to add it to the downloaded image every time to work with VM :-(. Is there any specific reason for not including it by default in Pharo 6 (60465). Regards .. Subbu

April 17, 2017

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

by Luke Gorrie

On 17 April 2017 at 10:17, Alistair Grant <akgrant0710(a)gmail.com> wrote: > This isn't really a feature, it's a core part of the VM's operation. > You could choose to build the itimer VM, but that has its own problems. > See: > > https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux > http://forum.world.st/Iceberg-with-SSH-on-Linux-td4940436.html > http://forum.world.st/Unix-heartbeat-thread-vs-itimer- > td4928943.html#a4938456 Thanks for the links! I have only read through once, but isn't it a no-brainer to disable that message telling you to edit your kernel config? It's very user-unfriendly, it's the very first thing a new user will see the first time they try Pharo, it's not actually applicable to all Linux distributions, and it provides no demonstrable benefit?

April 17, 2017

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

by K K Subbu

On Monday 17 April 2017 01:04 PM, Luke Gorrie wrote: > > I wonder if some DWIM would make sense here. For example, my bash > wrapper that starts the VM could inspect the image file and decide which > VM is appropriate (spur, non-spur, 32-it, 64-bit, etc.) Otherwise the > user needs to guess and decipher cryptic error messages. You can use the attached magic file with file(1) command: file -m magic <image files> ... to detect the image type. or register the patterns with binfmt_misc to match the vm to the image type automatically. BTW, I goofed in my earlier email. I was using 64/vm60 and not 64/vmT60. Sorry for the confusion. With 64/vmT60, I use the following : $ sudo prlimit --rtprio=2 --pid $$ $ ./pharo Pharo.image eval 3+4 Regards .. Subbu

April 17, 2017

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

by Alistair Grant

On Mon, Apr 17, 2017 at 09:34:53AM +0200, Luke Gorrie wrote: > On 17 April 2017 at 07:50, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Yes, 32 bit VM will only work with 32 bit images, and 64 bit VM with 64 > bit images. > > > I wonder if some DWIM would make sense here. For example, my bash wrapper that > starts the VM could inspect the image file and decide which VM is appropriate > (spur, non-spur, 32-it, 64-bit, etc.) Otherwise the user needs to guess and > decipher cryptic error messages. That would be great. It doesn't look like the images have a human readable magic number at the start. Hopefully someone can give us a hint. > Has anybody made such a "DWIM" script that automatically selects the right VM? > Would love a link to use for reference. > > Is there any compatibility matrix to help me understand which VMs are > compatible with which images? Now I know that the 64-bit VM can't run 32-bit > images but I am wondering whether e.g. the Spur VM can run older images like > Pharo 4 / DrGeo / etc or whether different VMs need to be built for those too. > > > As this says, for best operation you should enable higher priority > threads. Have you tried creating the file as described? > > > I will look for a build option to disable this feature that wants to set > realtime priority. This isn't really a feature, it's a core part of the VM's operation. You could choose to build the itimer VM, but that has its own problems. See: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux http://forum.world.st/Iceberg-with-SSH-on-Linux-td4940436.html http://forum.world.st/Unix-heartbeat-thread-vs-itimer-td4928943.html#a49384… Cheers, Alistair > I don't think it's reasonable to expect end-users to edit /etc files in order > to run GUI applications. I also don't like applications blindly printing > instructions that are distro-specific (there is no /etc/security directory on > NixOS for example.) I also :-) don't immediately see why it is safe to assume > that running pharo at realtime scheduler priority is what the user will want > when their system becomes overloaded. > > I already know that another problem coming down the pipeline, after making the > VM work, is finding hard-coded paths in popular image files that only work on > some distributions. For example the Moose image makes some unsafe assumptions > about what libcairo will be called, https://github.com/NixOS/nixpkgs/pull/14414 > > Grumble, grumble, grumble :). But soon all fixed! > > > If I'm reading the stack correctly, it looks like your HOME environment > variable isn't set (or the VM isn't able to access it). > > > Odd. That should not be the case. I will dig deeper. > > > > So maybe the problem is that I need a different source file? Or maybe > that I > > should switch to a 32-bit VM? Or something else entirely...? > > The 32 bit VM is more stable than the 64 bit one at the moment. If you > are still getting the build system stabilised, it might be easier to > stick with 32 bits for now. Switching to 64 bits later should be > straightforward (certainly easier than switching from building Pharo 5 > to Pharo 6). > > > Thanks for the tip! > > I will try to build the 32-bit VM now. > >

April 17, 2017

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

by Luke Gorrie

On 17 April 2017 at 07:50, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Yes, 32 bit VM will only work with 32 bit images, and 64 bit VM with 64 > bit images. > I wonder if some DWIM would make sense here. For example, my bash wrapper that starts the VM could inspect the image file and decide which VM is appropriate (spur, non-spur, 32-it, 64-bit, etc.) Otherwise the user needs to guess and decipher cryptic error messages. Has anybody made such a "DWIM" script that automatically selects the right VM? Would love a link to use for reference. Is there any compatibility matrix to help me understand which VMs are compatible with which images? Now I know that the 64-bit VM can't run 32-bit images but I am wondering whether e.g. the Spur VM can run older images like Pharo 4 / DrGeo / etc or whether different VMs need to be built for those too. As this says, for best operation you should enable higher priority > threads. Have you tried creating the file as described? > I will look for a build option to disable this feature that wants to set realtime priority. I don't think it's reasonable to expect end-users to edit /etc files in order to run GUI applications. I also don't like applications blindly printing instructions that are distro-specific (there is no /etc/security directory on NixOS for example.) I also :-) don't immediately see why it is safe to assume that running pharo at realtime scheduler priority is what the user will want when their system becomes overloaded. I already know that another problem coming down the pipeline, after making the VM work, is finding hard-coded paths in popular image files that only work on some distributions. For example the Moose image makes some unsafe assumptions about what libcairo will be called, https://github.com/NixOS/nixpkgs/pull/14414 Grumble, grumble, grumble :). But soon all fixed! If I'm reading the stack correctly, it looks like your HOME environment > variable isn't set (or the VM isn't able to access it). > Odd. That should not be the case. I will dig deeper. > > So maybe the problem is that I need a different source file? Or maybe > that I > > should switch to a 32-bit VM? Or something else entirely...? > > The 32 bit VM is more stable than the 64 bit one at the moment. If you > are still getting the build system stabilised, it might be easier to > stick with 32 bits for now. Switching to 64 bits later should be > straightforward (certainly easier than switching from building Pharo 5 > to Pharo 6). > Thanks for the tip! I will try to build the 32-bit VM now.

April 17, 2017

Esteban's ChangeLog week of 10 April 2017

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 10 April 2017 to 16 April 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=10/4/2017&to=16/4/2017 ChangeLog ========= 13 April 2017: -------------- * After spending again far too much time trying to get a compilation of +libgit2 v0.23+ on macOS 64bits (for some misterious reason is very hard... I guess is because is an old version), I decided to go the other way: migrate libgit2 bindings to the latest version (something that we needed to do anyway). So far, I got a version working on macOS 32bits (I needed to change some structures, but not as many as I thought). Anyway, tomorrow I will test linux and windows and we'll see 64bits later :) 12 April 2017: -------------- * I updated [zeroconf](http://get.pharo.org/64) with 64bits support! It is still a "preview" (stable version is still not final :P), but is there to test :) I recommend to test: ---- curl get.pharo.org/64/60+vmLatest | bash ---- *REMEMBER:* Windows 64bits is still not supported. * Just fixed a small bug on [iceberg](http://github.com/npasserini/iceberg) : it was missing comparison of locations when mixing absolute and relative paths, even if pointing to same place. * I worked on fix [case: 19891](https://pharo.fogbugz.com/f/cases/19891) and [case: 19890](https://pharo.fogbugz.com/f/cases/19890). Second one took more than expected even if is so trivial just because I was in the middle of another problem with VM :) * I spent some time updating [http://pharo.org/community](http://pharo.org/community) page (not much there, just making shure people will come to the right place when asking for help), and fixing a couple of annoying issues in +/news+. cheers! Esteban

April 17, 2017

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

by Alistair Grant

On Sun, Apr 16, 2017 at 11:55:27PM +0200, Luke Gorrie wrote: > I have the VM building under nix from the master branch now. The build is based > loosely on the linux.64x64 mvm script so it's building a 64-bit x86-64 VM. The > pharo-vm commit I am testing is 1c38b03f (from wednesday.) > > I have tried opening both Pharo-60465.image and Pharo-50771.image and both give > this error: > > > This interpreter (vers. 68021) cannot read image file (vers. 6521). > > > How come? Is this because I built a 64-bit VM? If I want to use those images > then should I build a 32-bit image instead? (Or none of the above?) Yes, 32 bit VM will only work with 32 bit images, and 64 bit VM with 64 bit images. > Then I found Pharo64-60465.image and this does open and display a window but > it's frozen and prints these messages: > > > pthread_setschedparam failed: Operation not permitted > This VM uses a separate heartbeat thread to update its internal clock > and handle events. For best operation, this thread should run at a > higher priority, however the VM was unable to change the priority. The > effect is that heavily loaded systems may experience some latency > issues. If this occurs, please create the appropriate configuration > file in /etc/security/limits.d/ as shown below: > > cat <<END | sudo tee /etc/security/limits.d/squeak.conf > * hard rtprio 2 > * soft rtprio 2 > END > > and report to the squeak mailing list whether this improves behaviour. > > You will need to log out and log back in for the limits to take effect. > For more information please see > https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux As this says, for best operation you should enable higher priority threads. Have you tried creating the file as described? That said, the message is only a warning, the system should be basically working. > 'Your VM is too old for this image. Please download the latest VM.' > Error: Can't find the requested origin > > > UnixResolver(PlatformResolver)>>cantFindOriginError > [ self cantFindOriginError ] in UnixResolver(PlatformResolver)>> > directoryFromEnvVariableNamed: in Block: [ self cantFindOriginError ] > [ ^ aBlock value ] in UnixResolver(PlatformResolver)>> > directoryFromEnvVariableNamed:or: in Block: [ ^ aBlock value ] > BlockClosure>>cull: > Context>>evaluateSignal: > Context>>handleSignal: > Error(Exception)>>signal > Error(Exception)>>signal: > ExternalLibraryFunction(Object)>>error: > ExternalLibraryFunction(Object)>>externalCallFailed > ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments: > UnixEnvironment(OSEnvironment)>>getEnv: > UnixEnvironment(OSEnvironment)>>at:ifAbsent: > [ Smalltalk os environment at: aString ifAbsent: [ nil ] ] in UnixResolver > (PlatformResolver)>>directoryFromEnvVariableNamed:or: in Block: [ Smalltalk > os environment at: aString ifAbse\ > nt: [...etc... > BlockClosure>>on:do: > UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: > UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: > UnixResolver>>home > [ self home / '.config' ] in UnixResolver>>preferences in Block: [ self > home / '.config' ] > [ ^ aBlock value ] in UnixResolver(PlatformResolver)>> > directoryFromEnvVariableNamed:or: in Block: [ ^ aBlock value ] > BlockClosure>>cull: > Context>>evaluateSignal: > Context>>handleSignal: > Error(Exception)>>signal > Error(Exception)>>signal: > ExternalLibraryFunction(Object)>>error: > ExternalLibraryFunction(Object)>>externalCallFailed > ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments: > UnixEnvironment(OSEnvironment)>>getEnv: > FFICalloutAPI>>function:module: > > > Googling around it sounds like this "origin error" is caused by not finding the > Sources file but I have provided the PharoV50.sources and strace suggests that > it is opened okay: > > > open("/nix/store/w85ynpp3zm33k8h1hvzh2g7hf7ggwx1k-pharo-share-1.0/lib/ > PharoV50.sources", O_RDONLY) = 3 > open("/nix/store/w85ynpp3zm33k8h1hvzh2g7hf7ggwx1k-pharo-share-1.0/lib/ > PharoV50.sources", O_RDONLY) = 6 If I'm reading the stack correctly, it looks like your HOME environment variable isn't set (or the VM isn't able to access it). > So maybe the problem is that I need a different source file? Or maybe that I > should switch to a 32-bit VM? Or something else entirely...? The 32 bit VM is more stable than the 64 bit one at the moment. If you are still getting the build system stabilised, it might be easier to stick with 32 bits for now. Switching to 64 bits later should be straightforward (certainly easier than switching from building Pharo 5 to Pharo 6). Cheers, Alistair

April 17, 2017

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

by K K Subbu

Luke, I don't see this in the latest binary and I have not adjusted the rtprio figures at all. I can try running some simple tests if you send them to me. $ curl get.pharo.org/64/60+vmLatest | bash .... file Pharo.image Pharo.image: Smalltalk image Spur 64b +C+NF+Tag (68021) $ prlimit --rtprio RESOURCE DESCRIPTION SOFT HARD UNITS RTPRIO max real-time priority 0 0 $ pharo-vm/lib/pharo/5.0-201704120850/pharo --version 5.0-201704120850 Wed Apr 12 09:13:59 UTC 2017 gcc 4.6.3 [Production Spur 64-bit ITHB VM] CoInterpreter VMMaker.oscog-eem.2188 uuid: ff4ca601-cd05-4792-ab0d-dcdf19975239 Apr 12 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2188 uuid: ff4ca601-cd05-4792-ab0d-dcdf19975239 Apr 12 2017 VM: 201704120850 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Wed Apr 12 10:50:48 2017 +0200 $ Plugins: 201704120850 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Linux testing-gce-504e47eb-4202-4e16-92e1-3d42dab82e2f 3.13.0-103-generic #150~precise1-Ubuntu SMP Thu Nov 24 11:05:34 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux plugin path: /opt/share/downloads/pharo/64/pharo-vm/lib/pharo/5.0-201704120850/ [default: /opt/share/downloads/pharo/64/pharo-vm/lib/pharo/5.0-201704120850/] $ ./pharo Pharo.image eval 0 tinyBenchmarks '923354373 bytecodes/sec; 82191014 sends/sec' Regards .. Subbu On Monday 17 April 2017 03:25 AM, Luke Gorrie wrote: > I have the VM building under nix from the master branch now. The build > is based loosely on the linux.64x64 mvm script so it's building a 64-bit > x86-64 VM. The pharo-vm commit I am testing is 1c38b03f (from wednesday.) > > I have tried opening both Pharo-60465.image and Pharo-50771.image and > both give this error: > > This interpreter (vers. 68021) cannot read image file (vers. 6521). > > > How come? Is this because I built a 64-bit VM? If I want to use those > images then should I build a 32-bit image instead? (Or none of the above?) > > Then I found Pharo64-60465.image and this does open and display a window > but it's frozen and prints these messages: > > pthread_setschedparam failed: Operation not permitted > This VM uses a separate heartbeat thread to update its internal clock > and handle events. For best operation, this thread should run at a > higher priority, however the VM was unable to change the priority. The > effect is that heavily loaded systems may experience some latency > issues. If this occurs, please create the appropriate configuration > file in /etc/security/limits.d/ as shown below: > > cat <<END | sudo tee /etc/security/limits.d/squeak.conf > * hard rtprio 2 > * soft rtprio 2 > END > > and report to the squeak mailing list whether this improves behaviour. > > You will need to log out and log back in for the limits to take effect. > For more information please see > https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux > 'Your VM is too old for this image. Please download the latest VM.' > Error: Can't find the requested origin > > > UnixResolver(PlatformResolver)>>cantFindOriginError > [ self cantFindOriginError ] in > UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: in > Block: [ self cantFindOriginError ] > [ ^ aBlock value ] in > UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in > Block: [ ^ aBlock value ] > BlockClosure>>cull: > Context>>evaluateSignal: > Context>>handleSignal: > Error(Exception)>>signal > Error(Exception)>>signal: > ExternalLibraryFunction(Object)>>error: > ExternalLibraryFunction(Object)>>externalCallFailed > ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments: > UnixEnvironment(OSEnvironment)>>getEnv: > UnixEnvironment(OSEnvironment)>>at:ifAbsent: > [ Smalltalk os environment at: aString ifAbsent: [ nil ] ] in > UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in > Block: [ Smalltalk os environment at: aString ifAbse\ > nt: [...etc... > BlockClosure>>on:do: > UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: > UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: > UnixResolver>>home > [ self home / '.config' ] in UnixResolver>>preferences in Block: [ > self home / '.config' ] > [ ^ aBlock value ] in > UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in > Block: [ ^ aBlock value ] > BlockClosure>>cull: > Context>>evaluateSignal: > Context>>handleSignal: > Error(Exception)>>signal > Error(Exception)>>signal: > ExternalLibraryFunction(Object)>>error: > ExternalLibraryFunction(Object)>>externalCallFailed > ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments: > UnixEnvironment(OSEnvironment)>>getEnv: > FFICalloutAPI>>function:module: > > > Googling around it sounds like this "origin error" is caused by not > finding the Sources file but I have provided the PharoV50.sources and > strace suggests that it is opened okay: > > open("/nix/store/w85ynpp3zm33k8h1hvzh2g7hf7ggwx1k-pharo-share-1.0/lib/PharoV50.sources", > O_RDONLY) = 3 > open("/nix/store/w85ynpp3zm33k8h1hvzh2g7hf7ggwx1k-pharo-share-1.0/lib/PharoV50.sources", > O_RDONLY) = 6 > > So maybe the problem is that I need a different source file? Or maybe > that I should switch to a 32-bit VM? Or something else entirely...? > > Any help appreciated :) > -Luke >

April 17, 2017