Re: [Pharo-dev] odd behaviour dragging method between protocols

[Nicolai Hess]

Happened to me too.
I think. I sometimes thought hey where is that method gone, couldn't
remember I deleted it.

Am 13.12.2017 03:42 schrieb "Ben Coman" :


I could just be having a brain freeze, but just sharing in case
anyone else is similarly going mad...
a few times recently in Nautilus I've dragged a method from the fourth pane
and dropped it on a protocol in the third pane and the method disappeared
from the system.  Luckily its easily recovered from Tools > Code Changes,
where it shows as deleted. But its weird that a delete could be triggered
from the action I (thought I) performed.

I've yet to detect a pattern.  Unfortunately its kind of
blink-and-you-miss-it.
Its not until a second later when selecting the target protocol
that the behaviour becomes apparent.

This is in 60527-64, Unix built on Jul 20 2017 20:40:36 Compiler: 4.6.3

cheers -ben

[Pharo-dev] Epicea feedback - save points

[Ben Coman]

When I'm in need Epicea, the common scenario is that I've working in the
same session of an Image most of the day, or even days, and I've done
something stupid to lock up the UI, and its only been an hour since my last
save point (force of habit).  When I review Epicea, "Filter > Show latest
changes" its still ahrd to determine which changes I'm missing.  What I've
just realised is I miss the visibility of the Save Point in the old changes
system.  I'd find it really useful for the save points to be show in the
changes list, and also a filter I'd find really useful is "Shows latest
changes since last save".


cheers -ben

Re: [Pharo-dev] spurious characters in class comments

[Norbert Hartl]

IMHO this would be the case if the sourde code is written in utf-8 but read in 
latin1.

Norbert

> Am 12.12.2017 um 23:41 schrieb Nicolas Cellier 
> :
> 
> Take a look at Dictionary.class.st for example
> 
> https://github.com/pharo-project/pharo/blob/bc8b9658958f4464189cf3e7fffd8c9bf775f85f/src/Collections-Unordered/Dictionary.class.st
> 
> on line 10:
> 
> I am use when we need a collection of objects which I can 
> access with a key. For example if you associate some words with a definition, 
> the word will be the key and the definition will be the value. Both of them 
> can be any kind of objects. 
> 
> At each commit, the number of odd characters increases...

[Pharo-dev] odd behaviour dragging method between protocols

[Ben Coman]

I could just be having a brain freeze, but just sharing in case
anyone else is similarly going mad...
a few times recently in Nautilus I've dragged a method from the fourth pane
and dropped it on a protocol in the third pane and the method disappeared
from the system.  Luckily its easily recovered from Tools > Code Changes,
where it shows as deleted. But its weird that a delete could be triggered
from the action I (thought I) performed.

I've yet to detect a pattern.  Unfortunately its kind of
blink-and-you-miss-it.
Its not until a second later when selecting the target protocol
that the behaviour becomes apparent.

This is in 60527-64, Unix built on Jul 20 2017 20:40:36 Compiler: 4.6.3

cheers -ben

[Pharo-dev] spurious characters in class comments

[Nicolas Cellier]

Take a look at Dictionary.class.st for example

https://github.com/pharo-project/pharo/blob/bc8b9658958f4464189cf3e7fffd8c9bf775f85f/src/Collections-Unordered/Dictionary.class.st

on line 10:

I am use when we need a collection of objects which I can
access with a key. For example if you associate some words with a
definition, the word will be the key and the definition will be the value.
Both of them can be any kind of objects.

At each commit, the number of odd characters increases...

[Pharo-dev] [Pharo 7.0-dev] Build #378: 20866-revert-retryTimes-parameter-on-CI

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #378 was: SUCCESS.

The Pull Request #600 was integrated: "20866-revert-retryTimes-parameter-on-CI"
Pull request url: https://github.com/pharo-project/pharo/pull/600

Issue Url: https://pharo.fogbugz.com/f/cases/20866
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/378/

Re: [Pharo-dev] better name for #aggregateRuns:

[Todd Blanchard]

I'm kind of trying to figure out when I'd want that operation.

groupsWithSeparatorsWhereSeparatatorsMatch: feels like it says what it does

> On Dec 12, 2017, at 10:19 AM, Ben Coman  wrote:
> 
> 
> 
> On 12 December 2017 at 20:03, Nicolas Cellier 
>  > wrote:
> 
> 
> 2017-12-12 13:01 GMT+01:00 Henrik Sperre Johansen 
> mailto:henrik.s.johan...@veloxit.no>>:
> Ben Coman wrote
> >
> > But after pondering a while for a better name, I wonder what is wrong with
> > the existing?
> > Googling "define aggregate" provides...
> > aggregate (noun) = a whole formed by combining several separate
> > elements.
> > aggregate (verb) = form or group into a class or cluster.
> >
> > The separate elements are runs defined by the block.
> > The existing name seems quite precise to me.
> >
> > cheers -ben
> 
> When I read aggregateRuns:, I think the opposite; something combining
> different runs into a single entity, not something that splits a single
> collection into constituent runs...
> 
> okay. I can understand that perspective. 
>  
> 
> Something like (split/collect)runsAccordingTo: sounds more descriptive to my
> ears, at least.
> 
> Cheers,
> Henry
> 
> 
> 
> I like groupBy: but in Squeak groupBy: produces a dictionary with unique keys 
> ignoring the multiple sequences...
> split already carries the meaning of preserving the sequences, but we have to 
> tell to split at a change of value
> Run is also quite explicit...
> 
> groupByRuns: / splitRuns:
> 
> +1 
> groupByRuns:   is good.
> 
> cheers -ben

Re: [Pharo-dev] Does pharo build not retry anymore?

[Pavel Krivanek]

The variable value was reverted to the original value. Thanks.

-- Pavel

2017-12-12 20:13 GMT+01:00 Pavel Krivanek :

> Yes, with Marcus we decreased the retryTimes variable two weeks ago to 1
> because in that time the validations were in really bad shape and literally
> every validation failed on some random issue and the retries caused
> enormous build times. It was producing more troubles than profit. It
> probably can be reverted now because the main problem of the validation
> instability was suppressed. I will prepare a PR.
>
> -- Pavel
>
> 2017-12-12 18:52 GMT+01:00 Guillermo Polito :
>
>> I see that we are retrying tests only once, which is causing most (if not
>> all) pull requests to fail sporadically...
>>
>> Maybe it got lost because of a mistake?
>>
>> Also, I'd like that changes in the build process are discussed in the
>> mailing list from time to time... I've put a lot of effort into making it
>> work and if we have regressions I'd like to understand them...
>>
>> Guille
>>
>> --
>>
>>
>>
>> Guille Polito
>>
>> Research Engineer
>>
>> Centre de Recherche en Informatique, Signal et Automatique de Lille
>>
>> CRIStAL - UMR 9189
>>
>> French National Center for Scientific Research - *http://www.cnrs.fr
>> *
>>
>>
>> *Web:* *http://guillep.github.io* 
>>
>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>
>
>

Re: [Pharo-dev] I love the launcher!!!!

[Alexandre Bergel]

