GPS Module, Extensions for handling other sentences, and u-blox NEO-6M GPS receiver

You are reading a single comment by @allObjects and its replies. Click here to read the full conversation.

•

Gordon
Cool - yes, start/stop would miss out on some lines - I don't think that would cause problems.

My feeling with enable is it's actually not that much more inefficient to implement it in the callback fn (after all, it only gets called once a second, at most 10 times a second).

'root scope' - It's not really the correct term - you'd probably be more used to 'Closure'/'Lambda'. For instance the obvious example:
```
var a = (function() {
  var z = 42; // <----- here
  return function() { return z; };
})();
```
Also applies to modules, which are implemented a lot like:
```
// --- 
var a = require("foo").connect();
// foo.js
var z = 42; // <----- here
String.prototype.hello = 42;
exports.connect = function() { return z; };

// Goes to
var a = (function() {
  var exports = {};
  // start module code ----------------
  var z = 42; // <----- here
  String.prototype.hello = 42;
  exports.connect = function() { return z; };
  // end module code -----------------
  return exports;
}).connect();
```
So what I'm saying is, if you define z, it's there forever, because it's part of the closure of the connect function. But if you define String.prototype.hello, that can be deleted.

•

allObjects in reply to @Gordon

I'm not concerned about missing out on lines. I see more the challenge in getting partial / incomplete lines (GPS sentences) on (re-)start/resume. On the other hand, the very rigid tag extract and check would then just make the partial line to be skipped too. The next one though is pickup for sure, which - with (most) receiver's default configuration - shows up right within the next second (I have seen increasing the sentence (set) frequency on u-blox receivers, which of course requires also to increase serial's speed/baud rate in order to send the - also configurable set of - messages within the configured time period.

Thanks for backfilling the term 'root scope'. I like it also for enforcing 'privacy' / enhanced encapsulation... (as 'private' in Java). It is a neat, JS distinctive thing to be able to establish things in the function/method body definition that then can only be seen from within the 'definition-time-scope' and will 'stay for ever' - or at least as the function/method is not garbage collected . The same happens to all things defined in modules when not exported... because it happens all in require()'s scope... (that's why the current GPS module's handleGPSLine() function is not accessible / lacks/suffers from accessibility - lacking or benefiting from absent accessibility is though always dependent on the design intention).

In GPS module I have seen single method export... and in my embedded code, I did emulate the multiple exports because require() returned that kind of object (see line 56 in post http://forum.espruino.com/comments/11857912/ - part 4 of 5). From your code snipped I conclude that you can have a 'collection' of exports... - or, more precisely - an object (instance) with named properties - or plain js object - POJSO (like POJO as in Java). I hoped for and assumed something like that... and now I see how it is done.

Because in the Espruino and a-like realm most challenges come from connecting to things / devices - and module help with that a great deal: hide the nitty-gritty, always the same looking things and (can also) provide additional convenience (methods). I see though the module technique not limited to that only and can see many other application that would have something else than connect as the initial method to get going. I could also see start and stop as a different scope than connect/disconnect, because start, stop, pause, and resume have a different feel to me... almost as we distinguish also boot/cold-start/warm-boot/start,... similar like sleep, deep sleep, and hibernate... none of these are reset or boot. These various types of processes or sequences/sets of life-cycle steps exist all in their own rights....

Oooops: I have - again - to remind my dreamy mind that with Espruino I deal with (very) limited resources... and thus many of these processes have to collapse into dedicated, simplified ones - just as needed. It's almost going back 50 or 60+ years in computing, when computers were built for a distinctive task... Only later systems, such as, for example, IBM System /360 computer announced early 60' were declared as a general purpose machines - not just to do Operations Research (OR), or Accounting, or... you name it. The key logo / badge for this first IBM general purpose computer was a compass rose: you can go any direction with this thing (see http://www.computerhistory.org/revolution/mainframe-computers/7/161).

Today, with 'cheap' hardware available in masses, we can go back to the future and 'back' to dedication... and there is need for a big warehouse, a power plant, and cooling towers for operating such things. I bet that Espruino has multitude of processing power and with wifi connectivity unlimited storage compared to /360 systems with relative little memory - some models with much less and some with more then Espruino - and 7+MB disk storage... and /360s were called a Main Frames... ;-): Everything has it's season.

GPS Module, Extensions for handling other sentences, and u-blox NEO-6M GPS receiver

About

Espruino