- Pharo-dev - lists.pharo.org

Re: [Pharo-project] idle VM runs at constant 3-5% CPU load

by Nicolas Cellier

Hehe, that reminds me time when i had clients using a st-80 app on a server workstation. At that time, MVC UI was still polling, with some kind of heart beat for relaxing CPU cycles... But RAM was not cheap and was the true bottleneck, our app already did already consume a few Mbytes. Naturally users did notice that they would not be swapped out of memory if they shake the mouse. So they more or less instinctively shake the mouse and we got lot of complaints from system engineers. They could not understand how a modern application could waste so many cycles for nothing and be such a bad citizen... I see that many years later, despite our (late) conversion to event driven UI, we still have some remnant ghosts... Nicolas 2012/6/4 Sven Van Caekenberghe <sven(a)beta9.be>: > Yes, we should at least understand why this happens. > > BTW, another related question is: when running headless, do we actually need those 6 processes ? > > Sven > > On 04 Jun 2012, at 21:56, Igor Stasenko wrote: > >> i just wonder, what takes so much CPU time, even if it completely idle... >> >> >> 4831- Â NBCog Â Â Â Â 4.8 >> 51519- NBCog Â Â Â Â 3.5 >> >> if i kill a UI process, the load goes down to 2.5-3 % ... >> still too much. >> >> i would like to know how we can minimize this. >> The reason why i concerned is straightly pragmatic: extending battery life.. >> >> i found that if i run completely on battery.. it depleting quite fast >> with VM running (and i don't do anything just coding, i.e not running >> benchmarks, but more thinking and typing). >> >> -- >> Best regards, >> Igor Stasenko. >> > >

June 4, 2012

Re: [Pharo-project] idle VM runs at constant 3-5% CPU load

by Igor Stasenko

On 4 June 2012 22:07, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Yes, we should at least understand why this happens. > > BTW, another related question is: when running headless, do we actually need those 6 processes ? > well, here ones: 1. Delay 2. Event fetcher 3. Low space watcher 4. UI process 5. finalization process 6. idle process well, i did following: InputEventFetcher shutDown. Delay stopTimerEventLoop. WeakArray finalizationProcess terminate. Processor activeProcess terminate. and still having constant 2.3-2.4% CPU load.. there's only idle process left.. > Sven -- Best regards, Igor Stasenko.

June 4, 2012

Re: [Pharo-project] idle VM runs at constant 3-5% CPU load

by Sven Van Caekenberghe

Yes, we should at least understand why this happens. BTW, another related question is: when running headless, do we actually need those 6 processes ? Sven On 04 Jun 2012, at 21:56, Igor Stasenko wrote: > i just wonder, what takes so much CPU time, even if it completely idle... > > > 4831- NBCog 4.8 > 51519- NBCog 3.5 > > if i kill a UI process, the load goes down to 2.5-3 % ... > still too much. > > i would like to know how we can minimize this. > The reason why i concerned is straightly pragmatic: extending battery life.. > > i found that if i run completely on battery.. it depleting quite fast > with VM running (and i don't do anything just coding, i.e not running > benchmarks, but more thinking and typing). > > -- > Best regards, > Igor Stasenko. >

June 4, 2012

Re: [Pharo-project] [update 2.0] #20110

by StÃ©phane Ducasse

Ok I know these ones and I will try to allocate some time. stef On Jun 4, 2012, at 7:35 PM, Esteban Lorenzano wrote: > 20110 > ----- > > Issue 5977: Rpackage may not handle well method removal in traits > http://code.google.com/p/pharo/issues/detail?id=5977 > > Issue 5997: Classes that implement unsafe equals > http://code.google.com/p/pharo/issues/detail?id=5997 > > > Just 3 rpackage tests in yellow now... although this is not the end of history, just the beginning, we are getting closer :)

June 4, 2012

[Pharo-project] idle VM runs at constant 3-5% CPU load

by Igor Stasenko

i just wonder, what takes so much CPU time, even if it completely idle... 4831- NBCog 4.8 51519- NBCog 3.5 if i kill a UI process, the load goes down to 2.5-3 % ... still too much. i would like to know how we can minimize this. The reason why i concerned is straightly pragmatic: extending battery life.. i found that if i run completely on battery.. it depleting quite fast with VM running (and i don't do anything just coding, i.e not running benchmarks, but more thinking and typing). -- Best regards, Igor Stasenko.

June 4, 2012

Re: [Pharo-project] Trouble loading XML RPC

by StÃ©phane Ducasse

On Jun 4, 2012, at 4:34 PM, Noury Bouraqadi wrote: > Hi GermÃ¡n, > > Thanks for your answer. Indeed, I tried with Pharo 1.4. And had the same issues. > My plan is to port XML RPC to Pharo 2. I'm interested on your work with Zinc. > Where is it available ? > > Can I get write access grant to the repo, so I can upload any improvement I do ? > > What I wanted to do is to cut off everything not XML RPC and complete based on sUnit tests. > BTW, any simple way to load all SUnit tests for all packages ? load: {'Tests'} ? > > I started analyzing the ConfigurationOfxxx classes. > ConfigurationOfXMLSupport includes some references that I would like to have some hints on them (where they are used): ConfigurationOfXMLSupport is a bad example to me it is not good to have all the clients of XML groups. Normally it is much better to have a nice configuration for Opax Sixx Pastell separated. > - Grease > - Opax > - Pastell > - SiXX > - XML-Observable > > Thanx, > Noury > > On 3 juin 2012, at 17:26, garduino wrote: > >> Hi: >> >> Sorry the late answer.... >> >> If you take an 1.4 stock image, and evaluates (as is commented on >> http://code.google.com/p/pharo-xmlrpc/) >> >> Gofer it >> url: 'http://ss3.gemstone.com/ss/XMLRPC'; >> package: 'ConfigurationOfXMLRPC'; >> load. >> >> and then: >> >> >> (ConfigurationOfXMLRPC project version: '1.0-Beta4') load: 'All'. >> >> the whole stuff should load. >> >> I noticed an error: >> >> This package depends on the following classes: >> TranscriptStream >> You must resolve these dependencies before you will be able to load these >> definitions: >> isTranscriptStream >> >> (May be another thing changed in Pharo that I need to know and fix, press >> proceed to load anyway). >> >> But the bad new is that in 1.4 I've some errors on tests, mainly a serious >> one in server that freeze the image, caution. However, the XMLRPC Client >> seems to work. >> >> XMLRPC is always in my to-do list but a project in what I can invest only a >> portion of my limited free time. >> >> The latest new was that I adapted the Client to use with Zinc, but need >> still to make the same thing with the server, then all xmlrpc should install >> and run in a stock image, without need Komanche for example. >> >> With respect to Pharo 2.0 I can't help, not tried yet. >> >> HTH. >> GermÃ¡n. >> >> >> >> >> >> -- >> View this message in context: http://forum.world.st/Trouble-loading-XML-RPC-tp4632653p4633037.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > Noury > -- > http://twitter.com/#!/NouryBouraqadi > http://www.kroobe.com/profile/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 > > > >

June 4, 2012

Re: [Pharo-project] STDIO on Win

by Ben Coman

Not sure if this is applicable but I bumped into an article [1] which seems to provide a way to get StdIn/StdOut working. The requirement for WSH 5.6 would seems to be covered as [2] is dated 2000 and talks about 5.6 being preinstalled in Whistler, which was development codename for XP - which should cover pretty much everyone. I had got annoyed at Pharo-1.4-one-click.bat leaving a console window open when starting Pharo 1.4, so I re-implemented this as Pharo-1.4-one-click.vbs using Pharo-1.4-one-click.sh as a template. I have attached this to Issue #6020 [3]. [1] http://technet.microsoft.com/en-us/library/ee156605.aspx [2] http://msdn.microsoft.com/en-us/library/ms974613.aspx [3] http://code.google.com/p/pharo/issues/detail?id=6020 Igor Stasenko wrote: > On 21 May 2012 19:01, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >> On Sun, May 20, 2012 at 6:52 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> On 21 May 2012 03:29, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> On 21 May 2012 02:16, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> >>>>> On Sun, May 20, 2012 at 4:59 PM, Igor Stasenko <siguctua(a)gmail.com> >>>>> wrote: >>>>> >>>>>> On 20 May 2012 21:34, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>>>> >>>>>>> Hi Torsten, >>>>>>> >>>>>>> On Sun, May 20, 2012 at 11:51 AM, Torsten Bergmann <astares(a)gmx.de> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> havent yet played with the latest stdin/stdout stuff. >>>>>>>> Does this already work on Windows? >>>>>>>> >>>>>>>> At least I tried >>>>>>>> >>>>>>>> FileStream stdout nextPutAll: 'Yopla' >>>>>>>> >>>>>>>> in the latest 2.0 after starting Pharo-2.0-one-click.bat. >>>>>>>> Gives an error (write failed). >>>>>>>> >>>>>>>> Any comments? >>>>>>>> >>>>>>> It works in my console VMs. If you download >>>>>>> >>>>>>> e.g. http://www.mirandabanda.org/files/Cog/VM/VM.r2550/cogwin.zip you >>>>>>> need >>>>>>> to run CroquetConsole.exe in a DOS or Cygwin window. Using the >>>>>>> normal >>>>>>> VM >>>>>>> does *not* work, since that's the way Windows is "designed". >>>>>>> >>>>>>> >>>>>> Nope. It just requires some work :) >>>>>> >>>>> Come on :) The program opening up a completely different console isn't >>>>> what >>>>> I'd call working. And if the program is in a pipe ist must stay in a >>>>> pipe. >>>>> Its an easy thing to have a console VM, e.g. run from a script. >>>>> >>>>> >>>>> >>>> Here, what i found (windoze 7/ gcc 4.6.1). >>>> >>>> Test code (test.c) - note the entry point is WinMain() , not main() : >>>> --------------------- >>>> #include <windows.h> >>>> #include <stdio.h> >>>> >>>> int APIENTRY WinMain( >>>> HINSTANCE hInstance, >>>> HINSTANCE hPrevInstance, >>>> LPSTR lpCmdLine, >>>> int nCmdShow >>>> ) >>>> { >>>> FILE *f; >>>> STARTUPINFO info; >>>> GetStartupInfo( &info); >>>> >>>> >>>> >>>> f = fopen("test.out","w"); >>>> >>>> fprintf(f, "stdin: %d stdout: %d stderr: %d\n", info.hStdInput , >>>> info.hStdOutput, info.hStdError); >>>> >>>> fprintf(f, "STD handles: stdin: %d stdout: %d stderr: %d\n", >>>> GetStdHandle(STD_INPUT_HANDLE) , GetStdHandle(STD_OUTPUT_HANDLE) , >>>> GetStdHandle(STD_ERROR_HANDLE)); >>>> >>>> fclose(f); >>>> return 0; >>>> } >>>> --------------------- >>>> >>>> >>>> gcc test.c >>>> >>>> >>>> Running from mingw bash shell: >>>> >>>> a.exe >>>> >>>> stdin: 11 stdout: 23 stderr: 27 >>>> STD handles: stdin: 11 stdout: 23 stderr: 27 >>>> >>>> a.exe < test.c >>>> >>>> >>>> stdin: 168 stdout: 23 stderr: 27 >>>> STD handles: stdin: 168 stdout: 23 stderr: 27 >>>> >>>> a.exe | less >>>> >>>> stdin: 11 stdout: 328 stderr: 27 >>>> STD handles: stdin: 11 stdout: 328 stderr: 27 >>>> >>>> Running from cmd shell: >>>> >>>> a.exe >>>> >>>> stdin: -1 stdout: -1 stderr: -1 >>>> STD handles: stdin: 3 stdout: 39 stderr: 15 >>>> >>>> a.exe < test.c >>>> >>>> stdin: -1 stdout: -1 stderr: -1 >>>> STD handles: stdin: 80 stdout: 39 stderr: 15 >>>> >>>> a.exe | more >>>> >>>> stdin: -1 stdout: -1 stderr: -1 >>>> STD handles: stdin: 3 stdout: 108 stderr: 15 >>>> >>>> Running from explorer: >>>> >>>> stdin: -1 stdout: -1 stderr: -1 >>>> STD handles: stdin: 3 stdout: 7 stderr: 11 >>>> >>>> >>>> ***** >>>> Now, if i compile with: >>>> >>>> gcc test.c -mwindows >>>> >>>> >>>> under bash : >>>> >>>> a.exe >>>> >>>> stdin: 11 stdout: 23 stderr: 27 >>>> STD handles: stdin: 11 stdout: 23 stderr: 27 >>>> >>>> under cmd >>>> >>>> stdin: -1 stdout: -1 stderr: -1 >>>> STD handles: stdin: 3 stdout: 39 stderr: 15 >>>> >>>> from explorer: >>>> >>>> stdin: 0 stdout: 65537 stderr: 0 >>>> STD handles: stdin: 0 stdout: 0 stderr: 0 >>>> >>>> >>>> Conclusion: >>>> - do not use -mwindows >>>> >>> ehh.. if not used, it will open annoying console window, since >>> -mconsole is default... >>> however, as you can see, if you run exe from shell, the handles are there. >>> So, you can use single binary (compiled with -mwindows) for both >>> shell/explorer interaction, >>> and you can actually detect where it runs from by checking contents of >>> STARTUPINFO struct. >>> >> If you can figure out how to suppress the annoying console window then I'd >> use a single executable. >> >> > please read my post again. i said that binary compiled with -mwindows > can be used both for console and explorer interaction(s). > all you need is to rebind std handles to C .. btw there's actually > already parts of code which > using GetStdHandle(): > > void SetupStderr() > { TCHAR tmpName[MAX_PATH+1]; > > *stderrName = *stdoutName = 0; > /* re-open stdout && stderr */ > GetTempPath(MAX_PATH,tmpName); > if(GetStdHandle(STD_ERROR_HANDLE) == INVALID_HANDLE_VALUE) > { > GetTempFileName(tmpName,TEXT("sq"),0,stderrName); > freopen(stderrName,"w+t",stderr); > } > else *stderrName = 0; > > if(GetStdHandle(STD_OUTPUT_HANDLE) == INVALID_HANDLE_VALUE) > { > GetTempFileName(tmpName,TEXT("sq"),0,stdoutName); > freopen(stdoutName,"w+t",stdout); > } > else *stdoutName = 0; > } > > ---- > but it looks like there is no callers and it does redirection if > handles are invalid. > > if they are valid, i think they should be already set up correctly > and if not, in the link which i put first in this topic, it is clear > how to do it: > > (http://dslweb.nwnexus.com/~ast/dload/guicon.htm) > > // redirect unbuffered STDOUT to the console > > lStdHandle = (long)GetStdHandle(STD_OUTPUT_HANDLE); > > hConHandle = _open_osfhandle(lStdHandle, _O_TEXT); > > fp = _fdopen( hConHandle, "w" ); > > *stdout = *fp; > > setvbuf( stdout, NULL, _IONBF, 0 ); > ------------- > so, if VM runs from console, there should be an access to its > stdin/out/err as you normally expect from posix environment. > > if VM started from explorer -> there will be no stdin/out/err handles > bound to process, then we can simply redirect > all to /dev/null or to some file, like SetupStderr() function does. > (http://stackoverflow.com/questions/313111/dev-null-in-windows) > >

June 4, 2012

[Pharo-project] [update 2.0] #20110

by Esteban Lorenzano

20110 ----- Issue 5977: Rpackage may not handle well method removal in traits http://code.google.com/p/pharo/issues/detail?id=5977 Issue 5997: Classes that implement unsafe equals http://code.google.com/p/pharo/issues/detail?id=5997 Just 3 rpackage tests in yellow now... although this is not the end of history, just the beginning, we are getting closer :)

June 4, 2012

Re: [Pharo-project] Next step in cleaning DataStream

by Damien Cassou

On Mon, Jun 4, 2012 at 6:09 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > I think it is a good proposal. Then it can be in separate package or as part > of MC package. I would put DataStream and its friends within the monticello package, and prepend MC to their names. Then, you can clean the resulting classes if you want to. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 4, 2012

Re: [Pharo-project] Next step in cleaning DataStream

by Pavel Krivanek

4. 6. 2012 v 17:58, Mariano Martinez Peck <marianopeck(a)gmail.com>: > So, so far we have removed SmartRefStream, deprecated ReferenceStream and integrated Fuel. The ONLY remaining user for DataStream is Monticello. We do not want to replace that yet because Fuel may still change the format and we do not want to break monticello versions. But, my question is now...should we clean DataStream and assume its only usage will be the definitions of Monticello? becuase I true, I think we may be able to remove DiskProxy and all its users, togethet with lots of methods like #objectForDataStream: > > what do you think? I think it is a good proposal. Then it can be in separate package or as part of MC package. -- Pavel > > -- > Mariano > http://marianopeck.wordpress.com >

June 4, 2012