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

[Pharo-project] Send a notification
by Alexandre Bergel Dec. 2, 2011

Dec. 2, 2011

Hi! Together with Ivan we have been looking for an easy way to send notifications. We first thought about sending email directly from Pharo, but apparently it is not easy to send email. Anyone has experience with this? We then thought about emitting twitts, but there is a need to authorize the client. Anyone has experience? Maybe producing a RSS could do the thing? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

5 7

Re: [Pharo-project] [squeak-dev] Re: #ensure: What would you expect?
by Eliot Miranda Dec. 2, 2011

Dec. 2, 2011

On Fri, Dec 2, 2011 at 8:17 AM, Andreas Raab <andreas.raab(a)gmx.de> wrote: > There is only one possibly correct answer which is raising > BlockCannotReturn, because we're trying to return while we're in the midst > of returning already, so there is no place to return to. That answer is > implemented by the attached change set. > > BTW, the code duplication between ContextPart>>restart > ContextPart>>resume:, ContextPart>>unwindTo:, and Process>>terminate > bothers me greatly. The change set only fixes one of these locations (the > one triggered by your problem statement) but having such critical code > duplicated all over the places can't be good. Any takers? > The first thing is a good set of tests. Do we have some of them? Clearly we don't have them for this case. What's the scope of the tests? The second thing I find related is that I find ContextPart>jump incomprehensible and worrying. Using simulation machinery to advance execution just seems wrong with me and yet this code is used in process termination (via runUntilErrorOrReturnFrom:) and in exception handling (via ContextPart>restart). ContextPart>jump is extremely complex and slow and buggy (I recently ( eem 11/16/2011 10:58) found and fixed a bad bug in runUntilErrorOrReturnFrom: that was causing too much peeling back of the stack in exception delivery when trying to advance a process to a particular point suitable for presenting to the user. If we could simplify this code that would be a relief to me :) The third thing that is related is that if a process is terminated from a different process, then unwinds execute in the context of the process that initiated the termination, not the process being terminated. The fourth thing that is related in my mind is that Cog supports a much faster Mutex which is in use in OpenQwaq and could be ported to Squeak and Pharo. But it needs some work on process termination, to avoid losing a signal when a process is terminated while in a critical section on the mutex. This is related because fixing this requires some work on unwind implementation. I think all of these need addressing, but they shouldn't be conflated. I'm just writing them down here so they don't get forgotten. cheers, Eliot > Cheers, > - Andreas > > > On 12/2/2011 15:18, Tobias Pape wrote: > >> Dear All, >> >> given the following class: >> >> Object subclass: #Foo >> instanceVariableNames: '' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'Foo'! >> a >> self b: [^ 1].! ! >> >> b: aBlock >> >> [self c: aBlock] ensure: [^ 2]. >> >> c: aBlock >> >> aBlock value. >> ^ 3 >> >> And you would do >> >> Foo new a >> >> what would you expect? >> >> I am very curious. >> Please, first guess, then execute. >> >> Best >> -Tobias >> >> >> >> >> >> >> > > > > -- best, Eliot

2 1

[Pharo-project] Videos Pharo talks ESUG 2010/2011
by Marcus Denker Dec. 2, 2011

Dec. 2, 2011

Hi, The Pharo talks of ESUG 2011 and ESUG 2010 are online: ESUG 2011 Pharo RoadMap (missing the a bit at the end, I think) http://www.youtube.com/watch?v=cJfiNQ8zhIE Slides: http://www.slideshare.net/MarcusDenker/the-pharo-roadmap ESUG 2010: Pharo http://www.youtube.com/watch?v=pu-w9wX6RwQ Smalltalks 2011 Slides: http://www.slideshare.net/MarcusDenker/pharo-one-year-later Video: Not yet. Marcus -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] Prune stack serialization
by Martin Dias Dec. 2, 2011

Dec. 2, 2011

Hi folks In Fuel, we serialize a block closure with its state, including its outerContext. This enables to serialize a sorted collection with its sortBlock: | bytes result | bytes := FLSerializer serializeToByteArray: (SortedCollection sortBlock: [:a :b | a > b ]). result := FLMaterializer materializeFromByteArray: bytes. result addAll: #(1 2 3); yourself. ---> a SortedCollection(3 2 1) Here the problem: the byte array is huge! (800kb) because we are serializing unneeded context for the sort block. We wonder how to prune it and save time and space. Thanks in advance MartÃn

4 7

[Pharo-project] [TODO 1.3] Issues tagged 1.3
by Marcus Denker Dec. 2, 2011

Dec. 2, 2011

http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.3 ... the interesting thing is that there are 3 issues that have *solutions*, yet nobody looked at them since the last time I sent this email... I wonder how important actually is it to fix bugs? -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [TODO 1.4] Issues tagged 1.4
by Marcus Denker Dec. 2, 2011

Dec. 2, 2011

http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.4 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] MethodDictionary rehash crash [WAS]Issue 4914 in pharo: #14196 VM crash on #cleanUpForRelease
by Mariano Martinez Peck Dec. 2, 2011

Dec. 2, 2011

Wierd...maybe Nicolas o Levente can help us? ---------- Forwarded message ---------- From: <pharo(a)googlecode.com> Date: Fri, Dec 2, 2011 at 5:00 PM Subject: Re: [Pharo-bugtracker] Issue 4914 in pharo: #14196 VM crash on #cleanUpForRelease To: pharo-bugtracker(a)lists.gforge.inria.fr Comment #9 on issue 4914 by marcus.d...(a)gmail.com: #14196 VM crash on #cleanUpForRelease http://code.google.com/p/**pharo/issues/detail?id=4914<http://code.google.com/p/pharo/issues/detail?id=4914> But ScriptLoader new cleanUpForRelease crashes the VM with that change and does not crash without. ______________________________**_________________ Pharo-bugtracker mailing list Pharo-bugtracker(a)lists.gforge.**inria.fr<Pharo-bugtracker(a)lists.gforge.inria.fr> http://lists.gforge.inria.fr/**cgi-bin/mailman/listinfo/**pharo-bugtracker<http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker> -- Mariano http://marianopeck.wordpress.com

1 0

[Pharo-project] [update 1.4] #14242
by Marcus Denker Dec. 2, 2011

Dec. 2, 2011

14242 ----- Issue 1817: [etoy] Should remove project http://code.google.com/p/pharo/issues/detail?id=1817 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [COTDC] 88 - TextConstants
by DeNigris Sean Dec. 2, 2011

Dec. 2, 2011

Continuing in Collections... Today: TextConstants Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest

3 5

[Pharo-project] [COTDC] 86 - TextURL
by Sean P. DeNigris Dec. 2, 2011

Dec. 2, 2011

Continuing in Collections... Today: TextURL Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest -- View this message in context: http://forum.world.st/COTDC-86-TextURL-tp4119838p4119838.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 5