Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Ben Coman]

On Wed, Mar 25, 2015 at 6:08 AM, Sean P. DeNigris 
wrote:

> > I have to confess I did not understand this obsession of implementing
> everything in Pharo when I joined coming from python. But now I find this
> obsession too infectious to resist :)
> That's why its impossible to convert people via HN and Reddit. Like
> skydiving (I imagine), it seems like a really bad idea to leave the safety
> of ill-conceived vendor-supplied tools until you jump and actually live it
> for yourself for long enough to realize what freedom feels like!


One of the things that drew me to do the Delay refactoring, is simply that
I could. That is, I was amazed that I could dig so deep so easily, see a
path to improvement and effect change at a fundamental level. Excepting
complexities with the CI due to "changing the wheels on the car at 100km/h"
(and one slip), it seems to have gone reasonably smoothly.  That sense of
mastery is seductive.
cheers -ben

[Pharo-dev] Latest VM doesn't have Wheel changes

[Sean P. DeNigris]

I see them in the source zip right alongside the app on Jenkins, and the
changes worked as expected on my Mac when I built by hand. I even kicked off
another build, but #419 didn't seem to have the changes either...



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Latest-VM-doesn-t-have-Wheel-changes-tp4814972.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Existing

[Tudor Girba]

Hi,

On Wed, Mar 25, 2015 at 12:17 AM, Nicolai Hess  wrote:

>
>
> 2015-03-24 22:48 GMT+01:00 Tudor Girba :
>
>> Hi Torsten,
>>
>> Thanks for the long email. The first part summarizes the situation
>> reasonably well, except that you are putting the same pot 
>> annotated methods and methods having example* selectors. To try to clear
>> the water I thought I would answer with an almost equally long email :).
>>
>> I am not trying to redefine anything. We had the discussion about
>> renaming the original  into  some months ago and since
>> then we only used  to mean what my description is: an initialized
>> object. There are indeed many methods named example* that have a loose
>> meaning that is different than the clearly defined  methods, but
>> that does not mean that  was ever used for anything else than what
>> my definition.
>>
>
> I must admit I misunderstood that discussion, I thought it was about a the
> GLMExamplesBrowser not the inspector. I thought the tag will be used
> to create a list of examples and selecting the method will run the method.
>
>
There was a screenshot of the inspector in it :).


>
>
>>
>> In the Pharo image there are current 96 methods annotated with 
>> or , and in fact, the only one method of these that does not
>> preserve the meaning of  appeared in the recently integrated
>> Athens version 3.1. This method executes a demo that requires a key press
>> to end.
>>
>> So, who would you say is changing the meaning of an existing state of
>> facts? :)
>>
>
> I think he is talkting about the meaning of "example" in the "method
> name". This exists much longer than the "gtExample pragmas".
> We have many exampleXXX methods in the image that actually start something
> (the widget examples for instance). So it is a bit confusing that
> the  pragma only provides some data.
>

Yes, there are many example* methods, often with different interpretations.
That is why, I specifically mentioned the distinction between the #example*
selectors and  pragmas multiple times.

As for Nautilus dealing with fuzzy semantics, my choice would be to only
support , or at least when we have  to inspect the result
rather than just to execute it.



> How about removing the  pragma from the runDemo method in
> VGTigerDemo and rename it to
> example
>
> and move this discussion after the release?
>

Sure. Or we can have 

Re: [Pharo-dev] Existing

[Nicolai Hess]

2015-03-24 22:48 GMT+01:00 Tudor Girba :

> Hi Torsten,
>
> Thanks for the long email. The first part summarizes the situation
> reasonably well, except that you are putting the same pot 
> annotated methods and methods having example* selectors. To try to clear
> the water I thought I would answer with an almost equally long email :).
>
> I am not trying to redefine anything. We had the discussion about renaming
> the original  into  some months ago and since then we
> only used  to mean what my description is: an initialized object.
> There are indeed many methods named example* that have a loose meaning that
> is different than the clearly defined  methods, but that does not
> mean that  was ever used for anything else than what my definition.
>

I must admit I misunderstood that discussion, I thought it was about a the
GLMExamplesBrowser not the inspector. I thought the tag will be used
to create a list of examples and selecting the method will run the method.




>
> In the Pharo image there are current 96 methods annotated with 
> or , and in fact, the only one method of these that does not
> preserve the meaning of  appeared in the recently integrated
> Athens version 3.1. This method executes a demo that requires a key press
> to end.
>
> So, who would you say is changing the meaning of an existing state of
> facts? :)
>

I think he is talkting about the meaning of "example" in the "method name".
This exists much longer than the "gtExample pragmas".
We have many exampleXXX methods in the image that actually start something
(the widget examples for instance). So it is a bit confusing that
the  pragma only provides some data.

How about removing the  pragma from the runDemo method in
VGTigerDemo and rename it to
example

and move this discussion after the release?


 There is great value that comes from the simple and clearly defined
> concept of .
>

I think this discussion shows that the purpose of the  pragma is
not "a simple and clearly defined concept" :)

  Nicolai



> Cheers,
> Doru
>
>
>
> On Tue, Mar 24, 2015 at 8:56 PM, Torsten Bergmann  wrote:
>
>> Hi Tudor and all,
>>
>> to understand the issue one has to know:
>>
>> --
>> There are two pragmas in Pharo 4 that were already introduced and
>> integrated:
>>
>>   

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Sean P. DeNigris]

> I have to confess I did not understand this obsession of implementing 
> everything in Pharo when I joined coming from python. But now I find this 
> obsession too infectious to resist :) 
That's why its impossible to convert people via HN and Reddit. Like skydiving 
(I imagine), it seems like a really bad idea to leave the safety of 
ill-conceived vendor-supplied tools until you jump and actually live it for 
yourself for long enough to realize what freedom feels like!





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

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Sean P. DeNigris]

> Yes, we do not have the replacement now, but we have never had so much 
> investment and will around the UI as we have now. We do not know at this 
> point what is the better way, we do not know the exact roadmap because it is 
> more than just a matter of implementation. But, I know that the kinds of 
> results we had recently around the UI is a highly encouraging predictor.
Well said! Things have been converging for a long time. I remember Alain showed 
me a Bloc ancestor at my very first ESUG. I feel that it's taken so long 
precisely because of our concern to preserve the awesome "build anything" power 
of a live, direct Morphic world while building more more mundane/standard 
layer(s) on top. And the results do seems to be rapidly accelerating lately.

For all of us who want to participate, I think the most important first step is 
research. Much good thinking about this has been done at and since PARC. There 
are great papers, articles, and videos available about: Self Morphic, the Star 
user interface, VPRI's experiments with e.g. text layout, MorphicWrappers and 
MathMorphs, the Alternate Reality Kit to name a few. You can also play with 
Self and Lively Kernel to see how things are done there.

I think that if we were going to replace the live, direct, uniform Morphic 
world with merely "a business UI toolkit" that it would have been done a long 
time ago!



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

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[kilon alios]

Tudor , I am only amazed how much you guys accomplish with so limited
resources. I may not agree with some of the choices but I am very happy
with the progress Pharo is making and glad I stick around.

If the community is not ready for a roadmap , so be it. You will be ready
when you will be ready.I do think however that more the community grows
coordinating effort will become a key issue.

I do agree that things look very encouraging and I trust the community to
move Pharo forward.

Just a side note: what I find cool about Pharo GUI coding is that all tools
are written in Pharo. Its easy to take this for granted but taking a look
at other dynamic programming languages shows that his is a blessing. I have
to confess I did not understand this obsession of implementing everything
in Pharo when I joined coming from python. But now I find this obsession
too infectious to resist :)

On Tue, Mar 24, 2015 at 11:56 PM, Tudor Girba  wrote:

> Hi Kilon,
>
> The situation is like this. For quite a while we did not have enough
> expertise in this community to build serious UI frameworks that can work.
> In the meantime we learnt a lot. GT is not just a couple of windows. It's
> an experiment of building something that does not exist anywhere else, and
> we learnt a lot from doing it. For example, to make Spotter both responsive
> and robust, the most difficult part was to learn to build the machinery
> behind, but now we are passed that initial step. At the same time, Alain
> put a ton of effort in Bloc. Athens was exercised both as the engine behind
> Block and from the Roassal team. And there are others like Sean, Nicolai
> and Ben who work around the same areas.
>
> This are all seemingly parallel and uncoordinated efforts, but they are
> converging. It is exactly because we are committed to the long term goal of
> building a real and better alternative to Morphic that we choose to not
> stop half way with Brick which is probably enough for GT purposes and
> choose instead to invest in evaluating Bloc.
>
> Yes, we do not have the replacement now, but we have never had so much
> investment and will around the UI as we have now. We do not know at this
> point what is the better way, we do not know the exact roadmap because it
> is more than just a matter of implementation. But, I know that the kinds of
> results we had recently around the UI is a highly encouraging predictor.
>
> Cheers,
> Doru
>
>
>
> On Tue, Mar 24, 2015 at 5:19 PM, kilon alios 
> wrote:
>
>>
>> "
>> if you read my mail, you will notice that I said BOTH are on the table
>> (and we are actually moving oon both):
>> - Bloc is the redesign
>> - In the mean time we WORK and ENCOURAGE others to work on improve it."
>>
>> Last time I asked about Bloc , I was told not to use it and instead stick
>> with Spec or Morphic.
>>
>> I said it before and will say it again, you guys need to sit down and
>> make a roadmap for Pharo because I am reading a lot of conflicting posts in
>> this mailing list and this is does not give the professional look Pharo
>> wants to show to people outside Pharo. As a user "replace in the long run"
>> is not enough ! The original author of Bloc , Alain, also said that he is
>> pretty much the only one that works on Bloc (with some help from Stef) and
>> if people dont start helping him out he is going to give up.
>>
>> How many more threads should we have about the GUI future of Pharo before
>> people really get the message that we need a roadmap ?
>>
>> Additionally , Pharo needs a roadmap , seriously it does.
>>
>> "but Morphic it self has several fundamental flaws that cannot be fixed
>> and that’s why in the long, very long way, needs to be replaced.  "
>>
>> What flaws , where , when , how , why ? So much discussion that Morphic
>> must go , close to zero discussion what the actual problems are.
>>
>> "First, Athens is not a replace for Morphic, is a replace for the canvas
>> in which morphs are drawn. So is not Morphic or Athens… is "Morph using
>> DisplayPlugin" or "Morphic using Athens".
>>
>> Second I did not say Athens is to replace Morphic . From my understanding
>> Bloc is based on Athens and Bloc is to replace Morphic. Correct me If I am
>> wrong.
>>
>> "Glamour is very mature and I’ve used it serval times… and in theory
>> Brick will be compatible with Glamour (mostly) so even if developers
>> deprecate one for the other you will be able to use your code (mostly). "
>>
>> Brick is called non usable by its own authors. Glamour is framework of
>> building browsers and simplified GUIs , its nowhere near as powerful as
>> Morphic and is based on Morphic. From the looks of its is not even as
>> powerful as Spec. Through the couple years I have been around I have seen
>> at best a couple of question on how to make it work compared to hundreds of
>> questions about Spec and Morphic . How something can be matured if it is
>> not heavily used ?
>>
>> "But anyway, how can Athens be so slow? Why? Can you share some info? "
>>
>>

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Tudor Girba]

Hi Kilon,

The situation is like this. For quite a while we did not have enough
expertise in this community to build serious UI frameworks that can work.
In the meantime we learnt a lot. GT is not just a couple of windows. It's
an experiment of building something that does not exist anywhere else, and
we learnt a lot from doing it. For example, to make Spotter both responsive
and robust, the most difficult part was to learn to build the machinery
behind, but now we are passed that initial step. At the same time, Alain
put a ton of effort in Bloc. Athens was exercised both as the engine behind
Block and from the Roassal team. And there are others like Sean, Nicolai
and Ben who work around the same areas.

This are all seemingly parallel and uncoordinated efforts, but they are
converging. It is exactly because we are committed to the long term goal of
building a real and better alternative to Morphic that we choose to not
stop half way with Brick which is probably enough for GT purposes and
choose instead to invest in evaluating Bloc.

Yes, we do not have the replacement now, but we have never had so much
investment and will around the UI as we have now. We do not know at this
point what is the better way, we do not know the exact roadmap because it
is more than just a matter of implementation. But, I know that the kinds of
results we had recently around the UI is a highly encouraging predictor.

Cheers,
Doru



On Tue, Mar 24, 2015 at 5:19 PM, kilon alios  wrote:

>
> "
> if you read my mail, you will notice that I said BOTH are on the table
> (and we are actually moving oon both):
> - Bloc is the redesign
> - In the mean time we WORK and ENCOURAGE others to work on improve it."
>
> Last time I asked about Bloc , I was told not to use it and instead stick
> with Spec or Morphic.
>
> I said it before and will say it again, you guys need to sit down and make
> a roadmap for Pharo because I am reading a lot of conflicting posts in this
> mailing list and this is does not give the professional look Pharo wants to
> show to people outside Pharo. As a user "replace in the long run" is not
> enough ! The original author of Bloc , Alain, also said that he is pretty
> much the only one that works on Bloc (with some help from Stef) and if
> people dont start helping him out he is going to give up.
>
> How many more threads should we have about the GUI future of Pharo before
> people really get the message that we need a roadmap ?
>
> Additionally , Pharo needs a roadmap , seriously it does.
>
> "but Morphic it self has several fundamental flaws that cannot be fixed
> and that’s why in the long, very long way, needs to be replaced.  "
>
> What flaws , where , when , how , why ? So much discussion that Morphic
> must go , close to zero discussion what the actual problems are.
>
> "First, Athens is not a replace for Morphic, is a replace for the canvas
> in which morphs are drawn. So is not Morphic or Athens… is "Morph using
> DisplayPlugin" or "Morphic using Athens".
>
> Second I did not say Athens is to replace Morphic . From my understanding
> Bloc is based on Athens and Bloc is to replace Morphic. Correct me If I am
> wrong.
>
> "Glamour is very mature and I’ve used it serval times… and in theory Brick
> will be compatible with Glamour (mostly) so even if developers deprecate
> one for the other you will be able to use your code (mostly). "
>
> Brick is called non usable by its own authors. Glamour is framework of
> building browsers and simplified GUIs , its nowhere near as powerful as
> Morphic and is based on Morphic. From the looks of its is not even as
> powerful as Spec. Through the couple years I have been around I have seen
> at best a couple of question on how to make it work compared to hundreds of
> questions about Spec and Morphic . How something can be matured if it is
> not heavily used ?
>
> "But anyway, how can Athens be so slow? Why? Can you share some info? "
>
> You ask me to tell you why Athens is slow when we have this discussion
> before ( a few months ago) and you told me that Athens is slow because of
> how Pharo handles rendering and that as soon as we move to SDL things will
> be 10 times faster.
>
> All I have to do is VGTiger runDemo and my 3Ghz Quad Cores beg me for
> mercy at 50% consumption. Calling it slow , is an understatement.
>
> Other much simpler example are very slow too like the sliding logo example
> at many more.
>
> Of course this problem affects Morphic too so personally I am examining
> the possibility that no pharo library will satisfy me and instead I will
> make my own GUI API on top of QT or HTML. Obviously more work for me,
> obviously a scenario that I want to avoid, but if the alternative is an app
> that consumes 50% cpu then I dont have much of a choice. Maybe I could take
> a look at Mars too.
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Existing

[Tudor Girba]

Hi Torsten,

Thanks for the long email. The first part summarizes the situation
reasonably well, except that you are putting the same pot 
annotated methods and methods having example* selectors. To try to clear
the water I thought I would answer with an almost equally long email :).

I am not trying to redefine anything. We had the discussion about renaming
the original  into  some months ago and since then we
only used  to mean what my description is: an initialized object.
There are indeed many methods named example* that have a loose meaning that
is different than the clearly defined  methods, but that does not
mean that  was ever used for anything else than what my definition.

In the Pharo image there are current 96 methods annotated with  or
, and in fact, the only one method of these that does not
preserve the meaning of  appeared in the recently integrated
Athens version 3.1. This method executes a demo that requires a key press
to end.

So, who would you say is changing the meaning of an existing state of
facts? :)

Now, let's discuss why having an example concept defined as an "initialized
object" is actually valuable. In order to run examples, you need the well
initialized object. So, you can have:

GLMBrick class>>exampleZindex

^ GLMBrick new ...
and then
GLMBrick class>>exampleZindexOpen
"
self exampleZindexOpen
"
self exampleZindex openInBrickWindowLabeled: 'Z-Index example'

But, the interesting thing is that you can also use the example object for
other purposes. For example, you can embed the object in a browser, or you
can run automatic smoke tests. Specifically, given that GT proposes the
idea of moldable tools that others can easily extend, it is also a
challenge to test these extensions. Having examples for each of the
extended classes makes this endeavor easily possible. And then we can also
start considering the work on seeing tests as a whole as nothing but
examples with assertions that depend on each other, but let's talk about
that at another time. There is great value that comes from the simple and
clearly defined concept of .

Btw, I think we should avoid talking about "for GT's purpose" because it
sounds as if GT would be an alien that should be put in quarantine :)

Cheers,
Doru



