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

2017-04-20 Thread Alistair Grant 
On Fri, Apr 21, 2017 at 09:05:15AM +0800, Ben Coman wrote:
> On Fri, Apr 21, 2017 at 12:31 AM, Nicolas Cellier
>  wrote:
> >
> > On the other hand, we have #keysAndValuesDo: which competes with
> > #withIndexDo: and is a bit more portable across dialects
> > (it's just that it turns the bloc parameters the other way around, [:index
> > :element | ])
> >
> > So maybe this should have been #keysAndValuesSelect: #keysAndValuesCollect:
> >
> > Reminder, keys does not mean Dictionary, in an IndexedCollection (or maybe a
> > SequenceableCollection) the keys are indices. Or the other way around, a
> > Dictionary is indexed by arbitrary keys (not just positive integers).
> 
> Sounds like something I should know, but I'm not quite getting it.
> Could you provide an example?

Is this what you meant?


| results |

results := OrderedCollection new.
#('a' 'b' 'c' 'd') keysAndValuesDo: 
[ :k :v | results add: { k. v. } ].
results


Cheers,
Alistair

Re: [Pharo-dev] do we "how to use Announcements" somewhere

2017-04-20 Thread Ben Coman 
On Fri, Apr 21, 2017 at 10:12 AM, Ben Coman  wrote:
> On Fri, Apr 21, 2017 at 5:47 AM, Peter Uhnak  wrote:
>> I was just explaining how Announcer/Announcements work to somebody because I 
>> couldn't find any online resource, but I thought I saw it somewhere.
>>
>> Do we have it explained in some book?
>>
>> Peter
>>
>
> I remember finding this tutorial very instructive.  Its quite old so
> I'm not sure how current it is, but I don't think much has changed
> with the Announcements API.
> http://pharo.dougedmunds.com/pmwiki.php?n=Pharo.AnnouncementsTutorial
>
> Also...
> http://pharo.gemtalksystems.com/book/LanguageAndLibraries/announcements/
> and...
> https://pharoweekly.wordpress.com/2016/09/03/building-an-announcement-spy-in/
>
> cheers -ben

Oh, and...
https://github.com/SquareBracketAssociates/PharoLimbo/blob/master/Announcements/Announcements.pdf

cheers -ben

Re: [Pharo-dev] do we "how to use Announcements" somewhere

2017-04-20 Thread Ben Coman 
On Fri, Apr 21, 2017 at 5:47 AM, Peter Uhnak  wrote:
> I was just explaining how Announcer/Announcements work to somebody because I 
> couldn't find any online resource, but I thought I saw it somewhere.
>
> Do we have it explained in some book?
>
> Peter
>

I remember finding this tutorial very instructive.  Its quite old so
I'm not sure how current it is, but I don't think much has changed
with the Announcements API.
http://pharo.dougedmunds.com/pmwiki.php?n=Pharo.AnnouncementsTutorial

Also...
http://pharo.gemtalksystems.com/book/LanguageAndLibraries/announcements/
and...
https://pharoweekly.wordpress.com/2016/09/03/building-an-announcement-spy-in/

cheers -ben

Re: [Pharo-dev] [Vm-dev] Fwd: Nix package for Pharo flavor of opensmalltalk-vm

2017-04-20 Thread Ben Coman 
On Fri, Apr 21, 2017 at 3:11 AM, Luke Gorrie  wrote:
> Hi Ben,
>
> Thanks for explaining the process for maintaining the stable vs development
> versions and illustrating it with data.
>
> I need to understand the Pharo Launcher better. Could indeed be the best
> strategy is to focus on supporting that well. That's basically the approach
> that Damien has taken with the current nix packages.
>
> Hopefully we can work out the optimal way to package Pharo once 6.0 has
> shipped and people have more bandwidth. Just now I have a hard time
> understanding what VM+image combinations are considered to be "supported"

In times past, the VM from the previous release has usually remained
stable for the most of the next development cycle. Except last year
there was a big change from pre-Spur to Spur, and this year a big
change from 32-bit to 64-bit, as you can see from the rate of
change...
https://github.com/OpenSmalltalk/opensmalltalk-vm/graphs/contributors

