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

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/… 1 regressions found. Zinc.Zodiac.ZnHTTPSTests.testGetPharoVersion

Sept. 17, 2013

[update 3.0] #30404

by Marcus Denker

30404 ----- 11622 remove bogus method in Number https://pharo.fogbugz.com/f/cases/11622 11621 New widget to edit an ordered list https://pharo.fogbugz.com/f/cases/11621 11627 prevent completion from popping out with empty list https://pharo.fogbugz.com/f/cases/11627 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.243… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Critics-MarcusDen… http://smalltalkhub.com/mc/Pharo/Pharo30/main/NECompletion-MarcusDenker.133… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1613.diff

Sept. 17, 2013

Re: [Pharo-dev] Maybe fixed?

by Friedrich Dominicus

Marcus Denker <marcus.denker(a)inria.fr> writes: > On Sep 16, 2013, at 11:12 AM, Friedrich Dominicus > <frido(a)q-software-solutions.de> wrote: > >> Marcus Denker <marcus.denker(a)inria.fr> writes: >> >>> On Sep 13, 2013, at 8:50 AM, Friedrich Dominicus >>> <frido(a)q-software-solutions.de> wrote: >>> >>>> I guess I found a bug in Browser>openAsMorphClassEditing >>> >>> I can not find this method in Pharo3 or Pharo2. >>> >>> Which version are you using? >> Pharo 2.0 with Nautilus. >> >> >> >>> >>> In general, we should remove the old Browser soon. It is not used. >> I don't know but it seemed to be used hereâ¦ >> > This is really strange: there are no references to class Browser, > > both > > Smalltalk tools browser > SystemBrowser default > > return Nautilus. > > Do you have an idea in which situation this happens? Sorry, I have tried to load some software into the image. I think it was BabyMock. There is a visual representation of the calles running and in the top you can click on a rectangle. I clicked on one of the rectangles and the MNU showed. I checked the code and have seen that asLayoutFrame was missing, I added it and the stuff runs. Regards Friedrich

Sept. 17, 2013

Re: [Pharo-dev] Seaside Continuous Integration on ci.inria.fr

by Tudor Girba

+100 This is so important. Doru On Sep 16, 2013, at 6:09 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I deeply appreciate your effort and I want to thank the seaside group. > > Stef > > On Sep 16, 2013, at 11:20 AM, Philippe Marschall <kustos(a)gmx.net> wrote: > >> Hi >> >> This is a short write up on the state of Seaside on ci.inria.fr. >> >> After a week of work we have Metacello based builds running green at ci.inria.fr. >> >> Grease 1.0 and 1.1 are green on both Pharo 2.0 and 3.0 [1]. Updating Pier 3 to use the latest Grease 1.0 should fix the Pier 3 build. >> >> For Seaside 3.x we load the Metacello group 'CI' and run the tests in the packages matching the following regex >> ((Seaside)|(Comet)|(Javascript)|(RSS)|(JQuery)|(Prototype)|(Scriptaculous))-.*. Currently we have no way of running SLint/Slime and fake Checkstyle like in [3]. If anybody knows how to do with please let us know. There are still some issues with file library in Pharo 3.0 and Seaside 3.0. They are only fixed in Seaside 3.1. >> >> Please try to keep the build green, otherwise we'll get spammed with emails. >> >> Currently we keep all the build (5GB already). Do we really need this? >> >> [1] https://ci.inria.fr/pharo-contribution/job/Grease/ >> [2] https://ci.inria.fr/pharo-contribution/job/Seaside/ >> [3] http://jenkins.lukas-renggli.ch/view/Seaside%203.1/job/Seaside%203.1/ >> >> Cheers >> Philippe >> >> > > -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

Sept. 17, 2013

scripts for automating the moose release

by Tudor Girba

Hi, I wrote a little blog post describing the process of releasing Moose: http://www.humane-assessment.com/blog/automating-moose-4-8-release Perhaps this might be useful for others. And perhaps we can find ways to improve it. Cheers, Doru -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

Sept. 17, 2013

Re: [Pharo-dev] moose build under 2.0

by Tudor Girba

