- Pharo-dev - lists.pharo.org

[Pharo-project] Pharo par l'exemple est maintenant disponible :)

by StÃ©phane Ducasse

Vraiment un grand merci aux traducteurs! Encore merci Bientot sur lulu. Stef https://gforge.inria.fr/frs/download.php/28665/PharoParLExemple-20-06-2011.… Stef

June 22, 2011

Re: [Pharo-project] Swazoo keeping HTTPConnections open

by Janko MivÅ¡ek

Patch included in Swazoo. Thanks Nico! - http://www.squeaksource.com/Swazoo/Swazoo-2.3beta2.3 - ConfigurationOfSwazoo2 2.3 also updated Best regards Janko S, Nicolas Petton piÅ¡e: > Hi Bernat, > > I have a patch that may solve your problem that will be integrated > mainstream. In the meantime: > > HTTPConnection>>close > self stream notNil ifTrue: [self stream close. stream := nil]. > self server notNil ifTrue: [self server removeConnection: self]. > self loop notNil ifTrue: [ > | process | > process := loop. loop := nil. > process terminate] > > > HTH, > Nicolas > > Le mercredi 22 juin 2011 Ã 11:36 +0200, Bernat Romagosa a Ã©crit : >> Hi list, I don't know where should I address this issue, so please >> excuse me if this mail is a bit off-topic. >> >> >> I've been running an Iliad app in Pharo for a couple of months, and >> just today I realised the image was behaving quite sluggish, so I >> checked the process browser and discovered thousands (literally) of >> Delay >> wait instances going on. Inspecting them, I found out they >> had all been spawned by Swazoo's HTTPConnection >> interact. >> >> >> So what I did is HTTPConnection allInstancesDo: [:c | c close], which >> took quite a while to conclude, and the problem was solved, but these >> processes keep on spawning every time a user logs in, and they never >> seem to die unless I tell them to. >> >> >> Also, killing these processes seems to have no effect on the >> application behaviour at all, all sessions stay where they should and >> everything is alright, so I'm even considering using a scheduler that >> kills'em'all every hour or so (how elegant could this be!) >> >> >> Has anybody ran into a similar issue before? >> >> >> Thanks! >> >> -- >> Bernat Romagosa. >>

June 22, 2011

Re: [Pharo-project] Swazoo keeping HTTPConnections open

by Bernat Romagosa

Thanks! :) 2011/6/22 Nicolas Petton <petton.nicolas(a)gmail.com> > Hi Bernat, > > I have a patch that may solve your problem that will be integrated > mainstream. In the meantime: > > HTTPConnection>>close > self stream notNil ifTrue: [self stream close. stream := nil]. > self server notNil ifTrue: [self server removeConnection: self]. > self loop notNil ifTrue: [ > | process | > process := loop. loop := nil. > process terminate] > > > HTH, > Nicolas > > Le mercredi 22 juin 2011 Ã 11:36 +0200, Bernat Romagosa a Ã©crit : > > Hi list, I don't know where should I address this issue, so please > > excuse me if this mail is a bit off-topic. > > > > > > I've been running an Iliad app in Pharo for a couple of months, and > > just today I realised the image was behaving quite sluggish, so I > > checked the process browser and discovered thousands (literally) of > > Delay >> wait instances going on. Inspecting them, I found out they > > had all been spawned by Swazoo's HTTPConnection >> interact. > > > > > > So what I did is HTTPConnection allInstancesDo: [:c | c close], which > > took quite a while to conclude, and the problem was solved, but these > > processes keep on spawning every time a user logs in, and they never > > seem to die unless I tell them to. > > > > > > Also, killing these processes seems to have no effect on the > > application behaviour at all, all sessions stay where they should and > > everything is alright, so I'm even considering using a scheduler that > > kills'em'all every hour or so (how elegant could this be!) > > > > > > Has anybody ran into a similar issue before? > > > > > > Thanks! > > > > -- > > Bernat Romagosa. > > > > -- > Nicolas Petton > http://www.nicolas-petton.fr > > > -- Bernat Romagosa.

June 22, 2011

Re: [Pharo-project] Swazoo keeping HTTPConnections open

by Nicolas Petton

Hi Bernat, I have a patch that may solve your problem that will be integrated mainstream. In the meantime: HTTPConnection>>close self stream notNil ifTrue: [self stream close. stream := nil]. self server notNil ifTrue: [self server removeConnection: self]. self loop notNil ifTrue: [ | process | process := loop. loop := nil. process terminate] HTH, Nicolas Le mercredi 22 juin 2011 Ã 11:36 +0200, Bernat Romagosa a Ã©crit : > Hi list, I don't know where should I address this issue, so please > excuse me if this mail is a bit off-topic. > > > I've been running an Iliad app in Pharo for a couple of months, and > just today I realised the image was behaving quite sluggish, so I > checked the process browser and discovered thousands (literally) of > Delay >> wait instances going on. Inspecting them, I found out they > had all been spawned by Swazoo's HTTPConnection >> interact. > > > So what I did is HTTPConnection allInstancesDo: [:c | c close], which > took quite a while to conclude, and the problem was solved, but these > processes keep on spawning every time a user logs in, and they never > seem to die unless I tell them to. > > > Also, killing these processes seems to have no effect on the > application behaviour at all, all sessions stay where they should and > everything is alright, so I'm even considering using a scheduler that > kills'em'all every hour or so (how elegant could this be!) > > > Has anybody ran into a similar issue before? > > > Thanks! > > -- > Bernat Romagosa. > -- Nicolas Petton http://www.nicolas-petton.fr

