18 replies to this topic

[RevEng]

I put together a small utility to double-check the syntax of a bB basic program. This version flags the following issues:

• unindented commands.
  
• indented "end".
  
• unmatched for and next count.
  
• incorrect "end" count.

If there are issues, bblint reports them along with the line numbers, if possible. If no problems are found, bblint just silently exits.

bblint is a command-line utility, so you'll need to know how to run those. If you run bB from a Batch or Make file, it would be a good idea to include this command there to double check your work.

Win32 and 64-bit Linux versions are included, along with source.

 bblint_v0.04.zip   19.21K   22 downloads

Edited by RevEng, Sun Dec 11, 2011 6:53 PM.

[diogoandrei]

This looks really interesting! I am gonna try it out this weekend =)

[RevEng]

Thanks diogoandrei!

It's not the most thrilling of utilities, but hopefully it will save people time bug-hunting.

[jwierer]

I can integrate this into visualbB so that it's really easy to launch it and capture the output into the IDE for folks that aren't as comfortable with the command-line.

-Jeff

[RevEng]

Sounds perfect Jeff!

[yuppicide]

How about something to analyze gosub and return commands or is that not doable?

[diogoandrei]

jwierer, on Fri Jan 28, 2011 6:54 PM, said:

I can integrate this into visualbB so that it's really easy to launch it and capture the output into the IDE for folks that aren't as comfortable with the command-line.

-Jeff

Really, really cool! Nothing like a handy new feature =)

[RevEng]

yuppicide, on Sat Jan 29, 2011 5:59 AM, said:

How about something to analyze gosub and return commands or is that not doable?

gosub+return commands is more complicated. It's pretty much impossible to determine one subroutine's return from another, since there's no real way to check where a subroutine ends.

I can't even do gosub/return counts, since it's a valid technique to have multiple return points from a subroutine, and you could have multiple gosubs to the same sub.

I think I've hit a lot of the obvious checks, but I have a few other ideas on what could be added...

• goto/gosub without real destination.
  
• dimming a variable name that's a reserved keyword
  
• setting up a constant that's a reserved keyword

...that said, I'm not rushing to update this right now, beyond bugfixes. I have too many projects right now as-is.

Edited by RevEng, Sat Jan 29, 2011 7:51 AM.

[RevEng]

v0.02 added to first post.

I've updated the keywords to include new ones from batari's v1.1 beta, and also fixed a bug where a rem statement was considered ended with a ':' character.

[Uberkatzchen]

Thought I'd be helpful to less savvy Macintosh users, so here's an Intel only binary (built on 10.6.4 Snow 'kitten' Leopard ;D)

It's in a zip instead of a tar.gz because I'm currently on a 'doze' box, it'll still unpack fine though! Run using ./bblint *filename of src file*

Great piece of software!

Attached Files

•  bblint.zip   3.99K   46 downloads

[RevEng]

Thanks Uberkatzchen!

[Uberkatzchen]

RevEng, on Wed Feb 2, 2011 4:53 AM, said:

Thanks Uberkatzchen!

No problem, I must commend you on your impeccable C chops, I didn't get a single warning and for a C program, that's pretty darn good! But that also meant I couldn't have fun nosing around and fixing bugs

[yuppicide]

Figured as such, but thought I'd mention it anyway. I wouldn't even know where to begin, because sometimes I find myself getting lost in my goto and gosub/returns.

RevEng, on Sat Jan 29, 2011 7:28 AM, said:

yuppicide, on Sat Jan 29, 2011 5:59 AM, said:

How about something to analyze gosub and return commands or is that not doable?

gosub+return commands is more complicated. It's pretty much impossible to determine one subroutine's return from another, since there's no real way to check where a subroutine ends.

I can't even do gosub/return counts, since it's a valid technique to have multiple return points from a subroutine, and you could have multiple gosubs to the same sub.

I think I've hit a lot of the obvious checks, but I have a few other ideas on what could be added...

• goto/gosub without real destination.
• dimming a variable name that's a reserved keyword
• setting up a constant that's a reserved keyword

...that said, I'm not rushing to update this right now, beyond bugfixes. I have too many projects right now as-is.

[RevEng]

bblint v0.03 has been attached to the first post.

I updated bblint's internal keyword list to match the latest released bB 1.1 beta, and ; comments are now taken into account. (still need some work to support C style comments)

Edited by RevEng, Mon Mar 7, 2011 10:22 PM.

[RevEng]

bblint v0.04 has been attached to the first post.

Understanding of "player#-#:" type statements has been added. Using these statements in your basic file with previous bblint versions would cause a warning about the "end" statement count.

[theloon]

What about renaming the bB compiler and having VisualbB call this instead? At the end of the bblint run you could then call the real compiler. Or, even better, you could ask the developer of VisualbB to add in support for calling bblint before compilation

[RevEng]

You have your wish - Jeff added integration into vbb a while back.

[theloon]

RevEng, on Thu Dec 22, 2011 11:23 AM, said:

You have your wish - Jeff added integration into vbb a while back.

Great, next thing you'll tell me is parachute pants are out of style!

Okay, what about include support? You could allow insertion of seperate bB source files so peeps could have their own libraries.

INCLUDE BOPHADS.BAS

Edited by theloon, Thu Dec 22, 2011 1:42 PM.

[RevEng]

Sounds like a good idea! When I get a chance I'll add that in.