|
Do you have better idea?
I think suggestion is more valuable than critics. :)
Regards,
Youngil
--------- Original Message ---------
Sender : Martijn The <[email protected]>
Date : 2017-04-19 19:09 (GMT+9)
Title : Re: [jerryscript-dev] Meeting notes community call 19-04
The idea is to alternate the time and thereby distributing the pain of timezones ☺
I am afraid that we have to join the next meeting at midnight.
It seems that it is hard to make all happy. How about that the least happy side decide next schedule ?
Next time, I will decide :)
Regards,
Youngil
--------- Original Message ---------
Sender : Jan Jongboom <[email protected]>
Date : 2017-04-19 18:16 (GMT+9)
Title : Re: [jerryscript-dev] Meeting notes community call 19-04
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.
Here are the meeting notes of today:
* 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.
Zidong: any projects who use JerryScript in production environment? It's important for jerry-util to proceed.
Szeged: None to our knowledge.
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.
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
---------------------------------------------------------------------
Intel Benelux B.V.
Registered in The Netherlands under number 24134020
Statutory seat: Rotterdam
Registered address: Capronilaan 37, 1119NG Schiphol-Rijk
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
![]()
_._,_._,_
Groups.io Links:
You receive all messages sent to this group.
View/Reply Online (#13) |
Reply To Group
| Reply To Sender
|
Mute This Topic
| New Topic
Change Your Subscription
Group Home
Contact Group Owner
Terms Of Service
Unsubscribe From This Group
_._,_._,_
|
