Re: Aicas again

[Guilhem Lavaux]

Hi Casey,

I would have appreciated one comment relatively to my proposal for
Classpath IO in December.... It was meeting aicas needs and ours (at
kaffe). At the moment I have left Roman makes his experiments hoping
that everything will stabilize afterwards.

http://lists.gnu.org/archive/html/classpath/2006-01/msg00048.html

Actually noone answered to my questions either. ;-)

Regards,
Guilhem.

Casey Marshall wrote:

> On Jan 23, 2006, at 7:02 PM, Dalibor Topic wrote:
>
>> If the new native layer code turns out to be something that does 
>> more harm then good, then it should be either autoconfiscated, to 
>> save what makes sense saving, or reverted and presumably gradually 
>> rewritten to remove the macros for good. I am not sure if it's too 
>> early to tell, I have not looked at the rewrite in past week myself.
>>
>
> One salient point, I think, is that this goes against the standard 
> way GNU packages are written, which seems to me to basically be to 
> target GNU, but try to be as portable as possible, and use autoconf 
> to sort out the messy bits.
>
> And, a lot of the code I've looked at breaks GNU's style rules 
> (besides using macros absolutely everywhere), which I don't like.
>
> It does make debugging much harder, so that right there is a negative.
>
>> I doubt that will change much for Darwin, either way, since Darwin 
>> is different enough from Linux to trigger portability issues. The 
>> same would be the case if GNU Classpath had more developers using 
>> Cygwin, which also gets regularly broken, in my experience, and  will
>> get regularly broken in the future no matter what approach to 
>> portability layers we take.
>>
>
> I do also think there is value in just writing UNIX-portable code; it 
> seems, to me, to encourage better thinking about what one is writing, 
> without relying on some obscure OS-specific crutch. It is like when I 
> hear C# or Java programmers say they can't write anything lower 
> level, because they depend too much on features (which are often 
> overly generic and inefficient) tied to that environment.
>
>> Runtimes that care about niche platforms like Darwin, Cygwin, 
>> Solaris, or eCos are at any time able to write and maintain their 
>> own code for the native layer anyway thanks to the VM interface 
>> layer, and several runtimes seem to be working fine that way.
>
>
> And that's what Aicas should do! This target-native stuff seems to 
> work really great for them, since they push it so hard. But in the 
> end it isn't terribly portable or usable by the community, and for 
> the life of me I don't see what value they get out of the JNI code 
> that wraps all of these macros. It seems to me like writing a POSIX 
> layer for whatever they are targeting would be easier -- why is 
> `TARGET_NATIVE_ERROR_TRY_AGAIN' better than just writing your own 
> `#define EAGAIN?' Why can't you just call `TARGET_NATIVE_LAST_ERROR' 
> `errno' for platforms that don't have a real errno?
>
> By the way, I don't want to sound like I'm just picking on Aicas 
> here; I should have introduced this as a discussion on just the 
> native layer, not this company in particular. If they had a good 
> suggestion on how to write the native interface, then I'd be fine 
> with it. I just think this one is extraordinarily bad.
>
>> I think the interesting question is where to draw the line what 
>> needs to be included in GNU Classpath (and at what cost) and what 
>> doesn't.
>>
>
> I think a nice, simple, almost reference-implementation style native 
> library makes sense for Classpath (for the things that make sense to 
> write as straight JNI code; truly VM-specific stuff needn't be 
> included). As far as targets go, popular platforms that free software 
> users use is best -- and that may not include Darwin, but GNU/Linux 
> and the sane BSD's should be supported.
>
>> I believe we'll be able to draw a clearer line once the last native 
>> layer experiment is over, but I haven't been following the 
>> discussion closely enough to be able to tell if it is over by now, 
>> or if the current state of afairs is some transition state to 
>> something else.
>>
>
> Is this really mostly an experimental thing? If it is, then it has 
> even less business being the only way of compiling native code right 
> now. It should have been done on a branch, especially since it is 
> continuously breaking things.
>
>
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/classpath