Activity for vms-ports
-
vms-ports updated /SQLITE3/README.txt
-
-
-
David Jones modified a comment on discussion Porting Project Discussions
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...
-
John Malmberg posted a comment on discussion Open Source on OpenVMS Conference Calls
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.
-
-
-
-
-
-
-
-
-
-
-
-
-
I put kit #38 in the files area. In addition updating the SQLite version 3.40.0, it includes the correct version of roquery.c. I also made changes in the way the options file for building sqlite3shr.exe is generated (generate_options.c was refactored so updating the image IDENT and GSMATCH no longer required editing the template file each time changes to the SQLite API extend the symbol vector).
-
-
-
-
I added the kit #37 to the files area, bringing it up to version SQLite 3.39.3. It also now includes the source for roquery source file and builds it with the other images. For Alpha builds, I was using the __RPCC builtin as one of the entropy sources for initializing the PRNG. I changed it to call SYS$RPCC_64() instead, which appears supported on Alpha, IA64, and X86_64.
-
-
-
-
Since most of my SQLite applications make use of a small support library I wrote, I decided to add its dozen or so routines to the sqlite3_vms_vfs shareable image. The files area now has an incremental update, vms_vfs_inc20220627.zip, that contains the new code and shareable image build.The distribution segregates the code for this library (statement_store.c) in its own [.sps] subdirectory rather than the directory that holds the modules specific to the SQLite port ([.port]). The HTML 'reference...
-
-
I updated the kit iteration to 36 (sqlite3_vms_036.zip). The main change is updating to SQLite 3.38.5, which seems to be stable. I also tinkered with the #VMS_GETQUI extension module as a way to investigate the some of the new library functions added in 3.38.0 (sqlite3_vtab_in(), sqlite3_vtab_in_first(), sqlite3_vtab_next()https://sqlite.org/c3ref/vtab_in_first.html).
-
-
-
-
We started these discussions and exchanges a DECADE ago!!! A LOT has been discussed and a lot has happened. Many improvements have been made in the process. BUT… After thinking about the state of mind of many of us – tired, withdrawn, frustrated and detached. As well as my own commitments to work and family, I have come to the conclusion that we should all take a break from the conference calls and focus on ourselves and when there is time work to get some progress on the various Open Source projects...
-
Upcoming conference call dates AND TIMES: Thursdays (Eastern US Time): 16 Jun 2022 at 23:00 EDT 21 Jul 2022 at 08:00 EDT No Call in August 15 Sep 2020 at 08:00 EDT The conference calls use JITSI, which does all of the processing through the web browser. We have tested with Firefox, Edge, and Chrome on Windows and Chrome/Chromium on Linux. We do not plan on using video... Although we may share items from desktops... Thanks to Jouk Jansen for providing this facility to our community! To attend the...
-
I put my latest kit, sqlite3_vms_035.zip in the files area. Not many changes: Remove definition of SQLITE_CORE from platform.h so you can use this header file in extensions. Fixed bug in 64-bit build (was linking shell64.exe against 32-bit shareable). Made generation of sqlite3-vms.c by patch.com a little more efficient. Allow you to change the shell program's configuration file (~/.sqliterc) using the logical name SQLITE3_SHELL_INIT. The logical name can be a search list, e.g. SYS$DISK:[],SYS$LOGIN:,...
-
While the quickview program was an interesting exercise (mainly to re-implement my dynamic DCL_PARSE table generation code in C), I don't use it interactively very much. I have found its ability to output the query results as DCL symbols useful inside of command procedures, though. I wrote a small program, roquery.c, that makes this useful feature its primary mission while adding a couple features: The database file specification is converted to URI format with an immutable=1 attribute added. This...
-
While the quickview program was an interesting exercise (mainly to re-implement my dynamic DCL_PARSE table generation code in C), I don't use it interactively very much. I have found its ability to output the query results as DCL symbols useful inside of command procedures, though. I wrote a small program, roquery.c, that makes this useful feature its primary mission while adding a couple features: The database file specification is converted to URI format with an immutable=1 attribute added. This...
-
While the quickview program was an interesting exercise (mainly to re-implement my dynamic DCL_PARSE table generation code in C), I don't use it interactively very much. I have found its ability to output the query results as DCL symbols useful inside of command procedures, though. I wrote a small program, roquery.c, that makes this useful feature its primary mission while adding a couple features: * The database file specification is converted to URI format with an immutable=1 attribute added. This...
-
-
-
I put my latest kit, sqlite3_vms_035.zip in the files area. Not many changes: Remove definition of SQLITE_CORE from platform.h so you can use this header file in extensions. Fixed bug in 64-bit build (was linking shell64.exe against 32-bit shareable). Made generation of sqlite3-vms.c by patch.com a little more efficient. Allow you to change the shell program's configuration file (~/.sqliterc) using the logical name SQLITE3_SHELL_INIT. The logical name can be a search list, e.g. SYS$DISK:[],SYS$LOGIN:,...
-
I put my latest kit, sqlite3_vms_035.zip in the files area. Not many changes: * Remove definition of SQLITE_CORE from platform.h so you can use this header file in extensions. * Fixed bug in 64-bit build (was linking shell64.exe against 32-bit shareable). * Made generation of sqlite3-vms.c by patch.com a little more efficient. * Allow you to change the shell program's configuration file (~/.sqliterc) using the logical name SQLITE3_SHELL_INIT. The logical name can be a search list, e.g. SYS$DISK:[],SYS$LOGIN:,...
-
-
1 >