March 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by Esteban Lorenzano

by base Interpreter you mean an InterpreterVM? On Mar 12, 2013, at 11:02 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > Thank you very much. It makes a lot of sense doing things the Pharo way. > > Now, I have been trying to get the InterpreterSimulator to work in > Pharo but there are some things to fix before being able to do so (one > is to have an image in 6504 format but hey, this is for me learning) > Classes like Utility etc that aren't in the image anymore. > > I had a chat with Bert yesterday and he actually helped me get the > Interpreter starting. > > t would be nice to have Pharo VMMaker have a working base interpreter > (in Smalltalk, running inside the image I mean). > > Maybe should I look at another class, like CogInterpreter? > > Phil > > 2013/3/12 Esteban Lorenzano <estebanlm(a)gmail.com>: >> We use an automated building method that tries to be exactly the same in each platform. We decided not to create bundles but dylibs because bundles are mac-specific stuff and .dylibs same (but for mac) as .so and .dll. >> Our process builds the vm, the plugins and the third party libraries as an all-in-one. Eliot builds are hand made, and when there is a process (like the autotool for unix builds), they are platform-specific. >> >> TL;DR: Is easier for us to build all the vm stuff in an unified way :) >> >> Esteban >> >> On Mar 12, 2013, at 10:49 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >>> Eliot's CogVM vs PharoVM on Mac application contents. Quite different. >>> >>> And worth some explanations :-) Why is it that way? >>> >>> Phil >>> >>> 2013/3/12 Stephan Eggermont <stephan(a)stack.nl>: >>>>> It would be good to have a parallel job, but the problem is that you will >>>>> get a message saying that the VM is too old for the Pharo 2.0 image. >>>> >>>> I started the latest MOOSE image on Eliots latest VM on mac. >>>> It still has the 'old vm' warning. >>>> Adding a monticello repository (directory) doesn't work. >>>> Tests are still running >>>> >>>> Stephan >>>> >>>> >>> <2013-03-12_10-43-37.png> >> >> >

March 12, 2013

[Pharo-project] GSoC13: Distributed Issue Tracker

by Stephan Eggermont

Distributed Issue Tracker Level: (intermediate, advanced) Possible mentor: Stephan Eggermont Possible second mentor: Diego Lont Description A native smalltalk distributed issue tracker. It should have basic issue tracking functionality including attaching files/pictures/code. It should have a native interface, a web interface and a scripting API. Primary development is in Pharo. Issue trackers have different kind of users. To make clear that different users have different needs, persona can be helpful. Isabelle is an information technology student looking for an interesting language and environment to learn. She wants to contribute to and learn from a smart community and needs interesting experiences on her cv. She has already learned the basics of a few mainstream languages and feels ready to try something more exotic. Smalltalk seems interesting as the origin of many inventions. Yann is the major developer of a web-based platform based on Pharo and Seaside. He needs to ensure the platform keeps working smoothly and is updated regularly with the latest changes. In production he uses the released versions. He fears the major clean-ups Pharo is making make it difficult for him to keep up. He is dependent on a few old unmaintained squeaksource packages. Janine just found an interesting old package on squeaksource. It was last changed in 2007. She has been using smalltalk for a few years, so knows what to expect when trying to load an unmaintained package. There are some missing classes that still exist in squeak. Tony is the developer of a package that is used with nearly all smalltalks. He mainly works with a commercial smalltalk and keeps just enough contact with the Pharo community to keep his package working. He has complained about some changes that made it necessary for him to change his package structure. He mainly updates the Pharo version on his way to and from the office in the train. Eve maintains a few of the crucial Pharo kernel packages. They are under heavy development and once in a while everything breaks, leading to a flood of issues. They mostly come from outsiders, as she talks daily with the Pharo core team. She has to close a lot of them as duplicates. She also has to review code that gets attached in one form or another to the issue. Daniel is a maintainer of the vm that forms the basis for the Pharo vm. The vm is used by many more projects. Lara is a release manager for a well known linux distribution. Pharo is just one of 30 languages that are included in the distribution. Before doing a release she scans the issue tracker for any show stoppers. She had to stop including environments because of security issues. Technical Details The recent decision by Google to deprecate and stop its API for the Google Issue Tracker used by a.o. the Pharo, Seaside, MOOSE and Metacello projects makes it necessary for those projects to select a different issue tracker. The timespan before this decision has to be made is too short for the development of a new issue tracker from scratch. Now most development in Smalltalk uses distributed version control systems, either Monticello or Git, the question arises why these projects still would want to use a centralized issue tracker. The long-standing problems in keeping squeaksource up-and-running are only one example of the problems of depending on centralized infrastructure. Other examples are the move of Lukas' repository and the number of times where the Pharo CI infrastructure was not available, especially on holidays and weekends. The currently used issue trackers cannot work disconnected. Integrating the issue tracker in the CI workflow of the projects is crucial. The goals of the persona should be translated into a storymap. Delivery should be iterative and incremental, driven by value to the community and technical risk. The student is expected to be active on the mailing list and discuss development there. This includes handling (source) contributions by others. There is a small prototype available. Benefits to the Student - getting to know the difficulties of issue tracking/the workflow of open source projects - experience with distributed systems - experience an agile open source environment Benefits to the Community - better integrated workflow - native issue tracker, accessible both in-image, web and automated - showcase for productive environment Questions Here are seven persona. Which ones are missing/should be fleshed out?

