When using Origen for test content generation, is there a standard in practice for logging text? I see in other examples 'ss' and 'cc' as well as places where 'puts' is used.
What is the proper usage for comments that should go into Origen generated test patterns and flow elements, comments that should print during generation, and comments that should only print when debug is on?
Generally puts should never be used except for temporary debugging. The convention in Origen applications is to keep logging as light as possible, this in reaction to many tools in this space which are overly verbose in their logging such that it becomes mostly ignored by users.
So only log to the terminal when you think it is really important by doing this:
Origen.log.info "Something important to tell the user!"
Most of the time, if the information is just for debug purposes, then use:
Origen.log.debug "Some debug help, the value of X is: #{x}"
In that case, then the terminal output will be clean, but you will see the debug info being output when ever you run Origen with the -d switch -verbose switch.
You can read more about other logging options here: http://origen-sdk.org/origen//guides/misc/logger
Additionally, if you are using Origen to generate a pattern, then the cc and ss methods are available.
cc "A low level comment"
Will appear in a pattern like this:
// A low level comment
For the main steps in a pattern you can use ss:
ss "A high level comment"
which will look more emphasized, like this:
//####################################################################
//# A high level comment
//####################################################################
For multi-line step comments, you can use this API:
step_comment do
cc "We are about to do this:"
cc " Blah: blah"
cc " Blah: blah"
end
Which would look like:
//####################################################################
//# We are about to do this:
//# Blah: blah
//# Blah: blah
//####################################################################
You can read more about how to document patterns here: http://origen-sdk.org/origen/guides/pattern/documenting/
Related
I started using fmt for printing recently. I really like the lib, fast, easy to use. But when I completed my conversion, there are ways that my program can run that will render with a bunch of additional newlines. It's not every case, so this will get a bit deep.
What I have is a compiler and a build manager. The build manager (picture Ninja, although this is a custom tool) launches compile processes, buffers the output, and prints it all at once. Both programs have been converted to use fmt. The key function being called is fmt::vprint(stream, format, args). When the build manager prints directly, things are fine. But when I'm reading the child process output, any \n in the data has been prefixed with \r. Windows Terminal will render that fine, but some shells (such as the Visual Studio output window) do not, and will show a bunch of extra newlines.
fmt is open source so I was able to hack on it a bunch and see what is different between what it did and what my program was doing originally. The crux is this:
namespace detail {
FMT_FUNC void print(std::FILE* f, string_view text) {
#ifdef _WIN32
auto fd = _fileno(f);
if (_isatty(fd)) {
detail::utf8_to_utf16 u16(string_view(text.data(), text.size()));
auto written = detail::dword();
if (detail::WriteConsoleW(reinterpret_cast<void*>(_get_osfhandle(fd)),
u16.c_str(), static_cast<uint32_t>(u16.size()),
&written, nullptr)) {
return;
}
// Fallback to fwrite on failure. It can happen if the output has been
// redirected to NUL.
}
#endif
detail::fwrite_fully(text.data(), 1, text.size(), f);
}
} // namespace detail
As a child process, the _isatty() function will come back with false, so we fall back to the fwrite() function, and that triggers the \r escaping. In my original program, I have an fwrite() fallback as well, but it only picks up if GetStdHandle(STD_OUTPUT_HANDLE) returns nullptr. In the child process case, there is still a console we can WriteFile() to.
The other side-effect I see happening is if I use the fmt way of injecting color, eg:
fmt::print(fmt::emphasis::bold | fg(fmt::color::red), "Elapsed time: {0:.2f} seconds", 1.23);
Again Windows Terminal renders it correctly, but in Visual Studio's output window this turns into a soup of garbage. The native way of doing it -- SetConsoleTextAttribute(console, FOREGROUND_RED | FOREGROUND_GREEN | FOREGROUND_INTENSITY);-- does not trigger that problem.
I tried hacking up the fmt source to be more like my original console printing code. The key difference was the _isatty() function. I suspect that's too broad of a question for the cases where console printing might fail.
\r is added because the file is opened in text mode. You could try (re)opening in binary mode or ignore \r on the read side.
There are a couple of answers for Perl 6 back in its Parrot days and they don't seem to work currently:
This is Rakudo version 2017.04.3 built on MoarVM version 2017.04-53-g66c6dda
implementing Perl 6.c.
The answer to Does perl6 enable “autoflush” by default? says it's enabled by default (but that was 2011).
Here's a program I was playing with:
$*ERR.say: "1. This is an error";
$*OUT.say: "2. This is standard out";
And its output, which is an unfortunate order:
2. This is standard out
1. This is an error
So maybe I need to turn it on. There's How could I disable autoflush? which mentions an autoflush method:
$*ERR.autoflush = True;
$*ERR.say: "1. This is an error";
$*OUT.say: "2. This is standard out";
But that doesn't work:
No such method 'autoflush' for invocant of type 'IO::Handle'
I guess I could fake this myself by making my IO class that flushes after every output. For what it's worth, it's the lack of this feature that prevented me from using Perl 6 for a particular task today.
As a secondary question, why doesn't Perl 6 have this now, especially when it looks like it used to have it? How would you persaude a Perl 5 person this isn't an issue?
There was an output refactory very recently. With my local version of rakudo i can't get it to give the wrong order any more (2017.06-173-ga209082 built on MoarVM version 2017.06-48-g4bc916e)
There's now a :buffer argument to io handles that you can set to a number (or pass it as :!buffer) that will control this.
I assume the default if the output isatty is to not buffer.
This might not have worked yet when you asked the question, but:
$*ERR.out-buffer = False;
$*ERR.say: "1. This is an error";
$*OUT.say: "2. This is standard out";
It's a bit hard to find, but it's documented here.
Works for me in Rakudo Star 2017.10.
Rakudo doesn't support autoflush (yet). There's a note in 5to6-perlvar under the $OUTPUT_AUTOFLUSH entry.
raiph posted a comment elsewhere with a #perl6 IRC log search showing that people keep recommending autoflush and some other people keep saying it's not implemented. Since it's not a documented method (although flush is), I suppose we'll have to live without for a bit.
If you're primarily interested in STDOUT and STDERR, the following seems to reopen them without buffering (auto-flushed):
$*OUT = $*OUT.open(:!buffer);
$*ERR = $*ERR.open(:!buffer);
This isn't thoroughly tested yet, and I'm surprised this works. It's a funny API that lets you re-open an open stream.
Is it possible to dump only trace_printk() outputs in trace file? I mean filter out all functions in function tracer (or any other tracer).
In general, you can switch options off inside of the options directory, /sys/kernel/debug/tracing/options. Use ls to display all toggle-able options.
# ls
annotate context-info funcgraph-abstime funcgraph-overhead func_stack_trace hex overwrite record-cmd sym-offset trace_printk
bin disable_on_free funcgraph-cpu funcgraph-overrun function-fork irq-info printk-msg-only sleep-time sym-userobj userstacktrace
blk_classic display-graph funcgraph-duration funcgraph-proc function-trace latency-format print-parent stacktrace test_nop_accept verbose
block event-fork funcgraph-irqs
Toggle options via echo, i.e.,
echo -n "1" > /sys/kernel/debug/tracing/options/trace_printk
If you are trying to filter out any output that was not produced by trace_printk(), you would likely need to ensure that trace_printk() is the only option set.
It's always good to check out the kernel documentation when in doubt. There's also a great lwn article that helped me out when I was first learning ftrace called Secrets of the Ftrace function tracer, which includes some sections about filtering in general.
For some who cannot get more informations from this thread...
Actually, if you use nop as an current_tracer, you will ignore all the trace except trace_printk.
do
echo nop > current_tracer
and run your kernel module or anything else which includes your trace_printk.
The journald of systemd supports kernel-style logging. So, the service can write on stderr the messages starting with "<6>", and they'll be parsed like info, "<4>" - warning.
But while developing the service it's launched outside of systemd. Is there any ready-to-use utilities to convert these numbers into readable colored strings? (it would be nice if that doesn't complicate the gdb workflow)
Don't want to roll my own.
There is no tool to convert the output but a simple sed run would do the magic.
As you said journal would strip off <x> token from the beginning of your log message and convert this to log level. What I would do is check for some env. variable in the code. For ex:
if (COLOR_OUTPUT_SET)
printf ("[ WARNING ] - Oh, snap\n");
else
printf ("<4> Oh, snap\n");
I've a configure.ac file containing lines like:
AC_DEFINE(CONF_XDISP, ":8", "X screen number")
These constants are used in the C source for setting compile defaults. I also have a configuration file conf/bumblebee.conf in which these defaults need to be set. I'm told that AC_SUBST can be used to get #CONF_XDISP# substituted for ":8" such that the below line:
VGL_DISPLAY=#CONF_XDISP#
becomes:
VGL_DISPLAY=":8"
Making an AC_SUBST line for each AC_DEFINE does not look the best way to me as it includes a lot duplication of lines. How can I combine these options, such that I can use something like AC_DEFINE_SUBST? Other ideas and suggestions to improve this are welcome too.
Thanks to thinton, I could cook up the below code:
# AC_DEFINE_SUBST(NAME, VALUE, DESCRIPTION)
# -----------------------------------------
AC_DEFUN([AC_DEFINE_SUBST], [
AC_DEFINE([$1], [$2], [$3])
AC_SUBST([$1], ['$2'])
])
For AC_DEFINE_SUBST(CONF_XDISP, ":8", "X screen number"), this generates a configure file containing:
$as_echo "#define CONF_XDISP \":8 \$PWD\"" >>confdefs.h
CONF_XDISP='":8"'
Related docs:
http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.68/html_node/Setting-Output-Variables.html
http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.68/html_node/Macro-Definitions.html
m4 is a macro language, after all, so something like
AC_DEFUN([AC_DEFINE_SUBST],
[AC_DEFINE($1,$2,$3)
AC_SUBST($1)])
should do the trick. You might have to fiddle with [ a little to get escaping right.