Object.create() missing

Hi all,

It seems there is no implementation for Object.create().

https://developer.mozilla.org/en-US/docs­/Web/JavaScript/Reference/Global_Objects­/Object/create

I couldn't find this discussed anywhere, is this on the roadmap or is there a technical reason why this isn't implemented?

Regards,

Alex

No, it's not on the roadmap and afaik there's no technical reason why it's not implemented.

The main reason why it's not in there is that you appear to be the first person who has wanted to use it. Is there any reason that you can't use the 'polyfill' Mozilla provides for older JS implementations that don't support it (minus the exception stuff) - it actually just do what it's doing in your code, instead of doing Object.create?

if (typeof Object.create != 'function') {
    (function () {
        var F = function () {};
        Object.create = function (o) {
            F.prototype = o;
            return new F();
        };
    })();
}

There are multiple ways to work around this issue of course. I thought it would be great if all the functions in "normal" javascript would be supported on the espruino to make porting code much easier. I could put a few dozen lines of code at the top of my program to create shift() replace() and object.create() but ideally I shouldn't have to if they are normal javascript functions.

All of these functions caused runtime errors when porting running code from node and chrome to the espruino so I figured I'd mention it :).

Absolutely - I'd like to have it in eventually.

There is only so much space in the device though (and I only have so much time!), so I'm focussing on the most used bits first as I will almost certainly run out of space before everything gets implemented.

Perhaps having a module that implemented things like this might be a good idea - then people could pull it in if full compatibility was needed - it'd also be easier for extra functionality to be contributed to it.

That modulizing thing sounds very good to me, particularly if done at a low level (i.e. getting or not getting compiled at all!). For instance, I'm temped at writing (well, porting actually) a driver for the ENC28J60, and it's probably going to be quite a lot of code - not the driver itself, but the tcp/ip on top of that. Also there's other bits which aren't used in all projects (Waveform comes to mind).. so yeah making it possible to pick which parts of Espruino get included would be a very good idea. Trouble is.. I haven't had much luck so far in setting up a toolchain to cross compile the thing on osx (but I've seen a few posts here that could help)

If memory space is very tight, I'd happily pay extra for an espruino with one of the bigger chips mentioned in the advanced hack thread. If this all works out, we're planning to buy a lot of espruino's :).

That'd be cool - I have some ENC28J60 boards kicking around.

There's already support for compiling/not-compiling support for various things - for example FAT/Graphics/WIZnet/CC3000 can all be included or left out (and it should be relatively easy to add new support for networking devices now). It's not desperately pretty (mostly done in the Makefile) but it does work.

However my point was really that a JavaScript module (not C) is far easier for people to contribute changes to, and you can choose whether you want it at run time. It's no good having a bunch of code that's configurable if nobody can get the toolchain working :)

PS. @cephdon's changes had some tweaks for better compilation on Mac: https://github.com/espruino/Espruino/pul­l/333/files - Hopefully that'll get merged in next week.

In the interests of not making life really hard for yourself, you could just use a Ubuntu VM though - or it'd be nice if someone made a script for Raspberry Pi that would get all the required stuff to build Espruino. A bunch of people must have them kicking around, and it would solve all these problems.

Well don't tell Gordon ;) but the first thing I'll do when I get my microPython will be compiling Espruino on that. And maybe the opposite too, just for the heck of it!
Actually, the best thing in the world would be to put the STM32 on a socket of sorts, so that you could pick the best suited to the job.

I see your point about the js modules. Thing is.. people could just use the polyfill as suggested

Yes - so I'm suggesting just having a module with the polyfills in - people could then contribute easily when they found things missing, and when the actual C code got implemented, the polyfill could be removed....

@Loop,

You will want to use the arm-none-eabi-gcc version 4.7.3 (Carlson-Minot Mac OSX Intelx86 2013.05-23 Lite) from Code_Sourcery_2013.5-23. It produces the smallest code. I just took the binaries and placed them on my system and in my path.
Also, I don't know what IDE you use(or if you use one), but I looked high and low and the best one I could find was QT Creator (on osx), all of the others had issues debugging or were incredibly slow. You can find instructions online for how to import projects with existing code. It takes a bit of fiddling, but once you get used to it, the way they setup different configurations is kinds natural... just watch out if you edit the makefile...you have to do it in VIM mode to keep tabs in the correct places.

You will want to install gdu from coreutils.. I got it from macports. It is needed to check the size of your compiled binary to make sure it will fit inside of the device. Linux uses the du command for this, but the osx version doesn't have the correct options, that is why gdu is necessary.

From memory, I think thats all there is...then the code compiles (with my makefile changes) and you can run the target to write it to the device.