These two very positive events obviously came with more churn in
updating the VM.


> vs which ones are likely to have obscure plugin problems, etc.

I've not seen many plugin problems reported.  Now unless you join the
consortium or otherwise pay for support, I would guess you'll get the
"best" support on the tip of development, with the risk of being the
first to categorise a new bug.  What might be good is to periodically
define some recommended in-development VM-Image combinations, so we
get more people working with a particular combination - to more
quickly hit bugs in a particular combo, and provide confidence for the
more cautious to move their applications forward. That is, not the
effort of a full release, (@Esteban?)

Very broadly, I'd stick with the Pharo 6 release for the first 3 - 6
months while any high impact stuff that has been waiting in the wings
during the Pharo 6 feature freeze are integrated.  Then as Pharo-6
bugs fixed in Pharo-7-dev accumulate, consider moving your personal
development to Pharo-7-dev, keeping release on Pharo-6.  It probably a
good idea port your app to Pharo-7-dev at least three months prior to
its release - so any bugs you hit get fixed *in* Pharo 7, otherwise
(unless they are critical, or you pay) you may end up waiting until
Pharo 8 release.

Probably its good to have CI running for both Pharo 6 Release and
Pharo-7-dev-tip so your tests pick up any new bugs.
https://ci.inria.fr/pharo-contribution/
@Damien might advise how compatible this is with nix.

(Disclaimer: Pharo is currently just a (significant) hobby for me, so
in practice YMMV.)

cheers -ben

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

2017-04-20 Thread Ben Coman 
On Fri, Apr 21, 2017 at 12:31 AM, Nicolas Cellier
 wrote:
>
>
> 2017-04-20 17:06 GMT+02:00 Ben Coman :
>>
>>
>>
>> On Thu, Apr 20, 2017 at 3:17 AM, Stephane Ducasse
>>  wrote:
>>>
>>> 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')
>>
>>
>>
>> selectEveryFirst seems a strange name, not indicating the skip amount.
>> The first of every three? or four?  As it stand, technically I'd think its
>> result would
>> be equals: (#(#Object #subclass: #Point #instanceVariableNames: 'x y'
>> #classVariableNames: '' #package: 'Kernel-BasicObjects')
>>
>> +1 to Peter's suggested #withIndexSelect:
>>
>> cheers -ben
>
>
> On the other hand, we have #keysAndValuesDo: which competes with
> #withIndexDo: and is a bit more portable across dialects
> (it's just that it turns the bloc parameters the other way around, [:index
> :element | ])
>
> So maybe this should have been #keysAndValuesSelect: #keysAndValuesCollect:
>
> Reminder, keys does not mean Dictionary, in an IndexedCollection (or maybe a
> SequenceableCollection) the keys are indices. Or the other way around, a
> Dictionary is indexed by arbitrary keys (not just positive integers).

Sounds like something I should know, but I'm not quite getting it.
Could you provide an example?

cheers -ben

Re: [Pharo-dev] do we "how to use Announcements" somewhere

2017-04-20 Thread Cyril Ferlicot D. 
Le 20/04/2017 à 23:47, Peter Uhnak a écrit :
> I was just explaining how Announcer/Announcements work to somebody because I 
> couldn't find any online resource, but I thought I saw it somewhere.
> 
> Do we have it explained in some book?
> 
> Peter
> 
Hi,

Check the Help Browser in Pharo.

In Pharo 6 the main Announcement class comments where improve with this
lines:


See in the help browser for more documentation. Just do:

HelpBrowser  openOn: AnnouncementsHelp

-- 
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature

[Pharo-dev] do we "how to use Announcements" somewhere

2017-04-20 Thread Peter Uhnak 
I was just explaining how Announcer/Announcements work to somebody because I 
couldn't find any online resource, but I thought I saw it somewhere.

Do we have it explained in some book?

Peter

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

2017-04-20 Thread Nicolas Cellier 
2017-04-20 9:53 GMT+02:00 Alistair Grant :

