Is BlitzMax ready for production use?

I am developing a software in BlitzMax for my university. It is a functional language interpreter called XSymbol, which will be used in an Artificial Intelligence project. Right now, I am trying to debug the interpreter to follow how it runs a script step by step. When running the program completely, it runs without problem, but when I try to debud it line by line, it aborts at one line that should be working perfectly (and which works if I am not debugging, even if I run the program in Debug mode). It does not return any errors, it simply quits with the "Process complete" message.

This is driving me insane, since this behaviour doesn't make any sense, and the software should be ready for showcase next tuesday. I talked some teachers at the department about BlitzMax, and how good it was for prototyping, but I am really considering to rewritte it completely in C in the days I have left, since bugs like these really prevent BlitzMax for being useful for any production use.

I love Blitz, but this is a serious bug that is a real pain. I have experienced it myself many times and it makes the debugger next to useless.

It's a shame, but it may be your best course of action.

Yes the debugger can be a pain, I've had to work around it by using Print and If statements so I can see where the program is going without using debug mode.

I would debuglog the variables and see what is changing between compiles.

It's a bit funny for me. I've learned programming in a time when debuggers still had to be invented, so I've been doing what Grey Alien suggests all my life and never became friendly with debuggers. I just don't miss them when they are not there or not working properly. And if they are there, I usually don't even bother to look at them.

I've worked for a couple of years for a compiler vendor. Except for one person there, I can hardly remember anyone of the team using the debugger that came with our compiler. Everybody did it the way Grey described above. I think we all must have been 'old school'. But when you have to debug multi-threaded software, you will soon find out that most debuggers are not worth crap.

Imagine you were using Python, Perl, PHP or any other scripting language. You would not have the luxury of having a debugger either. Would you still doubt their readiness for production use?

I never noticed that the BlitzMax or Xbase++ or PowerBASIC or Borland Pascal or Visual C#.NET debugger suck because I simply never really used any of them. And still, I was able to ship software written in these languages. For me, plain and simple, a debugger is not an essential tool.

That does not mean I am defending broken software. When you ship a development tool, it should work properly.

I also use debulog and print statements along with a profiler which creates a .trace file with function/method flow. It means a bit of extra typing but I am hoping to create a parser maxgui app to add the statements for selected functions/modules. Has anybody done something similar already?

In fact, I hardly use BlitzMax debugger. When I need to know if the program enters a specific section of code, I usually just put a "Hello world!" notify and run again to see if it's executed. If I see something wrong, I usually just print to the standard output the stated of the related variables. But in this specific case, the amount of data used is really big to do it this way.

I suspect there might be a problem in the interpreter. Every time a call to a script function is found, the "state stack" (a set of variables where I have the current execution offset, arguments passed, etc) is saved, then the interpreter loads the new arguments, moves to the offset of the function, executes the code in it, and restore the previous stack by updating its "retvalue" field with the result of the called function. The problem is that, since my language is functional, it makes an intensive use or recursivity, and you can guess how much indented calls have been made there (a few hundred in the program I am testing now). It is simply impossible to output to the console an stack this big and check line by line the state of all variables to find out where it got messed up and moved to an incorrect location. It is easier to stop when the program is about to enter the recursive calls, and step by step to see if the stack gets corrupted at any time.

Another way is a simple, write the debug text to a file this way even if it kills Blitz there is still the text log to look through. Elite Multiplayer does this atm as network debugging can be a real pain.

have you thought about using OcaML or F# to build the interpreter?

If I switch to another language, I would go with C, since I know it very well, it's robust, and have awesome development tools (like Visual C++). If I went with a non-so-standard language, I would probably pick D (as long as it has good debugging support, which I am not sure).

Are you using the Official/Community MaxIDE? Some users (including myself) find that Ziggy's BLIde is better at handling BlitzMax debugging, so you could try loading your source up in there, and using that to compile and debug.

yes it is.

(although depends what you mkean by ready, if you mean native 3d then not yet.)

It might just be me but I have never used the debugger and probably never will. I usually print stuff to the window or whatever. I do use debug to try and check for silly errors sometimes, but of course if it is broken and creates non-existent errors then that is a problem.

I never use debuggers - they always cause more problems than just using PRINT or sending output to a file.

"yes it is.

(although depends what you mkean by ready, if you mean native 3d then not yet.)"

Well, I meant what it says in the post. Did you just read the title?

With a non-working debugger, it's hardly suitable for projects like the one I'm working for at the university.

Sorry i scan read it as i had a 3 year old wanting his dinner :)

Yeah the debugger needs some work. Its usually worked ok for me in the past and have not noticed that problem myself.

What line is it stopping on? ( a code segment be useful )

Nope, never will be :) Debug is crap but if you can work with it then you'll get some decent results (with some mods) - mind you depends on your coding skills all the same. Quite frankly I STILL think this is the best cross-platform solution on the planet! I WISH BRL would actually improve upon it without us having to rely on USER mods to make it work.

