Re: Possible to fix glaring Gjs API issues before GNOME 4?

[Martin Pitt]

Nikita Churaev [2013-02-27 23:26 +0400]:
> 1. Some functions return useless "success" boolean: for example
> [success, contents, etag_out] = GFile.load_contents(). When C
> g_file_load_contents returns false, it also sets GError, so in Gjs it's
> either true or the function has thrown exception.

Note that many other functions with that style don't throw a GError.
In PyGObject we have overrides for many of them to filter out the bool
and only return the (out) arguments if the return value is True. Look
for "strip_boolean_result" in
http://git.gnome.org/browse/pygobject/tree/gi/overrides/Gtk.py

Perhaps gjs could do something similar. 

But as you already said, doing this anywhere (in annotations or
overrides) always means an API break, so at this point it might
actually be better to just use what we have and live with it. The
existing ones in PyGObject were mostly done for compatibility to the
old PyGTK API, but we will not introduce any new ones. In particular
not as a global heuristics for all functions
(https://bugzilla.gnome.org/show_bug.cgi?id=620912)

> 3. Gtk.TextBuffer.set_text(text, length) --- length argument is useless,
> since JavaScript uses UTF-16 and length expects length of UTF-8 string.

I'm afraid we have to live with little oddities like this. I think
it's better to stay compatible with the C API and its documentation,
and all currently existing JavaScript program which use the API than
breaking API and continuously chasing after weird cases like that.

> 4. It's impossible to create custom Gtk.TreeIter from JS (no
> constructor), so can't implement a completely custom Gtk.TreeModel.

Aren't these just vfuncs? Doesn't gjs support defining/overwriting them?

> Is it possible to fix these issues at least in Gjs ASAP without having
> to wait for GNOME 4, as there are still very few Gjs applications, so we
> don't have to worry as much about backwards compatibility as in eg.
> Python.

That's a fair point. I guess the primary affected module would be
gnome-shell, plus all the existing plugins?

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Possible to fix glaring Gjs API issues before GNOME 4?

[Dan Winship]

On 02/27/2013 08:26 PM, Nikita Churaev wrote:
> Introspection developers have already introduced "(skip)" mark for such
> return values, but they won't add it to existing API to avoid backwards
> incompatibility. What about adding "(skip2)" mark that only Gjs will use
> and replace it to "(skip)" when GNOME 4 comes?

AFAIK, there is no plan/timeline for GNOME 4, or for a GLib ABI break.

But it seems like it would be a good idea to start explicitly noting
planned future ABI breaks in some way, somewhere, so nothing gets
forgotten when it does come, and so people can see the big picture more
easily.

> 4. It's impossible to create custom Gtk.TreeIter from JS (no
> constructor), so can't implement a completely custom Gtk.TreeModel.

I don't know the details of this particular issue, but if it's not
possible to do at all now, then any change to make it more bindable
could not possibly break any existing code, so it could happen at any time.

> Is it possible to fix these issues at least in Gjs ASAP without having
> to wait for GNOME 4, as there are still very few Gjs applications, so we
> don't have to worry as much about backwards compatibility as in eg.
> Python.

Well, there's that shell thing. Would probably be good to not break that.


One possibility would be to figure out all the ABI breaks we wanted, and
then deprecate "imports.gi" and replace it with
"imports.new-and-improved-gi" (except with a non-stupid name), where the
modules imported from new-and-improved-gi would pick up all the
latest-and-greatest annotations, and would not include any functions
that had already been deprecated before its first release, while those
in imports.gi would just preserve the current API forever (ie, the
current versions of their gir files would get checked into git and we'd
never generate new ones).

