- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Why we have Behavior >> flushCache?

by Eliot Miranda

Mariano, the point is that it is classes that manage adding methods to classes and hence it is their private behavior to flush the VM's method cache. You'll see "self flushCache" in Smalltalk-80 v2 images. Now of course the VM provides selective cache flushing but back in the day adding or removing a method implied flushing the whole cache. Personally I don't see that this justifies adding Smalltalk vm yet. I would wait until you have a few more use cases. On Tue, Apr 26, 2011 at 3:34 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi. As far as I can see, > > Behavior >> flushCache > "Tell the interpreter to remove the contents of its method lookup > cache, if it has > one. Essential. See Object documentation whatIsAPrimitive." > > <primitive: 89> > self primitiveFailed > > > And primitive 89 does nothing in particular with the receiver (the class in > this case). In both, InterpreterVM and Cog, the WHOLE cache is flushed, > there is NOTHING related to the receiver class. Of course, that's at least > what it looks for me (please tell me if I am wrong). > So...if this is the case, wouldn't make sense to move it elsewhere? like > Smalltalk flushCache or Smalltalk vm flushCache (and it is a good moment to > reify the VM). So after we can do: Smalltalk vm version. Smalltlak vm > flushCache, Smalltalk vm parameterAt: , etc.... > > If you don't like doing "Smalltalk vm" then we can create a VM class with > all class methods, or a singleton and use #current or a singleton and put it > in Smalltalk globals...etc > > We will need to fix a couple of senders, thus. > > What do you think? For me is really confusing, and you don't understand it > until you see the primitive implementation. > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com > >

April 26, 2011

[Pharo-project] Process for fixing a package in stable but not in core?

by Michael Forster

Hi, Forgive me, but I'm still new to the Pharo development process, and my problem lies somewhere between being a Pharo developer and user. First, "Beeper beep" does not work in the current 1.2.1 image that I'm using for production. I need to fix it and would like to share that fix with the community. Second, I see from (closed) Issue 3489 that this is not a Pharo core problem, but one with the PharoSound package, and that, apparently, it might be fixed in the latest package version. Third, I fire up my 1.2.1 image, open the PharoSound squeaksource repository in the monticello browser and discover that, as expected, squeaksource does have some newer packages than the image. For example, 1.2.1-image: Sound-GuillermoPolito.63 vs. squeaksource: Sound-MarianoMartinezPeck.65 However, in other cases, the squeaksource package is _older_ than the image's. For example, squeaksource: ConfigurationOfPharoSound-GuillermoPolito.17 vs. 1.2.1-image: ConfigurationOfPharoSound-GuillermoPolito.22. How does one make sense of this? While can I reliably get the latest version of PharoSound loaded in a 1.2.1 image so that I know I'm writing and testing my fixes against a version that I can give back to the community -- and, more importantly, won't be blown away by some upcoming package version juggling? Thanks, Mike

April 26, 2011

[Pharo-project] [COTDC] 54 - BMPReadWriter

by laurent laffont

Today: BMPReadWriter 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 Laurent Laffont - @lolgzs <http://twitter.com/#%21/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st

April 26, 2011

Re: [Pharo-project] [COTDC] 53 - AnimatedGIFReadWriter

by laurent laffont

On Thu, Apr 21, 2011 at 8:38 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Today: AnimatedGIFReadWriter > Read an animated GIF file. Example: open all images of an animated GIF file in a Morphic window gifPath := '/path/to/my_animated.gif'. forms := (AnimatedGIFReadWriter formsFromFileNamed: gifPath) forms. content := UITheme builder newRow: (forms collect: [:aForm| UITheme builder newImage: aForm]). content openInWindowLabeled: 'Content of ', gifPath. Laurent > > > > > > > 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 > > Laurent Laffont - @lolgzs <http://twitter.com/#%21/lolgzs> > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/ > Developer group: http://cara74.seasidehosting.st > >

April 26, 2011

Re: [Pharo-project] Suggestions: move examples from UIThemes class to ExampleBuilderMorph class

by Mariano Martinez Peck

