[Pharo-dev] [pharo-project/pharo-core] eaac18: 60030

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: eaac18e0a2053591d14e561dc7c0df244ee82296
  
https://github.com/pharo-project/pharo-core/commit/eaac18e0a2053591d14e561dc7c0df244ee82296
  Author: Jenkins Build Server 
  Date:   2016-05-24 (Tue, 24 May 2016)

  Changed paths:
R Morphic-Widgets-Windows.package/WindowActivated.class/instance/as yet 
unclassified/isActivated.st
A 
Morphic-Widgets-Windows.package/WindowActivated.class/instance/testing/isActivated.st
R Morphic-Widgets-Windows.package/WindowAnnouncement.class/instance/as yet 
unclassified/isActivated.st
R Morphic-Widgets-Windows.package/WindowAnnouncement.class/instance/as yet 
unclassified/isDeActivated.st
A 
Morphic-Widgets-Windows.package/WindowAnnouncement.class/instance/testing/isActivated.st
A 
Morphic-Widgets-Windows.package/WindowAnnouncement.class/instance/testing/isDeActivated.st
R Morphic-Widgets-Windows.package/WindowCollapsed.class/instance/as yet 
unclassified/isCollapsed.st
A 
Morphic-Widgets-Windows.package/WindowCollapsed.class/instance/testing/isCollapsed.st
R Morphic-Widgets-Windows.package/WindowDeActivated.class/instance/as yet 
unclassified/isDeActivated.st
A 
Morphic-Widgets-Windows.package/WindowDeActivated.class/instance/testing/isDeActivated.st
R Morphic-Widgets-Windows.package/WindowExpanded.class/instance/as yet 
unclassified/isExpanded.st
A 
Morphic-Widgets-Windows.package/WindowExpanded.class/instance/testing/isExpanded.st
M 
NautilusRefactoring.package/NautilusRefactoring.class/instance/source/splitCascadeBetween_from_.st
M Refactoring-Core.package/RBSplitCascadeRefactoring.class/README.md
M 
Refactoring-Environment.package/RBBrowserEnvironment.class/instance/accessing-classes/allClasses.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60029.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60030.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60029.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60030.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  60030
18296 DNU on split cascade refactoring
https://pharo.fogbugz.com/f/cases/18296

18298 duplicate elements in RBClassEnvironments result set
https://pharo.fogbugz.com/f/cases/18298

18314 wrong or missing metho protokoll name for WindowAnnouncements
https://pharo.fogbugz.com/f/cases/18314

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

Re: [Pharo-dev] What's new in Pharo 5.0

[Marcus Denker]

> On 24 May 2016, at 07:41, Sven Van Caekenberghe  wrote:
> 
> 
>> On 24 May 2016, at 03:37, Sean P. DeNigris  wrote:
>> 
>> Sean P. DeNigris wrote
>>> Is there a more complete description than the announcement?
>> 
>> I should've mentioned that I did see the link to the bugtracker, but I'm
>> looking for some middle ground between the 5 bullet points in the
>> announcement and the 2400+ issues tagged for Pharo 5.0
> 
> It is our fault that such a list does not exist, but it is really, really 
> hard to make it, since no one knows everything. It is also a huge amount of 
> work.

Yes, I was not able to do this. At some point one needs to decide: Release 
(finish!), as imperfect as it is, or not.

Marcus

Re: [Pharo-dev] What's new in Pharo 5.0

[Sven Van Caekenberghe]

> On 24 May 2016, at 04:00, Sean P. DeNigris  wrote:
> 
> Doing some exploring... BlueInk, Chroma, Flashback, Renraku - all packages
> with no class comments.

The missing class comments are totally unacceptable, we should refuse these.

Apart from BlueInk (a code formatter), I have never heard or seen the others ;-)

> How would a new user discover what these are?

If these are important to end users, they should be mentioned somewhere.

> Also, not new to Pharo 5.0, but thinking as a new user... Nautilus presents
> the system as an overwhelming mess of top level packages. I guess this is
> because we're showing packages, which are a dependency/SCM artifact, instead
> of capturing/representing logical domain relations. There are so many
> packages that start with e.g. System. It is not relevant to the user that
> they are packaged separately, unless one is hacking that library. These
> should all be collapsed under a top-level System node.

