Activity for vms-ports
-
David Jones posted a comment on discussion Porting Project Discussions
I put out a new exec_convert kit (007). The main new feature is it better handles text in the spreadsheet that isn't 7-bit ASCII. .xlsx files store text using UTF8, which xlsxvtab virtual tables now decode and convert to the 8-bit DEC MCS character set byte default. If you want to disable the conversion, issue the SQL statement "SELECT xlsxvtab_config('text_convert', NULL);" prior to creating the virtual table (or first access if already defined in the schema). The default DECMCS mode can do some...
-
vms-ports released /SQLITE3/excel_convert_007.zip
-
-
I did a routine update of the kit to use the latest SQLite release, 3.49.2. There is also an updated gstvtab virtual table kit (gstvtab_003.zip). The new gstvtab tracks the library modules so you can find out which module defines a symbol. It can now show you symbol attributes for object library symbols (but not shareable image library symbols).
-
-
-
-
-
-
-
-
-
-
-
-
-
John Malmberg modified a wiki page
Packages
-
I add kit 52 to the files area. It has an experiment MMS file for building with clang on X86 systems. It also fixes a bug in handling of filenames/directories which contain special characters (the kind which require quoting with '^'). The names tend to give the CRTL problems, and failure of a decc$translate_vms() can lead to a program crash.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
The current kit is now 50 and comes with SQLite 3.47.0. The speedtest1 program runs dramatically faster with 3.47 than 3.46. They apparently tweaked the resident pages it the cache so speedtest1 makes 98% fewer I/O calls to the VFS.
-
-
-
-
-
-
-
I added a new incremental update to kit 48, superceding the 20240623 incremental (I'll wait until SQLite makes a new release before making a new full kit). The changes made have to do with the perf_timer VFS option: I wanted to better track how well the internal file cache was working so added statistics counters to that code. When enabled by bit 2 in the perf_timer setting, the new counters will produce a report showing: * Read/write ratio of calls to from the SQLite library to the VFS * The read...
-
I added a new incremental update to kit 48, superceding the 20240623 incremental (I'll wait until SQLite makes a new release before making a new full kit). The changes made have to do with the perf_timer VFS option: I wanted to better track how well the internal file cache was working so added statistics counters to that code. When enabled by bit 2 in the perf_timer setting, the new counters will produce a report showing: * Read/write ratio of calls to from the SQLite library to the VFS * The read...
-
-
-
I found a bug in VSI's C compiler for X86 that makes some of SQLite's builtin aggregate SQL functions not work. I made a workaround (re-implement SUM(), AVG(), TOTAL() in a auto-loaded extension built into the VMS VFS) and made it available in an 'increment' kit: vmsvfs_in20240623.zip. Note that the bug does not affect Alpha or IA64.
-
I found it strange that I hadn't encounter the problem with SUM before now, further investigation shows that: 1. SQLite didn't use the Kahan-Babushka algorithm until version 3.43.0, released in August 2023. 2. The cross-compiler for X86 doesn't appear to have the bug. The updated algorithm attempts to get a more accurate sum when the list of addends includes both large magnitude and small magnitude values. The problem is it depends upon strict ordering of operations which optimizing compilers would...
-
-
I found a bug in VSI's C compiler for X86 that makes some of SQLite's builtin aggregate SQL functions not work. I made a workaround (re-implement SUM(), AVG(), TOTAL() in a auto-loaded extension built into the VMS VFS) and made it available in an 'increment' kit: vmsvfs_in20240622.zip. Not that the bug does not affect Alpha or IA64.
-
-
I added kit 48 to the files area, mainly to update the embedded SQLite sources to 3.46.0. I also added the cstruct_01 kit for a virtual table extenssion I wrote to optimize buik loads of database tables. Strangely the performance improvement is much more my laptop with X86 VMS and other platforms I've tested: Alpha OVms, IA64 OVms, Pi 4 (ARM) Debian Linux, i5 Mac mini. Cstruct Example <nowiki> // database schema: CREATE TABLE parts(id INTEGER, name TEXT); // CREATE VIRTUAL TABLE input USING // cstruct('{int...
-
-
-
-
-
-
-
-
The files area now has kit #46, intended for building with SQLite 3.45.0. It also includes the updated vtablib.c I enhanced for use with the vms_auth_xx.zip kits (vms$auth is a virtual table function that lets privileged users map the SYSUAF data to an SQLite virtual table).
-
-
-
-
-
-
-
-
-
-
I put kit #44 in the files area. It uses the latest SQLite version, 3.43.2. They seemed to have tweaked something that makes the speedtest1 benchmark faster (noticeable, though not dramatic).
-
-
-
-
Would it help to use /L_DOUBLE=64 on the command line to tell it to use ordinary double as long double instead of doing anything fancy inside of SQLite? Adding that qualifier does stop the compiler crashes and my main test program (speedtest1) runs the same as the previously patched code. All I did was edit build_library.com, changing line 22 to: $ x86_skip_list = ",GEOPOLY,UTIL," And insert after line 114: $ if f$getsyi("ARCH_NAME") .eqs. "x86_64" then cflags = cflags+"/L_DOUBLE=64"
-
Craig A. Berry posted a comment on discussion Porting Project Discussions
Would it help to use /L_DOUBLE=64 on the command line to tell it to use ordinary double as long double instead of doing anything fancy inside of SQLite? The problems with long double on x86 are in the release notes, so they know about it but it just hasn't gotten prioritized yet. On Sep 7, 2023, at 3:53 PM, David Jones osuvman@users.sourceforge.net wrote: I added kit #43 to the files area. It uses the SQLite 3.43.0 sources, which required an extra patch to build under X86_64. SQLite wants to support...
-
I added kit #43 to the files area. It uses the SQLite 3.43.0 sources, which required an extra patch to build under X86_64. SQLite wants to support the long double data type, but will let you fall back to another type by defining a SQLITE_LONGDOUBLE_TYPE macro. For prior versions of SQLITE I used this workaround for building on X86 due to the VSI C compiler's broken support for long double. A change to the SQLite sources started using long double constants in a few areas, which makes the compiler...
-
-
-
-
-
-
-
-
Gary Sparkes posted a comment on discussion Open Source on OpenVMS Conference Calls
So I don't think there are any legal restrictions that would preclude VSI from releasing OpenSSH for HPE releases of VMS. But it's awfully hard to think of any reason that they would do so. Well, as I said before, I had heard that they can't offer any binary packages - open source or not - for VSI branded releases, hence not releasing anything for VAX even though they support customers with VAX because of their license agreement. I suppose they could provide a patch set and MMS file for you to build...
-
-
-
-
-
-
On May 29, 2023, at 12:37 AM, Gary Sparkes garysparkes@users.sourceforge.net wrote: I have not yet had a chance to test the Alpha OpenSSH port, need to take the time to manually install it as the initial kit was tied to VSI specific versions of OpenVMS, not that is should be. I recall that being a licensing issue - VSI can't support HP VMS at a code fix level/release updates/updated LPs for it, only VSI builds. While for example, i'm told they have the rights to do a VAX release, they can't release...
-
I have not yet had a chance to test the Alpha OpenSSH port, need to take the time to manually install it as the initial kit was tied to VSI specific versions of OpenVMS, not that is should be. I recall that being a licensing issue - VSI can't support HP VMS at a code fix level/release updates/updated LPs for it, only VSI builds. While for example, i'm told they have the rights to do a VAX release, they can't release (only do tech support/troubleshooting - but not issue patches) any updates/fixes...
-
I have not yet had a chance to test the Alpha OpenSSH port, need to take the time to manually install it as the initial kit was tied to VSI specific versions of OpenVMS, not that is should be. I recall that being a licensing issue - VSI can't support HP VMS at a code fix level/release updates/updated LPs for it, only VSI builds. While for example, i'm told they have the rights to do a VAX release, they can't release (only do tech support/troubleshooting - but not issue patches) any updates/fixes...
-
-
-
-
Bill Pedersen modified a wiki page
Home
-
I appreciate folks looking to get back and involved. This last year has been VERY BUSY and VERY TIME CONSUMING for me both professionally and personally. I wish I could say it was slowing down or time was being freed up, but it does not seem to be the case. But it is not that I have been sitting and not doing anything. Most of my open source effort has been around tools to support monitoring OpenVMS for customers and feed data to some of the newer tools, such as SPLUNK>. A couple customers are either...
-
Please take a look at https://sourceforge.net/p/gnv/gnulib_assist/ci/master/tree/vms/vms_gnulib_assist.md . One of the big problems we have had is that the VMS CRTL is not compatible enough with Linux and that we can not run tests. If we can get gnulib-assist fully fleshed out and tested, we can get a lot of stuff both ported and tested. The testing is sorely needed. We get a lot of bug reports where something does not work that would have shown up if we had run the unit tests. We also get bug reports...
-
Howdy! I know a few of us are coming out of the woodwork with the outpouring of new interest from the floodgates of x86 slowly opening, it definitely looks like more troops are starting to arrive! Just a few months ago I got my own copies and booted up my itanium to start moving stuff forward off of it for the first time in 6-7 years! At this rate i'm going to have to dig out my Alpha too... i've been writing the past month entirely new code, and my first test case/user was on a physical VAX of all...
-
I added kit #41 to the files area. The native VSI compiler for X86 exposed a bug in the code handling the SQLITE_HISTORY environment variable, so previous kits built with it will generally hang i(CPU loop) f SQLITE_HISTORY is defined as a logical name. The native compiler chokes so spectacularly on amalgamation builds that I modified descrip.mms to made the default dist_type 'preprocessed' when executed on X86_64 machines.
-
1 >
