- Pharo-dev - lists.pharo.org

Experience makers

by stepharo

Dear experience makers (Martin, yuriy, tommaso, roberto and others,) you would like to have many people doing your experience.... I know you would love that. Here is my suggestion: ease the use of new images. Each time I want to load the projects I'm hacking and I do not have a jenkins for it, it is painful (setting up the repos.... loading....). So I do not change often images and I'm reluctant to load new stuff (like your experiments) - build a simple little tool that could be integrated in pharo and would do the following: - let the user (un)/select some packages or configurations - generate a script to reload these configurations really easily This way I can load my project and then you provide a script for your experience. and after I can reload my project with your material for experience in my new image. Right now I do not like to hack the preference file because I have images where I do not want any interference So is my proposal clear? Stef

Oct. 27, 2014

Re: [Pharo-dev] ShoreLine Reporter - A tool to collect stack traces

by stepharo

It depends: - is it overriding? - is it well packaged? - is it cross cutting a lot? Stef On 27/10/14 07:01, Marcus Denker wrote: > I was thinking... would it make sense to have this in the image by > default? > > > On Tue, Oct 7, 2014 at 6:23 PM, Tommaso Dal Sasso > <tommaso.dalsasso(a)gmail.com <mailto:tommaso.dalsasso@gmail.com>> wrote: > > Hello everybody, > > for those of you who were not at ESUG, I present ShoreLine Reporter. > > ShoreLine Reporter is a Pharo plugin to collect stack traces from > exceptions and send them to a central repository. > You can give feedback to the community by breaking things: how > cool is that? > > > * Why? > > We are collecting stack traces for research purposes and to > identify the Pharo components that can be improved or optimized. > We are also working on a web platform where users can access the > submitted data and use them during the debugging process. More on > that soon! > > > * How? > > You can install ShoreLine Reporter by visiting the project page on > SmalltalkHub: > http://www.smalltalkhub.com/#!/~dalsat/ShoreLine-Reporter/ > <http://www.smalltalkhub.com/#%21/%7Edalsat/ShoreLine-Reporter/> > > Installing ShoreLine Reporter requires only a couple of seconds, > and you can configure it with the level of feedback that you > prefer. On the SmalltalkHub page you can find a script to > automatically install ShoreLine Reporter with every new Pharo > image. Just drop it in your Pharo preferences directory and forget > about it. > > Once ShoreLine Report is installed, you can decide to configure if > you want to be prompted to submit a stack trace, or to > automatically submit each exception without any bother. > > > * What? > > We try to collect as few data as possible: the execution > stacktrace, the name of the author and the Pharo build. We do > *not* any collect personal data, such as passwords or > repositories. The data is currently stored on our server, at the > University of Lugano. > > > * Compatibility > > ShoreLine Reporter is developed for the Pharo debugger. We are > improving ShoreLine Reporter to work with GTInspector, we will > push an update in the following days. > > > For any problem, contact me! > > Thanks, hope to see a lot of your exceptions ;-) > Tommaso Dal Sasso @ REVEAL > > > > > -- > -- > Marcus Denker -- denker(a)acm.org <mailto:denker@acm.org> > http://www.marcusdenker.de

Oct. 27, 2014

Re: [Pharo-dev] ShoreLine Reporter - A tool to collect stack traces

by stepharo

