Older blog entries for derupe (starting at number 31)

1 Jul 2005 (updated 1 Jul 2005 at 19:26 UTC) »

KONKNNI ULËY KONKNNI XIKËY - is the program currently being conducted by the Maharashtra Konkani Association. Translated it means "Speak Konkani, Teach Konkani".

Konkani people are dispersed throughout the world. In the past generations they have migrated and occupied most of the coastal belt of western India - from Ratnagiri to Kerala; some moved as far away as Kenya. In recent generations, they've moved even further - from Delhi to Dublin and from Australia to California.

Its very difficult for a scriptless language to survive. There has been a lot of discussion/controversy over the script used for Konkani. The reson for this is the use of various different scripts for the language - based on the regions where its spoken. Its written in Roman and Nagari scripts in Goa, Kannada script in Karnataka, Malayalam script in Kerala.

Most of the languages in India has about five to seven basic vowels excluding long vowels and diphthongs. But Konkani language has 16 basic vowels excluding equal number of long vowels and lots of diphthongs. Different types of nasal vowels are the speciality and greatness of Konkani language. Hence it is very diffecult to represent Konkani language as it is pronounced using any existing scripts in India.

The above program is trying to promote the use of Roman script - with a few modifications - for the Konkani language. Thomas Stephen Konkani Kendr in Goa has formulated a new Orthography for writing Konkani in Roman script by modifying the existing Roman script orthography used by Goan Catholics. This script is so simple that Konkani can be written by representing exact sounds using the normal computer keyboard keys. This script is the result of their research in of number of years.

"Kannada script can not be accepted as a universal script for Konkani as it is not popular outside Karnataka. Devnagiri script has the potential to unite all Konkani people at least at the national level. But it is sad that our people have not accepted it for Konkani even after trying for so many years. Now for the survival of Konkani the only option we have is Roman script that could be also used at the International level. People should come forward to make extensive use of this script for Konkani so that the language may be promoted to our next generation." said Rev. Dr. Pratap Naik S.J., director of Thomas Stephen Konkani Kendr Goa.

Comments

Ended the year with a new release of Kaprekar - version 3.0.

There are two main changes in this release - a) Parameterized the classes based on Java 5 Generics and b) Added a pause and resume option.

The pause and resume option holds only for the current run of Kaprekar. I plan to allow a "save state" feature in a future version where the user can save the current state of the Kaprekar run in a file and exit the application. Later, the user may "load the state" and resume the Kaprekar run.

For more info on the Kaprekar Series Generater, check its web site at http://kaprekar.sourceforge.net

Eclipse Bug - Encapsulate Field

Found this bug in Eclipse today while using the Encapsulate field functionality.

Eclipse Version: Version: 3.1.0 Build id: 200412162000

Create this simple class in eclipse -

public class TestEncapsulate {

String a, b; }

1) Select the Field a.
2) Right-click and select Refactor -> Encapsulate Field.
3) Click Ok.
4) The following code is generated -

public class TestEncapsulate {

String b; private int a;

/** * @param a The a to set. */ void setA(String a) { this.a = a; }

/** * @return Returns the a. */ String getA() { return a; } }

Problems
a) The field was changed to a private field even though it was package-private earlier.
This is ok by me, since I typically keep the fields as private.

b) The data type was changed from String to int!!!
This is crazy!

The encapsulate field works fine when there is only one package-private field delared in one line (String a;)
It breaks in the above code for both fields 'a' & 'b'.

I have reported this Encapsulate field bug.

Java 5.0 Crash

I was using the Eclipse Profiler Plugin to launch my application when the 5.0 JVM crashed.

Here's the information -

java version "1.5.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08)
Java HotSpot(TM) Client VM (build 1.5.0_01-b08, mixed mode, sharing)

Eclipse Version: 3.1.0 Build id: 200412162000

Plugin: Eclipse Profiler http://eclipsecolorer.sourceforge.net/index_profiler.html Plugin Version: 0.5.33

And here's the crash message - # # An unexpected error has been detected by HotSpot Virtual Machine: # # Internal Error (455843455054494F4E530E43505000FF), pid=2116, tid=2268 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_01-b08 mixed mode) # An error report file with more information is saved as hs_err_pid2116.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp #

It created the log file in the project workspace folder. It contained Thread, Stack, Native frames, Heap, Dynamic Libraries, VM, Environment and System information.

Java Code: Boolean Fun

Over time I've encountered Java code that I feel could have been written better. I'll list out a few example that I encountered recently.

If you do code review you'll want to check PMD, JLint, FindBugs and some such tools [I've mentioned these before while talking of Eclipse Plugins.]

Boolean Fun

Cosider this code

if(str.length() > len) {
      return true;
} else {
      return false;
}
The Boolean Expression need not be kept in an if-else block, the output of the boolean expression could have easily been returned as

return (str.length() > len);

A more advanced form of this problem was using a ternary operator -

return (str.length() > len ? true : false);

Yes, the ternary operator is absolutely unnecessary here.

