In Python one can say this:
python script.py
from the command line and receive script.py's output inlined. Is it possible to do this with Haskell's GHCi? Basically I'm wondering if there's a way to run a Haskell program from the command line without compiling and without the user entering the interpreter.
runghc is what you're looking for. From its manpage:
runghc is considered a non-interactive interpreter and part of The Glasgow
Haskell Compiler. runghc is a compiler that automatically runs its results at
the end.
Edit: Ubuntu provides a symlink called runhaskell, but it might not be standard.
Related
in the command prompt, I can use nvcc --version to check the CUDA information. Is that possible to wrap this command nvcc --version into a python script to be run by python. Thanks.
I suppose for simple cases like yours, you can use Python function os.system although it has been deprecated.
Official Python documentation wants you to use the subprocess module instead. See also PEP324.
Let me add that Stackoverflow and other forums have plenty of discussions about the merits and demerits of executing programs from Python in the first place, and which function to use.
I have a C++ program that starts two instances of a python program in separate processes. I have a problem in the python program which causes it to not to display any logging information. The python program instances communicate with the C++ program via Stdin and Stdout/Stderr. I want to, if possible, to run one instance of the program under the Pydev debugger since the C++ program is complaining about receiving invalid input from both of the python programs. The python program can do nothing without communication to the C++ program so running the python program in isolation does not help.
Because Stdin and Stdout are used for inter-process communication so I cannot use print() statements but must use python logging but the program seems to be crashing before anything can reach the log file. The python program was working before my last changes so the architecture is functioning OK.
Any suggestions?
My suggestion for debugging the Python program launched from the C++ program would be using the remote debugger feature:
http://www.pydev.org/manual_adv_remote_debugger.html
(that way you can add programatically start the debugger on the python code wherever you'd like without needing to do anything special to launch it).
I have a Scala program that is triggered from a shell script. I'd like to be able to run the program in eclipse in debug mode. Anybody knows how that can be done?
Thanks.
I'm not sure if there is a way to debug both together, but what you can do is run your script with the option -xv. So...
user#mypc$: bash -xv myscript other_args
That will show you the commands that are executed along with their parameters.
Then in Eclipse you can debug your Scala program normally and pass those parameters to it through the main method or run configuration.
Typically debuggers are language specific and won't be able to do both bash scripts and code in another language, but with this method, you should be able to figure out what's going on.
i have this issue (https://github.com/sbt/sbt/issues/562)
basically when I try to get a console it says:
[ERROR] Failed to construct terminal; falling back to unsupportedjava.lang.IllegalArgumentException: Invalid terminal type: jline.UnixTerminal
also you cant use backspace
you basically cannot use sbt in cygwin (in dos is fine but cygwin is a much nicer environment)
and have voiced my concern there
i have tried several workaround i found on the net but they are all for old releases and no use now
was just wondering if you know of any workaround?
thanks
The following works for me (mostly, see note at bottom):
Use the mintty shell. I believe this is the default shell for new cygwin installs but has been included as an alternative for a while. If mintty.exe exists in your <cygwin home>\bin folder then it's ready to use, else it can be installed through the typical cygwin package selection from the setup.exe.
Open a mintty window, right click anywhere, go to Options... -> Keys, and make sure Send Backspace as ^H is checked. This will allow the REPL to correctly interpret backspaces.
For just running the Scala REPL that should be all you need, but attempting to run sbt console can still produce that exception. To get past that, run sbt without any arguments to get to the sbt prompt. From there execute:
eval System.setProperty("jline.terminal", "scala.tools.jline.UnixTerminal")
then
console
or, as a single command (with both semi-colons being important):
; eval System.setProperty("jline.terminal", "scala.tools.jline.UnixTerminal") ; console
From what I can tell, this is caused at least in part by the Scala REPL and the sbt prompt using incompatible versions of JLine. In particular, it looks like the Scala REPL created their own wrappers around the library and are using that while sbt is using the JLine library directly.
Note
One limitation that I continue to run into is that the REPL wraps at column 80 even if the shell window has more horizontal space. Not only that, but when the REPL wraps like this it overwrites the same line rather than advancing to the next, and pulling long lines from history ends up pushing the cursor above the line you're actually editing.
I have a program that I'd like to debug with gdb via emacs. In order to run development versions of this program, I have a shell script that I can source that sets up the calling environment to see the right libraries, etc. What I can't sort out is how to ask emacs/gud to source this file before executing gdb.
I've tried using a command like "source env.sourceme && gdb my_program", but emacs complains that it doesn't know what "source" means. I guess it's not really running gdb in a shell, so these kinds of tricks won't work.
So, how can I convince gud/emacs/whatever to run gdb in my custom environment? I've got a hacky solution in place, but I feel like I must be missing something.
gdb has its own syntax for setting environment variables:
set environment varname [=value]
Instead of a shell script, write your variable definitions in a file using the above syntax, then source the file from a running gdb session. Note that this is not bash's built-in source command, but gdb's own, so naturally bash-style environment variable definitions will not work.
What's your hacky solution?
Why wouldn't you just have a wrapper script that sources env.sourceme and then run gdb?
#!/usr/bin/env bash
source env.sourceme
gdb -i=mi $1
You can modify the Emacs environment using setenv, either interactively (M-x setenv) or programmatically:
(setenv "FOOBAR" "whatever")
When you run gud-gdb, whatever you set using setenv will be passed to the gdb process.