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

Re: [Pharo-dev] Error in ByteArray>>booleanAt:

by Eliot Miranda

On Fri, Jun 23, 2017 at 4:19 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > https://pharo.fogbugz.com/f/cases/20176/Error-in-ByteArray-booleanAt > Fixed in Name: FFI-Kernel-eem.46 Author: eem Time: 23 June 2017, 10:00:42.756292 am UUID: ab2b7c9e-0edb-4f10-8fd2-32400997fb8e Ancestors: FFI-Kernel-EstebanLorenzano.45 Fix booleanAt: (This is part of the FFI package) > > > 2017-06-22 17:39 GMT+02:00 Raffaello Giulietti < > raffaello.giulietti(a)lifeware.ch>: > >> Hi, >> >> the current (Pharo 6) code reads >> >> ^(self integerAt: byteOffset size: 1 signed: false) == true >> >> so it always returns false, as no integer is identical to true. >> >> >> Instead, it should read >> >> ^(self integerAt: byteOffset size: 1 signed: false) ~= 0 >> >> implementing the usual convention that 0 maps to false and every other >> value maps to true. >> >> Greetings >> Raffaello >> >> > -- _,,,^..^,,,_ best, Eliot

June 23, 2017

Re: [Pharo-dev] Recursively downloading Pharo packages / Building images with Nix

by Eliot Miranda

Hi Luke, On Fri, Jun 23, 2017 at 8:59 AM, Luke Gorrie <luke(a)snabb.co> wrote: > Hi again Ben, > > I have an idea for a hacky way to import all of the Pharo packages into my > universe. Shooting holes in this idea would be welcome :). > > Suppose that for each package "P" in the catalog I want to make a list of > the recursive dependencies (mcz files) and their sha256 hashes. I would do > this using a script that runs Pharo outside the sandbox and with access to > the network: > > - Start Pharo with an empty package cache. > - Download "P" and all of its dependencies automatically with Gofer. > - Inspect the package cache to see every mcz file that was downloaded and > its sha256 hash. > > Then I could use this process to bootstrap a package repository: > > - Having a copy of all the .mcz files in a common ftp directory. > - Having a mapping of filename->sha256 to provide to nix. > - Having a mapping from package name ("P") to all .mcz dependencies. > > This package repository could then be used for Nix such that I say which > packages I want and it automatically downloads all of the required .mcz > files, validates them with sha256 to make sure the build is reproducible, > and then loads them all into an image and dumps the result ready for use. > > So then on the Nix side I would write something like: > > nix-build -E 'pharo6 { packages = [ roassal2 neojson ... ]; }' > > and it would automatically create an image for me based on the package > repository definition that it finds in Git. > > Sane? Workable? Fatal flaws? > Workable? Yes. Fatal flaws? None. Sane? Why introduce your own ftp directory? All you're doing is replicating all the repositories out there. Basically you want to seed a package-cache with any and all versions of the relevant packages. The ftp directory looks like a superfluous step. What you need to construct is the repository crawler that locates as many versions as you can find. The list of versions should be in each package; it's part of its history. You then have to find out where they are. As packages move from repository to repository (a sad fact of life) so tracking down these versions becomes difficult. _,,,^..^,,,_ best, Eliot

June 23, 2017

Re: [Pharo-dev] Recursively downloading Pharo packages / Building images with Nix

by Ben Coman

On Fri, Jun 23, 2017 at 11:59 PM, Luke Gorrie <luke(a)snabb.co> wrote: > Hi again Ben, > > I have an idea for a hacky way to import all of the Pharo packages into my > universe. Shooting holes in this idea would be welcome :). > > Suppose that for each package "P" in the catalog I want to make a list of > the recursive dependencies (mcz files) and their sha256 hashes. I would do > this using a script that runs Pharo outside the sandbox and with access to > the network: > > - Start Pharo with an empty package cache. > - Download "P" and all of its dependencies automatically with Gofer. > - Inspect the package cache to see every mcz file that was downloaded and > its sha256 hash. > > Then I could use this process to bootstrap a package repository: > > - Having a copy of all the .mcz files in a common ftp directory. > - Having a mapping of filename->sha256 to provide to nix. > - Having a mapping from package name ("P") to all .mcz dependencies. > > This package repository could then be used for Nix such that I say which > packages I want and it automatically downloads all of the required .mcz > files, validates them with sha256 to make sure the build is reproducible, > and then loads them all into an image and dumps the result ready for use. > > So then on the Nix side I would write something like: > > nix-build -E 'pharo6 { packages = [ roassal2 neojson ... ]; }' > > and it would automatically create an image for me based on the package > repository definition that it finds in Git. > > Sane? Workable? Fatal flaws? > That is exactly the approach I was thinking of also. But btw note, IIUC the bootstrap hasn't got a far as programatically creating an empty file and writing nil,true,false to it yet (if ever?). You will always be starting with a minimal.image rather than an empty.image. cheers -ben

