I'm not too sure what do with this one. There are a number of APIs
that have basically no meaning at all in the 4.0 world, and this is
one of them. There are others such as RexxTerminate() and
RexxWaitForTermination() that were part of the documented APIs. These
have been now stubbed off and
On Thu, Apr 23, 2009 at 6:50 AM, Rick McGuire object.r...@gmail.com wrote:
I'm not too sure what do with this one. There are a number of APIs
that have basically no meaning at all in the 4.0 world, and this is
one of them. ... The line in the sand we've drawn so far has been to
support
Crud, I hadn't thought to check in the samples. It is used in one of
the samples and was included in the rexx.h header files.
I think this one needs to be added back as at least a deprecated stub.
Rick
On Thu, Apr 23, 2009 at 10:25 AM, Mark Miesfeld miesf...@gmail.com wrote:
On Thu, Apr 23,
On Thu, Apr 23, 2009 at 7:32 AM, Rick McGuire object.r...@gmail.com wrote:
Crud, I hadn't thought to check in the samples. It is used in one of
the samples and was included in the rexx.h header files.
I think this one needs to be added back as at least a deprecated stub.
Crud My sentiments
I'm trying to make sure I fully understand the new features in 4.0.0 and
the first one I'm playing with is ::constant. I've read over the
documentation and tried to code the equivalent functionality in 3.2.
Here is what I came up with:
If in 4.0.0 I write
::class golden
::constant phi 1.618
Nope, that's pretty much the picture, though from a strict correctness
standpoint, it would really be:
::class golden
::method phi class unguarded
return 1.618
::method phi unguarded
return 1.618
The instance one does not forward to the class one, but has it's own
version of the
We now have two problems showing up in the 4.0 beta that can only be
classified as beyond bizarre and both seem to point to problems with
the _read() function in the C runtime library. I'm not sure I have
any good solutions at this point.
In 3.2.0, the stream library was implemented using the
Thanks Rick. Glad I didn't miss something here. BTW, I used the
'forward' to limit the appearance of the value to a single spot, even
though it incurs a performance hit.
Next question: are there any good examples of using the .package and
.routine classes? I'm a bit fuzzy as to when I would
Just a very quick response to this question (I have to drop offline in 5
minutes) ...
I remember from ages ago (1980s) having trouble using the low-level
routines in DOS and Windows (and OS/2). The same *sort* of things that we
have been seeing .. multithread, perhaps, just weird things. So
Well, routines are really useful to for passing around function
pointers or doing dynamic calls. For example, the old problem of
doing a variable based functions. For example,
::method init
expose variableRoutines
// create a directory with the set of locally defined routines
Rick,
I'm not going to do this in line cause I'm still thinking about it a
little. No option looks good this late in the beta, and it's really
not clear which would be the easiest and most likely to fix the
problem.
I take it the second instance is Walter's bug. Do you have a set up
that
Answers below.
On Thu, Apr 23, 2009 at 3:23 PM, Mark Miesfeld miesf...@gmail.com wrote:
Rick,
I'm not going to do this in line cause I'm still thinking about it a
little. No option looks good this late in the beta, and it's really
not clear which would be the easiest and most likely to fix
On Thu, Apr 23, 2009 at 12:37 PM, Rick McGuire object.r...@gmail.com wrote:
Answers below.
On Thu, Apr 23, 2009 at 3:23 PM, Mark Miesfeld miesf...@gmail.com wrote:
One other option, is to try building with VC++ 2003 and / or VC++
2008. I have both Visual Studios. I think both of them will
Reworking the BSF4Rexx dynamic library, and in a first step defining a
RexxPackEntry using a RexxRoutineEntry with 13 entries of type
REXX_CLASSIC_ROUTINE only can be compiled and be used with the
RxFuncAdd() function. (There are no new type routines defined in the
source file yet.)
However,
I don't spot anything obviously wrong here, so you'll probably need to
upload everything. Alternatively, since I know you occasionally build
from source, try running this in the debugger and attach a stack trace
to the bug report.
Rick
On Thu, Apr 23, 2009 at 4:49 PM, Rony G. Flatscher
Rick McGuire wrote:
I don't spot anything obviously wrong here, so you'll probably need to
upload everything. Alternatively, since I know you occasionally build
from source, try running this in the debugger and attach a stack trace
to the bug report.
O.K., am on the run home. Will try do
Assuming you have visual studio and you have a Rexx command that
creates the problem, just type
devenv /debugexe rexx yada yada yada
Hit PF5 to run, and it should stop at the location of the trap.
Rick
On Thu, Apr 23, 2009 at 5:04 PM, Rony G. Flatscher
rony.flatsc...@wu-wien.ac.at wrote:
On Thu, Apr 23, 2009 at 1:49 PM, Rony G. Flatscher
rony.flatsc...@wu-wien.ac.at wrote:
I don't know about the crash, but this isn't right:
RexxPackageEntry bsf_package_entry =
{
...
OOREXX_GET_PACKAGE(BSFLIB);
That should be:
OOREXX_GET_PACKAGE(bsf);
--
Mark Miesfeld
Good catch! I wonder what this actually ended up pointing to.
Rick
On Thu, Apr 23, 2009 at 5:39 PM, Mark Miesfeld miesf...@gmail.com wrote:
On Thu, Apr 23, 2009 at 1:49 PM, Rony G. Flatscher
rony.flatsc...@wu-wien.ac.at wrote:
I don't know about the crash, but this isn't right:
On Thu, Apr 23, 2009 at 2:56 PM, Rick McGuire object.r...@gmail.com wrote:
I've got a good start on converting SysFile to use the direct I/O
functions. I've got everything converted up to the getTimeStamp()
methods, where I sort of hit a wall. There are just a few things left
to convert, so
Rick McGuire wrote:
Good catch! I wonder what this actually ended up pointing to.
Rick
On Thu, Apr 23, 2009 at 5:39 PM, Mark Miesfeld miesf...@gmail.com wrote:
On Thu, Apr 23, 2009 at 1:49 PM, Rony G. Flatscher
rony.flatsc...@wu-wien.ac.at wrote:
I don't know about the crash, but
21 matches
Mail list logo