(Renaming "imports.gi" is not a totally awful idea anyway, since "gi" is
a completely opaque name unless you know details about the platform that
new developers shouldn't be expected to have to know. "imports.gnome"?)

-- Dan

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Possible to fix glaring Gjs API issues before GNOME 4?

[Torsten Schönfeld]

Von: "Martin Pitt" :
>> 1. Some functions return useless "success" boolean: for example
>> [success, contents, etag_out] = GFile.load_contents(). When C
>> g_file_load_contents returns false, it also sets GError, so in Gjs it's
>> either true or the function has thrown exception.
>
> Note that many other functions with that style don't throw a GError.
> In PyGObject we have overrides for many of them to filter out the bool
> and only return the (out) arguments if the return value is True. Look
> for "strip_boolean_result" in
> http://git.gnome.org/browse/pygobject/tree/gi/overrides/Gtk.py

We use a similar approach in the Perl bindings: 
,
 .

When functions with a "success" boolean and out arguments don't throw an 
exception, you can still get rid of the boolean if your language supports a 
variable number of return values.  You simply return nothing then in the case 
the boolean is false.

But note that you cannot use a heuristic like "has boolean return value and out 
arguments" to decide whether to apply this approach: 
gtk_tree_selection_get_selected is a counter example, 
.

I also think an annotation for boolean return values that states "this is a 
sentinel for whether the out args have been set" would be useful.  It would 
make it possible for bindings to share this information.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Possible to fix glaring Gjs API issues before GNOME 4?

[Simon Feltman]

On Thu, Feb 28, 2013 at 12:04 AM, Martin Pitt wrote:

> Nikita Churaev [2013-02-27 23:26 +0400]:

 > 3. Gtk.TextBuffer.set_text(text, length) --- length argument is useless,
> > since JavaScript uses UTF-16 and length expects length of UTF-8 string.
>
> I'm afraid we have to live with little oddities like this. I think
> it's better to stay compatible with the C API and its documentation,
> and all currently existing JavaScript program which use the API than
> breaking API and continuously chasing after weird cases like that.
>

I don't think skipping the length arg in this case could work even if API
breakage was acceptable. I assume a skip implies a value of zero is used
and in this case that would not work. A better alternative would be default
value support. This way the oddity can be avoided in client code without
breaking API and in general would be a very nice feature. However, new code
using this would need to specify it only works with advanced versions of
GLib or the libraries providing defaults.

https://bugzilla.gnome.org/show_bug.cgi?id=558620

-Simon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Possible to fix glaring Gjs API issues before GNOME 4?

[Maciej Piechotka]

On Thu, 2013-02-28 at 09:26 +0100, Dan Winship wrote:
> > 4. It's impossible to create custom Gtk.TreeIter from JS (no
> > constructor), so can't implement a completely custom Gtk.TreeModel.
> 
> I don't know the details of this particular issue, but if it's not
> possible to do at all now, then any change to make it more bindable
> could not possibly break any existing code, so it could happen at any
> time.

IIRC the GtkTreeIter is assumed to not allocate memory. The API and ABI
would need to be altered in order to incorporate it as:

 - 3rd party needs to free GtkTreeIter if it uses one from arbitrary
model (possibly not so important) - i.e. there is API change and ABI.
 - All elements of class struct are already occupied so the size of
struct would need to be change - thus changing the the ABI.

I looked at the issue around Gtk+ 3.2 when someone asked for non-memory
allocating iterators for libgee (I cannot find the request right now but
making it bindable would solve this issue as well).

Best regards


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Possible to fix glaring Gjs API issues before GNOME 4?

[Nikita Churaev]

On Thu, 2013-02-28 at 10:08 +, Maciej Piechotka wrote:
> On Thu, 2013-02-28 at 09:26 +0100, Dan Winship wrote:
> > > 4. It's impossible to create custom Gtk.TreeIter from JS (no
> > > constructor), so can't implement a completely custom Gtk.TreeModel.
> > 
> > I don't know the details of this particular issue, but if it's not
> > possible to do at all now, then any change to make it more bindable
> > could not possibly break any existing code, so it could happen at any
> > time.
> 
> IIRC the GtkTreeIter is assumed to not allocate memory. The API and ABI
> would need to be altered in order to incorporate it as:
> 
>  - 3rd party needs to free GtkTreeIter if it uses one from arbitrary
> model (possibly not so important) - i.e. there is API change and ABI.
>  - All elements of class struct are already occupied so the size of
> struct would need to be change - thus changing the the ABI.
> 
> I looked at the issue around Gtk+ 3.2 when someone asked for non-memory
> allocating iterators for libgee (I cannot find the request right now but
> making it bindable would solve this issue as well).
> 
> Best regards

struct GtkTreeIter {
  gint stamp;
  gpointer user_data;
  gpointer user_data2;
  gpointer user_data3;
};

There's a stamp member that models can put unique IDs in. We could allow
Gjs to create iterators with just stamps and leave user_data alone.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Possible to fix glaring Gjs API issues before GNOME 4?

[Nikita Churaev]

> I'd just like to reiterate that the idea isn't that JavaScript is
> preferred for new developers or "smaller" applications (what would be
> the cut-off?). We're going to encourage JavaScript for all new
> applications (regardless of who's writing them), both for core GNOME
and
> third-party.

Can Gjs handle complex applications (eg. multimedia editors like photo
and video editors, medium games, complex data analysis) without eating
up all the CPU and memory? If it can, then go for it!

> > However, there are some API issues that make Gjs confusing, and bad
> > for PEOPLE.
> 
> New developers are also people :)

Yes, they are all people, but they are also PEOPLE. I admit,
GNOME/JavaScript platform will only attract imperfect PEOPLE who still
have their inner hacker (in a good way) not completely beaten out of
them, as it's literally impossible for perfect PEOPLE to program in any
other platform other than a good safe platform that's prescribed, that
is, HTML5 on Windows 8+.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Possible to fix glaring Gjs API issues before GNOME 4?

[Nikita Churaev]

> > Is it possible to fix these issues at least in Gjs ASAP without having
> > to wait for GNOME 4, as there are still very few Gjs applications, so we
> > don't have to worry as much about backwards compatibility as in eg.
> > Python.
> 
> That's a fair point. I guess the primary affected module would be
> gnome-shell, plus all the existing plugins?

Maybe add version system to Gjs, so that if you call gjs xx.js it'll use
old API and if you call gjs2 xx.js it'll use the new API. GNOME Shell
could just use the old API.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Possible to fix glaring Gjs API issues before GNOME 4?

[Javier Jardón]

On 28 February 2013 08:26, Dan Winship  wrote:
>
> But it seems like it would be a good idea to start explicitly noting
> planned future ABI breaks in some way, somewhere, so nothing gets
> forgotten when it does come, and so people can see the big picture more
> easily.

In GTK+ this is done by marking bugs with 4.0 as target milestore [1]

[1] 
https://bugzilla.gnome.org/buglist.cgi?product=gtk%2B&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&target_milestone=4.0

-- 
Javier Jardón Cabezas
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Possible to fix glaring Gjs API issues before GNOME 4?

[Allan Day]

Javier Jardón  wrote:
> On 28 February 2013 08:26, Dan Winship  wrote:
>>
>> But it seems like it would be a good idea to start explicitly noting
>> planned future ABI breaks in some way, somewhere, so nothing gets
>> forgotten when it does come, and so people can see the big picture more
>> easily.
>
> In GTK+ this is done by marking bugs with 4.0 as target milestore [1]

We should also be tracking and targeting any gjs binding issues. We
really need the new applications to be clearing the way for those who
want to follow, rather than working around deficiencies in the
platform.

One issue I know of is the lack of introspection support in
libcanberra [1]. I bet there are others...

Allan

[1] https://bugs.freedesktop.org/show_bug.cgi?id=32587
--
IRC:  aday on irc.gnome.org
Blog: http://afaikblog.wordpress.com/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Possible to fix glaring Gjs API issues before GNOME 4?

[Maciej Piechotka]

