- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] New screenshots of Roassal 3d

by Craig Latta

Nice! -C -- Craig Latta www.netjam.org/resume +1 510 984 8117 (Skype rings this until 31 January 2014)

Dec. 11, 2013

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

by Esteban Lorenzano

that would be sooo cool. Thanks Thierry! Esteban On Wed, Dec 11, 2013 at 4:39 PM, Goubier Thierry <thierry.goubier(a)cea.fr>wrote: > Thanks. I'll have a look. > > If this format solves the git merge conflicts, I'll be porting it. But > I'll make sure first it doesn't have the performance problems Sebastian is > telling about. > > Because if it is just removing writing the metadata in gitfiletree, it's a > 5 minutes job :). > > Thierry > > Le 11/12/2013 16:24, Esteban Lorenzano a Ã©crit : > >> 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>> 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>>> 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>>> >> 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>__>> 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 > >

Dec. 11, 2013

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

by Goubier Thierry

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>> 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> > > o/ > > > > > > On Dec 11, 2013, at 12:44 PM, Sebastian Sastre > <sebastian(a)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>> 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> >>>> >>>> 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> / 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 Esteban Lorenzano

ah, and IMHO the problem is not about reading... is about writing (if it has to write the metadata each time...). Esteban On Wed, Dec 11, 2013 at 4:24 PM, Esteban Lorenzano <estebanlm(a)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>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>> >>> 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> >>> >>> >>> o/ >>> >>> >>> >>> >>> >>> On Dec 11, 2013, at 12:44 PM, Sebastian Sastre >>> <sebastian(a)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>> 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> >>>>>> >>>>>> 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> / 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 Esteban Lorenzano

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>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>> >> 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> >> >> >> o/ >> >> >> >> >> >> On Dec 11, 2013, at 12:44 PM, Sebastian Sastre >> <sebastian(a)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>> 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> >>>>> >>>>> 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> / 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

Le 11/12/2013 15:44, Sebastian Sastre a Ã©crit : > Hi Thierry > > On Dec 11, 2013, at 12:43 PM, Goubier Thierry <thierry.goubier(a)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. This operation is fast with gitfiletree because I cache the commit history and avoid reading the version file everytime: the version reader is very slow, especially with large version files. You're using FileTree and not gitfiletree ? gitfiletree may solve the reading problem, if it fits with your workflow (and it reads cleanly pre-existing git/filetree repository without changing them). > But the write is the most worrisome This is something I haven't found a need to optimise yet, so maybe you're on something important. >>> 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 Well, it ensures correctness and simplify the code ;) When it is confirmed to be a bottleneck, then we can act and change it. Thierry -- 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

[ANN] traversal-enabled objects with DeepTraverser

by Tudor Girba

Hi, I put together a little implementation for traversals. It is inspired by an original implementation from Mariano. Using DeepTraverser, you can traverse arbitrary graphs by describing the traversal and by specifying the actions you want to perform on the nodes and relations. The code is available in the Moose image as part of the MooseAlgos subproject, but can also be loaded separately in a Pharo image via: Gofer new url: 'http://www.smalltalkhub.com/mc/Moose/DeepTraverser/main'; package: âConfigurationOfDeepTraverserâ; load. (Smalltalk globals at: #ConfigurationOfDeepTraverser) loadDevelopment. Just to give you an idea, here are some representative examples: Number deep: #subclasses do: [:each | Transcript show: each; cr]. Number deepCollect: #subclasses. Number deep: #subclasses collect: #name. Number deep: #subclasses do: [:each | Transcript show: each; cr] relationDo: [ :from :to | Transcript show: from; show: ' <-- '; show: to; cr ]. More details about the usages and a little description of the implementation can be found here: http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects/ Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Dec. 11, 2013

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

by Esteban Lorenzano

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> 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> > > o/ > > > > > > On Dec 11, 2013, at 12:44 PM, Sebastian Sastre < > sebastian(a)flowingconcept.com> wrote: > > Hi Thierry > > On Dec 11, 2013, at 12:43 PM, Goubier Thierry <thierry.goubier(a)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> > > 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 / 83 95 > > > > >

Dec. 11, 2013

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

by Sebastian Sastre

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 o/ On Dec 11, 2013, at 12:44 PM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > Hi Thierry > > On Dec 11, 2013, at 12:43 PM, Goubier Thierry <thierry.goubier(a)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> >>> >>> 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 / 83 95 >> > >

Dec. 11, 2013

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

by Sebastian Sastre

Hi Thierry On Dec 11, 2013, at 12:43 PM, Goubier Thierry <thierry.goubier(a)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> >> >> 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 / 83 95 >

Dec. 11, 2013