REPL on windows doesn't recognize newlines #1
Comments
@rkoeninger when you run this code in SBCL, whats the output? (you will see a bunch of warnings, ignore those, what is important is the result of the call to (setq *standard-two-way* (make-two-way-stream *standard-input* *standard-output*))
(setq *stinput* *standard-two-way*)
(read-byte *stinput* nil -1) |
@rkoeninger have you discovered anything new related to this? Also, you don't have this problem in the CLisp port, right? |
@tizoc I'm going to look at this next. And no, the CLisp port doesn't have this problem. |
Ok, great. Btw, on my system the result of |
Well, it can be different, any combination of |
@tizoc If I start If it type |
@rkoeninger you hit enter to complete the expression or you mean enter after the expression has been submitted to the repl? It has to be: |
Btw are you using any kind of alternative terminal program? |
If it turns out the output is correct, here is another thing to try: (define toplineread_loop
-1 [] -> (exit 0)
Byte _ -> (error "line read aborted") where (= Byte (hat))
Byte Bytes -> (let Line (compile (/. X (<st_input> X)) Bytes (/. E nextline))
It (record-it Bytes)
_ (output "~%Line: ~R~%Bytes: ~R~%" Line Bytes) \\ ++LINE ADDED++
(if (or (= Line nextline) (empty? Line))
(toplineread_loop (read-byte (stinput))
(append Bytes [Byte]))
(@p Line Bytes)))
where (element? Byte [(newline) (carriage-return)])
Byte Bytes -> (toplineread_loop (read-byte (stinput))
(if (= Byte -1)
Bytes
(append Bytes [Byte])))) If the reason is not that the newline character is not recognized correctly, then it has to do with the parser not being able to handle it (probably because of some extraneous byte that gets inserted in the input). |
I've been using ConEmu. The But the Shen REPL still doesn't handle newlines even when run from |
Ok, good, just eliminating possibilities. |
I wrote your above code in the kl because I didn't want to re-build the shen:
I start the shen repl, type Using |
In the CLisp port, the above version of |
Well, there is the problem. It was not that the bytes had the value multiplied by 10, it is that between reads a NULL byte is inserted. This is what causes the parser to fail. iirc you were running SBCL 1.3.15, I just checked the release notes of 1.3.16 and I don't see anything related to I/O bug fixes. In my own install this:
results in:
No weird bytes added in between. Not sure what causes it, but we are getting closer. |
I'm now thinking that your SBCL install may be using a multibyte STDIN, could that be it? Trying to find if there is a way to control that in SBCL. |
@rkoeninger whats your output for this?
mine is:
|
Can I insert something like |
Do you launch Shen from the console? What I found (on random threads by Python and Go programmers having encoding issues in the console) is that you can change the encoding to UTF-8 by doing:
So doing so before launching Shen may help. I don't know if the encoding of STDIN can be changed after the process has started (or how it can be done in SBCL) |
I don't think I'm not a CommonLisp person, but I'm imaging wrapping the stdin stream in another stream that translates to a particular encoding. Or having a different version of read-byte that reads two bytes, ignoring the second. Does this make sense? (IF (FIND :WIN32 *FEATURES*)) ; or identify a 16-bit encoding
(DEFUN read-byte (S) (LET ((B (READ-BYTE S NIL -1))) (READ-BYTE S NIL -1) B)))
(DEFUN read-byte (S) (READ-BYTE S NIL -1))) |
Thats not going to work, because it only "fixes" the problem for the console input, breaking it for everything else (including STDIN when it is not the terminal). It may also work in your environment but cause problems for other users. Btw, the So, somehow, the SBCL input encoding has to change before generating the Shen binary, not after. |
I ran There's no way to say something like |
I don't know, I tried to find a way to do it and the best thing I found was the It is also not entirely clear to me how the terminal decides which encoding to send to the program, the older Shen.exe, and your CLisp compiled one do not have this problem, their STDIN is in a single-byte encoding. And what is more important, the old Shen.exe uses almost the same code, what is different is the environment in which it was compiled (that is, whatever version of Windows and SBCL Mark used at the time), there was no code to set the encoding of STDIN. |
@rkoeninger can you try obtaining the SBCL version from the old Shen binary? Being that it was compiled without the changes that get rid of the SBCL flags, If we know the version, we can then see if something changed between SBCL versions regarding terminal I/O. It will also let you test the current code compiled with that older version of SBCL to see how it behaves. |
Also, when running that Shen binary, whats the output of: |
the
|
Well, thats very interesting, it means that the encoding of STDIN is the same as the one compiled with a newer SBCL version (that throws a big part of my theory out of the window, what still stands is the difference in SBCL versions used to compile it). I will investigate later and see if I find what changed between 1.1.1 and 1.3.x. |
Oh, sorry the I don't know what the pre-built shen.exe would say. Trying to run the shen.exe that comes with the standard download gives me the ugly error above. ...i thought it worked before? I'll have to try it on my other machine, or on something that doesn't have sbcl installed separately. |
I found this: https://bugs.launchpad.net/sbcl/+bug/1660906 It is a fix introduced 1.3.15 with the description I don't think that is the issue, leaving it here just for the record. |
Aaaaand, in version This is why the old binary works and the new one doesn't. I guess this is the code that does that: I don't know what the solution is yet but I'm starting to get a better idea of how to approach it. |
And the change: sbcl/sbcl@eac461c |
@rkoeninger just pushed a new branch named |
If that doesn't work we have to figure out another way to make a separate stream for STDIN. I know binding it to the file descriptor with id 0 will work on unix-like systems, not sure if it will work on windows. |
It built, and when I ran shen.exe:
And then it crashed. |
I found something very weird. If I type anything else other than |
For me, shen.exe fails before I have the opportunity to provide any input. If I type |
This library seems to have the ability to wrap a stream in another stream with a different format: http://weitz.de/flexi-streams/#make-flexi-stream It's built on gray streams: https://github.com/sbcl/sbcl/blob/master/src/pcl/gray-streams.lisp |
@rkoeninger I made some changes, one that fixes the intermittent io errors I was having on OSX when using the new branch, another one that may fix the crash you were having on windows, give it another try when you get a chance. And just in case, don't think I'm not considered your suggestions, it is just that I'm trying to solve this at the right level, wrapping the streams will cause different issues because doing so just masks the problem instead of solving it, and as a result we may end having different problems (like for example, what happens when STDIN is not the console, but a redirected file). |
|
@rkoeninger mmm.... it is supposed to be defined on windows, maybe it needs some prefix (one I don't know of). Does it work if you change |
In the SBCL REPL, does this work? Edited: the prefix is |
|
@rkoeninger I borrowed a machine with windows, I can now try stuff without bothering you (thanks for your patience btw). I explained the situation in SBCL's irc, but the answers are not very helpful (it is basically, "well, shen shouldn't be doing that"), I'm not even being told if what I'm trying to do is possible at all or plain nonsense. |
@rkoeninger just pushed a new branch |
When I try to build the
|
Sorry, I messed something up when writing the code again on my machine (what I did in the windows machine worked, I just could not commit from there so I just rewrote the code here, but made a mistake). Already pushed the fixed version. |
With your latest change, it builds and the shen repl handles input as expected. I can even do Ctrl + D and hit Enter and it exits the shen repl. Also, the test suite passes just fine (~5.1s), so I guess file reads are still good. Good job, man! Thanks for all your time and effort on this! |
Oh, thats great. The "windows" machine I was testing on was a VirtualBox VM running on someone else's Linux computer, I guess thats why those keys were being weird when I tested. Btw, don't merge anything yet, I'm thinking of a cleaner solution that doesn't have to special-case windows or check for |
This should be fixed now. |
No description provided.
The text was updated successfully, but these errors were encountered: