- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Networking change in Pharo 1.2?

by Chris Muller

This is the VM I used: 3.9-7 #1 Sun Feb 6 18:58:21 PST 2011 gcc 4.1.2 Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.47] Linux mcqfes 2.6.18-128.el5 #1 SMP Wed Jan 21 10:44:23 EST 2009 i686 i686 i386 GNU/Linux plugin path: /opt/4dst/thirdparty/squeak/lib/squeak/3.9-7/ [default: /opt/4dst/thirdparty/squeak/lib/squeak/3.9-7/] However, I use this same VM when I run the test in Pharo 1.1.1 and it's solid. - Chris On Mon, Apr 18, 2011 at 3:23 AM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 17.04.2011 22:48, Chris Muller wrote: >> >> I was able to work on getting Magma 1.2 going in Pharo. Â It was quite >> easy to get the code loaded and functioning in Pharo 1.1.1, Pharo 1.2, >> and Pharo 1.3. >> >> But something seems to have changed in Pharo's networking from 1.1.1 >> to 1.2. Â All Magma functionality seems to work fine for low-volume >> activity. Â However, when the test-suite gets to the HA test cases (at >> the end), one of the images performing heavy networking activity, >> consistently gets very slow and bogged down for some reason; causing >> the clients to timeout and disrupting the test suite. Â Fortunately, it >> happens in the same place in the test-suite every time. >> >> The UI of the image in question becomes VERY sluggish, but >> MessageTally spyAllOn: didn't reveal anything useful. Â What is it >> doing? Â I did verify that the Magma server in that image is still >> functioning; clients were committing, but I had to increase their >> timeouts from 10 to 45 seconds to avoid timeouts.. >> >> Unfortunately, two days of wrangling in Pharo (because I'm an old >> Squeak dog) I could not nail the problem down; but I have one >> suspect.. Â A couple of times, I caught a process seemingly hung up in >> NetworkNameResolver; trying to resolve an IP from 'localhost'. >> >> This exact set of Magma packages is rock-solid on Pharo 1.1.1 and >> Squeak, but that doesn't mean the problem for sure lies in Pharo 1.2; >> maybe a networking bug in 1.1.1 is allowing Magma to "misuse" the >> network and get away with it and Pharo 1.2 is now more strict? Â I >> don't know, I would just like to ask the experts here for help who >> know all what went into Pharo 1.2 so hopefully we can get to the >> bottom of it. >> >> Thanks, >> Â Chris >> > Which VM did you run these tests on? > IIRC, Cog has a hard limit on how many external semaphores are available, > and each Socket consumes 3 of those. > So if you are running on Cog, the problem when under heavy load may be that > there simpy aren't enough free external semaphores to create enough > sockets... > > Cheers, > Henry > >

April 18, 2011

[Pharo-project] [update 1.3] #13162

by Marcus Denker

13162 ----- -> cleanup tests -> Browser class>>#cleanUp should not re-register browser -> add repos to all packages -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 18, 2011

Re: [Pharo-project] Last chance to Nile

by Noury Bouraqadi

We should not have two libraries for the same thing in the default image. Do we want/are we ready to switch to Nile? In the Ocean project, we'll consider using it instead of the old socketstream. But so far, our focus is to have the low-level sockets working. On 15 avr. 2011, at 17:36, Mariano Martinez Peck wrote: > Every single release we do, I've to spend a lot of time making Nile tests green. We have not never even received a mail in the mailing list about Nile. So..or nobody care about its tests, or nobody use it. > So...if tests are not green when Pharo 1.3 release arrives, we will remove it from the dev image. It's a pity because I like the project and I like to see Traits. > > Regards, > > -- > Mariano > http://marianopeck.wordpress.com > Noury Bouraqadi http://car.mines-douai.fr/noury -- -6th National Conference on âControl Architecture of Robotsâ 24-25 may 2011, Grenoble area, France http://car2011.inrialpes.fr/ -19th ESUG International Smalltalk Conference 22-26 August 2011, Edinburgh, UK http://www.esug.org/Conferences/2011 -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France

April 18, 2011

[Pharo-project] [update 1.3] #13161

by Marcus Denker

13161 ----- Issue 3990: 2 dependencies removed from ToolBuilder: PluggableMenuSpec & PluggableMenuItemSpec Issue 4045: Failing Test: SystemNavigationOnNewlyCreatedEnvironmentTest >> #testAllReferencesToPool Issue 4044: Failing test: SystemVersionTest>>#testMajorMinor Issue 4043: Undeclared NoSuchElementError Issue 4004: Obsolete class references to AutoStart Issue 4029: DomainError and NaNException -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 18, 2011

Re: [Pharo-project] Issue 4036 in pharo: Please update Help> Announcements tutorial

by Henrik Sperre Johansen