Your email made me try Pharo Launcher. I love it too!

It replaces all my scripts to download the VM and the last images.

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



> On Nov 23, 2017, at 5:51 AM, Stephane Ducasse  wrote:
> 
> Hi
> 
> I love the PharoLauncher.
> It helps me to manage my parallel development and projects.
> 
> We should put a link on the Pharo web site because
> 
> http://files.pharo.org/platform/launcher/
> 
> is arcane.
> 
> Stef
> 

Re: [Pharo-dev] Does pharo build not retry anymore?

[Pavel Krivanek]

Yes, with Marcus we decreased the retryTimes variable two weeks ago to 1
because in that time the validations were in really bad shape and literally
every validation failed on some random issue and the retries caused
enormous build times. It was producing more troubles than profit. It
probably can be reverted now because the main problem of the validation
instability was suppressed. I will prepare a PR.

-- Pavel

2017-12-12 18:52 GMT+01:00 Guillermo Polito :

> I see that we are retrying tests only once, which is causing most (if not
> all) pull requests to fail sporadically...
>
> Maybe it got lost because of a mistake?
>
> Also, I'd like that changes in the build process are discussed in the
> mailing list from time to time... I've put a lot of effort into making it
> work and if we have regressions I'd like to understand them...
>
> Guille
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> *
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>

Re: [Pharo-dev] better name for #aggregateRuns:

[Ben Coman]

On 12 December 2017 at 20:03, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:

>
>
> 2017-12-12 13:01 GMT+01:00 Henrik Sperre Johansen <
> henrik.s.johan...@veloxit.no>:
>
>> Ben Coman wrote
>> >
>> > But after pondering a while for a better name, I wonder what is wrong
>> with
>> > the existing?
>> > Googling "define aggregate" provides...
>> > aggregate (noun) = a whole formed by combining several separate
>> > elements.
>> > aggregate (verb) = form or group into a class or cluster.
>> >
>> > The separate elements are runs defined by the block.
>> > The existing name seems quite precise to me.
>> >
>> > cheers -ben
>>
>> When I read aggregateRuns:, I think the opposite; something combining
>> different runs into a single entity, not something that splits a single
>> collection into constituent runs...
>>
>
okay. I can understand that perspective.


>
>> Something like (split/collect)runsAccordingTo: sounds more descriptive
>> to my
>> ears, at least.
>>
>> Cheers,
>> Henry
>>
>>
>>
> I like groupBy: but in Squeak groupBy: produces a dictionary with unique
> keys ignoring the multiple sequences...
> split already carries the meaning of preserving the sequences, but we have
> to tell to split at a change of value
> Run is also quite explicit...
>
> groupByRuns: / splitRuns:
>

+1
groupByRuns:   is good.

cheers -ben

[Pharo-dev] Does pharo build not retry anymore?

[Guillermo Polito]

I see that we are retrying tests only once, which is causing most (if not
all) pull requests to fail sporadically...

Maybe it got lost because of a mistake?

Also, I'd like that changes in the build process are discussed in the
mailing list from time to time... I've put a lot of effort into making it
work and if we have regressions I'd like to understand them...

Guille

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Linux vm packages

[Marcus Denker]

> On 12 Dec 2017, at 17:32, Cyril Ferlicot  wrote:
> 
> On Tue, Dec 12, 2017 at 5:15 PM, Marcus Denker  wrote:
>> I have added the information to the 64bit download page for now (the other
>> comes next).
>> 
>> http://pharo.org/web/gnu-linux-installation-64
>> 
>> I wonder if we continue to announce a “default download” (the zip) if it is
>> much easier to use these?
>> 
> 
> I am just wondering,
> 
> What if I use zero conf to get my 32bits vm?
> 
> Will I be able to follow the instructions of the page, then dl and use
> a vm via zero conf without installing extra dependencies?
> 

That is the problem: you need to install all the 32bit libraries first.
Same for running what is now called the “default download” 32 bit
on current Linux.

This makes is quite hard to explain…

Marcus

Re: [Pharo-dev] Linux vm packages

[Cyril Ferlicot]

On Tue, Dec 12, 2017 at 5:15 PM, Marcus Denker  wrote:
> I have added the information to the 64bit download page for now (the other
> comes next).
>
> http://pharo.org/web/gnu-linux-installation-64
>
> I wonder if we continue to announce a “default download” (the zip) if it is
> much easier to use these?
>

I am just wondering,

What if I use zero conf to get my 32bits vm?

Will I be able to follow the instructions of the page, then dl and use
a vm via zero conf without installing extra dependencies?



-- 
Cyril Ferlicot
https://ferlicot.fr

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

Re: [Pharo-dev] Linux vm packages

[Marcus Denker]

I have added the information to the 64bit download page for now (the other 
comes next).

http://pharo.org/web/gnu-linux-installation-64 


I wonder if we continue to announce a “default download” (the zip) if it is 
much easier to use these?

> On 27 Nov 2017, at 09:22, Marcus Denker  wrote:
> 
> I can edit the website, I can put al needed infos there.
> 
> (but sometimes I am not be able to generate actions out of discussions on the 
> mailing list,
> there is just so much going on… so if something does not happen this just 
> means I do 
> not know that it should happen…)
> 
>> On 26 Nov 2017, at 13:52, Norbert Hartl > > wrote:
>> 
>> Can we change linux installation instructions on the web site? I can't 
>> believe they aren't there, yet. Here is the description.
>> 
>> http://forum.world.st/Latest-Debian-Ubuntu-and-CentOS-packages-of-the-pharo-vm-td4962000.html
>>  
>> 
>> 
>> This describes what to do for some linux distributions not only ubuntu. In 
>> the mail there are opensuse URLs. The all contain the word "latest" which 
>> means the development version. If this is exchanged with "stable" you get 
>> the stable version. The rest stays the same.
>> 
>> I really should have checked this. Because it is just stupid that people 
>> spend a lot of work into that and it is not used nor published.
>> 
>> If I can help please say so
>> 
>> Norbert
>> 
> 

Re: [Pharo-dev] Do we have this iterator?

[Martin Dias]

If your input was a string instead of a list of lines, you had:

'[^4]*4|.+' asRegex matchesIn: '1234123123456'
>>>
 "an OrderedCollection('1234' '1231234' '56')"

Martín

On Tue, Dec 12, 2017 at 9:33 AM, Stephane Ducasse 
wrote:

> Thanks sean.
> I will build it because for example I had list of lines and I needed
> to split the input depending
> on patterns inside the lines and sadly this was not for an advent of
> code.
>
> Rmoders suggested
> aggregateRuns:
> splitOn:
> but this is not the same.
>
>
> Stef
>
> On Tue, Dec 12, 2017 at 2:33 AM, Sean P. DeNigris 
> wrote:
> > Stephane Ducasse-3 wrote
> >> #(1 2 3 4 1 2 3 5 6 ) consumeUntil: [:each | each = 4)
> > {#(1 2 3 4) . #( 1 2 3 5 6 )}
> >
> > The shortest kernel thing I could come up with took two steps: `{ #(1 2
> 3 4
> > 1 2 3 5 6 ) copyUpThrough: 4.
> > #(1 2 3 4 1 2 3 5 6 ) copyAfter: 4 }`. The splitting messages seem to all
> > eat the separator.
> >
> >
> >
> > -
> > Cheers,
> > Sean
> > --
> > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.
> html
> >
>
>

[Pharo-dev] [Pharo 7.0-dev] Build #377: 20773 - Unused temps in BlockClosure value, value:, value:value:, ...

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #377 was: SUCCESS.

The Pull Request #558 was integrated: "20773 - Unused temps in BlockClosure 
value, value:, value:value:, ..."
Pull request url: https://github.com/pharo-project/pharo/pull/558

Issue Url: https://pharo.fogbugz.com/f/cases/20773
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/377/

[Pharo-dev] [Pharo 7.0-dev] Build #376: 20860-Cursor-webLink-is-initialized-wrongly-and-transparent

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #376 was: FAILURE.

The Pull Request #598 was integrated: 
"20860-Cursor-webLink-is-initialized-wrongly-and-transparent"
Pull request url: https://github.com/pharo-project/pharo/pull/598

Issue Url: https://pharo.fogbugz.com/f/cases/20860
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/376/

Re: [Pharo-dev] better name for #aggregateRuns:

[Cyril Ferlicot]

On Tue, Dec 12, 2017 at 10:23 AM, Pavel Krivanek
 wrote:
> Hi,
>
> do you have some proposals for a better name for the message named
> #aggregateRuns?
>
> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns:  [ :each | each = 4])
> >>> #(#(1 2 3) #(4) #(1 2 3 5 6)).
>
> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns:  [ :each | each = 4])
> >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)).
>
> ((1 to: 12) aggregateRuns:  [ :each | (each \\ 3) = 0])
> >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)).
>
> The current comment is:
> "Answer a new collection of the same species as the
> receiver with elements being collections (of the receiver
> species) containing those elements of the receiver
> for which the given block consecutively evaluates to
> the same object."
>
> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollection-aggregateRuns
>
> Cheers,
> -- Pavel

divideOn:?


-- 
Cyril Ferlicot
https://ferlicot.fr

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

Re: [Pharo-dev] [Pharo-users] [TechTalk] Topics Wanted for 2018!

[Marcus Denker]

Ok!

Pharo TechTalk: Genetic Algorithms
https://association.pharo.org/event-2757884


> On 11 Dec 2017, at 21:56, Alexandre Bergel  wrote:
> 
> Yes!
> 
> Cheers,
> Alexandre
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
>> On Dec 7, 2017, at 10:53 AM, Marcus Denker  wrote:
>> 
>> What about Tuesday 30th Jan?
>> 
>>> On 7 Dec 2017, at 02:06, Alexandre Bergel  wrote:
>>> 
>>> Hi Marcus!
>>> 
>>> Thanks for pushing the community!
>>> If there is a free slot at the end of January, I can do another tech talk 
>>> on AI technique. I am thinking about a lecture on Genetic Algorithm and 
>>> Genetic Programming.
>>> 
>>> Let me know...
>>> 
>>> Alexandre
>>> 
>>> 
 On Dec 1, 2017, at 7:58 AM, Marcus Denker  wrote:
 
 Hi,
 
 As you know, we are trying to have one Pharo tech-talk per month. 
 
 The idea is to use this for
-> mini “Lectures”
-> Demos of interesting Projects
-> Just some interesting topic to discuss with audio chat on Discord
 
 You can see the past topics here:
 
http://pharo.org/TechTalk
 
 We will soon define the dates for the first half of 2018. If you want to 
 do a techtalk
 yourself (give a presentation / Demo or moderate a discussion), feel free 
 to contact
 me! You are able to pick a date that works best for you.
 
 
Marcus
>>> 
>>> 
>> 
>> 
> 

Re: [Pharo-dev] Did the selection in Playground or rubric change?

[Marcus Denker]

Yes, I have it already on my list of things to fix… (not issue tracker entry 
yet, will add one).

Marcus

> On 12 Dec 2017, at 13:52, Stephane Ducasse  wrote:
> 
> just type
> 
> margins: Put the cursor here and press command + M or command + N
> in the past
> margins: was selected and used.
> 
> What you see is that we cannot rely on the AST.
> Now selecting items is boring.
> 
> Stef
> 
> On Tue, Dec 12, 2017 at 1:47 PM, Pavel Krivanek
>  wrote:
>> Hi,
>> 
>> Andrew improved that so it now works on AST and provides better results. If
>> you have some code where it does not work, please try to describe the
>> particular case so we can fix it.
>> 
>> -- Pavel
>> 
>> 2017-12-12 13:31 GMT+01:00 Stephane Ducasse :
>>> 
>>> Hi
>>> 
>>> usually in previous version we could put the cursor on the line and
>>> get senders and implementors without having to select the code.
>>> Now this super cool features does not work anymore.
>>> 
>>> Is it only my image?
>>> 
>>> Stef
>>> 
>> 
> 

Re: [Pharo-dev] How do you merge branches using Iceberg?

[Esteban Lorenzano]

