Re: [Pharo-dev] Epicea should ask before recovering

On Wed, Apr 19, 2017 at 9:42 PM, Rajula Vineet wrote: > Hi, > > I am interested in this issue. Maybe I will try adding this feature of a > pop > up when an image crashes, which asks 'do you want to recover your lost > changes?' > > Rajula > > Give it a go.

Re: [Pharo-dev] Missing VMMaker repo in Pharo 6

Hi Ben, On Tue, Apr 18, 2017 at 12:03 AM, Ben Coman wrote: > > > On Tue, Apr 18, 2017 at 1:57 PM, K K Subbu wrote: > >> On Monday 17 April 2017 11:52 PM, Cyril Ferlicot D. wrote: >> >> StartupPreferencesLoader default >>>

Re: [Pharo-dev] In the quest of a new iterator :)

I second the Peter’s idea. I don’t think that we need a dedicated index-based select when we already have withIndex*. Also one year after adding withIndexSelect: we can mine public repos and see how many projects use the method and the selection block does not read the first (each) parameter.

Re: [Pharo-dev] In the quest of a new iterator :)

We already have * #withIndexCollect: * #withIndexDo: So why not #withIndexSelect: ? #(#Object #subclass: #Point #instanceVariableNames:) withIndexSelect: [ :each :i | i \\ 2 = 0 ] Peter p.s. for every second you could also do aCollection pairsCollect: [ :first :second | second ] On Wed,

Re: [Pharo-dev] In the quest of a new iterator :)

There are already #pairsDo: and #pairsCollect: that could be used: #(a b c d e f g h) pairsCollect: [ :x :y | y ] => #(#b #d #f #h) > On 19 Apr 2017, at 22:12, Tudor Girba wrote: > > I like this one. > > Doru > > >> On Apr 19, 2017, at 8:43 PM, Stephane Ducasse

Re: [Pharo-dev] In the quest of a new iterator :)

I like this one. Doru > On Apr 19, 2017, at 8:43 PM, Stephane Ducasse wrote: > > Hi > > I have > > #(#Object #subclass: #Point #instanceVariableNames: 'x y' > #classVariableNames: '' #package: 'Kernel-BasicObjects') and I would like to > select on the second

Re: [Pharo-dev] #renameTo: and #moveTo:

2017-04-19 21:41 GMT+02:00 Alistair Grant : > Hi All, > > While recently running the test suite I've been getting failures in > FileLocatorTest>>testMoveTo if the working directory when the test > is run is on a different unix file system to the user's home directory. > >

[Pharo-dev] #renameTo: and #moveTo:

Hi All, While recently running the test suite I've been getting failures in FileLocatorTest>>testMoveTo if the working directory when the test is run is on a different unix file system to the user's home directory. The failing primitive is 'primitiveFileRename' in module 'FilePlugin', which

Re: [Pharo-dev] In the quest of a new iterator :)

2017-04-19 16:17 GMT-03:00 Stephane Ducasse : > why? > Iterators are powerful and avoid that we all reinvent the wheel in our own > corners. > > About keySelect: I do not see the point to convert a large collection into a > dictionary then do yet another pass. > To me it

Re: [Pharo-dev] changing default theme to DarkTheme

For the mooc we have normally an image: it is called Pharo 50. S. On Mon, Apr 17, 2017 at 3:34 PM, Mark Bestley wrote: > Dimitris Chloupis > wrote: > > > --001a113a8620c74f7a054d5aba55 > > Content-Type: text/plain; charset=UTF-8 > > > > Not before

Re: [Pharo-dev] In the quest of a new iterator :)

why? Iterators are powerful and avoid that we all reinvent the wheel in our own corners. About keySelect: I do not see the point to convert a large collection into a dictionary then do yet another pass. To me it looks like a hack. I implemented selectEvery: (selectFirst selectSecond) as helpers.

Re: [Pharo-dev] In the quest of a new iterator :)

2017-04-19 15:43 GMT-03:00 Stephane Ducasse : > Hi > > I have > > #(#Object #subclass: #Point #instanceVariableNames: 'x y' > #classVariableNames: '' #package: 'Kernel-BasicObjects') and I would like to > select on the second elements. > > I was thinking that > >

[Pharo-dev] In the quest of a new iterator :)

Hi I have #(#Object #subclass: #Point #instanceVariableNames: 'x y' #classVariableNames: '' #package: 'Kernel-BasicObjects') and I would like to select on the second elements. I was thinking that #(#Object #subclass: #Point #instanceVariableNames: 'x y' #classVariableNames: '' #package:

[Pharo-dev] [pharo-project/pharo-core] da8a37: 60466

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: da8a37f7701b9dbed548071a6082d9a2ed43f20b https://github.com/pharo-project/pharo-core/commit/da8a37f7701b9dbed548071a6082d9a2ed43f20b Author: Jenkins Build Server Date:

[Pharo-dev] [pharo-project/pharo-core]

Branch: refs/tags/60466 Home: https://github.com/pharo-project/pharo-core

Re: [Pharo-dev] Epicea should ask before recovering

Hi, I am interested in this issue. Maybe I will try adding this feature of a pop up when an image crashes, which asks 'do you want to recover your lost changes?' Rajula -- View this message in context: http://forum.world.st/Epicea-should-ask-before-recovering-tp4942281p4942694.html Sent from

[Pharo-dev] Pharo days: Register to help the organisation

Hi I know that some of you planned to come to the conference but did not yet register. Please do it fast because we should plan the social event and the lunches. Stef

Re: [Pharo-dev] Epicea should ask before recovering

On Wed, Apr 19, 2017 at 10:04:01AM +0200, Guillermo Polito wrote: > Yeh, What they mean is that instead of loading the list of "possible stuff > to recover" you launch at startup a dialog: > > "It seems your last Pharo session exited without saving some code. Do you > want to recover it?" YES/NO

Re: [Pharo-dev] esteban is on vacation this week....

I am not available either. If on holiday or not is hard to say as plans change literally every day, but if what is planed now will work out (I do not believe in that concept anymore, though), then everything gets better starting Mai 1. Marcus > On 16 Apr 2017, at 13:32, Stephane

Re: [Pharo-dev] Epicea should ask before recovering

Yeh, What they mean is that instead of loading the list of "possible stuff to recover" you launch at startup a dialog: "It seems your last Pharo session exited without saving some code. Do you want to recover it?" YES/NO :) On Tue, Apr 18, 2017 at 10:03 AM, Denis Kudriashov