- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Short summary of new announcement capabilities

by StÃ©phane Ducasse

Thanks a ***LOT*** It is really important for pharo. Stef On Mar 13, 2011, at 2:08 AM, Henrik Sperre Johansen wrote: > Barring a few update problems, they changes Igor and I made today should > be ready for general review/inclusion shortly. > Here's a few points about the most important differences to the current > implementation: > 1. Now supports action blocs with 0, 1 or 2 arguments (announcement and > receiver). > This should allows us to: > 1.1 Write blocks with strict guarantees for expiry and removal > without keeping strong references to announcers in subscriber, by using > the announcer arg to unsubscribe if action is invalid. (Not very nice > resulting code, but necessary if altering outside-accessible state) > 1.2 use suspendWhile: equivalent from blocks where announcer is not > kept in context when such protocol is added. > 1.3 Not use :ann argument for action blocks in which you don't > really care. > 1.4 Provide an upgrade path from events by replacing them with 0-arg > MessageSend announcements under the hood if we want. > (Would requires some nasty bits with objects as announcers though). > > 2. Support weak subscriptions for message send type of announcement. > Block action requires ephemeron support in VM to correctly > unsubscribe automatically, and trying to create them currently raises an > error. > > 3. Reify Subscriptions (which are returned by #when:do: and friends), > which can be made weak with #makeWeak. > However, for thread-safety reasons this is done using > #becomeForward:. > If weakness can be determined at subscription time, the recommended > way would be to use: > announcer weak when:send:to: > The weak send creates a wrapper which will instantiate the > subscription as weak from the get-go. > > 4. The SubscriptionRegistry is thread-safe, in the sense that add: > remove: and deliver: are protected by a Monitor. > (so you can remove: in action block without a deadlock, see 1.1). > Rather than block for the entire deliver: process, we chose to only > protect the copy of subscriptions. > This implies that the following may happen: > Thread 1 starts delivery of announcement. > Thread 2 interrupts after copy is created, then removes a > subscription and carries on doing its stuff > Thread 1 resumes, and delivers announcement to remaining > subscriptions, potentially including that removed by Thread2. > Don't think this is likely to be a common scenario where > protecting the entire delivery would have made a difference. > If you think otherwise, and can provide a good use case, please > speak up and we may change it. > > if you want to browse the changes, they are available for perusal in the > changesets attached to: > http://code.google.com/p/pharo/issues/detail?id=3814 > (Split in two to take care of migrating existing subscriptions) > Don't try to load them though, as they depend on changes in other > issues, and the comment changes cause errors. > > Feedback would be appreciated. > > Cheers, > Henry > > PS. We forgot to include #on:do:for: & friends, which allow you to > specify another subscriber than the object block belongs to. > This is an oversight and will be corrected before inclusion. Just in > case you were following Tudor's tweets and were wondering where they had > gone. > >

March 13, 2011

Re: [Pharo-project] Fwd: [ANN] pharo focused sprint - bern, feb 26

by Igor Stasenko

On 13 March 2011 02:17, Toon Verwaest <toon.verwaest(a)gmail.com> wrote: > I'm working on extracting everything to a model. DebuggerMethodMap is a mess > so we'll also have our own version of that class. Other methods that I found > too messy are rewritten in the model. > > Still work to be done, and Cog for linux doesn't like me committing code to > MC (it just crashes when I click save); so ... But it'll get there ;) Most > of the functionality is already there. You can use Stack interpreter VM https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Stack%20VM%20Unix/ which can open images saved by JIT-based one, and see if it can do things which leading to crash under JIT. > > Making it all remote shouldn't be too much of a problem. The debugger just > relies on the debugger model and a list of objects that represent the stack. > All actual evaluating actions can easily be forwarded over a proxy to the > remote model. > > cheers, > Toon > > On 03/13/2011 01:31 AM, Igor Stasenko wrote: >> >> On 2 March 2011 20:56, Adrian Lienhard<adi(a)netstyle.ch> Â wrote: >>> >>> On Mar 2, 2011, at 20:33 , Luc Fabresse wrote: >>> >>>>> - Adrian, Jorge and Toon worked on implementing a Debugger on top of >>>>> Glamour. They got a first version working that is able to do basic >>>>> actions: >>>>> step, restart, step into. The challenge was to get to understand the >>>>> model, >>>>> and to figure out that<primitive: 19> Â is used for marking that a >>>>> method >>>>> should not be debugged. In any case, working with Glamour seemed to >>>>> work >>>>> quite smoothly. The code is available in the Glamorous Toolkit. Adrian, >>>>> did >>>>> I get it right? :) >>>>> >>>> Nick in CC worked a lot to understand the model part of the Debugger. >>>> He has worked on a remote debugger. >>>> @Nick, you should have a look probably at this implementation of a >>>> debugger >>>> in Glamour. >>>> AFAICR the Debugger code really mixes the model, the GUI, the Debugees, >>>> ... >>>> so perhaps you can all join forces and propose a cleaner and extensible >>>> debugger ;-) >>> >>> Indeed, an independent model would make a lot of sense. Since the >>> original logic is mixed with the GUI code, we just copied parts of it over >>> to our new prototype. By factoring this out into an independent model we >>> would not end up multiple copies for the original debugger, the Glomour >>> debugger, the OB debugger, the remote debugger etc. >>> >> even if you copy it, we still badly need remote tools. :) >> Because we really cannot rely on having RFB installed on every >> headless image. It could be much more nicer and sexier >> to have small kernel image with small dispatcher to which you can >> connect Â and communicate with image remotely, >> without need of carrying Morphic blob inside it. > > > -- Best regards, Igor Stasenko AKA sig.