This has been suggested before. I actually like the current approach, I would 
not want to click open trees all the time.

> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/What-s-new-in-Pharo-5-0-tp4896954p4896956.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> 

Re: [Pharo-dev] What's new in Pharo 5.0

[Sven Van Caekenberghe]

> On 24 May 2016, at 03:37, Sean P. DeNigris  wrote:
> 
> Sean P. DeNigris wrote
>> Is there a more complete description than the announcement?
> 
> I should've mentioned that I did see the link to the bugtracker, but I'm
> looking for some middle ground between the 5 bullet points in the
> announcement and the 2400+ issues tagged for Pharo 5.0

It is our fault that such a list does not exist, but it is really, really hard 
to make it, since no one knows everything. It is also a huge amount of work.

> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/What-s-new-in-Pharo-5-0-tp4896954p4896955.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> 

Re: [Pharo-dev] What's new in Pharo 5.0

[Sean P. DeNigris]

Doing some exploring... BlueInk, Chroma, Flashback, Renraku - all packages
with no class comments. How would a new user discover what these are? 

Also, not new to Pharo 5.0, but thinking as a new user... Nautilus presents
the system as an overwhelming mess of top level packages. I guess this is
because we're showing packages, which are a dependency/SCM artifact, instead
of capturing/representing logical domain relations. There are so many
packages that start with e.g. System. It is not relevant to the user that
they are packaged separately, unless one is hacking that library. These
should all be collapsed under a top-level System node.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/What-s-new-in-Pharo-5-0-tp4896954p4896956.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] What's new in Pharo 5.0

[Sean P. DeNigris]

Sean P. DeNigris wrote
> Is there a more complete description than the announcement?

I should've mentioned that I did see the link to the bugtracker, but I'm
looking for some middle ground between the 5 bullet points in the
announcement and the 2400+ issues tagged for Pharo 5.0



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/What-s-new-in-Pharo-5-0-tp4896954p4896955.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] What's new in Pharo 5.0

[Sean P. DeNigris]

Is there a more complete description than the announcement? I've been
dutifully following the mailing lists, but don't feel like I have a real
handle on what the  new features are and why they matter. Thanks!



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/What-s-new-in-Pharo-5-0-tp4896954.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] compiledcode ?

[stepharo]

Thanks and a nice one please :)


Le 23/5/16 à 07:18, Clément Bera a écrit :

I will do a slice today.


On Mon, May 23, 2016 at 12:49 AM, Nicolai Hess > wrote:


Would it be possible to add some comments, please.

CompiledMethod is now a subclass of the new class CompiledCode
(and there is another
class CompiledBlock).

Can we please don't add new classes at this system level without
*any* comment.

nicolai

Re: [Pharo-dev] cleaning the Pharo Catalog

[stepharo]

esteban


we should sit with Pavel & christophe because package validation for 
distribution is on Pavel's roadmap and this is


probably the time to activate it.


Stef


Le 23/5/16 à 09:53, Esteban Lorenzano a écrit :

Hi guys,

I will update the Catalog for Pharo 6 and I was wondering if we should keep the 
“Unsorted” category… this corresponds with projects present in old 
MetacelloRepository repo, I added it at the beginning because I did not want 
those project to be lost, but in fact they are more or less abandonware and 
definitively, they were not very well kept (no descriptions, no tags and even 
worst, many of them will not load fine).
So what do you think? should I keep them?

Esteban

[Pharo-dev] UTF-8 regression in package saving

[stepharo]

Hi


I did not have the time to check but it seems that people cannot save 
code with accents using Monticello.



Stef

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 756471: 60029

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 7564717887459079fffd8bdf40f4ae6b69bd3a58
  
https://github.com/pharo-project/pharo-core/commit/7564717887459079fffd8bdf40f4ae6b69bd3a58
  Author: Jenkins Build Server 
  Date:   2016-05-23 (Mon, 23 May 2016)

  Changed paths:
A Kernel.package/Boolean.class/instance/controlling/xor_.st
M Manifest-Core.package/extension/TBehavior/instance/isManifest.st
M Refactoring-Critics.package/RBDetectIfNoneRule.class/README.md
M 
Refactoring-Critics.package/RBDetectIfNoneRule.class/instance/accessing/name.st
M 
Refactoring-Critics.package/RBDetectIfNoneRule.class/instance/accessing/rationale.st
M 
Refactoring-Critics.package/RBSmalltalkGlobalsRule.class/instance/accessing/name.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60028.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60029.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60028.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60029.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  60029
18309 Typo in RBSmalltalkGlobalsRule
https://pharo.fogbugz.com/f/cases/18309

18308 "Replaces detect:ifNone: by anySatisfy:" misleading rationale
https://pharo.fogbugz.com/f/cases/18308

18247 deprecation warning on #isManifest for metaclasses
https://pharo.fogbugz.com/f/cases/18247

18079 Boolean>>xor
https://pharo.fogbugz.com/f/cases/18079

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

[Pharo-dev] ConfigurationOfMerlin: to the guy who used a Halt as a cool way to let a message

[Esteban Lorenzano]

don’t!

I’m banning your configuration from MetaRepo because well… it messes with the 
update process. 
yes, I could and will add more solid support, but seriously, this is very bad 
programming. 

Esteban 

Re: [Pharo-dev] cleaning the Pharo Catalog

[Ben Coman]

On Mon, May 23, 2016 at 4:04 PM, Cyril Ferlicot Delbecque
 wrote:
>
>
> On 23/05/2016 10:00, Stephan Eggermont wrote:
>> Split into two categories? Those with full descriptions likely to load
>> and those probably needing some updates?
>>
>
> I like this option. Two tabs. A tab "PharoX" and a tab "Legacy" could be
> an idea.

But there are different levels of legacy.  Once version back maybe not
so bad.  Several versions back likely worse.  So maybe Pharo6, Pharo5,
Legacy ?  And it might be nice for Legacy to indicate which version
Pharo they were associated with, but probably not enough value for
such effort.

cheers -ben

>
>> Stephan
>>
>>
>>
>
> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 165 Avenue Bretagne
> Lille 59000 France
>

Re: [Pharo-dev] Mocketry names again

[Tudor Girba]

Yuppee! Thanks :)

Doru


> On May 23, 2016, at 12:18 PM, Denis Kudriashov  wrote:
> 
> And done. Version 3.4 deprecates "should got" and introduces "should receive".
> All docs are updated.
> 
> Prebuilt PDF can found here 
> https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/107/artifact/book-result/Mocketry/Mocketry.pdf
> 
> 2016-05-18 11:59 GMT+02:00 Denis Kudriashov :
> So at the end of week I will rename "should got" into "should receive"
> 
> 2016-04-27 23:39 GMT+02:00 Carlos Lombardi :
> Hi again,
> 
> ok, just to have coherence between the names for the two possible outcomes of 
> a method, you could use #beReturnedBy instead of #beReturnedFrom: . You would 
> have #beReturnedBy:  and  #beRaisedBy: 
> 
> On Wed, Apr 27, 2016 at 10:00 AM, Denis Kudriashov  
> wrote:
> 
> 2016-04-27 0:33 GMT+02:00 Carlos Lombardi :
> ... maybe 
> 
> #result should beTheResultOf: [mock someMessage].
> #result should not beTheResultOf: [mock anotherMessage].
> 
> It's nice.I think "The" can be omitted:
> 
> #result should beResultOf: [mock someMessage].
> 
> But anyway I use word #return because there are different types of result: 
> value return and error signal. There is no expression for last case but it 
> would be like:
> 
> anError should beRaisedBy: [mock someMessage]
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Speaking louder won't make the point worthier."

Re: [Pharo-dev] Mocketry names again

[Denis Kudriashov]

And done. Version 3.4 deprecates "should got" and introduces "should
receive".
All docs are updated.

Prebuilt PDF can found here
https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/107/artifact/book-result/Mocketry/Mocketry.pdf

2016-05-18 11:59 GMT+02:00 Denis Kudriashov :

