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 > Classpath@gnu.org > http://lists.gnu.org/mailman/listinfo/classpath _______________________________________________ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath