I'm currently working my way through Real World Ocaml and I got stuck running the OCaml "corebuild" compiled version of sum.ml:
$ ./sum.native
1
2
3
Uncaught exception:
(Invalid_argument "Float.of_string ")
Raised at file "pervasives.ml", line 31, characters 25-45
Called from file "sum.ml", line 7, characters 44-61
Called from file "sum.ml", line 10, characters 24-46
What am I doing wrong?
Thank you!
When I try to recreate your reported error, I don't see it. Things work fine and I get the answer of 6.0. Possibly I'm using a different version of Core.
Update
The problem occurs if you type an extra newline after the last number. Float.of_string fails when the input string is empty. I think that's what you're seeing because there is an empty line between the last number and the error report. If you type ^D to terminate the input, there's no empty line.
Related
I add a break point in Visual Studio 2015, with an action to output a string to Output Window. There will be an auto-added line break at the end. Problem is, my previous output message(which is not output by break point) has no line break.
So I want to add new line character at the beginning of my string, to avoid it messing up with my previous message. I tried to add \n, but the \n outputs as it is, without being escaped.
How to add a new line character in break point's action?
Here are four things for you to try:
You can produce a line break using the debugger expression {"\n",s8b} which makes use of the C++ debugger format specifier s8b (unquoted 8-bit string).
Here's an example with a two-line message First{"\n",s8b}Second:
(Other than that, I am not aware of any other way to include line breaks in the message. While there are ways to enter a multi-line message (by entering line break characters' Unicode code points using the numpad), Visual Studio will just throw away everything but the first text line entered.)
Just before your current breakpoint, add an additional breakpoint with a very short action message (a dot or comma) in order to get an additional line break before your real message.
If you're on Windows (which appears likely, given Visual Studio), you can send a message to the debugger using the Windows API function OutputDebugString. This is the currently suggested solution to the SO question, "How do I print to the debug output window in a Win32 app?"
Write a message to clog: std::clog << message << std::endl;.
In Addition to the answer from stakx that matches the original question for debugging C++ applications, I would like to add a character sequence that instead works for debugging .NET applications:
{"\n",nq}
The C++ sequence would otherwise result in this error message: 's8b' is not a valid format specifier
I am using REPL.it to run Python for my homework. When typing in and running this line of code:
# print "This will not run"
I get an unexpected EOF error:
Traceback (most recent call last):
File "python", line 1
# print "This will not run"
^
SyntaxError: unexpected EOF while parsing
This is an issue with REPL.it, not with Python. I am not sure what the internals of that interpreter are, but it appears that REPL.it will not allow a comment as the first line of code if there is no other code. To illustrate, try the following:
foo = 1
# print "This will not run"
The interpreter should spit out None instead of raising an error. It seems that it also works to have a comment on the first line and an empty line (or a line with code) as the second line, but running a file in this app that consists of only a single comment line does not seem to work.
If you have access to Python on your computer (which you do by default if you are on Mac OSX or Linux), then I would suggest trying your examples in a real Python interpreter. Otherwise, you might see some unexpected results, as I assume that repl.it is not a full-featured interpreter (as indicated by the syntax error).
It means Python is surprised that that the code ended without being finished. For your example, you didn't write any code, just a comment, without a blank line on the bottom?
Try print "This will not run" if that's the ONLY line of code in your file.
The python-interpreter is looking for code it shall execute but finds none, as the line you try to run is uncommented (by the # in the beginning).
Because it found no code to evaluate it makes some noise.
Remove the # and it will work...
I have a file with 16,900,000 lines, each line contains 10 numbers (mix of int and floats). I'm trying to read this file line by line, modify each line slightly, and write to a series of new files. The code below works on a laptop running Windows Visa, but when I run it on a desktop running Windows 7, the output file does not contain all the data from the input file. The number of lines in the output file varies from 2500 to 40,000.
I've commented out all of the processing, and writing to files, and just write every 100th line to cout, the last line to print isn't the last line of the file.
// skipping code prior to the loop
// only including minimal code that reproduces the problem
ifstream infile((srcdir+filename).c_str());
string line;
int lcount=0;
while(getline(infile,line)){
if(line.find("#")==string::npos){
lcount++;
if(lcount%100==0){
printf("Generating tiles for %s: %d lines processed\n",filename.c_str(),lcount);
}
}
}
Questions:
Is there a maximum buffer size that I might be overflowing?
Can anyone see a problem with my code?
Is there any reason this would work fine on Windows Vista, but not on Windows 7?
In your question there is very little information. But I will put here my guesses:
I don't think lcount is in being incremented at the correct place in code. It get incremented only if '#' is not in the line (I'm guessing this is some sort of comment). But a line starting (o containing) '#' has to be counted too. So your code should be:
while(getline(infile,line)){
lcount++; // Increment every time.
if(line.find("#")==string::npos){
if(lcount%100==0){
printf("Generating tiles for %s: %d lines processed\n",filename.c_str(),lcount);
}
}
}
On the other hand, you should activate isftream exceptions in order to see whats going on, see here how to doit.
While trying to create a minimal full program that would reproduce the problem, I found the culprit.
I'm trying to secure the executable with the keylock dongle that my company is using. When I removed the check for the dongle, the entire file was read.
Not sure if this is an appropriate question, but just recently I've noticed that when I run a C++ program in the terminal when it exits it has a % sign after the last output. For example a hello world program says "hello world%". What is this and how do I get rid of it? I'm on OS X, shell is zsh. Unless I am crazy it has never done this until now.
There are two possibilities that I can think of off hand:
1) You aren't printing a carriage return, so the % prompt appears at the end of the printed text instead of on the next line. (Is the % your standard prompt in the shell?)
2) You are printing past the end of a buffer and getting a random character as a result.
I'd guess #1 based on what you describe, but both could cause the behavior.
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.