tommaso send us a working script not something that we should browse and understand. Stef On 7/10/14 11:23, Tommaso Dal Sasso wrote: > Hello everybody, > > for those of you who were not at ESUG, I present ShoreLine Reporter. > > ShoreLine Reporter is a Pharo plugin to collect stack traces from > exceptions and send them to a central repository. > You can give feedback to the community by breaking things: how cool is > that? > > > * Why? > > We are collecting stack traces for research purposes and to identify > the Pharo components that can be improved or optimized. > We are also working on a web platform where users can access the > submitted data and use them during the debugging process. More on that > soon! > > > * How? > > You can install ShoreLine Reporter by visiting the project page on > SmalltalkHub: > http://www.smalltalkhub.com/#!/~dalsat/ShoreLine-Reporter/ > > Installing ShoreLine Reporter requires only a couple of seconds, and > you can configure it with the level of feedback that you prefer. On > the SmalltalkHub page you can find a script to automatically install > ShoreLine Reporter with every new Pharo image. Just drop it in your > Pharo preferences directory and forget about it. > > Once ShoreLine Report is installed, you can decide to configure if you > want to be prompted to submit a stack trace, or to automatically > submit each exception without any bother. > > > * What? > > We try to collect as few data as possible: the execution stacktrace, > the name of the author and the Pharo build. We do *not* any collect > personal data, such as passwords or repositories. The data is > currently stored on our server, at the University of Lugano. > > > * Compatibility > > ShoreLine Reporter is developed for the Pharo debugger. We are > improving ShoreLine Reporter to work with GTInspector, we will push an > update in the following days. > > > For any problem, contact me! > > Thanks, hope to see a lot of your exceptions ;-) > Tommaso Dal Sasso @ REVEAL > >

Oct. 27, 2014

Re: [Pharo-dev] ShoreLine Reporter - A tool to collect stack traces

by Marcus Denker

I was thinking... would it make sense to have this in the image by default? On Tue, Oct 7, 2014 at 6:23 PM, Tommaso Dal Sasso < tommaso.dalsasso(a)gmail.com> wrote: > Hello everybody, > > for those of you who were not at ESUG, I present ShoreLine Reporter. > > ShoreLine Reporter is a Pharo plugin to collect stack traces from > exceptions and send them to a central repository. > You can give feedback to the community by breaking things: how cool is > that? > > > * Why? > > We are collecting stack traces for research purposes and to identify the > Pharo components that can be improved or optimized. > We are also working on a web platform where users can access the submitted > data and use them during the debugging process. More on that soon! > > > * How? > > You can install ShoreLine Reporter by visiting the project page on > SmalltalkHub: > http://www.smalltalkhub.com/#!/~dalsat/ShoreLine-Reporter/ > > Installing ShoreLine Reporter requires only a couple of seconds, and you > can configure it with the level of feedback that you prefer. On the > SmalltalkHub page you can find a script to automatically install ShoreLine > Reporter with every new Pharo image. Just drop it in your Pharo preferences > directory and forget about it. > > Once ShoreLine Report is installed, you can decide to configure if you > want to be prompted to submit a stack trace, or to automatically submit > each exception without any bother. > > > * What? > > We try to collect as few data as possible: the execution stacktrace, the > name of the author and the Pharo build. We do *not* any collect personal > data, such as passwords or repositories. The data is currently stored on > our server, at the University of Lugano. > > > * Compatibility > > ShoreLine Reporter is developed for the Pharo debugger. We are improving > ShoreLine Reporter to work with GTInspector, we will push an update in the > following days. > > > For any problem, contact me! > > Thanks, hope to see a lot of your exceptions ;-) > Tommaso Dal Sasso @ REVEAL > > -- -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Oct. 27, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40330 Home: https://github.com/pharo-project/pharo-core

Oct. 27, 2014

[pharo-project/pharo-core] 2d2145: 40330

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 2d21456b96bf7019d03f220ca0325968f9a7ef4d https://github.com/pharo-project/pharo-core/commit/2d21456b96bf7019d03f220c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-27 (Mon, 27 Oct 2014) Changed paths: A Kernel.package/Float.class/instance/comparing/literalEqual_.st A KernelTests.package/FloatTest.class/instance/tests - compare/testLiteralEqual.st M Morphic-Core.package/WorldState.class/instance/stepping/runLocalStepMethodsIn_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script330.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40330.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40330 14324 ThemeIcons has a class instance var "icons" that is not used https://pharo.fogbugz.com/f/cases/14324 14316 Float zero and negative zero should not be #literalEqual: https://pharo.fogbugz.com/f/cases/14316 14322 fixed WorldSate>>#runLocalStepMethodsIn: https://pharo.fogbugz.com/f/cases/14322 http://files.pharo.org/image/40/40330.zip

Oct. 27, 2014

Re: [Pharo-dev] How to add a trait to a class from an external package?

by phil＠highoctane.be

