- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Problem with fork

by Henrik Sperre Johansen

Also, neither is cascading sends in a thread (like the ts show: xxx; cr in your example)... For things like that, you can use ThreadSafeTranscript with: [ :aStream | ], or if you prefer Transcript protocols, implement a method doing the same but with self as parameter. - This will have some overhead though, seeing as how you'll usually be reentering the critical section once for each call. Something like: TreadSafeTranscript >> doUninterruptably: aBlock accessSemaphore critical: [aBlock value: self] and you'll write: 1 to: 10 do: [:i | [ tr doUninterruptably: [:transcript | transcript show: i printString, ' fork ' ; cr.]. (semaphores at: i) signal. ] fork. Cheers, Henry On 01.07.2009 19:45, Henrik Sperre Johansen wrote: > Look at forMutualExclusion implementation, and you'll see it's set up > with one excess signal. > So the first thing to wait for it, doesn't have to wait, ie. your > semaphores do:[]... falls straight through and 'all forks processed' > gets displayed before any of the forks are run. > Substitute with new, and you SHOULD get the behaviour you expect. > However, show: is NOT threadsafe, it releases access lock between > nextPutAll and endEntry, thus you often end up with several threads > writing to stream, then endEntry displaying them multiple times > If you change nextPutAll: back to show: in the code below, this is > apparent (at least it was on my machine...) > > |semaphores tr| > semaphores := Array new: 10. > tr := ThreadSafeTranscript new. > tr open. > 1 to: 10 do: [ :index | semaphores at: index put: Semaphore new ]. > > 1 to: 10 do: [:i | > [ > tr nextPutAll: i printString, ' fork '; cr. > (semaphores at: i) signal. > ] fork > ]. > > semaphores do: [:each | each wait ]. > tr show: 'all forks proccesed'; cr. > > Cheers, > Henry > > > On 01.07.2009 16:41, Mariano Martinez Peck wrote: >> Hi folks! I am doing some benchmarks and I having problems with fork >> (I think). >> >> I have this method collect: >> >> collect >> |semaphores tr| >> semaphores := Array new: 10. >> tr := ThreadSafeTranscript new. >> tr open. >> 1 to: 10 do: [ :index | semaphores at: index put: Semaphore >> forMutualExclusion ]. >> >> 1 to: 10 do: [:i | >> [ >> tr show: 'one fork'; cr. >> (semaphores at: i) signal. >> ] fork >> ]. >> >> semaphores do: [:each | each wait ]. >> tr show: 'all forks proccesed'; cr. >> >> >> What I want is that the method collect returns when ALL of the forks >> created inside, are finished. Obviously in my real code, I don't do a >> transcript show: but another thing. >> >> I would expect something like this: >> >> one fork >> one fork >> one fork >> one fork >> one fork >> one fork >> one fork >> one fork >> one fork >> one fork >> all forks proccesed >> >> But the output is: >> >> >> all forks proccesed >> one fork >> one fork >> one fork >> one forkone fork >> one fork >> one fork >> one forkone fork >> one fork >> one fork >> one forkone fork >> >> So, I guess it isn't working :( I don't know too much about forks >> so any help is welcome! >> >> can be a problem with ThreadSafeTranscript ? If so, how could I >> test if my code is working as expected ? >> >> Thanks, >> >> Mariano >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ------------------------------------------------------------------------ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 1, 2009

Re: [Pharo-project] why FileDirectory sucks

by Cameron Sanders

On Jul 1, 2009, at 1:28 PM, Stephen Pair wrote: > On Wed, Jul 1, 2009 at 9:42 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > Hi guys > > we should really consider to have an alternate (may be building on / > rewriting part of RIO) > but FileDirectory sucks. > > I have a file > > FileDirectory default > > and now I want to get two levels up. > > Well after 20 min looking around I could not find a way. > I'm probably too stupid for squeak arcane logic. > > Smalltalk deserves a better library for file. What a crap this stuff. > > Stef > > LoL...how many years did it take you to come to this conclusion? > Anyway, if anyone does take up the job of rewriting the file system > interface, I have a suggestion based on some recent stuff we've done > here at work. We wanted a way of running test cases for code that > uses the file system, but we didn't want to actually use the file > system (for speed...when you run many thousands of test cases, > hitting the disk can really slow things down). We wanted to > substitute an in memory simulation of a file system. We had to go > to great lengths to accomplish this (in VisualWorks). It would be > really cool if things like filenames and directories didn't make > assumptions about the file system with which they are used (so that > you could have filenames for in memory file systems, or filenames > for other file systems that one might connect with in ways other > than the built in local file system primitives). > > - Stephen A related notion, but a tangent (and then returning to the above thread)... One thing I did in Java (in 2001) and Python (later) --and have been considering doing in my current smalltalk code base-- was to create "Accessors" to access relational DB's, directory based files, and memory-based 2d-tables in a generic fashion. An Accessor, as I defined it, looked a lot like a combo of a DB connection and results set. The file-based Accessors were opened on a directory as the DB, where the files were tables (and those could be read or written in several formats: CSV, tab-delimited, etc.), and subdirectories were treated like tables of Blobs; another variant allowed an accessor to be opened on a directory as if it were bound to a specific table, and so the directory looked like a table of Blobs. Obviously, any level of complexity, and "auto" handling of file types is possible. (And I am not describing what I did well, there was symmetry and a recursive nature... and I'm too lazy to look and detail it right now; instead my goal is just to kick some ideas out.) Obviously the Accessors allowed me to ignore the data source. I keep puzzling that I have not encountered this type of thing elsewhere. And back to the main topic here... aren't URL's fairly well generalized? Are they not the right way to fully generalize locations? -cam

July 1, 2009

Re: [Pharo-project] Problem with fork

by Henrik Sperre Johansen

Look at forMutualExclusion implementation, and you'll see it's set up with one excess signal. So the first thing to wait for it, doesn't have to wait, ie. your semaphores do:[]... falls straight through and 'all forks processed' gets displayed before any of the forks are run. Substitute with new, and you SHOULD get the behaviour you expect. However, show: is NOT threadsafe, it releases access lock between nextPutAll and endEntry, thus you often end up with several threads writing to stream, then endEntry displaying them multiple times If you change nextPutAll: back to show: in the code below, this is apparent (at least it was on my machine...) |semaphores tr| semaphores := Array new: 10. tr := ThreadSafeTranscript new. tr open. 1 to: 10 do: [ :index | semaphores at: index put: Semaphore new ]. 1 to: 10 do: [:i | [ tr nextPutAll: i printString, ' fork '; cr. (semaphores at: i) signal. ] fork ]. semaphores do: [:each | each wait ]. tr show: 'all forks proccesed'; cr. Cheers, Henry On 01.07.2009 16:41, Mariano Martinez Peck wrote: > Hi folks! I am doing some benchmarks and I having problems with fork > (I think). > > I have this method collect: > > collect > |semaphores tr| > semaphores := Array new: 10. > tr := ThreadSafeTranscript new. > tr open. > 1 to: 10 do: [ :index | semaphores at: index put: Semaphore > forMutualExclusion ]. > > 1 to: 10 do: [:i | > [ > tr show: 'one fork'; cr. > (semaphores at: i) signal. > ] fork > ]. > > semaphores do: [:each | each wait ]. > tr show: 'all forks proccesed'; cr. > > > What I want is that the method collect returns when ALL of the forks > created inside, are finished. Obviously in my real code, I don't do a > transcript show: but another thing. > > I would expect something like this: > > one fork > one fork > one fork > one fork > one fork > one fork > one fork > one fork > one fork > one fork > all forks proccesed > > But the output is: > > > all forks proccesed > one fork > one fork > one fork > one forkone fork > one fork > one fork > one forkone fork > one fork > one fork > one forkone fork > > So, I guess it isn't working :( I don't know too much about forks so > any help is welcome! > > can be a problem with ThreadSafeTranscript ? If so, how could I test > if my code is working as expected ? > > Thanks, > > Mariano > > ------------------------------------------------------------------------ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 1, 2009

Re: [Pharo-project] why FileDirectory sucks

by Stephen Pair

On Wed, Jul 1, 2009 at 9:42 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Hi guys > > we should really consider to have an alternate (may be building on / > rewriting part of RIO) > but FileDirectory sucks. > > I have a file > > FileDirectory default > > and now I want to get two levels up. > > Well after 20 min looking around I could not find a way. > I'm probably too stupid for squeak arcane logic. > > Smalltalk deserves a better library for file. What a crap this stuff. > > Stef LoL...how many years did it take you to come to this conclusion? Anyway, if anyone does take up the job of rewriting the file system interface, I have a suggestion based on some recent stuff we've done here at work. We wanted a way of running test cases for code that uses the file system, but we didn't want to actually use the file system (for speed...when you run many thousands of test cases, hitting the disk can really slow things down). We wanted to substitute an in memory simulation of a file system. We had to go to great lengths to accomplish this (in VisualWorks). It would be really cool if things like filenames and directories didn't make assumptions about the file system with which they are used (so that you could have filenames for in memory file systems, or filenames for other file systems that one might connect with in ways other than the built in local file system primitives). - Stephen

July 1, 2009

Re: [Pharo-project] why FileDirectory sucks

by Schwab,Wilhelm K

One thing that seems to be missing is a good abstraction of relative paths, and some type of #, message to allow relative ones to be tacked onto full ones (FileDirectory etc.)?? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Wednesday, July 01, 2009 12:11 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] why FileDirectory sucks > Smalltalk deserves a better library for file. What a crap this stuff. The problem is that a good platform independent library is not a trivial thing. Also from the architectural point of view this is a rather difficult problem. The biggest problem is though that the primitives where everything is built upon are arcane too. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 1, 2009

Re: [Pharo-project] why FileDirectory sucks

by Schwab,Wilhelm K

Yikes!!!! :) Anybody else for #parent or #up as a helper? -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Wednesday, July 01, 2009 12:08 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] why FileDirectory sucks > Well after 20 min looking around I could not find a way. > I'm probably too stupid for squeak arcane logic. FileDirectory default containingDirectory containingDirectory Yes, it took me a long time to find out the first time. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 1, 2009

Re: [Pharo-project] why FileDirectory sucks

by Schwab,Wilhelm K

Stef, One approach might be to use the #fullName and #pathNameDelimiter to create a collection of parent directories. Also see #pathParts, but that is probably not quite what you want, because it focuses on the names, but #do:separatedBy: could help correct that. So far, I have created some simple helper methods that will allow myriad senders in my Dolphin code to (hopefully) continue to work under Pharo. However, Dolphin has a Windows-only bias and Pharo needs to work with various conventions, so the "correct" abstraction for directory naming will have to be different from Dolphin's. Should there be a #, for concatenation? #parent to move up, with obvious caveat of throwing an exception? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Wednesday, July 01, 2009 8:43 AM To: Pharo Development Subject: [Pharo-project] why FileDirectory sucks Hi guys we should really consider to have an alternate (may be building on / rewriting part of RIO) but FileDirectory sucks. I have a file FileDirectory default and now I want to get two levels up. Well after 20 min looking around I could not find a way. I'm probably too stupid for squeak arcane logic. Smalltalk deserves a better library for file. What a crap this stuff. Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 1, 2009

Re: [Pharo-project] why FileDirectory sucks

by Lukas Renggli

> Smalltalk deserves a better library for file. What a crap this stuff. The problem is that a good platform independent library is not a trivial thing. Also from the architectural point of view this is a rather difficult problem. The biggest problem is though that the primitives where everything is built upon are arcane too. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

July 1, 2009

Re: [Pharo-project] why FileDirectory sucks

by Lukas Renggli

> Well after 20 min looking around I could not find a way. > I'm probably too stupid for squeak arcane logic. FileDirectory default containingDirectory containingDirectory Yes, it took me a long time to find out the first time. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

July 1, 2009

[Pharo-project] Pharo VM setup problem: where is pharo-vm-0.15.1b-linux source package available?

by Andreas Leidig

Dear List, who has/where is pharo-vm-0.15.1b-linux source package? I have a setup problem which I think I can determine or even solve with the sources. Cheers, Andreas

July 1, 2009