Snow Leopard's "Finder" show sizes of all small network files as 1MB

Googled for this phenomenon, and it looks quite well-discussed already.

listening to Jorge Degas's and Andreas Weiser's Heimat

listening to Franz Schubert's D 911

... "Winterreise. Ein Cyclus von Liedern von Wilhelm Müller. ..."

OpenOffice 3.2 RC1 arrives

... and it brings PowerPoint slide shows with music ...

editing files with VI and enforcing certain editor settings

You do know, that you can request VI (or VIM)  to make using the tab key equivalent to going e.g. 4 positions to the right (":set tabstop=4"). But what if your colleague opens that file and has a global setting like ":set tabstop=8"?
As long as you don't "globally" agree on this, it will at least help to add a setting with a "file-wide" scope. VI's feature supporting such options is called modeline. There are 2 related settings, that make the use of that feature possible resp. impossible: "[no]modeline", and "modelines=n". For further reading do a ":help modeline" in VIM! (I guess, there are not that many original UCB VI-s around nowadays any more) That shows you samples and the exact syntax for how to add modelines.
I saw Jürgen Gulbins using this feature like 25 years ago, found it useful then, but never applied it myself in the meantime. But now in my current project with mixed VIM and Eclipse usage it seems to make very good sense, but I wasn't able to recall the details. The article, that my Google enquiry pointed me to, was posted in December 2005 on the linux-il list: "vim inline :set". Thanks to Meir Kriheli for answering the question there!

bash version 4 and associative arrays

The new builtin array variable BASH_ALIASES is a nice example for an associative array.
If you do an ''echo ${BASH_ALIASES[@]}" you see all the values, if you do a "set | fgrep BASH_ALIASES" you see, to what the indexes map.

Update:

In December, when I got aware of the new feature, I thought, there is no way to get the list of indexes.
But there is:  ${!name[@]} and ${!name[*]} return the list of array keys. This gets explained in the section Parameter Expansion. I am sorry, if my former statements caused confusion.

my 1st steps in Java: extending a JasperReport sample program using Apache Commons CLI

iReports and JasperReports (and also JasperETL and much more) are open source software, that you can find on JasperForge.org.

I intended to extend jasperreports-3.6.2/demo/samples/text/TextApp.java, so that it would take "-Dname=value" style options. There was a need to make TextApp.java a little more flexible, and that was quite easily to achieve making use of getProperty calls.

A friend had given me the hint recently to have a look at "System.getProperty()", but it turned out to only provide the caller with properties like "os.name", according to http://java.sun.com/docs/books/tutorial/essential/environment/sysprop.html. So that wasn't quite the route to follow.


I started my day googling for "getopt java", found that nice package "Apache Commons CLI", made use of it within that JasperForge utility, and started scripting a batch run around that utility's targets named "fill..." resp. "text..." in bash, resp. their new sisters, that I derived from them today. Next step is to rewrite that shell script as Windows batch script file resp. as python script to be used in a Windows environment. This work is almost "production ready", but I am facing quite some necessary paperwork, so that the software developed can get made serious use of.

Looks like the Jasper guys had not expected their software to be used like that. The ".jrxml" gets designed using iReport on a Windows box or whatever; after that it is being made use of on any kind of server executing Java classes with access to a database. (I wonder, whether that approach would also work with JasperETL.)

I am quite satisfied with my 1st steps in Java in that JasperReport environment.

I really had no idea and also no perspective of getting thrown into Java development during a commercial project, and even in the context of JasperReport. I do like this.

Update / 2010-03-05:
The atomar production steps described within TextApp.java's build.xml are rather nice and instructive, but they make use of those routines within TextApp.java, where target file names (incl. directory path) get strictly derived from source file names. I added resp. derived productions steps, that make use of thoses methods of the API, that allow you to name the destiny's name explictily. And I also added chains of productions steps into the java source file, so that the calling shell resp. "whatever" script wouldn't have to deal with calling the chained steps one by one itself. So far there are chains starting at .jrxml and at .jasper, and chains that end at .txt and also at .pdf. The idea is to place intermediate files on local disks within temp. directories instead of close to the source resp. final target file (maybe) somewhere on a network file system.