Hi!

I've a problem debugging two processes which communicate over a
SharedQueue.  I wonder whether anybody out here can help or at least
confirm, that this is really a problem in Squeak.

Here's my situation: I've a morph which stores entered characters into a
SharedQueue object.  This morph obviously runs in the normal UI process.
Then I created another process which will read characters from that queue
and do some processing then.  As I'm far away from perfection, this things
are still buggy and often raise exceptions.

I can open the debugger and fix the bug but if I proceed or restart the
process the whole morphic UI stops working and when I press Alt-. to
interrupt the lock, the UI process was waiting in SharedQueue>>next.  

For me, this looks like the debugger doesn't resume the stopped process but
continues to execute the fixed code in the UI process which is WRONG.

Because of this, it's painful to debug because I always have to restart the
complete program and I'm suffering from the bad old edit/compile/test cycle
right now.


More details:  Last weekend I had the crazy idea to port a fairly old C
game to Squeak.  It's called Conquest (as may games) and I found it on some
old Amiga public domain diskette years ago.  It seems to be a C port of an
even older game written in Pascal or so - it's a simple console application
and everything else but object oriented.  Still at some time I like the
game and I decided to directly convert the C code and hack a Smalltalk
version into Squeak.  Unfortunately I underestimated the work needed but
after two weekends of work I finally have the complete game written in my
image.

To bring a console application to Squeak - to try this was actually my
initial motivation - I hacked together a simple ConsoleMorph which
implements a 80x25 black'n'white screen using a non proportional font.  It
features a #printf: and a #goto: method to emit C-formatted string
somewhere on its screen which is enough for Conquest.  But a console
application and an event driven application are fundamentally different in
its behavior.  Squeak is (sort-of) event driven, Conquest uses getchar() to
read in characters from the terminal.  But I wanted to do the translation
as close as possible to C so rewriting the program was no alternative
(Torge said, I wanted to go the hard way ;-) and I had to create a proper
console simulation within Squeak.

To solve the problem, my implementation forks the program after creating
the ConsoleMorph object and runs it as a second process.  Now the UI is
still responsive while the program waits for keyboard input.  I cannot
think about a simpler solution which uses just one process.   But I'm now
also suffering from the problem that I cannot really debug my code.

If you want to try it out yourself, I've uploaded my code to
www.3plus4.de/conquest.zip.  I wrote it for version 2.6.  As I'm using "[]
ensure: []" at one place it probably doesn't work with prior Squeaks.  You
can run the game by evaluating "CqGame run".  Make sure that the mouse is
over the ConsoleMorph.  There's no visual clue that it waits for input or
that it has the focus.  You can use "H" at most times to summon some help.
And I have to warn you that it doesn't run very well right now.  I did a
straight forward and manual translation of the already ugly C code and
didn't bother to refactor anything but some very basic things.  Conquest
will for example break if it comes to the first fight or after 4 turns when
you can buy new ships.  BTW, Conquest is a science fiction strategy game
where you have to conquer more planets than the ENEMY.


bye
--
Stefan Matthias Aust  //  Bevor wir fallen, fallen wir lieber auf.