June 23, 2017

Re: [Pharo-dev] Recursively downloading Pharo packages / Building images with Nix

by Luke Gorrie

Hi again Ben, I have an idea for a hacky way to import all of the Pharo packages into my universe. Shooting holes in this idea would be welcome :). Suppose that for each package "P" in the catalog I want to make a list of the recursive dependencies (mcz files) and their sha256 hashes. I would do this using a script that runs Pharo outside the sandbox and with access to the network: - Start Pharo with an empty package cache. - Download "P" and all of its dependencies automatically with Gofer. - Inspect the package cache to see every mcz file that was downloaded and its sha256 hash. Then I could use this process to bootstrap a package repository: - Having a copy of all the .mcz files in a common ftp directory. - Having a mapping of filename->sha256 to provide to nix. - Having a mapping from package name ("P") to all .mcz dependencies. This package repository could then be used for Nix such that I say which packages I want and it automatically downloads all of the required .mcz files, validates them with sha256 to make sure the build is reproducible, and then loads them all into an image and dumps the result ready for use. So then on the Nix side I would write something like: nix-build -E 'pharo6 { packages = [ roassal2 neojson ... ]; }' and it would automatically create an image for me based on the package repository definition that it finds in Git. Sane? Workable? Fatal flaws?

June 23, 2017

Re: [Pharo-dev] Recursively downloading Pharo packages / Building images with Nix

by Luke Gorrie

Hi Ben, On 23 June 2017 at 15:20, Ben Coman <btc(a)openinworld.com> wrote: > Typically Monticello mcz files are hosted on services shared via HTTP that > you can download with wget or curl, e.g.... > http://smalltalkhub.com/mc/Pharo/Pharo60/main > I guess if you pre-seed the package-cache, Pharo won't try to go to the > network to find the package. > That looks really promising, thanks for the link! I suppose that in the simplest case I would simply download every mcz file into the package cache and then I should be able to load any package without going over the network? Then the more sophisticated step would be to understand the dependency relationships so that I know what subset of the packages I need to install a given package e.g. Moose depends on Roassal depends on Trachel, etc. Is there an easy way to dump this dependency relationship e.g. to a text file? Is there also an easy way to determine the complete set of mcz files in the relevant universe? (The link above only covers projects hosted on SmalltalkHub, right? So I need to also know where to find all the potentially referenced projects on Github, etc, too?)

June 23, 2017

Re: [Pharo-dev] Recursively downloading Pharo packages / Building images with Nix

by Ben Coman

On Fri, Jun 23, 2017 at 4:20 PM, Luke Gorrie <luke(a)snabb.co> wrote: > Howdy! > > I want to build Pharo images using Nix <https://nixos.org/nix/>. On the > one hand this should look basically like the Jenkins scripts, but on the > other hand the build must run inside a sandbox that is isolated from the > network. So I need to download all of the code that I need ahead of time > because I am not able to contact Github, SmalltalkHub, etc, once the build > is running. > Typically Monticello mcz files are hosted on services shared via HTTP that you can download with wget or curl, e.g.... http://smalltalkhub.com/mc/Pharo/Pharo60/main I guess if you pre-seed the package-cache, Pharo won't try to go to the network to find the package. And with git repos, Pharo would be build from a local clone. cheers -ben > > I am not sure how to approach this problem yet but I have a preliminary > question. > > Is there an easy way that I could "recursively" download all the Smalltalk > code (etc) required for an application onto the local filesystem, and then > load this into a Pharo image that does not have network access? > > Concrete example - How could I write a Pharo script that downloads all the > software required to install Moose in a standard Pharo 6.0 image? Then how > could I load that into an image off the local filesystem? > > I feel like there should be a solution here, since Monticello seems to be > able to cache packages locally on the filesystem, but I don't how enough > experience to quite know how to approach it. > > If this is possible then the "utopian" vision could be to recursively > download every Pharo package that exists, in every relevant version, and > make them available in the Nix universe. This is what Nix does with Python, > R, Emacs, etc packages. > > Or if this turns out to be difficult for some reason then I could perhaps > build the Pharo image externally - e.g. on the Inria Jenkins - and then > import that into Nix as an opaque binary. This is probably the simplest > solution but it is not very appealing from my Nix-centric viewpoint because > I won't have visibility into what has changed between one image build and > the next. > > Feedback would be much appreciated! > -Luke > > P.S. Screenshot from the Pharo part of my application that is starting to > come together, visualizing Lua JIT compiler IR code to make it more > understandable than disassembly listings: https://github.com/ > raptorjit/raptorjit/pull/63#issuecomment-310138536. > > >

