• Dear Cerberus X User!

    As we prepare to transition the forum ownership from Mike to Phil (TripleHead GmbH), we need your explicit consent to transfer your user data in accordance with our amended Terms and Rules in order to be compliant with data protection laws.

    Important: If you accept the amended Terms and Rules, you agree to the transfer of your user data to the future forum owner!

    Please read the new Terms and Rules below, check the box to agree, and click "Accept" to continue enjoying your Cerberus X Forum experience. The deadline for consent is April 5, 2024.

    Do not accept the amended Terms and Rules if you do not wish your personal data to be transferred to the future forum owner!

    Accepting ensures:

    - Continued access to your account with a short break for the actual transfer.

    - Retention of your data under the same terms.

    Without consent:

    - You don't have further access to your forum user account.

    - Your account and personal data will be deleted after April 5, 2024.

    - Public posts remain, but usernames indicating real identity will be anonymized. If you disagree with a fictitious name you have the option to contact us so we can find a name that is acceptable to you.

    We hope to keep you in our community and see you on the forum soon!

    All the best

    Your Cerberus X Team

Fixed CerberusX reporting incorrectly number of line.

Thanks dawlane, I won't have time tonight, but tommorow to test it.
 
@MikeHart : Just noticed that more memory will be used with changing. Lines 201-203.
Code:
    Method Emit( t$ )
        output.Push t+"~n"
    End
So remove ther +"~n" and add it to the end of line 631. It should still work the same.
Code:
        Local source:=output.Join( "~n" )+"~n"

Edit: Take it as read that the changes are still a work-in-progress and that I may think of other ways to check for End terminations and improvements. So it may not be the final file. Plus I'm still thinking of a way to check the Repeat/Until/Forever block.
 
Last edited:
So testing might now be wise now as you may change things anyway.
 
So testing might now be wise now as you may change things anyway.
At the moment I'm going through any code that deals with blocks to get the tracing more accurate. In theory, blocks that are correct should not show up, but there will always be issues with blocks ending with just 'End'. Basically the same problem as with the preparser code of 'Which End is for what block'. So far I've never seen any For loops that end with either End, End For. Could drop that check and just stick with Next. Opinions?
 
For should always end with next. Ending it with End feels totally wrong.

Are you redoing the whole thing?
 
Last edited:
Shall I get rid of it?
For now only fixes. Any removal of existing language features we should implement in a version 2.
I don't have time to work on V2 alone. I am sure someone out there codes like that. But at the same time, it isn't documented. So we could always remove it. Go for it.
 
But at the same time, it isn't documented.
Well, it is documented twice. In the keywords section and in the loop for section. :oops:
Just to make things clear, I am in favour of these kind of changes, but maybe we should have a plan about what to change and then do it in one move!?
 
I prefer to use the retro style FOR...NEXT myself but I actually would like to also give a vote for keeping the End option.
Some of my friends like to use END and every other loop and condition has an End option so it makes sense to keep it.

For.. To/Until .. [Step].. Next/End
As long as you do not forced to use *only* END I would vote to keep both.
 
Well, it is documented twice. In the keywords section and in the loop for section. :oops:
Just to make things clear, I am in favour of these kind of changes, but maybe we should have a plan about what to change and then do it in one move!?
Sorry my bad. I was just looking at the keyword reference. There it isn't mentioned.

Ok @dawlane please leave End in.
 
@MikeHart;
Right. Hopefully these files should work.
The reflection (reflector.cxs) class needed a miror change, as the source it was generating didn't have a token to indicated an end marker.

The preparser.cxs has had a minor change to use an IntStack instead of a StringStack for storing possible error lines. This should save a bit of memory. At some point in the future, the code in the preparser for keeping track of code blocks should be changed to make use of the new class that deals with keeping track of code blocks and tracing.

The parser should have a little more accuracy of highlighting a code block error, it should also provide a trace of all block starts within the starting code block. Because of the use of 'End' being allowed, it will never be perfect, but the tracing of code block starts should help to locate where an error is.

