software compatibility

[mikebittmann]

A question for Zander: What program languages will work in the new EV3? I'm new to mindstorms and the icon based programming seems pretty easy at first glance. (I've never done any programming) You guys (the pros) wouldn't be running these other programming languages if there were not some great benefit. Can I get a short rundown on what you use and why?

Mike

[mightor]

Right now there's only the standard programming language available for the EV3, made by National Instruments. I am pretty sure John Hansen has plans, as do a couple of others, including myself. I am hoping for ROBOTC to be ported to this platform, but that is between LEGO Education and Robomatter. I am pretty sure Java will be made available as soon as we get our hands on the source code. I'd like Python to be made to work on this platform. The nice thing is that once the platform becomes generally available, it'll be no time before we see dozens of programming languages available for this. I'm looking forward to seeing what the community of hackers will do with this!

= Xander

[tcwan]

Right now there's only the standard programming language available for the EV3, made by National Instruments.
= Xander

Thanks for the info, the press releases and writeups did not touch on this.
I guess it's probably the reason why the current NXT-G 2.x has not been updated for the recent Mac OS X versions.

[mspall]

Xander,

I too would like to be able to program in python on the EV3. It would also be good for teaching programming. I also like the idea of the community being able to create python libraries for sensors, input filters such as Kolmogorov–Zurbenko, and controllers such as PID, much like the good quality math and science libraries that come with many language distributions.

[HaWe]

why not simply use a common standard ANSI C compiler ?
C compilers of any platform already come with a huge chunk of mathematic and statistic header libraries which are ANSI compatible and thus cross-compatible to headers of even other ANSI C compilers and so easily could be #included.
I guess, e.g. gpp with it's current libraries might easily target the Linux platform which will come with EV3-ARM9.

AND we might have turbo fast genuine ARM machine code on a already MT-capable platform, as fast as genuine asm machine code.

[tcwan]

AND we might have turbo fast genuine ARM machine code on a already MT-capable platform, as fast as genuine asm machine code.

I'm not parsing this sentence. How is ARM machine code not genuine asm machine code?

If by 'asm' you're referring to NXT Byte Code, then ARM machine code should be FASTER than NBC unless you have an incredible Just-In-Time byte code compiler.

Think Java Byte Code running on your PC. It is not going to be faster than native .exe files except in the latest versions of Java with much improved JIT support where it may reach parity.

[mightor]

why not simply use a common standard ANSI C compiler ?
C compilers of any platform already come with a huge chunk of mathematic and statistic header libraries which are ANSI compatible and thus cross-compatible to headers of even other ANSI C compilers and so easily could be #included.
I guess, e.g. gpp with it's current libraries might easily target the Linux platform which will come with EV3-ARM9.

gpp is the pre-processor, gcc is the compiler. The reason people use languages like Java and Python is because they don't like ANSI C and sometimes speed is not as important as convenience. The problem getting ANSI C to work for EV3 is not the actual compiler, but the glue (userspace libraries) to talk to the hardware. The compilers are already there.
Helmut, seeing as you have trouble writing things like RS485 communication libraries in high level languages like NXC and ROBOTC, what makes you think you can handle programming in native assembler for the ARM9? However, I don't want to discourage you before you even get going, so to get you started before the actual launch, you can perhaps check this out: http://stackoverflow.com/questions/2700 ... m-assembly

I look forward to seeing your first application!

= Xander

[HaWe]

gpp .. gcc... you probaly realize that this is currently not my world yet.
though it's a bit OT here, I hope that that old rs485 thing will be finally history because four EV3's should be able to be chained up by USB in order to address each remote I/O just as if it was a local I/O. That's more or less just what I have been looking for for NXC/NXT since 6 years.
3 or 4 I/Os each are far too poor, and if 4 bricks can be connected then also all up to 16 +16 I/Os must be easily accessable.
Of course I'm not able to write these low - or high level API functions by myself - I am writing AI programs for which I need to have them all-in, I generally don't intend to program API functions.
Of course asm is no issue at all to me, I only mentioned asm because real C compilers can generate code which is quite as quick a asm.
But of course speed actually is an issue, AI programs (just as chess move generators or neural nets or Astar or particle filters) need lot of calculation power (what they have got by working with genuine machine code) and are insanely speeded up when using pointers.
But I don't want to start a new discussion here about this unpleasant deficiency, it's just because you asked me - and I honestly hope your question was out of genuine interest in this subject and not just sort of rhetorical!^^

[mightor]

...and are insanely speeded up when using pointers.

I am not sure how pointers will help with speed, could you elaborate?

Taken from http://stackoverflow.com/questions/6919 ... speed-in-c

When you access a "variable", you a) look up the address, and b) fetch the value.

Remember - a pointer IS a variable. So you a) look up the address (of the pointer variable), b) fetch the value (the address stored at that variable) ...

... and then c) fetch the value at the address pointed to.

So yes, accessing via "pointer" (rather than directly) DOES involve (a bit) of extra work and (slightly) longer time.

Before you start saying things, it is generally better to do a bit of research first. You say gcc is not your world yet, then perhaps it is better not to make bold statements yet either.

= Xander

[HaWe]

pointers:
e.g., for my chess program, I have to pass arrays char [129] hundreds of times for each move and all plys for all deepenings to multiple functions "by reference" (or passing a pointer to an array).
NXC always copies each array each time for each function pass what makes that extreeeeeemly slow , if I could access the memory address directly I could modify the values without any copy work.
The same it's about my Fourier transformation program or my neural net programs or my Astar when expanding nodes, which all work with different arrays passed to functions "by reference" muliple times (or passing a pointer to an array).

gcc/gpp was only an example of a compiler and it's libraries that already works for Linux (IIRC).
if gcc/gpp does not match that what I meant then another C compiler might do it hopefully.