http://www.pharo-project.org/community/issue-tracking http://www.pharocasts.com/2010/03/how-to-contribute-to-pharo.html On Tue, Apr 26, 2011 at 9:44 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > edmund > > enter bug entries else your suggestions will be lost. > > Stef > > On Apr 25, 2011, at 8:56 PM, DougEdmunds wrote: > > > A couple of suggestions > > > > Part 1. > > Move the methods in the UIThemes class, protocol 'examples' to > > ExampleBuilderMorph class, protocol 'examples'. > > > > Rationale: Every one of these examples first creates an instance of > > ExampleBuilderMorph > > as the base class that the example is built on. These examples do not > > demonstrate > > anything about how to use UITheme. > > > > I made a file that duplicates the methods from UITheme class -examples- > to > > ExampleBuilderMorph class -examples-, suitable for filein. Methods such > as > > ExampleBuilderMorph class >>exampleBasicControls work fine, > > indicating they have no dependence on UITheme. > > The file's 347 lines, so I'm not posting it here, unless requested. > > > > Part 2. > > Then move ExampleBuilderMorph and ExampleRadioButtonModel from > > Polymorph-Widgets > > into a new package called Polymorph-Widgets-Examples. > > > > Rationale: This would be reduce the size of Polymorph-Widgets, and make > it > > more > > obvious that there are some examples of the widgets to look at. > > UITheme class is not the place where one expects to find examples of > > buttons, > > checkboxes, etc. Also this would be consistent with other Morphic > packages. > > (Morphic-MorphTreeWidget and Morphic-MorphTreeWidget-Examples) > > > > --- > > > > > > > > > > > > -- > > View this message in context: > http://forum.world.st/Suggestions-move-examples-from-UIThemes-class-to-Exam… > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > -- Mariano http://marianopeck.wordpress.com

April 26, 2011

[Pharo-project] a problem with Zinc on Pharo 1.1.1

by Esteban Lorenzano

Hi, I'm trying to execute this: ZnClient get: 'http://127.0.0.1:333/analytics/feeds/data' username: 'estebanlm(a)gmail.com' password: 'shhhh' ... on a Pharo 1.1.1 image, with latest #stable Zinc version, and I'm getting DNU on: #mimeEncode:multiLine: ZnUtils class>encodeBase64: string ^ (Base64MimeConverter mimeEncode: string readStream multiLine: false) contents is a bug, or something I have wrong? cheers, Esteban

April 26, 2011

Re: [Pharo-project] About testing that ensure works

by Henrik Sperre Johansen

On 26.04.2011 17:37, Igor Stasenko wrote: > On 26 April 2011 15:11, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> On 24.04.2011 12:05, StÃ©phane Ducasse wrote: >>>> i am puzzled. You wanna to be sure that ensure block are executed? >>>> It is. >>> I want to write a test that shows and tests the withOrganizer:do: >>> semantics. >>> In particular that the ensure is executed and that the context set by the >>> withOrganizer: is only present >>> in the do: block. >>> >> In other words, another use case probably written more cleanly using the >> non-existing >> Announcer>> #suspend: subscriber while: aBlock >> > What is potential implementation? > > Announcer>>suspend: subscriber while: aBlock > | subscriptions | > > subscriptions := OrderedCollection new. > > registry subscriptionsOf: subscriber do: [:each | > subscriptions add: each > ]. > registry removeSubscriber: subscriber. > > ^ aBlock ensure: [ subscriptions do: [:ea | registry add: ea ] ] > > > The problem is that its not doing exactly what is said: > - it suspends existing subscriptions instead of suspending subscriber. > > The difference between those are subtle but important: > a suspended subscriber should not receive any announcements during > block evaluation, > even if it may want to subscribe to new ones during given block evaluation. > And the code above not handling this case , as well as it doesn't > handling the case when subscriber may want > to occasionally unsubscribe from some announcements during block evaluation. > > So, for doing this correctly, a subscription registry should keep a > list of suspended subscribers somewhere, > and then in #deliver: > it should check if subscription's subscriber are not in that list, and > only then let it deliver an announcement. > > The problem is that delivery time will slowdown considerably, because > for every subscription you should check > if it's subscriber are not in 'suspended subscribers' list. > > > So, it is really depends on intent. Suspending a concrete subscription > will require adding 'suspended' flag to subscription state. > But suspending a concrete subscriber and to guarantee that it won't > receive any announcements (even if it will subscribe for > a new ones during suspension time), can't be solved by having > 'suspended' ivar on subscription. You have to manage suspended > subscribers list separately. > That'a a rather farfetched usecase it'd be nice to note in a method comment is NOT supported at the moment, nothing more imho :) Simply providing something like: suspend(SubscriptionsOf): subscriber while: aBlock |oldSubs| oldSubs := subscriptionRegistry removeSubscriber: subscriber. aBlock ensure: [oldSubs do: [ :each | subscriptionRegistry add: each]] is better than nothing. Cheers, Henry

