Re: [Pharo-dev] Roassal2 / Application Matrix

[Alexandre Bergel]

Hi Volkert,

There was a small problem when we generated the SVG file. Milton fixed it. 
Update Roassal and you will enjoy the expected behavior.

By the way, will you be at esug?

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



> On Jun 30, 2015, at 2:50 PM, volkert  wrote:
> 
> That is my plan ;-) Can you have look to the svg export? The inner boxes have 
> no coloring.
> 
> BW,
> Volkert
> 
> Am 30.06.2015 um 00:53 schrieb Alexandre Bergel:
>> Volker, I started to do something called RTApplicationMatrix.
>> But the Peter’s script seems to do a much better job. It would be great if 
>> you can structure it a bit.
>> 
>> Alexandre
>> 
>> 
>>> On Jun 28, 2015, at 8:56 AM, Peter Uhnák  wrote:
>>> 
>>> Well if you want super-crude procedural prototype, I've made this 
>>> http://ws.stfx.eu/MSUIRBAZKN2O
>>> 
>>> <2015-06-28_13:50:17.png>
>>> ​The layouting is very, very ugly and could be probably be simplified with 
>>> RTNest and RTCellLayout on the whole table, but I wanted to spend ​as 
>>> little time as possible (the whole code in ~30 minutes).
>>> You can read more about RTNest here 
>>> https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/0104-Roassal.html
>>>  (section 5) (and all chapters are here http://agilevisualization.com/#book 
>>> )
>>> 
>>> Also in your original picture there are boxes with rounded corners; Roassal 
>>> doesn't support this yet (afaik), but I can send you implementation for it 
>>> as I have it in my project.
>>> 
>>> Peter
>>> 
>>> On Sun, Jun 28, 2015 at 1:30 PM, Alexandre Bergel  
>>> wrote:
>>> Hi !
>>> 
>>> Yes, this is trivial I would say.
>>> This evening I will give a try
>>> 
>>> Alexandre
>>> 
>>> 
 Le 28 juin 2015 à 04:49, Volkert  a écrit 
 :
 
 Dear all,
 
 is such a visualization out of the box possible with Roassal2?
 
 BW,
 Volkert
 
 
>>> 
> 
> 

Re: [Pharo-dev] [Pharo-users] Modern Events Touch and Gestures in Pharo.

[J.F. Rick]

Awesome! There's a reasonable chance that I can contribute to this (or at
least utilize it), depending on what contracts I get. If I do get that in
the near future, who do I contact about contributing?

Cheers,

Jeff

On Tue, Jun 30, 2015 at 1:18 PM stepharo  wrote:

> Thanks Thales for the sponsoring.
>
> https://youtu.be/eNrbH8A5nyY
>
> Stef and the rmod team
>
>

Re: [Pharo-dev] Roassal2 / Application Matrix

[Alexandre Bergel]

Ok
Having a look at it now...

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



> On Jun 30, 2015, at 2:50 PM, volkert  wrote:
> 
> That is my plan ;-) Can you have look to the svg export? The inner boxes have 
> no coloring.
> 
> BW,
> Volkert
> 
> Am 30.06.2015 um 00:53 schrieb Alexandre Bergel:
>> Volker, I started to do something called RTApplicationMatrix.
>> But the Peter’s script seems to do a much better job. It would be great if 
>> you can structure it a bit.
>> 
>> Alexandre
>> 
>> 
>>> On Jun 28, 2015, at 8:56 AM, Peter Uhnák  wrote:
>>> 
>>> Well if you want super-crude procedural prototype, I've made this 
>>> http://ws.stfx.eu/MSUIRBAZKN2O
>>> 
>>> <2015-06-28_13:50:17.png>
>>> ​The layouting is very, very ugly and could be probably be simplified with 
>>> RTNest and RTCellLayout on the whole table, but I wanted to spend ​as 
>>> little time as possible (the whole code in ~30 minutes).
>>> You can read more about RTNest here 
>>> https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/0104-Roassal.html
>>>  (section 5) (and all chapters are here http://agilevisualization.com/#book 
>>> )
>>> 
>>> Also in your original picture there are boxes with rounded corners; Roassal 
>>> doesn't support this yet (afaik), but I can send you implementation for it 
>>> as I have it in my project.
>>> 
>>> Peter
>>> 
>>> On Sun, Jun 28, 2015 at 1:30 PM, Alexandre Bergel  
>>> wrote:
>>> Hi !
>>> 
>>> Yes, this is trivial I would say.
>>> This evening I will give a try
>>> 
>>> Alexandre
>>> 
>>> 
 Le 28 juin 2015 à 04:49, Volkert  a écrit 
 :
 
 Dear all,
 
 is such a visualization out of the box possible with Roassal2?
 
 BW,
 Volkert
 
 
>>> 
> 
> 

Re: [Pharo-dev] Stack

[Thierry Goubier]

Le 30/06/2015 19:27, stepharo a écrit :

alain fixed in place edit for string morph so we could even rename a
protocol simply by double clicking on it.


I noticed years ago that I could get that for free in a MorphTreeMorph 
by using a text instead of a string in the node description: would give 
you many, many types of renames, not only protocols.



But this is another story


Yes and no. There are complaints about the model, and when you see the 
state of the tools... you can't be impressed by the fact it wasn't 
improved a long time ago.


But maybe like that it makes some tools look better.

Thierry

Re: [Pharo-dev] Roassal2 / Application Matrix

[volkert]

That is my plan ;-) Can you have look to the svg export? The inner boxes 
have no coloring.


BW,
Volkert

Am 30.06.2015 um 00:53 schrieb Alexandre Bergel:

Volker, I started to do something called RTApplicationMatrix.
But the Peter’s script seems to do a much better job. It would be great if you 
can structure it a bit.

Alexandre



On Jun 28, 2015, at 8:56 AM, Peter Uhnák  wrote:

Well if you want super-crude procedural prototype, I've made this 
http://ws.stfx.eu/MSUIRBAZKN2O

