wishlist for NXC

[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.

[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]

The following prints 1010 instead of 00001010:

Code: Select all

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

[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]

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]

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

[linusa]

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.

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.

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.

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.

[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

[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).

[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