The project has been “mavenized” and moved to SVN (ok, maybe we should have switched directly to Git, please don’t tell Linus we are still using SVN).

A version 0.3 has been released, a full changelog can be found here. The main changes are:

• a patch to fix the case of multiple datasources has been applied (initialy provided by Juraj Sucik).
• supports version 3 rrd files (jRRD v0.1 only had support for version 1 rrd files)
• x86_64 files (only tested on linux 64bits plateform, if you have access to other 64bits plateform, please contact us)

The project is not really active because in its current state, it fits our needs, so fill free to wake it up and send us your feature requests.

C:\Cygwin\bin\rxvt.exe -g 120×70+75+-1  -sl 1500 -fn courier -bg black -fg grey -sr -e bash –login -i

but all you get is big window with strange spacing between chars:

.
Ok, it’s time to customize some stuff. Open a cygwin shell (or an ugly uncustomized rxvt), go to your home directory, and create/edit your .Xdefaults file to fit this one:

#Rxvt.reverseVideo:      true
Rxvt.scrollBar_right:   false
Rxvt.saveLines:         2048
Rxvt.font:              "Lucida Console-12"

Then edit your shortcut to something similar to this one:

C:\cygwin\bin\rxvt.exe -display :0 -bg black -fg grey -tn rxvt -sr -sl 1500 -g "140x60+1+-1" -e /usr/bin/bash --login -i

If you need to adjust the size of the window, you can change the -g “140×60+1+-1″ values.

You should now get something much more like that:



Enjoy!

All you’ll need is a piwik siteId, the piwik server name and path of your piwik installation. And the Piwik Analytics plugin for Hudson that you can download here (save as…) till there is an official version available (maybe some more tests needed, any feedback will be appreciated!)