<2015-06-28_13:50:17.png>
​The layouting is very, very ugly and could be probably be simplified with 
RTNest and RTCellLayout on the whole table, but I wanted to spend ​as little 
time as possible (the whole code in ~30 minutes).
You can read more about RTNest here 
https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/0104-Roassal.html
 (section 5) (and all chapters are here http://agilevisualization.com/#book )

Also in your original picture there are boxes with rounded corners; Roassal 
doesn't support this yet (afaik), but I can send you implementation for it as I 
have it in my project.

Peter

On Sun, Jun 28, 2015 at 1:30 PM, Alexandre Bergel  
wrote:
Hi !

Yes, this is trivial I would say.
This evening I will give a try

Alexandre



Le 28 juin 2015 à 04:49, Volkert  a écrit :

Dear all,

is such a visualization out of the box possible with Roassal2?

BW,
Volkert

Re: [Pharo-dev] Stack

[Thierry Goubier]

Le 30/06/2015 19:26, stepharo a écrit :

+1

Thierry we are talking API substituability here.


Yes I know.

Thierry


Le 30/6/15 11:30, Tudor Girba a écrit :

What he means is that just because subclassing is available as a
technical mechanism, we should only use it for modeling subtyping and
not implementation reuse (only in very few cases this is actually
useful in the long run).

For reference, this goes under the name of Liskov substitution
principle and one nice article that explains it is this one:
http://www.objectmentor.com/resources/articles/lsp.pdf

Cheers,
Doru


On Tue, Jun 30, 2015 at 11:21 AM, Thierry Goubier
mailto:thierry.goub...@gmail.com>> wrote:



2015-06-30 11:00 GMT+02:00 stepharo mailto:steph...@free.fr>>:



What I mean is that this is not good to have subclassing when
we can use subclassing.


Are you sure you mean that? *confused*

Thierry




--
www.tudorgirba.com 

"Every thing has its own flow"

Re: [Pharo-dev] pharo 50140 failing release test

[stepharo]

Thanks Nicolai.
Alain is head first in exam corrections :)
I'm heading to paris for our award reception.

Stef


Le 29/6/15 22:55, Nicolai Hess a écrit :

@alain @steph
can you check update pharo 50140
somehow all TAbleToRotate methods (protocol t-rotating) were copied
to class StringMorph.
And now ReleaseTest 
testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits

fails


nicolai

Re: [Pharo-dev] Stack

[stepharo]

Le 30/6/15 15:30, Ben Coman a écrit :

On Tue, Jun 30, 2015 at 5:21 PM, Thierry Goubier
 wrote:


2015-06-30 11:00 GMT+02:00 stepharo :



What I mean is that this is not good to have subclassing when we can use
subclassing.


Are you sure you mean that? *confused*

Thierry

Was it meant to be...
"not good to have subclassing when we can use composition" ?


and produce coherent API.
A stack is not a LinkedList. He can be implemented using a linkedlist.
The API of a stack is not the one of a linkedlist.





cheers -ben

Re: [Pharo-dev] Stack

[stepharo]

I consider that subclassing should be used for implementation reuse and
not for subtyping.

That is the GoF position and it makes a lot of sense to me. In fact, I
think we Smalltalkers suffer from McLuhan's "people become their tools"
syndrome in that, because the browser makes it easy to view inheritance
trees, we confuse inheritance with subtyping, creating unnecessary
coupling. This also adds to the "Smalltalk has no APIs" problem; when only
subclasses are considered subtypes, one never has to define what is and is
not the public API; protocols could help here, but have never really been
fleshed out for this purpose and are a mess right now due to overloading
with extension method duties.


+ 10

Definitely +1 to that. One of the things I really like about ENVY (as in VA
Smalltalk) is the fact that applications/packages have formally modelled
prerequisites and the in-image representation of a class also models the
contribution of each extending application. (As opposed to "by convention")

 I worked with Envy too and to me this is close to the package we have.
And soon we will have package level dependencies.



I'm not claiming ENVY is the be all to end all. It has room for improvement.
But it does formally model this particular aspect quite well.





--
View this message in context: http://forum.world.st/Stack-tp4834494p4834964.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Stack

[stepharo]

alain fixed in place edit for string morph so we could even rename a 
protocol simply by double clicking on it.

But this is another story

Le 30/6/15 15:24, Thierry Goubier a écrit :



2015-06-30 14:05 GMT+02:00 Sean P. DeNigris >:


Thierry Goubier wrote
> I consider that subclassing should be used for implementation reuse and
> not for subtyping.

That is the GoF position and it makes a lot of sense to me. In
fact, I think
we Smalltalkers suffer from McLuhan's "people become their tools"
syndrome
in that, because the browser makes it easy to view inheritance
trees, we
confuse inheritance with subtyping, creating unnecessary coupling.
This also
adds to the "Smalltalk has no APIs" problem; when only subclasses are
considered subtypes, one never has to define what is and is not
the public
API; protocols could help here, but have never really been fleshed
out for
this purpose and are a mess right now due to overloading with
extension
method duties.


I'll wonder what could be done with Traits about that. Traits may be 
better at establishing an API.


Tools could do more to hide the extension thing; I still can't 
understand why, more than two years after I did it, all Pharo users 
are still writing their * a-long-package-name by hand. I would hate 
having to explain to Pharo beginners how to make a method an extension.


(by the way, dropping a method on a package is a nice way to get a DNU 
in Nautilus on Pharo 4...)


Thierry

Re: [Pharo-dev] Stack

[stepharo]

+1

Thierry we are talking API substituability here.

Le 30/6/15 11:30, Tudor Girba a écrit :
What he means is that just because subclassing is available as a 
technical mechanism, we should only use it for modeling subtyping and 
not implementation reuse (only in very few cases this is actually 
useful in the long run).


For reference, this goes under the name of Liskov substitution 
principle and one nice article that explains it is this one:

http://www.objectmentor.com/resources/articles/lsp.pdf

Cheers,
Doru


On Tue, Jun 30, 2015 at 11:21 AM, Thierry Goubier 
mailto:thierry.goub...@gmail.com>> wrote:




2015-06-30 11:00 GMT+02:00 stepharo mailto:steph...@free.fr>>:



What I mean is that this is not good to have subclassing when
we can use subclassing.


Are you sure you mean that? *confused*

Thierry




--
www.tudorgirba.com 

"Every thing has its own flow"

Re: [Pharo-dev] Stack

[stepharo]

Le 30/6/15 11:20, Marcus Denker a écrit :


On 30 Jun 2015, at 11:16, Guillermo Polito > wrote:


Another /detail/ is that LinkedList's design is heavily tied to the 
VM. Our linked list implementation can contain any object that *looks 
like a link*, meaning
- in the higher level they have to understand the message nextLink 
and nextLink:
- in the lower level, if it is a linked list used by the VM, the 
nextLink should be the first inst var of the object.


What I mean with this is that we should be careful when changing 
linked list. Changing its internal representation may crash your 
image ^^.




We should really rename it to “ProcessList” and put a comment “do not 
touch!!!”, then make a copy and have a Linked List that we can change…
there are many issue tracker entries related to the linked list, as 
people try to use it but nobody dares to change it.


I reimplemented it once.
Now I was just consider Stack implementation.


Marcus

Re: [Pharo-dev] Stack

[Richard Sargent]

Sean P. DeNigris wrote
> 
> Thierry Goubier wrote
>> I consider that subclassing should be used for implementation reuse and
>> not for subtyping.
> That is the GoF position and it makes a lot of sense to me. In fact, I
> think we Smalltalkers suffer from McLuhan's "people become their tools"
> syndrome in that, because the browser makes it easy to view inheritance
> trees, we confuse inheritance with subtyping, creating unnecessary
> coupling. This also adds to the "Smalltalk has no APIs" problem; when only
> subclasses are considered subtypes, one never has to define what is and is
> not the public API; protocols could help here, but have never really been
> fleshed out for this purpose and are a mess right now due to overloading
> with extension method duties.

Definitely +1 to that. One of the things I really like about ENVY (as in VA
Smalltalk) is the fact that applications/packages have formally modelled
prerequisites and the in-image representation of a class also models the
contribution of each extending application. (As opposed to "by convention")

I'm not claiming ENVY is the be all to end all. It has room for improvement.
But it does formally model this particular aspect quite well.





--
View this message in context: http://forum.world.st/Stack-tp4834494p4834964.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] does anybody use the AST navigation?

[stepharo]

Hi guys

does any of you use the AST code navigation?
Because we could remove it.

Stef

[Pharo-dev] Modern Events Touch and Gestures in Pharo.

[stepharo]

Thanks Thales for the sponsoring.

https://youtu.be/eNrbH8A5nyY

Stef and the rmod team

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 88b32d: 40617

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 88b32d40acc3e2e99708146bccaa90f172c69f9d
  
https://github.com/pharo-project/pharo-core/commit/88b32d40acc3e2e99708146bccaa90f172c69f9d
  Author: Jenkins Build Server 
  Date:   2015-06-30 (Tue, 30 Jun 2015)

  Changed paths:
A AST-Core.package/RBConfigurableFormatter.class/class/-- all 
--/formatOnAccept.st
A AST-Core.package/RBConfigurableFormatter.class/class/-- all 
--/formatOnAccept_.st
A AST-Core.package/RBConfigurableFormatter.class/class/-- all 
--/formatOnDisplay.st
A AST-Core.package/RBConfigurableFormatter.class/class/-- all 
--/formatOnDisplay_.st
M AST-Core.package/RBConfigurableFormatter.class/class/-- all 
--/initialize.st
M AST-Core.package/RBConfigurableFormatter.class/class/-- all 
--/settingsOn_.st
A 
AST-Core.package/RBConfigurableFormatter.class/class/accessing/formatOnAccept.st
A 
AST-Core.package/RBConfigurableFormatter.class/class/accessing/formatOnAccept_.st
A 
AST-Core.package/RBConfigurableFormatter.class/class/accessing/formatOnDisplay.st
A 
AST-Core.package/RBConfigurableFormatter.class/class/accessing/formatOnDisplay_.st
M 
AST-Core.package/RBConfigurableFormatter.class/class/initialization/initialize.st
M 
AST-Core.package/RBConfigurableFormatter.class/class/settings/settingsOn_.st
M AST-Core.package/RBConfigurableFormatter.class/definition.st
M Nautilus.package/MethodDefinitionAcceptor.class/instance/-- all 
--/accept_notifying_.st
M 
Nautilus.package/MethodDefinitionAcceptor.class/instance/protocol/accept_notifying_.st
A Rubric.package/RubSHTextStylerST80.class/instance/-- all --/format_.st
A Rubric.package/RubSHTextStylerST80.class/instance/private/format_.st
M ScriptLoader40.package/ScriptLoader.class/instance/-- all 
--/commentForCurrentUpdate.st
R ScriptLoader40.package/ScriptLoader.class/instance/-- all --/script616.st
A ScriptLoader40.package/ScriptLoader.class/instance/-- all --/script617.st
R ScriptLoader40.package/ScriptLoader.class/instance/-- all 
--/update40616.st
A ScriptLoader40.package/ScriptLoader.class/instance/-- all 
--/update40617.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script616.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script617.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40616.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40617.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M Shout.package/SHTextStyler.class/instance/-- all --/format_.st
M Shout.package/SHTextStyler.class/instance/formatting/format_.st

  Log Message:
  ---
  40617
14387 ressurrect format on accept and format on display
https://pharo.fogbugz.com/f/cases/14387

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

[Pharo-dev] spec TreeNodeModel displayString

[Christophe Demarey]

Hi,

I have a TreeModel with different kinds of TreeNodeModel and I would like to 
get a customizable display string depending on the node type.
It looks like it is not possible to dispatch on nodes in a display block 
because it only takes the item (node content) and the tree as parameter.
It is strange as I expect that to be a standard feature. Do I miss something?

Thanks,
Christophe

smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] Stack

[Thierry Goubier]

2015-06-30 15:30 GMT+02:00 Ben Coman :

> On Tue, Jun 30, 2015 at 5:21 PM, Thierry Goubier
>  wrote:
> >
> >
> > 2015-06-30 11:00 GMT+02:00 stepharo :
> >>>
> >>>
> >>
> >> What I mean is that this is not good to have subclassing when we can use
> >> subclassing.
> >
> >
> > Are you sure you mean that? *confused*
> >
> > Thierry
>
> Was it meant to be...
> "not good to have subclassing when we can use composition" ?
>

That sounds like it :)

Thierry


>
> cheers -ben
>
>

Re: [Pharo-dev] Stack

[Ben Coman]

On Tue, Jun 30, 2015 at 5:21 PM, Thierry Goubier
 wrote:
>
>
> 2015-06-30 11:00 GMT+02:00 stepharo :
>>>
>>>
>>
>> What I mean is that this is not good to have subclassing when we can use
>> subclassing.
>
>
> Are you sure you mean that? *confused*
>
> Thierry

Was it meant to be...
"not good to have subclassing when we can use composition" ?

cheers -ben

Re: [Pharo-dev] [pharo-project/pharo-core] da585a: 50145

[Marcus Denker]

This update lists mistakenly
15396 Refactor Duplicated #itemFromPoint: (3 slightly-differing 
implementations)

as being part of this update, it is not because it has been already integrated 
earlier, but
the report was not closed, leading it to be integrated again.

Marcus

> On 30 Jun 2015, at 15:24, GitHub  wrote:
> 
>  Branch: refs/heads/5.0
>  Home:   https://github.com/pharo-project/pharo-core
>  Commit: da585ad0fa675fff5ef4044db436387d86faf2c1
>  
> https://github.com/pharo-project/pharo-core/commit/da585ad0fa675fff5ef4044db436387d86faf2c1
>  Author: Jenkins Build Server 
>  Date:   2015-06-30 (Tue, 30 Jun 2015)
> 
>  Changed paths:
>A Kernel.package/ProcessList.class/README.md
>A Kernel.package/ProcessList.class/class/accessing/streamSpecies.st
>A Kernel.package/ProcessList.class/class/instance creation/newFrom_.st
>A Kernel.package/ProcessList.class/class/instance creation/new_.st
>A Kernel.package/ProcessList.class/class/stream 
> creation/new_streamContents_.st
>A Kernel.package/ProcessList.class/definition.st
>A Kernel.package/ProcessList.class/instance/accessing/at_.st
>A Kernel.package/ProcessList.class/instance/accessing/at_putLink_.st
>A Kernel.package/ProcessList.class/instance/accessing/at_put_.st
>A Kernel.package/ProcessList.class/instance/accessing/first.st
>A Kernel.package/ProcessList.class/instance/accessing/firstLink.st
>A Kernel.package/ProcessList.class/instance/accessing/last.st
>A Kernel.package/ProcessList.class/instance/accessing/lastLink.st
>A Kernel.package/ProcessList.class/instance/accessing/size.st
>A Kernel.package/ProcessList.class/instance/accessing/swap_with_.st
>A Kernel.package/ProcessList.class/instance/adding/addFirst_.st
>A Kernel.package/ProcessList.class/instance/adding/addLast_.st
>A Kernel.package/ProcessList.class/instance/adding/add_.st
>A Kernel.package/ProcessList.class/instance/adding/add_afterLink_.st
>A Kernel.package/ProcessList.class/instance/adding/add_after_.st
>A Kernel.package/ProcessList.class/instance/adding/add_beforeLink_.st
>A Kernel.package/ProcessList.class/instance/adding/add_before_.st
>A Kernel.package/ProcessList.class/instance/copying/copyWith_.st
>A Kernel.package/ProcessList.class/instance/copying/copyWithout_.st
>A Kernel.package/ProcessList.class/instance/copying/postCopy.st
>A Kernel.package/ProcessList.class/instance/enumerating/collect_.st
>A 
> Kernel.package/ProcessList.class/instance/enumerating/collect_thenSelect_.st
>A Kernel.package/ProcessList.class/instance/enumerating/do_.st
>A Kernel.package/ProcessList.class/instance/enumerating/linksDo_.st
>A Kernel.package/ProcessList.class/instance/enumerating/select_.st
>A 
> Kernel.package/ProcessList.class/instance/enumerating/select_thenCollect_.st
>A Kernel.package/ProcessList.class/instance/enumerating/species.st
>A 
> Kernel.package/ProcessList.class/instance/private/indexOf_startingAt_ifAbsent_.st
>A Kernel.package/ProcessList.class/instance/private/linkAt_.st
>A Kernel.package/ProcessList.class/instance/private/linkAt_ifAbsent_.st
>A Kernel.package/ProcessList.class/instance/private/linkOf_.st
>A Kernel.package/ProcessList.class/instance/private/linkOf_ifAbsent_.st
>A Kernel.package/ProcessList.class/instance/private/validIndex_.st
>A Kernel.package/ProcessList.class/instance/removing/removeAll.st
>A Kernel.package/ProcessList.class/instance/removing/removeAllSuchThat_.st
>A Kernel.package/ProcessList.class/instance/removing/removeFirst.st
>A Kernel.package/ProcessList.class/instance/removing/removeLast.st
>A Kernel.package/ProcessList.class/instance/removing/removeLink_.st
>A 
> Kernel.package/ProcessList.class/instance/removing/removeLink_ifAbsent_.st
>A Kernel.package/ProcessList.class/instance/removing/remove_ifAbsent_.st
>A Kernel.package/ProcessList.class/instance/testing/isEmpty.st
>M 
> Kernel.package/ProcessorScheduler.class/instance/accessing/highestPriority_.st
>R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
> scripts/script50144.st
>A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
> scripts/script50145.st
>R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
> updates/update50144.st
>A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
> updates/update50145.st
>M 
> ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
> 
>  Log Message:
>  ---
>  50145
> 15396 Refactor Duplicated #itemFromPoint: (3 slightly-differing 
> implementations)
>   https://pharo.fogbugz.com/f/cases/15396
> 
> 15868 Differentiate ProcessList and LinkedList
>   https://pharo.fogbugz.com/f/cases/15868
> 
> http://files.pharo.org/image/50/50145.zip
> 
> 

Re: [Pharo-dev] Stack

[Thierry Goubier]

2015-06-30 14:05 GMT+02:00 Sean P. DeNigris :

> Thierry Goubier wrote
> > I consider that subclassing should be used for implementation reuse and
> > not for subtyping.
>
> That is the GoF position and it makes a lot of sense to me. In fact, I
> think
> we Smalltalkers suffer from McLuhan's "people become their tools" syndrome
> in that, because the browser makes it easy to view inheritance trees, we
> confuse inheritance with subtyping, creating unnecessary coupling. This
> also
> adds to the "Smalltalk has no APIs" problem; when only subclasses are
> considered subtypes, one never has to define what is and is not the public
> API; protocols could help here, but have never really been fleshed out for
> this purpose and are a mess right now due to overloading with extension
> method duties.
>

I'll wonder what could be done with Traits about that. Traits may be better
at establishing an API.

Tools could do more to hide the extension thing; I still can't understand
why, more than two years after I did it, all Pharo users are still writing
their * a-long-package-name by hand. I would hate having to explain to
Pharo beginners how to make a method an extension.

