View unanswered posts | View active topics It is currently Sun May 27, 2018 1:39 am

Reply to topic  [ 3 posts ] 
WARNING: RobotC bug prevents having more than 100 methods!!! 
Author Message

Joined: Fri Oct 24, 2008 8:58 am
Posts: 87
Post WARNING: RobotC bug prevents having more than 100 methods!!!
Okay, so I was really ticked off at 3:00am when I ran into this bug (again). I posted the first time about this but the developers never did anything about it...and now that I know what it is I realize they didn't even remotely try. Because they should have been able to tell me immediately what the issue was.

So now after a some sleep I'm only a little ticked off. Not because of the bug or even the limitation to RobotC, but because I believe the developers knew about the limitation (maybe even the bug too), and are intentionally trying to hide this limitation. If they were being up front they'd say on the description page. "Hey, this is RobotC. Its sorta like C but for Robots. Also you can only have 14 files and 100 functions, but its really alot like C so use it."

So the limitation is simple. You can't use more than 100 functions in a program. One nice thing is the compiler stats tell you how many you have. DEVELOPERS: WHY DIDN'T YOU SAY SOME THING LIKE "using 25 of 100 methods". Its just common sense to list limits next to usage!

The lack of documentation is just laziness, but the bug is something truely awesome to behold. Talk about a total lack of unit testing!

If you happen to use more 7-8 functions in each of your 14 allowed files ... then when you try to call the 101st function you get a RUNTIME ERROR. Yes, that's right. The compiler happily compiles as many functions as you are willing to type, but it CAN'T ACTUALLY CALL THEM.

I'm sorry but the excuse that "99.9% of RobotC users over the past 3 years haven't needed this functionality" just doesn't cut it. I call your bluff. I think its a limitation of your runtime and like all the other limitations you just fail to document it. Because I don't honestly believe you could successfully build something a complex as RobotC and the different firmwares and "overlook" the fact that you have a limit on the number of functions or files allowed in a program.

I can't even begin to imagine why this isn't at least flagged by the compiler. This lack of compiler warnings/errors and the total lack of documentation related to exactly how RobotC isn't ANSI C seems to say you're intentionally hiding RobotC limits. WE'RE PROGRAMMING A MICROCONTROLLER WE EXPECT LIMITS. WE JUST NEED TO KNOW WHAT THEY ARE BEFORE WE RUN HEADFIRST INTO THEM!

Oh, for those who don't want to type 101 functions for yourself to see the bug. Here's a test file to play with. Even the debugger can't break on the 101st function call :)

int foo0() {return 0;} int foo1() {return 1;} int foo2() {return 2;} int foo3() {return 3;}
int foo4() {return 4;} int foo5() {return 5;} int foo6() {return 6;} int foo7() {return 7;} int foo8() {return 8;}
int foo9() {return 9;} int foo10() {return 10;} int foo11() {return 11;} int foo12() {return 12;} int foo13() {return 13;}
int foo14() {return 14;} int foo15() {return 15;} int foo16() {return 16;} int foo17() {return 17;} int foo18() {return 18;}
int foo19() {return 19;} int foo20() {return 20;} int foo21() {return 21;} int foo22() {return 22;} int foo23() {return 23;}
int foo24() {return 24;} int foo25() {return 25;} int foo26() {return 26;} int foo27() {return 27;} int foo28() {return 28;}
int foo29() {return 29;} int foo30() {return 30;} int foo31() {return 31;} int foo32() {return 32;} int foo33() {return 33;}
int foo34() {return 34;} int foo35() {return 35;} int foo36() {return 36;} int foo37() {return 37;} int foo38() {return 38;}
int foo39() {return 39;} int foo40() {return 40;} int foo41() {return 41;} int foo42() {return 42;} int foo43() {return 43;}
int foo44() {return 44;} int foo45() {return 45;} int foo46() {return 46;} int foo47() {return 47;} int foo48() {return 48;}
int foo49() {return 49;} int foo50() {return 50;} int foo51() {return 51;} int foo52() {return 52;} int foo53() {return 53;}
int foo54() {return 54;} int foo55() {return 55;} int foo56() {return 56;} int foo57() {return 57;} int foo58() {return 58;}
int foo59() {return 59;} int foo60() {return 60;} int foo61() {return 61;} int foo62() {return 62;} int foo63() {return 63;}
int foo64() {return 64;} int foo65() {return 65;} int foo66() {return 66;} int foo67() {return 67;} int foo68() {return 68;}
int foo69() {return 69;} int foo70() {return 70;} int foo71() {return 71;} int foo72() {return 72;} int foo73() {return 73;}
int foo74() {return 74;} int foo75() {return 75;} int foo76() {return 76;} int foo77() {return 77;} int foo78() {return 78;}
int foo79() {return 79;} int foo80() {return 80;} int foo81() {return 81;} int foo82() {return 82;} int foo83() {return 83;}
int foo84() {return 84;} int foo85() {return 85;} int foo86() {return 86;} int foo87() {return 87;} int foo88() {return 88;}
int foo89() {return 89;} int foo90() {return 90;} int foo91() {return 91;} int foo92() {return 92;} int foo93() {return 93;}
int foo94() {return 94;} int foo95() {return 95;} int foo96() {return 96;} int foo97() {return 97;} int foo98() {return 98;}
int foo99() {return 99;} int foo100() {return 100;}

