February 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] What is Phlow?

by Norbert Hartl

That sounds really interesting. Are there any materials available? Norbert > Am 10.02.2015 um 08:14 schrieb stepharo <stepharo(a)free.fr>: > > This is fun because I wanted to propose to have a dataflow engine based on slot for event manipulation > and there is phlow :) > > Stef > >> 2015-02-09 21:50 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: >>> Hi, >>> >>> First, thanks for reviewing the code :). >>> >>> Phlow is a small engine that makes it possible to link Brick slots to one another to enable flow of data. >> >> Sounds interesting! >> >> >>> >>> Cheers, >>> Doru >>> >>> >>> >>>> On Mon, Feb 9, 2015 at 1:46 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >>>> For example GLMBrick subclass: #GLMPhlowBrick >>>> in category: 'Glamour-Morphic-Brick-Phlow' >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >

Feb. 10, 2015

Re: [Pharo-dev] What is Phlow?

by stepharo

This is fun because I wanted to propose to have a dataflow engine based on slot for event manipulation and there is phlow :) Stef > 2015-02-09 21:50 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>>: > > Hi, > > First, thanks for reviewing the code :). > > Phlow is a small engine that makes it possible to link Brick slots > to one another to enable flow of data. > > > Sounds interesting! > > > Cheers, > Doru > > > > On Mon, Feb 9, 2015 at 1:46 PM, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > > For example GLMBrick subclass: #GLMPhlowBrick > in category: 'Glamour-Morphic-Brick-Phlow' > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow" > >

Feb. 10, 2015

Re: [Pharo-dev] Reducing the activity of the image

by Eliot Miranda

On Feb 9, 2015, at 10:41 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 10 Feb 2015, at 01:55, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Sven, >> >> On Mon, Feb 9, 2015 at 1:43 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> There is some timer thread between the image and the vm that ticks every millisecond, that is the cause. I don't know what it does but it is apparently needed. >> >> Anyway, that is how I understood it from Igor and Eliot, long ago. >> >> So basically, the VM is always slightly busy. >> >> Yet the VM is always slightly busy with the heartbeat thread, but this is very cheap. The actual idle cost comes form the idle loop in the background process that sends relinquishProcessorForMicroseconds:, which is a primitive that eventually calls the select system call. This is the source of the cost. > > Can we change something about that ? > Maybe just as an experiment to prove your point ? What do you think halving or doubling the argument to relinquishProcessorForMicroseconds: should do if this is the major source of overhead? Processor usage at idle should be closely inversely proportional right? > >>> On 09 Feb 2015, at 21:11, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> I have an installation where a pharo powered hardware is used in a closed case. Over time that collects quite some heat. One reason for this is that the pharo vm is taking approx. 6% CPU all the time. The only thing that happens is network/sockets. I suspended the ui thread in the image but on this platform it doesn't help. >>> Are there any tweaks to lower the polling and the activity of the image/vm even more? >>> >>> thanks, >>> >>> Norbert >> -- >> best, >> Eliot > >

Feb. 10, 2015

Re: [Pharo-dev] Reducing the activity of the image

by Sven Van Caekenberghe

> On 10 Feb 2015, at 01:55, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Sven, > > On Mon, Feb 9, 2015 at 1:43 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > There is some timer thread between the image and the vm that ticks every millisecond, that is the cause. I don't know what it does but it is apparently needed. > > Anyway, that is how I understood it from Igor and Eliot, long ago. > > So basically, the VM is always slightly busy. > > Yet the VM is always slightly busy with the heartbeat thread, but this is very cheap. The actual idle cost comes form the idle loop in the background process that sends relinquishProcessorForMicroseconds:, which is a primitive that eventually calls the select system call. This is the source of the cost. Can we change something about that ? Maybe just as an experiment to prove your point ? > > On 09 Feb 2015, at 21:11, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > I have an installation where a pharo powered hardware is used in a closed case. Over time that collects quite some heat. One reason for this is that the pharo vm is taking approx. 6% CPU all the time. The only thing that happens is network/sockets. I suspended the ui thread in the image but on this platform it doesn't help. > > Are there any tweaks to lower the polling and the activity of the image/vm even more? > > > > thanks, > > > > Norbert > -- > best, > Eliot

Feb. 10, 2015

Re: [Pharo-dev] About AST instance variable naming

by Eliot Miranda

On Mon, Feb 9, 2015 at 12:31 PM, stepharo <stepharo(a)free.fr> wrote: > Hi > > today during a lecture I was quite surprised to see the name of the AST > variables. > There is no easy way to see that a variable is a position in the text or a > subtree. > > Example > > RBValueNode subclass: #RBArrayNode > instanceVariableNames: 'left right statements periods' > classVariableNames: '' > category: 'AST-Core-Nodes' > > RBValueNode subclass: #RBBlockNode > instanceVariableNames: 'left right colons arguments bar body scope' > classVariableNames: '' > category: 'AST-Core-Nodes' > > Annoying because you have always to think (yes I know I'm stupid not > knowing by heart the tree structure) > to know if you get a tree under your fingers. We can definitively better > in terms of code habilitability. > We cleaned the visitor and since then the code is much much much better. > > > I would do the following > > RBValueNode subclass: #RBArrayNode > instanceVariableNames: 'leftParenthesisPosition > rightParenthesisPosition statements periodsPosition' > classVariableNames: '' > category: 'AST-Core-Nodes' > leftParenthesisIndex is shorter... leftParenIndex shorter still ;-) I would be also ok with > > RBValueNode subclass: #RBArrayNode > instanceVariableNames: 'leftPosition rightPosition statements > periodsPosition' > classVariableNames: '' > category: 'AST-Core-Nodes' > > RBValueNode subclass: #RBBlockNode > instanceVariableNames: 'leftPosition rightPosition colonsPosition > arguments barPosition body scope' > classVariableNames: '' > category: 'AST-Core-Nodes' > > -- best, Eliot

