wishlist for NXC

Discussion specific to NXT-G, NXC, NBC, RobotC, Lejos, and more.
nxtboyiii
Posts: 366
Joined: 02 Oct 2010, 07:08
Location: Everywhere

Re: wishlist for NXC

Post by nxtboyiii »

Or the ability to efficiently read/write to the display screen memory. (We could apply our own transforms by developing our own libraries.)
Yes, that would be really good. Then we could have(as you said) many functions for morphing things on the nxt screen.
Thanks, and have a nice day,
nxtboy III

programnxt.com
HaWe
Posts: 2500
Joined: 04 Nov 2014, 19:00

Re: wishlist for NXC

Post by HaWe »

the HT Sensor mux port addressing like e.g.
msensor_S1_1 or
msensor_S2_3
are currently way too complicated to handle.
E.g., if you got 4 US sensors at an smux to S1 and an additional smux with 4 analog sensors at S2, you have to do it currently (IIRC) by HT cmds like

Code: Select all

distance[0] = smuxSensorLegoUS(msensor_S1_1);
distance[1] = smuxSensorLegoUS(msensor_S1_2);
distance[2] = smuxSensorLegoUS(msensor_S1_3);
distance[3] = smuxSensorLegoUS(msensor_S1_4);
ADvalue[0] = smuxSensorRaw(msensor_S2_1);
ADvalue[1] = smuxSensorRaw(msensor_S2_2);
ADvalue[2] = smuxSensorRaw(msensor_S2_3);
ADvalue[3] = smuxSensorRaw(msensor_S2_4);
This requires much code to be written and ends up in a kind of spaghetti code.
Also, if later on a NXT port changes, everything of the msensor_SN_M stuff has to be written new again.

it would be much easier if we had 2 seperated port parameters, 1 for the NXT port, and 1 for the mux port, like
HTsmuxSTYPE(NXTport, HTport)
e.g.:

Code: Select all

for(i=0; i<4; ++i) {distance[i] = HTsmuxLUS(S1,i); ADvalue[i] = HTsmuxRAW(S2,i);}
then it would be possible to set e.g.
#define USmux S1
#define ADmux S2
and program development and readjustments will be much more efficient and flexible.
muntoo
Posts: 834
Joined: 01 Oct 2010, 02:54
Location: Your Worst Nightmare
Contact:

Re: wishlist for NXC

Post by muntoo »

The following prints 1010 instead of 00001010:

Code: Select all

	printf("%08s", "1010");
Image

Commit to LEGO Mindstorms Robotics Stack Exchange:
bit.ly/MindstormsSE


Commit to LEGO Stack Exchange: bit.ly/Area51LEGOcommit
HaWe
Posts: 2500
Joined: 04 Nov 2014, 19:00

Re: wishlist for NXC

Post by HaWe »

printf is a wrap around FormatNum which does not support "%s" format strings.
What actually happens is that it's doing anything but formatting by "%s" in this case.
But as I wrote myself here in the wish list some months (or was it even years) ago:

a ANSI C like (stdio) print and printf would be appreciated...!
HaWe
Posts: 2500
Joined: 04 Nov 2014, 19:00

Re: wishlist for NXC

Post by HaWe »

I'd wish to have more NXC command which have the same name as the original ANSI C cmds.
E.G, C uses mostly Beep(freq, duration), in NXC we have PlayTone(freq, duration) which does actually the same - so why not use Beep right from the start but create a sort of custom cmd name?
PlayTone should be erased out of the API and just Beep should be implemented, so PlayTone is free to use for individual function names.

For Time C uses time() and clock() and not FirstTick or CurrentTick - so why not drop the latter and not use the first ANSI like ones?

The same it's about StrLen and strlen, the first one is redundant and could be erased out of the API because the 2nd is the C cmd

just 3 examples, there actually are many more issues of this kind.
afanofosc
Site Admin
Posts: 1256
Joined: 26 Sep 2010, 19:36
Location: Nashville, TN
Contact:

Re: wishlist for NXC

Post by afanofosc »

I am pretty sure that I won't ever add Beep and remove PlayTone. Or do much more with the NXC API other than add functions for new devices.

You can edit nxc_api.txt and delete all the stuff you don't like and add your custom functions to it. Then click the Default button on the API tab of the Preferences dialog and your custom version of the NXC API will be what shows up in the Code Completion list and Code insight hints as well as highlighted according to your preferences for the Command element type.

