- Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 6 snap install

by Stephane Ducasse

Hi luke We will do that. Now we are under stress for the release :) And PharoDays. Great conference! Stef On Wed, Apr 12, 2017 at 4:57 PM, Luke Gorrie <luke(a)snabb.co> wrote: > On 12 April 2017 at 16:43, Offray Vladimir Luna CÃ¡rdenas < > offray.luna(a)mutabit.com> wrote: > >> I'm also interested in the upcoming Nix package initiative that has been >> announced in the list recently, which also deals with installing >> dependencies in a Linux distribution neutral fashion. >> > > This can only happen if the Pharo community somehow products a new release > of the VM that I can package. > > The suggestion from the list was that I pick a commit from the > pharo-project/pharo-vm#master branch, but I have browsed the commit history > and that is way too much of a moving target for me to ship onwards to > Nix/NixOS users. > > Pharo community: Please - somehow - make a new source release of your > bloomin' VM! > > >

April 13, 2017

Re: [Pharo-users] Pharo 6 snap install

by Stephane Ducasse

Thanks a lot for this effort!!!!! On Wed, Apr 12, 2017 at 4:03 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Everyone, > > I've made a snap package for Pharo 6 which I think is far enough along > for some wider testing. > > To get Pharo up and running on Ubuntu 16.04: > > # Install Pharo > $ sudo snap install --edge pharo --classic > # If your system isn't configured for threaded heartbeat: > $ sudo pharo.config > # Download the latest Pharo 6 image > $ pharo.getimage > # Go... > $ pharo.ui Pharo.image > # or: > $ pharo Pharo.image eval 4+3 > > To get a list of available commands: > > $ snap info pharo > > > If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see > https://snapcraft.io/docs/core/install > > > The VM is the threaded heartbeat, dated 201704101933. > > The installation flags are: > > --edge - The edge channel is for development versions. It > progresses to beta, candidate and then stable. > --classic - Snap packages are normally sandboxed for security > reasons. Since Pharo is a development environment > in which we want to be able to run any executable, > or load any library, it is installed with access to > the entire system (as the running user). > > Why use snap packages? > > - They include all dependencies. In particular, for the 32 bit > versions, this means that it isn't necessary to install all the 32 bit > architecture and associated dependencies. > - Including dependencies means that there shouldn't be any problems with > incompatible library versions when upgrading. > > Why not use snap packages? > > - It's a relatively new technology, with a number of rough edges. > - There may still be issues with its sandboxing that I haven't > discovered yet. > - Please let me know of any others to be listed here. > - Because the package uses classic confinement, it isn't > cross-distribution in practice (unfortunately). > > If you don't trust me to configure your system correctly (which requires > sudo): > > - All the scripts that make up the sub-commands are visible, e.g. > pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG > > > The packaging code is at: https://github.com/akgrant43/pharo-snap > > I'm interested to know if people would like to see this eventually > become a supported package format. > > Cheers, > Alistair > >

April 13, 2017

Re: [Pharo-users] Traits, method flatten

by Hilaire

May be an important note, FileOut is handling just right the Traits logic. Hilaire Le 13/04/2017 Ã 08:53, Nicolai Hess a Ã©crit : > > I am interested, and I think I already looked at this issue, I vaguely > remember, that this has > something to do with the determination of the origin of a method (trait > methods that are from another trait > are wrongly recognized as (trait)local methods). > -- Dr. Geo http://drgeo.eu

April 13, 2017

Re: [Pharo-users] Traits, method flatten

by Hilaire

What is your email address? I can't read it from the usenet forum. Hilaire Le 13/04/2017 Ã 08:53, Nicolai Hess a Ã©crit : > > I am interested, and I think I already looked at this issue, I vaguely > remember, that this has > something to do with the determination of the origin of a method (trait > methods that are from another trait > are wrongly recognized as (trait)local methods). > -- Dr. Geo http://drgeo.eu

April 13, 2017

Re: [Pharo-users] Traits, method flatten

by Nicolai Hess

