July 2009 - Pharo-dev - lists.pharo.org

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

[Pharo-project] Problem with fork

by Mariano Martinez Peck

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

July 1, 2009

Re: [Pharo-project] running Pharo headless as service on Windows.

by Schwab,Wilhelm K

John, I'm glad you go it going. There is also an AppDirectory key that you can associate with a service, and I _think_ it will accomplish the same thing, albeit with silly syntax and no error useful messages :) Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Thornborrow Sent: Wednesday, July 01, 2009 4:32 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] running Pharo headless as service on Windows. Hi Wilhelm, To be semantic, we aren't running Pharo directly as a service - we are using Hudson[1] to execute the image. The image then outputs the test results to a text file (we are using SSpec and TextSpecRunner) and a batch script parses this results file. The issue was, as Damien suggested, that the image could not locate a sources file, so instead of calling the executable with the full path in our batch script, I simply changed it to "cd" to the path and call it locally :) Regards, John. Schwab,Wilhelm K wrote: > John, > > How are you obtaining the output, and/or concluding that the intended thing happened? I have found services to be quite flaky on Windows (did I just limit the scope to services??<g>), with a mix of silly syntax restrictions in the service properties and registry entries making huge differences in success or failure (with no useful error messages), and other hassles following from things like OutputDebugString() being hobbled ever more over time. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John > Thornborrow > Sent: Tuesday, June 30, 2009 7:48 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] running Pharo headless as service on Windows. > > Hi all, > > We're attempting to run a Pharo image as Headless as a Service on Windows XP. > > We've successfully done this before, but now we're using a later image (and exupery vm) it is unable to fully initialize. Squeak.exe is visible in Task manager. > > I don't even know where to start looking for more information so any > help is appreciated :) > > I know it's not working because it is only supposed to start, run some > specs/tests, then exit the image. When running this manually in the > command prompt, it behaves as expected (with and without the -headless > opt) but when run as service (SYSTEM user) it starts, but does nothing. > Presumably because of Morphic and no user environment for SYSTEM? > > MAny thanks and Regards, > John Thornborrow. > > www.pinesoft.co.uk > > > > > Consider your responsibility to the environment - think before you print! > > ********************************************************************** > ******************************************************************** > This email is from Pinesoft Limited. Its contents are confidential to > the intended recipient(s) at the email address(es) to which it has > been addressed. It may not be disclosed to or used by anyone other > than the addressee(s), nor may it be copied in anyway. If received in > error, please contact the sender, then delete it from your system. > Although this email and attachments are believed to be free of virus, > or any other defect which might affect any computer or IT system into > which they are received and opened, it is the responsibility of the > recipient to ensure that they are virus free and no responsibility is > accepted by Pinesoft for any loss or damage arising in any way from > receipt or use thereof. > ********************************************************************** > ********************************************************************* > > > Pinesoft Limited are registered in England, Registered number: > 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, > EN8 7EA > > _______________________________________________ > 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 > > _______________________________________________ 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