Re: [Pharo-dev] [pharo-project/pharo-core] 32b2db: 60455

[Ben Coman]

Just a note, since 60455 the following Athens no longer fails 30
seconds later...


| view form1 form2|
view  := AthensSceneView new.
form1 := UIThemeWatery new scrollbarThumbHorizontalMiddleForm.
form2 := UIThemeWatery new scrollbarThumbVerticalMiddleForm.
view scene: [:canvas |
canvas surface clear:  Color black.
canvas setPaint: Color white.
canvas drawShape: (0@0 corner:300@300).
(canvas setPaint:form1) repeat.
canvas paintTransform restoreAfter:[
canvas paintTransform translateBy:10@144.
canvas drawShape:(10@144 corner:290@157).
].
(canvas setPaint:form2) repeat.
canvas paintTransform restoreAfter:[
canvas paintTransform translateBy:144@10.
canvas drawShape:(144@10 corner:157@290).
].
].
view openInWindow.


Thanks for your efforts Eliot and Esteban.


(btw That was a side issue from...

https://pharo.fogbugz.com/f/cases/14813/Wrong-size-for-Athens-surface-pattern-paint-from-a-Form)


cheers -ben

On Thu, Mar 30, 2017 at 6:15 PM, GitHub  wrote:

>   Branch: refs/heads/6.0
>   Home:   https://github.com/pharo-project/pharo-core
>   Commit: 32b2dbb8baa7c84e08ff9a363f30428147fdd3d1
>   https://github.com/pharo-project/pharo-core/commit/
> 32b2dbb8baa7c84e08ff9a363f30428147fdd3d1
>   Author: Jenkins Build Server 
>   Date:   2017-03-30 (Thu, 30 Mar 2017)
>
>   Changed paths:
> M Graphics-Primitives.package/BitBlt.class/instance/copying/
> copyBits.st
> A Kernel-Tests.package/TimeTest.class/instance/tests
> input/testNanoConstructor.st
> A Kernel.package/Time.class/class/instance
> creation/hour_minute_second_nano_.st
> A Refactoring-Core.package/RBRenameClassVariableRefactori
> ng.class/instance/accessing/newName.st
> A Refactoring-Core.package/RBRenameClassVariableRefactori
> ng.class/instance/accessing/newName_.st
> A Refactoring-Core.package/RBRenameInstanceVariableRefact
> oring.class/instance/accessing/newName.st
> A Refactoring-Core.package/RBRenameInstanceVariableRefact
> oring.class/instance/accessing/newName_.st
> A Refactoring-Core.package/RBRenameInstanceVariableRefact
> oring.class/instance/accessing/renameAccessors.st
> A Refactoring-Core.package/RBRenameInstanceVariableRefact
> oring.class/instance/accessing/renameAccessors_.st
> A Refactoring-Core.package/RBRenameInstanceVariableRefact
> oring.class/instance/initialize-release/initialize.st
> M STON-Core.package/STONReader.class/instance/private/isClassChar_.st
> A STON-Tests.package/STONReaderTests.class/instance/tests/
> testClassWithUnderscore.st
> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/
> script60454.st
> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/
> script60455.st
> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/
> update60454.st
> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/
> update60455.st
> M ScriptLoader60.package/ScriptLoader.class/instance/public/
> commentForCurrentUpdate.st
> M System-Support.package/SmalltalkImage.class/instance/special
> objects/newSpecialObjectsArray.st
>
>   Log Message:
>   ---
>   60455
> 19882 copyBits fails when showing Athens surface
> https://pharo.fogbugz.com/f/cases/19882
>
> 19885 STON cannot read classes with underscore in their name
> https://pharo.fogbugz.com/f/cases/19885
>
> 19879 Accessors for instance and class variable rename refactoring
> https://pharo.fogbugz.com/f/cases/19879
>
> 19881 add Time >> #hour:minute:second:nano: constructor
> https://pharo.fogbugz.com/f/cases/19881
>
> http://files.pharo.org/image/60/60455.zip
>
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] 4a89b0: 60443

[denker]

> On 16 Mar 2017, at 07:45, GitHub  wrote:
> 
> 
> 
>  Log Message:
>  ---
>  60443
> 19837 Epicea: integrate release 8.1.3
>   https://pharo.fogbugz.com/f/cases/19837
> 
> http://files.pharo.org/image/60/60443.zip
> 
> 

CHANGE LOG:

- Log browser:
  * Display changes in a FastTableModel instead of a TreeModel, much faster for 
many changes.
  * Remove "x filtered entries" display as well as "See 50 more" and "See all" 
buttons, to make the list of changes look more as a standard list (to the user 
eyes). Also, implementation was not nice.
  * Big code clean up.
  * Show number of active filters in tab (small visual improvement).
  * Increase initial width.
- Fix case 19737: class removal annoucement now comes after class is renamed to 
AnObsolete (workaround).
- Fix case 19263: Catch all errors on redo and undo.
- Merge with fix to case 19819 by Denis. Thanks!
- Multiple code clean-ups
  * Code Critic runs.
  * Reduce direct explicit references to EpMonitor.
  * Others.
- Add tests of apply and revert changes.
- Split EpLog into a new superclass to conform a hierarchy, which has now 
EpSorterLog.
- Ombu:
  * Shutdown flush should be performed by all OmDeferrers, not only by all 
OmSessionStores.
  * Workaround needed because can''t get real file stream position from 
ZnBufferedWriteStream (+ would need special care of WideStrings).
  * Remove OmDirectoryStore and OmCompositeStore since they are not used 
anymore (continuous-style EpPriorView was the user).
  * The Ston''s OmEntryReader should not receive the stream as parameter and 
then store it in the Ston reader. This produced was confussing and produced 
concurrency issues.

Re: [Pharo-dev] [pharo-project/pharo-core] 1b4c50: 60436

[stepharong]

Re: [Pharo-dev] [pharo-project/pharo-core] 1b4c50: 60436

[stepharong]

Re: [Pharo-dev] [pharo-project/pharo-core] 1b4c50: 60436

[stepharong]

Re: [Pharo-dev] [pharo-project/pharo-core] 1b4c50: 60436

[stepharong]

+1

On Tue, 07 Mar 2017 14:58:33 +0100, Sven Van Caekenberghe   
wrote:



Thank you, Andrei, for your continued efforts !


On 7 Mar 2017, at 14:47, denker  wrote:



Log Message:
---
60436
Moose

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




This brings changes to the inspector, debugger and fast table renderer  
for glamour.

Detailed changes:

- added support for refresh in the Inspector/Playground. The refresh  
uses the stepping mechanism from Morphic. There exists a setting to  
start/stop the refresh. Each presentation can decide if it wants  
refresh or not.


- the Glamour renderer for fast table uses now a LRUCache for storing  
the string representation returned by the #format: block. This is  
disabled by default and configureable per presentation. By default it  
is enabled for the Raw presentation and the collection presentations.


- the debugger now offers access to variables defined in the playground  
when debugging code from the playground


- the inspector uses GTInspectorVariableNode to model variables in the  
Raw view.


- fixed inspector issues with collections

Also fixes issues:
- case 18899 Raw presentation from the debugger inspector raises error  
when the rawSelection comes from another presentation
- case 17949 Missing evaluator presentation for the current context in  
debugger
- case 19753 Disappearing content in the context inspector from  
GTDebugger when tags are used

- case 19720 Add method scoped [Evaluator] tab to debugger
- case 14569 GTInspector should do live updates of objects and their  
slots










--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] [pharo-project/pharo-core] 1b4c50: 60436

[Sven Van Caekenberghe]

Thank you, Andrei, for your continued efforts !

> On 7 Mar 2017, at 14:47, denker  wrote:
> 
> 
>> Log Message:
>> ---
>> 60436
>> Moose
>> 
>> http://files.pharo.org/image/60/60436.zip
>> 
> 
> 
> This brings changes to the inspector, debugger and fast table renderer for 
> glamour.
> Detailed changes:
> 
> - added support for refresh in the Inspector/Playground. The refresh uses the 
> stepping mechanism from Morphic. There exists a setting to start/stop the 
> refresh. Each presentation can decide if it wants refresh or not.
> 
> - the Glamour renderer for fast table uses now a LRUCache for storing the 
> string representation returned by the #format: block. This is disabled by 
> default and configureable per presentation. By default it is enabled for the 
> Raw presentation and the collection presentations.
> 
> - the debugger now offers access to variables defined in the playground when 
> debugging code from the playground
> 
> - the inspector uses GTInspectorVariableNode to model variables in the Raw 
> view.
> 
> - fixed inspector issues with collections 
> 
> Also fixes issues:
> - case 18899 Raw presentation from the debugger inspector raises error when 
> the rawSelection comes from another presentation
> - case 17949 Missing evaluator presentation for the current context in 
> debugger
> - case 19753 Disappearing content in the context inspector from GTDebugger 
> when tags are used
> - case 19720 Add method scoped [Evaluator] tab to debugger
> - case 14569 GTInspector should do live updates of objects and their slots
> 
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] 1b4c50: 60436

[denker]

>  Log Message:
>  ---
>  60436
> Moose
> 
> http://files.pharo.org/image/60/60436.zip
> 


This brings changes to the inspector, debugger and fast table renderer for 
glamour.
Detailed changes:

- added support for refresh in the Inspector/Playground. The refresh uses the 
stepping mechanism from Morphic. There exists a setting to start/stop the 
refresh. Each presentation can decide if it wants refresh or not.

- the Glamour renderer for fast table uses now a LRUCache for storing the 
string representation returned by the #format: block. This is disabled by 
default and configureable per presentation. By default it is enabled for the 
Raw presentation and the collection presentations.

- the debugger now offers access to variables defined in the playground when 
debugging code from the playground

- the inspector uses GTInspectorVariableNode to model variables in the Raw view.

- fixed inspector issues with collections 

Also fixes issues:
- case 18899 Raw presentation from the debugger inspector raises error when the 
rawSelection comes from another presentation
- case 17949 Missing evaluator presentation for the current context in debugger
- case 19753 Disappearing content in the context inspector from GTDebugger when 
tags are used
- case 19720 Add method scoped [Evaluator] tab to debugger
- case 14569 GTInspector should do live updates of objects and their slots

Re: [Pharo-dev] [pharo-project/pharo-core] bbbcab: 60434

[Esteban Lorenzano]

catalog use a configuration that points to the baseline (with a github tag).
so it is the same… 

and by the way this is the recommended way to release things maintained with 
git ;)

Esteban


> On 7 Mar 2017, at 13:02, Sven Van Caekenberghe  wrote:
> 
> Hmm, but that is different than the one in the catalog ?
> Confusing. Best have only one that is really maintained.
> 
>> On 7 Mar 2017, at 10:16, Pavel Krivanek  wrote:
>> 
>> Metacello new
>>  smalltalkhubUser: 'Pharo' project: 'MetaRepoForPharo50';
>>  configuration: #SublimishTheme;
>>  version: '1.0.0';
>>  load
>> 
>> 2017-03-07 10:06 GMT+01:00 Sven Van Caekenberghe :
>> 
>>> On 7 Mar 2017, at 09:51, GitHub  wrote:
>>> 
>>> Log Message:
>>> ---
>>> 60434
>>> 19801 Remove SublimishTheme
>>>  https://pharo.fogbugz.com/f/cases/19801
>> 
>> So where/how can this theme be loaded again, I really, really liked it.
>> 
>> 
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] bbbcab: 60434

[Sven Van Caekenberghe]

Hmm, but that is different than the one in the catalog ?
Confusing. Best have only one that is really maintained.

> On 7 Mar 2017, at 10:16, Pavel Krivanek  wrote:
> 
> Metacello new
>   smalltalkhubUser: 'Pharo' project: 'MetaRepoForPharo50';
>   configuration: #SublimishTheme;
>   version: '1.0.0';
>   load
> 
> 2017-03-07 10:06 GMT+01:00 Sven Van Caekenberghe :
> 
> > On 7 Mar 2017, at 09:51, GitHub  wrote:
> >
> >  Log Message:
> >  ---
> >  60434
> > 19801 Remove SublimishTheme
> >   https://pharo.fogbugz.com/f/cases/19801
> 
> So where/how can this theme be loaded again, I really, really liked it.
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] bbbcab: 60434

[Pavel Krivanek]

Metacello new
smalltalkhubUser: 'Pharo' project: 'MetaRepoForPharo50';
configuration: #SublimishTheme;
version: '1.0.0';
load

2017-03-07 10:06 GMT+01:00 Sven Van Caekenberghe :

>
> > On 7 Mar 2017, at 09:51, GitHub  wrote:
> >
> >  Log Message:
> >  ---
> >  60434
> > 19801 Remove SublimishTheme
> >   https://pharo.fogbugz.com/f/cases/19801
>
> So where/how can this theme be loaded again, I really, really liked it.
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] bbbcab: 60434

[Sven Van Caekenberghe]

> On 7 Mar 2017, at 09:51, GitHub  wrote:
> 
>  Log Message:
>  ---
>  60434
> 19801 Remove SublimishTheme
>   https://pharo.fogbugz.com/f/cases/19801

So where/how can this theme be loaded again, I really, really liked it.

Re: [Pharo-dev] [pharo-project/pharo-core] 986ba2: 60402

[Andrei Chis]

Ping me in the evening when you have time. I might have some time but I'm
not 100% sure.

Cheers,
Andrei

On Tue, Feb 21, 2017 at 7:47 AM, p...@highoctane.be 
wrote:

> There are quite a few Themers + hard coded colors in GT.
>
> Maybe someone from the GT team can pair for an hour or two with me so that
> we can get this done.
>
> I can do this in the evening CET as I am pretty busy this week (managed to
> have Pharo a large part of my daily work now).
>
> Phil
>
> On Mon, Feb 20, 2017 at 6:54 PM, Sven Van Caekenberghe 
> wrote:
>
>> Thanks.
>>
>> Not that it is a big deal, but the default background does not really
>> match, but that might be taste as well.
>>
>> > On 20 Feb 2017, at 17:41, p...@highoctane.be wrote:
>> >
>> > I have fixed the spotter styling but need to get a 6.0 and move it
>> there.
>> >
>> > 
>> >
>> > On Mon, Feb 20, 2017 at 5:25 PM, Sven Van Caekenberghe 
>> wrote:
>> >
>> >> On 20 Feb 2017, at 16:45, GitHub  wrote:
>> >>
>> >> 19728 Integrate Sublimish theme
>> >>  https://pharo.fogbugz.com/f/cases/19728
>> >
>> > Very nice !
>> >
>> > But does it also not need Spotter styling ? This looks odd:
>> >
>> > 
>> >
>>
>>
>>
>

Re: [Pharo-dev] [pharo-project/pharo-core] 986ba2: 60402

[p...@highoctane.be]

There are quite a few Themers + hard coded colors in GT.

Maybe someone from the GT team can pair for an hour or two with me so that
we can get this done.

I can do this in the evening CET as I am pretty busy this week (managed to
have Pharo a large part of my daily work now).

Phil

On Mon, Feb 20, 2017 at 6:54 PM, Sven Van Caekenberghe  wrote:

> Thanks.
>
> Not that it is a big deal, but the default background does not really
> match, but that might be taste as well.
>
> > On 20 Feb 2017, at 17:41, p...@highoctane.be wrote:
> >
> > I have fixed the spotter styling but need to get a 6.0 and move it there.
> >
> > 
> >
> > On Mon, Feb 20, 2017 at 5:25 PM, Sven Van Caekenberghe 
> wrote:
> >
> >> On 20 Feb 2017, at 16:45, GitHub  wrote:
> >>
> >> 19728 Integrate Sublimish theme
> >>  https://pharo.fogbugz.com/f/cases/19728
> >
> > Very nice !
> >
> > But does it also not need Spotter styling ? This looks odd:
> >
> > 
> >
>
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] 69aea4: 60403

[denker]

> 
>  Log Message:
>  ---
>  60403
> Moose
> http://files.pharo.org/image/60/60403.zip
> 
> 
This actually is a merge for GT… with:

The version moves the inspector to FastTable. More precisely it moves the Raw 
presentation and the presentations for collections to FastTable. For that it 
adds a tree datasource that has columns. More details here: 
http://forum.world.st/inspector-performance-improvement-td4933944.html

There are still two issues that need to be fixed after integrating this version:
- sorting in the Raw presentation does not preserve expanded elements
- editing should be done using SHIFT+double click (in place) or using a popup 
window for larger expressions.


This fixes:
- case 19645 Enabling search triggers error in the FastTable renderer for 
Glamour
- case 19560 The Glamour renderer for FastTable should offer a DataSource that 
combines a table and a tree presentation
- case 19648 Collection>>gtInspectorItemsIn: should use FastTable

Also fixes:
- case 17578 GTInspector recognizes a mouse click only after moving the mouse
- case 19423 Collection*gtInspectorItemsIn: defines the same helpMessage twice
- case 17644 Header rows in the Inspector can be "dragged"
- case 19676 We miss closeAllInspectors in Smalltalk tools inspector to close 
all inspectors, like we do for debuggers
- case 19712 GTInspector should not sort variables by name

Re: [Pharo-dev] [pharo-project/pharo-core] 986ba2: 60402

[Sven Van Caekenberghe]

Thanks.

Not that it is a big deal, but the default background does not really match, 
but that might be taste as well.

> On 20 Feb 2017, at 17:41, p...@highoctane.be wrote:
> 
> I have fixed the spotter styling but need to get a 6.0 and move it there.
> 
> 
> 
> On Mon, Feb 20, 2017 at 5:25 PM, Sven Van Caekenberghe  wrote:
> 
>> On 20 Feb 2017, at 16:45, GitHub  wrote:
>> 
>> 19728 Integrate Sublimish theme
>>  https://pharo.fogbugz.com/f/cases/19728
> 
> Very nice !
> 
> But does it also not need Spotter styling ? This looks odd:
> 
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] fcd75f: 60386

[Sven Van Caekenberghe]

> On 11 Feb 2017, at 09:48, GitHub  wrote:
> 
>  Branch: refs/heads/6.0
>  Home:   https://github.com/pharo-project/pharo-core
>  Commit: fcd75f0830aa6925f2fee68011ae20fb30efee81
>  
> https://github.com/pharo-project/pharo-core/commit/fcd75f0830aa6925f2fee68011ae20fb30efee81
>  Author: Jenkins Build Server 
>  Date:   2017-02-11 (Sat, 11 Feb 2017)
> 
>  Changed paths:
>R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
> scripts/script60385.st
>A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
> scripts/script60386.st
>R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
> updates/update60385.st
>A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
> updates/update60386.st
>M 
> ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
>M Tool-FileList.package/FileList.class/instance/accessing/contents.st
>A Tool-FileList.package/FileList.class/instance/accessing/getEncoding.st
>M Tool-FileList.package/FileList.class/instance/file menu action/getHex.st
>A 
> Tool-FileList.package/FileList.class/instance/private/knownEncodingIdentifiers.st
>M 
> Tool-FileList.package/FileList.class/instance/private/readContentsBrief_.st
>M Tool-FileList.package/FileList.class/instance/private/readContentsHex_.st
>M Tool-FileList.package/FileList.class/instance/private/selectEncoding.st
>A 
> Tool-FileList.package/FileList.class/instance/private/streamFirst5000BytesFrom_.st
>A 
> Tool-FileList.package/FileList.class/instance/private/streamFirst5000BytesWithEncodingFrom_.st
>A 
> Tool-FileList.package/FileList.class/instance/private/streamFullContentsFrom_.st
>A 
> Tool-FileList.package/FileList.class/instance/private/streamFullContentsWithEncodingFrom_.st
> 
>  Log Message:
>  ---
>  60386
> 18778 FileList "View as" does not work
>   https://pharo.fogbugz.com/f/cases/18778
> 
> http://files.pharo.org/image/60/60386.zip

Very nice indeed, Nicolai, thank you once more.

Re: [Pharo-dev] [pharo-project/pharo-core] 16537e: 60373

[denker]

> 
>  Log Message:
>  ---
>  60373
> Moose


This is:

This version addresses some bug fixes and synchronises those packages 
integrated using slices with the GToolkit repos. Changes:

- case 19575
- case 19646
- case 19604
- case 19542
- case 19260
- case 19454
- FastTable/List/Tree presentations can set rowHeight.
- Set to the Source presentation of a Context object doItReceiver and 
doItContext.

Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] cfba43: 60350

[denker]

> 
>  Log Message:
>  ---
>  60350
> 19556 Glamour version 4.31
>   https://pharo.fogbugz.com/f/cases/19556
> 

Changes:

- fixes example GLMBasicExamples>>#morphWithCustomInteraction
- adds example GLMBasicExamples>>#changingTabsInComposite
- case 19505 Setting the selection using #initialize: does not work in a pharo 
script presentation.
- case 19504 Glamour should preserve the selection when updating a text 
presentation
- Put example browser into World / Help menu.
- better tests for the FT renderer in Glamour
- synchronize packages with Pharo

Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] 458c6c: 60330

[Max Leske]

VM looks ok BTW. Really seems to be the update itself.

> On 19 Dec 2016, at 21:00, Marcus Denker  wrote:
> 
> Hmm.. I think I will revert this update.
> 
>> On 19 Dec 2016, at 16:36, Max Leske  wrote:
>> 
>> Confirmed on OS X 10.12.3
>> 
>>> On 19 Dec 2016, at 19:26, Marcus Denker  wrote:
>>> 
>>> The image seems to come up with a black screen… something went wrong.
>>> 
>>> Can someone else check?
>>> 
 On 19 Dec 2016, at 14:21, GitHub  wrote:
 
 Branch: refs/heads/6.0
 Home:   https://github.com/pharo-project/pharo-core
 Commit: 458c6cef0678ceeedd886a7e8c952aa72ceddca0
   
 https://github.com/pharo-project/pharo-core/commit/458c6cef0678ceeedd886a7e8c952aa72ceddca0
 Author: Jenkins Build Server 
 Date:   2016-12-19 (Mon, 19 Dec 2016)
 
 Changed paths:
 M 
 Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForMilliseconds.st
 M 
 Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForSeconds.st
 M 
 Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForMilliseconds.st
 M 
 Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForSeconds.st
 M Kernel.package/Delay.class/class/initialize-release/initialize.st
 R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
 scripts/script60329.st
 A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
 scripts/script60330.st
 R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
 updates/update60329.st
 A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
 updates/update60330.st
 M 
 ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
 A 
 SmartSuggestions.package/SugsAbstractContext.class/instance/accessing/model.st
 A 
 SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectTheTextForTheNode.st
 A 
 SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectedInterval.st
 
 Log Message:
 ---
 60330
 18735 DNU on suggestions shortcut in GTDebugger
https://pharo.fogbugz.com/f/cases/18735
 
 19432 Promote DelaySpinScheduler from experimental status (part 2)
