January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] glamour and pharo

by Guido Stepken

I foresee Pharo as multithreaded OS, like HP's dropped WebOS. All based on one interpreter. Why not? Guido Stepken Am 02.01.2012 um 17:41 schrieb Lukas Renggli <renggli(a)gmail.com>: >> IMHO, Pharo can never be just what Lukas propose: just a kernel, like linux, allowing different distributions. > > Esteban, why not? Can you give one technical reason why what Linux > does cannot work for Pharo? > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Jan. 2, 2012

Re: [Pharo-project] glamour and pharo

by Lukas Renggli

> IMHO, Pharo can never be just what Lukas propose: just a kernel, like linux, allowing different distributions. Esteban, why not? Can you give one technical reason why what Linux does cannot work for Pharo? Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 2, 2012

[Pharo-project] [ANN] Aida 6.4 Christmas Edition released

by Janko MivÅ¡ek

Dear Smalltalkers, Well, Christmas is over but to keep with a tradition here is a new Aida 6.4 on Squeak/Pharo and VisualWorks, as a present for Smalltalk community in New Year :) This one is mostly a maintenance release with two new features: * image backup before hourly snapshot * event handling: WebElement #on: anEventSymbol do: aBlock Enhancements: * Widget simplifications and enhancements * form support now works in all possible combinations * Widget examples added to demos More in Release notes: http://www.aidaweb.si/release-notes-6.4 The easiest way to Aida is One-Click Pharo image accessible from: http://www.aidaweb.si/download If you want to load by yourself: on Pharo it is really simple to load, just evaluate this script: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfAida'; load. (Smalltalk at: #ConfigurationOfAida) load. Then simply open http://localhost:8888 . Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Jan. 2, 2012

Re: [Pharo-project] [ VM ]Smalltalk getSystemAttribute:

by Esteban Lorenzano

Hi, I was trying to fix this, but seems to be a problem (besides the "'-psn_0_528513'", which is an error). According SmalltalkImage>>#getSystemAttribute: comment, getSystemAttribute: 0 shouldn't answer the executable name, but the VM path: 0 the full path name for currently executing VM (or, on some platforms, just the path name of the VM's directory) ...so... getSystemAttribute: 0 is answering fine... and -1 should answer nil (or the vm parameters, if present), not the executable name. Real problem then is: we don't have a way to get the executable name or getSystemAttribute: comment is wrong :) what's the audience opinion? cheers, Esteban El 31/12/2011, a las 9:11p.m., Sean P. DeNigris escribiÃ³: > The latest blessed cocoa build from Jenkins (12/11/11 #10) + 1.3-rc returns: > > SmalltalkImage current getSystemAttribute: -1."'-psn_0_528513'" > SmalltalkImage current getSystemAttribute: 0 "'/Applications'" > > There does not seem to be a way to get the vm executable name. > > Sean > > -- > View this message in context: http://forum.world.st/VM-Smalltalk-getSystemAttribute-tp4122708p4249718.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 2, 2012

Re: [Pharo-project] About announcements

by Lukas Renggli

Ok, first of all I did not know who wrote the code. I was just fixing some of my code that suddenly broke and was astonished what the announcer all does when stepping through the announcement procedure with the debugger ... >>> 3. It enters a critical section of a monitor: This is rarely useful >>> and the slowest kind of concurrency control available in Pharo (a >>> Mutex would be enough for what it is used for, and instantiate >>> multiple semaphores and queues), and btw the lazy initialization of >>> the monitor is the prime example of a race condition. >>> >> agreed here. I would even leave a semaphore. >> I think it is overlooked by Henrik. >> It also don't needs a lazy initialization in #protected: , since in >> #initialize it can just create a ready for use fresh >> synchronization object. A semaphore might block, because an announcement could register another announcement. So probably the Mutex would be the right thing to use. >>> 4. It creates a copy of the collection of all the subscriptions: This >>> is rarely useful and wouldn't be necessary if an immutable data >>> structure was used. >>> >> propose better solution how to deal with situation when during >> handling an announcement, >> your handler unsubscribing from announcer. Array. Slower for registration, but faster at announcing (the common operation). >>> 5. It iterates over all announcements, it doesn't even try to group >>> announcements of the same kind. >>> >> it is pointless to group them, and makes no real difference. >> Because announcer doesn't knows what kinds of announcements will be >> announcement, >> and it knows only about subscriptions. >> Suppose i have a subscription to Announcement. And i announcing >> AnnouncementA (a subclass of it). Fair enough, probably it doesn't matter. >>> 7. It then tests each announcement if it matches, again it doesn't >>> even try to group the announcements of the same kind. Aside, the match >>> test was changed so that it doesn't allow instance-based announcements >>> anymore, breaking some of my code. >>> >> what is instance-based announcements? If you have a client with 1000 different possibly dynamically changing properties and you want a way to register for announcements of a single property. The current implementation forces you to create a class per property, previously you could fake a "kind of announcements" with an instance. >> you can use any object as Â a subscription selector, just make sure it >> understands #handles: message. >> i.e. No, because the Announcement>>#handles: takes a class, not an instance. >>> 9. It then culls the announcement and announcer into the block. Not >>> sure why the announcer is useful, after all the block was registered >>> with the announcer at some point. >>> >> cull there is for passing optional arguments. I didn't complain about #cull:, but about the useless announcer passed in. Now for me you don't need to change the semantics of the Pharo Announcements again. Now for my code I will just use my own implementation that has exactly the behavior and performance characteristics I need. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 2, 2012