> On Wed, Apr 19, 2017 at 09:57:41PM +0200, Nicolas Cellier wrote:
> > 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.
>
> I meant from within the image.  Also, while this is fine for Linux,
> and probably for MacOS, what about Windows?
>
>
Ah, so it's more a Squeak/Pharo VM problem than a unix problem ;)
You are right, there is a call to stat() in unix file plugin

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/plugins/FilePlugin/sqUnixFile.c

but the device info is not passed back to the image...
Too bad!

As for windows, it's not a problem, there is a rename function that would
move files across devices (but not directories!)
See rename() on msdn https://msdn.microsoft.com/en-us/library/zw5t957f.aspx



> It would be great if this exists in the image.  Maybe it's time for me
> to learn FFI.
>
>
Yes, that would probably work.
However, what I don't like with FFI is that we have to pass a pointer on
the stat structure to the foreign function.
But what is the exact layout of this structure? Is it identical on all
suported OS? Is the order of fields stable across implementations?
Is it going to gain new fields in future versions?
I'm not so sure that a standard does impose those implementation details...
So someone must check image implementation on each supported OS (and major
OS version).
Practically, the layout is not going to change everyday, but we have no
guaranty.

If it's C source code, then those details are not exposed, they are in
implementation provided headers, and we can compile identical source code
at application side (the file plugin).

We already had this conversation many times. Eliot said that image side
implementation-defined features like constants or structure size and layout
could be generated, but this work is yet to be done.


>
> > Is there a reason not to propose this as a patch?
>
> Cheers,
> Alistair
>
>
>

Re: [Pharo-dev] [Vm-dev] Fwd: Nix package for Pharo flavor of opensmalltalk-vm

2017-04-20 Thread Luke Gorrie 
Hi Ben,

Thanks for explaining the process for maintaining the stable vs development
versions and illustrating it with data.

I need to understand the Pharo Launcher better. Could indeed be the best
strategy is to focus on supporting that well. That's basically the approach
that Damien has taken with the current nix packages.

Hopefully we can work out the optimal way to package Pharo once 6.0 has
shipped and people have more bandwidth. Just now I have a hard time
understanding what VM+image combinations are considered to be "supported"
vs which ones are likely to have obscure plugin problems, etc.

[Pharo-dev] [pharo-project/pharo-core] 7bde98: 60468

2017-04-20 Thread GitHub 
  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 7bde98ed1694390205b9b93c81ebfffc82ed2ff3
  
https://github.com/pharo-project/pharo-core/commit/7bde98ed1694390205b9b93c81ebfffc82ed2ff3
  Author: Jenkins Build Server 
  Date:   2017-04-20 (Thu, 20 Apr 2017)

  Changed paths:
A 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/basic-colors/errorPopperBackgroundColor.st
M 
Glamour-Morphic-Widgets.package/GLMErrorPopper.class/instance/initialization/initializeTextMorph.st
A 
Polymorph-Widgets.package/Pharo3DarkTheme.class/instance/basic-colors/errorPopperBackgroundColor.st
M Polymorph-Widgets.package/Pharo3Theme.class/instance/accessing 
colors/balloonBackgroundColor.st
A 
Polymorph-Widgets.package/Pharo3Theme.class/instance/basic-colors/errorPopperBackgroundColor.st
A 
Polymorph-Widgets.package/UIThemeWatery.class/instance/basic-colors/errorPopperBackgroundColor.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60467.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60468.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60467.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60468.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
A TravisIntegrationHelp.package/TravisIntegrationHelp.class/README.md
A 
TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/accessing/bookName.st
A 
TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/accessing/open.st
A 
TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/accessing/pages.st
A 
TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/introduction.st
A 
TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/moreInformation.st
A 
TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/step01.st
A 
TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/step02.st
A 
TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/step03.st
A 
TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/step04.st
A 
TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/step05.st
A TravisIntegrationHelp.package/TravisIntegrationHelp.class/definition.st

  Log Message:
  ---
  60468
19956 switching back to pharo3 theme has wrong tooltip color
https://pharo.fogbugz.com/f/cases/19956

19937 Help for TravisIntegration
https://pharo.fogbugz.com/f/cases/19937

19961 Impossible to read popup error in playground and Dark Theme
https://pharo.fogbugz.com/f/cases/19961

http://files.pharo.org/image/60/60468.zip

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

2017-04-20 Thread GitHub 
  Branch: refs/tags/60468
  Home:   https://github.com/pharo-project/pharo-core

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

2017-04-20 Thread Alistair Grant 
Hi Stef,

On Thu, Apr 20, 2017 at 08:11:31PM +0200, Stephane Ducasse wrote:
> Thanks for looking at this. We should really improve this part. 

No problem.  I've just finished coding and testing.

The one part I'm not completely happy with is what I mentioned earlier:
I'm not aware of any way within Pharo to determine whether two files are
on the same disk filesystem, so currently the code tries a rename, and if
that fails it falls back to copy and delete.  If I get a chance to
learn FFI soon I may try and improve it.

The original FileLocatorTest>>testMoveTo test now passes, and running
the entire test suite produces the same results (there are a few other
tests that fail).

There are some additional tests, so it currently checks:

- Moving files within the disk filesystem works.
- Moving files within the memory filesystem works.
- Moving files from the memory filesystem to the disk filesystem works.

Since this is a core part of the system, I'm going to wait until Pharo 7
development begins before posting the patch.  This will also provide
some ad-hoc testing as I've got this in my daily work image.

Cheers,
Alistair


> On Wed, Apr 19, 2017 at 9:41 PM, Alistair Grant  wrote:
> 
> 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-20 Thread Esteban A. Maringolo 
2017-04-20 13:31 GMT-03:00 Nicolas Cellier :
>
>
> 2017-04-20 17:06 GMT+02:00 Ben Coman :

> On the other hand, we have #keysAndValuesDo: which competes with
> #withIndexDo: and is a bit more portable across dialects
> (it's just that it turns the bloc parameters the other way around, [:index
> :element | ])
>
> So maybe this should have been #keysAndValuesSelect: #keysAndValuesCollect:

+1

> Reminder, keys does not mean Dictionary, in an IndexedCollection (or maybe a
> SequenceableCollection) the keys are indices. Or the other way around, a
> Dictionary is indexed by arbitrary keys (not just positive integers).

This is what I was trying to explain at the beginning. :)


Esteban A. Maringolo

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

2017-04-20 Thread Stephane Ducasse 
Thanks for looking at this. We should really improve this part.

On Wed, Apr 19, 2017 at 9:41 PM, Alistair Grant 
wrote:

> 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] Pharo 5 and retina displays in 2017?

2017-04-20 Thread Stephane Ducasse 
retina should be supported.
Now we need to get rid of bug induced by freetype and what would be better
is to have the time to breath and think.
Because right now FFI and 64 bits sucked most of the attention of esteban.

For Bloc yes it got more traction but we will know more during PharoDays I
imagine.

Stef


On Thu, Apr 20, 2017 at 2:27 PM, Tim Mackinnon  wrote:

> I mentioned this last year - and I’m wondering if there is any news or
> developments on making Pharo look better on higher end hardware like
> Macbook’s and Dell’s?
>
> I keep dipping into Pharo but every time I see the blurry screen, it just
> takes away the shine for me (which is a bit sad)?
>
> Is Bloc getting much traction?
>
> Tim
>
>
> On 23 Dec 2016, at 09:29, Tim Mackinnon  wrote:
>
> Thanks for the update - that is exciting and gives me some hope.
>
> What do we need to do to help bloc advance at pace?
>
> Tim
>
> Sent from my iPhone
>
> On 23 Dec 2016, at 01:22, Yuriy Tymchuk  wrote:
>
> Hi Tim,
>
> it’s coming, but it needs some time: https://twitter.com/
> aliakseisyrel/status/812065956856025088
>
> On 1 Dec 2016, at 14:44, Tim Mackinnon  wrote:
>
> To give people a better view of this - here is the Pharo image next to the
> mail client (I’m not sure if the screen captures really do it justice as
> when you scale them down in a picture everything looks fine - however if I
> zoom into that bottom corner in a second image it might make it more
> obvious).
>
> I think this has been a problem brewing for a while, but if most
> contributors don’t have retina screens (although they are getting much more
> common now) then I guess it goes unnoticed. I suspect in the next few
> years, as people start replacing machines - it will gain more visibility.
>
> I find it quite distracting when switching from mail or other apps to
> Pharo and then you notice the fuzziness. Maybe if you spend a few hours in
> the code you might adjust.
>
> Tim
>
>
>
> The following is the bottom corner zoom in to show what I mean by fuzzy:
>
>
> 
>
> On 30 Nov 2016, at 23:53, Stephan Eggermont  wrote:
>
> On 30/11/16 20:32, Sven Van Caekenberghe wrote:
>
> Maybe, but the thing is, you are looking at it half size, in some
> sense, when it is on a Retina display. Anyway, to me, it is OK, but
> my eyes are no longer what they used to be. I can imagine young
> people being more sensitive to it.
>
>
> Nah, it just is blurry. I've played a bit with krono's vm, and it is
> a very noticable difference. Much better readable and less tiring.
> And you mostly only notice when trying to go back from HiDPI to low.
>
> Stephan
>
>
>
>
>
>

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