(by the way, dropping a method on a package is a nice way to get a DNU in
Nautilus on Pharo 4...)

Thierry

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] da585a: 50145

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: da585ad0fa675fff5ef4044db436387d86faf2c1
  
https://github.com/pharo-project/pharo-core/commit/da585ad0fa675fff5ef4044db436387d86faf2c1
  Author: Jenkins Build Server 
  Date:   2015-06-30 (Tue, 30 Jun 2015)

  Changed paths:
A Kernel.package/ProcessList.class/README.md
A Kernel.package/ProcessList.class/class/accessing/streamSpecies.st
A Kernel.package/ProcessList.class/class/instance creation/newFrom_.st
A Kernel.package/ProcessList.class/class/instance creation/new_.st
A Kernel.package/ProcessList.class/class/stream 
creation/new_streamContents_.st
A Kernel.package/ProcessList.class/definition.st
A Kernel.package/ProcessList.class/instance/accessing/at_.st
A Kernel.package/ProcessList.class/instance/accessing/at_putLink_.st
A Kernel.package/ProcessList.class/instance/accessing/at_put_.st
A Kernel.package/ProcessList.class/instance/accessing/first.st
A Kernel.package/ProcessList.class/instance/accessing/firstLink.st
A Kernel.package/ProcessList.class/instance/accessing/last.st
A Kernel.package/ProcessList.class/instance/accessing/lastLink.st
A Kernel.package/ProcessList.class/instance/accessing/size.st
A Kernel.package/ProcessList.class/instance/accessing/swap_with_.st
A Kernel.package/ProcessList.class/instance/adding/addFirst_.st
A Kernel.package/ProcessList.class/instance/adding/addLast_.st
A Kernel.package/ProcessList.class/instance/adding/add_.st
A Kernel.package/ProcessList.class/instance/adding/add_afterLink_.st
A Kernel.package/ProcessList.class/instance/adding/add_after_.st
A Kernel.package/ProcessList.class/instance/adding/add_beforeLink_.st
A Kernel.package/ProcessList.class/instance/adding/add_before_.st
A Kernel.package/ProcessList.class/instance/copying/copyWith_.st
A Kernel.package/ProcessList.class/instance/copying/copyWithout_.st
A Kernel.package/ProcessList.class/instance/copying/postCopy.st
A Kernel.package/ProcessList.class/instance/enumerating/collect_.st
A 
Kernel.package/ProcessList.class/instance/enumerating/collect_thenSelect_.st
A Kernel.package/ProcessList.class/instance/enumerating/do_.st
A Kernel.package/ProcessList.class/instance/enumerating/linksDo_.st
A Kernel.package/ProcessList.class/instance/enumerating/select_.st
A 
Kernel.package/ProcessList.class/instance/enumerating/select_thenCollect_.st
A Kernel.package/ProcessList.class/instance/enumerating/species.st
A 
Kernel.package/ProcessList.class/instance/private/indexOf_startingAt_ifAbsent_.st
A Kernel.package/ProcessList.class/instance/private/linkAt_.st
A Kernel.package/ProcessList.class/instance/private/linkAt_ifAbsent_.st
A Kernel.package/ProcessList.class/instance/private/linkOf_.st
A Kernel.package/ProcessList.class/instance/private/linkOf_ifAbsent_.st
A Kernel.package/ProcessList.class/instance/private/validIndex_.st
A Kernel.package/ProcessList.class/instance/removing/removeAll.st
A Kernel.package/ProcessList.class/instance/removing/removeAllSuchThat_.st
A Kernel.package/ProcessList.class/instance/removing/removeFirst.st
A Kernel.package/ProcessList.class/instance/removing/removeLast.st
A Kernel.package/ProcessList.class/instance/removing/removeLink_.st
A Kernel.package/ProcessList.class/instance/removing/removeLink_ifAbsent_.st
A Kernel.package/ProcessList.class/instance/removing/remove_ifAbsent_.st
A Kernel.package/ProcessList.class/instance/testing/isEmpty.st
M 
Kernel.package/ProcessorScheduler.class/instance/accessing/highestPriority_.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50144.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50145.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50144.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50145.st
M 
ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  50145
15396 Refactor Duplicated #itemFromPoint: (3 slightly-differing implementations)
https://pharo.fogbugz.com/f/cases/15396

15868 Differentiate ProcessList and LinkedList
https://pharo.fogbugz.com/f/cases/15868

http://files.pharo.org/image/50/50145.zip

Re: [Pharo-dev] [pharo-project/pharo-core] 05f052: 50144

[Marcus Denker]

This update lists issue 15867 as integrated as part of this update, but
this was already
integrated in some other earlier update but the issue was not closed back
them, leading to me
integrating again, which leads to an update that lists this issue yet does
not contain any changes
related to the issue.

On Tue, Jun 30, 2015 at 2:58 PM, GitHub  wrote:

>   Branch: refs/heads/5.0
>   Home:   https://github.com/pharo-project/pharo-core
>   Commit: 05f05284ec286ed63c0e0ff2d8fdc19dfe9f1481
>
> https://github.com/pharo-project/pharo-core/commit/05f05284ec286ed63c0e0ff2d8fdc19dfe9f1481
>   Author: Jenkins Build Server 
>   Date:   2015-06-30 (Tue, 30 Jun 2015)
>
>   Changed paths:
> M AST-Core.package/RBMessageNode.class/instance/testing/lastIsReturn.st
> M
> OpalCompiler-Core.package/extension/RBMessageNode/instance/isInlineIf.st
> M
> OpalCompiler-Core.package/extension/RBMessageNode/instance/isInlineIfNil.st
> M
> OpalCompiler-Tests.package/OCOpalExamples.class/instance/examples-blocks-optimized/exampleIfTrue.st
> R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/
> script50143.st
> A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/
> script50144.st
> R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/
> update50143.st
> A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/
> update50144.st
> M
> ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
>
>   Log Message:
>   ---
>   50144
> 15450 VM crash with disabled optionInlineIfNil
> https://pharo.fogbugz.com/f/cases/15450
>
> 15867 Fix shortcut for smart suggestions in Nautilus
> https://pharo.fogbugz.com/f/cases/15867
>
> http://files.pharo.org/image/50/50144.zip
>
>
>


-- 
--
Marcus Denker  --  den...@acm.org
http://www.marcusdenker.de

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 05f052: 50144

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 05f05284ec286ed63c0e0ff2d8fdc19dfe9f1481
  
