October 2014 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

Oct. 27, 2014

[pharo-project/pharo-core] c0f42d: 40331

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: c0f42dece0f18b0fa05bc68473aa5bf3ec9cfa5c https://github.com/pharo-project/pharo-core/commit/c0f42dece0f18b0fa05bc684… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-27 (Mon, 27 Oct 2014) Changed paths: M Morphic-Core.package/WorldState.class/instance/stepping/runLocalStepMethodsIn_.st R OpalCompiler-Core.package/CCompilationContext.class/instance/options/optionIlineNone.st A OpalCompiler-Core.package/CCompilationContext.class/instance/options/optionInlineNone.st R OpalCompiler-Core.package/CompilationContext.class/instance/options/optionIlineNone.st A OpalCompiler-Core.package/CompilationContext.class/instance/options/optionInlineNone.st M OpalCompiler-Core.package/OpalCompiler.class/class/options/defaultOptions.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script331.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40331.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40331 14329 Playground "print it" does not work anymore since 40 #330 https://pharo.fogbugz.com/f/cases/14329 14328 Typo: optionIlineNone => optionInlineNone https://pharo.fogbugz.com/f/cases/14328 http://files.pharo.org/image/40/40331.zip

Oct. 27, 2014

Re: [Pharo-dev] Experience makers

by Ben Coman

Yuriy Tymchuk wrote: > To summarise Iâd like to propose adding startup scripts manager to pharo luncher. Whatâs more, usually we are working on our one âprojectâ. And as itâs a good practice to start from a fresh image, we either have to load a configuration of it into fresh images or download pre-built image from CI. And we are too bound to CI because of image building. What I see as next step in the development workflow, is to say to the launcher: I want this Project is this Image (3.0, 4.0) with this prefs (experiences). The launcher builds the thing and you can work with it. > > In general I like your idea a lot, but letâs have a little discussion to hear what the others have to say. > > Uko That would be a REALLY cool. Something like like a CI builder for home? Doubly cool if the framework could be bent to do something like the following scenarios... 1. A menu item "Test A Slice" that asks for a case number, creates a new image from the latest "Local" template, named like... "Case12345-Build40230 The Case Description" then on that image runs a script that a. Opens Inbox repository b. Adds slice number to filter c. For latest slice, clicks <Changes>. "as a reference after merge" d. For latest slice, clicks <Merge>, then waits for user interaction. 2. Allow user to define a test script to be run across multiple images, in a binary search pattern, to help isolate the first occurrence of a bug. cheers -ben > >> On 27 Oct 2014, at 13:13, stepharo <stepharo(a)free.fr> wrote: >> >> 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] convention for examples?

by Andrei Chis

Hi Stef, I renamed the pragmas that we used in the inspector to <example> and <example: 'Title'> (the method can have any name) It will be integrated with the next GTools version and then we can iterate (keep the pragmas, move examples to other classes, etc) Cheers, Andrei On Mon, Oct 27, 2014 at 9:15 AM, stepharo <stepharo(a)free.fr> wrote: > Hi doru and others > > so finally what is the conventions we should use for example? > > exampleFooBar > <example> > > Stef > > >

Oct. 27, 2014

Re: [Pharo-dev] convention for examples?

by Pablo Estefo

I agree with kilon. Sorry if it is an stupid question but why not identify them by grouping into "examples" protocols? The rule could be matching "examples*" named protocols, then you can group examples that match different features ("examples-featureA", "examples-featureB" ...). On 27 October 2014 13:56, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > So you can both name your example whatever you want and keep your code > separate , clean and nice. > I believe the reason for convention was clickable examples in system > browser. So as far as tests go even if they are in separate classes you can > only run methods beginning with 'test' and not other support (setUp/..) > methods. The same would go for examples. You may need other non-example > methods to run the example so you need to discriminate them. > > Also shouldn't this convention for pragmas vs method names be more global? > For example > ComposableModel class>>defaultSpec vs <spec> and so on. > > Peter > > On Mon, Oct 27, 2014 at 1:33 PM, kilon alios <kilon.alios(a)gmail.com> > wrote: > >> I am not a fan of pragmas myself, but then I am also not an enemy. >> >> Personal I would prefer if we would follow a similar approach to unit >> testing, meaning separate classes for examples. I dont like the idea of >> mixing regular code with examples even just for a single example. Separate >> class will also mean there would be no need for the name of the method to >> contain "example". So you can both name your example whatever you want and >> keep your code separate , clean and nice. >> >> On Mon, Oct 27, 2014 at 2:15 PM, stepharo <stepharo(a)free.fr> wrote: >> >>> Hi doru and others >>> >>> so finally what is the conventions we should use for example? >>> >>> exampleFooBar >>> <example> >>> >>> Stef >>> >>> >>> >> >