2017-04-20 Thread Stephane Ducasse 
Hi nicolas

Yes but it looks strange :)
but indeed having a

#keysAndValuesSelect: #keysAndValuesCollect:

And it would be good to have #withIndexDo: following the same orders for
argument.



On Thu, Apr 20, 2017 at 6:31 PM, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:

>
>
> 2017-04-20 17:06 GMT+02:00 Ben Coman :
>
>>
>>
>> On Thu, Apr 20, 2017 at 3:17 AM, Stephane Ducasse <
>> stepharo.s...@gmail.com> wrote:
>>
>>> 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')
>>>
>>
>>
>> selectEveryFirst seems a strange name, not indicating the skip amount.
>> The first of every three? or four?  As it stand, technically I'd think
>> its result would
>> be equals: (#(#Object #subclass: #Point #instanceVariableNames: 'x y'
>> #classVariableNames: '' #package: 'Kernel-BasicObjects')
>>
>> +1 to Peter's suggested #withIndexSelect:
>>
>> cheers -ben
>>
>
> On the other hand, we have #keysAndValuesDo: which competes with
> #withIndexDo: and is a bit more portable across dialects
> (it's just that it turns the bloc parameters the other way around, [:index
> :element | ])
>
> So maybe this should have been #keysAndValuesSelect: #keysAndValuesCollect:
>
> Reminder, keys does not mean Dictionary, in an IndexedCollection (or maybe
> a SequenceableCollection) the keys are indices. Or the other way around, a
> Dictionary is indexed by arbitrary keys (not just positive integers).
>

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

2017-04-20 Thread Stephane Ducasse 
Peter

can you send an implementation and a bunch of tests :)

Stef

On Wed, Apr 19, 2017 at 11:07 PM, 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 :)

2017-04-20 Thread Stephane Ducasse 
Yes this is probably what I was also looking for.

On Wed, Apr 19, 2017 at 11:07 PM, 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 :)

2017-04-20 Thread Stephane Ducasse 
This is what I was looking for.



On Wed, Apr 19, 2017 at 10:54 PM, Sven Van Caekenberghe 
wrote:

> 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] changing default theme to DarkTheme

2017-04-20 Thread Ben Coman 
I see in 60467 that the deed is done.  Okay, so moving forward... be
prepared ;) for a surge of feedback as a bunch of us
dark-theme-newbies start using it in earnest.  I understand those that
been using it a while already are obviously happy with how its tuned,
and probably not many things can be accommodated, but there is one
thing...

Maybe its that its 1AM, or its my astigmatism, but my first impression
was a shock at the high contrast pure-white-on-black text - for the
World Menu and System Browser - to the degree that my eyes felt
crosseyed.  Particularly the title-bar-text was jarring.  Dimming it
slightly made it *much* easier to focus.   Could
dark-theme-connoisseurs try this out...

Pharo3DarkTheme>>textColor
^ Color veryLightGray lighter


And wow!  That very bright green in TestRunner hurts.


Other than that, so far it looks cool.

cheers -ben


On Thu, Apr 20, 2017 at 3:19 AM, Stephane Ducasse
 wrote:
> 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 :)

2017-04-20 Thread Nicolas Cellier 
2017-04-20 17:06 GMT+02:00 Ben Coman :

>
>
> On Thu, Apr 20, 2017 at 3:17 AM, Stephane Ducasse  > wrote:
>
>> 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')
>>
>
>
> selectEveryFirst seems a strange name, not indicating the skip amount.
> The first of every three? or four?  As it stand, technically I'd think its
> result would
> be equals: (#(#Object #subclass: #Point #instanceVariableNames: 'x y'
> #classVariableNames: '' #package: 'Kernel-BasicObjects')
>
> +1 to Peter's suggested #withIndexSelect:
>
> cheers -ben
>

On the other hand, we have #keysAndValuesDo: which competes with
#withIndexDo: and is a bit more portable across dialects
(it's just that it turns the bloc parameters the other way around, [:index
:element | ])

So maybe this should have been #keysAndValuesSelect: #keysAndValuesCollect:

Reminder, keys does not mean Dictionary, in an IndexedCollection (or maybe
a SequenceableCollection) the keys are indices. Or the other way around, a
Dictionary is indexed by arbitrary keys (not just positive integers).

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

2017-04-20 Thread Ben Coman 
On Thu, Apr 20, 2017 at 3:17 AM, Stephane Ducasse 
wrote:

> 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')
>


