[Pharo-dev] Tell me about your workflow

Tudor Girba tudor at tudorgirba.com
Mon Dec 16 15:45:35 EST 2013


Hi,

By following the instructions from any of the Moose webpages:

http://www.moosetechnology.org/download/pharo
http://www.smalltalkhub.com/#!/~Moose/Moose


Gofer new
      smalltalkhubUser: 'Moose' project: 'Moose';
      package: 'ConfigurationOfMoose';
      load.
(Smalltalk at: #ConfigurationOfMoose)
      perform: #loadDevelopment

Cheers,
Doru


On Sat, Dec 14, 2013 at 9:01 AM, GOUBIER Thierry <thierry.goubier at cea.fr>wrote:

>  Stef,
>
> how do I load Moose in a 3.0 image? There is no Moose config in the 3.0
> meta repository.
>
> Thierry
>  ------------------------------
> *De :* Pharo-dev [pharo-dev-bounces at lists.pharo.org] de la part de
> Stéphane Ducasse [stephane.ducasse at inria.fr]
> *Date d'envoi :* vendredi 13 décembre 2013 13:47
>
> *À :* Pharo Development List
> *Objet :* Re: [Pharo-dev] Tell me about your workflow
>
>  try with Moose.
>
>  Stef
>
>  On Dec 12, 2013, at 4:20 PM, Yuriy Tymchuk <yuriy.tymchuk at me.com> wrote:
>
>  Pharo10 on SmalltalkHub is humongous. You can definitely do a stress
> test with it :)
>
>  Uko
>
>  On 12 Dec 2013, at 15:43, GOUBIER Thierry <thierry.goubier at cea.fr> wrote:
>
>  I would need a large project, composed of one or more packages, with
> more than 150~200 classes, which triggers the slow read and writing times
> Sebastian experience. And, probably, to be complete, a long and complex
> commit history in git (> 100 commits).
>
> I'll keep in mind the idea of creating one randomly ;)
>
> Thierry
>
>  ------------------------------
> *De :* Pharo-dev [pharo-dev-bounces at lists.pharo.org] de la part de Yuriy
> Tymchuk [yuriy.tymchuk at me.com]
> *Date d'envoi :* jeudi 12 décembre 2013 15:37
> *À :* Pharo Development List
> *Objet :* Re: [Pharo-dev] Tell me about your workflow
>
>  Are you interested in a package or a project? I can provide you
> information based on size, etc…
>
>  Uko
>
>  On 12 Dec 2013, at 15:30, GOUBIER Thierry <thierry.goubier at cea.fr> wrote:
>
>  I gave up running gitfiletree on 1.4 :(
>
> It's possible to use gitfiletree from a 2.0 or a 3.0 image to browse your
> git repository, but testing the writing will be an issue.
>
> My best chance would be to find a large enough package I can use on 2.0 or
> 3.0 to test and profile. Does anybody has a large enough package which
> could fit? Anything that doesn't require a NDA to read it, of course. Is
> Roassal large enough?
>
> Thierry
>
>  ------------------------------
> *De :* Pharo-dev [pharo-dev-bounces at lists.pharo.org] de la part de
> Sebastian Sastre [sebastian at flowingconcept.com]
> *Date d'envoi :* jeudi 12 décembre 2013 12:12
> *À :* Pharo Development List
> *Objet :* Re: [Pharo-dev] Tell me about your workflow
>
>  gee the big code package is airflowing which I have, quite
> conservatively, running on #14438 images
>
>   I load filetree like this:
>
>  Gofer new
>       url: 'http://ss3.gemstone.com/ss/FileTree';
>       package: 'ConfigurationOfFileTree';
>       load.
> ((Smalltalk at: #ConfigurationOfFileTree) project version: #'stable') load.
>
>  and it never complained
>
>  let me know
>
>
>
>
>
>  On Dec 12, 2013, at 3:53 AM, GOUBIER Thierry <thierry.goubier at cea.fr>
> wrote:
>
>  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 at lists.pharo.org] de la part de
> Sebastian Sastre [sebastian at 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 at 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 at cea.fr
> <mailto:thierry.goubier at cea.fr <thierry.goubier at 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 at gmail.com <mailto:estebanlm at gmail.com <estebanlm at gmail.com>>
> <mailto:estebanlm at gmail.com <estebanlm at 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 at cea.fr
> <mailto:thierry.goubier at cea.fr <thierry.goubier at cea.fr>><
> mailto:thierry.goubier at cea.fr <thierry.goubier at 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 at flowingconcept.com
> <mailto:sebastian at flowingconcept.com <sebastian at flowingconcept.com>>
>           <mailto:sebastian at flowingconcept.com<sebastian at flowingconcept.com>
> >
>           <mailto:sebastian at __flowingconcept.com
>           <mailto:sebastian at flowingconcept.com<sebastian at 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 at flowingconcept.com
> <mailto:sebastian at flowingconcept.com <sebastian at flowingconcept.com>>
>           <mailto:sebastian at flowingconcept.com<sebastian at flowingconcept.com>
> >
>           <mailto:sebastian at __flowingconcept.com
>           <mailto:sebastian at flowingconcept.com<sebastian at flowingconcept.com>
> >>>
>                wrote:
>
>                    Hi Thierry
>
>                    On Dec 11, 2013, at 12:43 PM, Goubier Thierry
>                    <thierry.goubier at cea.fr
> <mailto:thierry.goubier at cea.fr <thierry.goubier at cea.fr>>
>               <mailto:thierry.goubier at cea.fr <thierry.goubier at cea.fr>>
>               <mailto:thierry.goubier at cea.fr <thierry.goubier at cea.fr>
>               <mailto:thierry.goubier at cea.fr <thierry.goubier at 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
>
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131216/86d9285a/attachment-0002.html>


More information about the Pharo-dev mailing list