March 13, 2011

Re: [Pharo-project] Fwd: Amiga Longplay [133] Skweek

by stephane ducasse

There were 4 or 5 cheats on the map :) Sred ] On Mar 13, 2011, at 9:54 AM, laurent laffont wrote: > I've played it a lot on Atari Lynx. I remember the cheat of zooming near a palm tree to get extra lives ! > > Laurent > > On Sun, Mar 13, 2011 at 9:46 AM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > My first game :) > > Stef > > > Begin forwarded message: > > > From: Laurent Arditi <laurent.arditi(a)gmail.com> > > Date: March 11, 2011 10:00:44 PM GMT+01:00 > > To: StÃ©phane Ducasse <stephane.ducasse(a)free.fr>, Andrzej Fien <fien112(a)hotmail.com>, Pascal Clarysse <pascal.clarysse(a)gmail.com> > > Subject: Amiga Longplay [133] Skweek > > > > Hi all > > > > Look at this video: one guy plays Skweek and finishes the game in 2 hours. He is an excellent player! > > > > http://www.youtube.com/watch?v=WIAOSFD6c1g&feature=youtube_gdata_player > > > > > > Laurent. > > >

March 13, 2011

Re: [Pharo-project] The current status of OSProcess

by StÃ©phane Ducasse

+1 OSProcess is really important for us. Like a good FFI Stef On Mar 13, 2011, at 1:11 AM, Igor Stasenko wrote: > On 13 March 2011 00:19, David T. Lewis <lewis(a)mail.msen.com> wrote: >> Hi Igor, >> >> I think it is good to make OSPP (and AioPlugin and XDisplayControlPlugin >> where appropriate) available in all distributed VMs, but in some applications >> they provide too much access to the operating system, so it is good to >> have them as external modules so that people who do not want them on >> the system can delete the modules. So I think it is best to treat it >> like FFI, it is there if you want it but can be removed if you are doing >> some sort of application where the user should not have easy access to >> the OS functions. >> > > Well, i think for making a secure 'appliance' sort of, a better > approach to not rely on > prebuilt VM , but build your own where you can always decide what is > secure enough and what's not, > and should be removed/disabled. > > Btw, we discussed a bit of this today with Henrik, and first thing i > think people should do, in order to make it more secure > is to disable external module loading mechanism. > Declaring that standard VM is more secure if you don't ship it with > _external_ modules (like FFI) sounds like a joke. > > So, what i'd like to ask is, that if everyone feel a day-to-day need > for using things like FFI or OSProcessPlugin > we should make it available by default and out of the box. And for > those, who concerned with low security there is always > an options to improve it, like hiring people to develop a custom VM > based on default one, where all security problems is > addressed properly. > > So, i don't see why we should constrain ourselves with things we use > and need, only because in eyes of someone > it doesn't looks secure enough. > >> Dave >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

March 13, 2011

Re: [Pharo-project] Fwd: Amiga Longplay [133] Skweek

by laurent laffont