Basically, plugging a trait in a class dynamically should be doable. Especially with our beloved platform that can ;-) Otherwise, this reduces their usefulness quite a lot for composing things cleanly. Hey, Javascript people can do these things. Admittedly, all is dirty all the time there .... :-p Phil â

Oct. 27, 2014

Re: [Pharo-dev] How to add a trait to a class from an external package?

by Yuriy Tymchuk

By the way, this is an interesting conceptual question. Because couple of times Iâve encountered this problem that I had to extend different entities with the same methods, which results in duplication. Uko > On 27 Oct 2014, at 11:31, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 27.10.2014, at 11:27, phil(a)highoctane.be <mailto:phil@highoctane.be> wrote: >> >> On Mon, Oct 27, 2014 at 11:18 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> >> > On 27.10.2014, at 11:16, phil(a)highoctane.be <mailto:phil@highoctane.be> wrote: >> > >> > I have a TCXTBSButton trait that I want to add to a couple of WA classes. >> > >> > Now, I do not want to touch the WA classes as it would mean that I have to maintain them on my own, which isn't good. >> > >> > So, how do I add a trait to a class without changing its code? >> > Programmatically adding a trait to a class on package/configuration load. >> > >> > For methods, I can do a *myownpackage so that things will be saved there. >> > >> > But for traits, I do not know how. >> > >> > Help :-) >> >> I donât think thereâs any other option than doing a postload and recompiling those classes. Obviously, the packages of those classes will become dirty. >> >> Annoying. I do not want them dirty. >> >> In the meantime, I have subclassed the TagBrush I need and added the trait there. >> But that's a pain for all other features that do use the superclass as such. >> >> Phil > > If youâre adventurous you could maybe copy the methods from the trait to the classes and classify them as extensions of your package. Then at least only your package would be dirtyâ¦ > > But yeah, not very nice... > >> >> >> > >> > Phil

Oct. 27, 2014

Re: [Pharo-dev] How to add a trait to a class from an external package?

by Max Leske

> On 27.10.2014, at 11:27, phil(a)highoctane.be wrote: > > On Mon, Oct 27, 2014 at 11:18 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > > > On 27.10.2014, at 11:16, phil(a)highoctane.be <mailto:phil@highoctane.be> wrote: > > > > I have a TCXTBSButton trait that I want to add to a couple of WA classes. > > > > Now, I do not want to touch the WA classes as it would mean that I have to maintain them on my own, which isn't good. > > > > So, how do I add a trait to a class without changing its code? > > Programmatically adding a trait to a class on package/configuration load. > > > > For methods, I can do a *myownpackage so that things will be saved there. > > > > But for traits, I do not know how. > > > > Help :-) > > I donât think thereâs any other option than doing a postload and recompiling those classes. Obviously, the packages of those classes will become dirty. > > Annoying. I do not want them dirty. > > In the meantime, I have subclassed the TagBrush I need and added the trait there. > But that's a pain for all other features that do use the superclass as such. > > Phil If youâre adventurous you could maybe copy the methods from the trait to the classes and classify them as extensions of your package. Then at least only your package would be dirtyâ¦ But yeah, not very nice... > > > > > > Phil

Oct. 27, 2014

Re: [Pharo-dev] How to add a trait to a class from an external package?

by phil＠highoctane.be

On Mon, Oct 27, 2014 at 11:18 AM, Max Leske <maxleske(a)gmail.com> wrote: > > > On 27.10.2014, at 11:16, phil(a)highoctane.be wrote: > > > > I have a TCXTBSButton trait that I want to add to a couple of WA classes. > > > > Now, I do not want to touch the WA classes as it would mean that I have > to maintain them on my own, which isn't good. > > > > So, how do I add a trait to a class without changing its code? > > Programmatically adding a trait to a class on package/configuration load. > > > > For methods, I can do a *myownpackage so that things will be saved there. > > > > But for traits, I do not know how. > > > > Help :-) > > I donât think thereâs any other option than doing a postload and > recompiling those classes. Obviously, the packages of those classes will > become dirty. > Annoying. I do not want them dirty. In the meantime, I have subclassed the TagBrush I need and added the trait there. But that's a pain for all other features that do use the superclass as such. Phil > > > > > Phil > > >

Oct. 27, 2014