This week, I submitted more fixes in relation to Jython support in ADAMS. This time, the fix resolved around execution of scripts on the Windows platform. In a nutshell: it didn't work. So far, it had only been used on Linux and Mac. But that's resolved now. Furthermore, I automated the generation of the Jython registry ($HOME/.jython or %USERPROFILE%/.jython), ensuring that the "python.security.respectJavaAccessibility" property is set to "false". Up till now, users had to manually create the registry file, before they could make use of Jython actors.

More on the Jython registry here:

http://www.jython.org/archive/21/docs/registry.html

A new addition is hot off the press today: basic support for reading MS Access (formats 2000 to 2010 supported) tables as spreadsheets. With the next snapshot/release you can then use it in the flow by adding the SpreadSheetFileReader transformer and then choosing the AccessSpreadSheetReader as the actual reader. You only have to feed in the Access database that you want to read from and define the correct table name in the AccessSpreadSheetReader instance. Write access might get added in the future.

The Jackcess library is used for interfacing with Access:

http://jackcess.sourceforge.net/

Due to the issues with Jython, I will probably make a new release in the coming weeks.

Write access is now also available, using the AccessSpreadSheetWriter plugin for the SpreadSheetFileWriter sink.

Unfortunately, the last release has a broken support for Jython inline scripts, with the input getting rejected. This happened due to the shift to a new editor component for source code and a left-over cast to the wrong superclass. The unit tests didn't pick this regression up, as it is a GUI-only problem. Support for Groovy inline scripts was working as expected in the release. Anyway, that's fixed now.

On the bright side, there is now support for a range of barcodes available in the adams-imaging module, thanks to my student Leo Xiong. You can, at the time of writing, generate EAN13 and QRCode barcodes using the "Barcode" draw operation (within the "Draw" transformer). Decoding is possible as well, even with a bigger range of possible barcodes. The barcode support is availabel throught the excellent zxing/core library, which I believe is used by Android as well.

Here is an example:

Using one of the scripting modules (groovy/jython) in conjunction with the pdf module, you can then easily create PDFs that contain QR codes. For instance for printing labels.

[One of my new years resolutions is to inform people a bit more about what's happening in the development of ADAMS. So I will try to post significant enough bits (improvements, additions, bugfixes) in the future.]

Today, I've submitted some minor, but very useful, tweaks to some interactive sources.

EnterManyValues

1. ValueDefinition now has a new "display" property which is the human-readable display string, whereas the "name" property is used in the SpreadSheet that's generated. That makes it easy to convert all values directly to "machine-friendly" variables in one go using the SpreadSheetVariableRowIterator transformer.

2. No longer modal dialog, i.e., the flow can be stopped via the "stop" button now while the dialog is being displayed.

EnterValue

1. No longer modal dialog, i.e., the flow can be stopped via the "stop" button now while the dialog is being displayed.

2. When using buttons for displaying the selection strings, the button with the label that matches the "initial" string gets the initial focus when the dialog gets displayed. Makes it rather easy to select this default option now just by hitting the space bar.

I can't remember exactly when I started using Eclipse as an IDE for developing Java applications, but it's been a while probably dating back to at least version 3.2 (released in 2006). However, in recent years I've become more and more annoyed by its random and sometimes outright weird behavior: sudden shutdowns, restart required for errors to go away (clean all projects didn't do it), ...

Since I started dabbling in Python last year (https://github.com/fracpete/python-weka-wrapper), I was on the lookout for an nice IDE and finally settled on PyCharm (https://www.jetbrains.com/pycharm/).

Being rather happy with it, I decided this year, after some initial preparations in December, to finally jump ship and use IntelliJ IDEA (community edition - https://www.jetbrains.com/idea/).

I just committed changes to subversion related to using the latest version of Weka, namely 3.7.12.

Due to changes in the way test instances get generated, data is sorted and default options in Weka, a number of regression files were affected and have been updated accordingly.

Just a heads up that the build system (https://adams.cms.waikato.ac.nz/jenkins/) has switched to Java 8. Some reference files for the regression tests needed to be updated during that process.

Currently, the code base is still Java 7 and it still compiles to 7. However, this might change in the future without further notice.

Why? Java 7 will reach its end-of-life in April this year.

ADAMS 0.4.7 has been released. More details and download links are available from here.

I've just committed changes to the repository that affect how simple input dialogs and the EnterValue source actor now operate. Instead of using the JOptionPane.showInputDialog(...) this is now handled via the GUIHelper.showInputDialog(...) methods.

Why this?

The JOptionPane-based dialogs block the complete application, whereas the GUIHelper-based ones only block the current dialog/frame.

Furthermore, it is now also possible to have an input dialog with several options that get displayed as buttons (omitting the OK/Cancel buttons altogether) rather than having a dropdown list with the options. This can make repetitive interactive actors like the EnterValue source much faster. Instead of selecting the desired item and then hitting OK, you can simply hit the button associated with the desired option.

Also, these new input dialogs support Esc/Enter for cancelling/accepting the current input rather than forcing the user to click a button.

Since this change affected quite a few code locations, let me know if you come across some (newly introduced) bugs.

Last Friday, I fixed a bug in regards to how float/double are handled in the GenericObjectEditor. The bug was introduced with the locale handling after release 0.4.2. In non-English locales, or more general, ones that use a comma as the decimal point, numbers like 4.25 got interpreted incorrectly as 425 in the GUI. Simply executing existing flows doesn't result in any data corruption. However, bringing up options in the GUI and then saving them again may result in incorrect values being saved. It is therefore recommended to either set the locale to en_US in the preferences dialog or download a current snapshot to avoid this issue.

Sorry about that.

Running the NZ Data Mining Workshop as part of the eResearch 2014 conference hosted here at the university.

More details here.