You can post your revised nxc_api.txt file and custom header file if you want to promote your alternate API. You can do the same with nxc_constants.txt if you prefer a different #define constant naming convention or capitalization style.

John Hansen
Multi-platform LEGO MINDSTORMS programming
http://bricxcc.sourceforge.net/
linusa
Posts: 228
Joined: 16 Oct 2010, 11:44
Location: Aachen, Germany
Contact:

Re: wishlist for NXC

Post by linusa »

doc-helmut wrote: If it should be as close as possible to Lego FW hotchpotch it should be called NXH or If it should be as close as possible to Lego FW gibberish we should call it NXG.
No. NXC is NotXC, the language you want should be called XC, or just C. I gave reasons for my opinion, and on this wishlist it is my wish that the current naming will be kept. You wish, I wish, all cool.
doc-helmut wrote:we talk about nxC which should be as close as possible to C.
That is your wish, cool, but I don't share your opinion. As others said, NXC has different priorities (some of them made it very popular) -- and there already are ANSI C implementations for the NXT.
doc-helmut wrote: But it was a good and smart decision to make it C like and call it NXC (not exactly C, admittedly), so it should mimicri C keywords (and syntax) as exactly as possible.
We currently have PlayTone - either how Lego hottchpotch calles this, we may better call it Beep.
I don't know if Beep is in the C standard (if so, please link), but aren't you confusing actual language with API? The C syntax and keywords are the core elements. How important is the rest? How many devices that support C can actually beep? How many do have screen / a console / a filesystem? How many have motors or sensors? Where do you draw the line with the naming?

The whole discussion of how to name this and how to design that is a thing you can do when designing NXC2. But NXC has legacy code and a huge userbase.
doc-helmut wrote: And also we have C compatible strlen - so why have a redundand StrLen?
Simple: "For historic reasons". Yeah, it's not nice. But that's life. The decision to actually remove API calls or keywords from a language is a drastic one. Look at the history of software. There are great usenet discussions about similar design decisions for Linux, e.g. Linus Torvalds' opinion in the ext4 discussion. App developers were doing things "the wrong way", and he argued to keep this "wrong way of file access" supported just to not break legacy code and keep incorrectly written apps running correctly.

If I couldn't compile my old programs with a newer compiler version of NXC, I'd be seriously annoyed, and many members of the community. This style of change is about community and product management, not a technical decision.

The appropriate way to solve this issue is forking. Create a fork, and if it's good, it might catch on. Great things have emerged that way. But cutting off a solid userbase is not an option.
RWTH - Mindstorms NXT Toolbox for MATLAB
state of the art in nxt remote control programming
http://www.mindstorms.rwth-aachen.de
MotorControl now also in Python, .net, and Mathematica
mightor
Site Admin
Posts: 1079
Joined: 25 Sep 2010, 15:02
Location: Rotterdam, Netherlands
Contact:

Re: wishlist for NXC

Post by mightor »

The topic of removing non ANSI-C functions and replacing them with more C-like functions ends right now. John has stated it will not happen. Period.

- Xander
| My Blog: I'd Rather Be Building Robots (http://botbench.com)
| RobotC 3rd Party Driver Suite: (http://rdpartyrobotcdr.sourceforge.net)
| Some people, when confronted with a problem, think, "I know, I'll use threads,"
| and then two they hav erpoblesms. (@nedbat)
mattallen37
Posts: 1818
Joined: 02 Oct 2010, 02:19
Location: Michigan USA
Contact:

Re: wishlist for NXC

Post by mattallen37 »

The new fast I2C is wonderful, but I have found one issue. If you try reading a sensor, and it isn't plugged in, not only does it crash the program but it crashes the NXT (freezes and needs to be restarted). I would rather it just crash the program (much more convenient).
Matt
http://mattallen37.wordpress.com/

I'm all for gun control... that's why I use both hands when shooting ;)
mightor
Site Admin
Posts: 1079
Joined: 25 Sep 2010, 15:02
Location: Rotterdam, Netherlands
Contact:

Re: wishlist for NXC

Post by mightor »

IMHO, it should just return a normal I2C read error, rather than crash the program. Transient errors are to be expected, which is no different from a disconnected sensor.

- Xander
| My Blog: I'd Rather Be Building Robots (http://botbench.com)
| RobotC 3rd Party Driver Suite: (http://rdpartyrobotcdr.sourceforge.net)
| Some people, when confronted with a problem, think, "I know, I'll use threads,"
| and then two they hav erpoblesms. (@nedbat)
Post Reply

Who is online

Users browsing this forum: No registered users and 11 guests