Re: [Pharo-dev] Class/Method common interface idea

[stepharo]

Le 24/2/15 08:13, Marcus Denker a écrit :

On 23 Feb 2015, at 17:46, Yuriy Tymchuk  wrote:

Hi,

so my idea is that maybe we can create traits for common classes(behaviors) and 
methods properties. Because besides the real ones there are ring, monticello 
and other definitions. It would be nice if one could browse the trait that 
defines common properties for all the definitions + if someone needs a custom 
property - there is one place to add it.

What is clear is that we need to unify the API. We now have

propertyValueAt:

in CompiledMethod and Behaviour, while RBProgramNode uses

propertyAt:

and Morph even

valueOfProperty:

I think the best is just propertyAt:, we don’t have “valueAt:” in Array, either.


+1


As for a shared Trait… the implementation is quite different in all of them...
Indeed I think that making the API compatible is more important because 
we do not care to reuse

different implementation.
This is what ring failed a bit to do, its API should be revisited.




Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

[stepharo]

Doru and Yuriy

String is not a good API for reflective operations. This is what you are 
doing with asPackage.

When I want to access to a class I do
Class
or Smalltalk globals classNamed: 'Point'
a compile method Point>>#x
and not 'Point?x' asCompiledMethod
I would prefer to have Package named: 'jkljk' than the string behavior.

and what if I want to reflect on code that is remote?

So I maintain that we are polluting String with reflective operations 
that it should not have.


Stef

Re: [Pharo-dev] convention for protocol names

[Esteban Lorenzano]

> On 24 Feb 2015, at 08:47, Nicolai Hess  wrote:
> 
> Nautilus provides some nice icons for different protocol names
> a red square for a "private"
> a yellow diamond for "initialization"
> 
> And you can generate the initialize method. 
> But this generated initialize method is put into an "initialize" protocol. 
> 
> What is the convention a protocol for the initialize methods:
> 
> initialize
> or
> initialization
this one :)

Esteban

> ?
> 
> nicolai
> 

Re: [Pharo-dev] [Slots] Invisible Slots

[Marcus Denker]

> On 19 Feb 2015, at 10:19, Marcus Denker  wrote:
> 
>> 
>> 
>> I started to implement PropertySlot, this uses hidden slots, initialisation 
>> (to set the empty dictionary of the base slot), virtual slots
>> (the proper slots), reflectively changing the class both when adding and 
>> removing (to add the base slot and remove it as needed).
>> 
> 
> Next tiny step: 
> 
> 14914 #initializeSlots: should not skip hidden slots
>   
> https://pharo.fogbugz.com/f/cases/14914/initializeSlots-should-not-skip-hidden-slots
> 

This is now finally in 502… 5 days feel like eternity.


> Now the slots get correctly called when initialising an object. To test:
> 
> Object subclass: #TT
>   slots: { #tt => PropertySlot }
>   classVariables: {  }
>   category: ‘Playground'
> 
> The slot will add an #initialize methods to the class when it gets installed.
> 
> When you inspect
> 
> TT new
> 
> you can see just the tt slot (you can change it in the inspector).
> 
> Adding an accessor for tt will show what the compiler does:
> 
> 21 <20> pushConstant: #tt => PropertySlot
> 22 <70> self
> 23  send: read:
> 24 <7C> returnTop
> 
> 
> this means that it compiles a reflective read for that slot.

[Pharo-dev] convention for protocol names

[Nicolai Hess]

Nautilus provides some nice icons for different protocol names
a red square for a "private"
a yellow diamond for "initialization"

And you can generate the initialize method.
But this generated initialize method is put into an "initialize" protocol.

What is the convention a protocol for the initialize methods:

initialize
or
initialization
?

nicolai

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 3f2cda: 40502

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 3f2cdac7de828dde7c7a11862756359315d4fb26
  
https://github.com/pharo-project/pharo-core/commit/3f2cdac7de828dde7c7a11862756359315d4fb26
  Author: Jenkins Build Server 
  Date:   2015-02-24 (Tue, 24 Feb 2015)

  Changed paths:
M Kernel.package/Class.class/instance/instance variables/addInstVarNamed_.st
M Kernel.package/Duration.class/instance/accessing/seconds.st
A Kernel.package/Duration.class/instance/accessing/totalSeconds.st
A Kernel.package/Duration.class/instance/accessing/wholeMicroseconds.st
A Kernel.package/Duration.class/instance/accessing/wholeMilliseconds.st
A Kernel.package/Duration.class/instance/accessing/wholeNanoseconds.st
A 
Kernel.package/Duration.class/instance/printing/humanReadablePrintString.st
A Kernel.package/Duration.class/instance/printing/printHumanReadableOn_.st
A 
KernelTests.package/DurationTest.class/instance/tests/testHumanReadablePrintString.st
A KernelTests.package/DurationTest.class/instance/tests/testIsZero.st
A 
KernelTests.package/DurationTest.class/instance/tests/testPrintHumanReadableOn.st
A KernelTests.package/DurationTest.class/instance/tests/testTotalSeconds.st
A 
KernelTests.package/DurationTest.class/instance/tests/testWholeMicroseconds.st
A 
KernelTests.package/DurationTest.class/instance/tests/testWholeMilliseconds.st
A 
KernelTests.package/DurationTest.class/instance/tests/testWholeNanoseconds.st
M 
Manifest-Core.package/TheManifestBuilder.class/instance/adding%2Fremoving/removeManifestOf_.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script502.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40502.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M Slot.package/PropertyBaseSlot.class/instance/testing/isVisible.st
M Slot.package/PropertySlot.class/instance/class building/installingIn_.st
M 
Slot.package/SlotClassBuilder.class/instance/initialize-release/buildNewClass.st
M Traits.package/TBehavior.class/instance/initialization/initializeSlots_.st

  Log Message:
  ---
  40502
14960 Extend Duration with a human readable print option and some related 
accessors
https://pharo.fogbugz.com/f/cases/14960

14963 addInstVarNamed: should use addSlot:
https://pharo.fogbugz.com/f/cases/14963

14970 TheManifestBuilder>>removeManifestOf:(manifest is shadowed)
https://pharo.fogbugz.com/f/cases/14970

14914 #initializeSlots: should not skip hidden slots
https://pharo.fogbugz.com/f/cases/14914

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

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

[stepharo]

I have to think about what it means that have them in global
(in terms of having different kind of value for binding).

Stef

Le 24/2/15 08:01, Marcus Denker a écrit :

On 24 Feb 2015, at 07:49, Yuriy Tymchuk  wrote:

Just my 2 cents:

I find this really useful and have already implemented this extension in a 
couple of my packages, as writing:

RuleChecker check: (RPackageOrganizer default packageNamed: ‘Kernel’)

is much worse than:

RuleChecker check: ‘Kernel’ asPackage



Sometimes I wonder if Packages should not be part of the Smalltalk globals 
namespace…

e.g. packages could have a nice reflective API:

MyPackage unload.

and even an API for using… e.g. a Compiler has a very tiny surface API:

OpalCompiler compile: ‘….’

(but I do not really like nested classes, which is what people will now 
suggest…)

Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

[stepharo]

Interesting idea.
We should have a guy trying.
I would be curious to see what is happening in the context of Conch (the 
module system of camille).
He should present it to us too. But we would need somebody to work on 
the tools.


Now for me what I would prefer is to have a kernel in which class have a 
direct pointer to their packages like for their super/subclasses.


Stef


Le 24/2/15 08:01, Marcus Denker a écrit :

On 24 Feb 2015, at 07:49, Yuriy Tymchuk  wrote:

Just my 2 cents:

I find this really useful and have already implemented this extension in a 
couple of my packages, as writing:

RuleChecker check: (RPackageOrganizer default packageNamed: ‘Kernel’)

is much worse than:

RuleChecker check: ‘Kernel’ asPackage



Sometimes I wonder if Packages should not be part of the Smalltalk globals 
namespace…

e.g. packages could have a nice reflective API:

MyPackage unload.

and even an API for using… e.g. a Compiler has a very tiny surface API:

OpalCompiler compile: ‘….’

(but I do not really like nested classes, which is what people will now 
suggest…)

Marcus

Re: [Pharo-dev] Class/Method common interface idea

[Marcus Denker]

> On 23 Feb 2015, at 17:46, Yuriy Tymchuk  wrote:
> 
> Hi,
> 
> so my idea is that maybe we can create traits for common classes(behaviors) 
> and methods properties. Because besides the real ones there are ring, 
> monticello and other definitions. It would be nice if one could browse the 
> trait that defines common properties for all the definitions + if someone 
> needs a custom property - there is one place to add it.

What is clear is that we need to unify the API. We now have

propertyValueAt:

in CompiledMethod and Behaviour, while RBProgramNode uses

propertyAt:

and Morph even

valueOfProperty:

I think the best is just propertyAt:, we don’t have “valueAt:” in Array, either.

As for a shared Trait… the implementation is quite different in all of them...


Marcus

Re: [Pharo-dev] Example implementation of associations with Slots in Pharo 4.0

[Marcus Denker]

> On 23 Feb 2015, at 22:34, Ben Coman  wrote:
> 
> I haven't played with the relation example yet, but will real soon.  Just 
> some initial thoughts...
> 
> I like RelationSlot.  To me association seems one-way while a relation is 
> two-way.
> 
> btw, Is there some reason to not match the syntax of the often cited paper 
> "Flexible Object Layout" ?  
> I see one advantage is that its easier to read all the slot names vertically 
> aligned.
> 
> Object subclass: #SlotExampleMovie
>   slots: { 
>   #name. 
>   #year. 
>   #director => ToOneRelationSlot opposite: #directedMovies class: 
> #SlotExamplePerson.
>   #actors => ToManyRelationSlot opposite: #actedInMovies  class: 
> #SlotExamplePerson. }
>   classVariables: {  }
>   category: 'SlotAssociations-Tests-Example'
> 
> 
> Also maybe an alternative slot class name so that it reads more like a 
> sentence... "#director related to one #directedMovies in class 
> #SlotExamplePerson"
> 
> Object subclass: #SlotExampleMovie
>   slots: { 
>   #name. 
>   #year. 
>   #director => RelatedToOne inverse: #directedMovies inClass: 
> #SlotExamplePerson.
>   #actors => RelatedToMany inverse: #actedInMovies  inClass: 
> #SlotExamplePerson. }
>   classVariables: {  }
>   category: 'SlotAssociations-Tests-Example'
> 

Something like those would be good… yes, I think having the slot name in front 
is important.

Marcus

Re: [Pharo-dev] Example implementation of associations with Slots in Pharo 4.0

[Marcus Denker]

> On 23 Feb 2015, at 19:33, Jan van de Sandt  wrote:
> 
> 
> On Mon, Feb 23, 2015 at 9:59 AM, Marcus Denker  > wrote:
> 
> > On 21 Feb 2015, at 21:11, Jan van de Sandt  > > wrote:
> >
> > Today I experimented a little with the new Slots feature of Pharo 4.0. As 
> > an example I implemented support for associations/relationships.
> >
> 
> Very nice! Can I add this to Pharo4 as an example?
> 
> Sure, cool!
>  

Ok, I will do that.

Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

[Marcus Denker]

> On 24 Feb 2015, at 07:49, Yuriy Tymchuk  wrote:
> 
> Just my 2 cents:
> 
> I find this really useful and have already implemented this extension in a 
> couple of my packages, as writing:
> 
> RuleChecker check: (RPackageOrganizer default packageNamed: ‘Kernel’)
> 
> is much worse than:
> 
> RuleChecker check: ‘Kernel’ asPackage
> 
> 

Sometimes I wonder if Packages should not be part of the Smalltalk globals 
namespace…

e.g. packages could have a nice reflective API:

MyPackage unload.

and even an API for using… e.g. a Compiler has a very tiny surface API:

OpalCompiler compile: ‘….’

(but I do not really like nested classes, which is what people will now 
suggest…)

Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

[Yuriy Tymchuk]

Just my 2 cents:

I find this really useful and have already implemented this extension in a 
couple of my packages, as writing:

RuleChecker check: (RPackageOrganizer default packageNamed: ‘Kernel’)

is much worse than:

RuleChecker check: ‘Kernel’ asPackage


Uko

> On 23 Feb 2015, at 23:27, Tudor Girba  wrote:
> 
> Hi,
> 
> Indeed, having all "asXYZ from the Earth" would not be desirable to have in 
> the Kernel, but:
> - asPackage is packaged in *RPackage-SystemIntegration, so it's not in the 
> Kernel
> - I think extending String is a cheap and rather elegant way to ease common 
> access patterns, and in this case RPackage is a common thing to look at.
> 
> So, from this perspective, I think it is good to have asPackage.
> 
> If my main system would be something about Players, and I would need ways to 
> script that be sure I would have an asPlayer in my image (not in Pharo though 
> :)).
> 
> I would have actually preferred to put this in Symbol, but I saw that asClass 
> is in String and I implemented it in the same way.
> 
> Cheers,
> Doru
> 
> On Mon, Feb 23, 2015 at 11:16 PM, stepharo  > wrote:
> 
>> It is symmetrical to String>>asClass which proves rather elegant for 
>> scripting class lookup.
>> 
>> Why is it not good?
> Because you are binding RPackage (which is for now a layer on top of class) 
> directly inside the kernel
> and this should not be done like that. May be you defined it as a class 
> extension (I hope) I could not see the code.
> We should stop extending core classes. It makes the system more complex to 
> maintain and decompose.
> 
> String should not contain all the as methods from earth.
> Why we do not have asMethod, asPoint, asPlayer, asSound ?
> 
> Stef
> 
>> 
>> 
>> Le 23/2/15 15:53, Sven Van Caekenberghe a écrit :
>> Cool, we're back in business ;-)
>> 
>> yes but why having String>>asPackage is better?
>> 
>> Stef
>> 
>> 
>> 
>> 
>> -- 
>> www.tudorgirba.com 
>> 
>> "Every thing has its own flow"
> 
> 
> 
> 
> -- 
> www.tudorgirba.com 
> 
> "Every thing has its own flow"

Re: [Pharo-dev] GTInspector custom presentations discoverability idea

[Sean P. DeNigris]

Ben Coman wrote
> btw, At the end I felt like clapping with the audience.  This sort of
> overview it what has been missing from my understanding the overall
> aim/architecture of GT Tools

+100. I already knew the GT Toolkit was cool. But now I see how cool it
really is! And have a dream about how cool it will be in the future ;)

A few impressions...

1. When creating an instance-side method from within GT:
  a. BUG: When I select a method from the "Methods" pane, and write a new
method in the "Source" pane, accepting doesn't seem to do anything i.e. the
orange triangle is still there, and my new method doesn't appear in the
"Methods" pane on the left. However, if I open a new Playground, the method
is indeed saved.
  b. ENH Request: Selecting in the "Methods" pane is not a great way to
specify which class a new method should be defined in. The target class may
not have any existing methods, or the user may have to scroll extensively
searching for it.

2. Also, it would be cool if previewing/diving into a menu item showed its
builder. Right now the preview just shows the same thing as the previous
column.

3. Previews of pragmas seem to be indented a lot for no reason, and then cut
off the actual info with '...'
 



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/GTInspector-custom-presentations-discoverability-idea-tp4806872p4807121.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Athens/Morphic

[Nicolai Hess]

No, it is not yet integrated.
but this should work with pharo 40501
Merge (from pharo4 inbox): ConfigurationOfAthens-NicolaiHess.52
ConfigurationOfAthens loadVersion:'2.9'

AthensWrapWorldMorph new openInWorld



2015-02-23 23:09 GMT+01:00 stepharo :

>  I tried to load 2.9 from the athens repo into Latest update: #40501 and I
> got
> incompatibleLayoutConflict
> because apparently I got some packages that were saved
>
> Well I got totally lost.
>
>
> Le 23/2/15 23:06, stepharo a écrit :
>
>
> Le 23/2/15 09:59, Nicolai Hess a écrit :
>
>   Load the new configuration of athens (2.9)
>
>
> I could not find it in the ConfigurationBrowser or in the Pharo40 main
> repo.
> I thought that it was integrated in Pharo (I used the latest version 40501)
>
>   Open an AthensWorld:
>  AthensWrapWorldMorph new openInWorld
>
>
>  Drag and drop some morphs on this athens world.
>  (Nautilus /Old Workspace should fully work/ GT Inspector and Playground
> not)
>
>
>
> 2015-02-23 9:51 GMT+01:00 stepharo :
>
>>  how can I play with that?
>>
>> even if I should not.
>>
>> Le 20/2/15 08:54, Marcus Denker a écrit :
>>
>> Very nice! Works here (on Mac).
>>
>>  I will integrate as soon as the CI is up again…
>>
>>  Marcus
>>
>>  On 19 Feb 2015, at 12:44, Nicolai Hess  wrote:
>>
>>Most of this (without the test class (AthensTestDisplay)) is now
>> ready for
>> integration.
>>
>>  A lot of changes for making Mophic and Text(Morphs) work on Athens
>> (For testing purpose there is also the AthensWrapWorldMorph included).
>>
>>  The Canvas wrapper (AthensCanvasWrapper) is not yet included and
>> therefore
>>  all Morphs that do not explicit have a proper drawOnAthensCanvas method
>> arent't drawn (or just like rectangles).
>>
>>  Should work with any image >= 40490
>>  Just load the latest ConfigurationOfAthens from pharo 40 inbox and
>> load
>> ConfigurationOfAthens loadVersion:'2.9'
>>
>>  If this is working (or not:) ) please leave a note on fogbugz:
>> "14954 load new configuration 2.9 (more morphic support)"
>>
>>
>>  nicolai
>>
>>
>> 2015-01-31 11:54 GMT+01:00 Alain Plantec :
>>
>>>
>>>
>>> Yes the HandMorph is handled like any other Morph, it draws itself
>>> and
>>>  after that it draws all its submorphs. (And actually it does not use
>>> any caching, and it is still quite fast)
>>>
>>>
>>>  the same in Bloc, no caching and it works just fine :)
>>>
>>> But yes, it needs a special drawOnAthens method.
>>>
>>>
  Do you plane to make a package for it ?
 I would like to integrate it in Bloc.

>>>
>>>  What would like to integrate?
>>>
>>>  In fact I do not see any change when in Bloc.
>>> So I guess I will have to adapt Bloc to your changes.
>>>
>>> I will upload the changes  in Athens-Morphic package to
>>>  the Athens repository.
>>>
>>>
>>>  cool.
>>>
>>>  thanks
>>>
>>>  Alain
>>>
>>
>>
>>
>>
>
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

[Tudor Girba]

Hi,

Indeed, having all "asXYZ from the Earth" would not be desirable to have in
the Kernel, but:
- asPackage is packaged in *RPackage-SystemIntegration, so it's not in the
Kernel
- I think extending String is a cheap and rather elegant way to ease common
access patterns, and in this case RPackage is a common thing to look at.

So, from this perspective, I think it is good to have asPackage.

If my main system would be something about Players, and I would need ways
to script that be sure I would have an asPlayer in my image (not in Pharo
though :)).

I would have actually preferred to put this in Symbol, but I saw that
asClass is in String and I implemented it in the same way.

Cheers,
Doru

On Mon, Feb 23, 2015 at 11:16 PM, stepharo  wrote:

>
>  It is symmetrical to String>>asClass which proves rather elegant for
> scripting class lookup.
>
>  Why is it not good?
>
> Because you are binding RPackage (which is for now a layer on top of
> class) directly inside the kernel
> and this should not be done like that. May be you defined it as a class
> extension (I hope) I could not see the code.
> We should stop extending core classes. It makes the system more complex to
> maintain and decompose.
>
> String should not contain all the as methods from earth.
> Why we do not have asMethod, asPoint, asPlayer, asSound ?
>
> Stef
>
>
>
>> Le 23/2/15 15:53, Sven Van Caekenberghe a écrit :
>>
>>> Cool, we're back in business ;-)
>>>
>>
>>  yes but why having String>>asPackage is better?
>>
>> Stef
>>
>>
>
>
>  --
>  www.tudorgirba.com
>
>  "Every thing has its own flow"
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

[stepharo]

It is symmetrical to String>>asClass which proves rather elegant for 
scripting class lookup.


Why is it not good?
Because you are binding RPackage (which is for now a layer on top of 
class) directly inside the kernel
and this should not be done like that. May be you defined it as a class 
extension (I hope) I could not see the code.
We should stop extending core classes. It makes the system more complex 
to maintain and decompose.


String should not contain all the as methods from earth.
Why we do not have asMethod, asPoint, asPlayer, asSound ?

Stef




Le 23/2/15 15:53, Sven Van Caekenberghe a écrit :

Cool, we're back in business ;-)


yes but why having String>>asPackage is better?

Stef




--
www.tudorgirba.com 

"Every thing has its own flow"

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

[stepharo]

I know!

Now I wanted to say that we are binding everything together. We are just 
making the job of people like Pavel
and Guille more difficult. We should not expect that they will continue 
to produce a modular core if we do not

pay attention like that. At least I would be them, I would stop.

If we decide to bind package that deep into the system (because String 
is deep)

then may be we should have package inside Class definition themselves.

Stef


 Le 23/2/15 15:53, Sven Van Caekenberghe a écrit :

Cool, we're back in business ;-)

yes but why having String>>asPackage is better?

Stef

I was commenting on the CI/Integration process, not this particular issue.

Re: [Pharo-dev] Example implementation of associations with Slots in Pharo 4.0

[Tudor Girba]

Exactly :).

In Fame, there is a FMMultivalueLink hierarchy that implement many to one
and many to many relations. This implementation exists since before slots
and now we should reimplement them with slots. It will make the code so
much nicer :).

Anyone interested in picking this up?

Cheers,
Doru


On Mon, Feb 23, 2015 at 10:34 PM, Ben Coman  wrote:

> I haven't played with the relation example yet, but will real soon.  Just
> some initial thoughts...
>
> I like RelationSlot.  To me association seems one-way while a relation is
> two-way.
>
> btw, Is there some reason to not match the syntax of the often cited paper
> "Flexible Object Layout" ?
> I see one advantage is that its easier to read all the slot names
> vertically aligned.
>
> Object subclass: #SlotExampleMovie
> slots: {
> #name.
> #year.
> #director => ToOneRelationSlot opposite: #directedMovies class:
> #SlotExamplePerson.
> #actors => ToManyRelationSlot opposite: #actedInMovies  class: 
> #SlotExamplePerson.
> }
> classVariables: {  }
> category: 'SlotAssociations-Tests-Example'
>
>
> Also maybe an alternative slot class name so that it reads more like a
> sentence... "#director related to one #directedMovies in class
> #SlotExamplePerson"
>
> Object subclass: #SlotExampleMovie
> slots: {
> #name.
> #year.
> #director => RelatedToOne inverse: #directedMovies inClass:
> #SlotExamplePerson.
> #actors => RelatedToMany inverse: #actedInMovies  inClass: #SlotExamplePerson.
> }
> classVariables: {  }
> category: 'SlotAssociations-Tests-Example'
>
> Or even...
>
> Object subclass: #SlotExampleMovie
> slots: {
> #name.
> #year.
> #director => OneRelatedTo many: #directedMovies inClass:
> #SlotExamplePerson.
> #actors => ManyRelatedTo many: #actedInMovies  inClass: #SlotExamplePerson.
> }
> classVariables: {  }
> category: 'SlotAssociations-Tests-Example'
>
> cheers -ben
>
>
> On Tue, Feb 24, 2015 at 2:33 AM, Jan van de Sandt 
> wrote:
>
>>
>> On Mon, Feb 23, 2015 at 9:59 AM, Marcus Denker 
>> wrote:
>>
>>>
>>> > On 21 Feb 2015, at 21:11, Jan van de Sandt  wrote:
>>> >
>>> > Today I experimented a little with the new Slots feature of Pharo 4.0.
>>> As an example I implemented support for associations/relationships.
>>> >
>>>
>>> Very nice! Can I add this to Pharo4 as an example?
>>>
>>> Sure, cool!
>>
>>
>>> My idea is that at first we add these things as examples, and then later
>>> take the examples and distill a library of
>>> generally useful slots.
>>>
>>>
>>>
>> That sounds like a good approach to get familiar with these kind of new
>> features.
>>
>> Some things I can do to improve the Example
>> -  Add an option to make one side of the association readonly. In most
>> situations I think it's a good idea to update an association only from one
>> side to keep things simple.
>> - Whats a better name AssociationSlot or RelationSlot? I'm not sure
>> - As Stéphane said, isn't there a nicer way to declare the associations?
>> - Better error handling
>>
>> Jan.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Athens/Morphic

[stepharo]

I tried to load 2.9 from the athens repo into Latest update: #40501 and 
I got

incompatibleLayoutConflict
because apparently I got some packages that were saved

Well I got totally lost.


Le 23/2/15 23:06, stepharo a écrit :


Le 23/2/15 09:59, Nicolai Hess a écrit :

Load the new configuration of athens (2.9)


I could not find it in the ConfigurationBrowser or in the Pharo40 main 
repo.
I thought that it was integrated in Pharo (I used the latest version 
40501)



Open an AthensWorld:
AthensWrapWorldMorph new openInWorld


Drag and drop some morphs on this athens world.
(Nautilus /Old Workspace should fully work/ GT Inspector and 
Playground not)




2015-02-23 9:51 GMT+01:00 stepharo >:


how can I play with that?

even if I should not.

Le 20/2/15 08:54, Marcus Denker a écrit :

Very nice! Works here (on Mac).

I will integrate as soon as the CI is up again…

Marcus


On 19 Feb 2015, at 12:44, Nicolai Hess mailto:nicolaih...@web.de>> wrote:

Most of this (without the test class (AthensTestDisplay)) is
now ready for
integration.

A lot of changes for making Mophic and Text(Morphs) work on Athens
(For testing purpose there is also the AthensWrapWorldMorph
included).

The Canvas wrapper (AthensCanvasWrapper) is not yet included
and therefore
all Morphs that do not explicit have a proper
drawOnAthensCanvas method arent't drawn (or just like rectangles).

Should work with any image >= 40490
Just load the latest ConfigurationOfAthens from pharo 40 inbox and
load
ConfigurationOfAthens loadVersion:'2.9'

If this is working (or not:) ) please leave a note on fogbugz:
"14954 load new configuration 2.9 (more morphic support)"


nicolai


2015-01-31 11:54 GMT+01:00 Alain Plantec
mailto:alain.plan...@yahoo.com>>:




Yes the HandMorph is handled like any other Morph, it
draws itself and
after that it draws all its submorphs. (And actually it
does not use any caching, and it is still quite fast)


the same in Bloc, no caching and it works just fine :)


But yes, it needs a special drawOnAthens method.

Do you plane to make a package for it ?
I would like to integrate it in Bloc.


What would like to integrate?

In fact I do not see any change when in Bloc.
So I guess I will have to adapt Bloc to your changes.


I will upload the changes  in Athens-Morphic package to
the Athens repository.


cool.

thanks

Alain

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

[Tudor Girba]

It is symmetrical to String>>asClass which proves rather elegant for
scripting class lookup.

Why is it not good?

Doru


On Mon, Feb 23, 2015 at 10:59 PM, stepharo  wrote:

>
> Le 23/2/15 15:53, Sven Van Caekenberghe a écrit :
>
>> Cool, we're back in business ;-)
>>
>
> yes but why having String>>asPackage is better?
>
> Stef
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

[Sven Van Caekenberghe]

> On 23 Feb 2015, at 22:59, stepharo  wrote:
> 
> 
> Le 23/2/15 15:53, Sven Van Caekenberghe a écrit :
>> Cool, we're back in business ;-)
> 
> yes but why having String>>asPackage is better?
> 
> Stef

I was commenting on the CI/Integration process, not this particular issue.

Re: [Pharo-dev] Athens/Morphic

[stepharo]

Le 23/2/15 09:59, Nicolai Hess a écrit :

Load the new configuration of athens (2.9)


I could not find it in the ConfigurationBrowser or in the Pharo40 main repo.
I thought that it was integrated in Pharo (I used the latest version 40501)


Open an AthensWorld:
AthensWrapWorldMorph new openInWorld


Drag and drop some morphs on this athens world.
(Nautilus /Old Workspace should fully work/ GT Inspector and 
Playground not)




2015-02-23 9:51 GMT+01:00 stepharo >:


how can I play with that?

even if I should not.

Le 20/2/15 08:54, Marcus Denker a écrit :

Very nice! Works here (on Mac).

I will integrate as soon as the CI is up again…

Marcus


On 19 Feb 2015, at 12:44, Nicolai Hess mailto:nicolaih...@web.de>> wrote:

Most of this (without the test class (AthensTestDisplay)) is now
ready for
integration.

A lot of changes for making Mophic and Text(Morphs) work on Athens
(For testing purpose there is also the AthensWrapWorldMorph
included).

The Canvas wrapper (AthensCanvasWrapper) is not yet included and
therefore
all Morphs that do not explicit have a proper drawOnAthensCanvas
method arent't drawn (or just like rectangles).

Should work with any image >= 40490
Just load the latest ConfigurationOfAthens from pharo 40 inbox and
load
ConfigurationOfAthens loadVersion:'2.9'

If this is working (or not:) ) please leave a note on fogbugz:
"14954 load new configuration 2.9 (more morphic support)"


nicolai


2015-01-31 11:54 GMT+01:00 Alain Plantec
mailto:alain.plan...@yahoo.com>>:




Yes the HandMorph is handled like any other Morph, it draws
itself and
after that it draws all its submorphs. (And actually it
does not use any caching, and it is still quite fast)


the same in Bloc, no caching and it works just fine :)


But yes, it needs a special drawOnAthens method.

Do you plane to make a package for it ?
I would like to integrate it in Bloc.


What would like to integrate?

In fact I do not see any change when in Bloc.
So I guess I will have to adapt Bloc to your changes.


I will upload the changes  in Athens-Morphic package to
the Athens repository.


cool.

thanks

Alain

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

[stepharo]

Le 23/2/15 15:53, Sven Van Caekenberghe a écrit :

Cool, we're back in business ;-)


yes but why having String>>asPackage is better?

Stef

Re: [Pharo-dev] CI Server still down...

[Tudor Girba]

Thanks!

Doru

On Mon, Feb 23, 2015 at 3:54 PM, Sven Van Caekenberghe  wrote:

>
> > On 23 Feb 2015, at 15:52, Marcus Denker  wrote:
> >
> >>
> >> On 23 Feb 2015, at 15:27, Marcus Denker  wrote:
> >>
> >>
> >>> On 23 Feb 2015, at 15:17, Marcus Denker 
> wrote:
> >>>
> >>> So I restarted the slaves, but now the Jenkins is down:
> >>>
> >>> https://ci.inria.fr/pharo/
> >>>
> >>> I already restarted it once, it does not start up again.
> >>>
> >>>
> >>
> >>
> >> It seems to work now.
> >>
> >
> > and update 497 has been done… this means: we are back in business!
> >
> >   Marcus
>
> Thanks, Marcus !
>
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Example implementation of associations with Slots in Pharo 4.0

[Ben Coman]

I haven't played with the relation example yet, but will real soon.  Just
some initial thoughts...

I like RelationSlot.  To me association seems one-way while a relation is
two-way.

btw, Is there some reason to not match the syntax of the often cited paper
"Flexible Object Layout" ?
I see one advantage is that its easier to read all the slot names
vertically aligned.

Object subclass: #SlotExampleMovie
slots: {
#name.
#year.
#director => ToOneRelationSlot opposite: #directedMovies class:
#SlotExamplePerson.
#actors => ToManyRelationSlot opposite: #actedInMovies  class:
#SlotExamplePerson.
}
classVariables: {  }
category: 'SlotAssociations-Tests-Example'


Also maybe an alternative slot class name so that it reads more like a
sentence... "#director related to one #directedMovies in class
#SlotExamplePerson"

Object subclass: #SlotExampleMovie
slots: {
#name.
#year.
#director => RelatedToOne inverse: #directedMovies inClass:
#SlotExamplePerson.
#actors => RelatedToMany inverse: #actedInMovies  inClass: #SlotExamplePerson.
}
classVariables: {  }
category: 'SlotAssociations-Tests-Example'

Or even...

Object subclass: #SlotExampleMovie
slots: {
#name.
#year.
#director => OneRelatedTo many: #directedMovies inClass: #SlotExamplePerson.
#actors => ManyRelatedTo many: #actedInMovies  inClass: #SlotExamplePerson.
}
classVariables: {  }
category: 'SlotAssociations-Tests-Example'

cheers -ben


On Tue, Feb 24, 2015 at 2:33 AM, Jan van de Sandt 
wrote:

