generated files in CVS?
Why are the following files in CVS? config.guess config.sub ltmain.sh If there is no particular reason, I'd like to remove them from CVS, as runnnig auto* tools causes spurious diffs in these files. Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
Hi all, As most people dislike the m4 approach without even having a look at it (just remembering m4 as used in auto* stuff...), I will no push for this further. I have no time for religious wars. As for the --with-vm, it will for now be implemented as an optional command-line argument. Not providing it will not change anything to current behavior. Note to Patrik: I thought you would have noticed, by now, that I was only trying to tell about a subset of the VMs that use Classpath without using 10 words. (See other messages for a better description). I used "normal" as in "normally built". I did not intend to say "better" or "worse". Etienne Patrik Reali wrote: And how do you define "normal" anyway? Only technology that is at least 20 years old? -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Proposed java.io.OutputStreamWriter patch
Hi,
Currently, if you System.out.println() a string containing an
unencodeable character, the line gets silently swallowed, instead the
unencodeable character should be replaced by a question mark (at least
that's what Sun does on Windows).
This behavior doesn't appear to be specified anywhere, but testing
suggests that the proper way to do this is by calling setBadCharValue on
the Encoder in OutputStreamWriter.
OK to apply?
Regards,
Jeroen
Index: java/io/OutputStreamWriter.java
===
RCS file: /cvsroot/classpath/classpath/java/io/OutputStreamWriter.java,v
retrieving revision 1.9
diff -u -r1.9 OutputStreamWriter.java
--- java/io/OutputStreamWriter.java 9 May 2003 13:30:35 -
1.9
+++ java/io/OutputStreamWriter.java 27 Mar 2004 14:18:22 -
@@ -101,6 +101,14 @@
throws UnsupportedEncodingException
{
this.out = EncodingManager.getEncoder (out, encoding_scheme);
+try
+{
+ this.out.setBadCharValue('?');
+}
+catch(CharConversionException x)
+{
+ // what can we do here?
+}
}
/**
@@ -112,6 +120,14 @@
public OutputStreamWriter (OutputStream out)
{
this.out = EncodingManager.getEncoder (out);
+try
+{
+ this.out.setBadCharValue('?');
+}
+catch(CharConversionException x)
+{
+ // what can we do here?
+}
}
/**
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
Classpath is not meant to live on its own; it is either meant to be used as a class library for a compiler (e.g. jikes), or as a class library for a virtual machine (gcj, JikesRVM, SableVM, Kaffe, ...). So, I suggest to change the "configure.ac" to force "./configure" to require a "--with-vm=xxx" option. In other words, there would not be a "default" Classpath configuration. The motivation is that when a user builds a Classpath version, he intends to use it in some context. There is no default set of options that would work for all possible uses of Classpath. In fact, each possible "default" configuration would favor one VM or one compiler over the others. This doesn't apply to Jaos: it uses Classpath out of the box; some methods are overridden by an Oberon implementation, but it still requires the java class in the beginning. There seems to be at least 4 VM whose configuration corresponds to the current "default" configuration I think this defeats the purpose of being a library for all VM and compilers around, and raises the entry barrier for new ones. The objective: Share as much code between "normal" VMs (that need nothing really special in base classes), and intuitive source file locations. Sharing is possible only when this code written in java, because this is the only common denominator all VM use! And how do you define "normal" anyway? Only technology that is at least 20 years old? -Patrik Patrik Reali http://www.reali.ch/~patrik/ http://www.oberon.ethz.ch/jaos/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
