IntyBASIC compiler v1.1: The Director's Cut ;)

[intvnut]

 

There is nothing syntactically nor semantically wrong with declaring a variable and not using it. Some of us don't need handholding and are quite capable of keeping track of a few dozen variables in our heads

 

It drives me nuts to comment out a single line while testing, which happens to be the only line that references variable X, and then suddenly get a bunch of "errors" from my compiler. Thanks, Mom.

 

But that's why I said I'd like it as an option, with warnings enabled by default. Newcomers and the average person benefit from these things.

 

As tedious as it is, I've found I benefit more from the strictures than not. I certainly don't consider myself a newcomer. I think the warnings are useful to programmers at all levels.

 

In Perl, I "use warnings; use strict;". In C/C++ I throw as many -W flags as I can stand at the code. And yes, in intermediate builds I end up with warnings I need to tune out. But, they serve as "to-do" lists, and eventually I clean up all or most of the warnings before checking in code. (Or, I'll make an intermediate checkin, followed by cleanup checkins.) I'll let the warnings happen, to remind me of what I have left to write.

 

Sometimes adding -W flags to a project that was developed in their absence kicks over a hornet's nest. For example, cleaning up AS1600 was especially fun. (And I think it's not yet 100% clean.) It was originally a K&R C program. I turned on all the warnings related to 'const' and got page after page of warnings... The resulting cleanup was time well spent, IMHO, but painful in the short run. Old idioms such as 'char *foo = "string"' suddenly became warnings. And then there were all the missing function prototypes (again due to it originally being a K&R C program, not ANSI C)...

 

Now for WIP stuff: If you know you have a bunch of things that aren't implemented, but you have some declarations that trigger the warning, I suppose that could be annoying. If you have a placeholder in your code for the procedure(s) that will eventually use those variables, maybe you could put some dummy code there to quell the warnings. That's perhaps similar to the UNUSED() macro I have for variables I declare but never use.

 

*shrug*

[freewheel]

Guys, you've got the warnings in the compiler. There's no further need to campaign in their favour

 

I bet my variable naming conventions and indentation styles would drive y'all nuts, too. Which is why it's a good thing that I'll never have anything good enough that it becomes a team effort Heaven help us if we ever get C-style function brackets. Then it's WAR.

[Kiwi]

I had so many warnings in my Colecovision project that it stops compiling midway and the error didn't show up in the CCI3 console. So cleaning up and fixing the warning resolve the issue.

Basically I used to do for(i=0;i<=5;i++){find a slot code here;} which causes the warning.

Replacing that with for(i=0;i!=6;i++){find a slot code here;} Does the same thing, but doesn't cause the warning.

[intvnut]

Guys, you've got the warnings in the compiler. There's no further need to campaign in their favour

 

I bet my variable naming conventions and indentation styles would drive y'all nuts, too. Which is why it's a good thing that I'll never have anything good enough that it becomes a team effort Heaven help us if we ever get C-style function brackets. Then it's WAR.

 

If your indentation styles are set at, say "2", but your hard tabs are set at, say "4", and then you expect people to make sense if it when their hard tabs are set at "8"? Yeah, that's nuts. (And I've seen even worse tab damage when someone editing the code has their editor to convert tabs to spaces, and someone else has their editor set to convert spaces to tabs, each with different "spaces per tab" settings...)

 

 

Basically I used to do for(i=0;i<=5;i++){find a slot code here;} which causes the warning.

 

Replacing that with for(i=0;i!=6;i++){find a slot code here;} Does the same thing, but doesn't cause the warning.

 

Allow me to respectfully state whatever warning that was is misguided and wrong. I guess it was trying to get you to write "for ( i = 0 ; i < 6 ; i++ )", which in the end you didn't actually write....

 

What was the exact text of the warning? And what compiler gave that warning? SDCC? Something else?

[freewheel]

Basically I used to do for(i=0;i<=5;i++){find a slot code here;} which causes the warning.

 

Replacing that with for(i=0;i!=6;i++){find a slot code here;} Does the same thing, but doesn't cause the warning.

 

Ironically, the latter can cause other problems that most compilers won't pick up on. I'm not even sure why the first example caused a warning to begin with, to be honest.

[freewheel]

 

If your indentation styles are set at, say "2", but your hard tabs are set at, say "4", and then you expect people to make sense if it when their hard tabs are set at "8"? Yeah, that's nuts. (And I've seen even worse tab damage when someone editing the code has their editor to convert tabs to spaces, and someone else has their editor set to convert spaces to tabs, each with different "spaces per tab" settings...)

 

Style, not settings.

 

I find it nice in IntyBASIC to have tabs set to 2, but I indent actual statements by 4 tabs to give labels a bit of breathing room. Things within FOR loops just get a single tab. Purists (and OCD types) absolutely loathe people who do this. I like the visual style as it helps me scan code much quicker. And the editor keeps track of where the next line should be very nicely. Mind you, it wouldn't surprise me if the code ended up looking like crap in another tool.

 

I also pretty much never break things out into multiple files due to the small size of these things - although with one project pushing against 10,000 lines I'll probably start doing it occasionally (it's 80% DATA and BITMAP statements and probably 500+ lines of comments/descriptions). At least I have a nice multi-file editor with a decent tree view. I think some people are still doing this in Notepad and vi and such.

 

I even occasionally intersperse code and data segments, when it makes sense for me. I worked with a guy who would go nuclear if he saw that.

[freewheel]

Allow me to respectfully state whatever warning that was is misguided and wrong. I guess it was trying to get you to write "for ( i = 0 ; i < 6 ; i++ )", which in the end you didn't actually write....

 

What was the exact text of the warning? And what compiler gave that warning? SDCC? Something else?

 

For the life of me I can't remember where, but I once worked with in an environment that would pick up modifications to "i" within that loop and throw a warning that runtime conditions could cause the loop to never finish. Which makes sense as a warning. Unless you've worked with students (and professionals who should know better) that never really learn what they're doing, and just try random code until it eliminates the warning: because "all warnings mean a problem in my code, no warnings mean my code is perfect". Pretty much quoted verbatim, sadly.

 

Of course his fix wouldn't change a damn thing (in fact it could make things somewhat worse), but it could be enough to suppress the warning depending on how and what the compiler is checking.

[intvnut]

 

Style, not settings.

 

I find it nice in IntyBASIC to have tabs set to 2, but I indent actual statements by 4 tabs to give labels a bit of breathing room. Things within FOR loops just get a single tab. Purists (and OCD types) absolutely loathe people who do this. I like the visual style as it helps me scan code much quicker. And the editor keeps track of where the next line should be very nicely. Mind you, it wouldn't surprise me if the code ended up looking like crap in another tool.

 

I also pretty much never break things out into multiple files due to the small size of these things - although with one project pushing against 10,000 lines I'll probably start doing it occasionally (it's 80% DATA and BITMAP statements and probably 500+ lines of comments/descriptions). At least I have a nice multi-file editor with a decent tree view. I think some people are still doing this in Notepad and vi and such.

 

I even occasionally intersperse code and data segments, when it makes sense for me. I worked with a guy who would go nuclear if he saw that.

 

 

I have a feeling I wouldn't have a problem with your code as long as it had its own internal (if quirky) consistency. What I can't stand are files where there's no consistency at all. Stuff like:

.

 if( blah<3)
             {
   x-=2;
} else
     { 
     fred(x  );
  }

.

I have actually had to deal with codebases like that. I think half of it was due to tab damage, and the other half was actually due to someone having a stroke. At least, that's the charitable explanation.

[freewheel]

 

I have a feeling I wouldn't have a problem with your code as long as it had its own internal (if quirky) consistency.

 

When needed, I can write to any coding style*. One of the reasons I love doing this stuff in IntyBASIC is that I can do what *I* want. I'll probably eventually release all of my source code for people to laugh at learn from/improve on, but for right now it's my sandbox.

 

* but I will never, EVER enjoy writing

 

if (condition) {

 

do stuff;

 

}

 

I've had the reasons explained to me 1000 times, and that style of braces just drives me bonkers. My brain refuses to process it nicely. Fortunately that appears to be a rarity at my current employment, where I actually have to read and write code for the first time in a lot of years.

 

Anyway, we've once again gone waaaaaaaaaaaaaay off-topic in a programming thread My apologies.

[Kiwi]

 