The new file blktrace.cxs is a stand-alone class that can be used to keep track of code blocks and provides a tracing function to list the start lines of those code blocks.

If there is any problems, I will need sample code so I can reproduce the issue. But so far the samples build and run as does the Cerberus build process.
 

Attachments

  • parser_updates.zip
    24.3 KB · Views: 129
Thanks a ton dawlane for all the time you spend. I will test it myself. If I don't find any issues then I will see that I compile a official release on all 3 platforms soon.
 
If there is any problems, I will need sample code so I can reproduce the issue.
Here you go, this produces a memory access error when you parse the project. Just press F6.

Cerberus:
Strict

'Simple C++ tool script

'The next line is the faulty one.
Const SAPP_MODIFIER_SHIFT:Int = (1 << 0)
Const SAPP_MODIFIER_CTRL:Int  = (1 Shl 1)
Const SAPP_MODIFIER_ALT:Int  = (1 Shl 2)
Const SAPP_MODIFIER_SUPER:Int = (1 Shl 3)
'-----------------------------------------------------------------
Function Main:Int()
    Print ("Cerberus X - C++ tool template")
    Return 0
End
 
I made the changes here, as there were in the posts on this thread, but the error persists. Soon, today, I will post what errors occur when using #Rem #End and in what situation. Cerberus X reports different errors depending on the content between #Rem and #End, so far it reports a right line as a wrong line and reports this: "Function 'Main' Not Found.
I am doing some tests here and I will describe in which scenarios the errors occur.
 
You downloaded the last zip file from dawlane and rebuild trans?
 
@MikeHart @dawlane

Cerberus X reports this error: "Function 'Main' not found, in this situation:
When the content between "#Rem" and "#End" has a double quote (") balance incorrectly,
for example, if you do this:

Cerberus:
#Rem
    asdf "asdf" "
#End

Function Main:Int()
    Print
End

Regarding CerberusX reporting the correct line as wrong, it also occurs with double quotes,
however, unlike the previous error, the error occurs when there is a correct balance of double quotes, that is,
you opened and closed the quotes correctly, however, the error occurs if you opened the double quotes
in one line and close the double quotes in another line.
If you start and close the double quotes on the same line, CerberusX reports the wrong line correctly.
The number of lines separating the initial double quotes from the corresponding final double quotes, will be
equal to how far Cerberus X is from the really incorrect line. For example, if the error is on line 10
and you start the quotes on one line and end on the next line, CerberusX reports the error on line 9.
If you start the quotes on one line and end two lines in front, CerberusX reports the error on line 8.

In the code below, the user typed the double quotes starting on one line and ending on the next line,
CerberusX will report the error on one line before the really wrong line.

Cerberus:
#Rem
    asdf "asdf
    asdf"
#End

Function Main:Int()
    Print                ' This line incorrect. But CerberusX reports the previous line
End

In this other code, the user started the double quotes on one line and closed the double quotes
two lines ahead, in this case, CerberusX reported 2 lines before where the error really exists.

Cerberus:
#Rem
    asdf "asdf
  
    asdf"
#End
                        ' <-- CerberusX reported this line as incorrect.
Function Main:Int()
    Print                ' Although, the really incorrect line is this.
End
 
Last edited:
Probably, the tests were done with content between "#Rem" and "#End, that there was no double quote character. Therefore, the error persists, even after reconstructing transcc. For, the code that had sent when starting this thread reporting this, had the character double quotes.
 
Probably, the tests were done with content between "#Rem" and "#End, that there was no double quote character. Therefore, the error persists, even after reconstructing transcc. For, the code that had sent when starting this thread reporting this, had the character double quotes.
Something tells me you are not using the last set of files. Those snippets report correctly with the files I have.

@MikeHart :
The full set of files modified parse files, with blktrace and parse updated.
 

Attachments

  • parser_v0.1_update.zip
    19.9 KB · Views: 124
I made a diff on the files you uploaded are different from the zip file that I downloaded earlier, probably there was an update.
I will test here.
 
Back
Top Bottom