task main() {
foo0(); foo1(); foo2(); foo3(); foo4(); foo5(); foo6(); foo7();
foo8(); foo9(); foo10(); foo11(); foo12(); foo13(); foo14(); foo15(); foo16(); foo17();
foo18(); foo19(); foo20(); foo21(); foo22(); foo23(); foo24(); foo25(); foo26(); foo27();
foo28(); foo29(); foo30(); foo31(); foo32(); foo33(); foo34(); foo35(); foo36(); foo37();
foo38(); foo39(); foo40(); foo41(); foo42(); foo43(); foo44(); foo45(); foo46(); foo47();
foo48(); foo49(); foo50(); foo51(); foo52(); foo53(); foo54(); foo55(); foo56(); foo57();
foo58(); foo59(); foo60(); foo61(); foo62(); foo63(); foo64(); foo65(); foo66(); foo67();
foo68(); foo69(); foo70(); foo71(); foo72(); foo73(); foo74(); foo75(); foo76(); foo77();
foo78(); foo79(); foo80(); foo81(); foo82(); foo83(); foo84(); foo85(); foo86(); foo87();
foo88(); foo89(); foo90(); foo91(); foo92(); foo93(); foo94(); foo95(); foo96(); foo97();
foo98(); foo99(); foo100();
while(true) {wait1Msec(10);}

I'm going to write a Python script to automatically refactor code to remove the least needed functions. So I'll post that when I get it done. Right now my robot code is sitting at exactly 100 methods. I've been sitting right at the bleeding edge of disaster for a week and never knew it. And I still need to put autonomous back in :(

Thu Feb 26, 2009 11:36 am
Site Admin
Site Admin

Joined: Wed Jan 24, 2007 10:42 am
Posts: 620
Post Re: WARNING: RobotC bug prevents having more than 100 methods!!!
ROBOTC's intention was never to be the "all encompassing/fully featured ANSI C programming environment" for the high end programmer. I apologize if you disagree with this.

That being said, in regards to your 14 include files and 100 functions/methods limitations, these limits were put in place during development as what we thought would be upper cases that no one would run into, keeping in mind our original intentions of making an easy to use programming language for beginners and also our thought processes during initial development. Honestly, you're the first person to bring this to our attention in the 4+ years that ROBOTC has been in development, so thank you for that. These limits can and will be raised without too much work and implemented in a new version of ROBOTC in a short period of time.

I will however comment that shouting that "OMG ROBOTC IS BROKEN YOU GUYS SUCK AT TESTING AND ARE LAZY" is not a very good way to get our attention. If you have suggestions on improving the documentation or feature requests or anything else, being even slightly respectful could go a long way in us listening.

With ROBOTC users growing in numbers, more advance users have pointed out some of the shortcomings of ROBOTC and with that we're grateful for the feedback. We are working on making improvements all the time and have actually implemented some of the suggestions from our users on the forums. With a development team of about 1.5 people (I work on many other projects), it's difficult to meet all users requests with each release.

We unfortunately cannot release a new version of ROBOTC every single time someone finds a minor issue that only affects a single team or a single person. With ROBOTC being used in competitions, we have to be very aware of our releases, both beta and public, as it is difficult to ensure that all users of ROBOTC with a given competition are using the same version to ensure a level playing field. It's the reason that 1.46 is the current version for FTC, even though we're up to 1.51 in our own internal development.

Timothy Friez
ROBOTC Developer - SW Engineer

Thu Feb 26, 2009 1:15 pm

Joined: Fri Oct 24, 2008 8:58 am
Posts: 87
Post Re: WARNING: RobotC bug prevents having more than 100 methods!!!
I do appreciate the effort you guys have made with RobotC. Its a much better alternative to Labview or NXT-G.

Actually, I don't care that RobotC isn't exactly ANSI C. But most of the issues I've seen are a long way from "high end programming".
There are some very basic things that should work but don't.

My real point was that after using RobotC for several months, I have to conclude that either: 1) these issues like #of files or #of functions were overlooked/missed (and then yes that is lazy programming/testing) or 2) they are "known" problems and we as the users are just kept in the dark about them. Clearly its the latter.

So actually I wasn't shouting to you that RobotC is broken (you already knew that) I was letting other people know that there is a limitation they don't know about and could waste alot of their time fighting against.

My message to you was more like: "Hey, why did I have to waste my time with this when you knew about it all along?".

I understand that some limit has to exist. I never asked for them to be fixed right away. Yes, you have a large audience among the different competitions and I understand that releases need to be as controlled as possible.

My hope is that you use the growing exposure and even monopoly in many cases to become a better product. My concern is that if you always shoot down legitimate bugs as just being "advanced features" outside the scope of your product, and alienate the "advanced users" that have the technical knowledge to stretch the product to find its limits, then you never will.

Thu Feb 26, 2009 4:01 pm
Display posts from previous:  Sort by  
Reply to topic   [ 3 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.