Feb. 10, 2015

Re: [Pharo-dev] Reducing the activity of the image

by Eliot Miranda

Hi Sven, On Mon, Feb 9, 2015 at 1:43 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > There is some timer thread between the image and the vm that ticks every > millisecond, that is the cause. I don't know what it does but it is > apparently needed. > > Anyway, that is how I understood it from Igor and Eliot, long ago. > > So basically, the VM is always slightly busy. > Yet the VM is always slightly busy with the heartbeat thread, but this is very cheap. The actual idle cost comes form the idle loop in the background process that sends relinquishProcessorForMicroseconds:, which is a primitive that eventually calls the select system call. This is the source of the cost. > On 09 Feb 2015, at 21:11, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > I have an installation where a pharo powered hardware is used in a > closed case. Over time that collects quite some heat. One reason for this > is that the pharo vm is taking approx. 6% CPU all the time. The only thing > that happens is network/sockets. I suspended the ui thread in the image but > on this platform it doesn't help. > > Are there any tweaks to lower the polling and the activity of the > image/vm even more? > > > > thanks, > > > > Norbert > -- best, Eliot

Feb. 10, 2015

Re: [Pharo-dev] Reducing the activity of the image

by Ben Coman

You might look at #interCyclePause: and #handleTimerEvent . cheers -ben On Tue, Feb 10, 2015 at 4:11 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > I have an installation where a pharo powered hardware is used in a closed > case. Over time that collects quite some heat. One reason for this is that > the pharo vm is taking approx. 6% CPU all the time. The only thing that > happens is network/sockets. I suspended the ui thread in the image but on > this platform it doesn't help. > Are there any tweaks to lower the polling and the activity of the image/vm > even more? > > thanks, > > Norbert > > >

Feb. 9, 2015

Re: [Pharo-dev] What is Phlow?

by Nicolai Hess

2015-02-09 21:50 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > First, thanks for reviewing the code :). > > Phlow is a small engine that makes it possible to link Brick slots to one > another to enable flow of data. > Sounds interesting! > > Cheers, > Doru > > > > On Mon, Feb 9, 2015 at 1:46 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> For example GLMBrick subclass: #GLMPhlowBrick >> in category: 'Glamour-Morphic-Brick-Phlow' >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Feb. 9, 2015

Re: [Pharo-dev] Reducing the activity of the image

by Kjell Godo

is there any software engineering wisdom that can be displayed about the decision making which led to polling being chosen over event driven in the first place? Are there any watch words to the wise to be avoided here? On Monday, February 9, 2015, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 09.02.2015 um 22:19 schrieb stepharo <stepharo(a)free.fr <javascript:;> > >: > > > > > >>>> I have an installation where a pharo powered hardware is used in a > closed case. Over time that collects quite some heat. One reason for this > is that the pharo vm is taking approx. 6% CPU all the time. The only thing > that happens is network/sockets. I suspended the ui thread in the image but > on this platform it doesn't help. > >>>> Are there any tweaks to lower the polling and the activity of the > image/vm even more? > >>> Right now having an event driven VM is the way but it is not on the > horizon. JB was starting to look at that when he worked on the android part. > >> Are the prerequisites for having things event driven known? Is that a > huge task for the vm if things need to call in instead of being called? > > > > I do not know. What I can tell you is that we are doing our best and I'm > try to get funding. > > This is three years that I apply to EU funding and fail :). But if I get > it I have 8 years engineers planned. > > I know is hard. Thank you very much to try harder :) > > We'll make it somehow ;) > > Norbert > > >

Feb. 9, 2015

Re: [Pharo-dev] Reducing the activity of the image

by Sven Van Caekenberghe

There is some timer thread between the image and the vm that ticks every millisecond, that is the cause. I don't know what it does but it is apparently needed. Anyway, that is how I understood it from Igor and Eliot, long ago. So basically, the VM is always slightly busy. > On 09 Feb 2015, at 21:11, Norbert Hartl <norbert(a)hartl.name> wrote: > > I have an installation where a pharo powered hardware is used in a closed case. Over time that collects quite some heat. One reason for this is that the pharo vm is taking approx. 6% CPU all the time. The only thing that happens is network/sockets. I suspended the ui thread in the image but on this platform it doesn't help. > Are there any tweaks to lower the polling and the activity of the image/vm even more? > > thanks, > > Norbert

Feb. 9, 2015