March 12, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by stephane ducasse

On Mar 12, 2013, at 11:02 AM, phil(a)highoctane.be wrote: > Thank you very much. It makes a lot of sense doing things the Pharo way. > > Now, I have been trying to get the InterpreterSimulator to work in > Pharo but there are some things to fix before being able to do so (one > is to have an image in 6504 format but hey, this is for me learning) > Classes like Utility etc that aren't in the image anymore. > > I had a chat with Bert yesterday and he actually helped me get the > Interpreter starting. > > t would be nice to have Pharo VMMaker have a working base interpreter > (in Smalltalk, running inside the image I mean). yes it would be nice. Now have Utilities monster kind of class in our system is not something we like. :) > Maybe should I look at another class, like CogInterpreter? > > Phil > > 2013/3/12 Esteban Lorenzano <estebanlm(a)gmail.com>: >> We use an automated building method that tries to be exactly the same in each platform. We decided not to create bundles but dylibs because bundles are mac-specific stuff and .dylibs same (but for mac) as .so and .dll. >> Our process builds the vm, the plugins and the third party libraries as an all-in-one. Eliot builds are hand made, and when there is a process (like the autotool for unix builds), they are platform-specific. >> >> TL;DR: Is easier for us to build all the vm stuff in an unified way :) >> >> Esteban >> >> On Mar 12, 2013, at 10:49 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >>> Eliot's CogVM vs PharoVM on Mac application contents. Quite different. >>> >>> And worth some explanations :-) Why is it that way? >>> >>> Phil >>> >>> 2013/3/12 Stephan Eggermont <stephan(a)stack.nl>: >>>>> It would be good to have a parallel job, but the problem is that you will >>>>> get a message saying that the VM is too old for the Pharo 2.0 image. >>>> >>>> I started the latest MOOSE image on Eliots latest VM on mac. >>>> It still has the 'old vm' warning. >>>> Adding a monticello repository (directory) doesn't work. >>>> Tests are still running >>>> >>>> Stephan >>>> >>>> >>> <2013-03-12_10-43-37.png> >> >> >

March 12, 2013

[Pharo-project] Bad links on http://www.squeakvm.org/mac/

by phil＠highoctane.be

Looks like you guys are going to https://ci.lille.inria.fr/pharo/job/Cog-VM/Architecture=32,OS=mac/lastSucce… but the servername is not that anymore. Stuff now lives here: http://pharo.gforge.inria.fr/ci/ Please adjust the links accordingly... Phil

March 12, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by phil＠highoctane.be

The iOS VM has another layout even. And the exe is smaller than 600KB. Phil 2013/3/12 Esteban Lorenzano <estebanlm(a)gmail.com>: > not exactly, but yes, some of the plugins that are internal in Eliot's are external for pharo (no real important reason: we decided to put as external as many as possible :) > > Esteban > > On Mar 12, 2013, at 11:15 AM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> Also, it looks like the Pharo VM uses only external plugins? The >> Squeak VM has a bunch of those plugins, but as internal ones. That's >> probably most of the difference Phil's asking about. >> >> frank >> >> On 12 March 2013 09:57, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> We use an automated building method that tries to be exactly the same in each platform. We decided not to create bundles but dylibs because bundles are mac-specific stuff and .dylibs same (but for mac) as .so and .dll. >>> Our process builds the vm, the plugins and the third party libraries as an all-in-one. Eliot builds are hand made, and when there is a process (like the autotool for unix builds), they are platform-specific. >>> >>> TL;DR: Is easier for us to build all the vm stuff in an unified way :) >>> >>> Esteban >>> >>> On Mar 12, 2013, at 10:49 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>> >>>> Eliot's CogVM vs PharoVM on Mac application contents. Quite different. >>>> >>>> And worth some explanations :-) Why is it that way? >>>> >>>> Phil >>>> >>>> 2013/3/12 Stephan Eggermont <stephan(a)stack.nl>: >>>>>> It would be good to have a parallel job, but the problem is that you will >>>>>> get a message saying that the VM is too old for the Pharo 2.0 image. >>>>> >>>>> I started the latest MOOSE image on Eliots latest VM on mac. >>>>> It still has the 'old vm' warning. >>>>> Adding a monticello repository (directory) doesn't work. >>>>> Tests are still running >>>>> >>>>> Stephan >>>>> >>>>> >>>> <2013-03-12_10-43-37.png> >>> >>> >> > >

March 12, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by Esteban Lorenzano

not exactly, but yes, some of the plugins that are internal in Eliot's are external for pharo (no real important reason: we decided to put as external as many as possible :) Esteban On Mar 12, 2013, at 11:15 AM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > Also, it looks like the Pharo VM uses only external plugins? The > Squeak VM has a bunch of those plugins, but as internal ones. That's > probably most of the difference Phil's asking about. > > frank > > On 12 March 2013 09:57, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> We use an automated building method that tries to be exactly the same in each platform. We decided not to create bundles but dylibs because bundles are mac-specific stuff and .dylibs same (but for mac) as .so and .dll. >> Our process builds the vm, the plugins and the third party libraries as an all-in-one. Eliot builds are hand made, and when there is a process (like the autotool for unix builds), they are platform-specific. >> >> TL;DR: Is easier for us to build all the vm stuff in an unified way :) >> >> Esteban >> >> On Mar 12, 2013, at 10:49 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >>> Eliot's CogVM vs PharoVM on Mac application contents. Quite different. >>> >>> And worth some explanations :-) Why is it that way? >>> >>> Phil >>> >>> 2013/3/12 Stephan Eggermont <stephan(a)stack.nl>: >>>>> It would be good to have a parallel job, but the problem is that you will >>>>> get a message saying that the VM is too old for the Pharo 2.0 image. >>>> >>>> I started the latest MOOSE image on Eliots latest VM on mac. >>>> It still has the 'old vm' warning. >>>> Adding a monticello repository (directory) doesn't work. >>>> Tests are still running >>>> >>>> Stephan >>>> >>>> >>> <2013-03-12_10-43-37.png> >> >> >

March 12, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by Frank Shearar