selectEveryFirst seems a strange name, not indicating the skip amount.
The first of every three? or four?  As it stand, technically I'd think its
result would
be equals: (#(#Object #subclass: #Point #instanceVariableNames: 'x y'
#classVariableNames: '' #package: 'Kernel-BasicObjects')

+1 to Peter's suggested #withIndexSelect:

cheers -ben

Re: [Pharo-dev] [Vm-dev] Fwd: Nix package for Pharo flavor of opensmalltalk-vm

2017-04-20 Thread Ben Coman 
On Thu, Apr 20, 2017 at 10:19 PM, Ben Coman  wrote:
> Moved thread back to pharo-dev for image-side nix packaging discussion.

Whoops. Try again, back to pharo-dev.

>
> On Thu, Apr 20, 2017 at 3:59 PM, Luke Gorrie  wrote:
>>
>> On 20 April 2017 at 06:03, Ben Coman  wrote:
>>
>>> On Thu, Apr 20, 2017 at 12:21 AM, Luke Gorrie  wrote:

 Then you can start one of those images with these shell commands:

 pharo-6.0
 pharo64-6.0
 pharo-5.0
 moose-6.1
 pharo-launcher-2017.02.28
>>>
>>> Since Pharo 6 is not yet released, what are the implications of naming those
>>> pharo-6.dev & pharo64-6.dev [minor edit]
>>
>> On reflection I will split up my packaging work into "vm" and "image" 
>> components. I will send the vm upstream ASAP. I will leave the images on a 
>> development branch, perhaps indefinitely, because I am not sure that I am on 
>> the right track there at all.
>
> That sounds like a good approach.
>
>> So, here are more thoughts on image packaging, but with the disclaimer that 
>> I will probably not actively pursue this topic further at the moment:
>>
>> I assert that Pharo 5 and Pharo 6 are both released,
>
> The "release" event will create the PharoV60.sources file,
> null out the .changes file (it gets incorporated into PharoV60.sources)
> and Pharo 7 development on will commence.
> None of those things has happened yet.
> Last I read, this was due in May, similar timeframe to Pharo 5 release
> last year.
>
>> and are both fast-moving targets.
>
> The attached chart shows the dev-image build rate.
> There is a clear change in Pharo 5 build rate after it was released on 12-May.
> What happens is that during Pharo-6-development, a critical bug was
> fixed and deemed worthy to backport to Pharo 5.  That doesn't put
> released-Pharo-5 and in-development-Pharo-6 on equal footing.
>
> Perhaps for packaging for distributions we need a modified process
> for post-release-updates, such that the released image remains
> constant and upon startup notifies that there are updates available to
> install.
>
>>
>> On http://pharo.org/download there is a prominent link to Pharo 6 as the 
>> "development version" ready for download. Anecdotally the Pharo community 
>> that I interact with (mailing list, twitter, slack chat, etc) seem more 
>> focused on Pharo 6 than on Pharo 5.
>
> The greater focus on Pharo 6 is because it is "in development"
> and you are talking to pharo-developers.
>
>
>> Occasionally people express surprise when I tell them I am "still" using 
>> Pharo 5.
>
> On the one hand, that might be considered overzealous recommending
> alpha/beta software for your primary platform.  On the other hand,
> in practice many find the bleeding edge consistently very stable.
> (opinion depends on the exact critical nature the application)
>
> The thing is, if you hit a bug in the in-development version, it can
> get fixed quite quickly.  More Pharo-developers work on the HEAD,
> so its self interest to get things working smoothly. Policy is that *all*
> fixes must *first* be done in the in-development-version.  Only critical
> fixes get backported to the released-version.  So if you hit a bug in
> a released-version, you might not see the fix before the next release.
>
> So there is a lot of benefit following the tip of development.
>
>>
>> On http://files.pharo.org/image/50/ there is a new release of Pharo 5 every 
>> few weeks. This means that each time I have downloaded "Pharo 5" in the past 
>> I have probably gotten a different image and a different VM. So from my 
>> end-user perspective I have no idea what software I am installing regardless 
>> of whether I choose Pharo 5 or Pharo 6.
>
> I consider this moving target for a released version (i.e. Pharo 5) a
> problem. Personally I'd like to see post-release versionning like
> 5.0.x,
> but other seem to disagree, or maybe its just resourcing.
>
> Pharo 6 is "in-development" so different rules apply.
> Personally I never use the "latest" download.
> I manually choose the latest build using PharoLauncher (couldn't live
> without it)
>
>
>>
>> So as a nix user it would make sense for me to be able to download both 
>> Pharo 5 and Pharo 6 and for the nix package definitions to determine exactly 
>> which software I am running (as opposed to getting an invisible update from 
>> Pharo upstream every few days/weeks potentially leading to "but it worked 
>> fine on my other machine..." sorts of problems that are exactly what can nix 
>> protect me from.)
>>
>
> I agree with you wrt to a released-Pharo-5, but not in-development-Pharo-6.
>
>
>>> Packing the other images is maybe also wrong.  How would you deal with user 
>>> state being stored in the image when a new build download in available?
>>
>>
>> The ad-hoc idea that I ran with is this:
>>
>> Running a script like pharo-5.0 (or moose-6.1, etc) will make a temporary 
>> copy of the image in the current directory. The changes file will be 
>> read-write (requirement) but the i

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

2017-04-20 Thread Ron Teitelbaum 
The first thing I thought of was:

| anArray |
anArray := #(#Object #subclass: #Point #instanceVariableNames: 'x y'
#classVariableNames: '' #package: 'Kernel-BasicObjects').

(1 to: anArray size by: 2) collect: [:i | anArray at: i]

All the best,

Ron Teitelbaum

On Thu, Apr 20, 2017 at 2:04 AM Alistair Grant 
wrote:

> 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
>
>
>
>

[Pharo-dev] Pharo 5 and retina displays in 2017?

2017-04-20 Thread Tim Mackinnon 
I mentioned this last year - and I’m wondering if there is any news or 
developments on making Pharo look better on higher end hardware like Macbook’s 
and Dell’s?

I keep dipping into Pharo but every time I see the blurry screen, it just takes 
away the shine for me (which is a bit sad)?

Is Bloc getting much traction? 

Tim


> On 23 Dec 2016, at 09:29, Tim Mackinnon  wrote:
> 
> Thanks for the update - that is exciting and gives me some hope.
> 
> What do we need to do to help bloc advance at pace?
> 
> Tim
> 
> Sent from my iPhone
> 
> On 23 Dec 2016, at 01:22, Yuriy Tymchuk  > wrote:
> 
>> Hi Tim,
>> 
>> it’s coming, but it needs some time: 
>> https://twitter.com/aliakseisyrel/status/812065956856025088 
>> 
>>> On 1 Dec 2016, at 14:44, Tim Mackinnon >> > wrote:
>>> 
>>> To give people a better view of this - here is the Pharo image next to the 
>>> mail client (I’m not sure if the screen captures really do it justice as 
>>> when you scale them down in a picture everything looks fine - however if I 
>>> zoom into that bottom corner in a second image it might make it more 
>>> obvious).
>>> 
>>> I think this has been a problem brewing for a while, but if most 
>>> contributors don’t have retina screens (although they are getting much more 
>>> common now) then I guess it goes unnoticed. I suspect in the next few 
>>> years, as people start replacing machines - it will gain more visibility.
>>> 
>>> I find it quite distracting when switching from mail or other apps to Pharo 
>>> and then you notice the fuzziness. Maybe if you spend a few hours in the 
>>> code you might adjust.
>>> 
>>> Tim
>>> 
>>> 
>>> 
>>> The following is the bottom corner zoom in to show what I mean by fuzzy:
>>> 
>>> 
>>> 
 On 30 Nov 2016, at 23:53, Stephan Eggermont >>> > wrote:
 
 On 30/11/16 20:32, Sven Van Caekenberghe wrote:
> Maybe, but the thing is, you are looking at it half size, in some
> sense, when it is on a Retina display. Anyway, to me, it is OK, but
> my eyes are no longer what they used to be. I can imagine young
> people being more sensitive to it.
 
 Nah, it just is blurry. I've played a bit with krono's vm, and it is
 a very noticable difference. Much better readable and less tiring.
 And you mostly only notice when trying to go back from HiDPI to low.
 
 Stephan
 
 
>>> 
>>

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

2017-04-20 Thread Denis Kudriashov 
I as trying to write little tips. But I realized new issue 19957


2017-04-20 3:34 GMT+02:00 Ben Coman :

>
>
> 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
>

[Pharo-dev] Spotter feature idea/request - exclusion filter

2017-04-20 Thread Ben Coman 
I had a poke at this but couldn't find my way into how Spotter filters
work,
so I'll just pass on the idea.

Wanting to look at implementers of  #withIndex*
several tests are mixed in the result that it would be nice to eliminate
by typing "subtract test" like this... " -test "
much like I'd do in google search.

cheers -ben

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

2017-04-20 Thread Alistair Grant 
On Wed, Apr 19, 2017 at 09:57:41PM +0200, Nicolas Cellier wrote:
> 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.

I meant from within the image.  Also, while this is fine for Linux,
and probably for MacOS, what about Windows?

It would be great if this exists in the image.  Maybe it's time for me
to learn FFI.


> Is there a reason not to propose this as a patch?

Cheers,
Alistair

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

2017-04-20 Thread GitHub 
  Branch: refs/tags/60467
  Home:   https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] bf8db7: 60467