Update 2009-11-03: I fixed the mime type for hpi files so no more Save as should be needed.
Update 2009-11-04: some minor changes: french translations and the possibility to add download extensions (see

http://piwik.org/docs/javascript-tracking/

Update 2009-11-06: fixed the package to be compatible with jdk 1.5
Update 2009-11-07: the plugin has been officially released and should be available in you admin plugin list.

La raison est simple, le kernel livré avec la fc11 est un 2.6.29, qui n’était pas encore sorti lorsque le player 2.5.2 est sorti.

Toutes les infos et le patch a appliquer se trouvent par là.

Après application du patch, ça devrait donner:

Starting VMware services:
Virtual machine monitor                                 [  OK  ]
Virtual machine communication interface                 [  OK  ]
Blocking file system                                    [  OK  ]
Virtual ethernet                                        [  OK  ]
Shared Memory Available                                 [  OK  ]

et zou.

vmware-6.5.2-modules-2.6.29-fix.sh
vmware-6.5.2-modules-2.6.29-fix.patch

If you’ve just upgraded your fedora install to version 11 and that you (have to) use VMware player (despite VirtualBox works very well), you will encounter a small problem: additionnal kernel modules needed by the vmware install won’t compile.

Indeed, the kernel bundled with fc11 is a 2.6.29, that wasn’t out when vmware player 2.5.2 was released.

All informations and a patch to apply are provided here.

Let’s apply the patch and enjoy:

Starting VMware services:
 Virtual machine monitor                                 [  OK  ]
 Virtual machine communication interface                 [  OK  ]
 Blocking file system                                    [  OK  ]
 Virtual ethernet                                        [  OK  ]
 Shared Memory Available                                 [  OK  ]

that's all folks!

vmware-6.5.2-modules-2.6.29-fix.sh
vmware-6.5.2-modules-2.6.29-fix.patch

Jusqu’à ce jour. Je viens de découvrir (shame on me?) qu’il est parfois nécessaire de ne pas explicitement forcer la valeur par défaut.

1er cas:

public class MotherClass {

public MotherClass(String… args) {
System.out.println(“MotherClass(): [BERORE CALL TO PREPARE] this:” + this);
prepare(args);
System.out.println(“MotherClass(): [AFTER CALL TO PREPARE] this:” + this);
}

public void prepare(String… args) {

this.member0_1 = args[0];
this.member0_2 = args[1];
System.out.println(“MotherClass.prepare(): this:” + this);
}


public String toString() {
return ”MotherClass <member0_1=” + member0_1 + ”, member0_2=” + member0_2 + ”>”;
}

protected String member0_1;
protected String member0_2 = ”initialized”;

public static void main(String[] args) {
MotherClass mc = new MotherClass(new String[] { ”first”, ”second” });
System.out.println(“main(): mc:” + mc);
}
}

Si on lance le main, ça donne:

MotherClass(): [BERORE CALL TO PREPARE] this:MotherClass <member0_1=null, member0_2=initialized>
MotherClass.prepare(): this:MotherClass <member0_1=first, member0_2=second>
MotherClass(): [AFTER CALL TO PREPARE] this:MotherClass <member0_1=first, member0_2=second>
main(): mc:MotherClass <member0_1=first, member0_2=second>

Dans ce cas, rien de particulier, la classe se comporte comme on peut s’y attendre, que la variable d’instance ait été initialisée (member0_2) ou pas (member0_1).

Etendons maintenant cette classe:

public class ClassThatExtends extends MotherClass {

public ClassThatExtends(String… args) {
super(args);
System.out.println(“ClassThatExtends(): [AFTER super()] this:” + this);
}

public void prepare(String… args) {
if (args.length == 4) {
this.member0_1 = args[0];
this.member0_2 = args[1];
this.member1_1 = args[2];
this.member1_2 = args[3];
}
System.out.println(“ClassThatExtends.prepare(): this:” + this);
}

public String toString() {
return ”ClassThatExtends <member0_1=” + member0_1 + ”, member0_2=” + member0_2
+ ”, member1_1=” + member1_1 + ”, member1_2=” + member1_2 + ”>”;
}

private String member1_1;
private String member1_2 = ”initialized”;

public static void main(String[] args) {
ClassThatExtends cte = new ClassThatExtends(new String[] { ”first”, ”second”, ”third”,
“fourth” });
System.out.println(“main(): cte:” + cte);
}
}

Si on lance le main:

MotherClass(): [BERORE CALL TO PREPARE] this:ClassThatExtends <member0_1=null, member0_2=initialized, member1_1=null, member1_2=null>

ClassThatExtends.prepare(): this:ClassThatExtends <member0_1=first, member0_2=second, member1_1=third, member1_2=fourth>

MotherClass(): [AFTER CALL TO PREPARE] this:ClassThatExtends <member0_1=first, member0_2=second,member1_1=third, member1_2=fourth>

ClassThatExtends(): [AFTER super()] this:ClassThatExtends <member0_1=first, member0_2=second,member1_1=third, member1_2=initialized>

main(): cte:ClassThatExtends <member0_1=first, member0_2=second, member1_1=third, member1_2=initialized>

WTF? member1_1 qui n’a pas été explicitement initialisée dans la classe fille a gardé la valeur fixée lors de l’appel du constructeur, par contre, member1_2 qui a été explicitement initialisée a été écrasée après avoir été valorisée dans le constructeur!

Les variables d’instance d’une classe “fille” sont donc initialisées APRES la chaîne des appels des constructeurs.

Dans le cas où la variable n’est pas explicitement initialisée lors de sa déclaration et que la variable est valorisée dans le constructeur, la valeur de la variable d’instance sera conservée. Dans le cas où la variable d’instance est explicitement initialisée lors de sa déclaration et qu’elle est valorisée dans le constructeur, la valeur est écrasée par la valeur d’initialisation spécifiée!

Fichtre! En voila donc un comportement pas forcément trivial… Si quelqu’un arrive à me trouver le bout de doc chez Java (ou ailleurs) que j’ai du louper, je suis preneur.

• http://internna.blogspot.com/2009/04/web-framework-comparison-prototyping.html
• http://java.dzone.com/tips/java-web-frameworks-survey
• http://docs.google.com/Doc?id=ajgdx7ccvkxg_50ccp25f

Ce cookbook contient pas mal d’exemple d’utilisation des outils Apache Commons , Apache * & autres, pour se faciliter la vie et ne pas réinventer le fil à couper le beurre (ou le GregorianCalendar)