I use Sympy for some calculations and during debugging or after the script has run in want to inspect some variables. The IDE is Spyder, so i use its console. I think it is called IPython, but i am not sure about this.
As all the variables used within the script, they all remain available after the script stopped. I just write the name of a variable to the console and expect that the content of the variable is displayed.
This works nicely for "normal" variables. But when it comes to Sympy objects, i can see only garbage:
What am i doing wrong? Can i change this behavior? Can i make Spyder/IPython write the Sympy expressions using normal ASCII characters, It does not need to reformat the expressions in some not easy readably ASCII "art". If i need a nice representation of the expressions i can use a Jupyter notebook anyway.
I deactivated "Symbolic mathematics" in Preferences / IPython console / Advanced settings.
Related
I have a make project creating binaries using various back-ends…
→ C, C++, csharp, java… on linux using mono csharp compiler, gcc, etc…
if I choose a single back-end (example csharp) by open a XXX.cs file than the make-output-error parser working OK… this mean error-output is parsed proper and I can jump to the error right away…
if I choose the toplevel make… (open vim without file on a toplevel directory) than the make-output-error parser does not work properly.
I discovered that the vim errorformat variable has changed between 1. and 2.
and now my question: how I can tell vim to recognize the error-output from C,C++,CSharp… and Java during run of the toplevel make ?
Whatever filetype plugin you have for C# is probably changing the value of :help 'errorformat' to work with C# compilers while you are left with the default value when running your top level make which, I assume, outputs errors as-is, without any filtering.
In order for Vim to interpret correctly the potentially mixed output of all your compilers you could:
set errorformat to a value that would work with all those formats,
or add a step to your build process that unifies every native output format into a single format that Vim can interpret without effort.
First option, find the errorformat values used by every compiler and prepend them to the default value at startup:
set errorformat^=<efm for c#>
set errorformat^=<efm for cpp>
...
Second option, I've been thinking for many years about writing a program that would do just that but never found the time to even write a README.md. If such a thing doesn't exist you will have to sed and awk your way on your own I'm afraid.
Python 3.7, on Windows print does not work as expected for ANSI color codes until shell=True once in subprocess.call().
In the below links it appears to imply that the ANSI color codes should work using the "print" command out of the box.
How to print colour/color in python?
Print in terminal with colors using Python?
the second one mentions VT100 emulation... not sure what exactly that means. I am able to write a batch file that outputs the color fine so I would think (naively) that it should work the same way in Python.
However I am not able to use the ANSI color codes as it seems that the ESC character is being "commented out"(?) because for instance when I
print(u"\u001b[31mHelloWorld")
I am not able to see the colored output, as the ESC character seems to be necessary in Windows and prints in the python shell as "[?]" (a box with a question mark)
Is there something I am missing here?
I found myself an answer. As often happens I just did not look far enough.
the Colorama module can be installed with
py -m pip install colorama
and comes with a method definition at the root of the module called init
colorama.init()
This is a cross platform function in that it is only useful on windows (it saves the active Terminal state for reversal and writes the Terminal to preprocess ANSI codes), it does nothing for other operating systems.
I am thinking about implementing an even more lightweight solution using ctypes and setting the Interpret flags on the active terminal myself.
If you are interested in more information, see here:
https://learn.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences
Output Sequences
The following terminal sequences are intercepted by the console host when written into the output stream, if the ENABLE_VIRTUAL_TERMINAL_PROCESSING flag is set on the screen buffer handle using the SetConsoleMode flag. Note that the DISABLE_NEWLINE_AUTO_RETURN flag may also be useful in emulating the cursor positioning and scrolling behavior of other terminal emulators in relation to characters written to the final column in any row.
Emphasis mine.
I am new to Atom / Stack / Haskell and after a fair bit of hand wringing managed to get set up on my windows 10 box.
One thing I am still stumped on is finding a way to set up interactive evaluation from within Atom (like "debugging" in Leksah)?
I have installed the "Script" which looks promising but all I get is:
'ghc' is not recognized as an internal or external command,operable program or batch file.
I presume I need some kind of configuration but I can't work out what's required. I think need a way to pipe through to an open ghci console.
Is there a way of setting this up with "Script"or any similar package?
Thanks
John
as you checked for yourself the ide-haskell-repl atom-package should work here
I'm trying to make a bash script that behaves differently based on the terminal program that someone is using (Putty, mobaxterm, etc). Is there any way to retrieve this kind of information from a bash script?
I was searching around online but I was not able to find anything (or I'm just wording it incorrectly, which could be a distinct possibility).
thank you
You need to understand that these are terminal emulators. There is a simple, crude identification function for (most?) modern line terminals (now that's an oxymoron!) but it will return something like vt102 or xterm i.e. whatever the emulator is emulating; not the identity of the program performing this emulation. Incidentally, this is usually used when the session is initiated, and reflected in the value of the $TERM environment variable.
The common way to do this is the environment variable TERM. Try
echo $TERM
That should output the terminal emulator's type, indicating its capabilities. Often, though not always, the value of TERM will be the name of the terminal emulator. For example, xterm may set TERM to xterm, or to xterm-color, depending on configuration.
Note that the user can change this variable, so it may contain something completely different.
That said, if you want to do fancy things with the terminal from a script, you don't need to build support for different terminals by hand. There are various libraries that offer all the usual functions (clear terminal, resize window, change font etc.). The most popular one is terminfo; there are various packages that build on terminfo.
How can you set a string to be used instead of standard input? For example, when running the latex command in Unix it will always find some trivial errors, to skip through all errors you have to enter "r" into the command line (I now know that with latex specifically you can use -interactionmode nonstopmode, but is there a more general solution to do this?)
Is there anyway to specify that this should be done automatically? I tried redirecting standard input to read from a file containing "r\n", but this didn't work.
How can I achieve this?
Not all applications that need input can be satisfied with their stdin redirected.
This is because the app can call the isatty C function (if written in C, or some equivalent call for other languages) to determine if the input come from a tty or not.
In such situation, there is a valuable tool to use, and this is expect.
latex --interaction=MODE
where MODE is one of:
errorstopmode: stop at every error and ask for input
scrollmode: scroll over non-fatal errors, but stop at fatal errors (such as "file not found")
nonstopmode: scroll over non-fatal errors, abort at fatal errors
batchmode: like nonstopmode, but don't show messaes at the terminal
For interactive use, errorstopmode (the default) is fine, for non-interactive use, nonstopmode and batchmode are better.
But beware, there are no trivial errors: all errors must be fixed, and all warnings should be fixed if possible.
Redirecting stdin works without problems here:
/tmp $ tex '\undefined\end' <<< r
This is TeX, Version 3.1415926 (TeX Live 2010)
! Undefined control sequence.
<*> \undefined
\end
? OK, entering \nonstopmode...
(see the transcript file for additional information)
No pages of output.
Transcript written on texput.log.
You've got two plausible answers detailing the way to handle Latex specifically. One comment indicates that you need a more general answer.
Most usually, the tool recommended for the general solution is 'expect'. It arranges for the command to have a pseudo-tty connected for input and output, and the command interacts with the pseudo-tty just as it would your real terminal. You tell 'expect' to send certain strings and expect certain other strings, with conditional code and regular expressions to help you do so.
Expect is built using Tcl/Tk. There are alternative implementations for other languages; Perl has an Expect module, for example.
From the man page:
-interaction mode
Sets the interaction mode. The mode can be either batchmode, nonstopmode, scrollmode, and errorstopmode. The meaning of these modes is the same as that of the corresponding \commands.
Looks like -interaction nonstopmode might help you.