greggyb
commented
1 month ago With more experimentation, it appears that this is specific to readline-enabled interpreters. Disabling readline with $ dotnet fsi --readline- seems to eliminate the error.
Open greggyb opened 1 month ago
greggyb
commented
1 month ago With more experimentation, it appears that this is specific to readline-enabled interpreters. Disabling readline with $ dotnet fsi --readline- seems to eliminate the error.
vzarytovskii
commented
1 month ago What's the version of sdk in use?
greggyb
commented
1 month ago Ubuntu:
$ dotnet --version
8.0.105FreeBSD:
$ dotnet --version
8.0.100Extra context:
Right now, due to a confluence of how FSAC and editors interact, working around this with the --readline- option has pretty negative knock-on effects for interactive programming with Ionide plugins.
A fix for the latter (FSAC issues with CLI options) will make the situation much more tenable for interactive development. Personally, I hope to get that PR raised tonight, as this is impacting my productivity.
After that fix, I think the situation will be much less severe. It certainly won't be a major concern for me, as the vast majority (99%) of my interactive use is sending lines from an editor to the interpreter via Ionide.
bmitc
commented
1 month ago This isn't to say that "it works on my machine" but rather to give further debug data point that this indeed seems specific to the terminal being used. On Windows 11 and Windows Terminal, FSI handles long lines. For example:
PowerShell 7.4.2
Loading personal and system profiles took 1605ms.
> dotnet fsi
Microsoft (R) F# Interactive version 12.8.200.0 for F# 8.0
Copyright (c) Microsoft Corporation. All Rights Reserved.
For help type #help;;
> printfn "This is a very long sentence which I will type to overflow the boundary of the terminal and yield the error
that I am talking about in this bug report. No holding down a key for me! System.PlatformNotSupportedException: Opera
tion is not supported on this platform.asdflkajsfdaoiwejfoawjefoaijwefljawlkefjlakwjfelkajwveoijaoifjeoawjfeawljlvkjaw
kljfoeiawjfeoiawjfoejawoefjoajwfeioajwfeljaklvjelkajfeoaijwfeoiawjefoij";;
This is a very long sentence which I will type to overflow the boundary of the terminal and yield the error that I am talking about in this bug report. No holding down a key for me! System.PlatformNotSupportedException: Operation is not supported on this platform.asdflkajsfdaoiwejfoawjefoaijwefljawlkefjlakwjfelkajwveoijaoifjeoawjfeawljlvkjawkljfoeiawjfeoiawjfoejawoefjoajwfeioajwfeljaklvjelkajfeoaijwfeoiawjefoij
val it: unit = ()Versions:
> dotnet fsi --version
Microsoft (R) F# Interactive version 12.8.200.0 for F# 8.0
> dotnet --version
8.0.204Hopefully that's helpful.
When editing a line in FSI, and seemingly only when we've already used the height of the terminal in lines of input, the interpreter process crashes when a single line overflows the terminal width.
It also unreliably reproduces when the terminal screen is not full, but the most reliable reproduction needs the long line to be at the bottom of a terminal screen where history has rolled off the top of the terminal.
Repro steps
$ dotnet fsiThe sample below is running on Ubuntu 22.04 from official apt sources, but I can reproduce in the following environments:
++Edit++: also under tmux as a terminal multiplexer
For vim and neovim terminals, I have reproduced both by sending lines from a script file with Ionide-vim and by typing directly into the terminal. I originally found this by means of sending script lines to the interpreter with Ionide-vim. I had a long line that only caused issues when I had created my fsi window in a vertical split (two panes side by side, so each is half the screen width); if I stacked the windows on top of one another instead (each has whole screen width), I did not have any issue. Repro followed from there.
Expected behavior
You should be able to type arbitrarily long lines into FSI (or at least a whole lot longer than one screen width) and it should interpret the code.
Actual behavior
Overflowing a terminal line causes the exception above. Sometimes, I have observed that instead of immediately throwing the exception, instead the cursor will wrap around to the beginning of the current line without a linefeed/newlline character (as if it were just executing a carriage return, but I have not validated the actual character codes being interpreted while typing), and the exception will only be thrown sometime after that. It can also get very confused about what quotes have been terminated when this specific behavior occurs. I cannot reliably reproduce the latter behavior, but it throws the same
System.PlatformNotSupportedException: Operation is not supported on this platform.When the latter behavior occurs I do not get the full stack trace either.Known workarounds
Write shorter code.
Related information
vim and nvim versions.