- Pharo-dev - lists.pharo.org

Re: [Pharo-project] New Pharo-dev based on 10279

by John Toohey

- Download the image from the Pharo site - Download the closure enabled OSX VM from Pharo site. - Start MC, and tried to load the Seaside29-A3 build with MC script generated by seaside builder. Is there something else I should try? On Fri, Apr 17, 2009 at 10:47, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Fri, Apr 17, 2009 at 4:33 PM, John Toohey <johnptoohey(a)gmail.com> wrote: >> I just downloaded this image, and the latest VM for OSX, and I cannot >> load any packages with MC. I get this error := 'Improper store into >> indexable object'. Even trying to go through the stack trace in the >> debugger, I get more errors thrown from the debugger itself (Syntax >> error). >> >> Is this a problem with the image or the VM? > > I can't reproduce on my Linux box. Please provide step-by-step instructions. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- -JT

April 17, 2009

Re: [Pharo-project] New Pharo-dev based on 10279

by Damien Cassou

On Fri, Apr 17, 2009 at 4:33 PM, John Toohey <johnptoohey(a)gmail.com> wrote: > I just downloaded this image, and the latest VM for OSX, and I cannot > load any packages with MC. I get this error := 'Improper store into > indexable object'. Even trying to go through the stack trace in the > debugger, I get more errors thrown from the debugger itself (Syntax > error). > > Is this a problem with the image or the VM? I can't reproduce on my Linux box. Please provide step-by-step instructions. -- Damien Cassou http://damiencassou.seasidehosting.st

April 17, 2009

Re: [Pharo-project] New Pharo-dev based on 10279

by John Toohey

I just downloaded this image, and the latest VM for OSX, and I cannot load any packages with MC. I get this error := 'Improper store into indexable object'. Even trying to go through the stack trace in the debugger, I get more errors thrown from the debugger itself (Syntax error). Is this a problem with the image or the VM? Thanks. On Fri, Apr 17, 2009 at 08:31, Damien Cassou <damien.cassou(a)gmail.com> wrote: > http://pharo-project.org/download > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- -JT

April 17, 2009

Re: [Pharo-project] Input sensor rewrite

by Michael Rueger

Damien Cassou wrote: > Hi Michael, > > for those who haven't followed this discussion, could you please > explain the benefits of the new mechanism? (just realized the comments aren't up to date and even incomplete) Cleanup ------- -remove the old and confusing EventSensor and InputSensor classes and replace them with InputEventSensor. -remove backward compatibility and polling where possible Not all VMs signal the input semaphore, that's why we currently us a polling event fetcher. Pluggability ------------ -events from the VM are now fetched by an InputEventFetcher "InputEventFetcher is responsible for fetching the raw VM events and forward them to the registered event handlers. Event fetching is done in a high priority process, so even with other processes (e.g. the Morphic UI process) being busy events will still be fetched." This finally gets rid of the input event tickler! InputEventHandlers can then listen to events. Current default listeners are the InputEventSensor for Morphic and UserInterruptHandler. This allows for alternative UI frameworks or other interesting stuff ;-) to register as a listener and deal with input events without ever having to deal with Morphic. Next on my list is to do exactly that with Miro and my experimental IMorph implementation, both built on Announcements. Michael

April 17, 2009

Re: [Pharo-project] Input sensor rewrite

by Damien Cassou

Hi Michael, for those who haven't followed this discussion, could you please explain the benefits of the new mechanism? Thank you On Fri, Apr 17, 2009 at 3:38 PM, Michael Rueger <m.rueger(a)acm.org> wrote: > Hi all, > > there is a updated version of the input sensor/event rewrite in the > Pharo inbox: > > -load the config map Event-rewrite1.mcm (it's in the Event category in > the repository) > -load the slice EventRewrite2-michael_rueger.2 > - in a workspace execute > InputEventSensor installPollingEventSensorFramework > > voila... > Sensor should now be an InputEventSensor. > > At a later point we can the remove the EventSensor and InputSensor classes. > > Michael > P.S. Could someone please remove > Collections-Sequenceable-michael_rueger.15 > from the inbox? It's a bogus version > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou http://damiencassou.seasidehosting.st

April 17, 2009

[Pharo-project] Input sensor rewrite

by Michael Rueger

Hi all, there is a updated version of the input sensor/event rewrite in the Pharo inbox: -load the config map Event-rewrite1.mcm (it's in the Event category in the repository) -load the slice EventRewrite2-michael_rueger.2 - in a workspace execute InputEventSensor installPollingEventSensorFramework voila... Sensor should now be an InputEventSensor. At a later point we can the remove the EventSensor and InputSensor classes. Michael P.S. Could someone please remove Collections-Sequenceable-michael_rueger.15 from the inbox? It's a bogus version

April 17, 2009

[Pharo-project] New Pharo-dev based on 10279

by Damien Cassou

http://pharo-project.org/download -- Damien Cassou http://damiencassou.seasidehosting.st

April 17, 2009

Re: [Pharo-project] New Pharo-dev based on 10277

by Damien Cassou

On Fri, Apr 17, 2009 at 12:38 PM, Oscar Nierstrasz <oscar(a)iam.unibe.ch> wrote: > The latest pharo-dev seems to have a several unpackaged classes > (BlockClosuresTestCase, ClosureTests, CollectionCombinator and > DecompilerTests). > > Even after updating, they are still unpackaged. > > Shouldn't they all go to their own packages? That has already been reported (by Alex IIRC). Thank you Oscar. -- Damien Cassou http://damiencassou.seasidehosting.st

April 17, 2009

Re: [Pharo-project] is it now possible to load script again

by Damien Cassou

On Fri, Apr 17, 2009 at 11:52 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > with the changes of mime types and others is it possible to load > scripts? do you mean by passing the script file to the VM directly? Sure, I fixed the bug and tested it immediately :-). Thank you -- Damien Cassou http://damiencassou.seasidehosting.st

April 17, 2009

Re: [Pharo-project] New Pharo-dev based on 10277

by Oscar Nierstrasz

The latest pharo-dev seems to have a several unpackaged classes (BlockClosuresTestCase, ClosureTests, CollectionCombinator and DecompilerTests). Even after updating, they are still unpackaged. Shouldn't they all go to their own packages? - on

April 17, 2009