- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Using TreeModel>>selectAll

by StÃ©phane Ducasse

In the midterm would it not be better to start a new implementation? Stef On Dec 11, 2013, at 11:18 PM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > Thatâs the default behaviour > > I was thinking today of introducing a special one which act as you described > > Ben > > On 11 Dec 2013, at 21:49, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> One thing I didn't understand is, are valueholders supposed to announce changes, even if >> the "value" didn't changed? >> >> |log node | >> log := OrderedCollection new. >> node:= >> TreeNodeModel new >> content: $a; >> whenSelectedChanged:[:item | self halt.log add:item]; >> selected: true; >> selected: true; >> selected: true. >> log >> >> will log three times, even the value (selected=true) didn't changed at all. >> (or at most one if "selected" is initialized with false). >> >> Nicolai >> >> >> >> 2013/12/9 Martin Dias <tinchodias(a)gmail.com> >> thanks for your help, Ben >> >> On Mon, Dec 9, 2013 at 11:15 AM, Benjamin >> <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: >> > I am still chasing why itâs executed three times >> > >> > Must be an issue in the info propagation. >> > >> > Ben >> > >> > On 09 Dec 2013, at 06:48, Martin Dias <tinchodias(a)gmail.com> wrote: >> > >> > Hi, I'm back with more annoying questions :) >> > >> > Using #whenSelectedItemsChanged:, I see that the block is evaluated a lot of >> > times: >> > >> > log := OrderedCollection new. >> > roots := #(1 2) collect: [ :each | >> > TreeNodeModel new >> > content: each; >> > selected: true; >> > yourself ]. >> > >> > TreeModel new >> > roots: roots; >> > multiSelection: true; >> > whenSelectedItemsChanged: [ :items | >> > log add: items ]; >> > openWithSpec. >> > log ---> an OrderedCollection(#() an OrderedCollection(1) an >> > OrderedCollection(1) an OrderedCollection(1 2) an OrderedCollection(1 2) an >> > OrderedCollection(1 2)) >> > >> > I'd expect only one evaluation... is it a bug or a feature? >> > >> > cheers, >> > MartÃn >> > >> > >> > On Sun, Dec 8, 2013 at 12:22 AM, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> >> >> aha! thanks >> >> >> >> MartÃn >> >> >> >> On Sat, Dec 7, 2013 at 10:33 AM, Benjamin >> >> <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: >> >> > roots := #(1 2 3) collect: [ :e | TreeNodeModel new content: e ; >> >> > yourself ]. >> >> > >> >> > TreeModel new >> >> > roots: roots; >> >> > multiSelection: true; >> >> > openWithSpec. >> >> > >> >> > roots third >> >> > selected: true; >> >> > takeHighlight >> >> > >> >> > Ben >> >> > >> >> > On 07 Dec 2013, at 05:44, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> > >> >> > ouch! thanks Ben. >> >> > >> >> > Another related question: is there any way of selecting an arbitrary >> >> > item? I tried (among others) with: >> >> > >> >> > TreeModel new >> >> > roots: #(1 2 3); >> >> > multiSelection: true; >> >> > openWithSpec; >> >> > selection: 3 >> >> > >> >> > without success. >> >> > >> >> > Cheers, >> >> > MartÃn >> >> > >> >> > >> >> > >> >> > On Thu, Dec 5, 2013 at 4:17 PM, Benjamin >> >> > <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: >> >> > >> >> > your tree here is single selection so it will not work >> >> > >> >> > TreeModel new >> >> > roots: #(1 2 3); >> >> > multiSelection: true; >> >> > openWithSpec; >> >> > selectAll >> >> > >> >> > Ben >> >> > >> >> > On 05 Dec 2013, at 15:38, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> > >> >> > Hi, >> >> > >> >> > I'm not sure how this method should be used. I tried in different >> >> > ways, for example: >> >> > >> >> > TreeModel new >> >> > roots: #(1 2 3); >> >> > selectAll; >> >> > openWithSpec >> >> > >> >> > But always the items are unselected. Is it a bug? or I didn't find the >> >> > way to use it? >> >> > >> >> > Thanks, >> >> > MartÃn >> >> > >> >> > >> >> > >> >> > >> > >> > >> > >> >> >

