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

Re: [Pharo-project] About Pharo sprint

by StÃ©phane Ducasse

On Mar 13, 2011, at 10:52 AM, Igor Stasenko wrote: > On 13 March 2011 09:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> 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. > > Hehe.. yes. We left lab at 10. :) and all the cookies were in my office :) > >> Ocean people were really into let us make progress. >> Glamour debugger, yeah I want a model too. >> >> Stef >> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

March 13, 2011

Re: [Pharo-project] [Pharo-users] Last pending things for Pharo 1.2

by StÃ©phane Ducasse

On Mar 12, 2011, at 8:19 PM, Mariano Martinez Peck wrote: > So....here is the list of things I guess are pending: > > 1) "Release" all configurations included in Pharo (this is, ConfigurationOfPharo and all it dependencies). I mean, we should NOT use or depend on #development versions. mariano can you have a look at 1) > 2) Update the one click image to use latest cog images and "pharo prepared vms". There are some issues regarding this... > 3) Write down all the things/summary done in Pharo 1.2 > 5) Update SystemVersion current -->> Pharo1.2rc2 of 27 January 2011 update 12340 > 6) Condense sources? condense changes? #cleanUpForRelease > > Cheers > > Mariano

March 13, 2011

[Pharo-project] Status bar

by Hilaire Fernandes

Hello, Do we have nay thing close as a status bar in Polymorph? A widget you plug in the bottom of a window and where you print textual information. Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

March 13, 2011

Re: [Pharo-project] About Pharo sprint

by Igor Stasenko

On 13 March 2011 09:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> 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. Hehe.. yes. We left lab at 10. :) > Â Â Â Â Ocean people were really into let us make progress. > Â Â Â Â Glamour debugger, yeah I want a model too. > > Stef > >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > -- Best regards, Igor Stasenko AKA sig.

March 13, 2011

Re: [Pharo-project] Update process broken by 13084

by StÃ©phane Ducasse

can you tell me the symptoms? Which package/class got corrupted? Stef On Mar 13, 2011, at 12:29 AM, Henrik Sperre Johansen wrote: > See title. > Probably caused by saving from multiple open copies of the same image so > the .changes file source was exported from was corrupted :) > > Cheers, > Henry >

March 13, 2011

Re: [Pharo-project] Update process broken by 13084

by StÃ©phane Ducasse

But we do not publish the changes anymore. So you think that the packages got corrupted? Stef On Mar 13, 2011, at 12:29 AM, Henrik Sperre Johansen wrote: > See title. > Probably caused by saving from multiple open copies of the same image so > the .changes file source was exported from was corrupted :) > > Cheers, > Henry >

March 13, 2011

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