While using DPI in SystemVerilog I faced an issue to redirect stdout of C side into stdout of SystemVerilog to get all log writes in one place (In my case printf from C were displayed in terminal but not seemed in log file from EDA).
I know the 100% works solution it is export function from SV side and use it in C to print, but it does not seem to me clever.
I tried to use some sort of redirection using reopen functions to changed address stdout var points to (as far as I understand the stdout it is an address for program to write into), but eventually it redirects all logging into this stdout including SystemVerilog log.
What is a better way to keep all logs in one stream?
Maybe there is a way to get C know the IDE stdout?
The answer had been given by https://stackoverflow.com/users/1143850/serge
Use vpi_print function from C side. The vpi_print will put its output into the same stream as EDI does
Related
I have a custom nagios plugin which is written in Perl. For complicated political reasons I am required to hide the source code of this plugin. The only way I found to do this was by using perlc (http://marginalhacks.com/Hacks/perlc).
In the words of author:
"Takes a single perl script, converts the block using a simple encoding with an optionally defined key. The script is decoded at runtime and fed to the perl library, to avoid it getting in the hands of the user."
The problem I am getting is that Nagios shows "No output returned from plugin" when I used the compiled version of the plugin. The raw perl source works just fine.
After debugging for a while I narrowed the problem down to using exit in perl. I.e
This works fine when compiled.
print "OK: Everything is working fine.\n";
This however does not work and results in ""No output returned from plugin"
print "OK: Everything is working fine.\n";
exit 1;
It doesn't matter how I exit (0 1 2 or 3) I still get the same problem.
According to the cross-posted PerlMonks thread, the issue was resolved by enabling autoflushing:
$| = 1;
From perlvar:
HANDLE->autoflush( EXPR )
$OUTPUT_AUTOFLUSH
$|
If set to nonzero, forces a flush right away and after every write or
print on the currently selected output channel. Default is 0
(regardless of whether the channel is really buffered by the system or
not; $| tells you only whether you've asked Perl explicitly to flush
after each write). STDOUT will typically be line buffered if output is
to the terminal and block buffered otherwise. Setting this variable is
useful primarily when you are outputting to a pipe or socket, such as
when you are running a Perl program under rsh and want to see the
output as it's happening.
See the article Suffering from Buffering? for more details.
So I am trying run a perl debugger inside another perl debugger. I keep readin tty in perl is the solution. Can someone explain to me what tty means ( is it terminal type?) and how is it useful? This is where I read it:
http://search.cpan.org/~rjbs/perl-5.18.0/lib/perl5db.pl#$CreateTTY
The reason I am trying to use tty is because of this question I asked:
Pass argument to perl file in debugger and set breakpoint in file executed by system
Thanks to all the ones who answer, the more you guys tell me what it is, better the idea I get :)
TTY (short for teletype) is basically a special input or output filehandle that connects to the terminal - namely, user input. For nitty gritty details, see:
Unix.SE in-depth answer on TTYs
Text Terminal HOWTO
This is what you need to know for starters (hard to say more since you didn't explain what you need to do with a TTY):
On Unix, it typically maps to /dev/tty device or similar
You can test for it using -t in Perl
As far as debugger, 2 things need to be known at least (if you intend to play with the TTY, the last paragraph is the most important). All data is near-quoted from perldoc perldebug
p expr prints to $DB::OUT filehandle (NOT STDOUT), which in turn is open to /dev/tty.
I think this may be controlled by LineInfo option from PERLDB_OPTS but never played with it so not sure.
Can be affected by the following $ENV{PERLDB_OPTS} options:
TTY - The TTY to use for debugging I/O.
noTTY - If set, the debugger goes into NonStop mode and will not connect to a TTY. If interrupted (or if control goes to the debugger via explicit setting of $DB::signal or $DB::single from the Perl script), it connects to a TTY specified in the TTY option at startup, or to a tty found at runtime using the Term::Rendezvous module of your choice.
This module should implement a method named new that returns an object with two methods: IN and OUT . These should return filehandles to use for debugging input and output correspondingly. The new method should inspect an argument containing the value of $ENV{PERLDB_NOTTY} at startup, or "$ENV{HOME}/.perldbtty$$" otherwise. This file is not inspected for proper ownership, so security hazards are theoretically possible.
Every time when I finish running a matlab code collection on command line, when I exit matlab, the standard output just gets messed. I can still use the terminal window, but whatever I typed won't show up on the screen, leaving me either type with my eyes blind, or open up a new terminal and excessively cd to the old place.
This happens every single time when I use make to run a matlab collection, and since I'm working a lot on this, it turns out to be very annoying. Does anyone know what's the problem here and how should I fix it?
As was pointed out in the comments, the makescript is probably dumping "bad" characters to the terminal. You could prevent this (but possibly lose useful information) by redirecting the output - instead of sending it to the terminal window, you can send it to a file, or even /dev/null ("the great bit bucket in the sky").
The underlying problem, however, is that your makefile is even sending these characters to the terminal in the first place. I would recommend that you pipe the output to a file with something like make > myDump.txt, then examine the resulting file to see what is going on, and where in your makefile the problem is created. It is possible that you will still be getting some output when you do this - that's because by default > redirects stdout only, and not stderr - a second output stream used for error messages. You can redirect both to a file with make 2>&1 myDump.txt.
You have already seen the recommendation to use stty sane to restore the status of the terminal - I am repeating it here in case someone only looks at answers, and not at comments; but I don't take credit for it :-).
Have a look here
Can Perl method calls be intercepted?
It shows how to rewrite the symbol table for a simple sub. The print command can take a list I believe, so what is the right way to intercept/rewrite it? I wish to get a program to delay printing while maintaining the same signature, and instead push the output into an array, pre-sort it, then regurgitate all the output at the very end.
Intercepting print itself isn't the way to go -- it has a number of operating modes, including writing to a file or socket. Instead, take a look at the select function, which can be used to change the default filehandle which print will write to.
Also, look at the concept of a "tied" IO handle, as used by IO::Capture.
I have simple web-form with a little js script that sends form values to a text box. This combined value becomes a database query.
This will be sendt to dsmadmc (TSM administrative command line).
How can I use perl to keep the dsmadmc process open for consecutive input/output without the dsmadmc process closing between each input command sent?
And how can I capture the output - this is to be sent back to the same web page, in a separate div.
Any thought, anyone?
Probably IPC::Open2 could help. It allows to read/write to/from both input and output of an external process.
Beware of deadlocks though (i.e. situations where both your code and the app wait for their counterpart). You might want to use IO::Select to handle that.
P.S. I don't know how these modules behave on windows (.exe?..), but from a quick google search it looks like they are compatible.