Re: [Pharo-project] About announcements

by Henrik Sperre Johansen

On 02.01.2012 15:50, Henrik Sperre Johansen wrote: > On 02.01.2012 14:45, Igor Stasenko wrote: >> On 2 January 2012 10:42, Lukas Renggli<renggli(a)gmail.com> wrote: >> >>> 6. It wraps each announcement delivery into a curtailed block. It does >>> that even for those that are never actually announced. >>> >> yeah, this can be optimized > With subs parameter a sequenceable collection, it could be made nearly > non-existant by iterating manually rather than through do:, moving > ifCurtailed to the outer scope. (resuming from index rather than a > copy after failed delivery). > Code would be uglier though. By "nearly non-existant", I meant you pay the overhead once per delivery rather than once per subscriber. It's still an overhead when you have a large number of deliveries to a few subscribers. >> 5. It iterates over all announcements, it doesn't even try to group >> announcements of the same kind. >> > it is pointless to group them, and makes no real difference. Forgot to comment this, I partly agree with both really. Of course it is not pointless to group them, algorithmically speaking. Is the scale at which it matters a usual occurance? Don't think so. Do you fix your announcement lookup by doing so? Yes. Is that necessarily a bad thing? I'm not sure. IIRC, it was one of the discussions Igor "won" (plus, it was simpler to mess about with) :) Cheers, Henry

Jan. 2, 2012

Re: [Pharo-project] roadmap

by Alexandre Bergel

This is indeed important. I tried several times to use Pharo 1.4 but I could not really work with it unfortunately. I am stuck with 1.3 > Please, let's discuss this roadmap. Not listing wishes, but actionable points. > > I start with some questions: > - beside RB and Announcements, are there other things that could be problematic > - how do we approach the RB problem? Is it Ok to get it out of the image and have Jenkins build the Pharo distribution by loading the head? I have probably read superficially the emails about those issues. Can you give a brief summary of the problem? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 2, 2012

Re: [Pharo-project] About announcements

by Henrik Sperre Johansen

