April 2009 - Pharo-dev - lists.pharo.org

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

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

by StÃ©phane Ducasse

Damien with the changes of mime types and others is it possible to load scripts? Stef

April 17, 2009

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

by Damien Cassou

On Thu, Apr 16, 2009 at 8:04 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > My primary rhetorical question is not how often you should produce web images, but whether or not the developer image plus scripting is good enough. Â I ask in part because of things like FFI/Alien, etc. The script I use to generate dev-images is in the zip file. There is a part which installs Seaside, Magritte and the others. -- Damien Cassou http://damiencassou.seasidehosting.st

April 17, 2009

Re: [Pharo-project] About literalsDo: deprecation

by Marcus Denker

Hi, On 15.04.2009, at 16:53, Nicolas Cellier wrote: > I notice while scanning Eliot changes that #literalsDo: is a > deprecated message... > But (literals do:) replacement is not neutral concerning speed. > It creates an Array where literalsDo: did not. > This is not a detail because this is called on each and every method > when scanning code: > > For example, I tried this in Pharo image: > > Time millisecondsToRun: [SystemNavigation default allGlobalRefs] > ->5356 with Eliot's literalsDo: > ->8947 pharo version calling literals do: > > This change spoils a few minutes out of our every day work ;) yeah, we should reverse that change. Marcus -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

April 16, 2009

[Pharo-project] [ANN] 10279 closure fixes

by StÃ©phane Ducasse

- Fix for http://code.google.com/p/pharo/issues/detail?id=726 add #sender method to BlockClosure - Add messages to BlockClosure to fix issue http://code.google.com/p/pharo/issues/detail?id=722 - Issue 746: missing package for Closure and friends - Work-around for issue http://code.google.com/p/pharo/issues/detail?id=739 We cannot run some Debugger tests profiled... ... because Debugger would reset Tally Timer class var. Work around is to put a Timer ifNotNil: protection... - fix closureParser invocation (should probably clean the rest) Thanks nicolas. :)

April 16, 2009