October 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Too many semaphores, image blocked

by Henrik Sperre Johansen

On 21.10.2011 10:42, Henrik Sperre Johansen wrote: > On 20.10.2011 15:30, Igor Stasenko wrote: >> 2011/10/20 Janko MivÅ¡ek<janko.mivsek(a)eranova.si>: >>> Hi guys, >>> >>> I'm measuring how my image is breathing through the time and what is >>> interesting is how nr. of Semaphore instances is variating through the >>> time. Every hour just before snapshot I report nr of instances, see >>> last >>> 10 hours: >>> >> Well, the number of semaphores tells nothing because not all of them >> serve for sockets. >> >> There are 3 semaphores per socket. So, if you have 4 sockets, there >> should be 12 external objects. >> Of course not counting others, which is there for other purposes. >> >> Could you add following to report: >> >> Socket registry size >> StandardFileStream registry size >> (ExternalSemaphoreTable unprotectedExternalObjects reject: #isNil) size > There's something wrong with startup/shutdown list, at least with my > Pharo 1.4 image... Both InputEventFetcher and InputEventPollingFetcher are in the lists, going back to at least 1.3 Can't have that. Probably got there when switching InputFetcher (IE a _long_ time ago) due to being careless with receiver of #install / #deinstall... InputEventPollingFetcher should be removed. Cheers, Henry

Oct. 21, 2011

Re: [Pharo-project] Too many semaphores, image blocked

by Henrik Sperre Johansen

On 20.10.2011 15:30, Igor Stasenko wrote: > 2011/10/20 Janko MivÅ¡ek<janko.mivsek(a)eranova.si>: >> Hi guys, >> >> I'm measuring how my image is breathing through the time and what is >> interesting is how nr. of Semaphore instances is variating through the >> time. Every hour just before snapshot I report nr of instances, see last >> 10 hours: >> >> ** image state: >> 0 HTTPCommections >> 4 Sockets >> 22 Processes >> 259 Semaphores >> >> ** image state: >> 0 HTTPCommections >> 4 Sockets >> 22 Processes >> 274 Semaphores >> >> ** image state: >> 0 HTTPCommections >> 4 Sockets >> 22 Processes >> 312 Semaphores >> >> ** image state: >> 0 HTTPCommections >> 4 Sockets >> 22 Processes >> 356 Semaphores >> >> ** image state: >> 0 HTTPCommections >> 4 Sockets >> 22 Processes >> 346 Semaphores >> >> ** image state: >> 0 HTTPCommections >> 4 Sockets >> 22 Processes >> 141 Semaphores >> >> ** image state: >> 0 HTTPCommections >> 4 Sockets >> 22 Processes >> 310 Semaphores >> >> ** image state: >> 0 HTTPCommections >> 4 Sockets >> 26 Processes >> 79 Semaphores >> >> ** image state: >> 0 HTTPCommections >> 4 Sockets >> 20 Processes >> 300 Semaphores >> >> > Well, the number of semaphores tells nothing because not all of them > serve for sockets. > > There are 3 semaphores per socket. So, if you have 4 sockets, there > should be 12 external objects. > Of course not counting others, which is there for other purposes. > > Could you add following to report: > > Socket registry size > StandardFileStream registry size > (ExternalSemaphoreTable unprotectedExternalObjects reject: #isNil) size There's something wrong with startup/shutdown list, at least with my Pharo 1.4 image... The InputEventFetcher's shutdown/startup methods are called twice when you save, thus you end up with an extra semaphore in the table whenever you save. Janko just runs into the consequences of this faster as he saves frequently. Cheers, Henry View transcript when saving with InputEventFetcher doing logging like: shutDown self crLog: 'Shutdown called!'. self terminateEventLoop. inputSemaphore ifNotNil: [|pre post| pre := (ExternalSemaphoreTable unprotectedExternalObjects select: [:each | each notNil]) size. Smalltalk unregisterExternalObject: inputSemaphore. post := (ExternalSemaphoreTable unprotectedExternalObjects select: [:each | each notNil]) size. pre = post ifTrue: [self logCr: 'Tried unregistering inputSemaphore, but still there!']] startUp self crLog: 'Startup called!'. inputSemaphore := Semaphore new. self primSetInputSemaphore: (Smalltalk registerExternalObject: inputSemaphore). inputSemaphore initSignals. self installEventLoop