Dec. 12, 2013

Re: [Pharo-dev] Which tests should be run in CI?

by Marcus Denker

On 12 Dec 2013, at 06:31, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Stephan, > > Thanks for pushing the #packages problem. > > > But, it's strange that the Pharo3 build is not red. Could it be that the test was not integrated into Pharo? > the test tests that there is no #packages in Pharo on the class side other than the one that returns the rpackage istance. â> this is the case, the test is green. > The Moose jobs run the Moose-specific tests (those defined in the Tests group in the configuration). You are not running that test as you are only running the moose tests. Marcus

Dec. 12, 2013

Re: [Pharo-dev] Tell me about your workflow

by GOUBIER Thierry

If you would be ready to profile a package save on your repository, it would be great. In the mean time, I'll make available a special gitfiletree package to test. Which version of Pharo you are using? 2.0 or 3.0? Regards, Thierry ________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Sebastian Sastre [sebastian(a)flowingconcept.com] Date d'envoi : mercredi 11 dÃ©cembre 2013 17:09 Ã : Pharo Development List Objet : Re: [Pharo-dev] Tell me about your workflow ok, if saving is dumping all, then 3 is confirmed? After the first commit, I'd say so. about 2, I don't know. I'm available to make tests and measure results have a nice trip, keep us tuned about any progress On Dec 11, 2013, at 2:09 PM, Goubier Thierry <thierry.goubier(a)cea.fr<mailto:thierry.goubier@cea.fr>> wrote: Yes, you're right in the general case. But a solution to that general problem will take time to be implemented (time I lack at the moment, sadly) and if the main gain is a few % because it's writing the version file and the metadata for methods which are the "slow" factors, then we'll have worked hard for nothing. If you want to help, I'd really like to see either 2- or 3- confirmed. I can produce a special gitfiletree to remove writing the metadata, that you can try on a large project temporary copy; if the slow writing (and reading) is confirmed, then this is 3- (But I'm leaving on a trip tomorrow early, so I have no idea of when I'll have the time to do that :( ). Thierry Le 11/12/2013 16:44, Sebastian Sastre a Ã©crit : Without entering in details, a cause for slow package write is dumping all every time. For that strategy, we already have the image save which is magically fast. So, if we make something to scan the code and write only when it's different from what's on disk, then we would be preventing tons of redundant writes sebastian <https://about.me/sebastianconcept> o/ On Dec 11, 2013, at 1:43 PM, Goubier Thierry <thierry.goubier(a)cea.fr<mailto:thierry.goubier@cea.fr> <mailto:thierry.goubier@cea.fr>> wrote: Le 11/12/2013 16:27, Esteban Lorenzano a Ã©crit : ah, and IMHO the problem is not about reading... is about writing (if it has to write the metadata each time...). But, personnaly, I don't know if this is the reason for the lack of performance... I have three hypothesis for Sebastian problem: 1 - Slow read time for version metadata - Confirmed because of the 16 seconds wait time for reading the package metadata in the repository browser. 2 - Slow metadata write 3 - Slow package write I have an implemented solution for 1-, a very easy to implement for 2-, and none yet for 3- So I'd really like to check if 3- is confirmed ;) Thierry Esteban On Wed, Dec 11, 2013 at 4:24 PM, Esteban Lorenzano <estebanlm(a)gmail.com<mailto:estebanlm@gmail.com> <mailto:estebanlm@gmail.com> <mailto:estebanlm@gmail.com>> wrote: Thierry, I know there is a working version... let me search... (5 mins later) here: https://github.com/rjsargent/CypressReferenceImplementation Dale says Richard made a metadata-less version. We should take a look at that. Esteban On Wed, Dec 11, 2013 at 4:28 PM, Goubier Thierry <thierry.goubier(a)cea.fr<mailto:thierry.goubier@cea.fr> <mailto:thierry.goubier@cea.fr><mailto:thierry.goubier@cea.fr>> wrote: Esteban, Sebastian, In the filetree code, you will find a format without metadata, but it's not in use anymore. If you use gitfiletree, it will write the metadata for compatibility reasons with filetree, but it will never read it back. I'm pushing code to make filetree robust to absence of metadata, but I haven't worked on it for a while. gitfiletree has solved the problem of a slow metadata read. It does not solve any performance problem associated with writing, yet. Thierry Le 11/12/2013 16:12, Esteban Lorenzano a Ã©crit : I know there is a version of filetree without metadata (more compelling for projects that will never use other formats). Dale told me that there was a preview somewhere, but I didn't tested yet (lack of time) and now I cannot find the mail... Dale, can you re-send the link? cheers, Esteban On Wed, Dec 11, 2013 at 4:08 PM, Sebastian Sastre <sebastian(a)flowingconcept.com<mailto:sebastian@flowingconcept.com> <mailto:sebastian@flowingconcept.com> <mailto:sebastian@flowingconcept.com> <mailto:sebastian@__flowingconcept.com <mailto:sebastian@flowingconcept.com>>> wrote: I should breath before I type, but you probably already got that I meant /redundant writes/ (not reads)... Anyway.. I was talking with Esteban and he mentions some kind of compatibility metadata. If I'm going to give a leap of faith to filetree repos to save code why should I care about mcz compatibility? Paying a toll for no reason is evil. Maybe we could make that optional so those who don't extract value from that feature can opt-out? sebastian <https://about.me/__sebastianconcept <https://about.me/sebastianconcept>> o/ On Dec 11, 2013, at 12:44 PM, Sebastian Sastre <sebastian(a)flowingconcept.com<mailto:sebastian@flowingconcept.com> <mailto:sebastian@flowingconcept.com> <mailto:sebastian@flowingconcept.com> <mailto:sebastian@__flowingconcept.com <mailto:sebastian@flowingconcept.com>>> wrote: Hi Thierry On Dec 11, 2013, at 12:43 PM, Goubier Thierry <thierry.goubier(a)cea.fr<mailto:thierry.goubier@cea.fr> <mailto:thierry.goubier@cea.fr> <mailto:thierry.goubier@cea.fr> <mailto:thierry.goubier@cea.fr <mailto:thierry.goubier@cea.fr>__>> wrote: I have packages (in the order of hundreds of classes) and save delays and package click delays are starting to demand patience in a way that doesn't feel like the right path Which operations ? I didn't remember noticing much with 179 classes on a laptop without a SSD. choose one. Just for clicking the package that will should you UUID, version and author I need to wait ~16 seconds. Sounds like a lot of overhead for reading a small .json file. But the write is the most worrisome All that is with a SSD disk, otherwise save delays would be /way/ beyond unacceptable I'd like to know more, and understand the reason, for sure. As far as I know, filetree will rewrite the whole package to disk everytime... and maybe optimising that could be the solution. Well, that explains a lot. Writing all every time is the lazy thing that's okay for a prototype and temporary code in a proof of concept but that massive redundant reads certainly doesn't sounds like pro software. Specially for SSD's which has a limited quantity of writes Thierry sebastian <https://about.me/__sebastianconcept <https://about.me/sebastianconcept>> o/ -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 <tel:%2B33%20%280%29%201%2069%2008%2032%2092> <tel:%2B33%20%280%29%201%2069%__2008%2032%2092> / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 <tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Dec. 12, 2013

