weird behaviour in remark

[rikky]

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.

[rikky]

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

[bigbass]

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

[rikky]

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.

[Pjot]

Apr 8, 2020 14:08:31 GMT 1 rikky said:

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

[alexfish]

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:

[Pjot]

Thanks Alex,

This is fixed in the latest bacon.lang syntax file.

BR
Peter