On Tue, Mar 24, 2015 at 8:56 PM, Torsten Bergmann  wrote:

> Hi Tudor and all,
>
> to understand the issue one has to know:
>
> --
> There are two pragmas in Pharo 4 that were already introduced and
> integrated:
>
>   

Re: [Pharo-dev] Some Memory Leak

[Andrei Chis]

Hi Henry,

Thanks for the feedback. Don't stop :)

In this case I think the memory lead comes from the class variables of
GLMHintableActionButtonBrick.
Clearing them up removes all instances of playground and spotter from my
image. We need to find a better design for that.


Cheers,
Andrei



On Tue, Mar 24, 2015 at 9:38 PM, Henrik Sperre Johansen <
henrik.s.johan...@veloxit.no> wrote:

> A tiny bit of code review while I'm at it...
>
> GTSpotterResultsBrick >> initialize
> super initialize
> self band hSpaceFill.
> self announcer weak subscribe: GLMBrickScrollPositionChanged send:
> #onScrolled to: self
>
> This is a tempting, but sneaky anti-pattern, you should never, ever, ever
> have to subscribe to your own announcer:
> The reason for calling it an anti-pattern is; if your code actually depends
> on this, it means other sources might invoke changes in you indirectly
> through your announcer, which quickly becomes debugging hell if you allow
> it, and something screws up. (I speak from experience)
>
> It's much easier to understand when done directly, in this case that means
> extending the super method where announcement is made:
>
> GTSpotterResultsBrick >> privateScrollPosition:anInteger
> super privateScrollPosition:anInteger.
> self onScrolled
>
> Cheers,
> Henry
>
> P.S. Announcements are objects, they are intended to hold the data
> subscribers might be interested in.
> Whenever you find yourself writing something like:
> someAnnouncer announce: SomeAnnouncement new
> ask yourself twice if that may lead to subscribers accessing state that
> would more naturally be part of the announcement through other channels
> (such as keeping extra instvars, etc).
>
>
>
> --
> View this message in context:
> http://forum.world.st/Some-Memory-Leak-tp4814779p4814912.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] Some Memory Leak

[Henrik Sperre Johansen]

A tiny bit of code review while I'm at it...

GTSpotterResultsBrick >> initialize
super initialize
self band hSpaceFill.
self announcer weak subscribe: GLMBrickScrollPositionChanged send:
#onScrolled to: self

This is a tempting, but sneaky anti-pattern, you should never, ever, ever
have to subscribe to your own announcer:
The reason for calling it an anti-pattern is; if your code actually depends
on this, it means other sources might invoke changes in you indirectly
through your announcer, which quickly becomes debugging hell if you allow
it, and something screws up. (I speak from experience)

It's much easier to understand when done directly, in this case that means
extending the super method where announcement is made:

GTSpotterResultsBrick >> privateScrollPosition:anInteger
super privateScrollPosition:anInteger.
self onScrolled

Cheers,
Henry

P.S. Announcements are objects, they are intended to hold the data
subscribers might be interested in.
Whenever you find yourself writing something like: 
someAnnouncer announce: SomeAnnouncement new
ask yourself twice if that may lead to subscribers accessing state that
would more naturally be part of the announcement through other channels
(such as keeping extra instvars, etc).



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

Re: [Pharo-dev] Glamour List Presentation get selection index

[Andrei Chis]

Hi,

No. Currently from a GLMListPresentation you can just get the selected
element.


Cheers,
Andrei


On Tue, Mar 24, 2015 at 7:40 PM, Yuriy Tymchuk  wrote:

> Hi,
>
> is it possible, to get selection index from GLMListPresentation?
>
> Cheers
> Uko
>
>

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Alain Plantec via Pharo-dev]

--- Begin Message ---

> 
> I don’t get it sorry.
> 
> Padding by ten pixels to the left:
> 
>   | leftMargin aParserButton |
>   leftMargin := Morph new
>   width: 10;
>   hResizing: #shrinkWrap;
>   vResizing: #spaceFill.
>   aParserButton := PluggableButtonMorph on: self getState: nil action: 
> #parse.
>   aParserButton
>   hResizing: #spaceFill;
>   vResizing: #shrinkWrap;
>   label: 'Parse'.
>   AlignmentMorph newRow
>   vResizing: #shrinkWrap;
>   hResizing: #spaceFill;
>   layoutInset: 0;
>   addMorph: aParserButton;
>   addMorph: leftMargin;
>   openInWorld

Regarding this example, AlignmentMorph is a submorph of Morph with a layout 
policy.
you can do the same with bloc. No time now but i will implement this example in 
my doc.

> 
> Mind you, I consider Bloc a very good choice, but I fear that we're not able 
> to stress it enough with hard, very advanced GUIs to ensure we're not loosing 
> power compared to Morphic.

yes, there is a risk, this is why we should progress carefully and not too fast

thanks
Alain


--- End Message ---

Re: [Pharo-dev] Some Memory Leak

[Henrik Sperre Johansen]

Along the lines of Nicolas' hint, here's one example of what you can *not*
do, and expect to work (just the other way around):

GLMPagerScrollBrick pagerModel: aModel
pagerModel := aModel.
-snip-
pagerModel announcer weak
when: GLMPagePushed send: #onPagePushed: to: self.
-snip-

In a workspace:
pager:= GLMPagerModel new.
brick := GLMPagerScrollBrick  new.
brick pagerModel: pager.
brick := nil.
Smalltalk garbageCollect.
pager announcer subscriptions numberOfSubscriptions. --> 8

And, with a small addition of early exit after nilling pagerModel if aModel
is nil:
(pager announcer subscriptions instVarNamed: #subscriptions) anyOne
subscriber pagerModel: nil.
Smalltalk garbageCollect.
pager announcer subscriptions numberOfSubscriptions. --> 0

In other words: You can NOT hold references to Announcers in an object that
subscribes to it weakly.

Cheers,
Henry



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

[Pharo-dev] Existing

[Torsten Bergmann]

Hi Tudor and all,

to understand the issue one has to know:
--
There are two pragmas in Pharo 4 that were already introduced and integrated:

  

[Pharo-dev] Glamour List Presentation get selection index

[Yuriy Tymchuk]

Hi,

is it possible, to get selection index from GLMListPresentation?

Cheers
Uko

Re: [Pharo-dev] Some Memory Leak

[Andrei Chis]

If somebody has a larger image can he/she load the latest version of
Glamour-Morphic-Brick and then run [1] plus a few garbage collects.

[1] Smalltalk cleanUp: true except: #() confirming: false.


Cheers,
Andrei

On Tue, Mar 24, 2015 at 4:56 PM, Sven Van Caekenberghe  wrote:

>
> > On 24 Mar 2015, at 16:50, Andrei Chis 
> wrote:
> >
> > There are lot of spotter objects that do not get garbaged collected
> >
> > GTSpotter allInstances size --> 29 in my image
>
> I got 10 now.
>
> But can they cause megabytes to be locked up ?
>
> > On Tue, Mar 24, 2015 at 4:16 PM, Tudor Girba 
> wrote:
> > Yes, there are clearly objects lying around. I suspect it has to do with
> Playground or Inspector, but I am not sure.
> >
> > Doru
> >
> > On Tue, Mar 24, 2015 at 4:13 PM, Max Leske  wrote:
> >
> > > On 24 Mar 2015, at 15:18, Sven Van Caekenberghe  wrote:
> > >
> > > Hi,
> > >
> > > There seems to be some kind of memory leak in recent Pharo 4.0 images.
> Image size (as saved on disk) seems to be growing very rapidly under normal
> use (development with Nautilus, Spotter, GTPlayground, GTInspector and
> Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and
> they seem to increase constantly, over a period of days.
> >
> > Are you saying that the static image size is growing? Dynamic growth
> could easily be explained by leaks in NativeBoost for instance. But static
> image size means that there are objects lying around that shouldn’t (at
> least that should be easier to debug).
> >
> > >
> > > One way to look at memory use is with
> > >
> > >  SpaceTally printSpaceAnalysis
> > >
> > > but that takes a while.
> > >
> > > Please help us find and fix this issue.
> > >
> > > Thanks,
> > >
> > > Sven
> > >
> > >
> >
> >
> >
> >
> >
> > --
> > www.tudorgirba.com
> >
> > "Every thing has its own flow"
> >
>
>
>

Re: [Pharo-dev] Update question

[Norbert Hartl]

> Am 24.03.2015 um 18:45 schrieb Marcus Denker :
> 
> 
>> On 24 Mar 2015, at 11:13, Norbert Hartl  wrote:
>> 
>> Today I wanted (again) to update my image and it can't find GT packages. So 
>> I'm interested how the community deals with that. Do you take fresh 
>> downloaded images regularly? Or you do not update? Is it just me?
>> 
> 
> We should add an issue to the issue tracker… I really wonder how this 
> happens. 
> 
https://pharo.fogbugz.com/default.asp?15231 


Norbert

Re: [Pharo-dev] [Pharo4] 203 issues tagged tagged for Pharo4

[Marcus Denker]

33. And there are some already fixed, waiting to be reviewed.

> On 22 Mar 2015, at 19:29, Marcus Denker  wrote:
> 
> 44!
> 
>> On 20 Mar 2015, at 20:17, Marcus Denker  wrote:
>> 
>> 52. Much better!
>> 
>> some are even already fixed (but not integrated) so we will be below 50 soon.
>> 
>>> On 20 Mar 2015, at 10:11, Marcus Denker  wrote:
>>> 
>>> 68
>>> 
 On 19 Mar 2015, at 08:50, Marcus Denker  wrote:
 
 88.
 
 https://pharo.fogbugz.com/f/filters/103/4-0-All
 
>>> 
>>> 
>> 
> 

Re: [Pharo-dev] Update question

[Marcus Denker]

> On 24 Mar 2015, at 11:13, Norbert Hartl  wrote:
> 
> Today I wanted (again) to update my image and it can't find GT packages. So 
> I'm interested how the community deals with that. Do you take fresh 
> downloaded images regularly? Or you do not update? Is it just me?
> 

We should add an issue to the issue tracker… I really wonder how this happens. 

Marcus

[Pharo-dev] [pharo-project/pharo-core] 059630: 40581

[GitHub]

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

  Changed paths:
R AST-Interpreter-Core.package/AIBlockContext.class/README.md
R AST-Interpreter-Core.package/AIBlockContext.class/class/instance 
creation/fromVMContext_.st
R AST-Interpreter-Core.package/AIBlockContext.class/definition.st
R 
AST-Interpreter-Core.package/AIBlockContext.class/instance/accessing/exceptionHandler.st
R 
AST-Interpreter-Core.package/AIBlockContext.class/instance/accessing/exceptionHandler_.st
R 
AST-Interpreter-Core.package/AIBlockContext.class/instance/accessing/homeContext.st
R 
AST-Interpreter-Core.package/AIBlockContext.class/instance/accessing/homeContext_.st
R 
AST-Interpreter-Core.package/AIBlockContext.class/instance/accessing/method.st
R 
AST-Interpreter-Core.package/AIBlockContext.class/instance/accessing/methodClass.st
R 
AST-Interpreter-Core.package/AIBlockContext.class/instance/accessing/receiver.st
R 
AST-Interpreter-Core.package/AIBlockContext.class/instance/accessing/returnContext.st
R 
AST-Interpreter-Core.package/AIBlockContext.class/instance/debugging/debugPrintString.st
R 
AST-Interpreter-Core.package/AIBlockContext.class/instance/printing/printOn_.st
R AST-Interpreter-Core.package/AIBlockContext.class/instance/testing/=.st
R 
AST-Interpreter-Core.package/AIBlockContext.class/instance/testing/hasExceptionHandler.st
R AST-Interpreter-Core.package/AIContext.class/README.md
R AST-Interpreter-Core.package/AIContext.class/definition.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/accessing/arguments.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/accessing/arguments_.st
R AST-Interpreter-Core.package/AIContext.class/instance/accessing/closure.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/accessing/closure_.st
R AST-Interpreter-Core.package/AIContext.class/instance/accessing/code.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/accessing/createTemp_.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/accessing/currentExecutedNode.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/accessing/currentExecutedNode_.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/accessing/homeContext.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/accessing/methodClass.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/accessing/methodNode.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/accessing/outerContext.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/accessing/outerContext_.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/accessing/tempNamed_.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/accessing/tempNamed_put_.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/accessing/temporaries.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/accessing/temporaries_.st
R AST-Interpreter-Core.package/AIContext.class/instance/compatibility 
layer/contextTag.st
R AST-Interpreter-Core.package/AIContext.class/instance/compatibility 
layer/home.st
R AST-Interpreter-Core.package/AIContext.class/instance/compatibility 
layer/selector.st
R AST-Interpreter-Core.package/AIContext.class/instance/compatibility 
layer/sender.st
R AST-Interpreter-Core.package/AIContext.class/instance/continuation/die.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/continuation/resume_.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/continuation/return_.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/continuation/terminateTo_value_.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/debugging/debugPrintString.st
R AST-Interpreter-Core.package/AIContext.class/instance/debugging/stack.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/exception-handling/cannotReturn_.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/exception-handling/cannotReturn_to_.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/exception-handling/findContextSuchThat_.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/exception-handling/findNextHandlerContext.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/exception-handling/handleSignal_.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/exception-handling/nextHandlerContext.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/initialization/initialize.st
R 
AST-Interpreter-Core.package/AIContext.class/instance/initialize-release/initializeContext_.st
R AST-Interpreter-Core.package/AIContext.class/instance/printing/printOn_.st

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

[GitHub]

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

Re: [Pharo-dev] Update question

[kilon alios]

"@Kilon:
  Integrating PharoLauncher in the standard image would not make sense.
Then I use PharoLauncher to download
  an image with a prepackaged PharoLauncher, ...

  If you mean that it should be the default tool to download when getting
Pharo 4.0 or Pharo 3.0 from the
  download page or from zeroconf then I would agree. Maybe some more help
is needed for Pharo newbees then."

Actually it makes perfect sense, think about it. We have configuration
browser. Now go to your pharolauncher and enable development mode, open
world menu and bingo pharolauncher is there as a tool and i think thats
great already. So you have 2 tools in your image 1) Configuration Browser
that allows you to install pharo libraries / apps 2) PharoLauncher that
allows you to download images . Both accessed in world menu and this
functionality is already provided by PharoLauncher.

"
I don't think Kilon was referring to PhaoLauncher, but to "World > System >
Software update"
cheers -ben"

Yeap correct Ben I was referring to Software Update, as a matter of fact I
loved PharoLauncher so much I became a contributor and added documentation
about it in the new PBE.

On Tue, Mar 24, 2015 at 4:43 PM, Norbert Hartl  wrote:

>
> > Am 24.03.2015 um 13:02 schrieb Sean P. DeNigris :
> >
> > NorbertHartl wrote
> >> What would be better using PharoLauncher?
> >
> > I was a hold out, but I've finally started using it and it's really nice.
> > For things that don't have an automated build process, it's much better
> than
> > downloading from file.pharo.org by hand. You can set the folder to
> which the
> > images get saved, and choose to make new images from e.g. Pharo 4, 3, 2,
> > moose, anything on the contribution CI server, and a few others.
> >
> > I really like Peter's idea to act from a startup script based on the
> image
> > name. That sounds like a powerful combination.
> >
>
> Oh, I didn't know that you can choose the folder where the images live. I
> might take another peek at it. But then I'm using something like that for a
> very long time.
>
> - make a folder projects in you home directory
> - in that folder create symlink to any of your smalltalk project directory
> that you are working at the moment
> - drop that folder in the dock
> - you click the icon on the dock, a list of projects pops up, you select
> one and you get the contents of that the directory. You click on an image
> and it starts
>
> So I'm not sure I'll gain something but I will try again.
>
> Norbert
>

Re: [Pharo-dev] collecting Pharo 4.0 Contributors

[kilon alios]

I am Dimitris Chloupis, always a honor to contribute to such an awesome
project like Pharo. I have not contributed bug fixes but I have contributed
with a lot of documentation by porting 5 chapters of PBE to Pharo 3 and
many video tutorials.

You cant be a dead language and still the king of live coding , that would
be ironic :D

Nope Pharo is alive and kicking ass . Thanks to all the contributors .

On Tue, Mar 24, 2015 at 4:39 PM, Esteban Lorenzano 
wrote:

> Hi,
>
> I’m collection the list of contributors for this version.
> Since we detect contributors by author stamps:
>
> - some times who made the commit does not reflect all the people who
> worked on a problem,
> - we consider contributors to Pharo all people who has contributed in any
> way: discussing things, commenting bugs, doing videos or any kind of
> documentation, etc.
>
> the list will be incomplete, so please look for yourself on it and let me
> know if you are missing:
>
> also, I would like to know who are this two guys:
> - aaef
> - monty
>
> (btw… we collected so far 76 contributors… not bat at all, for a dead
> language ;) )
>
> Clara Allende
> Jean Baptiste Arnaud
> Philippe Back
> Clement Bera
> Alexandre Bergel
> Torsten Bergmann
> Vincent Blondeau
> Noury Bouraqadi
> Santiago Bragagnolo
> Johan Brichau
> Sven Van Caekenberghe
> Damien Cassou
> Nicolas Cellier
> Guido Chari
> Dimitris Chloupis
> Andrei Chis
> Ben Coman
> Bernardo Contreras
> Tommaso Dal Sasso
> Jan Van De Sandt
> Christophe Demarey
> Sean DeNigris
> Marcus Denker
> Martin Dias
> Stephane Ducasse
> Stephan Eggermont
> Luc Fabresse
> Johan Fabry
> Hilaire Fernandes
> Jerome Garcia
> Tudor Girba
> Thierry Goubier
> Kris Gybels
> Norbert Hartl
> Dale Henrichs
> Pablo Herrero
> Nicolai Hess
> Pavel Krivanek
> Juraj Kubelka
> Jan Kurs
> Laurent Laffont
> Jannik Laval
> Kevin Lanvin
> Max Leske
> David Lewis
> Diego Lont
> Esteban Lorenzano
> Esteban Maringolo
> Stefan Marr
> Tim Mackinnon
> Max Mattone
> Martin Mc Clure
> Eliot Miranda
> Sean De Nigris
> Alain Plantec
> Guillermo Polito
> Damien Pollet
> Stefan Reichhart
> Mark Rizun
> Udo Schneider
> Ignacio Sniechowski
> Henrik Sperre Johansen
> Igor Stasenko
> Aliaksei Syrel
> Ciprian Teodorov
> Camille Teruel
> Sebastian Tleye
> Yuriy Tymchuk
> Peter Uhnak
> Andres Valloud
> Sven Van Caekenberghe
> Thomas Vincent
> Martin Walk
> Richard Wettel
>
> thanks,
> Esteban
>

Re: [Pharo-dev] Google Code Shutdown

[kilon alios]

Another project abandoned by Google, what a surprise :D

On Tue, Mar 24, 2015 at 3:14 PM, Sean P. DeNigris 
wrote:

> In case anyone hasn't heard, Google Code will shut down entirely on January
> 25, 2016. I was following these Smalltalk projects there:
> magritte-metamodel
> moose-technology
> seaside
> marsonpharo
> nativeboost
> metacello
> squeaksource3
> phratch - already on GitHub per Jannik
>
> The easiest action seems to be to export to GitHub, for which Google Code
> even provides a button! I just used it for one of my projects and it was
> pretty painless.
>
> - Sean
>
> Cross-posted to ESUG, pharo-dev, squeak-dev, seaside-dev, magritte,
> metacello
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/Google-Code-Shutdown-tp4814760.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] Slots and MethodWrappers

[Marcus Denker]

> On 24 Mar 2015, at 13:02, p...@highoctane.be wrote:
> 
> I wondered how these two things are related.
> 
> Will slots be giving MWs facilities out of the box?
> 
> When should I use both?
> 
Hello,

Slots are about state (instance variables), while method wrappers are about 
methods
(and hooking into method execution). So they are not directly related, but 
there is indeed
a connection :-)

The MetaLinks (which we will get for real in Pharo5, I sadly did not finish it 
for Pharo4) 
can be seen as a generalisation of MethodWrappers. They are much more flexible 
and
apply not to whole methods, but any “structural” reflective entity.

This means any node in the AST, but, in addition, slots. This means you can put 
a meta-link
on a slot (e.g. one describing a normal instance variable) and call meta-object 
before, after
or instead. Which in some way means that you can put a “wrapper” on an instance 
variable.

The meta-link machinery will indeed completely replace method wrappers. You can 
implement
method wrappers using them if you need them, but in most cases using directly 
the link will
be exactly what you need.

I am sure we will use this *a lot* for the tools. E.g. breakpoints will use 
links to hook into execution.
Or the inspector will use them to get notified on state change to update the 
display… an many more.

Marcus

Re: [Pharo-dev] Some Memory Leak

[Max Leske]

> On 24 Mar 2015, at 16:56, Sven Van Caekenberghe  wrote:
> 
> 
>> On 24 Mar 2015, at 16:50, Andrei Chis  wrote:
>> 
>> There are lot of spotter objects that do not get garbaged collected
>> 
>> GTSpotter allInstances size --> 29 in my image
> 
> I got 10 now.
> 
> But can they cause megabytes to be locked up ?

If they work like Nautilus then there’s a huge tree attached to every one, with 
morphs, weak references, contexts…
I think there was (and maybe there still is) a problem with detection of 
circular dependencies and weak references. If you register actions in the 
EventManager (or whatever it’s called now) make sure that they are cleared.

Then, there used to be a class variable somewhere that held on to the single 
instance of some kind of work space factory (or some such thing) which strongly 
holds on to stuff and prevents garbage collection. 

I don’t know what has been cleaned by now but there’s a lot of potential for 
such things…

I had to write some code a while ago to get rid of window instances that 
wouldn’t be garbage collected. I’ve attached the file outs, maybe someone can 
use them (they are for Pharo 1.3 though, so maybe not of too much use…)

Cheers,
Max



NSSettings class-cleanupEvents.st
Description: Binary data


NSSettings class-cleanupSystemWindows.st
Description: Binary data


NSSettings class-cleanupWindows.st
Description: Binary data


NSSettings class-cleanupWorkspaces.st
Description: Binary data


> 
>> On Tue, Mar 24, 2015 at 4:16 PM, Tudor Girba  wrote:
>> Yes, there are clearly objects lying around. I suspect it has to do with 
>> Playground or Inspector, but I am not sure.
>> 
>> Doru
>> 
>> On Tue, Mar 24, 2015 at 4:13 PM, Max Leske  wrote:
>> 
>>> On 24 Mar 2015, at 15:18, Sven Van Caekenberghe  wrote:
>>> 
>>> Hi,
>>> 
>>> There seems to be some kind of memory leak in recent Pharo 4.0 images. 
>>> Image size (as saved on disk) seems to be growing very rapidly under normal 
>>> use (development with Nautilus, Spotter, GTPlayground, GTInspector and 
>>> Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and 
>>> they seem to increase constantly, over a period of days.
>> 
>> Are you saying that the static image size is growing? Dynamic growth could 
>> easily be explained by leaks in NativeBoost for instance. But static image 
>> size means that there are objects lying around that shouldn’t (at least that 
>> should be easier to debug).
>> 
>>> 
>>> One way to look at memory use is with
>>> 
>>> SpaceTally printSpaceAnalysis
>>> 
>>> but that takes a while.
>>> 
>>> Please help us find and fix this issue.
>>> 
>>> Thanks,
>>> 
>>> Sven
>>> 
>>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> www.tudorgirba.com
>> 
>> "Every thing has its own flow"
>> 
> 
> 

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[kilon alios]

"
if you read my mail, you will notice that I said BOTH are on the table (and
we are actually moving oon both):
- Bloc is the redesign
- In the mean time we WORK and ENCOURAGE others to work on improve it."

Last time I asked about Bloc , I was told not to use it and instead stick
with Spec or Morphic.

I said it before and will say it again, you guys need to sit down and make
a roadmap for Pharo because I am reading a lot of conflicting posts in this
mailing list and this is does not give the professional look Pharo wants to
show to people outside Pharo. As a user "replace in the long run" is not
enough ! The original author of Bloc , Alain, also said that he is pretty
much the only one that works on Bloc (with some help from Stef) and if
people dont start helping him out he is going to give up.

How many more threads should we have about the GUI future of Pharo before
people really get the message that we need a roadmap ?

Additionally , Pharo needs a roadmap , seriously it does.

"but Morphic it self has several fundamental flaws that cannot be fixed and
that’s why in the long, very long way, needs to be replaced.  "

What flaws , where , when , how , why ? So much discussion that Morphic
must go , close to zero discussion what the actual problems are.

"First, Athens is not a replace for Morphic, is a replace for the canvas in
which morphs are drawn. So is not Morphic or Athens… is "Morph using
DisplayPlugin" or "Morphic using Athens".

Second I did not say Athens is to replace Morphic . From my understanding
Bloc is based on Athens and Bloc is to replace Morphic. Correct me If I am
wrong.

"Glamour is very mature and I’ve used it serval times… and in theory Brick
will be compatible with Glamour (mostly) so even if developers deprecate
one for the other you will be able to use your code (mostly). "

Brick is called non usable by its own authors. Glamour is framework of
building browsers and simplified GUIs , its nowhere near as powerful as
Morphic and is based on Morphic. From the looks of its is not even as
powerful as Spec. Through the couple years I have been around I have seen
at best a couple of question on how to make it work compared to hundreds of
questions about Spec and Morphic . How something can be matured if it is
not heavily used ?

"But anyway, how can Athens be so slow? Why? Can you share some info? "

You ask me to tell you why Athens is slow when we have this discussion
before ( a few months ago) and you told me that Athens is slow because of
how Pharo handles rendering and that as soon as we move to SDL things will
be 10 times faster.

All I have to do is VGTiger runDemo and my 3Ghz Quad Cores beg me for mercy
at 50% consumption. Calling it slow , is an understatement.

Other much simpler example are very slow too like the sliding logo example
at many more.

Of course this problem affects Morphic too so personally I am examining the
possibility that no pharo library will satisfy me and instead I will make
my own GUI API on top of QT or HTML. Obviously more work for me, obviously
a scenario that I want to avoid, but if the alternative is an app that
consumes 50% cpu then I dont have much of a choice. Maybe I could take a
look at Mars too.

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Thierry Goubier]

2015-03-24 16:43 GMT+01:00 Aliaksei Syrel :

> The same in Brick:
>
> GLMButtonBrick new
>>   marginLeft: 10;
>>   text: 'Parse';
>>   vAlign: #center;
>>   hSpaceFill;
>>   openInBrickWindow
>
>
> Yes, I agree - using composition for margin/padding/aligning is much more
> simple, readable, fast and maintainable, than horrible scripting in brick,
> sorry for that.
>

Yes, I'm pretty sure writing the same stuff in Motif or Windows 3.1 works
too. Oh, well, maybe not in Windows 3.1 ;)

And, so what?

Is the contest writing a basic, business gui of the 80's the shortest way?

Thierry

Re: [Pharo-dev] Some Memory Leak

[Tudor Girba]

I also tried this:

1. Create a dummy class:
Object subclass: #AAA
instanceVariableNames: 'x'
classVariableNames: ''
category: 'AAA'.
2. Open a Playground and do it and go on this:
a := #AAA asClass new.

3. In the second pane go on "self"

4. Close the Playground

5. Execute:
3 timesRepeat: [ Smalltalk garbageCollect ].

6. Check:
#AAA asClass allInstances.

7. Repeat if necessary, and after a while, the result after step 6 is not
empty.


Cheers,
Doru


On Tue, Mar 24, 2015 at 4:50 PM, Andrei Chis 
wrote:

> There are lot of spotter objects that do not get garbaged collected
>
> GTSpotter allInstances size --> 29 in my image
>
> On Tue, Mar 24, 2015 at 4:16 PM, Tudor Girba  wrote:
>
>> Yes, there are clearly objects lying around. I suspect it has to do with
>> Playground or Inspector, but I am not sure.
>>
>> Doru
>>
>> On Tue, Mar 24, 2015 at 4:13 PM, Max Leske  wrote:
>>
>>>
>>> > On 24 Mar 2015, at 15:18, Sven Van Caekenberghe  wrote:
>>> >
>>> > Hi,
>>> >
>>> > There seems to be some kind of memory leak in recent Pharo 4.0 images.
>>> Image size (as saved on disk) seems to be growing very rapidly under normal
>>> use (development with Nautilus, Spotter, GTPlayground, GTInspector and
>>> Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and
>>> they seem to increase constantly, over a period of days.
>>>
>>> Are you saying that the static image size is growing? Dynamic growth
>>> could easily be explained by leaks in NativeBoost for instance. But static
>>> image size means that there are objects lying around that shouldn’t (at
>>> least that should be easier to debug).
>>>
>>> >
>>> > One way to look at memory use is with
>>> >
>>> >  SpaceTally printSpaceAnalysis
>>> >
>>> > but that takes a while.
>>> >
>>> > Please help us find and fix this issue.
>>> >
>>> > Thanks,
>>> >
>>> > Sven
>>> >
>>> >
>>>
>>>
>>>
>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Some Memory Leak

[Sven Van Caekenberghe]

> On 24 Mar 2015, at 16:50, Andrei Chis  wrote:
> 
> There are lot of spotter objects that do not get garbaged collected
> 
> GTSpotter allInstances size --> 29 in my image

I got 10 now.

But can they cause megabytes to be locked up ?

> On Tue, Mar 24, 2015 at 4:16 PM, Tudor Girba  wrote:
> Yes, there are clearly objects lying around. I suspect it has to do with 
> Playground or Inspector, but I am not sure.
> 
> Doru
> 
> On Tue, Mar 24, 2015 at 4:13 PM, Max Leske  wrote:
> 
> > On 24 Mar 2015, at 15:18, Sven Van Caekenberghe  wrote:
> >
> > Hi,
> >
> > There seems to be some kind of memory leak in recent Pharo 4.0 images. 
> > Image size (as saved on disk) seems to be growing very rapidly under normal 
> > use (development with Nautilus, Spotter, GTPlayground, GTInspector and 
> > Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and 
> > they seem to increase constantly, over a period of days.
> 
> Are you saying that the static image size is growing? Dynamic growth could 
> easily be explained by leaks in NativeBoost for instance. But static image 
> size means that there are objects lying around that shouldn’t (at least that 
> should be easier to debug).
> 
> >
> > One way to look at memory use is with
> >
> >  SpaceTally printSpaceAnalysis
> >
> > but that takes a while.
> >
> > Please help us find and fix this issue.
> >
> > Thanks,
> >
> > Sven
> >
> >
> 
> 
> 
> 
> 
> -- 
> www.tudorgirba.com
> 
> "Every thing has its own flow"
> 

Re: [Pharo-dev] Some Memory Leak

[Andrei Chis]

There are lot of spotter objects that do not get garbaged collected

GTSpotter allInstances size --> 29 in my image

On Tue, Mar 24, 2015 at 4:16 PM, Tudor Girba  wrote:

> Yes, there are clearly objects lying around. I suspect it has to do with
> Playground or Inspector, but I am not sure.
>
> Doru
>
> On Tue, Mar 24, 2015 at 4:13 PM, Max Leske  wrote:
>
>>
>> > On 24 Mar 2015, at 15:18, Sven Van Caekenberghe  wrote:
>> >
>> > Hi,
>> >
>> > There seems to be some kind of memory leak in recent Pharo 4.0 images.
>> Image size (as saved on disk) seems to be growing very rapidly under normal
>> use (development with Nautilus, Spotter, GTPlayground, GTInspector and
>> Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and
>> they seem to increase constantly, over a period of days.
>>
>> Are you saying that the static image size is growing? Dynamic growth
>> could easily be explained by leaks in NativeBoost for instance. But static
>> image size means that there are objects lying around that shouldn’t (at
>> least that should be easier to debug).
>>
>> >
>> > One way to look at memory use is with
>> >
>> >  SpaceTally printSpaceAnalysis
>> >
>> > but that takes a while.
>> >
>> > Please help us find and fix this issue.
>> >
>> > Thanks,
>> >
>> > Sven
>> >
>> >
>>
>>
>>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Aliaksei Syrel]

The same in Brick:

GLMButtonBrick new
>   marginLeft: 10;
>   text: 'Parse';
>   vAlign: #center;
>   hSpaceFill;
>   openInBrickWindow


Yes, I agree - using composition for margin/padding/aligning is much more
simple, readable, fast and maintainable, than horrible scripting in brick,
sorry for that.

One more time for people who still don't hear us. Brick is internal for GT.
We just put in package named "Brick" reusable widgets we built to use in
our tools. They just normal subclasses of morph. Nothing fancy. We don't
want you to use it and suggest to learn Spec for UI, please.

Keep Calm :)

Cheers,
Alex

On Tue, Mar 24, 2015 at 4:28 PM, Thierry Goubier 
wrote:

>
>
> 2015-03-24 16:03 GMT+01:00 Alain Plantec via Pharo-dev <
> pharo-dev@lists.pharo.org>:
>
>>
>>
>> -- Message transféré --
>> From: Alain Plantec 
>> To: Pharo Development List 
>> Cc:
>> Date: Tue, 24 Mar 2015 16:02:56 +0100
>> Subject: Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
>>
>> Le 24 mars 2015 à 15:56, Thierry Goubier  a
>> écrit :
>>
>>
>>
>> 2015-03-24 15:39 GMT+01:00 Denis Kudriashov :
>>
>>>
>>> 2015-03-24 17:36 GMT+03:00 Thierry Goubier :
>>>
 IMHO, Rubrics, just from it's layout approach, is already a step
 backward.
>>>
>>>
>>>
>>> What you mean by this? What's wrong with Rubric layouting?
>>>
>>
>> Padding -> resolved in Morphic by Morph composition: no need to add that
>> to the Layout engine of each widget
>>
>> Aligning -> resolved in Morphic by Morph composition: no need to add that
>> to the Layout engine of each widget
>>
>>
>> I don’t get it sorry.
>>
>
> Padding by ten pixels to the left:
>
> | leftMargin aParserButton |
> leftMargin := Morph new
> width: 10;
> hResizing: #shrinkWrap;
> vResizing: #spaceFill.
> aParserButton := PluggableButtonMorph on: self getState: nil action:
> #parse.
> aParserButton
> hResizing: #spaceFill;
> vResizing: #shrinkWrap;
> label: 'Parse'.
> AlignmentMorph newRow
> vResizing: #shrinkWrap;
> hResizing: #spaceFill;
> layoutInset: 0;
> addMorph: aParserButton;
> addMorph: leftMargin;
> openInWorld
>
> Aligning to the center, horizontally: add a right and left morph, but
> hResizing: #spaceFill this time.
>
> Some type of constraints are hard to do with that system (*), but... LaTeX
> layout exclusively with that, so, maybe it works ;)
>
> ((*) And this is where someone knowing Rubricks could come with a few
> examples of those).
>
>
>> maybe one example would help
>>
>
> From the SmaCC GUI :)
>
>
>>
>>
>> ZOrdering -> nothing says that submorphs in Morphic can't overlay each
>> other.
>>
>>
>> Bloc uses z-ordering exactly as Morphic (the code for adding/removing a
>> submorph are nearly the same)
>>
>
> Ok. But do you know why? There is a reason for that choice.
>
> Spec had a real issue with that ordering, so the pressure will be to get
> it 'corrected'.
>
> Mind you, I consider Bloc a very good choice, but I fear that we're not
> able to stress it enough with hard, very advanced GUIs to ensure we're not
> loosing power compared to Morphic.
>
> Thierry
>
>
>>
>> Cheers
>> Alain
>>
>>
>> One of the issue with Morphic as it stands today is that the API is
>> fairly complex if you want to carefully control placement and morph
>> behavior under container resizing / move. Oh, and it's very buggy too.
>> Rubricks shows an API which is even more complex, which isn't surprising if
>> the inspiration is CSS layout.
>>
>> Thierry
>>
>>
>>
>>
>

Re: [Pharo-dev] String>>howManyMatch: Bug or feature ?

[Nicolas Cellier]

2015-03-24 13:53 GMT+01:00 Noury Bouraqadi :

> Hi,
>
> The normal behavior
> 'abc' howManyMatch: 'abd' --> 2.
>
> I got suprized the way Blanks and new lines are handled.
>
> '\**' withCRs howManyMatch: '\\**' withCRs. --> 2 instead of 1
>
> 'ab\ **' withCRs howManyMatch: 'ab\\**' withCRs. --> 4 instead of 3
>
> '\ **' withCRs howManyMatch: '\\**' withCRs. --> 3 instead of 1
>
> 'ab\ **' withCRs howManyMatch: 'ab\\**' withCRs. --> 5 instead of 3
>
> The behavior is the same in both Pharo 3 and Pharo 4.
>
> Reading the code of does not help me understand why it's this way
>
> String>>howManyMatch: string
> "Count the number of characters that match up in self and aString."
> | count shorterLength |
>
> count := 0.
> shorterLength := self size min: string size.
> 1 to: shorterLength do: [:index |
> (self at: index) = (string at: index )
> ifTrue: [ count := count + 1 ]].
> ^  count
>
>
> Noury
>

Noury,
I think you're looking after the number of common chars only at beginning.
Wouldn't the method finder hit a better match?

The method works as advertised in the comment. Though I find it very
questionnable:
Doesn't "match" imply some other semantic like pattern matching (and thus
things like wild character etc...)?
Is such specific behavior usefull? Really? Why/Where?


>
> Afin de contribuer au respect de l'environnement,
> merci de n'imprimer ce courriel qu'en cas de necessite
>
> Please consider the environment before you print
>
>
>
>

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Thierry Goubier]

2015-03-24 16:03 GMT+01:00 Alain Plantec via Pharo-dev <
pharo-dev@lists.pharo.org>:

>
>
> -- Message transféré --
> From: Alain Plantec 
> To: Pharo Development List 
> Cc:
> Date: Tue, 24 Mar 2015 16:02:56 +0100
> Subject: Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
>
> Le 24 mars 2015 à 15:56, Thierry Goubier  a
> écrit :
>
>
>
> 2015-03-24 15:39 GMT+01:00 Denis Kudriashov :
>
>>
>> 2015-03-24 17:36 GMT+03:00 Thierry Goubier :
>>
>>> IMHO, Rubrics, just from it's layout approach, is already a step
>>> backward.
>>
>>
>>
>> What you mean by this? What's wrong with Rubric layouting?
>>
>
> Padding -> resolved in Morphic by Morph composition: no need to add that
> to the Layout engine of each widget
>
> Aligning -> resolved in Morphic by Morph composition: no need to add that
> to the Layout engine of each widget
>
>
> I don't get it sorry.
>

Padding by ten pixels to the left:

| leftMargin aParserButton |
leftMargin := Morph new
width: 10;
hResizing: #shrinkWrap;
vResizing: #spaceFill.
aParserButton := PluggableButtonMorph on: self getState: nil action: #parse.
aParserButton
hResizing: #spaceFill;
vResizing: #shrinkWrap;
label: 'Parse'.
AlignmentMorph newRow
vResizing: #shrinkWrap;
hResizing: #spaceFill;
layoutInset: 0;
addMorph: aParserButton;
addMorph: leftMargin;
openInWorld

Aligning to the center, horizontally: add a right and left morph, but
hResizing: #spaceFill this time.

Some type of constraints are hard to do with that system (*), but... LaTeX
layout exclusively with that, so, maybe it works ;)

((*) And this is where someone knowing Rubricks could come with a few
examples of those).


> maybe one example would help
>

>From the SmaCC GUI :)


>
>
> ZOrdering -> nothing says that submorphs in Morphic can't overlay each
> other.
>
>
> Bloc uses z-ordering exactly as Morphic (the code for adding/removing a
> submorph are nearly the same)
>

Ok. But do you know why? There is a reason for that choice.

Spec had a real issue with that ordering, so the pressure will be to get it
'corrected'.

Mind you, I consider Bloc a very good choice, but I fear that we're not
able to stress it enough with hard, very advanced GUIs to ensure we're not
loosing power compared to Morphic.

Thierry


>
> Cheers
> Alain
>
>
> One of the issue with Morphic as it stands today is that the API is fairly
> complex if you want to carefully control placement and morph behavior under
> container resizing / move. Oh, and it's very buggy too. Rubricks shows an
> API which is even more complex, which isn't surprising if the inspiration
> is CSS layout.
>
> Thierry
>
>
>
>

Re: [Pharo-dev] Populating/editing list with modal dialogs in Glamour

[Andrei Chis]

Hi,

GLMActionListPresentation is currently the only mechanism to have a
separate list of actions as buttons.
However, usually when working with lists we add actions directly in the
toolbar of the presentation.

There is no default way of opening a pop-up. However, it shouldn't be so
difficult to have a special action that opens a pop-up.
We are actually adding one now because we need it for something :)

Cheers,
Andrei


On Tue, Mar 24, 2015 at 12:00 PM, Yuriy Tymchuk 
wrote:

> Hi everyone,
>
> I’m playing with glamour, and I’m trying to construct a list that can be
> edited e.g. you can add items, edit them and remove and for adding and
> editing you have a custom popup written again in glamour. So first question
> is how can I dead with basic actions? Is the GLMActionListPresentation way
> to go, or I should look on the other things. Another question is how do you
> open a modal window with glamour and how do you get the result from it.
>
> I’ll be very thankful for any reply.
> Cheers.
> Uko
>

Re: [Pharo-dev] Some Memory Leak

[Tudor Girba]

Yes, there are clearly objects lying around. I suspect it has to do with
Playground or Inspector, but I am not sure.

Doru

On Tue, Mar 24, 2015 at 4:13 PM, Max Leske  wrote:

>
> > On 24 Mar 2015, at 15:18, Sven Van Caekenberghe  wrote:
> >
> > Hi,
> >
> > There seems to be some kind of memory leak in recent Pharo 4.0 images.
> Image size (as saved on disk) seems to be growing very rapidly under normal
> use (development with Nautilus, Spotter, GTPlayground, GTInspector and
> Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and
> they seem to increase constantly, over a period of days.
>
> Are you saying that the static image size is growing? Dynamic growth could
> easily be explained by leaks in NativeBoost for instance. But static image
> size means that there are objects lying around that shouldn’t (at least
> that should be easier to debug).
>
> >
> > One way to look at memory use is with
> >
> >  SpaceTally printSpaceAnalysis
> >
> > but that takes a while.
> >
> > Please help us find and fix this issue.
> >
> > Thanks,
> >
> > Sven
> >
> >
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Some Memory Leak

[Sven Van Caekenberghe]

> On 24 Mar 2015, at 16:13, Max Leske  wrote:
> 
> 
>> On 24 Mar 2015, at 15:18, Sven Van Caekenberghe  wrote:
>> 
>> Hi,
>> 
>> There seems to be some kind of memory leak in recent Pharo 4.0 images. Image 
>> size (as saved on disk) seems to be growing very rapidly under normal use 
>> (development with Nautilus, Spotter, GTPlayground, GTInspector and 
>> Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and 
>> they seem to increase constantly, over a period of days.
> 
> Are you saying that the static image size is growing? Dynamic growth could 
> easily be explained by leaks in NativeBoost for instance. But static image 
> size means that there are objects lying around that shouldn’t (at least that 
> should be easier to debug).

Yes, it is the latter. We have seen it in a couple of places, but we can't seem 
to find the culprit.

Many people do not keep images very long, but it seems to be visible in one to 
two days, which is obviously too fast.

>> One way to look at memory use is with
>> 
>> SpaceTally printSpaceAnalysis
>> 
>> but that takes a while.
>> 
>> Please help us find and fix this issue.
>> 
>> Thanks,
>> 
>> Sven
>> 
>> 
> 
> 

Re: [Pharo-dev] Some Memory Leak

[Max Leske]

> On 24 Mar 2015, at 15:18, Sven Van Caekenberghe  wrote:
> 
> Hi,
> 
> There seems to be some kind of memory leak in recent Pharo 4.0 images. Image 
> size (as saved on disk) seems to be growing very rapidly under normal use 
> (development with Nautilus, Spotter, GTPlayground, GTInspector and 
> Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and 
> they seem to increase constantly, over a period of days.

Are you saying that the static image size is growing? Dynamic growth could 
easily be explained by leaks in NativeBoost for instance. But static image size 
means that there are objects lying around that shouldn’t (at least that should 
be easier to debug).

> 
> One way to look at memory use is with
> 
>  SpaceTally printSpaceAnalysis
> 
> but that takes a while.
> 
> Please help us find and fix this issue.
> 
> Thanks,
> 
> Sven
> 
> 

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Alain Plantec via Pharo-dev]

--- Begin Message ---
> Le 24 mars 2015 à 15:56, Thierry Goubier  a écrit :
> 
> 
> 
> 2015-03-24 15:39 GMT+01:00 Denis Kudriashov  >:
> 
> 2015-03-24 17:36 GMT+03:00 Thierry Goubier  >:
> IMHO, Rubrics, just from it's layout approach, is already a step backward.
> 
> 
> What you mean by this? What's wrong with Rubric layouting?
> 
> Padding -> resolved in Morphic by Morph composition: no need to add that to 
> the Layout engine of each widget
> 
> Aligning -> resolved in Morphic by Morph composition: no need to add that to 
> the Layout engine of each widget
> 

I don’t get it sorry. 

maybe one example would help


> ZOrdering -> nothing says that submorphs in Morphic can't overlay each other.

Bloc uses z-ordering exactly as Morphic (the code for adding/removing a 
submorph are nearly the same)

Cheers
Alain

> 
> One of the issue with Morphic as it stands today is that the API is fairly 
> complex if you want to carefully control placement and morph behavior under 
> container resizing / move. Oh, and it's very buggy too. Rubricks shows an API 
> which is even more complex, which isn't surprising if the inspiration is CSS 
> layout.
> 
> Thierry

--- End Message ---

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Thierry Goubier]

2015-03-24 15:39 GMT+01:00 Denis Kudriashov :

>
> 2015-03-24 17:36 GMT+03:00 Thierry Goubier :
>
>> IMHO, Rubrics, just from it's layout approach, is already a step backward.
>
>
>
> What you mean by this? What's wrong with Rubric layouting?
>

Padding -> resolved in Morphic by Morph composition: no need to add that to
the Layout engine of each widget

Aligning -> resolved in Morphic by Morph composition: no need to add that
to the Layout engine of each widget

ZOrdering -> nothing says that submorphs in Morphic can't overlay each
other.

One of the issue with Morphic as it stands today is that the API is fairly
complex if you want to carefully control placement and morph behavior under
container resizing / move. Oh, and it's very buggy too. Rubricks shows an
API which is even more complex, which isn't surprising if the inspiration
is CSS layout.

Thierry

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Thierry Goubier]

Hi,

2015-03-24 15:27 GMT+01:00 Tudor Girba :

> Hi,
>
>>
>> I think I do not understand this point. Why do you say that the future
> solution will be less than Morphic?
>
>
Because we're driving it with uses which are less than Morphic requirements
were.

Because you don't need Morphic power to do GT tools; it justs gets in the
way: slow, over-engineered for that use case. As a consequence, you end up
with Rubricks: dedicated, ad-hoc solution which is a far better match for
its use case. That Rubricks proudly present its Z layering where Morphic
was / is probably the easiest toolkit ever to do layering of arbitrary
widgets on top of another? (*)

Thierry

(*) Even if we're not doing it(**).

(**) Well, I did. Nobody's interested, so what ?






> Doru
>
>
>>
>> Thierry
>>
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>

Re: [Pharo-dev] Slots and MethodWrappers

[Norbert Hartl]

> Am 24.03.2015 um 15:26 schrieb Johan Fabry :
> 
> 
> I would say that they are different although related. Slots are for the 
> interception of accessing instance variables (for read and write), and method 
> wrappers for the interception of accessing methods (for execution).
> 
+1 Very precise and short. Conceptional some might see overlap when it comes to 
getters and setters :)

Norbert

>> On Mar 24, 2015, at 09:02, p...@highoctane.be  
>> wrote:
>> 
>> I wondered how these two things are related.
>> 
>> Will slots be giving MWs facilities out of the box?
>> 
>> When should I use both?
>> 
>> Phil
>> 
> 
> 
> 
> ---> Save our in-boxes! http://emailcharter.org  
> <---
> 
> Johan Fabry   -   http://pleiad.cl/~jfabry 
> PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile
> 

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Johan Fabry]

> On Mar 24, 2015, at 10:29, kilon alios  wrote:
> 
> [Spec] does not support custom made GUIs which is what I want


That’s simply not true. Spec supports the embedding of whatever Morph you want 
inside your GUI. So you can easily mix and match your custom components with 
all the standard Spec components.

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile

Re: [Pharo-dev] Update question

[Norbert Hartl]

> Am 24.03.2015 um 13:02 schrieb Sean P. DeNigris :
> 
> NorbertHartl wrote
>> What would be better using PharoLauncher? 
> 
> I was a hold out, but I've finally started using it and it's really nice.
> For things that don't have an automated build process, it's much better than
> downloading from file.pharo.org by hand. You can set the folder to which the
> images get saved, and choose to make new images from e.g. Pharo 4, 3, 2,
> moose, anything on the contribution CI server, and a few others.
> 
> I really like Peter's idea to act from a startup script based on the image
> name. That sounds like a powerful combination.
> 

Oh, I didn't know that you can choose the folder where the images live. I might 
take another peek at it. But then I'm using something like that for a very long 
time.

- make a folder projects in you home directory
- in that folder create symlink to any of your smalltalk project directory that 
you are working at the moment
- drop that folder in the dock
- you click the icon on the dock, a list of projects pops up, you select one 
and you get the contents of that the directory. You click on an image and it 
starts

So I'm not sure I'll gain something but I will try again.

Norbert

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Denis Kudriashov]

2015-03-24 17:36 GMT+03:00 Thierry Goubier :

> IMHO, Rubrics, just from it's layout approach, is already a step backward.



What you mean by this? What's wrong with Rubric layouting?

[Pharo-dev] collecting Pharo 4.0 Contributors

[Esteban Lorenzano]

Hi, 

I’m collection the list of contributors for this version. 
Since we detect contributors by author stamps: 

- some times who made the commit does not reflect all the people who worked on 
a problem,
- we consider contributors to Pharo all people who has contributed in any way: 
discussing things, commenting bugs, doing videos or any kind of documentation, 
etc. 
 
the list will be incomplete, so please look for yourself on it and let me know 
if you are missing: 

also, I would like to know who are this two guys: 
- aaef
- monty

(btw… we collected so far 76 contributors… not bat at all, for a dead language 
;) )