Re: [Pharo-dev] Which tests should be run in CI?

by Tudor Girba

Hi Stephan, Thanks for pushing the #packages problem. The Moose jobs run the Moose-specific tests (those defined in the Tests group in the configuration). But, it's strange that the Pharo3 build is not red. Could it be that the test was not integrated into Pharo? Cheers, Doru Cheers, Doru On Wed, Dec 11, 2013 at 9:36 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Torsten, > > For unit tests building on green builds might be enough, but what about > integration/smoke tests? > > Concrete case: I added a test to check that no class implements >>packages > That is a test that should be run by all builds, but is not. The > consequence is > that Moose and Pharo3 based builds using seaside or magritte can not > reliably use "senders of" > > I assume there are more tests like this. > > Stephan > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 12, 2013

Re: [Pharo-dev] Voronoi diagram

by Torsten Bergmann

Load it and then check class side methods in the classes of the packages There are many methods starting with "example" - just run them Â Bye T. Â

Dec. 11, 2013

Re: [Pharo-dev] Using TreeModel>>selectAll

by Benjamin

Thatâs the default behaviour I was thinking today of introducing a special one which act as you described Ben On 11 Dec 2013, at 21:49, Nicolai Hess <nicolaihess(a)web.de> wrote: > One thing I didn't understand is, are valueholders supposed to announce changes, even if > the "value" didn't changed? > > |log node | > log := OrderedCollection new. > node:= > TreeNodeModel new > content: $a; > whenSelectedChanged:[:item | self halt.log add:item]; > selected: true; > selected: true; > selected: true. > log > > will log three times, even the value (selected=true) didn't changed at all. > (or at most one if "selected" is initialized with false). > > Nicolai > > > > 2013/12/9 Martin Dias <tinchodias(a)gmail.com> > thanks for your help, Ben > > On Mon, Dec 9, 2013 at 11:15 AM, Benjamin > <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > > I am still chasing why itâs executed three times > > > > Must be an issue in the info propagation. > > > > Ben > > > > On 09 Dec 2013, at 06:48, Martin Dias <tinchodias(a)gmail.com> wrote: > > > > Hi, I'm back with more annoying questions :) > > > > Using #whenSelectedItemsChanged:, I see that the block is evaluated a lot of > > times: > > > > log := OrderedCollection new. > > roots := #(1 2) collect: [ :each | > > TreeNodeModel new > > content: each; > > selected: true; > > yourself ]. > > > > TreeModel new > > roots: roots; > > multiSelection: true; > > whenSelectedItemsChanged: [ :items | > > log add: items ]; > > openWithSpec. > > log ---> an OrderedCollection(#() an OrderedCollection(1) an > > OrderedCollection(1) an OrderedCollection(1 2) an OrderedCollection(1 2) an > > OrderedCollection(1 2)) > > > > I'd expect only one evaluation... is it a bug or a feature? > > > > cheers, > > MartÃn > > > > > > On Sun, Dec 8, 2013 at 12:22 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > >> > >> aha! thanks > >> > >> MartÃn > >> > >> On Sat, Dec 7, 2013 at 10:33 AM, Benjamin > >> <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > >> > roots := #(1 2 3) collect: [ :e | TreeNodeModel new content: e ; > >> > yourself ]. > >> > > >> > TreeModel new > >> > roots: roots; > >> > multiSelection: true; > >> > openWithSpec. > >> > > >> > roots third > >> > selected: true; > >> > takeHighlight > >> > > >> > Ben > >> > > >> > On 07 Dec 2013, at 05:44, Martin Dias <tinchodias(a)gmail.com> wrote: > >> > > >> > ouch! thanks Ben. > >> > > >> > Another related question: is there any way of selecting an arbitrary > >> > item? I tried (among others) with: > >> > > >> > TreeModel new > >> > roots: #(1 2 3); > >> > multiSelection: true; > >> > openWithSpec; > >> > selection: 3 > >> > > >> > without success. > >> > > >> > Cheers, > >> > MartÃn > >> > > >> > > >> > > >> > On Thu, Dec 5, 2013 at 4:17 PM, Benjamin > >> > <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > >> > > >> > your tree here is single selection so it will not work > >> > > >> > TreeModel new > >> > roots: #(1 2 3); > >> > multiSelection: true; > >> > openWithSpec; > >> > selectAll > >> > > >> > Ben > >> > > >> > On 05 Dec 2013, at 15:38, Martin Dias <tinchodias(a)gmail.com> wrote: > >> > > >> > Hi, > >> > > >> > I'm not sure how this method should be used. I tried in different > >> > ways, for example: > >> > > >> > TreeModel new > >> > roots: #(1 2 3); > >> > selectAll; > >> > openWithSpec > >> > > >> > But always the items are unselected. Is it a bug? or I didn't find the > >> > way to use it? > >> > > >> > Thanks, > >> > MartÃn > >> > > >> > > >> > > >> > > > > > > > > >

