Search results for:

I've just dropped some RegExp check and polyfilled internally what was missing in Espruino, in case you'd like to have ES6 alike syntax for classes, with ES7 ability to compose through mixins/traits, I'd like to link you at this project of mine, called es-class

The minified version is not hand crafted/compacted explicitly for Espruino, but with plain 3.5kB (1.6kB gzipped) you get granted cross platform compatibility, including the MIPS node version of Arduino Yun, and basically all other JS engines out there I could verify.

Key features are:

1. semantic Class({..}) declaration
   
2. extends and handy this.super(...) ability
   
3. static properties definitions
   
4. bonus for mixins/traits via with: [ ... ] plus implements for light checks on expected interfaces
   
   

As Gordon asked me in another thread, you ain't gonna need probably all these features, but maybe you'd like to write some code that looks like modern JS without breaking your Espruino.

Performance are also as good as vanilla JS, only light overhead is classes definitions, luckily this happens only once at bootstrap so you won't probably notice that.

All tests are green except those based on ES3 non standard get/set literal objects syntax which is not implemented here, and some tiny instanceof gotcha that will hopefully be solved soon since Gordon has already a bug to work on.

I hope someone will find it handy.

Best Regards

Actually I've just realized Function.bind is there indeed but Function.prototype.bind is not ... but (function(){}).bind is there too ... oh well, good to know (sort of weird)

As temporary work around on top of your file:

Function.bind||(Function.prototype.bind=function(c){var f=this,a=[].slice.call(arguments,1);return function(){a.push.apply(a,arguments);return f.apply(c,a)}});

In case you don't care about handling extra arguments ...

Function.bind||(Function.prototype.bind=function(c,f){f=this;return function(){return f.apply(c,arguments)}});

Until it's solved, of course

P.S. you've probably checked it already, but this would be already a great thing to have.

It's MIT Style License, it's deployed in micro controllers, and it's a subset for RegExp, a 1.5 subset.

It's called ure: http://docs.micropython.org/en/latest/library/ure.html#module-ure

Here the module used in micro python:
https://github.com/micropython/micropython/blob/a86d40ccd437fe0235c09426ef6d552b968d86e8/extmod/modure.c

and here the folder with the lib:
https://github.com/micropython/micropython/tree/a86d40ccd437fe0235c09426ef6d552b968d86e8/extmod/re1.5

what you're trying to do on Espruino where you need this?

You have, as example, an opened bug about a comment weird behavior where the user coded via ES3 regular "classes" ... that code contains syntax usable since about ever and it would work everywhere.

I have a simple little module that brings better looking and more semantic classes in and when you deal with hardware you might want to use these patterns too (like the other user did).

Accordingly, having instanceof not working as expected is surprising and inconsistent, while I agree propsrtyIsEnumerable is a less common method that won't bring much in here.

The missing RegExp should at least be mentioned on top of Espruino capabilities (if not already, couldn't find it) ... I often give them for granted, so I might lazily check /something/.test(command) instead of command.indexOf(something) > 0 and for cross platform modules is very good to know limit.

About that, I wonder what's the process to submit a module to the list of already available one in espruino, in case a working NPM solution would take long time.

Thank you

I wouldn't expect toLocaleString to be part of the Object.prototype since there's no local in Espruino, but I found it weird propertyIsEnumerable and isPrototypeOf are not implemented.

A quick and dirty solution would be the following:

Object.prototype.propertyIsEnumerable=function(p){for(var k in this)if(k==p)return this.hasOwnProperty(k);return false};
Object.prototype.isPrototypeOf=function(o){return o instanceof this.constructor};

However, instanceof is also broken in Espruino. Above code uses the constructor but a proper check would be the equivalent of the following:

Object.prototype.isPrototypeOf=function(o){
  function F() {}
  F.prototype = this;
  return o instanceof F;
};

// this should be true
Object.prototype.isPrototypeOf({});

Latter check is false but it should be true. Ideally, isPrototypeOf and propertyIsEnumerable should be implemented natively.

Last question for now, I'v enoticed that RegExp and in general regular expression /syntax/ is not implemented. Is that too big to bring in natively or it's something planned already?

Thanks

In fact I think even prefixing your module with var module=this; will work.

watch out, the this inside a module is the exports itself, not the module ... I know it's quite confusing but better knowing this before doing any work.

console.log(this === module.exports);

If you require a file like that, the log is true in (node|io).js

I personally would be already happy with a fully compliant ES3 code-base but the fact Object.getOwnPropertyDescriptor is there, together with Object.getOwnPropertyNames, mislead me because if there's no way to define enumerability or descriptors these two look like impostors.

That being said, I agree you usually go easy with micro controllers and JS, without bringing absurd alchemies in, but since Espruino supports and promotes the usage of modules, you surely know that module and imported API + getters/setters play usually very well, and give developers the ability to create code that is more pleasant to use.

I just wanted to understand the rational behind those methods and I got it, I also hope those methods could make it without bloating too much the core.

Regards

OK, I wrote it not so clear indeed ...

This is current/common status in npm

// the module
module.exports = function () {
  console.log('I am the module');
};


// the consumer
var module = require('my-module');
module(); // I am the module

With current Espruino there's no way to directly export the object or the function, you can only attach properties to the exports variable.

Will this be improved to reflect common npm modules pattern or the module object won't ever be exposed?

Thanks

In Espruino Pico 1v76 I've noticed that Object.getOwnPropertyDescriptor is present, and returns a descriptor object, but everything else available in ES5 to actually define properties through descriptors is missing:

Object.defineProperty;
Object.defineProperties;
Object.create(null, {test: {get: function () {return 123}}}).test;
Object.create(null, {test: {value: 456}}).test;

All these are undefined and I wonder why, at this point, Object.getOwnPropertyDescriptor is available. It kinda misleads features detection.

As summary: is there any plan to bring the ability to define properties through descriptors, or, if not, could we just drop getOwnPropertyDescriptor so no code would be confused about its presence?

Thanks!

uhm ... OK, thanks for the info. If I load it manually I get this error:

ncaught Error: Field or method "exports" does not already exist, and can't create it on undefined
 at line 4 col 428
...OwnPropertySymbols");module.exports=Object.getOwnPropertySym...

And looking at "official" modules I see module is never used, only exports is.

It is quite common in npm-land to module-exports = ... so that you can just require what's exported. It looks like in Espruino this pattern is not allowed: any specific reason for that?

Back to the fragmentation quick chat we had on twitter few days ago, having a different way to export for Espruino only would be somehow weird for most modules.

I understand not every module will or should run in here, but I've been coding small modules since about ever and I'm curious to see what works here and how well.

Thanks

I'm, trying to require quite small modules through the Web IDE and on a Pico board 1v76

No matter what I require, it's always the same:

WARNING: Module "anything" not found

I'm requiring on the right side, which is also graphically telling me every time that module hasn't been found.

this module is just an example, but reading the documentation I also spot the following:

the Web IDE will automatically look online for minified versions of the modules you need, download them, and load them onto the board.

In node.js and io.js world I've never thought minification would have been useful but I understand its value for small devices like the Espruino Pico.

However, I wonder if there's any official procedure able to make a module compatible with the pico: any specific field in the package.json file? Should the main file be the one minified, called .min?

Please let me know what I should do in order to write Espruino Pico capable code, thank you.