> On 12 Dec 2017, at 14:03, Mariano Martinez Peck  wrote:
> 
> m ok. And let me ask (I don't have another example at hand now to test) 
> ... with metacello integration enabled, would that ALSO reload the packages 
> from git into my image?

no

> or it would only do the git-side of the merge ?

yes

> 
> Thanks in advance, 
> 
> On Tue, Dec 12, 2017 at 9:47 AM, Esteban Lorenzano  > wrote:
> is not very clear, but you can use the history window for that (yeah, it 
> needs to be better, etc., etc.)
> 
> Esteban
> 
> 
>> On 12 Dec 2017, at 13:32, Mariano Martinez Peck > > wrote:
>> 
>> Let's say I have xxx and then I created branch xxx-mariano. Every in a 
>> while, I want to merge latest xxx into my xxx-mariano. I haven't found a way 
>> to do this in Iceberg (I am using 0.6.2 on Pharo 6.1). I had to go to 
>> console, do the git merge there and then from Iceberg I had to "reload all 
>> packages". 
>> 
>> Is there a better way of doing this? 
>> 
>> Thanks,
>> 
>> 
>> -- 
>> Mariano
>> http://marianopeck.wordpress.com 
> 
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com 

Re: [Pharo-dev] Did the selection in Playground or rubric change?

[Pavel Krivanek]

We probably should use a fallback with the old behavior.

-- Pavel

2017-12-12 13:52 GMT+01:00 Stephane Ducasse :

> just type
>
> margins: Put the cursor here and press command + M or command + N
> in the past
> margins: was selected and used.
>
> What you see is that we cannot rely on the AST.
> Now selecting items is boring.
>
> Stef
>
> On Tue, Dec 12, 2017 at 1:47 PM, Pavel Krivanek
>  wrote:
> > Hi,
> >
> > Andrew improved that so it now works on AST and provides better results.
> If
> > you have some code where it does not work, please try to describe the
> > particular case so we can fix it.
> >
> > -- Pavel
> >
> > 2017-12-12 13:31 GMT+01:00 Stephane Ducasse :
> >>
> >> Hi
> >>
> >> usually in previous version we could put the cursor on the line and
> >> get senders and implementors without having to select the code.
> >> Now this super cool features does not work anymore.
> >>
> >> Is it only my image?
> >>
> >> Stef
> >>
> >
>
>

Re: [Pharo-dev] How do you merge branches using Iceberg?

[Mariano Martinez Peck]

m ok. And let me ask (I don't have another example at hand now to test)
... with metacello integration enabled, would that ALSO reload the packages
from git into my image? or it would only do the git-side of the merge ?

Thanks in advance,

On Tue, Dec 12, 2017 at 9:47 AM, Esteban Lorenzano 
wrote:

> is not very clear, but you can use the history window for that (yeah, it
> needs to be better, etc., etc.)
>
> Esteban
>
>
> On 12 Dec 2017, at 13:32, Mariano Martinez Peck 
> wrote:
>
> Let's say I have xxx and then I created branch xxx-mariano. Every in a
> while, I want to merge latest xxx into my xxx-mariano. I haven't found a
> way to do this in Iceberg (I am using 0.6.2 on Pharo 6.1). I had to go to
> console, do the git merge there and then from Iceberg I had to "reload all
> packages".
>
> Is there a better way of doing this?
>
> Thanks,
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-dev] Did the selection in Playground or rubric change?

[Stephane Ducasse]

just type

margins: Put the cursor here and press command + M or command + N
in the past
margins: was selected and used.

What you see is that we cannot rely on the AST.
Now selecting items is boring.

Stef

On Tue, Dec 12, 2017 at 1:47 PM, Pavel Krivanek
 wrote:
> Hi,
>
> Andrew improved that so it now works on AST and provides better results. If
> you have some code where it does not work, please try to describe the
> particular case so we can fix it.
>
> -- Pavel
>
> 2017-12-12 13:31 GMT+01:00 Stephane Ducasse :
>>
>> Hi
>>
>> usually in previous version we could put the cursor on the line and
>> get senders and implementors without having to select the code.
>> Now this super cool features does not work anymore.
>>
>> Is it only my image?
>>
>> Stef
>>
>

Re: [Pharo-dev] [Ann] New Calypso version 0.8

[Denis Kudriashov]

2017-12-12 13:25 GMT+01:00 Mariano Martinez Peck :

> Hi Denis,
>
> Congratulations on the new release! Two quick question:
>


> 1) does this work on latest Pharo 6.1 ;
>

Yes


> 2) Is it safe to update images with Calypso already installed by doing the
> same baseline loading as the original installation ?
>

I think not. But I not try. I just have impression that complex updates are
not properly work in Pharo. All package structure is changed and it can be
a problem for such update.


>
> Thanks
>
> On Tue, Dec 12, 2017 at 9:05 AM, Denis Kudriashov 
> wrote:
>
>> Hello.
>>
>> I glad announce new Calypso version. It is a big refactoring on
>> navigation model and browser pluggability.
>>
>> Look for details in my blog http://dionisiydk.blogspot.fr/
>> 2017/12/new-calypso-version-08-is-out.html.
>>
>> Now I start document new design and will post progress on it.
>>
>> Notice: this version is not adopted for TelePharo and Cargo. It will be
>> done soon.
>>
>> Best regards,
>> Denis
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

Re: [Pharo-dev] Did the selection in Playground or rubric change?

[Pavel Krivanek]

Hi,

Andrew improved that so it now works on AST and provides better results. If
you have some code where it does not work, please try to describe the
particular case so we can fix it.

-- Pavel

2017-12-12 13:31 GMT+01:00 Stephane Ducasse :

> Hi
>
> usually in previous version we could put the cursor on the line and
> get senders and implementors without having to select the code.
> Now this super cool features does not work anymore.
>
> Is it only my image?
>
> Stef
>
>

Re: [Pharo-dev] How do you merge branches using Iceberg?

[Esteban Lorenzano]

is not very clear, but you can use the history window for that (yeah, it needs 
to be better, etc., etc.)

Esteban

> On 12 Dec 2017, at 13:32, Mariano Martinez Peck  wrote:
> 
> Let's say I have xxx and then I created branch xxx-mariano. Every in a while, 
> I want to merge latest xxx into my xxx-mariano. I haven't found a way to do 
> this in Iceberg (I am using 0.6.2 on Pharo 6.1). I had to go to console, do 
> the git merge there and then from Iceberg I had to "reload all packages". 
> 
> Is there a better way of doing this? 
> 
> Thanks,
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com 

Re: [Pharo-dev] Do we have this iterator?

[Stephane Ducasse]

Thanks sean.
I will build it because for example I had list of lines and I needed
to split the input depending
on patterns inside the lines and sadly this was not for an advent of code.

Rmoders suggested
aggregateRuns:
splitOn:
but this is not the same.


Stef

On Tue, Dec 12, 2017 at 2:33 AM, Sean P. DeNigris  wrote:
> Stephane Ducasse-3 wrote
>> #(1 2 3 4 1 2 3 5 6 ) consumeUntil: [:each | each = 4)
> {#(1 2 3 4) . #( 1 2 3 5 6 )}
>
> The shortest kernel thing I could come up with took two steps: `{ #(1 2 3 4
> 1 2 3 5 6 ) copyUpThrough: 4.
> #(1 2 3 4 1 2 3 5 6 ) copyAfter: 4 }`. The splitting messages seem to all
> eat the separator.
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

[Pharo-dev] How do you merge branches using Iceberg?

[Mariano Martinez Peck]

Let's say I have xxx and then I created branch xxx-mariano. Every in a
while, I want to merge latest xxx into my xxx-mariano. I haven't found a
way to do this in Iceberg (I am using 0.6.2 on Pharo 6.1). I had to go to
console, do the git merge there and then from Iceberg I had to "reload all
packages".

Is there a better way of doing this?

Thanks,


-- 
Mariano
http://marianopeck.wordpress.com

[Pharo-dev] Did the selection in Playground or rubric change?

[Stephane Ducasse]

Hi

usually in previous version we could put the cursor on the line and
get senders and implementors without having to select the code.
Now this super cool features does not work anymore.

Is it only my image?

Stef

Re: [Pharo-dev] [Ann] New Calypso version 0.8

[Mariano Martinez Peck]

Hi Denis,

Congratulations on the new release! Two quick question: 1) does this work
on latest Pharo 6.1 ; 2) Is it safe to update images with Calypso already
installed by doing the same baseline loading as the original installation ?

Thanks

On Tue, Dec 12, 2017 at 9:05 AM, Denis Kudriashov 
wrote:

> Hello.
>
> I glad announce new Calypso version. It is a big refactoring on navigation
> model and browser pluggability.
>
> Look for details in my blog http://dionisiydk.blogspot.fr/
> 2017/12/new-calypso-version-08-is-out.html.
>
> Now I start document new design and will post progress on it.
>
> Notice: this version is not adopted for TelePharo and Cargo. It will be
> done soon.
>
> Best regards,
> Denis
>



-- 
Mariano
http://marianopeck.wordpress.com

[Pharo-dev] [Ann] New Calypso version 0.8

