- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] missing updates: 30503 30504

by Sven Van Caekenberghe

Everybody does a lot of work for Pharo, visible and invisible. We are complementary and we need each other - so we have to work together. On 23 Oct 2013, at 18:53, Camillo Bruni <camillobruni(a)gmail.com> wrote: > On 2013-10-23, at 16:06, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> On 2013-10-23, at 13:48, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> On Oct 23, 2013, at 10:52 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>> On 2013-10-22, at 10:44, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>>>>> For retracting files you need access to files.pharo.org. >>>>>> >>>>>> This is what should be written in the readme. >>>>> >>>>> BTW have you tried that you actually have access to the machine? >>>>> Because I remember that it didn't work for you nor Esteban... >>>> >>>> >>>> So stef, did you check that you can actually edit the file? >>> >>> I cannot access it but I least I know that I should not look for it. >>> And next time if there is a problem I just stop integrated and continue hacking on my cool stuff and look smart. >> >> Why can't you access it? >> What do you want instead? >> How do we avoid this situation in the future? (happened already before a couple of times) > > Just to get something straight here: > > You have hardly something to complain... What you see is the tip of the iceberg. > I spend roughly 1-2 hours per week maintaining all the jenkins instances with all > the slaves and all the jobs that run (and there is Christoph to, regularly fixing > and tweaking things all around). > > Now running around wild and screaming that everything does not work and is not > documented is highly demotivating. Marcus and Esteban work on it on a daily basis. > If maintaining jenkins were so much fun, you would do it, but you don't. > > > So enjoy, and focus on the things you are truly great at: motivating people for a better pharo!

Oct. 23, 2013

Re: [Pharo-dev] Startup Preferences: An Alternative

by Sven Van Caekenberghe

This is really cool, is that in the image already ? What about plain HTTP repos ? On 23 Oct 2013, at 20:04, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > philippeback wrote >> Would be great to have a logout, in order to give images to other people >> without leaving credentials around. > > Done, added to world menu under the individual repo login options > > The way the logins work is that a file named .mcconfig is expected in the > general preferences folder with the format: > > [squeaksource] > user := 'me'. > password := 'pwd'. > [squeaksource3] > user := 'me'. > password = 'pwd'. > [smalltalkhub] > user := 'me'. > password := 'pwd'. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Startup-Preferences-An-Alternative-tp4713968p4716686.… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Oct. 23, 2013

VM acceptance tests

by Camillo Bruni

I am still struggling with the VM acceptance test. Currently we're loading Seaside and Moose, two very big projects which hopefully stress many parts of the VM. The problem is, that these two projects evolve by themselves, adding another axis of freedom which I would like to avoid. So is there an easy way to freeze a configuration and store it on our fileserver, so that we have a fixed reference? (Note, we use a 2.0 image) If we have that, I can even integrate the validation process into the travis build which should make contributions to the pharo-vm much easier...

Oct. 23, 2013

Re: [Pharo-dev] Startup Preferences: An Alternative

by Sean P. DeNigris

philippeback wrote > Would be great to have a logout, in order to give images to other people > without leaving credentials around. Done, added to world menu under the individual repo login options The way the logins work is that a file named .mcconfig is expected in the general preferences folder with the format: [squeaksource] user := 'me'. password := 'pwd'. [squeaksource3] user := 'me'. password = 'pwd'. [smalltalkhub] user := 'me'. password := 'pwd'. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Startup-Preferences-An-Alternative-tp4713968p4716686.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 23, 2013

Re: [Pharo-dev] Startup Preferences: An Alternative

by Sean P. DeNigris

Sean P. DeNigris wrote > "what's the minimum amount of code necessary to bootstrap into real > smalltalk?" I simplified even further, and use #startUp: to handle the actual preferences. The only thing the startup.st actually does is load the code via Metacello on the first run: StartupLoader default executeAtomicItems: { StartupAction name: 'Load DeNigrisPreferences' code: [ Gofer it url: 'http://smalltalkhub.com/mc/SeanDeNigris/DeNigrisPreferences/main'; package: 'DeNigrisPreferences-Core'; load ] runOnce: true }. Everything else is handled in the image. Enjoy! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Startup-Preferences-An-Alternative-tp4713968p4716685.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 23, 2013

Re: [Pharo-dev] Startup Preferences: An Alternative

by Sean P. DeNigris

