On 25.02.2011 09:27, Jean-Louis Faucher wrote: > > There will be a portable ooRexxTry-GUI called "ooRexxTry.rxj" from > a student, which I will enclose in the next release of BSF4ooRexx, > which looks like the Windows ooRexxTry.rex, but has a few bells > and whistles more, and most importantly, it runs on all platforms > BSF4ooRexx is available (i.e. also on MacOSX for which BSF4ooRexx > got compiled to). > > > Is it something that could become like Object Rexx workbench ? I > remember you asked questions about API for debug... > I never had a chance to see this workbench in action, and I can't find > any doc about it. Except these lines from IBM site : > <<The Workbench supports, for example, multi-color trace output, > in-source debugging, tracepoints, step in, step out, step over, run to > cursor, a call stack, and inspect variables.>> Yes, these were available under IBM's Object REXX.
Unfortunately to this day ooRexx with the new (4.x) kernel has not yet gained any such APIs which are desperately needed, if a GUI-workbench is desired for ooRexx 4.x. > There is something which is mysterious to me : I read in several > places that the workbench supports ooRexx. But ooRexx has no API for > debug, so how the workbench can do all that ? The workbench was part of IBM's Object REXX and could not be opensourced by IBM for legal reasons. It works only for ooRexx 3.x, because it is dependent on the debug APIs. It cannot work on ooRexx 4.x unfortunately. As long as there is no debug API available for ooRexx 4.x there is no way, a comparable development environment could be possibly created! I think this is Rick's call, who is probably the only person able to put in a debug API efficiently into ooRexx 4.x. Maybe Rick can comment on his plans regarding adding a desparetely needed debug API to ooRexx 4.x (and maybe also a profiling API to thelp the ooRexx developers optimize their code). > > Ad intercepting trace-output: currently the trace output goes to > .error (.stderr) as are condition error messages. So ooRexxTry.rxj > will show both, trace and error output in the same window. It > would be interesting for a specific category of use-cases to > become able to intercept trace (log) output by having that go to > an own monitor ".trace", which may by default forward to the > .error monitor. If an own monitor like ".trace" existed, then it > would allow for redirecting to an own stream, such that trace > messages can be filtered with practically no overhead! > > Any comments on such an idea? > > > Sounds good to me. Maybe you should open an RFE and see if it will be > accepted ? Just entered a RFE, cf. <http://sourceforge.net/tracker/?func=detail&aid=3196233&group_id=119701&atid=684733>. > > My notes about this possible evolution : > > In RexxActivity::traceOutput, should change : > RexxObject *stream = getLocalEnvironment(OREF_ERRORNAME); > by > RexxObject *stream = getLocalEnvironment(OREF_TRACE); > > In CoreClasses.orx, should add : > .local~setentry('TRACE', .monitor~new(.stderr)) > .trace~objectname = "The TRACE monitor" Wow, that would be really great! ---rony P.S.: Sorry for my late answer, am on a conference trip with very bad access to e-mail. :(
------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
