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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 634716: 40528

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 634716236bb6b4a9c003544f90a98303609f0b31
  
https://github.com/pharo-project/pharo-core/commit/634716236bb6b4a9c003544f90a98303609f0b31
  Author: Jenkins Build Server 
  Date:   2015-03-03 (Tue, 03 Mar 2015)

  Changed paths:
M 
Morphic-Widgets-Tree.package/MorphTreeChangeRequest.class/instance/accessing/change_.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script527.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script528.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40527.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40528.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M Spec-Core.package/AbstractAdapter.class/README.md
R 
Spec-Core.package/CheckBoxModel.class/instance/api-events/whenLabelChanged_.st
A 
Spec-Core.package/CheckBoxModel.class/instance/api-valueHolder/labelHolder.st
M Spec-Core.package/CheckBoxModel.class/instance/api/label_.st
A 
Spec-Core.package/CheckBoxModel.class/instance/deprecated/whenLabelChanged_.st
M 
Spec-Core.package/CheckBoxModel.class/instance/initialization/initialize.st
A Spec-Core.package/ComposableModel.class/instance/api/adapterFrom_model_.st
M 
Spec-Core.package/ComposableModel.class/instance/api/buildWithSpecLayout_.st
A 
Spec-Core.package/ComposableModel.class/instance/api/setExtentAndBindingTo_.st
M 
Spec-Core.package/ComposableModel.class/instance/private/private%5FbuildWithSpec_.st
A 
Spec-Core.package/ComposableModel.class/instance/private/privateAdapterFromModel_withSpec_.st
M 
Spec-Core.package/ContainerModel.class/instance/api/buildAdapterWithSpec.st
M 
Spec-Core.package/DialogWindowModel.class/instance/private/buildWithSpecLayout_.st
M Spec-Core.package/DynamicComposableModel.class/README.md
M Spec-Core.package/DynamicComposableModel.class/instance/error 
handling/doesNotUnderstand_.st
M Spec-Core.package/ImageModel.class/definition.st
R 
Spec-Core.package/ImageModel.class/instance/api-events/whenActionChanged_.st
R 
Spec-Core.package/ImageModel.class/instance/api-events/whenImageChanged_.st
A 
Spec-Core.package/ImageModel.class/instance/api-valueHolder/actionHolder.st
A Spec-Core.package/ImageModel.class/instance/api-valueHolder/imageHolder.st
M Spec-Core.package/ImageModel.class/instance/api/action.st
M Spec-Core.package/ImageModel.class/instance/api/action_.st
M Spec-Core.package/ImageModel.class/instance/api/image_.st
A 
Spec-Core.package/ImageModel.class/instance/deprecated/whenActionChanged_.st
A 
Spec-Core.package/ImageModel.class/instance/deprecated/whenImageChanged_.st
M Spec-Core.package/ImageModel.class/instance/initialization/initialize.st
M Spec-Core.package/LabelModel.class/definition.st
R 
Spec-Core.package/LabelModel.class/instance/api-events/whenLabelChanged_.st
A Spec-Core.package/LabelModel.class/instance/api-valueHolder/labelHolder.st
M Spec-Core.package/LabelModel.class/instance/api/label.st
M Spec-Core.package/LabelModel.class/instance/api/label_.st
M Spec-Core.package/LabelModel.class/instance/deprecated-api/text.st
M Spec-Core.package/LabelModel.class/instance/deprecated-api/text_.st
A 
Spec-Core.package/LabelModel.class/instance/deprecated-api/whenLabelChanged_.st
M 
Spec-Core.package/LabelModel.class/instance/deprecated-api/whenTextChanged_.st
M 
Spec-Core.package/MenuGroupModel.class/instance/private/buildWithSpecLayout_.st
R 
Spec-Core.package/RadioButtonModel.class/instance/api-events/whenLabelChanged_.st
A 
Spec-Core.package/RadioButtonModel.class/instance/api-valueHolder/labelHolder.st
A 
Spec-Core.package/RadioButtonModel.class/instance/deprecated/whenLabelChanged_.st
M 
Spec-Core.package/RadioButtonModel.class/instance/initialization/initialize.st
M Spec-Core.package/SliderModel.class/instance/initialization/initialize.st
M 
Spec-Core.package/WindowModel.class/instance/private/buildWithSpecLayout_.st

  Log Message:
  ---
  40528
15028 MorphTreeChangeRequest>>change: does not need the respondTo:
https://pharo.fogbugz.com/f/cases/15028

15016 clean Spec: ValueHolder exposition
https://pharo.fogbugz.com/f/cases/15016

http://files.pharo.org/image/40/40528.zip

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

[Marcus Denker]

> On 02 Mar 2015, at 18:29, Marcus Denker  wrote:
> 
>> 
>> 
>> Other things TODO to make it even smaller:
>> 
>> - Hunt down that one GTPlayground instance that is hanging around

This is *strange*. I was able to get it down to 1

Smalltalk garbageCollect.
Smalltalk garbageCollect.
Smalltalk garbageCollect.
GTPlayground allInstances size.

and then I saved that and uploaded it the build server. Now all the Undeclareds 
are gone.
Yet, when I download the last build, open *one* GTPlayground:

GTPlayground allInstances size ==> 2.
There is something happening that I don’t understand.

>> - fix class annitations to not allocate 4000 empty dictionaries:
>>  
>> https://pharo.fogbugz.com/f/cases/14956/Properties-on-Behaviour-self-properties-creates-empty-dict-for-keys
>>  
>> 
Integrated.

Size: 22.9MB (== 21.8 MiB, people obsessed with memory size tend to think 
binary).

Marcus

[Pharo-dev] [pharo-project/pharo-core] d6cc2e: 40527

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: d6cc2e540bd5f28058b79ee3be92ea7797a14e93
  
https://github.com/pharo-project/pharo-core/commit/d6cc2e540bd5f28058b79ee3be92ea7797a14e93
  Author: Jenkins Build Server 
  Date:   2015-03-03 (Tue, 03 Mar 2015)

  Changed paths:
A 
Kernel.package/Behavior.class/instance/accessing-properties/ensureProperties.st
M Kernel.package/Behavior.class/instance/accessing-properties/properties.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script526.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script527.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40526.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40527.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M Slot.package/PropertySlot.class/instance/class building/removingFrom_.st
M 
Tool-ImageCleaner.package/ImageCleaner.class/instance/api/cleanUpForProduction.st
M 
Traits.package/TBehavior.class/instance/accessing-properties/propertyValueAt_ifAbsent_.st
M 
Traits.package/TBehavior.class/instance/accessing-properties/propertyValueAt_put_.st
M 
Traits.package/TBehavior.class/instance/accessing-properties/removeProperty_ifAbsent_.st
A 
Traits.package/TClassDescription.class/instance/slots/allSlotsEverywhere.st
A 
Traits.package/TraitBehavior.class/instance/accessing-properties/ensureProperties.st
M 
Traits.package/TraitBehavior.class/instance/accessing-properties/properties.st

  Log Message:
  ---
  40527
14956 Properties on Behaviour: "self properties" creates empty dict for keys
https://pharo.fogbugz.com/f/cases/14956

15035 allSlotsEverywhere
https://pharo.fogbugz.com/f/cases/15035

15031 #cleanUpForProduction does not need to reset MCVersionInfo instances
https://pharo.fogbugz.com/f/cases/15031

http://files.pharo.org/image/40/40527.zip

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

[GitHub]

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

Re: [Pharo-dev] 13017 Class renaming does not update textual class definition

[Sean P. DeNigris]

Ben Coman wrote
> which forks...

AFAICT part of the problem is that it /doesn't/ fork. It just returns
control to Morphic, so if you're in the UI thread a Semaphore would freeze
the UI.


Ben Coman wrote
> windowClosedAction: [
> refactoringDoneSemaphore signal].
> refactoringDoneSemaphore wait.

There is okAction:, but see above about the Semaphore



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/13017-Class-renaming-does-not-update-textual-class-definition-tp4808879p4809007.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] WhatsUp from: 2015-03-02 until: 2015-03-15

[Max Leske]

> On 02 Mar 2015, at 07:00, seas...@rmod.lille.inria.fr wrote:
> 
> Hi! We're sending this automatic email twice a month, to give the community 
> an opportunity to easily know what's happening and to coordinate efforts.  
> Just answer informally, and feel free to spawn discussions thereafter!
> 
> ### Here's what I've been up to since the last WhatsUp:
> 
> - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS

- Reviewed Ben’s changes to the delay machinery
- Worked with Martin on libgit2 features he needs for Yrupe
- Finally got some libgit2 stuff done
- fixed a huge memoy leak in my libgit2 code (there are still more…)
- proposed a change to NativeBoost to enable optCoerceNilToNull for 
NBExternalObjectType and NBExternalAddressType

> 
> ### What's next, until 2015-03-15 (*):
> 
> - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION

- Work and Uni…
- try to fix the remaining problems during large exports with Yrupe

> 
> (*) we'll be expecting results by then ;)
> 

Re: [Pharo-dev] 13017 Class renaming does not update textual class definition

[Ben Coman]

On Mon, Mar 2, 2015 at 11:59 PM, Sean P. DeNigris 
wrote:

> Ben Coman wrote
> > is there a standard way to pause
> > code execution in the sender of #openWithSpec until the window is closed?
>
> Something like
> "model openDialogWithSpec okAction: [ self doNextThing ]"?
>
>
I'm not sure. A code example may help.  The problem is we have...

AbstractNautilusUI >>renameClass
self okToChange ifFalse: [ ^ self ].
self selectedClass ifNil: [ ^ self ].
self basicRenameClass: self selectedClass theNonMetaClass.
self changed: #sourceCodeFrom:.

and 12 levels deep into #basicRenameClass:
we have...

NautilusRefactoring>>internalPerformRefactorings:
...
(ChangesBrowser changes: aCollectionRefactoring) openWithSpec

which forks such that execution returns to perform the #changed: before you
get a chance to click the  button.

So the problem is how to make it pause at #basicRenameClass: until the
ChangesBrowser is closed (either ok cancel), such that #changed: is not
executed before the changes are applied.  The complication is the existing
code operating on the ChangesBrowser  button, and the stack distance of
#internalPerformRefactorings: from #renameClass.

I am thinking of some synchronisation like the following would be least
impact...

NautilusRefactoring>>internalPerformRefactorings:
...
(ChangesBrowser changes: aCollectionRefactoring)
   openDialogWithSpec windowClosedAction: [
refactoringDoneSemaphore signal].
refactoringDoneSemaphore wait.

or maybe that could be pushed into SpecDialogWindow as a convenience method
available to others.

cheers -ben

Re: [Pharo-dev] Keyboard Event Weirdness

[p...@highoctane.be]

9
Le 2 mars 2015 21:35, "Sean P. DeNigris"  a écrit :
>
> Sean P. DeNigris wrote
> > It seems the keyUp/Downs do not have the correct charCode and the
keyValue
> > is different than the keystroke for the same key. What's going on here?

Each platform has its own idea about these events.

That is where SDL will be welcome.

Phil
>
> This still has not been fixed. Any ideas? I sent a message to the VM
list...
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context:
http://forum.world.st/Keyboard-Event-Weirdness-tp4737056p4808969.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
Nabble.com.
>

Re: [Pharo-dev] Keyboard Event Weirdness

[Sean P. DeNigris]

Sean P. DeNigris wrote
> It seems the keyUp/Downs do not have the correct charCode and the keyValue
> is different than the keystroke for the same key. What's going on here?

This still has not been fixed. Any ideas? I sent a message to the VM list...



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Keyboard-Event-Weirdness-tp4737056p4808969.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] Visual Debugger Feedback for Resumable Exceptions

[Sean P. DeNigris]

I was creating a class with an empty package name. When the debugger
appeared, stating that "The Category should not be empty' [1], I thought I
would not be able to use that package name. But, in fact, as I found out
later, the exception is resumable, and clicking 'Proceed' created the class
in the '' package.
It might be nice to make it obvious to the user when exceptions are
resumable. If, for example, the "Proceed" button said "Resume", I might have
realized right away that there was value in continuing execution.

[1] OT: This is probably not the best message for a resumable warning. How
about something like "Are you sure you want to use an empty category?"



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Visual-Debugger-Feedback-for-Resumable-Exceptions-tp4808954.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] ChangesBrowser should not roll own dialog (was 13017 Class renaming does not update textual class definition)

[Sean P. DeNigris]

Sean P. DeNigris wrote
> Fix in inbox:
> SLICE-Issue-15030-ChangesBrowser-should-not-roll-own-dialog-SeanDeNigris.1