>
> On Mon, Feb 23, 2015 at 9:59 AM, Marcus Denker 
> wrote:
>
>>
>> > On 21 Feb 2015, at 21:11, Jan van de Sandt  wrote:
>> >
>> > Today I experimented a little with the new Slots feature of Pharo 4.0.
>> As an example I implemented support for associations/relationships.
>> >
>>
>> Very nice! Can I add this to Pharo4 as an example?
>>
>> Sure, cool!
>
>
>> My idea is that at first we add these things as examples, and then later
>> take the examples and distill a library of
>> generally useful slots.
>>
>>
>>
> That sounds like a good approach to get familiar with these kind of new
> features.
>
> Some things I can do to improve the Example
> -  Add an option to make one side of the association readonly. In most
> situations I think it's a good idea to update an association only from one
> side to keep things simple.
> - Whats a better name AssociationSlot or RelationSlot? I'm not sure
> - As Stéphane said, isn't there a nicer way to declare the associations?
> - Better error handling
>
> Jan.
>
>
>
>
>
>
>
>
>
>
>
>

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 22586d: 40500

[GitHub]

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

  Changed paths:
R 
Komitter.package/extension/EclipseUIThemeIcons/instance/overlayAddIconContents.st
R 
Komitter.package/extension/EclipseUIThemeIcons/instance/overlayModificationIconContents.st
R 
Komitter.package/extension/EclipseUIThemeIcons/instance/overlayRemoveIconContents.st
A Komitter.package/extension/ThemeIcons/instance/overlayAddIconContents.st
A 
Komitter.package/extension/ThemeIcons/instance/overlayModificationIconContents.st
A 
Komitter.package/extension/ThemeIcons/instance/overlayRemoveIconContents.st
M NativeBoost-Win32.package/NBWin32Window.class/class/as yet 
unclassified/createWindowExA_lpClassName_lpWindowName_dwStyle_x_y_width_height_hWndParent_hMenu_hInstance_lParam_.st
M NativeBoost-Win32.package/NBWin32Window.class/class/as yet 
unclassified/createWindowExW_lpClassName_lpWindowName_dwStyle_x_y_width_height_hWndParent_hMenu_hInstance_lParam_.st
M NativeBoost-Win32.package/NativeBoostWin32.class/class/library 
loading/getModuleHandle_.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script500.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40500.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M Traits.package/TClass.class/instance/initialize-release/obsolete.st
M Traits.package/TClass.class/instance/testing/isObsolete.st

  Log Message:
  ---
  40500
14631 DNU GLMThemeIcons >> overlayModificationIconContents
https://pharo.fogbugz.com/f/cases/14631

14941 isObsolete returns true for anonymous classes 
https://pharo.fogbugz.com/f/cases/14941

14728 NBFFICalloutAPI option WinUnicode is not prefixed with opt, as all the 
other options
https://pharo.fogbugz.com/f/cases/14728

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

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

[GitHub]

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

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 7e744b: 40499

[GitHub]

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

  Changed paths:
A 
FileSystem-Core.package/AbstractFileReference.class/instance/enumerating/allChildrenMatching_.st
A 
FileSystem-Core.package/AbstractFileReference.class/instance/enumerating/allDirectoriesMatching_.st
M 
FileSystem-Core.package/AbstractFileReference.class/instance/private/childGeneratorBlock_matching_.st
M Graphics-Transformations.package/MorphicTransform.class/class/instance 
creation/offset_angle_scale_.st
M 
Graphics-Transformations.package/MorphicTransform.class/instance/accessing/withAngle_.st
M 
Graphics-Transformations.package/MorphicTransform.class/instance/accessing/withOffset_.st
M 
Graphics-Transformations.package/MorphicTransform.class/instance/accessing/withScale_.st
M 
Graphics-Transformations.package/MorphicTransform.class/instance/private/setAngle_.st
M 
Graphics-Transformations.package/MorphicTransform.class/instance/private/setOffset_angle_scale_.st
M 
Graphics-Transformations.package/MorphicTransform.class/instance/private/setScale_.st
M 
ProfStef-Core.package/PharoSyntaxTutorial.class/instance/interactive/divideTwoByZero.st
R 
ProfStef-Core.package/PharoSyntaxTutorial.class/instance/lessons/instanciation.st
A 
ProfStef-Core.package/PharoSyntaxTutorial.class/instance/lessons/instantiation.st
M 
ProfStef-Core.package/PharoSyntaxTutorial.class/instance/tutorial/tutorial.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script499.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40499.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  40499
14971 MorphicTransform: Better Argument Names
https://pharo.fogbugz.com/f/cases/14971

14961 instantiation is misspelled in PharoSyntaxTutorial
https://pharo.fogbugz.com/f/cases/14961

14947 Missing allChildrenMatching:
https://pharo.fogbugz.com/f/cases/14947

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

Re: [Pharo-dev] Determine if a method is Jitted or not

[Thierry Goubier]

2015-02-23 16:36 GMT+01:00 Eliot Miranda :

> Hi Thierry,
>
>  there's an unadvertised primitive called Context>>#xRay (or
> ContextPart>>#xRay) that answers these questions for tests.  I'm away from
> the system right now but I'll get you the source soon.  Also, the limit on
> jutting methods, 60 literals, is a default. There's a command line option
> -maxcoglits (IIRC) that you can change.
>

Thanks Eliot!

It's helping a lot to guide me, even if I have to work at the ast level
and, as a result, I estimate the number of literals in the bytecode by
counting the number of literal nodes in the AST, with the approximation
that ~100 literal nodes will make it under the limit.

Making it under the limit shaves 30% of the execution time of a parse with
SmaCC. And it avoids the too long methods as a side benefit.

I would dream of having precise ways of estimating things like that on the
AST. It's interesting to hit those "I'd like to be able to predict the
performance of that piece of code" issues.

Thierry


>
> Eliot (phone)
>
> On Feb 23, 2015, at 5:05 AM, Thierry Goubier 
> wrote:
>
> > Hi All,
> >
> > anybody knows how to check if a method is jitted or not?
> >
> > I remember (maybe wrongly) that the Jit in Cog has a configurable limit
> on the number of bytecodes for a method to be jitted or not; I'm looking
> into the performance of generated code where I can, more or less, control
> the length of methods (SmaCC) and I'd like to find the optimum point.
> >
> > Thanks,
> >
> > Thierry
>
>

Re: [Pharo-dev] Determine if a method is Jitted or not

[Eliot Miranda]

Hi Thierry,

 there's an unadvertised primitive called Context>>#xRay (or 
ContextPart>>#xRay) that answers these questions for tests.  I'm away from the 
system right now but I'll get you the source soon.  Also, the limit on jutting 
methods, 60 literals, is a default. There's a command line option -maxcoglits 
(IIRC) that you can change. 

Eliot (phone)

On Feb 23, 2015, at 5:05 AM, Thierry Goubier  wrote:

> Hi All,
> 
> anybody knows how to check if a method is jitted or not?
> 
> I remember (maybe wrongly) that the Jit in Cog has a configurable limit on 
> the number of bytecodes for a method to be jitted or not; I'm looking into 
> the performance of generated code where I can, more or less, control the 
> length of methods (SmaCC) and I'd like to find the optimum point.
> 
> Thanks,
> 
> Thierry

Re: [Pharo-dev] [pharo-project/pharo-core] 6e105e: 40498

[Marcus Denker]

> On 23 Feb 2015, at 16:20, GitHub  wrote:
> 
>  Branch: refs/heads/4.0
>  Home:   https://github.com/pharo-project/pharo-core
>  Commit: 6e105eaf2fe849f630afc1aae35355b855ad1399
>  
> https://github.com/pharo-project/pharo-core/commit/6e105eaf2fe849f630afc1aae35355b855ad1399
>  Author: Jenkins Build Server 
>  Date:   2015-02-23 (Mon, 23 Feb 2015)
> 
>  Changed paths:
>A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
> scripts/script498.st
>A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
> updates/update40498.st
>M 
> ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
> 
>  Log Message:
>  ---
>  40498
> 14961 instantiation is misspelled in PharoSyntaxTutorial
>   https://pharo.fogbugz.com/f/cases/14961
> 
> 14947 Missing allChildrenMatching:
>   https://pharo.fogbugz.com/f/cases/14947
> 
> 14971 MorphicTransform: Better Argument Names
>   https://pharo.fogbugz.com/f/cases/14971


No, this one is empty. Strange. 

I will do a manual update next.

Marcus

[Pharo-dev] Fwd: Build failed in Jenkins: NeoCSV » 40,stable,vm #474

[Sven Van Caekenberghe]