This one was really funny!

if(!(x == y))

I wonder why the developer thought of such a convoluted way to write x != y.

Another common problem I have come across when Boolean objects are used. Invariably you'll see

Boolean b = new Boolean(true);

There is no need to create a new instance here, you could just write -

Boolean b = Boolean.TRUE;
14 Dec 2004 (updated 14 Dec 2004 at 21:03 UTC) »
Eclipse QuickFix problem

Encountered a strange problem while working on Eclipse [In the latest integration build - Version: 3.1.0 Build id: 200412081200]

I wrote a small snippet of code -

    if(getContentSpec().equals("Test"))
        return true;
The method getContentSpec was not implemented in the class; so it gave a compilation error. I took the QuickFix route and asked Eclipse to generate the stub for me. To my surprise, it generated the following code -
/**
* @return
*/
private AbstractList getContentSpec() {
    // TODO Auto-generated method stub
    return null;
}
I didn't really expect the method to return a String - but I at least expected it to return an Object. But it ended by returning an AbstractList!!!!! This was s t r a n g e!

To recreate the problem, before I submit the bug, I created a simple class -

public class QuickFixEquals {

public boolean hasChildren() { return(getContentSpec().equals("Test")); } }

Applied QuickFix ... and the code generated was
    private Object getContentSpec() {
        // TODO Auto-generated method stub
        return null;
    }
Well, thats what I wanted in the original code ... why did it behave differently here?

I finally tracked it down to ... guess what? ... an import statement.

Try QuickFix on the following code

import java.util.List;

public class QuickFixEquals {

public boolean hasChildren() { return(getContentSpec().equals("Test")); } }

It will generate
	private List getContentSpec() {
		// TODO Auto-generated method stub
		return null;
	}
Better yet, try this code
import java.util.ArrayList;
import java.util.List;

public class QuickFixEquals {

public boolean hasChildren() { return (getContentSpec().equals("Test")); }

public List<String> getList() { return new ArrayList<String>(); } }

Apply QuickFix, and lo, you get -
    private AbstractList<E> getContentSpec() {
        // TODO Auto-generated method stub
        return null;
    }
Here's the link to the QuickFix Bug.
3 Dec 2004 (updated 3 Dec 2004 at 18:57 UTC) »
Languages based on the Java VM

I read the article "GJ: Extending the JavaTM programming language with type parameters" [by Gilad Bracha, Martin Odersky, David Stoutamire, Philip Wadler, March 1998; revised August 1998]. It introduces the GJ compiler that is an extension of Java (during the time of JDK 1.2) which provided generics support. The current generics support in Java 5 is based on GJ.

GJ, per the article, is based on Pizza. "GJ is based closely on the handling of parametric types in Pizza".

This led me to search around for Pizza and other languages based on the Java programming language.

The Pizza compiler is hosted on sourceforge. Its current version is 1.1 [released 03-Jan-2002].

The Pizza language is an extension to Java with three new features:

  • Generics (aka Parametric polymorphism)
  • Function pointers (aka First-class functions)
  • Class cases and pattern matching (aka Algebraic types)

The Pizza Tutorial explains the three new features listed above.

GJ - A Generic Java Language Extension - is currently on version 0.6m. It is a superset of the Java programming language and is compatible with existing libraries.

Bistro is a new programming language that integrates the best features of Smalltalk and Java. It is currently on version 3.5 [21-Apr-2002?]. You can read about Bistro in the language neutrality article.

Kiev is another language derived from Java. It was initially written in (and tries to be source compatible with) Pizza language. It is currently on version 0.09a.

You can check many more languages at the list of languages based on the Java VM.

19 Nov 2004 (updated 19 Nov 2004 at 16:57 UTC) »
pipeman asked: What does the numbers next to the names in the Advogato recentlog mean?

Could it be what others have rated your dairy?

Everyone's home page has a question similar to this -

How interesting is pipeman's diary, on a 1 to 10 scale?

It could be the average of all the ratings - hence the fraction against some dairy entries ...

Released version 2.2b of Kaprekar Series Generator.

This is more of a code refactoring release. The code was changed to be more modular. The serialization, SVG generation and statistics code had crept into the Kaprekar Engine. I extracted those into separate classes - this also fixed some cut-and-paste code.

The only bug-fix in this code is for the progress bar in the GUI - the progress bar would not show the progress while searching for Kaprekar Series with more than 19 digits. This is fixed now. Well I had written the code, but for some reason I didn't invoke it. Ok, I thought it was an expensive call so didn't invoke it. Now I'm keeping track of the heartbeat and invoking it initially every 50 heartbeats and then every 500 heartbeats. It didn't seem to have too much of an overhead.

This change was in preparation of moving Kaprekar Series Generator to Java 1.5 to use the new language features.

Found this article on Functional programming in the Java language at IBM DeveloperWorks. A good read ... now need to explore about the Apache Commons Functor.

This is fun - never knew that something like Elephant Polo existed! ;-)

22 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!