March 2012 - Pharo-dev - lists.pharo.org

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 23, 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 23, 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 23, 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 23, 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

Re: [Pharo-project] Little challenge for you

by Schwab,Wilhelm K

Stef, This reminds me of a Dolphin feature called IDE extensions. Presenters trigger an event (IIRC off of their class) when the open, and menus and commands trigger events when they are about to do something interesting. One can then easily add to an opening menu to add commands to it. As a silly but relaxing example, I had an extension that played a random sound clip when a debugger opens. It was easy with extensions, because I simply watched Debugger class for #open:aDebugger or whatever it is called, and then play the clip. I have library of short/satirical clips that can add humor to debugging sessions. More pragmatically, I had tools to help with creating acessors, compound instance creation methods, etc. It can be a very powerful feature, and all it takes is trigging some events to enable it. Dolphin makes the (IMHO **HUGE**) mistake of enabling extensions as they load. For the sake of building a new image from packages, the extensions should load and then be explicitly activated once a stable new image exists and has received a backup copy in case changes to the new system cause havoc with the operation of the extension. As was quoted recently, "if your ideas are any good, you will have the cram them down people's throats." :) Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Friday, March 23, 2012 6:09 AM To: pharo-project(a)lists.gforge.inria.fr Development Subject: [Pharo-project] Little challenge for you Hi guys I would love to be able to get the gofer expression automatically from the ui. I click on a package and I ask load me expression and pouf I got a gofer expressions :) Anybody wants to improve our tools? Stef

March 23, 2012

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

by Schwab,Wilhelm K

Marcus, I like the idea of "downstream projects" but the dark side is that one won't know how much testing they have received. For one thing, the 1.4 Seaside image does not support Shout in system browsers (it works in the debugger) - 1.4 does have Shout everywhere. Someone suggested that the build scripts are not right, but my idealistic side asks why the downstream Seaside is not simply the latest 1.4 with Seaside loaded to save everybody time. I guess what I am saying is that you can pay now or pay later. Looking deeper, the pay later approach (which is what we are using) is that Pharo itself is consistent, but the end user gets stuck finding the things that would be found if Pharo were built and used (during development) in a more full featured way. I really miss the old web image, and would like to see a clean Pharo for those who must (Stef clearly finds it important - who am I to stand in his way), and a heavily advertised more fully featured image with RB, Seaside, Magritte, etc. loaded into it from the start. These are good tools that we want to promote, so we should get them tested as we go vs. dumping it on the user later. Re the RB, I enjoy having it, I choose not to use it very much. Older code accumulates lots of comments that have proven to save my skin in many situations. The RB's formatting has come a long way, but it still makes a mess of treasured resource in my old code. Refactorings that do not have to touch the code are great, and I am often willing to exploit the RB in new code that has not had time to accumulate valuable comments in cascades and other weird places. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Marcus Denker [marcus.denker(a)inria.fr] Sent: Friday, March 23, 2012 5:34 AM To: Pharo Development Subject: [Pharo-project] About 1.4 Release... 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?" Marcus -- Marcus Denker -- http://marcusdenker.de

March 23, 2012