Bug Comment blocks #REM, #END not works when nested.

[zuibaf]

On the code below, when I nest comment blocks, cerberus not works correctly, this error ocurred: Error : #End without #If or #Rem
On the documentation, it says what comments blocks can be nesting.

Strict

#Rem
    Test   
#Rem
#End
#End

'-----------------------------------------------------------------
Function Main:Int()
    Return 0
End

 

[MikeHart]

It would never have came to me to nest comments. Anyway, as the docs say it should work, it is a bug then.

 

[dawlane]

It would never have came to me to nest comments. Anyway, as the docs say it should work, it is a bug then.

I would check one of the old bug reports and the ambiguity of #End and the issues I had trying to get the parse to work correctly the last time without breaking everything.

 

[dawlane]

@MikeHart
See if this quick change to preprocessor.cxs works.
It should ignore everything in a remark block apart from an #End. Nested #Rem/#End should work, providing that an #If/#Else block isn't terminated with a #End. It won't keep track of the #If/#Else blocks in any remark block, so there will be no tracing of conditional block lines, though rearranging the track and tracknesting before the continue check should fix it.
Scratch that. Fixed one issue and end up causing another.

 

[Wingnut]

I recognize this as I've used nested comments before as a way of testing and swapping out code.
Sometimes I left "dead" code like that too as it was a nice to have code around, especially if I go in the middle of a coding session and need to pick it up later.

But boy did it break when you least need it to. You ended up with "debugging" (well decommenting really) thousands of lines of code.
So nowadays changed my habits to use:

#If False
#Endif

..for testing code , but I really wish that the code would be grayed out in the IDE..

I think a good solution would be to do what the IDE already does when you select a range of lines and hit tab/shift+tab.
It's a simple but useful feature. If you were able to do the same when it comes to commenting / de-commenting lines, ppl would probably use it all the time.

 

[dawlane]

@MikeHart
The only way I can figure out how to deal with block comments and pre-processor conditionals within them is to enforce the use of #End strictly for block comments and an error message stating that conditionals should be terminated with #Endif.

I've attached file updates for modules/trans for testing.
New files here.

 

[zuibaf]

It would never have came to me to nest comments. Anyway, as the docs say it should work, it is a bug then.

I don't nest comments either, however, I was following the tutorial in the book: "Monkey Game Development: Beginner's Guide", then from chapter 3 onwards, I used the FantomEngine module, I downloaded it from github, but it was giving an error, so I went to analyze the code, there were nested comments. After deletes the innermost comment, everything worked normally.

 

[MikeHart]

It did? Wow, I don't even remember doing that.

 

[zuibaf]

@MikeHart
The only way I can figure out how to deal with block comments and pre-processor conditionals within them is to enforce the use of #End strictly for block comments and an error message stating that conditionals should be terminated with #Endif.

I've attached file updates for modules/trans for testing.

I did this:
I copy the 3 files to the folder transcc, I compile the file "transcc.cxs", this output the folder of name: "transcc.buildv<data_de_hoje>.
I did rename the folder transcc.build for another name, then, I get the folder generated before, ""transcc.buildv<data_de_hoje>", I rename for transcc.build.
Then, I executed "rebuildall.sh", then generated a new transcc_linux.
I fiz a few test, there is a new error:
All lines, after "#Rem" and before of "#End" are not exclude of preprocessing:

Strict

#ANOTHER_VALUE = 1

Function Main:Int()
    #Rem Another(0)
        Another(1)
        #Rem
            Another(2)
            #Rem
                Another(3)
            #End
        #End
    #End
   
    Print "Testing..."
    Return 0
End

Function Another:Int(valor:Int)
    Print "Novo valor: " + valor
    Return 0
End Function

Saída:

TRANS cerberus compiler V2022-03-20
Parsing...
Semanting...
Translating...
Building...
Novo valor: 1
Novo valor: 2
Novo valor: 3
Testing...
Done.

Let's see, the sentence "Another(0)" not executed, conformed it expected, but, the lines executed.

 

[dawlane]

I copy the 3 files to the folder transcc, I compile the file "transcc.cxs", this output the folder of name: "transcc.buildv<data_de_hoje>.
I did rename the folder transcc.build for another name, then, I get the folder generated before, ""transcc.buildv<data_de_hoje>", I rename for transcc.build.
Then, I executed "rebuildall.sh", then generated a new transcc_linux.
I fiz a few test, there is a new error:

There's no need to copy or rename directories, or run rebuildall.sh.
You can edit a few lines in cerberus/src/transcc/transcc.cxs to point to a test file for a debug build of transcc to run.
All you do is create a directory in cerberus/examples and create a test file inside and edit these lines in transcc.cxs.

' Debug transcc
#If CONFIG="debug"
    Const VERSION:="2022-03-20 (DEBUG)"
    Const TEST_PATH:="/examples/test"
    Const TEST_BUILD:="-run"
    Const TEST_CONFIG:="release"
    Const TEST_FILE:="test_file"
    Const TEST_TARGET:="C++_Tool"
 
    ' Comes in handy when needing to debug the parser.
    ' If DebugIsMainCXS(Toker.Path) DebugStop
    Function DebugIsMainCXS( path:String )
        If path.Contains( TEST_FILE+".cxs" ) Return True
        Return False
    End
#Else
    Const VERSION:="2022-03-20"
#Endif

You should restore all the original files and directories replaced or renamed to there originals and run rebuildall.sh

Attached the fix and updated the comments.
Before making changes to the files in cerberus/modules/trans, make back up copies of the files named in the zip archive before extracting and overwriting them.

 

[zuibaf]

I copied the three files to the "modules/trans" directory, ran "transcc" in the "debug" config, it ran the test file and passed correctly. However, when I run the "transcc" file in "release" mode, the following error appears:

/home/fabiuz/Downloads/cerberus/Cerberus-v2022-03-26_Linux/cerberus/src/transcc/transcc.buildv2022-03-26
TRANS cerberus compiler V2022-03-20
TRANS FAILED: Failed to open config file
TRANS FAILED: Error executing '"/home/fabiuz/Downloads/cerberus/Cerberus-v2022-03-26_Linux/cerberus/src/transcc/transcc.buildv2022-03-26/cpptool/main_linux"', return code=65280
Done.

As I said the test passed, however, the linux transcc of the "bin" folder remains the same.
So what I did was copy the "main_linux" file from the "transcc.buildv2022-03-26" directory directly to the cerberus "bin" directory, renamed it to "transcc_linux".

 

[dawlane]

Building the transcc sources in the IDE can only be executed when built in debug mode. For it to do this, the current transcc compiler uses the value in the CONFIG pre-processor variable to compile a debug binary with alternate paths to required files, such as config.linux.txt. This makes it possible to test and debug transcc without having to mess with the current Cerberus X installation.

Release build do not do this. Therefore they are treated the same as any other target where a executable file is created in the projects build directory. You then rename and move to where the file is required.

 

[zuibaf]

Ok.

 

[Dubbsta]

I recognize this as I've used nested comments before as a way of testing and swapping out code.
Sometimes I left "dead" code like that too as it was a nice to have code around, especially if I go in the middle of a coding session and need to pick it up later.

But boy did it break when you least need it to. You ended up with "debugging" (well decommenting really) thousands of lines of code.
So nowadays changed my habits to use:

#If False
#Endif

..for testing code , but I really wish that the code would be grayed out in the IDE..

I think a good solution would be to do what the IDE already does when you select a range of lines and hit tab/shift+tab.
It's a simple but useful feature. If you were able to do the same when it comes to commenting / de-commenting lines, ppl would probably use it all the time.

I recognize this as I've used nested comments before as a way of testing and swapping out code.
Sometimes I left "dead" code like that too as it was a nice to have code around, especially if I go in the middle of a coding session and need to pick it up later.

But boy did it break when you least need it to. You ended up with "debugging" (well decommenting really) thousands of lines of code.
So nowadays changed my habits to use:

#If False
#Endif

..for testing code , but I really wish that the code would be grayed out in the IDE..

I think a good solution would be to do what the IDE already does when you select a range of lines and hit tab/shift+tab.
It's a simple but useful feature. If you were able to do the same when it comes to commenting / de-commenting lines, ppl would probably use it all the time.

Is that the same as shift +e or control + e forget which one . That comments out blocks too

 

[Wingnut]

Is that the same as shift +e or control + e forget which one . That comments out blocks too

Wow I missed that one. It was ctrl + e (cmd + e on Apple) Thanks!