[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Aicas again
Re: Aicas again
Tue, 24 Jan 2006 09:02:32 +0100
Debian Thunderbird 1.0.2 (X11/20051002)
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.
Actually noone answered to my questions either. ;-)
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
> 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