- Pharo-dev - lists.pharo.org

[Pharo-project] Pharo 1.4 Tests-Unix - Build # 302 - Still Unstable!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

March 24, 2012

[Pharo-project] [update 1.4] #14408

by Marcus Denker

14408 ----- Issue 5525: Get rid of string comparison in MessageListBrowser and FlatMessageListBrowser http://code.google.com/p/pharo/issues/detail?id=5525 Issue 5524: StartupPreferences progress bar http://code.google.com/p/pharo/issues/detail?id=5524 -- Marcus Denker -- http://marcusdenker.de

March 24, 2012

Re: [Pharo-project] Needs help with hang images

by Max Leske

You could use MingW (for GDB): http://hamsterrepublic.com/ohrrpgce/GDB_on_Windows.html Max On 23.03.2012, at 14:55, Denis Kudriashov wrote: > Sorry, I forget to say that all run on Windows > > 2012/3/23 David T. Lewis <lewis(a)mail.msen.com> > On Fri, Mar 23, 2012 at 02:13:57PM +0400, Denis Kudriashov wrote: > > Hello. > > > > I have standalone application with UI which hangs sometime (very *rarely*). > > This application has many threads which interacts with server. > > All interactions with server and UI activity logged. > > > > But at hang state there are no new log entries. There are no server > > interactions. > > It looks like all VM block image stuff. ("alt ." not work too). > > Logs always finished at same position. I know where I should add extra > > logging which give me information before hang. > > > > So I need help. > > What information about system can help me? What code I should use? > > Is somebody has same problems? > > If this is Cog on Unix/Linux you can send SIGUSR1 to the VM to > cause it to print a diagnostic stack trace (the Smalltalk stacks) > to its output. That may give you a better idea of the source of > the problem. For example, from a Unix shell use "ps -f" to identify > the pid of the Cog VM process, and if the pid is 1234, then you can do > "kill -SIGUSR1 1234" and a stack trace will be printed to your terminal > window. (Note, a similar mechanism is present in OSProcess for use > with interpreter VMs). > > Dave > > > > > Application uses old cog VM (maybe one of first distributions from Eliot) > > and Pharo1.1. > > Application uses continuations actively. > > I want try updated VM. What version I should use? I need most reliable cog > > (not latest I think). > > >

March 24, 2012

Re: [Pharo-project] Needs help with hang images

by Denis Kudriashov

Sorry, I forget to say that all run on Windows 2012/3/23 David T. Lewis <lewis(a)mail.msen.com> > On Fri, Mar 23, 2012 at 02:13:57PM +0400, Denis Kudriashov wrote: > > Hello. > > > > I have standalone application with UI which hangs sometime (very > *rarely*). > > This application has many threads which interacts with server. > > All interactions with server and UI activity logged. > > > > But at hang state there are no new log entries. There are no server > > interactions. > > It looks like all VM block image stuff. ("alt ." not work too). > > Logs always finished at same position. I know where I should add extra > > logging which give me information before hang. > > > > So I need help. > > What information about system can help me? What code I should use? > > Is somebody has same problems? > > If this is Cog on Unix/Linux you can send SIGUSR1 to the VM to > cause it to print a diagnostic stack trace (the Smalltalk stacks) > to its output. That may give you a better idea of the source of > the problem. For example, from a Unix shell use "ps -f" to identify > the pid of the Cog VM process, and if the pid is 1234, then you can do > "kill -SIGUSR1 1234" and a stack trace will be printed to your terminal > window. (Note, a similar mechanism is present in OSProcess for use > with interpreter VMs). > > Dave > > > > > Application uses old cog VM (maybe one of first distributions from Eliot) > > and Pharo1.1. > > Application uses continuations actively. > > I want try updated VM. What version I should use? I need most reliable > cog > > (not latest I think). > > >

March 24, 2012

Re: [Pharo-project] Needs help with hang images

by Max Leske