Clara Allende
Jean Baptiste Arnaud
Philippe Back
Clement Bera
Alexandre Bergel
Torsten Bergmann
Vincent Blondeau
Noury Bouraqadi
Santiago Bragagnolo
Johan Brichau
Sven Van Caekenberghe
Damien Cassou
Nicolas Cellier
Guido Chari
Dimitris Chloupis
Andrei Chis
Ben Coman
Bernardo Contreras
Tommaso Dal Sasso
Jan Van De Sandt
Christophe Demarey
Sean DeNigris
Marcus Denker
Martin Dias
Stephane Ducasse
Stephan Eggermont
Luc Fabresse
Johan Fabry
Hilaire Fernandes
Jerome Garcia
Tudor Girba
Thierry Goubier
Kris Gybels
Norbert Hartl
Dale Henrichs
Pablo Herrero
Nicolai Hess
Pavel Krivanek
Juraj Kubelka
Jan Kurs
Laurent Laffont
Jannik Laval
Kevin Lanvin
Max Leske
David Lewis
Diego Lont
Esteban Lorenzano
Esteban Maringolo
Stefan Marr
Tim Mackinnon
Max Mattone
Martin Mc Clure
Eliot Miranda
Sean De Nigris
Alain Plantec
Guillermo Polito
Damien Pollet
Stefan Reichhart
Mark Rizun
Udo Schneider
Ignacio Sniechowski
Henrik Sperre Johansen
Igor Stasenko
Aliaksei Syrel
Ciprian Teodorov
Camille Teruel
Sebastian Tleye
Yuriy Tymchuk
Peter Uhnak
Andres Valloud
Sven Van Caekenberghe
Thomas Vincent
Martin Walk
Richard Wettel

thanks, 
Esteban

Re: [Pharo-dev] GLMBrick whats next?

[Nicolai Hess]

2015-03-24 13:54 GMT+01:00 Tudor Girba :

> Hi,
>
> I think I might have misunderstood your mail :).
>
> Tthe intention behind Brick is not to be a separate framework but an
> internal tool for GT. At least not now, and at least not before we
> investigate how we get to the end goal of having a vectorial canvas (hence
> Bloc). Is this satisfying?
>

Yes,
thank you!


>
> Cheers,
> Doru
>
>
>
> On Tue, Mar 24, 2015 at 1:44 PM, Nicolai Hess  wrote:
>
>>
>>
>> 2015-03-24 12:37 GMT+01:00 Tudor Girba :
>>
>>> Hi Nicolai,
>>>
>>> I am surprised by your conclusion that the current Brick implementation
>>> disqualifies it from being part of the Core :)
>>>
>>
>> not the implementation, the uncertainty of its purpose - a GT private
>> implementation / a public framework.
>>
>>
>>>
>>>
>>> All in all, you should see Brick as a pragmatic intermediary step
>>> towards removing Morph. I agree that it can be better (what cannot be), but
>>> I disagree we should discard GT because of it.
>>>
>>
>> I did not say "discard GT" . Brick is in  the image, but  I don't want to
>> have it in the
>> core image *as another UI-library* next to what we already have - without
>> cleaning that up.
>>
>> You know the questions on the mailing list about what framework to use
>> for creating an application:pure Morphic/Polymorph/Spec/Glamour,
>> and yes I am sure people will come and ask "hey how can I create such
>> cool looking application like spotter".
>> It is already difficult for new people to step in, and get an idea how to
>> work in pharo, or find information about the different frameworks.
>>
>> Nicolai
>>
>>
>>
>>
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Every thing has its own flow"
>>>
>>
>>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>

Re: [Pharo-dev] Update question

[Ben Coman]

On Tue, Mar 24, 2015 at 9:19 PM, Sean P. DeNigris 
wrote:

> kilon.alios wrote
> > I tried it a few times, and had nothing but problems with it. We have
> > discussed here several times and from what I have learned there several
> > technical limitation.
>
>
I don't think Kilon was referring to PhaoLauncher, but to "World > System >
Software update"
cheers -ben

I initially had a bad experience as well. I probably didn't give it a fair
> trial, but also IIRC at that time the image folder was not configurable.
> Anyway, I had a much different experience with the latest version. I keep
> it
> in "Development Mode" (available in the settings) so I have full access to
> the IDE.
>
> 
>
>
>

Re: [Pharo-dev] Update question

[Norbert Hartl]

> Am 24.03.2015 um 12:41 schrieb Serge Stinckwich :
> 
> PharoLauncher manage all your images and dl new images directly from the CI 
> server. PharoLauncher is written in Pharo and can be adapted to your own 
> needs ;-)
> 
So there is nothing to gain. My use cases are completely different. I don't 
want my images to be managen in one place. I have a lot of projects that have 
their own project folder where they live with other resources and they are 
organized in a directory structure that makes sense.
My point was preventing the installation of my stuff in a new image everytime. 
One project is a lot of stuff to load and adjust and for that I'd like to just 
update the image. So to me it appears PharoLauncher is just able to make my 
situation worse :)

Norbert



> Sent from my iPhone
> 
>> On 24 mars 2015, at 12:38, Norbert Hartl  wrote:
>> 
>> What would be better using PharoLauncher? 
>> 
>> Norbert
>> 
>>> Am 24.03.2015 um 12:30 schrieb Serge Stinckwich 
>>> :
>>> 
>>> Don't update use PharoLauncher instead ! I use PharoLauncher everyday for 
>>> my work and I download new images every 2-3 days.
>>> 
>>> Sent from my iPhone
>>> 
 On 24 mars 2015, at 11:13, Norbert Hartl  wrote:
 
 Today I wanted (again) to update my image and it can't find GT packages. 
 So I'm interested how the community deals with that. Do you take fresh 
 downloaded images regularly? Or you do not update? Is it just me?
 
 thanks,
 
 Norbert
>> 
>> 
> 

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Thierry Goubier]

2015-03-24 15:27 GMT+01:00 Alain Plantec via Pharo-dev <
pharo-dev@lists.pharo.org>:

>
>
> -- Message transféré --
> From: Alain Plantec 
> To: Pharo Development List 
> Cc:
> Date: Tue, 24 Mar 2015 15:27:18 +0100
> Subject: Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
> Hello Thierry,
>
> > Le 24 mars 2015 à 15:24, Thierry Goubier  a
> écrit :
> >
> > One of the problem is that the Morphic replacement will probably be less
> than Morphic was (or was intended to be) :(
>
> why do you think so ?
>

Because we're doing a rewrite, with no uses of the specifics of what
Morphic uses. So whatever usage of a pattern of code, or of layout or
display that was special to Morphic, will disappear: nobody will keep dead
code which only exercise a corner case of Morphic alone.

IMHO, Rubrics, just from it's layout approach, is already a step backward.

Who knows why a Morph does z-ordering of its submorphs in the reverse order
of all other gui toolkits? Has Bloc kept that? Why should it keep it? It's
messing up Spec gui building. It will be disappear.

Thierry


> Cheers
> Alain
>
> >
> > You'll probably tell me that for the kind of work we're doing in UI with
> Pharo, we don't need the power of Morphic and I'd agree with you.
> >
> > Still, I will miss the demise of Morphic.
> >
> > Thierry
>
>
>
>

Re: [Pharo-dev] Slots and MethodWrappers

[Mariano Martinez Peck]

You can try to use a special slot for the 'methodDict' instVar of Behavior
and implement another way of doing method wrappers through that slot class,
but I am sure the VM won't be happy ;)

On Tue, Mar 24, 2015 at 11:26 AM, Johan Fabry  wrote:

>
> I would say that they are different although related. Slots are for the
> interception of accessing instance variables (for read and write), and
> method wrappers for the interception of accessing methods (for execution).
>
> On Mar 24, 2015, at 09:02, p...@highoctane.be wrote:
>
> I wondered how these two things are related.
>
> Will slots be giving MWs facilities out of the box?
>
> When should I use both?
>
> Phil
>
>
>
>
> ---> Save our in-boxes! http://emailcharter.org <---
>
> Johan Fabry   -   http://pleiad.cl/~jfabry
> PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile
>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Alain Plantec via Pharo-dev]

--- Begin Message ---
Hello all,

I think you should consider what is mature and what is in the image now.
now we have Spec with Morphic, Morphic without Spec as an alternative, GT Tool 
framework (with Brick), Glamour.

Regarding text editing we have Rubric. 
My fault, someone (sorry I don’t remember who) proposed to work on its 
integration (PluggableTextMorph replacement).
As an answer, I said that I wouldn’t do it because of TxText. 
TxText is really cool but not fully integrated.
Thus, maybe it  was a mistake to not replace PluggableTextMorph with Rubric.
And now yes, as a fork of PluggableTextMorph, Rubric brings a lot of code 
duplication.
I guess we will have to live with that for a while.

Cheers
Alain



> Le 24 mars 2015 à 14:29, kilon alios  a écrit :
> 
> There is a big diffirence between Morphic and the other. Morphic is a full 
> solution and mature one as well. The others , with the exception of Bloc , 
> try to wrap things up or offering better solution to some areas. 
> 
> The one thing I don't understand is why improving Morphic or even redesigning 
> it is not even on the table. Looks to me like the least painful scenario. 
> Unless thats the intention of Bloc to be the next generation of Morphic. In 
> that case I am all for Bloc. 
> 
> I am in a dilemma myself, I am currently deep into interfacing pharo with 
> python for my project Ephestos but I will need to consider a GUI API soon. 
> Spec is out of the question since I dont like the desing and does not support 
> custom made GUIs which is what I want. Brick is as far as I understand an 
> extension to morphic and not usable. Which leaves me with 2 candidates 
> Morphic and Bloc. 
> 
> The one thing I really like about Bloc is that it is vectorial which is the 
> kind of custom GUI I want to create but it will also have to be fast and 
> since its related to Athens, Athens has proven very slow for my needs. So I 
> am considering sticking to Morphic and make the GUI pseudo vectorial using 
> bitmaps. In any case the situation is far from ideal . But I really like to 
> push something forward (preferably Bloc or a new Morphci) and I would hate it 
> if I go creating my own solution but that is a very likely scenario too. 
> 
> On Tue, Mar 24, 2015 at 2:56 PM, Esteban Lorenzano  > wrote:
> And well… I think Nicolai is right in a point (not the fault of Brick, btw): 
> current status is far from ideal: 
> 
> - we have Morphic, and it’s upcoming replace, Brick (but Brick is not in the 
> image, so the pain there is less)
> - we have Spec to support our tooling.
> - we have Glamour to support… well, our tooling too. 
> - we have now Brick, who (AFAIS) is an extension of Morphic, and a 
> replacement the Morphic Widgets and also Glamour. 
> GTTools team has explicitly declared Brick will replace Glamour (but API will 
> remain largely compatible, they say).
> GTTools team has also stated they would use Bloc is they could/when they can. 
> - We have the old Text Editor
> - We have Rubric, which was stated to be “old stuff” and deprecated
> - We have also the new TxModel which intends to replace both, Text Editor and 
> Rubric… but it cannot be used right now (or better: It cannot replace none of 
> the previous yet)
> 
> So… which one to use?
> We, the board, have something clear and some other not so clear yet, for 
> example: 
> 
> - we would like to replace Morphic with Bloc, but this is a lot of work and 
> will take a lot of time so in the mean time we also clean old Morphic as much 
> as we can (and we encourage people to do it)
> - Spec needs work too
> - Glamour will be replaced by Brick, so do not use it
> - TxModel will replace all the previous, but it needs a lor of work. In the 
> mean time, we suggest to use and improve Rubric, and of course, we would like 
> to have more people contributing to TxModel. 
> 
> So well… yes this is a mess. Yes we are aware. No we don’t know when things 
> will improve, but *they will*. 
> In the mean time as a Pharo user, I would like to know which one should I use 
> for my projects… this is my recommendation: 
> 
> - Do not use “direct” Morphic unless doing graphics
> - Use TxModel and if you cannot, Rubric
> - Use Brick or Spec, not Glamour (because Brick will replace it soon)
> 
> And of course, I would help with fixes and reports on everything :)
> 
> 
> cheers, 
> Esteban
> 
> 
> 
> 
>> On 24 Mar 2015, at 12:37, Tudor Girba > > wrote:
>> 
>> Hi Nicolai,
>> 
>> I am surprised by your conclusion that the current Brick implementation 
>> disqualifies it from being part of the Core :)
>> 
>> Let's recap.
>> 
>> Brick was created to support GT. We wanted GT in the image, hence Brick is 
>> in the image as part of Glamour. In the meantime, Brick has grown and it's 
>> now an almost standalone framework, but it is not yet advisable to use it 
>> apps because it will likely change more.
>> 
>> As Alex says, we do not want to have two compet

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Tudor Girba]

Hi,

On Tue, Mar 24, 2015 at 3:24 PM, Thierry Goubier 
wrote:

>
>
> 2015-03-24 15:16 GMT+01:00 Esteban Lorenzano :
>
>>
>> On 24 Mar 2015, at 14:29, kilon alios  wrote:
>>
>> There is a big diffirence between Morphic and the other. Morphic is a
>> full solution and mature one as well. The others , with the exception of
>> Bloc , try to wrap things up or offering better solution to some areas.
>>
>>
>> The one thing I don't understand is why improving Morphic or even
>> redesigning it is not even on the table. Looks to me like the least painful
>> scenario. Unless thats the intention of Bloc to be the next generation of
>> Morphic. In that case I am all for Bloc.
>>
>>
>> if you read my mail, you will notice that I said BOTH are on the table
>> (and we are actually moving oon both):
>> - Bloc is the redesign
>> - In the mean time we WORK and ENCOURAGE others to work on improve it.
>>
>> but Morphic it self has several fundamental flaws that cannot be fixed
>> and that’s why in the long, very long way, needs to be replaced.
>>
>
> One of the problem is that the Morphic replacement will probably be less
> than Morphic was (or was intended to be) :(
>
> You'll probably tell me that for the kind of work we're doing in UI with
> Pharo, we don't need the power of Morphic and I'd agree with you.
>
> Still, I will miss the demise of Morphic.
>

I think I do not understand this point. Why do you say that the future
solution will be less than Morphic?

Doru


>
> Thierry
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Alain Plantec via Pharo-dev]

--- Begin Message ---
Hello Thierry,

> Le 24 mars 2015 à 15:24, Thierry Goubier  a écrit :
> 
> One of the problem is that the Morphic replacement will probably be less than 
> Morphic was (or was intended to be) :(

why do you think so ?

Cheers
Alain

> 
> You'll probably tell me that for the kind of work we're doing in UI with 
> Pharo, we don't need the power of Morphic and I'd agree with you.
> 
> Still, I will miss the demise of Morphic.
> 
> Thierry


--- End Message ---

Re: [Pharo-dev] Slots and MethodWrappers

[Johan Fabry]

I would say that they are different although related. Slots are for the 
interception of accessing instance variables (for read and write), and method 
wrappers for the interception of accessing methods (for execution).

> On Mar 24, 2015, at 09:02, p...@highoctane.be wrote:
> 
> I wondered how these two things are related.
> 
> Will slots be giving MWs facilities out of the box?
> 
> When should I use both?
> 
> Phil
> 



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Alain Plantec via Pharo-dev]

--- Begin Message ---
Hello Esteban,

> Most probably is because you are doing double work: you draw with Athens, but 
> you convert it to a Form to display it (and a Form is a Morph using 
> DisplayPlugin). 
> I can ensure you that if you use Athens directly with SDL2 (an example I can 
> share with you anytime) it is orders of magnitude faster… 

please share :)
I would like to learn how to use SDL2.
Thanks

Cheers
Alain


> 
> Esteban
> 


--- End Message ---

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Thierry Goubier]

2015-03-24 15:16 GMT+01:00 Esteban Lorenzano :

>
> On 24 Mar 2015, at 14:29, kilon alios  wrote:
>
> There is a big diffirence between Morphic and the other. Morphic is a full
> solution and mature one as well. The others , with the exception of Bloc ,
> try to wrap things up or offering better solution to some areas.
>
>
> The one thing I don't understand is why improving Morphic or even
> redesigning it is not even on the table. Looks to me like the least painful
> scenario. Unless thats the intention of Bloc to be the next generation of
> Morphic. In that case I am all for Bloc.
>
>
> if you read my mail, you will notice that I said BOTH are on the table
> (and we are actually moving oon both):
> - Bloc is the redesign
> - In the mean time we WORK and ENCOURAGE others to work on improve it.
>
> but Morphic it self has several fundamental flaws that cannot be fixed and
> that's why in the long, very long way, needs to be replaced.
>

One of the problem is that the Morphic replacement will probably be less
than Morphic was (or was intended to be) :(

You'll probably tell me that for the kind of work we're doing in UI with
Pharo, we don't need the power of Morphic and I'd agree with you.

Still, I will miss the demise of Morphic.

Thierry

[Pharo-dev] Some Memory Leak

[Sven Van Caekenberghe]

Hi,

There seems to be some kind of memory leak in recent Pharo 4.0 images. Image 
size (as saved on disk) seems to be growing very rapidly under normal use 
(development with Nautilus, Spotter, GTPlayground, GTInspector and Monticello, 
debugging). Numbers go from the initial 20Mb to 100s of Mb and they seem to 
increase constantly, over a period of days.

One way to look at memory use is with

  SpaceTally printSpaceAnalysis

but that takes a while.

Please help us find and fix this issue.

Thanks,

Sven

Re: [Pharo-dev] GLMBrick whats next?

[Alain Plantec via Pharo-dev]

--- Begin Message ---
Hello Sean,

As I’ve already said, I’m currently working on a documentation on Bloc.
I’ve stopped adding new things into it (well only examples and bug fixes)

It is far from being finished and polished 
https://github.com/SquareBracketAssociates/PharoInProgress/tree/master/Bloc 

have a look at BlocCore.pillar

please, be patient, I can’t work full time on it, unfortunately

Cheers
Alain

> Le 24 mars 2015 à 14:41, Sean P. DeNigris  a écrit :
> 
> Tudor Girba-2 wrote
>> Concretely, on March 31 and April 1 (no joke :)), we have a session in
>> Bern
>> where Alain Plantec will join us to look into how to approach this problem
>> concretely.
> 
> Given that, now I /really/ feel it would be beneficial to have the talks
> recorded because otherwise you increase your work exponentially by excluding
> the bulk of the community from the conversation. You will have to try and
> convey all the decisions and rationales over what... the lists? AFAICT many
> Morphic replacements have failed primarily due to lack of community buy in.
> Let's finally break that trend!
> 
> 
> 
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/GLMBrick-whats-next-tp4797474p4814769.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> 

