Page 1 of 1

Desired behavior in macro compiler?

Posted: Sat Jun 09, 2018 6:11 pm
by Meeply
I started a macro shell so I wouldn't have to start from scratch each time with basic utilitarian examples. The top part of the main looks like this.

Code: Select all

#include meeply.inc
#turbo 20
    
|: --------------------------------------------------------------------------------------------
|: SUB: Main
|: --------------------------------------------------------------------------------------------

Sub Main

    | declare and set variables here
    /declare i int inner
    /varset i 0

    /call FixWhile
Error came back:
"Subroutine FixWhile wasn't found.
hello.mac@18 (Main): /call FixWhile"

Turns out after 2 heads and hours of looking at it, I declared the scope of the int I incorrectly. Should have been local instead of inner. (Thinking global, outter, inner instead of global, outter, local.)

Yes this is in the manual, yes this is my mistake. But the macro compiler flagging the wrong statement/line as the error should be considered a bug. There is no way to "comment debug" this and gives an erroneous error message. Change /declare I int inner to /declare I int local and it works.

Should this be considered a compiler bug? I know its small but typos happen even if I didn't get my syntax mixed up.

Thanks.

----- EDIT: sorry but I still need to look at this more. The person that thought they figured it out gave me a one line change to make it work and it's not. I need to sort this out first. Sorry for the premature post. -----

Re: Desired behavior in macro compiler?

Posted: Sat Jun 09, 2018 7:36 pm
by dewey2461
Compilers are very hard things to write. Especially if they are coded by hand instead of using flex / yacc. I'm honestly shocked that the macro language works as well as it does.

Re: Desired behavior in macro compiler?

Posted: Sat Jun 09, 2018 9:06 pm
by Meeply
Still stumped after many more hours. I'm trying things at random at this point. (I always hated when someone asked how do I fix this and someone else in my group said "Have you tried this yet?" Means they don't know, which at this point obviously I don't.

Is the only way to debug this macro to compile MQ2 and step through the macro compiler?

I tried with VS 2012 but got an error about targeting .NET version 4.0. Since I have 4.5+ on my machine I'm not allowed to install 4.0 (according to the MS installer.) Wondering if this is a compiler thing since I've now seen various conflicting notes (clearly some older) about what version you need to compile MQ2 with. The best note I have seen says I need 2015 or higher and only have 2010 pro. Yes, I tried the community version install but I have a small SSD as my OS drive and it wants to install more stuff on there than I have space so I have to sort that out first.

Worked on a project with its own language and yes, we had a guy doing lex/yacc (obviously a while ago) to interpret the language. Worked very well.

Sorry if I seem frustrated folks and over the top. I've been disabled and out of the game for many years and have "chemo brain" side effects affecting my retention so I'm really more frustrated at myself for not being able to catch up quicker.

Thanks.

Re: Desired behavior in macro compiler?

