Re: [Pharo-users] MorphTree behavior changed

[Tudor Girba]

Hi Hilaire,

Could you be more specific?

What exactly is the problem?

Cheers,
Doru




On Tue, Jun 3, 2014 at 8:24 PM, Hilaire Fernandes <
hilaire.fernan...@gmail.com> wrote:

> Hi,
>
> why when morph tree send updateList there is an announcement from the
> model? It was not the case before.
>
> Thanks
>
> Hilaire
>
> --
> Dr. Geo http://drgeo.eu
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] Slowness question

[Hilaire Fernandes]

I did not try yet.

Hilaire

Le 05/06/2014 19:46, Alain Busser a écrit :
> What does the profiler say?
> 
> Alain
> 

-- 
Dr. Geo http://drgeo.eu

Re: [Pharo-users] MorphTree behavior changed

[Hilaire Fernandes]

Just confused by the shift to Annoucement. Ok now.
Again I beg for consolidations in Pharo to avoid confusion with multiple
frameworks doing the same things.

Hilaire

Le 06/06/2014 11:08, Tudor Girba a écrit :
> Hi Hilaire,
> 
> Could you be more specific?
> 
> What exactly is the problem?
> 
> Cheers,
> Doru
> 
> 
> 
> 
> On Tue, Jun 3, 2014 at 8:24 PM, Hilaire Fernandes
>  > wrote:
> 
> Hi,
> 
> why when morph tree send updateList there is an announcement from the
> model? It was not the case before.
> 
> Thanks
> 
> Hilaire
> 
> --
> Dr. Geo http://drgeo.eu
> 
> 
> 
> 
> 
> -- 
> www.tudorgirba.com 
> 
> "Every thing has its own flow"

-- 
Dr. Geo http://drgeo.eu

Re: [Pharo-users] Slowness question

[Sven Van Caekenberghe]

On 04 Jun 2014, at 23:15, Hilaire Fernandes  wrote:

> Programmed sketch in DrGeo can be animated, for example like the script
> bellow.
> The "canvas do:" message forks the block so user is not blocked.
> At #udpate message the items and views (morph) are recomputed and refreshed
> .
> Before porting DrGeo to Athens, the animation was pretty fast, now it is
> very slow.
> 
> Any idea from where it could come from?

I don't know, this is not my area. But I remember a discussion about Morphic 
updates and Athens where Igor participated in, but I can't find it anywhere. I 
thought he said doing it that way is very inefficient.

Sorry for the vague answer.

Re: [Pharo-users] MorphTree behavior changed

[Sven Van Caekenberghe]

On 06 Jun 2014, at 14:41, Hilaire Fernandes  wrote:

> Just confused by the shift to Annoucement. Ok now.
> Again I beg for consolidations in Pharo to avoid confusion with multiple
> frameworks doing the same things.

But is it not normal that first the basic building blocks of something new are 
added, then slowly more and more code starts using it ? OK, this is not ideal, 
but not everything can happen at once.

The Announcement framework is small, old, external and independent of other 
system elements. It is used at various places already but I guess it is not yet 
used everywhere uniformly. Maybe it is not ideal for everything.

Re: [Pharo-users] Slowness question

[Hilaire Fernandes]

Right, I remember about it as well.
Once a few morphs are added it get really slower pretty quickly.

The discussion you refer is there:
http://forum.world.st/Redraw-suggestion-for-Athens-tt4750951.html#a4751188

Regarding DrGeo canvas, it does not really need and rely on the change
mechanisme of Morph: model tree is updated in one shot, then the views
are updated in one shot after. But may be there are leftover change in
the used view, not necessary to drgeo but implying unecessary update.


Hilaire


Le 06/06/2014 14:46, Sven Van Caekenberghe a écrit :
> I don't know, this is not my area. But I remember a discussion about Morphic 
> updates and Athens where Igor participated in, but I can't find it anywhere. 
> I thought he said doing it that way is very inefficient.

-- 
Dr. Geo http://drgeo.eu

Re: [Pharo-users] MorphTree behavior changed

[Hilaire Fernandes]

I agree with you. That's why I beg for a few releases to concentrate on
consolidation to make the system cleaner *and* easier to understand for
beginner, and not so beginner.

The Annoucement framework looks definitely better and it is easier to
track it in the image.

Thanks

Hilaire

