# Friday, 03 October 2003
« Constructing Inner Classes | Main | GNU Classpath Meeting »
Vacation

I'm going on vacation again :-) I'll be back on the 12th.

I just realised I haven't blogged for a whole month. It's not because there hasn't been any progress. I've been experimenting with a way to make ghost interfaces more usable from other languages. More on that when I get back.

Friday, 03 October 2003 21:53:33 (W. Europe Daylight Time, UTC+02:00)  #    Comments [8] Tracked by:
"strip poker online game" (strip poker online game) [Trackback]

Monday, 06 October 2003 20:21:26 (W. Europe Daylight Time, UTC+02:00)
Jeroen,

You may want to plan on using the C# generics support in the upcoming Whidbey class libraries and runtime to implement your ghost interfaces in future IKVM releases. They should release a prerelease an the end of the month. See: http://research.microsoft.com/projects/clrgen/generics.pdf
You can experiment with the implementation now with the Gyro generics implementation running on rotor. See Gyro at: http://research.microsoft.com/research/downloads/
Tuesday, 07 October 2003 16:22:35 (W. Europe Daylight Time, UTC+02:00)
Oh no! Don't give Jeroen an excuse to require 2.0! I still want 1.0 support! ;)

Just last week I was enquiring as to whether it would be possible for IKVM to support the 1.0 framework version. Jeroen's reply was that it wouldn't be hard in theory to make the relevant parts of the code conditional, but that it would be subject to bitrot when parts of the code with obscure 1.0 workarounds are rewritten and the workarounds get forgotten.

At the very least, I hope that we stay on 1.1 until there's a VS.NET corresponding to 2.0...
Stuart
Monday, 13 October 2003 11:52:57 (W. Europe Daylight Time, UTC+02:00)
I don't see how using generics would help with the ghost interfaces. Do you have any specific suggestions? I already played with Gyro way back when it was released, so I have some familiarity with it.

Stuart, no need to worry, I will not switch to 2.0 until it is released ;-)

Monday, 13 October 2003 19:33:00 (W. Europe Daylight Time, UTC+02:00)
Another thought on framework versions:

It's (probably) too late for 1.0, but would you consider switching to a "real" version number system rather than just "the latest snapshot" before requiring a new framework version? That way, as long as my program works with some past IKVM release, I can always recommend to users to get that version if they need 1.1 support, even after 2.0 is required by newer versions.
Stuart
Wednesday, 15 October 2003 03:17:11 (W. Europe Daylight Time, UTC+02:00)
// Jeroen,

Here's what I was suggesting for using generics for ghost interfaces. I haven't tested this code at all but I wanted to get back to you on what I was thinking from what I read about gyro:


// Consider the following example:

using Object = System.Object;
using String = System.String;
using StringBuffer = java.lang.StringBuffer;
using Character = java.lang.Character;
using CharSequence = java.lang.CharSequence;

class Test
{
/*
public static CharSequence toUpperCase(CharSequence seq)
{
StringBuffer buf = new StringBuffer();
int len = seq.length();
for(int i = 0; i < len; i++)
{
char c = seq.charAt(i);
c = Character.toUpperCase(c);
buf.append(c);
}
return buf;
}
public static void Main ()
{
String s = "abc";
String theUpperCaseString = Test.ToUpperCase (s);
}
*/
}

// Your current ghost implementation compiles into something like the following:

class TestCompiled
{

// Currently, you compile this as something like:

private static object toUpperCase(object seq)
{
StringBuffer buf = new StringBuffer();
int len;
if(seq is String)
{
len = ((String)seq).Length;
}
else
{
len = ((CharSequence.__Interface)seq).length();
}
for(int i = 0; i < len; i++)
{
char c;
if(seq is String)
{
c = ((String)seq) [i];
}
else
{
c = ((CharSequence.__Interface)seq).charAt(i);
}
c = Character.toUpperCase(c);
buf.append(c);
}
return buf;
}
public static void Main ()
{
string s = "abc";
string theUpperCaseString = (string) toUpperCase (s);
}
}

// I have not tested this code since I haven't yet installed gyro and rotorl, but from what I read about generics, you might be able to do something like the following:

interface CharSequence<V>
{
char charAt (V theSequence, int i);
int length (V theSequence);
}

class CharSequenceHelper

{
public static char charAt<V>(CharSequence<V> s, int i) where V: CharSequence<V> (string<V> s) { return (s.charAt (i); }
public static int length<V>(CharSequence<V> s) where V: CharSequence<V> (string<V> s) { return (s.length(); }
}

class TestCompiledWithGenerics
{
public static CharSequence<V> toUpperCase(CharSequence<V> seq)
{
StringBuffer buf = new StringBuffer();
int len = CharSequenceHelper.length(seq);
for(int i = 0; i < len; i++) {
char c = CharSequenceHelper.charAt(seq, i);
c = Character.toUpperCase(c);
buf.append(c);
}
return buf;
}
public static Main ()
{
string s = "abc";
string theUpperCaseString = TestCompiledWithGenerics.ToUpperCase<string> (s);
}
}
Wednesday, 15 October 2003 18:54:23 (W. Europe Daylight Time, UTC+02:00)
To Stuart: I agree I should start using a real version number, but at the moment I still feel the whole design is too much in flux for that. I will make the promise that before upgrading to the 2.0 CLR I will make a frozen 1.1 release and keep that up on the site.

To Jonathan: I've moved the discussion to e-mail (ikvm-developers list), because I think the comment system is too uncomfortable for extensive discussions.

For those not subscribed to the mailing list, the archives are available at: http://sourceforge.net/mailarchive/forum.php?forum_id=13102
Thursday, 16 October 2003 23:14:07 (W. Europe Daylight Time, UTC+02:00)
I think I disagree that the design being in flux is a good reason to stay away from real version numbers. On the contrary, I think it's an excellent reason to *use* real version numbers.

Consider that if someone shows up on the mailing list with problems in a version of IKVM they downloaded "a while ago", they may not be able to give a specific date that they downloaded it on, but they can certainly type "ikvm -version" (which currently, unless I'm mistaken, doesn't give information that would be useful to figure out how old of a snapshot it is). You could then correlate the release date of that version against blog entries and mailing lists to figure out what the architecture was like at that point in time and give useful suggestions.

Even if the version number is "0.0.20031016" (the last part being the date) at least there's some way to say which version you mean, rather than "the latest snapshot as of last Thursday" I'd also like to be able to get prior snapshots - for example, if the last version that supported 1.0 were available anywhere in source form, it would have been valuable to me a couple of weeks ago.

(Btw, I'm certainly guilty of the same thing myself - there's always "a few more things" that I want to get done before I call nrdo (http://savannah.nongnu.org/projects/nrdo) "version 0.1" or whatever. But since nobody but me is actually using nrdo at all, it doesn't affect anyone much ;) I also know that I'm wrong to do this and putting a version number on the current snapshot is one of my top priorities as soon as I find time to do a "release process".)
Stuart
Friday, 17 October 2003 15:08:56 (W. Europe Daylight Time, UTC+02:00)
The version number reported by ikvm -version can actually be translated to a timestamp. The build number is the number of days since whenever and the revision is the number of seconds (?) since midnight.

OK, I admit, I'm just being lazy :-)
Name
E-mail
Home page

I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.

Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)

Answer:  
Comment (HTML not allowed)  

Live Comment Preview