This section should probably also explain the concept of the subscriber, ie. the thing you need to unregister for the announcement to stop being sent. For message sends (on:send:to:) it is the receiver (to: argument), for blocks (on: do:) it's the object where block is defined. #on:do:for:/#when:do:for, which lets you specify another object as subscriber for block actions, is currently not implemented. It's also a difference from the VW implementation, where when:do: uses the action block itself as subscriber, so you're much more likely to need on:do:for:. Cheers, Henry On 18.04.2011 11:13, Henrik Sperre Johansen wrote: > On 18.04.2011 10:47, Fernando Olivero wrote: >> To remove the subscription you can evaluate: World announcer initialize. >> >> Maybe the tutorial should add (pesudo code): >> >> MyStuff>>initialize >> World announcer >> on: WindowOpened >> send: #showOnTranscript >> to: self >> SystemAnnouncer on:#classremove send:#release: to: self. >> >> MyStuff>>release: anAnn >> World announcer unsuscribe: self. >> >> MyStuff>>showOnTranscript >> Transcript show: 'A new window was opened';cr >> >> I can update the tutorial if people agrees on the pseudo code. >> >> >> To open a transcript evaluate: TranscriptMorph openWindow >> (decoupled Transcript from Morphic, so directly ask the view to open >> itself) >> >> Fernando > > The old tutorial was weak mainly because it didn't tell you how to > unsubscribe. > > > Here's a few examples of that: > > "Unsubscribe automatically with weak announcements." > World announcer weak > on: WindowOpened > send: #shownOnTranscript > to: self. > > Then example in Workspace > obj := self new. > "Open a window, and see Transcript printing" > obj := nil. > "Open a window, you may see Transcript printing (depending on > finalization)" > "Now force finalization" > Smalltalk garbageCollect. > "Open a window, now see no transcript prints." > > > "Automatically unregister after handling one announcement" > initialize > World announcer > on: WindowOpened > do: [:ann: announcer | self shownOnTranscript. > announcer unsubscribe: self.] > > "Unregister specifically after some time" > initialize > World announcer > on: WindowOpened > send: #shownOnTranscript > to: self. > > release > World announcer unsubscribe: self. > > "Using same action block registered for multiple announcers, > unregister specifially at a specific time" > initialize > handlesAnnoucements := true. > actionBlock:= [:ann :announcer | > handlesAnnouncement > ifTrue: [self shownOnTranscript] > ifFalse: [announcer unsubscribe: self]]. > World announcer on: WindowOpened do: actionBlock. > AnnouncerTest announcer on: TestCaseEnded do: actionBlock. > > release > handlesAnnouncements := false. > > > > > >

April 18, 2011

Re: [Pharo-project] Issue 4036 in pharo: Please update Help> Announcements tutorial

by Henrik Sperre Johansen

On 18.04.2011 10:47, Fernando Olivero wrote: > To remove the subscription you can evaluate: World announcer initialize. > > Maybe the tutorial should add (pesudo code): > > MyStuff>>initialize > World announcer > on: WindowOpened > send: #showOnTranscript > to: self > SystemAnnouncer on:#classremove send:#release: to: self. > > MyStuff>>release: anAnn > World announcer unsuscribe: self. > > MyStuff>>showOnTranscript > Transcript show: 'A new window was opened';cr > > I can update the tutorial if people agrees on the pseudo code. > > > To open a transcript evaluate: TranscriptMorph openWindow > (decoupled Transcript from Morphic, so directly ask the view to open itself) > > Fernando The old tutorial was weak mainly because it didn't tell you how to unsubscribe. Here's a few examples of that: "Unsubscribe automatically with weak announcements." World announcer weak on: WindowOpened send: #shownOnTranscript to: self. Then example in Workspace obj := self new. "Open a window, and see Transcript printing" obj := nil. "Open a window, you may see Transcript printing (depending on finalization)" "Now force finalization" Smalltalk garbageCollect. "Open a window, now see no transcript prints." "Automatically unregister after handling one announcement" initialize World announcer on: WindowOpened do: [:ann: announcer | self shownOnTranscript. announcer unsubscribe: self.] "Unregister specifically after some time" initialize World announcer on: WindowOpened send: #shownOnTranscript to: self. release World announcer unsubscribe: self. "Using same action block registered for multiple announcers, unregister specifially at a specific time" initialize handlesAnnoucements := true. actionBlock:= [:ann :announcer | handlesAnnouncement ifTrue: [self shownOnTranscript] ifFalse: [announcer unsubscribe: self]]. World announcer on: WindowOpened do: actionBlock. AnnouncerTest announcer on: TestCaseEnded do: actionBlock. release handlesAnnouncements := false.

April 18, 2011

Re: [Pharo-project] Issue 4036 in pharo: Please update Help> Announcements tutorial

by Fernando Olivero