Oct. 27, 2014

Re: [Pharo-dev] convention for examples?

by Peter UhnÃ¡k

> So you can both name your example whatever you want and keep your code separate , clean and nice. I believe the reason for convention was clickable examples in system browser. So as far as tests go even if they are in separate classes you can only run methods beginning with 'test' and not other support (setUp/..) methods. The same would go for examples. You may need other non-example methods to run the example so you need to discriminate them. Also shouldn't this convention for pragmas vs method names be more global? For example ComposableModel class>>defaultSpec vs <spec> and so on. Peter On Mon, Oct 27, 2014 at 1:33 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > I am not a fan of pragmas myself, but then I am also not an enemy. > > Personal I would prefer if we would follow a similar approach to unit > testing, meaning separate classes for examples. I dont like the idea of > mixing regular code with examples even just for a single example. Separate > class will also mean there would be no need for the name of the method to > contain "example". So you can both name your example whatever you want and > keep your code separate , clean and nice. > > On Mon, Oct 27, 2014 at 2:15 PM, stepharo <stepharo(a)free.fr> wrote: > >> Hi doru and others >> >> so finally what is the conventions we should use for example? >> >> exampleFooBar >> <example> >> >> Stef >> >> >> >

Oct. 27, 2014

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

by kilon alios

pretty every one does this nowdays since most people are too busy or dont care about bug reports it would make sense for a dialog to pop up the first time to ask the user if he allows the tool to collect information and then store that to the image so it can collect the info so it wont have to bother the user again. Standard practice. On Mon, Oct 27, 2014 at 2:01 PM, Marcus Denker <marcus.denker(a)inria.fr> 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> 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

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

by Esteban A. Maringolo

I wonder how JavaScript guys manage which behavior comes from base and which from a mixin. :) I used ExtJS, and you could do extensive use of mixins, but once they were mixed, it's all the same piece of code. I started using Traits and then moved away back to good'ol subclassification and, in some cases, code duplication. Regards! Esteban A. Maringolo 2014-10-27 7:44 GMT-03:00 phil(a)highoctane.be <phil(a)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] Experience makers

by Yuriy Tymchuk

To summarise Iâd like to propose adding startup scripts manager to pharo luncher. Whatâs more, usually we are working on our one âprojectâ. And as itâs a good practice to start from a fresh image, we either have to load a configuration of it into fresh images or download pre-built image from CI. And we are too bound to CI because of image building. What I see as next step in the development workflow, is to say to the launcher: I want this Project is this Image (3.0, 4.0) with this prefs (experiences). The launcher builds the thing and you can work with it. In general I like your idea a lot, but letâs have a little discussion to hear what the others have to say. Uko > On 27 Oct 2014, at 13:13, stepharo <stepharo(a)free.fr> wrote: > > 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] convention for examples?

by kilon alios

I am not a fan of pragmas myself, but then I am also not an enemy. Personal I would prefer if we would follow a similar approach to unit testing, meaning separate classes for examples. I dont like the idea of mixing regular code with examples even just for a single example. Separate class will also mean there would be no need for the name of the method to contain "example". So you can both name your example whatever you want and keep your code separate , clean and nice. On Mon, Oct 27, 2014 at 2:15 PM, stepharo <stepharo(a)free.fr> wrote: > Hi doru and others > > so finally what is the conventions we should use for example? > > exampleFooBar > <example> > > Stef > > >

Oct. 27, 2014