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

[Pharo-project] Issue 3641 in pharo: possible new implementation of reduce:
by pharo＠googlecode.com Feb. 1, 2011

Feb. 1, 2011

Status: Accepted Owner: stephane...(a)gmail.com Labels: Milestone-1.3 New issue 3641 by stephane...(a)gmail.com: possible new implementation of reduce: http://code.google.com/p/pharo/issues/detail?id=3641 there is already a version of reduce: made by lukas and I would like to know the difference with this one (proposed by eliot because squeak did not got reduce:) if people can comment on speed... and whatever it would be good. Collection>>reduce: binaryBlock "Apply the argument, binaryBlock cumulatively to the elements of the receiver. For sequenceable collections the elements will be used in order, for unordered collections the order is unspecified." | first nextValue | first := true. self do: [ :each | first ifTrue: [ nextValue := each. first := false ] ifFalse: [ nextValue := binaryBlock value: nextValue value: each ] ]. first ifTrue: [ self errorEmptyCollection ]. ^nextValue! !

1 1

Re: [Pharo-project] Issue 3234 in pharo: fold: reduce: Merge
by pharo＠googlecode.com Feb. 1, 2011

Feb. 1, 2011

Updates: Labels: Milestone-1.3 Comment #1 on issue 3234 by siguc...(a)gmail.com: fold: reduce: Merge http://code.google.com/p/pharo/issues/detail?id=3234 - here the changeset for integrating it Attachments: foldreduce.1.cs 1.1 KB

1 2

Re: [Pharo-project] TODO 1.2
by Marcus Denker Feb. 1, 2011

Feb. 1, 2011

On Jan 31, 2011, at 7:38 PM, Lukas Renggli wrote: >> Can I suggest that we really remove the non show stopper? >> and I'm sorry but we cannot maintain packages we do not know. >> >> Lukas could you integrate the fix I did for OB? > > I suggest that you publish the changes to your own repository. I would > like to keep the code in http://source.lukas-renggli.ch/omnibrowser/ > working in Pharo 1.1. > But it is clear that staying backward compatible forever will not make sense? I personally do not have energy for that. in 1.1, everyone used OB and was happy. So why would anyone using 1.1 (which will not be many people) would need to have an updated OB? I personally think energy should not be wasted for this. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] About KeyBindings
by Fernando Olivero Feb. 1, 2011

Feb. 1, 2011

Hi, recently there were some discussion on implementing KeyBindings for our IDE. There are at least 3 frameworks which address this functionality, the last one mentioned is the work done by Guillermo. I've implemented another one, for Gaucho. >From what i understand, the previous work focuses on implementing GLOBAL keybindings . Basically adding behavior to HandMorph or PasteUpMorph or the toolbar ( docking bar) present in the World. My implementation is a generic keybinding for any Morph, which can be applied to any morph. Special cases for the docking bar or the paste up Morph can be easily implemented following this uniform scheme. I didn't have the time to integrate it into Pharo yet, but will do in one week from now. I like to bring up the discussion on which one we should adopt and integrate into Morphic, points in favor of my approach: 1) clean 2) customizable 3) generic: no special cases I believe the other Global keybindings should be a subset of this generic keybinding mechanism. Fernando pd: From a previous mail: "... So for example, if you want to delete any Morph from the system by pressing cmd-w, you have to add the following binding: condition := GMCondition compositeWith: #( #understandsKeyBindingCommandCondition #uneditedCondition ) ). binding := GMKeyBinding actingOn: $w asciiValue modifiedBy: #(#command) satisfying: condition applying: #close. m := Morph new. m addKeyBinding: binding . ... " pd2: Useful and related comment from Stef ".. A classVar Binding and an instance var binding. **All** the methods only access binding binding get initialized with the default table defined in Binding => we can have table binding sharing => we can have instance based customization.

5 7