Dec. 11, 2013

Re: [Pharo-dev] Voronoi diagram

by Natalia Tymchuk

Hello. Cool. It is easy to download. Does anybody know how to use it, because there are no comments and tests? Best regards, Natalia 2013/12/10 NISHIHARA Satoshi <goonsh(a)gmail.com> > Voronoi-2d-Diagram, you can install from Configuration browser of 2.0. ;-) > > 2013/12/8 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > > Check this out > > > > http://www.smalltalkhub.com/#!/~goonsh/Voronoi-2d-Diagram > > http://www.squeaksource.com/VoronoiDiagram.html > > > > There is also an old package implementing Voronoi diagrams also, I can > have > > a look if you those are not enough for your needs. > > Cheers > > > > HernÃ¡n > > > > El 07/12/2013 13:59, Natalia Tymchuk escribiÃ³: > > > >> Hello. > >> I started implementing visualization of Voronoi diagrams and I need to > >> do a lot of operations on the lines and polygons. I have some questions: > >> Is it implemented somewhere? > >> Did somebody do something with the Voronoi diagrams? > >> > >> Best regards, > >> Natalia > >> > >> > > > > > > > > -- > -- > "NISHIHARA Satoshi" > [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] > >

Dec. 11, 2013

Re: [Pharo-dev] MessageNotUnderstood: SmallInteger>>isEmpty

by Esteban Lorenzano

I will promote the latest vm (latest before spur) as stable tomorrow morning. So I suppose he can try that :) Pharo-VM-mac-latest.zip<http://files.pharo.org/vm/pharo/mac/Pharo-VM-mac-latest.zip> cheers, Esteban On Wed, Dec 11, 2013 at 7:41 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 11 Dec 2013, at 19:37, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > Hi Dario, > > > > > > On Wed, Dec 11, 2013 at 12:41 AM, Dario Trussardi < > dario.trussardi(a)tiscali.it> wrote: > > Ciao Eliot, > > > > > >> Hi Dario, > >> > >> > >> On Tue, Dec 10, 2013 at 8:12 AM, Dario Trussardi < > dario.trussardi(a)tiscali.it> wrote: > >> Ciao, > >> > >> i work with a new Pharo 2.0 20628 image. > >> > >> I do first : > >> A) Gofer new url: ' > http://smalltalkhub.com/mc/DiegoLont/QCMagritte/main'; package: > 'ConfigurationOfQCMagritte'; load. > >> > >> and: > >> B) ((Smalltalk at: #ConfigurationOfQCMagritte) project > version: '0.2') load: #( 'Demo' ). > >> > >> After some works the system when Fetching 1.0.2.1 of > ConfigurationOfTwitteBootstrap > >> > >> erase the error: > >> > >> > >> SmallInteger(Object)>>doesNotUnderstand: #isEmpty > >> MetacelloMCVersionSpec>>resolveToLoadableSpecs:map: > >> MetacelloMCVersionSpec>>resolveToLoadableSpecs: > >> MetacelloMCVersionSpec>>expandToLoadableSpecNames: in Block: [:cache | > ... > >> > MetacelloPharoPlatform(MetacelloPlatform)>>stackCacheFor:cacheClass:at:doing: > in Block: [:dict | ... > >> > MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: > in Block: [^ aBlock value: dict] > >> BlockClosure>>on:do: > >> > MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: > >> > MetacelloPharoPlatform(MetacelloPlatform)>>stackCacheFor:cacheClass:at:doing: > >> MetacelloPharoPlatform(MetacelloPlatform)>>stackCacheFor:at:doing: > >> MetacelloMCVersionSpec>>expandToLoadableSpecNames: > >> MetacelloMCVersion>>expandToLoadableSpecNames: > >> MetacelloMCProjectSpec>>relativeCurrentVersion in Block: [vrsn > expandToLoadableSpecNames: (loadList := self...etc... > >> BlockClosure>>on:do: > >> MetacelloMCProjectSpec>>relativeCurrentVersion > >> MetacelloProjectReferenceSpec>>relativeCurrentVersion > >> MetacelloMCVersionSpec>>isPartiallyCurrentAgainst: in Block: [:prj | ... > >> MetacelloProjectReferenceSpec>>projectDo:packageDo:groupDo: > >> MetacelloMCVersionSpec>>specsNamed:projectDo:packageDo:groupDo: in > Block: [:name | | pkgSpec | (pkgSpec := map... > >> Array(SequenceableCollection)>>do: > >> MetacelloMCVersionSpec>>specsNamed:projectDo:packageDo:groupDo: > >> MetacelloMCVersionSpec>>isPartiallyCurrentAgainst: > >> MetacelloMCVersionSpec>>isPartiallyCurrent > >> MetacelloMCProject(MetacelloProject)>>currentVersionAgainst: in Block: > [:version | ... > >> Array(SequenceableCollection)>>do: > >> MetacelloMCProject(MetacelloProject)>>currentVersionAgainst: in Block: > [:cache | ... > >> > MetacelloPharoPlatform(MetacelloPlatform)>>stackCacheFor:cacheClass:at:doing: > in Block: [:dict | ... > >> > MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: > in Block: [^ aBlock value: dict] > >> BlockClosure>>on:do: > >> > MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: > >> > >> Any idea? > >> > >> I suspect you have an older, buggy, VM. What does the VM say to > -version? > > > > How i can define the VM that the system used ? > > > > The Mac finder has facilities for choosing an app for a document type. > google will find it quickly. > > > > In the menu System / System Reported i found this: > > > > Virtual Machine --------------- > /Users/dtr/Desktop/Pharo2.0.app/Contents/MacOS/Pharo NBCoInterpreter > NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 NBCogit > NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 git://gitorious > > .org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 > Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> > Jenkins build #14535 Mac Cocoa Cog 5.8b12 21-Sep-10 > >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< VMMaker versionString git:// > gitorious.org/cogvm/blessed.git Commit: > 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 > By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 NBCogit > NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > > > > It is significant ? > > > > yes. that VM is buggy. I suggest you use the most up-to-date Pharo VM. > Pharo VM guys, what VM would you recommend for Dario? > > http://www.pharo-project.org/ > > => > > http://www.pharo-project.org/pharo-download > > => > > http://files.pharo.org/vm/pharo/mac/Pharo-VM-mac-stable.zip > > Or did you already try this ? > > > In my MacBook i have run some Pharo version. > > > > For open the Pharo 2.0 i double click on the Pharo 2.0 icon on the > desktop. > > > > Right ? > > > > Thanks, > > > > Dario > > > >> > >> Thanks, > >> > >> Dario > >> > >> -- > >> HTH, > >> Eliot > > > > > > > > > > -- > > best, > > Eliot > > >

Dec. 11, 2013

Re: [Pharo-dev] Using TreeModel>>selectAll

by Nicolai Hess

One thing I didn't understand is, are valueholders supposed to announce changes, even if the "value" didn't changed? |log node | log := OrderedCollection new. node:= TreeNodeModel new content: $a; whenSelectedChanged:[:item | self halt.log add:item]; selected: true; selected: true; selected: true. log will log three times, even the value (selected=true) didn't changed at all. (or at most one if "selected" is initialized with false). Nicolai 2013/12/9 Martin Dias <tinchodias(a)gmail.com> > thanks for your help, Ben > > On Mon, Dec 9, 2013 at 11:15 AM, Benjamin > <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > > I am still chasing why itâs executed three times > > > > Must be an issue in the info propagation. > > > > Ben > > > > On 09 Dec 2013, at 06:48, Martin Dias <tinchodias(a)gmail.com> wrote: > > > > Hi, I'm back with more annoying questions :) > > > > Using #whenSelectedItemsChanged:, I see that the block is evaluated a > lot of > > times: > > > > log := OrderedCollection new. > > roots := #(1 2) collect: [ :each | > > TreeNodeModel new > > content: each; > > selected: true; > > yourself ]. > > > > TreeModel new > > roots: roots; > > multiSelection: true; > > whenSelectedItemsChanged: [ :items | > > log add: items ]; > > openWithSpec. > > log ---> an OrderedCollection(#() an OrderedCollection(1) an > > OrderedCollection(1) an OrderedCollection(1 2) an OrderedCollection(1 2) > an > > OrderedCollection(1 2)) > > > > I'd expect only one evaluation... is it a bug or a feature? > > > > cheers, > > MartÃn > > > > > > On Sun, Dec 8, 2013 at 12:22 AM, Martin Dias <tinchodias(a)gmail.com> > wrote: > >> > >> aha! thanks > >> > >> MartÃn > >> > >> On Sat, Dec 7, 2013 at 10:33 AM, Benjamin > >> <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > >> > roots := #(1 2 3) collect: [ :e | TreeNodeModel new content: e ; > >> > yourself ]. > >> > > >> > TreeModel new > >> > roots: roots; > >> > multiSelection: true; > >> > openWithSpec. > >> > > >> > roots third > >> > selected: true; > >> > takeHighlight > >> > > >> > Ben > >> > > >> > On 07 Dec 2013, at 05:44, Martin Dias <tinchodias(a)gmail.com> wrote: > >> > > >> > ouch! thanks Ben. > >> > > >> > Another related question: is there any way of selecting an arbitrary > >> > item? I tried (among others) with: > >> > > >> > TreeModel new > >> > roots: #(1 2 3); > >> > multiSelection: true; > >> > openWithSpec; > >> > selection: 3 > >> > > >> > without success. > >> > > >> > Cheers, > >> > MartÃn > >> > > >> > > >> > > >> > On Thu, Dec 5, 2013 at 4:17 PM, Benjamin > >> > <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > >> > > >> > your tree here is single selection so it will not work > >> > > >> > TreeModel new > >> > roots: #(1 2 3); > >> > multiSelection: true; > >> > openWithSpec; > >> > selectAll > >> > > >> > Ben > >> > > >> > On 05 Dec 2013, at 15:38, Martin Dias <tinchodias(a)gmail.com> wrote: > >> > > >> > Hi, > >> > > >> > I'm not sure how this method should be used. I tried in different > >> > ways, for example: > >> > > >> > TreeModel new > >> > roots: #(1 2 3); > >> > selectAll; > >> > openWithSpec > >> > > >> > But always the items are unselected. Is it a bug? or I didn't find the > >> > way to use it? > >> > > >> > Thanks, > >> > MartÃn > >> > > >> > > >> > > >> > > > > > > > > >

Dec. 11, 2013

Re: [Pharo-dev] Which tests should be run in CI?

by Stephan Eggermont

Torsten, For unit tests building on green builds might be enough, but what about integration/smoke tests? Concrete case: I added a test to check that no class implements >>packages That is a test that should be run by all builds, but is not. The consequence is that Moose and Pharo3 based builds using seaside or magritte can not reliably use "senders of" I assume there are more tests like this. Stephan

Dec. 11, 2013