Re: 5.8.0 release candidate status

Here are the results of the individual tests: $ @[.vms]test .exe "" "-v" [.op]pack.t ok 189 Improperly handled condition, image exit forced. Signal arguments Stack contents Number = 00030001 Name = 04B40

Re: [PATCH @17190] configure.com: join the sPRI... party

There isn't a separate option for "64ptr" because of Perl's many integer-to-pointer-and-back assumptions. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen

Re: [PATCH @17190] configure.com: join the sPRI... party

Craig Berry wrote: !We have those. Last time I built with them I get all tests passing, though !the definition of "all" in use64bitall may or may not include everything it !does on other platforms. ! !>I see that both CC and CXX support the /POINTER=64 !>or /POINTER=LONG qualifier. ! ! !The siz

Re: [PATCH @17190] configure.com: join the sPRI... party

At 04:04 PM 6/12/2002 -0400, [EMAIL PROTECTED] wrote: >While messing with long types I wonder: has anyone >considered support for configuring with >"-Duse64bitint" and/or "-Duse64bitall"? We have those. Last time I built with them I get all tests passing, though the definition of "all" in use64

Re: [PATCH @17190] configure.com: join the sPRI... party

Craig Berry wrote: !--- configure.com;-0 Sat Jun 1 12:02:50 2002 !+++ configure.com Tue Jun 11 21:19:50 2002 !@@ -2970,24 +2970,12 @@ `mms test` obtains: All tests successful. u=111.66 s=0 cu=0 cs=0 scripts=630 tests=63941 compaq c 6.5, vms 7.3. While messing with

VAX math problems (was Re: 5.8.0 release candidate status)

At 11:38 AM 6/12/2002 -0400, Brian Tillman wrote: >Here are the results of the individual tests: > >$ @[.vms]test .exe "" "-v" [.op]pack.t >... >ok 189 > Improperly handled condition, image exit forced. Life is not good in D_FLOAT land. Even if the tests make unreasonable assumptions about ex

possible VMS v5.5 fix (was RE: 5.8.0 release candidate status)

Henry, I think (hope) this will take care of the compilation problems you are having. For the GNU-impaired, I supply the patch as the result of a DIFFERENCES/SLP command. To apply, set default to the [.vms] directory, create the file vms_c_patch.upd from what I've included below, and execute

RE: 5.8.0 release candidate status

At 12:25 PM 6/12/2002 -0400, Henry A. Frystak - System Manager wrote: >> > Downloaded the above snapshot and >compiled it on my aging Vax system. Details are: VAX/VMS V5.5-2 on a VAXstation >4000-90a, Multinet V4.2 Rev A-X, DEC C V5.5-002 (yes, I know its old, but the

RE: 5.8.0 release candidate status

>From: MX%"[EMAIL PROTECTED]" "Craig A. Berry" 10-JUN-2002 17:13:18.45 >To:MX%"[EMAIL PROTECTED]" >CC: >Subj: 5.8.0 release candidate status > >Thanks to those who have been testing RC1. Some problems that have come up >have been resolved but there is room for a lot more testing. Rel

Re: 5.8.0 release candidate status

At 9:15 AM -0400 6/12/02, Brian Tillman wrote: >I'm not sure how to run these individually. Using an example that I thought >appropriate, I tried the following: > >$ @[.vms]test .exe "" "-v" [.t.op]pack.t Close. Paths as spit out by the test suite are relative to the top-level directory, but pa

Re: 5.8.0 release candidate status

>More than likely all these are D_FLOAT issues, i.e., they depend on the >ability to represent numbers bigger than 1.7e38. It would be nice to know >more details, though, if you have time to run them individually. I'm not sure how to run these individually. Using an example that I thought appro

Re: 5.8.0 release candidate status

>Thanks for the report. OpenVMS VAX 7.2, C 6.4, right? Yes. >Are you running Multinet? I think we've now got something in README.vms >about this. Oh. Right. I saw the conversation when this was detected. I just didn't associate it. I could switch to SOCKETSHR, but I have the newer Multine