[Denis Kudriashov]

Hello.

I glad announce new Calypso version. It is a big refactoring on navigation
model and browser pluggability.

Look for details in my blog
http://dionisiydk.blogspot.fr/2017/12/new-calypso-version-08-is-out.html.

Now I start document new design and will post progress on it.

Notice: this version is not adopted for TelePharo and Cargo. It will be
done soon.

Best regards,
Denis

Re: [Pharo-dev] better name for #aggregateRuns:

[Nicolas Cellier]

2017-12-12 13:01 GMT+01:00 Henrik Sperre Johansen <
henrik.s.johan...@veloxit.no>:

> Ben Coman wrote
> >
> > But after pondering a while for a better name, I wonder what is wrong
> with
> > the existing?
> > Googling "define aggregate" provides...
> > aggregate (noun) = a whole formed by combining several separate
> > elements.
> > aggregate (verb) = form or group into a class or cluster.
> >
> > The separate elements are runs defined by the block.
> > The existing name seems quite precise to me.
> >
> > cheers -ben
>
> When I read aggregateRuns:, I think the opposite; something combining
> different runs into a single entity, not something that splits a single
> collection into constituent runs...
>
> Something like (split/collect)runsAccordingTo: sounds more descriptive to
> my
> ears, at least.
>
> Cheers,
> Henry
>
>
>
I like groupBy: but in Squeak groupBy: produces a dictionary with unique
keys ignoring the multiple sequences...
split already carries the meaning of preserving the sequences, but we have
to tell to split at a change of value
Run is also quite explicit...

groupByRuns: / splitRuns:


> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] better name for #aggregateRuns:

[Henrik Sperre Johansen]

Ben Coman wrote
> 
> But after pondering a while for a better name, I wonder what is wrong with
> the existing?
> Googling "define aggregate" provides...
> aggregate (noun) = a whole formed by combining several separate
> elements.
> aggregate (verb) = form or group into a class or cluster.
> 
> The separate elements are runs defined by the block.
> The existing name seems quite precise to me.
> 
> cheers -ben

When I read aggregateRuns:, I think the opposite; something combining
different runs into a single entity, not something that splits a single
collection into constituent runs...

Something like (split/collect)runsAccordingTo: sounds more descriptive to my
ears, at least.

Cheers,
Henry



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] better name for #aggregateRuns:

[Ben Coman]

On 12 December 2017 at 17:23, Pavel Krivanek 
wrote:

> Hi,
>
> do you have some proposals for a better name for the message named
> #aggregateRuns?
>
> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns:  [ :each | each = 4])
> >>> #(#(1 2 3) #(4) #(1 2 3 5 6)).
>
> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns:  [ :each | each = 4])
> >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)).
>
> ((1 to: 12) aggregateRuns:  [ :each | (each \\ 3) = 0])
> >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)).
>
> The current comment is:
> "Answer a new collection of the same species as the
> receiver with elements being collections (of the receiver
> species) containing those elements of the receiver
> for which the given block consecutively evaluates to
> the same object."
>
> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-
> SequenceableCollection-aggregateRuns
>
>
Split is almost an obvious choice, except I feel the same as Norbert
that "split
methods operate on separators which are not included in the result."
Maybe "groupSomethingXXX"...

But after pondering a while for a better name, I wonder what is wrong with
the existing?
Googling "define aggregate" provides...
aggregate (noun) = a whole formed by combining several separate
elements.
aggregate (verb) = form or group into a class or cluster.

The separate elements are runs defined by the block.
The existing name seems quite precise to me.

cheers -ben

Re: [Pharo-dev] better name for #aggregateRuns:

[Norbert Hartl]

Sorry, I’m not sure what I’ve read but it does not seem to be the mail of Pavel 
:)

Norbert


> Am 12.12.2017 um 11:05 schrieb Norbert Hartl :
> 
> For me split methods operate on separators which are not included in the 
> result. So name it splitXXX might not be the best idea. And I think it should 
> be more explicit. When the matching elements are included in the result it 
> needs to indicate where the are added. So it is rather something like 
> 
> xxxAfter: 
> 
> because the collection is separated after the matching element. What the 
> method does is oppositional to flattenXXX. So if we would have the opposite 
> term of flatten that might be a good candidate. Then it would be something 
> like
> 
> roughenAfter:
> 
> :) Ok, stupid name but you got the idea.
> 
> Norbert
> 
> 
> 
> 
> 
>> Am 12.12.2017 um 10:50 schrieb Sven Van Caekenberghe :
>> 
>> #splitWhile: because the block does not define separators but its value 
>> indicates runs ?
>> 
>>> On 12 Dec 2017, at 10:34, Thomas Dupriez 
>>>  wrote:
>>> 
>>> #(1 2 3 4 1 2 3 5 6 ) splitWhen:  [ :each | each = 4]
>>> 
>>> 
>>> Le 12/12/2017 à 10:23, Pavel Krivanek a écrit :
 Hi,
 
 do you have some proposals for a better name for the message named 
 #aggregateRuns?
 
 (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns:  [ :each | each = 4])
>>> #(#(1 2 3) #(4) #(1 2 3 5 6)).
 
 (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns:  [ :each | each = 4])
>>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)).
 
 ((1 to: 12) aggregateRuns:  [ :each | (each \\ 3) = 0])
>>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)).
 
 The current comment is:
 "Answer a new collection of the same species as the
 receiver with elements being collections (of the receiver
 species) containing those elements of the receiver
 for which the given block consecutively evaluates to
 the same object."
 
 https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollection-aggregateRuns
 
 Cheers,
 -- Pavel
>>> 
>>> 

Re: [Pharo-dev] better name for #aggregateRuns:

[Pavel Krivanek]

If short names not work, what about to use something more descriptive like
#splitToGroupsThatAlternatelySafisfy:

-- Pavel

2017-12-12 10:23 GMT+01:00 Pavel Krivanek :

> Hi,
>
> do you have some proposals for a better name for the message named
> #aggregateRuns?
>
> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns:  [ :each | each = 4])
> >>> #(#(1 2 3) #(4) #(1 2 3 5 6)).
>
> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns:  [ :each | each = 4])
> >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)).
>
> ((1 to: 12) aggregateRuns:  [ :each | (each \\ 3) = 0])
> >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)).
>
> The current comment is:
> "Answer a new collection of the same species as the
> receiver with elements being collections (of the receiver
> species) containing those elements of the receiver
> for which the given block consecutively evaluates to
> the same object."
>
> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-
> SequenceableCollection-aggregateRuns
>
> Cheers,
> -- Pavel
>

Re: [Pharo-dev] better name for #aggregateRuns:

[Thomas Dupriez]

Oups, spoke too fast. My bad.

I mean that I don't really see a 'matching element' here, it's more that 
the collection is cut whenever the block given as argument evaluates to 
a different value.



Le 12/12/2017 à 11:11, Thomas Dupriez a écrit :
Hm, aggregateRuns: separates the collection both after and before the 
separator.


#(1 2 3 4 1 2 4 5 6 ) aggregateRuns:  [ :each | each = 4]

