MSS Code Factory 2.9 (production) Release History

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."


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 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 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 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 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, 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.