The IDE has a tendency to freeze up for me when I try expanding tree nodes in the debugger panel, and I have to terminate the process.

And it will never ever be improved.

I hate to agree with you, but I think you're right. It's all well and good making statements like 'I don't like debuggers', 'they are no use', 'use print statements', but my experience with, say MSVC, shows that they can work and they are powerful. Sometimes a print just doesn't cut it.

I think the fundamental problem with the debugger issue is that to date there's been no sure fire way of reproducing it in simple code. I've said before that I've very rarely seen the problem when debugging the CE IDE< and that's a beast!

Hopefully Seb's post below yields a decent clue in this department, and I'm quite sure any specific examples would help (rather than the usual "it doesn't work, but I can't show you how" whinging).

http://www.blitzmax.com/Community/posts.php?topic=78266

I really wish the debugger was seperated from the IDE so that we could get it running in generic IDEs (ie. UltraEdit).

The debugger is basically just a stdio pipe with commands sent into the running app, and data pumped out. You can in theory use it from the command line I believe, but a standalone harness that simply wraps this is entirely feasible if someone wanted to write it.

In fact, you might be able to just wrap / hack debug.bmx in the CE IDE with a simple GUI to do just that if you really wanted to...

The line where the debugger crashes is this:

For Local i = 0 Until ScriptFuncs.length

If I change it to:

Local length = ScriptFuncs.length
For Local i = 0 Until length

It doesn't crash, which doesn't make any sense. And both versions work fine if I'm not step-debugging it. But now that it doesn't crash at that point, it does at some other, so...

Jedive, what kind of object is ScriptFuncs, and does a simple example of this break the debugger, e.g.

'a$ = "12345678901234567890123456789012345678901234567890"
Local a$[3] ; a$ = ["1","2","3","4","5"]
DebugStop()
For Local i = 0 To a.length-1
	Print a[i]
	a=a[ ..a.length+1]
Next

(The above works fine for me)

The only time I've ever seen the debugger dropout as described here ( as opposed to hanging completely as Josh describes which I see all too often ) is when I've done something which has caused the stack to overflow. Either recursion which is very deep or just an endless loop.

In this case, it looks like you're looping through an array. By any chance are you changing the size of said array within that loop?

Good call, but adding an array resize still doesn't break it.

@Gabriel:I'm not changing the size of the array.

@Mark: The above example does not break the debugger here.

I think that it might be what Gabriel is saying. As I said, the interprer is running a script which makes intensive use of recursion.

You could put Global RecursionCount:Int = 0 and RecursionCount :+ 1 at the start of the recursive function, and put RecursionCount :- 1 at the end. That way you can tell how deep it is when it crashes. Also, you could add Global RecursionMax:Int = 0 and If RecursionCount > RecursionMax Then RecursionMax = RecursionCount. Then you can test how deep the recursion goes when it does work.

Yeah I'm using old-skool debug techniques now but I used to really love the debugger in Delphi, it was a revelation to me. Breakpoints, step in, step out, evaluating values, inserting new values etc. All very useful.

I know this isn't helpful, but if the program works fine otherwise, why is it necessary to rewrite it from scratch? Is your program finished?

As a hack, you could try writing the problematic sections of code in C and then include them into the BlitzMax source...

From this other thread, it looks like at least some of the debugger problems in max are caused by the debugger getting itself caught up with the garbage collector.

http://www.blitzmax.com/Community/posts.php?topic=78266

Might be worth seeing if the suggested fix sorts out your issue Jedive?

I like max. Usually. It seems to fall apart when our projects get past a certain size and we have to work around little niggles- The doc systems totally naff.

Long story short. Right now if i ws offered a very large contract and had a fresh slate, I'd choose c++ or c#.

I think the biggest stumbling block in a Professional production environment is that hardly anyone has heard of blitmax or recognises blitzmax as a viable language for creating their software.

Plenty of jobs around asking for flash, java, python these days, but mention blitzmax and then try and explain its a really nice modern basic and they will probably give you an awkward look. This is a stumbling block that can be hard to overcome.

I'm with you on that note- but Bmax does have some internal issues that have been discussed elsewhere. Our docs problem should be simple to solve if someone could decrypt the DocMods source hehe.

The debugger is broken- this is a major problem. Ziggy has done all he can to fix it with Blide but when max itself is conking out, there's only so much that can be done. Also, trying to fix a bug that doesn't exist where it is telling you it is, is impossible.

For those experiencing problems with the debugger, try the CE IDE in the link below which incorporates Seb's IDE fixes:

http://www.blitzmax.com/Community/posts.php?topic=78491

That won't fix everything. Some bugs appear even when using seperate IDEs.

True. But it does fix the only reproducible bug actually reported, hence showing the value in reporting bugs properly...