April 26, 2011

Re: [Pharo-project] What is a well documented class?

by StÃ©phane Ducasse

I did not imply anything special. I just remember when lukas started to write comments on seaside while I was driving on the high way to Nice. I said ok let us start :) But I regularly got burned by comments absence and I spend time writing them because I like when the code tell: stef you are so smart, you guess well what I'm doing. Because comments are about reinforcement of hypothesis. Stef > > StÃ©phane Ducasse wrote: >> >> >> yes but.... let us write more comments. >> All the rest is arguments not to write them which is far easier as usual. >> >> Stef >> > > Absolutely. Sorry, I didn't mean to imply otherwise. > > Mike > > -- > View this message in context: http://forum.world.st/What-is-a-well-documented-class-tp3470956p3475730.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

April 26, 2011

Re: [Pharo-project] Hudson version 2.0 is available

by Henrik Sperre Johansen

On 26.04.2011 17:32, DougEdmunds wrote: > Pharo is being developed on a Hudson 1.358 server (2010/05/14). > Hudson has recently released version 2.0 (2011/04/21). > http://hudson-ci.org/ > > -- > View this message in context: http://forum.world.st/Hudson-version-2-0-is-available-tp3475761p3475761.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > Takes some time to get INRIA operations to approve and do installation of new versions apparently :) Anyways, I suspect the next installed version will be of Jenkins, not Hudson. Cheers, Henrt

April 26, 2011

Re: [Pharo-project] About testing that ensure works

by Igor Stasenko

On 26 April 2011 15:11, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 24.04.2011 12:05, StÃ©phane Ducasse wrote: >>> >>> i am puzzled. You wanna to be sure that ensure block are executed? >>> It is. >> >> I want to write a test that shows and tests the withOrganizer:do: >> semantics. >> In particular that the ensure is executed and that the context set by the >> withOrganizer: is only present >> in the do: block. >> > In other words, another use case probably written more cleanly using the > non-existing > Announcer >> #suspend: subscriber while: aBlock > What is potential implementation? Announcer >>suspend: subscriber while: aBlock | subscriptions | subscriptions := OrderedCollection new. registry subscriptionsOf: subscriber do: [:each | subscriptions add: each ]. registry removeSubscriber: subscriber. ^ aBlock ensure: [ subscriptions do: [:ea | registry add: ea ] ] The problem is that its not doing exactly what is said: - it suspends existing subscriptions instead of suspending subscriber. The difference between those are subtle but important: a suspended subscriber should not receive any announcements during block evaluation, even if it may want to subscribe to new ones during given block evaluation. And the code above not handling this case , as well as it doesn't handling the case when subscriber may want to occasionally unsubscribe from some announcements during block evaluation. So, for doing this correctly, a subscription registry should keep a list of suspended subscribers somewhere, and then in #deliver: it should check if subscription's subscriber are not in that list, and only then let it deliver an announcement. The problem is that delivery time will slowdown considerably, because for every subscription you should check if it's subscriber are not in 'suspended subscribers' list. So, it is really depends on intent. Suspending a concrete subscription will require adding 'suspended' flag to subscription state. But suspending a concrete subscriber and to guarantee that it won't receive any announcements (even if it will subscribe for a new ones during suspension time), can't be solved by having 'suspended' ivar on subscription. You have to manage suspended subscribers list separately. -- Best regards, Igor Stasenko AKA sig.

April 26, 2011