Le 06/06/2014 14:52, Sven Van Caekenberghe a écrit :
> 
> On 06 Jun 2014, at 14:41, Hilaire Fernandes  
> wrote:
> 
>> Just confused by the shift to Annoucement. Ok now.
>> Again I beg for consolidations in Pharo to avoid confusion with multiple
>> frameworks doing the same things.
> 
> But is it not normal that first the basic building blocks of something new 
> are added, then slowly more and more code starts using it ? OK, this is not 
> ideal, but not everything can happen at once.
> 
> The Announcement framework is small, old, external and independent of other 
> system elements. It is used at various places already but I guess it is not 
> yet used everywhere uniformly. Maybe it is not ideal for everything.
> 
> 
> 

-- 
Dr. Geo http://drgeo.eu

Re: [Pharo-users] Slowness question

[Hilaire Fernandes]

I extracted from the buggy profiler window the profile tree of the
execution of this script.

The DrGeo computing part take only a fraction of the CPU time.

Hilaire


Le 06/06/2014 14:55, Hilaire Fernandes a écrit :
> When executing under the profiler the mentioned DrGeo script, I realize
> the Profiler window is severely broken:
> 
> Part of the windows can't be renderd, profile result can not be properly
> read (tiny text zone user can't resize). See screenshot.
> Can't see related problem on the bug tracker.
> 
> Hilaire
> 
> Le 04/06/2014 23:15, Hilaire Fernandes a écrit :
>> Before porting DrGeo to Athens, the animation was pretty fast, now it is
>> very slow.
>>
>> Any idea from where it could come from?
> 

-- 
Dr. Geo http://drgeo.eu
 - 28115 tallies, 28366 msec.

**Tree**

Process: other processes

22.0% {6234ms} ProcessorScheduler class>>idleProcess
2.8% {786ms} DrGeoCanvas>>segment:to:
  2.7% {761ms} DrGeoCanvas>>finalizeCurve:
1.4% {389ms} DrGeoDomain>>createFromMathItemNoStack:
  |1.1% {324ms} DrGMathItemFactory(DrGFactory)>>pushAsLastWhenInPool:
  |  1.1% {324ms} DrGMathItemFactory(DrGFactory)>>findInPool:
  |1.1% {324ms} DrGMathItemFactory(DrGFactory)>>indexOf:
  |  1.1% {324ms} OrderedCollection(SequenceableCollection)>>indexOf:
  |1.1% {324ms} 
OrderedCollection(SequenceableCollection)>>indexOf:ifAbsent:
  |  1.1% {324ms} 
OrderedCollection(SequenceableCollection)>>indexOf:startingAt:ifAbsent:
  |1.1% {313ms} DrGSegment2ptsItem(DrGMathItem)>>=
  |  1.1% {306ms} DrGSegment2ptsItem>>parentsEqual:
  |1.0% {297ms} DrGPointIntersectionItem>>=
  |  1.0% {297ms} DrGPointIntersectionItem(DrGMathItem)>>=
  |1.0% {297ms} 
DrGPointIntersectionItem(DrGMathItem)>>parentsEqual:
  |  1.0% {295ms} 
OrderedCollection(SequenceableCollection)>>=
  |1.0% {295ms} 
OrderedCollection(SequenceableCollection)>>hasEqualElements:
1.3% {371ms} DrGeoCanvas>>costumeOf:
  1.3% {371ms} DrGeo>>costumeOf:
1.3% {357ms} DrGSegment2ptsItem(DrGMathItem)>>=
  1.2% {351ms} DrGSegment2ptsItem>>parentsEqual:
1.1% {312ms} DrGPointIntersectionItem>>=
  1.1% {312ms} DrGPointIntersectionItem(DrGMathItem)>>=
1.1% {312ms} 
DrGPointIntersectionItem(DrGMathItem)>>parentsEqual:
  1.1% {310ms} OrderedCollection(SequenceableCollection)>>=
1.1% {310ms} 
OrderedCollection(SequenceableCollection)>>hasEqualElements:
  1.1% {307ms} DrGCircle2ptsItem(DrGMathItem)>>=
1.1% {307ms} 
DrGCircle2ptsItem(DrGMathItem)>>parentsEqual:
  1.1% {307ms} Array(SequenceableCollection)>>=
1.1% {307ms} 
Array(SequenceableCollection)>>hasEqualElements:
  1.1% {305ms} DrGPointIntersectionItem>>=
1.1% {305ms} 
DrGPointIntersectionItem(DrGMathItem)>>=
  1.1% {305ms} 
DrGPointIntersectionItem(DrGMathItem)>>parentsEqual:
1.1% {303ms} 
OrderedCollection(SequenceableCollection)>>=
  1.0% {298ms} 
OrderedCollection(SequenceableCollection)>>hasEqualElements:
1.0% {294ms} 
DrGCircle2ptsItem(DrGMathItem)>>=
  1.0% {294ms} 
DrGCircle2ptsItem(DrGMathItem)>>parentsEqual:
1.0% {294ms} 
Array(SequenceableCollection)>>=
  1.0% {294ms} 
Array(SequenceableCollection)>>hasEqualElements:
1.0% {294ms} 
DrGPointIntersectionItem>>=
  1.0% {294ms} 
DrGPointIntersectionItem(DrGMathItem)>>=
1.0% {294ms} 
DrGPointIntersectionItem(DrGMathItem)>>parentsEqual:
  1.0% {292ms} 
OrderedCollection(SequenceableCollection)>>=
1.0% {292ms} 
OrderedCollection(SequenceableCollection)>>hasEqualElements:
  1.0% {291ms} 
DrGCircle2ptsItem(DrGMathItem)>>=
1.0% {291ms} 
DrGCircle2ptsItem(DrGMathItem)>>parentsEqual:
  1.0% {291ms} 
Array(SequenceableCollection)>>=
1.0% {291ms} 
Array(SequenceableCollection)>>hasEqualElements:
  1.0% {291ms} 
DrGPointIntersectionItem>>=
   

Re: [Pharo-users] Slowness question

[stepharo]

can you open a bug entry.

Stef

On 6/6/14 14:55, Hilaire Fernandes wrote:

When executing under the profiler the mentioned DrGeo script, I realize
the Profiler window is severely broken:

Part of the windows can't be renderd, profile result can not be properly
read (tiny text zone user can't resize). See screenshot.
Can't see related problem on the bug tracker.

Hilaire

Le 04/06/2014 23:15, Hilaire Fernandes a écrit :

Before porting DrGeo to Athens, the animation was pretty fast, now it is
very slow.

Any idea from where it could come from?

[Pharo-users] [ANN] Generating beautiful html books from Pillar

[Damien Cassou]

Nicolas Petton and I are proud to announce the possibility to create really
nice HTML books from Pillar (I must thank
https://github.com/GitbookIO/gitbook as well). The first book to get this
nice layout is the Pillar documentation:

http://damiencassou.gitbooks.io/pillar/introduction.pier.html

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without losing
enthusiasm."
Winston Churchill

Re: [Pharo-users] Slowness question

[stepharo]

igor is hacking with max on virtualCPU to offer a common abstraction to 
both X86 and ARM assembly generation

and nativeboost.

Stef

On 4/6/14 23:15, Hilaire Fernandes wrote:

Hi,


Programmed sketch in DrGeo can be animated, for example like the script
bellow.
The "canvas do:" message forks the block so user is not blocked.
At #udpate message the items and views (morph) are recomputed and refreshed
.
Before porting DrGeo to Athens, the animation was pretty fast, now it is
very slow.

Any idea from where it could come from?

Thanks


---8<--
|canvas s stats points|

points :=Array new: 12.
stats := Array new: 12 withAll: 0.

canvas := DrGeoCanvas new.
2 to: 12 do: [:i |
points at: i put: (canvas point: i@0.1).
(points at: i) square; color: Color blue.
s := canvas segment: i@0 to: (points at: i).
s color: Color red].

canvas do: [
1 to: 1 do: [:i|
s := 6 atRandom + 6 atRandom.
stats at: s put: ((stats at: s)+1).
(points at: s)
name: (stats at: s) asString;
moveTo: s @ ((stats at: s) / 100).
canvas update].
---8<--

Re: [Pharo-users] Slowness question

[Hilaire Fernandes]

Hi Steph,

Before I would like to discuss the issue because I don't know if it
belongs to drgeo itlself or Pharo.

What is strange, althought the script execution becomes more and more
slow as more and more items are built, once the sketch is fully
constructed, manipulating the sketch is fast and smooth.

The only things I can add about this script: the construction take place
in a forked process to let the user see the construction as an animation.

I emptied the change/update family of methods in the used morph for
drgeo canvas, it does change the issue.

Hilaire


Le 06/06/2014 18:03, stepharo a écrit :
> can you open a bug entry.
> 
> Stef
> 
> On 6/6/14 14:55, Hilaire Fernandes wrote:
>> When executing under the profiler the mentioned DrGeo script, I realize
>> the Profiler window is severely broken:
>>
>> Part of the windows can't be renderd, profile result can not be properly
>> read (tiny text zone user can't resize). See screenshot.
>> Can't see related problem on the bug tracker.
>>
>> Hilaire
>>
>> Le 04/06/2014 23:15, Hilaire Fernandes a écrit :
>>> Before porting DrGeo to Athens, the animation was pretty fast, now it is
>>> very slow.
>>>
>>> Any idea from where it could come from?
> 
> 
> 

-- 
Dr. Geo http://drgeo.eu

Re: [Pharo-users] Slowness question

[Hilaire Fernandes]

Read: "...it does not change the issue."

Le 06/06/2014 18:19, Hilaire Fernandes a écrit :
> I emptied the change/update family of methods in the used morph for
> drgeo canvas, it does change the issue.

-- 
Dr. Geo http://drgeo.eu

Re: [Pharo-users] Slowness question

[Ben Coman]

Hilaire Fernandes wrote:

Hi Steph,

Before I would like to discuss the issue because I don't know if it
belongs to drgeo itlself or Pharo.

What is strange, althought the script execution becomes more and more
slow as more and more items are built, once the sketch is fully
constructed, manipulating the sketch is fast and smooth.

The only things I can add about this script: the construction take place
in a forked process to let the user see the construction as an animation.

I emptied the change/update family of methods in the used morph for
drgeo canvas, it does change the issue.

Hilaire


Le 06/06/2014 18:03, stepharo a écrit :
  

can you open a bug entry.

Stef

On 6/6/14 14:55, Hilaire Fernandes wrote:


When executing under the profiler the mentioned DrGeo script, I realize
the Profiler window is severely broken:

Part of the windows can't be renderd, profile result can not be properly
read (tiny text zone user can't resize). See screenshot.
Can't see related problem on the bug tracker.

Hilaire

Le 04/06/2014 23:15, Hilaire Fernandes a écrit :
  

Before porting DrGeo to Athens, the animation was pretty fast, now it is
very slow.

Any idea from where it could come from?

I once had a problem with Announcements being fired too often for the 
rendering loop, but apparently my solution wasn't the best.


So I'm just just curious what might happen if somewhere under the 
WorldState>>doOneCycleFor: call stack you might store the time "now", 
only do a high cost render every 100ms.


cheers -ben

Re: [Pharo-users] Slowness question

[Hilaire Fernandes]

Le 06/06/2014 19:34, Ben Coman a écrit :

> So I'm just just curious what might happen if somewhere under the
> WorldState>>doOneCycleFor: call stack you might store the time "now",
> only do a high cost render every 100ms.

Can you rephrase I don't understand?

Thanks

Hilaire


-- 
Dr. Geo http://drgeo.eu

Re: [Pharo-users] Slowness question

[Hilaire Fernandes]

Oops, I did not realize you were referring to the profiler bug!
Here it is https://pharo.fogbugz.com/f/cases/13309/

Hilaire

Le 06/06/2014 18:03, stepharo a écrit :
> can you open a bug entry.
> 
> Stef

-- 
Dr. Geo http://drgeo.eu

Re: [Pharo-users] [ANN] Generating beautiful html books from Pillar

[Yuriy Tymchuk]

Thank you for creating the future.

Uko

Sent from my iPhone

> On 06 Jun 2014, at 21:36, Damien Cassou  wrote:
> 
> Nicolas Petton and I are proud to announce the possibility to create really 
> nice HTML books from Pillar (I must thank 
> https://github.com/GitbookIO/gitbook as well). The first book to get this 
> nice layout is the Pillar documentation:
> 
> http://damiencassou.gitbooks.io/pillar/introduction.pier.html
> 
> -- 
> Damien Cassou
> http://damiencassou.seasidehosting.st
> 
> "Success is the ability to go from one failure to another without losing 
> enthusiasm." 
> Winston Churchill

Re: [Pharo-users] Slowness question

[Ben Coman]

Hilaire Fernandes wrote:

  Le 06/06/2014 19:34, Ben Coman a écrit :

  
  
So I'm just just curious what might happen if somewhere under the
WorldState>>doOneCycleFor: call stack you might store the time "now",
only do a high cost render every 100ms.

  
  
Can you rephrase I don't understand?

Thanks

Hilaire


  

I was referring to 
	 30.2% {8564ms} DrGDrawable(Morph)>>fullDrawOnAthensCanvas:

Perhaps the total accumulation of time includes how often the code is run.
Just as an experiment, wrap the current method something like...
now := DateAndTime now.
lasttime ifNil: [ lasttime = 0].
(now > lasttime + "100ms") ifTrue: [ "do original method" ]

Now the display might flash horribly, but you may be able to observe an effect on responsiveness, and different profile output as a step to fixing. 

cheers -ben