June 22, 2011

[Pharo-project] Swazoo keeping HTTPConnections open

by Bernat Romagosa

Hi list, I don't know where should I address this issue, so please excuse me if this mail is a bit off-topic. I've been running an Iliad app in Pharo for a couple of months, and just today I realised the image was behaving quite sluggish, so I checked the process browser and discovered thousands (literally) of Delay >> wait instances going on. Inspecting them, I found out they had all been spawned by Swazoo's HTTPConnection >> interact. So what I did is HTTPConnection allInstancesDo: [:c | c close], which took quite a while to conclude, and the problem was solved, but these processes keep on spawning every time a user logs in, and they never seem to die unless I tell them to. Also, killing these processes seems to have no effect on the application behaviour at all, all sessions stay where they should and everything is alright, so I'm even considering using a scheduler that kills'em'all every hour or so (how elegant could this be!) Has anybody ran into a similar issue before? Thanks! -- Bernat Romagosa.

June 22, 2011

Re: [Pharo-project] #assert:equals: feels backwards

by Damien Cassou

On Tue, Jun 21, 2011 at 9:51 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > Why don't you just use #assert: and #=? > > This is much shorter and the description string is not really worth > the troubles, isn't it :-) When the test fails, you can debug more easily with #assert:equals:. If you use #assert: and #= you know that the boolean passed to #assert: is false, not really useful. If you use #assert:equals: you have the two objects and you can compare them. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 22, 2011

[Pharo-project] what about a sprint at lille July 8

by StÃ©phane Ducasse

June 22, 2011

Re: [Pharo-project] Pharo par l'exemple :)

by Olivier Auverlot

Le 22/06/11 08:42, StÃ©phane Ducasse a Ã©crit : >> Almost done ;-) >> >> We will put the final version soon on Lulu and on the website. >> The file is available here: >> http://ffii.fr/ramix/PBE/PharoParLExemple-20-06-2011.pdf > Stef > <happy> YOUAIHHHH !!!!! </happy> thanks to all the contributors Olivier ;-) www.auverlot.fr

June 22, 2011

[Pharo-project] Pharo par l'exemple :)

by StÃ©phane Ducasse

> Almost done ;-) > > We will put the final version soon on Lulu and on the website. > The file is available here: > http://ffii.fr/ramix/PBE/PharoParLExemple-20-06-2011.pdf Stef

June 22, 2011

Re: [Pharo-project] #assert:equals: feels backwards

by laurent laffont

On Wed, Jun 22, 2011 at 7:58 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Jun 22, 2011, at 7:44 AM, laurent laffont wrote: > > > Camillo and Dennis, > > > > Thanks for answer and yes, I think you're right about using > PhExample/Mocketry DSL, that's the way to go. > > except that I would not patch SUnit but have another Testing framework for > that. > And I\m not sure that I want to write should equals:..... not enought > experience to have a good point of view > > I don't know about PhExample but Mocketry does not patch SUnit but provide extensions to Object / SmallInteger / ... for the DSL part. It loads easily and also have an HelpSystem book :) Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfMocketry'; load. ConfigurationOfMocketry load. 1 should equal: 1. I think I will use it for TWM. Laurent. > > > Laurent. > > > > > > On Wed, Jun 22, 2011 at 6:31 AM, Dennis Schetinin <chaetal(a)gmail.com> > wrote: > > > > > > 2011/6/22 laurent laffont <laurent.laffont(a)gmail.com> > > IMO having the expected value before is the right way ! Do you TDD ? It > makes a lot of sense for me to write assert: expected equals: actual. Am I > alone ? > > > > I practice TDD, and I start tests with assertions (after naming them). > But I'm not sure I specify expected value first, as I'm focused on the > result (I write the test for). Btw, I use Mocketry and exploit its sugar (or > DSL?) for specifications there. So, I write: > > > > actualValue should equal: expectedValue. > > > > That is, after I've decided on a test case and named it, I think: what > should I test? That's the actualValue. I name and write it. And only after > that, I think about the value it should haveâ¦ well, in most cases at least. > > > > Anyway, I'm not sure an order I use to write assertion should be repeated > by assertion messages. Just as order I use to write a test (name -> > assertion -> the way to fetch the actual value -> â¦) is not reflected by > test code. It's much more important to have a readable and understandable > (after many months) code. And for me it's much more natural to read it this > way: > > > > self assert: actualValue equals: expectedValue > > > > > > > > If you do TDD, you have first to decide what you expect. You don't know > how to get it because the code doesn't exist yet. So you usually I write > > > > self assert: 'i want this' equals: > > > > then stop because I have to think about the interface / selectors / > object I want. So it matches the flow of thought when I'm writing tests. > > > > And the other weird thing is that with this "fix" I now have to change > hundred of tests I've written to be semantically correct !!!! > > > > > > Laurent. > > > > > > On Wed, Jun 22, 2011 at 12:39 AM, Sean P. DeNigris < > sean(a)clipperadams.com> wrote: > > > > Mariano Martinez Peck wrote: > > > > > > I don't understand Sean's problem. > > > > > > > Still using 1.2.2 :) Thanks for fixing it. > > > > Sean > > > > -- > > View this message in context: > http://forum.world.st/assert-equals-feels-backwards-tp3614760p3615548.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > > > > > > > > -- > > Dennis Schetinin > > > > >

June 22, 2011