https://github.com/pharo-project/pharo-core/commit/05f05284ec286ed63c0e0ff2d8fdc19dfe9f1481
  Author: Jenkins Build Server 
  Date:   2015-06-30 (Tue, 30 Jun 2015)

  Changed paths:
M AST-Core.package/RBMessageNode.class/instance/testing/lastIsReturn.st
M OpalCompiler-Core.package/extension/RBMessageNode/instance/isInlineIf.st
M 
OpalCompiler-Core.package/extension/RBMessageNode/instance/isInlineIfNil.st
M 
OpalCompiler-Tests.package/OCOpalExamples.class/instance/examples-blocks-optimized/exampleIfTrue.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50143.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50144.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50143.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50144.st
M 
ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  50144
15450 VM crash with disabled optionInlineIfNil
https://pharo.fogbugz.com/f/cases/15450

15867 Fix shortcut for smart suggestions in Nautilus
https://pharo.fogbugz.com/f/cases/15867

http://files.pharo.org/image/50/50144.zip

Re: [Pharo-dev] Stack

[Sean P. DeNigris]

Thierry Goubier wrote
> I consider that subclassing should be used for implementation reuse and
> not for subtyping.

That is the GoF position and it makes a lot of sense to me. In fact, I think
we Smalltalkers suffer from McLuhan's "people become their tools" syndrome
in that, because the browser makes it easy to view inheritance trees, we
confuse inheritance with subtyping, creating unnecessary coupling. This also
adds to the "Smalltalk has no APIs" problem; when only subclasses are
considered subtypes, one never has to define what is and is not the public
API; protocols could help here, but have never really been fleshed out for
this purpose and are a mess right now due to overloading with extension
method duties.



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

Re: [Pharo-dev] Stack

[stepharo]

:)

my question was to check if we can change it :)

Le 30/6/15 11:10, Max Leske a écrit :

On 30 Jun 2015, at 11:00, stepharo  wrote:



Le 28/6/15 19:00, Sven Van Caekenberghe a écrit :

On 28 Jun 2015, at 17:59, Max Leske  wrote:



On 28 Jun 2015, at 17:22, stepharo  wrote:

Hi guys

is there a real reason for Stack being a subclass of LinkedLink?

1. You don’t need to adjust an internal data structure (grow, shrink, move, 
sort) to update the stack but only move references.

But it is used in practice?
Because Stack could use a LinkedList and you get the same benefits and not 
stupid methods that do not make sense for Stack.

agreed.


2. The interface is pretty similar

No there are not :)
Stack is push pop top not insert after:.
or this is a strange stack.

What I meant was: Linked list provides an interface that allows for stack 
operations. Not that the naming conventions are the same.


3. It is an implementation detail/technique, it is indeed not as if Stack is-a 
LinkedList (from that point of view it is confusing)

What I mean is that this is not good to have subclassing when we can use 
subclassing.
We remove the fact that Dictionary is a subclass of Set for this reason.


You asked for reasons. I didn’t say they were *good* reasons :)


Stef

[Pharo-dev] [pharo-project/pharo-core] 6f0eb1: 50143

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 6f0eb1c292ae34764b5e0ba4809355818878f247
  
https://github.com/pharo-project/pharo-core/commit/6f0eb1c292ae34764b5e0ba4809355818878f247
  Author: Jenkins Build Server 
  Date:   2015-06-30 (Tue, 30 Jun 2015)

  Changed paths:
M 
ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version315_.st
A 
ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version316_.st
R 
Morphic-Widgets-List.package/SimpleHierarchicalListMorph.class/instance/event 
handling/itemFromPoint_.st
R 
Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/accessing/itemFromPoint_.st
A 
Morphic-Widgets-Pluggable.package/PluggableMultiColumnListMorph.class/instance/accessing/findSubmorphFor_.st
R 
Morphic-Widgets-Pluggable.package/PluggableMultiColumnListMorph.class/instance/accessing/itemFromPoint_.st
A Morphic-Widgets-Scrolling.package/ScrollPane.class/instance/event 
handling/findSubmorphFor_.st
A Morphic-Widgets-Scrolling.package/ScrollPane.class/instance/event 
handling/itemFromPoint_.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50142.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50143.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50142.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50143.st
M 
ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M 
SmartSuggestions.package/SugsMenuBuilder.class/class/builder/buildSmartActionsShortcuts_.st
M 
SmartSuggestions.package/SugsMenuBuilder.class/class/private/findBestNodeFor_.st

  Log Message:
  ---
  50143
15396 Refactor Duplicated #itemFromPoint: (3 slightly-differing implementations)
https://pharo.fogbugz.com/f/cases/15396

15863 Update Glamour to load last version of Rubric
https://pharo.fogbugz.com/f/cases/15863

15867 Fix shortcut for smart suggestions in Nautilus
https://pharo.fogbugz.com/f/cases/15867

http://files.pharo.org/image/50/50143.zip

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

[GitHub]

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

Re: [Pharo-dev] pharo / Cairo / MacOS 10.6.8

[Nicolas Anquetil]

will have a look at it

thanks

nicolas

On 30/06/2015 11:01, Stephan Eggermont wrote:

On 30-06-15 10:55, Nicolas Anquetil wrote:


While giving a course on Moose/Pharo last week, one of the attendants
had a problem that we could not resolve with unfound cairo library on
pharo 4.0 / MacOS 10.6.8 (simingly an old one)

we had no chances with the instructions posted there:
http://cairographics.org/download/

anyone knows how to solve the problem?


Well known issue indeed. The cairo library was compiled with a wrong
dependency.

Just copy the libcairo.2.dylib (in Contents/MacOS/Plugins when you do
Show Package Contents on the vm app) from the 18 september 2013 vm.

http://forum.world.st/Last-Pharo-VM-on-mac-os-x-10-6-8-td4777304.html

Stephan

Re: [Pharo-dev] Stack

[Guillermo Polito]

I will open an issue ^^

El mar., 30 de jun. de 2015 a la(s) 11:20 a. m., Marcus Denker <
marcus.den...@inria.fr> escribió:

>
> On 30 Jun 2015, at 11:16, Guillermo Polito 
> wrote:
>
> Another *detail* is that LinkedList's design is heavily tied to the VM.
> Our linked list implementation can contain any object that *looks like a
> link*, meaning
> - in the higher level they have to understand the message nextLink and
> nextLink:
> - in the lower level, if it is a linked list used by the VM, the nextLink
> should be the first inst var of the object.
>
> What I mean with this is that we should be careful when changing linked
> list. Changing its internal representation may crash your image ^^.
>
>
> We should really rename it to “ProcessList” and put a comment “do not
> touch!!!”, then make a copy and have a Linked List that we can change…
> there are many issue tracker entries related to the linked list, as people
> try to use it but nobody dares to change it.
>
> Marcus
>
>

Re: [Pharo-dev] Stack

[Thierry Goubier]

2015-06-30 11:30 GMT+02:00 Tudor Girba :

> What he means is that just because subclassing is available as a technical
> mechanism, we should only use it for modeling subtyping and not
> implementation reuse (only in very few cases this is actually useful in the
> long run).
>

Given how Smalltalk defines types and subtyping, I consider that
subclassing should be used for implementation reuse and not for subtyping.
Any Smalltalk class hierarchy which has instance variables defined in the
superclass does implementation sharing/reuse.

Modeling is another consideration.

(I still consider the meaning of Stef phrase confusing...)


> For reference, this goes under the name of Liskov substitution principle
> and one nice article that explains it is this one:
> http://www.objectmentor.com/resources/articles/lsp.pdf
>

This reference is too much into how that particular principle turns out in
an ill-designed type and code sharing mechanism (C++) to be of much help ;)

Thierry


>
>
> Cheers,
> Doru
>
>
> On Tue, Jun 30, 2015 at 11:21 AM, Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
>
>>
>>
>> 2015-06-30 11:00 GMT+02:00 stepharo :
>>
>>>

>>> What I mean is that this is not good to have subclassing when we can use
>>> subclassing.
>>>
>>
>> Are you sure you mean that? *confused*
>>
>> Thierry
>>
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>

Re: [Pharo-dev] Stack

[Tudor Girba]

What he means is that just because subclassing is available as a technical
mechanism, we should only use it for modeling subtyping and not
implementation reuse (only in very few cases this is actually useful in the
long run).

For reference, this goes under the name of Liskov substitution principle
and one nice article that explains it is this one:
http://www.objectmentor.com/resources/articles/lsp.pdf

Cheers,
Doru


On Tue, Jun 30, 2015 at 11:21 AM, Thierry Goubier  wrote:

>
>
> 2015-06-30 11:00 GMT+02:00 stepharo :
>
>>
>>>
>> What I mean is that this is not good to have subclassing when we can use
>> subclassing.
>>
>
> Are you sure you mean that? *confused*
>
> Thierry
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Stack

[Thierry Goubier]

2015-06-30 11:00 GMT+02:00 stepharo :

>
>>
> What I mean is that this is not good to have subclassing when we can use
> subclassing.
>

Are you sure you mean that? *confused*

Thierry

Re: [Pharo-dev] Stack

[Marcus Denker]

> On 30 Jun 2015, at 11:16, Guillermo Polito  wrote:
> 
> Another detail is that LinkedList's design is heavily tied to the VM. Our 
> linked list implementation can contain any object that *looks like a link*, 
> meaning 
> - in the higher level they have to understand the message nextLink and 
> nextLink:
> - in the lower level, if it is a linked list used by the VM, the nextLink 
> should be the first inst var of the object.
> 
> What I mean with this is that we should be careful when changing linked list. 
> Changing its internal representation may crash your image ^^.
> 

We should really rename it to “ProcessList” and put a comment “do not 
touch!!!”, then make a copy and have a Linked List that we can change…
there are many issue tracker entries related to the linked list, as people try 
to use it but nobody dares to change it.

Marcus

Re: [Pharo-dev] Stack

[Guillermo Polito]

Another *detail* is that LinkedList's design is heavily tied to the VM. Our
linked list implementation can contain any object that *looks like a link*,
meaning
- in the higher level they have to understand the message nextLink and
nextLink:
- in the lower level, if it is a linked list used by the VM, the nextLink
should be the first inst var of the object.

What I mean with this is that we should be careful when changing linked
list. Changing its internal representation may crash your image ^^.

El mar., 30 de jun. de 2015 a la(s) 11:10 a. m., Max Leske <
maxle...@gmail.com> escribió:

>
> > On 30 Jun 2015, at 11:00, stepharo  wrote:
> >
> >
> >
> > Le 28/6/15 19:00, Sven Van Caekenberghe a écrit :
> >>> On 28 Jun 2015, at 17:59, Max Leske  wrote:
> >>>
> >>>
>  On 28 Jun 2015, at 17:22, stepharo  wrote:
> 
>  Hi guys
> 
>  is there a real reason for Stack being a subclass of LinkedLink?
> >>> 1. You don’t need to adjust an internal data structure (grow, shrink,
> move, sort) to update the stack but only move references.
> > But it is used in practice?
> > Because Stack could use a LinkedList and you get the same benefits and
> not stupid methods that do not make sense for Stack.
>
> agreed.
>
> >
> >>> 2. The interface is pretty similar
> >
> > No there are not :)
> > Stack is push pop top not insert after:.
> > or this is a strange stack.
>
> What I meant was: Linked list provides an interface that allows for stack
> operations. Not that the naming conventions are the same.
>
> >> 3. It is an implementation detail/technique, it is indeed not as if
> Stack is-a LinkedList (from that point of view it is confusing)
> >
> > What I mean is that this is not good to have subclassing when we can use
> subclassing.
> > We remove the fact that Dictionary is a subclass of Set for this reason.
> >
>
> You asked for reasons. I didn’t say they were *good* reasons :)
>
> >>
>  Stef
> 
> >>>
> >>
> >>
> >
> >
>
>
>

Re: [Pharo-dev] Stack

[Max Leske]

> On 30 Jun 2015, at 11:00, stepharo  wrote:
> 
> 
> 
> Le 28/6/15 19:00, Sven Van Caekenberghe a écrit :
>>> On 28 Jun 2015, at 17:59, Max Leske  wrote:
>>> 
>>> 
 On 28 Jun 2015, at 17:22, stepharo  wrote:
 
 Hi guys
 
 is there a real reason for Stack being a subclass of LinkedLink?
>>> 1. You don’t need to adjust an internal data structure (grow, shrink, move, 
>>> sort) to update the stack but only move references.
> But it is used in practice?
> Because Stack could use a LinkedList and you get the same benefits and not 
> stupid methods that do not make sense for Stack.

