Re: [Oorexx-devel] Playing with the stream library in Rick's sandbox

2008-06-19 Thread Rick McGuire
Miesfeld [EMAIL PROTECTED] wrote: On Thu, Jun 19, 2008 at 8:07 AM, Rick McGuire [EMAIL PROTECTED] wrote: See my comments below. On Thu, Jun 19, 2008 at 10:08 AM, Mark Miesfeld [EMAIL PROTECTED] wrote: ... I just took out the position--; line All of those look reasonable. Thanks

Re: [Oorexx-devel] The new stream library

2008-06-22 Thread Rick McGuire
a simple test that can reproduce this, or does it require the full test suite? Rick On Sun, Jun 22, 2008 at 5:00 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: On Sun, Jun 22, 2008 at 12:26 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: On Sun, Jun 22, 2008 at 12:24 PM, Rick McGuire [EMAIL PROTECTED] wrote

Re: [Oorexx-devel] Getting the test framework to run: parse source

2008-06-24 Thread Rick McGuire
Yes, that looks like the correct fix. Rick On Tue, Jun 24, 2008 at 12:42 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: Thought I'd start a new thread. The next stumbling block in getting the ooTest framework to run is parse source in a ::requires file. Here is a simple test case: /*

Re: [Oorexx-devel] Some individual tests now passing in the Sandbox

2008-06-26 Thread Rick McGuire
] wrote: This command line pegs the CPU and hangs: E:\work.ooRexx\3.x\interpreter.rick\Win32Dbg.\rexx \work.ooRexx\ooRexxUnit\3.x\testOORexx.rex -R ooRexx\base\runtime.objects -U runtime.objects only has the environmentEntries.testGroup -- Mark Miesfeld On Thu, Jun 26, 2008 at 3:13 AM, Rick

Re: [Oorexx-devel] Some individual tests now passing in the Sandbox

2008-06-26 Thread Rick McGuire
Ok, strange,I just did an svn up to pick up all of your latest changes, and now SYSSLEEP is failing for me! Rick On Thu, Jun 26, 2008 at 12:06 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 8:46 AM, Rick McGuire [EMAIL PROTECTED] wrote: Ok, this one was definitely

Re: [Oorexx-devel] Some individual tests now passing in the Sandbox

2008-06-26 Thread Rick McGuire
, 2008 at 3:13 AM, Rick McGuire [EMAIL PROTECTED] wrote: Which ones are hanging? I can start chasing those next. Your commit fixed the ones I had run into. This one still hangs, might have a different root cause. It pegs the CPU so it looks like an infinite loop also: C:\work.ooRexx\3.x

Re: [Oorexx-devel] The BEEP.testGroup

2008-06-26 Thread Rick McGuire
Yes, that's one of the implications of the new APIs and the type routines/methods. A lot of argument errors will get trapped before the target is even called and will result in more specific errors than the generic Invalid call to routine error 40. Rick On Thu, Jun 26, 2008 at 8:26 PM, Mark

Re: [Oorexx-devel] The BEEP.testGroup

2008-06-26 Thread Rick McGuire
Although I see one problem with the messageit should not be saying argument in METHOD. I think this is just a problem with the message text. Rick On Thu, Jun 26, 2008 at 8:29 PM, Rick McGuire [EMAIL PROTECTED] wrote: Yes, that's one of the implications of the new APIs and the type

Re: [Oorexx-devel] The BEEP.testGroup

2008-06-26 Thread Rick McGuire
I changed my mind. Switching to the generic 88 messages seemed the more consistent thing to use. Rick On Thu, Jun 26, 2008 at 8:39 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 5:30 PM, Rick McGuire [EMAIL PROTECTED] wrote: Although I see one problem with the message

Re: [Oorexx-devel] Solaris and Linux issues.

