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

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

Re: [Pharo-users] Neural Networks in Pharo

by Ben Coman

On Wed, Apr 5, 2017 at 8:27 AM, Oleksandr Zaytsev <olk.zaytsev(a)gmail.com> wrote: > Hello! > > Several weeks ago I've announced my NeuralNetworks project. Thank you very > much for your ideas and feedback. As suggested, I wrote examples for every > class and tested my perceptron on linearly-separable logical functions. > > I have just completed a post about my implementation of a single-layer > perceptron: https://medium.com/@i.oleks/single-layer-perceptron-in-pharo > -5b13246a041d. It has a detailed explanation of every part of the design > and illustrates different approaches to implementation. > > Please, tell me what you think. > > Are my class diagrams correct or did I mess something up? > Is there a design pattern that I should consider? > Do you think that I should do something differently? > Should I improve the quality of my code? > > Yours sincerely, > Oleksandr > Hi Oleks, (sorry for the delayed response. Saw you other post in pharo-dev and found this sitting in my drafts from last week.) Nice article and interesting read. I only did NeuralNetworks in my undergrad 25 years ago so my knowledge is a bit vague. I think you design reasoning is fine for this stage. Down the track you might consider that OO is about hiding implementation details. So just a vague idea, you might have SLPerceptron storing neuron data internally in arrays that a GPU can process efficiently, but when "SLPerceptron>>#at:" is asked for a neuron, it constructs a "real" neuron object, whose methods forward to the arrays in theSLPerceptron. cheers -ben

April 12, 2017

Re: [Pharo-users] Pharo 6 snap install

by Offray Vladimir Luna CÃ¡rdenas

Thanks for this Alistair. Having more self contained package options, is good. 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. Cheers, Offray On 12/04/17 09:03, 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. > > 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 12, 2017

Pharo 6 snap install

by Alistair Grant

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 12, 2017

Re: [Pharo-users] Recommended stable Pharo 5.0 VM for Linux users?

by Luke Gorrie

On 12 April 2017 at 14:08, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > It is in my TODO list. > â¦ along with other milliards of things with more priority ;) > > I will welcome any Pull Request, in any area but specially on that one :D > I can potentially make some time to help out with VM maintenance. I have already volunteered to maintain the NixOS packaging for Pharo and that is what leads me here in the first place, I will need to successfully build the VM myself before I can help anybody else though :). Before committing time I would like to understand the situation a little bit better. How come nobody in the Pharo community sees it as a priority to make a VM source release that is compatible with the current image version (5.0)? I had imagined that a compatible VM would be released at the same time as the image. So I am obviously missing some point about why other people see the VM source release as such a low priority. Is it just that everybody is running zeroconf binaries distributed by Jenkins and that I am one of very few people who wants to build from source (without bootstrapping from another Pharo)? Context: I am a relative newbie who wants to develop an application based on Pharo. It's much harder than I expected to get started!

April 12, 2017