Hello,
I will test the 64/32 bit 4.2 branch against this test suit.
I'll keep you posted.
Bye
Rainer
On 27.12.2013 17:02, Mark Miesfeld wrote:
> On Fri, Dec 27, 2013 at 7:10 AM, Rainer Tammer <mailto:tam...@tammer.net>> wrote:
>
> The current ooRexx 4.2 branch d
Hello,
The current ooRexx 4.2 branch does build under AIX 6.1 (64Bit) without a
problem. All sample programs do work.
Which text suite should be used for ooRexx 4.2 branch??
Bye
Rainer
--
Rapidly troubleshoot problems
ct *)string_value) == OREF_NULL)
>
> Rick
>
>
> On Mon, Jun 24, 2013 at 11:04 AM, Rainer Tammer <mailto:tam...@tammer.net>> wrote:
>
> Hello,
> I am very sorry, this is the error:
>
> source='./interpreter/classes/ObjectClass.cpp'
> object
r RexxArray *()".
"./interpreter/classes/ObjectClass.cpp", line 1171.37: 1540-1231 (I) The
conversion from argument number 2 to "RexxArray *" uses "a pointer
conversion".
"./interpreter/memory/ProtectedObject.hpp", line 116.17: 1540-1202 (I)
No candidate
Hello,
the current SVN branch for 4.1.3 BETA does (after two small changes)
compile on AIX (32/64).
* Which test suite is the correct one for 4.1.3?
Bye
Rainer
--
This SF.net email is sponsored by Windows:
Build for
Hello,
I'll test the AIX code in the next days...
Bye
Rainer
On 13.05.2013 16:38, David Ashley wrote:
> I have no objections to a 4.1.3 bug release. Just let me know what the
> target date is and I will do the Linux builds for it.
>
> David Ashley
>
> On Sun, 2013-05-12 at 10:04 -0700, Mark Mie
Hallo,
I am a little confused.
What is the correct SVN URL to download the release 4.1.2 source???
This is working:
https://oorexx.svn.sourceforge.net/svnroot/oorexx/main/releases/4.1.1/
This is not working:
https://oorexx.svn.sourceforge.net/svnroot/oorexx/main/releases/4.1.2/
Bye
Rainer
On
Hello,
I just tried to compile ooRexx 4.1.2 (oorexx/main/branches/4.1.2/trunk,
8193) on AIX 64, but I get an compile error.
Is this a known problem??
xlC_r -DHAVE_CONFIG_H -I. -DORX_VER=4 -DORX_REL=1 -DORX_MOD=2
-DORX_FIX=0 -DORX_SYS_STR=\"AIX\" -DORX_CATDIR=\"/opt/ooRexx/bin\"
-DORX_SHARED_LIB
Hello,
OK, I will provide the new 4.1.2 builds, but I have to go on a business
trip to Sao Paulo in a couple of days.
I'll be back 2012-09-15.
Maybe I can squeeze in the build in the next couple of days, but this
would be very tight.
If this does not work out I'll provide the packages as soon as I
Hello,
The 64bit build looks good too.
I'll only have to do the packaging now.
Bye
Rainer
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has cha
Hello,
Yes, the problem was the disk size...
Thanks for the heads up.
Bye
Rainer Tammer
On 14.06.2012 18:42, Jean-Louis Faucher wrote:
> About the three failures TEST_MANY_CHARS.
> I have them under windows, when running the test from an USB drive.
> http://sourceforge.net/ma
Hello,
any ideas before I start the real AIX builds??
Bye
Rainer
On 12.06.2012 09:37, Rainer Tammer wrote:
> Hello,
> I just found out, that URL was not correct...
>
> To be sure that there are no bigger problems with the 4.1.1 release I
> just build a 32 4.1.1 ooRexx and ex
Hello,
I just found out, that URL was not correct...
To be sure that there are no bigger problems with the 4.1.1 release I
just build a 32 4.1.1 ooRexx and executed the test suite:
ooTest Framework - Automated Test of the ooRexx Interpreter
Interpreter: REXX-ooRexx_4.1.1(MT) 6.03 12 Jun 201
Hello,
On 08.06.2012 19:51, Mark Miesfeld wrote:
> Hi Rainer,
>
> We haven't heard from you in awhile. Are you still lurking around?
Yes,
but currently I am buried in SAP migraption projects...
> If so, is it possible for you to build an AIX package for ooRexx 4.1.1?
Yes,
I will try to build the
Hello,
this is the test suite output for AIX 5.3 / ooRexx 4.1.1beta 32 bit:
ooTest Framework - Automated Test of the ooRexx Interpreter
Interpreter: REXX-ooRexx_4.1.1(MT) 6.03 27 Feb 2012
Addressing Mode: 32
ooRexxUnit: 2.0.0_3.2.0ooTest: 1.0.0_4.0.0
Tests ran: 18993
Ass
Hello,
this is the test suite output for AIX 5.3 / ooRexx 4.1.1beta 64 bit:
ooTest Framework - Automated Test of the ooRexx Interpreter
Interpreter: REXX-ooRexx_4.1.1(MT) 6.03 27 Feb 2012
Addressing Mode: 64
ooRexxUnit: 2.0.0_3.2.0ooTest: 1.0.0_4.0.0
Tests ran: 18993
Ass
Hello,
I'll just try the 4.1.1 on AIX...
Is this the correct branch:
https://oorexx.svn.sourceforge.net/svnroot/oorexx/main/branches/4.1/
And is this the correct test branch:
https://oorexx.svn.sourceforge.net/svnroot/oorexx/test/branches/4.1.0
Bye
Rainer
On 25.02.2012 06:06, Mark Miesfeld w
Hello,
I will commit this change to head this evening (German time).
Bye
Rainer
On 14.03.2011 20:03, Jean-Louis Faucher wrote:
> Hi Rainer
>
> 2011/3/14 Rainer Tammer mailto:tam...@tammer.net>>
>
> Hello,
> I changed the extension a bit:
>
> I thi
Hello,
I changed the extension a bit:
#
[^]
# svn diff
Index: rxsockfn.cpp
===
--- rxsockfn.cpp(revision 6571)
+++ rxsockf
Hello,
this is the AIX definition:
Technical Reference:
Communications, Volume 2
gethostbyaddr Subroutine
Purpose
Gets network host entry by address.
Library
Standard C Libra
Hello,
I think that the /platform/unix/xxx version is cleaner.
Bye
Rainer
On 25.02.2011 16:36, David Ashley wrote:
> All (but especially Rick) -
>
> I am going to reconfigure the platform specific source for rxapi while I am
> at
> SHARE next week. I am going to take Rick's suggestion that we
Hello,
that's great to hear.
It looks like reorderQueues() mixes things up.
Bye
Rainer
Henning Gammelmark wrote:
Hi
I have applyed the new rxapi to my
system.
After the fix has been applyed I have
not
(yet) been able to recreate the rxapi loop problem.
I have just
rrent->next = queues;
> queues = current;
> }
> +*/
> }
>
> inline void removeQueue(DataQueue *current, DataQueue *previous)
>
>
> On Tue, Jan 11, 2011 at 12:27 PM, Rainer Tammer wrote:
>> Hello,
>> the fix te
Hello,
the fix test for the problem is available for 96h on:
http://www.tammer.net/ooRexx/6571/
Bye
Rainer
On 11.01.2011 15:51, Mark Miesfeld wrote:
> This is directed to Rainer.
>
> Not to put any pressue on you Raniner, I know you're busy. But, if
> some time you could put together a 4.1.0
Hello,
On 11.01.2011 15:51, Mark Miesfeld wrote:
> This is directed to Rainer.
>
> Not to put any pressue on you Raniner, I know you're busy. But, if
> some time you could put together a 4.1.0 buidl on AIX with Rick's fix
> for this bug, I'm sure the opener (Henning Gammelmark) of the bug
> would
Hello,
just a short first answer here (a more detailed will follow).
On AIX it's the best thing to run the daemon under the control of the
subsystem resource controller (SRC). This way you get
fancy error log entries and automatic restart of the daemon
in case of a failure.
There is only one pro
Hello,
On 03.12.2010 20:01, David Ashley wrote:
> All -
>
> I have created the ooRexx 4.1.0 release folder in the SourceForge Files
> section
> and uploaded a bunch of files to it. I also created the Docs 4.1.0 folder and
> uploaded the docs to it.
>
> All we lack are the Windows, mac and AIX i
Hello,
this is not entirely related to the test suit, but please read below...
Mark Miesfeld wrote:
> David,
>
> The bulk of the failures look to be in the stream tests. As Rainer
> demonstrated, these tests are dependent on the state of the file
> system.
>
> In his case his file system was full
Hello,
this is the real result of the AIX 64 bit test suite run:
Sorry for the last message. The CHAROUT.testGroup
errors were all caused by a full filesystem. Shame on me.
ooTest Framework - Automated Test of the ooRexx Interpreter
Interpreter: REXX-ooRexx_4.1.0(MT) 6.03 30 Nov 2010
Addres
Hello,
this is the result of the AIX 64 bit test suite run:
ooTest Framework - Automated Test of the ooRexx Interpreter
Interpreter: REXX-ooRexx_4.1.0(MT) 6.03 30 Nov 2010
Addressing Mode: 64
ooRexxUnit: 2.0.0_3.2.0ooTest: 1.0.0_4.0.0
Tests ran: 18986
Assertions:
Hello,
I have two questions regarding the SysGeterrnomsg() function:
1. What is the purpose of the following code ??
..
"State not recoverable",
"Operation not possible due to RF-kill",
};
if (en > sizeof(en) / sizeof(char *)) {
return (RexxObjectPtr)context->Ne
Hello,
On 01.12.2010 00:50, Mark Miesfeld wrote:
> The other thing though is, I don't want to start down the path of any
> big changes in APService.cpp for 4.1.0.
>
> If you need to piggy back off of the run as foreground stuff to get
> things working nicely on MAC for 4.1.0, then go ahead.
>
> In
Hello,
On 01.12.2010 00:02, CVBruce wrote:
> rxapi was only a partial success in 4.0.1. It ran, but the system tried to
> respawn a new server every 10 seconds.
>
> 11/30/10 2:47:14 PM com.apple.launchd.peruser.503[314]
> (org.rexxla.oorexx.rxapid[57779]) Exited with exit code: 255
> 11/
helps a lot.
I will try to work this out over the holidays.
> David Ashley
>
Bye
Rainer
> On 11/30/2010 09:18 AM, Rainer Tammer wrote:
>> Hello,
>> currently I am preparing the ooRexx 4.1 RC for AIX.
>>
>> I do know that the installation directory changed on Linu
Hello,
currently I am preparing the ooRexx 4.1 RC for AIX.
I do know that the installation directory changed on Linux.
Do you think that it is acceptable to stay with /opt/ooRexx
on AIX, at least for the 4.1 branch?
This build does currently not show the problem with
TIME.testGroup, so this looks
Hello,
sorry for the delay...
I will prepare the AIX builds in the next days.
CAUTION: I will use AIX 5.3 as build system.
All older build were done on AIX 5.2.
Bye
Rainer
On 26.11.2010 16:22, Mark Miesfeld wrote:
> We don't seem to be getting any new bug reports with 4.1.0. I've been
> worki
Hello,
I tried that. It seems that the problem is moving around.
The machine does nothing during the test.
I have added the extended assert to cbNa assertTrue() tests:
This is one sample failure:
[failure] [20101103 08:15:07.738747]
svn:r4227 Change date: 2009-02-26 19:38:21 +0100
Test:
Hello,
On 02.11.2010 16:04, Mark Miesfeld wrote:
> On Tue, Nov 2, 2010 at 7:12 AM, Rainer Tammer wrote:
>
>> this is the result for the test suit on AIX 5.3 / 64 bit.
>> The test suite does show 3 (unexpected?) failures:
> Rainer,
>
> Be sure you are using the 4.0.1
Hello,
this is the result for the test suit on AIX 5.3 / 64 bit.
The test suite does show 3 (unexpected?) failures:
ooTest Framework - Automated Test of the ooRexx Interpreter
Interpreter: REXX-ooRexx_4.1.0(MT) 6.03 2 Nov 2010
Addressing Mode: 64
ooRexxUnit: 2.0.0_3.2.0ooTest: 1.0.0
Hello,
On 02.11.2010 14:02, David Ashley wrote:
> Ranier -
>
> We have always gotten a lot of complaints about our install methodology on
> *nix
> systems. So after some consideration we decided to change it to a more
> traditional approach, even though this possibly violates the spirit of th
Hello,
I am currently testing the ooRexx 4.1 tree on AIX.
The whole thing compiles, that way it look good.
I did not yet run the test suite.
I have notice one difference, the installation directory
changed from /opt/ooRexx to /usr.
Is there a specific reason for that ??
Bye
Rainer
---
Hello,
here is a small correction for the alloca:
If you use the XL C/C++ compiler then you do not need to include the
alloca.h on AIX:
# svn diff
Index: rxunixsys.h
===
--- rxunixsys.h (revision 6196)
+++ rxunixsys.h (working copy)
TINE(SysGetservbyname, SysGetservbyname),
REXX_TYPED_ROUTINE(SysGetservbyport, SysGetservbyport),
REXX_TYPED_ROUTINE(SysWordexp, SysWordexp),
Bye
Rainer
> David Ashley
>
> On 09/17/2010 01:05 AM, Rainer Tammer wrote:
>> Hello MArk,
>>
>> On 16.09.2010 16:21, Mark
0. Same with cvsStream, that
> extension is not in 4.1.0.
>
> Maybe David didn't finish merging everything he meant to.
Then removing that was OK.
> --
> Mark Miesfeld
Bye
Rainer
> On Thu, Sep 16, 2010 at 1:52 AM, Rainer Tamme
Hello,
I just tried to compiler the 4.1 branch on AIX, but there are some
problems with the code:
1. YACC
Index: configure.ac
===
--- configure.ac(revision 6196)
+++ configure.ac(working copy)
@@ -59,7 +59,7 @@
AC_P
Hello,
I just got this E-Mail:
On 25.06.2010 12:56, Henning Gammelmark wrote:
>
> Hi Rainer
>
> We have now been testing rexx 4.0.1.2 for a while.
>
> We have one very bad problem. When my aix (aix 6.1 TL5SP1 og TL2SP3)
> have more than one CPU the rxapi starts looping after 1-10 days.
> We have
Hello,
I just tried to compile ooRexx trunk on AIX
There is one small problem in common/platform/unix/SysFile.cpp which I
just fixed (not yet committed).
And there are other problems in
extensions/rexxutil/platform/unix/rexxutil.cpp:
* AIX dos not have #include
-> I have to teach configure to h
Hello,
I will build the AIX versions as soon as possible.
Bye
Rainer
On 05.05.2010 02:34, Mark Miesfeld wrote:
> The ooRexx team is pleased to announce that the official release of
> ooRexx 4.0.1 is now available at:
>
> http://sourceforge.net/projects/oorexx/files/
>
> ooRexx 4.0.1 is a bug fi
Hello,
one question regarding the naming:
This this thing be called RC2 or beta 2 ??
I will provide an AIX build 32/64 for AIX 5.3/6.1.
Bye
Rainer
On 14.04.2010 17:27, Mark Miesfeld wrote:
> We haven't had any bugs opened specifically for the beta 1 build.
>
> There was just this one: 2981692
Hello,
On 05.04.2010 16:35, Mark Miesfeld wrote:
> On Mon, Apr 5, 2010 at 1:48 AM, Rainer Tammer wrote:
>
>
>> what exactly did you change do fix the
>> /Users/bjskelly/4.0.1/ooRexx/base/bif/VALUE.testGroup in 32 bit mode ???
>>
> Rainer,
>
> We talke
e base is currently scheduled for release in
> September. So for a short time at least these will be three supported
> versions of AIX eg. 5.3, 6.1, and 7.1.
>
>
I try to get a beta of 7.1 as soon as possible.
Bye
Rainer
> On 04/04/2010 08:05 AM, Rainer Tammer wrote:
>
Hello,
what exactly did you change do fix the
/Users/bjskelly/4.0.1/ooRexx/base/bif/VALUE.testGroup in 32 bit mode ???
Bye
Rainer
CVBruce wrote:
> Hi Mark,
>
> I updated the code that was failing, in the test, and I now have a
> version of ooRexx 4.0.1 that passes all of the tests.
>
> ooTest
Hello,
I just have sent the BETA1 binaries to Mark.
This binaries were build on AIX 5.2. This AIX version is out of support.
I also have a build on AIX 5.3 TL8 SP9. This is currently the oldest
supported AIX level. Should I switch to this level for all further builds ??
If someone needs ooRexx on
Hello Mark,
On 28.03.2010 18:05, Mark Miesfeld wrote:
> On Sun, Mar 28, 2010 at 8:16 AM, Rainer Tammer wrote:
>
>
>> I am getting one error on AIX 32 bit. The second error is expected.
>> Any ideas ??
>>
> I ran the test suite on 4 different Linux systems
Hello MArk,
On 28.03.2010 18:05, Mark Miesfeld wrote:
> On Sun, Mar 28, 2010 at 8:16 AM, Rainer Tammer wrote:
>
>
>> I am getting one error on AIX 32 bit. The second error is expected.
>> Any ideas ??
>>
> I ran the test suite on 4 different Linux systems
Hello,
I am getting one error on AIX 32 bit. The second error is expected.
Any ideas ??
Interpreter: REXX-ooRexx_4.0.1(MT) 6.03 28 Mar 2010
Addressing Mode: 32
ooRexxUnit: 2.0.0_3.2.0ooTest: 1.0.0_4.0.0
Tests ran: 18980
Assertions: 575819
Failures:2
Err
Hello,
OK, I'll try to build the AIX packages as soon as possible.
I'll keep you posted.
Bye
Rainer
On 27.03.2010 17:08, Mark Miesfeld wrote:
> All,
>
> I created the 4.0.1 files directory on SourceForge, put up the 4.0.1
> docs and the Windows 64 package to get things started. There does not
Hello,
Congratulations Brandon.
Bye
Rainer
On 17.03.2010 19:44, Rick McGuire wrote:
> I'm pleased to announce that Brandon Cherry has accepted an invitation
> to become a committer to the ooRexx project. Brandon has been busy
> lately, submitting a number of enhancement and bug fix patches to
Hello,
the AIX 32 bit version is also OK.
The test suite shows the same two failuers (which are no real failures).
Bye
Rainer
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compi
Hello,
OK, thanks.
Bye
Rainer
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel
Hello,
this is the result of the 4.0.1 test suite on AIX (64 bit mode).
The second failure is expected as the test suite was called under root.
# rexx -v
Open Object Rexx Version 4.0.1
Build date: Mar 1 2010
Addressing Mode: 64
This looks correct...
Is this because of api/oorexxapi.h
#define R
Hello,
this is a good idea. I'll test the branch on AIX.
Bye
Rainer
On 12.02.2010 17:11, Rick McGuire wrote:
> Ok, I've created a branch we can use to start merging revisions into.
> Most bug fix changes to trunk should merge fairly cleanly, though I
> suspect there are a couple that might need
Hhello,
On 01.02.2010 19:47, Rick McGuire wrote:
> On Mon, Feb 1, 2010 at 1:38 PM, David Ruggles wrote:
>
>> I'm not sure what macrospace is so I don't know. What is macrospace?
>>
> macrospace is a means of loading programs into storage and keeping
> them there that dates from the OS/2 1
Hello,
the test suite passes all tests on svn: 5509 (64 bit build).
Bye
Rainer
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities
Hello,
I think that there is a small problem in ooRexx 4.0 trunk:
common/platform/unix/SysThread.cpp
...
// create a new thread and attach to an activity
void SysThread::createThread(void)
{
pthread_attr_t newThreadAttr;
int schedpolicy, maxpri, minpri;
struct sched_param schedparam;
Hello,
IBM fond something interesting
I have to test this but it seems that the nobody problem on AIX could be
solved...
- IBM mail ---
Rainer Tammer,
The problem seems to be the priority set for call to pthread_create,
File
ooRexx-4.0.0/common/platform/unix
Hello,
the SVN 5272 is working on AIX (at least in 32 bit, need to check the 64
bit build and the test suite)...
Bye
Rainer
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer e
libraries should also be compile
with the XL C/C++ V8, V9, V10.1 compiler.
The old V6 will not work.
Bye
Rainer
> [root]/>
>
> regards,
>
> Yug
>
> On Wed, Sep 16, 2009 at 1:08 PM, Rainer Tammer <mailto:tam...@tammer.net>> wrote:
>
> Hello,
>
>
Hello,
one addition: Additionally we could double APIServer *server.
This way if both server and server_backup points to the same object
we could be reasonable sure that the server pointer is not corrupted.
Bye
Rainer
-
Hello,
(Rick please read the note at the end)
yug k wrote:
> Hi All,
>
> I've been trying to compile the source code of ooRexx 4.0.0 on AIX 5.3
OK what exact compiler version do you use?
The code is very sensitive to the C compiler.
The gcc compiler does not work. If you are using a IBM compile
Hello,
OK.
You can try this:
# stopsrc -s rxapi
# export AIXTHREAD_SCOPE=S
# cd /opt/ooRexx/bin
# ./rxapid
.. test your app ..
.. wait for the crash / or success
.. check that the rxapi process is gone, in case of success kill the rxapid
# startsrc -s rxapi
It is possible that the other threa
Hello,
Rick McGuire wrote:
> On Fri, Sep 11, 2009 at 6:34 AM, Rainer Tammer wrote:
>
>> Hello,
>> Rick McGuire wrote:
>>
>> Just because the value is not nil this time does not eliminate the
>> possibility that this is a memory overlay. The symptoms are
ly this time, it has been
> overwritten with a non-nil, but still invalid value.
>
>
I agree, but if you look at the values then you can see that they make
sense.
At the first sight they seem not random, all are in the same range...
> Rick
>
Bye
Rainer
> On Fri, Sep 11,
Hello,
(-> Rick)
>
> *[root]/opt/ooRexx/bin> dbx rxapi*
> Type 'help' for help.
> [using memory image in core]
> reading symbolic information ...
>
> Segmentation fault in
> _Insert(std::list
> >::iterator,APIServerThread* const&) at line 47 in file
> "/usr/vacpp/include/list.t" ($t343)
>47
> Rick
>
>
Bye
Rainer
> On Sun, Aug 30, 2009 at 5:16 AM, Rainer Tammer wrote:
>
>> Hello,
>> I have a question regarding memory allocation in rxapi:
>>
>> In rexxapi/common/platform/unixSysAPIManager.cpp
>>
>> void *SysAPIManager::alloca
Hello,
I have a question regarding memory allocation in rxapi:
In rexxapi/common/platform/unixSysAPIManager.cpp
void *SysAPIManager::allocateMemory(size_t l)
{
return malloc(l);
}
In rexxapi/clientRegistrationAPI.cpp
void *REXXENTRY RexxAllocateMemory(size_t size)
{
return SysAPIManag
Hello,
yug k wrote:
> Hi Rainer,
>
> Please find the snap core file *"snapcore_630798.pax.Z"* attached in
> the mail .
>
> Herez the output of the snapcore comand that was run :
>
> [root]/opt/ooRexx/bin> snapcore core /opt/ooRexx/bin/rxapi
> Creating directory /tmp/snapcore ...
> Core file "core"
l | grep pthread
> bos.rte.libpthreads 5.3.0.30 COMMITTED libpthreads Library**
>
>
> *As pointed by you I still have /usr/lpp/orexx/bin/rexx in my path ..
> I've just removed it and started testing again ..
>
* Please ensure that the system is at least at TL7 SP8
Hello,
to get a better look at the core file I would need a snapcore:
snapcore core /opt/ooRexx/bin/rxapi
The output is in: /tmp/snapcore
This archive contains the core + the binary + the dependent shared
libraries.
Bey
Rainer
yug k wrote:
> Hi All,
>
> I've had a core dump with rxapi while t
Hello,
Rick McGuire wrote:
> But none of that code would modify the server pointer value in the
> enclosing APIServerThread instance. The root problem is the server
> field in that instance getting set to NULL. There are precisely 3
> references to that field in the entire code base.
>
> 1) Th
Hello Rick,
Rick McGuire wrote:
> I doubt this a synchonization problem. The APIServerThread instance
> is only accessed by the local thread and really just has a few fields.
> The call in question occurs here:
>
>
> /**
> * Dispatch the newly created reader thread to do it's work.
> */
> void
Hello,
Rick McGuire wrote:
> Hmmm, something very strange going on here, most likely a memory
> overlay of some sort. From the stack trace, the nil value passed to
> sessionTerminated() is clearly wrong, which results in an access of
> 0x005c getting used for the list, causing the trap. My o
Hello,
please could you also post the output from:
dbx rxapi
(dbx) where
...
The core should be in the same directory as rxapi.
Bye
Rainer
yug k wrote:
> Hi All,
>
> I've had a core dump with rxapi while testing ooRexx 4.0.0 on AIX
> 5.3.0.0 . I've raise a bug for the same couple of days ago
Hello,
yug k wrote:
> Hi All,
>
> I've had a core dump with rxapi while testing ooRexx 4.0.0 on AIX
> 5.3.0.0 . I've raise a bug for the same couple of days ago bearing Bug
> ID 2844093 on SF . Please find the core dump attached in this mail .
>
What is the output of:
oslevel -s
lslpp -L xlC.rte
Hello,
the commit was not working ... someone was a bit faster :-))
Bye
Rainer
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployme
rrency_dir)/TrappingDispatcher.cpp \
I'll commit the fix...
Bye
Rainer
Rainer Tammer wrote:
> Hello,
> the current trunk (5100) does not compile:
>
> cp ./interpreter/RexxClasses/*.orx .
> cp ./interpreter/platform/unix/*.orx .
> ./rexximage
> exec(): 0509-036 Cannot load program
> /da
Hello,
the current trunk (5100) does not compile:
cp ./interpreter/RexxClasses/*.orx .
cp ./interpreter/platform/unix/*.orx .
./rexximage
exec(): 0509-036 Cannot load program
/daten/source/ooRexx/main32/trunk/.libs/lt-rexximage because of the
following errors:
rtld: 0712-001 Symbol __vft16UninitDi
Hello,
Mark Miesfeld wrote:
> All,
>
> The Fedora Core 10, 64-bit rpm, worked fine on SuSE 11. Since David
> built a Fedora Core 11 rpm, I went to test that on Fedora 10 and SuSE
> to minimize the number of different rpms we needed.
>
> The Fedora 11 rpm worked fine on Fedora 10. But, when I test
Hello,
currently I am preparing the AIX release of ooRexx 4.0.0.
The packages will be ready on Monday.
Bye
Rainer
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your repo
Hello David,
I just tested HOSTEMU on AIX - only a very quick test (EXECIO read
function).
Compared to linein() this thing is extremely fast (300.000 lines in 8s)
Do you plan to put this in ooRexx 4.0.n (n > 0) ??
Do you already have a version for Windows (my colleague would love this).
Bye
Hello,
the SVN 5077 4.0 beta looks good on AIX.
The 32 bit and 64 bit 4.0.0 test suite passes to 100%.
The callrexxN examples are working. I can see no obvious problems.
Bye
Rainer
David Ashley wrote:
> All -
>
> Are we ready to deliver 4.0? The number of bugs opened has slowed to a
> crawl an
Rick
>
>
bye
Rainer
> On Sat, Aug 8, 2009 at 8:01 AM, Rainer Tammer wrote:
>
>> Hello,
>> this is a very simple test program:
>>
>> * build53.some.org resolves and exists
>> * build55.some.org does not resolve and does not exist
>>
&g
Hello,
this is a very simple test program:
* build53.some.org resolves and exists
* build55.some.org does not resolve and does not exist
#!/usr/bin/rexx
If RxFuncQuery("SockDropFuncs") then
do
rc = RxFuncAdd("SockLoadFuncs","rxsock","SockLoadFuncs")
rc = SockLoadFuncs()
end
say SockGetHostB
Hello,
I think that the last paragraph in the INSTALL read me should be changed:
Suggestion:
snip ---
Checkout, Build, and Install from the Subversion Repository
===
The entire source tree for oo
-- resend / the first version got messed up --
Hello David,
David Ashley wrote:
> Moritz -
>
> This is exactly what the configure script does.
> It creates files including config.h, Makefile,
> etc from the information in the configure.ac file
> and dynamic testing of platform. All this depen
Hello David,
David Ashley wrote:
> Moritz -
>
> This is exactly what the configure script does. It creates files
including config.h, Makefile, etc from the information in the
configure.ac file and dynamic testing of platform. All this depends on
the libtool, autoconf, automake and other GNU tools
Hello,
Moritz Hoffmann wrote:
> Rainer Tammer schrieb:
> > Hello,
> > I want to cleanup the different types of #defines in ooRexx.
>
> What could help would be shifting away from command line defines to a
> config.h file that contains all the defines.
Yes,
this was my lo
t way in the C++ code.
I intend to changed this to:
#if defined(OPSYS_XXX) or #if !defined(OPSYS_XXX)
Does anyone see a problem in this ?
If so please give a short explanation and one sample..
Thanks very much.
Bye
Rainer
> David Ashley
>
> On 08/06/2009 10:53 AM, Rainer Tammer wrote
Hello,
Rick McGuire wrote:
> The cleanup for #defines in the platform-specific code is far from
> complete. A lot of this was inherited from the original IBM code,
> which was not done very consistently. I'm not even sure how/where the
> GENERIC_OS and GENERIC_OPSYS flags are used. This is cert
(AIX)
#if defined(OPSYS_AIX)
#ifdef AIX
...
What is the preferred way ?
Do we really need the "OPSYS_" version ??
Should I changed this to:
A: OPSYS_AIX, OPSYS_LINUX, OPSYS_SUN, ...
B: AIX, LINUX, SUN, ...
I would vote for version B.
Bye
Rai
1 - 100 of 247 matches
Mail list logo
