Activity for vms-ports
-
David Jones posted a comment on discussion Porting Project Discussions
I added kit 56 to the files area. This one has more than usual changes, mostly to prepare for upcoming changes in the SQLite shell program. The shell in the next version defaults to 'box' mode, which output UTF-8 box-drawing characters (akin to the DEC EGS mode). The upcoming shell consolidates output into a central sqlite3_format_query_result function that I incorporated into the roquery program.
-
vms-ports released /SQLITE3/sqlite3_vms_056.zip
-
-
-
-
Thanks for the feedback.
-
Martin Vorlaender modified a comment on discussion Porting Project Discussions
Hi everyone! I now have finally had the time to look at SQLite for VMS, something I have long wanted to. First: thanks a lot, David, for the effort you put into this. To make deployment work, I had to make some small changes to DEPLOY.COM: --- deploy.com;1 2026-02-19 10:53:14 +0100 +++ deploy.com;2 2026-02-19 12:51:34 +0100 @@ -149,7 +149,7 @@ $ item_name = cf_clang $ i = i + 1 ! skip VFS image. $ else -$ item_name = cf_vsic; +$ item_name = cf_vsic $ endif $ return $!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!...
-
Hi everyone! I now have finally had the time to look at SQLite for VMS, something I have long wanted to. First: thanks a lot, David, for the effort you put into this. To make deployment work, I had to make some changes to DEPLOY.COM: --- deploy.com;1 2026-02-19 10:53:14 +0100 +++ deploy.com;2 2026-02-19 12:51:34 +0100 @@ -149,7 +149,7 @@ $ item_name = cf_clang $ i = i + 1 ! skip VFS image. $ else -$ item_name = cf_vsic; +$ item_name = cf_vsic $ endif $ return $!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!...
-
-
-
-
-
-
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...
-
-
-
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...
-
-
-
-
-
1 >