Disk full on the contribution CI ...

> Begin forwarded message:
> 
> Date: 23 Feb 2015 16:26:46 CET
> From: ci-pharo-contribut...@inria.fr
> To: s...@stfx.eu
> Subject: Build failed in Jenkins: NeoCSV » 40,stable,vm #474
> 
> See 
> 
> 
> --
> Started by upstream project "NeoCSV" build number 475
> originally caused by:
> Started by timer
> Building remotely on pharo-contribution-linux64.ci.inria.fr (32 64 linux) in 
> workspace 
> 
> 
> Deleting project workspace... [vm] $ /bin/sh -xe 
> /tmp/hudson5392095292005988537.sh
> + export JOB_NAME=NeoCSV
> + bash
> + wget --quiet -O - get.pharo.org/40+vm
> Downloading the latest 40 Image:
>http://files.pharo.org/image/40/latest.zip
> Pharo.image
> Downloading the latest pharoVM:
>   http://files.pharo.org/vm/pharo/linux/stable.zip
> pharo-vm/pharo
> Downloading PharoV10.sources:
>   http://files.pharo.org/sources//PharoV10.sources.zip
> Downloading PharoV20.sources:
>   http://files.pharo.org/sources//PharoV20.sources.zip
> Downloading PharoV30.sources:
>   http://files.pharo.org/sources//PharoV30.sources.zip
> pharo-vm/PharoV30.sources:  write error (disk full?).  Continue? (y/n/^C) 
> warning:  pharo-vm/PharoV30.sources is probably truncated
> Build step 'Execute shell' marked build as failure
> Archiving artifacts
> Recording test results

[Pharo-dev] [pharo-project/pharo-core] 6e105e: 40498

[GitHub]

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

  Changed paths:
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script498.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40498.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  40498
14961 instantiation is misspelled in PharoSyntaxTutorial
https://pharo.fogbugz.com/f/cases/14961

14947 Missing allChildrenMatching:
https://pharo.fogbugz.com/f/cases/14947

14971 MorphicTransform: Better Argument Names
https://pharo.fogbugz.com/f/cases/14971

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

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

[GitHub]

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

Re: [Pharo-dev] CI Server still down...

[Sven Van Caekenberghe]

> On 23 Feb 2015, at 15:52, Marcus Denker  wrote:
> 
>> 
>> On 23 Feb 2015, at 15:27, Marcus Denker  wrote:
>> 
>> 
>>> On 23 Feb 2015, at 15:17, Marcus Denker  wrote:
>>> 
>>> So I restarted the slaves, but now the Jenkins is down:
>>> 
>>> https://ci.inria.fr/pharo/
>>> 
>>> I already restarted it once, it does not start up again.
>>>  
>>> 
>> 
>> 
>> It seems to work now.
>> 
> 
> and update 497 has been done… this means: we are back in business!
> 
>   Marcus

Thanks, Marcus !

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

[Sven Van Caekenberghe]

Cool, we're back in business ;-)

> On 23 Feb 2015, at 15:52, GitHub  wrote:
> 
>  Branch: refs/heads/4.0
>  Home:   https://github.com/pharo-project/pharo-core
>  Commit: 3fabea9dab3061c6749f77aef01dc44bad73167c
>  
> https://github.com/pharo-project/pharo-core/commit/3fabea9dab3061c6749f77aef01dc44bad73167c
>  Author: Jenkins Build Server 
>  Date:   2015-02-23 (Mon, 23 Feb 2015)
> 
>  Changed paths:
>A Kernel.package/Number.class/instance/converting/percent.st
>A KernelTests.package/NumberTest.class/instance/tests/testPercent.st
>A RPackage-SystemIntegration.package/extension/String/instance/asPackage.st
>A 
> RPackage-SystemIntegration.package/extension/String/instance/asPackageIfAbsent_.st
>A RPackage-Tests.package/RPackageStringExtensionTest.class/README.md
>A RPackage-Tests.package/RPackageStringExtensionTest.class/definition.st
>A 
> RPackage-Tests.package/RPackageStringExtensionTest.class/instance/tests/testAsPackage.st
>A 
> RPackage-Tests.package/RPackageStringExtensionTest.class/instance/tests/testAsPackageIfAbsent.st
>A 
> RPackage-Tests.package/RPackageStringExtensionTest.class/instance/tests/testAsPackageWithError.st
>A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
> scripts/script497.st
>A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
> updates/update40497.st
>M 
> ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
>M 
> Spec-PolyWidgets.package/DateModel.class/instance/initialization/initializeWidgets.st
> 
>  Log Message:
>  ---
>  40497
> 14949 String>>asPackage
>   https://pharo.fogbugz.com/f/cases/14949
> 
> 14957 Number>>#percent
>   https://pharo.fogbugz.com/f/cases/14957
> 
> 14958 DateModel>>#initializeWidgets error
>   https://pharo.fogbugz.com/f/cases/14958
> 
> http://files.pharo.org/image/40/40497.zip
> 
> 

Re: [Pharo-dev] Determine if a method is Jitted or not

[Clément Bera]

2015-02-23 15:08 GMT+01:00 Thierry Goubier :

