What will the following tcl code do? - if-statement

I have the following line:
if {[catch {exec fgrep E- $log_file} errors]} {
set errors ""
}
What does this do?
Does the catch command puts all the lines found by fgrep in the log file into errors?
Will it put there only errors thrown by fgrep, for example if the file doesn't exist?
When will the if be taken, and when it won't be taken?

Let's deconstruct your code from the inside out.
exec fgrep E- $log_file
This runs fgrep E- against the file whose name is stored in the variable log_file. It produces a Tcl error if there is a syntactic problem with the exec (there isn't, thankfully), a syntactic problem with the fgrep program (looks OK to me), if $log_file doesn't exist, or if there were no matches. If there were no errors, it returns the output of the grepping, warts and all.
catch {exec fgrep E- $log_file} errors
This runs the code from above in an environment which traps errors, and returns whether an error occurred (formally, it returns 0 when there was no error, 1 when there was an error, and other codes for other less-common types of exceptional return which don't happen in this case). The normal result of the exec is stored in the errors variable if no error happened, and the error message is stored in errors if there was an error. Note that it's possible to distinguish between the types of errors through the global errorCode variable, but you don't do that (and it's often not necessary).
if {[catch {exec fgrep E- $log_file} errors]} {
set errors ""
}
This uses the result of the catch above as a boolean: if an error happened, it evaluates the body (which sets the errors variable to the empty string), and otherwise it does nothing extra.
Summary
Overall, your code sets errors to the newline-separated lines found in the file in log_file, and sets errors to the empty string otherwise.

Yes, you're right. If the command exec fgrep E- $log_file returns any errors, they will be caught and the variable errors will be assigned the error message. In this case it is the results of the exec command that is being caught. Looking at the manual you can see the particularities of how exec returns an error. Your code example immediately over-writes the errors variable. I should add that errors is a slightly misleading choice of variable name - results would be better, as the variable gets set whether or not an error occurs.
So the if will be taken if the catch finds an error. I couldn't comment on the question regarding fgrep not finding a file. It's not clear to me if that is an error or a normal situation.

Related

sys.exit('message') isn't printing in IDLE

In python IDLE it won't print the specified error message when using sys.exit('') but in cmd.exe it will. Why?
import sys
try:
print fail
except:
sys.exit("This is an example of an error message")
Your error message is printed to stderr which is not shown in IDLE because it's run in a subprocess (see this report of your observation and this related answer). So IDLE writes it on the terminal used to start IDLE.
The documentation states about the arguments of sys.exit:
Some systems have a convention for assigning specific meanings to
specific exit codes, but these are generally underdeveloped; Unix
programs generally use 2 for command line syntax errors and 1 for all
other kind of errors. If another type of object is passed, None is
equivalent to passing zero, and any other object is printed to stderr
and results in an exit code of 1. In particular, sys.exit("some error
message") is a quick way to exit a program when an error occurs.
So, the safest way is to only pass error codes and use an additional print (or calling a custom exit-function that gives the user an analysis of what happened).

Scilab compilation "cannot allocate this quantity of memory"

I am facing issues with memory allocation in Scilab after compiling.
I am compiling on a Red Hat on ppc64 (POWER8). Stack limits are already set to unlimited (ulimit -s unlimited). The ./configure script (with several options I am not showing here) runs successfully, but the make all fails and stops. When it stops, it is stuck at the Scilab command prompt with this message:
./bin/scilab-cli -ns -noatomsautoload -f modules/functions/scripts/buildmacros/buildmacros.sce
stacksize(5000000);
!--error 10001
stacksize: Cannot allocate memory.
%s: Cannot allocate this quantity of memory.
at line 27 of exec file called by :
exec('modules/functions/scripts/buildmacros/buildmacros.sce',-1)
-->
I have investigated a bit, and that error message seems to be called of course at line 00027 in buildmatros.sce, where the function stacksize(5000000) is called.
This function is defined in:
scilab-5.5.1/modules/core/sci_gateway/c/sci_stacksize.c
I found a version of the file at this page: http://doxygen.scilab.org/master_wg/d5/dfb/sci__stacksize_8c_source.html.
The condition that is FALSE and that triggers the message seems to me to show up at line 00295.
Inside that file, you see that error is displayed whenever the stacksize given as input is LARGER than what is returned by the method get_max_memory_for_scilab_stack() from the class:
scilab-5.5.1/modules/core/src/c/stackinfo.c
Again I found a version online at the following page:
http://doxygen.scilab.org/master_wg/dd/dfb/stackinfo_8h.html#afbd65a57df45bed9445a7393a4558395
The Method is declared from line 109.
It seems to invoke a variable called MAXLONG, which is however NEVER explicitly declared! As you see, it is declared several times (line 00019, 00035, 00043, 00050), but all lines are commented! [correction: the lines are NOT commented, it was my false understanding of # being a comment sign, but it's not]
So my guess is: MAXLONG is not declared, so the function does not return a value (or it returns 0) and therefore the error message is triggered because the stacksize given as input is higher than 0 or NULL or N/A.
My questions are then:
Why are all lines commented where MAXLONG is defined?
Where does MAXLONG originate from? Is it something passed from the kernel?
How can I solve the problem?
Thanks!
PS - I tried to uncomment the line in buildmacros, and it compiled and installed without issues. However, when I started scilab-cli, it displayed the same message again.
Edit after further investigation:
After further investigation, I found out that what I thought were the comments are indeed instructions for the compiler... but I kept those errors of mine, so that the answer to my question is understandable.
Here are my new points.
In Scilab I noticed that by giving an input stacksize out of bounds, the same method get_max_memory_for_scilab_stack() is invoked, to get the upper bound. The lower bound I've seen it's defined by default.
-->stacksize(1)
!--error 1504
stacksize: Out of bounds value. Not in [180000,268435454].
Also the stacksize used seems fine:
-->stacksize()
ans =
7999994. 332.
However, when trying to give such value an input inbetween, it fails.
-->stacksize(1)
!--error 1504
stacksize: Out of bounds value. Not in [180000,268435454].
It seems to invoke a variable called MAXLONG
It's not a variable, but a pre-processor macro.
Why are all lines commented where MAXLONG is defined?
You should ask that from the person who commented the lines. They're not commented in scilab-5.5.1 that's online.
Where does MAXLONG originate from? Is it something passed from the kernel?
It's defined in the file scilab-5.5.1/modules/core/src/c/stackinfo.c. It's defined to the same value as LONG_MAX which is defined by the standard c library (<limits.h> header). If the macro is not supplied by the standard library, then it's defined to some other, platform specific value.
How can I solve the problem?
If your problem originates from the lack of definition for MAXLONG, then you must define it. One way going about it is to uncomment the lines that define it. Or re-download the original sources since yours don't appear to match with the official ones.

Error message : "Assertion 't = find_next_time_event( m )' failed at pulse/mainloop.c" ?...(C++)

Ok so I'm using CodeBlocks for programming in C++ . I have so "random" (it doesn't happen everytime, and I'm not able to predict when it happens) error message which makes the program crash, it says :
Assertion 't = find_next_time_event( m )' failed at pulse/mainloop.c:721,
function calc_next_timeout() . Aborting .
Aborted (core dumped) .
Process returned 134 (0x86)
Core dumped is when I should not have deleted some pointer, am I right?
The thing I don't understand is what is before "Aborted, core dumepd" . Can it guide me to which kind of error I made ?
Or is it a problem with CodeBlocks (I doubt it , but that could be great :p)
*I don't put code here because I just want information about what could theorically create this kind of message . Then I'll search and if I've problems with finding the error(s), I'll put some code here ;) *
It is telling you that an assertion failed on line 721 of the file pulse/mainloop.c that is part of your source code.
An assertion is typically placed to check invariants or preconditions/postconditions. Taking a precondition as an example, this is saying "this expression has to be true in order for the code below to work correctly".
By inspecting the condition (at line 721 of mainloop.c) and understanding why it was not true in your case, you should be able to find an error in your code that lead to the failed assertion.
This isn't really a solution but this issue actually has to do with PulseAudio. I assume OP is using Linux, possibly Ubuntu, which is when this error occurs. I sometimes get the same thing when using a program written in Python. There is a noted bug about this issue in the PulseAudio Launchpad bugs.

Silent Charniak Parse when it can not parse sentence - It does not work

I am using charniak parser - bllip-parser for chunking output. Sometimes parser can not parse sentence. As README, there is one argument '-S' which tells parser to remain silent when it can not parse any sentence and it just goes to next sentence. But using this argument, parser does not go to next sentence. It still throws exception.
My input to parser is :
./parseIt, -l400, -K, -t4, -S, -EInputTagFile.txt, ../DATA/EN/, InputTextFile.txt
Output of this command (error) :
Warning [parseIt.C:266] Sentence 4: Parse failed from 0, inf or nan probabililty -- reparsing without POS constraints
Warning [ChartBase.C:172] Sentence 4: estimating the counts on a zero-probability sentence
parseIt: MeChart.C:105: Bst& MeChart::findMapParse(): Assertion `s' failed.
Aborted (core dumped)
What is wrong with '-S' argument ? Any suggestions ?
The warnings were due to a bug and should be fixed now. See the GitHub ticket.
The parser shouldn't be run in multithreaded mode (it's not really threadsafe) which I suspect is the source of the assertion failure and subsequent abort().

Strange output and branch warning when compiling

I compile a fortran 77 code using gfortran and get the following error:
10 open (23,file=outfile,status='old',access='append',err=10)
1
Warning: Branch at (1) may result in an infinite loop
This happens several times.
One of the output files looks like the following:
^L6a10È <90> ) &<9b>LÓLÓLÕ<91><90> <90> <90> È <8e><9b>LÓLÓLÕ<93>2
!MERCURY ¢¤õ/!ô<8a><8a><90> ÿ<90> ÿ<90> ÿÌÖÏ©ü}M<91>
"VENUS «}>±{©±<8b><90> ÿ<90> ÿ<90> ÿʺ93¿<8d>d<91>
However, it should just look like a table of text.
Any ideas?
Your line of code
10 open (23,file=outfile,status='old',access='append',err=10)
specifies that the open statement should transfer control to itself (label 10) in case an error is encountered, so any error could trigger an infinite loop. It also suppresses the output of error messages. If you want to just check for an error status, I would suggest using the iostat and/or iomsg (Fortran 2003) arguments:
open (23, file=outfile, status='old', access='append', iostat=ios, iomsg=str)
Here ios is an integer that will be zero if no errors occur and nonzero otherwise, and str is a character variable that will record the corresponding error message.
The err= argument in your open statement specifies a statement label to branch to should the open fail for some reason. Your code specifies a branch to the line labelled 10 which happens to be the line containing the open statement. This is probably not a good idea; a better idea would be to branch to a line which deals gracefully with an error from the open statement.
The warning from gfortran is spot on.
As to the apparent garbage in your output file, without sight of the code you use to write the garbage (or what you think are pearls perhaps) it's very difficult to diagnose and fix that problem.