I've played it a lot on Atari Lynx. I remember the cheat of zooming near a palm tree to get extra lives ! Laurent On Sun, Mar 13, 2011 at 9:46 AM, stephane ducasse <stephane.ducasse(a)free.fr>wrote: > My first game :) > > Stef > > > Begin forwarded message: > > > From: Laurent Arditi <laurent.arditi(a)gmail.com> > > Date: March 11, 2011 10:00:44 PM GMT+01:00 > > To: StÃ©phane Ducasse <stephane.ducasse(a)free.fr>, Andrzej Fien < > fien112(a)hotmail.com>, Pascal Clarysse <pascal.clarysse(a)gmail.com> > > Subject: Amiga Longplay [133] Skweek > > > > Hi all > > > > Look at this video: one guy plays Skweek and finishes the game in 2 > hours. He is an excellent player! > > > > http://www.youtube.com/watch?v=WIAOSFD6c1g&feature=youtube_gdata_player > > > > > > Laurent. > > >

March 13, 2011

[Pharo-project] Fwd: Amiga Longplay [133] Skweek

by stephane ducasse

My first game :) Stef Begin forwarded message: > From: Laurent Arditi <laurent.arditi(a)gmail.com> > Date: March 11, 2011 10:00:44 PM GMT+01:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)free.fr>, Andrzej Fien <fien112(a)hotmail.com>, Pascal Clarysse <pascal.clarysse(a)gmail.com> > Subject: Amiga Longplay [133] Skweek > > Hi all > > Look at this video: one guy plays Skweek and finishes the game in 2 hours. He is an excellent player! > > http://www.youtube.com/watch?v=WIAOSFD6c1g&feature=youtube_gdata_player > > > Laurent.

March 13, 2011

Re: [Pharo-project] About Pharo sprint

by StÃ©phane Ducasse

> It is easy to tell, when it happens.. > > because my inbox is flooded with tons of messages :) > > And that's great :) Yes it was cool to see you and henrik pair programming. and people were really committed. Ocean people were really into let us make progress. Glamour debugger, yeah I want a model too. Stef > > -- > Best regards, > Igor Stasenko AKA sig. >

March 13, 2011

Re: [Pharo-project] [Pharo-users] Actions done in Pharo 1.2

by StÃ©phane Ducasse

we should look at the scriptloader log. Stef On Mar 12, 2011, at 8:17 PM, Mariano Martinez Peck wrote: > Please, we need help to write down / summarize all the actions done in Pharo 1.2. > > Include them here: http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotTwo > > cheers > > Mariano

March 13, 2011

Re: [Pharo-project] Pharo mailing list weekly summary #5

by laurent laffont

Thanks FranÃ§ois, very useful. Laurent. On Sun, Mar 13, 2011 at 1:35 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Thanks for overview. > Works for me. I found that i missed couple of important topics this week. > > .. ohh there is too much mails :) > > On 12 March 2011 21:19, Francois Stephany <tulipe.moutarde(a)gmail.com> > wrote: > > Sure, I'll add the date range next week ;) > > Of course, some threads span on 2 or 3 periods. > > > > On 12/03/11 19:49, Noury Bouraqadi wrote: > >> > >> I'd rather prefer the actual date such as: 7-13 march 2011 > >> > >> Thanx FranÃ§ois any way. > >> On 12 mars 2011, at 18:14, Geert Claes wrote: > >> > >>> Hi Francois, Excellent job again. Just one suggestion, can we use the > >>> actual > >>> week number e.g. Pharo summary week 10, 2011? > >>> > >>> -- > >>> View this message in context: > >>> > http://forum.world.st/Pharo-mailing-list-weekly-summary-5-tp3350331p3350535… > >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

March 13, 2011

Re: [Pharo-project] Issue 3706 in pharo: In OB: Text in comment pane of Browser uses syntax highlighting

by pharo＠googlecode.com

Comment #5 on issue 3706 by renggli: In OB: Text in comment pane of Browser uses syntax highlighting http://code.google.com/p/pharo/issues/detail?id=3706 Did you check out the overlay at http://source.lukas-renggli.ch/pharo12/? This is the code I wrote during the the last sprint in Bern. It contains a complete rewrite of the text editor for morphic and it fixes all the other problems I encountered in Pharo 1.2. Shout and eCompletion works perfectly for me. Being an overlay means that you should load it like this: Gofer new renggli: 'pharo12'; " this repository take precedence " renggli: 'omnibrowser'; " over the code in here " package: ... " list all the OB packages " Note, that you cannot merge the overlay packages with any other code, because they are a clean rewrite. They do not use the old interface of the text editor that was hacked in ugly ways to kind of make it work in Pharo 1.2. The packages in http://source.lukas-renggli.ch/pharo12/ are ment to replace the packages in http://source.lukas-renggli.ch/omnibrowser/ as soon as Pharo 1.2 is released.

March 13, 2011