--- End Message ---

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Esteban Lorenzano]

> On 24 Mar 2015, at 14:29, kilon alios  wrote:
> 
> There is a big diffirence between Morphic and the other. Morphic is a full 
> solution and mature one as well. The others , with the exception of Bloc , 
> try to wrap things up or offering better solution to some areas. 
> 
> The one thing I don't understand is why improving Morphic or even redesigning 
> it is not even on the table. Looks to me like the least painful scenario. 
> Unless thats the intention of Bloc to be the next generation of Morphic. In 
> that case I am all for Bloc. 

if you read my mail, you will notice that I said BOTH are on the table (and we 
are actually moving oon both): 
- Bloc is the redesign
- In the mean time we WORK and ENCOURAGE others to work on improve it.

but Morphic it self has several fundamental flaws that cannot be fixed and 
that’s why in the long, very long way, needs to be replaced.  

> 
> I am in a dilemma myself, I am currently deep into interfacing pharo with 
> python for my project Ephestos but I will need to consider a GUI API soon. 
> Spec is out of the question since I dont like the desing and does not support 
> custom made GUIs which is what I want. Brick is as far as I understand an 
> extension to morphic and not usable. Which leaves me with 2 candidates 
> Morphic and Bloc. 

Glamour is very mature and I’ve used it serval times… and in theory Brick will 
be compatible with Glamour (mostly) so even if developers deprecate one for the 
other you will be able to use your code (mostly). 

> 
> The one thing I really like about Bloc is that it is vectorial which is the 
> kind of custom GUI I want to create but it will also have to be fast and 
> since its related to Athens, Athens has proven very slow for my needs. So I 
> am considering sticking to Morphic and make the GUI pseudo vectorial using 
> bitmaps. In any case the situation is far from ideal . But I really like to 
> push something forward (preferably Bloc or a new Morphci) and I would hate it 
> if I go creating my own solution but that is a very likely scenario too. 

First, Athens is not a replace for Morphic, is a replace for the canvas in 
which morphs are drawn. So is not Morphic or Athens… is "Morph using 
DisplayPlugin" or "Morphic using Athens". 
But anyway, how can Athens be so slow? Why? Can you share some info? 
Most probably is because you are doing double work: you draw with Athens, but 
you convert it to a Form to display it (and a Form is a Morph using 
DisplayPlugin). 
I can ensure you that if you use Athens directly with SDL2 (an example I can 
share with you anytime) it is orders of magnitude faster… 

Esteban

> 
> On Tue, Mar 24, 2015 at 2:56 PM, Esteban Lorenzano  > wrote:
> And well… I think Nicolai is right in a point (not the fault of Brick, btw): 
> current status is far from ideal: 
> 
> - we have Morphic, and it’s upcoming replace, Brick (but Brick is not in the 
> image, so the pain there is less)
> - we have Spec to support our tooling.
> - we have Glamour to support… well, our tooling too. 
> - we have now Brick, who (AFAIS) is an extension of Morphic, and a 
> replacement the Morphic Widgets and also Glamour. 
> GTTools team has explicitly declared Brick will replace Glamour (but API will 
> remain largely compatible, they say).
> GTTools team has also stated they would use Bloc is they could/when they can. 
> - We have the old Text Editor
> - We have Rubric, which was stated to be “old stuff” and deprecated
> - We have also the new TxModel which intends to replace both, Text Editor and 
> Rubric… but it cannot be used right now (or better: It cannot replace none of 
> the previous yet)
> 
> So… which one to use?
> We, the board, have something clear and some other not so clear yet, for 
> example: 
> 
> - we would like to replace Morphic with Bloc, but this is a lot of work and 
> will take a lot of time so in the mean time we also clean old Morphic as much 
> as we can (and we encourage people to do it)
> - Spec needs work too
> - Glamour will be replaced by Brick, so do not use it
> - TxModel will replace all the previous, but it needs a lor of work. In the 
> mean time, we suggest to use and improve Rubric, and of course, we would like 
> to have more people contributing to TxModel. 
> 
> So well… yes this is a mess. Yes we are aware. No we don’t know when things 
> will improve, but *they will*. 
> In the mean time as a Pharo user, I would like to know which one should I use 
> for my projects… this is my recommendation: 
> 
> - Do not use “direct” Morphic unless doing graphics
> - Use TxModel and if you cannot, Rubric
> - Use Brick or Spec, not Glamour (because Brick will replace it soon)
> 
> And of course, I would help with fixes and reports on everything :)
> 
> 
> cheers, 
> Esteban
> 
> 
> 
> 
>> On 24 Mar 2015, at 12:37, Tudor Girba > > wrote:
>> 
>> Hi Nicolai,
>> 
>> I am surprised by your conclusion that the current Brick implementation 

Re: [Pharo-dev] GLMBrick whats next?

[Tudor Girba]

There is only one talk about Bloc. The rest is like a sprint.

Doru

On Tue, Mar 24, 2015 at 2:41 PM, Sean P. DeNigris 
wrote:

> Tudor Girba-2 wrote
> > Concretely, on March 31 and April 1 (no joke :)), we have a session in
> > Bern
> > where Alain Plantec will join us to look into how to approach this
> problem
> > concretely.
>
> Given that, now I /really/ feel it would be beneficial to have the talks
> recorded because otherwise you increase your work exponentially by
> excluding
> the bulk of the community from the conversation. You will have to try and
> convey all the decisions and rationales over what... the lists? AFAICT many
> Morphic replacements have failed primarily due to lack of community buy in.
> Let's finally break that trend!
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/GLMBrick-whats-next-tp4797474p4814769.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] GLMBrick whats next?

[Sean P. DeNigris]

Tudor Girba-2 wrote
> Concretely, on March 31 and April 1 (no joke :)), we have a session in
> Bern
> where Alain Plantec will join us to look into how to approach this problem
> concretely.

Given that, now I /really/ feel it would be beneficial to have the talks
recorded because otherwise you increase your work exponentially by excluding
the bulk of the community from the conversation. You will have to try and
convey all the decisions and rationales over what... the lists? AFAICT many
Morphic replacements have failed primarily due to lack of community buy in.
Let's finally break that trend!



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

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[kilon alios]

There is a big diffirence between Morphic and the other. Morphic is a full
solution and mature one as well. The others , with the exception of Bloc ,
try to wrap things up or offering better solution to some areas.

The one thing I don't understand is why improving Morphic or even
redesigning it is not even on the table. Looks to me like the least painful
scenario. Unless thats the intention of Bloc to be the next generation of
Morphic. In that case I am all for Bloc.

I am in a dilemma myself, I am currently deep into interfacing pharo with
python for my project Ephestos but I will need to consider a GUI API soon.
Spec is out of the question since I dont like the desing and does not
support custom made GUIs which is what I want. Brick is as far as I
understand an extension to morphic and not usable. Which leaves me with 2
candidates Morphic and Bloc.

The one thing I really like about Bloc is that it is vectorial which is the
kind of custom GUI I want to create but it will also have to be fast and
since its related to Athens, Athens has proven very slow for my needs. So I
am considering sticking to Morphic and make the GUI pseudo vectorial using
bitmaps. In any case the situation is far from ideal . But I really like to
push something forward (preferably Bloc or a new Morphci) and I would hate
it if I go creating my own solution but that is a very likely scenario too.

On Tue, Mar 24, 2015 at 2:56 PM, Esteban Lorenzano 
wrote:

> And well… I think Nicolai is right in a point (not the fault of Brick,
> btw): current status is far from ideal:
>
> - we have Morphic, and it’s upcoming replace, Brick (but Brick is not in
> the image, so the pain there is less)
> - we have Spec to support our tooling.
> - we have Glamour to support… well, our tooling too.
> - we have now Brick, who (AFAIS) is an extension of Morphic, and a
> replacement the Morphic Widgets and also Glamour.
> GTTools team has explicitly declared Brick will replace Glamour (but API
> will remain largely compatible, they say).
> GTTools team has also stated they would use Bloc is they could/when they
> can.
> - We have the old Text Editor
> - We have Rubric, which was stated to be “old stuff” and deprecated
> - We have also the new TxModel which intends to replace both, Text Editor
> and Rubric… but it cannot be used right now (or better: It cannot replace
> none of the previous yet)
>
> So… which one to use?
> We, the board, have something clear and some other not so clear yet, for
> example:
>
> - we would like to replace Morphic with Bloc, but this is a lot of work
> and will take a lot of time so in the mean time we also clean old Morphic
> as much as we can (and we encourage people to do it)
> - Spec needs work too
> - Glamour will be replaced by Brick, so do not use it
> - TxModel will replace all the previous, but it needs a lor of work. In
> the mean time, we suggest to use and improve Rubric, and of course, we
> would like to have more people contributing to TxModel.
>
> So well… yes this is a mess. Yes we are aware. No we don’t know when
> things will improve, but *they will*.
> In the mean time as a Pharo user, I would like to know which one should I
> use for my projects… this is my recommendation:
>
> - Do not use “direct” Morphic unless doing graphics
> - Use TxModel and if you cannot, Rubric
> - Use Brick or Spec, not Glamour (because Brick will replace it soon)
>
> And of course, I would help with fixes and reports on everything :)
>
>
> cheers,
> Esteban
>
>
>
>
> On 24 Mar 2015, at 12:37, Tudor Girba  wrote:
>
> Hi Nicolai,
>
> I am surprised by your conclusion that the current Brick implementation
> disqualifies it from being part of the Core :)
>
> Let's recap.
>
> Brick was created to support GT. We wanted GT in the image, hence Brick is
> in the image as part of Glamour. In the meantime, Brick has grown and it's
> now an almost standalone framework, but it is not yet advisable to use it
> apps because it will likely change more.
>
> As Alex says, we do not want to have two competing new projects running in
> parallel (Brick and Bloc) and fragmenting the effort even more. That is
> why, for Pharo 5 we want to invest in Bloc. The interesting thing is that
> while Bloc starts from scratch, Brick already works and has quite some high
> level widgets and logic built in. Brick is already going in the same
> direction expected by Bloc, so we will likely have the opportunity of
> moving Brick on top of Bloc (Alex already did an experiment in this
> direction).
>
> Concretely, on March 31 and April 1 (no joke :)), we have a session in
> Bern where Alain Plantec will join us to look into how to approach this
> problem concretely.
>
> All in all, you should see Brick as a pragmatic intermediary step towards
> removing Morph. I agree that it can be better (what cannot be), but I
> disagree we should discard GT because of it.
>
> Cheers,
> Doru
>
>
> On Tue, Mar 24, 2015 at 12:06 PM, Nicolai Hess  wrote:
>
>>
>>
>> 2015-03-23 20:54 GMT+0

Re: [Pharo-dev] Update question

[Sean P. DeNigris]

kilon.alios wrote
> I tried it a few times, and had nothing but problems with it. We have
> discussed here several times and from what I have learned there several
> technical limitation.

I initially had a bad experience as well. I probably didn't give it a fair
trial, but also IIRC at that time the image folder was not configurable.
Anyway, I had a much different experience with the latest version. I keep it
in "Development Mode" (available in the settings) so I have full access to
the IDE.

 



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

[Pharo-dev] Google Code Shutdown

[Sean P. DeNigris]

In case anyone hasn't heard, Google Code will shut down entirely on January
25, 2016. I was following these Smalltalk projects there:
magritte-metamodel
moose-technology
seaside
marsonpharo
nativeboost
metacello
squeaksource3
phratch - already on GitHub per Jannik

The easiest action seems to be to export to GitHub, for which Google Code
even provides a button! I just used it for one of my projects and it was
pretty painless.

- Sean

Cross-posted to ESUG, pharo-dev, squeak-dev, seaside-dev, magritte,
metacello



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

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Esteban Lorenzano]

> On 24 Mar 2015, at 14:23, Thierry Goubier  wrote:
> 
> Hi Esteban,
> 
> 2015-03-24 13:56 GMT+01:00 Esteban Lorenzano  >:
> And well… I think Nicolai is right in a point (not the fault of Brick, btw): 
> current status is far from ideal: 
> 
> - we have Morphic, and it’s upcoming replace, Brick (but Brick is not in the 
> image, so the pain there is less)
> 
> I suspect you mean Bloc, not Brick there, no? Now I'm lost ;)

oops! yes, Bloc :P

> 
> Thierry

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Thierry Goubier]

Hi Esteban,

2015-03-24 13:56 GMT+01:00 Esteban Lorenzano :

> And well... I think Nicolai is right in a point (not the fault of Brick,
> btw): current status is far from ideal:
>
> - we have Morphic, and it's upcoming replace, Brick (but Brick is not in
> the image, so the pain there is less)
>

I suspect you mean Bloc, not Brick there, no? Now I'm lost ;)

Thierry

Re: [Pharo-dev] Update question

[Torsten Bergmann]

@Norbert:
  I also use PharoLauncher, this way I can download clean 3.0/4.0 or 
prepackaged (Moose, Boostrap) images at own will, 
  clone, copy as I like and with a fresh image it is easy to see if code is 
loading cleanly, ...

  I have to give up nothing. I can still profit from image development as I can 
save my image as usual and 
  continue with it later.


@Kilon:
  Integrating PharoLauncher in the standard image would not make sense. Then I 
use PharoLauncher to download
  an image with a prepackaged PharoLauncher, ...
  
  If you mean that it should be the default tool to download when getting Pharo 
4.0 or Pharo 3.0 from the 
  download page or from zeroconf then I would agree. Maybe some more help is 
needed for Pharo newbees then. 

  But I would vote for it as I would download/install Pharo one time on a 
machine and then choose - download - start
  the image that I like.
 

Gesendet: Dienstag, 24. März 2015 um 11:25 Uhr
Von: "kilon alios" 
An: "Pharo Development List" 
Betreff: Re: [Pharo-dev] Update question

I tried it a few times, and had nothing but problems with it. We have discussed 
here several times and from what I have learned there several technical 
limitation.
 I am using pharolauncher non stop and wonder why Pharolauncher is not 
integrated inside Pharo yet. I have added my code inside the configuration 
browser (Ephestos, Nireas) and Installing my code back in a fresh image is just 
a two click process.
 
On Tue, Mar 24, 2015 at 12:13 PM, Norbert Hartl  
wrote:Today I wanted (again) to update my image and it can't find GT packages. 
So I'm interested how the community deals with that. Do you take fresh 
downloaded images regularly? Or you do not update? Is it just me?

thanks,

Norbert

 

[Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

[Esteban Lorenzano]

And well… I think Nicolai is right in a point (not the fault of Brick, btw): 
current status is far from ideal: 

- we have Morphic, and it’s upcoming replace, Brick (but Brick is not in the 
image, so the pain there is less)
- we have Spec to support our tooling.
- we have Glamour to support… well, our tooling too. 
- we have now Brick, who (AFAIS) is an extension of Morphic, and a replacement 
the Morphic Widgets and also Glamour. 
GTTools team has explicitly declared Brick will replace Glamour (but API will 
remain largely compatible, they say).
GTTools team has also stated they would use Bloc is they could/when they can. 
- We have the old Text Editor
- We have Rubric, which was stated to be “old stuff” and deprecated
- We have also the new TxModel which intends to replace both, Text Editor and 
Rubric… but it cannot be used right now (or better: It cannot replace none of 
the previous yet)

So… which one to use?
We, the board, have something clear and some other not so clear yet, for 
example: 

- we would like to replace Morphic with Bloc, but this is a lot of work and 
will take a lot of time so in the mean time we also clean old Morphic as much 
as we can (and we encourage people to do it)
- Spec needs work too
- Glamour will be replaced by Brick, so do not use it
- TxModel will replace all the previous, but it needs a lor of work. In the 
mean time, we suggest to use and improve Rubric, and of course, we would like 
to have more people contributing to TxModel. 

So well… yes this is a mess. Yes we are aware. No we don’t know when things 
will improve, but *they will*. 
In the mean time as a Pharo user, I would like to know which one should I use 
for my projects… this is my recommendation: 

- Do not use “direct” Morphic unless doing graphics
- Use TxModel and if you cannot, Rubric
- Use Brick or Spec, not Glamour (because Brick will replace it soon)

And of course, I would help with fixes and reports on everything :)


cheers, 
Esteban




