MSS Code Factory 2.9 (production) Release History

2018-02-18 MSS Code Factory CFAll 2.9.14156 All of the C++14 WLS projects now build and link

This release is the culmination of nine months of working producing not quite 26 million lines of clean compiling and linking C++14 code.

Now begins the debugging...

2018-02-18 MSS Code Factory CFCore 2.9.14144 Archive script updated

I'm repackaging and re-issuing CFCore 2.9.1444 to capture a minor change to the Archive script. The zip files are now compressed with the -9 option, saving upload and download time, and server space.

2018-02-18 MSS Code Factory CFLib 2.9.14143 Archive script updated

I'm repackaging and re-issuing CFLib 2.9.14143 to capture a minor change to the Archive script. The zip files are now compressed with the "-9" option, saving upload and download time, and server space.

2010-02-13 MSS Code Factory CFAll 2.9.14153 Script and rule changes to build 2.10 projects

The scripts and rules have been updated to produce WSL builds for the 2.10 projects.

The Debian/Ubuntu support has been stripped from the 2.10 builds.

2018-02-09 MSS Code Factory CFAll 2.9.14150 Synchronized release

This is the synchronized release of MSS Code Factory 2.9 for Windows 10 and Windows 10 WSL Ubuntu. As cross-platform Java code, it also runs on pretty much any platform supporting JDK 9. All requirements for a GUI have been stripped from the 2.9 code base; there is no more CFBamEditor. That feature won't come back into play until MSS Code Factory 10.

The documentation has also seen extensive updates.

2018-02-08 MSS Code Factory Programmer's Notes

I may no longer have a Linux system, but Windows Services for Linux with Ubuntu 17.04 is coming along nicely. I've successfully built 2.8 under the code stack, suppressing the deprecated code warnings as I've no interest in carrying the 2.8 code base any further than it has to go.

I've been busy seeing what I can do with the combination of Windows 10 and WSL Ubuntu development environments. (I'll just refer to the Ubuntu environment as "WSL" for the future.)

I installed the JDK 9's for both environments -- Oracle JDK 9 for Windows and openjdk-9-jdk-headless for WSL.

Git and ant were installed for both environments. Ant for WSL recommends a whole bunch of extra stuff to go with it, and I installed pretty much all of the recommendations.

There were some extra Windows tools to install to support GPG signing and SSL encryption. Both environments have been configured, though I can't get GPG encryption and SSL encryption to share keys; they use different armored formats.

You'll do a lot of googling for things like "Windows SSL git config" and "Windows Kleopatra Git config", but I'm not going to document the details -- there is plenty of fine documentation out there that I just followed to get things up and running.

I pruned the JavaFX code from 2.8 and 2.9 so they can both be built with openjdk-9-jdk-headless. That means no more CFBam editor. That will only exist for the 2.10 code base.

The build environments used for the projects are as follows:

I have a collection of environment scripts in the home-template directory of the download server. There are initialization files for the WSL and Windows home directories there. Don't forget to replace the "dot-" part of the file names with ".".

I also have a copy of the jars I depend on for Java builds in the apache.org directory of the download server. Most of these are the versions from Ubuntu 17.04 and the relevant apache.org websites, refreshed only this past fall.

I expect MSSCFHOME to be set to "d:\msscodefactory" under Windows. In theory you could point it somewhere else, but I kind of assume you're on D:. I should probably add an MSSCFDRIVE environment variable that specifies the drive letter and then an MSSCFDIR that is MSSCFDIR without the drive letter. MSSCFHOME would then be set to match. If I then specify "%MSSCFDRIVE%:" in my scripts instead of "d:", I should be able to make the installation location-agnostic, though I do assume exactly one installation per machine.

Correspondingly, MSSCFHOME needs to be set to the /mnt/drive/msscodefactory location matching the Windows directory in your .profile. You'll find the pattern strings "Your Name" and "your@email.address" littering the template files. Edit them accordingly. You'll also need to edit the SSL and GPG key ids according to your keys.

I need to document the system environment variables and PATH elements I expect you to set for the Windows 10 environment. I rely on those in my scripts.

2018-02-07 MSS Code Factory CFAll 2.9.14148 Production release of JDK 9 code base

This is the production release of the JDK 9 code base and rule cartridge, producing a clean build of the 2.10 projects.

2018-02-07 MSS Code Factory CFAll 2.9.14145 Working release for Windows JDK 9

This is a working release built with Windows JDK 9. The 2.10 projects will also be built with Windows JDK 9. Only 2.8 is built with the Linux OpenJDK 9 headless.

2018-02-07 MSS Code Factory CFCore 2.9.14144 Clean synchronization build under Windows stack

The CFCore 2.9 build has been synchronized with the latest code manufactured by MSS Code Factory 2.8, and built with CFLib 2.9.14143.

2018-02-07 MSS Code Factory CFLib 2.9.14143 Clean synchronization build under Windows stack

The 2.9 and 2.10 Java code bases will only be compiled with the Windows tool stack, as openjdk-9-jre-headless is insufficient for too much of the code base. You just can't run the latest code under WSL. (Well, you *can*, but the OpenJDK 9 runtime gripes about the Oracle JDK 9 produced .class files having a newer version number than OpenJDK supports. It will run, provided you don't touch any GUI classes during execution.)

The builds have been cleaned up such that they only reference the WSL openjdk-9-jre-headless.

2018-02-06 MSS Code Factory CFCore 2.9.14139 Clean compile for Java JDK 9

There were three unavoidable errors about unchecked/generic types in one file, so I added @SuppressWarnings("unchecked") to those three methods to shut the compiler up. Other than that, all of the CFCore 2.9 code is now JDK 9 compliant.

2018-02-06 MSS Code Factory CFLib 2.9.14138 Correct packaging error

The CFTip objects weren't in the jar because the path to them was specified incorrectly by the build.xml.

2018-02-06 MSS Code Factory CFLib 2.9.14137 Clean compile for Java JDK 9

CFLib 2.9 now compiles clean with JDK 9. The main deprecation corrected was to replace the syntax "new Type( value )" with "Type.valueOf( value )".

There was also a stale reference to a private file that crept into my code somewhere. I would certainly never have referenced a private file intentionally.

2018-02-04 MSS Code Factory Windows 10 Environment ready to begin testing

I've installed and configured:

Windows 10 Home 64-bit
The big Kahuna. Financially: OUCH!
390.65-desktop-win10-64bit-international-whql.exe
Latest NVidia drivers.
MSSCFHOME
mkdir /mnt/d/msscodefactory
/mnt/d/msscodefactory/keys
mkdir and disable permission inheritance, read access to Authenticated Users, full access to Users/msobkow@sasktel.net, read access to Administrators, all other permission groups removed. Set same permissions on external hard drive backup of keys directory.
Google Chrome
My preferred browser nowadays
NortonNSDownloader.exe
Norton Anti-Virus. Discount for first year of subscription.
vlc-2.2.8-win32.exe
VLC media player
Thunderbird-Setup-52.5.2.exe
Thunderbird EMail (removed Sunbird add-on)
Apache_OpenOffice_4.1.5_Win_x86_install_en-US.exe
Open Office
OriginThinSetup.exe
EA/Origin game management client
SteamSetup.exe
Steam game client. 35 games to install. Took a few days.
uTorrent.exe
Gotta have my torrents
Windows Services for Linux, Ubuntu amd64 edition
Core migration tools
winzip22-paid.exe
Paid-for copy of WinZip. Ouch. No bargains here.
putty-64bit-0.70-installer.msi
PuTTY SSH tunnel with Pageant key server
gvim80-586.exe
GVim source code editor
gpg4win-3.0.3.exe
GPG4Win provides a free Windows 10 implementation of GPG
Git-2.16.1.2-64-bit.exe
The eponymous code library management system
jdk-9.0.4_windows-x64_bin.exe
Latest Oracle Java JDK 9; binds nicely to WSL
jre-9.0.4
Latest JRE came with Oracle Java JDK 9
TortoiseGit-2.5.0.0-64bit.msi
A rather nice Windows GIT integration package
FileZilla_3.30.0_win64-setup_bundled.exe
My preferred SFTP client

That included creating new RSA2048 keys using both the WSL ssh-keygen and PuTTY Keygen utilities, exporting the armored public and private keys to /mnt/d/msscodefactory/keys, disabling permission inheritance on the private keys, removing all access other than my own user id from the private key files, configuring the SSH servers under both service streams to use the saved key files, and making sure permissions for group and other only have read access to the public .asc files, and none to the private files. Read the manuals...

2018-02-04 MSS Code Factory Programmer's Notes

I've decided to try for WSL builds of the C++14 code after all. That means migrating the build environment for the Java tool chain first, which unfortunately includes a major Java JDK upgrade to release 9.

This is going to take a while.

2017-12-09 MSS Code Factory 2.9.14134 Update Package.bash scripts

Update the cplus/Package*.bash scripts to make sure the cplus/installer directory exists.

2017-12-12 MSS Code Factory CFCore 2.9.14132 Make .bash files executable

The CFCore file opening process now makes .bash files executable.

2017-12-08 Programmer's Notes

This is what I do for each release. The build numbers change, of course, but this is as close to a detailed script of the build process as I've ever produced.

Refresh 2.9 to 2.9.14132
CleanCFAll29.bash
Edit CFBam Engine version string to build 14132
Edit CFCli runtime version string to build 14132
BuildCFAll29.bash update runtime
PackageCFAll29.bash
Commit 2.9.14132 code base, noting pre-debugging base code
ManufactureCFAll210.bash remanufacture all projects to show new version stamps
GitCFAll210.bash add .
GitCFAll210.bash commit remanufactured 2.10.14133 code base, noting pre-debugging base code