I had such an image last week and I managed to get the stacks with GDB (this was on a Debian Linux. When trying the same on my Mac I had to force shutdown the machineâ¦ doesn't seem to work the same everywhereâ¦): $ gdb attach <pid> In case stdout/stderr are not redirected to a file, we redirect them to your shell. Else, skip to (*). (gdb) call (void) close(1) (gdb) call (void) close(2) Now, let's see which shell we are on: (gdb) shell tty /dev/ttyp1 <----- the result may be different (this is the whole point) (gdb) call (int) open("/dev/ttyp1", 2, 0) <----- set the right shell here $1 = 1 (gdb) call (int) open("/dev/ttyp1", 1, 0) <----- here too $2 = 2 (*) No, lets get some datapoints (gdb) call printCallStack() // prints the current active Smalltalk stack (gdb) call (int) printAllStacks() // prints all Smalltalk stacks gdb) bt // prints the C backtrace, i.e., the stack of the VM interpreter In case you use stdout/stderr redirected to files, you may need to flush to see the output: (gdb) call fflush(stderr) (gdb) call fflush(stdout) from: http://developer.apple.com/technotes/tn/tn2032.html http://minnow.cc.gatech.edu/squeak/533 HTH, Max On 23.03.2012, at 11:13, Denis Kudriashov wrote: > Hello. > > I have standalone application with UI which hangs sometime (very rarely). > This application has many threads which interacts with server. > All interactions with server and UI activity logged. > > But at hang state there are no new log entries. There are no server interactions. > It looks like all VM block image stuff. ("alt ." not work too). > Logs always finished at same position. I know where I should add extra logging which give me information before hang. > > So I need help. > What information about system can help me? What code I should use? > Is somebody has same problems? > > Application uses old cog VM (maybe one of first distributions from Eliot) and Pharo1.1. > Application uses continuations actively. > I want try updated VM. What version I should use? I need most reliable cog (not latest I think). > > Best regards, > Denis >

March 24, 2012

Re: [Pharo-project] Needs help with hang images

by David T. Lewis

On Fri, Mar 23, 2012 at 02:13:57PM +0400, Denis Kudriashov wrote: > Hello. > > I have standalone application with UI which hangs sometime (very *rarely*). > This application has many threads which interacts with server. > All interactions with server and UI activity logged. > > But at hang state there are no new log entries. There are no server > interactions. > It looks like all VM block image stuff. ("alt ." not work too). > Logs always finished at same position. I know where I should add extra > logging which give me information before hang. > > So I need help. > What information about system can help me? What code I should use? > Is somebody has same problems? If this is Cog on Unix/Linux you can send SIGUSR1 to the VM to cause it to print a diagnostic stack trace (the Smalltalk stacks) to its output. That may give you a better idea of the source of the problem. For example, from a Unix shell use "ps -f" to identify the pid of the Cog VM process, and if the pid is 1234, then you can do "kill -SIGUSR1 1234" and a stack trace will be printed to your terminal window. (Note, a similar mechanism is present in OSProcess for use with interpreter VMs). Dave > > Application uses old cog VM (maybe one of first distributions from Eliot) > and Pharo1.1. > Application uses continuations actively. > I want try updated VM. What version I should use? I need most reliable cog > (not latest I think).

March 24, 2012

Re: [Pharo-project] About 1.4 Release...

by StÃ©phane Ducasse

I'm working on cleaning ECompletion: now it works well in 1.4 So I guess that loading RBEngine and OB should make it. Now people should help. For 1.5 we will get nautilus. Stef > Ok, but that kind volunteer needs an image built the way they are told to do so. The convenience factor of having big stuff loaded into an image will attract users/testers. > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Frank Shearar [frank.shearar(a)gmail.com] > Sent: Friday, March 23, 2012 6:25 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] About 1.4 Release... > > On 23 March 2012 09:34, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Hi, >> >> We were discussing here about the 1.4 release... and my standpoint is: >> >> "What is on the Build Server will be the Release" >> >> For 1.4, this means that this image is the release image: >> >> https://ci.lille.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifac… >> >> possibly with more bugs fixed. >> >> the list is here: http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.4 >> >> It especially means that we will not load additional packages (RB, OB....), because then we should >> have used the resulting image already the last months and we did not. >> >> Is that what we want? or will people say "without refactorings, I will not use it?" > > I'd say "What is on the Build Server will be the Release" is exactly > the right thing to do, because it's the thing you've been testing. You > can have high confidence that the artifact will be stable, etc. Adding > in extra stuff increases the testing burden. > > Of course, you (you, or some kind volunteer) could have a job that > adds the various extras, and tests that Pharo+(stuff) image. > > frank > >

March 23, 2012

Re: [Pharo-project] Pharo and an old plotter

by Norbert Hartl

Pavel, that is really nice. I like those kind of projects (well, I hate them, too, because I don't find time to do that stuff). If you are looking for a new one. A port of moppy [1] to pharo would be cool. Then we could do things like this [2] from pharo. Norbert [1] http://dduino.blogspot.de/2011/10/moppy-playing-music-with-floppy-drives.ht… [2] http://www.youtube.com/watch?v=Xk_XaJ7gE4Q Am 22.03.2012 um 14:47 schrieb Pavel Krivanek: > Hi, > > I would like to mention one funny usage of Pharo. I have got an old > simple czech plotter from 1989 named XY4150. It is no secret that the > interactive environment of Smalltalk is ideal for controlling such > machines because it is very easy to send commands to it and experiment > with drawing capabilities. > > Even today such old hardware can find a real-life production > deployment. I currently use it to write owner names to plastic cards > with pre-printed bar codes by a special pen destined to sign credit > cards :-) > > It is controlled by Arduino however LPT can be used too. > > Btw. there was several interesting czech plotters. The most > interesting one was named Merkur Alfi. It was a construction set for > children with two stepper motors and one relay. > http://www.youtube.com/watch?v=yUmFYzyL9eo > > And they started to sell it recently again so if you are looking for > some cool hardware for your children, you can look here: > http://www.merkurtoys.cz/vyrobky/plotrovy-zapisovac-alfi-z-merkuru[1] > But it's about 139â¬ so it's quite expensive... > > Cheers, > -- Pavel > <pharo-plotter2.JPG>

March 23, 2012

[Pharo-project] Pharo Kernel Reload Tests-Unix - Build # 32 - Still unstable!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

March 23, 2012

Re: [Pharo-project] About 1.4 Release...

by Schwab,Wilhelm K

Ok, but that kind volunteer needs an image built the way they are told to do so. The convenience factor of having big stuff loaded into an image will attract users/testers. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Frank Shearar [frank.shearar(a)gmail.com] Sent: Friday, March 23, 2012 6:25 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] About 1.4 Release... On 23 March 2012 09:34, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > We were discussing here about the 1.4 release... and my standpoint is: > > "What is on the Build Server will be the Release" > > For 1.4, this means that this image is the release image: > > https://ci.lille.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifac… > > possibly with more bugs fixed. > > the list is here: http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.4 > > It especially means that we will not load additional packages (RB, OB....), because then we should > have used the resulting image already the last months and we did not. > > Is that what we want? or will people say "without refactorings, I will not use it?" I'd say "What is on the Build Server will be the Release" is exactly the right thing to do, because it's the thing you've been testing. You can have high confidence that the artifact will be stable, etc. Adding in extra stuff increases the testing burden. Of course, you (you, or some kind volunteer) could have a job that adds the various extras, and tests that Pharo+(stuff) image. frank

March 23, 2012