agreed.

> 
>>> 2. The interface is pretty similar
> 
> No there are not :)
> Stack is push pop top not insert after:.
> or this is a strange stack.

What I meant was: Linked list provides an interface that allows for stack 
operations. Not that the naming conventions are the same.

>> 3. It is an implementation detail/technique, it is indeed not as if Stack 
>> is-a LinkedList (from that point of view it is confusing)
> 
> What I mean is that this is not good to have subclassing when we can use 
> subclassing.
> We remove the fact that Dictionary is a subclass of Set for this reason.
> 

You asked for reasons. I didn’t say they were *good* reasons :)

>> 
 Stef
 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] pharo / Cairo / MacOS 10.6.8

[Stephan Eggermont]

On 30-06-15 10:55, Nicolas Anquetil wrote:


While giving a course on Moose/Pharo last week, one of the attendants
had a problem that we could not resolve with unfound cairo library on
pharo 4.0 / MacOS 10.6.8 (simingly an old one)

we had no chances with the instructions posted there:
http://cairographics.org/download/

anyone knows how to solve the problem?


Well known issue indeed. The cairo library was compiled with a wrong
dependency.

Just copy the libcairo.2.dylib (in Contents/MacOS/Plugins when you do
Show Package Contents on the vm app) from the 18 september 2013 vm.

http://forum.world.st/Last-Pharo-VM-on-mac-os-x-10-6-8-td4777304.html

Stephan

Re: [Pharo-dev] Stack

[stepharo]

Le 28/6/15 19:00, Sven Van Caekenberghe a écrit :

On 28 Jun 2015, at 17:59, Max Leske  wrote:



On 28 Jun 2015, at 17:22, stepharo  wrote:

Hi guys

is there a real reason for Stack being a subclass of LinkedLink?

1. You don’t need to adjust an internal data structure (grow, shrink, move, 
sort) to update the stack but only move references.

But it is used in practice?
Because Stack could use a LinkedList and you get the same benefits and 
not stupid methods that do not make sense for Stack.



2. The interface is pretty similar


No there are not :)
Stack is push pop top not insert after:.
or this is a strange stack.

3. It is an implementation detail/technique, it is indeed not as if Stack is-a 
LinkedList (from that point of view it is confusing)


What I mean is that this is not good to have subclassing when we can use 
subclassing.

We remove the fact that Dictionary is a subclass of Set for this reason.




Stef

[Pharo-dev] pharo / Cairo / MacOS 10.6.8

[Nicolas Anquetil]

While giving a course on Moose/Pharo last week, one of the attendants 
had a problem that we could not resolve with unfound cairo library on 
pharo 4.0 / MacOS 10.6.8 (simingly an old one)


we had no chances with the instructions posted there: 
http://cairographics.org/download/


anyone knows how to solve the problem?

nicolas

[Pharo-dev] [pharo-project/pharo-core] 35f8e2: 50142

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 35f8e25057a1f96777a57fb2c19e8757833c5a9c
  
https://github.com/pharo-project/pharo-core/commit/35f8e25057a1f96777a57fb2c19e8757833c5a9c
  Author: Jenkins Build Server 
  Date:   2015-06-30 (Tue, 30 Jun 2015)

  Changed paths:
M 
Collections-Abstract.package/SequenceableCollection.class/instance/enumerating/doWithIndex_.st
M 
Collections-Abstract.package/SequenceableCollection.class/instance/enumerating/withIndexDo_.st
M 
ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic 
versions/stable_.st
A 
ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version110_.st
A 
ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version111_.st
A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - 
error handling/testSetLinkIncompatibleReification.st
R Reflectivity.package/HookGenerator.class/instance/ast 
manipulation/reificationsFor_.st
M Reflectivity.package/HookGenerator.class/instance/initialize/node_link_.st
M Reflectivity.package/HookGenerator.class/instance/initialize/setupTable.st
A Reflectivity.package/MetaLink.class/instance/accessing/allReifications.st
A 
Reflectivity.package/MetaLink.class/instance/installing/checkForCompatibilityWith_.st
A Reflectivity.package/MetaLink.class/instance/private/reificationsFor_.st
M Reflectivity.package/extension/RBProgramNode/instance/link_.st
M 
Rubric.package/RubSmalltalkEditor.class/instance/accessing/selectionPosition_.st
M Rubric.package/RubStringMorphContentsEdited.class/README.md
M Rubric.package/RubStringMorphContentsEdited.class/definition.st
A 
Rubric.package/RubStringMorphContentsEdited.class/instance/accessing/previousContents.st
A 
Rubric.package/RubStringMorphContentsEdited.class/instance/accessing/previousContents_.st
M Rubric.package/RubStringMorphEditorProvider.class/README.md
M Rubric.package/RubStringMorphEditorProvider.class/instance/announcement 
handling/closeEditor.st
A Rubric.package/RubStringMorphEditorProvider.class/instance/announcement 
handling/whenEditorDeleted_.st
M Rubric.package/RubStringMorphEditorProvider.class/instance/announcement 
handling/whenTextAccepted_.st
A 
Rubric.package/RubStringMorphEditorProvider.class/instance/events-processing/handleListenEvent_.st
M Rubric.package/RubStringMorphEditorProvider.class/instance/public 
editing/buildEditor.st
M Rubric.package/RubStringMorphEditorProvider.class/instance/public 
editing/openEditorForStringMorph_.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50141.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50142.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50141.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50142.st
M 
ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  50142
15862 Better method comment for withIndexDo: and doWithIndex:
https://pharo.fogbugz.com/f/cases/15862

15864 Reflectivity: error when installing incompatibe link
https://pharo.fogbugz.com/f/cases/15864

15312 Wrong position for completion menu in Rubric/Playground
https://pharo.fogbugz.com/f/cases/15312

http://files.pharo.org/image/50/50142.zip

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

[GitHub]

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

[Pharo-dev] Camp Smalltalk PDX --- August 21st through the 23rd

[Andres Valloud]

Camp Smalltalk Portland 2015 is go for August 21st through the 23rd! 
(and if you arrive earlier on the 20th that's cool too) Please register 
for the event here:


https://www.picatic.com/event14352674835773927

Help us by filling in the questions so you can get your event shirt. And 
also see that we're having a BBQ with live music on Saturday. You can't 
miss it!