https://pharo.fogbugz.com/f/cases/19432
 
 19438 Widen tolerance for DelayScheduler timing tests
https://pharo.fogbugz.com/f/cases/19438
 
 http://files.pharo.org/image/60/60330.zip
 
 
>>> 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] 458c6c: 60330

[Marcus Denker]

Hmm.. I think I will revert this update.

> On 19 Dec 2016, at 16:36, Max Leske  wrote:
> 
> Confirmed on OS X 10.12.3
> 
>> On 19 Dec 2016, at 19:26, Marcus Denker  wrote:
>> 
>> The image seems to come up with a black screen… something went wrong.
>> 
>> Can someone else check?
>> 
>>> On 19 Dec 2016, at 14:21, GitHub  wrote:
>>> 
>>> Branch: refs/heads/6.0
>>> Home:   https://github.com/pharo-project/pharo-core
>>> Commit: 458c6cef0678ceeedd886a7e8c952aa72ceddca0
>>>
>>> https://github.com/pharo-project/pharo-core/commit/458c6cef0678ceeedd886a7e8c952aa72ceddca0
>>> Author: Jenkins Build Server 
>>> Date:   2016-12-19 (Mon, 19 Dec 2016)
>>> 
>>> Changed paths:
>>>  M 
>>> Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForMilliseconds.st
>>>  M 
>>> Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForSeconds.st
>>>  M 
>>> Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForMilliseconds.st
>>>  M 
>>> Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForSeconds.st
>>>  M Kernel.package/Delay.class/class/initialize-release/initialize.st
>>>  R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
>>> scripts/script60329.st
>>>  A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
>>> scripts/script60330.st
>>>  R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
>>> updates/update60329.st
>>>  A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
>>> updates/update60330.st
>>>  M 
>>> ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
>>>  A 
>>> SmartSuggestions.package/SugsAbstractContext.class/instance/accessing/model.st
>>>  A 
>>> SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectTheTextForTheNode.st
>>>  A 
>>> SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectedInterval.st
>>> 
>>> Log Message:
>>> ---
>>> 60330
>>> 18735 DNU on suggestions shortcut in GTDebugger
>>> https://pharo.fogbugz.com/f/cases/18735
>>> 
>>> 19432 Promote DelaySpinScheduler from experimental status (part 2)
>>> https://pharo.fogbugz.com/f/cases/19432
>>> 
>>> 19438 Widen tolerance for DelayScheduler timing tests
>>> https://pharo.fogbugz.com/f/cases/19438
>>> 
>>> http://files.pharo.org/image/60/60330.zip
>>> 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] 458c6c: 60330

[Max Leske]

Confirmed on OS X 10.12.3

> On 19 Dec 2016, at 19:26, Marcus Denker  wrote:
> 
> The image seems to come up with a black screen… something went wrong.
> 
> Can someone else check?
> 
>> On 19 Dec 2016, at 14:21, GitHub  wrote:
>> 
>> Branch: refs/heads/6.0
>> Home:   https://github.com/pharo-project/pharo-core
>> Commit: 458c6cef0678ceeedd886a7e8c952aa72ceddca0
>> 
>> https://github.com/pharo-project/pharo-core/commit/458c6cef0678ceeedd886a7e8c952aa72ceddca0
>> Author: Jenkins Build Server 
>> Date:   2016-12-19 (Mon, 19 Dec 2016)
>> 
>> Changed paths:
>>   M 
>> Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForMilliseconds.st
>>   M 
>> Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForSeconds.st
>>   M 
>> Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForMilliseconds.st
>>   M 
>> Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForSeconds.st
>>   M Kernel.package/Delay.class/class/initialize-release/initialize.st
>>   R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
>> scripts/script60329.st
>>   A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
>> scripts/script60330.st
>>   R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
>> updates/update60329.st
>>   A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
>> updates/update60330.st
>>   M 
>> ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
>>   A 
>> SmartSuggestions.package/SugsAbstractContext.class/instance/accessing/model.st
>>   A 
>> SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectTheTextForTheNode.st
>>   A 
>> SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectedInterval.st
>> 
>> Log Message:
>> ---
>> 60330
>> 18735 DNU on suggestions shortcut in GTDebugger
>>  https://pharo.fogbugz.com/f/cases/18735
>> 
>> 19432 Promote DelaySpinScheduler from experimental status (part 2)
>>  https://pharo.fogbugz.com/f/cases/19432
>> 
>> 19438 Widen tolerance for DelayScheduler timing tests
>>  https://pharo.fogbugz.com/f/cases/19438
>> 
>> http://files.pharo.org/image/60/60330.zip
>> 
>> 
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] 458c6c: 60330

[Marcus Denker]

The image seems to come up with a black screen… something went wrong.

Can someone else check?

> On 19 Dec 2016, at 14:21, GitHub  wrote:
> 
>  Branch: refs/heads/6.0
>  Home:   https://github.com/pharo-project/pharo-core
>  Commit: 458c6cef0678ceeedd886a7e8c952aa72ceddca0
>  
> https://github.com/pharo-project/pharo-core/commit/458c6cef0678ceeedd886a7e8c952aa72ceddca0
>  Author: Jenkins Build Server 
>  Date:   2016-12-19 (Mon, 19 Dec 2016)
> 
>  Changed paths:
>M 
> Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForMilliseconds.st
>M 
> Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForSeconds.st
>M 
> Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForMilliseconds.st
>M 
> Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForSeconds.st
>M Kernel.package/Delay.class/class/initialize-release/initialize.st
>R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
> scripts/script60329.st
>A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
> scripts/script60330.st
>R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
> updates/update60329.st
>A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
> updates/update60330.st
>M 
> ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
>A 
> SmartSuggestions.package/SugsAbstractContext.class/instance/accessing/model.st
>A 
> SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectTheTextForTheNode.st
>A 
> SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectedInterval.st
> 
>  Log Message:
>  ---
>  60330
> 18735 DNU on suggestions shortcut in GTDebugger
>   https://pharo.fogbugz.com/f/cases/18735
> 
> 19432 Promote DelaySpinScheduler from experimental status (part 2)
>   https://pharo.fogbugz.com/f/cases/19432
> 
> 19438 Widen tolerance for DelayScheduler timing tests
>   https://pharo.fogbugz.com/f/cases/19438
> 
> http://files.pharo.org/image/60/60330.zip
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] 48592d: 60274

[Marcus Denker]

> 
>  Log Message:
>  ---
>  60274
> Moose

This is:

18884 Inspecting a large Bag crashes the Image
18224 Scrolling Spotter creates draw damage outside of its bounds

Re: [Pharo-dev] [pharo-project/pharo-core] 93c8ee: 60250

[Marcus Denker]

> 
>  Log Message:
>  ---
>  60250
> Moose
> 
> http://files.pharo.org/image/60/60250.zip
> 
> 

Changes:

- case 19032

- case 19127

- fixed #name deprecation in Announcer>>#gtInspectorSubscriptionsIn:

- debuggers uses keymaps for specifying shortcuts instead of characters

- sync with the changes done in Pharo through slices

Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[stepharo]

For those found of annotations I suggest
#
or since it's destinated to IDE/Tool


Good idea. I will keep it in mind.

Stef

Re: [Pharo-dev] [pharo-project/pharo-core] d17433: 60238

[stepharo]

Ok I was confused and I checked everything has been well integrated.


Le 24/9/16 à 18:42, stepharo a écrit :

Apparently the changes are not in the image.

I'm puzzled.


Stef



Le 24/9/16 à 18:05, GitHub a écrit :

   Branch: refs/heads/6.0
   Home:   https://github.com/pharo-project/pharo-core
   Commit: d174333406cc1ff2973a8ef75ce1cdedd8e89804
https://github.com/pharo-project/pharo-core/commit/d174333406cc1ff2973a8ef75ce1cdedd8e89804
   Author: Jenkins Build Server 
   Date:   2016-09-24 (Sat, 24 Sep 2016)

   Changed paths:
 R Collections-Tests.package/StringTest.class/instance/tests - as 
class/testAsClass.st
 R Collections-Tests.package/StringTest.class/instance/tests - as 
class/testAsClassIfAbsent.st
 R Collections-Tests.package/StringTest.class/instance/tests - as 
class/testAsClassIfPresent.st
 R Collections-Tests.package/SymbolTest.class/instance/tests - as 
class/testAsClass.st
 R Collections-Tests.package/SymbolTest.class/instance/tests - as 
class/testAsClassIfAbsent.st
 R Collections-Tests.package/SymbolTest.class/instance/tests - as 
class/testAsClassIfPresent.st
 M 
FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance 
creation/newBoldButtonMorph.st
 M 
FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance 
creation/newItalicButtonMorph.st
 M 
FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance 
creation/newStruckOutButtonMorph.st
 M 
FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance 
creation/newUnderlinedButtonMorph.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/checkboxSelectedForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/checkboxUnselectedForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/menuPinForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newCheckboxMarkerForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newRadioButtonMarkerForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newWindowCloseForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newWindowMaximizeForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newWindowMenuForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newWindowMenuPassiveForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newWindowMinimizeForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/radioButtonForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/radioButtonSelectedForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/windowClosePassiveForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/windowMaximizePassiveForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/windowMinimizePassiveForm.st
 M 
Glamour-Rubric-Presentations.package/GLMLipsumWithSegmentsExample.class/instance/accessing/presentation.st
 M 
Glamour-Rubric-Presentations.package/GLMRubricExample.class/definition.st
 M 
Keymapping-Tests.package/KMCategoryTest.class/instance/tests/testCreateExistentCategoryFails.st

 M Komitter.package/Komitter.class/class/icon/taskbarIcon.st
 M Komitter.package/Komitter.class/definition.st
 M 
Morphic-Widgets-ColorPicker.package/ColorSelectorDialogWindow.class/instance/actions/newColorPickerButtonMorph.st
 M 
Morphic-Widgets-ColorPicker.package/ColorSelectorDialogWindow.class/instance/actions/pickColor.st
 M 
Morphic-Widgets-Tabs.package/Tab.class/instance/private-icons/defaultIcon.st
 M 
Morphic-Widgets-Windows.package/SystemWindow.class/instance/thumbnail/icon.st
 R 
Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/icon/iconNamed_.st
 M 
Nautilus.package/PackageTreePackageGroupNodeModel.class/instance/accessing/icon.st
 R 
NautilusCommon.package/NautilusPluginManager.class/instance/icons/iconNamed_.st
 M 
Polymorph-Widgets.package/AlertDialogWindow.class/instance/visual 
properties/icon.st
 M 
Polymorph-Widgets.package/ChooseDropListDialogWindow.class/instance/as 
yet unclassified/icon.st
 M 
Polymorph-Widgets.package/DenyDialogWindow.class/instance/visual 
properties/icon.st
 M Polymorph-Widgets.package/ErrorDialogWindow.class/instance/as 
yet unclassified/icon.st
 M 
Polymorph-Widgets.package/MessageDialogWindow.class/instance/visual 
properties/icon.st
 M 
Polymorph-Widgets.package/PopupChoiceDialogWindowWithMessage.class/instance/accessing/icon.st
 M 
Polymorph-Widgets.package/ProceedDialogWindow.class/instance/as yet 
unclassified/icon.st
 M 

Re: [Pharo-dev] [pharo-project/pharo-core] d17433: 60238

[stepharo]

May be there is a cache here.

Could someone tell me if in the latest version Object>>yourself has a 
large method comment?


Tx



Le 24/9/16 à 18:42, stepharo a écrit :

Apparently the changes are not in the image.

I'm puzzled.


Stef



Le 24/9/16 à 18:05, GitHub a écrit :

   Branch: refs/heads/6.0
   Home:   https://github.com/pharo-project/pharo-core
   Commit: d174333406cc1ff2973a8ef75ce1cdedd8e89804
https://github.com/pharo-project/pharo-core/commit/d174333406cc1ff2973a8ef75ce1cdedd8e89804
   Author: Jenkins Build Server 
   Date:   2016-09-24 (Sat, 24 Sep 2016)

   Changed paths:
 R Collections-Tests.package/StringTest.class/instance/tests - as 
class/testAsClass.st
 R Collections-Tests.package/StringTest.class/instance/tests - as 
class/testAsClassIfAbsent.st
 R Collections-Tests.package/StringTest.class/instance/tests - as 
class/testAsClassIfPresent.st
 R Collections-Tests.package/SymbolTest.class/instance/tests - as 
class/testAsClass.st
 R Collections-Tests.package/SymbolTest.class/instance/tests - as 
class/testAsClassIfAbsent.st
 R Collections-Tests.package/SymbolTest.class/instance/tests - as 
class/testAsClassIfPresent.st
 M 
FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance 
creation/newBoldButtonMorph.st
 M 
FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance 
creation/newItalicButtonMorph.st
 M 
FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance 
creation/newStruckOutButtonMorph.st
 M 
FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance 
creation/newUnderlinedButtonMorph.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/checkboxSelectedForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/checkboxUnselectedForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/menuPinForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newCheckboxMarkerForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newRadioButtonMarkerForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newWindowCloseForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newWindowMaximizeForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newWindowMenuForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newWindowMenuPassiveForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newWindowMinimizeForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/radioButtonForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/radioButtonSelectedForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/windowClosePassiveForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/windowMaximizePassiveForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/windowMinimizePassiveForm.st
 M 
Glamour-Rubric-Presentations.package/GLMLipsumWithSegmentsExample.class/instance/accessing/presentation.st
 M 
Glamour-Rubric-Presentations.package/GLMRubricExample.class/definition.st
 M 
Keymapping-Tests.package/KMCategoryTest.class/instance/tests/testCreateExistentCategoryFails.st

 M Komitter.package/Komitter.class/class/icon/taskbarIcon.st
 M Komitter.package/Komitter.class/definition.st
 M 
Morphic-Widgets-ColorPicker.package/ColorSelectorDialogWindow.class/instance/actions/newColorPickerButtonMorph.st
 M 
Morphic-Widgets-ColorPicker.package/ColorSelectorDialogWindow.class/instance/actions/pickColor.st
 M 
Morphic-Widgets-Tabs.package/Tab.class/instance/private-icons/defaultIcon.st
 M 
Morphic-Widgets-Windows.package/SystemWindow.class/instance/thumbnail/icon.st
 R 
Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/icon/iconNamed_.st
 M 
Nautilus.package/PackageTreePackageGroupNodeModel.class/instance/accessing/icon.st
 R 
NautilusCommon.package/NautilusPluginManager.class/instance/icons/iconNamed_.st
 M 
Polymorph-Widgets.package/AlertDialogWindow.class/instance/visual 
properties/icon.st
 M 
Polymorph-Widgets.package/ChooseDropListDialogWindow.class/instance/as 
yet unclassified/icon.st
 M 
Polymorph-Widgets.package/DenyDialogWindow.class/instance/visual 
properties/icon.st
 M Polymorph-Widgets.package/ErrorDialogWindow.class/instance/as 
yet unclassified/icon.st
 M 
Polymorph-Widgets.package/MessageDialogWindow.class/instance/visual 
properties/icon.st
 M 
Polymorph-Widgets.package/PopupChoiceDialogWindowWithMessage.class/instance/accessing/icon.st
 M 
Polymorph-Widgets.package/ProceedDialogWindow.class/instance/as yet 

Re: [Pharo-dev] [pharo-project/pharo-core] d17433: 60238

[stepharo]

Apparently the changes are not in the image.

I'm puzzled.


Stef



Le 24/9/16 à 18:05, GitHub a écrit :

   Branch: refs/heads/6.0
   Home:   https://github.com/pharo-project/pharo-core
   Commit: d174333406cc1ff2973a8ef75ce1cdedd8e89804
   
https://github.com/pharo-project/pharo-core/commit/d174333406cc1ff2973a8ef75ce1cdedd8e89804
   Author: Jenkins Build Server 
   Date:   2016-09-24 (Sat, 24 Sep 2016)

   Changed paths:
 R Collections-Tests.package/StringTest.class/instance/tests - as 
class/testAsClass.st
 R Collections-Tests.package/StringTest.class/instance/tests - as 
class/testAsClassIfAbsent.st
 R Collections-Tests.package/StringTest.class/instance/tests - as 
class/testAsClassIfPresent.st
 R Collections-Tests.package/SymbolTest.class/instance/tests - as 
class/testAsClass.st
 R Collections-Tests.package/SymbolTest.class/instance/tests - as 
class/testAsClassIfAbsent.st
 R Collections-Tests.package/SymbolTest.class/instance/tests - as 
class/testAsClassIfPresent.st
 M 
FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance 
creation/newBoldButtonMorph.st
 M 
FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance 
creation/newItalicButtonMorph.st
 M 
FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance 
creation/newStruckOutButtonMorph.st
 M 
FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance 
creation/newUnderlinedButtonMorph.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/checkboxSelectedForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/checkboxUnselectedForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/menuPinForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newCheckboxMarkerForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newRadioButtonMarkerForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newWindowCloseForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newWindowMaximizeForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newWindowMenuForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newWindowMenuPassiveForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/newWindowMinimizeForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/radioButtonForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/radioButtonSelectedForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/windowClosePassiveForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/windowMaximizePassiveForm.st
 M 
Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/forms/windowMinimizePassiveForm.st
 M 
Glamour-Rubric-Presentations.package/GLMLipsumWithSegmentsExample.class/instance/accessing/presentation.st
 M Glamour-Rubric-Presentations.package/GLMRubricExample.class/definition.st
 M 
Keymapping-Tests.package/KMCategoryTest.class/instance/tests/testCreateExistentCategoryFails.st
 M Komitter.package/Komitter.class/class/icon/taskbarIcon.st
 M Komitter.package/Komitter.class/definition.st
 M 
Morphic-Widgets-ColorPicker.package/ColorSelectorDialogWindow.class/instance/actions/newColorPickerButtonMorph.st
 M 
Morphic-Widgets-ColorPicker.package/ColorSelectorDialogWindow.class/instance/actions/pickColor.st
 M 
Morphic-Widgets-Tabs.package/Tab.class/instance/private-icons/defaultIcon.st
 M 
Morphic-Widgets-Windows.package/SystemWindow.class/instance/thumbnail/icon.st
 R 
Nautilus-GroupManagerUI.package/DialogGroupManagerUI.class/instance/icon/iconNamed_.st
 M 
Nautilus.package/PackageTreePackageGroupNodeModel.class/instance/accessing/icon.st
 R 
NautilusCommon.package/NautilusPluginManager.class/instance/icons/iconNamed_.st
 M Polymorph-Widgets.package/AlertDialogWindow.class/instance/visual 
properties/icon.st
 M Polymorph-Widgets.package/ChooseDropListDialogWindow.class/instance/as 
yet unclassified/icon.st
 M Polymorph-Widgets.package/DenyDialogWindow.class/instance/visual 
properties/icon.st
 M Polymorph-Widgets.package/ErrorDialogWindow.class/instance/as yet 
unclassified/icon.st
 M Polymorph-Widgets.package/MessageDialogWindow.class/instance/visual 
properties/icon.st
 M 
Polymorph-Widgets.package/PopupChoiceDialogWindowWithMessage.class/instance/accessing/icon.st
 M Polymorph-Widgets.package/ProceedDialogWindow.class/instance/as yet 
unclassified/icon.st
 M Polymorph-Widgets.package/TextEditorDialogWindow.class/instance/visual 
properties/icon.st
 M 

Re: [Pharo-dev] [pharo-project/pharo-core] d3c4dd: 60236

[stepharo]

On improvements at a time at work!

Excellent


Le 23/9/16 à 09:25, Marcus Denker a écrit :

19124 enhance Deprecation to log sending method
https://pharo.fogbugz.com/f/cases/19124


The result of this is that now the log on the CI now exactly tells us what to 
fix:
(I will add issue tracker entries for each):

*** Warning: Deprecation: The method GTSpotter>>isEmpty called from 
GTSpotterTest>>#testNewSpotter has been deprecated.
Use hasSteps instead

*** Warning: Deprecation: The method Object>>name called from 
KMRepository>>#addCategory: has been deprecated.
Implement your own domain representation of an object, or use #asString or 
#printString instead.

*** Warning: Deprecation: The method Object>>name called from 
ClassHierarchyTest>>#testSubclasses has been deprecated.
Implement your own domain representation of an object, or use #asString or 
#printString instead.

*** Warning: Deprecation: The method Object>>name called from 
BooleanSlot>>#layoutChanged: has been deprecated.
Implement your own domain representation of an object, or use #asString or 
#printString instead.

*** Warning: Deprecation: The method Object>>name called from 
GlobalVariableTest>>#testSmalltalkNotDoubleSymbol has been deprecated.
Implement your own domain representation of an object, or use #asString or 
#printString instead.

*** Warning: Deprecation: The method Object>>name called from 
PropertySlot>>#layoutChanged: has been deprecated.
Implement your own domain representation of an object, or use #asString or 
#printString instead.

*** Warning: Deprecation: The method Object>>name called from 
UnlimitedInstanceVariableSlot>>#layoutChanged: has been deprecated.
Implement your own domain representation of an object, or use #asString or 
#printString instead.

*** Warning: Deprecation: The method Object>>name called from 
ChangeSet>>#changeRecorderFor: has been deprecated.
Implement your own domain representation of an object, or use #asString or 
#printString instead.

Re: [Pharo-dev] [pharo-project/pharo-core] d3c4dd: 60236

[Marcus Denker]

> On 23 Sep 2016, at 08:25, Marcus Denker  wrote:
> 
> 
>> 
>> 19124 enhance Deprecation to log sending method 
>>  https://pharo.fogbugz.com/f/cases/19124
> 
> 
> The result of this is that now the log on the CI now exactly tells us what to 
> fix:
> (I will add issue tracker entries for each):
> 

They are now all added as subclasses of 

https://pharo.fogbugz.com/f/cases/18702/ 



Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] d87de4: 60237

[Marcus Denker]

> On 23 Sep 2016, at 11:34, Marcus Denker  wrote:
> 
> 
>> 
>> Log Message:
>> ---
>> 60237
>> Moose
>> 
>> http://files.pharo.org/image/60/60237.zip
>> 
>> 
> 
> This is:
> 
> - case 19032
> - testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits was failing due to 
> #isLastInOwner
> - add manifest wit preUnload action in GTDebugger
> 
> But:
> 
> => 19032 seems to be not fixed. (there is still a sender if #ifNotNilDo:)
> 
> => the gt problem with 
> testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits was fixed, but in 
> the meantime
> we got more problems (from epicea). This is a nice example how not fixing 
> a trivial bug leads to more decay fast
> that we do not even know about. “yes, that test fails and I know why. 
> Will be fixed when we merge”.  
> What happens instead is that this “known failure” will fail soon due to 
> many more other reasons… that nobody is
> even aware of.
> 
> Trivial is not trivial.. that is why one needs to fix them as soon as 
> possible and *never* think that batching trivialities is
> a good idea…
> 

Issue tracker entries are updated. (closed / edited so reflect what is left to 
be done)

Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] d87de4: 60237

[Marcus Denker]

> 
>  Log Message:
>  ---
>  60237
> Moose
> 
> http://files.pharo.org/image/60/60237.zip
> 
> 

This is:

- case 19032
- testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits was failing due to 
#isLastInOwner
- add manifest wit preUnload action in GTDebugger

But:

=> 19032 seems to be not fixed. (there is still a sender if #ifNotNilDo:)

=> the gt problem with testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits 
was fixed, but in the meantime
 we got more problems (from epicea). This is a nice example how not fixing 
a trivial bug leads to more decay fast
 that we do not even know about. “yes, that test fails and I know why. Will 
be fixed when we merge”.  
 What happens instead is that this “known failure” will fail soon due to 
many more other reasons… that nobody is
 even aware of.

Trivial is not trivial.. that is why one needs to fix them as soon as possible 
and *never* think that batching trivialities is
a good idea…

Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] d3c4dd: 60236

[Tudor Girba]

Great addition!

Doru


> On Sep 23, 2016, at 8:25 AM, Marcus Denker  wrote:
> 
> 
>> 
>> 19124 enhance Deprecation to log sending method 
>>  https://pharo.fogbugz.com/f/cases/19124
> 
> 
> The result of this is that now the log on the CI now exactly tells us what to 
> fix:
> (I will add issue tracker entries for each):
> 
> *** Warning: Deprecation: The method GTSpotter>>isEmpty called from 
> GTSpotterTest>>#testNewSpotter has been deprecated.
> Use hasSteps instead
> 
> *** Warning: Deprecation: The method Object>>name called from 
> KMRepository>>#addCategory: has been deprecated.
> Implement your own domain representation of an object, or use #asString or 
> #printString instead.
> 
> *** Warning: Deprecation: The method Object>>name called from 
> ClassHierarchyTest>>#testSubclasses has been deprecated.
> Implement your own domain representation of an object, or use #asString or 
> #printString instead.
> 
> *** Warning: Deprecation: The method Object>>name called from 
> BooleanSlot>>#layoutChanged: has been deprecated.
> Implement your own domain representation of an object, or use #asString or 
> #printString instead.
> 
> *** Warning: Deprecation: The method Object>>name called from 
> GlobalVariableTest>>#testSmalltalkNotDoubleSymbol has been deprecated.
> Implement your own domain representation of an object, or use #asString or 
> #printString instead.
> 
> *** Warning: Deprecation: The method Object>>name called from 
> PropertySlot>>#layoutChanged: has been deprecated.
> Implement your own domain representation of an object, or use #asString or 
> #printString instead.
> 
> *** Warning: Deprecation: The method Object>>name called from 
> UnlimitedInstanceVariableSlot>>#layoutChanged: has been deprecated.
> Implement your own domain representation of an object, or use #asString or 
> #printString instead.
> 
> *** Warning: Deprecation: The method Object>>name called from 
> ChangeSet>>#changeRecorderFor: has been deprecated.
> Implement your own domain representation of an object, or use #asString or 
> #printString instead.
> 
> 

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

"Obvious things are difficult to teach."

Re: [Pharo-dev] [pharo-project/pharo-core] d3c4dd: 60236

[Marcus Denker]

> 
> 19124 enhance Deprecation to log sending method 
>   https://pharo.fogbugz.com/f/cases/19124


The result of this is that now the log on the CI now exactly tells us what to 
fix:
(I will add issue tracker entries for each):

*** Warning: Deprecation: The method GTSpotter>>isEmpty called from 
GTSpotterTest>>#testNewSpotter has been deprecated.
Use hasSteps instead

*** Warning: Deprecation: The method Object>>name called from 
KMRepository>>#addCategory: has been deprecated.
Implement your own domain representation of an object, or use #asString or 
#printString instead.

*** Warning: Deprecation: The method Object>>name called from 
ClassHierarchyTest>>#testSubclasses has been deprecated.
Implement your own domain representation of an object, or use #asString or 
#printString instead.

*** Warning: Deprecation: The method Object>>name called from 
BooleanSlot>>#layoutChanged: has been deprecated.
Implement your own domain representation of an object, or use #asString or 
#printString instead.

*** Warning: Deprecation: The method Object>>name called from 
GlobalVariableTest>>#testSmalltalkNotDoubleSymbol has been deprecated.
Implement your own domain representation of an object, or use #asString or 
#printString instead.

*** Warning: Deprecation: The method Object>>name called from 
PropertySlot>>#layoutChanged: has been deprecated.
Implement your own domain representation of an object, or use #asString or 
#printString instead.

*** Warning: Deprecation: The method Object>>name called from 
UnlimitedInstanceVariableSlot>>#layoutChanged: has been deprecated.
Implement your own domain representation of an object, or use #asString or 
#printString instead.

*** Warning: Deprecation: The method Object>>name called from 
ChangeSet>>#changeRecorderFor: has been deprecated.
Implement your own domain representation of an object, or use #asString or 
#printString instead.

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Henrik Sperre Johansen]

Tudor Girba-2 wrote
> Now, this is something cool, I think. Let’s investigate this further. One
> issue is whether the Pragma class should be modified to take into account
> the new semantics. 
> 
> Cheers,
> Doru

A major disadvantage is that in other Smalltalks supporting tags, block
scoping isn't simply ignored/treated as a regular method tag, but a syntax
error. So a change would benefit from some degree of coordination.

With upcoming split between Clean/Other blocks you also have decide
polymorphically the valid execution scope; context-free clean blocks can be
executed as examples anywhere, non-clean ones will only be valid
inspecting/debugging a live object.

The same idea can, for the same reasons, also be applied to implement
asserts that are entirely free when disabled; 
[ param satisfiesSomeCondition]
A change in global assert setting could recompile affected methods,
adding/removing #value calls to the block in AST as appropriate.



--
View this message in context: 
http://forum.world.st/pharo-project-pharo-core-edd9f3-60220-tp4915481p4916389.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Tudor Girba]

Now, this is something cool, I think. Let’s investigate this further. One issue 
is whether the Pragma class should be modified to take into account the new 
semantics. 

Cheers,
Doru


> On Sep 20, 2016, at 10:41 PM, Nicolai Hess  wrote:
> 
> 
> 
> 2016-09-19 16:24 GMT+02:00 Henrik Johansen :
> 
>> On 19 Sep 2016, at 4:03 , Henrik Johansen  
>> wrote:
>> 
>>> 
>>> On 17 Sep 2016, at 4:17 , Ben Coman  wrote:
>>> 
>>> On Sat, Sep 17, 2016 at 3:45 AM, Nicolai Hess  wrote:
 
 
 2016-09-16 18:42 GMT+02:00 Eliot Miranda :
> 
> Hi All,
> 
> 
> 
> _,,,^..^,,,_ (phone)
>> On Sep 14, 2016, at 10:50 PM, Marcus Denker 
>> wrote:
>> 
>> 
 
 We can change it back and maybe add support for the reformatter to not
 convert it to the literal array #(3 #+ 4) .
>>> 
>>> I do not know in fact this is why I asked :)
>>> Now may be my idea to use pragma to get something like pythondoctest is
>>> a bad idea
>>> but I really want to have literal programming.
>>> What do you think?
>> I like the idea to show examples/tests close to code, but pragmas are
>> not really good...
>> 
>>> If we have ' ' then it would be good that the syntax higlighter works
>>> with a special mode inside the ' '
>> 
>> it is just a string. How do you know that it contains code?
>> 
>> Would you highlight all string in all code as if it contained code? Or
>> would you add this just for
>> Pragmas? But even there, strings are string, not code.
>> 
>> I think we can conclude that pragmas are not a good solution to the
>> problem, as they are far
>> too limited to express code.
> 
> I think that's not a safe conclusion.  We know from Igor's use of Kieran
> arrays for C signatures in the UFFI, and can easily extrapolate here, that
> arbitrary Smalltalk expressions /can/ be expressed in literal arrays.  S
> expressions work for lisp.
> 
> In this particular case special casing pretty printing of literal arrays
> in pragmas would be all that's needed to make the code look beautiful.  
> Why
> throw the baby out with the bath water?  It would be so easy to make this
> work well.
 
 
 We can try this as well. And it is far more easier to work with this
 expressions if they are pragma arguments, than to parse the comment to find
 some code within.
 On the other hand, it looks much nicer if we have the examples right in the
 method doc. you have some text describing the method, some code, some more
 text about the reslt.
 
 
> 
> 
> The only thing I'd do would be to print like this to make it clear that
> the argument t is a literal Array and not some magic form of code:
> 
> 
> 
 
 Yes, I would like to change this anyway, even for literal arrays for ffi,
 calls like
 
 mouseStateX: x y: y
>>> errorCode>
^ self nbCall: #( Uint32 SDL_GetMouseState ( int* x , int* y ) )
 
 this will be reformatted to
 
 mouseStateX: x y: y
>>> 'errorCode'>
^ self nbCall: #(#Uint32 #SDL_GetMouseState #(#int #* #x #, #int #* #y))
>>> 
>>> errr, yuck!  Thats not pretty at all.  Is there some way to avoid
>>> that?  As I've been getting started with FFI its been really nice
>>> visually to see a *direct* correspondence between the C header file
>>> declaration and the in-Image method.  
>> 
>> +1, that's about the main thought behind it...
>> As long as the only required use of a # inside of literal arrays is 
>> differentiating whether something is a literal string or symbol, changing to 
>> format *all* symbols using it seems somewhat overzealous.
>> 
>> Personally, if a solution using method properties/+ browser improvements to 
>> show/create them in a good way is out of the question,
>> I have a weakness for using empty blocks as method-local, syntax-highlighted 
>> code comments (at least compared to special comment syntax, or pragmas 
>> backed by a whole literal -> ST parser).
>> Though lately, the code critic (rightly, and very usefully, in the cases 
>> where it's a user error) points out they are dead code, and the IR optimizes 
>> them out entirely, meaning they miss out on 
>> senders/implementors/refactorings functionality. (Full blocks would 
>> potentially let us change the IR to leave them alone, put them in the 
>> literal slot and be searchable, at no additional runtime-cost/use in 
>> bytecodes)
>> 
>> Cheers,
>> Henry
> 
> Now imagine if tags were scoped, and you could do
> 
> Number >>  #+ aNumber
> 
> [  3 + 4 == 7 ].
> ^self fallbackAdd: aNumber
> 
> And have the browser pick it up, and either 
> - collapse it
> - display text with alpha < 1
> 
> Make 

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Nicolai Hess]

2016-09-19 16:24 GMT+02:00 Henrik Johansen :

>
> On 19 Sep 2016, at 4:03 , Henrik Johansen 
> wrote:
>
>
> On 17 Sep 2016, at 4:17 , Ben Coman  > wrote:
>
> On Sat, Sep 17, 2016 at 3:45 AM, Nicolai Hess 
> wrote:
>
>
>
> 2016-09-16 18:42 GMT+02:00 Eliot Miranda :
>
>
> Hi All,
>
>
>
> _,,,^..^,,,_ (phone)
>
> On Sep 14, 2016, at 10:50 PM, Marcus Denker 
> wrote:
>
>
>
> We can change it back and maybe add support for the reformatter to not
> convert it to the literal array #(3 #+ 4) .
>
>
> I do not know in fact this is why I asked :)
> Now may be my idea to use pragma to get something like pythondoctest is
> a bad idea
> but I really want to have literal programming.
> What do you think?
>
> I like the idea to show examples/tests close to code, but pragmas are
> not really good...
>
> If we have ' ' then it would be good that the syntax higlighter works
> with a special mode inside the ' '
>
>
> it is just a string. How do you know that it contains code?
>
> Would you highlight all string in all code as if it contained code? Or
> would you add this just for
> Pragmas? But even there, strings are string, not code.
>
> I think we can conclude that pragmas are not a good solution to the
> problem, as they are far
> too limited to express code.
>
>
> I think that's not a safe conclusion.  We know from Igor's use of Kieran
> arrays for C signatures in the UFFI, and can easily extrapolate here, that
> arbitrary Smalltalk expressions /can/ be expressed in literal arrays.  S
> expressions work for lisp.
>
> In this particular case special casing pretty printing of literal arrays
> in pragmas would be all that's needed to make the code look beautiful.  Why
> throw the baby out with the bath water?  It would be so easy to make this
> work well.
>
>
>
> We can try this as well. And it is far more easier to work with this
> expressions if they are pragma arguments, than to parse the comment to find
> some code within.
> On the other hand, it looks much nicer if we have the examples right in the
> method doc. you have some text describing the method, some code, some more
> text about the reslt.
>
>
>
>
> The only thing I'd do would be to print like this to make it clear that
> the argument t is a literal Array and not some magic form of code:
>
> 
>
>
> Yes, I would like to change this anyway, even for literal arrays for ffi,
> calls like
>
> mouseStateX: x y: y
> errorCode>
>^ self nbCall: #( Uint32 SDL_GetMouseState ( int* x , int* y ) )
>
> this will be reformatted to
>
> mouseStateX: x y: y
> 'errorCode'>
>^ self nbCall: #(#Uint32 #SDL_GetMouseState #(#int #* #x #, #int #* #y))
>
>
> errr, yuck!  Thats not pretty at all.  Is there some way to avoid
> that?  As I've been getting started with FFI its been really nice
> visually to see a *direct* correspondence between the C header file
> declaration and the in-Image method.
>
>
> +1, that's about the main thought behind it...
> As long as the only required use of a # inside of literal arrays is
> differentiating whether something is a literal string or symbol, changing
> to format *all* symbols using it seems somewhat overzealous.
>
> Personally, if a solution using method properties/+ browser improvements
> to show/create them in a good way is out of the question,
> I have a weakness for using empty blocks as method-local,
> syntax-highlighted code comments (at least compared to special comment
> syntax, or pragmas backed by a whole literal -> ST parser).
> Though lately, the code critic (rightly, and very usefully, in the cases
> where it's a user error) points out they are dead code, and the IR
> optimizes them out entirely, meaning they miss out on 
> senders/implementors/refactorings
> functionality. (Full blocks would potentially let us change the IR to leave
> them alone, put them in the literal slot and be searchable, at no
> additional runtime-cost/use in bytecodes)
>
> Cheers,
> Henry
>
>
> Now imagine if tags were scoped, and you could do
>
> Number >>  #+ aNumber
> 
> [  3 + 4 == 7 ].
> ^self fallbackAdd: aNumber
>
> And have the browser pick it up, and either
> - collapse it
> - display text with alpha < 1
>
> Make the code critic aware as well, and no more warnings of unused blocks
> when used for examples!
>
> Cheers,
> Henry
>

Hm, dead blocks, nice idea.

see attached cs, you can file it in and have to uncomment one line in
RBParser>>#parseBlock (the parsePragmasInto: aNode  line)
to activate pragmas in blocks, now you can add a "dead block" like

[ 3+4]

and the icon styler lets you execute (inspect) the code.
(Just a quick and dirty implementation)
'From Pharo6.0 of 13 May 2016 [Latest update: #60231] on 20 September 2016 at 
10:31:13.740364 pm'!
IconStyler subclass: #ExampleIconStyler
instanceVariableNames: ''
classVariableNames: ''
   

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Nicolai Hess]

2016-09-19 19:14 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com>:

>
>
> 2016-09-19 17:08 GMT+02:00 Esteban Lorenzano :
>
>>
>> On 19 Sep 2016, at 16:49, Nicolai Hess  wrote:
>>
>>
>> Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano" <
>> esteba...@gmail.com>:
>> >
>> >
>> >> On 16 Sep 2016, at 21:45, Nicolai Hess  wrote:
>> >>
>> >>
>> >>
>> >> 2016-09-16 18:42 GMT+02:00 Eliot Miranda :
>> >>>
>> >>> Hi All,
>> >>>
>> >>>
>> >>>
>> >>> _,,,^..^,,,_ (phone)
>> >>> > On Sep 14, 2016, at 10:50 PM, Marcus Denker 
>> wrote:
>> >>> >
>> >>> >
>> >>> >>>
>> >>> >>> We can change it back and maybe add support for the reformatter
>> to not convert it to the literal array #(3 #+ 4) .
>> >>> >>
>> >>> >> I do not know in fact this is why I asked :)
>> >>> >> Now may be my idea to use pragma to get something like
>> pythondoctest is a bad idea
>> >>> >> but I really want to have literal programming.
>> >>> >> What do you think?
>> >>> > I like the idea to show examples/tests close to code, but pragmas
>> are not really good...
>> >>> >
>> >>> >> If we have ' ' then it would be good that the syntax higlighter
>> works with a special mode inside the ' '
>> >>> >
>> >>> > it is just a string. How do you know that it contains code?
>> >>> >
>> >>> > Would you highlight all string in all code as if it contained code?
>> Or would you add this just for
>> >>> > Pragmas? But even there, strings are string, not code.
>> >>> >
>> >>> > I think we can conclude that pragmas are not a good solution to the
>> problem, as they are far
>> >>> > too limited to express code.
>> >>>
>> >>> I think that's not a safe conclusion.  We know from Igor's use of
>> Kieran arrays for C signatures in the UFFI, and can easily extrapolate
>> here, that arbitrary Smalltalk expressions /can/ be expressed in literal
>> arrays.  S expressions work for lisp.
>> >>>
>> >>> In this particular case special casing pretty printing of literal
>> arrays in pragmas would be all that's needed to make the code look
>> beautiful.  Why throw the baby out with the bath water?  It would be so
>> easy to make this work well.
>> >>
>> >>
>> >> We can try this as well. And it is far more easier to work with this
>> expressions if they are pragma arguments, than to parse the comment to find
>> some code within.
>> >> On the other hand, it looks much nicer if we have the examples right
>> in the method doc. you have some text describing the method, some code,
>> some more text about the reslt.
>> >>
>> >>
>> >>>
>> >>>
>> >>> The only thing I'd do would be to print like this to make it clear
>> that the argument t is a literal Array and not some magic form of code:
>> >>>
>> >>>  
>> >>>
>> >>
>> >> Yes, I would like to change this anyway, even for literal arrays for
>> ffi, calls like
>> >>
>> >> mouseStateX: x y: y
>> >> > errorCode>
>> >> ^ self nbCall: #( Uint32 SDL_GetMouseState ( int* x , int* y ) )
>> >>
>> >> this will be reformatted to
>> >>
>> >> mouseStateX: x y: y
>> >> > 'errorCode'>
>> >> ^ self nbCall: #(#Uint32 #SDL_GetMouseState #(#int #* #x #, #int
>> #* #y))
>> >
>> >
>> > this is ugly… also, it breaks the spirit of UFFI where the purpose of
>> using the array literals to give a feeling close to the C method.
>> > I already told before I disagree with this reformatting…. So no, I’m
>> absolutely against forcing such kind of format.
>>
>> Where and when did you disagreed?
>> I always thought this behavior of the formatter was like that from the
>> beginning, and it wasn't changed afterward.
>>
>> My suggestion was, to change the formatter to *not* reformat these
>> literal arrays, so we could at least use a pragma like
>> 
>> And don't have to use quotes. Or the ugly literal array form #(3 #+ 4)
>>
>>
>> ah, then we agree :)
>>
>>
> Generally speaking, reformatting 16rF0F0 into 61680 is never going to be a
> good idea.
> Same for carefully aligned arrays
>   #(
>  #( 16r00 16r01 16r03 16rFF )
>  #( 16r00 16r01 16r03 16rFF )
>)
> or #[
> 16r00 16r01 16r03 16rFF
> 16r00 16r01 16r03 16rFF
>]
>

Pharo now uses RBParser and a formatter based on RBParsers AST-Nodes, and
here, at least the number format is preserved, but not the layout of
the array.

foo
|a b|
a := #[ 16r00 16r00 16rFF].
b := #(
   #(1 0 0)
   #(0 1 0)
   #(0 0 1)).

will be formatted to

foo
| a b |
a := #[16r00 16r00 16rFF].
b := #(#(1 0 0) #(0 1 0) #(0 0 1))



>
> The canonical representation for these is absolutely unhelpful for a human.
> The formatting expresses an intention (for example some data structure to
> which the Array will be mapped...).
> You can see plenty examples of things that should not be reformatted in
> VMMaker.
>
> >
>> > Esteban
>> >
>> >>
>> >>
>> >>
>> >>>
>> >>> >
>> >>> >Marcus
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> 

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Nicolas Cellier]

2016-09-19 19:14 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com>:

>
>
> 2016-09-19 17:08 GMT+02:00 Esteban Lorenzano :
>
>>
>> On 19 Sep 2016, at 16:49, Nicolai Hess  wrote:
>>
>>
>> Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano" <
>> esteba...@gmail.com>:
>> >
>> >
>> >> On 16 Sep 2016, at 21:45, Nicolai Hess  wrote:
>> >>
>> >>
>> >>
>> >> 2016-09-16 18:42 GMT+02:00 Eliot Miranda :
>> >>>
>> >>> Hi All,
>> >>>
>> >>>
>> >>>
>> >>> _,,,^..^,,,_ (phone)
>> >>> > On Sep 14, 2016, at 10:50 PM, Marcus Denker 
>> wrote:
>> >>> >
>> >>> >
>> >>> >>>
>> >>> >>> We can change it back and maybe add support for the reformatter
>> to not convert it to the literal array #(3 #+ 4) .
>> >>> >>
>> >>> >> I do not know in fact this is why I asked :)
>> >>> >> Now may be my idea to use pragma to get something like
>> pythondoctest is a bad idea
>> >>> >> but I really want to have literal programming.
>> >>> >> What do you think?
>> >>> > I like the idea to show examples/tests close to code, but pragmas
>> are not really good...
>> >>> >
>> >>> >> If we have ' ' then it would be good that the syntax higlighter
>> works with a special mode inside the ' '
>> >>> >
>> >>> > it is just a string. How do you know that it contains code?
>> >>> >
>> >>> > Would you highlight all string in all code as if it contained code?
>> Or would you add this just for
>> >>> > Pragmas? But even there, strings are string, not code.
>> >>> >
>> >>> > I think we can conclude that pragmas are not a good solution to the
>> problem, as they are far
>> >>> > too limited to express code.
>> >>>
>> >>> I think that's not a safe conclusion.  We know from Igor's use of
>> Kieran arrays for C signatures in the UFFI, and can easily extrapolate
>> here, that arbitrary Smalltalk expressions /can/ be expressed in literal
>> arrays.  S expressions work for lisp.
>> >>>
>> >>> In this particular case special casing pretty printing of literal
>> arrays in pragmas would be all that's needed to make the code look
>> beautiful.  Why throw the baby out with the bath water?  It would be so
>> easy to make this work well.
>> >>
>> >>
>> >> We can try this as well. And it is far more easier to work with this
>> expressions if they are pragma arguments, than to parse the comment to find
>> some code within.
>> >> On the other hand, it looks much nicer if we have the examples right
>> in the method doc. you have some text describing the method, some code,
>> some more text about the reslt.
>> >>
>> >>
>> >>>
>> >>>
>> >>> The only thing I'd do would be to print like this to make it clear
>> that the argument t is a literal Array and not some magic form of code:
>> >>>
>> >>>  
>> >>>
>> >>
>> >> Yes, I would like to change this anyway, even for literal arrays for
>> ffi, calls like
>> >>
>> >> mouseStateX: x y: y
>> >> > errorCode>
>> >> ^ self nbCall: #( Uint32 SDL_GetMouseState ( int* x , int* y ) )
>> >>
>> >> this will be reformatted to
>> >>
>> >> mouseStateX: x y: y
>> >> > 'errorCode'>
>> >> ^ self nbCall: #(#Uint32 #SDL_GetMouseState #(#int #* #x #, #int
>> #* #y))
>> >
>> >
>> > this is ugly… also, it breaks the spirit of UFFI where the purpose of
>> using the array literals to give a feeling close to the C method.
>> > I already told before I disagree with this reformatting…. So no, I’m
>> absolutely against forcing such kind of format.
>>
>> Where and when did you disagreed?
>> I always thought this behavior of the formatter was like that from the
>> beginning, and it wasn't changed afterward.
>>
>> My suggestion was, to change the formatter to *not* reformat these
>> literal arrays, so we could at least use a pragma like
>> 
>> And don't have to use quotes. Or the ugly literal array form #(3 #+ 4)
>>
>>
>> ah, then we agree :)
>>
>>
> Generally speaking, reformatting 16rF0F0 into 61680 is never going to be a
> good idea.
> Same for carefully aligned arrays
>   #(
>  #( 16r00 16r01 16r03 16rFF )
>  #( 16r00 16r01 16r03 16rFF )
>)
> or #[
> 16r00 16r01 16r03 16rFF
> 16r00 16r01 16r03 16rFF
>]
>
> The canonical representation for these is absolutely unhelpful for a human.
> The formatting expresses an intention (for example some data structure to
> which the Array will be mapped...).
> You can see plenty examples of things that should not be reformatted in
> VMMaker.
>
> And of course, it's not limited to literals.
These Integer methods are somehow understandable as long as human formatted:

swap8bytes
^( self << 56 bitAnd: 16rff00) bitOr:
  ((self << 40 bitAnd: 16rff) bitOr:
  ((self << 24 bitAnd: 16rff00) bitOr:
  ((self <<   8 bitAnd: 16rff) bitOr:
  ((self >>   8 bitAnd: 16rff00) bitOr:
  ((self >> 24 bitAnd: 16rff) bitOr:
  ((self >> 40 bitAnd: 16rff00) bitOr:
  ( self 

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Nicolas Cellier]

2016-09-19 17:08 GMT+02:00 Esteban Lorenzano :

>
> On 19 Sep 2016, at 16:49, Nicolai Hess  wrote:
>
>
> Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano"  >:
> >
> >
> >> On 16 Sep 2016, at 21:45, Nicolai Hess  wrote:
> >>
> >>
> >>
> >> 2016-09-16 18:42 GMT+02:00 Eliot Miranda :
> >>>
> >>> Hi All,
> >>>
> >>>
> >>>
> >>> _,,,^..^,,,_ (phone)
> >>> > On Sep 14, 2016, at 10:50 PM, Marcus Denker 
> wrote:
> >>> >
> >>> >
> >>> >>>
> >>> >>> We can change it back and maybe add support for the reformatter to
> not convert it to the literal array #(3 #+ 4) .
> >>> >>
> >>> >> I do not know in fact this is why I asked :)
> >>> >> Now may be my idea to use pragma to get something like
> pythondoctest is a bad idea
> >>> >> but I really want to have literal programming.
> >>> >> What do you think?
> >>> > I like the idea to show examples/tests close to code, but pragmas
> are not really good...
> >>> >
> >>> >> If we have ' ' then it would be good that the syntax higlighter
> works with a special mode inside the ' '
> >>> >
> >>> > it is just a string. How do you know that it contains code?
> >>> >
> >>> > Would you highlight all string in all code as if it contained code?
> Or would you add this just for
> >>> > Pragmas? But even there, strings are string, not code.
> >>> >
> >>> > I think we can conclude that pragmas are not a good solution to the
> problem, as they are far
> >>> > too limited to express code.
> >>>
> >>> I think that's not a safe conclusion.  We know from Igor's use of
> Kieran arrays for C signatures in the UFFI, and can easily extrapolate
> here, that arbitrary Smalltalk expressions /can/ be expressed in literal
> arrays.  S expressions work for lisp.
> >>>
> >>> In this particular case special casing pretty printing of literal
> arrays in pragmas would be all that's needed to make the code look
> beautiful.  Why throw the baby out with the bath water?  It would be so
> easy to make this work well.
> >>
> >>
> >> We can try this as well. And it is far more easier to work with this
> expressions if they are pragma arguments, than to parse the comment to find
> some code within.
> >> On the other hand, it looks much nicer if we have the examples right in
> the method doc. you have some text describing the method, some code, some
> more text about the reslt.
> >>
> >>
> >>>
> >>>
> >>> The only thing I'd do would be to print like this to make it clear
> that the argument t is a literal Array and not some magic form of code:
> >>>
> >>>  
> >>>
> >>
> >> Yes, I would like to change this anyway, even for literal arrays for
> ffi, calls like
> >>
> >> mouseStateX: x y: y
> >>  errorCode>
> >> ^ self nbCall: #( Uint32 SDL_GetMouseState ( int* x , int* y ) )
> >>
> >> this will be reformatted to
> >>
> >> mouseStateX: x y: y
> >>  'errorCode'>
> >> ^ self nbCall: #(#Uint32 #SDL_GetMouseState #(#int #* #x #, #int #*
> #y))
> >
> >
> > this is ugly… also, it breaks the spirit of UFFI where the purpose of
> using the array literals to give a feeling close to the C method.
> > I already told before I disagree with this reformatting…. So no, I’m
> absolutely against forcing such kind of format.
>
> Where and when did you disagreed?
> I always thought this behavior of the formatter was like that from the
> beginning, and it wasn't changed afterward.
>
> My suggestion was, to change the formatter to *not* reformat these literal
> arrays, so we could at least use a pragma like
> 
> And don't have to use quotes. Or the ugly literal array form #(3 #+ 4)
>
>
> ah, then we agree :)
>
>
Generally speaking, reformatting 16rF0F0 into 61680 is never going to be a
good idea.
Same for carefully aligned arrays
  #(
 #( 16r00 16r01 16r03 16rFF )
 #( 16r00 16r01 16r03 16rFF )
   )
or #[
16r00 16r01 16r03 16rFF
16r00 16r01 16r03 16rFF
   ]

The canonical representation for these is absolutely unhelpful for a human.
The formatting expresses an intention (for example some data structure to
which the Array will be mapped...).
You can see plenty examples of things that should not be reformatted in
VMMaker.

>
> > Esteban
> >
> >>
> >>
> >>
> >>>
> >>> >
> >>> >Marcus
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>>
> >>
> >
>
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Esteban Lorenzano]

> On 19 Sep 2016, at 16:49, Nicolai Hess  wrote:
> 
> 
> Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano"  >:
> >
> >
> >> On 16 Sep 2016, at 21:45, Nicolai Hess  >> > wrote:
> >>
> >>
> >>
> >> 2016-09-16 18:42 GMT+02:00 Eliot Miranda  >> >:
> >>>
> >>> Hi All,
> >>>
> >>>
> >>>
> >>> _,,,^..^,,,_ (phone)
> >>> > On Sep 14, 2016, at 10:50 PM, Marcus Denker  >>> > > wrote:
> >>> >
> >>> >
> >>> >>>
> >>> >>> We can change it back and maybe add support for the reformatter to 
> >>> >>> not convert it to the literal array #(3 #+ 4) .
> >>> >>
> >>> >> I do not know in fact this is why I asked :)
> >>> >> Now may be my idea to use pragma to get something like pythondoctest 
> >>> >> is a bad idea
> >>> >> but I really want to have literal programming.
> >>> >> What do you think?
> >>> > I like the idea to show examples/tests close to code, but pragmas are 
> >>> > not really good...
> >>> >
> >>> >> If we have ' ' then it would be good that the syntax higlighter works 
> >>> >> with a special mode inside the ' '
> >>> >
> >>> > it is just a string. How do you know that it contains code?
> >>> >
> >>> > Would you highlight all string in all code as if it contained code? Or 
> >>> > would you add this just for
> >>> > Pragmas? But even there, strings are string, not code.
> >>> >
> >>> > I think we can conclude that pragmas are not a good solution to the 
> >>> > problem, as they are far
> >>> > too limited to express code.
> >>>
> >>> I think that's not a safe conclusion.  We know from Igor's use of Kieran 
> >>> arrays for C signatures in the UFFI, and can easily extrapolate here, 
> >>> that arbitrary Smalltalk expressions /can/ be expressed in literal 
> >>> arrays.  S expressions work for lisp.
> >>>
> >>> In this particular case special casing pretty printing of literal arrays 
> >>> in pragmas would be all that's needed to make the code look beautiful.  
> >>> Why throw the baby out with the bath water?  It would be so easy to make 
> >>> this work well.
> >>
> >>
> >> We can try this as well. And it is far more easier to work with this 
> >> expressions if they are pragma arguments, than to parse the comment to 
> >> find some code within.
> >> On the other hand, it looks much nicer if we have the examples right in 
> >> the method doc. you have some text describing the method, some code, some 
> >> more text about the reslt.
> >>
> >>  
> >>>
> >>>
> >>> The only thing I'd do would be to print like this to make it clear that 
> >>> the argument t is a literal Array and not some magic form of code:
> >>>
> >>>  
> >>>
> >>
> >> Yes, I would like to change this anyway, even for literal arrays for ffi, 
> >> calls like
> >>
> >> mouseStateX: x y: y
> >>  >> errorCode>
> >> ^ self nbCall: #( Uint32 SDL_GetMouseState ( int* x , int* y ) )
> >>
> >> this will be reformatted to
> >>
> >> mouseStateX: x y: y
> >>  >> 'errorCode'>
> >> ^ self nbCall: #(#Uint32 #SDL_GetMouseState #(#int #* #x #, #int #* 
> >> #y))
> >
> >
> > this is ugly… also, it breaks the spirit of UFFI where the purpose of using 
> > the array literals to give a feeling close to the C method. 
> > I already told before I disagree with this reformatting…. So no, I’m 
> > absolutely against forcing such kind of format.
> 
> Where and when did you disagreed?
> I always thought this behavior of the formatter was like that from the 
> beginning, and it wasn't changed afterward.
> 
> My suggestion was, to change the formatter to *not* reformat these literal 
> arrays, so we could at least use a pragma like
> 
> And don't have to use quotes. Or the ugly literal array form #(3 #+ 4)
> 

ah, then we agree :)

> >
> > Esteban
> >
> >>
> >>
> >>  
> >>>
> >>> >
> >>> >Marcus
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>>
> >>
> >
> 

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Nicolai Hess]

Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano" :
>
>
>> On 16 Sep 2016, at 21:45, Nicolai Hess  wrote:
>>
>>
>>
>> 2016-09-16 18:42 GMT+02:00 Eliot Miranda :
>>>
>>> Hi All,
>>>
>>>
>>>
>>> _,,,^..^,,,_ (phone)
>>> > On Sep 14, 2016, at 10:50 PM, Marcus Denker 
wrote:
>>> >
>>> >
>>> >>>
>>> >>> We can change it back and maybe add support for the reformatter to
not convert it to the literal array #(3 #+ 4) .
>>> >>
>>> >> I do not know in fact this is why I asked :)
>>> >> Now may be my idea to use pragma to get something like pythondoctest
is a bad idea
>>> >> but I really want to have literal programming.
>>> >> What do you think?
>>> > I like the idea to show examples/tests close to code, but pragmas are
not really good...
>>> >
>>> >> If we have ' ' then it would be good that the syntax higlighter
works with a special mode inside the ' '
>>> >
>>> > it is just a string. How do you know that it contains code?
>>> >
>>> > Would you highlight all string in all code as if it contained code?
Or would you add this just for
>>> > Pragmas? But even there, strings are string, not code.
>>> >
>>> > I think we can conclude that pragmas are not a good solution to the
problem, as they are far
>>> > too limited to express code.
>>>
>>> I think that's not a safe conclusion.  We know from Igor's use of
Kieran arrays for C signatures in the UFFI, and can easily extrapolate
here, that arbitrary Smalltalk expressions /can/ be expressed in literal
arrays.  S expressions work for lisp.
>>>
>>> In this particular case special casing pretty printing of literal
arrays in pragmas would be all that's needed to make the code look
beautiful.  Why throw the baby out with the bath water?  It would be so
easy to make this work well.
>>
>>
>> We can try this as well. And it is far more easier to work with this
expressions if they are pragma arguments, than to parse the comment to find
some code within.
>> On the other hand, it looks much nicer if we have the examples right in
the method doc. you have some text describing the method, some code, some
more text about the reslt.
>>
>>
>>>
>>>
>>> The only thing I'd do would be to print like this to make it clear that
the argument t is a literal Array and not some magic form of code:
>>>
>>>  
>>>
>>
>> Yes, I would like to change this anyway, even for literal arrays for
ffi, calls like
>>
>> mouseStateX: x y: y
>> 
>> ^ self nbCall: #( Uint32 SDL_GetMouseState ( int* x , int* y ) )
>>
>> this will be reformatted to
>>
>> mouseStateX: x y: y
>> 
>> ^ self nbCall: #(#Uint32 #SDL_GetMouseState #(#int #* #x #, #int #*
#y))
>
>
> this is ugly… also, it breaks the spirit of UFFI where the purpose of
using the array literals to give a feeling close to the C method.
> I already told before I disagree with this reformatting…. So no, I’m
absolutely against forcing such kind of format.

Where and when did you disagreed?
I always thought this behavior of the formatter was like that from the
beginning, and it wasn't changed afterward.

My suggestion was, to change the formatter to *not* reformat these literal
arrays, so we could at least use a pragma like

And don't have to use quotes. Or the ugly literal array form #(3 #+ 4)

>
> Esteban
>
>>
>>
>>
>>>
>>> >
>>> >Marcus
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>
>

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Henrik Johansen]

> On 19 Sep 2016, at 4:03 , Henrik Johansen  
> wrote:
> 
>> 
>> On 17 Sep 2016, at 4:17 , Ben Coman > > wrote:
>> 
>> On Sat, Sep 17, 2016 at 3:45 AM, Nicolai Hess > > wrote:
>>> 
>>> 
>>> 2016-09-16 18:42 GMT+02:00 Eliot Miranda >> >:
 
 Hi All,
 
 
 
 _,,,^..^,,,_ (phone)
> On Sep 14, 2016, at 10:50 PM, Marcus Denker  >
> wrote:
> 
> 
>>> 
>>> We can change it back and maybe add support for the reformatter to not
>>> convert it to the literal array #(3 #+ 4) .
>> 
>> I do not know in fact this is why I asked :)
>> Now may be my idea to use pragma to get something like pythondoctest is
>> a bad idea
>> but I really want to have literal programming.
>> What do you think?
> I like the idea to show examples/tests close to code, but pragmas are
> not really good...
> 
>> If we have ' ' then it would be good that the syntax higlighter works
>> with a special mode inside the ' '
> 
> it is just a string. How do you know that it contains code?
> 
> Would you highlight all string in all code as if it contained code? Or
> would you add this just for
> Pragmas? But even there, strings are string, not code.
> 
> I think we can conclude that pragmas are not a good solution to the
> problem, as they are far
> too limited to express code.
 
 I think that's not a safe conclusion.  We know from Igor's use of Kieran
 arrays for C signatures in the UFFI, and can easily extrapolate here, that
 arbitrary Smalltalk expressions /can/ be expressed in literal arrays.  S
 expressions work for lisp.
 
 In this particular case special casing pretty printing of literal arrays
 in pragmas would be all that's needed to make the code look beautiful.  Why
 throw the baby out with the bath water?  It would be so easy to make this
 work well.
>>> 
>>> 
>>> We can try this as well. And it is far more easier to work with this
>>> expressions if they are pragma arguments, than to parse the comment to find
>>> some code within.
>>> On the other hand, it looks much nicer if we have the examples right in the
>>> method doc. you have some text describing the method, some code, some more
>>> text about the reslt.
>>> 
>>> 
 
 
 The only thing I'd do would be to print like this to make it clear that
 the argument t is a literal Array and not some magic form of code:
 
 
 
>>> 
>>> Yes, I would like to change this anyway, even for literal arrays for ffi,
>>> calls like
>>> 
>>> mouseStateX: x y: y
>>>>> errorCode>
>>>^ self nbCall: #( Uint32 SDL_GetMouseState ( int* x , int* y ) )
>>> 
>>> this will be reformatted to
>>> 
>>> mouseStateX: x y: y
>>>>> 'errorCode'>
>>>^ self nbCall: #(#Uint32 #SDL_GetMouseState #(#int #* #x #, #int #* #y))
>> 
>> errr, yuck!  Thats not pretty at all.  Is there some way to avoid
>> that?  As I've been getting started with FFI its been really nice
>> visually to see a *direct* correspondence between the C header file
>> declaration and the in-Image method.
> 
> +1, that's about the main thought behind it...
> As long as the only required use of a # inside of literal arrays is 
> differentiating whether something is a literal string or symbol, changing to 
> format *all* symbols using it seems somewhat overzealous.
> 
> Personally, if a solution using method properties/+ browser improvements to 
> show/create them in a good way is out of the question,
> I have a weakness for using empty blocks as method-local, syntax-highlighted 
> code comments (at least compared to special comment syntax, or pragmas backed 
> by a whole literal -> ST parser).
> Though lately, the code critic (rightly, and very usefully, in the cases 
> where it's a user error) points out they are dead code, and the IR optimizes 
> them out entirely, meaning they miss out on senders/implementors/refactorings 
> functionality. (Full blocks would potentially let us change the IR to leave 
> them alone, put them in the literal slot and be searchable, at no additional 
> runtime-cost/use in bytecodes)
> 
> Cheers,
> Henry

Now imagine if tags were scoped, and you could do

Number >>  #+ aNumber

[  3 + 4 == 7 ].
^self fallbackAdd: aNumber

And have the browser pick it up, and either
- collapse it
- display text with alpha < 1

Make the code critic aware as well, and no more warnings of unused blocks when 
used for examples!

Cheers,
Henry


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Esteban Lorenzano]

> On 16 Sep 2016, at 21:45, Nicolai Hess  wrote:
> 
> 
> 
> 2016-09-16 18:42 GMT+02:00 Eliot Miranda  >:
> Hi All,
> 
> 
> 
> _,,,^..^,,,_ (phone)
> > On Sep 14, 2016, at 10:50 PM, Marcus Denker  > > wrote:
> >
> >
> >>>
> >>> We can change it back and maybe add support for the reformatter to not 
> >>> convert it to the literal array #(3 #+ 4) .
> >>
> >> I do not know in fact this is why I asked :)
> >> Now may be my idea to use pragma to get something like pythondoctest is a 
> >> bad idea
> >> but I really want to have literal programming.
> >> What do you think?
> > I like the idea to show examples/tests close to code, but pragmas are not 
> > really good...
> >
> >> If we have ' ' then it would be good that the syntax higlighter works with 
> >> a special mode inside the ' '
> >
> > it is just a string. How do you know that it contains code?
> >
> > Would you highlight all string in all code as if it contained code? Or 
> > would you add this just for
> > Pragmas? But even there, strings are string, not code.
> >
> > I think we can conclude that pragmas are not a good solution to the 
> > problem, as they are far
> > too limited to express code.
> 
> I think that's not a safe conclusion.  We know from Igor's use of Kieran 
> arrays for C signatures in the UFFI, and can easily extrapolate here, that 
> arbitrary Smalltalk expressions /can/ be expressed in literal arrays.  S 
> expressions work for lisp.
> 
> In this particular case special casing pretty printing of literal arrays in 
> pragmas would be all that's needed to make the code look beautiful.  Why 
> throw the baby out with the bath water?  It would be so easy to make this 
> work well.
> 
> We can try this as well. And it is far more easier to work with this 
> expressions if they are pragma arguments, than to parse the comment to find 
> some code within.
> On the other hand, it looks much nicer if we have the examples right in the 
> method doc. you have some text describing the method, some code, some more 
> text about the reslt.
> 
>  
> 
> The only thing I'd do would be to print like this to make it clear that the 
> argument t is a literal Array and not some magic form of code:
> 
>  
> 
> 
> Yes, I would like to change this anyway, even for literal arrays for ffi, 
> calls like
> 
> mouseStateX: x y: y
>  errorCode>
> ^ self nbCall: #( Uint32 SDL_GetMouseState ( int* x , int* y ) )
> 
> this will be reformatted to
> 
> mouseStateX: x y: y
>  'errorCode'>
> ^ self nbCall: #(#Uint32 #SDL_GetMouseState #(#int #* #x #, #int #* #y))

this is ugly… also, it breaks the spirit of UFFI where the purpose of using the 
array literals to give a feeling close to the C method. 
I already told before I disagree with this reformatting…. So no, I’m absolutely 
against forcing such kind of format.

Esteban

> 
> 
>  
> >
> >Marcus
> >
> >
> >
> >
> >
> >
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Henrik Johansen]

> On 17 Sep 2016, at 4:17 , Ben Coman  wrote:
> 
> On Sat, Sep 17, 2016 at 3:45 AM, Nicolai Hess  > wrote:
>> 
>> 
>> 2016-09-16 18:42 GMT+02:00 Eliot Miranda :
>>> 
>>> Hi All,
>>> 
>>> 
>>> 
>>> _,,,^..^,,,_ (phone)
 On Sep 14, 2016, at 10:50 PM, Marcus Denker 
 wrote:
 
 
>> 
>> We can change it back and maybe add support for the reformatter to not
>> convert it to the literal array #(3 #+ 4) .
> 
> I do not know in fact this is why I asked :)
> Now may be my idea to use pragma to get something like pythondoctest is
> a bad idea
> but I really want to have literal programming.
> What do you think?
 I like the idea to show examples/tests close to code, but pragmas are
 not really good...
 
> If we have ' ' then it would be good that the syntax higlighter works
> with a special mode inside the ' '
 
 it is just a string. How do you know that it contains code?
 
 Would you highlight all string in all code as if it contained code? Or
 would you add this just for
 Pragmas? But even there, strings are string, not code.
 
 I think we can conclude that pragmas are not a good solution to the
 problem, as they are far
 too limited to express code.
>>> 
>>> I think that's not a safe conclusion.  We know from Igor's use of Kieran
>>> arrays for C signatures in the UFFI, and can easily extrapolate here, that
>>> arbitrary Smalltalk expressions /can/ be expressed in literal arrays.  S
>>> expressions work for lisp.
>>> 
>>> In this particular case special casing pretty printing of literal arrays
>>> in pragmas would be all that's needed to make the code look beautiful.  Why
>>> throw the baby out with the bath water?  It would be so easy to make this
>>> work well.
>> 
>> 
>> We can try this as well. And it is far more easier to work with this
>> expressions if they are pragma arguments, than to parse the comment to find
>> some code within.
>> On the other hand, it looks much nicer if we have the examples right in the
>> method doc. you have some text describing the method, some code, some more
>> text about the reslt.
>> 
>> 
>>> 
>>> 
>>> The only thing I'd do would be to print like this to make it clear that
>>> the argument t is a literal Array and not some magic form of code:
>>> 
>>> 
>>> 
>> 
>> Yes, I would like to change this anyway, even for literal arrays for ffi,
>> calls like
>> 
>> mouseStateX: x y: y
>>> errorCode>
>>^ self nbCall: #( Uint32 SDL_GetMouseState ( int* x , int* y ) )
>> 
>> this will be reformatted to
>> 
>> mouseStateX: x y: y
>>> 'errorCode'>
>>^ self nbCall: #(#Uint32 #SDL_GetMouseState #(#int #* #x #, #int #* #y))
> 
> errr, yuck!  Thats not pretty at all.  Is there some way to avoid
> that?  As I've been getting started with FFI its been really nice
> visually to see a *direct* correspondence between the C header file
> declaration and the in-Image method.

+1, that's about the main thought behind it...
As long as the only required use of a # inside of literal arrays is 
differentiating whether something is a literal string or symbol, changing to 
format *all* symbols using it seems somewhat overzealous.

Personally, if a solution using method properties/+ browser improvements to 
show/create them in a good way is out of the question,
I have a weakness for using empty blocks as method-local, syntax-highlighted 
code comments (at least compared to special comment syntax, or pragmas backed 
by a whole literal -> ST parser).
Though lately, the code critic (rightly, and very usefully, in the cases where 
it's a user error) points out they are dead code, and the IR optimizes them out 
entirely, meaning they miss out on senders/implementors/refactorings 
functionality. (Full blocks would potentially let us change the IR to leave 
them alone, put them in the literal slot and be searchable, at no additional 
runtime-cost/use in bytecodes)

Cheers,
Henry


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] [pharo-project/pharo-core] 4d8aa6: 60226

[stepharo]

2016-09-15 22:11 GMT+02:00 stepharo >:


This change break the miniimage. I will check with pavel.

Stef



This is now the second time the
method
SingleCodeCriticResultList>>#setTextModelForTransformationRule:
vanished

see case 19079 
 
CriticBrowser can not show result for transformation rules anymore (DNU)

and
case 19055 
 More 
iconNamed: cleaning


what happens here ?


I do not know.
When I work with the icon I just work on what is in the image.
Yuiriy do you have an idea?
May be there is a problem with a class extension of something like that.
Stef





Le 15/9/16 à 22:05, GitHub a écrit :

   Branch: refs/heads/6.0
   Home: https://github.com/pharo-project/pharo-core

   Commit: 4d8aa66f6cb150f6aef66a9d807106bb89404cf5

https://github.com/pharo-project/pharo-core/commit/4d8aa66f6cb150f6aef66a9d807106bb89404cf5


   Author: Jenkins Build Server >
   Date:   2016-09-15 (Thu, 15 Sep 2016)

   Changed paths:
 M

FontChooser.package/AbstractFontSelectorDialogWindow.class/class/icons/taskbarIcon.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousAccept.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousAdd.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousAlarm.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousBookmark.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousBrowse.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousBug.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousCancel.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousClose.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousDown.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousDropDown.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousEdit.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousExample.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousFolder.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousGo.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousGrayCircle.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousGrayCircleEmpty.st

 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousGreenCircle.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousHelp.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousInspect.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousInto.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousLargeGrayCircleEmphasized.st

 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousLeft.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousLeftSide.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousMore.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousOpen.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousOpenFromUrl.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousOver.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousPlay.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRedCircle.st
 M

Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRedo.st
 M

Re: [Pharo-dev] [pharo-project/pharo-core] 4d8aa6: 60226

[Nicolai Hess]

2016-09-15 22:11 GMT+02:00 stepharo :

> This change break the miniimage. I will check with pavel.
>
> Stef
>
>

This is now the second time the
method
SingleCodeCriticResultList>>#setTextModelForTransformationRule:
vanished

see case 19079

CriticBrowser can not show result for transformation rules anymore (DNU)
and
case 19055 
More iconNamed: cleaning

what happens here ?



>
> Le 15/9/16 à 22:05, GitHub a écrit :
>
>Branch: refs/heads/6.0
>>Home:   https://github.com/pharo-project/pharo-core
>>Commit: 4d8aa66f6cb150f6aef66a9d807106bb89404cf5
>>https://github.com/pharo-project/pharo-core/commit/4d8aa66f
>> 6cb150f6aef66a9d807106bb89404cf5
>>Author: Jenkins Build Server 
>>Date:   2016-09-15 (Thu, 15 Sep 2016)
>>
>>Changed paths:
>>  M FontChooser.package/AbstractFontSelectorDialogWindow.class/
>> class/icons/taskbarIcon.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousAccept.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousAdd.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousAlarm.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousBookmark.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousBrowse.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousBug.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousCancel.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousClose.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousDown.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousDropDown.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousEdit.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousExample.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousFolder.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousGo.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousGrayCircle.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousGrayCircleEmpty.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousGreenCircle.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousHelp.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousInspect.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousInto.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousLargeGrayCircleEmphasized.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousLeft.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousLeftSide.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousMore.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousOpen.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousOpenFromUrl.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousOver.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousPlay.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousRedCircle.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousRedo.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousRefresh.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousRemove.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousRestart.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousRight.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousRightSide.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousSave.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousSaveToUrl.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousSearch.st
>> 

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Ben Coman]

On Sat, Sep 17, 2016 at 3:45 AM, Nicolai Hess  wrote:
>
>
> 2016-09-16 18:42 GMT+02:00 Eliot Miranda :
>>
>> Hi All,
>>
>>
>>
>> _,,,^..^,,,_ (phone)
>> > On Sep 14, 2016, at 10:50 PM, Marcus Denker 
>> > wrote:
>> >
>> >
>> >>>
>> >>> We can change it back and maybe add support for the reformatter to not
>> >>> convert it to the literal array #(3 #+ 4) .
>> >>
>> >> I do not know in fact this is why I asked :)
>> >> Now may be my idea to use pragma to get something like pythondoctest is
>> >> a bad idea
>> >> but I really want to have literal programming.
>> >> What do you think?
>> > I like the idea to show examples/tests close to code, but pragmas are
>> > not really good...
>> >
>> >> If we have ' ' then it would be good that the syntax higlighter works
>> >> with a special mode inside the ' '
>> >
>> > it is just a string. How do you know that it contains code?
>> >
>> > Would you highlight all string in all code as if it contained code? Or
>> > would you add this just for
>> > Pragmas? But even there, strings are string, not code.
>> >
>> > I think we can conclude that pragmas are not a good solution to the
>> > problem, as they are far
>> > too limited to express code.
>>
>> I think that's not a safe conclusion.  We know from Igor's use of Kieran
>> arrays for C signatures in the UFFI, and can easily extrapolate here, that
>> arbitrary Smalltalk expressions /can/ be expressed in literal arrays.  S
>> expressions work for lisp.
>>
>> In this particular case special casing pretty printing of literal arrays
>> in pragmas would be all that's needed to make the code look beautiful.  Why
>> throw the baby out with the bath water?  It would be so easy to make this
>> work well.
>
>
> We can try this as well. And it is far more easier to work with this
> expressions if they are pragma arguments, than to parse the comment to find
> some code within.
> On the other hand, it looks much nicer if we have the examples right in the
> method doc. you have some text describing the method, some code, some more
> text about the reslt.
>
>
>>
>>
>> The only thing I'd do would be to print like this to make it clear that
>> the argument t is a literal Array and not some magic form of code:
>>
>>  
>>
>
> Yes, I would like to change this anyway, even for literal arrays for ffi,
> calls like
>
> mouseStateX: x y: y
>  errorCode>
> ^ self nbCall: #( Uint32 SDL_GetMouseState ( int* x , int* y ) )
>
> this will be reformatted to
>
> mouseStateX: x y: y
>  'errorCode'>
> ^ self nbCall: #(#Uint32 #SDL_GetMouseState #(#int #* #x #, #int #* #y))

errr, yuck!  Thats not pretty at all.  Is there some way to avoid
that?  As I've been getting started with FFI its been really nice
visually to see a *direct* correspondence between the C header file
declaration and the in-Image method.  Actually I think it would be
useful to go a step further to have positional rather than named
parameters for FFI methods.  At the moment the method names still end
up a bit mangled.  This seems feasible since currently an
open-round-bracket is invalid syntax if not preceded by an assignment
or colon.

e.g.
myvar := (a + b).   "okay"
self setVar: (a + b).  "okay"
self setVar( a + b ).  "currently invalid syntax - but could could
represent an FFI call"

defined like...
SomeLibrary class >> setVar( newValue )
^ self ffiCall: #( int setVar ( int newValue )

But I expect its not something we'd want to leap into.

cheers -ben

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Nicolai Hess]

2016-09-16 18:42 GMT+02:00 Eliot Miranda :

> Hi All,
>
>
>
> _,,,^..^,,,_ (phone)
> > On Sep 14, 2016, at 10:50 PM, Marcus Denker 
> wrote:
> >
> >
> >>>
> >>> We can change it back and maybe add support for the reformatter to not
> convert it to the literal array #(3 #+ 4) .
> >>
> >> I do not know in fact this is why I asked :)
> >> Now may be my idea to use pragma to get something like pythondoctest is
> a bad idea
> >> but I really want to have literal programming.
> >> What do you think?
> > I like the idea to show examples/tests close to code, but pragmas are
> not really good...
> >
> >> If we have ' ' then it would be good that the syntax higlighter works
> with a special mode inside the ' '
> >
> > it is just a string. How do you know that it contains code?
> >
> > Would you highlight all string in all code as if it contained code? Or
> would you add this just for
> > Pragmas? But even there, strings are string, not code.
> >
> > I think we can conclude that pragmas are not a good solution to the
> problem, as they are far
> > too limited to express code.
>
> I think that's not a safe conclusion.  We know from Igor's use of Kieran
> arrays for C signatures in the UFFI, and can easily extrapolate here, that
> arbitrary Smalltalk expressions /can/ be expressed in literal arrays.  S
> expressions work for lisp.
>
> In this particular case special casing pretty printing of literal arrays
> in pragmas would be all that's needed to make the code look beautiful.  Why
> throw the baby out with the bath water?  It would be so easy to make this
> work well.
>

We can try this as well. And it is far more easier to work with this
expressions if they are pragma arguments, than to parse the comment to find
some code within.
On the other hand, it looks much nicer if we have the examples right in the
method doc. you have some text describing the method, some code, some more
text about the reslt.



>
> The only thing I'd do would be to print like this to make it clear that
> the argument t is a literal Array and not some magic form of code:
>
>  
>
>
Yes, I would like to change this anyway, even for literal arrays for ffi,
calls like

mouseStateX: x y: y

^ self nbCall: #( Uint32 SDL_GetMouseState ( int* x , int* y ) )

this will be reformatted to

mouseStateX: x y: y

^ self nbCall: #(#Uint32 #SDL_GetMouseState #(#int #* #x #, #int #* #y))




> >
> >Marcus
> >
> >
> >
> >
> >
> >
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Eliot Miranda]

Hi All,



_,,,^..^,,,_ (phone)
> On Sep 14, 2016, at 10:50 PM, Marcus Denker  wrote:
> 
> 
>>> 
>>> We can change it back and maybe add support for the reformatter to not 
>>> convert it to the literal array #(3 #+ 4) .
>> 
>> I do not know in fact this is why I asked :)
>> Now may be my idea to use pragma to get something like pythondoctest is a 
>> bad idea 
>> but I really want to have literal programming.
>> What do you think?
> I like the idea to show examples/tests close to code, but pragmas are not 
> really good...
> 
>> If we have ' ' then it would be good that the syntax higlighter works with a 
>> special mode inside the ' '
> 
> it is just a string. How do you know that it contains code? 
> 
> Would you highlight all string in all code as if it contained code? Or would 
> you add this just for
> Pragmas? But even there, strings are string, not code.
> 
> I think we can conclude that pragmas are not a good solution to the problem, 
> as they are far
> too limited to express code.

I think that's not a safe conclusion.  We know from Igor's use of Kieran arrays 
for C signatures in the UFFI, and can easily extrapolate here, that arbitrary 
Smalltalk expressions /can/ be expressed in literal arrays.  S expressions work 
for lisp.

In this particular case special casing pretty printing of literal arrays in 
pragmas would be all that's needed to make the code look beautiful.  Why throw 
the baby out with the bath water?  It would be so easy to make this work well.

The only thing I'd do would be to print like this to make it clear that the 
argument t is a literal Array and not some magic form of code:

 

> 
>Marcus
> 
> 
> 
> 
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] 4d8aa6: 60226

[Pavel Krivanek]

error not related, build works well after restart

-- Pavel

2016-09-15 22:11 GMT+02:00 stepharo :

> This change break the miniimage. I will check with pavel.
>
> Stef
>
>
> Le 15/9/16 à 22:05, GitHub a écrit :
>
>Branch: refs/heads/6.0
>>Home:   https://github.com/pharo-project/pharo-core
>>Commit: 4d8aa66f6cb150f6aef66a9d807106bb89404cf5
>>https://github.com/pharo-project/pharo-core/commit/4d8aa66f
>> 6cb150f6aef66a9d807106bb89404cf5
>>Author: Jenkins Build Server 
>>Date:   2016-09-15 (Thu, 15 Sep 2016)
>>
>>Changed paths:
>>  M FontChooser.package/AbstractFontSelectorDialogWindow.class/
>> class/icons/taskbarIcon.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousAccept.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousAdd.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousAlarm.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousBookmark.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousBrowse.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousBug.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousCancel.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousClose.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousDown.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousDropDown.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousEdit.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousExample.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousFolder.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousGo.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousGrayCircle.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousGrayCircleEmpty.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousGreenCircle.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousHelp.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousInspect.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousInto.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousLargeGrayCircleEmphasized.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousLeft.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousLeftSide.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousMore.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousOpen.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousOpenFromUrl.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousOver.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousPlay.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousRedCircle.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousRedo.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousRefresh.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousRemove.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousRestart.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousRight.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousRightSide.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousSave.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousSaveToUrl.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousSearch.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousSpawn.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousThrough.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> ss/icons/glamorousTrash.st
>>  M Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/cla
>> 

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Thierry Goubier]

2016-09-16 8:54 GMT+02:00 stepharo :

>
> Furthermore, typical examples require more than one liners, and these
>> should be factored out separately.
>>
>
> I really like the one liners that you can find im some method comments,
> like in Color class>>#wheel:
> if you are new to pharo and start exploring the system, it makes fun to
> see these little one lines and
> just execute it. (even if they aren't onelines like in some method in
> class Form).
>
>
> Me too and what I like is that there are coupled to the method.
> I find a method and I guess it will help me
> and bam I read the example and I'm sure it is or not what I'm looking for.
>

My belief is that we have an IDE able to track metadata (here, examples)
along with methods, and that there is no need to play with syntax
extensions (which are a way of adding metadata to programming languages
stuck in the file concept of the 60's).

In short, a nice, OO way of adding information about a method / class / tag
/ package that the IDE knows how to relate to the code.

Having the class comment pane open in Nautilus is already a step towards
doing that.

Regards,

Thierry


>
> Stef
>
>
>
>>
>> Cheers,
>> Doru
>>
>>
>> >
>> >   Marcus
>> >
>> >
>> >
>> >
>> >
>> >
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Every thing should have the right to be different."
>>
>>
>>
>>
>>
>>
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[stepharo]

Furthermore, typical examples require more than one liners, and
these should be factored out separately.


I really like the one liners that you can find im some method 
comments, like in Color class>>#wheel:
if you are new to pharo and start exploring the system, it makes fun 
to see these little one lines and
just execute it. (even if they aren't onelines like in some method in 
class Form).


Me too and what I like is that there are coupled to the method.
I find a method and I guess it will help me
and bam I read the example and I'm sure it is or not what I'm looking for.

Stef



Cheers,
Doru


>
>   Marcus
>
>
>
>
>
>

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

"Every thing should have the right to be different."

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[stepharo]

So, until know, I didn't really know what pythondoctest is about.  I 
first thought the "test" is about unit tests
and thought our way how we can generate or jump from methods to the 
corresponding is better,
but know I understand that it is about "perform regression testing by 
verifying that interactive examples are working"

And that is of course a good idea.


To me this is more than that.
This is having simple scenario always validated and in front of my nose 
when I read the code.






If we have ' ' then it would be good that the syntax higlighter
works with a special mode inside the ' '


Not for pragma arguments, I think this would be confusing.

Yes I cam to the same conclusion than marcus.


I did some expreiments with formatting code in comments. I 'll write 
shortly about it.





nicolai



Stef


  60220
19086 do not allow expressions as pragma arguments
https://pharo.fogbugz.com/f/cases/19086

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Tudor Girba]

Hi,

> On Sep 15, 2016, at 10:16 PM, Nicolai Hess  wrote:
> 
> 
> 
> 2016-09-15 8:12 GMT+02:00 Tudor Girba :
> Hi,
> 
> > On Sep 15, 2016, at 7:50 AM, Marcus Denker  wrote:
> >
> >
> >>>
> >>> We can change it back and maybe add support for the reformatter to not 
> >>> convert it to the literal array #(3 #+ 4) .
> >>
> >> I do not know in fact this is why I asked :)
> >> Now may be my idea to use pragma to get something like pythondoctest is a 
> >> bad idea
> >> but I really want to have literal programming.
> >> What do you think?
> >>
> > I like the idea to show examples/tests close to code, but pragmas are not 
> > really good...
> >
> >> If we have ' ' then it would be good that the syntax higlighter works with 
> >> a special mode inside the ' '
> >
> > it is just a string. How do you know that it contains code?
> >
> > Would you highlight all string in all code as if it contained code? Or 
> > would you add this just for
> > Pragmas? But even there, strings are string, not code.
> >
> > I think we can conclude that pragmas are not a good solution to the 
> > problem, as they are far
> > too limited to express code.
> 
> I second that.
> 
> Furthermore, typical examples require more than one liners, and these should 
> be factored out separately.
> 
> I really like the one liners that you can find im some method comments, like 
> in Color class>>#wheel:
> if you are new to pharo and start exploring the system, it makes fun to see 
> these little one lines and
> just execute it. (even if they aren't onelines like in some method in class 
> Form).
> 

I like one liners, too. But, should a documentation mechanism be confined to 
only work with small examples?

Cheers,
Doru


> Cheers,
> Doru
> 
> 
> >
> >   Marcus
> >
> >
> >
> >
> >
> >
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Every thing should have the right to be different."

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

"Reasonable is what we are accustomed with."

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Nicolai Hess]

2016-09-15 8:12 GMT+02:00 Tudor Girba :

> Hi,
>
> > On Sep 15, 2016, at 7:50 AM, Marcus Denker 
> wrote:
> >
> >
> >>>
> >>> We can change it back and maybe add support for the reformatter to not
> convert it to the literal array #(3 #+ 4) .
> >>
> >> I do not know in fact this is why I asked :)
> >> Now may be my idea to use pragma to get something like pythondoctest is
> a bad idea
> >> but I really want to have literal programming.
> >> What do you think?
> >>
> > I like the idea to show examples/tests close to code, but pragmas are
> not really good...
> >
> >> If we have ' ' then it would be good that the syntax higlighter works
> with a special mode inside the ' '
> >
> > it is just a string. How do you know that it contains code?
> >
> > Would you highlight all string in all code as if it contained code? Or
> would you add this just for
> > Pragmas? But even there, strings are string, not code.
> >
> > I think we can conclude that pragmas are not a good solution to the
> problem, as they are far
> > too limited to express code.
>
> I second that.
>
> Furthermore, typical examples require more than one liners, and these
> should be factored out separately.
>

I really like the one liners that you can find im some method comments,
like in Color class>>#wheel:
if you are new to pharo and start exploring the system, it makes fun to see
these little one lines and
just execute it. (even if they aren't onelines like in some method in class
Form).


>
> Cheers,
> Doru
>
>
> >
> >   Marcus
> >
> >
> >
> >
> >
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Every thing should have the right to be different."
>
>
>
>
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Nicolai Hess]

2016-09-14 21:24 GMT+02:00 stepharo :

>
> Hi nicolai
>>
>> Why we should not accept
>>
>> foo
>> 
>> ^ self
>>
>> and be forced to put around ''
>>
>> foo
>> < func: '(3+4)' res: 0 >
>> ^ self
>>
>> I understand that we store literal but why you do not like it :).
>>
>
> First of all, the old compiler did not accept this. And I am a bit
> sensitive about changes, we allow a different syntax
> just because RB happens  to allow this (and maybe no one knows why or it
> just does not happens on purpose).
>
>
> valid point.
>
>
> And another reason, even without my fix, if we don't put quotes around
> that expression, the reformatting the source will convert this to:
>
> foo
> 
> ^ self
>
> What I noticed is that I could not write
>
>  foo
> 
>
> but it worked when I put () so I did it in the new code I wrote.
>
> And, even if (3+4) looks like an expression, it is just a list of literals
> something like this:
>
> foo
> 
> ^ self
>
> would be allowed too.
>
> This one is ugly
>
> But of course this is only my own opinion :)
>
> We can change it back and maybe add support for the reformatter to not
> convert it to the literal array #(3 #+ 4) .
>
>
> I do not know in fact this is why I asked :)
> Now may be my idea to use pragma to get something like pythondoctest is a
> bad idea
> but I really want to have literal programming.
> What do you think?
>

So, until know, I didn't really know what pythondoctest is about.  I first
thought the "test" is about unit tests
and thought our way how we can generate or jump from methods to the
corresponding is better,
but know I understand that it is about "perform regression testing by
verifying that interactive examples are working"
And that is of course a good idea.



>
> If we have ' ' then it would be good that the syntax higlighter works with
> a special mode inside the ' '
>

Not for pragma arguments, I think this would be confusing.

I did some expreiments with formatting code in comments. I 'll write
shortly about it.

>
>
> nicolai
>
>
>
>> Stef
>>
>>
>>   60220
>>> 19086 do not allow expressions as pragma arguments
>>> https://pharo.fogbugz.com/f/cases/19086
>>>
>>
>>
>>
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] 4d8aa6: 60226

[stepharo]

This change break the miniimage. I will check with pavel.

Stef


Le 15/9/16 à 22:05, GitHub a écrit :

   Branch: refs/heads/6.0
   Home:   https://github.com/pharo-project/pharo-core
   Commit: 4d8aa66f6cb150f6aef66a9d807106bb89404cf5
   
https://github.com/pharo-project/pharo-core/commit/4d8aa66f6cb150f6aef66a9d807106bb89404cf5
   Author: Jenkins Build Server 
   Date:   2016-09-15 (Thu, 15 Sep 2016)

   Changed paths:
 M 
FontChooser.package/AbstractFontSelectorDialogWindow.class/class/icons/taskbarIcon.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousAccept.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousAdd.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousAlarm.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousBookmark.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousBrowse.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousBug.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousCancel.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousClose.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousDown.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousDropDown.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousEdit.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousExample.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousFolder.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousGo.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousGrayCircle.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousGrayCircleEmpty.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousGreenCircle.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousHelp.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousInspect.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousInto.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousLargeGrayCircleEmphasized.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousLeft.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousLeftSide.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousMore.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousOpen.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousOpenFromUrl.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousOver.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousPlay.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRedCircle.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRedo.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRefresh.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRemove.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRestart.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRight.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRightSide.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousSave.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousSaveToUrl.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousSearch.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousSpawn.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousThrough.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousTrash.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousUndo.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousUp.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousZoomIn.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousZoomOut.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousZoomToFit.st
 M 

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Tudor Girba]

Hi,

Given the current interest, I am raising the issue of GTExample again.

I sent a while ago a thorough description of the current solution:
http://gtoolkit.org/doc/Examples/examples.html

The goal is to provide documentation for all methods and classes both by 
allowing simple examples (plain unary methods) and offering the potential of 
doing more than just simple things.

Except for Nicolai, there was no other feedback. Is there an interest to have a 
conversation about it?

Cheers,
Doru


> On Sep 15, 2016, at 8:40 PM, stepharo  wrote:
> 
>>> Would you highlight all string in all code as if it contained code? Or 
>>> would you add this just for
>>> Pragmas? But even there, strings are string, not code.
> and then? you try and if it failed then in not code and you do not highlight 
> it.
> KISS. No?
>>> I think we can conclude that pragmas are not a good solution to the 
>>> problem, as they are far
>>> too limited to express code.
>> I second that.
>> Furthermore, typical examples require more than one liners, and these should 
>> be factored out separately.
> 
> I'm talking about
> 
> basename
>"Returns the base of the basename,
>i.e.
>/foo/gloops.taz basename is 'gloops.taz'
>/ basename is '/'"
> 
> I do not think that it makes sense to have a separate example for this.
> Because you want to read everything
> 
> 
> I do not see why the following would not work.
> basename
>"Returns the base of the basename"
>  'gloops.taz'>
> 
> Now I hate the extra ' for strings.
> We should invent a syntax to be put inside comments and that we can easily 
> parse because we need to improve
> the use and discovery of the library.
> 
> basename
>"Returns the base of the basename"
>"
>'/foo/gloops.taz' asFileReference basename
>>>> 'gloops.taz'
>"
> 
> I cannot not do anything and just complain that our methods are not that well 
> documented.
> We as a community should take this and build an super cool system.
> 
> 
> 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] [pharo-project/pharo-core] edd9f3: 60220

[stepharo]

Would you highlight all string in all code as if it contained code? Or would 
you add this just for
Pragmas? But even there, strings are string, not code.
and then? you try and if it failed then in not code and you do not 
highlight it.

KISS. No?

I think we can conclude that pragmas are not a good solution to the problem, as 
they are far
too limited to express code.

I second that.
Furthermore, typical examples require more than one liners, and these should be 
factored out separately.


I'm talking about

basename
"Returns the base of the basename,
i.e.
/foo/gloops.taz basename is 'gloops.taz'
/ basename is '/'"

I do not think that it makes sense to have a separate example for this.
Because you want to read everything


I do not see why the following would not work.
basename
"Returns the base of the basename"
 'gloops.taz'>


Now I hate the extra ' for strings.
We should invent a syntax to be put inside comments and that we can 
easily parse because we need to improve

the use and discovery of the library.

basename
"Returns the base of the basename"
"
'/foo/gloops.taz' asFileReference basename
>>> 'gloops.taz'
"

I cannot not do anything and just complain that our methods are not that 
well documented.

We as a community should take this and build an super cool system.


Stef

Re: [Pharo-dev] [pharo-project/pharo-core] 770d9c: 60222

[Marcus Denker]

> 
>  Log Message:
>  ---
>  60222
> 19085 Integrate Epicea 8
>   https://pharo.fogbugz.com/f/cases/19085


This is a big sync with Epicea, fixing and improving many things.

Change log:

- Pass on UI + search more consistent names (e.g. session -> log).

- Replace "Session Browser" by "Log Set" from EpiceaHiedra experimental package.

- Add EpMonitorModel, to manipulate EpMonitor via UI.

- Rename: apply/revert instead of redo/undo.

- Fix 18946: package does not exist when a category removal is announced.

- Fixes for Dark theme.

- Avoid using #name in some cases.

- Make EpLogBrowser composable (it needs to be correctly initialized when 
created with #new).

- Optimization: reuse entryReader with an instance variable.

- Encapsulate morph creation to a new class: EpMorphFactory.

- Delete Trait issue (case 19045): Avoid sending #name to nil.

- Add EpMonitor>>debug setting

- Ombu writing entries: Do not catch all Error but FileException.

- Ombu: Move writing error handling to EpMonitor.

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Tudor Girba]

Hi,

> On Sep 15, 2016, at 7:50 AM, Marcus Denker  wrote:
> 
> 
>>> 
>>> We can change it back and maybe add support for the reformatter to not 
>>> convert it to the literal array #(3 #+ 4) .
>> 
>> I do not know in fact this is why I asked :)
>> Now may be my idea to use pragma to get something like pythondoctest is a 
>> bad idea 
>> but I really want to have literal programming.
>> What do you think?
>> 
> I like the idea to show examples/tests close to code, but pragmas are not 
> really good...
> 
>> If we have ' ' then it would be good that the syntax higlighter works with a 
>> special mode inside the ' ' 
> 
> it is just a string. How do you know that it contains code? 
> 
> Would you highlight all string in all code as if it contained code? Or would 
> you add this just for
> Pragmas? But even there, strings are string, not code.
> 
> I think we can conclude that pragmas are not a good solution to the problem, 
> as they are far
> too limited to express code.

I second that.

Furthermore, typical examples require more than one liners, and these should be 
factored out separately.

Cheers,
Doru


> 
>   Marcus
> 
> 
> 
> 
> 
> 

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

"Every thing should have the right to be different."

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Marcus Denker]

>> 
>> We can change it back and maybe add support for the reformatter to not 
>> convert it to the literal array #(3 #+ 4) .
> 
> I do not know in fact this is why I asked :)
> Now may be my idea to use pragma to get something like pythondoctest is a bad 
> idea 
> but I really want to have literal programming.
> What do you think?
> 
I like the idea to show examples/tests close to code, but pragmas are not 
really good...

> If we have ' ' then it would be good that the syntax higlighter works with a 
> special mode inside the ' ' 

it is just a string. How do you know that it contains code? 

Would you highlight all string in all code as if it contained code? Or would 
you add this just for
Pragmas? But even there, strings are string, not code.

I think we can conclude that pragmas are not a good solution to the problem, as 
they are far
too limited to express code.

Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[stepharo]

Hi nicolai

Why we should not accept

foo

^ self

and be forced to put around ''

foo
< func: '(3+4)' res: 0 >
^ self

I understand that we store literal but why you do not like it :).


First of all, the old compiler did not accept this. And I am a bit 
sensitive about changes, we allow a different syntax
just because RB happens  to allow this (and maybe no one knows why or 
it just does not happens on purpose).


valid point.


And another reason, even without my fix, if we don't put quotes around 
that expression, the reformatting the source will convert this to:


foo

^ self

What I noticed is that I could not write

 foo


but it worked when I put () so I did it in the new code I wrote.

And, even if (3+4) looks like an expression, it is just a list of 
literals something like this:


foo

^ self

would be allowed too.

This one is ugly


But of course this is only my own opinion :)

We can change it back and maybe add support for the reformatter to not 
convert it to the literal array #(3 #+ 4) .


I do not know in fact this is why I asked :)
Now may be my idea to use pragma to get something like pythondoctest is 
a bad idea

but I really want to have literal programming.
What do you think?

If we have ' ' then it would be good that the syntax higlighter works 
with a special mode inside the ' '



nicolai



Stef


  60220
19086 do not allow expressions as pragma arguments
https://pharo.fogbugz.com/f/cases/19086

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[stepharo]

Hi nicolai

Why we should not accept

foo

^ self

and be forced to put around ''

foo
< func: '(3+4)' res: 0 >
^ self

I understand that we store literal but why you do not like it :).

Stef


  60220
19086 do not allow expressions as pragma arguments
https://pharo.fogbugz.com/f/cases/19086

Re: [Pharo-dev] [pharo-project/pharo-core] d6bfc8: 60219

[Marcus Denker]

Hi,

This update should fix the  “load updates” menu. Thanks to Norbert who helped 
tracking that down.

Marcus

> On 13 Sep 2016, at 18:55, GitHub  wrote:
> 
>  Branch: refs/heads/6.0
>  Home:   https://github.com/pharo-project/pharo-core
>  Commit: d6bfc88a219ec6f709fa6d481aa7c83c27089dbc
>  
> https://github.com/pharo-project/pharo-core/commit/d6bfc88a219ec6f709fa6d481aa7c83c27089dbc
>  Author: Jenkins Build Server 
>  Date:   2016-09-13 (Tue, 13 Sep 2016)
> 
>  Changed paths:
>M 
> Kernel-Tests.package/MetaclassTest.class/instance/tests/testMetaclassAndTraitClassRespectsPolymorphismRules.st
>A Kernel.package/Metaclass.class/instance/instance 
> creation/newAnonymousSubclass.st
>R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
> scripts/script60218.st
>A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
> scripts/script60219.st
>R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
> updates/update60218.st
>A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
> updates/update60219.st
>M 
> ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
>M 
> System-Support.package/SystemVersion.class/instance/printing/shortVersionString.st
> 
>  Log Message:
>  ---
>  60219
> 17857 newAnonymousSubclass should works for Metaclass
>   https://pharo.fogbugz.com/f/cases/17857
> 
> 19082 The tool to do updates is broken due to space in SystemVersion 
>   https://pharo.fogbugz.com/f/cases/19082
> 
> http://files.pharo.org/image/60/60219.zip
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] e2d5dd: 60213

[Marcus Denker]

> 
>  Log Message:
>  ---
>  60213
> 19076 New assert extension to compare floats by closeTo
>   https://pharo.fogbugz.com/f/cases/19076
> 
> 19068 SUnit failed tests during command line or monkey run
>   https://pharo.fogbugz.com/f/cases/19068
> 

With these, we are down to 9 failing tests on the CI:

SmalllintManifestCheckerTest.testCriticsOf
SmalllintManifestCheckerTest.testToDoOf
- tests need to be updated, will be fixed with next QA update

SHParserST80Test.testNumberHierarchy
- syntax errors in some methods.

ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits
- fixed upstream (yes, I need to start bugging people again… there is 
   *nothing* to be gained from delaying integrating!)

ReleaseTest.testMethodsWithUnboundGlobals
- FFI package references a non existing class. We should really fix 
that...

SystemAnnouncerLiveTest.testNoDeadSubscriptions 
Announcements.Tests.Core.Tests.WeakAnnouncerTest.testNoDeadWeakSubscriptions
- no idea

SystemVersionTest.testUpgrade 
The space in SystemVersion. makes *lots* of problems and has to be 
reverted.
(e.g. “load code update” is broken due to that, too)

ClassDescriptionTest.testClassDescriptionRespectsPolymorphismWithTraitDescription
#iconNamed: in ClassDescription. Should it be there?


Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] 0e42ac: 60212

[Marcus Denker]

> On 12 Sep 2016, at 20:11, stepharo  wrote:
> 
> tx
> 
> Should I reissue
> 
> 19055 More iconNamed: cleaning
>https://pharo.fogbugz.com/f/cases/19055


normally this should have been integrated.

Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] 0e42ac: 60212

[stepharo]

tx

Should I reissue

19055 More iconNamed: cleaning
https://pharo.fogbugz.com/f/cases/19055

Stef
Le 12/9/16 à 13:17, Marcus Denker a écrit :

This should hopefully fix running the test on the slices for the CI (aka “the 
monkey”).

Marcus


On 12 Sep 2016, at 13:14, GitHub  wrote:

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 0e42ac3a57d6f06df9b018af0d536ab362fa703e
  
https://github.com/pharo-project/pharo-core/commit/0e42ac3a57d6f06df9b018af0d536ab362fa703e
  Author: Jenkins Build Server 
  Date:   2016-09-12 (Mon, 12 Sep 2016)

  Changed paths:
A 
Refactoring-Critics.package/RBPharoBootstrapRule.class/class/accessing/uniqueIdentifierName.st
R Refactoring-Critics.package/RBPharoBootstrapRule.class/class/as yet 
unclassified/isVisible.st
A 
Refactoring-Critics.package/RBPharoBootstrapRule.class/class/testing/isVisible.st
A 
Refactoring-Critics.package/RBRenrakuWrapperLintRule.class/class/accessing/uniqueIdentifierName.st
M Refactoring-Critics.package/RBRenrakuWrapperLintRule.class/class/instance 
creation/new_.st
M 
Refactoring-Critics.package/RBRenrakuWrapperLintRule.class/instance/adding/addSearchStringFrom_in_.st
R 
Refactoring-Tests-Critics.package/RBSmalllintTest.class/instance/tests/testOnlyReadOrWrittenTemporary.st
R 
Refactoring-Tests-Critics.package/RBSmalllintTest.class/instance/tests/testTemporaryVariableCapitalization.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60211.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60212.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60211.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60212.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  60212
19075 SmallLint tests failing after update
https://pharo.fogbugz.com/f/cases/19075

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

Re: [Pharo-dev] [pharo-project/pharo-core] 0e42ac: 60212

[Marcus Denker]

This should hopefully fix running the test on the slices for the CI (aka “the 
monkey”).

Marcus

> On 12 Sep 2016, at 13:14, GitHub  wrote:
> 
>  Branch: refs/heads/6.0
>  Home:   https://github.com/pharo-project/pharo-core
>  Commit: 0e42ac3a57d6f06df9b018af0d536ab362fa703e
>  
> https://github.com/pharo-project/pharo-core/commit/0e42ac3a57d6f06df9b018af0d536ab362fa703e
>  Author: Jenkins Build Server 
>  Date:   2016-09-12 (Mon, 12 Sep 2016)
> 
>  Changed paths:
>A 
> Refactoring-Critics.package/RBPharoBootstrapRule.class/class/accessing/uniqueIdentifierName.st
>R Refactoring-Critics.package/RBPharoBootstrapRule.class/class/as yet 
> unclassified/isVisible.st
>A 
> Refactoring-Critics.package/RBPharoBootstrapRule.class/class/testing/isVisible.st
>A 
> Refactoring-Critics.package/RBRenrakuWrapperLintRule.class/class/accessing/uniqueIdentifierName.st
>M 
> Refactoring-Critics.package/RBRenrakuWrapperLintRule.class/class/instance 
> creation/new_.st
>M 
> Refactoring-Critics.package/RBRenrakuWrapperLintRule.class/instance/adding/addSearchStringFrom_in_.st
>R 
> Refactoring-Tests-Critics.package/RBSmalllintTest.class/instance/tests/testOnlyReadOrWrittenTemporary.st
>R 
> Refactoring-Tests-Critics.package/RBSmalllintTest.class/instance/tests/testTemporaryVariableCapitalization.st
>R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
> scripts/script60211.st
>A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
> scripts/script60212.st
>R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
> updates/update60211.st
>A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
> updates/update60212.st
>M 
> ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
> 
>  Log Message:
>  ---
>  60212
> 19075 SmallLint tests failing after update
>   https://pharo.fogbugz.com/f/cases/19075
> 
> http://files.pharo.org/image/60/60212.zip
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] c0db47: 60199

[Marcus Denker]

>
>   Log Message:
>   ---
> 10025 MethodDictionary at:put: and #flushCache
> https://pharo.fogbugz.com/f/cases/10025
>

For this one we need to carefully check if there are bad side effects.

it should work as now at:put: is the fall-back case and flushes by selector.
(instead of clients having to do it explicitly)

Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] e64121: 60202

[stepharo]

Sean

this is like that since years.

Stef


Le 4/9/16 à 20:06, Sean P. DeNigris a écrit :

GitHub wrote

19001 Another pass to introduce iconNamed: and avoid Smalltalk ui icons
https://pharo.fogbugz.com/f/cases/19001

This one surprised me. I thought we were trying to avoid extensions to
low-level classes when possible. How is icon retrieval a responsibility of
ClassDescription?! I'm all about convenience, but not getting this change.
Was there a discussion somewhere? What benefits am I missing?



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/pharo-project-pharo-core-e64121-60202-tp4914016p4914078.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] [pharo-project/pharo-core] e64121: 60202

[Sean P. DeNigris]

GitHub wrote
> 19001 Another pass to introduce iconNamed: and avoid Smalltalk ui icons
>   https://pharo.fogbugz.com/f/cases/19001

This one surprised me. I thought we were trying to avoid extensions to
low-level classes when possible. How is icon retrieval a responsibility of
ClassDescription?! I'm all about convenience, but not getting this change.
Was there a discussion somewhere? What benefits am I missing?



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/pharo-project-pharo-core-e64121-60202-tp4914016p4914078.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] [pharo-project/pharo-core] 518075: 60194

[Marcus Denker]

> On 31 Aug 2016, at 11:29, GitHub  wrote:
> 
> 
>  Log Message:
>  ---
>  60194
> Moose
> 
> http://files.pharo.org/image/60/60194.zip
> 
> 

This update contains:

- case 18965 (removed GTExample)

- case 18596
Remove references from Glamour to Smalltalk evaluate:

- case 18948
remove a direct reference to Compiler from GT tests

- case 18923
inspector: improve "list methods using this variable"

- case 18905
cleanup #withThorougMethodsReferTo:do:


Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] e91f1f: 60171

[stepharo]

Pay attention that it was on my todo to work on packaging Grid and I 
need to do a pass on the Spec version


because I do not like the design. So I will probably change the Grid 
package.


Then I not sure that the grid should be by default in Pharo.
It was a personal project and I should probably improve it again.

Stef


Le 8/8/16 à 10:34, GitHub a écrit :

  60171
18875 RBRemoveClassRefactoring applicable despite showing a warning
https://pharo.fogbugz.com/f/cases/18875

18793 Add CTGrid
https://pharo.fogbugz.com/f/cases/18793

18876 Rename BinaryFileStream >> setAtEnd -> setToEnd
https://pharo.fogbugz.com/f/cases/18876

Re: [Pharo-dev] [pharo-project/pharo-core] f57843: 60163

[stepharo]

Le 5/8/16 à 05:28, Martin Dias a écrit :
Hi Stef, good, I take note. I improved filters in the recent releases 
and will continue improving.


Thanks Martin

I have problems with the menu item names :)
To me redo looks strange
when I get a crash I want to import the changes not redo them.
Then I do not get what undo means (yes I know this is probably revert)
May be some pharoers have better names than mine.

Stef


Martin

On Wed, Aug 3, 2016 at 5:30 PM, stepharo > wrote:


Thanks Martin.

We missed yesterday: show only the latest version of every
entities. :)


Setf


Le 3/8/16 à 11:23, Marcus Denker a écrit :

On 03 Aug 2016, at 11:07, GitHub > wrote:


  Log Message:
  ---
  60163
18831 Integrate new  Epicea  version
https://pharo.fogbugz.com/f/cases/18831


ChangeLog for this:

- Case 18813: Implement redo and undo of protocol addition and
removal.

- Case 18612: disable drag until TreeModel supports it
correctly.

- Case 18384: Redo and undo: show on any selection (not only
when all selected entries are code changes).

- Enhancement: Improve lost changes detection; show only the
events actually lost.

- Enhancement: Pass on filters.

- Clean up: Do not show the "absent entry" item anymore since
it was not useful at all.

- Clean up: Remove unused "commit tags" in log browser.

- Clean up: Remove unused tests. They were good idea, we can
re-introduce them but working and covering more cases.

- Clean up: Rename #displayWidget to #asMorph in
EpLogBrowserItem''s hierarchy. It is more meaningful.

- Workaround: Hide "Open in Sorter" menu action since it is
useless until Treemodel drag is fixed.



18768 Inlined method const could be implemented by metalinks
https://pharo.fogbugz.com/f/cases/18768


18835 Update RBParser-Nodes class comments
https://pharo.fogbugz.com/f/cases/18835


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

Re: [Pharo-dev] [pharo-project/pharo-core] f57843: 60163

[Martin Dias]

Hi Stef, good, I take note. I improved filters in the recent releases and
will continue improving.

Martin

On Wed, Aug 3, 2016 at 5:30 PM, stepharo  wrote:

> Thanks Martin.
>
> We missed yesterday: show only the latest version of every entities. :)
>
>
> Setf
>
>
> Le 3/8/16 à 11:23, Marcus Denker a écrit :
>
> On 03 Aug 2016, at 11:07, GitHub  wrote:
>>>
>>>
>>>   Log Message:
>>>   ---
>>>   60163
>>> 18831 Integrate new  Epicea  version
>>> https://pharo.fogbugz.com/f/cases/18831
>>>
>>> ChangeLog for this:
>>
>> - Case 18813: Implement redo and undo of protocol addition and removal.
>>
>> - Case 18612: disable drag until TreeModel supports it correctly.
>>
>> - Case 18384: Redo and undo: show on any selection (not only when all
>> selected entries are code changes).
>>
>> - Enhancement: Improve lost changes detection; show only the events
>> actually lost.
>>
>> - Enhancement: Pass on filters.
>>
>> - Clean up: Do not show the "absent entry" item anymore since it was not
>> useful at all.
>>
>> - Clean up: Remove unused "commit tags" in log browser.
>>
>> - Clean up: Remove unused tests. They were good idea, we can re-introduce
>> them but working and covering more cases.
>>
>> - Clean up: Rename #displayWidget to #asMorph in EpLogBrowserItem''s
>> hierarchy. It is more meaningful.
>>
>> - Workaround: Hide "Open in Sorter" menu action since it is useless until
>> Treemodel drag is fixed.
>>
>>
>>
>> 18768 Inlined method const could be implemented by metalinks
>>> https://pharo.fogbugz.com/f/cases/18768
>>>
>>> 18835 Update RBParser-Nodes class comments
>>> https://pharo.fogbugz.com/f/cases/18835
>>>
>>> http://files.pharo.org/image/60/60163.zip
>>>
>>>
>>>
>>
>>
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] f57843: 60163

[Sean P. DeNigris]

Ben Coman wrote
> Thanks for the follow up post of this change log Marcus.

+1!!



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/pharo-project-pharo-core-f57843-60163-tp4909296p4909676.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] [pharo-project/pharo-core] f57843: 60163

[Ben Coman]

Thanks for the follow up post of this change log Marcus.
cheers -ben

On Wed, Aug 3, 2016 at 5:23 PM, Marcus Denker  wrote:
>
>> On 03 Aug 2016, at 11:07, GitHub  wrote:
>>
>>
>>  Log Message:
>>  ---
>>  60163
>> 18831 Integrate new  Epicea  version
>>   https://pharo.fogbugz.com/f/cases/18831
>>
> ChangeLog for this:
>
> - Case 18813: Implement redo and undo of protocol addition and removal.
>
> - Case 18612: disable drag until TreeModel supports it correctly.
>
> - Case 18384: Redo and undo: show on any selection (not only when all 
> selected entries are code changes).
>
> - Enhancement: Improve lost changes detection; show only the events actually 
> lost.
>
> - Enhancement: Pass on filters.
>
> - Clean up: Do not show the "absent entry" item anymore since it was not 
> useful at all.
>
> - Clean up: Remove unused "commit tags" in log browser.
>
> - Clean up: Remove unused tests. They were good idea, we can re-introduce 
> them but working and covering more cases.
>
> - Clean up: Rename #displayWidget to #asMorph in EpLogBrowserItem''s 
> hierarchy. It is more meaningful.
>
> - Workaround: Hide "Open in Sorter" menu action since it is useless until 
> Treemodel drag is fixed.
>
>
>
>> 18768 Inlined method const could be implemented by metalinks
>>   https://pharo.fogbugz.com/f/cases/18768
>>
>> 18835 Update RBParser-Nodes class comments
>>   https://pharo.fogbugz.com/f/cases/18835
>>
>> http://files.pharo.org/image/60/60163.zip
>>
>>
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] f57843: 60163

[stepharo]

Thanks Martin.

We missed yesterday: show only the latest version of every entities. :)


Setf


Le 3/8/16 à 11:23, Marcus Denker a écrit :

On 03 Aug 2016, at 11:07, GitHub  wrote:


  Log Message:
  ---
  60163
18831 Integrate new  Epicea  version
https://pharo.fogbugz.com/f/cases/18831


ChangeLog for this:

- Case 18813: Implement redo and undo of protocol addition and removal.

- Case 18612: disable drag until TreeModel supports it correctly.

- Case 18384: Redo and undo: show on any selection (not only when all selected 
entries are code changes).

- Enhancement: Improve lost changes detection; show only the events actually 
lost.

- Enhancement: Pass on filters.

- Clean up: Do not show the "absent entry" item anymore since it was not useful 
at all.

- Clean up: Remove unused "commit tags" in log browser.

- Clean up: Remove unused tests. They were good idea, we can re-introduce them 
but working and covering more cases.

- Clean up: Rename #displayWidget to #asMorph in EpLogBrowserItem''s hierarchy. 
It is more meaningful.

- Workaround: Hide "Open in Sorter" menu action since it is useless until Treemodel 
drag is fixed.




18768 Inlined method const could be implemented by metalinks
https://pharo.fogbugz.com/f/cases/18768

18835 Update RBParser-Nodes class comments
https://pharo.fogbugz.com/f/cases/18835

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

Re: [Pharo-dev] [pharo-project/pharo-core] 94fcf4: 60165

[Ben Coman]

Thanks for the follow up log message Marcus.
cheers -ben

On Wed, Aug 3, 2016 at 7:00 PM, Marcus Denker  wrote:
>
>> On 03 Aug 2016, at 12:24, GitHub  wrote:
>>
>>  Branch: refs/heads/6.0
>>  Home:   https://github.com/pharo-project/pharo-core
>>  Commit: 94fcf44742b41d7898726b57a76edc70fb1d9aea
>>  
>> https://github.com/pharo-project/pharo-core/commit/94fcf44742b41d7898726b57a76edc70fb1d9aea
>>  Author: Jenkins Build Server 
>>  Date:   2016-08-03 (Wed, 03 Aug 2016)
>>
>>
>>  Log Message:
>>  ---
>>  60165
>> Moose
>
>
> Fixes these issues:
> - case 18691
> - case 18471
> - case 18244
> - case 18708
> - GT-InspectorExtensions: only show methods for the current class, added 
> basic example for RBCondition
> - Uses Pragma>>#methodSelector instead of Pragma>>#selector (case 18665).
> - Uses Behavior>>#classLayout instead of Behavior>>#layout (case 16636).
> - Uses CompiledMethod>>#sourceCode instead of CompiledMethod>>#getSource 
> (case 18694).
> - GT-EventRecorder: Add a basic recorder event
>
> Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] 94fcf4: 60165

[Marcus Denker]

> On 03 Aug 2016, at 12:24, GitHub  wrote:
> 
>  Branch: refs/heads/6.0
>  Home:   https://github.com/pharo-project/pharo-core
>  Commit: 94fcf44742b41d7898726b57a76edc70fb1d9aea
>  
> https://github.com/pharo-project/pharo-core/commit/94fcf44742b41d7898726b57a76edc70fb1d9aea
>  Author: Jenkins Build Server 
>  Date:   2016-08-03 (Wed, 03 Aug 2016)
> 
>   
>  Log Message:
>  ---
>  60165
> Moose


Fixes these issues:
- case 18691
- case 18471
- case 18244
- case 18708
- GT-InspectorExtensions: only show methods for the current class, added basic 
example for RBCondition
- Uses Pragma>>#methodSelector instead of Pragma>>#selector (case 18665).
- Uses Behavior>>#classLayout instead of Behavior>>#layout (case 16636).
- Uses CompiledMethod>>#sourceCode instead of CompiledMethod>>#getSource (case 
18694).
- GT-EventRecorder: Add a basic recorder event

Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] f57843: 60163

[Marcus Denker]

> On 03 Aug 2016, at 11:07, GitHub  wrote:
> 
> 
>  Log Message:
>  ---
>  60163
> 18831 Integrate new  Epicea  version
>   https://pharo.fogbugz.com/f/cases/18831
> 
ChangeLog for this:

- Case 18813: Implement redo and undo of protocol addition and removal.

- Case 18612: disable drag until TreeModel supports it correctly.

- Case 18384: Redo and undo: show on any selection (not only when all selected 
entries are code changes).

- Enhancement: Improve lost changes detection; show only the events actually 
lost.

- Enhancement: Pass on filters.

- Clean up: Do not show the "absent entry" item anymore since it was not useful 
at all.

- Clean up: Remove unused "commit tags" in log browser.

- Clean up: Remove unused tests. They were good idea, we can re-introduce them 
but working and covering more cases.

- Clean up: Rename #displayWidget to #asMorph in EpLogBrowserItem''s hierarchy. 
It is more meaningful.

- Workaround: Hide "Open in Sorter" menu action since it is useless until 
Treemodel drag is fixed.



> 18768 Inlined method const could be implemented by metalinks
>   https://pharo.fogbugz.com/f/cases/18768
> 
> 18835 Update RBParser-Nodes class comments
>   https://pharo.fogbugz.com/f/cases/18835
> 
> http://files.pharo.org/image/60/60163.zip
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] ac9f62: 60149

[Marcus Denker]

> On 13 Jul 2016, at 10:03, Marcus Denker  wrote:
> 
>> 
>> http://files.pharo.org/image/60/60149.zip
>> 
>> 
> Strangely it did not build. Wasted already >1 hour on this…
> 

Now it is there.

Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] ac9f62: 60149

[Marcus Denker]

> 
> http://files.pharo.org/image/60/60149.zip
> 
> 
Strangely it did not build. Wasted already >1 hour on this…

Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

[stepharo]

Do you think professional developers who use Pharo all day like crashes or 
hangs ? We are all the same here, we want a stable system.

It is not certain that the catalog download is the problem.

This specific feature that you think should only be enabled by those who want 
it (you call them pros) is exactly a beginner's feature: a way to discover 
every external library written. How ironic that you don't care.

Sven the students we have are not looking for published packages and if they 
need, they can use the catalog: entering XML and pressing ok
there is simple enough. It is not a complex ui. Spotter is a lot more confusing 
than the catalog UI. But dogma says the inverse so I will stop
arguing.

Well, you won, the feature is gone.

No it is not gone.
Update your preferences and help fixing the real problem and we will put 
it back.


You see I produce Spotter videos for the mooc. Do you think that I 
should have spent all this energy for something that I do not like.

Now we should be able to critic features.

Stef

Yes, newcomers hit all kinds of issues that more experienced users 
subconsciously avoid, being mindful for that is important. I think we all try 
to do that, by fixing things, not by turning things off.

We lack a proper process to decide these kinds of conflicts.


On 08 Jul 2016, at 11:21, stepharo  wrote:

Again again and again: How many times do you see students having Pharo frozen 
because the internet connection in the classroom is fleaky.

Apparently turning off these people is not an issue to you. Perfect but it is 
one for me.

For your productivity boost why can't you click on one setting and put it on?

Tell me I do not understand. In my dev image I have several settings set for my 
own usage.

So why you cannot have one extra one? Especially since preferences are loaded 
automatically.


Then when we will find a way to address the real problem we can just turn the 
setting on.

I will have spent half of my life showing software to newbies and may I ask you 
when is the last time

you show Pharo to a guy that is learning programming? I do that often (may be 
too often)

and in bad situation like in Afrika but not only.

Stef



Le 6/7/16 à 20:19, Sven Van Caekenberghe a écrit :

I'll try once more to explain.

You like the catalog, don't you ?  It was your idea in the first place. With 
this feature you can just type XML, CSV, JSON or whatever and it will suggest a 
couple of catalog projects that you can install with just one click, no need to 
open any tool you don't even know. This is especially good for new people. IT 
IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It leverages all the 
work put in the catalog.

Is Spotter or any other part of Pharo perfect ? No.

For many people, Spotter make a huge functional difference, we use it every 
minute. If it would hang or block the image even once a day, any of us would 
complain loudly.

Conclusion: it works for 99% of the people/cases.

Even in the 1% where there is a problem, it is not 100% sure it is related to 
the catalog searching. In the last concrete issue reported, the guy tried 
disabling the catalog searching AND IT MADE NO DIFFERENCE !

So again, why turn it off ? It is an overreaction, not engineering.

The underlying problem is that in some very rare, hard to reproduce cases we 
cannot reliably detect that there is no network. That's about it.

Note also that almost every application or app today will do some network 
calls, this is how the world work - we should be able to do the same with 
Pharo, not run away and kill every feature that does a network call.


On 06 Jul 2016, at 18:14, stepharo  wrote:

Who vote to put it in?

Seriously I think that my main concern is about getting Pharo stable in any 
occasion and not giving

a bad impression of the system. I takes enough time to build traction and such 
glitches can spoil

our effort in no time. "Yes Pharo froze."

So it would be nice to care take of such aspect.

I do not understand why super users do not manage to put a reference to on in 
the preferences.

Sorry esteban but I do not buy your argument that something off is remove. No 
it is off.

Stef

On 06 Jul 2016, at 09:52, GitHub  wrote:

18674 Turn spotter catalog off by default
https://pharo.fogbugz.com/f/cases/18674

We did not agree on this, at all, there was no public discussion, no vote.

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

[Sven Van Caekenberghe]

> On 08 Jul 2016, at 12:21, stepharo  wrote:
> 
> 
> 
> Le 8/7/16 à 11:44, Sven Van Caekenberghe a écrit :
>> Do you think professional developers who use Pharo all day like crashes or 
>> hangs ? We are all the same here, we want a stable system.
>> 
>> It is not certain that the catalog download is the problem.
>> 
>> This specific feature that you think should only be enabled by those who 
>> want it (you call them pros) is exactly a beginner's feature: a way to 
>> discover every external library written. How ironic that you don't care.
> 
> Sven the students we have are not looking for published packages and if they 
> need, they can use the catalog: entering XML and pressing ok
> there is simple enough. It is not a complex ui. Spotter is a lot more 
> confusing than the catalog UI. But dogma says the inverse so I will stop
> arguing.

Well, you won, the feature is gone.

>> 
>> Yes, newcomers hit all kinds of issues that more experienced users 
>> subconsciously avoid, being mindful for that is important. I think we all 
>> try to do that, by fixing things, not by turning things off.
>> 
>> We lack a proper process to decide these kinds of conflicts.
>> 
>>> On 08 Jul 2016, at 11:21, stepharo  wrote:
>>> 
>>> Again again and again: How many times do you see students having Pharo 
>>> frozen because the internet connection in the classroom is fleaky.
>>> 
>>> Apparently turning off these people is not an issue to you. Perfect but it 
>>> is one for me.
>>> 
>>> For your productivity boost why can't you click on one setting and put it 
>>> on?
>>> 
>>> Tell me I do not understand. In my dev image I have several settings set 
>>> for my own usage.
>>> 
>>> So why you cannot have one extra one? Especially since preferences are 
>>> loaded automatically.
>>> 
>>> 
>>> Then when we will find a way to address the real problem we can just turn 
>>> the setting on.
>>> 
>>> I will have spent half of my life showing software to newbies and may I ask 
>>> you when is the last time
>>> 
>>> you show Pharo to a guy that is learning programming? I do that often (may 
>>> be too often)
>>> 
>>> and in bad situation like in Afrika but not only.
>>> 
>>> Stef
>>> 
>>> 
>>> 
>>> Le 6/7/16 à 20:19, Sven Van Caekenberghe a écrit :
 I'll try once more to explain.
 
 You like the catalog, don't you ?  It was your idea in the first place. 
 With this feature you can just type XML, CSV, JSON or whatever and it will 
 suggest a couple of catalog projects that you can install with just one 
 click, no need to open any tool you don't even know. This is especially 
 good for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS 
 SHOULD WORK. It leverages all the work put in the catalog.
 
 Is Spotter or any other part of Pharo perfect ? No.
 
 For many people, Spotter make a huge functional difference, we use it 
 every minute. If it would hang or block the image even once a day, any of 
 us would complain loudly.
 
 Conclusion: it works for 99% of the people/cases.
 
 Even in the 1% where there is a problem, it is not 100% sure it is related 
 to the catalog searching. In the last concrete issue reported, the guy 
 tried disabling the catalog searching AND IT MADE NO DIFFERENCE !
 
 So again, why turn it off ? It is an overreaction, not engineering.
 
 The underlying problem is that in some very rare, hard to reproduce cases 
 we cannot reliably detect that there is no network. That's about it.
 
 Note also that almost every application or app today will do some network 
 calls, this is how the world work - we should be able to do the same with 
 Pharo, not run away and kill every feature that does a network call.
 
> On 06 Jul 2016, at 18:14, stepharo  wrote:
> 
> Who vote to put it in?
> 
> Seriously I think that my main concern is about getting Pharo stable in 
> any occasion and not giving
> 
> a bad impression of the system. I takes enough time to build traction and 
> such glitches can spoil
> 
> our effort in no time. "Yes Pharo froze."
> 
> So it would be nice to care take of such aspect.
> 
> I do not understand why super users do not manage to put a reference to 
> on in the preferences.
> 
> Sorry esteban but I do not buy your argument that something off is 
> remove. No it is off.
> 
> Stef
>>> On 06 Jul 2016, at 09:52, GitHub  wrote:
>>> 
>>> 18674 Turn spotter catalog off by default
>>> https://pharo.fogbugz.com/f/cases/18674
>> We did not agree on this, at all, there was no public discussion, no 
>> vote.
>> 
>> 
 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

[stepharo]

Le 8/7/16 à 11:44, Sven Van Caekenberghe a écrit :

Do you think professional developers who use Pharo all day like crashes or 
hangs ? We are all the same here, we want a stable system.

It is not certain that the catalog download is the problem.

This specific feature that you think should only be enabled by those who want 
it (you call them pros) is exactly a beginner's feature: a way to discover 
every external library written. How ironic that you don't care.


Sven the students we have are not looking for published packages and if 
they need, they can use the catalog: entering XML and pressing ok
there is simple enough. It is not a complex ui. Spotter is a lot more 
confusing than the catalog UI. But dogma says the inverse so I will stop

arguing.



Yes, newcomers hit all kinds of issues that more experienced users 
subconsciously avoid, being mindful for that is important. I think we all try 
to do that, by fixing things, not by turning things off.

We lack a proper process to decide these kinds of conflicts.


On 08 Jul 2016, at 11:21, stepharo  wrote:

Again again and again: How many times do you see students having Pharo frozen 
because the internet connection in the classroom is fleaky.

Apparently turning off these people is not an issue to you. Perfect but it is 
one for me.

For your productivity boost why can't you click on one setting and put it on?

Tell me I do not understand. In my dev image I have several settings set for my 
own usage.

So why you cannot have one extra one? Especially since preferences are loaded 
automatically.


Then when we will find a way to address the real problem we can just turn the 
setting on.

I will have spent half of my life showing software to newbies and may I ask you 
when is the last time

you show Pharo to a guy that is learning programming? I do that often (may be 
too often)

and in bad situation like in Afrika but not only.

Stef



Le 6/7/16 à 20:19, Sven Van Caekenberghe a écrit :

I'll try once more to explain.

You like the catalog, don't you ?  It was your idea in the first place. With 
this feature you can just type XML, CSV, JSON or whatever and it will suggest a 
couple of catalog projects that you can install with just one click, no need to 
open any tool you don't even know. This is especially good for new people. IT 
IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It leverages all the 
work put in the catalog.

Is Spotter or any other part of Pharo perfect ? No.

For many people, Spotter make a huge functional difference, we use it every 
minute. If it would hang or block the image even once a day, any of us would 
complain loudly.

Conclusion: it works for 99% of the people/cases.

Even in the 1% where there is a problem, it is not 100% sure it is related to 
the catalog searching. In the last concrete issue reported, the guy tried 
disabling the catalog searching AND IT MADE NO DIFFERENCE !

So again, why turn it off ? It is an overreaction, not engineering.

The underlying problem is that in some very rare, hard to reproduce cases we 
cannot reliably detect that there is no network. That's about it.

Note also that almost every application or app today will do some network 
calls, this is how the world work - we should be able to do the same with 
Pharo, not run away and kill every feature that does a network call.


On 06 Jul 2016, at 18:14, stepharo  wrote:

Who vote to put it in?

Seriously I think that my main concern is about getting Pharo stable in any 
occasion and not giving

a bad impression of the system. I takes enough time to build traction and such 
glitches can spoil

our effort in no time. "Yes Pharo froze."

So it would be nice to care take of such aspect.

I do not understand why super users do not manage to put a reference to on in 
the preferences.

Sorry esteban but I do not buy your argument that something off is remove. No 
it is off.

Stef

On 06 Jul 2016, at 09:52, GitHub  wrote:

18674 Turn spotter catalog off by default
https://pharo.fogbugz.com/f/cases/18674

We did not agree on this, at all, there was no public discussion, no vote.

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

[Sven Van Caekenberghe]

Do you think professional developers who use Pharo all day like crashes or 
hangs ? We are all the same here, we want a stable system.

It is not certain that the catalog download is the problem.

This specific feature that you think should only be enabled by those who want 
it (you call them pros) is exactly a beginner's feature: a way to discover 
every external library written. How ironic that you don't care.

Yes, newcomers hit all kinds of issues that more experienced users 
subconsciously avoid, being mindful for that is important. I think we all try 
to do that, by fixing things, not by turning things off.

We lack a proper process to decide these kinds of conflicts.

> On 08 Jul 2016, at 11:21, stepharo  wrote:
> 
> Again again and again: How many times do you see students having Pharo frozen 
> because the internet connection in the classroom is fleaky.
> 
> Apparently turning off these people is not an issue to you. Perfect but it is 
> one for me.
> 
> For your productivity boost why can't you click on one setting and put it on?
> 
> Tell me I do not understand. In my dev image I have several settings set for 
> my own usage.
> 
> So why you cannot have one extra one? Especially since preferences are loaded 
> automatically.
> 
> 
> Then when we will find a way to address the real problem we can just turn the 
> setting on.
> 
> I will have spent half of my life showing software to newbies and may I ask 
> you when is the last time
> 
> you show Pharo to a guy that is learning programming? I do that often (may be 
> too often)
> 
> and in bad situation like in Afrika but not only.
> 
> Stef
> 
> 
> 
> Le 6/7/16 à 20:19, Sven Van Caekenberghe a écrit :
>> I'll try once more to explain.
>> 
>> You like the catalog, don't you ?  It was your idea in the first place. With 
>> this feature you can just type XML, CSV, JSON or whatever and it will 
>> suggest a couple of catalog projects that you can install with just one 
>> click, no need to open any tool you don't even know. This is especially good 
>> for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. 
>> It leverages all the work put in the catalog.
>> 
>> Is Spotter or any other part of Pharo perfect ? No.
>> 
>> For many people, Spotter make a huge functional difference, we use it every 
>> minute. If it would hang or block the image even once a day, any of us would 
>> complain loudly.
>> 
>> Conclusion: it works for 99% of the people/cases.
>> 
>> Even in the 1% where there is a problem, it is not 100% sure it is related 
>> to the catalog searching. In the last concrete issue reported, the guy tried 
>> disabling the catalog searching AND IT MADE NO DIFFERENCE !
>> 
>> So again, why turn it off ? It is an overreaction, not engineering.
>> 
>> The underlying problem is that in some very rare, hard to reproduce cases we 
>> cannot reliably detect that there is no network. That's about it.
>> 
>> Note also that almost every application or app today will do some network 
>> calls, this is how the world work - we should be able to do the same with 
>> Pharo, not run away and kill every feature that does a network call.
>> 
>>> On 06 Jul 2016, at 18:14, stepharo  wrote:
>>> 
>>> Who vote to put it in?
>>> 
>>> Seriously I think that my main concern is about getting Pharo stable in any 
>>> occasion and not giving
>>> 
>>> a bad impression of the system. I takes enough time to build traction and 
>>> such glitches can spoil
>>> 
>>> our effort in no time. "Yes Pharo froze."
>>> 
>>> So it would be nice to care take of such aspect.
>>> 
>>> I do not understand why super users do not manage to put a reference to on 
>>> in the preferences.
>>> 
>>> Sorry esteban but I do not buy your argument that something off is remove. 
>>> No it is off.
>>> 
>>> Stef
> On 06 Jul 2016, at 09:52, GitHub  wrote:
> 
> 18674 Turn spotter catalog off by default
>   https://pharo.fogbugz.com/f/cases/18674
 We did not agree on this, at all, there was no public discussion, no vote.
 
 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] a813b2: 60138