> Hi Clement,
>
> 2015-02-23 14:46 GMT+01:00 Clément Bera :
>
>>
>> Any method is jitted if when activated it's already in the global lookup
>> cache and it's not already jitted (so mostly on second calls).
>>
>
> Ok.
>
>
>>
>> The only limit is on the number of literals. A method with more than a
>> certain number of literals (by default, 64) is not jitted. You can change
>> this limit by starting the VM with a specific command line argument (I
>> don't remember, something like --maxNumLiterals, you will find it when
>> pressing --help I don't have access to a VM right now). Basically the limit
>> is to 64 because the GC consume a lot of time in the machine code zone.
>> Each literals require specific care because their addresses are directly in
>> the generated code (Has the literal moved in memory, ...).
>>
>
> 64 literals in a method... This means something like :
>
> aCompiledMethod numLiterals <= 64
>
> Would reasonably tells me which methods will be jitted.
>

Yes. This is the code in VMMAker:

^(objectMemory literalCountOfMethodHeader: methodHeader) <=
maxLiteralCountForCompile


>
>
>>
>> There's a few other things, such as a method with unknown bytecodes will
>> not be jitted (so you can rely for example on the respondsToUnknownBytecode
>> hook with interpreted methods), but I don't think it matters for you.
>>
>
> And unknown bytecodes won't be generated by standard smalltalk code,
> right? So it shouldn't matter to me.
>

No. But I wrote that just so you know if you start doing exotic things
there are other constraints than just the number of literals.

>
> This is very helpful, thanks.
>
> Thierry
>

Re: [Pharo-dev] CI Server still down...

[Marcus Denker]

> On 23 Feb 2015, at 15:27, Marcus Denker  wrote:
> 
> 
>> On 23 Feb 2015, at 15:17, Marcus Denker > > wrote:
>> 
>> So I restarted the slaves, but now the Jenkins is down:
>> 
>> https://ci.inria.fr/pharo/ 
>> 
>> I already restarted it once, it does not start up again.
>>  
>> 
> 
> 
> It seems to work now.
> 

and update 497 has been done… this means: we are back in business!

Marcus

[Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

[GitHub]

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

  Changed paths:
A Kernel.package/Number.class/instance/converting/percent.st
A KernelTests.package/NumberTest.class/instance/tests/testPercent.st
A RPackage-SystemIntegration.package/extension/String/instance/asPackage.st
A 
RPackage-SystemIntegration.package/extension/String/instance/asPackageIfAbsent_.st
A RPackage-Tests.package/RPackageStringExtensionTest.class/README.md
A RPackage-Tests.package/RPackageStringExtensionTest.class/definition.st
A 
RPackage-Tests.package/RPackageStringExtensionTest.class/instance/tests/testAsPackage.st
A 
RPackage-Tests.package/RPackageStringExtensionTest.class/instance/tests/testAsPackageIfAbsent.st
A 
RPackage-Tests.package/RPackageStringExtensionTest.class/instance/tests/testAsPackageWithError.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script497.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40497.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M 
Spec-PolyWidgets.package/DateModel.class/instance/initialization/initializeWidgets.st

  Log Message:
  ---
  40497
14949 String>>asPackage
https://pharo.fogbugz.com/f/cases/14949

14957 Number>>#percent
https://pharo.fogbugz.com/f/cases/14957

14958 DateModel>>#initializeWidgets error
https://pharo.fogbugz.com/f/cases/14958

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

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

[GitHub]

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

Re: [Pharo-dev] CI Server still down...

[Marcus Denker]

> On 23 Feb 2015, at 15:17, Marcus Denker  wrote:
> 
> So I restarted the slaves, but now the Jenkins is down:
> 
> https://ci.inria.fr/pharo/ 
> 
> I already restarted it once, it does not start up again.
>  
> 


It seems to work now.

> I try again….
> 
>> On 23 Feb 2015, at 14:49, Marcus Denker > > wrote:
>> 
>> Ci is up again… we now need to restart the slaves.
>> 
>>> On 20 Feb 2015, at 11:03, Marcus Denker >> > wrote:
>>> 
>>> Hi,
>>> 
>>> CI Servers are still down.
>>> 
>>> Until they are up we can not do any integration nor run the automatic check
>>> on submitted things.
>>> 
>>> Marcus
>> 
> 

Re: [Pharo-dev] CI Server still down...

[Marcus Denker]

> On 23 Feb 2015, at 15:13, Sven Van Caekenberghe  wrote:
> 
> The build queues are massive ... 600+ on contrib
> Maybe they need to be reset ?
> 

Yes, that would be good. I wonder if there is a way to do that without clicking 
600 times?

>> On 23 Feb 2015, at 14:49, Marcus Denker  wrote:
>> 
>> Ci is up again… we now need to restart the slaves.
>> 
>>> On 20 Feb 2015, at 11:03, Marcus Denker  wrote:
>>> 
>>> Hi,
>>> 
>>> CI Servers are still down.
>>> 
>>> Until they are up we can not do any integration nor run the automatic check
>>> on submitted things.
>>> 
>>> Marcus
>> 
>> 
> 
> 

Re: [Pharo-dev] CI Server still down...

[Marcus Denker]

So I restarted the slaves, but now the Jenkins is down:

https://ci.inria.fr/pharo/ 

I already restarted it once, it does not start up again.
 

I try again….

> On 23 Feb 2015, at 14:49, Marcus Denker  wrote:
> 
> Ci is up again… we now need to restart the slaves.
> 
>> On 20 Feb 2015, at 11:03, Marcus Denker  wrote:
>> 
>> Hi,
>> 
>> CI Servers are still down.
>> 
>> Until they are up we can not do any integration nor run the automatic check
>> on submitted things.
>> 
>>  Marcus
> 

Re: [Pharo-dev] CI Server still down...

[Sven Van Caekenberghe]

The build queues are massive ... 600+ on contrib
Maybe they need to be reset ?

> On 23 Feb 2015, at 14:49, Marcus Denker  wrote:
> 
> Ci is up again… we now need to restart the slaves.
> 
>> On 20 Feb 2015, at 11:03, Marcus Denker  wrote:
>> 
>> Hi,
>> 
>> CI Servers are still down.
>> 
>> Until they are up we can not do any integration nor run the automatic check
>> on submitted things.
>> 
>>  Marcus
> 
> 

Re: [Pharo-dev] Determine if a method is Jitted or not

[Thierry Goubier]

Hi Clement,

2015-02-23 14:46 GMT+01:00 Clément Bera :

>
> Any method is jitted if when activated it's already in the global lookup
> cache and it's not already jitted (so mostly on second calls).
>

Ok.


>
> The only limit is on the number of literals. A method with more than a
> certain number of literals (by default, 64) is not jitted. You can change
> this limit by starting the VM with a specific command line argument (I
> don't remember, something like --maxNumLiterals, you will find it when
> pressing --help I don't have access to a VM right now). Basically the limit
> is to 64 because the GC consume a lot of time in the machine code zone.
> Each literals require specific care because their addresses are directly in
> the generated code (Has the literal moved in memory, ...).
>

64 literals in a method... This means something like :

aCompiledMethod numLiterals <= 64

Would reasonably tells me which methods will be jitted.


>
> There's a few other things, such as a method with unknown bytecodes will
> not be jitted (so you can rely for example on the respondsToUnknownBytecode
> hook with interpreted methods), but I don't think it matters for you.
>

And unknown bytecodes won't be generated by standard smalltalk code, right?
So it shouldn't matter to me.

This is very helpful, thanks.

Thierry

Re: [Pharo-dev] CI Server still down...

[Marcus Denker]

Ci is up again… we now need to restart the slaves.

> On 20 Feb 2015, at 11:03, Marcus Denker  wrote:
> 
> Hi,
> 
> CI Servers are still down.
> 
> Until they are up we can not do any integration nor run the automatic check
> on submitted things.
> 
>   Marcus

Re: [Pharo-dev] Determine if a method is Jitted or not

[Clément Bera]

2015-02-23 14:05 GMT+01:00 Thierry Goubier :

> Hi All,
>

Hello,

>
> anybody knows how to check if a method is jitted or not?
>

I don't think there's a way to do that.

>
> I remember (maybe wrongly) that the Jit in Cog has a configurable limit on
> the number of bytecodes for a method to be jitted or not; I'm looking into
> the performance of generated code where I can, more or less, control the
> length of methods (SmaCC) and I'd like to find the optimum point.
>
> Any method is jitted if when activated it's already in the global lookup
cache and it's not already jitted (so mostly on second calls).

The only limit is on the number of literals. A method with more than a
certain number of literals (by default, 64) is not jitted. You can change
this limit by starting the VM with a specific command line argument (I
don't remember, something like --maxNumLiterals, you will find it when
pressing --help I don't have access to a VM right now). Basically the limit
is to 64 because the GC consume a lot of time in the machine code zone.
Each literals require specific care because their addresses are directly in
the generated code (Has the literal moved in memory, ...).

There's a few other things, such as a method with unknown bytecodes will
not be jitted (so you can rely for example on the respondsToUnknownBytecode
hook with interpreted methods), but I don't think it matters for you.

> Thanks,
>
> Thierry
>

[Pharo-dev] Determine if a method is Jitted or not

[Thierry Goubier]

Hi All,

anybody knows how to check if a method is jitted or not?

I remember (maybe wrongly) that the Jit in Cog has a configurable limit on
the number of bytecodes for a method to be jitted or not; I'm looking into
the performance of generated code where I can, more or less, control the
length of methods (SmaCC) and I'd like to find the optimum point.

Thanks,

Thierry

Re: [Pharo-dev] Athens/Morphic

[kilon alios]

so that means now athens mix with morphic just fine without extra work ,
great work guys :)

On Mon, Feb 23, 2015 at 10:59 AM, Nicolai Hess  wrote:

> Load the new configuration of athens (2.9)
> Open an AthensWorld:
> AthensWrapWorldMorph new openInWorld
>
>
> Drag and drop some morphs on this athens world.
> (Nautilus /Old Workspace should fully work/ GT Inspector and Playground
> not)
>
>
>
> 2015-02-23 9:51 GMT+01:00 stepharo :
>
>>  how can I play with that?
>>
>> even if I should not.
>>
>> Le 20/2/15 08:54, Marcus Denker a écrit :
>>
>> Very nice! Works here (on Mac).
>>
>>  I will integrate as soon as the CI is up again…
>>
>>  Marcus
>>
>>  On 19 Feb 2015, at 12:44, Nicolai Hess  wrote:
>>
>>Most of this (without the test class (AthensTestDisplay)) is now
>> ready for
>> integration.
>>
>>  A lot of changes for making Mophic and Text(Morphs) work on Athens
>> (For testing purpose there is also the AthensWrapWorldMorph included).
>>
>>  The Canvas wrapper (AthensCanvasWrapper) is not yet included and
>> therefore
>>  all Morphs that do not explicit have a proper drawOnAthensCanvas method
>> arent't drawn (or just like rectangles).
>>
>>  Should work with any image >= 40490
>>  Just load the latest ConfigurationOfAthens from pharo 40 inbox and
>> load
>> ConfigurationOfAthens loadVersion:'2.9'
>>
>>  If this is working (or not:) ) please leave a note on fogbugz:
>> "14954 load new configuration 2.9 (more morphic support)"
>>
>>
>>  nicolai
>>
>>
>> 2015-01-31 11:54 GMT+01:00 Alain Plantec :
>>
>>>
>>>
>>> Yes the HandMorph is handled like any other Morph, it draws itself
>>> and
>>>  after that it draws all its submorphs. (And actually it does not use
>>> any caching, and it is still quite fast)
>>>
>>>
>>>  the same in Bloc, no caching and it works just fine :)
>>>
>>> But yes, it needs a special drawOnAthens method.
>>>
>>>
  Do you plane to make a package for it ?
 I would like to integrate it in Bloc.

>>>
>>>  What would like to integrate?
>>>
>>>  In fact I do not see any change when in Bloc.
>>> So I guess I will have to adapt Bloc to your changes.
>>>
>>> I will upload the changes  in Athens-Morphic package to
>>>  the Athens repository.
>>>
>>>
>>>  cool.
>>>
>>>  thanks
>>>
>>>  Alain
>>>
>>
>>
>>
>>
>

Re: [Pharo-dev] Weird method source…

[Yuriy Tymchuk]

Update:

I’ve checked in clean image and it’s ok, looks like some profiling stuff that I 
load is modifying that.

Uko

> On 23 Feb 2015, at 10:27, Yuriy Tymchuk  wrote:
> 
> Hi,
> 
> Take a look at the a look at the attached pic please. It should display a 
> method #viewChanges:from:to: but as source you have #with3arg:arg:arg:
> 
> 
> 
> Uko

Re: [Pharo-dev] Example implementation of associations with Slots in Pharo 4.0

[Marcus Denker]

> On 21 Feb 2015, at 21:11, Jan van de Sandt  wrote:
> 
> Today I experimented a little with the new Slots feature of Pharo 4.0. As an 
> example I implemented support for associations/relationships. 
> 

Very nice! Can I add this to Pharo4 as an example?

My idea is that at first we add these things as examples, and then later take 
the examples and distill a library of 
generally useful slots.

Marcus

Re: [Pharo-dev] Athens/Morphic

[Nicolai Hess]

Load the new configuration of athens (2.9)
Open an AthensWorld:
AthensWrapWorldMorph new openInWorld


Drag and drop some morphs on this athens world.
(Nautilus /Old Workspace should fully work/ GT Inspector and Playground
not)



2015-02-23 9:51 GMT+01:00 stepharo :

>  how can I play with that?
>
> even if I should not.
>
> Le 20/2/15 08:54, Marcus Denker a écrit :
>
> Very nice! Works here (on Mac).
>
>  I will integrate as soon as the CI is up again…
>
>  Marcus
>
>  On 19 Feb 2015, at 12:44, Nicolai Hess  wrote:
>
>Most of this (without the test class (AthensTestDisplay)) is now ready
> for
> integration.
>
>  A lot of changes for making Mophic and Text(Morphs) work on Athens
> (For testing purpose there is also the AthensWrapWorldMorph included).
>
>  The Canvas wrapper (AthensCanvasWrapper) is not yet included and therefore
>  all Morphs that do not explicit have a proper drawOnAthensCanvas method
> arent't drawn (or just like rectangles).
>
>  Should work with any image >= 40490
>  Just load the latest ConfigurationOfAthens from pharo 40 inbox and
> load
> ConfigurationOfAthens loadVersion:'2.9'
>
>  If this is working (or not:) ) please leave a note on fogbugz:
> "14954 load new configuration 2.9 (more morphic support)"
>
>
>  nicolai
>
>
> 2015-01-31 11:54 GMT+01:00 Alain Plantec :
>
>>
>>
>> Yes the HandMorph is handled like any other Morph, it draws itself
>> and
>>  after that it draws all its submorphs. (And actually it does not use
>> any caching, and it is still quite fast)
>>
>>
>>  the same in Bloc, no caching and it works just fine :)
>>
>> But yes, it needs a special drawOnAthens method.
>>
>>
>>>  Do you plane to make a package for it ?
>>> I would like to integrate it in Bloc.
>>>
>>
>>  What would like to integrate?
>>
>>  In fact I do not see any change when in Bloc.
>> So I guess I will have to adapt Bloc to your changes.
>>
>> I will upload the changes  in Athens-Morphic package to
>>  the Athens repository.
>>
>>
>>  cool.
>>
>>  thanks
>>
>>  Alain
>>
>
>
>
>