> On 24 Mar 2015, at 12:37, Tudor Girba  wrote:
> 
> Hi Nicolai,
> 
> I am surprised by your conclusion that the current Brick implementation 
> disqualifies it from being part of the Core :)
> 
> Let's recap.
> 
> Brick was created to support GT. We wanted GT in the image, hence Brick is in 
> the image as part of Glamour. In the meantime, Brick has grown and it's now 
> an almost standalone framework, but it is not yet advisable to use it apps 
> because it will likely change more.
> 
> As Alex says, we do not want to have two competing new projects running in 
> parallel (Brick and Bloc) and fragmenting the effort even more. That is why, 
> for Pharo 5 we want to invest in Bloc. The interesting thing is that while 
> Bloc starts from scratch, Brick already works and has quite some high level 
> widgets and logic built in. Brick is already going in the same direction 
> expected by Bloc, so we will likely have the opportunity of moving Brick on 
> top of Bloc (Alex already did an experiment in this direction).
> 
> Concretely, on March 31 and April 1 (no joke :)), we have a session in Bern 
> where Alain Plantec will join us to look into how to approach this problem 
> concretely.
> 
> All in all, you should see Brick as a pragmatic intermediary step towards 
> removing Morph. I agree that it can be better (what cannot be), but I 
> disagree we should discard GT because of it.
> 
> Cheers,
> Doru
> 
> 
> On Tue, Mar 24, 2015 at 12:06 PM, Nicolai Hess  > wrote:
> 
> 
> 2015-03-23 20:54 GMT+01:00 Aliaksei Syrel  >:
> Hi,
> 
> Sorry if my reply will be too long, but I tried to summarise our experience 
> with Morphic/Brick and give some useful feedback or even provide ideas. Who 
> wants will read :)
> 
> Hi, 
> thank you, this is a really great source of information, and it would be 
> heplful
> to have this kind of write up somewhere else (not in the mailinglist).
> But I did not question why we may need brick or why it is done.
> My question was, what are the feature plans, is it just an experiment that
> can vanish, so it is better to not use it for the core tools. Or is it meant 
> to be
> THE new framework we should gain our focus on. 
>  
> 
> Brick is not a thin layer anymore.
> It depends on what you mean under 'a thin layer' ;) Anyway, Brick was born 
> out of need. Spotter is completely built using Brick and Rubric.
> 
> This is something I don't understand. As we integrated GT-Tools into the 
> image, Rubric
> slipped in as it is need by GT. I asked what is the background, what are the 
> feature plans
> and complained about the undocumented core classes, that makes it difficult 
> to see
> what changed compared to the old text classes. Alain said he doesn't plan to 
> do further
> work on Rubric. 
> So, WHY don't we replace and migrate the existing classes now and clean it 
> up. It takes so
> much resources to maintain both. Every theme change, every change on 
> shortcuts/menus/keymapping, th

Re: [Pharo-dev] GLMBrick whats next?

[Tudor Girba]

Hi,

I think I might have misunderstood your mail :).

Tthe intention behind Brick is not to be a separate framework but an
internal tool for GT. At least not now, and at least not before we
investigate how we get to the end goal of having a vectorial canvas (hence
Bloc). Is this satisfying?

Cheers,
Doru



On Tue, Mar 24, 2015 at 1:44 PM, Nicolai Hess  wrote:

>
>
> 2015-03-24 12:37 GMT+01:00 Tudor Girba :
>
>> Hi Nicolai,
>>
>> I am surprised by your conclusion that the current Brick implementation
>> disqualifies it from being part of the Core :)
>>
>
> not the implementation, the uncertainty of its purpose - a GT private
> implementation / a public framework.
>
>
>>
>>
>> All in all, you should see Brick as a pragmatic intermediary step towards
>> removing Morph. I agree that it can be better (what cannot be), but I
>> disagree we should discard GT because of it.
>>
>
> I did not say "discard GT" . Brick is in  the image, but  I don't want to
> have it in the
> core image *as another UI-library* next to what we already have - without
> cleaning that up.
>
> You know the questions on the mailing list about what framework to use for
> creating an application:pure Morphic/Polymorph/Spec/Glamour,
> and yes I am sure people will come and ask "hey how can I create such cool
> looking application like spotter".
> It is already difficult for new people to step in, and get an idea how to
> work in pharo, or find information about the different frameworks.
>
> Nicolai
>
>
>
>
>>
>> Cheers,
>> Doru
>>
>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

[Pharo-dev] String>>howManyMatch: Bug or feature ?

[Noury Bouraqadi]

Hi,

The normal behavior
'abc' howManyMatch: 'abd' --> 2.

I got suprized the way Blanks and new lines are handled.

'\**' withCRs howManyMatch: '\\**' withCRs. --> 2 instead of 1

'ab\ **' withCRs howManyMatch: 'ab\\**' withCRs. --> 4 instead of 3

'\ **' withCRs howManyMatch: '\\**' withCRs. --> 3 instead of 1

'ab\ **' withCRs howManyMatch: 'ab\\**' withCRs. --> 5 instead of 3

The behavior is the same in both Pharo 3 and Pharo 4.

Reading the code of does not help me understand why it's this way

String>>howManyMatch: string 
"Count the number of characters that match up in self and aString."
| count shorterLength |

count := 0.
shorterLength := self size min: string size.
1 to: shorterLength do: [:index |
(self at: index) = (string at: index )
ifTrue: [ count := count + 1 ]].
^  count 


Noury

Afin de contribuer au respect de l'environnement,
merci de n'imprimer ce courriel qu'en cas de necessite

Please consider the environment before you print

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 79e66b: 40580

[GitHub]

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

  Changed paths:
R 
Athens-Balloon.package/AthensBalloonSurface.class/instance/paints/createLinearGradient_origin_corner_.st
R 
Athens-Cairo.package/AthensCairoSurface.class/instance/paints/createLinearGradient_origin_corner_.st
R 
Athens-Core.package/AthensSurface.class/instance/paints/createLinearGradient_origin_corner_.st
R Athens-Examples.package/VGTigerDemo.class/class/as yet 
unclassified/checkDataSizes.st
R Athens-Examples.package/VGTigerDemo.class/class/as yet 
unclassified/commands.st
R Athens-Examples.package/VGTigerDemo.class/class/as yet 
unclassified/runDemo.st
R Athens-Examples.package/VGTigerDemo.class/class/as yet 
unclassified/tigerCommandCount.st
R Athens-Examples.package/VGTigerDemo.class/class/as yet 
unclassified/tigerMaxX.st
R Athens-Examples.package/VGTigerDemo.class/class/as yet 
unclassified/tigerMaxY.st
R Athens-Examples.package/VGTigerDemo.class/class/as yet 
unclassified/tigerMinX.st
R Athens-Examples.package/VGTigerDemo.class/class/as yet 
unclassified/tigerMinY.st
R Athens-Examples.package/VGTigerDemo.class/class/as yet 
unclassified/tigerPointsCount.st
A Athens-Examples.package/VGTigerDemo.class/class/private/checkDataSizes.st
A Athens-Examples.package/VGTigerDemo.class/class/private/commands.st
A 
Athens-Examples.package/VGTigerDemo.class/class/private/tigerCommandCount.st
A Athens-Examples.package/VGTigerDemo.class/class/private/tigerMaxX.st
A Athens-Examples.package/VGTigerDemo.class/class/private/tigerMaxY.st
A Athens-Examples.package/VGTigerDemo.class/class/private/tigerMinX.st
A Athens-Examples.package/VGTigerDemo.class/class/private/tigerMinY.st
A 
Athens-Examples.package/VGTigerDemo.class/class/private/tigerPointsCount.st
A Athens-Examples.package/VGTigerDemo.class/class/run/runDemo.st
R Athens-Examples.package/VGTigerDemo.class/instance/as yet 
unclassified/convertPathData2.st
R Athens-Examples.package/VGTigerDemo.class/instance/as yet 
unclassified/initialize.st
R Athens-Examples.package/VGTigerDemo.class/instance/as yet 
unclassified/runDemo.st
A 
Athens-Examples.package/VGTigerDemo.class/instance/conversion/convertPathData2.st
A 
Athens-Examples.package/VGTigerDemo.class/instance/initialization/initialize.st
A Athens-Examples.package/VGTigerDemo.class/instance/run/runDemo.st
M 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/symbolic 
versions/stable_.st
A 
ConfigurationOfAthens.package/ConfigurationOfAthens.class/instance/versions/version31_.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script579.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script580.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40579.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40580.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  40580
15210 load new configuration of Athens 3.1
https://pharo.fogbugz.com/f/cases/15210

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

Re: [Pharo-dev] GLMBrick whats next?

[Nicolai Hess]

2015-03-24 12:37 GMT+01:00 Tudor Girba :

> Hi Nicolai,
>
> I am surprised by your conclusion that the current Brick implementation
> disqualifies it from being part of the Core :)
>

not the implementation, the uncertainty of its purpose - a GT private
implementation / a public framework.


>
>
> All in all, you should see Brick as a pragmatic intermediary step towards
> removing Morph. I agree that it can be better (what cannot be), but I
> disagree we should discard GT because of it.
>

I did not say "discard GT" . Brick is in  the image, but  I don't want to
have it in the
core image *as another UI-library* next to what we already have - without
cleaning that up.

You know the questions on the mailing list about what framework to use for
creating an application:pure Morphic/Polymorph/Spec/Glamour,
and yes I am sure people will come and ask "hey how can I create such cool
looking application like spotter".
It is already difficult for new people to step in, and get an idea how to
work in pharo, or find information about the different frameworks.

Nicolai




>
> Cheers,
> Doru
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>

Re: [Pharo-dev] GLMBrick whats next?

[Esteban Lorenzano]

> On 24 Mar 2015, at 12:37, Tudor Girba  wrote:
> 
> Hi Nicolai,
> 
> I am surprised by your conclusion that the current Brick implementation 
> disqualifies it from being part of the Core :)

it was not that what disqualifies it. It is the “we will not announce it” part 
:)
I mean: if it is not a separated framework then is not appropriate to use it 
for other stuff outside its intended purpose (doing GTTools).

Esteban 

> 
> Let's recap.
> 
> Brick was created to support GT. We wanted GT in the image, hence Brick is in 
> the image as part of Glamour. In the meantime, Brick has grown and it's now 
> an almost standalone framework, but it is not yet advisable to use it apps 
> because it will likely change more.
> 
> As Alex says, we do not want to have two competing new projects running in 
> parallel (Brick and Bloc) and fragmenting the effort even more. That is why, 
> for Pharo 5 we want to invest in Bloc. The interesting thing is that while 
> Bloc starts from scratch, Brick already works and has quite some high level 
> widgets and logic built in. Brick is already going in the same direction 
> expected by Bloc, so we will likely have the opportunity of moving Brick on 
> top of Bloc (Alex already did an experiment in this direction).
> 
> Concretely, on March 31 and April 1 (no joke :)), we have a session in Bern 
> where Alain Plantec will join us to look into how to approach this problem 
> concretely.
> 
> All in all, you should see Brick as a pragmatic intermediary step towards 
> removing Morph. I agree that it can be better (what cannot be), but I 
> disagree we should discard GT because of it.
> 
> Cheers,
> Doru
> 
> 
> On Tue, Mar 24, 2015 at 12:06 PM, Nicolai Hess  > wrote:
> 
> 
> 2015-03-23 20:54 GMT+01:00 Aliaksei Syrel  >:
> Hi,
> 
> Sorry if my reply will be too long, but I tried to summarise our experience 
> with Morphic/Brick and give some useful feedback or even provide ideas. Who 
> wants will read :)
> 
> Hi, 
> thank you, this is a really great source of information, and it would be 
> heplful
> to have this kind of write up somewhere else (not in the mailinglist).
> But I did not question why we may need brick or why it is done.
> My question was, what are the feature plans, is it just an experiment that
> can vanish, so it is better to not use it for the core tools. Or is it meant 
> to be
> THE new framework we should gain our focus on. 
>  
> 
> Brick is not a thin layer anymore.
> It depends on what you mean under 'a thin layer' ;) Anyway, Brick was born 
> out of need. Spotter is completely built using Brick and Rubric.
> 
> This is something I don't understand. As we integrated GT-Tools into the 
> image, Rubric
> slipped in as it is need by GT. I asked what is the background, what are the 
> feature plans
> and complained about the undocumented core classes, that makes it difficult 
> to see
> what changed compared to the old text classes. Alain said he doesn't plan to 
> do further
> work on Rubric. 
> So, WHY don't we replace and migrate the existing classes now and clean it 
> up. It takes so
> much resources to maintain both. Every theme change, every change on 
> shortcuts/menus/keymapping, the athens drawing, all has to be double checked 
> - It is so exhausting.
> 
>  
> No morphs are used at all (except Rubric of course).
> 
> Well, all Bricks ARE morphs, they share the same state and api.
>  
> All Bricks in Spotter in the end are subclasses of GLMBrick, which uses from 
> original Morph only Canvas (without drawing) and MorphicEvents.
> 
> If so, the clean/better way would be to extract those part into a 
> "ProtoMorph" or a "PlainMorph".
> and subclass from that once for Brick and again for Morphs.
> Now we have Bricks, that are looking like a Morph, but aren't used to be one, 
> and probable doesn't even work if they are used as Morphs.
> (Sure this is true for other Morphsubclasses as well, but that does not means 
> it doesn't hurt if we do more of this).
>  
> Everything else was rewritten from scratch. During some period of time Brick 
> was able to render itself on Athens canvas, but we dropped it because of Font 
> issues in athens.
> There are even more issues for Athens, and they don't vanish magically. There 
> are some issues
> on fogbugz just waiting for some feedback, preferable from people intending 
> to use Athens.
>  
> Spotter is not the only tool written using Brick, GLMPager - a pane pager in 
> GT-Inspector, GT-Playground and GT-Debugger is also completely done using 
> Brick. Almost all tab labels and tab selector in GT tools are Bricks.
> 
> 
> ...
>  
> 
> We really would like to move all tools to Bloc as soon as possible, but we 
> just need something right now that works and can be used in current version.
> 
> But wyh not waiting on Bloc or (even better) help finishing Bloc. Why it is 
> needed to push
> this into the release.
>  
>  I think we will never (but who knows) ann

Re: [Pharo-dev] Update question

[Sean P. DeNigris]

NorbertHartl wrote
> What would be better using PharoLauncher? 

I was a hold out, but I've finally started using it and it's really nice.
For things that don't have an automated build process, it's much better than
downloading from file.pharo.org by hand. You can set the folder to which the
images get saved, and choose to make new images from e.g. Pharo 4, 3, 2,
moose, anything on the contribution CI server, and a few others.

I really like Peter's idea to act from a startup script based on the image
name. That sounds like a powerful combination.



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

[Pharo-dev] Slots and MethodWrappers

[p...@highoctane.be]

I wondered how these two things are related.

Will slots be giving MWs facilities out of the box?

When should I use both?

Phil

Re: [Pharo-dev] Update question

[Serge Stinckwich]

PharoLauncher manage all your images and dl new images directly from the CI 
server. PharoLauncher is written in Pharo and can be adapted to your own needs 
;-)

Sent from my iPhone

> On 24 mars 2015, at 12:38, Norbert Hartl  wrote:
> 
> What would be better using PharoLauncher? 
> 
> Norbert
> 
>> Am 24.03.2015 um 12:30 schrieb Serge Stinckwich :
>> 
>> Don't update use PharoLauncher instead ! I use PharoLauncher everyday for my 
>> work and I download new images every 2-3 days.
>> 
>> Sent from my iPhone
>> 
>>> On 24 mars 2015, at 11:13, Norbert Hartl  wrote:
>>> 
>>> Today I wanted (again) to update my image and it can't find GT packages. So 
>>> I'm interested how the community deals with that. Do you take fresh 
>>> downloaded images regularly? Or you do not update? Is it just me?
>>> 
>>> thanks,
>>> 
>>> Norbert
> 
> 

Re: [Pharo-dev] Update question

[Norbert Hartl]

What would be better using PharoLauncher? 

Norbert

> Am 24.03.2015 um 12:30 schrieb Serge Stinckwich :
> 
> Don't update use PharoLauncher instead ! I use PharoLauncher everyday for my 
> work and I download new images every 2-3 days.
> 
> Sent from my iPhone
> 
>> On 24 mars 2015, at 11:13, Norbert Hartl  wrote:
>> 
>> Today I wanted (again) to update my image and it can't find GT packages. So 
>> I'm interested how the community deals with that. Do you take fresh 
>> downloaded images regularly? Or you do not update? Is it just me?
>> 
>> thanks,
>> 
>> Norbert
>> 
>> 
> 

Re: [Pharo-dev] GLMBrick whats next?

[Tudor Girba]

Hi Nicolai,

I am surprised by your conclusion that the current Brick implementation
disqualifies it from being part of the Core :)

Let's recap.

Brick was created to support GT. We wanted GT in the image, hence Brick is
in the image as part of Glamour. In the meantime, Brick has grown and it's
now an almost standalone framework, but it is not yet advisable to use it
apps because it will likely change more.