[stepharo]

Le 6/7/16 à 18:52, Marcus Denker a écrit :

On 06 Jul 2016, at 18:16, stepharo  wrote:

I always found such kind of changes totally obscure and it would be nice to 
have a description.



Fixes issues:

- 18450 GT-Tools: "Do not use #ifNotNilDo:ifNil:, #ifNil:ifNotNilDo:, 
#ifNotNilDo:"
- 18453 GT-Tools: "do not use #ifEmpty:ifNotEmptyDo: #ifNotEmptyDo: 
#ifNotEmptyDo:ifEmpty:”
- 18431 attach glmpopplers shortcut to the textarea instead of the scroll pane
- Esteban's change to GLMAction

This was mostly me pushing for getting the trivial things *DONE* and not wait 
another 3 weeks…

Great.
I love this runtime deprecation transform it will really help us to move 
faster.

Tx for building it. I love it. :)


(I should have just committed slices, the overhead with committing and syncing 
is to high for
trivial refactorings)

Yes :)
I hope one day (soon) we will be able to get a lot faster on our 
pullrequests.

Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

[stepharo]

Again again and again: How many times do you see students having Pharo 
frozen because the internet connection in the classroom is fleaky.


Apparently turning off these people is not an issue to you. Perfect but 
it is one for me.


For your productivity boost why can't you click on one setting and put 
it on?


Tell me I do not understand. In my dev image I have several settings set 
for my own usage.


So why you cannot have one extra one? Especially since preferences are 
loaded automatically.



Then when we will find a way to address the real problem we can just 
turn the setting on.


I will have spent half of my life showing software to newbies and may I 
ask you when is the last time


you show Pharo to a guy that is learning programming? I do that often 
(may be too often)


and in bad situation like in Afrika but not only.

Stef



Le 6/7/16 à 20:19, Sven Van Caekenberghe a écrit :

I'll try once more to explain.

You like the catalog, don't you ?  It was your idea in the first place. With 
this feature you can just type XML, CSV, JSON or whatever and it will suggest a 
couple of catalog projects that you can install with just one click, no need to 
open any tool you don't even know. This is especially good for new people. IT 
IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It leverages all the 
work put in the catalog.

Is Spotter or any other part of Pharo perfect ? No.

For many people, Spotter make a huge functional difference, we use it every 
minute. If it would hang or block the image even once a day, any of us would 
complain loudly.

Conclusion: it works for 99% of the people/cases.

Even in the 1% where there is a problem, it is not 100% sure it is related to 
the catalog searching. In the last concrete issue reported, the guy tried 
disabling the catalog searching AND IT MADE NO DIFFERENCE !

So again, why turn it off ? It is an overreaction, not engineering.

The underlying problem is that in some very rare, hard to reproduce cases we 
cannot reliably detect that there is no network. That's about it.

Note also that almost every application or app today will do some network 
calls, this is how the world work - we should be able to do the same with 
Pharo, not run away and kill every feature that does a network call.


On 06 Jul 2016, at 18:14, stepharo  wrote:

Who vote to put it in?

Seriously I think that my main concern is about getting Pharo stable in any 
occasion and not giving

a bad impression of the system. I takes enough time to build traction and such 
glitches can spoil

our effort in no time. "Yes Pharo froze."

So it would be nice to care take of such aspect.

I do not understand why super users do not manage to put a reference to on in 
the preferences.

Sorry esteban but I do not buy your argument that something off is remove. No 
it is off.

Stef

On 06 Jul 2016, at 09:52, GitHub  wrote:

18674 Turn spotter catalog off by default
https://pharo.fogbugz.com/f/cases/18674

We did not agree on this, at all, there was no public discussion, no vote.

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

[Esteban Lorenzano]

I have to add here… solution is bad, because now projects are not shown EVEN if 
I activate it in settings :(

> On 06 Jul 2016, at 12:28, Esteban Lorenzano  wrote:
> 
> yes, I do not agree either but is true there where problems. 
> but IMO this would be solved just by putting a timeout in 1-2s (and then run 
> in background, and cache results) 
> not turning it off. 
> in for my experience, turning something off is equivalent to remove the 
> feature (but then is worst, because it becomes dead code inside image).
> 
> Anyway, any taker, to solve this in a proper way? 
> 
> Esteban
> 
>> On 06 Jul 2016, at 12:13, Marcus Denker  wrote:
>> 
>> 
>>> On 06 Jul 2016, at 10:12, Sven Van Caekenberghe  wrote:
>>> 
>>> 
 On 06 Jul 2016, at 09:52, GitHub  wrote:
 
 18674 Turn spotter catalog off by default
https://pharo.fogbugz.com/f/cases/18674
>>> 
>>> We did not agree on this, at all, there was no public discussion, no vote.
>>> 
>> 
>> I only know that there where problems.
>> 
>>  Marcus
>> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

[Eliot Miranda]

Hi Ben,

On Wed, Jul 6, 2016 at 5:16 PM, Ben Coman  wrote:

> On Thu, Jul 7, 2016 at 2:19 AM, Sven Van Caekenberghe 
> wrote:
> > I'll try once more to explain.
> >
> > You like the catalog, don't you ?  It was your idea in the first place.
> With this feature you can just type XML, CSV, JSON or whatever and it will
> suggest a couple of catalog projects that you can install with just one
> click, no need to open any tool you don't even know. This is especially
> good for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD
> WORK. It leverages all the work put in the catalog.
> >
> > Is Spotter or any other part of Pharo perfect ? No.
> >
> > For many people, Spotter make a huge functional difference, we use it
> every minute. If it would hang or block the image even once a day, any of
> us would complain loudly.
> >
> > Conclusion: it works for 99% of the people/cases.
> >
> > Even in the 1% where there is a problem, it is not 100% sure it is
> related to the catalog searching. In the last concrete issue reported, the
> guy tried disabling the catalog searching AND IT MADE NO DIFFERENCE !
> >
> > So again, why turn it off ? It is an overreaction, not engineering.
> >
> > The underlying problem is that in some very rare, hard to reproduce
> cases we cannot reliably detect that there is no network. That's about it.
>
> If the root cause is a blocking system call e.g
> "NetNameResolver class>>#addressForName: sometimes hangs when there is
> no network"
> https://pharo.fogbugz.com/default.asp?18281;
>
> this seems very hard to fix at the Image level, except maybe doing
> in-Image name resolution instead of relying on the system library. I
> found this...
> http://forum.world.st/ANN-DnsClient-More-protocol-fun-td2303225.html


It'll be child's play when we have the threaded FFI.

>
>
> and...
> http://www.squeaksource.com/dnsclient.html
> http://www.squeaksource.com/ar.html
>
> cheers -ben
>
> >
> > Note also that almost every application or app today will do some
> network calls, this is how the world work - we should be able to do the
> same with Pharo, not run away and kill every feature that does a network
> call.
> >
> >> On 06 Jul 2016, at 18:14, stepharo  wrote:
> >>
> >> Who vote to put it in?
> >>
> >> Seriously I think that my main concern is about getting Pharo stable in
> any occasion and not giving
> >>
> >> a bad impression of the system. I takes enough time to build traction
> and such glitches can spoil
> >>
> >> our effort in no time. "Yes Pharo froze."
> >>
> >> So it would be nice to care take of such aspect.
> >>
> >> I do not understand why super users do not manage to put a reference to
> on in the preferences.
> >>
> >> Sorry esteban but I do not buy your argument that something off is
> remove. No it is off.
> >>
> >> Stef
>  On 06 Jul 2016, at 09:52, GitHub  wrote:
> 
>  18674 Turn spotter catalog off by default
>  https://pharo.fogbugz.com/f/cases/18674
> >>> We did not agree on this, at all, there was no public discussion, no
> vote.
> >>>
> >>>
> >>
> >>
> >
> >
>
>


-- 
_,,,^..^,,,_
best, Eliot

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

[Ben Coman]

On Thu, Jul 7, 2016 at 2:19 AM, Sven Van Caekenberghe  wrote:
> I'll try once more to explain.
>
> You like the catalog, don't you ?  It was your idea in the first place. With 
> this feature you can just type XML, CSV, JSON or whatever and it will suggest 
> a couple of catalog projects that you can install with just one click, no 
> need to open any tool you don't even know. This is especially good for new 
> people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It 
> leverages all the work put in the catalog.
>
> Is Spotter or any other part of Pharo perfect ? No.
>
> For many people, Spotter make a huge functional difference, we use it every 
> minute. If it would hang or block the image even once a day, any of us would 
> complain loudly.
>
> Conclusion: it works for 99% of the people/cases.
>
> Even in the 1% where there is a problem, it is not 100% sure it is related to 
> the catalog searching. In the last concrete issue reported, the guy tried 
> disabling the catalog searching AND IT MADE NO DIFFERENCE !
>
> So again, why turn it off ? It is an overreaction, not engineering.
>
> The underlying problem is that in some very rare, hard to reproduce cases we 
> cannot reliably detect that there is no network. That's about it.

If the root cause is a blocking system call e.g
"NetNameResolver class>>#addressForName: sometimes hangs when there is
no network"
https://pharo.fogbugz.com/default.asp?18281;

this seems very hard to fix at the Image level, except maybe doing
in-Image name resolution instead of relying on the system library. I
found this...
http://forum.world.st/ANN-DnsClient-More-protocol-fun-td2303225.html

and...
http://www.squeaksource.com/dnsclient.html
http://www.squeaksource.com/ar.html

cheers -ben

>
> Note also that almost every application or app today will do some network 
> calls, this is how the world work - we should be able to do the same with 
> Pharo, not run away and kill every feature that does a network call.
>
>> On 06 Jul 2016, at 18:14, stepharo  wrote:
>>
>> Who vote to put it in?
>>
>> Seriously I think that my main concern is about getting Pharo stable in any 
>> occasion and not giving
>>
>> a bad impression of the system. I takes enough time to build traction and 
>> such glitches can spoil
>>
>> our effort in no time. "Yes Pharo froze."
>>
>> So it would be nice to care take of such aspect.
>>
>> I do not understand why super users do not manage to put a reference to on 
>> in the preferences.
>>
>> Sorry esteban but I do not buy your argument that something off is remove. 
>> No it is off.
>>
>> Stef
 On 06 Jul 2016, at 09:52, GitHub  wrote:

 18674 Turn spotter catalog off by default
 https://pharo.fogbugz.com/f/cases/18674
>>> We did not agree on this, at all, there was no public discussion, no vote.
>>>
>>>
>>
>>
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] a813b2: 60138

[Ben Coman]

On Thu, Jul 7, 2016 at 12:52 AM, Marcus Denker  wrote:
>
>> On 06 Jul 2016, at 18:16, stepharo  wrote:
>>
>> I always found such kind of changes totally obscure and it would be nice to 
>> have a description.
>>
>
>

The point I took from Stef's question is... not just getting a
followup description here in the mail list, but could this text you've
typed here

> Fixes issues:
>
> - 18450 GT-Tools: "Do not use #ifNotNilDo:ifNil:, #ifNil:ifNotNilDo:, 
> #ifNotNilDo:"
> - 18453 GT-Tools: "do not use #ifEmpty:ifNotEmptyDo: #ifNotEmptyDo: 
> #ifNotEmptyDo:ifEmpty:”
> - 18431 attach glmpopplers shortcut to the textarea instead of the scroll pane
> - Esteban's change to GLMAction

...in future be added as the Log message instead of just "Moose" so
there is a permanent record in our package history.

>
> This was mostly me pushing for getting the trivial things *DONE* and not wait 
> another 3 weeks…
>
> (I should have just committed slices, the overhead with committing and 
> syncing is to high for
> trivial refactorings)

Sure, buts lets document this. Since anyway we'll just ask for a
followup in the mail list ;) and I presume it takes more effort to go
back and look these up after the fact, than copy-pasting at
integration time.

cheers -ben
>
> Marcus

P.S.  Not to take your efforts doing the integrations for granted,
thanks for regularly doing this task.

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

[Andrei Chis]

+1

On Wed, Jul 6, 2016 at 8:19 PM, Sven Van Caekenberghe  wrote:

> I'll try once more to explain.
>
> You like the catalog, don't you ?  It was your idea in the first place.
> With this feature you can just type XML, CSV, JSON or whatever and it will
> suggest a couple of catalog projects that you can install with just one
> click, no need to open any tool you don't even know. This is especially
> good for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD
> WORK. It leverages all the work put in the catalog.
>
> Is Spotter or any other part of Pharo perfect ? No.
>
> For many people, Spotter make a huge functional difference, we use it
> every minute. If it would hang or block the image even once a day, any of
> us would complain loudly.
>
> Conclusion: it works for 99% of the people/cases.
>
> Even in the 1% where there is a problem, it is not 100% sure it is related
> to the catalog searching. In the last concrete issue reported, the guy
> tried disabling the catalog searching AND IT MADE NO DIFFERENCE !
>
> So again, why turn it off ? It is an overreaction, not engineering.
>
> The underlying problem is that in some very rare, hard to reproduce cases
> we cannot reliably detect that there is no network. That's about it.
>
> Note also that almost every application or app today will do some network
> calls, this is how the world work - we should be able to do the same with
> Pharo, not run away and kill every feature that does a network call.
>
> > On 06 Jul 2016, at 18:14, stepharo  wrote:
> >
> > Who vote to put it in?
> >
> > Seriously I think that my main concern is about getting Pharo stable in
> any occasion and not giving
> >
> > a bad impression of the system. I takes enough time to build traction
> and such glitches can spoil
> >
> > our effort in no time. "Yes Pharo froze."
> >
> > So it would be nice to care take of such aspect.
> >
> > I do not understand why super users do not manage to put a reference to
> on in the preferences.
> >
> > Sorry esteban but I do not buy your argument that something off is
> remove. No it is off.
> >
> > Stef
> >>> On 06 Jul 2016, at 09:52, GitHub  wrote:
> >>>
> >>> 18674 Turn spotter catalog off by default
> >>> https://pharo.fogbugz.com/f/cases/18674
> >> We did not agree on this, at all, there was no public discussion, no
> vote.
> >>
> >>
> >
> >
>
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

[Sven Van Caekenberghe]

I'll try once more to explain.

You like the catalog, don't you ?  It was your idea in the first place. With 
this feature you can just type XML, CSV, JSON or whatever and it will suggest a 
couple of catalog projects that you can install with just one click, no need to 
open any tool you don't even know. This is especially good for new people. IT 
IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It leverages all the 
work put in the catalog.

Is Spotter or any other part of Pharo perfect ? No.

For many people, Spotter make a huge functional difference, we use it every 
minute. If it would hang or block the image even once a day, any of us would 
complain loudly.

Conclusion: it works for 99% of the people/cases.

Even in the 1% where there is a problem, it is not 100% sure it is related to 
the catalog searching. In the last concrete issue reported, the guy tried 
disabling the catalog searching AND IT MADE NO DIFFERENCE !

So again, why turn it off ? It is an overreaction, not engineering.

The underlying problem is that in some very rare, hard to reproduce cases we 
cannot reliably detect that there is no network. That's about it.

Note also that almost every application or app today will do some network 
calls, this is how the world work - we should be able to do the same with 
Pharo, not run away and kill every feature that does a network call.

> On 06 Jul 2016, at 18:14, stepharo  wrote:
> 
> Who vote to put it in?
> 
> Seriously I think that my main concern is about getting Pharo stable in any 
> occasion and not giving
> 
> a bad impression of the system. I takes enough time to build traction and 
> such glitches can spoil
> 
> our effort in no time. "Yes Pharo froze."
> 
> So it would be nice to care take of such aspect.
> 
> I do not understand why super users do not manage to put a reference to on in 
> the preferences.
> 
> Sorry esteban but I do not buy your argument that something off is remove. No 
> it is off.
> 
> Stef
>>> On 06 Jul 2016, at 09:52, GitHub  wrote:
>>> 
>>> 18674 Turn spotter catalog off by default
>>> https://pharo.fogbugz.com/f/cases/18674
>> We did not agree on this, at all, there was no public discussion, no vote.
>> 
>> 
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] a813b2: 60138

[Marcus Denker]

> On 06 Jul 2016, at 18:16, stepharo  wrote:
> 
> I always found such kind of changes totally obscure and it would be nice to 
> have a description.
> 


Fixes issues:

- 18450 GT-Tools: "Do not use #ifNotNilDo:ifNil:, #ifNil:ifNotNilDo:, 
#ifNotNilDo:"
- 18453 GT-Tools: "do not use #ifEmpty:ifNotEmptyDo: #ifNotEmptyDo: 
#ifNotEmptyDo:ifEmpty:”
- 18431 attach glmpopplers shortcut to the textarea instead of the scroll pane
- Esteban's change to GLMAction

This was mostly me pushing for getting the trivial things *DONE* and not wait 
another 3 weeks…

(I should have just committed slices, the overhead with committing and syncing 
is to high for
trivial refactorings)

Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] a813b2: 60138

[stepharo]

I always found such kind of changes totally obscure and it would be nice 
to have a description.



Stef


Le 6/7/16 à 11:29, GitHub a écrit :

   Branch: refs/heads/6.0
   Home:   https://github.com/pharo-project/pharo-core
   Commit: a813b2cc8d72ea3442e7ab1e9be5856203ea4c3f
   
https://github.com/pharo-project/pharo-core/commit/a813b2cc8d72ea3442e7ab1e9be5856203ea4c3f
   Author: Jenkins Build Server 
   Date:   2016-07-06 (Wed, 06 Jul 2016)

   Changed paths:
 M 
ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version018_.st
 M 
ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/symbolic
 versions/stable_.st
 M 
ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version310_.st
 A 
ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version311_.st
 M 
ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version212_.st
 M 
GT-BytecodeDebugger.package/extension/Context/instance/gtBytecodeDebuggerRetrieveContextValues.st
 M 
GT-EventRecorder.package/GTEventPacking.class/instance/private/updateAnnouncement_for_.st
 A GT-EventRecorder.package/GlobalIdentifier.class/class/class 
initialization/initialize.st
 A GT-EventRecorder.package/GlobalIdentifier.class/class/system 
startup/startUp_.st
 R GT-Inspector.package/GTExample.class/class/examples/gtExample.st
 A 
GT-Inspector.package/GTExample.class/class/examples/gtExampleFromPragma.st
 R 
GT-Inspector.package/GTExample.class/instance/pragma-selectors/afterClass_selector_arguments_.st
 R 
GT-Inspector.package/GTExample.class/instance/pragma-selectors/afterFinishClass_selector_.st
 R 
GT-Inspector.package/GTExample.class/instance/pragma-selectors/afterFinishClass_selector_arguments_.st
 R 
GT-Inspector.package/GTExample.class/instance/pragma-selectors/afterFinish_.st
 R 
GT-Inspector.package/GTExample.class/instance/pragma-selectors/after_arguments_.st
 A 
GT-Inspector.package/GTExample.class/instance/public/signalableExceptions.st
 M GT-Inspector.package/GTExampleEvaluator.class/README.md
 M GT-Inspector.package/GTExampleEvaluator.class/definition.st
 M 
GT-Inspector.package/GTExampleEvaluator.class/instance/initializing/initialize.st
 R 
GT-Inspector.package/GTExampleEvaluator.class/instance/primitives/primitiveProcessExampleAfterFinish_.st
 R 
GT-Inspector.package/GTExampleEvaluator.class/instance/primitives/primitiveProcessExampleAfter_.st
 M 
GT-Inspector.package/GTExampleEvaluator.class/instance/primitives/primitiveProcessExample_withArguments_.st
 A 
GT-Inspector.package/GTExampleEvaluator.class/instance/private/newResultFor_.st
 A 
GT-Inspector.package/GTExampleEvaluator.class/instance/private/processAfter_.st
 A 
GT-Inspector.package/GTExampleEvaluator.class/instance/private/processAfter_withResult_.st
 M 
GT-Inspector.package/GTExampleEvaluator.class/instance/private/process_withArguments_.st
 R 
GT-Inspector.package/GTExampleEvaluator.class/instance/private/withLinkContextFor_do_.st
 M GT-Inspector.package/GTExampleEvaluator.class/instance/public/result.st
 R GT-Inspector.package/GTExampleLinkContext.class/README.md
 R GT-Inspector.package/GTExampleLinkContext.class/definition.st
 R 
GT-Inspector.package/GTExampleLinkContext.class/instance/accessing/example.st
 R 
GT-Inspector.package/GTExampleLinkContext.class/instance/accessing/example_.st
 R 
GT-Inspector.package/GTExampleLinkContext.class/instance/private/install.st
 R 
GT-Inspector.package/GTExampleLinkContext.class/instance/private/onLinkNode_arguments_.st
 R 
GT-Inspector.package/GTExampleLinkContext.class/instance/private/onLinkNode_at_put_.st
 R 
GT-Inspector.package/GTExampleLinkContext.class/instance/private/uninstall.st
 R 
GT-Inspector.package/GTExampleLinkContext.class/instance/private/withLinksDo_.st
 R 
GT-Inspector.package/GTExampleLinkContext.class/instance/public/arguments.st
 R GT-Inspector.package/GTExampleLinkContext.class/instance/public/do_.st
 R 
GT-Inspector.package/GTExampleLinkContext.class/instance/testing/hasLinks.st
 M 
GT-Inspector.package/GTExampleTestCase.class/instance/private/runExampleContainers_.st
 A 
GT-Inspector.package/GTExampleTestCase.class/instance/private/runExample_.st
 R 
GT-Inspector.package/GTExampleTestCase.class/instance/private/runExample_fromContainer_.st
 M 
GT-Inspector.package/GTInspector.class/class/inspecting/inspectorExtendingMethods.st
 M GT-Inspector.package/GTInspector.class/instance/building/compose.st
 M GT-Inspector.package/GTInspectorHelp.class/class/accessing/pages.st
 A GT-Inspector.package/extension/Class/instance/gtInspectorGTExamplesIn_.st
 M GT-Inspector.package/extension/CompiledMethod/instance/gtExample.st