Re: [Pharo-dev] Athens/Morphic

[Marcus Denker]

> On 23 Feb 2015, at 09:51, stepharo  wrote:
> 
> how can I play with that?
> 
> even if I should not.
> 

I loaded Athens and then did

AthensWrapWorldMorph new openInWorld

I think.

> Le 20/2/15 08:54, Marcus Denker a écrit :
>> Very nice! Works here (on Mac).
>> 
>> I will integrate as soon as the CI is up again…
>> 
>> 
>> Marcus
>> 
>>> On 19 Feb 2015, at 12:44, Nicolai Hess >> > wrote:
>>> 
>>> Most of this (without the test class (AthensTestDisplay)) is now ready for
>>> integration.
>>> 
>>> A lot of changes for making Mophic and Text(Morphs) work on Athens 
>>> (For testing purpose there is also the AthensWrapWorldMorph included).
>>> 
>>> The Canvas wrapper (AthensCanvasWrapper) is not yet included and therefore
>>> all Morphs that do not explicit have a proper drawOnAthensCanvas method 
>>> arent't drawn (or just like rectangles).
>>> 
>>> Should work with any image >= 40490
>>> Just load the latest ConfigurationOfAthens from pharo 40 inbox and
>>> load
>>> ConfigurationOfAthens loadVersion:'2.9'
>>> 
>>> If this is working (or not:) ) please leave a note on fogbugz:
>>> "14954 load new configuration 2.9 (more morphic support)"
>>> 
>>> 
>>> nicolai
>>> 
>>> 
>>> 2015-01-31 11:54 GMT+01:00 Alain Plantec >> >:
>>> 
 
 Yes the HandMorph is handled like any other Morph, it draws itself and
 after that it draws all its submorphs. (And actually it does not use any 
 caching, and it is still quite fast)
>>> 
>>> the same in Bloc, no caching and it works just fine :)
>>> 
 But yes, it needs a special drawOnAthens method.
  
 Do you plane to make a package for it ?
 I would like to integrate it in Bloc.
 
 What would like to integrate?
>>> 
>>> In fact I do not see any change when in Bloc.
>>> So I guess I will have to adapt Bloc to your changes.
>>> 
 I will upload the changes  in Athens-Morphic package to
 the Athens repository. 
>>> 
>>> cool.
>>> 
>>> thanks
>>> 
>>> Alain
>>> 
>> 
> 

Re: [Pharo-dev] Athens/Morphic

[stepharo]

how can I play with that?

even if I should not.

Le 20/2/15 08:54, Marcus Denker a écrit :

Very nice! Works here (on Mac).

I will integrate as soon as the CI is up again…

Marcus

On 19 Feb 2015, at 12:44, Nicolai Hess > wrote:


Most of this (without the test class (AthensTestDisplay)) is now 
ready for

integration.

A lot of changes for making Mophic and Text(Morphs) work on Athens
(For testing purpose there is also the AthensWrapWorldMorph included).

The Canvas wrapper (AthensCanvasWrapper) is not yet included and 
therefore
all Morphs that do not explicit have a proper drawOnAthensCanvas 
method arent't drawn (or just like rectangles).


Should work with any image >= 40490
Just load the latest ConfigurationOfAthens from pharo 40 inbox and
load
ConfigurationOfAthens loadVersion:'2.9'

If this is working (or not:) ) please leave a note on fogbugz:
"14954 load new configuration 2.9 (more morphic support)"


nicolai


2015-01-31 11:54 GMT+01:00 Alain Plantec >:





Yes the HandMorph is handled like any other Morph, it draws
itself and
after that it draws all its submorphs. (And actually it does not
use any caching, and it is still quite fast)


the same in Bloc, no caching and it works just fine :)


But yes, it needs a special drawOnAthens method.

Do you plane to make a package for it ?
I would like to integrate it in Bloc.


What would like to integrate?

In fact I do not see any change when in Bloc.
So I guess I will have to adapt Bloc to your changes.


I will upload the changes in Athens-Morphic package to
the Athens repository.


cool.

thanks

Alain

Re: [Pharo-dev] GTInspector custom presentations discoverability idea

[stepharo]

fixed!

Le 22/2/15 15:50, Ben Coman a écrit :
On the pharo.org  home page, maybe "moldable tools" 
should be added under the "Feel a live environment" heading.  btw, I 
notice there that "developping" has too many 'p's.