> So at the end of week I will rename "should got" into "should receive"
>
> 2016-04-27 23:39 GMT+02:00 Carlos Lombardi :
>
>> Hi again,
>>
>> ok, just to have coherence between the names for the two possible
>> outcomes of a method, you could use #beReturnedBy instead of
>> #beReturnedFrom: . You would have #beReturnedBy:  and  #beRaisedBy:
>>
>> On Wed, Apr 27, 2016 at 10:00 AM, Denis Kudriashov 
>> wrote:
>>
>>>
>>> 2016-04-27 0:33 GMT+02:00 Carlos Lombardi :
>>>
 ... maybe

 #result should beTheResultOf: [mock someMessage].
 #result should not beTheResultOf: [mock anotherMessage].

>>>
>>> It's nice.I think "The" can be omitted:
>>>
>>> #result should beResultOf: [mock someMessage].
>>>
>>>
>>> But anyway I use word #return because there are different types of
>>> result: value return and error signal. There is no expression for last case
>>> but it would be like:
>>>
>>> anError should beRaisedBy: [mock someMessage]
>>>
>>>
>>
>

Re: [Pharo-dev] cleaning the Pharo Catalog

[Cyril Ferlicot Delbecque]

On 23/05/2016 10:00, Stephan Eggermont wrote:
> Split into two categories? Those with full descriptions likely to load
> and those probably needing some updates?
> 

I like this option. Two tabs. A tab "PharoX" and a tab "Legacy" could be
an idea.

> Stephan
> 
> 
> 

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

[Pharo-dev] [pharo-project/pharo-core] e22bb5: 60028

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: e22bb56e311438134062dea8f1c80822f144c27c
  
https://github.com/pharo-project/pharo-core/commit/e22bb56e311438134062dea8f1c80822f144c27c
  Author: Jenkins Build Server 
  Date:   2016-05-23 (Mon, 23 May 2016)

  Changed paths:
M Collections-Abstract.package/Collection.class/instance/math 
functions/stdev.st
R Kernel.package/Object.class/instance/updating/noteSelectionIndex_for_.st
M 
Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/updating/verifyContents.st
M 
Refactoring-Core.package/RBAbstractClassVariableRefactoring.class/README.md
M 
Refactoring-Core.package/RBAbstractInstanceVariableRefactoring.class/README.md
M Refactoring-Core.package/RBAbstractVariablesRefactoring.class/README.md
M Refactoring-Core.package/RBAccessorClassRefactoring.class/README.md
M Refactoring-Core.package/RBAddClassRefactoring.class/README.md
M Refactoring-Core.package/RBAddClassVariableRefactoring.class/README.md
M Refactoring-Core.package/RBAddInstanceVariableRefactoring.class/README.md
M Refactoring-Core.package/RBAddMethodRefactoring.class/README.md
M Refactoring-Core.package/RBAddParameterRefactoring.class/README.md
M Refactoring-Core.package/RBCategoryRegexRefactoring.class/README.md
M Refactoring-Core.package/RBChangeMethodNameRefactoring.class/README.md
M Refactoring-Core.package/RBChildrenToSiblingsRefactoring.class/README.md
M Refactoring-Core.package/RBClassRefactoring.class/README.md
M Refactoring-Core.package/RBClassRegexRefactoring.class/README.md
M 
Refactoring-Core.package/RBCreateAccessorsForVariableRefactoring.class/README.md
M 
Refactoring-Core.package/RBExpandReferencedPoolsRefactoring.class/README.md
M Refactoring-Core.package/RBExtractMethodRefactoring.class/README.md
M 
Refactoring-Core.package/RBExtractMethodToComponentRefactoring.class/README.md
M Refactoring-Core.package/RBExtractToTemporaryRefactoring.class/README.md
M Refactoring-Core.package/RBGenerateEqualHashRefactoring.class/README.md
M Refactoring-Core.package/RBGeneratePrintStringRefactoring.class/README.md
M Refactoring-Core.package/RBInlineAllSendersRefactoring.class/README.md
M 
Refactoring-Core.package/RBInlineMethodFromComponentRefactoring.class/README.md
M Refactoring-Core.package/RBInlineMethodRefactoring.class/README.md
M Refactoring-Core.package/RBInlineParameterRefactoring.class/README.md
M Refactoring-Core.package/RBInlineTemporaryRefactoring.class/README.md
M Refactoring-Core.package/RBMethodName.class/README.md
M Refactoring-Core.package/RBMethodRefactoring.class/README.md
M Refactoring-Core.package/RBMoveMethodRefactoring.class/README.md
M 
Refactoring-Core.package/RBMoveVariableDefinitionRefactoring.class/README.md
M Refactoring-Core.package/RBPrettyPrintCodeRefactoring.class/README.md
M 
Refactoring-Core.package/RBProtectInstanceVariableRefactoring.class/README.md
M Refactoring-Core.package/RBProtocolRegexRefactoring.class/README.md
M Refactoring-Core.package/RBPullUpClassVariableRefactoring.class/README.md
M 
Refactoring-Core.package/RBPullUpInstanceVariableRefactoring.class/README.md
M Refactoring-Core.package/RBPullUpMethodRefactoring.class/README.md
M 
Refactoring-Core.package/RBPushDownClassVariableRefactoring.class/README.md
M 
Refactoring-Core.package/RBPushDownInstanceVariableRefactoring.class/README.md
M Refactoring-Core.package/RBPushDownMethodRefactoring.class/README.md
M Refactoring-Core.package/RBRefactoring.class/README.md
M Refactoring-Core.package/RBRefactoringManager.class/README.md
M Refactoring-Core.package/RBRefactoryTyper.class/README.md
M Refactoring-Core.package/RBRegexRefactoring.class/README.md
M Refactoring-Core.package/RBRemoveClassRefactoring.class/README.md
M Refactoring-Core.package/RBRemoveClassVariableRefactoring.class/README.md
M 
Refactoring-Core.package/RBRemoveInstanceVariableRefactoring.class/README.md
M Refactoring-Core.package/RBRemoveMethodRefactoring.class/README.md
M Refactoring-Core.package/RBRemoveParameterRefactoring.class/README.md
M Refactoring-Core.package/RBRenameClassRefactoring.class/README.md
M Refactoring-Core.package/RBRenameClassVariableRefactoring.class/README.md
M 
Refactoring-Core.package/RBRenameInstanceVariableRefactoring.class/README.md
M Refactoring-Core.package/RBRenameMethodRefactoring.class/README.md
M Refactoring-Core.package/RBRenameTemporaryRefactoring.class/README.md
M Refactoring-Core.package/RBSourceRegexRefactoring.class/README.md
M Refactoring-Core.package/RBSplitCascadeRefactoring.class/README.md
M 
Refactoring-Core.package/RBSplitCascadeRefactoring.class/instance/preconditions/findMessageNodes.st
A 
Refactoring-Core.package/RBSplitCascadeRefactoring.class/instance/printing/storeOn_.st
 

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

[GitHub]

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

Re: [Pharo-dev] cleaning the Pharo Catalog

[Stephan Eggermont]

On 23/05/16 09:53, Esteban Lorenzano wrote:

Hi guys,

I will update the Catalog for Pharo 6 and I was wondering if we should keep the 
“Unsorted” category… this corresponds with projects present in old 
MetacelloRepository repo, I added it at the beginning because I did not want 
those project to be lost, but in fact they are more or less abandonware and 
definitively, they were not very well kept (no descriptions, no tags and even 
worst, many of them will not load fine).
So what do you think? should I keep them?


Split into two categories? Those with full descriptions likely to load 
and those probably needing some updates?


Stephan

[Pharo-dev] cleaning the Pharo Catalog

[Esteban Lorenzano]

Hi guys, 

I will update the Catalog for Pharo 6 and I was wondering if we should keep the 
“Unsorted” category… this corresponds with projects present in old 
MetacelloRepository repo, I added it at the beginning because I did not want 
those project to be lost, but in fact they are more or less abandonware and 
definitively, they were not very well kept (no descriptions, no tags and even 
worst, many of them will not load fine). 
So what do you think? should I keep them?

Esteban