philippeback wrote > I am looking at this configuration and had fun loading the Batcave thing. > What is this green area and slider on the right for? Cool! Ha ha, the batcave is full of experiments... the green widget is telling you that the system is up-to-date. It should turn red if there are Pharo updates available but not loaded. The other widget with the slider (which I don't think works so well, IIRC there is a bug in the slider interaction), well, ha ha, I read an article about how short an average human life actually is from the viewpoint of days remaining, which impacted me greatly, so it was supposed to be a little reminder about that. I think the slider was to play with different age projections and it was supposed to count down as the days go by... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Startup-Preferences-An-Alternative-tp4713968p4716684.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 23, 2013

Re: [Pharo-dev] How is this possible?

by Sean P. DeNigris

Marcus Denker-4 wrote > I will > -> commit an update where the code moves the temps to the method > -> then fix the compiler next week Are there issues for these? I want to track the status because the TWM port to 3.0 is on hold until it's fixed... ----- Cheers, Sean -- View this message in context: http://forum.world.st/How-is-this-possible-tp4713857p4716682.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 23, 2013

Re: [Pharo-dev] missing updates: 30503 30504

by Camillo Bruni

On 2013-10-23, at 16:06, Camillo Bruni <camillobruni(a)gmail.com> wrote: > On 2013-10-23, at 13:48, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> On Oct 23, 2013, at 10:52 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> On 2013-10-22, at 10:44, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>>>> For retracting files you need access to files.pharo.org. >>>>> >>>>> This is what should be written in the readme. >>>> >>>> BTW have you tried that you actually have access to the machine? >>>> Because I remember that it didn't work for you nor Esteban... >>> >>> >>> So stef, did you check that you can actually edit the file? >> >> I cannot access it but I least I know that I should not look for it. >> And next time if there is a problem I just stop integrated and continue hacking on my cool stuff and look smart. > > Why can't you access it? > What do you want instead? > How do we avoid this situation in the future? (happened already before a couple of times) Just to get something straight here: You have hardly something to complain... What you see is the tip of the iceberg. I spend roughly 1-2 hours per week maintaining all the jenkins instances with all the slaves and all the jobs that run (and there is Christoph to, regularly fixing and tweaking things all around). Now running around wild and screaming that everything does not work and is not documented is highly demotivating. Marcus and Esteban work on it on a daily basis. If maintaining jenkins were so much fun, you would do it, but you don't. So enjoy, and focus on the things you are truly great at: motivating people for a better pharo!

Oct. 23, 2013

Re: [Pharo-dev] Pharo on Mac OS X 10.9 Mavericks

by Eliot Miranda

Hi Sven, cc'ing squeak list cuz answer may be generally useful. On Wed, Oct 23, 2013 at 8:07 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Eliot, > > On 23 Oct 2013, at 14:59, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > Hi Sven, > > > > On Wed, Oct 23, 2013 at 5:52 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > On 23 Oct 2013, at 14:22, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > > Yeah, i was also exploring, why even if i do not touch image i got > like 3-5% CPU load. > > > What i found that it is in VM. Because i basicaly removed everything > in image, > > > and just left idle process, and still had such loads. > > > > Igor, some time ago you told me which thread inside the VM was doing > this, but maybe you forgot ;-) > > > > two different things. One is the idle process, in the image. This is > heavy-weight. It calls relinquishProcessorForMicroseconds: which does all > sorts of things, including system calls to poll for i/o. The other is the > poll thread in the Cog and Stack VMs. This simply sleeps for a > millisecond, wakes up and sets a variable, and then goes back to sleep. It > is relatively lightweight. > > > > I suspect the 3-5% is due to the former, not the latter. One way to > test would be to compare the interpreter VM against the Stack and Cog VMs > and see how much time the interpreter VM takes. If the interpreter VM also > takes a lot of time at idle, then the poll thread is not the culprit. > > Thanks for the answer, I think I understand, more or less. > > But #relinquishProcessorForMicroseconds: is primitive 230, so anything it > might be doing is done in the VM right ? Yes. > The only thing that can be done from the image level is to call it less > often, unless that would create problems. Right ? > Currently. But a better solution entirely would be to replace the mechanism with something that blocks until an event or i/o is possible. Then the VM would go to sleep when at idle instead of uselessly spinning. > What is the function of the poll thread then ? > In the Interpreter VM there is a counter, decremented on every backward branch or non-primitive send, that causes a check for interrupts when it reaches zero. The basic problem with such counters is that they either incur too much work or too much latency. Set the counter to a high value and latency increases. Set the counter too low and work increases. Further, if the program starts doing something time consuming in primitives (e.g. very large integer arithmetic operations) that reduces the frequency of counter decrements and the system can become unresponsive (because events are not being checked) for a long time, apparently locking up. In the Stack and Cog VMs execution is on a stack divided up into pages (because this allows sharing the stack between processes, and limits the amount of work done converting stack activations into context activations when more stack is needed). Every (non-primitive) method activation must check the current stack limit to avoid overflowing the current page. The stack limit can then be used as a "free" interrupt check. If the variable holding the stack limit is set to all ones every stack check fails (cuz the stack grow down). The stack overflow logic checks if the stack has really overflowed and if not, checks for events. Backward branch is modified to check the stack limit also. The poll thread periodically sets the stack limit variable to all ones, causing an event check soon there-after. This is much cheaper and much more regularly periodic than the counter approach. > Sven > > > > On 23 October 2013 13:52, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > Hi, > > > > > > This morning I upgraded my MacBook Air to Mac OS X 10.9 Mavericks. The > good new is that my trusty VM [1] is still working OK ! > > > > > > However, something seems to have changed regarding full screen mode: > it more or less works but there are two black bands and the window title > remains visible, it is as if it did not expand enough: > > > > > > <Screen Shot 2013-10-23 at 13.40.56.png> > > > > > > Which is a pity: I rely on this a lot to get more screen space on my > 13 inch screen and to work distraction free. > > > > > > I guess weâll have to wait for our hero Esteban to have a look. > > > > > > Also new is the focus on energy management and efficiency. Sadly Pharo > is flagged as using to much (look at the menu under the battery icon top > right and the energy tab in the activity monitor): > > > > > > <Screen Shot 2013-10-23 at 13.49.53.png> > > > > > > This is probably related to the busy thread running/polling every ms > or so inside the VM. > > > > > > I could turn these into issues. > > > > > > Sven > > > > > > [1] > > > > > > Virtual Machine > > > --------------- > > > /Users/sven/Develop/Smalltalk/Pharo.app/Contents/MacOS/Pharo > > > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > > > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > > > git://gitorious.org/cogvm/blessed.git Commit: > 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 > By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 > > > > > > Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< > > > VMMaker versionString git://gitorious.org/cogvm/blessed.git Commit: > 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 > By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 > > > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > > > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > > > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Igor Stasenko. > > > > > > > > > > > > -- > > best, > > Eliot > > > -- best, Eliot

Oct. 23, 2013

Re: [Pharo-dev] Pharo on Mac OS X 10.9 Mavericks

by Sven Van Caekenberghe

Hi Eliot, On 23 Oct 2013, at 14:59, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Sven, > > On Wed, Oct 23, 2013 at 5:52 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 23 Oct 2013, at 14:22, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > Yeah, i was also exploring, why even if i do not touch image i got like 3-5% CPU load. > > What i found that it is in VM. Because i basicaly removed everything in image, > > and just left idle process, and still had such loads. > > Igor, some time ago you told me which thread inside the VM was doing this, but maybe you forgot ;-) > > two different things. One is the idle process, in the image. This is heavy-weight. It calls relinquishProcessorForMicroseconds: which does all sorts of things, including system calls to poll for i/o. The other is the poll thread in the Cog and Stack VMs. This simply sleeps for a millisecond, wakes up and sets a variable, and then goes back to sleep. It is relatively lightweight. > > I suspect the 3-5% is due to the former, not the latter. One way to test would be to compare the interpreter VM against the Stack and Cog VMs and see how much time the interpreter VM takes. If the interpreter VM also takes a lot of time at idle, then the poll thread is not the culprit. Thanks for the answer, I think I understand, more or less. But #relinquishProcessorForMicroseconds: is primitive 230, so anything it might be doing is done in the VM right ? The only thing that can be done from the image level is to call it less often, unless that would create problems. Right ? What is the function of the poll thread then ? Sven > > On 23 October 2013 13:52, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > > > This morning I upgraded my MacBook Air to Mac OS X 10.9 Mavericks. The good new is that my trusty VM [1] is still working OK ! > > > > However, something seems to have changed regarding full screen mode: it more or less works but there are two black bands and the window title remains visible, it is as if it did not expand enough: > > > > <Screen Shot 2013-10-23 at 13.40.56.png> > > > > Which is a pity: I rely on this a lot to get more screen space on my 13 inch screen and to work distraction free. > > > > I guess weâll have to wait for our hero Esteban to have a look. > > > > Also new is the focus on energy management and efficiency. Sadly Pharo is flagged as using to much (look at the menu under the battery icon top right and the energy tab in the activity monitor): > > > > <Screen Shot 2013-10-23 at 13.49.53.png> > > > > This is probably related to the busy thread running/polling every ms or so inside the VM. > > > > I could turn these into issues. > > > > Sven > > > > [1] > > > > Virtual Machine > > --------------- > > /Users/sven/Develop/Smalltalk/Pharo.app/Contents/MacOS/Pharo > > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > > git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 > > > > Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< > > VMMaker versionString git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 > > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > > > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > -- > best, > Eliot

Oct. 23, 2013