From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-12-05 12:24:16
|
On Fri, Dec 5, 2008 at 1:13 PM, Ville Voutilainen <vil...@gm...> wrote: > On Fri, Dec 5, 2008 at 12:15 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: >> I presume this fixes the *linux* failures? > > Yes.. > >> If that's true, that's really great! (There will still be Windows >> fixes required, but I have an idea where to look for them.) If this >> all happens, we're back at our "regular" 47/48 failures and we'll be >> able to merge all of this back to trunk. > > I thought I saw 49, which is a not-seen-before number, correctly > run ensure-directories-exist or not. I have to look at that again. I believe Hideo hinted at that: OPEN.66 might fail on the branch, but never has on the trunk. The issue here is that OPEN can be passed an open stream: a situation we don't seem to handle in OPEN. Why that test would work on trunk is a mistery to me though. > I still wonder *why* this helps. The charPos is practically just a flag - > nothing decreases it, it's just set to zero (or zero + > chars-after-last-newline), > so why does it matter if it's set in two places or not? Both of the places > should set the same value as far as I can see. Because if the flag is 0, it must not be overwritten? I have no idea. The issue on the Windows branch is that the sources of the test already contain \r\n characters and that \n is being translated into \r\n, resulting in \r\r\n. This basically means we need to implement the extended form of new-line translation as discussed before: it would fix the issue in the most fundamental way possible. Bye, Erik. |
From: Ville V. <vil...@gm...> - 2008-12-05 17:16:27
|
On Fri, Dec 5, 2008 at 2:24 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > On Fri, Dec 5, 2008 at 1:13 PM, Ville Voutilainen > The issue on the Windows branch is that the sources of the test > already contain \r\n characters and that \n is being translated into > \r\n, resulting in \r\r\n. This basically means we need to implement > the extended form of new-line translation as discussed before: it > would fix the issue in the most fundamental way possible. That would work, but why don't we default to RAW? I find it a bit odd that we default to a mode where eol-translations are done, then all practical (IMHO) stream operations need to explicitly specify binary/RAW mode. Are lisp streams usually eol-translating by default? |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-12-05 18:43:25
|
On Fri, Dec 5, 2008 at 6:16 PM, Ville Voutilainen <vil...@gm...> wrote: > On Fri, Dec 5, 2008 at 2:24 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: >> On Fri, Dec 5, 2008 at 1:13 PM, Ville Voutilainen >> The issue on the Windows branch is that the sources of the test >> already contain \r\n characters and that \n is being translated into >> \r\n, resulting in \r\r\n. This basically means we need to implement >> the extended form of new-line translation as discussed before: it >> would fix the issue in the most fundamental way possible. > > That would work, but why don't we default to RAW? I find it a bit odd > that we default to a mode where eol-translations are done, then all > practical (IMHO) stream operations need to explicitly specify > binary/RAW mode. Are lisp streams usually eol-translating by > default? I think most Windows Lisps translate \n (alias ~%) to \r\n... [both on input as well as output]. Other than that, I don't think there are any which do other translations. Bye, Erik. |
From: Hideo at Y. <hid...@gm...> - 2008-12-06 03:29:56
|
Hi. being an old timer from the pre-MS-DOS age, I have a question here. On Sat, 06 Dec 2008 03:43:22 +0900, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > On Fri, Dec 5, 2008 at 6:16 PM, Ville Voutilainen > <vil...@gm...> wrote: >> On Fri, Dec 5, 2008 at 2:24 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: >>> On Fri, Dec 5, 2008 at 1:13 PM, Ville Voutilainen >>> The issue on the Windows branch is that the sources of the test >>> already contain \r\n characters and that \n is being translated into >>> \r\n, resulting in \r\r\n. This basically means we need to implement >>> the extended form of new-line translation as discussed before: it >>> would fix the issue in the most fundamental way possible. Isn't something unusual going on ? Test case source files on Windows contain CRLFs as EOL chars. OK, that's typical. But I would expect those CRLFs would be turned into LFs by the stream that reads the file when the lisp reader parses them, and in the lisp's internal memory representation they would become LFs. And when the program is run, that LF will be translated to CRLF by the output stream. That is what other languages like C or Java does. So there shouldn't be any \r\n hanging around in lisp strings, unless you do a raw read in the Windows world. Maybe I am missing something about the test cases running on Windows. Cheers, Hideo. >> >> That would work, but why don't we default to RAW? I find it a bit odd >> that we default to a mode where eol-translations are done, then all >> practical (IMHO) stream operations need to explicitly specify >> binary/RAW mode. Are lisp streams usually eol-translating by >> default? > > I think most Windows Lisps translate \n (alias ~%) to \r\n... [both on > input as well as output]. > > Other than that, I don't think there are any which do other translations. > > Bye, > > > Erik. > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, > Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > armedbear-j-devel mailing list > arm...@li... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel -- Opera の革新的メールクライアント: http://jp.opera.com/mail/ |
From: <log...@gm...> - 2008-12-05 22:05:27
|
Diff format of the previous email > Just a troublcshooting note: this fixes for windows .. However of course it almost reverts the code back to the trunk state. [root@titan trunk-diff]# svn diff src/org/armedbear/lisp/Stream.java Index: src/org/armedbear/lisp/Stream.java =================================================================== --- src/org/armedbear/lisp/Stream.java (revision 11418) +++ src/org/armedbear/lisp/Stream.java (working copy) @@ -1869,13 +1869,19 @@ * @param c * @throws org.armedbear.lisp.ConditionThrowable */ + int lastChar = -1; public void _writeChar(char c) throws ConditionThrowable { try { if (c == '\n') { - if (eolStyle == EolStyle.CRLF) - writer.write("\r\n"); + if (eolStyle == EolStyle.CRLF && lastChar!='\r') { + if (!Utilities.isPlatformWindows) //they are non windows but have specificed the CrLF so we obey + writer.write("\r\n"); + else + writer.write(eolChar); // this is delaying the win32 problem but passes the tests + + } else writer.write(eolChar); @@ -1883,6 +1889,8 @@ charPos = 0; } else { writer.write(c); + //for EolStyle.CR + if (eolChar==c) charPos = 0; else ++charPos; } } @@ -1895,6 +1903,7 @@ { error(new StreamError(this, e)); } + lastChar = c; } /** Writes a series of characters in the underlying stream, @@ -1915,7 +1924,7 @@ //###FIXME: the number of writes can be greatly reduced by // writing the space between newlines as chunks. _writeChar(chars[i]); - + return; // because each _writeChar(char) did all to positional updates :) } else writer.write(chars, start, end - start); [root@titan trunk-diff]# |
From: <log...@gm...> - 2008-12-05 22:22:14
|
Just a troublcshooting note: this fixes for windows .. However of course it almost reverts the code back to the trunk state. int lastChar = 0; /** Writes a character into the underlying stream, * updating charPos while doing so * * @param c * @throws org.armedbear.lisp.ConditionThrowable */ public void _writeChar(char c) throws ConditionThrowable { try { if (c == '\n') { if (eolStyle == EolStyle.CRLF && lastChar!='\r') if (Utilities.isPlatformUnix) { // Well they said want it this way writer.write("\r\n"); } else { writer.write(eolChar); // why does this make all the win32 fail? writer.write("\r\n"); } else writer.write(eolChar); writer.flush(); charPos = 0; } else { writer.write(c); //for EolStyle.CR if (eolChar==c) charPos = 0; else ++charPos; } } catch (NullPointerException e) { // writer is null streamNotCharacterOutputStream(); } catch (IOException e) { error(new StreamError(this, e)); } lastChar = c; } ----- Original Message ----- From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX To: "Ville Voutilainen" <vil...@gm...> Cc: <dm...@us...>; <arm...@li...> Sent: Friday, December 05, 2008 10:43 AM Subject: Re: Fixed the Failures - _writeChars(char[] chars, int start, int end) > On Fri, Dec 5, 2008 at 6:16 PM, Ville Voutilainen > <vil...@gm...> wrote: >> On Fri, Dec 5, 2008 at 2:24 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: >>> On Fri, Dec 5, 2008 at 1:13 PM, Ville Voutilainen >>> The issue on the Windows branch is that the sources of the test >>> already contain \r\n characters and that \n is being translated into >>> \r\n, resulting in \r\r\n. This basically means we need to implement >>> the extended form of new-line translation as discussed before: it >>> would fix the issue in the most fundamental way possible. >> >> That would work, but why don't we default to RAW? I find it a bit odd >> that we default to a mode where eol-translations are done, then all >> practical (IMHO) stream operations need to explicitly specify >> binary/RAW mode. Are lisp streams usually eol-translating by >> default? I was able to fix the windows errors with this line > > I think most Windows Lisps translate \n (alias ~%) to \r\n... [both on > input as well as output]. > > Other than that, I don't think there are any which do other translations. > |
From: Ville V. <vil...@gm...> - 2008-12-05 16:20:02
|
On Fri, Dec 5, 2008 at 2:24 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: >> I still wonder *why* this helps. The charPos is practically just a flag - >> nothing decreases it, it's just set to zero (or zero + >> chars-after-last-newline), >> so why does it matter if it's set in two places or not? Both of the places >> should set the same value as far as I can see. > Because if the flag is 0, it must not be overwritten? I have no idea. I think I found it. It's in LispThread.print: private static void pprint(LispObject obj, int indentBy, Stream stream) String raw = obj.writeToString(); if (stream.getCharPos() + raw.length() < 80) { // It fits. stream._writeString(raw); return; } This fits-or-not calculation will go to the doesn't-fit part, because we increment charPos twice and thus it's incremented too much in some cases. The reason why I see 49 failures is that LISTEN.7 fails, so we have a socket-related regression. |