Academic

Completed my IMT presentation for DH, and in the process added some new features to the presentation codebase originally created for the ColDesp launch:

• A readout at the bottom now shows the current slide # and total.
• Unless display=kiosk is explicitly specified in the URL search, it starts in manual mode (which we use more often).
• CSS styling for XML tags and attributes has now been added to the stylesheet, linking into a Transformer 3 sequence I've written to escape and tag XML code, to make it quick and easy to integrate code into presentations.

Working on this presentation is forcing me to do a number of useful things:

• Look closely at TILE. It seems a long way from ready at the moment, although it apparently hasn't been touched since February. TEI "support" seems grafted on, and there is no actual manipulation of any of the XML in a TEI file; TILE data just seems to be injected into the unchanged TEI file in another namespace.
• Rework my link handling in IMT. I was putting text content inside the link element, but of course it's an empty element, so that won't do; recoded the caption property so it saves and loads from @n.
• Create a complete sample TEI file as it will be created by IMT 2. This was very useful. I have no way of doing much with it, but I can go through each of the key parts as part of my presentation.

Created a short presentation, without a task. It would be complicated to set up a task, and by the time we get to this, most people will probably be deep in their own projects, and either have an immediate use for it, or not have time for a task.

Just a brief intro with a single task, in case we want to present this in a formal way.

Added a new presentation on XSL variables. We may not use it -- SB says he'd prefer to present the topic off the cuff -- but just in case we do, this will be available, and preparing it helps clarify the topic for me.

Next week is the DHSI workshop, so I've been working through the plan and the materials and making minor fixes. According to SB's plan, we seem to be missing about four presentations, so I'll get going on those tomorrow (unless they're somewhere else that I wasn't aware of).

I made my first few commits today, and I thought I'd report my experiences in case they help anyone else who's intending to do this but hasn't tried yet. This is all on Ubuntu Linux.

First I followed these instructions to install the TEI packages for Debian on my machine:

http://wiki.tei-c.org/index.php/TEIDebian

I made a directory and checked out the full source my local machine:

mkdir sf_repo
svn co https://tei.svn.sourceforge.net/svnroot/tei sv_repo

Then I moved to the P5 directory and ran a build using "make":

cd sf_repo/trunk/P5
make

This took a long while the first time, and showed me lots of messages that turned out to be a mixture of the incomprehensible, the ignorable, and the relevant. Relevant messages (for me) are ones that I can imagine a way to fix; or that were caused by one of my changes (this hasn't happened yet).

I soon realized that watching the messages go by in my terminal was not really useful, so I started saving the error output to a separate file incorporating a datetime stamp in its name every time I ran a build. This is how I'm working now:

#Go to the root directory of the SVN tree
cd sf_repo

#Check out the latest changes
svn up

#Go into the P5 directory
cd trunk/P5

#Run a preliminary build
make 2> /path/to/error/file/make_errors_`date +"%Y-%m-%dT%H:%M:%S"`.txt

#Make my own changes...

#then run another build
make 2> /path/to/error/file/make_errors_`date +"%Y-%m-%dT%H:%M:%S"`.txt

#Finally, diff the two latest error files to see if I've fixed 
#any previous errors, or introduced any new ones. For this I 
#use Meld.

#Commit my changes if all is OK
cd Source/Specs #(for instance, assuming that's where I edited a file)
svn commit -m "Message explaining my changes."

#Go to Jenkins and watch it build the changed source, 
#then check for errors again.

Watching Jenkins today answered a number of questions for me about how it works, especially with regard to queueing up builds:

Jenkins seems to be configured to run up to two builds simultaneously. When it is already engaged in doing two builds, it will not start another one until one of the current ones is finished. Then it will initiate a new build which incorporates ALL the changes which have been committed during the time it was engaged in the previous build. What this means is that some revisions are never built independently. For instance, I committed two changes to SVN while a build was in progress (revisions 8816 and 8817); when Jenkins was free, it commenced a build of the documentation that incorporated both those changes, meaning that no independent build of revision 8816 was created. Only revision 8817 was built. (At least, that's my current understanding based on observation.)

What this means in practice is that, if there are many editors making changes and commits, we will only see the results of our commits (in terms of errors and warnings) mixed in with those from other commits which have happened around the same time. That will make it slightly more difficult to tell whether you caused an error or not, and how you might fix it. So I think it's probably even more important to have a local build environment you can use to test your changes before committing them. While errors can easily be undone by means of reverting, there is a danger that in order to do this, you might have to revert past other people's changes that were committed just after your own.

Made two sets of changes to TEI source and committed them today. Watching to see how Jenkins handles the results. The first one went fine, with no errors (as expected from my local tests). Local tests also show no errors from the second batch of changes (relating to nested bibls), but the first Jenkins build has only just started. I took advanted of the second commit being in two different directories to stagger the commits, so that Jenkins will (presumably) start two separate builds; I'm now waiting to see if it does them serially or in parallel. We need to figure this out for our own local copy of Jenkins.

Command-line run from /trunk/P5 to get the errors out to a timed file, for diffing against previous error output:

make 2> /home/mholmes/WorkData/tei/make_errors_`date +"%Y-%m-%dT%H:%M:%S"`.txt

(Just to save me from mistyping and forgetting and having to re-learn.)

Following my own instructions in the previous post, got my working build environment set up on the work computer, and ran a test build. I'm now running another build, saving the output to a file so I can examine the errors coming out of tests.