June 23, 2017

Re: [Pharo-dev] Error in ByteArray>>booleanAt:

by Pavel Krivanek

https://pharo.fogbugz.com/f/cases/20176/Error-in-ByteArray-booleanAt 2017-06-22 17:39 GMT+02:00 Raffaello Giulietti < raffaello.giulietti(a)lifeware.ch>: > Hi, > > the current (Pharo 6) code reads > > ^(self integerAt: byteOffset size: 1 signed: false) == true > > so it always returns false, as no integer is identical to true. > > > Instead, it should read > > ^(self integerAt: byteOffset size: 1 signed: false) ~= 0 > > implementing the usual convention that 0 maps to false and every other > value maps to true. > > Greetings > Raffaello > >

June 23, 2017

Re: [Pharo-dev] [ANN] Pharo Sprint June 30

by Pavel Krivanek

Right now for Pharo 7 you will need to download image from here: https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/ And because of a Monticello issue you will need to have your clone in image working directory, in the folder named 'pharo-core' (the other alternative is to reload all packages). Then you need to switch this repository to the particular commit that was used for the image bootstrap. You can get the hash with: SystemVersion current commitHash ...and this cannot be done now from Iceberg. Then you can create issue branches and pull request. One goal of the sprint can be to make this all easier ;-) Cheers, -- Pavel 2017-06-23 10:57 GMT+02:00 Juraj Kubelka <juraj.kubelka(a)icloud.com>: > Great! > > Is the the Zeroconf Script the right one to use for the Pharo sprint? > curl get.pharo.org/70+vm | bash > > Currently it shows > Pharo 6.0 > Latest update: #60499 > > Can we still produces slices during the sprint? > I will appreciate any advice according to on going changes, in particular, > using GitHub. > > Thanks! > Juraj > > El 23-06-2017, a las 10:09, Marcus Denker <marcus.denker(a)inria.fr> > escribiÃ³: > > Hi! > > Next Friday, June 30 will be the next Pharo Sprint! > > It will start 10:00am. (Local Time Paris). > > For more infos, see: *https://association.pharo.org/event-2492492 > <https://association.pharo.org/event-2492492>* > > Marcus > > >

June 23, 2017

Re: [Pharo-dev] [ANN] Pharo Sprint June 30

by Juraj Kubelka

Great! Is the the Zeroconf Script the right one to use for the Pharo sprint? curl get.pharo.org/70+vm | bash Currently it shows Pharo 6.0 Latest update: #60499 Can we still produces slices during the sprint? I will appreciate any advice according to on going changes, in particular, using GitHub. Thanks! Juraj > El 23-06-2017, a las 10:09, Marcus Denker <marcus.denker(a)inria.fr> escribiÃ³: > > Hi! > > Next Friday, June 30 will be the next Pharo Sprint! > > It will start 10:00am. (Local Time Paris). > > For more infos, see: https://association.pharo.org/event-2492492 <https://association.pharo.org/event-2492492> > > Marcus

June 23, 2017

Recursively downloading Pharo packages / Building images with Nix

by Luke Gorrie

Howdy! I want to build Pharo images using Nix <https://nixos.org/nix/>. On the one hand this should look basically like the Jenkins scripts, but on the other hand the build must run inside a sandbox that is isolated from the network. So I need to download all of the code that I need ahead of time because I am not able to contact Github, SmalltalkHub, etc, once the build is running. I am not sure how to approach this problem yet but I have a preliminary question. Is there an easy way that I could "recursively" download all the Smalltalk code (etc) required for an application onto the local filesystem, and then load this into a Pharo image that does not have network access? Concrete example - How could I write a Pharo script that downloads all the software required to install Moose in a standard Pharo 6.0 image? Then how could I load that into an image off the local filesystem? I feel like there should be a solution here, since Monticello seems to be able to cache packages locally on the filesystem, but I don't how enough experience to quite know how to approach it. If this is possible then the "utopian" vision could be to recursively download every Pharo package that exists, in every relevant version, and make them available in the Nix universe. This is what Nix does with Python, R, Emacs, etc packages. Or if this turns out to be difficult for some reason then I could perhaps build the Pharo image externally - e.g. on the Inria Jenkins - and then import that into Nix as an opaque binary. This is probably the simplest solution but it is not very appealing from my Nix-centric viewpoint because I won't have visibility into what has changed between one image build and the next. Feedback would be much appreciated! -Luke P.S. Screenshot from the Pharo part of my application that is starting to come together, visualizing Lua JIT compiler IR code to make it more understandable than disassembly listings: https://github.com/raptorjit/raptorjit/pull/63#issuecomment-310138536.

June 23, 2017