Spell check under Openoffice
on
Tuesday, October 06, 2009
Labels:
Linux
,
openoffice
1
comments
Are you unable to do auto spell check in the OpenOffice applications? To make it work, you need to go to the application (oowriter, oocalc etc) menu, go to Tools -> Options -> Language Settings -> Languages and set the "Default language for the documents" to something standard. In my case "English (USA)" just worked fine.
Reliance Netconnect on Ubuntu
on
Friday, October 02, 2009
Labels:
netconnect
,
reliance
,
ubuntu
2
comments
I am absolutely delighted as I write this post. I am using Reliance Netconnect on my Ubunut 9.04.
And if you are under impression that it was achieved after hours of googling, trial and error and after running hundreds of commands, then you are wrong.
To get it working,
And if you are under impression that it was achieved after hours of googling, trial and error and after running hundreds of commands, then you are wrong.
To get it working,
- Plug in the dongle.
- Wait till the network manager applet menu shows "Auto Mobile Broadband (CDMA) connection"
- Best way to make it work is to select the "Auto Mobile Broadband (CDMA) connection" and let it figure out the settings
- After step 4, it tries to establish connection but obviously fails since the user and password are not provided
- Now, right click on the network manager applet and select edit connections.
- Go to "Mobile Broadband" tab
- Now there is already a configuration created named "Auto Mobile Broadband (CDMA) connection"
- Edit that configuration and add your user name and password.
- Now connect like in step 8 by clicking on Network manager applet and selecting the "Auto Mobile Broadband (CDMA) connection"
- Enjoy high speed mobile broadband on Ubuntu!
Annoying system beep under Xubuntu 8.10
on
Tuesday, April 14, 2009
Labels:
Linux
,
xubuntu
0
comments
If you face a problem of getting an annoying system beep at startup / shutdow and any other actions under xubuntu 8.10, the only solution is to blacklist the pcspkr module.
edit the /etc/modprobe.d/blacklist file as root (sudo) and add line,
blacklist pcspkr
Although the changes will apply only after you reboot the machine, you can do
sudo modprobe -r pcspkr
This will remove the pcspkr module and disable the annoying sound
edit the /etc/modprobe.d/blacklist file as root (sudo) and add line,
blacklist pcspkr
Although the changes will apply only after you reboot the machine, you can do
sudo modprobe -r pcspkr
This will remove the pcspkr module and disable the annoying sound
Setting default alarm for events in Lightning (Thunderbird Calendar)
on
Sunday, April 12, 2009
Labels:
Lightning
,
thunderbird
0
comments
With new Lightning version 0.9, I had started facing a problem where if an event was created or sent to me by someone, which did not have default alarm set, there wont be any alarm going off before the event.
It was probably my sheer laziness that I never really looked for an option for this, If you are facing a same problem here is how to fix it,
go to Edit -> Preferences -> Lightning -> Alarms and set the "Default alarm setting for events" to "On"
It was probably my sheer laziness that I never really looked for an option for this, If you are facing a same problem here is how to fix it,
go to Edit -> Preferences -> Lightning -> Alarms and set the "Default alarm setting for events" to "On"
Problems with Thunderbird calendar after Thunderbird upgrade
Labels:
Linux
,
thunderbird
,
ubuntu
0
comments
If you are not able to see the calendar data after upgrading your Thunderbird, specially after upgrading your linux version, the problem can be solved by installing libstdc++5.
I recently upgraded to Xubuntu 8.10 from OpenSUSE 10.3 (late but worth it) and after importing my mail data, I could not see the calendar. The Thunderbird version I used before was 2.0.0.6 and the new version was 2.0.0.17. I tried installing the lower version (in /opt keeping the prebuild version) and it complained to start. It complained about missing libstdc++5.so after I installed that (sudo apt-get install libstdc++5) all worked fine.
After a bit of googling that the problem with latest version is that it is dependant on libstdc++6 whereas the calendar plugin is dependant on libstdc++5 (I am using Lightning version 0.9 which presumably is the latest)
I recently upgraded to Xubuntu 8.10 from OpenSUSE 10.3 (late but worth it) and after importing my mail data, I could not see the calendar. The Thunderbird version I used before was 2.0.0.6 and the new version was 2.0.0.17. I tried installing the lower version (in /opt keeping the prebuild version) and it complained to start. It complained about missing libstdc++5.so after I installed that (sudo apt-get install libstdc++5) all worked fine.
After a bit of googling that the problem with latest version is that it is dependant on libstdc++6 whereas the calendar plugin is dependant on libstdc++5 (I am using Lightning version 0.9 which presumably is the latest)
Time measurement accuracy in Java
on
Friday, February 06, 2009
Labels:
Java
,
performance
0
comments
An interesting article about time measurement under Java
http://www.simongbrown.com/blog/2007/08/20/millisecond_accuracy_in_java.html
Beware if you are doing any performance measurements on Windows.
http://www.simongbrown.com/blog/2007/08/20/millisecond_accuracy_in_java.html
Beware if you are doing any performance measurements on Windows.
java.library.path and LD_LIBRARY_PATH
on
Friday, January 09, 2009
As everyone might know, you have to set the java.library.path system property for making sure that you can load some JNI libraries in your java application. But often it wont be enough for you to specify java.library.path. The libraries which are referencing other shared libraries, would depend on standard way to resolve the libraries. Which means that if you have a foo.so which you are trying to load in your Java application, and foo.so references or is dynamically linked to bar.so, foo.so will look for the bar.so using the LD_LIBRARY_PATH.
java.library.path only works to resolve the immidiate native library that you are loading in your code. Loading of the other dependent libraries is left to the first library. The JNI library that you load will rely on the OS dependent way to resolve its references.
The catch is that, you will have to provide both java.library.path and LD_LIBRARY_PATH in such case for the libraries to load successfully. So its reliable to depend on the OS dependent way (LD_LIBRARY_PATH) of loading library files than java.library.path system property.
java.library.path only works to resolve the immidiate native library that you are loading in your code. Loading of the other dependent libraries is left to the first library. The JNI library that you load will rely on the OS dependent way to resolve its references.
The catch is that, you will have to provide both java.library.path and LD_LIBRARY_PATH in such case for the libraries to load successfully. So its reliable to depend on the OS dependent way (LD_LIBRARY_PATH) of loading library files than java.library.path system property.
How to get the byte array Class instance?
Have you ever wondered how you can get handle to the Class instance for bye array (byte [])? Its easier to get handle to instances of other primitives like Integer by just doing Integer.class. I don't know if there is any better and standardized way to do it, but I just did (new byte [0]).class.
Any one knows a better way?
Any one knows a better way?
Ant / Junit and Class Loaders
on
Friday, November 21, 2008
Labels:
ant
,
classloader
,
Java
0
comments
Have you ever come across situations where you need to load external resources in your Junit tests? I generally prefer loading external resource files from the classpath. So I add the resources on the classpath and in the test case I look up the resource using the ClassLoader.getResource(). If you are running the Junit tests using ant, you can run into all sorts of problems if you are trying to load resources from the classpath.
Ant runs each Junit test in its own class loader. This makes sure that any libraries on the ant's classpath wont interfere with the test's environment.
If you are using a class loader to load the resources, always use the immediate class loader to load the resource. Generally you can get the handle to class loader through ClassLoader.getSystemClassLoader(). But if you try to load a resource using this class loader in the test case, JVM will try to load the resource using the system class loader. System class loader in this case is class loader for Ant. But unfortunately since Ant created a special class loader for the test, the system class loader does not contain the same classpath that you have configured in ant's build.xml for running tests (Ideally you would have added the directories containing the resources that you need to dynamically look up in test cases here). You would end up with a resource not being found.
To overcome this, always use immediate class loader, how to dot it?
use MyTest.class.getClassLoader()
This ensures that we are getting the class loader that loaded test class. Which infact is the immediate class loader.
This also applies for any framework / API you write. Using immediate class loader makes sure that your framework would be testable in the multi classloader environements.
Ant runs each Junit test in its own class loader. This makes sure that any libraries on the ant's classpath wont interfere with the test's environment.
If you are using a class loader to load the resources, always use the immediate class loader to load the resource. Generally you can get the handle to class loader through ClassLoader.getSystemClassLoader(). But if you try to load a resource using this class loader in the test case, JVM will try to load the resource using the system class loader. System class loader in this case is class loader for Ant. But unfortunately since Ant created a special class loader for the test, the system class loader does not contain the same classpath that you have configured in ant's build.xml for running tests (Ideally you would have added the directories containing the resources that you need to dynamically look up in test cases here). You would end up with a resource not being found.
To overcome this, always use immediate class loader, how to dot it?
use MyTest.class.getClassLoader()
This ensures that we are getting the class loader that loaded test class. Which infact is the immediate class loader.
This also applies for any framework / API you write. Using immediate class loader makes sure that your framework would be testable in the multi classloader environements.
Continuous Integration Servers
Labels:
continnuem
,
continuous integration
,
hudson
,
teamcity
0
comments