Indeed. Torsten pointed out the same thing. We will look into it. Doru On Sep 16, 2013, at 11:15 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > actually you pointed out the problem :) > > we previously load seaside into the same image, seems like the grease versions do not like each other very much ;) > > > On 2013-09-16, at 17:26, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> We typically load development on the CI server: >> >> REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main >> ./pharo $JOB_NAME.image config $REPO ConfigurationOfMoose --install=development >> >> But, I think you are doing something else other than loading the code, and I think the problem is that at least in the version that we load, Grease defines its own package implementation which conflicts with RPackage. Could you confirm? >> >> Cheers, >> Doru >> >> >> >> On Sep 16, 2013, at 8:51 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> I'm trying to fix the VM acceptance test. I currently have troubles loading moose. >>> What is the standard location of the configuration for Pharo 2.0? >>> >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> + ./pharo ./Pharo.image config http://www.smalltalkhub.com/mc/Moose/Moose/main >>> ConfigurationOfMoose --install=stable >>> >>> >>> =============================================================================== >>> Notice: Installing ConfigurationOfMoose stable >>> =============================================================================== >>> >>> ==== Startup Error: GRError: 'Grease-Tests-Pharo-Core' depends on unknown package 'Grease-Pharo-Core' >>> >>> GRPackage class(GRObject class)>>error: >>> GRPackage(GRObject)>>error: >>> GRPackage>>resolveWith: in Block: [self error: self name printString , ' depends on ...etc... >>> Dictionary>>at:ifAbsent: >>> GRPackage>>resolveWith: in Block: [:each | aDictionary... >>> OrderedCollection>>collect: >>> GRPackage>>resolveWith: >>> GRPackage class>>packages in Block: [:each | each resolveWith: packages] >>> ... >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> >> >> -- >> www.tudorgirba.com >> >> "Every now and then stop and ask yourself if the war you're fighting is the right one." >> >> >> >> > -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

Sept. 17, 2013

Re: [Pharo-dev] Issues trying to use NewList on Nautilus

by Nicolas Passerini

> If your UI is based on multi selection (and Nautilus definitely is) you > should not register to whenSelectedIndexChanged:/whenSelectedItemChanged:, > but only the plural version. > Ok, I get that. Still, when you create a NewList you have to provide a setIndexSelector, for example in the CategoryWidget I am doing: categoriesList := NewList on: self getItemsSelector: #getCategories setIndexSelector: #selectedCategoryIndex: getDisplaySelector: #categoryWrapper:. So, every time you click on the categories list (both selecting multiple categories or not) the CategoryWidget receives the #selectedCategoryIndex: message. The current selectedCategoryIndex: message reads like this: selectedCategoryIndex: anInteger | anObject | anObject := self getCategories at: anInteger ifAbsent: [ nil ]. self model selectedCategory: anObject. self changed: #selectedCategoryIndex. self model categorySelectionChanged. self model changed: #currentHistoryIndex. Also the NewList is in the list of dependents of the CategoryWidget, so it also gets the #update: message Is this right?

Sept. 17, 2013

Re: [Pharo-dev] Annotating classes

by kilon

yeah I think option b is better cause it does not "corrupt" existing code. This way I wont have to modify existing classes to add those tags. I could even tag group of classes or group of methods ( or protocols ). Igor Stasenko wrote > there's only two practical ways (which i know and use) of associating > extra > state per object: > - internal: by extending object's state via directly adding extra > instance > variable (or indirectly like Morphic's properties) > - external: creating a map (aka dictionary) which maps between your > domain > object(s) and its corresponding extra state. > > i do not see how classes (like any other object) is exception from that. > > > > On 13 September 2013 09:40, kilon < > thekilon@.co > > wrote: > >> I like to hear some more details on this and other opinions too. >> >> One of the thing I want to work is a new SystemBrowser with more flexible >> browsing system. I take inspiration from preset browsers in software >> sysnthesizers. Each preset represent a sound that can be manipulated with >> real time controls, the problem is that there thousands of presets the >> same >> way there are thousands of classes. The initial implementation was to >> brake >> presets to groups / categories , same way SystemBrowser has packages. >> Unfortunately that still made browsing through presets very tedious and >> long >> process. >> >> The modern system is tag based , for example if I want to select a sound >> present I a presented with a row and columns of buttons, each row is a >> category of tags , each cell is a tag. For example I could choose Timbre >> : >> metalic , Type: pad, Speed: fast, Rythm : non-rythmic etc these >> criterias >> then would allow me to browse only a limited amount of presets having >> those >> tags. I would have to reset the browser (which disables all tag choices) >> to >> view all presets again. >> >> I am considering implementing something similar for class and even >> methods. >> At first I was considering what Igor said, an instance variable that >> contained a dictionary/hash-table associating tags with their categories >> providing also a gui to set those tags easily. However I was wondering >> like >> the original poster if there is a better way to "annotate" classes and if >> there is any way to "annotate" methods . >> >> >> Esteban A. Maringolo wrote >> > Isn't answering to a message not enough? >> > >> > Like #nbStruc #ormTableName etc. >> > >> > Pragmas are somehow orthogonal to the common message sending and method >> > lookup. >> > >> > >> > Esteban A. Maringolo >> > >> > >> > 2013/9/12 Igor Stasenko < >> >> > siguctua@ >> >> > > >> > >> >> >> >> >> >> >> >> On 12 September 2013 13:56, Torsten Bergmann < >> >> > astares@ >> >> > > wrote: >> >> >> >>> We can mark methods with pragmas and ask the pragma collector >> >>> to give the methods marked with it. >> >>> >> >>> Do we (already) have some kind of pragma like mechanism to annotate >> >>> classes? I mean a general mechanism that one can use to mark classes >> >>> with pragmas/settings/ ...? >> >>> >> >>> There are various scenarios where this might be useful: >> >>> - an ORM mapper would like to associate a persistence class with a >> >>> table name >> >>> - an NBExternalStructure subclass wrapping a structure can be >> >>> annotated >> >>> with >> >>> the original struct name >> >>> - ... >> >>> >> >>> >> >> Why so complicated (e.g. pragmas) ? Just add one more inst var , like >> >> 'annotation' for Class object >> >> and you have it. >> >> >> >> >> >>> Thx >> >>> T. >> >>> >> >>> >> >>> >> >> >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko. >> >> >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Annotating-classes-tp4707854p4708033.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> > > > -- > Best regards, > Igor Stasenko. -- View this message in context: http://forum.world.st/Annotating-classes-tp4707854p4708669.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 16, 2013

Re: [Pharo-dev] Please help us by buying the book

by kilon

how long for the amazon version ? I am Greek and I am not sure if the first choice delivers here. -- View this message in context: http://forum.world.st/Please-help-us-by-buying-the-book-tp4708575p4708667.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 16, 2013

Re: [Pharo-dev] moose build under 2.0

by Camillo Bruni

actually you pointed out the problem :) we previously load seaside into the same image, seems like the grease versions do not like each other very much ;) On 2013-09-16, at 17:26, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > We typically load development on the CI server: > > REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main > ./pharo $JOB_NAME.image config $REPO ConfigurationOfMoose --install=development > > But, I think you are doing something else other than loading the code, and I think the problem is that at least in the version that we load, Grease defines its own package implementation which conflicts with RPackage. Could you confirm? > > Cheers, > Doru > > > > On Sep 16, 2013, at 8:51 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> I'm trying to fix the VM acceptance test. I currently have troubles loading moose. >> What is the standard location of the configuration for Pharo 2.0? >> >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> + ./pharo ./Pharo.image config http://www.smalltalkhub.com/mc/Moose/Moose/main >> ConfigurationOfMoose --install=stable >> >> >> =============================================================================== >> Notice: Installing ConfigurationOfMoose stable >> =============================================================================== >> >> ==== Startup Error: GRError: 'Grease-Tests-Pharo-Core' depends on unknown package 'Grease-Pharo-Core' >> >> GRPackage class(GRObject class)>>error: >> GRPackage(GRObject)>>error: >> GRPackage>>resolveWith: in Block: [self error: self name printString , ' depends on ...etc... >> Dictionary>>at:ifAbsent: >> GRPackage>>resolveWith: in Block: [:each | aDictionary... >> OrderedCollection>>collect: >> GRPackage>>resolveWith: >> GRPackage class>>packages in Block: [:each | each resolveWith: packages] >> ... >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> > > -- > www.tudorgirba.com > > "Every now and then stop and ask yourself if the war you're fighting is the right one." > > > >

Sept. 16, 2013