On Thu, 2013-02-28 at 15:52 +0400, Nikita Churaev wrote:
> On Thu, 2013-02-28 at 10:08 +, Maciej Piechotka wrote:
> > On Thu, 2013-02-28 at 09:26 +0100, Dan Winship wrote:
> > > > 4. It's impossible to create custom Gtk.TreeIter from JS (no
> > > > constructor), so can't implement a completely custom Gtk.TreeModel.
> > > 
> > > I don't know the details of this particular issue, but if it's not
> > > possible to do at all now, then any change to make it more bindable
> > > could not possibly break any existing code, so it could happen at any
> > > time.
> > 
> > IIRC the GtkTreeIter is assumed to not allocate memory. The API and ABI
> > would need to be altered in order to incorporate it as:
> > 
> >  - 3rd party needs to free GtkTreeIter if it uses one from arbitrary
> > model (possibly not so important) - i.e. there is API change and ABI.
> >  - All elements of class struct are already occupied so the size of
> > struct would need to be change - thus changing the the ABI.
> > 
> > I looked at the issue around Gtk+ 3.2 when someone asked for non-memory
> > allocating iterators for libgee (I cannot find the request right now but
> > making it bindable would solve this issue as well).
> > 
> > Best regards
> 
> struct GtkTreeIter {
>   gint stamp;
>   gpointer user_data;
>   gpointer user_data2;
>   gpointer user_data3;
> };
> 
> There's a stamp member that models can put unique IDs in. We could allow
> Gjs to create iterators with just stamps and leave user_data alone.
> 

DISCLAIMER: Sorry - either I didn't understood you or you didn't
understood the problem. The following e-mail is written after studying
the problem for 5 minutes so it might include counterfactual
informations

