Whenever trying to start Apache Tomcat 6.0.18 after installing it on a Windows XP Pro (SP3) machine, I would run into that error:Failed creating java C:\Program Files\Java\jre6\bin\client\jvm.dll.
Actually, that’s because apparently you need:
1) Either to have the SDK and not JDK of Java installed
2) Or you need to have the msvcr71.dll. dll in your windows system directory.
I downloaded the DLL from dll-files and it solved the problem.
More info on: http://netbeans-forum.de/viewtopic.php?t=640
As a researcher in computer science (who thinks a CS researcher day without any line of code is a wasted day
) I end up spending quite a bit of time sitting in front of my computer.
So far so good, till today I was young and innocent and could spend 14 hours in a raw debugging an obscure prototype in C. HOWEVER, since a while now I end up having such bad back pain that I decided to act!
What’s my point? Well I was trying to find a tool that would force me to take (short) breaks on a regular basis (let’s say every 60 minutes).
I actually found a tool that does much better, it’s a timer but also a personal trainer: StrechClock!

Every 60 minutes (you can customize that) it pops up a browser window which contains a youtube video of a one to two minutes stretching exercise demonstrated by a guy in suite (that guy is just hilarious at first!).
That great tool comes as a Vista sidebar Gadget (which I’m using) and as a igoogle gadget. It’s free but there is a cool business model behind it, the site that pops up also offers some related adds and a shopping corner, nothing intrusive and rather contextual.
Yes, it’s cool but moreover it also seems to… work! I actually started using it a week ago and I already fell the difference (nope, I don’t have any shares in that company, at least not at the time of writing).
From a technical point of view I also quite like the app since it is a nice example of a web/desktop “mashup”. The tool installed on your desktop is directly connected to a website which in turns uses youtube to display contextual content (videos). Isn’t that a nice example of the cloud?
Last note: you might end up looking really foolish doing these exercise in front of your colleagues. BUT three replies to that: 1) who will look foolish in 10 years time when they can’t bend anymore? Um? 2) let’s all use it! 3) who cares, looking foolish is cool!
Get it now: http://www.stretchclock.com/download/default.htm
November 14th, 2008 in
Lifestyle |
No Comments
While syncing with SVN in Netbeans on Linux is now trivial (a least since Netbeans 5) it is still kind of a hassle on Windows. Not so much because of Netbeans but rather because you need to find a distribution that contains the svn.exe for Windows.
Looking for a lightweight distrib of the SVN CLIENT (don’t need the server) I found that one: http://www.sliksvn.com/en/download which works pretty fine, is not too big, and does not need you to register to download it!
A few days ago I started experimenting with the Google Web Toolkit module for the Netbeans IDE a rather nice module that lets you develop GWT code directly in your (at least mine!) very favorite IDE. The biggest benefit is free code completion and tagets for building and debugging your application.
A few remarks thought, when trying to integrate the awesome OFCGWT chart library in my application I had to face two problems.
First of all the GWT4NB tutorial on Netbeans.org says you should use the 1.4 java compiler because the GWT does not support Java EE 1.5. Well I’m pretty sure the GWT does not offer support for EJBs and the like (because it has nothing to do with the backend, it’s a UI toolkit!) but it does support Java SE 6 constructs. Thus, if you do select Java EE 1.4 when first creating your project be sure to then change the source/binary version to 1.6 in the project properties.
As an example I could not compile the OFCGWT example without it.
The next thing to be aware of is that the GWT4NB module does not fully comply with the URL assigned to your application by the GWT, when a typical application URL would look like (in GWT):
http://localhost:8080/UWTest/org.test.Main
Netbeans with the GWT4NB plugin exposes it as:
http://localhost:8080/UWTest/
That basically means the entry point .html file is not located in org.test.Main in the GWT4NB version but rather directly at the root context of your app.
A consequence of this is that GWT modules assuming that the compiled javascript will be loaded by a page at org.test.Main will look for files in the wrong place. Namely, in the case of OFCGWT, the .js references .swf files which it expects to be located in the same folder as where it has been loaded from.
Anyway, I found two workarounds for that matter:
1:
We need to override the post-compile target in our build.xml which is guaranteed
never to be re-generated by the IDE:
<target name="-post-compile">
<property name="gwt.compiler.output.style" value="OBFUSCATED"/>
<property name="gwt.compiler.logLevel" value="WARN"/>
<java classpath="${javac.classpath}:${src.dir}"
failonerror="true"
classname="com.google.gwt.dev.GWTCompiler" fork="true"
maxmemory="512m">
<arg value="-out"/>
<arg path="${build.web.dir}/"/>
<arg value="-style"/>
<arg value="${gwt.compiler.output.style}"/>
<arg value="-logLevel"/>
<arg value="${gwt.compiler.logLevel}"/>
<arg value="${gwt.module}"/>
</java>
<property name="gwt.output.dir" value="${gwt.module}"/>
<move todir="${build.web.dir}/${gwt.output.dir}">
<fileset dir="${build.web.dir}/${gwt.module}"/>
<fileset dir="${build.web.dir}">
<include name="**/*.html"/>
<include name="**/*.css"/>
</fileset>
</move>
</target>
This will actually move all the .css and .html files of your web folder to the correct output dir. You then need to be sure that the correct .js file is loaded in your welcomeGWT.html file. That is: you need to remove the org.test.Main/ part.
When deploying Apache might not really be happy anymore since there is no html file at the root of your application anymore however, you just need to call it explicitely like:
http://localhost:8080/UWTest/org.test.Main/welcomeGWT.html and that
should do the trick! BUT –>
2:
BUT, that said, there is a much simpler way of getting rid of that problem: In gwt.properties change the line gwt.output.dir to gwt.output.dir=/
This will deploy the GWT files (all of them, including the .html and the ofcgwt .swf files) at the root http://localhost:8080/UWTest/ which then means that the .js, .swf and .html files are all located in the same folder and thus all on the same path.
This will actually move all the .css and .html files of your web folder to the correct output dir. You then need to be sure that the correct .js file is loaded in your welcomeGWT.html file. That is: you need to remove the org.test.Main/ part.
Wanting to turn the Ploggs, into more RESTful devices, I needed to add a web server (HTTP) to the C++ code managing the Ploggs.
After comparing and trying a number of lightweight web servers (Apache was not an option for this kind of small app) I picked SHTTPD, mainly because:
- It was one of the few I managed to embed in my C++ code (I’m not a C expert…)
- It offered the possibility of registering call back methods when a particular URL is called, which makes it a quite good candidate for a REST interface.
Here is how I did proceed to integrate it to my Microsoft Visual C++ project:
- Compile the project (the core, not the example), this should create a
shttpd.lib file. (This post might in case you do not succeed this step ).
- Copy the shttpd.lib, shttpd.h to your src folder (the one of your Visual Studio project).
- Download shttpd.pem and copy it to your src folder as well.
- Add the
shttpd.h file to your project.
- Add the following lib references to your project:
shttpd.lib ws2_32.lib, see to get details on how to add it.
- Add the code to start and setup the server. Snippets can be found in the example folder of the SHTTPD distrib. That in my case:
// TestSHTTPD.cpp : Defines the entry point for the console application.
#include
#include
#include
#include
#include
#include “stdafx.h”
#include “shttpd.h”
#define ALIAS_URI “/my_c”
#define ALIAS_DIR “c:\\”
static void show_index(struct shttpd_arg *arg) {
shttpd_printf(arg, “%s”,
“HTTP/1.1 200 OK\r\nContent-Type: text/html\r\n\r\n”
“Welcome to embedded example of SHTTPD”);
arg->flags |= SHTTPD_END_OF_OUTPUT;
}
int _tmain(int argc, char* argv[])
{
/*
* Initialize SHTTPD context.
* Attach folder c:\ to the URL /my_c (for windows), and
* /etc/ to URL /my_etc (for UNIX). These are Apache-like aliases.
* Set WWW root to current directory.
* Start listening on ports 8080 and 8081
*/
int data = 1234567;
struct shttpd_ctx *ctx;
ctx = shttpd_init(argc, argv);
shttpd_set_option(ctx, “ssl_cert”, “shttpd.pem”);
shttpd_set_option(ctx, “aliases”, ALIAS_URI “=” ALIAS_DIR);
shttpd_set_option(ctx, “ports”, “8080,8081s”);
/* Register an index page under two URIs */
shttpd_register_uri(ctx, “/”, &show_index, (void *) &data);
shttpd_register_uri(ctx, “/abc.html”, &show_index, (void *) &data);
/* Serve connections infinitely until someone kills us */
for (;;)
shttpd_poll(ctx, 1000);
/* Probably unreached, because we will be killed by a signal */
shttpd_fini(ctx);
return 0;
}
You should now be able to use the web server within your application.
Running a makefile in command-line on Windows can be painful if you try to set all the environment variables (path, bin folder for the nmake utility, and so forth) manually, luckily enough, Visual Studio (Express edition as well) comes bundled with a batch file that does it for you: vcvars32.bat.
The tool is located in the bin folder of your Visual Studio install.
Source: http://www.codeguru.com/forum/archive/index.php/t-419379.html
Coming from the Java world I would describe dlls as sort of jar files. A dll represents the component part of an application, that is: not the end-user part but rather the re-usable part of a Windows app. The so-called API of a dll is the .h file. That means the .h file contains all the methods, or functions that one can call on the dll.
To use the dll of Visual Studio (Express 2008) project A in project B we do what microsoft calls an implicit linking (http://msdn.microsoft.com/en-us/library/d14wsce5(VS.80).aspx). In more concrete terms here are the steps to follow:
1) Generate the dll of project A. When you do this, the linker (after-compiler thingy) creates both a dll and a lib file.
2) Copy the dll and the lib file to project B, namely to a place accessible by the compiler and the linker, a place that’s on the classpath to use the Java terminology.
3) Right-click on the project B in Visual Studio and select Configuration Properties -> Linker -> Input -> Additional Dependencies
4) There you can select the .lib counterpart of the dll (e.g. swill.lib in my case).

Add additional dependencies
5) Add the header file (.h) of the dll to your project.
That’s it you should now be able to use the dll of A from project B, at least it worked fine for me.
Btw, being mainly a Java developer, I’m rather new to C++ so if that’s a silly way of doing it please do comment the post.
How can one do anything without having line number listed next to his/her code? Um?
To display them in Visual Studio .Net 2008 Express goto:
Tools->Options->Text Editor->All languages and select show line numbers.
Took me half an our to find that out, good old Netbeans fellow, where it takes just a right click on the text zone to switch the line numbers on/off…
Select your code and do CTRL-K, CTRL-F. That’s it!

According to http://www.plogginternational.com/ the Plogg “is a combined smart meter plug (kWh) and data logger, especially suited for metering, monitoring and control at the point of use – the appliance level.”
I would add not any kind of smart meter. Indeed, each Plogg is a sensor node, namely a small embedded computer that communicates with it peers (and possibly a number of computers/mobiles) using wireless connectivity.
Since I started working on a project that aims at making people aware of the energy consumption of appliances in a plain old office of the Cudrefin02 foundation I thought testing the Ploggs would be a good thing.
I’ll report on my Ploggs experiences on a regular basis on this blogg, um sorry I mean blog.