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

Re: [Pharo-dev] [Pharo-users] vested interest in PharoJS?

by Stephane Ducasse

Did you contact noury? On Thu, Jun 22, 2017 at 3:49 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 22.06.2017 um 13:57 schrieb Siemen Baader <siemenbaader(a)gmail.com>: > > Very cool, Norbert. I have been watching what you are doing at 2denker and > thought you might be interested ;) > > What is holding you back - do you need more from PharoJS before starting to > use it commercially, or are you waiting for a (paid) project before you can > start? > > What is keeping me? A project and the feasibility. The amber project we > could do because the project was more of a research project so I said "why > not". For anything serious you need to check if it is feasible to use. And > my trials with PharoJS were only little so I don't have the feeling, yet, if > it is a huge benefit using it. But I feel a huge potential in it so it is on > my list of things I wanna try but not on top. > > Norbert > > > -- Siemen > > On Thu, Jun 22, 2017 at 1:08 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> I thought I responded already. We are interested in pharoJS. We developed >> stuff with amber but stopped using it. We have one app in the app store with >> ionic and amber and I'd like to do another one with pharoJS. Additionally I >> think that combining pharoJS with electron could be a nice thing to have in >> order to create desktop apps. And finally I was shortly researching native >> callouts from javascript with javascript core on ios and it seems you can do >> pharo code, transpile to javascript that calls javascript functions which >> are OS-native functions. >> >> Norbert >> >> > Am 14.06.2017 um 11:46 schrieb Siemen Baader <siemenbaader(a)gmail.com>: >> > >> > Hi all, >> > >> > Is anyone else interested in PharoJS and making it mature for their own >> > commercial mobile and single page web app (and node.js) development? >> > >> > I think it has a huge potential because it brings the browser runtime >> > and many libraries and online services from the JS world to us Smalltalkers >> > while letting us keep our agile development and good CS practices. But it >> > does not yet have the necessary features and documentation to work smoothly. >> > >> > -- Siemen >> > >

June 24, 2017

Re: [Pharo-dev] files.pharo.org no disk space left?

by Stephane Ducasse

Yes it looks like. We hope to get a solution by monday. On Sat, Jun 24, 2017 at 12:49 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > I have the impression that files.pharo.org has no space left > > Stephan > >

June 24, 2017

Re: [Pharo-dev] Saving a setting in Pharo

by Stephane Ducasse

startUpPreferences On Sat, Jun 24, 2017 at 9:18 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Why dont you use preferences (check the chapter in deep into pharo). > Preferences are managed across images. > Stef > > On Sat, Jun 24, 2017 at 1:50 PM, Myroslava Romaniuk <romaniuk(a)ucu.edu.ua> > wrote: > >> For my GSoC project I've been working on the rule toggle so I created a >> setting that bans a rule for the whole image. >> >> But I'm thinking that some of you might want to disable a certain rule >> for all the following images too. >> >> Hence my question: how to save a setting programatically so that the same >> setting would immediately work for the next image as well? >> >> For now I only know how to do it manually but I need a more elegant way >> to do this: >> [image: Inline images 2] >> >> Any help or advice would be much appreciated. >> >> Regards, >> Myroslava. >> > >

June 24, 2017

Re: [Pharo-dev] Saving a setting in Pharo

by Stephane Ducasse

Why dont you use preferences (check the chapter in deep into pharo). Preferences are managed across images. Stef On Sat, Jun 24, 2017 at 1:50 PM, Myroslava Romaniuk <romaniuk(a)ucu.edu.ua> wrote: > For my GSoC project I've been working on the rule toggle so I created a > setting that bans a rule for the whole image. > > But I'm thinking that some of you might want to disable a certain rule for > all the following images too. > > Hence my question: how to save a setting programatically so that the same > setting would immediately work for the next image as well? > > For now I only know how to do it manually but I need a more elegant way to > do this: > [image: Inline images 2] > > Any help or advice would be much appreciated. > > Regards, > Myroslava. >

June 24, 2017

Saving a setting in Pharo

by Myroslava Romaniuk

For my GSoC project I've been working on the rule toggle so I created a setting that bans a rule for the whole image. But I'm thinking that some of you might want to disable a certain rule for all the following images too. Hence my question: how to save a setting programatically so that the same setting would immediately work for the next image as well? For now I only know how to do it manually but I need a more elegant way to do this: [image: Inline images 2] Any help or advice would be much appreciated. Regards, Myroslava.

June 24, 2017

files.pharo.org no disk space left?

by Stephan Eggermont

I have the impression that files.pharo.org has no space left Stephan

June 23, 2017

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

by Stephan Eggermont

On 23/06/17 17:59, Luke Gorrie 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 :). > ... > Sane? Workable? Fatal flaws? You might want to look at StephanEggermont/DeprecationFinder on sth That tries downloading latest versions of all packages in all projects of sth. It misses the team projects. It needs an old moose (or upgrading). Another experiment I did was StephanEggermont/MonticelloProjects. That combines all code from all the mcz's in a project and can recreate the separate versions. The deduplication is incorrect when there are inconsistent histories. http://forum.world.st/Compact-representation-of-source-code-history-td48669… http://forum.world.st/Working-with-a-compressed-Fuel-file-td4869105.html#a4… Stephan

June 23, 2017

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

by Juraj Kubelka

Thank you Pavel, I will try it soon. One idea: as you say that the sprint goal could be to make it easier. Can you propose some issues that split the goal to small tasks? I guess you have an idea what is necessary to implement. It may help the others to understand and participate. Having a few independent issues to solve would be great for the sprint. Cheers, Juraj > El 23-06-2017, a las 11:20, Pavel Krivanek <pavel.krivanek(a)gmail.com> escribiÃ³: > > 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/ <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 <mailto:juraj.kubelka@icloud.com>>: > Great! > > Is the the Zeroconf Script the right one to use for the Pharo sprint? > curl get.pharo.org/70+vm <http://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 <mailto:marcus.denker@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] Recursively downloading Pharo packages / Building images with Nix

by Paul DeBruicker

For those projects described with Metacello baselines or configurations you can issue a #fetch command to download all the Monticello packages needed to load the projects into your image.... e.g. Metacello new configuration:'Seaside3'; repository: 'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main'; version: #stable; fetch or fetch: #('Core' 'Tests') etc etc etc It does load the projects configuration/baseline and all of the dependencies projects/baselines in order to analyze them and find what needs to be downloaded. But it doesn't load any of the packages' code. Does this help? Paul Luke Gorrie 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. > > 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. -- View this message in context: http://forum.world.st/Recursively-downloading-Pharo-packages-Building-image… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 23, 2017

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

by Ben Coman

On Sat, Jun 24, 2017 at 12:58 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > 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. >> > btw, you may find interesting World > System > System Reporter > MC Working Copies which is coded at SystemReporter>>reportWorkingCopies: > 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. > I guess its an attempt to shortcut that pain in five years when that Linux distribution wants to recreate a particular historical release. cheers -ben

June 23, 2017