How do I command the Rascal Shell not to truncate my output if it's quite long - rascal

This seems like a pretty basic question to me, but I don't seem to be able to find the answer anywhere. I need to get the full output of a command in the Rascal shell, however, Rascal seems to truncate long outputs automatically. Is there any way to tell the shell to always show the full output for a given command.
Example:
rascal>calculateCodeDuplication("smallsql0.21_src")
list[list[loc]]: [
[
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1310,26,<34,0>,<34,26>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1494,56,<43,1>,<43,57>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1558,49,<46,1>,<48,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1616,44,<51,1>,<53,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1665,57,<55,1>,<57,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1731,51,<59,1>,<61,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1791,57,<63,1>,<66,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1853,65,<68,1>,<71,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1927,61,<74,1>,<77,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1993,56,<79,1>,<82,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2055,50,<84,1>,<86,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2114,54,<88,1>,<90,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2177,42,<92,1>,<94,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2248,7,<96,24>,<96,31>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2225,136,<96,1>,<101,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2390,8,<103,24>,<103,32>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2367,153,<103,1>,<107,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2526,54,<109,1>,<111,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2586,51,<113,1>,<115,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2671,16,<118,27>,<118,43>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2645,78,<118,1>,<120,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2731,49,<123,1>,<125,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2789,48,<128,1>,<130,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2846,48,<133,1>,<135,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2902,46,<138,1>,<140,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2955,72,<143,1>,<143,73>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(3118,19,<149,43>,<149,62>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(3041,227,<146,4>,<152,5>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1340,1931,<36,0>,<153,1>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(0,3273,<1,0>,<153,3>),
|java+compilationUnit:///src/smallsql/database/ExpressionFunctionLog.java|(1305,26,<33,0>,<33,26>),
|java+compilationUnit:///src/smallsql/database/ExpressionFunctionLog.java|(1418,51,<38,4>,<38,55>),
|java+compilationUnit:///src/smallsql/database/ExpressionFunctionLog.java|(1477,123,<40,4>,<43,5>),
|java+compilationUnit:///src/smallsql/database/ExpressionFunctionLog.java|(1337,266,<36,0>,<44,1>),
|java+compilationUnit:///src/smallsql/database/ExpressionFunctionLog.java|(0,1603,<1,0>,<44,1>),
|java+compilationUnit:///src/smallsql/junit/TestDBMetaData.java|(1298,23,<33,0>,<33,23>),
|java+compilationUnit:///src/smallsql/junit/TestDBMetaData.java|(1325,18,<35,...
(note that the console outputs cuts off in the middle of the line with ...)

There are a number of ways. Here are the two I use most frequently:
use iprintln or println from the IO module. The former does indentation which is nice for complex outputs. example: import IO; iprintln(calculateCodeDuplication("smallsql0.21_src")); The nice thing about this is that in the terminal values of loc type are hyperlinks
open an editor for the value using the util::ValueUI module (only in Eclipse), for example: import util::ValueUI; text(calculateCodeDuplication("smallsql0.21_src")); This will pop up an editor with the indented output value (nice to search in using CTRL+F, but the loc is not a hyperlink. Would love to have a contribution in that direction :-))
Caveat for the first one is that scrolling up and down in the Eclipse terminal is very slow on Mac's, and not really fast on Windows either.

Related

Sending IFS File to Outq Prints Line of "#" Symbols

I am attempting to send a file from IFS to an outq on our AS/400 system. Whenever I do, I get exactly what I send, as well as a line of "#" symbols of varying lengths appended to the end.
Here's the command I'm using:
qsh cmd('cat -c /path/test.txt | Rfile -wbQ -c "ovrprtf file(qprint)
outq(*LIBL/ABCD) devtype(*USERASCII) rplunprt(*no) splfname(test) hold(*no)"
qprint')
The contents of test.txt is just Hello World!
The output I get when I send the command is
Hello World!####################################################################
I have not found any posts online about a similar problem, and have tried changing values and looking for additional switches to get it to work. Nothing I'm doing seems to fix the issue.
Is there a command or switch that I am missing, or is something I have in there already causing this?
EDIT:
I found this documentation which is the first time I've seen this issue mentioned, but it's not very helpful:
“Messages for a Take Action command might consist of a long string of "at" symbols (#) in a pop-up message. (The Reflex automation Take Action command, which is configured in situations, does not have this problem.) A resolution for this problem is under construction. This problem might be resolved by the time of the product release. If you see this problem, contact IBM Software Support.”
The only differences are: 1) this is not a pop-up message, it's printed. 2) I don't believe we use Tivoli Monitoring, although I could be wrong.
Assuming we do use Tivoli Monitoring, what would the solution be? There's no additional documentation past that, and I am not a system administrator, so I can't really make the call to IBM Software Support myself. And assuming we DON'T use it, what else could cause this issue?
I get different results, yet similar. I created a test.txt with Windows Explorer, put in Hello, world!, saved it and tried the script. I got gibberish for the 'Hello, world!' and then the line of # symbols.
My system is 7.3 TR5, CCSID 37 (US English) and my IFS file is CCSID 1252 (Windows English). Results did not change if I used a stream file of CCSID 819 (US ASCII).
I didn't have any luck modifying Rfile switches.
I found that removing devtype(*userascii) produced printed output in plain English without the # symbols. Do you really need *USERASCII? I would think that would be more for a pre-formatted 'print-ready' file like Postscript or the like.
EDIT: some more things to try
I don't understand why *USERASCII is adding those # symbols; it looks like a translation issue.
I tried this and still got the extra ###... You might have to play with the TOCCSID() parameter. Although a failure, it did give me an idea: what if those # symbols are EBCDIC spaces being sent as-is to the *USERASCII print stream? All we'd need is a way to send only the number of bytes in the stream file, without any padding.
CRTPF FILE(QTEMP/PRTSTMF) RCDLEN(132)
CPY OBJ('/path/test.txt') TOOBJ('/qsys.lib/qtemp.lib/prtstmf.file/prtstmf.mbr') replace(*yes)
ovrprtf file(qprint) outq(*LIBL/prt3812) devtype(*USERASCII) rplunprt(*no) splfname(test) hold(*no)
cpyf prtstmf qprint
The data in QTEMP/PRTSTMF is in ASCII; DSPPFM shows that much. It also shows a bunch of spaces: after all, it is a fixed length file. My next step was to write an RPG program to read the stream file and print it, but Scott Klement already did that: http://www.scottklement.com/PrtStmf.zip
This works on my system:
ovrprtf file(qsysprt) outq(*LIBL/abcd) devtype(*USERASCII) rplunprt(*no) splfname(test) hold(*no)
prtstmf stmf('/path/test.txt') outq(abcd)

Send SystemVerilog $display to stderr

I am using Verilator to incorporate an algorithm written in SystemVerilog into an executable utility that manipulates I/O streams passed via stdin and stdout. Unfortunately, when I use the SystemVerilog $display() function, the output goes to stdout. I would like it to go to stderr so that stdout remains uncontaminated for my other purposes.
How can I make this happen?
Thanks to #toolic for pointing out the existence of $fdisplay(), which can be used thusly...
$fdisplay(STDERR,"hello world"); // also supports formatted arguments
IEEE Std 1800-2012 states that STDERR should be pre-opened, but it did not seem to be known to Verilator. A workaround for this is:
integer STDERR = 32'h8000_0002;
Alternatively, you can create a log file handle for use with $fdisplay() like so...
integer logfile;
initial begin
$system("echo 'initial at ['$(date)']'>>temp.log");
logfile = $fopen("temp.log","a"); // or open with "w" to start fresh
end
It might be nice if you could create a custom wrapper that works like $display but uses your selected file descriptor (without specifying it every time). Unfortunately, that doesn't seem to be possible within the language itself -- but maybe you can do it with the DPI, see DPI Display Functions (I haven't gotten this to work so far).

Help embedding FSI

Starting here - Embedding F# interactive - I've been trying to embed FSI in my application.
However, I'm getting weird stuff back from StandardOutput.
for example, in standard FSI, if I send this:
let a = 3;;
I get this back:
[empty line here]
val a : int = 3
[empty line here]
> |
(with Pipe representing the input position)
But if I send let a = 3;; to StandardInput, I get this back on StandardOutput:
>
val a : int = 3
|
Has anyone else tried this? Is there something I'm doing wrong, and if not is there any way to work around this? None of the things I've tried so far work, and before I try the 'worse' thing I can think of (set a timer after sending stuff, add the > myself on timeout), I'd like to know if there is a better way!
When embedding F# Interactive, Visual Studio uses the --fsi-server:<some value> parameter.
As far as I know, this does two things:
Changes the way output is printed (instead of printing >, it prints SERVER-PROMPT> on a separate line, so it should be easier to remove it from the output and detect state when input is expected)
It also starts some .NET Remoting channel that you can use to stop execution of commands in F# Interactive (e.g. if it runs into an infinite loop) and it can also provide some completion information.
The F# Interactive pad in MonoDevelop F# plugin uses the flag (see source code on GitHub). I think it works mostly right, but I believe it sometimes prints additional \n in the output.

Using pfccomp or pint to run Pascal-FC programs

I'm using the Pascal FC implementation for Windows Vista found on http://www-users.cs.york.ac.uk/burns/pf.html
I'm trying to run the dining philophers problem found on the link but I don't get how to make the compiler work.
Screenshot
In the screen shot, the program appears to be waiting for you to enter the name of the file to use for the compiler output. Enter a file name.
Better yet, use the pfc.bat command and let it choose the output names for you. The batch file will also run the program automatically after it has been compiled. At the command prompt, run the command like this:
C:\pascalfc-vista> pfc philchan.pas

#line and jump to line

Do any editors honer C #line directives with regards to goto line features?
Context:
I'm working on a code generator and need to jump to a line of the output but the line is specified relative to the the #line directives I'm adding.
I can drop them but then finding the input line is even a worse pain
If the editor is scriptable it should be possible to write a script to do the navigation. There might even be a Vim or Emacs script that already does something similar.
FWIW when I writing a lot of Bison/Flexx I wrote a Zeus Lua macro script that attempted to do something similar (i.e. move from input file to the corresponding line of the output file by search for the #line marker).
For any one that might be interested here is that particular macro script.
#line directives are normally inserted by the precompiler, not into source code, so editors won't usually honor that if the file extension is .c.
However, the normal file extension for post-compiled files is .i or .gch, so you might try using that and see what happens.
I've used the following in a header file occasionally to produce clickable items in
the VC6 and recent VS(2003+) compiler ouptut window.
Basically, this exploits the fact that items output in the compiler output
are essentially being parsed for "PATH(LINENUM): message".
This presumes on the Microsoft compiler's treatment of "pragma remind".
This isn't quite exactly what you asked... but it might be generally helpful
in arriving at something you can get the compiler to emit that some editors might honor.
// The following definitions will allow you to insert
// clickable items in the output stream of the Microsoft compiler.
// The error and warning variants will be reported by the
// IDE as actual warnings and errors... which means you can make
// them occur in the task list.
// In theory, the coding standards could be checked to some extent
// in this way and reminders that show up as warnings or even
// errors inserted...
#define strify0(X) #X
#define strify(X) strify0(X)
#define remind(S) message(__FILE__ "(" strify( __LINE__ ) ") : " S)
// example usage
#pragma remind("warning: fake warning")
#pragma remind("error: fake error")
I haven't tried it in a while but it should still work.
Use sed or a similar tool to translate the #lines to something else not interpreted by the compiler, so you get C error messages on the real line, but have a reference to the original input file nearby.

Resources