Oct. 21, 2011

[Pharo-project] Text for 1.3 announcement?

by Marcus Denker

Hi, We should officially announce 1.3... For that we need a short text to be posted as a news: http://www.pharo-project.org/news Anyone interested in writing it? -- Marcus Denker -- http://marcusdenker.de

Oct. 21, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by Martin Dias

Hi I followed with interest the discussion but without many interventions. I want to explain an idea I have for supporting backward-compatibility without neither stabilizing the format nor getting the current code dirty. Maybe it's a bit crazy but I think it can be a practical solution. I would like to know your opinions. We can offer: - Maintain a *compatibility package* for each released version, that can co-exist in the same image. For example Fuel1_5, Fuel1_6, etc. Obviously, the current version always has the nice clean name (Fuel). - Provide a facade that works like "Fuel load: aFile asOfVersion: '1.4'" who interacts with the compatibility packages. To generate each *compatibility package*, we rename several elements of the original Fuel released package, this way: * Extension methods: Append at beggining of each extension method selector a prefix. For example: #fuelAccept: --> #fuel1_6_fuelAccept: * Classes: Append to each one some version identifier. For example: FLSerializer --> FLSerializer_1_6 * Methods: Fix each reference to a class or extension method selector THAT BELONGS to the package. For example: "FLSerializer new" --> "FLSerializer_1_6 new". I think it could be not that hard to make such renames automatically with a small tool. Then, we can simultaneously maintain each *compatibility package* (Fuel1_5, Fuel1_6, etc.) when Pharo evolves: Our Jenkins will run tests for all the compatibility Fuel packages. For example... Does Fuel1_7 stop working in Pharo1.5? then (if it's possible) we fix it, save the monticello version and mark it in our ConfigurationOfFuel as "this is the stable monticello version of fuel 1.7 in pharo 1.5". Now that I see how many lines I took to explain it, I think it's a bit insane. I hope to read some opinions! Bests, MartÃn On Thu, Oct 20, 2011 at 6:00 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Mariano, > > I gave you a pretty tough time :) It appears that you understand that I > did so with the best of intentions. Thanks for listening. > > One problem that I do *not* think you need to solve is that of old software > talking to new software. Someone wanting forward compatibility is probably > going to use XML or something similar to get a timeless protocol that will > be of necessity very simple. A good serializer is hard to write, and > forward-compatibility is probably too much to ask, particularly when > efficiency is a stated goal. > > A backwardly-compatible Fuel will be most welcome and useful. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez > Peck [marianopeck(a)gmail.com] > Sent: Thursday, October 20, 2011 7:00 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] When will Fuel file format stabilize? > > On Thu, Oct 20, 2011 at 12:54 PM, Ben Coman <btc(a)openinworld.com<mailto: > btc(a)openinworld.com>> wrote: > Mariano Martinez Peck wrote: > Well...thanks guys. The point is taken. Thanks Philip, Bill and all who > gave feedback and suggestions. We are aware of this and we are already > discussing with Martin possible solutions and analyzing all the things that > has been said in this thread. > We will keep you informed. > > Cheers > Just one thing I hadn't seen discussed. Is Fuel possibly a way to exchange > objects/data between users/systems ? > > Yes > > In which case it would have to deal with different systems having different > versions of Fuel. > > > Exactly. It doesn't matter whether the different versions of Fuel happens > in your own image or in different systems. So yes, it is the same problem. > Note this is not only a problem for Fuel, but for any serializer which does > not manages full backward compatibility between versions. > > > -- > Mariano > http://marianopeck.wordpress.com > > >

Oct. 20, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by Schwab,Wilhelm K

Mariano, I gave you a pretty tough time :) It appears that you understand that I did so with the best of intentions. Thanks for listening. One problem that I do *not* think you need to solve is that of old software talking to new software. Someone wanting forward compatibility is probably going to use XML or something similar to get a timeless protocol that will be of necessity very simple. A good serializer is hard to write, and forward-compatibility is probably too much to ask, particularly when efficiency is a stated goal. A backwardly-compatible Fuel will be most welcome and useful. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com] Sent: Thursday, October 20, 2011 7:00 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] When will Fuel file format stabilize? On Thu, Oct 20, 2011 at 12:54 PM, Ben Coman <btc(a)openinworld.com<mailto:btc@openinworld.com>> wrote: Mariano Martinez Peck wrote: Well...thanks guys. The point is taken. Thanks Philip, Bill and all who gave feedback and suggestions. We are aware of this and we are already discussing with Martin possible solutions and analyzing all the things that has been said in this thread. We will keep you informed. Cheers Just one thing I hadn't seen discussed. Is Fuel possibly a way to exchange objects/data between users/systems ? Yes In which case it would have to deal with different systems having different versions of Fuel. Exactly. It doesn't matter whether the different versions of Fuel happens in your own image or in different systems. So yes, it is the same problem. Note this is not only a problem for Fuel, but for any serializer which does not manages full backward compatibility between versions. -- Mariano http://marianopeck.wordpress.com

Oct. 20, 2011

Re: [Pharo-project] [Seaside] Re: Welcome to the "seaside" mailing list

by Dale Henrichs

Guillermo, To add to what others have said ... If you are doing JSON and REST then you will want both Seaside-REST and Seaside-JSON ... there are configurations for both I'm using both REST and JSON for tODE and the JSON canvas is very nice ... you can look at the tODE-Amber package in tODE if you want to see how I'm using them both... I think that if you load Seaside 3.0.6.2 into Pharo 1.3, then load the other configs you'll be successful. It looks like ConfigurationOfSeasideREST will load Seaside 3.0.6 which doesn't load into Pharo 1.3 anymore. I should change that configuration to use #stable instead ... Dale ----- Original Message ----- | From: "Guillermo Polito" <guillermopolito(a)gmail.com> | To: seaside(a)lists.squeakfoundation.org, "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> | Sent: Thursday, October 20, 2011 4:59:50 AM | Subject: [Seaside] Re: Welcome to the "seaside" mailing list | | | Hi! | | I need to set up a rest server serving JSON and I want to do it with | seaside, since I heard about it in the pharo's mailing list :). | | I found in squeaksource/MetacelloRepository a | ConfigurationOfSeasideRest, and the following link: | http://code.google.com/p/seaside/wiki/SeasideRest . But I didn't | manage to get it installed in my 1.3 image... I also googled and | looked in the seaside doc, but I didn't find a way to do it :(. | | Does anybody have a link or point me to some documentation? Or give | me some instructions of how to do it, hehe :P. | | Thanks! | Guille | | _______________________________________________ | seaside mailing list | seaside(a)lists.squeakfoundation.org | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |

Oct. 20, 2011

Re: [Pharo-project] Some bugs

by StÃ©phane Ducasse

Thanks andrea. We will a post release update. Stef On Oct 20, 2011, at 1:45 PM, Andrea BrÃ¼hlmann wrote: > I checked some of my previously reported bugs in pharo1.3 and added our fixes - thanks for integrating them :-) > > Please have a look at the following issues: > > New: > 4920: Copying a trait fails > 4919: Class copying issues > > Question: > 4688: Progress bar disappears on image save => Does "Milestone-1.4" mean you will not put the fix into 1.3? This would be too sad... > > > Not to forget: > > 4689: MessageTally bug > > http://code.google.com/p/pharo/issues/detail?id=4689 > > >> 4684: Missing ctrl+w (methodNamesContainingIt:) >> http://code.google.com/p/pharo/issues/detail?id=4684 >> 4686: Method category change creates no new version >> http://code.google.com/p/pharo/issues/detail?id=4686 >> 4692: Drop downs should select the default entry (topmost) instead of a middle one >> http://code.google.com/p/pharo/issues/detail?id=4692 > > -- > Andrea BrÃ¼hlmann >