2017-04-20 Thread GitHub 
  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: bf8db76012347d23e7b9b78176aebbc6e9be413f
  
https://github.com/pharo-project/pharo-core/commit/bf8db76012347d23e7b9b78176aebbc6e9be413f
  Author: Jenkins Build Server 
  Date:   2017-04-20 (Thu, 20 Apr 2017)

  Changed paths:
A Komitter.package/Komitter.class/instance/announcement/unsubscribe.st
A Komitter.package/KomitterUI.class/instance/private/windowIsClosing.st
M Polymorph-Widgets.package/Pharo3DarkTheme.class/instance/accessing 
colors/borderColor.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60466.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60467.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60466.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60467.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M 
Spec-Tools.package/MessageBrowser.class/instance/private/isMethodDefinition_.st
M System-CommandLineHandler.package/PharoCommandLineHandler.class/README.md

  Log Message:
  ---
  60467
19943 Error while browsing a comment un MessageBrowser
https://pharo.fogbugz.com/f/cases/19943

19945 PharoCommandLineHandler class comments incorrect
https://pharo.fogbugz.com/f/cases/19945

19954 Komitter should explicitly unsubscribe form SystemAnnoucer when window is 
closed
https://pharo.fogbugz.com/f/cases/19954

19941 Dark Theme - overlapped title bars need to be distinctive
https://pharo.fogbugz.com/f/cases/19941

http://files.pharo.org/image/60/60467.zip