So Many Plans, so little time…

16 Jun

Started several on and off time projects.  Most are needed for work, but will require personal time to ever see the light of day.

Some things I hope to complete this year are:

  • Chukik (versioning for Rocket u2 + Systembuilder)
  • pygments lexer for Unibasic
  • redis-u2 – improving my naive exec() based redis bindings for Unibasic to use socket communication.  Redis is AWESOME.
  • volunteer at rhodecode, help bring 1.2 to release.
Advertisements

Introducing Chukik, Capture those free running SB+ and U2 objects!

8 Apr

This project is aimed at getting better visibility of development on my U2 database.  The db schema, Report Layouts and Screen Forms are all stored in multi-part binary files.  That makes packaging and versioning a real chore.

The homepage can be found here.  For some reason WP is not letting me insert links.

https://sourceforge.net/projects/chukik/

Comparing and Versioning MV objects

7 Apr

Pondering how to best handle versioning multivalue arrays and System Builder objects.

Have a couple of ideas that center around xslt’s to take XML output from Unidata and normalize it to something mercurial can consume for version control.  That same xslt (or one like it) can target other outputs such as toHTML, toDiff, toJSON, etc.

Brondsma’s DataDiff I think will provide the diff functionality.

The overall goals are to:

  • handle a U2 dictionary item (FD, SB Report, etc) to hg, then revert it back to the dictionary and have a valid SB+ object.
  • handle single or mass compares at cli (or gui)
  • enable hg diff to show meaningful context of changes

Update on Unidata XDOM

7 Apr

We upgraded our AIX and Unidata and the XML libraries seem MUCH more solid.  The abends I was previously experiencing have disappeared.  Good Job IBM and Rocket!

Python Deployment Automation

27 Dec

I like the freedom of working on any of my personal and work machines.  My DVCS manages the code well, however, I still get bogged down in the minutiae of deployment.  Part of the problem is I am still sampling application frameworks and do not want to limit myself to just one.  I want to use the right tool for the right job and not be swayed by fear of deployment and development.

Caktus Consulting has a nice method I think I can adapt for my needs.  If done well, I want to just specify What Product Template, Where From and Where To.

Some opportunities to automate:

  • virtualenv management
  • framework choice (django, flask, pyramid)
  • Source Host (dvcs repo or tarball I reckon)
  • Destination Host (named config entries for my machines)

Update on Unidata 6.1 XDOM issues

27 Dec

Looks like XDOM with ud61 is a lost cause for playing nicely.  Tech support ran my processes on a 7.2.5 instance with no memory leak so looks like I have a reason to upgrade now.

Unable to free memory with Unidata 6.1

10 Dec

Enjoying using Gregor’s U2 XDOM wrapper. One thing I learned dealing with a large DOM tree is XDOMClose() does not free the memory when the program ends.

A monthly run of my current ETL will use quite a bit of memory, and two runs will abend my session.

Seems like a good idea to delete the root node before closing it to ensure we done have a memory leak.

Even though it sounds reasonable, it is not effective.  Not sure exactly how to do this.  Looks like a support call to Rocket is in order.


*****************
CLOSE.DOM.HANDLE:
*****************
* Output the XML
MSG = "Starting DOM Write"; CALL CLOGGER(MSG,LOGGING.NS,"DEBUG","")
xml.foutname = 'ggddt_':RUN_ID:".xml"
xmlStatus = XDOMWrite(domHandle, xml.foutname, XML.TO.FILE)
MSG = "Finished DOM Write"; CALL CLOGGER(MSG,LOGGING.NS,"DEBUG","")


* Explicitly remove the DOM tree from memory, closing doesnt do it.
xmlStatus = XDOMRemove(domHandle, '/GGDDT', '', '', JUNK)
IF xmlStatus XML.SUCCESS THEN GOSUB HANDLE.XML.ERROR
xmlStatus = XDOMClose(domHandle)
RETURN