Great stuff everyone -- these are really good minutes with a lot of good info. :-)
On Wed, Aug 17, 2016 at 4:48 AM, <philip.chime...@gmail.com> wrote: > Hi list, > > Here are the notes from Day 1 of the GJS dev room at GUADEC. > > Profiling > --------- > Christian has had some profiler patches for a while that he wants to merge > so that you can do GJS profiling with Sysprof. The problem is that they > (ab)use SIGUSR1 and SIGUSR2 to enable or disable profiling. > > Proposal: toggling profiling using DBus. Would fall back to not allowing > profiling if DBus was not reachable. gjs-console would export a DBus > interface. For gnome-shell and other embedding cases, libgjs would have to > provide API for exporting the interface yourself. Concern: We don't want > GJS to change its behaviour by init'ing the bus before the application > starts. > > Porting to mozjs31 etc > ---------------------- > Yes, we welcome this port, though we need to find time to do it. We want > GNOME's JS to be modern, rather than use old Mozilla extensions. Tim Lunn > (darkxst) did the ports to mozjs17 and mozjs24, but nobody knows whether he > is available at the moment or how much time he has. > > Do we port first to mozjs31 or go all the way to mozjs45? In 31 the C API > was removed, you can only use the C++ API now. It seems better not to break > everything at once. However, it might be possible to skip mozjs38 in favour > of mozjs45. > > In mozjs45 ES6 classes were introduced. We should figure out how to do > GObjects as ES6 classes. Maybe a wrapper function that takes an ES6 class > and adds a GType, properties, signals, etc., since we don't have > metaclasses. We should also ensure that Lang.Class keeps working. > > Missing GObject Features > ------------------------ > Were hoping to hear from other GJS consumers about whether they were > missing any GObject features in their apps. Here are a few that we can > think of: > > GTask - this is not bindable because of bare gpointers in the API. Useful > for implementing the GAsyncResult pattern, though if you were _consuming_ > that pattern it might be better to have promises. Matt Watson wrote a GTask > workalike which we can pull in: https://github.com/endlessm/ > eos-knowledge-lib/blob/master/js/search/asyncTask.js > > Enums - of course JS does not need enums by itself, but it might be nice > to be able to define enum-valued GObject properties. > > GValue boxing and unboxing - Philip C forgot which APIs he needed this > for. However, if there's a GValue in an API, then it should probably be > covered by an override. > > Promises? We'll get them in mozjs31. Several Node promise libraries have > "promisify" functions that wrap other libraries' callback-based APIs, so > we'd like to do something similar for GAsyncResult-based APIs. > > Some discussion about GErrors but it seems that support is pretty > sufficient in GJS. > > Documentation > ------------- > The DevDocs site is temporarily out of commission because Philip C ran out > of AWS free tier hosting. We need another place to host this. Owen might be > able to get it on a VM on GNOME infrastructure. > > We also need to make sure the code in modules/overrides/ is documented, > currently this is obscure and the only way to find it out is to read the > source. > > Michael pointed out (as I was typing these notes up) that PyGObject has a > fairly good tutorial for GObjects in Python (http://python-gtk-3-tutorial. > readthedocs.io/en/latest/objects.html) but really, the only good > documentation story for people coming to the platform is for the C > libraries. > > GJS Autocompletion > ------------------ > For use inside Builder. > Tern? https://github.com/ternjs/tern > Generate JS stubs out of GIR files for this? > > Debugger > -------- > How is this supported within mozjs? > > We would like to work with an existing debugger if possible. > > Owen knows of a patch in a Gentoo overlay where someone patched GJS to > support a debugger protocol that can be used with a program called "JSRDB". > (Link?) > > It would be great if we could debug via Chrome Dev Tools, since many > people would be familiar with them. > > React Native > ------------ > Niv is interested in this. Ubuntu published React Native for QT and > someone else published a React Native proof of concept hack in GJS. (Links?) > > Interoperability with Node > -------------------------- > Philip C has been thinking about a Node shim that implements Node's fs, > require, and sockets APIs in terms of GIO, so that more Node modules could > be used directly in GJS. There have already been several efforts in this > direction (https://github.com/WebReflection/jsgtk, > https://github.com/satya164/gjs-helpers) Niv is also interested in using > Webpack/Babel for this purpose. > > Of course this wouldn't work for Node modules with native code, though. > > Does Node ever plan to support ES6 modules? > > Some debate about whether this should be part of GJS, or a side project. > Also differing opinions about how important this is to the platform. In any > case, we should follow the ES standard primarily, and have hooks to support > Node stuff, rather than mutating GJS into something that looks like Node > but is not quite the same. > > Developers used to Node have a lot of niceties at their fingertips; e.g. > it's good to just be able to do `npm install jshint --save-dev` and your > project has linting set up. We don't necessarily need to have the same > answer as Node, but our answer should be something else than "we don't have > that." > > Switching to a different engine > ------------------------------- > Consensus seems to be that staying on mozjs is slightly unattractive but > not overly objectionable. There has been lots of tricky GObject code > written, solving weird cases bit by bit, and another engine would have a > lot of catch-up to do; though probably if we were starting GJS now, it > would be based on top of Node. > > Node seems to be abstracting out JS engine backends? Anyone got a link for > this? > > Standards for GNOME application development > ------------------------------------------- > Currently there's no place in /usr/share to install modules. We should add > this. > > How do we make it really easy for people to Flatpak their GJS app without > having to write a bunch of Autotools? Especially if they come from the > wider JS community. We should discuss inside the community what our > template for application development should be, and then make sure it is > available as a default in Builder. Let's also look at apps like > gnome-sound-recorder or Polari, to see what we want and what we don't want. > > Do we use package.js?? Should we be getting people to write ES6 modules > using Babel?? > > Outreach > -------- > We should make more of an effort to point people to #javascript and > javascript-list@gnome.org. At least everyone in this room should be > subscribed :-) > > Action Items > ------------ > - [x] Philip C: Send these notes to javascript-list > - [ ] Christian: finish profiling patches with environment variable, plan > to merge for 3.22 > - [ ] Christian: think about IPC for enabling/disabling profiler > - [ ] Philip C: investigate targeting mozjs31 work for 3.24? > - [ ] Christian: check out adding Tern to Builder > - [ ] Niv: investigate bridging Tern with GObject > - [ ] Niv: experiment with React Native > - [ ] Philip C: move Endless's AsyncTask.js into GJS for 3.22, Owen will > review > - [x] Philip C: send setup script for DevDocs server to Owen > - [ ] Owen: check out the JSRDB patch > > _______________________________________________ > javascript-list mailing list > javascript-list@gnome.org > https://mail.gnome.org/mailman/listinfo/javascript-list > > -- Jeremiah C. Foster GENIVI COMMUNITY MANAGER Pelagicore AB Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden M: +1.860.772.9242 jeremiah.fos...@pelagicore.com
_______________________________________________ javascript-list mailing list javascript-list@gnome.org https://mail.gnome.org/mailman/listinfo/javascript-list
