3 May! On Wed, Apr 19, 2017 at 10:09 AM, Young-il Choi <[email protected]> wrote:
> > > Is it correct that next meeting will be *Wednesday 3 March 2017 ?* > > > > --------- *Original Message* --------- > > *Sender* : Jan Jongboom <[email protected]> > > *Date* : 2017-04-19 18:08 (GMT+9) > > *Title* : [jerryscript-dev] Meeting notes community call 19-04 > > > Hi all, > > Next meeting will be *Wednesday 3 March 2017, 3PM UTC, 4PM UK, 5PM CET, > 8AM PST, 11AM EST, midnight South Korea, 11PM Shanghai.* > > You can join the meeting via https://meet.intel.com/martijn.the/8VOOMYPR > <https://meet.intel.com/martijn.the/8VOOMYPR> > > Here are the meeting notes of today: > > *TL;DR:* > > ** Face-to-face meeting planned for September 2017 in Hungary.* > ** Will alternate schedule of community calls between morning/afternoon > EU, so US can join as well.* > ** Intel to work on module proposal for sharing native modules between > ports.* > > --- > > Heiko (Intel) > Martijn (Intel) > Zidong (Intel) > Szeged team > Jan (ARM) > Rob (ARM) > > Zidong: any projects who use JerryScript in production environment? It's > important for jerry-util to proceed. > Martijn: Pebble. > Szeged: None to our knowledge. > Jan: Neither on mbed. > > Heiko: what about products that are about to be released? > Martijn: Mark Juskin(?) is opening issues again, might be working on a > product. > Should reach out to him and others and see what they're running against > to. Fitbit. > > Hop.js could be, demo'ed at Embedded World on STM silicon. > > Alternating schedule US / EU? We lose maybe South-Korea. But Zephyr.js > could join, which is great. > > Next meeting scheduled 5PM CET on Wednesday in two weeks, see if people > can join. Zidong will try. > > Coming back from last meeting: jerryscript-util state. PR is openend, > looking for feedback right now. Martijn is happy about the discussion and > its flexible enough. > > Hungarian team, do maintenance work right now, not much new work. Want to > improve on existing ports. > > Martijn: Szeged was working on tooling, developer experience. Debugging > support. What's the plans there? What needs to be improved? > > Szeged: Long term project. Covers this year. Planning to work on memory > profiler. > > Szeged: Want feedback on the debugger. Working on Visual Studio Code > extension. But it's all longer term work, not the next few weeks. > > Martijn: Can we share these plans somewhere? > > Szeged: Will open GH issues for them. > > Face to face meetings. Jan: September OK? Or too late? Probably good > September. > > Martijn: Need someone to run it. > > Jan will own it. > > New mailing list is officially in place. Groups.io will be used from now > on. Already reflected on GitHub as well. > > Szeged: New feature: adding timeout mechanism for scripts, are > implementing it in the next few weeks, as a compile-time enabled feature. > Checking for JMP backwards. Soft counter is implemented here, if in > infinite loop then can be detected, will terminate the script. > > Heiko/Martijn: Can we join some of the work on enabling timers in > JerryScript with this? Not sure how it would be implemented. > > Martijn: we merged user context API. Per context, and per binding piece of > bookkeeping. Was discussing with Gabriel, working on building a utility on > top of this API, like a module manager, similar to require(). Requires > bookkeeping. ES6 spec has abstract module record (for import/export). > Modules have state, need to have a handle related to that state. Native > bindings also need this. Would it make sense to add something to jerry-core > that implements abstract module record? So we can add > import/require()/native bindings on top of it. > > Szeged: so we want to have module registering and retrieving be maintained > by jerry-core? > > Martijn: Not accessible by JavaScript, but it's useful for maintaining the > bindings. > > Szeged: This should be part of utils, as you can choose what > implementation you want depending on the workload. But can figure out > something more generic. Hard to decide what's the best approach. Modules > need to be handled by the environment. Not sure. > > Martijn: we need to find a way of loading modules from variety of sources, > mbed / Zephyr / Intel all invent their own. > > Szeged: main concern is with the size. We want JS to remain small as > possible. > > Martijn: will come with a concrete proposal. > > > > > > >
_______________________________________________ jerryscript-dev mailing list [email protected] https://mail.gna.org/listinfo/jerryscript-dev
