Coding

There is a lot of information available on how to call Ant from Maven2 scripts, but very little on the reverse operation. As it happens, this is actually quite simple to manage - Maven2 is a Java app, so it can be executed by simply using the Java task from inside your Ant script with the correct classpath, Main class name and arguments. The following snippit will do this for the simple case:



Note that this depends on the property "maven.home" being set correctly, and when called it will require the "maven.target" parameter to be supplied. "maven.home" will likely be set in build.properties or similar, and calling it is as simple as

I was reading fairly recently about somebody (No attribution because I really can't remember who it was or where I read it. Sorry) who has a setup where he can do automatic bisect runs on the linux kernel by building the kernel, copying the built files across to a second machine and causing the second machine to reboot. The build was then considered bad if the second machine hadn't come up within 10 minutes, and the entire process was automatic except for needing to reboot the machine by hand if it didn't come up.

This got me to thinking about ways that this can be improved. I haven't tested this yet, but in theory this would work just as well but be more streamlined.

The first thought was to use a virtual machine - something like VMWare or VirtualBox - instead of a physical machine then the script can also be responsible for killing the machine if it doesn't come up.

It then occured to me that this can be taken a step further by having a virtual machine booting off of a live CD - one that was specially crafted using the newly built kernel. This way, there's no requirement to have the machine be able to boot in order to install the new kernel. The entire process would be something like:

** Build kernel
** Master a new Live CD image featuring the kernel
** Fire up the virtual machine using the newly mastered Live CD
** Test if it worked
** Kill the virtual machine
** Repeat

Testing if it worked is a slightly tricky one - I think the article I read used a serial console to do this, but I'm not sure if that's possible on a virtual machine. What is possible though is if the script was to run up a network server on a well known IP/Port - the script already knows these details and so can build it into the Live CD - and the Live CD run a program that connects to this network server during startup. It could even go so far as to make the only process that is loaded in startup - after all of the required networking stuff is loaded, obviously - be the client that connects to this server. The script can then determine success/failure by if the server gets a connection from the virtual machine within a known period of time - 10 minutes works, but can probably be cut down quite a lot since the virtual machine is doing very little now. I'd like to think with the amount that is being done, a boot up time of 2 minutes is slow...

As I said - I've not even considered how to go about making this a reality, but it's an interesting thought that could streamline bisecting of kernels to see which ones boot with zero user intervention.

Asciidoc is a really useful and sensible way of allowing people to write documentation, in that the plain text source code is nearly as readable as the generated output. The following is a CMake file to allow for conversion of text input files into asciidoc generated output files


PROJECT(Document)
FIND_PACKAGE(Asciidoc)
IF(ASCIIDOC_FOUND)
FILE(GLOB _docfiles *.txt)

FOREACH(_file ${_docfiles})
GET_FILENAME_COMPONENT(_file_we ${_file} NAME_WE)
SET(_in "${_file_we}")
SET(_out "${_file_we}.html")
IF (NOT "${_in}" STREQUAL "CMakeLists")
ADD_CUSTOM_COMMAND(
OUTPUT "${_out}"
COMMAND ${ASCIIDOC_EXECUTABLE} -a toc -o ${_out} ${_file}
DEPENDS ${_file}
COMMENT "Asciidoc ${_in}"
)
ADD_CUSTOM_TARGET(${_in} ALL echo
DEPENDS "${_out}"
)
ENDIF (NOT "${_in}" STREQUAL "CMakeLists")

ENDFOREACH(_file)
ENDIF(ASCIIDOC_FOUND)


And it needs the following FindAsciidoc.cmake file available


# - Find Asciidoc
# this module looks for asciidoc
#
# ASCIIDOC_EXECUTABLE - the full path to asciidoc
# ASCIIDOC_FOUND - If false, don't attempt to use asciidoc.

FIND_PROGRAM(ASCIIDOC_EXECUTABLE
asciidoc
)

MARK_AS_ADVANCED(
ASCIIDOC_EXECUTABLE
)

IF (NOT ASCIIDOC_EXECUTABLE)
SET(ASCIIDOC_FOUND "NO")
ELSE (NOT ASCIIDOC_EXECUTABLE)
SET(ASCIIDOC_FOUND "YES")
ENDIF (NOT ASCIIDOC_EXECUTABLE)


IF (NOT ASCIIDOC_FOUND AND Asciidoc_FIND_REQUIRED)
MESSAGE(FATAL_ERROR "Could not find asciidoc")
ENDIF (NOT ASCIIDOC_FOUND AND Asciidoc_FIND_REQUIRED)


It appears that I have just discovered yet another IE6 hang bug- though I'm probably not the first person to discover it...

I'm not sure of the exact set of circumstances that cause it to happen yet, as I've not been able to reproduce it in a simplified form unfortunatly, but at least part of what is required is as follows:

• An element - div in this case - with a margin-left of some non-zero value


• Immediatly inside this element at least 4 input elements of type hidden, all together


• Immediatly after these 4 input elements, an element that is defined to be float: left

Whether or not a doctype is present does not appear to affect the outcome, so it is not a simple reproduction of the bug mentioned at this blog post.

However, the following do stop the bug from manifesting:

• Making it so that there are less than 4 input elements all together before the float


• Making at least one of the input elements to not be of type hidden


• Putting another element between the 4 inputs and the float


• Making the element not float any more


• Changing the margin-left to padding-left instead.


• Wrapping the 4 input elements in a container element themselves - This is the one I used to solve the problem, the 4 input elements now exist inside a div that is set to display: none, and everything is happy.

Having just set up a new autotools project, and started the project in Git the following is the complete .gitignore list that I've produced to capture all of the artifacts that have been produced. This only covers the artifacts that are produced by a bare project that doesn't acutally produce any output.

All the major browsers have the ability to download an XML document that has an xml-stylesheet processing instruction, understand the xml-stylesheet instruction, download the referenced XSL file and transform the downloaded XML before rendering it for the user. This means that you have the ability to even more clearly seperate the data from the design when producing web pages - have an XML feed that is the pure data, have an XSL file that transforms this XML file into (X)HTML for the browser to render and then have linked CSS files to apply visual styles to the HTML that is being rendered.

Where this falls apart at first attempts is with the output encodings - specifically with IE trying to render the pages. It turns out that the encoding name that I keep using for everything is actually wrong. I always put an encoding of "utf8" on my xml documents, but the legal encoding name is actually "UTF-8". In every XML and XSL capable program that I've used, this has never been a problem which is why I never realised.

Except for IE of course. In IE if you put in an encoding of "utf8" then you get the dreaded "System does not support the specified encoding" error that doesn't actually tell you anything. To make matters even more complicated, IE as an XML or HTML renderer can handle the name "utf8" perfectly well. It is only IE as an XSL processor that has trouble handling it. In other words, if you don't have an xml-stylesheet PI on your XML file, where the XML file is listed as having an encoding of "utf8" then IE will open it perfectly well, and will even process it with it's built in XSL file perfectly well. As soon as you put an xml-stylesheet PI onto this document, still with the encoding of "utf8" then it just all stops working...

In short - to make sure that your XML and XSL files are going to work with IE, use an encoding name of "UTF-8" instead of "utf8"...

For something I'm working on at the moment, I needed a simple way of generating Soundex, Metaphone and Double Metaphone conversions of strings. As I couldn't find anything that did this easily on the web, I wrote myself one. This is found Here

The code for this uses the modules Text::Soundex, Text::Metaphone and Text::DoubleMetaphone

The GNU GLibC library defines a function called fmemopen that allows you to open an in-memory buffer as if it was a FILE * handle. The LibC that Cygwin uses doesn't define this, and so this functionality is not possible.

The below code is an implementation of fmemopen that works under Cygwin. It's far from finished, and likely to be very flakey, but simple tests do prove that it works.

Currently missing features are:
** Seeking
** Writing into the buffer

fmemopen.h

To use it, simply #include the fmemopen.h file in your source file, and then call the fmemopen(const char * data, const size_t size, const char * mode) function to get your FILE * pointer.

The fields are as follows:
** data: The data that you want to use.
** size: The size of the data to use.
** mode: Ignored, but included for footprint compatibility with the GLibC version.

The actual data is memcpy'd out into an internal buffer, starting at data, and going for size bytes.

Not tested any of this yet, but this looks like a very concise and easy-to-understand introduction to embedding Lua in C++ code.

http://www.debian-administration.org/articles/264

Web design is something that people are either very good at or very bad at. I'm one of the people who are very bad at it, and as such use as much help as possible from elsewhere to do the design of any websites I'm working on.

One such place is Open Source Web Design - a repository of free to use web templates that you can just drop into place and use. This I have used a fair bit and the work is generally quite excellent.

Another place that I have just found is GetTemplate - another site with free web templates and also offering custom designs for a fee. I think this site is run by one of the publishers who has work on OSWD, and it's his work that he is offering.

This site is a very useful reference of all the different getElement(s)By... functions available in Javascript:

http://www.getelementsby.com/

Once again, IE proves that it can't do anything in a standard way.

Retrieving the caret position from a text control in Firefox and Opera is a very simple job - you simply use the selectionStart and selectionEnd parameters of the control itself.

Retrieving the caret position from a text control in IE is not quite so simple. There are no parameters that give you this information, so you have to work it out for yourself. As it happens, there are a number of ways of doing this available on the internet. Unfortunatly, none of them work properly.

The "official" method of doing it according to the Microsoft Web Team in the article Yule Not Want to Miss this One (See "O Cursor, Where Art Thou—finding yourself in a text box") is just horrible:

1. Save the input field value in a temporary variable.
2. Create a TextRange object on the document.selection (assuming the input field is focused).
3. Insert a “~” character into that TextRange object (range.text = "~"). Thus, the tilde would be inserted at the caret position (which we actually want to determine).
4. Search for the “~” character in the input field value and remember the index where it was found.
   Restore the original input field value, saved at (1).
5. Return the index determined at (4) and claim it is the caret position.

The better method of doing it uses undocumented features of the Range object, and is described here by Mishoo.

This uses the Range.getBookmark() function which returns a value that can be used to get to the caret position. It worked fine. And in IE7 it stopped working. Microsoft changed the way this function worked (It's undocumented and so they can do that) and broke things that rely on it.

The third method of working out the caret position, which I have not seen mentioned anywhere on the internet and so might very well not work properly, is to use the Range.offsetLeft value. This gives you a value which represents the distance from the start of the text field that the caret is located at. In standard mode, this value is (position * 7) + 1.

This has been tested in IE5, IE5.5, IE6 and IE7 and returns the same values across all of them. It also returns the same value regardless of the zoom of the page and the location of the textbox on the screen.

As such, below is my cross-browser function to get the caret position from a given text field. It is known to work in Firefox, Opera, Netscape and (now) all versions of IE from 5.5 and up.

It seems that IE7 have managed to make things even worse in the cross-browser keyboard handling arena.

From some simple testing, it would appear that either IE7 updates the caret position before the keypress event is triggered, even though the new character isn't yet entered (and might not be entered), or (and this is more likely) the caret positions are now 1-indexed and not 0-indexed like everybody else uses.

For the vast majority of cases out there, this is not going to cause any problems at all, but if you do care about where the character being entered is meant to go in a cross-browser manner then it would appear that you are in trouble. Essentially all it means is that in IE7 your caret positions are always going to be one greater than they are in the other browsers, but it's enough of a difference to cause problems...

Edit: (See above) It appears that the problem is really that Microsoft changed the undocumented feature that I was using to get the caret position. I was using this because there is no documented way to get at the position that is worth considering.

Different browsers handle events in different ways. Unfortunatly, this means that the same function will receive it's data in different ways on different browsers. From the major three:

• Firefox. Event object is passed as parameter to the callback function
• Opera. Event object is passed as a parameter to the callback function. Some members of event object have different names
• Internet Explorer. No parameters passed to callback function. Event object exists as a global variable(!) instead. Some members of event object have different names.

Whilst Internet Explorer does use a global variable to store the event object, this is actually less of a problem since the javascript engine is single-threaded. It shouldn't be possible to have two event handlers for two different events using the same event object. This could change in IE7 or later however, at which time things will likely all stop working in a horrible manner.

This snippit can be called, being passed the event parameter from the event handler, and will return an event object in a standardised way. Note that this is nowhere near finished, and still has a lot of work needed to cover everything. In specific, keyboard handling is very rudimentary (see below) and mouse handling is non-existant.

Keyboard handling in Javascript events gives a whole new meaning to "impossible". It turns out that there is simply no reliable way to do this and still have your code work across the board.

The main problem here turns out to be Opera. Opera, in their ultimate wisdom, have decided that in the keypress event they will give you the Keyboard code for function keys, and Character code for all other keys. The problem is that they give you this code in the same variable in the event object.

The problem comes from the fact that the keyboard code and the character code can, and often do, overlap each other. For example, the character code for the period character is 46. It just so happens that the keyboard code for the delete key is also 46. Having compared the event object that is passed into the keypress event when the period and the delete key are pressed, the event objects are identical. There is not a single way to tell the difference between those two keys in that event!

As it happens, the reason I was trying to do this was to have a text field that only allows certain keys to be pressed. Period wasn't one of the keys, but I did want all the function keys to work (arrows, delete, home, end, etc). Another "feature" of Opera is that these keys can not be cancelled. As such, if I think it might be a period I can try and cancel it, and if it's a period it's cancelled and if it's a delete then it's not.