To remove the subscription you can evaluate: World announcer initialize. Maybe the tutorial should add (pesudo code): MyStuff>>initialize World announcer Â Â Â Â Â Â Â Â on: WindowOpened Â Â Â Â Â Â Â Â send: #showOnTranscript Â Â Â Â Â Â Â Â to: self SystemAnnouncer on:#classremove send:#release: to: self. MyStuff>>release: anAnn World announcer unsuscribe: self. MyStuff>>showOnTranscript Transcript show: 'A new window was opened';cr I can update the tutorial if people agrees on the pseudo code. To open a transcript evaluate: TranscriptMorph openWindow (decoupled Transcript from Morphic, so directly ask the view to open itself) Fernando On Sun, Apr 17, 2011 at 12:41 PM, <pharo(a)googlecode.com> wrote: > Status: Accepted > Owner: marcus.d...(a)gmail.com > > New issue 4036 by marcus.d...(a)gmail.com: Please update Help> Announcements > tutorial > http://code.google.com/p/pharo/issues/detail?id=4036 > > 1. Not understanding how announcements work, I tried the tutorial > information > found under > World menu > Help> Help Browser > Announcements framework > > 2. Under Tutorial - Step 3, there is this line: > > Â "Transcript open." Â That crashes, because apparently Transcript no longer > understands 'open'. Â How do you open a Transcript from a workspace under > 1.3? > > 3. Â I created a category 'Sandbox', and a class 'MyStuff'. Â I put the code > from Tutorial -Step 3 into a method called anno1 > > Object subclass: #MyStuff > Â Â Â Â instanceVariableNames: '' > Â Â Â Â classVariableNames: '' > Â Â Â Â poolDictionaries: '' > Â Â Â Â category: 'Sandbox'! > > !MyStuff methodsFor: 'as yet unclassified' stamp: 'DougEdmunds 4/14/2011 > 16:27'! > anno1 > Â Â Â Â | announcer | > Â Â Â Â World announcer > Â Â Â Â Â Â Â Â on: WindowOpened > Â Â Â Â Â Â Â Â send: #value > Â Â Â Â Â Â Â Â to: [ Transcript show: 'A new window was opened';cr].! ! > > I ran "MyStuff new anno1." in a workspace. > Now every time I open a window, the Transcript shows. Â "A new window was > opened." > > 4. Â I removed the MyStuff class. Â But every time I open a window, the > Transcript still shows "A new window was opened." > > I return to the Announcements Tutorial, and there is NO EXPLANATION how to > get rid of this 'announcement' or whatever I should call the line that > appears in the Transcript. > > 6. So, please whoever wrote the Tutorial, update it. > > 7. And the more immediate question: how do I stop automatically printing Â 'A > new window was opened' Â in the Transcript every time I open a window? > > > >

April 18, 2011

Re: [Pharo-project] [ANN] new mailinglist for tracker mails

by Marcus Denker

On Apr 18, 2011, at 10:32 AM, Geert Claes wrote: > I added the new list to forum.world.st at: > http://forum.world.st/Pharo-Issue-Tracker-f3456798.html > > I do have one question though, is it possible to remove the "Re: " prefix to > the items that are automatically posted to that list? > sadly there is nothing possible to configure at the google issue tracker (and no I do not have time to build a mail filter for this...) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 18, 2011

Re: [Pharo-project] [ANN] new mailinglist for tracker mails

by Geert Claes

I added the new list to forum.world.st at: http://forum.world.st/Pharo-Issue-Tracker-f3456798.html I do have one question though, is it possible to remove the "Re: " prefix to the items that are automatically posted to that list? -- View this message in context: http://forum.world.st/ANN-new-mailinglist-for-tracker-mails-tp3456696p34569… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 18, 2011

Re: [Pharo-project] Networking change in Pharo 1.2?

by Henrik Sperre Johansen

On 17.04.2011 22:48, Chris Muller wrote: > I was able to work on getting Magma 1.2 going in Pharo. It was quite > easy to get the code loaded and functioning in Pharo 1.1.1, Pharo 1.2, > and Pharo 1.3. > > But something seems to have changed in Pharo's networking from 1.1.1 > to 1.2. All Magma functionality seems to work fine for low-volume > activity. However, when the test-suite gets to the HA test cases (at > the end), one of the images performing heavy networking activity, > consistently gets very slow and bogged down for some reason; causing > the clients to timeout and disrupting the test suite. Fortunately, it > happens in the same place in the test-suite every time. > > The UI of the image in question becomes VERY sluggish, but > MessageTally spyAllOn: didn't reveal anything useful. What is it > doing? I did verify that the Magma server in that image is still > functioning; clients were committing, but I had to increase their > timeouts from 10 to 45 seconds to avoid timeouts.. > > Unfortunately, two days of wrangling in Pharo (because I'm an old > Squeak dog) I could not nail the problem down; but I have one > suspect.. A couple of times, I caught a process seemingly hung up in > NetworkNameResolver; trying to resolve an IP from 'localhost'. > > This exact set of Magma packages is rock-solid on Pharo 1.1.1 and > Squeak, but that doesn't mean the problem for sure lies in Pharo 1.2; > maybe a networking bug in 1.1.1 is allowing Magma to "misuse" the > network and get away with it and Pharo 1.2 is now more strict? I > don't know, I would just like to ask the experts here for help who > know all what went into Pharo 1.2 so hopefully we can get to the > bottom of it. > > Thanks, > Chris > Which VM did you run these tests on? IIRC, Cog has a hard limit on how many external semaphores are available, and each Socket consumes 3 of those. So if you are running on Cog, the problem when under heavy load may be that there simpy aren't enough free external semaphores to create enough sockets... Cheers, Henry

April 18, 2011