Re: [Pharo-dev] In the quest of a new iterator :)
On Thu, Apr 20, 2017 at 12:17:35AM +0300, Yuriy Tymchuk wrote: > 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. > > Uko > > > On 20 Apr 2017, at 00:07, Peter Uhnak wrote: > > > > We already have > > > > * #withIndexCollect: > > * #withIndexDo: > > > > > > So why not #withIndexSelect: ? > > > > #(#Object #subclass: #Point #instanceVariableNames:) withIndexSelect: [ > > :each :i | i \\ 2 = 0 ] > > > > Peter +1
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. http://pharo.org/contribute-propose-fix https://pharo.fogbugz.com/f/cases/19955/Epicea-should-ask-before-recovering For approach, use "World menu > Tools > Finder > Source" searching for the window title "Lost Changes Detected". Drop a "self halt" at the top of that method. Save the Image, then change any random method and Quit the image. Next startup a debugger should open in the appropriate spot. --- However a side question is, when someone goes "World menu > Quit" should that be taken to mean they are throwing away outstanding changes? --- Something else, I went to test previous behaviour of Lost Changes in Pharo 5.0 and I'm confounded by this behaviour. Preparation... 1. Downloaded and uznipped http://files.pharo.org/platform/Pharo5.0-linux.zip 2. From the command line, ran ./pharo 3. Opened System Browser on random method EllipseMorph>>closestPointTo: 4. Appended "aPoint + 0@0" and saved method. 5. Save&Quit Image, then re-opened Image Test... 6. Changed 0@0 to 1@1. 7. At the command line, hit to crash-stop the image 8. Re-open image ==> Expect "Lost Changes" dialog but there is none. Do I misremember the expected behaviour? This is the same with... http://files.pharo.org/platform/Pharo2.0-linux.zip cheers -ben
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
>>> addAtStartupInGeneralPreferenceFolder:
>>> {(StartupAction
>>> name: 'Add my repository'
>>> code: [ MCRepositoryGroup default
>>> addRepository:
>>> (MCSqueaksourceRepository location: 'http://source.squeak.org/VMMaker')
>>> ]
>>> runOnce: true)}
>>>
>>
>> Thank you for this nice tip. I was just curious about why this repo was
>> omitted from the built-in repos in a released image? Is VMMaker not a
>> supported package for Pharo?
>>
>
> Pharo is not delivered with VMMaker built-in / pre-loaded. So neither is
> its repo built-in.
> VMMaker is not relevant to most users, and it has no priority over 100s of
> user packages.
> All the repos you see built-in are actually components delivered
> built-into Pharo.
>
> btw, AFAIK the VM Simulator doesn't work on Pharo - though I'm not sure
> anyone has had a serious look at it.
> The main vm-devs and the OpenSmalltalk CI builds work on top of Squeak.
>
We think the simulator does work on Pharo. At least at some point it did
work. Remember all the agony with the transcript not updating after
flush? That was the VM simulator wanting to produce output to the
transcript.
And the VMMaker Smalltalk-to-C Slang output does work. Esteban is using it
to generate test builds after every commit for travisci.
What I /don't/ want to see is the VMMaker repo split. It should remain at
source.squeak.org/VMMaker' and be a conventional Monticello HTTP repository.
_,,,^..^,,,_
best, Eliot
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. Uko > On 20 Apr 2017, at 00:07, Peter Uhnak wrote: > > 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, Apr 19, 2017 at 04:35:07PM -0300, Esteban A. Maringolo wrote: >> 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 looks like a hack. >> >> keySelect: would do a select based on the key (index in the case of >> SequenceableCollection) of the element, no need to create a >> Dictionary. >> >> keySelect: aBlock >> | result | >> result := self species new. >> self keysAndValuesDo: [:key :value | >> (aBlock value: key) ifTrue: [result add: value] >> ]. >> ^result >> >> >> You could implement #selectEverySecond or #selectEveryFirst in terms >> of the above. The name sounds weird though, but I'm not a native >> English speaker. >> >> Regarding #unzip it's a different story, I wouldn't use 'zip' in a >> selector for non Zip (compression) related methods. >> >> But do as you please, Pharo is yours as well ;) >> >> Regards! >> >> >>> I implemented >>> selectEvery: >>> (selectFirst selectSecond) as helpers. >>> >>> and also unzip all in one pass. >>> Now I have no problem to keep them for me but to me this is the wrong >>> attitude. >>> >>> Stef >>> >>> >>> testSelectEveryFirst >>> self assert: (#(#Object #subclass: #Point #instanceVariableNames: 'x y' >>> #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEveryFirst) >>> asArray equals: #(#Object #Point 'x y' '' 'Kernel-BasicObjects') >>> testSelectEverySecond self assert: (#(#Object #subclass: #Point >>> #instanceVariableNames: 'x y' #classVariableNames: '' #package: >>> 'Kernel-BasicObjects') selectEverySecond) asArray equals: #(#subclass: >>> #instanceVariableNames: #classVariableNames: #package:) >>> testUnzip >>> | uz | >>> uz := #(#Object #subclass: #Point #instanceVariableNames: 'x y' >>> #classVariableNames: '' #package: 'Kernel-BasicObjects') unzip. >>> self assert: uz first asArray equals: #(#Object #Point 'x y' '' >>> 'Kernel-BasicObjects'). >>> self assert: uz second asArray equals: #(#subclass: #instanceVariableNames: >>> #classVariableNames: #package:) >> >> >> Esteban A. Maringolo >> >
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, Apr 19, 2017 at 04:35:07PM -0300, Esteban A. Maringolo wrote: > 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 looks like a hack. > > keySelect: would do a select based on the key (index in the case of > SequenceableCollection) of the element, no need to create a > Dictionary. > > keySelect: aBlock > | result | > result := self species new. > self keysAndValuesDo: [:key :value | > (aBlock value: key) ifTrue: [result add: value] > ]. > ^result > > > You could implement #selectEverySecond or #selectEveryFirst in terms > of the above. The name sounds weird though, but I'm not a native > English speaker. > > Regarding #unzip it's a different story, I wouldn't use 'zip' in a > selector for non Zip (compression) related methods. > > But do as you please, Pharo is yours as well ;) > > Regards! > > > > I implemented > > selectEvery: > > (selectFirst selectSecond) as helpers. > > > > and also unzip all in one pass. > > Now I have no problem to keep them for me but to me this is the wrong > > attitude. > > > > Stef > > > > > > testSelectEveryFirst > > self assert: (#(#Object #subclass: #Point #instanceVariableNames: 'x y' > > #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEveryFirst) > > asArray equals: #(#Object #Point 'x y' '' 'Kernel-BasicObjects') > > testSelectEverySecond self assert: (#(#Object #subclass: #Point > > #instanceVariableNames: 'x y' #classVariableNames: '' #package: > > 'Kernel-BasicObjects') selectEverySecond) asArray equals: #(#subclass: > > #instanceVariableNames: #classVariableNames: #package:) > > testUnzip > > | uz | > > uz := #(#Object #subclass: #Point #instanceVariableNames: 'x y' > > #classVariableNames: '' #package: 'Kernel-BasicObjects') unzip. > > self assert: uz first asArray equals: #(#Object #Point 'x y' '' > > 'Kernel-BasicObjects'). > > self assert: uz second asArray equals: #(#subclass: #instanceVariableNames: > > #classVariableNames: #package:) > > > Esteban A. Maringolo >
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 >> wrote: >> >> 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: 'Kernel-BasicObjects') selectEvery: [ :i | >> i \\ 2 = 0 ] >> could be a nice iterator. >> >> What do you think? >> >> >> Stef >> > > -- > www.tudorgirba.com > www.feenk.com > > "Innovation comes in the least expected form. > That is, if it is expected, it already happened." > >
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 elements. > > I was thinking that > > #(#Object #subclass: #Point #instanceVariableNames: 'x y' > #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEvery: [ :i | > i \\ 2 = 0 ] > could be a nice iterator. > > What do you think? > > > Stef > -- www.tudorgirba.com www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."
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. > > The failing primitive is 'primitiveFileRename' in module 'FilePlugin', > which calls rename(), which is presumably part of libc - I didn't chase > it back through the C code. > > libc rename() requires the source and destination filenames to be on the > same file system. > > This has been discussed multiple times before: > > https://pharo.fogbugz.com/f/cases/13957/Add-exception-for- > cross-volume-folder-renames > https://pharo.fogbugz.com/f/cases/12992/Cannot-move-files- > to-another-volume-partition-under-linux > https://pharo.fogbugz.com/f/cases/12965/Cannot-moveTo-FileLocator > > Issue 12965 is even supposed to include a fix, although when I searched > through the slice I couldn't find anything that actually looked like a > fix. > > As Nicolai suggested in 12965, the obvious solution is to implement move > as copy+delete. It looks like there isn't an easy way to check whether > the two files are on the same unix file system, so presumably it would > be implemented as try to rename, and if that fails, try to copy and > delete. > What? Google this: man stat The first field of stat structure is a device ID, so deciding if two files are on same file system or not is doable by checking this field for the source file and destination file (if it exists) or directory - modulo the fact that you'd have to care of symbolic links with lstat. > > Is there a reason not to propose this as a patch? > > Thanks, > Alistair > >
[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 calls rename(), which is presumably part of libc - I didn't chase it back through the C code. libc rename() requires the source and destination filenames to be on the same file system. This has been discussed multiple times before: https://pharo.fogbugz.com/f/cases/13957/Add-exception-for-cross-volume-folder-renames https://pharo.fogbugz.com/f/cases/12992/Cannot-move-files-to-another-volume-partition-under-linux https://pharo.fogbugz.com/f/cases/12965/Cannot-moveTo-FileLocator Issue 12965 is even supposed to include a fix, although when I searched through the slice I couldn't find anything that actually looked like a fix. As Nicolai suggested in 12965, the obvious solution is to implement move as copy+delete. It looks like there isn't an easy way to check whether the two files are on the same unix file system, so presumably it would be implemented as try to rename, and if that fails, try to copy and delete. Is there a reason not to propose this as a patch? Thanks, Alistair
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 looks like a hack. keySelect: would do a select based on the key (index in the case of SequenceableCollection) of the element, no need to create a Dictionary. keySelect: aBlock | result | result := self species new. self keysAndValuesDo: [:key :value | (aBlock value: key) ifTrue: [result add: value] ]. ^result You could implement #selectEverySecond or #selectEveryFirst in terms of the above. The name sounds weird though, but I'm not a native English speaker. Regarding #unzip it's a different story, I wouldn't use 'zip' in a selector for non Zip (compression) related methods. But do as you please, Pharo is yours as well ;) Regards! > I implemented > selectEvery: > (selectFirst selectSecond) as helpers. > > and also unzip all in one pass. > Now I have no problem to keep them for me but to me this is the wrong > attitude. > > Stef > > > testSelectEveryFirst > self assert: (#(#Object #subclass: #Point #instanceVariableNames: 'x y' > #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEveryFirst) > asArray equals: #(#Object #Point 'x y' '' 'Kernel-BasicObjects') > testSelectEverySecond self assert: (#(#Object #subclass: #Point > #instanceVariableNames: 'x y' #classVariableNames: '' #package: > 'Kernel-BasicObjects') selectEverySecond) asArray equals: #(#subclass: > #instanceVariableNames: #classVariableNames: #package:) > testUnzip > | uz | > uz := #(#Object #subclass: #Point #instanceVariableNames: 'x y' > #classVariableNames: '' #package: 'Kernel-BasicObjects') unzip. > self assert: uz first asArray equals: #(#Object #Point 'x y' '' > 'Kernel-BasicObjects'). > self assert: uz second asArray equals: #(#subclass: #instanceVariableNames: > #classVariableNames: #package:) Esteban A. Maringolo
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 IMMEDIATELY realizing that all screenshots containing the > white > > theme are outdated and will IMMEDIATELY prefer the dark ones that will > have > > an updated view of the Pharo GUI compared to a screenshot that has the > > white theme and it's outdated by two or more years. > > > > No they will think it is for a different environment and waste time > looking for a match. > > A beginner won't see that just that they cannot get the same answer as > the mooc or documentation. > > They will look for a language where the documentation matches what they > get as they don't know if the documentation or their code is wrong. (and > probably cast aspersions on the quality of what they are using) > > > Updating the screenshots for PBE5 was a big pain and I am sure there are > > ones that are left that are still outdated showing 1.4 , which is at > least > > 6 years old. > > > > -- > Mark > > >
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. and also unzip all in one pass. Now I have no problem to keep them for me but to me this is the wrong attitude. Stef testSelectEveryFirst self assert: (#(#Object #subclass: #Point #instanceVariableNames: 'x y' #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEveryFirst) asArray equals: #(#Object #Point 'x y' '' 'Kernel-BasicObjects') testSelectEverySecond self assert: (#(#Object #subclass: #Point #instanceVariableNames: 'x y' #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEverySecond) asArray equals: #(#subclass: #instanceVariableNames: #classVariableNames: #package:) testUnzip | uz | uz := #(#Object #subclass: #Point #instanceVariableNames: 'x y' #classVariableNames: '' #package: 'Kernel-BasicObjects') unzip. self assert: uz first asArray equals: #(#Object #Point 'x y' '' 'Kernel-BasicObjects'). self assert: uz second asArray equals: #(#subclass: #instanceVariableNames: #classVariableNames: #package:) On Wed, Apr 19, 2017 at 9:05 PM, Esteban A. Maringolo wrote: > 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 > > > > #(#Object #subclass: #Point #instanceVariableNames: 'x y' > > #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEvery: [ > :i | > > i \\ 2 = 0 ] > > could be a nice iterator. > > > > What do you think? > > I think I wouldn't add a new enumerating selector to the core classes. > > If it needs to be there, I would replace it by #keysSelect: > > So it would work to select based on the keys of the receiver (indexes > for sequenced collections) but also would work as it does for > #keysAndValuesDo: implementors. > > Regards, > > > -- > Esteban. > >
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 > > #(#Object #subclass: #Point #instanceVariableNames: 'x y' > #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEvery: [ :i | > i \\ 2 = 0 ] > could be a nice iterator. > > What do you think? I think I wouldn't add a new enumerating selector to the core classes. If it needs to be there, I would replace it by #keysSelect: So it would work to select based on the keys of the receiver (indexes for sequenced collections) but also would work as it does for #keysAndValuesDo: implementors. Regards, -- Esteban.
[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: 'Kernel-BasicObjects') selectEvery: [ :i | i \\ 2 = 0 ] could be a nice iterator. What do you think? Stef
[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: 2017-04-19 (Wed, 19 Apr 2017) Changed paths: R GT-EventRecorder-Tests.package/GlobalIdentifierFuelPersistenceTest.class/README.md R GT-EventRecorder-Tests.package/GlobalIdentifierFuelPersistenceTest.class/definition.st R GT-EventRecorder-Tests.package/GlobalIdentifierFuelPersistenceTest.class/instance/accessing/persistenceClass.st R GT-EventRecorder-Tests.package/GlobalIdentifierFuelPersistenceTest.class/instance/running/setUpPreferences.st R GT-EventRecorder-Tests.package/GlobalIdentifierFuelPersistenceTest.class/instance/running/tearDown.st R GT-EventRecorder-Tests.package/GlobalIdentifierMergerTest.class/README.md R GT-EventRecorder-Tests.package/GlobalIdentifierMergerTest.class/definition.st R GT-EventRecorder-Tests.package/GlobalIdentifierMergerTest.class/instance/running/setUp.st R GT-EventRecorder-Tests.package/GlobalIdentifierMergerTest.class/instance/tests/testMerge.st R GT-EventRecorder-Tests.package/GlobalIdentifierMergerTest.class/instance/tests/testMerge2.st R GT-EventRecorder-Tests.package/GlobalIdentifierMergerTest.class/instance/tests/testMerge3.st R GT-EventRecorder-Tests.package/GlobalIdentifierMergerTest.class/instance/tests/testMerge4.st R GT-EventRecorder-Tests.package/GlobalIdentifierMergerTest.class/instance/tests/testMerge5.st R GT-EventRecorder-Tests.package/GlobalIdentifierMergerTest.class/instance/tests/testMerge6.st R GT-EventRecorder-Tests.package/GlobalIdentifierMergerTest.class/instance/tests/testMerge7.st R GT-EventRecorder-Tests.package/GlobalIdentifierMergerTest.class/instance/tests/testMerge8.st R GT-EventRecorder-Tests.package/GlobalIdentifierPersistenceTest.class/README.md R GT-EventRecorder-Tests.package/GlobalIdentifierPersistenceTest.class/class/testing/isAbstract.st R GT-EventRecorder-Tests.package/GlobalIdentifierPersistenceTest.class/definition.st R GT-EventRecorder-Tests.package/GlobalIdentifierPersistenceTest.class/instance/accessing/folderName.st R GT-EventRecorder-Tests.package/GlobalIdentifierPersistenceTest.class/instance/accessing/persistenceClass.st R GT-EventRecorder-Tests.package/GlobalIdentifierPersistenceTest.class/instance/running/setUp.st R GT-EventRecorder-Tests.package/GlobalIdentifierPersistenceTest.class/instance/running/setUpPreferences.st R GT-EventRecorder-Tests.package/GlobalIdentifierPersistenceTest.class/instance/running/tearDown.st R GT-EventRecorder-Tests.package/GlobalIdentifierPersistenceTest.class/instance/tests/testDefault.st R GT-EventRecorder-Tests.package/GlobalIdentifierPersistenceTest.class/instance/tests/testDelete.st R GT-EventRecorder-Tests.package/GlobalIdentifierPersistenceTest.class/instance/tests/testEnsureDirectory.st R GT-EventRecorder-Tests.package/GlobalIdentifierPersistenceTest.class/instance/tests/testLoad.st R GT-EventRecorder-Tests.package/GlobalIdentifierPersistenceTest.class/instance/tests/testLoad2.st R GT-EventRecorder-Tests.package/GlobalIdentifierPersistenceTest.class/instance/tests/testSave.st R GT-EventRecorder-Tests.package/GlobalIdentifierStonPersistenceTest.class/README.md R GT-EventRecorder-Tests.package/GlobalIdentifierStonPersistenceTest.class/definition.st R GT-EventRecorder-Tests.package/GlobalIdentifierStonPersistenceTest.class/instance/accessing/persistenceClass.st R GT-EventRecorder-Tests.package/GlobalIdentifierStonPersistenceTest.class/instance/running/setUpPreferences.st R GT-EventRecorder-Tests.package/GlobalIdentifierTest.class/README.md R GT-EventRecorder-Tests.package/GlobalIdentifierTest.class/class/testing/isAbstract.st R GT-EventRecorder-Tests.package/GlobalIdentifierTest.class/definition.st R GT-EventRecorder-Tests.package/GlobalIdentifierTest.class/instance/accessing/actualPreferencesFileName.st R GT-EventRecorder-Tests.package/GlobalIdentifierTest.class/instance/accessing/folderName.st R GT-EventRecorder-Tests.package/GlobalIdentifierTest.class/instance/running/setUp.st R GT-EventRecorder-Tests.package/GlobalIdentifierTest.class/instance/running/setUpPersistenceStrategy.st R GT-EventRecorder-Tests.package/GlobalIdentifierTest.class/instance/running/tearDown.st R GT-EventRecorder-Tests.package/GlobalIdentifierTest.class/instance/tests/testBackwardCompatibility.st R GT-EventRecorder-Tests.package/GlobalIdentifierTest.class/instance/tests/testBackwardCompatibility2.st R GT-EventRecorder-Tests.package/GlobalIdentifierTest.class/instance/tests/testBackwardCompatibility3.st R GT-EventRecorder-Tests.package/GlobalIdentifierTest.class/instance/tests/testBackwardCompatibility4.st R GT-EventRecord
[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 the Pharo Smalltalk Developers mailing list archive at Nabble.com.
[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 Precisely. (and reading my original mail I've realized that I should not write when I am tired... the first sentence there made no sense at all... sorry :)) Peter > > :) > > On Tue, Apr 18, 2017 at 10:03 AM, Denis Kudriashov > wrote: > > > Hi Martin. > > > > 2017-04-18 0:22 GMT+02:00 Martin Dias : > > > >> You can disable it: World Menu > Settings > Tools > Epicea > Detect lost > >> events on start up > > > > > > Idea to not disable it but to show notification about lost changes with > > button to open changes browser. It should remove delay on image startup > > because full changes will be not loaded in that case. > > > >
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 Ducasse wrote: > > like that you understand why he is no replying >
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 wrote: > Hi Martin. > > 2017-04-18 0:22 GMT+02:00 Martin Dias : > >> You can disable it: World Menu > Settings > Tools > Epicea > Detect lost >> events on start up > > > Idea to not disable it but to show notification about lost changes with > button to open changes browser. It should remove delay on image startup > because full changes will be not loaded in that case. > >