Oct. 20, 2011

[Pharo-project] New COg VMs available at...

by Eliot Miranda

http://www.mirandabanda.org/files/Cog/VM/VM.r2502/ CogVM binaries as per VMMaker.oscog-eem.134/r2502 Ensure the unix run scripts set SQUEAK_PLUGINS if unset. Fix remaining bug in context access fixes of VMMaker.oscog-eem.119. stObject:at: and stObject:at:put: need to use stackPointerForMaybeMarriedContext: not fetchStackPointerOf:, since the context's stack pointer may be stale. Fix send trace printing. Interpreter sends need also to be printed. (A better fix is probably to redo sendBreakpoint: but this will serve for now). N.B. this reassigns the sendtrace flag values. Add primitiveNotEquivalent with prim # 169. -- best, Eliot

Oct. 20, 2011

Re: [Pharo-project] old windows in image not responding

by Mariano Martinez Peck

On Thu, Oct 20, 2011 at 5:54 PM, Ben Coman <btc(a)openinworld.com> wrote: > > I have just opened a Pharo image on Windows 7 that I haven't touched in > months. This was originally derived from the Pharo.1.2.1.OneCick, and the > TitleBar > 'Display Version Information' indicates "About Pharo on Win32 - > Pharo4.1.1 from Mar 3 2011". > I assume the image was left it in good working order, but now the 16 open > windows (including a pinned World Menu) are not responding to any mouse > click. Clicking over them brings up a fresh World Menu as if I just clicked > on the background. From this fresh World Menu, I can open a properly > functioning Workspace and Browser. It seems like a snapshot "old" windows > has become the background image, except that from the window-bar and bottom > of screen going "Windows > Collapse All Windows" does collapse the "old" > windows - and "Windows > Expand All Windows" restores them, but they still > cannot be selected. One of the "old" windows is a dialog box "Question: > Save changes before quitting Yes/No/Cancel" which is the single "old" window > I can select. Choosing Yes or No closes the image and choosing Cancel keeps > me in the image, but still with none of the "old" windows selectable. I > naively speculate that I was closing the image and walked away while "save > changes" dialog was open, and in the meantime the power dropped out to the > machine. > > It would be nice to regain access to some code snippets in the "old" > Workspace, but just closing all the "old" of them would be okay. > If you open a new workspace in the top right of the window, there is an arrow that brings options, included one called "Previous contents ..." cheers > Your thoughts on possible causes and alternatives to fix would be > appreciated. > cheers, Ben > > > > -- Mariano http://marianopeck.wordpress.com

Oct. 20, 2011

[Pharo-project] old windows in image not responding

by Ben Coman

I have just opened a Pharo image on Windows 7 that I haven't touched in months. This was originally derived from the Pharo.1.2.1.OneCick, and the TitleBar > 'Display Version Information' indicates "About Pharo on Win32 - Pharo4.1.1 from Mar 3 2011". I assume the image was left it in good working order, but now the 16 open windows (including a pinned World Menu) are not responding to any mouse click. Clicking over them brings up a fresh World Menu as if I just clicked on the background. From this fresh World Menu, I can open a properly functioning Workspace and Browser. It seems like a snapshot "old" windows has become the background image, except that from the window-bar and bottom of screen going "Windows > Collapse All Windows" does collapse the "old" windows - and "Windows > Expand All Windows" restores them, but they still cannot be selected. One of the "old" windows is a dialog box "Question: Save changes before quitting Yes/No/Cancel" which is the single "old" window I can select. Choosing Yes or No closes the image and choosing Cancel keeps me in the image, but still with none of the "old" windows selectable. I naively speculate that I was closing the image and walked away while "save changes" dialog was open, and in the meantime the power dropped out to the machine. It would be nice to regain access to some code snippets in the "old" Workspace, but just closing all the "old" of them would be okay. Your thoughts on possible causes and alternatives to fix would be appreciated. cheers, Ben

Oct. 20, 2011