Also, it looks like the Pharo VM uses only external plugins? The Squeak VM has a bunch of those plugins, but as internal ones. That's probably most of the difference Phil's asking about. frank On 12 March 2013 09:57, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > We use an automated building method that tries to be exactly the same in each platform. We decided not to create bundles but dylibs because bundles are mac-specific stuff and .dylibs same (but for mac) as .so and .dll. > Our process builds the vm, the plugins and the third party libraries as an all-in-one. Eliot builds are hand made, and when there is a process (like the autotool for unix builds), they are platform-specific. > > TL;DR: Is easier for us to build all the vm stuff in an unified way :) > > Esteban > > On Mar 12, 2013, at 10:49 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> Eliot's CogVM vs PharoVM on Mac application contents. Quite different. >> >> And worth some explanations :-) Why is it that way? >> >> Phil >> >> 2013/3/12 Stephan Eggermont <stephan(a)stack.nl>: >>>> It would be good to have a parallel job, but the problem is that you will >>>> get a message saying that the VM is too old for the Pharo 2.0 image. >>> >>> I started the latest MOOSE image on Eliots latest VM on mac. >>> It still has the 'old vm' warning. >>> Adding a monticello repository (directory) doesn't work. >>> Tests are still running >>> >>> Stephan >>> >>> >> <2013-03-12_10-43-37.png> > >

March 12, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by Stephan Eggermont

Phil wrote: >Eliot as a new VM as of yesterday > >http://www.mirandabanda.org/files/Cog/VM/VM.r2701/README.2701 > >That kind of fixes things. > >But I guess the Pharo team still has to integrate these fixes. This is with 2701. The Moose image is based on Pharo 20589 Stephan

March 12, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by phil＠highoctane.be

Thank you very much. It makes a lot of sense doing things the Pharo way. Now, I have been trying to get the InterpreterSimulator to work in Pharo but there are some things to fix before being able to do so (one is to have an image in 6504 format but hey, this is for me learning) Classes like Utility etc that aren't in the image anymore. I had a chat with Bert yesterday and he actually helped me get the Interpreter starting. t would be nice to have Pharo VMMaker have a working base interpreter (in Smalltalk, running inside the image I mean). Maybe should I look at another class, like CogInterpreter? Phil 2013/3/12 Esteban Lorenzano <estebanlm(a)gmail.com>: > We use an automated building method that tries to be exactly the same in each platform. We decided not to create bundles but dylibs because bundles are mac-specific stuff and .dylibs same (but for mac) as .so and .dll. > Our process builds the vm, the plugins and the third party libraries as an all-in-one. Eliot builds are hand made, and when there is a process (like the autotool for unix builds), they are platform-specific. > > TL;DR: Is easier for us to build all the vm stuff in an unified way :) > > Esteban > > On Mar 12, 2013, at 10:49 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> Eliot's CogVM vs PharoVM on Mac application contents. Quite different. >> >> And worth some explanations :-) Why is it that way? >> >> Phil >> >> 2013/3/12 Stephan Eggermont <stephan(a)stack.nl>: >>>> It would be good to have a parallel job, but the problem is that you will >>>> get a message saying that the VM is too old for the Pharo 2.0 image. >>> >>> I started the latest MOOSE image on Eliots latest VM on mac. >>> It still has the 'old vm' warning. >>> Adding a monticello repository (directory) doesn't work. >>> Tests are still running >>> >>> Stephan >>> >>> >> <2013-03-12_10-43-37.png> > >

March 12, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by Esteban Lorenzano

We use an automated building method that tries to be exactly the same in each platform. We decided not to create bundles but dylibs because bundles are mac-specific stuff and .dylibs same (but for mac) as .so and .dll. Our process builds the vm, the plugins and the third party libraries as an all-in-one. Eliot builds are hand made, and when there is a process (like the autotool for unix builds), they are platform-specific. TL;DR: Is easier for us to build all the vm stuff in an unified way :) Esteban On Mar 12, 2013, at 10:49 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > Eliot's CogVM vs PharoVM on Mac application contents. Quite different. > > And worth some explanations :-) Why is it that way? > > Phil > > 2013/3/12 Stephan Eggermont <stephan(a)stack.nl>: >>> It would be good to have a parallel job, but the problem is that you will >>> get a message saying that the VM is too old for the Pharo 2.0 image. >> >> I started the latest MOOSE image on Eliots latest VM on mac. >> It still has the 'old vm' warning. >> Adding a monticello repository (directory) doesn't work. >> Tests are still running >> >> Stephan >> >> > <2013-03-12_10-43-37.png>

March 12, 2013