Posted: Sat Jun 09, 2018 10:45 pm
by dewey2461
I'm still not sure what you are asking so I'll try to answer a couple of the questions. ( If you haven't read the manual that is a good place to start )

#1 You need to add #warning at the top of the macro. This will cause the macro to STOP if you have any undeclared variables.

#warning
#turbo 80
....

#2 When I need to debug a macro I use the /echo command. Sprinkle them around your macro so you can see which lines are executing.

#3 You may need to add some /delays if things scroll too fast.

#4 This is mainly syntax but the macro's aren't compiled.

#5 MACROQUEST2.EXE is complied from source but only for the test server. ( Some ass hats were compiling for the truebox servers and as a result the live source is no longer being distributed )

#6 YOU can compile for live but you have to do it through the "builder" tool which lets you upload your custom plugins via a web interface.

Re: Desired behavior in macro compiler?

Posted: Sun Jun 10, 2018 3:12 am
by Meeply
Couple issues with the parser/interpreter (assuming these are interpreted) for macros.

One of the errors I was having with my include file was due to unclosed comments

Code: Select all

|**********************************
|* test.inc
|**********************************
Sub Test
	echo In Test
/return
I was thinking I was using the single line comment multiple times when I was actually using the multi line comment and never closed it. The problem didn't show up until I included test.inc and tried to call the sub in there. I got a message about the function not existing but no error on unclosed comments in a different file. Seems an oversight on error checking when parsing. Should have got a message about comment not being closed before the file ended.

Second issue. Extra whitespace in parameter declarations in subs are a problem?

Code: Select all

Sub Hello( string MyName )
	/echo Hello ${MyName}
/return
This call will produce the output: Hello NULL when it should be producing: Hello whatevermynameis.

If the Sub is defined this way instead

Code: Select all

Sub Hello(string MyName)
It will produce the expected results. Is this really intentional? In all my years I've never seen extra whitespace for readability like that cause any problems. This bug is fixable. I'm not even going to go to the place that asked why are there parens for a definition of a Sub but not in the call. I think that ship sailed long ago.

The third issue was no error message when I declared a variable with a non-existent scope.

Code: Select all

	/declare int i inner
never generated an error even though that scope does not exist. (Thinking outer/inner since global is forever until the program is closed or the var is deleted). Yes, I coded this wrong and it is in the wiki but an error message on a var definition would be a good thing no?

I thought the guys trying to correct my code were telling myths and wives tales about what worked for them and not real solutions until I tried them. I'm sure these will get low priority on fixing them but anyone starting to learn to macro in this language will not find the first two issues in the wiki and a simple typo could ruin his var definition. Nor can 2 of these be debugged by /echo calls. The third, the /echo would tell them the variable didn't get passed in correctly but not why.

I hope some day someone can get a look at them please.

Thank you for your help and consideration.

Re: Desired behavior in macro compiler?

Posted: Sun Jun 10, 2018 4:15 am
by Meeply
dewey2461 wrote:
Sat Jun 09, 2018 10:45 pm
I'm still not sure what you are asking so I'll try to answer a couple of the questions. ( If you haven't read the manual that is a good place to start )

#1 You need to add #warning at the top of the macro. This will cause the macro to STOP if you have any undeclared variables.

#warning
#turbo 80
....

#2 When I need to debug a macro I use the /echo command. Sprinkle them around your macro so you can see which lines are executing.

#3 You may need to add some /delays if things scroll too fast.

#4 This is mainly syntax but the macro's aren't compiled.

#5 MACROQUEST2.EXE is complied from source but only for the test server. ( Some ass hats were compiling for the truebox servers and as a result the live source is no longer being distributed )

#6 YOU can compile for live but you have to do it through the "builder" tool which lets you upload your custom plugins via a web interface.
Thanks for replying dewey.
1) Thanks for the tip. If it should be necessary (which I would agree with), wouldn't you think that was the default?
2) I used to debug Windows code will MessageBox() in the 80s before they had IDEs. I remember those days and still can do so if needed. Since there is no real debugger for macros, I guess that's all we get. But, it's doesn't help when the macro won't parse/interpret or run at all.
3) I'll have to look at delays. Just trying to understand the basic framework now.
4) I stand corrected. I assumed they were actually interpreted since there is no object file produced but used the wrong word.
5) It's not my code but it's a shame the live version is not available to compile yourself and costs to use the builder but a compiled debug test version would have at least allowed me to step through the code parsing the macro. If I don't have access to the live code, I can't also contribute or fix things I'm complaining about that nobody else has time for. Seems like a lose/lose in this case. I do get the issues with this involving time and all the people that got this running and keep it there as I was lead dev on a old text based MUD on the internet for free for years but I would have never gotten there or able to contribute at all if there was not a way to download the source. It's a slippery slope.
6) I misread slightly the text at the top of the builder page that says you "can" build live versions with the builder. I did not read that to mean you MUST. Since I'm not in the builder group, didn't seem to apply that much.

We must have been responding near the same time because I didn't see your response until after I finished mine.

Thanks for the time and advice.

Re: Desired behavior in macro compiler?

Posted: Sun Jun 10, 2018 6:53 am
by dewey2461
Meeply wrote:
Sun Jun 10, 2018 3:12 am

The third issue was no error message when I declared a variable with a non-existent scope.

Code: Select all

	/declare int i inner
This should be:

/declare i int inner

You are declaring a variable called "int" of type "i" in the "inner" scope.

Re: Desired behavior in macro compiler?

Posted: Sun Jun 10, 2018 6:27 pm
by SwiftyMUSE
dewey2461 wrote:
Sat Jun 09, 2018 10:45 pm
#5 MACROQUEST2.EXE is complied from source but only for the test server. ( Some ass hats were compiling for the truebox servers and as a result the live source is no longer being distributed )
Actually, the loader (macroquest2.exe) is compiled for any server, however, it is provided in compiled form only and there is no open-source code for it.