- Pharo-dev - lists.pharo.org

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

by GOUBIER Thierry

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(a)lists.pharo.org] de la part de Sebastian Sastre [sebastian(a)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(a)cea.fr<mailto:thierry.goubier@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(a)lists.pharo.org<mailto:pharo-dev-bounces@lists.pharo.org>] de la part de Sebastian Sastre [sebastian(a)flowingconcept.com<mailto:sebastian@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

the athens tutorial is not working in latest 30.

by StÃ©phane Ducasse

Dec. 12, 2013

Re: [Pharo-dev] Image frozen on Socket>>waitForConnectionFor: timeout ifTimedOut: timeoutBlock

by Sebastian Sastre

Doing this removes redundant code, still not a solution: waitForConnectionFor: timeout ifTimedOut: timeoutBlock "Wait up until the given deadline for a connection to be established. Return true if it is established by the deadline, false if not." ^ self waitForConnectionUntil: (self class deadlineSecs: timeout) ifTimedOut: timeoutBlock On Dec 12, 2013, at 11:32 AM, Sebastian Sastre <SEBASTIAN(a)FLOWINGCONCEPT.COM> wrote: > Hi guys, > > I'm having an issue.. > > What happens? > > The image UI gets frozen when terminating a thread that's waiting on that method > > What I've discovered so far? > > seaside /config responds (but nothing else) > restarting the UI process results to no avail > terminating the process (selected in that screenshot) freezes everything but.. > debugging works and.. > when I debug and close the debugger freezes everything, but.. > if instead I evaluate with an inspector the block > > [(status = WaitingForConnection) and: [(msecsEllapsed := Time millisecondsSince: startTime) < msecsDelta]] > > it answers false and closing the dbugger after that leaves the system normal (meaning that if I terminate the process after that, it doesn't freeze and all go as expected) > > Still working on it.. > > Help and ideas appreciated > > > <Screen Shot 2013-12-12 at 11.24.32 AM.png>

Dec. 12, 2013

Image frozen on Socket>>waitForConnectionFor: timeout ifTimedOut: timeoutBlock

by Sebastian Sastre

Hi guys, I'm having an issue.. What happens? The image UI gets frozen when terminating a thread that's waiting on that method What I've discovered so far? seaside /config responds (but nothing else) restarting the UI process results to no avail terminating the process (selected in that screenshot) freezes everything but.. debugging works and.. when I debug and close the debugger freezes everything, but.. if instead I evaluate with an inspector the block [(status = WaitingForConnection) and: [(msecsEllapsed := Time millisecondsSince: startTime) < msecsDelta]] it answers false and closing the dbugger after that leaves the system normal (meaning that if I terminate the process after that, it doesn't freeze and all go as expected) Still working on it.. Help and ideas appreciated

Dec. 12, 2013

Re: [Pharo-dev] [Pharo Trick: #0009] 'Enable halt/inspect once' button

by btc＠openinworld.com

Dec. 12, 2013

Re: [Pharo-dev] [Pharo Trick: #0009] 'Enable halt/inspect once' button

by Max Leske

#setHaltOnce is implemented on Object. Evaluate this in a workspace: self setHaltOnce. -> same effect Cheers, Max On 12.12.2013, at 13:06, btc(a)openInWorld.com wrote: > When I have a 'self haltOnce' breakpoint that I am activating often, going "World > System > Enable halt/inspect once" each time is annoying. So using the Duplicate Halo on the menu item, I drag it onto the background so that it acts like a button. > > cheers -ben >

Dec. 12, 2013

Re: [Pharo-dev] [Pharo Trick: #0001] - Simple TODO list

by Esteban Lorenzano

I use it too, and I think they are a nice add that the tools should be more aware (not just showing the flag icon in browser) On Thu, Dec 12, 2013 at 1:05 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On 12 Dec 2013, at 12:58, Torsten Bergmann <astares(a)gmx.de> wrote: > > > Did you check the number of senders of #flag: in a recent Pharo image? > You > > will be surprised that not all come from Squeak ;) > > > I use it, yes. > > Marcus > >

Dec. 12, 2013

[Pharo Trick: #0009] 'Enable halt/inspect once' button

by btc＠openinworld.com

When I have a 'self haltOnce' breakpoint that I am activating often, going "World > System > Enable halt/inspect once" each time is annoying. So using the Duplicate Halo on the menu item, I drag it onto the background so that it acts like a button. cheers -ben

Dec. 12, 2013

Re: [Pharo-dev] [Pharo Trick: #0001] - Simple TODO list

by Marcus Denker

On 12 Dec 2013, at 12:58, Torsten Bergmann <astares(a)gmx.de> wrote: > Did you check the number of senders of #flag: in a recent Pharo image? You > will be surprised that not all come from Squeak ;) > I use it, yes. Marcus

Dec. 12, 2013

Re: [Pharo-dev] [Pharo Trick: #0008] - If appropriate use the memory file system

by Torsten Bergmann

Hi Marcus, regarding 2) In Pharo 3.0 one can already open a file browser on the memory file system: |fs| fs := FileSystem memory. (fs / 'hello.txt') writeStreamDo: [:s| s nextPutAll: 'Exported data' ]. FileList openOn: fs root but it looks like it needs some love. One can create new files but most functionality will not work. Should we create an issue? Thx T. > Gesendet: Donnerstag, 12. Dezember 2013 um 12:44 Uhr > Von: "Marcus Denker" <marcus.denker(a)inria.fr> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Cc: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] [Pharo Trick: #0008] - If appropriate use the memory file system > > Related to that: > > For Pharo4 I want to experiment to have the following: > > 1) one Memory FileSystem per RPackage (just an ivar there). > 2) File Browser support to show all these so one can put files in the package filesystem > 3) in Monticello, save all the files as part of the .zip (directory âresourcesâ) > 4) When loading with MC, load all files from the resources dir into the package filesystem > > (at first the file support will be very simple, e.g. no support for diffs). > > ==> then store e.g. all the icons there instead of a MIME-Encode string. > > Marcus > > On 12 Dec 2013, at 12:39, Torsten Bergmann <astares(a)gmx.de> wrote: > > > ----------------------------------------------------------------------------------- > > [Pharo Trick: #0008] - If appropriate use the memory file system > > ----------------------------------------------------------------------------------- > > Works in: Pharo 2.0, 3.0, ... > > ----------------------------------------------------------------------------------- > > > > It may be possible that your application has to export some > > data into an external file in a specific format. Pharo allows writing into > > a file using Streams as any other Smalltalk. > > > > But sometimes you want to check the result right from the Pharo image > > without having to look into the external file using external tools. > > > > So the trick here is to use the memory file system instead > > of the real disk file system during development since also no > > cleanup on the hard disk is required afterwards: > > > > |fs| > > fs := FileSystem memory. > > (fs / 'hello.txt') writeStreamDo: [:s| s nextPutAll: 'Exported data' ]. > > (fs / 'hello.txt') readStream contents. > > > > The memory filesystem is also nice if you need to work with files > > within a unit test. So when the test runs nothing remains left on the > > hard disk. > > > > If you need a real copy of the file on the hard disk you can also copy > > from the memory file system to the disk file system using #copyTo: > > > > |fs| > > fs := FileSystem memory. > > (fs / 'hello.txt') writeStreamDo: [:s| s nextPutAll: 'Memory first and then disk' ]. > > (fs / 'hello.txt') copyTo: (FileSystem disk / 'exactCopy.txt') > > > > > > >

Dec. 12, 2013