2008-06-27 Thread Rick McGuire
On Fri, Jun 27, 2008 at 10:17 AM, Mark Miesfeld [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 9:03 PM, Alex Bochannek [EMAIL PROTECTED] wrote: Hi Alex, Has anybody had a chance to look at the Solaris problem I reported a few weeks ago? I just installed 3.2.0 on Linux and there aren't any

[Oorexx-devel] Merging trunk changes into my sandbox

2008-06-27 Thread Rick McGuire
In order to merge my sandbox changes back into trunk, we need to merge any change made to trunk since my sandbox branch was created into my sandbox. I'm merging in the kernel changes, but there are a number of changes to makefiles, unix build artifacts, the installer, etc. That I was not

Re: [Oorexx-devel] Some info on the new APIs? RexxPackageEntry, etc.

2008-06-28 Thread Rick McGuire
On Sat, Jun 28, 2008 at 4:36 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: On Sat, Jun 28, 2008 at 1:02 PM, Rick McGuire [EMAIL PROTECTED] wrote: Well, one way is to use the ::REQUIRES directive with the LIBRARY option. However, there's a compatibility feature I built in so that code that uses

Re: [Oorexx-devel] Some info on the new APIs? RexxPackageEntry, etc.

2008-06-28 Thread Rick McGuire
: On Sat, Jun 28, 2008 at 3:00 PM, Rick McGuire [EMAIL PROTECTED] wrote: It's two, two directives in one! A pesking missing return instruction caused this ::requires to function both as a library loader and a normal ::REQUIRES (sigh). ;-) It works well now after your commit. Both forms. Sort

Re: [Oorexx-devel] A little help with rxqueue

2008-06-28 Thread Rick McGuire
Ok, I've got this one fixed now. Rick On Sat, Jun 28, 2008 at 7:51 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: I get a could not find routine RXQUEUE error where things are using rxqueue() [error] [20080628 16:40:55.381000] Test: TEST_07COPYPASTE Class: Clipboard.testGroup File:

Re: [Oorexx-devel] Development set-up

2008-06-28 Thread Rick McGuire
MS Visual C++ SVN of some flavor Apache Xerces Apache Xalan That's really all you need. There's not requirement for anything from cygwin that I can think of. Rick On Sat, Jun 28, 2008 at 9:04 PM, Dan Carter [EMAIL PROTECTED] wrote: I did find the list. I am preparing WinXP as a workstation

Re: [Oorexx-devel] Development set-up

2008-06-28 Thread Rick McGuire
] wrote: I notice references to Docbook. Is that something I will need? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick McGuire Sent: Saturday, June 28, 2008 19:11 To: Open Object Rexx Developer Mailing List Subject: Re: [Oorexx-devel

Re: [Oorexx-devel] Development set-up

2008-06-28 Thread Rick McGuire
yep, that should be fine. On Sat, Jun 28, 2008 at 9:16 PM, Dan Carter [EMAIL PROTECTED] wrote: You are correct. My C++ on windows came with Visual Studio .NET. Will that be sufficient? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick McGuire

Re: [Oorexx-devel] Development set-up

2008-06-29 Thread Rick McGuire
Dan, Even though it's in a bit of a transitional stage right now, I think you would be best off starting your work from the current trunk. The interface between the portable code and the platform has changed significantly, and you'd end up having to do things twice. If you are planning on using

[Oorexx-devel] A suggestion for improving the unit tests for handling syntax errors.

2008-07-01 Thread Rick McGuire
Mark, I was looking at what you've done for processing syntax errors in the CONSTANT directive test group, and I have some suggestions that might make these types of tests easier to manage. To start with, you can completely eliminate the need to write this to a file by using the new package

Re: [Oorexx-devel] A suggestion for improving the unit tests for handling syntax errors.

2008-07-01 Thread Rick McGuire
It should still be available in the condition traceback information, just like you're doing with assertion failures. Rick On Tue, Jul 1, 2008 at 4:40 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: On Tue, Jul 1, 2008 at 11:29 AM, Rick McGuire [EMAIL PROTECTED] wrote: I was looking at what you've

Re: [Oorexx-devel] A suggestion for improving the unit tests for handling syntax errors.

2008-07-01 Thread Rick McGuire
:15 PM, Rick McGuire [EMAIL PROTECTED] wrote: Realized I didn't answer all of your questions. The other new class is the Routine class, which decouples Routines from Methods. Previously, a ::ROUTINE directive created a Method objectnow it creates a Routine object. You could also have

Re: [Oorexx-devel] Where are we at with running unit tests?

2008-07-02 Thread Rick McGuire
Mark, I'm curious...is the clipboard timing problem a new problem on trunk, or did it occur on 3.2.0 also? I'll explain why I'm asking once I have your answer. Rick On Wed, Jul 2, 2008 at 5:56 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: On Wed, Jul 2, 2008 at 1:48 PM, Chip Davis [EMAIL

Re: [Oorexx-devel] Where are we at with running unit tests?

2008-07-03 Thread Rick McGuire
: On Wed, Jul 2, 2008 at 3:35 PM, Rick McGuire [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Cool! ... starting showing up now because the calls to native functions are now significantly faster than the previous release. Speaking of significantly faster, I had meant to draw your

Re: [Oorexx-devel] Paths and paths and paths....

2008-07-03 Thread Rick McGuire
, the harder it is to override it when necessary. -Chip- On 7/2/08 18:45 Rick McGuire said: As part of the recent merge back into the trunk, I introduced the concept of an extension path as an option to the APIs. The intent of this option was to allow the normal file search path to be extended

Re: [Oorexx-devel] Where are we at with running unit tests?

2008-07-03 Thread Rick McGuire
the arrays extend themselves than to use lines() to get an accurate count first. Probably because the cost of I/O vastly outweighs the other factors. Rick On Thu, Jul 3, 2008 at 9:51 AM, Gil Barmwater [EMAIL PROTECTED] wrote: Rick McGuire wrote: On Thu, Jul 3, 2008 at 9:30 AM, Gil Barmwater [EMAIL

Re: [Oorexx-devel] Where are we at with running unit tests?

2008-07-03 Thread Rick McGuire
[EMAIL PROTECTED] wrote: Rick McGuire wrote: On Thu, Jul 3, 2008 at 9:30 AM, Gil Barmwater [EMAIL PROTECTED] wrote: With all the changes to STREAM in the new release, I was wondering if the performance issue with ARRAYIN has been addressed as well (I seem to remember a discussion about the cause

Re: [Oorexx-devel] Where are we at with running unit tests?

2008-07-03 Thread Rick McGuire
\runtime\RexxActivation.cpp) a = s~charin(,s~chars)~makearray s~close end say time('e') for a~items items Rick McGuire wrote: Ok, I took a couple minutes to do the experiment. Here's the simple test I was using: call time 'r' do 200 s = .stream~new(\ORexxDev\oorexx\kernel

Re: [Oorexx-devel] Need a quick tutorial on debugging on Linux

2008-07-05 Thread Rick McGuire
I managed to get this working. I needed to be in the .libs directory in order to resolve things. I've also managed to get the Slickedit GDB debugger support working which is a VERY nice looking debugger. Rick On Sat, Jul 5, 2008 at 7:15 PM, Rick McGuire [EMAIL PROTECTED] wrote: Ok, I've

Re: [Oorexx-devel] ooRexx 4.0 on Linux

2008-07-10 Thread Rick McGuire
give it a quick try. After a RPM install, on a very simple program, just: say hello world It runs but no output is produced. Is that a symptom of not finding the image? -- Mark Miesfeld On Thu, Jul 10, 2008 at 3:02 PM, Rick McGuire [EMAIL PROTECTED] wrote: David, I've fixed

Re: [Oorexx-devel] ooRexx 4.0 on Linux

2008-07-10 Thread Rick McGuire
, Mark Miesfeld [EMAIL PROTECTED] wrote: On Thu, Jul 10, 2008 at 3:32 PM, Rick McGuire [EMAIL PROTECTED] wrote: I would like to get the SlickEdit debugger going, but I don't have time right now. Have to work on that later. Pretty easy, actually. Select Debug-Attach Debugger-Debug Other

[Oorexx-devel] Changing the spelling of REXXPATH.

2008-07-11 Thread Rick McGuire
In the trunk build, I've added support for a REXXPATH environment variable as part of the Rexx file search order. I'm thinking this should be changed to REXX_PATH, to be consistent with the REXX_HOME variable we use for help information. It would also be consistent with other similar uses, such

Re: [Oorexx-devel] ooRexx 4.0 on Linux

2008-07-11 Thread Rick McGuire
. As for a debugger, MacOSX has an excellent one in XCode. best regards, René Jansen. On 11 jul 2008, at 17:22, Rick McGuire wrote: Ok, now if I could just find an understandable debugger to use to debug these problems. SlickEdit doesn't seem to like to be restarted, I hate using command line

Re: [Oorexx-devel] ooRexx 4.0 on Linux

2008-07-11 Thread Rick McGuire
Rene, Could you do an svn info from your trunk directory and post the result? Rick On Fri, Jul 11, 2008 at 1:18 PM, René Jansen [EMAIL PROTECTED] wrote: Mark, yes. but this is actually the only project in which svn appears to be doing this, and I would like to trust the versioning tools. I

Re: [Oorexx-devel] ooRexx 4.0 on Linux

2008-07-11 Thread Rick McGuire
2008, at 19:27, Rick McGuire wrote: Ah, thought soyou have the wrong version checked out. That's the 4.0 version I started working on years ago, and then merged many of the changes back into the normal trunk. You want the oorexx/interpreter-3.x/trunk branch. Rick On Fri, Jul 11, 2008

Re: [Oorexx-devel] ooRexx 4.0 on Linux

2008-07-11 Thread Rick McGuire
in this scope make: *** [librexx_la-SysFileSystem.lo] Error 1 René. On 11 jul 2008, at 19:36, Rick McGuire wrote: Yeah, it's a long story. I took that branch about 3 1/2 years ago, and was madly toiling away at the codethen I moved above 3 years ago and work stalled. In the meantime, I

Re: [Oorexx-devel] ooRexx 4.0 on Linux

2008-07-11 Thread Rick McGuire
. On 11 jul 2008, at 19:36, Rick McGuire wrote: Yeah, it's a long story. I took that branch about 3 1/2 years ago, and was madly toiling away at the codethen I moved above 3 years ago and work stalled. In the meantime, I finally decided that we need to get some new features out, so all

[Oorexx-devel] Linux debugging (again)

2008-07-11 Thread Rick McGuire
Time for a new thread. I've managed to fix the problem with lineout, but the debuggers are driving me crazy. Slickedit is the easiest to usewhen it works. ddd I find to be absolutely unusable, and I can't figure out how to get gdb to set breakpoints for me (or ddd, for that matter). To

[Oorexx-devel] Rexxtry now working on Linux

2008-07-11 Thread Rick McGuire
Ok, I've got things working far enough for rexxtry to work. Errors are still having a problem opening the rexx.cat file, but I suspect this might be a setup problem rather than a code problem. Rick - Sponsored by:

Re: [Oorexx-devel] Ready to make a little change

2008-07-12 Thread Rick McGuire
Jon, The appropriate way to do this would be check out the entire trunk build. This would be the code at https://oorexx.svn.sourceforge.net/svnroot/oorexx/interpreter-3.x/trunk In other words, do a svn co https://oorexx.svn.sourceforge.net/svnroot/oorexx/interpreter-3.x/trunk oorexx The last

Re: [Oorexx-devel] Oorexx-devel Digest, Vol 26, Issue 21

2008-07-12 Thread Rick McGuire
We have a Tracker area on the sourceforge site for submitting patches. We prefer them in SVN patch format, which makes them easier to merge in. You might want to just open one Tracker item for the zOS work, and just keep attaching new patch files to that item. We'll get notifications on all

Re: [Oorexx-devel] The new API and calling back into the interpreter

2008-07-13 Thread Rick McGuire
Ok, I think I found the problem. The entry code for the AttachThread() API was using the RexxInstance * pointer directly as an InterpreterInstance *, which is not correct. I've fixed that problem, so you might want to give it another go. Now, let me also suggest an improvement on what you've

Re: [Oorexx-devel] Ready to make a little change

2008-07-13 Thread Rick McGuire
Answered inline before. On Sun, Jul 13, 2008 at 12:54 PM, Sahananda (Jon) Wolfers [EMAIL PROTECTED] wrote: OK, pardon the three steps backwards, two steps forward approach. A few questions: 1) CoreClasses.orx looks like it is just written in rexx - yet one needs to rebuild the interpreter

Re: [Oorexx-devel] The new API and calling back into the interpreter

2008-07-13 Thread Rick McGuire
Resendingthis didn't snow up in the archives, which leads me to believe it never made it. I've also already put in a fix for this problem. Rick On Sun, Jul 13, 2008 at 7:05 AM, Rick McGuire [EMAIL PROTECTED] wrote: Congratulations Markyou've written the long explanation on how to use

Re: [Oorexx-devel] The new API and calling back into the interpreter

2008-07-13 Thread Rick McGuire
This one also seems to have gone missing. Rick On Sun, Jul 13, 2008 at 7:44 AM, Rick McGuire [EMAIL PROTECTED] wrote: Ok, I think I found the problem. The entry code for the AttachThread() API was using the RexxInstance * pointer directly as an InterpreterInstance *, which is not correct

Re: [Oorexx-devel] interpreter-AttachThread(context) continued

2008-07-13 Thread Rick McGuire
the instance information in the objects and attaching every time you want to invoke a method . Rick On Sun, Jul 13, 2008 at 4:56 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: On Sun, Jul 13, 2008 at 1:34 PM, Rick McGuire [EMAIL PROTECTED] wrote: I don't have Word, so debugging this using oodialog

Re: [Oorexx-devel] The new API and calling back into the interpreter

2008-07-13 Thread Rick McGuire
McGuire wrote: Resendingthis didn't snow up in the archives, which leads me to believe it never made it. I've also already put in a fix for this problem. Rick On Sun, Jul 13, 2008 at 7:05 AM, Rick McGuire [EMAIL PROTECTED] wrote: Congratulations Markyou've written the long explanation

Re: [Oorexx-devel] interpreter-AttachThread(context) continued

2008-07-13 Thread Rick McGuire
frequently. Failing to detach results in nested contexts on the same thread, so things start to accumulate. Rick On Sun, Jul 13, 2008 at 6:05 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: On Sun, Jul 13, 2008 at 2:46 PM, Rick McGuire [EMAIL PROTECTED] wrote: I committed fixes for this problem

Re: [Oorexx-devel] interpreter-AttachThread(context) continued

2008-07-13 Thread Rick McGuire
Yeah, if feels at times a little like the Apollo moon landing...a lot of work went into that one small step :-) Rick On Sun, Jul 13, 2008 at 7:09 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: On Sun, Jul 13, 2008 at 2:46 PM, Rick McGuire [EMAIL PROTECTED] wrote: I committed fixes

Re: [Oorexx-devel] Ready to make a little change

2008-07-14 Thread Rick McGuire
You don't actually need to move the newly built files into your rexx_home to use this. Just CD into ..\trunk\Win32dbg after the build and you should be able to run the new rexx version directly from there without having to touch your installed one. Do a taskkill /F /IM rxapi.exe to kill the

Re: [Oorexx-devel] Ready to make a little change

2008-07-14 Thread Rick McGuire
/7/14 Rick McGuire [EMAIL PROTECTED]: You don't actually need to move the newly built files into your rexx_home to use this. Just CD into ..\trunk\Win32dbg after the build and you should be able to run the new rexx version directly from there without having to touch your installed one. Do

Re: [Oorexx-devel] Ready to make a little change

2008-07-14 Thread Rick McGuire
or batch file. Building Rexxapi.. ***! Error occured !** : build halted I shall have to find out how to move my repository. I've tried a simple cut paste and it is chuntering away - we shall see if that works when it has finished. cheers, Jon 2008/7/14 Rick McGuire [EMAIL PROTECTED

Re: [Oorexx-devel] Ready to make a little change

2008-07-14 Thread Rick McGuire
some time ago when Mark was showing me what he had done with resource files. Perhaps it is back-level? I'm not sure how to tell. Jon 2008/7/14 Rick McGuire [EMAIL PROTECTED]: By default, all of the output from the build is written to the file Win32dbg\build.log, so you can look

Re: [Oorexx-devel] .method behaviour

2008-07-15 Thread Rick McGuire
Well, a lot of stuff has been rewritten, so it's possible that some inadvertent problems have been in On Tue, Jul 15, 2008 at 5:26 PM, Moritz Hoffmann [EMAIL PROTECTED] wrote: Hi, did the behaviour of the mthod class change recently? A while ago one could create instances of this class,

Re: [Oorexx-devel] .method behaviour

2008-07-15 Thread Rick McGuire
Sorry, Gmail problems. A lot of code has been rewritten, so it's possible that something unintentional got introduced. Please post a test case showing the problem, but I suspect I know what's happening. There was a problem in prior releases where Method objects were used as class Methods,

[Oorexx-devel] Anybody else having problems committing code?

2008-07-16 Thread Rick McGuire
I'm trying to commit a small change to the code right now, and I'm getting the following error: C:\ORexxDev\oorexx2svn --username bigrixx commit -m fix multithreading deadloc k svn: Commit failed (details follow): svn: MKACTIVITY of '/svnroot/oorexx/!svn/act/9f4c3e6e-152b-1f4d-bc6a-1383ce18698

Re: [Oorexx-devel] Anybody else having problems committing code?

2008-07-16 Thread Rick McGuire
Ok, to answer my own question, this looks like a system wide problem. There's a discussion thread about this already on the sourceforge discussion forums. Rick On Wed, Jul 16, 2008 at 12:50 PM, Rick McGuire [EMAIL PROTECTED] wrote: I'm trying to commit a small change to the code right now

Re: [Oorexx-devel] Anybody else having problems committing code?

2008-07-16 Thread Rick McGuire
, Rick McGuire [EMAIL PROTECTED] wrote: Ok, to answer my own question, this looks like a system wide problem. There's a discussion thread about this already on the sourceforge discussion forums. Rick On Wed, Jul 16, 2008 at 12:50 PM, Rick McGuire [EMAIL PROTECTED] wrote: I'm trying to commit

Re: [Oorexx-devel] svn e-mail notifications may not be working

2008-07-16 Thread Rick McGuire
Yes, I just experienced the same thing. I was just about to post something about this on the sourceforge forums. Rick On Wed, Jul 16, 2008 at 6:20 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: Rick, I made a couple of minor commits. I think the svn e-mail notifications may not be working yet.

Re: [Oorexx-devel] svn e-mail notifications may not be working

2008-07-16 Thread Rick McGuire
Mark, I have a small improvement to your one update to ThreadContextStubs that I'll checkin once svn starts behaving again. Rather than do a new_string(...)-upper() you can use new_upper_string(...), which only creates a single object rather than two. Rick On Wed, Jul 16, 2008 at 6:20 PM, Mark

Re: [Oorexx-devel] Should discuss compiler version for Windows build

2008-07-17 Thread Rick McGuire
I suspect it's time to move forward on what the minimum compiler level is too. I think your target is reasonable, but I'd like to understand what issues we have with the 6.0 level before committing on a version. Extensions built with older levels should not be an issue. Those are just code and

[Oorexx-devel] The context class

2008-07-18 Thread Rick McGuire
We had a discussion a while back about the adding an implementation of a class that will retrieve the current execution context via the environment variable .CONTEXT. This now implemented in trunk, and here's the initial set of things I allow you to access via .CONTEXT: - package This is the

Re: [Oorexx-devel] The context class

2008-07-18 Thread Rick McGuire
On Fri, Jul 18, 2008 at 1:39 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: On Fri, Jul 18, 2008 at 9:41 AM, Rick McGuire [EMAIL PROTECTED] wrote: We had a discussion a while back about the adding an implementation of a class that will retrieve the current execution context via the environment

Re: [Oorexx-devel] Changes between 3.2.0 and the current SVN interpreter-3.x

2008-07-20 Thread Rick McGuire
. See mail From: Rick McGuire - 2008-02-11 16:13 [Oorexx-devel] [DISCUSS] Exposing the source object. Monitor : The public method unknown is now guarded. MutableBuffer : The public methods request and uninit have been removed. New public method makeArray. OLEVariant : New public method

Re: [Oorexx-devel] Changes between 3.2.0 and the current SVNinterpreter-3.x

2008-07-20 Thread Rick McGuire
of dropRegisteredRoutine SubcommandAPI.c : RexxResolveRoutine : in the call to RegLoad, must pass handler, not handler Jean Louis - Original Message - From: Rick McGuire [EMAIL PROTECTED] To: Open Object Rexx Developer Mailing List oorexx-devel@lists.sourceforge.net Sent: Sunday, July 20

Re: [Oorexx-devel] Coding standards

2008-07-21 Thread Rick McGuire
Object Rexx was originally written in C, and converted to C++ fairly late in the development cycle back in 1995. At that time, hardly any of the things on your list even existed yet, and on some platforms we were looking to port the code to, the C++ compilers were still implemented as C++ to C

Re: [Oorexx-devel] Arg validation in the native API

2008-07-21 Thread Rick McGuire
Mark, This is probably one that would need to be traced to be figured out. Start with a breakpoint at our old friend RexxActivity::raiseException to find out where the error is getting triggered from and back up from there. I suspect, however, that the reason this is failing is because it is a

Re: [Oorexx-devel] Coding standards

2008-07-21 Thread Rick McGuire
On Mon, Jul 21, 2008 at 8:13 AM, David Crayford [EMAIL PROTECTED] wrote: Rick McGuire wrote: On Mon, Jul 21, 2008 at 7:50 AM, David Crayford [EMAIL PROTECTED] wrote: Thanks Rick, comments below... Rick McGuire wrote: Standard library objects need to be used with care because of storage

Re: [Oorexx-devel] Changes between 3.2.0 and the current SVNinterpreter-3.x

2008-07-21 Thread Rick McGuire
of dropRegisteredRoutine SubcommandAPI.c : RexxResolveRoutine : in the call to RegLoad, must pass handler, not handler Jean Louis - Original Message - From: Rick McGuire [EMAIL PROTECTED] To: Open Object Rexx Developer Mailing List oorexx-devel@lists.sourceforge.net Sent: Sunday, July 20, 2008 10:56 PM

Re: [Oorexx-devel] Arg validation in the native API

2008-07-21 Thread Rick McGuire
Mark, I think I spotted the problem. The problem was with the unint32_t value as a return value rather than passing it as an argument. The code had one of my typical cut-and-paste errors, where the value was getting cast to (wholenumber_t) rather than (stringsize_t), which caused the wrong

Re: [Oorexx-devel] It's my build, but...

2008-07-21 Thread Rick McGuire
Jon, This is just a shot in the dark, but how do you invoke rexxtry? Do you invoke it by typing rexxtry.rex or rexx rexxtry.rex I suspect if it is the former, it might be picking up the older version because the file associations are probably pointing directly to the executable. If you

Re: [Oorexx-devel] oorexx on Solaris/SPARC

2008-07-21 Thread Rick McGuire
Not sure I understand what you mean by correctly converted. Rick On Mon, Jul 21, 2008 at 12:00 PM, Moritz Hoffmann [EMAIL PROTECTED] wrote: On Mon, 21 Jul 2008 08:34:58 -0700 Mark Miesfeld [EMAIL PROTECTED] wrote: Moritz, I think it is great you are trying to compile on Solaris SPARC. It

Re: [Oorexx-devel] oorexx on Solaris/SPARC

2008-07-21 Thread Rick McGuire
Looking at the stacktrace you have, this is the sort of exception you'd get if you tried to call the RexxDirectory::at() method will a null pointer or a bogus pointer value. Is it possible that the static variable initializers are not getting run correctly? The first step to debugging this is to

Re: [Oorexx-devel] oorexx on Solaris/SPARC

2008-07-21 Thread Rick McGuire
On Mon, Jul 21, 2008 at 12:42 PM, Moritz Hoffmann [EMAIL PROTECTED] wrote: On Mon, 21 Jul 2008 12:13:10 -0400 Rick McGuire [EMAIL PROTECTED] wrote: Looking at the stacktrace you have, this is the sort of exception you'd get if you tried to call the RexxDirectory::at() method will a null

Re: [Oorexx-devel] Arg validation in the native API

2008-07-21 Thread Rick McGuire
On Mon, Jul 21, 2008 at 5:37 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: On Mon, Jul 21, 2008 at 6:21 AM, Rick McGuire [EMAIL PROTECTED] wrote: I think I spotted the problem. The problem was with the unint32_t value as a return value rather than passing it as an argument. Rick, somehow I

[Oorexx-devel] API testing

2008-07-21 Thread Rick McGuire
I brought this up some time ago, but now that we actually have the new API code in and (mostly) working, we need to apply a little more thought to how we handle this problem. We really should be adding unit test code for testing the API routines in addition to our coverage of the direct language

Re: [Oorexx-devel] Deferred evaluation of arguments ?

2008-07-22 Thread Rick McGuire
I've been giving some thought to whether closures could be added to the language for some time, but the issues generally lie on the calling end. That is, what is the syntax to be used that would allow a closure to be created without cluttering up the language with lots of special exceptions or

Re: [Oorexx-devel] Deferred evaluation of arguments ?

2008-07-22 Thread Rick McGuire
than this. Rick On Tue, Jul 22, 2008 at 6:27 AM, Rick McGuire [EMAIL PROTECTED] wrote: I've been giving some thought to whether closures could be added to the language for some time, but the issues generally lie on the calling end. That is, what is the syntax to be used that would allow

Re: [Oorexx-devel] Deferred evaluation of arguments ?

2008-07-22 Thread Rick McGuire
cc Subject Re: [Oorexx-devel] Deferred evaluation of arguments ? I love closures! I've only used them hacking about in groovy but they're really nice. What else is on your todo list? Have you given aspects any thought? Rick McGuire wrote: I've been giving some thought to whether

Re: [Oorexx-devel] API testing

2008-07-22 Thread Rick McGuire
or making the API tests completely optional. If others have any kind of a solution for this problem please comment. Thanks, W. David Ashley IBM Systems and Technology Group Lab Services Open Object Rexx Team Mobile Phone: 512-289-7506 Rick McGuire ---07/21/2008 06:19:30 PM---I brought this up

[Oorexx-devel] Building on x86_64 Fedora

2008-07-22 Thread Rick McGuire
I just made my first attempt at building on an x86_64 version of Fedora 9. It died on the first file, and it appears from the compiler options it's still trying to compile for the x86_32 architecture. Does anybody have any ideas on what needs to get updated to allow 64-bit builds? Here's the

Re: [Oorexx-devel] Building on x86_64 Fedora

2008-07-22 Thread Rick McGuire
: creating config.h config.status: executing depfiles commands On Tue, Jul 22, 2008 at 1:36 PM, Rick McGuire [EMAIL PROTECTED] wrote: I just made my first attempt at building on an x86_64 version of Fedora 9. It died on the first file, and it appears from the compiler options it's still trying

Re: [Oorexx-devel] Revisit native API typed value args

2008-07-22 Thread Rick McGuire
Mark, This mostly looks good, but I don't understand why you had to use unsignedInt64Value() rather than unsignedNumberValue(). The latter should work (and if it doesn't there's a bug there). Rick On Tue, Jul 22, 2008 at 1:52 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: Rick, I'll try to

Re: [Oorexx-devel] Migration of String methods to MutableBuffer (was : Re: Deferred evaluation of arguments ?)

2008-07-23 Thread Rick McGuire
On Wed, Jul 23, 2008 at 3:11 AM, Jean-Louis Faucher [EMAIL PROTECTED] wrote: I made a side-by-side comparison of String with MutableBuffer. 100 methods on one side, 13 methods on the other side...(sigh:-) See attached .txt file. I'm not aiming for mutablebuffer to necessarily implement every

Re: [Oorexx-devel] oorexx on Solaris/SPARC

2008-07-23 Thread Rick McGuire
On Mon, 21 Jul 2008 12:50:06 -0400 Rick McGuire [EMAIL PROTECTED] wrote: On Mon, Jul 21, 2008 at 12:42 PM, Moritz Hoffmann [EMAIL PROTECTED] wrote: On Mon, 21 Jul 2008 12:13:10 -0400 Rick McGuire [EMAIL PROTECTED] wrote: Looking at the stacktrace you have, this is the sort of exception

Re: [Oorexx-devel] oorexx on Solaris/SPARC

2008-07-23 Thread Rick McGuire
RexxObject::classInstance is not the variable I highlighted as bad. RexxObject::operatorMethods was the one that looked suspect in your last post. Rick On Wed, Jul 23, 2008 at 10:35 AM, Moritz Hoffmann [EMAIL PROTECTED] wrote: On Wed, 23 Jul 2008 08:23:39 -0400 Rick McGuire [EMAIL PROTECTED

Re: [Oorexx-devel] Linux debugging (again)

2008-07-23 Thread Rick McGuire
Mark, I've fixed both the concurrenty issues and the rexxhide crash. Rick On Tue, Jul 22, 2008 at 8:29 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: On Tue, Jul 22, 2008 at 5:18 PM, Rick McGuire [EMAIL PROTECTED] wrote: Now you have my sympathy! And, a bit of good news. I've now managed

Re: [Oorexx-devel] Native API methods with no return value?

2008-07-23 Thread Rick McGuire
If you want to return nothing, then declare the return type as RexxObjectPtr and return NULLOBJECT. This will only raise an error if the method is used in an expression context. For example, say x~'STATE='(1) Would return raise an error, but x~state=1 would not. A VOID return type just

Re: [Oorexx-devel] Native API packages and scaling

2008-07-26 Thread Rick McGuire
They will scale very well. Once the package is loaded, the methods/routines are loaded into hash tables so the searches will be very fast. Much faster in fact than the old mechanism that required an IPC and a linear table search. Any for methods, since they only get added to the method

Re: [Oorexx-devel] Thinking about reorganizing the code tree

2008-07-26 Thread Rick McGuire
to base further development on. Moritz On Sat, 26 Jul 2008 08:00:20 -0400 Rick McGuire [EMAIL PROTECTED] wrote: Now that I'm porting the rxapi/rexxapi code from 4.0 back into trunk, I'm starting to think we need to organize the code a bit. Focusing for a moment on just the core pieces, we

Re: [Oorexx-devel] Thinking about reorganizing the code tree

2008-07-26 Thread Rick McGuire
On Sat, Jul 26, 2008 at 1:20 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: On Sat, Jul 26, 2008 at 5:00 AM, Rick McGuire [EMAIL PROTECTED] wrote: Now that I'm porting the rxapi/rexxapi code from 4.0 back into trunk, I'm starting to think we need to organize the code a bit. Rick I'm all

Re: [Oorexx-devel] Native API packages and scaling

2008-07-26 Thread Rick McGuire
On Sat, Jul 26, 2008 at 1:38 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: On Sat, Jul 26, 2008 at 3:09 AM, Rick McGuire [EMAIL PROTECTED] wrote: They will scale very well. Once the package is loaded, That is one of the things I was thinking about, the actual loading of the package. What

Re: [Oorexx-devel] Thinking about reorganizing the code tree

2008-07-27 Thread Rick McGuire
the problem. Thanks, W. David Ashley IBM Systems and Technology Group Lab Services Open Object Rexx Team Mobile Phone: 512-289-7506 Rick McGuire ---07/26/2008 07:00:58 AM---Now that I'm porting the rxapi/rexxapi code from 4.0 back into trunk, Rick McGuire [EMAIL PROTECTED] Sent

[Oorexx-devel] Adjusting the build machine.

2008-07-27 Thread Rick McGuire
David, I suspect the build machine is going to need some adjustment for the new SVN urls. Rick - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with

Re: [Oorexx-devel] Native API and FindClass

2008-07-27 Thread Rick McGuire
That particular API function resolves a class in the same context that code declared within a package would locate the function. I'd have to see the whole overall structure of the program, but I think generally, if you are using a function in a native package, then in the context of that package,

Re: [Oorexx-devel] Native API and FindClass

2008-07-27 Thread Rick McGuire
, I'm going to add a FindContextClass to the CallContext as wellbeing able to locate a class from your caller's context would be for native functions. Rick On Sun, Jul 27, 2008 at 4:04 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: On Sun, Jul 27, 2008 at 12:45 PM, Rick McGuire [EMAIL PROTECTED

[Oorexx-devel] A potential improvement to the native APIs.

2008-07-27 Thread Rick McGuire
Mark's recent questions about his RECT class sort of triggered a thought for a way to improve the native APIs and make it easier to write certain types of objects. The native API has two special pseudo types intended to make objects that use backing C structs or C++ classes easier to use. These

Re: [Oorexx-devel] A potential improvement to the native APIs.

2008-07-27 Thread Rick McGuire
:43 PM, Rick McGuire [EMAIL PROTECTED] wrote: Ok, this is in. Pretty easy to add, actually. Rick On Sun, Jul 27, 2008 at 5:00 PM, Mark Miesfeld [EMAIL PROTECTED] wrote: On Sun, Jul 27, 2008 at 1:35 PM, Rick McGuire [EMAIL PROTECTED] wrote: Mark's recent questions about his RECT class sort

Re: [Oorexx-devel] Native API and DirectoryAt()

2008-07-29 Thread Rick McGuire
Yes, that's the behavior I intended (and the behavior the internal code relies upon). From Rexx code, the only mechanism that exists for returning nothing is .nilbut .nil is also an object that can be stored in a directory. Returning NULL for the native APIs disambiguates those two cases.

Re: [Oorexx-devel] A potential improvement to the native APIs.

2008-07-30 Thread Rick McGuire
of the pointer so I can fetch it later in other methods. Can you give me an example? Thanks, W. David Ashley IBM Systems and Technology Group Lab Services Open Object Rexx Team Mobile Phone: 512-289-7506 Rick McGuire ---07/27/2008 04:03:16 PM---Yes, that's exactly what I'm proposing. When you lay out

[Oorexx-devel] dbgPrintf

2008-07-30 Thread Rick McGuire
Mark, Doing a little cleanup in the windows build stuff in my sandbox version. There's a module in called DebugOutput.cpp that's in the kernel windows directory that is only referenced in one place in the orexxole.c. This is conditionally compiled using #ifdef REXX_DEBUG, but the enablement of

  1   2   3   4   5   6   7   8   9   10   >