Is this possible? I really hope it is. You see, some of my design decisions is based on the procedure where I need the actual J Window showing so I can step through the code line by line. Query the current values and understanding what the problem is with the data.
Around 98% of problems that I encounter in production systems are bad data. There are even cases that users are even able to enter data that they should not be able to enter. Unfortunately, without J Window in your control ... it's next to impossible to do so. Being able to debug remotely without stopping the server and being able to pick which instance to debug is something that would be very-very helpful. :) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oleg Kobchenko Sent: Friday, February 16, 2007 2:32 PM To: General forum Subject: [Jgeneral] Remote J Debugging That brings about an interesting idea: Remote J Debugging. Useful for command-line and headless jconsole processes like CGI. GUI Debugger is implemented in J. There is also J remoting interface via sockets. So it would be possible to debug a headless instance of J with a GUI instance of J communicating with this remoting. Would be also a good "real-world" example of remoting J programming. Implementation note: existing debugger is split into two parts: client and server. Client sets debugging mode and when debug condition occurs, attaches (starts or resumes) to the server, the server showing the GUI. They communicate with a protocol to update GUI and pass GUI events that control debugging settings and commands like "step" to the client. --- Alex Rufon <[EMAIL PROTECTED]> wrote: > Arrrgggghhh! Old habits really die hard. My J601 workspace has the > allowed x. and y. enabled. You see, I still have running installation of > J504 in Vietnam, Saipan, Taiwan, Dongguan and the Philippines that I am > supporting. I really want to upgrade them but the Powers That Be is > playing the Don't Fix the Not Broken card. :) > > Sorry about the RAR thingy. I was having trouble uploading and I don't > want to clog Chris email that I double compressed it. > > About the Session Window, this is something that I picked up from Chris > Burke. I believe that this is how they envisioned J will be used during > testing/development cycle. I actually find this handy. You see, I have > implementation of J running the Web, App, database servers (3-Tier > Systems) and on the Client. I designed my J .NET wrapper for servers in > such a way that when I need to debug a code in production, I can easily > switch the whole server side system to run on a single instance of J ... > instead of the normal multiple instances. This way, I can actually catch > all calls and execution on one Session Window. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David Mitchell > Sent: Thursday, February 15, 2007 10:38 PM > To: General forum > Subject: Re: [Jgeneral] J.NET Guide > > Alex Rufon wrote: > > The file download for the "Real World Example" is now working. :) > > > > I downloaded the zip and (after a brief tussle with unrar) installed it. > I > tried running the program > D:\Projects\J.NET\timedeviceviewer\bin\Debug\timedeviceviewer.exe and > got: > > |spelling error > | 10000 100 100 base y. > | ^ > | dateencode=: 3 :0 > |[-343] D:\Projects\J.NET\timedeviceviewer.ijs > > I do like the Session Server window. It makes debugging simpler. ________________________________________________________________________ ____________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