Inject CFLib 2.10.14133
Edit htdocs releases-2.10.html and welcome.html to log update injection
of MSS Code Factory CFLib 2.10.14133
cd htdocs
git add .
git commit comments about update injection
git push
cd ..
cd net-sourceforge-MSSCodeFactory-CFLib-2-10/cplus
./PackageCFLib210.bash 14133
cd ..
git add .
git commit comments about injected CFLib 2.10.14133
git push
cd ..
cd net-sourceforge-MSSCodeFactory-Cartridge-2-9/cplus
edit rules referencing libcflib to specify build 14133
git add .
git commit comments about update injection
git push
cd ../..
ManufactureCFAll210.bash
vi net-sourceforge-MSSCodeFactory-CFBam-2-10/java/cfbammsscf210custom/src/*Engine.java version number to 14134
add bootstrapBindings2() near line 5000 of net-sourceforge-MSSCodeFactory-CFBam-2-10/java/cfbammsscf210/src/*Engine.java
GitCFAll210.bash add .
GitCFAll210.bash commit comments about update injection
GitCFAll210.bash push

End of work for now: 2017-12-09-06:00:00

Debug CFSecurity XML Loader initialization.
This is where the magic happens.
cd net-sourceforge-MSSCodeFactory-CFSecurity-2-10/cplus

For each debug cycle:
ManufactureCFSecurity210.bash cplus
ManufactureCFSecurity210.bash cplus+xml
ManufactureCFSecurity210.bash cplus+ram
ManufactureCFSecurity210.bash cplus+ram+loader
./BuildCFSecurityAll.bash 14134
ddd

Release CFLib 2.10.14133
cd htdocs
Edit htdocs releases-2.10.html and welcome.html to log release tick 2.10.14133
git add .
git commit comments about release tick 2.10.14133
git tag -s 2.10.14133 comments about release tick
git push
git push --tags
cd ..
cd net-sourceforge-MSSCodeFactory-CFLib-2-10/cplus
./PackageCFLib210.bash 14133
git add .
git commit comments about release tick 2.10.14133
git tag -s 2.10.14133 comments about release tick
git push
git push --tags
cd ..
Update 2.10 projects with debugged rule changes
ManufactureCFAll210.bash

Build 2.10 Java and C++14 projects
BuildCFAll210.bash
Many more steps for C++14 builds right now, as I'm not ready to let the computer run free while I wait.

Package 2.10.14134 Java and C++14 packages
May need to copy-paste-edit PackageBlah.bash scripts.

Archive 2.10.14134 source code
ArchiveCFAll210.bash 14134

Push 2.9.14132 to git
Update htdocs with 2.9.14132 release notes for debugged security code
git push htdocs
git tag -s 2.9.14132 htdocs release notes for debugged security code
git push htdocs
git push --tags htdocs
GitCFAll29.bash add .
GitCFAll29.bash commit release notes for debugged security code
GitCFAll29.bash tag -s 2.9.14132 release notes for debugged security code
GitCFAll29.bash push
GitCFAll29.bash push --tags

Issue 2.9 release of Cartridge project
cd net-sourceforge-MSSCodeFactory-Cartridge-2-9
./ArchiveCFCartridge.bash 14132
git add .
git commit --allow-empty release notes for debugged security code
git tag -s 2.9.14132 release notes for debugged security code

Push 2.10.14134 to git
Refresh htdocs for 2.10.14134
Edit releases-2.10.html and welcome.html
git add .
git commit release notes for 2.10.14134 about debugged security initialisation code
git tag -s 2.10.14134 release notes about debugged security initialisation code
git push
git push --tags
GitCFAll210.bash add .
GitCFAll210.bash commit 2.10.14134 comments about debugged security initialization code
GitCFAll210.bash tag -s 2.10.14134 comments about debugged security initialization code
GitCFAll210.bash push
GitCFAll210.bash push --tags

Post 2.9.14132
FileZilla upload of website updates and 2.9.14132 builds and packages,
including Cartridge-src 2.9.14132. Don't forget to delete previous release first to make room for the upload, especially the prior 2.10 releases.

Post 2.10.14134 release of projects
FileZilla upload of website updates (high priority) and 2.10.14133 source and distribution packages.

2017-11-26 MSS Code Factory Documentation 2.9.14131 The documentation has been updated

The documentation has been updated to incorporate the changes needed for the separated rule base.

Now edit the created .msscfrc, and make sure the following entries reference the directories created so far (adjust as necessary if you aren't using the defaults):

msscf.cartridgedir=/home/msobkow/msscodefactory/net-sourceforge-MSSCodeFactory-Cartridge-2-9/cpluscartridge-2.9
msscf.cartridgedir1=/home/msobkow/msscodefactory/net-sourceforge-MSSCodeFactory-Cartridge-2-9/javacartridge-2.9
msscf.cartridgedir2=/home/msobkow/msscodefactory/net-sourceforge-MSSCodeFactory-Cartridge-2-9/dbcartridge-2.9
msscf.cartridgedir3=/home/msobkow/msscodefactory/net-sourceforge-MSSCodeFactory-Cartridge-2-9/anycartridge-2.9
msscf.modeldir=/home/msobkow/msscodefactory/net-sourceforge-MarkII-1-1/model-2.9
msscf.modeldir1=/home/msobkow/msscodefactory/net-sourceforge-MSSCodeFactory-2-9/java/model-2.9
msscf.rootgendir=/home/msobkow/msscodefactory

You'll need to download the net-sourceforge-MSSCodeFactory-Cartridge-2-9 project separately and extract it into an appropriate subdirectory under msscodefactory. As long as the paths are correct in your .msscfrc, the rules will be found. The engine itself will rarely update, but the rules update quite regularly.

2017-11-25 MSS Code Factory CFAll 2.9.14130 License header bugs corrected

It turns out you can't expand project information in a license header as is normally done with the GPL family of licenses, because you've popped past the SchemaDef, so you can't get the information about the schema that is being manufactured. I'd have to seriously rework the MSS Code Factory engine to support such a feature (the references would have to push a new GenContext before expanding the reference, so that you can PopTop to get back to the context that invoked the reference.)

2017-11-25 MSS Code Factory CFCore 2.9.14129 Rework PopTop verb

PopTop has been reworked so that it accounts for the current context being the top matching reference.

2017-11-25 MSS Code Factory CFAll 2.9.14128 Split off rule cartridges to Cartridge project

The project net-sourceforge-MSSCodeFactory-Cartridge-2-9 has been added and is now expected to be the home for the rules used by the engine. The engine will no longer be updated itself; only the rule base will be changing, and even that will be isolated to the C++14 rules as I use MSS Code Factory to produce a C++14 GNU Debian amd64 Linux binary for the forked MarkII project on my Ubuntu 17.10 system.

2017-11-14 MSS Code Factory 2.9.14126 Project complete

Originally this project was all about the MSS Code Factory engine itself and the rule base. But of course to debug the engine, I needed to develop some rule mappings to produce the code for supporting various technologies. After all, it wouldn't do if there was some technology I couldn't support with MSS Code Factory. Otherwise it wouldn't be a general-purpose tool.

Somewhere along the way, I let my focus shift to the code that was being produced by the factory, and kept enhancing and debugging it for several years until I had a Java website providing the back-end services to access any of a number of relational databases. The front-end client is completely isolated from the technology used by the back-end.

Then I decided I needed to be able to support C++14 code, and made the changes to the engine itself that were required, and got on with the business of migrating the Java code to C++14. I've put in a goodly effort on that front, and the bottom three layers and one main clean-compile. They aren't debugged, but they build. The framework is there to prove you can produce valid C++14 code with MSS Code Factory.

That is enough. It is time to put the scope-creep to bed and call this project "done."

I'm going to enjoy my retirement now. With the full honour of completing and sharing a life's work of 18 years with the world. Peace.

2017-11-14 MSS Code Factory 2.9.14126 Corrected typo so C++14 code so far will build

One last fix so the C++14 code so far will build.

2017-11-14 MSS Code Factory 2.9.14125 Latest manufactured code requires CFLib 2.10.14124

The C++14 code produced by this release requires CFLib 2.10.14124.

I've decided to abandon MSS Code Factory, despite the fact that I haven't debugged the C++14 code produced to date. Someone else can pick up the torch if they like. I'm done. I've spent 18+ years on this project, and nearly 40 years of my life coding.

I quit.

2017-11-10 MSS Code Factory 2.9.14122 Latest manufactured code requires CFLib 2.10.14121

The interace of CFLib is pretty stable, so the only changes I expect to make their way into CFLib are for the implementations, not the interfaces. Just in case there are any changes made along the way, I've pre-emptively injected CFLib 2.10.14121 to collect the potential edits.

In Obj/EditObj::copy[Buff/PKey]To[PKey/Buff]() dereference the buffer and pkey objects once instead of per-attribute. A minor performance tweak, but one that I didn't want to count on the compiler implementing automatically.

It takes less than 2 minutes to manufacture all of the C++14 code for CFSecurity 2.10, including the not-buildable-yet native MySql API support.

It takes 42 minutes on my Ryzen 5 4-core box to build CFSecurity in all its glorious layers... (MySql is a work in progress and is not in the build list yet.) I have scripts to manufacture the CFSecurity C++ layers, build/package/install them, and bundle them in distribution archives.

The less than comparisons were incorrect and always returned false no matter what inputs they were presented with, resulting in the code misidentifing id 1 as id 2 during the search. The search code style is valid; the problem was a bad comparison.

Now I need to figure out why the data pointer for the search is NULL -- an entry IS being resolved for the key "system".

I distracted myself with a dive into tidying up the formatting of the C++14 code. The changes are so drastic that I'm issuing a release to capture the changes with a tag in GitHub.

The code still does not work...

2017-11-04 MSS Code Factory CFAll 2.9.14119 Build requires latest CFLib and CFCore

The build now requires CFLib 2.9.14117 and CFCore 2.9.14118.

2017-11-03 MSS Code Factory CFCore 2.9.14118 Clean build from source

Clean build from repository source.

2017-11-03 MSS Code Factory CFLib 2.9.14117 Clean build from source

Clean build from repository source.

2017-11-03 MSS Code Factory 2.9.14116 Clean build requires CFLib 2.10.14115

Fresh build of MSS Code Factory 2.9 updated to require CFLib 2.10.14115.

2017-11-03 Back from vacation

I'm just recovering the MSS Code Factory development environment from the github repositories and some of my backup files on external media.

2017-10-24 Officially taking a vacation

I haven't really taken a proper vacation from working on MSS Code Factory for more than a couple of weeks in over 18 years. I find lately I have no interest in slinging code at all, despite the fact that I've been doing so since I was 14 years old (I'm 53.)

So, until further notice, I'm on a break. Maybe some day I'll pick up coding again and resume working on this project, but for now, I'm enjoying listening to tunes, reading, watching TV, watching movies, and visiting friends. i.e. Living a "normal" life.

Perhaps I'll opt to make it a "full retirement" after a while, and just stop working on code for the rest of my life. I've certainly put in enough time in the trenches with a 25 year paid career and over 5 years of hobby coding on disability. Nothing lasts forever; perhaps it is time to make a "life change."

Peace.

2017-10-17 Programmer's Notes

I haven't done any coding in a while, but I did get my system upgraded to the Ubuntu 17.10 Beta 2 release yesterday. Test builds were successful, so all future packaging will be for the new release. Not to worry, though -- the full official release of 17.10 is later this week.

2017-10-04 MSS Code Factory 2.9.14112 RAM Loaders attempt to create data now

September 2017 marked 18 years along the MSS Code Factory road.

The RAM loaders now completely instantiate the RAM storage objects and try to initialize them. The Cluster.create() method is invoked and succeeds, but the subsequent read-by-name fails on the next invocation of getSystemCluster().

CFLib 2.10.14111 is required by all C++14 code manufactured by this release.

2017-09-30 MSS Code Factory CFAll 2.9.14109 Debugged code to the point that RAM loader initiates

The RAM loaders now initiate and complain about a lack of input arguments, so all of my constructors are firing properly and successfully execute. One step at a time, eh?

The built-in tag CodeFactoryVersion has been added to MSS Code Factory itself, returning the string "MSS Code Factory 2.9.xxxxx" as defined by the CFCli main.

CFLib 2.10.14108 is required by all C++14 code manufactured by this release.

The initializers for the various classes in CFLib have been coordinated and tidied up. Now all the project code has to do is invoke CFLib::init() and CFLib::release() to fire all of the specific initializers in the library, as well as any dependent libraries like Xerces-C.

2017-09-27 MSS Code Factory 2.9.14106 Created rule packages loader and cplus+ram+loader

The rule packages loader and cplus+ram+loader have been added to the rule base.

The RAM loader clean compiles, links, and packages for distribution, but crashes with segmentation violations during initialization.

I figured out to get debhelper to stop clobbering my debug path information so I can use ddd to do some debugging. I've done a test run under the debugger just to verify that the information is there now. That doesn't help anyone but me, but such is life. I'm all about me... :P :P :P

2017-09-26 Programmer's Notes

For now I have specified that only the amd64 architecture is supported by manufactured projects. In the future, I'll modify the CFLib 2.10 build process to check for the integer, size_t, and pointer_t types, and verify the size of those types match a 64-bit architecture. That should allow a much wider range of architectures to run the code. After doing so, I'll revert the manufactured code to any architecture, and let the dependency on CFLib 2.10 take care of the architecture checks. If CFLib 2.10 won't pass the architecture tests, you can't run the manufactured code on it.

Specifically, [u]int[16/32/64] must be defined and of exactly the right size. size_t must be 64 bits, and pointer_t must be at least 64 bits.

2017-09-17 MSS Code Factory 2.9.14102 C++14 RAM storage builds and packages cleanly

The C++14 RAM storage layer clean compiles and packages without any unresolved symbols, but it will leak like a sieve as I've done virtually nothing about memory management, and the Java code base I started with doesn't deal with such things.

The documentation has been updated. The last vestiges of the references to artificial intelligence have been replaced by the term "Fractal Programming." I think it is better to be modest about what this tool does rather than rambling about AI stuff just because it is the current "in" technology.

Besides, I think AI makes a lot of people nervous, and there is nothing upredictable about the code this tool produces, so I think the term "fractal" captures what it does better. It produces mathematically precise code.

There is much more information about the development process found in the Git logs for MSS Code Factory 2.9; I checked in frequently to make notes about how I was progressing with my efforts.

The RAM effort started on 2017-09-08, nine days ago. So for that period, I've averaged 608200 new lines of code per day, 25341 per hour, or 422 lines per minute. Not bad productivity, eh?

2017-09-14 Programmer's Notes

I've been working away at the RAM implementation, but you should be aware that the initial release is going to leak memory like a sieve, being based on Java code.

2017-09-08 MSS Code Factory 2.9.14099 C++14 XML library leaks plugged

The C++14 XML library was leaking like a sieve. That has been corrected.

I was about to start coding the RAM layer when I realized I'll need to add a clone() method to the Buff objects so that I can easily make copies of the buffers in the RAM storage for return to the client. Unlike Java, you won't be getting back pointers to the RAM storage memory itself.

A proper separation of functionality is being imposed, the same as is in place for the database interfaces.

I also want to move the parsing methods for Enums from the implementation class to the interface for the schema. You should not need to include the implementation objects in order to parse an enum. There is no point restricting myself to the same requirements Java has when declaring an interface; C++ doesn't even have interfaces in the same sense.

2017-09-07 MSS Code Factory 2.9.14097 Skeleton for RAM C++14 migration created

The build environment for the C++14 migration of the RAM layer has been codified in the rule base. I'm ready to start working on the actual code migration, which is likely to take several days. I just wanted to do this release to flag the start of the effort; I don't expect to post another release until I have a clean build of the RAM layer.

2017-09-06 Programmer's Notes

Next up will be the RAM storage. Technically the RAM layer depends on the XML layer, so it should be coded as the cplus+xml+ram layer, but all of the databases depend on the XML layer so I'm going to treat that dependency as a given and put the rules in cplus+ram.

Yes, the RAM layer is finally becoming a layer all its own instead of living in the core rule base, and treated the same way that the other databases are for gluing together SAX Loader mains.

As I've noted, I only support 64 bit platforms, with a size_t of at least 64 bits and the full range of [u]int[16/32/64]_t types defined. Someday I'll do a cross platform Android build for my Samsung 7-inch tablet, but not for a long, long time.

2017-09-06 MSS Code Factory 2.9.14095 Xerces SAX2 XML Structured Parsers Migrated to C++14

The SAX2 XML Parsers provided by the [schema]xml[version] sub-projects have been ported from Java 8 with Xerces-J to C++14 with Xerces-C for Ubuntu/Debian amd64 platforms.

All code for this release requires CFLib 2.10.14094.

Work on this feature started 2017-08-27, nine days ago. The new lines of code were produced at an average of 151195 lines per day, or 6299 lines per hour of each 24 hour day.

I may someday do a cross-platform ARM build targetting the version of Android that runs on my 7-inch Samsung tablet. Any true 64-bit platform should work for this code, but 32-bit architectures are right out. Get with today, never mind tomorrow. 32 bit is as dead as 16 bit and 8 bit.

2017-09-01 MSS Code Factory 2.9.14093 Fleshed out cplus+xml code framework

There are now .cpp files to include the manufactured .hpp files so that their syntax can be checked by a build. The .cpp files themselves are but skeletons of what they will someday be.

2017-09-01 MSS Code Factory 2.9.14092 Outline cplus+xml code

An initial outline of the cplus+xml code is now produced by the factory.

All projects manufactured by this release require CFLib 2.10.14091 or newer.

2017-08-28 Programmer's Notes

That is it for the base and obj layers of C++14 code (at least until it is debug time.) Next up are the SAX2 parsers. I've started reading up on Xerces-C, which has changed somewhat since I last used it. (Or my memory is really, really fuzzy as I haven't used it in many long years.)

2017-08-26 MSS Code Factory 2.9.14089 Implement diamond inheritance of models for C++14

C++14 now supports diamond inheritance of the models.

2017-08-24 MSS Code Factory CFAll 2.9.14087 Correct TableRefs implementation, define Java rules using it

The TableRefs iterator implementation was checking for a SchemaDef GenDef instead of a Table GenDef. That caused runtime exceptions, of course, as the iterator is accessed from a Table's scope.

Obj.getNamedObject() should not throw exceptions if no object matching the name is found. It is perfectly reasonable to probe to check if an object exists, not knowing whether it will be found or not, as I discovered while debugging the TableRefs iterator.

The changes to the Java rules have been coded as well, and the resulting code test-compiled. Everything seems happy for Java, though it is really CFUniverse that would have seen a major difference in the resulting code. Still, there are changes to the Java interfaces for every project except the three lowest projects in the system: CFSecurity, CFInternet, and CFCrm.

I'll work on the C++14 version of the changes some other day.

2017-08-24 MSS Code Factory CFAll 2.9.14085 Add iterator TableRefs

The TableRefs iterator takes the current table and dereferences its SchemaDef. The SchemaRefs specified for the SchemaDef are then iterated, and any instances of the table name found in the referenced schema are added to the returned iteration list.

This new iterator will be used to implement the diamond inheritance of the Obj interfaces for both Java and C++14. Up until now, all projects have followed a single inheritance tree, so diamond inheritance wasn't a factor, but while looking at the CFUniversity code, I realized there was a diamond interface issue that had to be addressed.

2017-08-23 Programmer's Notes

I might have thought of an issue with the manufactured code, but I'm not sure yet.

The classes for a layer that are defined by other schemas are accessed using the objects of the DefSchema, and cast to the current layer's classes, as the implementation objects are those of the current layer.

In the server, this is definitely not an issue because the server code is always implemented using the topmost layer, and the custom server procs are re-implemented by that code, rather than invoking the version in the inherited schema. (i.e. Objects are entirely implemented by the current schema rather than inheriting implementations from the DefSchema.)

However, if you ever have a client that tries to integrate multiple inherited schemas, there is a good chance the custom code will be expecting the current schema as of the project/schema that defined the custom code. When you integrate that code in a client, the typecasts will fail for all but the top schema and the DefSchema objects.

What I think I need to do to resolve this potential issue is to build a list of all the versions of a table that are implemented by the various schemas (by searching the list of SchemaRefs, and probing each for the table name in question), and making the current schema inherit the interfaces from *all* of the referenced schemas that define the object, not just the DefSchema interface.

That way you'll be able to safely cast the implementation objects to any of the inherited schemas for the custom code to run successfully.

Even if it turns out I'm wrong about this potential issue, my fix is the correct way to implement the code; when I came up with the DefSchema rules, I wasn't considering the possibility of inheriting schemas in any way other than a direct chain of inheritance. The issue is a variation on diamond inheritance, and only comes into play when more than one schema references one of the lower level schemas (which is pretty much guaranteed to happen for CFSecurity, as *everything* includes that.)

Note that I don't have any real-world examples of these issues. They just cropped up in my head, and have had me thinking for a few days.

Regardless, coding my fix for the potential problem is next on my list before I tackle the C++14 SAX XML parsers.

2017-08-20 MSS Code Factory 2.9.14083 Added missing index files for Java

The Java rules weren't producing all of the index key objects that they were supposed to, which resulted in Mark II failing to build. This defect has been corrected. I don't know how it escaped me for so long.

The build for Mark II has been corrected as well.

2017-08-20 MSS Code Factory 2.9.14082 Tweaked dh_make invocation by Package script

The dh_make invocation by the Package script has been tweaked with a " -y" option so it doesn't prompt for user interaction, and the addition of proper --copyright specifications for ApacheV2, GplV2, LGplV2, GplV3, and LGplV3 licenses as named in the 2.9 models. Others could be added later, of course. When I have the urge to do so.

2017-08-18 MSS Code Factory 2.9.14080 Add rules for implementsClassCode(), add project model MarkII

Added and used the rules for implementsClassCode(). CFLib 2.10.14079 is required by code produced by this version of MSS Code Factory.

Added the project model for MSS Code Factory Mark II 2.10, which does NOT follow the usual "CF" prefixing, as it is a special-case beast that can only be implemented with a Java server. I'll need to wire gateway procedures for the C++14 version, initiating the goal of distributed servers. The gateway is likely to be named with the CF prefixing.

2017-08-18 MSS Code Factory 2.9.14077 CFDbTest 2.10 now clean-compiles

CFDbTest, CFCrm, CFInternet, and CFSecurity 2.10 all clean compile and package now, with no unresolved symbols reported by shlibdeps.

CFLib 2.10.14076 is required for all C++14 projects manufactured by this release of MSS Code Factory.

CFDbTestTableTableObj.cpp exposed a number of issues with returning lists of objects from server methods. Those have been corrected after numerous build attempts.

Eliminated some dead methods from the interface; they weren't being used, so why produce them?

Made consistent use of pointers for passing obj arguments.

Corrected additional dereferencing and indirection errors.

Corrected a value dereferencing error and removed NULL checks for pass-by-reference arguments.

Made Numbers accessors and variables use const specifications consistently.

Remove last vestiges of Java work-around for lack of 64-bit unsigned integers.

Add Buff constant MAX_LEN for Blob, String, Token, NmToken, NmTokens, and Text columns and use it in the .cpp files.

Corrected Min/Max Value checking

Use Generic (atomic) comparison for mpfr::mpreal values.

Requires libcflib 2.10.14076 for the unsigned type support.

2017-08-18 Programmer's Notes

I'm going to have to do some serious rework of the DB/2 LUW layers because that database doesn't support recursive procedures, which are required for my current implementation of delete stored proces.

Instead, DB/2 LUW will have to perform delete processing in the client layer, which will be a lot slower, but will allow for self-referencing objects in the models.

I'd rather have the flexibility of self-referencing objects than limit the modelled projects based on the requirement of one database of many.

2017-08-13 MSS Code Factory 2.9.14074 Add some .gitignore files

.gitignore files have been added to the libschema and libschema/debian directories. Otherwise git tries to put your compiled code in the repository.

2017-08-13 MSS Code Factory 2.9.14072 CFCrm 2.10 packaged cleanly

CFSecurity, CFInternet, and CFCrm are now all packaged cleanly. Those are the foundation packages upon which all MSS Code Factory manufactured projects are built, so today is a big milestone for me.

Next up is working on getting CFDbTest 2.10 to build and package. Not today, though. I'm content with having gotten CFCrm addressed for the day.

2017-08-13 MSS Code Factory 2.9.14069 CFInternet 2.10 is finally packaged cleanly!

I finally got CFInternet 2.10 to package cleanly. CFCrm doesn't build because of its use of Blobs and some APIs I need to add to CFLib, but I'm sure I'll get that resolved quickly enough -- some other time.

2017-08-12 MSS Code Factory 2.9.14067 CFInternet 2.10 compiles, but there are packaging errors

CFInternet 2.0 compiles, but there are still Debian packaging errors, so no binaries will be posted with this release. I am posting a source update, though.

2017-08-12 MSS Code Factory 2.9.14066 A little bit closer to CFInternet building

I finally got CFInternetMajorVersionEditObj.cpp to compile. That one took three days, so rather than diving into the errors produced by CFInternetMajorVersionTableObj.cpp, I'm going to call it "good enough" for today. I'm not posting an update of CFSecurity tonight, either. Posting and reposting it serves no purpose. If you want to see the changes so far, use the factory to refresh the code and build it yourself. :P

2017-08-10 MSS Code Factory 2.9.14064 I'm getting close to a CFInternet build

There are still some vestiges of Java in the EditObj implementation, and I'm having trouble with certain aspects of the constructors, but for the most part I've made tremendous progress today towards getting CFInternet 2.10 built.

However, I promised myself last night that I'd stop coding at a reasonable hour today, regardless of whether I got CFInternet compiles or not. It is 5:00, and therefore quitting time.

The rest of the day is mine, not the computer's.

2017-08-10 Programmer's Notes

My current goal is to get CFInternet and CFCrm 2.10 built for C++14. After that I'll be dealing with CFDbTest, which I expect to uncover a number of defects in the rules, as it is a project designed primarily for testing the data persistence implementations and features of MSS Code Factory manufactured code.

My plan after I get the Obj .debs built for all of the 2.10 projects is to do the same for the SAX Parser in the manufactured XML support using Xerces-C, and then to implement the RAM persistence. The persistence implementations all need to include the XML support so they can service the file import method properly.

Then it is a trivial matter to add on a main so I can test the code I've manufactured. I expect to spend a lot of time debugging before I can import my CFDbTest test data to the RAM database. But I need to do that to debug the main Obj and XML code before I deal with database persistence.

With a RAM persistence model in place, I'll tackle implementing CFCore and the MSS Code Factory engine in C++14. I need that -- I have plans to extend it to turn it into a rather different scripting language than you've ever seen before. The scripting engine will use the same code base as MSS Code Factory itself, but primarily as a means of resolving persisted data attributes. I'll need to add the other accoutrements of a scripting language like variables and scoping, function and procedure specifications, non-persisted structures, binding to general capabilities like looping through the results of a duplicate index query, dereferencing .name variables, and implementing the whole thing as object fragments that can be compiled into a runtime the same way the definitions of a rule base compile to objects derived from the RAM-persisted model of the rule base and business application model.

The goal is to have a scripting engine that I can run on top of my portable data persistence implementations. Then I can submit scripts from the client to perform business functions, and store scripts in the database for running the overnight processing of a business data system on the server. I expect the scripts to look like an extension of the current rule base, so that all I need to do to produce data exports and XML communication messages in scripts is to add file management and message transmission support so that servers can communicate with each other.

As MySql is the default database on an Ubuntu system, I'll code persistence for that first, and then PostgreSQL. Sybase ASE is probably next, because it is easy to uninstall if Ubuntu releases a new version of the desktop (which happens about twice a year.) DB/2 UDB is easy to install and remove as well, but no more popular than Sybase ASE and I happen to like coding for Sybase, so DB/2 plays second fiddle to Sybase in my world.

That leaves Oracle. Damned Oracle is a nightmare to install and leaves your system un-upgradeable. What I might do is dust off the laptop to install and run an Oracle server on it, provided that installing the client doesn't leave the system in an un-upgradeable state in and of itself.

I'll have to document my Oracle install process thoroughly this time, and add a page to the MSS Code Factory website explaining how to install it on Ubuntu. I've done it before; I know it can be done. But it was hard as hell and I didn't even bookmark what I was reading. I'll do better this time.

That brings me to SQL Server. Microsoft is working on a Linux version, which I'm sure will be released well before I'm done coding the other five databases.

This project will take years, not weeks or months. Something to keep me busy during a disability retirement...

2017-08-09 MSS Code Factory 2.9.14062 Use Reference methods in joins

The joins in the Obj and EditObj implementations now use the Reference methods for optional target arguments, and the regular attribute accessors for required arguments.

There have been so many changes today I've lost track, but CFInternet 2.10 still won't build. It is a lot closer this evening, but not there yet. This is work-in-progress code I'm checking in, rather than a completed task. At least CFSecurity 2.10 builds with it.

2017-08-09 MSS Code Factory 2.9.14059 Added Reference methods to Obj layer

The Reference methods have been added to the Obj layer. That leaves one more step to implement, then I can test my solution to the latest CFInternet build problem. In a nutshell, C++ doesn't have automatic variable wrapping like Java does.

2017-08-08 MSS Code Factory 2.9.14057 Updated to use CFLib 2.10.14056

The rules have been updated to expect CFLib 2.10.14056, which allows the code to add the Reference methods to the attribute getters. The Reference methods return a const pointer to the value if the value is not null, or a NULL pointer if the value is null. This will take care of emulating the Java atomic type wrappers.

So far I've implemented the new methods for the base objects. Next I need to move up a layer and implement them for the Obj layer.

Then finally I can modify the implementations of the queries in the Obj and EditObj code such that they use the new methods when passing values to optional arguments of a query. That will take me one step closer to a building CFInternet -- this day's work has all been towards dealing with the next build problem I have for CFInternet.

2017-08-08 Programmer's Notes

I need to add a new method to the Buff, Obj, and EditObj implementations that returns a ConstOptAtom type to wrap the attributes. These new methods will be suffixed "Reference", thus "getIdReference()" might return a "const int64_t*", while the get value method returns the actual value.

These new methods will then be used to invoke queries so that optional arguments are passed by reference instead of by value.

This should take care of giving me the equivalent to Java's value wrappers being automatically created.

2017-08-08 MSS Code Factory 2.9.14054 Refreshed C++14 support for CFLib 2.10.14053

CFLib 2.10.14053 is now required by all manufactured code. I am that much closer to building CFInternet 2.10 for C++14. But I'm not there yet.

2017-08-07 MSS Code Factory 2.9.14049 C++14 builds no longer result in undefined symbols

The C++14 build for CFSecurity no longer results in undefined symbols.

2017-08-06 MSS Code Factory 2.9.14048 C++14 CFSecurity build corrected

I removed factory objects from inheriting projects, such that there is only the DefSchema specification of the factory interface and default implementation, rather than there being subclasses of them in the referencing projects.

However, I made some mistakes updating the rules for the Makefile.am and Top.xml file generation specifications and had to correct that before CFSecurity would build successfully. Yes, I waited for the build to finish this time.

2017-08-06 MSS Code Factory 2.9.14046 C++14 Makefile.am corrected

There was a missing space in a file list that caused the CFSecurity build to fail. Oops.

2017-08-06 MSS Code Factory 2.9.14044 C++14 Rule base produced clean-compiling CFSecurity again

I'd broken the C++14 implementation rather badly. This has it fixed for CFSecurity; I'll be continuing to work on CFInternet until it builds as well.

2017-08-06 MSS Code Factory 2.9.14043 C++14 Rule base updated with goal of achieving a C++14 CFInternet build

I've decided that I like the way you specify destination directories for groups of include files in a Makefile.am specification.

The correct usage is much tidier than my earlier hack, which would probably not have worked on anything but the particular flavour of Ubuntu I was running at the time. The Autotools and Debhelper implementations have been refreshed since I last visited that code, so my hack no longer worked. I had to learn the proper way of doing things, and scoured the internet until I figured it out.

The changes have also been applied to the Makefile.am for CFLib 2.10, and an updated release of that code (2.10.14042) published.

There were a lot of inheritance errors. In particular, I used multiple colons to try to specify multiple inheritance constructs rather than the required comma-separated lists.

There were numerous missing includes for inherited objects for objects that are redefined in the projects that include a reference to a base project.

Stale code that specified per-project namespaces was eliminated.

There were a number of header files that weren't properly specified for installation by the manufactured Makefile.am, which forced me to pause for a rebuild and reinstall of CFSecurity after correcting the defect, as it left the CFInternet code unable to find several CFSecurity header files.

I have yet to achieve a build of CFInternet 2.10, but this is getting close. I thought it was time to release an update of the work in progress.

One layer at a time I will work through the bugs until all the projects build. My next challenge is to get CFDbTest to build. I won't be posting my next update until that goal is achieved.

2017-08-05 MSS Code Factory 2.9.14040 C++14 Debian build now sane for CFSecurity

The Ubuntu/Debian build was not putting the package headers in the right subdirectories. My old way of doing that with Debhelper is no longer valid with the latest updates to the Ubuntu Debhelper implementation. I'll have to update my CFLib scripts as well -- that build is currently broken.

2017-08-04 MSS Code Factory 2.9.14039 C++14 Debian build scripts tested for CFSecurity

CFSecurity builds with warnings about missing copyright information using the the manufactured Debian build scripts. I am trying to specify a custom copyright file, and even though it follows the Debian copyright file format provided by a template of debian files, lintian keeps complaining that there is no copyright assigned to the file.

I specified that the copyright applies to all files in the project.

2017-08-04 MSS Code Factory 2.9.14038 C++14 Debian build scripts added

The new build scripts and build configuration files haven't been tested yet, but they look good for CFInternet (which is the project I've been using for testing the rules, as I didn't want to overwrite CFSecurity's template copy of the configuration files.)

I am now ready to do a manufacturing run to overwrite CFSecurity's hand-created files, and to do a test build with the manufactured build scripts.

2017-08-03 MSS Code Factory 2.9.14035 Bring CFAccounting back into the main project collection

CFAccounting is being moved back into the 2.10 project family.

2017-07-31 MSS Code Factory 2.9.14033 Implementation of narrowed relations corrected

There were bugs in the narrowed relationship implementations for years and years and years and years...

2017-07-30 MSS Code Factory 2.9.14030 Models and rules ported forward from 2.8

The changes to the models and rules in version 2.8 of MSS Code Factory have been ported forward to 2.9. All of the 2.10 Java projects compile again.

2017-07-30 MSS Code Factory 2.9.14029 The code works again

The 2.9 code for MSS Code Factory works again. I sure made a mess with one little change...

The models and rules aren't in sync with 2.8; this is just a snapshot release of a version that runs. That doesn't mean things are ready to download for anything other than on an experimental basis.

2017-07-29 MSS Code Factory 2.9.14027 Close to working again

I've resolve the License location issues, and have a new naming issue cropping up. I am sure it is due to the custom SAX parser in CFBam not properly establishing the parent/child relationships, though.

Do not download this release -- it is only provided for those who like to torture themselves like I do.

AMD Ryzen 5 Computer Parts List and Timings

Parts and timing results for my new system compared to the old laptop.