That's not an issue - you can put even a pointer but the problem is that
you need to pin object. You don't know (automatically without user
intervention) when you can free the resource. At any point GTK might
keep GtkTreeIter alive so data you put inside cannot be freed (or
garbage collected or however you'll call it) and it need's to be always
considered 'alive'. I guess it is possible to workaround the issue by
reverse engineering the Gtk internals but solution would be very
unstable and not remotely elegant. 

In other words - if I have following code:

var iter = new MyIter() {...}
pass_iter_to_gtk(iter);
// Is iter alive? who knows - maybe. We need to know about the function
// This is half of problem - let's assume we can 'model' in gtk functon
iter = new MyIter() {...};
pass_iter_to_other_lib(iter);
// Can we release memory associated with iter?

== After reading the GTK manual =

I read into the Gtk section about iters. From GTK 3.2 reference manual
"The lifecycle of an iterator can be a little confusing at first.
Iterators are expected to always be valid for as long as the model is
unchanged (and doesn't emit a signal). The model is considered to own
all outstanding iterators and nothing needs to be done to free them from
the user's point of view. Additionally, some models guarantee that an
iterator is valid for as long as the node it refers to is valid (most
notably the GtkTreeStore andGtkListStore). Although generally
uninteresting, as one always has to allow for the case where iterators
do not persist beyond a signal, some very important performance
enhancements were made in the sort model. As a result, the
GTK_TREE_MODEL_ITERS_PERSIST flag was added to indicate this behavior."

I would say that the need is to subclass GtkTreeModel and use it.

Now the GtkTreeModel keeps all of the issued pointers in some sort of
data structure (say list). 

Then you can add handler to listen to changes and free them as needed
(Vala syntax + libgee usage as shameless self-promotion):

public interface GITreeIter : GLib.Object {
   ...
   void equals(MyTreeIter other);
}

public abstract MyTreeIter? gi_get_iter (Gtk.TreePath path);

public gboolean get_iter (out Gtk.TreeIter iter, Gtk.TreePath path) {
GITreeIter *giter = gi_get_iter (path); // Wrapped HL object
if (giter == null)
   return false;
stored_iters.add(giter);
iter.user_data = giter;
return true;
}

this.row_changed.connect ((path, iter) => {
for(Iterator iiter = stored_iters.iterator();
iter.next();) {
MyTreeIter *miter = iiter.get();
if (iter.equals(miter)) {
// Dereferences the item so in case of wrapper objects etc.
// this is no longer a pinned object.
delete citer; 
iiter.delete();
}
}
});

It could be possibly optimized if the gi_get_iter was guranteed to
return always the same object for the same (logical) path - which would
push a bit of complexity back to user:

this.row_changed.connect ((path, iter) => {
delete iter.user_data;
stored_iters.remove(iter.user_data);
});


Other possible option, more efficient but potentially less user-friendly
(as user of library needs to manage it on its own) would be to cache the
iterators pointing to ro

Re: Possible to fix glaring Gjs API issues before GNOME 4?

[Nikita Churaev]

> That's not an issue - you can put even a pointer but the problem is that
> you need to pin object. You don't know (automatically without user
> intervention) when you can free the resource. At any point GTK might
> keep GtkTreeIter alive so data you put inside cannot be freed (or
> garbage collected or however you'll call it) and it need's to be always
> considered 'alive'. I guess it is possible to workaround the issue by
> reverse engineering the Gtk internals but solution would be very
> unstable and not remotely elegant. 

The problem with GtkTreeIter is that you can't make any function to be
called when iter goes out of scope. Example:

int
foo(void)
{
  GtkTreeIter iter;
  get_iter_of_something (&iter);
  do_something_with_iter (&iter);

  /* iter is no longer needed, C frees its memory 
 automatically, but we can't make it call a 
 custom function, as C doesn't have C++'s
 destructors, that's why we can't put references
 to JavaScript objects into them */
}

However, luckily for us, GtkTreeIter has an integer stamp field that
could be used instead of a direct reference. JavaScript custom tree
models will be slower as they would need to look up items by their
stamps. Example:

_init: function() {
  this.parent(...);
  this._items = [];
},

getTreeIterOfItem: function(itemStamp)
{
  if (this._items[itemStamp] === undefined)
return undefined;

  return new Gtk.TreeIter(itemStamp);
},

getItemByTreeIter: function(iter)
{
  return this._items[iter.stamp];
}

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Possible to fix glaring Gjs API issues before GNOME 4?

[Maciej Piechotka]

On Fri, 2013-03-01 at 02:44 +0400, Nikita Churaev wrote:
> > That's not an issue - you can put even a pointer but the problem is that
> > you need to pin object. You don't know (automatically without user
> > intervention) when you can free the resource. At any point GTK might
> > keep GtkTreeIter alive so data you put inside cannot be freed (or
> > garbage collected or however you'll call it) and it need's to be always
> > considered 'alive'. I guess it is possible to workaround the issue by
> > reverse engineering the Gtk internals but solution would be very
> > unstable and not remotely elegant. 
> 
> The problem with GtkTreeIter is that you can't make any function to be
> called when iter goes out of scope. Example:
> 
> int
> foo(void)
> {
>   GtkTreeIter iter;
>   get_iter_of_something (&iter);
>   do_something_with_iter (&iter);
> 
>   /* iter is no longer needed, C frees its memory 
>  automatically, but we can't make it call a 
>  custom function, as C doesn't have C++'s
>  destructors, that's why we can't put references
>  to JavaScript objects into them */
> }
> 
> However, luckily for us, GtkTreeIter has an integer stamp field that
> could be used instead of a direct reference. JavaScript custom tree
> models will be slower as they would need to look up items by their
> stamps. Example:
> 
> _init: function() {
>   this.parent(...);
>   this._items = [];
> },
> 
> getTreeIterOfItem: function(itemStamp)
> {
>   if (this._items[itemStamp] === undefined)
> return undefined;
> 
>   return new Gtk.TreeIter(itemStamp);
> },
> 
> getItemByTreeIter: function(iter)
> {
>   return this._items[iter.stamp];
> }
> 

Yes. That is the problem I've wrote about. 

I didn't parsed the sentence "models guarantee that an
iterator is valid for as long as the node it refers to is valid (...)"
correctly. Arguably this allows to even point to node in one of the
field speeding things a little:

I assume that we don't use list as probably GtkListModel is better in
such case. Sorry if code is incorrect (I don't use JS):

function MyNode() {
this._init();
}

MyNode.prototype = {
_init: function() {

},
next: function() {

}
parent: function() {

}
};

function MyModel() {
this._init();
}

MyModel.prototype = {
_init: function() {
...
},
getTreeIterFromTreePath: function(iter, path) {
var node = doMagic(path);
iter._user_data1 = marshal_as_unowned(node); // Don't pin
}
getNodeFromTreeIter: function(iter) {
return iter._user_data1;
}
root: new MyNode();
};

I'm not sure if marshal_as_unowned exists in GJS now though.

Best regards


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Possible to fix glaring Gjs API issues before GNOME 4?

[Nikita Churaev]

On Thu, 2013-02-28 at 23:09 +, Maciej Piechotka wrote:
> On Fri, 2013-03-01 at 02:44 +0400, Nikita Churaev wrote:
> > > That's not an issue - you can put even a pointer but the problem is that
> > > you need to pin object. You don't know (automatically without user
> > > intervention) when you can free the resource. At any point GTK might
> > > keep GtkTreeIter alive so data you put inside cannot be freed (or
> > > garbage collected or however you'll call it) and it need's to be always
> > > considered 'alive'. I guess it is possible to workaround the issue by
> > > reverse engineering the Gtk internals but solution would be very
> > > unstable and not remotely elegant. 
> > 
> > The problem with GtkTreeIter is that you can't make any function to be
> > called when iter goes out of scope. Example:
> > 
> > int
> > foo(void)
> > {
> >   GtkTreeIter iter;
> >   get_iter_of_something (&iter);
> >   do_something_with_iter (&iter);
> > 
> >   /* iter is no longer needed, C frees its memory 
> >  automatically, but we can't make it call a 
> >  custom function, as C doesn't have C++'s
> >  destructors, that's why we can't put references
> >  to JavaScript objects into them */
> > }
> > 
> > However, luckily for us, GtkTreeIter has an integer stamp field that
> > could be used instead of a direct reference. JavaScript custom tree
> > models will be slower as they would need to look up items by their
> > stamps. Example:
> > 
> > _init: function() {
> >   this.parent(...);
> >   this._items = [];
> > },
> > 
> > getTreeIterOfItem: function(itemStamp)
> > {
> >   if (this._items[itemStamp] === undefined)
> > return undefined;
> > 
> >   return new Gtk.TreeIter(itemStamp);
> > },
> > 
> > getItemByTreeIter: function(iter)
> > {
> >   return this._items[iter.stamp];
> > }
> > 
> 
> Yes. That is the problem I've wrote about. 
> 
> I didn't parsed the sentence "models guarantee that an
> iterator is valid for as long as the node it refers to is valid (...)"
> correctly. Arguably this allows to even point to node in one of the
> field speeding things a little:
> 
> I assume that we don't use list as probably GtkListModel is better in
> such case. Sorry if code is incorrect (I don't use JS):
> 
> function MyNode() {
> this._init();
> }
> 
> MyNode.prototype = {
> _init: function() {
> 
> },
> next: function() {
> 
> }
> parent: function() {
> 
> }
> };
> 
> function MyModel() {
> this._init();
> }
> 
> MyModel.prototype = {
> _init: function() {
> ...
> },
> getTreeIterFromTreePath: function(iter, path) {
> var node = doMagic(path);
> iter._user_data1 = marshal_as_unowned(node); // Don't pin
> }
> getNodeFromTreeIter: function(iter) {
> return iter._user_data1;
> }
> root: new MyNode();
> };
> 
> I'm not sure if marshal_as_unowned exists in GJS now though.
> 
> Best regards

IDK, there's no guarantee that SpiderMonkey won't start moving objects
in memory in next versions.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list