InsideQC Forums

This error?



In theory that's probably the best that the error message can be, owing to the internal format of .dsp and .dsw files where line-endings are actually important.

Yes, this is the message. Welp, shame on me...
In my defense, when I searched the error on Google I was led to believe it was something more serious, and the only sane way to fix would be to recreate the projects from scratch.

In fairness that is totally understandable.

I have no idea what I did to realise it was just line-endings; it happened years ago, and while I've been aware of it for a long time, it never actually registered with me that others might not be.

Well atleast it was usefull to people not aware of this the fix is running unix2dos on the project files.
You can do that from msys cygwin msys2 or if you dont want those just snag the windows version from gnuwin32 (remember to get the dependencies for it as well).

I suppose Notepad++ could handle this, too.

I just open in Wordpad (I keep a shortcut to it in my SendTo menu) then save back; handles the job fine.

Strictly speaking VS 2008 should be able to detect this and handle it properly. It does it for .sln files OK, and does it for actual source files too, so it's probably a VS bug that it can't do it for old vc6 project files too. But at least it's easy to fix things up yourself once you know.

was not aware wordpad could convert the line endings nice to know
notepad++ can i found out, and vice versa besides supporting a wealth of document types.
Since i use git heavily myself i guess i got lucky most of the times since i mostly checkout the sources via git .

Parsing expressions like "6 + 7 * (9 * 8 + 3 ) + 4" sucks.

It's not super-horrible if you do some research into how expression trees work. Then it just becomes annoyingly horrible.

On the plus side: owning expression trees comes with a nice set of knowledge benefits. Even more fun if you write it such a way that you can backtrack any element to its text origin as-is for crystal-clear user-feedback instead of "gee, there was an error of [blah] on line X".

Extra fun if you mentally plan in advance for some optimizations like detecting constant parts of an expression if it support variables. Some of working on this felt like one the QuakeC parts of the engine and I admit I took a peek at the QuakeC compiler just to see if any quick and easy hint might be gleaned.

But really, parsing expressions is the kind of barrier that breaking down leads to "greater things".

Writing a parser from scratch? I would assume a recursive function based on discovery of open brackets and secondary recursion based on operator priority. Someone has probably written this in 12 lines of code Minus another 12 lines of warning and error messages.

When stumped, I increase granularity of warning, error, or debug messages (developer mode) as appropriate. Eventually it may reveal the underlying typo, syntax error or limitation. An example would be sending a string from a calling function that provides a name or other info to be reported in a warning message.

qbism wrote:Writing a parser from scratch? I would assume a recursive function based on discovery of open brackets and secondary recursion based on operator priority. Someone has probably written this in 12 lines of code Minus another 12 lines of warning and error messages.

Well, I'm not sure what a logical response to that is really. You have to use nodes to do it right and node up based on precedence. At least to do it right.

And then work up from the bottom. This also allows operator short circuiting and reduction to constants.

Then again, I am specifically interested in this from the compiler/optimization/speed angle.

Baker wrote:Well, I'm not sure what a logical response to that is really. You have to use nodes to do it right and node up based on precedence. At least to do it right.

Frankly I'm clueless, but interested. I had to look up nodes. Are the overhead and features of general language processing needed for math parsing? Such as the ability to revisit nodes. In terms of recursion, this project phrases it 'recursive decent style': https://github.com/jamesgregson/expression_parser

http://www.difranco.net/compsci/C_Opera ... _Table.htm

(That guy's code looks a little overly indirect to me instead of jumping right in --- operator actions could be handled by a switch statement instead of making a function for each one.)

Having to rebuild 99% of my packages whenever msys2 updates ... damn this is some time consuming stuff.