- Pharo-dev - lists.pharo.org

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

by Torsten Bergmann

Hi Stephan, that depends - for instance for "Bootstrap" I follow the pattern that most other contributions have configured: I only run the tests of the Bootstrap package to see when my own stuff breaks. If I would run all tests it may never be green because the underlying platform may be on the move. Usually a build can depende on another build (like Pharo 3) - so if this is not green the chain does not continue. At least this is how I see it... Bye T. > Gesendet: Mittwoch, 11. Dezember 2013 um 21:14 Uhr > Von: "Stephan Eggermont" <stephan(a)stack.nl> > An: pharo-dev(a)lists.pharo.org, Moose-dev(a)iam.unibe.ch > Betreff: [Pharo-dev] Which tests should be run in CI? > > I notice that several builds are green, though I added a breaking test to Pharo 3. > That probably means that those builds don't run all of the Pharo tests. > Most builds probably don't need to run all tests (all the time), but it might be > useful to be able to mark tests as integration tests, that are expected to be > run by all downstream builds. > > Concrete, every Pharo 3 build that loads Grease should currently be red. > > Stephan >

Dec. 11, 2013

Which tests should be run in CI?

by Stephan Eggermont

I notice that several builds are green, though I added a breaking test to Pharo 3. That probably means that those builds don't run all of the Pharo tests. Most builds probably don't need to run all tests (all the time), but it might be useful to be able to mark tests as integration tests, that are expected to be run by all downstream builds. Concrete, every Pharo 3 build that loads Grease should currently be red. Stephan

Dec. 11, 2013

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

by Sven Van Caekenberghe

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] MessageNotUnderstood: SmallInteger>>isEmpty

by Eliot Miranda

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? > > 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] [Spec] whenSelectedItemsChanged: on TreeModel

by Benjamin

As I said to Martin, I will investigate why, but itâs a bit tricky Must be some issue in MorphTreeMorph I introduced recently Ben On 11 Dec 2013, at 16:46, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > Hi, > > I am experiencing problems with #whenSelectedItemsChanged: on a TreeModel. > > In particular, the block (i.e., argument of #whenSelectedItemsChanged: gets randomly executed a couple of times (3/4) the second time that the selection happens. The first time is fine. It looks like the registration of the âeventâ or âannouncementâ is done multiple times. > > Any hint? > > Cheers, > R

Dec. 11, 2013

Re: [Pharo-dev] Workaround for File Out Package

by Torsten Bergmann

"Alfredo Sanzo" wrote: >Oh, sorry, wrong link. >https://pharo.fogbugz.com/f/cases/12409/DNU-RPackage-item-when-FileOut Â I can confirm the slice #12409 from Esteban is working, see issue @Alfredo: either load it from Pharo30Inbox or wait until it is integrated Bye T.

Dec. 11, 2013

Re: [Pharo-dev] Workaround for File Out Package

by Alfredo Sanzo

Oh, sorry, wrong link. https://pharo.fogbugz.com/f/cases/12409/DNU-RPackage-item-when-FileOut 2013/12/11 Alfredo Sanzo <alfredo.sanzo(a)gmail.com> > Hi! > > I am having a problem when trying to export a Package to .st using Right > Click -> Fileout. > Here is the case: > https://pharo.fogbugz.com/f/cases/7519 > > Do anyone know a workaround? > A way to do it via code? > > This is a feature we use at several universities in order to provide fast > and simple code exporting, without the need to explain code sharing > principles. > > Thanks in advance for any response, and sorry if this is not the right > list. :) > > Cordially, > > Alf >

Dec. 11, 2013

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

by Sebastian Sastre

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> 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>> 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>> 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>> 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>>> 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>>> >>>> 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>__>> 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. 11, 2013

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

by Goubier Thierry

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>> 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>> 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>> 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>>> 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>>> >>> 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>__>> 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. 11, 2013

Re: [Pharo-dev] [ANN] Neo-Caching

by Sven Van Caekenberghe

On 11 Dec 2013, at 14:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 11 Dec 2013, at 13:42, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > >> On 11/12/13 12:20, Sven Van Caekenberghe wrote: >>> Hi Jan, >>> >>> On 11 Dec 2013, at 12:49, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >>> >>>> Hi, >>>> >>>>> By default, no concurrent access protection takes place, but optionally a semaphore for mutual exclusion can be used. This slows down access. >>>>> >>>>> cache useSemaphore. >>>>> >>>> >>>> There was enough "awesomes" already :-) so now some critics :-) >>> >>> I like constructive feedback ! >>> >>>> Wouldn't it be better to rename #useSemaphore to #beThreadSafe >>>> or #beSynchronized. >>> >>> Yes, specifying the goal/result is better than specifying the means. I think I will go for #beThreadSafe (although threads in Pharo are called Processes ;-). The last one reminds me of Java and we donât have a âsynchronisedâ concept in Pharo AFAIK. >> >>> >>>> Also I would use recursion lock (monitor, if you like) rather than plain mutex. >>> >>> Iâve used both, they both work. But I must admit that in my mind the difference is not very clear. A monitor can be re-entered while a semaphore cannot, >> >> That's exactly the difference, subtle but important :-) >> >> but I doubt this is necessary here. >> >> Imagine you need Fibonacci number and want to cache them for speed. >> How would one do that? Obvious solution would be: >> >> fibCache := NeoCache ... >> fibCache factory: [:key | (fibCache at: key - 1) + (fibCache at: key - 1) ]. >> >> If I understood the code correctly `fibCache at: 10` would hang, right? > > OK, you convinced me ! Thanks for the explanation. > > I will even make the fib example part of the unit tests. === Name: Neo-Caching-SvenVanCaekenberghe.15 Author: SvenVanCaekenberghe Time: 11 December 2013, 5:07:11.601995 pm UUID: 35273b73-8caf-4810-afc5-614d7c690580 Ancestors: Neo-Caching-SvenVanCaekenberghe.14 processed some feedback by Jan Vrany (Thx!): - renamed #useSemaphore to #beThreadSafe - use a Monitor instead of a Semaphore for mutual exclusion so that it can be re-entered safely - added #testFibonacci - added some clarifications to NeoTTLCache's class comment === > But I will probably change it to > > [ :key | > key < 2 > ifTrue: [ key ] > ifFalse: [ (fibCache at: key - 1) + (fibCache at: key - 1) ] ] > > ;-) > >>> >>> Any other reasons to choose one over the other ? Speed ? >> >> Speed-wise, it depends on implementation. The cost of recursion >> lock could be reduced to couple machine instructions in case >> there's no contention (which is usually the case). > > Iâll measure it. > >> Actually, this would make an interesting use-case for NB... >> >>> >>> Sven >>> >>>> Best, Jan >

Dec. 11, 2013