->    #(#(1 2 3) #(4) #(1 2) #(4) #(5 6))


Le 12/12/2017 à 11:05, Norbert Hartl a écrit :
For me split methods operate on separators which are not included in 
the result. So name it splitXXX might not be the best idea. And I 
think it should be more explicit. When the matching elements are 
included in the result it needs to indicate where the are added. So 
it is rather something like


xxxAfter:

because the collection is separated after the matching element. What 
the method does is oppositional to flattenXXX. So if we would have 
the opposite term of flatten that might be a good candidate. Then it 
would be something like


roughenAfter:

:) Ok, stupid name but you got the idea.

Norbert






Am 12.12.2017 um 10:50 schrieb Sven Van Caekenberghe :

#splitWhile: because the block does not define separators but its 
value indicates runs ?


On 12 Dec 2017, at 10:34, Thomas Dupriez 
 wrote:


#(1 2 3 4 1 2 3 5 6 ) splitWhen:  [ :each | each = 4]


Le 12/12/2017 à 10:23, Pavel Krivanek a écrit :

Hi,

do you have some proposals for a better name for the message named 
#aggregateRuns?


(#(1 2 3 4 1 2 3 5 6 ) aggregateRuns:  [ :each | each = 4])

#(#(1 2 3) #(4) #(1 2 3 5 6)).

(#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns:  [ :each | each = 4])

#(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)).

((1 to: 12) aggregateRuns:  [ :each | (each \\ 3) = 0])

#(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)).

The current comment is:
"Answer a new collection of the same species as the
receiver with elements being collections (of the receiver
species) containing those elements of the receiver
for which the given block consecutively evaluates to
the same object."

https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollection-aggregateRuns 



Cheers,
-- Pavel

Re: [Pharo-dev] better name for #aggregateRuns:

[Thomas Dupriez]

Hm, aggregateRuns: separates the collection both after and before the 
separator.


#(1 2 3 4 1 2 4 5 6 ) aggregateRuns:  [ :each | each = 4]

->    #(#(1 2 3) #(4) #(1 2) #(4) #(5 6))


Le 12/12/2017 à 11:05, Norbert Hartl a écrit :

For me split methods operate on separators which are not included in the 
result. So name it splitXXX might not be the best idea. And I think it should 
be more explicit. When the matching elements are included in the result it 
needs to indicate where the are added. So it is rather something like

xxxAfter:

because the collection is separated after the matching element. What the method 
does is oppositional to flattenXXX. So if we would have the opposite term of 
flatten that might be a good candidate. Then it would be something like

roughenAfter:

:) Ok, stupid name but you got the idea.

Norbert






Am 12.12.2017 um 10:50 schrieb Sven Van Caekenberghe :

#splitWhile: because the block does not define separators but its value 
indicates runs ?


On 12 Dec 2017, at 10:34, Thomas Dupriez  
wrote:

#(1 2 3 4 1 2 3 5 6 ) splitWhen:  [ :each | each = 4]


Le 12/12/2017 à 10:23, Pavel Krivanek a écrit :

Hi,

do you have some proposals for a better name for the message named 
#aggregateRuns?

(#(1 2 3 4 1 2 3 5 6 ) aggregateRuns:  [ :each | each = 4])

#(#(1 2 3) #(4) #(1 2 3 5 6)).

(#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns:  [ :each | each = 4])

#(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)).

((1 to: 12) aggregateRuns:  [ :each | (each \\ 3) = 0])

#(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)).

The current comment is:
"Answer a new collection of the same species as the
receiver with elements being collections (of the receiver
species) containing those elements of the receiver
for which the given block consecutively evaluates to
the same object."

https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollection-aggregateRuns

Cheers,
-- Pavel

Re: [Pharo-dev] better name for #aggregateRuns:

[Norbert Hartl]

For me split methods operate on separators which are not included in the 
result. So name it splitXXX might not be the best idea. And I think it should 
be more explicit. When the matching elements are included in the result it 
needs to indicate where the are added. So it is rather something like 

xxxAfter: 

because the collection is separated after the matching element. What the method 
does is oppositional to flattenXXX. So if we would have the opposite term of 
flatten that might be a good candidate. Then it would be something like

roughenAfter:

:) Ok, stupid name but you got the idea.

Norbert





> Am 12.12.2017 um 10:50 schrieb Sven Van Caekenberghe :
> 
> #splitWhile: because the block does not define separators but its value 
> indicates runs ?
> 
>> On 12 Dec 2017, at 10:34, Thomas Dupriez 
>>  wrote:
>> 
>> #(1 2 3 4 1 2 3 5 6 ) splitWhen:  [ :each | each = 4]
>> 
>> 
>> Le 12/12/2017 à 10:23, Pavel Krivanek a écrit :
>>> Hi,
>>> 
>>> do you have some proposals for a better name for the message named 
>>> #aggregateRuns?
>>> 
>>> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns:  [ :each | each = 4])
>> #(#(1 2 3) #(4) #(1 2 3 5 6)).
>>> 
>>> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns:  [ :each | each = 4])
>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)).
>>> 
>>> ((1 to: 12) aggregateRuns:  [ :each | (each \\ 3) = 0])
>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)).
>>> 
>>> The current comment is:
>>> "Answer a new collection of the same species as the
>>> receiver with elements being collections (of the receiver
>>> species) containing those elements of the receiver
>>> for which the given block consecutively evaluates to
>>> the same object."
>>> 
>>> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollection-aggregateRuns
>>> 
>>> Cheers,
>>> -- Pavel
>> 
>> 

Re: [Pharo-dev] better name for #aggregateRuns:

[Thomas Dupriez]

#splitByGroupingWhile:

The 'split' indicates it's a method to split a collection, and the 
'GroupingWhile' expresses how it's done: by grouping elements while they 
make the block evaluate to the same value.


Le 12/12/2017 à 10:50, Sven Van Caekenberghe a écrit :

#splitWhile: because the block does not define separators but its value 
indicates runs ?


On 12 Dec 2017, at 10:34, Thomas Dupriez  
wrote:

#(1 2 3 4 1 2 3 5 6 ) splitWhen:  [ :each | each = 4]


Le 12/12/2017 à 10:23, Pavel Krivanek a écrit :

Hi,

do you have some proposals for a better name for the message named 
#aggregateRuns?

(#(1 2 3 4 1 2 3 5 6 ) aggregateRuns:  [ :each | each = 4])
 >>> #(#(1 2 3) #(4) #(1 2 3 5 6)).

(#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns:  [ :each | each = 4])
 >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)).

((1 to: 12) aggregateRuns:  [ :each | (each \\ 3) = 0])
 >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)).

The current comment is:
"Answer a new collection of the same species as the
receiver with elements being collections (of the receiver
species) containing those elements of the receiver
for which the given block consecutively evaluates to
the same object."

https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollection-aggregateRuns

Cheers,
-- Pavel

Re: [Pharo-dev] better name for #aggregateRuns:

[Sven Van Caekenberghe]

#splitWhile: because the block does not define separators but its value 
indicates runs ?

