Input Error Handling Messages Don't Behave Properly

[mlesnick]

When opening up a random file in RIVET via the file open dialogue. Weird error messages appear.

You might have to try a few times before seeing buggy behavior. But it is definitely there.

EDIT: In fact, currently there are no error messages at all. Files of the incorrect format are simply ignored. It seems that some of Bryn's recent changes disabled the error messages. The first step is to re-enable that code.

[mlesnick]

Original comment by M L (GitHub: mlesnick):

---

I experimented with this on a new Mac in OSX Sierra. I still occasionally occasionally do not get a popup error message when selecting an incorrect file.

Thus this is not just a Mavericks error, as we may have hoped.

[mlesnick]

Original comment by M L (GitHub: mlesnick):

---

Hi Bryn, I tested this out, using commit 28035a7 in the master branch.

I don't see any change from the previous behavior.

As an additional clue I'll mention that within this issue, it seems that there is an inconsistency: if a correct file has previously been selected, then when this error happens, most often the file is not deselected, but sometimes it is.

[mlesnick]

Original comment by Bryn Keller (GitHub: xoltar):

---

Checked in a new fix in the neptune branch: 96faad4

Please let me know if this works better for you!

[mlesnick]

Original comment by Matthew Wright (GitHub: mlwright84):

---

I do not know why the text is cut off in the Qt dialog boxes in Mike's screenshots.

The dialog boxes seem to be fine in Linux -- e.g. if I select an improper file, I consistently see this:!

[mlesnick]

Original comment by M L (GitHub: mlesnick):

---

(message from a few hours ago that somehow never made it up here.)

I tested this. Good news and bad news: There are no chopped alert messages any longer. Bad news: The problem where no alert message pop-up appears at all is still present, and has become significantly more common.

[mlesnick]

Original comment by Bryn Keller (GitHub: xoltar):

---

Okay, another attempt is now in 9ce211a, which hopefully will work even when lines get chopped up during delivery.

[mlesnick]

Original comment by M L (GitHub: mlesnick):

---

BTW based on interacting with the software more, I expect that the error where the dialogue box doesn't appear at all is a limiting case of the general error where the full text doesn't get written to the box.

[mlesnick]

Original comment by M L (GitHub: mlesnick):

---

All of the errors I saw before still appear, though it seems to have taken longer for them to start popping up.

The file bifiltration1.txt in the data folder seems to give problems frequently for some reason. Did you try to open this?

[mlesnick]

Original comment by Bryn Keller (GitHub: xoltar):

---

I see. I think this is problem with either the OS or the version of Qt, since I have never seen this problem, no matter how many times I attempt to open files. It could be either that the string isn't getting fully written to the output stream before the console exits, or it could be that Qt is reporting a line is complete before it actually is. I added some extra code in 112d45c to try to force the error to get written out by the console completely before the program exits. Could you see if that helps at all?

[mlesnick]

Original comment by M L (GitHub: mlesnick):

---

BTW to be clear, the bugs are inconsistent. My testing strategy is to open files over and over, and only sometimes do I see problems. But it's not as if the problems are a rare event. They happen ~50% of the time.

[mlesnick]

Original comment by M L (GitHub: mlesnick):

---

QMake version 3.0 Using Qt version 5.5.0 in /Users/mlesnick/Qt/5.5/clang_64/lib

[mlesnick]

Original comment by Bryn Keller (GitHub: xoltar):

---

What about your Qt version? What does qmake -v print out, for instance?

[mlesnick]

Original comment by M L (GitHub: mlesnick):

---

10.9.5

[mlesnick]

Original comment by Bryn Keller (GitHub: xoltar):

---

Hmm. What version of Mac OS X are you seeing this on?

[mlesnick]

Original comment by M L (GitHub: mlesnick):

---

I have been following the directions to build in the latest version of the readme exactly each time, except that I don't create the folder "build" because it as already been created.

So the answer is yes. If there is something else I should try, please let me know.

[mlesnick]

Original comment by Bryn Keller (GitHub: xoltar):

---

Hi Mike, when you rebuilt this, did you also rebuild the console? I usually do something like:

(assuming I'm in the rivet folder already):

(cd build && make) && make

This will build the console and then (only if building the console is successful) build the viewer. The problem you're seeing looks like error messages not being fully written to the output stream before the console program ends, and I had put in some additional flush() calls to the console to try to deal with that problem.

[mlesnick]

Original comment by M L (GitHub: mlesnick):

---

Hi Bryn, The new dialogue box and line number is a very nice improvement, thanks. However, this update is still exhibiting bugs on OSX. Please see the new screenshots.

In addition, there are times when no dialogue box appears at all, and the software just ignores the file I tried to open. (I think only for bad input, not good input).

[mlesnick]

Original comment by Bryn Keller (GitHub: xoltar):

---

Fixed I think in 48d2e12. Now error messages should be consistent, and display in a dialog box rather than the label. Also I added line numbers when errors occur while parsing files, so e.g. data/bifiltration2.txt will give a line number when it runs into trouble.

[mlesnick]

Original comment by M L (GitHub: mlesnick):

---

BTW this is in the warning branch, the newest code. The figures show that the text is sometimes cut off.

It also seems that the error messages are not consistent. Sometimes it says "Error:" sometimes not. What is the intended behavior?

[mlesnick]

Original comment by M L (GitHub: mlesnick):

---

[mlesnick]

Original comment by M L (GitHub: mlesnick):

---

I think this issue is not resolved. I played around more and see that the behavior is still buggy and inconsistent. One may have to try several times to open different files before the problems appear.

[mlesnick]

Original comment by Bryn Keller (GitHub: xoltar):

---

Fixed in 6657048, message now says "Unsupported file type" rather than trying to also say what kind of file it is.

[mlesnick]

Original comment by M L (GitHub: mlesnick):

---

However, I no longer am seeing the message "Un" displayed now, as previously discussed in emails.