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

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

by Luke Gorrie

On 17 April 2017 at 10:37, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > 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. > Thanks for this!

April 17, 2017

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

by Alistair Grant

On Sun, Apr 16, 2017 at 11:21:48PM +0800, Ben Coman wrote: > On Sun, Apr 16, 2017 at 10:50 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Do you know how the linux zero conf scripts are / will be built? > > > > My assumption has been that they are part of the image build. > > I'm not familiar with the zero-conf implementation. > You might learn something here... > https://github.com/pharo-project/pharo-zeroconf Thanks. This looks like it provides the download scripts and CONFIG for the threaded vm, but not the pharo and pharo-ui scripts that actually launch Pharo. I'll have to keep searching... :-) Thanks again, Alistair

April 17, 2017

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

by Alistair Grant

On Mon, Apr 17, 2017 at 12:47:38PM +0200, Luke Gorrie wrote: > On 17 April 2017 at 11:33, Luke Gorrie <luke(a)snabb.co> wrote: > > 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'. > > > I have resolved this now. > > The problem was the VM primitive ioLoadModule() not being able to find libc. It > has some heuristics for where to look but they don't work on NixOS. I added the > relevant folder into $LD_LIBRARY_PATH in my wrapper script and now it is happy. > > There will be a lot of this in my future... finding hard-coded paths for things > like shared libraries and un-hard-coding them. I am not sure what to do in > cases where the paths are in Smalltalk code inside an image, that's harder to > patch than the VM sources or ELF headers etc. I've hit this as well building the snap package, e.g. CairoLibrary>>unixModuleName. I modified the method directly, but probably it would be better to create a UnixPlatform>>findLibrary: method to look after it centrally. Cheers, Alistair

April 17, 2017

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

by Dimitris Chloupis

Not before IMMEDIATELY realizing that all screenshots containing the white theme are outdated and will IMMEDIATELY prefer the dark ones that will have an updated view of the Pharo GUI compared to a screenshot that has the white theme and it's outdated by two or more years. Updating the screenshots for PBE5 was a big pain and I am sure there are ones that are left that are still outdated showing 1.4 , which is at least 6 years old. At some point we will have to automate the whole process with the documentation. Which is why I am implementing a new in image interactive documentation system QA tooltip based I call Prometheas using a online PostgreSQL database that will make it unnecessary to have to download the latest Pharo to get latest documentation. As long as you are online you will have direct access to latest documentation. It won't replace the online HTML/PDF docs but it will provide a quick and dirty way to fetch and create documentation in image. On Mon, 17 Apr 2017 at 12:46, Mark Bestley <news{(a)bestley.co.uk> wrote: > 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:33, Luke Gorrie <luke(a)snabb.co> wrote: > 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'. > I have resolved this now. The problem was the VM primitive ioLoadModule() not being able to find libc. It has some heuristics for where to look but they don't work on NixOS. I added the relevant folder into $LD_LIBRARY_PATH in my wrapper script and now it is happy. There will be a lot of this in my future... finding hard-coded paths for things like shared libraries and un-hard-coding them. I am not sure what to do in cases where the paths are in Smalltalk code inside an image, that's harder to patch than the VM sources or ELF headers etc.

April 17, 2017

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

by Luke Gorrie

On 17 April 2017 at 11:59, Alistair Grant <akgrant0710(a)gmail.com> wrote: > What about the genVersion.sh script I provided earlier in this thread? > The genVersion.sh script has a dependency under the hood that I can't satisfy: it expects to be able to run git commands but I can't do that in the nix environment. The root problem is that nix requires a perfectly reproducible build environment, with the sha256 hash of every dependency declared, and that is hard to do for the .git folder. The .git is really a database that contains many source code versions and not just the one that I have checked out. Which perl script (I'm still learning about the build process), and why > would you need access to git blobs directly? > Check out opensmalltalk-vm/.git_filters/RevDateURL.smudge. This is a perl script that is accessing environmental state that's off-limits in the nix universe e.g. whoami, hostname, date, git, etc. Could be that I should write the version info by hand and apply it as a patch. I have to make my build produce the same result every time it runs. That way it will always work the same, and somebody in 5 years who wants to run an _ancient_ Pharo 6 image will be able to do that with my build script because it's a fixed point. > What does "Smalltalk vm interpreterSourceDate" actually return? > actually it gets an exception because I don't have well-formed values from the strings it is trying to parse.

April 17, 2017

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

by Alistair Grant

On Mon, Apr 17, 2017 at 02:07:40PM +0530, K K Subbu wrote: > 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. Thanks! This should make it straightforward to update the startup scripts. Cheers, Alistair

April 17, 2017

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

by Alistair Grant

Hi Luke, On Mon, Apr 17, 2017 at 11:33:38AM +0200, Luke Gorrie wrote: > On 17 April 2017 at 11:01, Luke Gorrie <luke(a)snabb.co> wrote: > Otherwise I need to supply the "smudged" version information in some reasonable > way. What about the genVersion.sh script I provided earlier in this thread? > I don't have access to the .git folder during build so I can't use the > perl script directly. Which perl script (I'm still learning about the build process), and why would you need access to git blobs 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 :). What does "Smalltalk vm interpreterSourceDate" actually return? Cheers, Alistair

April 17, 2017

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