> On 12 Dec 2017, at 10:34, Thomas Dupriez  
> wrote:
> 
> #(1 2 3 4 1 2 3 5 6 ) splitWhen:  [ :each | each = 4]
> 
> 
> Le 12/12/2017 à 10:23, Pavel Krivanek a écrit :
>> Hi,
>> 
>> do you have some proposals for a better name for the message named 
>> #aggregateRuns?
>> 
>> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns:  [ :each | each = 4])
>> >>> #(#(1 2 3) #(4) #(1 2 3 5 6)).
>> 
>> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns:  [ :each | each = 4])
>> >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)).
>> 
>> ((1 to: 12) aggregateRuns:  [ :each | (each \\ 3) = 0])
>> >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)).
>> 
>> The current comment is:
>> "Answer a new collection of the same species as the
>> receiver with elements being collections (of the receiver
>> species) containing those elements of the receiver
>> for which the given block consecutively evaluates to
>> the same object."
>> 
>> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollection-aggregateRuns
>> 
>> Cheers,
>> -- Pavel
> 
> 

Re: [Pharo-dev] better name for #aggregateRuns:

[Pavel Krivanek]

maybe something in the direction of splitOnThresholds:?

2017-12-12 10:38 GMT+01:00 Pavel Krivanek :

> We already have #splitOn: with slightly different behavior:
>
> (#(1 2 3 4 1 2 3 5 6 ) splitOn:  [ :each | each = 4])
>
> So splitOnEach: and splitWhen: would be probably confusing
>
> 2017-12-12 10:34 GMT+01:00 Thomas Dupriez  saclay.fr>:
>
>> #(1 2 3 4 1 2 3 5 6 ) splitWhen:  [ :each | each = 4]
>>
>>
>>
>> Le 12/12/2017 à 10:23, Pavel Krivanek a écrit :
>>
>>> Hi,
>>>
>>> do you have some proposals for a better name for the message named
>>> #aggregateRuns?
>>>
>>> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns:  [ :each | each = 4])
>>> >>> #(#(1 2 3) #(4) #(1 2 3 5 6)).
>>>
>>> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns:  [ :each | each = 4])
>>> >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)).
>>>
>>> ((1 to: 12) aggregateRuns:  [ :each | (each \\ 3) = 0])
>>> >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)).
>>>
>>> The current comment is:
>>> "Answer a new collection of the same species as the
>>> receiver with elements being collections (of the receiver
>>> species) containing those elements of the receiver
>>> for which the given block consecutively evaluates to
>>> the same object."
>>>
>>> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-Sequ
>>> enceableCollection-aggregateRuns
>>>
>>> Cheers,
>>> -- Pavel
>>>
>>
>>
>>
>

Re: [Pharo-dev] better name for #aggregateRuns:

[Pavel Krivanek]

We already have #splitOn: with slightly different behavior:

(#(1 2 3 4 1 2 3 5 6 ) splitOn:  [ :each | each = 4])

So splitOnEach: and splitWhen: would be probably confusing

2017-12-12 10:34 GMT+01:00 Thomas Dupriez <
thomas.dupr...@ens-paris-saclay.fr>:

> #(1 2 3 4 1 2 3 5 6 ) splitWhen:  [ :each | each = 4]
>
>
>
> Le 12/12/2017 à 10:23, Pavel Krivanek a écrit :
>
>> Hi,
>>
>> do you have some proposals for a better name for the message named
>> #aggregateRuns?
>>
>> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns:  [ :each | each = 4])
>> >>> #(#(1 2 3) #(4) #(1 2 3 5 6)).
>>
>> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns:  [ :each | each = 4])
>> >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)).
>>
>> ((1 to: 12) aggregateRuns:  [ :each | (each \\ 3) = 0])
>> >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)).
>>
>> The current comment is:
>> "Answer a new collection of the same species as the
>> receiver with elements being collections (of the receiver
>> species) containing those elements of the receiver
>> for which the given block consecutively evaluates to
>> the same object."
>>
>> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-Sequ
>> enceableCollection-aggregateRuns
>>
>> Cheers,
>> -- Pavel
>>
>
>
>

Re: [Pharo-dev] better name for #aggregateRuns:

[Thomas Dupriez]

#(1 2 3 4 1 2 3 5 6 ) splitWhen:  [ :each | each = 4]


Le 12/12/2017 à 10:23, Pavel Krivanek a écrit :

Hi,

do you have some proposals for a better name for the message named 
#aggregateRuns?


(#(1 2 3 4 1 2 3 5 6 ) aggregateRuns:  [ :each | each = 4])
    >>> #(#(1 2 3) #(4) #(1 2 3 5 6)).

(#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns:  [ :each | each = 4])
    >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)).

((1 to: 12) aggregateRuns:  [ :each | (each \\ 3) = 0])
    >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)).

The current comment is:
"Answer a new collection of the same species as the
receiver with elements being collections (of the receiver
species) containing those elements of the receiver
for which the given block consecutively evaluates to
the same object."

https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollection-aggregateRuns

Cheers,
-- Pavel

Re: [Pharo-dev] better name for #aggregateRuns:

[Denis Kudriashov]

Hi

#(1 2 3 4 1 2 3 5 6 ) collectGroupsWhere:  [ :each | each = 4])

2017-12-12 10:23 GMT+01:00 Pavel Krivanek :

> Hi,
>
> do you have some proposals for a better name for the message named
> #aggregateRuns?
>
> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns:  [ :each | each = 4])
> >>> #(#(1 2 3) #(4) #(1 2 3 5 6)).
>
> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns:  [ :each | each = 4])
> >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)).
>
> ((1 to: 12) aggregateRuns:  [ :each | (each \\ 3) = 0])
> >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)).
>
> The current comment is:
> "Answer a new collection of the same species as the
> receiver with elements being collections (of the receiver
> species) containing those elements of the receiver
> for which the given block consecutively evaluates to
> the same object."
>
> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-
> SequenceableCollection-aggregateRuns
>
> Cheers,
> -- Pavel
>

Re: [Pharo-dev] better name for #aggregateRuns:

[Alistair Grant]

Hi Pavel,

On 12 December 2017 at 10:23, Pavel Krivanek  wrote:
> Hi,
>
> do you have some proposals for a better name for the message named
> #aggregateRuns?
>
> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns:  [ :each | each = 4])
> >>> #(#(1 2 3) #(4) #(1 2 3 5 6)).
>
> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns:  [ :each | each = 4])
> >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)).
>
> ((1 to: 12) aggregateRuns:  [ :each | (each \\ 3) = 0])
> >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)).
>
> The current comment is:
> "Answer a new collection of the same species as the
> receiver with elements being collections (of the receiver
> species) containing those elements of the receiver
> for which the given block consecutively evaluates to
> the same object."
>
> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollection-aggregateRuns
>
> Cheers,
> -- Pavel

#groupAround:
#selectAround:

Cheers,
Alistair

[Pharo-dev] better name for #aggregateRuns:

[Pavel Krivanek]

Hi,

do you have some proposals for a better name for the message named
#aggregateRuns?

