|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
||||||
|
||||||
|
a lot of work...
The proposed systems is going to be a lot of work, more than the estimates in the initial post (IMHO).
It is a valiant effort, but I think one that is going to be full of sneaky and subtle bugs. I am afraid that you will get something that ALMOST works, but not quite well enough to trust it to actually run your robot. The root of the problem is that PBASIC is very powerful but has some serious limitations. I am not sure that autocode generation will really help (whether it is a graphical interface or any interface) because the limitations are still there. For my money, I think that it is better to learn the Zen of PBASIC and deal with that. BUT... ...There are a few "macros" that if someone wrote, I would be very grateful for: 1) the ability to have a single "header" file for all modules with all variable, alias & constantant definitions. As it stands, when I use several programing slots, I have to have the same declaration in many files. This can lead to subtle errors if I fix something in one file and forget to fix it in another. 2) an IF-THEN-ELSEIF-ELSE structure 3) something like the "macro" function in C (or C++) 4) way of having common subroutine definitions that would allow a singe definition of a subrountine that is shared by multiple programming slots (subroutines with names like "GetData" & "PutData" come to mind). I am thinking about basically a VBasic program that would allow code to be edited in a single file on a standard text editor (e.g. Wordpad) and then sent through a string edit process that would include the header files, substitute the macros & other cool stuff like IF-THEN-ELSEIF-ELSE. The string editor would then break the code up into seperate files, one per programming slot. In an ideal world, the VBasic program would break up into the needed slots, but I suppose this would add more complexity than I think is worth the bother. I recommend just having some tags that let the code writer define the slots as needed. Finally, the Vbasic program would open the Parallax tokenizer/downloader/debugger and download the code, passing any errors back to the user. The last step of dealing with errors could be tricker than you might think (e.g. Is this problem the coder's fault or the Vbasic program's -- could lead to very confusing finger pointing, to say nothing of the error messages themselves). Anyway, this kind of code seems to me to be of much more use than the initial proposal. Does anyone else share my view? Joe J. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Obscure PBASIC for RoboEmu | rbayer | Programming | 1 | 28-03-2003 23:57 |
| PBasic 2.5 vs. 2.0 | Anthony Kesich | Programming | 6 | 09-02-2003 22:06 |
| PBasic Question | Melissa H. | Programming | 28 | 17-11-2002 18:53 |
| emulationFIRST (aka PBasic emulator) | Matt Leese | Programming | 5 | 30-06-2002 12:06 |
| PBASIC Loop Speed? | archiver | 2001 | 3 | 23-06-2002 23:46 |