1 validation failure that seems to have nothing to do with the fix. Make
#noMonkey to be reviewed manually…



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/ChangesBrowser-should-not-roll-own-dialog-was-13017-Class-renaming-does-not-update-textual-class-def-tp4808902p4808952.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] CI: Monkey run down to 17min

[Yuriy Tymchuk]

> On 02 Mar 2015, at 12:16, Marcus Denker  wrote:
> 
> 
>> On 02 Mar 2015, at 18:01, Max Leske > > wrote:
>> 
>> 
>>> On 02 Mar 2015, at 17:44, Alexandre Bergel >> > wrote:
>>> 
>>> Thanks Marcus for taking care of all of these hidden low level matters. 
>>> Your effort is indispensable and central to Pharo.
>> 
>> I second that! Although: “I am not sure what exactly the reason is, but this 
>> is nice.” 
>> 
> 
> 1) removing 160KLoc code
> 2) maybe the AST changes?
> 
> https://pharo.fogbugz.com/f/cases/14881/running-Smallint-rules-is-significant-slower-now
>  
> 
> 
> shows that multiple runs of a rule where slow, now the second (and every 
> other) is very fast.
> 
>   Marcus
> 

Sorry for slowing down SmallLint and not fixing that. & thanks for the 
improvements.

Uko

Re: [Pharo-dev] CI: Monkey run down to 17min

[Bernardo Ezequiel Contreras]

+1

On Mon, Mar 2, 2015 at 2:34 PM, Sven Van Caekenberghe  wrote:
>
>> On 02 Mar 2015, at 17:44, Alexandre Bergel  wrote:
>>
>> Thanks Marcus for taking care of all of these hidden low level matters. Your 
>> effort is indispensable and central to Pharo.
>
> + 1e10
>
>> Alexandre
>>
>>
>>> On Mar 2, 2015, at 11:24 AM, Marcus Denker  wrote:
>>>
>>> Hi,
>>>
>>> Since last week the time the monkey takes to run tests twice + selected 
>>> code critique rules
>>> is down to 17min. It was ~38 before.
>>>
>>> I am not sure what exactly the reason is, but this is nice.
>>>
>>>  Marcus
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>
>



-- 
Bernardo E.C.

Sent from a cheap desktop computer in South America.

Re: [Pharo-dev] CI: Monkey run down to 17min

[Sven Van Caekenberghe]

> On 02 Mar 2015, at 17:44, Alexandre Bergel  wrote:
> 
> Thanks Marcus for taking care of all of these hidden low level matters. Your 
> effort is indispensable and central to Pharo.

+ 1e10

> Alexandre
> 
> 
>> On Mar 2, 2015, at 11:24 AM, Marcus Denker  wrote:
>> 
>> Hi,
>> 
>> Since last week the time the monkey takes to run tests twice + selected code 
>> critique rules
>> is down to 17min. It was ~38 before.
>> 
>> I am not sure what exactly the reason is, but this is nice.
>> 
>>  Marcus
> 
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

[Marcus Denker]

> 
> 
> Other things TODO to make it even smaller:
> 
> - Hunt down that one GTPlayground instance that is hanging around
> - fix class annitations to not allocate 4000 empty dictionaries:
>   
> https://pharo.fogbugz.com/f/cases/14956/Properties-on-Behaviour-self-properties-creates-empty-dict-for-keys
>  
> 
I submitted a fix. 

Marcus

Re: [Pharo-dev] CI: Monkey run down to 17min

[Marcus Denker]

> On 02 Mar 2015, at 18:01, Max Leske  wrote:
> 
> 
>> On 02 Mar 2015, at 17:44, Alexandre Bergel  wrote:
>> 
>> Thanks Marcus for taking care of all of these hidden low level matters. Your 
>> effort is indispensable and central to Pharo.
> 
> I second that! Although: “I am not sure what exactly the reason is, but this 
> is nice.” 
> 

1) removing 160KLoc code
2) maybe the AST changes?

https://pharo.fogbugz.com/f/cases/14881/running-Smallint-rules-is-significant-slower-now
 


shows that multiple runs of a rule where slow, now the second (and every other) 
is very fast.

Marcus

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

[Tudor Girba]

On Mon, Mar 2, 2015 at 4:47 PM, Esteban Lorenzano 
wrote:

>
> On 02 Mar 2015, at 16:43, Marcus Denker  wrote:
>
> Wow!
>
> For the download of 40524, the image is 24.2, opening it and saving it
> gets that down
> to 23.2MB.This is more than 10MB smaller than a week ago.
>
> Other things TODO to make it even smaller:
>
> - Hunt down that one GTPlayground instance that is hanging around
>
>
> this should be done, after I fixed the bug I introduced with the morph
> event processing :)
>

Aha! So it was you :)

Could you describe the issue?

Doru


> - fix class annitations to not allocate 4000 empty dictionaries:
>
> https://pharo.fogbugz.com/f/cases/14956/Properties-on-Behaviour-self-properties-creates-empty-dict-for-keys
> - why is the image smaller after saving it once?
>
> https://pharo.fogbugz.com/f/cases/14367/image-from-CI-grows-with-each-build-due-to-stack
>
> Marcus
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] CI: Monkey run down to 17min

[Max Leske]

> On 02 Mar 2015, at 17:44, Alexandre Bergel  wrote:
> 
> Thanks Marcus for taking care of all of these hidden low level matters. Your 
> effort is indispensable and central to Pharo.

I second that! Although: “I am not sure what exactly the reason is, but this is 
nice.” 

:)

> 
> Alexandre
> 
> 
>> On Mar 2, 2015, at 11:24 AM, Marcus Denker  wrote:
>> 
>> Hi,
>> 
>> Since last week the time the monkey takes to run tests twice + selected code 
>> critique rules
>> is down to 17min. It was ~38 before.
>> 
>> I am not sure what exactly the reason is, but this is nice.
>> 
>>  Marcus
> 
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

[Marcus Denker]

> On 02 Mar 2015, at 16:47, Esteban Lorenzano  wrote:
> 
> 
>> On 02 Mar 2015, at 16:43, Marcus Denker > > wrote:
>> 
>> Wow!
>> 
>> For the download of 40524, the image is 24.2, opening it and saving it gets 
>> that down
>> to 23.2MB.This is more than 10MB smaller than a week ago.
>> 
>> Other things TODO to make it even smaller:
>> 
>> - Hunt down that one GTPlayground instance that is hanging around
> 
> this should be done, after I fixed the bug I introduced with the morph event 
> processing :)

No, sadly it still is there…

Marcus

Re: [Pharo-dev] CI: Monkey run down to 17min

[Alexandre Bergel]

Thanks Marcus for taking care of all of these hidden low level matters. Your 
effort is indispensable and central to Pharo.

Alexandre


> On Mar 2, 2015, at 11:24 AM, Marcus Denker  wrote:
> 
> Hi,
> 
> Since last week the time the monkey takes to run tests twice + selected code 
> critique rules
> is down to 17min. It was ~38 before.
> 
> I am not sure what exactly the reason is, but this is nice.
> 
>   Marcus

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

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

[Sven Van Caekenberghe]

> On 02 Mar 2015, at 16:49, Marcus Denker  wrote:
> 
>> 
>> On 02 Mar 2015, at 16:47, Esteban Lorenzano  wrote:
>> 
>> 
>>> On 02 Mar 2015, at 16:43, Marcus Denker  wrote:
>>> 
>>> Wow!
>>> 
>>> For the download of 40524, the image is 24.2, opening it and saving it gets 
>>> that down
>>> to 23.2MB.This is more than 10MB smaller than a week ago.
>>> 
>>> Other things TODO to make it even smaller:
>>> 
>>> - Hunt down that one GTPlayground instance that is hanging around
>> 
>> this should be done, after I fixed the bug I introduced with the morph event 
>> processing :)
> 
> No, sadly it still is there…
> 
>   Marcus

Than we won't be able to include GTPlayground in the release ... ;-)

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

[Sven Van Caekenberghe]

> On 02 Mar 2015, at 16:43, Marcus Denker  wrote:
> 
> Wow!
> 
> For the download of 40524, the image is 24.2, opening it and saving it gets 
> that down
> to 23.2MB.This is more than 10MB smaller than a week ago.
> 
> Other things TODO to make it even smaller:
> 
> - Hunt down that one GTPlayground instance that is hanging around
> - fix class annitations to not allocate 4000 empty dictionaries:
>   
> https://pharo.fogbugz.com/f/cases/14956/Properties-on-Behaviour-self-properties-creates-empty-dict-for-keys
> - why is the image smaller after saving it once?
>   
> https://pharo.fogbugz.com/f/cases/14367/image-from-CI-grows-with-each-build-due-to-stack
> 
>   Marcus

Yes, this is very cool progress.

I love it that so many small things are happening everywhere and that they 
reinforce each other. And then sometimes, something has a lot of effect ;-)

We have to make the build green too, as we are progressing to a release.

Sven

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

[Esteban Lorenzano]

> On 02 Mar 2015, at 16:49, Marcus Denker  wrote:
> 
>> 
>> On 02 Mar 2015, at 16:47, Esteban Lorenzano > > wrote:
>> 
>> 
>>> On 02 Mar 2015, at 16:43, Marcus Denker >> > wrote:
>>> 
>>> Wow!
>>> 
>>> For the download of 40524, the image is 24.2, opening it and saving it gets 
>>> that down
>>> to 23.2MB.This is more than 10MB smaller than a week ago.
>>> 
>>> Other things TODO to make it even smaller:
>>> 
>>> - Hunt down that one GTPlayground instance that is hanging around
>> 
>> this should be done, after I fixed the bug I introduced with the morph event 
>> processing :)
> 
> No, sadly it still is there…

ok… then is not my fault (and I have no idea what causes it) :)

> 
>   Marcus

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

[Marcus Denker]

> On 02 Mar 2015, at 16:58, Sven Van Caekenberghe  wrote:
> 
> 
>> On 02 Mar 2015, at 16:49, Marcus Denker  wrote:
>> 
>>> 
>>> On 02 Mar 2015, at 16:47, Esteban Lorenzano  wrote:
>>> 
>>> 
 On 02 Mar 2015, at 16:43, Marcus Denker  wrote:
 
 Wow!
 
 For the download of 40524, the image is 24.2, opening it and saving it 
 gets that down
 to 23.2MB.This is more than 10MB smaller than a week ago.
 
 Other things TODO to make it even smaller:
 
 - Hunt down that one GTPlayground instance that is hanging around
>>> 
>>> this should be done, after I fixed the bug I introduced with the morph 
>>> event processing :)
>> 
>> No, sadly it still is there…
>> 
>>  Marcus
> 
> Than we won't be able to include GTPlayground in the release ... ;-)
> 
> 
But if you can remove it, the problem would be solved…

Marcus

[Pharo-dev] CI: Monkey run down to 17min

[Marcus Denker]

Hi,

Since last week the time the monkey takes to run tests twice + selected code 
critique rules
is down to 17min. It was ~38 before.

I am not sure what exactly the reason is, but this is nice.

Marcus

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

[GitHub]

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

[Pharo-dev] ChangesBrowser should not roll own dialog (was 13017 Class renaming does not update textual class definition)

[Sean P. DeNigris]

Issue 15030: ChangesBrowser should not roll own dialog
Since Spec already provides a dialog wrapper, the ChangesBrowser should use
it.

Fix in inbox:
SLICE-Issue-15030-ChangesBrowser-should-not-roll-own-dialog-SeanDeNigris.1
- Replace hand-rolled dialog functionality with Spec's #openDialogWithSpec.
The 'Accept' button is now labeled 'Okay'. It could be changed, but I don't
see the point of the added complexity.
- Fix senders/users



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/ChangesBrowser-should-not-roll-own-dialog-was-13017-Class-renaming-does-not-update-textual-class-def-tp4808902.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] [pharo-project/pharo-core] b546d3: 40526

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: b546d3c47edc566e96587e0794847dfeaf93e43a
  
https://github.com/pharo-project/pharo-core/commit/b546d3c47edc566e96587e0794847dfeaf93e43a
  Author: Jenkins Build Server 
  Date:   2015-03-02 (Mon, 02 Mar 2015)

  Changed paths:
A Athens-Morphic.package/AthensCanvasWrapper.class/README.md
A Athens-Morphic.package/AthensCanvasWrapper.class/class/instance 
creation/on_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/definition.st
A 
Athens-Morphic.package/AthensCanvasWrapper.class/instance/accessing/allocateForm_.st
A 
Athens-Morphic.package/AthensCanvasWrapper.class/instance/accessing/canvas_.st
A 
Athens-Morphic.package/AthensCanvasWrapper.class/instance/accessing/form.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
accessing/clipRect.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
accessing/contentsOfArea_into_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
accessing/depth.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
accessing/extent.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
accessing/origin.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
converting/asShadowDrawingCanvas.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-general/drawMorph_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-general/draw_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-general/fullDrawMorph_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-general/fullDraw_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-general/roundCornersOf_during_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-general/roundCornersOf_in_during_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-images/drawImage_at_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-images/drawImage_at_sourceRect_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-images/paintImage_at_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-images/paintImage_at_sourceRect_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-images/translucentImage_at_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-images/translucentImage_at_sourceRect_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-ovals/fillOval_color_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-ovals/fillOval_color_borderWidth_borderColor_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-ovals/fillOval_fillStyle_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-ovals/fillOval_fillStyle_borderWidth_borderColor_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-polygons/drawPolygon_color_borderWidth_borderColor_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-polygons/drawPolygon_fillStyle_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-polygons/drawPolygon_fillStyle_borderWidth_borderColor_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-rectangles/fillRectangle_color_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-rectangles/fillRectangle_fillStyle_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-rectangles/fillRectangle_fillStyle_borderStyle_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-rectangles/frameAndFillRectangle_fillColor_borderWidth_borderColor_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-rectangles/frameAndFillRectangle_fillColor_borderWidth_topLeftColor_bottomRightColor_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-rectangles/frameRectangle_color_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-rectangles/frameRectangle_width_color_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-rectangles/frameRectangle_width_colors_dashes_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-support/cache_using_during_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-support/clipBy_during_.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
drawing-support/flush.st
A Athens-Morphic.package/AthensCanvasWrapper.class/instance/canvas 
d

Re: [Pharo-dev] 13017 Class renaming does not update textual class definition

[Sean P. DeNigris]

Ben Coman wrote
> is there a standard way to pause
> code execution in the sender of #openWithSpec until the window is closed?

Something like
"model openDialogWithSpec okAction: [ self doNextThing ]"?



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/13017-Class-renaming-does-not-update-textual-class-definition-tp4808879p4808890.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] [regression reporter]regression occurred

[Andrei Chis]

On Fri, Feb 27, 2015 at 6:03 PM, Andrei Chis 
wrote:

> Thanks :)
> We would still want to do one more update, maybe today or tomorrow, to add
> the extension for recording user data.
>

The last update for GTools that adds a bigger features is ready for review:
https://pharo.fogbugz.com/f/cases/15018/Integrate-GT-tools-with-event-recoder-in-spotter



Cheers,
Andrei



> Afterwards it's bug fixing mode.
>
> On Fri, Feb 27, 2015 at 5:37 PM, Marcus Denker 
> wrote:
>
>>
>>
>> On Fri, Feb 27, 2015 at 10:22 AM, Andrei Chis > > wrote:
>>
>>> The issue is waiting integration:
>>> https://pharo.fogbugz.com/f/cases/14993/Integrate-GTools
>>> There are still some more bugs to fix but we should integrate
>>> nevertheless.
>>>
>>
>> In 40 update #520
>>
>> Marcus
>>
>
>

[Pharo-dev] [Pharo4] Image size now 23.2MB

[Marcus Denker]

Wow!

For the download of 40524, the image is 24.2, opening it and saving it gets 
that down
to 23.2MB.This is more than 10MB smaller than a week ago.

Other things TODO to make it even smaller:

- Hunt down that one GTPlayground instance that is hanging around
- fix class annitations to not allocate 4000 empty dictionaries:

https://pharo.fogbugz.com/f/cases/14956/Properties-on-Behaviour-self-properties-creates-empty-dict-for-keys
 

- why is the image smaller after saving it once?

https://pharo.fogbugz.com/f/cases/14367/image-from-CI-grows-with-each-build-due-to-stack
 


Marcus

[Pharo-dev] 13017 Class renaming does not update textual class definition

[Ben Coman]

In reviewing issues that I have opened to clean out for Pharo 4 release, I
have isolated a bug further, but don't know how to proceed from there.

Essentially, the Changes Browser forks using openWithSpec, and so falls
through to the a #changed: call before the change occurs.

Opening modal might be a bit extreme, but is there a standard way to pause
code execution in the sender of #openWithSpec until the window is closed?

https://pharo.fogbugz.com/default.asp?13017

cheers -ben

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

[Esteban Lorenzano]

> On 02 Mar 2015, at 16:43, Marcus Denker  wrote:
> 
> Wow!
> 
> For the download of 40524, the image is 24.2, opening it and saving it gets 
> that down
> to 23.2MB.This is more than 10MB smaller than a week ago.
> 
> Other things TODO to make it even smaller:
> 
> - Hunt down that one GTPlayground instance that is hanging around

this should be done, after I fixed the bug I introduced with the morph event 
processing :)

> - fix class annitations to not allocate 4000 empty dictionaries:
>   
> https://pharo.fogbugz.com/f/cases/14956/Properties-on-Behaviour-self-properties-creates-empty-dict-for-keys
>  
> 
> - why is the image smaller after saving it once?
>   
> https://pharo.fogbugz.com/f/cases/14367/image-from-CI-grows-with-each-build-due-to-stack
>  
> 
> 
>   Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] 842399: 40525

[Thierry Goubier]

2015-03-02 16:33 GMT+01:00 GitHub :

>
>   Log Message:
>   ---
>   40525
> 14997 Lazy MCVersionInfo to reduce MC memory use
> https://pharo.fogbugz.com/f/cases/14997
>

Please consider this one if you see things changing in the Repository
Inspector.

Thanks,

Thierry

Re: [Pharo-dev] WhatsUp from: 2015-03-02 until: 2015-03-15

[p...@highoctane.be]

On Mon, Mar 2, 2015 at 4:27 PM, Damien Pollet  wrote:
> On 2 March 2015 at 15:11, Sean P. DeNigris  wrote:
>>
>> Cool! How do you handle namespace to prefix mapping?
>
>
> ^ self notYetDecidedAboutThat.
>
> TBH I first considered awk/sed to rewrite method files from VW-cypress to
> filetree format.
> I'll admit that thought felt perversely satisfying…
>
> I think Pharo should be able to load code that does not compile, first. The
> compiler could install pseudo-methods with the broken source code and which
> would flag the problem if you try to run them, instead of immediately
> complaining and forcing you to fix it in the middle of the process. Then we
> could have tools to fix problems.

Especially on code that Opal rejects and was accepted by the old
compiler (e.g. #. - had to figure that one out this morning).

>
> --
> Damien Pollet
> type less, do more [ | ] http://people.untyped.org/damien.pollet

Re: [Pharo-dev] Flattr

[p...@highoctane.be]

On Mon, Mar 2, 2015 at 3:44 PM, Marcus Denker  wrote:
>
>> On 02 Mar 2015, at 13:09, p...@highoctane.be wrote:
>>
>> I guess we should add a button like this to the Pharo website.
>>
>> https://flattr.com/
>>
>
> Yes! And big Donation button on the download page with paypal.. I will put it 
> on the
> TODO

Flattr can do recurring payments. Little drops make big rivers...


>
> Marcus
>
>
>

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 842399: 40525

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 842399af11ce8a6fed50de3947c50105a01a7296
  
https://github.com/pharo-project/pharo-core/commit/842399af11ce8a6fed50de3947c50105a01a7296
  Author: Jenkins Build Server 
  Date:   2015-03-02 (Mon, 02 Mar 2015)

  Changed paths:
A 
Collections-Sequenceable.package/LinkedList.class/instance/enumerating/collect_thenSelect_.st
A Monticello.package/MCLazyVersionInfo.class/README.md
A Monticello.package/MCLazyVersionInfo.class/class/class 
initialization/initialize.st
A Monticello.package/MCLazyVersionInfo.class/class/class 
initialization/install.st
A 
Monticello.package/MCLazyVersionInfo.class/class/instance-creation/from_.st
A Monticello.package/MCLazyVersionInfo.class/definition.st
A Monticello.package/MCLazyVersionInfo.class/instance/accessing/ancestors.st
A 
Monticello.package/MCLazyVersionInfo.class/instance/accessing/stepChildren.st
A Monticello.package/MCLazyVersionInfo.class/instance/comparing/species.st
A 
Monticello.package/MCLazyVersionInfo.class/instance/initialization/initialize.st
A 
Monticello.package/MCLazyVersionInfo.class/instance/initialization/initializeWithName_id_message_date_time_author_ancestors_stepChildren_.st
A Monticello.package/MCLazyVersionInfo.class/instance/initialization/lazy.st
A 
Monticello.package/MCLazyVersionInfo.class/instance/private/loadAncestorsAndStepChildren.st
A Monticello.package/MCVersionInfo.class/instance/initialization/lazy.st
A 
Monticello.package/MCWorkingAncestry.class/instance/accessing/ancestors_.st
M Monticello.package/MCWorkingAncestry.class/instance/adding/addAncestor_.st
M 
Monticello.package/MCWorkingAncestry.class/instance/adding/addStepChild_.st
A Monticello.package/MCWorkingAncestry.class/instance/initialization/lazy.st
M 
MonticelloFileTree-Core.package/extension/MCFileRepositoryInspector/instance/refresh.st
M MonticelloGUI.package/MCFileRepositoryInspector.class/definition.st
R 
MonticelloGUI.package/MCFileRepositoryInspector.class/instance/actions/computeLoadedAndInheritedFromManager_.st
M MonticelloGUI.package/MCFileRepositoryInspector.class/instance/morphic 
ui/versionHighlight_.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script524.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script525.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40524.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40525.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M Zinc-HTTP.package/ZnClient.class/instance/private/newConnectionTo_.st
M Zodiac-Core.package/ZdcSecureSocketStream.class/instance/private 
in/fillBytes_startingAt_count_.st

  Log Message:
  ---
  40525
14997 Lazy MCVersionInfo to reduce MC memory use
https://pharo.fogbugz.com/f/cases/14997

15021 LinkedList>>#collect:thenSelect: is slow
https://pharo.fogbugz.com/f/cases/15021

15022 ZdcSecureSocketStream trouble reading response with no content-length and 
connection close
https://pharo.fogbugz.com/f/cases/15022

15008 Regression: ZnClient HTTPS request through HTTP proxy failing
https://pharo.fogbugz.com/f/cases/15008

http://files.pharo.org/image/40/40525.zip

Re: [Pharo-dev] WhatsUp from: 2015-03-02 until: 2015-03-15

[Damien Pollet]

On 2 March 2015 at 15:11, Sean P. DeNigris  wrote:

> Cool! How do you handle namespace to prefix mapping?
>

^ self notYetDecidedAboutThat.

TBH I first considered awk/sed to rewrite method files from VW-cypress to
filetree format.
I'll admit that thought felt perversely satisfying…

I think Pharo should be able to load code that does not compile, first. The
compiler could install pseudo-methods with the broken source code and which
would flag the problem if you try to run them, instead of immediately
complaining and forcing you to fix it in the middle of the process. Then we
could have tools to fix problems.

-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Re: [Pharo-dev] [Reflectivity] Tiny progress of the day: MetaLink

[Marcus Denker]

> On 02 Mar 2015, at 13:18, Sean P. DeNigris  wrote:
> 
> Marcus Denker-4 wrote
>>> Could this be used in stead of Spec Adapters? That would probably require
>>> MetaLinkCollection.
>> 
>> We need to be careful using these mechanisms… it is powerful but you can
>> build very hard
>> to understand systems when using it too much...
> 
> Yes, IMHO opinion, this feature should be thought of like #instVarNamed:put:
> - awesome & powerful when you /really/ need it (usually deep within the IDE
> itself), but an anti-pattern for general use
> 
yes, the idea is that one can use this magic to build abstractions an then use
*those*. Like seaside: call/answer uses magic that you should never use in a
application code.

Marcus

Re: [Pharo-dev] Flattr

[Marcus Denker]

> On 02 Mar 2015, at 13:09, p...@highoctane.be wrote:
> 
> I guess we should add a button like this to the Pharo website.
> 
> https://flattr.com/
> 

Yes! And big Donation button on the download page with paypal.. I will put it 
on the 
TODO

Marcus

Re: [Pharo-dev] [Reflectivity] Tiny progress of the day: MetaLink

[Marcus Denker]

> On 02 Mar 2015, at 13:10, Clara Allende  wrote:
> 
> 
> Le 2 mars 2015 05:38, "Marcus Denker"  > a écrit :
> >
> > Hi,
> >
> > The tiny progress of today: I reviewed the code for the MetaLink from 
> > Clara’s Breakpoints
> > and added it to Pharo4.
> 
> Yay! There was also one extension method in Slot to make work with those, 
> have you seen it?
> 
> 

Ah, the uninstall… I will add it. 

Marcus

Re: [Pharo-dev] WhatsUp from: 2015-03-02 until: 2015-03-15

[Sean P. DeNigris]

Damien Pollet wrote
> - this in order to port a couple libs over from VW (small ones mostly, but
> Andres' Assessments would be nice eventually)

Cool! How do you handle namespace to prefix mapping?



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/WhatsUp-from-2015-03-02-until-2015-03-15-tp4808757p4808847.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] WhatsUp from: 2015-03-02 until: 2015-03-15

[Damien Pollet]

### Here's what I've been up to since the last WhatsUp:

Not much (yay burnout), but started reading code again (PPM, FileTree…)


> ### What's next, until 2015-03-15 (*):
>

- hacking on a new FileTree reader/writer that follows the latest cypress
design, and will allow to simplify the current implementation

- this in order to port a couple libs over from VW (small ones mostly, but
Andres' Assessments would be nice eventually)


-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Re: [Pharo-dev] [Reflectivity] Tiny progress of the day: MetaLink

[Sean P. DeNigris]

Marcus Denker-4 wrote
>> Could this be used in stead of Spec Adapters? That would probably require
>> MetaLinkCollection.
> 
> We need to be careful using these mechanisms… it is powerful but you can
> build very hard
> to understand systems when using it too much...

Yes, IMHO opinion, this feature should be thought of like #instVarNamed:put:
- awesome & powerful when you /really/ need it (usually deep within the IDE
itself), but an anti-pattern for general use



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Reflectivity-Tiny-progress-of-the-day-MetaLink-tp4808781p4808828.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] Flattr

[p...@highoctane.be]

I guess we should add a button like this to the Pharo website.

https://flattr.com/

Phil

Re: [Pharo-dev] [Reflectivity] Tiny progress of the day: MetaLink

[Clara Allende]

Le 2 mars 2015 05:38, "Marcus Denker"  a écrit :
>
> Hi,
>
> The tiny progress of today: I reviewed the code for the MetaLink from
Clara’s Breakpoints
> and added it to Pharo4.

Yay! There was also one extension method in Slot to make work with those,
have you seen it?

I has as state:
>
> metaObject  the target
> selectorwhat to call
> arguments   which args?
> condition   true, false or [block evaluating to a boolean]
> control before, after, replace…
> level   active at base or meta level? (to stop meta-recursion)
> nodes   where it is installed.
>
>
> -- Examples -
>
> MetaLink new
> metaObject: Halt;
> selector: #now.
>
> MetaLink new
> metaObject: [ self halt ];
> selector: #value.
>
> MetaLink new
> metaObject: #node;
> selector: tagExecuted
>
> or one that can only be installed on Message send:
>
> MetaLink
> metaObject: #object;
> selector: perform:withArguments;
> arguments: #(selector arguments);
> control: #replace
>
>
> Of course, the real core of the whole things is next: An AST transforming
compiler plugin
> that takes these links into account.
> Of course, exact details might change (e.g. control using symbols or
classes (ControlBefore)”,
> do we call it instead, replace or even AOP-style “around”?
>
> The first will be just a #before with no arguments, as this is what we
need for simple breakpoints.
>
> Marcus

Re: [Pharo-dev] [Reflectivity] Tiny progress of the day: MetaLink

[Clara Allende]

Le 2 mars 2015 05:58, "Marcus Denker"  a écrit :
>
>
> > On 02 Mar 2015, at 09:51, p...@highoctane.be wrote:
> >
> > Is there any background material one can read about these things?
> >
>
> I fear only my PhD… I never published a paper about the whole thing (huge
mistake…).
>
> http://scg.unibe.ch/archive/phd/denker-phd.pdf
>
> The problem is that this tells the story including the first steps that
where wrong (based on byte code
> and too complex). Chapter 5 is about the final model, chapter 6 discusses
meta-recursion.
> So one could read 2, the intro of 3 + 4, and then 5.
>
> I will write a real paper about the version in Pharo when it is done.

Specifically for the breakpoints there is my paper, and my blog (which I
should update at some point): clarialle...@wordpress.com

In both I do a small introduction to Reflectivity, and explain how we use
it for the breakpoints. Maybe you can start from there and then follow up
with Marcus' thesis.
>
> Marcus
>
>

Re: [Pharo-dev] [Reflectivity] Tiny progress of the day: MetaLink

[Marcus Denker]

> On 02 Mar 2015, at 11:04, Peter Uhnák  wrote:
> 
> Could this be used in stead of Spec Adapters? That would probably require 
> MetaLinkCollection.
> 

We need to be careful using these mechanisms… it is powerful but you can build 
very hard
to understand systems when using it too much...

> Peter
> 
> On Mon, Mar 2, 2015 at 9:58 AM, Marcus Denker  > wrote:
> 
> > On 02 Mar 2015, at 09:51, p...@highoctane.be  
> > wrote:
> >
> > Is there any background material one can read about these things?
> >
> 
> I fear only my PhD… I never published a paper about the whole thing (huge 
> mistake…).
> 
> http://scg.unibe.ch/archive/phd/denker-phd.pdf 
> 
> 
> The problem is that this tells the story including the first steps that where 
> wrong (based on byte code
> and too complex). Chapter 5 is about the final model, chapter 6 discusses 
> meta-recursion.
> So one could read 2, the intro of 3 + 4, and then 5.
> 
> I will write a real paper about the version in Pharo when it is done.
> 
> Marcus
> 
> 
> 

Re: [Pharo-dev] [Reflectivity] Tiny progress of the day: MetaLink

[Peter Uhnák]

Could this be used in stead of Spec Adapters? That would probably require
MetaLinkCollection.

Peter

On Mon, Mar 2, 2015 at 9:58 AM, Marcus Denker 
wrote:

>
> > On 02 Mar 2015, at 09:51, p...@highoctane.be wrote:
> >
> > Is there any background material one can read about these things?
> >
>
> I fear only my PhD… I never published a paper about the whole thing (huge
> mistake…).
>
> http://scg.unibe.ch/archive/phd/denker-phd.pdf
>
> The problem is that this tells the story including the first steps that
> where wrong (based on byte code
> and too complex). Chapter 5 is about the final model, chapter 6 discusses
> meta-recursion.
> So one could read 2, the intro of 3 + 4, and then 5.
>
> I will write a real paper about the version in Pharo when it is done.
>
> Marcus
>
>
>

[Pharo-dev] [pharo-project/pharo-core] be23e3: 40524

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: be23e3914c2b3be0ee661b5723bb01c56a16dbfb
  
https://github.com/pharo-project/pharo-core/commit/be23e3914c2b3be0ee661b5723bb01c56a16dbfb
  Author: Jenkins Build Server 
  Date:   2015-03-02 (Mon, 02 Mar 2015)

  Changed paths:
M Kernel.package/CompiledMethod.class/class/instance 
creation/headerFlagForEncoder_.st
M Kernel.package/CompiledMethod.class/instance/debugger 
support/prepareForSimulationWith_.st
M 
Refactoring-Core.package/RBRenameInstanceVariableRefactoring.class/instance/initialize-release/rename_to_in_.st
R 
Refactoring-Tests-Core.package/RBRenameInstanceVariableTest.class/instance/tests/testRenameInstVarAccessorsReferences.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script523.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script524.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40523.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40524.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  40524
14988 failing test testErrorCodeNotFound
https://pharo.fogbugz.com/f/cases/14988

15002 Rename instance variable is broken 
https://pharo.fogbugz.com/f/cases/15002

http://files.pharo.org/image/40/40524.zip

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

[GitHub]

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

Re: [Pharo-dev] [Reflectivity] Tiny progress of the day: MetaLink

[Marcus Denker]

> On 02 Mar 2015, at 09:51, p...@highoctane.be wrote:
> 
> Is there any background material one can read about these things?
> 

I fear only my PhD… I never published a paper about the whole thing (huge 
mistake…).

http://scg.unibe.ch/archive/phd/denker-phd.pdf

The problem is that this tells the story including the first steps that where 
wrong (based on byte code
and too complex). Chapter 5 is about the final model, chapter 6 discusses 
meta-recursion.
So one could read 2, the intro of 3 + 4, and then 5.

I will write a real paper about the version in Pharo when it is done.

Marcus

Re: [Pharo-dev] [Reflectivity] Tiny progress of the day: MetaLink

[p...@highoctane.be]

Is there any background material one can read about these things?

TIA
Phil

On Mon, Mar 2, 2015 at 9:38 AM, Marcus Denker  wrote:
> Hi,
>
> The tiny progress of today: I reviewed the code for the MetaLink from Clara’s 
> Breakpoints
> and added it to Pharo4. I has as state:
>
> metaObject  the target
> selectorwhat to call
> arguments   which args?
> condition   true, false or [block evaluating to a boolean]
> control before, after, replace…
> level   active at base or meta level? (to stop meta-recursion)
> nodes   where it is installed.
>
>
> -- Examples -
>
> MetaLink new
> metaObject: Halt;
> selector: #now.
>
> MetaLink new
> metaObject: [ self halt ];
> selector: #value.
>
> MetaLink new
> metaObject: #node;
> selector: tagExecuted
>
> or one that can only be installed on Message send:
>
> MetaLink
> metaObject: #object;
> selector: perform:withArguments;
> arguments: #(selector arguments);
> control: #replace
>
>
> Of course, the real core of the whole things is next: An AST transforming 
> compiler plugin
> that takes these links into account.
> Of course, exact details might change (e.g. control using symbols or classes 
> (ControlBefore)”,
> do we call it instead, replace or even AOP-style “around”?
>
> The first will be just a #before with no arguments, as this is what we need 
> for simple breakpoints.
>
> Marcus

Re: [Pharo-dev] [Reflectivity] Tiny progress of the day: MetaLink

[Sven Van Caekenberghe]

Yes, a good breakpoint facility, even a simple one, is really needed.

> On 02 Mar 2015, at 09:38, Marcus Denker  wrote:
> 
> Hi,
> 
> The tiny progress of today: I reviewed the code for the MetaLink from Clara’s 
> Breakpoints
> and added it to Pharo4. I has as state:
> 
> metaObjectthe target  
> selector  what to call
> arguments which args?
> condition true, false or [block evaluating to a boolean] 
> control   before, after, replace… 
> level active at base or meta level? (to stop meta-recursion)
> nodes where it is installed.
> 
> 
> -- Examples -
> 
> MetaLink new 
>   metaObject: Halt;
>   selector: #now.
>   
> MetaLink new 
>   metaObject: [ self halt ];
>   selector: #value.
> 
> MetaLink new 
>   metaObject: #node;
>   selector: tagExecuted
> 
> or one that can only be installed on Message send:
> 
> MetaLink 
>   metaObject: #object;
>   selector: perform:withArguments;
>   arguments: #(selector arguments);
>   control: #replace 
> 
> 
> Of course, the real core of the whole things is next: An AST transforming 
> compiler plugin
> that takes these links into account.
> Of course, exact details might change (e.g. control using symbols or classes 
> (ControlBefore)”,
> do we call it instead, replace or even AOP-style “around”?
> 
> The first will be just a #before with no arguments, as this is what we need 
> for simple breakpoints.
> 
>   Marcus

[Pharo-dev] [Reflectivity] Tiny progress of the day: MetaLink

[Marcus Denker]

Hi,

The tiny progress of today: I reviewed the code for the MetaLink from Clara’s 
Breakpoints
and added it to Pharo4. I has as state:

metaObject  the target  
selectorwhat to call
arguments   which args?
condition   true, false or [block evaluating to a boolean] 
control before, after, replace… 
level   active at base or meta level? (to stop meta-recursion)
nodes   where it is installed.


-- Examples -

MetaLink new 
metaObject: Halt;
selector: #now.

MetaLink new 
metaObject: [ self halt ];
selector: #value.

MetaLink new 
metaObject: #node;
selector: tagExecuted

or one that can only be installed on Message send:

MetaLink 
metaObject: #object;
selector: perform:withArguments;
arguments: #(selector arguments);
control: #replace 


Of course, the real core of the whole things is next: An AST transforming 
compiler plugin
that takes these links into account.
Of course, exact details might change (e.g. control using symbols or classes 
(ControlBefore)”,
do we call it instead, replace or even AOP-style “around”?

The first will be just a #before with no arguments, as this is what we need for 
simple breakpoints.

Marcus