(#(1 2 3 4 1 2 3 5 6 ) aggregateRuns:  [ :each | each = 4])
>>> #(#(1 2 3) #(4) #(1 2 3 5 6)).

(#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns:  [ :each | each = 4])
>>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)).

((1 to: 12) aggregateRuns:  [ :each | (each \\ 3) = 0])
>>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)).

The current comment is:
"Answer a new collection of the same species as the
receiver with elements being collections (of the receiver
species) containing those elements of the receiver
for which the given block consecutively evaluates to
the same object."

https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollection-aggregateRuns

Cheers,
-- Pavel

Re: [Pharo-dev] loading from github changes lgit classes?

[Denis Kudriashov]

2017-12-12 8:52 GMT+01:00 Andrei Chis :

> I think this was added because on windows if we did not rebuild accessors,
> some offsets were nil in external structures. Can that still be an issue?
>

Not only Windows. Problem was in Pharo 6 where external OSWindow not worked
because of nil offsets. And Bloc solved it by manual initialisation after
loading code.


>
> Cheers,
> Andrei
>
> On Tue, Dec 12, 2017 at 7:39 AM, Esteban Lorenzano 
> wrote:
>
>>
>>
>> On 12 Dec 2017, at 04:29, Martin Dias  wrote:
>>
>> Should the rebuild changes be logged?
>> Maybe we can have EpMonitor suspendDuring: […]
>>
>>
>> no they not.
>> what should be suspended is field regeneration on bloc config ;)
>>
>> Esteban
>>
>>
>> Martín
>>
>> On Mon, Dec 11, 2017 at 6:42 PM, Nicolai Hess 
>> wrote:
>>
>>> :) This looks interesting:
>>>
>>> So, postload of bloc and some classes (MozEnum, SpartaCairoEnum) doing a
>>> rebuild with this author.
>>>
>>> 2017-12-11 22:27 GMT+01:00 Esteban Lorenzano :
>>>
 honestly, this should not be happening.
 Now, I have no idea why it is happening at all ;)

 I mean, there is no automatic process that would have a UFFI name there
 (the only place where this can happen is on #rebuildFieldAccessors and that
 will use an UFFIGenerator author, not just UFFI.
 And also that method needs to be executed by hand…

 weird… can you search for UFFI in system?

 Esteban

 On 11 Dec 2017, at 22:00, Nicolai Hess  wrote:

 It happens not only from lgit-classes but from other FFI-Subclasses
 too, for example AthensCairoMatrix.

 And some methods have a strange version history (see screenshot).
 The timestamp of all of the UFFI changes are during loading gtoolkit.
 Maybe during loading we have multiple reinitializations that will
 recreate autogenerated methods, again and again ?

 2017-12-11 21:49 GMT+01:00 Nicolai Hess :

> But these aren't method changes.
> The class definition is changed. (see screenshot)
> It looks like it adds new class variables, even though they were
> alreday in the original fresh image.
>
>
> 2017-12-11 13:49 GMT+01:00 Max Leske :
>
>> Without taking a closer look, those are probably auto generated
>> methods.
>>
>> Max
>>
>>
>>
>> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaih...@gmail.com)
>> wrote:
>>
>> How come, loading a github project writes strange code change entries
>> for classes
>> like
>> LGitFetchOptions
>> LGitRemoteCallbacks
>> ...
>>
>> For example, in a Pharo 6.1 image I load bloc like this:
>>
>> Metacello new
>> baseline: 'Bloc';
>> repository: 'github://pharo-graphics/Bloc:pharo6.1/src';
>> load: #core
>>
>> In my Epicea code change window I see this entries (see screenshot).
>> And the final "new" version of this classes, (class definitions) just
>> look like the
>> original class definition in a fresh image.
>>
>>
>>
>
 



>>>
>>
>>
>

Re: [Pharo-dev] loading from github changes lgit classes?

[Esteban Lorenzano]

> On 12 Dec 2017, at 08:52, Andrei Chis  wrote:
> 
> I think this was added because on windows if we did not rebuild accessors, 
> some offsets were nil in external structures. Can that still be an issue?

it should not.
and even if that’s the case, you do not need to regenerate accessors: executing 
#compileFields instead #rebuildFieldAccessors should solve any initialisation 
problems without actually regenerate all structures, which is what you are 
doing :)

Esteban

> 
> Cheers,
> Andrei
> 
> On Tue, Dec 12, 2017 at 7:39 AM, Esteban Lorenzano  > wrote:
> 
> 
>> On 12 Dec 2017, at 04:29, Martin Dias > > wrote:
>> 
>> Should the rebuild changes be logged?
>> Maybe we can have EpMonitor suspendDuring: […]
> 
> no they not. 
> what should be suspended is field regeneration on bloc config ;)
> 
> Esteban
> 
>> 
>> Martín
>> 
>> On Mon, Dec 11, 2017 at 6:42 PM, Nicolai Hess > > wrote:
>> :) This looks interesting:
>> 
>> So, postload of bloc and some classes (MozEnum, SpartaCairoEnum) doing a 
>> rebuild with this author.
>> 
>> 2017-12-11 22:27 GMT+01:00 Esteban Lorenzano > >:
>> honestly, this should not be happening. 
>> Now, I have no idea why it is happening at all ;)
>> 
>> I mean, there is no automatic process that would have a UFFI name there (the 
>> only place where this can happen is on #rebuildFieldAccessors and that will 
>> use an UFFIGenerator author, not just UFFI. 
>> And also that method needs to be executed by hand… 
>> 
>> weird… can you search for UFFI in system?
>> 
>> Esteban
>> 
>>> On 11 Dec 2017, at 22:00, Nicolai Hess >> > wrote:
>>> 
>>> It happens not only from lgit-classes but from other FFI-Subclasses too, 
>>> for example AthensCairoMatrix.
>>> 
>>> And some methods have a strange version history (see screenshot).
>>> The timestamp of all of the UFFI changes are during loading gtoolkit.
>>> Maybe during loading we have multiple reinitializations that will recreate 
>>> autogenerated methods, again and again ?
>>> 
>>> 2017-12-11 21:49 GMT+01:00 Nicolai Hess >> >:
>>> But these aren't method changes.
>>> The class definition is changed. (see screenshot)
>>> It looks like it adds new class variables, even though they were alreday in 
>>> the original fresh image.
>>> 
>>> 
>>> 2017-12-11 13:49 GMT+01:00 Max Leske >> >:
>>> Without taking a closer look, those are probably auto generated methods.
>>> 
>>> Max
>>> 
>>>  
>>> 
>>> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaih...@gmail.com 
>>> ) wrote:
>>> 
 How come, loading a github project writes strange code change entries for 
 classes
 like
 LGitFetchOptions
 LGitRemoteCallbacks
 ...
 
 For example, in a Pharo 6.1 image I load bloc like this:
 
 Metacello new
 baseline: 'Bloc';
 repository: 'github://pharo-graphics/Bloc: <>pharo6.1/src';
 load: #core
 
 In my Epicea code change window I see this entries (see screenshot).
 And the final "new" version of this classes, (class definitions) just look 
 like the
 original class definition in a fresh image.
 
 
>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
>