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

Re: [Pharo-project] [ANN] Magma 1.2

by Elliot Finley

On Tue, Apr 19, 2011 at 4:08 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > Magma 1.2 is now finally released for Squeak 4.2, Pharo 1.1 and Pharo > 1.2. Â This new release offers improved performance thanks to > minimizing the problem associated with finalization, as well as > avoiding Squeak's slow become except once every 30 seconds. Â See Much thanks for this and especially for the improved documentation. Elliot

April 20, 2011

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

by Henrik Sperre Johansen

On 20.04.2011 01:13, Henrik Sperre Johansen wrote: > > Also, it's currently possible to register more than this limit in > current images (Smalltalk registerExternalObject:) without an error. > Am I correct in my reading of the code that when this happens, they > will never be signaled? > If so, we'd probably want to do some changes to ExternalSemaphoreTable :) > > Cheers, > Henry > Eheh, I guess so. I did it as part of testing and forgot about it, then when I wanted to publish the slice, I got stuck on a Socket semaphore which never signaled, and had to wait the entire timeout period before it proceeded. :) Cheers, Henry

April 19, 2011

Re: [Pharo-project] Announcer methods are bloated

by Henrik Sperre Johansen

On 20.04.2011 00:00, DougEdmunds wrote: > I'd vote to keep the subscribe:do: and subscribe:send:to methods, since that > seems to most clearly identify what they are doing. Maybe better would be > subscribeTo:do: and subscribeTo:send:to: > > A good example is the instance var 'announcer' in PragmaCollector which > holds requests to receive (subscriptions to) 'PragmaAnnouncement' and to > 'PragmaCollectorReset' announcements. > > subscribe: anAnnouncement send: aSelector to: anObject > "see Announcements packages" > self announcer subscribe: anAnnouncement send: aSelector to: anObject > > > whenChangedSend: aSelector to: anObject > "record a change listener" > self subscribe: PragmaAnnouncement send: aSelector to: anObject > > whenResetSend: aSelector to: anObject > "record a change listener" > self subscribe: PragmaCollectorReset send: aSelector to: anObject > In my eyes, an issue with subscribeTo: is that it kind of encourage giving announcement classes noun names rather than using verbs, if you want subscriptions to read naturally. on: does not have that problem to the same extent, and when: certainly doesn't. subscribe: reads awkwardly no matter what you name them, imo :) Of course, subscribe:'s big advantage is that it's not polymorphic with any existing system. Cheers, Henry

April 19, 2011

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

by Henrik Sperre Johansen

On 19.04.2011 20:19, Eliot Miranda wrote: > Hi Henrik, > > On Mon, Apr 18, 2011 at 1:23 AM, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@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. > > > Not so. The limit is soft. It can be accessed using Smalltalk > vmParameterAt: 49. It defaults to 256 entries. It maxes out it 64k > entries because the value set via vmParameterAt: 49 put: X persists in > a short in the image header. I expect 20k sockets to be sufficient > for a while, right? Ah, absolutely :D That's what I get for skimming readme's, think it'd be good to upgrade the comment though? No specific mention is made that it can be(although frowned upon)/how to set it after startup, currently it reads: "Another significant change is in the external semaphore table support code. This is now lock-free at the cost of having to specify a maximum number of external semaphores at start-up (default 256)." I guess having it accessible from image is one interpretation of that line, personally I thought it was that you could use some parameter when launching the executable :) Also, it's currently possible to register more than this limit in current images (Smalltalk registerExternalObject:) without an error. Am I correct in my reading of the code that when this happens, they will never be signaled? If so, we'd probably want to do some changes to ExternalSemaphoreTable :) Cheers, Henry

April 19, 2011

Re: [Pharo-project] [ANN] Magma 1.2

by Miguel CobÃ¡

Thanks Chris, I will install it this night and update the ConfigurationOfMagma and will set new #stable version both for Pharo 1.1.x and Pharo 1.2.x Thank you very much for your effort to keep Magma working on Pharo. We the Pharoers are very grateful. Cheers El mar, 19-04-2011 a las 17:08 -0500, Chris Muller escribiÃ³: > Magma 1.2 is now finally released for Squeak 4.2, Pharo 1.1 and Pharo > 1.2. This new release offers improved performance thanks to > minimizing the problem associated with finalization, as well as > avoiding Squeak's slow become except once every 30 seconds. See > > http://wiki.squeak.org/squeak/6163 > > for release-notes details. > > I just went through all of the wiki pages and fixed / updated several > of them, including new, clean, one-click installation scripts for for > Pharo: > > http://wiki.squeak.org/squeak/2657 > > Squeak users may install with one-click directly from the SqueakMap > Catalog user-interface. I hope Pharo will consider bringing this back > into a future version; SqueakMap already has several projects that > load from Metacello. > > I also realized several of Magma's special capabilities have been > undocumented. I've now documented them. > > http://wiki.squeak.org/squeak/6164 > > This release is, exactly, one year since Magma 1.1, thank you for your > patience. As before, support for Magma is described at: > > http://wiki.squeak.org/squeak/5818 > _______________________________________________ > Magma mailing list > Magma(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/magma -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

April 19, 2011

[Pharo-project] [ANN] Magma 1.2

by Chris Muller

Magma 1.2 is now finally released for Squeak 4.2, Pharo 1.1 and Pharo 1.2. This new release offers improved performance thanks to minimizing the problem associated with finalization, as well as avoiding Squeak's slow become except once every 30 seconds. See http://wiki.squeak.org/squeak/6163 for release-notes details. I just went through all of the wiki pages and fixed / updated several of them, including new, clean, one-click installation scripts for for Pharo: http://wiki.squeak.org/squeak/2657 Squeak users may install with one-click directly from the SqueakMap Catalog user-interface. I hope Pharo will consider bringing this back into a future version; SqueakMap already has several projects that load from Metacello. I also realized several of Magma's special capabilities have been undocumented. I've now documented them. http://wiki.squeak.org/squeak/6164 This release is, exactly, one year since Magma 1.1, thank you for your patience. As before, support for Magma is described at: http://wiki.squeak.org/squeak/5818

April 19, 2011

Re: [Pharo-project] Announcer methods are bloated

by DougEdmunds

I'd vote to keep the subscribe:do: and subscribe:send:to methods, since that seems to most clearly identify what they are doing. Maybe better would be subscribeTo:do: and subscribeTo:send:to: A good example is the instance var 'announcer' in PragmaCollector which holds requests to receive (subscriptions to) 'PragmaAnnouncement' and to 'PragmaCollectorReset' announcements. subscribe: anAnnouncement send: aSelector to: anObject "see Announcements packages" self announcer subscribe: anAnnouncement send: aSelector to: anObject whenChangedSend: aSelector to: anObject "record a change listener" self subscribe: PragmaAnnouncement send: aSelector to: anObject whenResetSend: aSelector to: anObject "record a change listener" self subscribe: PragmaCollectorReset send: aSelector to: anObject -- View this message in context: http://forum.world.st/Announcer-methods-are-bloated-tp3461131p3461644.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 19, 2011

Re: [Pharo-project] Announcer methods are bloated

by Henrik Sperre Johansen

On 19.04.2011 21:40, StÃ©phane Ducasse wrote: > Hi Doug > > in addition I do not like to use on:do: since I prefer to keep it for exception. > Now did you check senders of each of these methods? > What would be a path to go to your solution. In fact subscribe:do: is not a really good name too. > I prefer on: do: (even if I do not like the overload) and on:send:do: > > I think that we could deprecate when:do: first. > Then may be deprecate subscribe:do: > > Stef > > > > On Apr 19, 2011, at 8:07 PM, DougEdmunds wrote: > >> If Announcements are newly added to core (discussion at >> http://forum.world.st/Announcements-in-core-images-tc3188286.html) >> why not start with a trimmed down set of methods? Why start with bloat? >> >> Announcer has these two core methods: >> >> 1) subscribe:do >> 2) subscribe:send:to: >> >> are fine. >> >> There is no need for >> 3) on:do (just calls 1) >> 4) on:send:to: (just calls 2) >> 5) when:do (also justs calls 1) Personally, I'd keep when:do:, add when:do:for: and when:send:to, and deprecate the rest. Why? Mainly because that makes it the same as what you find in VisualWorks, so if Announcements happen to become an item for standardization some time in the future, there's less to quarrel about :) It also fits in nicely with being a replacement for events. Cheers, Henry

April 19, 2011

[Pharo-project] [update 1.3] #13164

by Marcus Denker

13164 ----- Issue 4060: KeyNotFoundAndValueNotFound Issue 4059: Fixed #cleanUpForRelease to not call #cleanUp on all classes but use Smalltalk>>#cleanUp: ... Issue 4053: remove empty package system-launcher -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 19, 2011

Re: [Pharo-project] [TODO 1.2.2] Steps to a 1.2.2 Release

by Lukas Renggli

Ideally you copy the versions to a location you control. You never know what happens with locations you don't control. Lukas On 19 April 2011 12:40, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Coool!Â so it is just a matter of copying your commits to PharoOB repo and > updating the confs :) > or just to update the confs to get the versions from your repo. > > On Mon, Apr 18, 2011 at 10:48 PM, Sven Van Caekenberghe <sven(a)beta9.be> > wrote: >> >> Great! >> >> On 18 Apr 2011, at 22:36, Lukas Renggli wrote: >> >> > I can confirm that OmniBrowser works in Pharo 1.2 and Pharo 1.3 with >> > refactoring tools, syntax highlighting and code completion. All tests >> > pass in the latest versions of both images: >> > >> > Â Â 2131 run, 2130 passes, 1 expected failures, 0 failures, 0 errors, >> > 0 unexpected passes >> >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Lukas Renggli www.lukas-renggli.ch

April 19, 2011