|
Post by rikky on Apr 7, 2020 21:30:21 GMT 1
Hello I'm using a fossil from a while ago. Did not update to the latest, for I'm lazy by nature. So maybe this post is already outdated. In that case I'm sorry. I've tested this /* remark */ thing. And there are a few un consistencies, it seems. for example /* blabla */ works /* blabla &*/ works /* blabla &\*/ works /* blabla & \*/ works /* blabla NL$ */ works /* blabla NL$ \*/ works But /* blabla NL$ & \*/ compiles, but the rest of your program is gone. /* blabla NL$ & \*/ PRINT "hallo" Does nothing. Neither does: /* blabla NL$ & */ So it has to do with the combination of NL$ and &, I think. Theoretically they both should be ignored, if I am not mistaken. Rik.
|
|
|
Post by rikky on Apr 8, 2020 7:28:07 GMT 1
I found one more: /* "1234567890abcdefghijklmnop" & \*/ PRINT "hallo" gives: Syntax error: could not parse line 4 in file '/home/pi/test.bac': "CONCAT__b2c__string_var(/* "1234567890abcdefghijklmnop" , \*/)" also : /* "1234567890abcdefghijklmnop" & */
but: /* "1234567890abcdefghijklmnop" & */ PRINT "hallo" compiles, bit the program is lost. The following compiles and runs nicely: /* "1234567890abcdefghijklmnop" & */ PRINT "hallo" But with this one, again the program is lost: /* "1234567890abcdefghijklmnop" & \ */ PRINT "hallo" So it is the &. And has nothing to do with the NL$. Rik
|
|
|
Post by bigbass on Apr 8, 2020 9:13:33 GMT 1
Hello Rik
before I offer some suggestions ================================================= you exposed a block quote parsing problem with concat & and a temp solution enclose it in (&) then it all will compile and run =================================================
a few suggestions
OPTION PARSE FALSE when mixing c or c++ commands in bacon which works well and will fix some of your examples
to be on the safe side of things just use ' comment on the bacon side of the code
Joe
|
|
|
Post by rikky on Apr 8, 2020 14:08:31 GMT 1
I don't know c c++ c+++ and so on. I'm just someone trying to do a bit of programming. But certainly not a professional, and probably never will be. Now I have encountered this problem it is not a problem anymore. I can avoid making this mistake in the future. but I know Peter is on the lookout for little glitches, and that's why I report this. And it is not a little glitch. I'll give an example: I use it for testing my little console editor that I am making. Which is a lot more complicated then I thought it would be. But I told you already, I am not a professional, I do other work for a living. so I have this test_text$ to test my editor. So that I don't have to type it every time again. Depending on where and what I want to test, the test_text$ changes. that leaves me with this kind of things in my program: /* test_text$ = "" & \ "1234567890abcdefghijklmnop" & \ "1234567890abcdefghijklmnop" & \ "1234567890abcdefghijklmnop" & \ "1234567890abcdefghijklmnop" & NL$ & \ "fff" & NL$ & \ "hhh" & NL$ & \ "aaa" & NL$ & \ "bbb" & NL$ & \ */ You get the picture I suppose. If then somewhere else there is another piece of block remark, then suddenly the program starts again after that remark, and it becomes a hell of a lot of work to find the 'bug' in the program. Anyway, thanks for helping out. Rik.
|
|
|
Post by Pjot on Apr 9, 2020 15:02:42 GMT 1
but I know Peter is on the lookout for little glitches, and that's why I report this. And it is not a little glitch. Thanks Rik! The problem is caused by the parser, which parses a whole line of code at once. It doesn't know that the line starts with "/*" so it will turn the '&' into a CONCAT$ function. It now is fixed in the latest beta in fossil. Thanks again, Peter
|
|
|
Post by alexfish on Apr 19, 2020 17:43:37 GMT 1
Hi Peter this one is perhaps slightly minor RE REM statements using latest bacon4 & bacongui-gtk + latest source 'bacon.lang' BR Alex screen-shot of HUG.bac Attachments:
|
|
|
Post by Pjot on Apr 20, 2020 8:24:21 GMT 1
Thanks Alex, This is fixed in the latest bacon.lang syntax file. BR Peter
|
|