Allow me to respectfully state whatever warning that was is misguided and wrong. I guess it was trying to get you to write "for ( i = 0 ; i < 6 ; i++ )", which in the end you didn't actually write....

 

What was the exact text of the warning? And what compiler gave that warning? SDCC? Something else?

 

Doing something like

for(ID=0;ID<=5;ID++){
if(birdx>objectx[ID]-10 && birdx<objectx[ID]+10){
if(birdy>objecty[ID]-10 && birdy<objecty[ID]+10)
{ObjectGet();}}
}

will give, Flappy.c:2879: warning 94: comparison is always false due to limited range of data type.

 

And it quite picky where the function is structured in my C project.

Flappy.c:2110: warning 112: function 'bossdies' implicit declaration

Flappy.c:2110: warning 84: 'auto' variable 'bossdies' may be used before initialization

Flappy.c:2110: warning 84: 'auto' variable 'bossdies' may be used before initialization

 

Even with the warning, the game works fine. No VRAM curruption thankfully.

 

I have to think everything is in bytes, not char or int since Colecovision is an 8-bit system. So all of my variables are bytes. That something I conceptize myself. Also I do avoid multiplication and use adding. Division usually uses shift method when I need to have sprites interact with the background tiles. CII3 uses SDCC and I'm using 3.3.0 version. It calls the SDCC kits, help link the compiled codes to make a ROM, and can call BlueMSX to test the ROM. The coleco libraries are pretty good and I do get good results using those libraries. They are optimize for size since you could only go up to 32KB without bankswitching.

 

I applied my knowledge that I gain from Colecovision over to the intellivision. IntyBASIC does a great job with my insanity coding. I don't have to worry about TOKEn issue for forgetting the ; Or missing } which will cause problem. Both Colecovision homebrew kit and IntyBASIC are great and coded by talented people.

[intvnut]

* but I will never, EVER enjoy writing

 

if (condition) {

 

do stuff;

 

}

 

OK agreed there: I prefer the opening curly in a place where I can align it with the closing curly. And that never happens reasonably if the open curly is on the same line as the if or for statement that inspired it.

 

 

 

Doing something like

for(ID=0;ID<=5;ID++){
if(birdx>objectx[ID]-10 && birdx<objectx[ID]+10){
if(birdy>objecty[ID]-10 && birdy<objecty[ID]+10)
{ObjectGet();}}
}

will give, Flappy.c:2879: warning 94: comparison is always false due to limited range of data type.

 

Ok, that just sounds like a terminally broken compiler. If it's giving you warnings that are so obviously wrong, that's worse than having the warnings at all. It's actively wasting your time. (That's assuming it's warning for the 'for' loop, and not the if-statements.)

 

Sure, some warnings (such as signed vs. unsigned comparison) are maybe a bit marginal, but what you're showing is beyond marginal and actively detracting from development. Oy!

Edited July 16, 2015 by intvnut

[Kiwi]

Ok, that just sounds like a terminally broken compiler. If it's giving you warnings that are so obviously wrong, that's worse than having the warnings at all. It's actively wasting your time.

 

Sure, some warnings (such as signed vs. unsigned comparison) are maybe a bit marginal, but what you're showing is beyond marginal and actively detracting from development. Oy!

Fortunately I am stubborn and don't listen to the warnings,so I resumed working on the project. The project was completed and released even with the warnings. For my Coleco current project, I replaced all of the >= with !=.

 

With IntyBASIC, the console goes very fast and then close since I use Window's Run command to compile the code, and same with as1600. If it doesn't produce a ROM, or didn't make a new ROM to replace the old one, then I'll check the lst log to see what warning and ERRORs is being produce.

[intvnut]

With IntyBASIC, the console goes very fast and then close since I use Window's Run command to compile the code, and same with as1600. If it doesn't produce a ROM, or didn't make a new ROM to replace the old one, then I'll check the lst log to see what warning and ERRORs is being produce.

 

 

If you wrap it in a batch file, you can add IF ERRORLEVEL 1 PAUSE to keep the window from disappearing when there's an error.

[+nanochess]

Now updated to IntyBASIC v1.2

 

http://atariage.com/forums/topic/241446-intybasic-12-the-good-things-are-now-better/