On 02.01.2012 14:45, Igor Stasenko wrote: > On 2 January 2012 10:42, Lukas Renggli<renggli(a)gmail.com> wrote: >>>>> To you, the current Pharo image is the Pharo Core and you are unhappy that it is too big (for example because RB is there). >>>> The size is the least problem. >>>> >>>> More annoying is that the code quickly gets out of sync and >>>> non-changes are added to the history. Both of these problems are >>>> already visible today. >>>> >>>> Additionally, over time people will change/add/remove features that >>>> get integrated without proper review. I just had a look at the >>>> announcement framework in Pharo 1.4 today, it is unbelievable how a >>>> tiny framework could degrade to a bloated, untested and dead slow pile >>>> of mud in just a few years :-( >>> I think your are unfair here. The new features might be untested (current coverage is at 56%), but the changes were meant to provide working weak announcements. And they do work. >> Nice argument for your students reading this thread: >> http://memegenerator.net/instance/12779750. >> >>> But, what do you mean by slow? How did you benchmark it? >> No, but if you look at the code you will see many extra steps: >> >> 1. It tests if a registry is there: Why would that be necessary in an >> object-oriented implementation? >> > this should be cleaned up. > i think it is a leftover from migration code from old Announcer class (pre 1.3) > to a new one. > We did things incrementally, and had code to migrate all instances > from old format to a new one, > without losing subscription and without stopping working. Yup, leftover from live migration. >> 3. It enters a critical section of a monitor: This is rarely useful >> and the slowest kind of concurrency control available in Pharo (a >> Mutex would be enough for what it is used for, and instantiate >> multiple semaphores and queues), and btw the lazy initialization of >> the monitor is the prime example of a race condition. >> > agreed here. I would even leave a semaphore. > I think it is overlooked by Henrik. > It also don't needs a lazy initialization in #protected: , since in > #initialize it can just create a ready for use fresh > synchronization object. Yup, leftover from live migration/when whole delivery was in critical section (ie before copying), a Semaphore should be ok. Can't remember why we picked Monitor over Mutex in the first place :( > >> 4. It creates a copy of the collection of all the subscriptions: This >> is rarely useful and wouldn't be necessary if an immutable data >> structure was used. >> > propose better solution how to deal with situation when during > handling an announcement, > your handler unsubscribing from announcer. Alternative is the way the old code worked: Copy and replace collection whenever you add/remove subscriptions. Then there need be no critical section in deliver: at all. Of course, it's a performance tradeoff between fast subscription/unsubscription and delivery, one is not necessarily better than the other. Question is if it's worth providing/switching between different SubscriptionRegistries based on actual use pattern? Or, is a default generally better, and if so, which of the approaches should be favored? Lukas seem to thing delivery, and I'm inclined to agree with him, I think we were a bit blinded by benching lots of subscriptions/unsubscriptions in relations with the weak implementations, and lost sight of the most common use pattern. > >> 6. It wraps each announcement delivery into a curtailed block. It does >> that even for those that are never actually announced. >> > yeah, this can be optimized With subs parameter a sequenceable collection, it could be made nearly non-existant by iterating manually rather than through do:, moving ifCurtailed to the outer scope. (resuming from index rather than a copy after failed delivery). Code would be uglier though. > > > >> 8. It then wraps the actual notification into an exception handler. >> Again, this is rarely useful and should probably rather be something >> pluggable. >> > perhaps we can add even more 'bloat' to have 'safe' and 'unsafe' announcers :) > But for things like SystemAnnouncer, this is not a question that > exception handler must be present > and delivery must be guaranteed. 6 and 8. both arrived as responses to a desire to make delivery more robust. I personally argued for using 6, but not 8, for a default announcer as a reasonable(?) compromise. Would not mind seeing this pluggable, and in either case moved to SubscriptionRegistry to sit alongside the curtailing, so there is only one class to modify for testing different delivery/error handling/robustness strategies. > >> 9. It then culls the announcement and announcer into the block. Not >> sure why the announcer is useful, after all the block was registered >> with the announcer at some point. >> > cull there is for passing optional arguments. Personally, it was to make it slightly more compatible with VW announcements (which also pass the subscription as an optional 3rd param). One use is when weak announcements don't give strong enough guarantees on termination, and your block does not have access to the announcer. (usually when an object is passively registered for listening) A >> handlerBlock [:announcement :announcer | self isValid ifTrue: [self writeSomeStateUsedElseWhereBasedOn: announcement ] ifFalse: [announcer unsubscribe: self]] A listenTo: announcer announcer when: IWantToListen do: self handlerBlock Yes, you can also do the same by keeping an extra inst var with all announcers A are sent as arguments, personally I find that less desirable to maintain. What I didn't notice at the time though, was that cull: makes MessageSend subscription delivery quite slow, due to String numArgs implementation... So that specific case needs optimization, otherwise the overhead of supporting this is negligible. Cheers, Henry

Jan. 2, 2012

Re: [Pharo-project] Experience with Monitor

by Mariano Martinez Peck

It was Mutex. http://forum.world.st/How-to-resurrect-an-unrepsonsive-image-tp4168518p4178… On Mon, Jan 2, 2012 at 3:28 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > I remember reading somewhere that Monitor was broken in Pharo/Squeak? > I do not remember where. > Does anybody have experience with bad monitor behavior? > Because we got some bad experience with Monitor. > > THe funny part is that now doing self inform: freezes to death our image. > > Stef > > -- Mariano http://marianopeck.wordpress.com

Jan. 2, 2012

[Pharo-project] roadmap

by Tudor Girba

Hi, Lukas and Stefan (Marr) both raised the topic of the roadmap. From Lukas: > This leads me to the question: Did anybody ever sketch an architecture > of where Pharo should be heading to? I created a simplified one based > on my own understanding of the current proposals: http://bit.ly/vpnAf1 > (Google Docs). I think too that they have a point. Stef answered: > We should because we know where we want to go. I think that at the very least it is a communication issue. From outside it is unclear in what order should the efforts be spent. We have a ton of wishes, but not an understanding of where we want to get and how. Please, let's discuss this roadmap. Not listing wishes, but actionable points. I start with some questions: - beside RB and Announcements, are there other things that could be problematic - how do we approach the RB problem? Is it Ok to get it out of the image and have Jenkins build the Pharo distribution by loading the head? Cheers, Doru -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

Jan. 2, 2012