As Alex says, we do not want to have two competing new projects running in
parallel (Brick and Bloc) and fragmenting the effort even more. That is
why, for Pharo 5 we want to invest in Bloc. The interesting thing is that
while Bloc starts from scratch, Brick already works and has quite some high
level widgets and logic built in. Brick is already going in the same
direction expected by Bloc, so we will likely have the opportunity of
moving Brick on top of Bloc (Alex already did an experiment in this
direction).

Concretely, on March 31 and April 1 (no joke :)), we have a session in Bern
where Alain Plantec will join us to look into how to approach this problem
concretely.

All in all, you should see Brick as a pragmatic intermediary step towards
removing Morph. I agree that it can be better (what cannot be), but I
disagree we should discard GT because of it.

Cheers,
Doru


On Tue, Mar 24, 2015 at 12:06 PM, Nicolai Hess  wrote:

>
>
> 2015-03-23 20:54 GMT+01:00 Aliaksei Syrel :
>
>> Hi,
>>
>> Sorry if my reply will be too long, but I tried to summarise our
>> experience with Morphic/Brick and give some useful feedback or even provide
>> ideas. Who wants will read :)
>>
>
> Hi,
> thank you, this is a really great source of information, and it would be
> heplful
> to have this kind of write up somewhere else (not in the mailinglist).
> But I did not question why we may need brick or why it is done.
> My question was, what are the feature plans, is it just an experiment that
> can vanish, so it is better to not use it for the core tools. Or is it
> meant to be
> THE new framework we should gain our focus on.
>
>
>>
>> Brick is not a thin layer anymore.
>>
>> It depends on what you mean under 'a thin layer' ;) Anyway, Brick was
>> born out of need. Spotter is completely built using Brick and Rubric.
>>
>
> This is something I don't understand. As we integrated GT-Tools into the
> image, Rubric
> slipped in as it is need by GT. I asked what is the background, what are
> the feature plans
> and complained about the undocumented core classes, that makes it
> difficult to see
> what changed compared to the old text classes. Alain said he doesn't plan
> to do further
> work on Rubric.
> So, WHY don't we replace and migrate the existing classes now and clean it
> up. It takes so
> much resources to maintain both. Every theme change, every change on
> shortcuts/menus/keymapping, the athens drawing, all has to be double
> checked - It is so exhausting.
>
>
>
>> No morphs are used at all (except Rubric of course).
>>
>
> Well, all Bricks ARE morphs, they share the same state and api.
>
>
>> All Bricks in Spotter in the end are subclasses of GLMBrick, which uses
>> from original Morph only Canvas (without drawing) and MorphicEvents.
>>
>
> If so, the clean/better way would be to extract those part into a
> "ProtoMorph" or a "PlainMorph".
> and subclass from that once for Brick and again for Morphs.
> Now we have Bricks, that are looking like a Morph, but aren't used to be
> one, and probable doesn't even work if they are used as Morphs.
> (Sure this is true for other Morphsubclasses as well, but that does not
> means it doesn't hurt if we do more of this).
>
>
>> Everything else was rewritten from scratch. During some period of time
>> Brick was able to render itself on Athens canvas, but we dropped it because
>> of Font issues in athens.
>>
> There are even more issues for Athens, and they don't vanish magically.
> There are some issues
> on fogbugz just waiting for some feedback, preferable from people
> intending to use Athens.
>
>
>> Spotter is not the only tool written using Brick, GLMPager - a pane pager
>> in GT-Inspector, GT-Playground and GT-Debugger is also completely done
>> using Brick. Almost all tab labels and tab selector in GT tools are Bricks.
>>
>>
> ...
>
>
>>
>> We really would like to move all tools to Bloc as soon as possible, but
>> we just need something right now that works and can be used in current
>> version.
>>
>
> But wyh not waiting on Bloc or (even better) help finishing Bloc. Why it
> is needed to push
> this into the release.
>
>
>>  I think we will never (but who knows) announce Brick as separate
>> project. In our minds it is just useful helper library.
>>
>
> For me, this just disqualifies Brick from being used in the core image.
>
>
> I see that many things in the GToolkit are better than the old one
> (theming/layouting/delegate behavior in sub(classes/bricks). Great, it
> makes fun to work with it,extending the inspector or Spotter search.
>
> But I don't understand why this i

Re: [Pharo-dev] Update question

[Serge Stinckwich]

Don't update use PharoLauncher instead ! I use PharoLauncher everyday for my 
work and I download new images every 2-3 days.

Sent from my iPhone

> On 24 mars 2015, at 11:13, Norbert Hartl  wrote:
> 
> Today I wanted (again) to update my image and it can't find GT packages. So 
> I'm interested how the community deals with that. Do you take fresh 
> downloaded images regularly? Or you do not update? Is it just me?
> 
> thanks,
> 
> Norbert
> 
> 

Re: [Pharo-dev] GLMBrick whats next?

[Nicolai Hess]

2015-03-23 20:54 GMT+01:00 Aliaksei Syrel :

> Hi,
>
> Sorry if my reply will be too long, but I tried to summarise our
> experience with Morphic/Brick and give some useful feedback or even provide
> ideas. Who wants will read :)
>

Hi,
thank you, this is a really great source of information, and it would be
heplful
to have this kind of write up somewhere else (not in the mailinglist).
But I did not question why we may need brick or why it is done.
My question was, what are the feature plans, is it just an experiment that
can vanish, so it is better to not use it for the core tools. Or is it
meant to be
THE new framework we should gain our focus on.


>
> Brick is not a thin layer anymore.
>
> It depends on what you mean under 'a thin layer' ;) Anyway, Brick was born
> out of need. Spotter is completely built using Brick and Rubric.
>

This is something I don't understand. As we integrated GT-Tools into the
image, Rubric
slipped in as it is need by GT. I asked what is the background, what are
the feature plans
and complained about the undocumented core classes, that makes it difficult
to see
what changed compared to the old text classes. Alain said he doesn't plan
to do further
work on Rubric.
So, WHY don't we replace and migrate the existing classes now and clean it
up. It takes so
much resources to maintain both. Every theme change, every change on
shortcuts/menus/keymapping, the athens drawing, all has to be double
checked - It is so exhausting.



> No morphs are used at all (except Rubric of course).
>

Well, all Bricks ARE morphs, they share the same state and api.


> All Bricks in Spotter in the end are subclasses of GLMBrick, which uses
> from original Morph only Canvas (without drawing) and MorphicEvents.
>

If so, the clean/better way would be to extract those part into a
"ProtoMorph" or a "PlainMorph".
and subclass from that once for Brick and again for Morphs.
Now we have Bricks, that are looking like a Morph, but aren't used to be
one, and probable doesn't even work if they are used as Morphs.
(Sure this is true for other Morphsubclasses as well, but that does not
means it doesn't hurt if we do more of this).


> Everything else was rewritten from scratch. During some period of time
> Brick was able to render itself on Athens canvas, but we dropped it because
> of Font issues in athens.
>
There are even more issues for Athens, and they don't vanish magically.
There are some issues
on fogbugz just waiting for some feedback, preferable from people intending
to use Athens.


> Spotter is not the only tool written using Brick, GLMPager - a pane pager
> in GT-Inspector, GT-Playground and GT-Debugger is also completely done
> using Brick. Almost all tab labels and tab selector in GT tools are Bricks.
>
>
...


>
> We really would like to move all tools to Bloc as soon as possible, but we
> just need something right now that works and can be used in current version.
>

But wyh not waiting on Bloc or (even better) help finishing Bloc. Why it is
needed to push
this into the release.


>  I think we will never (but who knows) announce Brick as separate project.
> In our minds it is just useful helper library.
>

For me, this just disqualifies Brick from being used in the core image.


I see that many things in the GToolkit are better than the old one
(theming/layouting/delegate behavior in sub(classes/bricks). Great, it
makes fun to work with it,extending the inspector or Spotter search.

But I don't understand why this is pushed that way and on top of the old
system/classes instead of cleaning that up.


nicolai


>
> Thanks for reading :)
>
> Cheers,
> Alex
>

Re: [Pharo-dev] Morphs becoming unresponsive

[Henrik Johansen]

> On 24 Mar 2015, at 11:22 , Alain Plantec via Pharo-dev 
>  wrote:
> 
> 
> Subject: Re: [Pharo-dev] Morphs becoming unresponsive
> From: Alain Plantec 
> Date: 24 Mar 2015 11:21:55 CET
> To: Pharo Development List 
> 
> 
> Hello Henrik,
> 
> I read 
> windowEvent: anEvent
> 
> WorldState quitSession.
> self removeProperty: #closeWorldDialogOpen ]
> 
> but shouldn't it be
> 
> windowEvent: anEvent
> 
> WorldState quitSession.
> self removeProperty: #canOpenCloseDialog ]
> 
> Cheers
> Alain

You are right of course, thanks!
Last minute renames are never a good idea, even when the method is 5 lines long 
:/
I submitted a new slice where the property name is consistent.

Cheers,
Henry

[Pharo-dev] Populating/editing list with modal dialogs in Glamour

[Yuriy Tymchuk]

Hi everyone,

I’m playing with glamour, and I’m trying to construct a list that can be edited 
e.g. you can add items, edit them and remove and for adding and editing you 
have a custom popup written again in glamour. So first question is how can I 
dead with basic actions? Is the GLMActionListPresentation way to go, or I 
should look on the other things. Another question is how do you open a modal 
window with glamour and how do you get the result from it.

I’ll be very thankful for any reply.
Cheers.
Uko

Re: [Pharo-dev] Update question

[Thierry Goubier]

2015-03-24 11:13 GMT+01:00 Norbert Hartl :

> Today I wanted (again) to update my image and it can't find GT packages.
> So I'm interested how the community deals with that. Do you take fresh
> downloaded images regularly? Or you do not update? Is it just me?
>

I don't update. I want to make sure my developments are buildable somewhere
else (for a team member, for versionning, for moving work from one computer
to another), so I make sure I have a script for a fresh image (and I
regularly rebuild (i.e. commit, push, make clean, make).

My scripts are Makefiles, and the Makefiles are in the version control
system.

Thierry



>
> thanks,
>
> Norbert
>
>
>

Re: [Pharo-dev] Update question

[kilon alios]

I tried it a few times, and had nothing but problems with it. We have
discussed here several times and from what I have learned there several
technical limitation.

I am using pharolauncher non stop and wonder why Pharolauncher is not
integrated inside Pharo yet. I have added my code inside the configuration
browser (Ephestos, Nireas) and Installing my code back in a fresh image is
just a two click process.

On Tue, Mar 24, 2015 at 12:13 PM, Norbert Hartl  wrote:

> Today I wanted (again) to update my image and it can't find GT packages.
> So I'm interested how the community deals with that. Do you take fresh
> downloaded images regularly? Or you do not update? Is it just me?
>
> thanks,
>
> Norbert
>
>
>

Re: [Pharo-dev] Morphs becoming unresponsive

[Alain Plantec via Pharo-dev]

--- Begin Message ---
Hello Henrik,

I read 
windowEvent: anEvent

WorldState quitSession.
self removeProperty: #closeWorldDialogOpen ]

but shouldn't it be

windowEvent: anEvent

WorldState quitSession.
self removeProperty: #canOpenCloseDialog ]

Cheers
Alain


> Le 23 mars 2015 à 14:06, Henrik Johansen  a 
> écrit :
> 
> I just ran into a case where all morphs became unresponsive, and clicking 
> anywhere only gave me the World Menu.
> 
> After some investigation, it turned out all the World submorphs had been 
> locked, and I could "unfreeze" them with the following (from a new Workspace):
> World submorphsDo: [ :aMorph | aMorph unlock ]
> 
> What triggered it?
> Well, the image had become unresponsive, so I clicked the close buttons a 
> couple of times (before trying good ol' cmd-dot, which brought up a debugger 
> on the old UI process and let me continue).
> 
> The close dialog is modal, normally that's no problem, since the modal morph 
> locks all other morphs, no two can be opened at the same time (unless you 
> somehow let that modal morph open another), but the close triggered by the 
> system window's close button is special, since it is triggered outside the 
> control of the World.
> 
> The bug is rare in occurrence, yet easy to trigger; press the window close 
> button twice, cancel one of the close dialogs, all windows that were open 
> will remain locked and seem unresponsive.
> 
> It might be smart to rethink the whole modality concept to make the code more 
> robust/coherent, but for now an extra check for this single case in  
> PasteUpMorph >> windowEvent: (for instance, using a morph property) should do 
> the trick, I'll submit a slice shortly.
> 
> Cheers,
> Henry

--- End Message ---

Re: [Pharo-dev] Update question

[Peter Uhnák]

I didn't even know there was an update option.
Instead I download fresh images (regularly) through Pharo Launcher, plus I
have startup script that looks at the name of the image and does extra
stuff — e.g. if the image name contains MyProjectX, it automatically adds
repositories for it and loads it).

Peter

On Tue, Mar 24, 2015 at 11:13 AM, Norbert Hartl  wrote:

> Today I wanted (again) to update my image and it can't find GT packages.
> So I'm interested how the community deals with that. Do you take fresh
> downloaded images regularly? Or you do not update? Is it just me?
>
> thanks,
>
> Norbert
>
>
>

[Pharo-dev] Update question

[Norbert Hartl]

Today I wanted (again) to update my image and it can't find GT packages. So I'm 
interested how the community deals with that. Do you take fresh downloaded 
images regularly? Or you do not update? Is it just me?

thanks,

Norbert

Re: [Pharo-dev] Old Pharo Mac VM on pharo.org

[Ben Coman]

Is pharo-minimal going to be an artefact of the Release?  Should it be
temporarily sacrificed to allow a more recent VM to go out with the
Release?

If its too close to Release to change the VM, then perhaps the current
release date could be a Release Candidate including a new VM, kept for
maybe a two weeks with a hard rule for no updates except related to the new
VM.

I guess the creation of additional work and complexity for the Release, as
well as risk updating the VM would be a consideration against.

cheers -ben

On Mon, Mar 23, 2015 at 9:05 PM, Esteban Lorenzano 
wrote:

>
> On 23 Mar 2015, at 10:27, Norbert Hartl  wrote:
>
>
> Am 23.03.2015 um 09:51 schrieb Noury Bouraqadi :
>
> Hi,
>
> On http://pharo.org/download I got the Mac VM dating back to sept 2014.
> Shouldn't it be http://files.pharo.org/vm/pharo/mac/latest.zip ?
>
> No, I think latest is more less a direct copy of the latest successful
> build on jenkins. That would be a no-go to offer as the vm to use. VMs have
> have releases as well. And in the same directory there is a stable.zip
> which is the right one. And it is from september. Everything else is in the
> hands of esteban.
>
>
> this :)
>
> but seriously: I’ve been having some problems to promote a newer vm as
> stable, concretely in the pharo-minimal step. I wanted to have new one for
> Pharo4, but I’m not arriving either… so I will move it as soon as I find a
> solution, I’m sorry :(
>
> Esteban
>
>
> Norbert
>
>
>

[Pharo-dev] Making Seaside work in Pharo 4

[Stephan Eggermont]

In Issue 13739, build 40145 classesInTheSelectedPackage in Nautilus was 
removed. What is the correct way to replace it? WABrowser uses a

nautilus browser to show a web-based browser.
(build 609, Seaside #'release3.1' pharo4, from ci)

WABrowserTest>>testContentsNotifying
| model |
model := WABrowser browserClass new.
	model systemCategoryListIndex: (model systemCategoryList indexOf: 
'Seaside-Tests-Pharo-Development').

model classListIndex: (model classList indexOf: #WABrowserTest).
	model messageCategoryListIndex: (model messageCategoryList indexOf: 
#'-- all --').

[
self assert:
(model contents: 'sampleMethod
^ 1 + 1'
notifying: self).
self assert: message isNil ]
ensure: [ WABrowserTest removeSelectorSilently: #sampleMethod ]

Stephan

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 0368f1: 40579

[GitHub]

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

  Changed paths:
M Morphic-Core.package/PasteUpMorph.class/instance/event 
handling/windowEvent_.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script578.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script579.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40578.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40579.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
A 
Slot-Tests.package/PropertySlotTest.class/instance/tests/testCreateClassWithPropertySlotAddSecond.st
A 
Slot-Tests.package/PropertySlotTest.class/instance/tests/testRemovePropertySlot.st
A 
Slot-Tests.package/PropertySlotTest.class/instance/tests/testRemovePropertySlot2.st
R Slot.package/PropertySlot.class/instance/class building/installingIn_.st
A Slot.package/PropertySlot.class/instance/class building/layoutChanged_.st
R Slot.package/PropertySlot.class/instance/class building/removingFrom_.st
R Slot.package/PropertySlot.class/instance/initalize/initialize.st
A Slot.package/Slot.class/instance/class building/layoutChanged_.st
M Slot.package/SlotClassBuilder.class/instance/initialize-release/build.st
M 
Slot.package/SlotClassBuilder.class/instance/initialize-release/buildNewClass.st

  Log Message:
  ---
  40579
15221 PropertySlot: Tests for removing PropertySlots
https://pharo.fogbugz.com/f/cases/15221

15215 Prevent the World locking due to multiple modal dialogs open
https://pharo.fogbugz.com/f/cases/15215

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