I've been trying for a week to get F# interactive working in Emacs and I haven't been able to.
The problem is that whenever I run "fsi" or "fsharpi" (either using fsharp mode or in a shell buffer), the buffer becomes unresponsive. I check the system monitor and see a mono process using 100% CPU and obviously anything I type doesn't get evaluated.
I've tried this on Emacs 24.1 and 23.2; also on OS X, Linux Mint and Fedora, and all cause the same exact problem.
I've tried different versions of mono (2.10.9, 3.0 and 2.8 on OS X; 2.10.8.1 on Linux Mint, can't remember on Fedora). I've also tried F# 2.0 and 3.0; all with same results.
I've also tried passing in "--no-gui" and "--readline" when launching the interpreter to no use.
Here's basically what happens
bash-3.2$ fsharpi
Microsoft (R) F# 3.0 Interactive version (Mono build)
Copyright (c) Microsoft Corporation. All Rights Reserved.
For help type #help;;
> - 1+2;;
# after waiting for a minute, I kill the mono process
Killed: 9
bash-3.2$ bash: syntax error near unexpected token `;;'
However, the interpreter does work when running it on an "ansi-term" buffer:
bash-3.2$ fsharpi
Microsoft (R) F# 3.0 Interactive version (Mono build)
Copyright (c) Microsoft Corporation. All Rights Reserved.
For help type #help;;
> - 1+2;;
val it : int = 3
I want to use it with fsharp mode so that I can send code to the interpreter easily.
I haven't seen anyone having problems of this kind online, and resolving this would make development so much more convenient.
Any ideas on how to get this working?
Edit: as expected, running it in comint mode also "hangs" (comint is what fsharp mode uses).
What version of fsharp-mode are you using? The last update (v0.3) was just after the release of VS2010 (F# 2.0), and the release notes mention that an infinite-loop bug was fixed in that version.
Another possibility -- the last update to fsharp-mode predates Mono's support for F#, so my guess is that some piece of code in the Intellisense helper project (in the /src folder of the fsharp-mode code) is relying on Windows-specific behavior and breaking when you run it on Mono.
I think your best bet to get this working is to repost your question on the fsharp-opensource mailing list, as a number of people on there are running F# on Mono and might know how to fix the problem.
EDIT: The answer from the mailing list post is to pass in the --readline- flag. The trailing - turns readline off and fixes the problem.
The answer is to run the F# interpreter with the option "--readline-".
It should be solved (no need for this command line argument) in the Github repository https://github.com/fsharp/fsharp
Related
I have three machines running VSCode on Windows 10 set up for C++ with msys2 / mingw64 /gcc.
Via Github they share each other's code.
On one Machine i have a problem with intellisense that is annoying:
When I want to retrieve intellisense information, e.g. from an instance of a String object by pressing "." after the instance name, I do get the list of member functions and attributes, but the type information window to the left of it is sparse.
This is how it looks like on other computers (same os, same VSCode version, same gcc compiler, as far as i can tell)
This is how it looks on this certain machine.
It is exactly the same file. I don't get the meaningful additional information that otherwise appears in the intellisense popup.
Note that the bottom line of file normally says basic_string.h, but on the problem computer it says xstring. In other cases also something else with "X", e.g. xiobase.
I've been suggested that these files could belong to Microsoft C++ header files, but I use gcc here.
gcc --version on these machines gives me
gcc (Rev7, Built by MSYS2 project) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
In fact, the Microsoft C compiler is installed on the aforementioned faulty Rachner (but also on the third computer, which I don't have access to at the moment, but which also provides "correct" intellisense).
Here is another interesting fact that may be important: In the VSCode output Console i'm getting a message as C/C++ Configuration Warnings saying
[11.1.2023, 23:40:57] Unable to resolve configuration with compilerPath "c:\Users\Username\.vscode\extensions\bartmanabyss.amiga-debug-1.6.7\bin\win32\opt\bin\m68k-amiga-elf-gcc". Using "cl.exe" instead.
With cl.exe being the Microsoft compiler.
I don't have the slightest idea where this comes from, the bartmanabyss.amiga-debug-1.6.7 directory doesn't even exist in the extensions directory.
Microsoft C/C++ IntelliSense, debugging, and code browsing extension is version v1.13.9 on all machines.
Looks like i have lost some information here.
I think there should be some configuration setting, but so far i didn't manage to find a reason for this.
I have been using Coverity Scan for about a year, currently in Windows 7 Pro SP1 x64. Since I first started with it, I had no trouble feeding cov-build my project's make command and it emitting 100% of the compilation units every time. Something has changed with version 8.7.0 of the Coverity Build tool: It takes a similar amount of time to process my source code, but it always results in error and says that no compilation units were emitted.
The intermediate directory has many files written when I use this release of cov-build, and the log has many instances of the following:
error: unknown target triple '--windows-gnu', please use -triple or
-arch WARNING: cov-internal-emit-clang returned with code 4
My source code hasn't changed significantly, I haven't changed any of my build tools either. If I downgrade to the previous version of the build tool (8.5.0.5), it works properly and emits all compilation units as expected. I've emailed Coverity support about this a couple of times, but haven't received a response. Is the latest version of the build tool working for other people?
It turns out that the original 8.7.0 release had a bug that prevented the capture tool from properly identifying the compiler. Coverity support advised me to re-download the 8.7.0 release and it's working normally now.
Looking at the build log snippet you pasted, this looks like you've configured gcc on Windows as comptype clangcc. On MacOSX gcc is really Apple's Clang compiler in disguise, but I'm not aware of the same being true on Windows. This is causing the compiler probes for Clang to fail - most directly indicated by this obviously incorrect compiler version switch:
--comp_ver "gcc.exe (GCC) 4.8.1 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. "
I believe your solution is to delete your gcc-as-clang configurations and re-run cov-configure. Most likely this will be sufficient:
cov-configure --gcc
however if there is some product bug where that doesn't work (please contact support of that's the case), then this is the more explicit version:
cov-configure --compiler gcc --comptype gcc --template
Did you run cov-configure yourself, or are these the configurations being shipped with SCAN?
I have been running PowerShell v3 for some time on several different systems. On occasion I wish to check compatibility or other issues with v2 so I switch to v2 within an existing PowerShell with this:
PS> powershell -version 2
As a matter of course I then use either $hosts.Version or $PSVersionTable to do a sanity check. But on one machine when I did this they both reported I was still in a V3 shell. I tried again from scratch; same result. I also tried invoking it from a DOS shell instead of a PowerShell; again, same result. Then to check my own sanity(!) I went to another system, did the same sequence, and it worked as expected--I did indeed switch from a V3 to a V2 environment.
The only other observation I have is that on the system that worked, I got a 2009 copyright notice when it started up the inner shell; on the system that did not it showed 2012.
Final detail: of the two machines mentioned, it worked on Win8 and failed on Win7 enterprise but I really doubt that is a relevant factor here.
I would be really surprised if (a) this is a PS bug or (b) I am the only one seeing the issue, yet web searching has been fruitless for me thusfar. Any thoughts on why this might be happening?
One reason would be that .NET 2.0 is not installed on the failing system, I cant recall if it had to be already installed prior to v3 or you can install it after upgrading to v3.
Quick search turned up this, just an idea? Maybe V2 is not installed?
Is Version 2 installed?
In my product we are using winzipCLI to zip packages. After a long time i seeing an issue not able to resolve it. A evaluation acceptance message is thrown in CLI which is causing my build system to fail. I found the issue by manually running the winzip cli and below the evalution question asked ....How to suppress it? Any options? or any script? or...etc?
C:\Program Files\WinZip>WZZIP.EXE -a test.zip *.txt
WinZip(R) Command Line Support Add-On Version 4.0 32-bit (Build 10480)
Copyright (c) 1991-2013 WinZip International LLC - All Rights Reserved
THANK YOU FOR TRYING WINZIP COMMAND LINE ADD-ON
This is a fully functional version for EVALUATION USE ONLY
This notice is not displayed with registered Standard and Pro editions of
WinZip.
Please go to www.winzip.com to order WinZip.
(press any key to continue (Ctrl-C to quit))
Yes, buy a license for WinZip.
(Stack Overflow is not the place to ask questions like "How can I avoid paying for this piece of commercial software?" If in fact you have bought a license and you're still getting that message then I apologise for misjudging you and you should take it up with WinZip tech support.)
I'm having the strangest issue while trying to build and install muParser on my windows machine. As suggested by the installation guide, I just cd into the build folder, and run
make -f makefile.mingw
This should be all well and good standard procedure. However, I can't make sense of the output from the command:
if not exist obj\gcc_static_rel mkdir obj\gcc_static_rel
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Chase\Desktop\muparser_v2_0_0\muparser_v2_0_0\build>
Now... at this point, I'm really confused. Because according to the title of the command prompt window, I'm still INSIDE the make command. So, I type "exit" at the "prompt"
g++ -c -o obj\gcc_static_rel\muParser_lib_muParser.o -DNDEBUG -O2 -D_WIN32 - I..\include -MTobj\gcc_static_rel\muParser_lib_muParser.o - MFobj\gcc_static_rel\muParser_lib_muParser.o.d -MD -MP ../src/muParser.cpp
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Chase\Desktop\muparser_v2_0_0\muparser_v2_0_0\build>
The command appears to "step" through it's next function. I continue to type exit at the "prompt" and the command appears to continue stepping until it's done. However, after exiting completely, I can't see any results and it appears nothing's actually been done.
Also, this doesn't have anything to do with the command prompt. I even wrote a python script to cd into the directory and call make, and the output still displayed a windows-style command prompt - complete with the copyright Microsoft line etc., and waited for an input. I typed exit the same way until the process exited back to python.
Now, I might be going insane, but I'm really confused. Asking on the forums yielded no help, the only response is that "the windows build should be working."
Does anyone know what's going on???
I downloaded the muParser package and tried to build it. I got the same strange behaviour from make as you did. Then I realised I only had MSYS-make installed, not MinGW-make (the first one is intended for use in the MSYS shell, the second one for use in the Windows cmd shell).
Unfortunately, installing and using mingw32-make gave a different error, but googling that lead me to this page, where it was suggested to rename sh.exe in the MSYS directory. After doing that, running mingw32-make -f makefile.mingw succesfully built (the static version of) the library.
The other method you and shellter are using of running ./configure; make in the MSYS shell, also fails to build the example for me. It does build the dll version of the library in this case, instead of the static version; perhaps this is why the example fails to build.
(You might want to add a tag for 'make' or 'gmake', that should boost the number of eyes looking at your problem).
Looking at the makefile.mingw, I'm surprised to see statements like '-if not exist ..', that is .bat file syntax.
I ran ./configure ; make and it got past the error messages you mention, but I'm seeing a bunch of error messages like undefined reference to mu::ParserError: , so I'm probably missing libraries to make it work completely. I'll have to leave it at that, and hope that it helps you. Note that I didn't use make -f makefile.mingw. After using configure, make just picked up the newly created Makefile, and it worked (excepting the library problems ;-)
(When you say forums, did you mean the mingw forums? If not, try looking around here. The search functionality is pretty good.)
I hope this helps.