Re: 3.2: gjs/seed

[Tomeu Vizoso <tomeu vizoso collabora co uk>]

On Fri, Apr 22, 2011 at 00:19, Giovanni Campagna
<scampa giovanni gmail com> wrote:
> Il giorno mer, 20/04/2011 alle 19.12 -0400, Colin Walters ha scritto:
>> Hi,
>>
>> So speaking as someone who was motivated to make writing GNOME apps
>> easier, I'm not very happy with how things turned out with the mix of
>> gjs/seed/python/introspection/gtk3.
>> [...]
>>
>> But let me cut to the chase and say that I think we'd at least
>> consider realigning on seed for 3.2 for gnome-shell (and by extension,
>> mark gjs as deprecated at least in GNOME).
>>
>> [...]
>>
>> Even tougher would be unwinding the Spidermonkey let/const and
>> generator usage inside gnome-shell, but we dug the hole, we can dig it
>> out.
>
> I would say "Eventually! One working JS engine instead of two piles of
> bugs!", if it wasn't for this.
> But removing let/const will be a lot of work, and will surely introduce
> bugs (as var has different semantics than let). We need to know as soon
> as possible if such move is needed for 3.2
> Also, there are missing parts both in GJS and in Seed, especially wrt
> GVariant and GDBus. I've made patches for GJS, I'd like know if I need
> to rewrite them for Seed. Same for array support, which is inconsistent
> for GJS and appears to be completely missing for Seed.
>
>>
>> That covers reasons 1,2 and 5.  As far as reason 3), they're not as
>> active anymore (probably gjs basically works for them), and for 6) I
>> think we need to change this anyways.  This leaves reason 4) which I
>> admit is just a feeling.
>>
>> So - seed/gjs contributors - what do you think?
>>
>> One thing I'm not totally happy with is the organic growth in API in
>> both seed and gjs.  seed for example added an "os" module with e.g.
>> "fork" which I think is totally wrong; it's just broken to fork() a
>> GNOME app, since it conflicts with threads, etc.  If we're going to do
>> some unification, we should also prune a lot of cruft.  If there are
>> bits missing from GNOME (like GIO is really missing both Console and
>> Process classes), we need to add them.
>>
>> == Dynamic Languages in GNOME ==
>>
>> One thing that's worth addressing though (again) is the question "do
>> we need both Python and JavaScript?".  The uptake of both seed and gjs
>> has been relatively low; lower than Python at least for scripting
>> GNOME apps.  However, I think at least one the core reason for working
>> on JavaScript remains that *we define the platform*.  Python comes
>> with a vast API, a lot of it really old and crufty, but even more
>> importantly, large parts of it are *wrong* to use in GNOME.
>
> JS also has some native API that is wrong to use in GNOME.
> Date.toLocaleFormat is one example (it often segfaults GJS). E4X is
> another big one. Even JSON is bad, if you want to talk to C libraries
> using JsonGlib. (And let's ignore the subtle differences between RegExp
> and GRegex).
> Basically, if you want a language that is fully GObject based, the only
> choice is Vala. Other languages all have some kind of standard library,
> that won't interoperate with GLib/GIO.
>
>> For example, we don't want people to use Python's mostly-POSIX-like
>> wrappers for IO, we want people to use GIO, so it doesn't block the
>> mainloop.  We don't want people to use Python's "webbrowser" module,
>> its "multiprocessing" module (which totally breaks things like X and
>> DBus since it uses a bare fork()), etc.
>>
>> On the other side of the coin though, I think we largely failed to
>> make JavaScript a compelling way to write apps.  The language is only
>> a part of the question, and it's really not a large one.  We need to
>> focus more on a build/deploy story, and less on /usr/bin/gjs.  By
>> "build" I mean we really shouldn't be leaving it up to app authors to
>> figure out how to use Automake with gjs/seed and to do
>> "imports.gi.Gtk".  Deploy is another story.
>>
>> The other reasons:
>>   * ecosystem: The industry adoption is reflected in all the work that
>> goes into JIT compilers, as well as people simply learning the
>> language
>>   * Better engine internals - the global interpreter lock in cPython
>> really hurts it as far as a future in a multicore world
>
> Better implementations != Better engine internals. A PyTypeObject is
> definitely cleaner than a JSClass, with all its mess of prototype,
> constructor, parent objects and the like.
> (Which somehow explains why PyGObject, while being younger than GJS, has
> complete support for all introspection features).

Don't know much about JS internals, but in the case of PyGObject, the
reason for broader introspection support is that we had apps to port,
so we needed at least the same level of access to GNOME APIs as we had
with static bindings.

My understanding (please correct me if this is outdated or plainly
false) is that for existing usage of GJS such as gnome-shell, it's ok
to have to write stuff in C when a limitation is found in GJS's
introspection support.

Regards,

Tomeu