I am interested, and I think I already looked at this issue, I vaguely remember, that this has something to do with the determination of the origin of a method (trait methods that are from another trait are wrongly recognized as (trait)local methods). 2017-04-13 8:37 GMT+02:00 Hilaire <hilaire(a)drgeo.eu>: > Hi, > > If anyone with deep knowledge on Monticello wants to give a look with > this bugs on Traits, I can share privately an image exposing the > problem. Just mail me at hilaire [AT] drgeo.eu > > Thanks > > Hilaire > > Le 12/04/2017 Ã 14:08, Hilaire a Ã©crit : > > Investigating a bit on the mater, here is the conduct: > > > > - In a fresh 5.0, find an a version of my package where the Traits logic > > is not compromised (All traits methods are not duplicated in the classes > > using the traits) > > > > - Load this package, all seems fine. > > > > - Promote the class/trait category to a package, let's say TraitsPackage > > > > - Save this package locally in a .mcz file > > > > - In the Pharo5.0 image unload all my packages > > > > - Load back the TraitsPackage, all traits methods are duplicated... > > > > - Examine the source in the .mcz file: the traits logic is already > > compromised > > > > > > Is there anything wrong in this process? > > > > > > Conclusion1: Pharo5 does not know how to save Trait correctly. > > Conclusion2: Already get there, > > http://forum.world.st/Strange-behaviour-with-traits-td4891623.html > > -- > Dr. Geo > http://drgeo.eu > > >

April 13, 2017

Re: [Pharo-users] Traits, method flatten

by Hilaire

Hi, If anyone with deep knowledge on Monticello wants to give a look with this bugs on Traits, I can share privately an image exposing the problem. Just mail me at hilaire [AT] drgeo.eu Thanks Hilaire Le 12/04/2017 Ã 14:08, Hilaire a Ã©crit : > Investigating a bit on the mater, here is the conduct: > > - In a fresh 5.0, find an a version of my package where the Traits logic > is not compromised (All traits methods are not duplicated in the classes > using the traits) > > - Load this package, all seems fine. > > - Promote the class/trait category to a package, let's say TraitsPackage > > - Save this package locally in a .mcz file > > - In the Pharo5.0 image unload all my packages > > - Load back the TraitsPackage, all traits methods are duplicated... > > - Examine the source in the .mcz file: the traits logic is already > compromised > > > Is there anything wrong in this process? > > > Conclusion1: Pharo5 does not know how to save Trait correctly. > Conclusion2: Already get there, > http://forum.world.st/Strange-behaviour-with-traits-td4891623.html -- Dr. Geo http://drgeo.eu

April 13, 2017

Machine Learning in Pharo

by frankl1_miky

Hello everyone, I would like to experiment machine learning in Pharo. Is there any library out there for that purpose ? Thanks ! -- View this message in context: http://forum.world.st/Machine-Learning-in-Pharo-tp4941934.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 13, 2017

Re: [Pharo-users] Pharo 6 snap install

by Alistair Grant

Hi Subbu, On Wed, Apr 12, 2017 at 08:22:27PM +0530, K K Subbu wrote: > On Wednesday 12 April 2017 07:33 PM, Alistair Grant wrote: > >Hi Everyone, > > > >I've made a snap package for Pharo 6 which I think is far enough along > >for some wider testing. > > Just tried it now. worked like charm. Thanks! > > --classic - Snap packages are normally sandboxed for security > > reasons. Since Pharo is a development environment > > in which we want to be able to run any executable, > > or load any library, it is installed with access to > > the entire system (as the running user). > Is this really necessary even if we want to work only within an image? No, I've used it successfully with strict confinement, however I think most developers will quickly become frustrated with the restrictions. If someone has a Pharo based application that they'd like to distribute, I think strict confinement is a much more likely to be a realistic option. Cheers, Alistair

April 12, 2017

Re: [Pharo-users] Pharo 6 snap install

by Luke Gorrie

On 12 April 2017 at 16:43, Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com> wrote: > I'm also interested in the upcoming Nix package initiative that has been > announced in the list recently, which also deals with installing > dependencies in a Linux distribution neutral fashion. > This can only happen if the Pharo community somehow products a new release of the VM that I can package. The suggestion from the list was that I pick a commit from the pharo-project/pharo-vm#master branch, but I have browsed the commit history and that is way too much of a moving target for me to ship onwards to Nix/NixOS users. Pharo community: Please - somehow - make a new source release of your bloomin' VM!

April 12, 2017

Re: [Pharo-users] Pharo 6 snap install

by K K Subbu

On Wednesday 12 April 2017 07:33 PM, Alistair Grant wrote: > Hi Everyone, > > I've made a snap package for Pharo 6 which I think is far enough along > for some wider testing. Just tried it now. worked like charm. > --classic - Snap packages are normally sandboxed for security > reasons. Since Pharo is a development environment > in which we want to be able to run any executable, > or load any library, it is installed with access to > the entire system (as the running user). Is this really necessary even if we want to work only within an image? Regards .. Subbu

April 12, 2017