Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GPII-1526: Port native addons to nan #2

Merged
merged 47 commits into from May 18, 2016
Merged

Conversation

javihernandez
Copy link

Hey @amb26,

I've ported our native modules to nan, so this is ready for you to start reviewing it.
The only missing piece is the packageKit addon, which is being ported by @klown and will end up in this branch for you to review too.

args[1]->ToString()->WriteAscii(key);
if (args[2]->IsBoolean()) {
status = g_settings_set_boolean(settings,key,args[2]->BooleanValue());
settings = g_settings_new(*String::Utf8Value(schema));
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be a good opportunity to fix our long-standing bug due to never deallocating this object. By my reading - we should call g_object_unref, but I may misunderstand - http://stackoverflow.com/questions/2848273/should-a-g-object-new-have-a-matching-g-object-unref
What do you think?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.
Certainly I did in the Gnome Control Panel for the Magnifier, e.g.:
https://git.gnome.org/browse/gnome-control-center/tree/panels/universal-access/zoom-options.c#n438

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@amb26, @klown,

ACTUALLY YES, so I've also added some "deallocating" code in both gsettings and packageKit modules.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@javihernandez
I wrote:

Actually g_clear_object (&settings) would be better.

I've updated the packagekit add-on in that regard (nodepackagekit.cc), and pushed it this morning. If you want to keep it in your GPII-1526 branch, you'll have to pull my latest in.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@klown,

I've just merged in your changes

klown and others added 7 commits December 9, 2015 09:19
Used g_clear_object() instead of the conditional g_object_unref().
Cleaned up white space.
Conflicts:
	gpii/node_modules/packagekit/nodepackagekit/nodepackagekit.cc
* klown/GPII-1526:
  GPII-1526: Ported PackageKit addon to nan.

Conflicts:
	gpii/node_modules/packagekit/nodepackagekit/nodepackagekit.cc
Attempt #2.
Conflicts:
	gpii/node_modules/packagekit/nodepackagekit/nodepackagekit.cc
for (i = 0; keys[i]; i++) {
togo->Set(i,String::New(keys[i]));
togo->Set(i,String::NewFromUtf8(isolate, keys[i]));
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see this strategy for constructing strings advertised in the public NAN docs - where did you find the recommendation?

What I see in the docs is this: https://github.com/nodejs/nan/blob/master/doc/string_bytes.md#api_nan_encode which seems to avoid the need for the bizarre "Isolate" reference...

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right,

My fault, I saw the weird "Isolate" thing in a few examples from nodejs official addon examples, which wasn't using Nan. In fact, now I'm realizing that would be better to use Nan::New(keys[i]).ToLocalChecked() instead, since internally we're making use of a MaybeLocal type. Is that correct?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@javihernandez
I used Nan::Encode() to construct strings without the need for Isolate, as @amb26 suggested.
Look inside makePac() of nodepackagekit.cc
https://github.com/klown/linux/blob/GPII-1526/gpii/node_modules/packagekit/nodepackagekit/nodepackagekit.cc#L85

I haven't addressed other uses of Isolate in that code yet, though.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wrote:

I haven't addressed other uses of Isolate in that code yet, though.

I have removed the use of Isolate in nodepackagekit.cc when allocating v8 Arrays and a Boolean. There is still a use in one case with a ThrowError. I'll address that on Mon.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wrote:

I haven't addressed other uses of Isolate in that code yet, though.

I have removed the use of Isolate in nodepackagekit.cc when allocating v8 Arrays and a
Boolean. There is still a use in one case with a ThrowError. I'll address that on Mon.

Done. There are no more instances of Isolate in nodepackagekit.cc.

klown and others added 8 commits December 11, 2015 12:03
Modified ut8StringFromValue() to use Nan string functions.

Addresses amb26's comment:
amb26#2
Modified makePac() to eliminate using Isolate object for string
construction.

Addresses amb26's comment:
amb26#2
Reomved usage of Isolate with respect to allocating a v8 Array
and Boolean.
Modified makePac() to use a loop to get various properties of an
individual package.
Removed use of Isolate by the ThrowError() within performAction().
Added unit test of this ThrowError() by calling performAction() such
that it fails.

Addresses amb26's comment:
amb26#2
Also, updated the code to use Local handles when possible.
* klown/GPII-1526:
  GPII-1526: PackageKit nan port:  Remove Isolate.
  GPII-1526: PackageKit nan port.
  GPII-1526: PackageKit nan port:  Isolate
  GPII-1526: PackageKit nan port:  strings.
  GPII-1526: Port of PackageKit addon to nan.
klown and others added 4 commits April 25, 2016 12:23
Modified performAction():  For unsupported actions, free and
NULL-ify allocated data structures prior to throwing an error.
amb26#2 (comment)
The test of setting the screen resolution to impossible dimensions
was erroneously using the physical size of the display as the
impossible resolution.  Changed to simply use a resolution of
(-1 ,-1).

amb26#2
* klown/GPII-1526:
  GPII-1526: Xrandr add-on nan port: fixed memory leak.
  GPII-1526: Xrandr add-on nan port: improved unit test.
  GPII-1526: PackageKit nan port: freed data structures.
  GPII-1526: XRandr nan port: throws errors instead of exit().
  GPII-1526: PackageKit nan port: added comment re: NanUtf8 strings.
@klown
Copy link

klown commented Apr 28, 2016

@javihernandez @amb26 A heads up: GPII needs to support Fedora-23/glib-2.46.
I merged all of @javihernandez's changes with mine and re-built everything. nodegsettings.cc does not compile because it depends on glib-2.46 (for g_settings_schema_list_keys()) and Fedora-22 only goes as high as glib-2.44. I can upgrade to Fedora-23 to solve this, no problem; but then so does GPII as a whole (or some other distro that includes glib-2.46).

@javihernandez
Copy link
Author

@javihernandez @amb26 A heads up: GPII needs to support Fedora-23/glib-2.46.
I merged all of @javihernandez's changes with mine and re-built everything. nodegsettings.cc does not compile because it depends on glib-2.46 (for g_settings_schema_list_keys()) and Fedora-22 only goes as high as glib-2.44. I can upgrade to Fedora-23 to solve this, no problem; but then so does GPII as a whole (or some other distro that includes glib-2.46).

oh, I see, and sorry for that. Do you want me to add backwards compatibility or just do a "heads up" communication to the rest of the team? (mostly thinking about our provisioning system)

@amb26
Copy link
Owner

amb26 commented Apr 28, 2016

I think a headsup is fine. I don't see a need for us to depend on a version of Fedora that will receive EOL before we produce the APCP release.

@@ -155,6 +155,17 @@ var fluid = require("universal"),
return matchPkg;
};

pkTests.testPerformActionFailure = function() {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two linting failures in this function - please ensure to run "grunt lint" before issuing pull - see @the-t-in-rtf work on git commit hooks

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, will fix these as well as the one below.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just in case, here's the archive of the note:

http://lists.idrc.ocad.ca/pipermail/architecture/2016-April/004051.html

It typically prevents me from committing badly formatted code a few times a week, totally worth it.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the link, @the-t-in-rtf !
Aside: as a test, I added the hook to my copy of universal, added a lint violation to gpii.js, and tried to commit it. Nothing happened. It turns out that universal's Gruntfile.js checks only the files under the "gpii", "tests", and "examples" directories. Adding "./*.js" to the list fixed that and reported two errors in gpii.js, besides my cooked-up one. Is there a reason for not linting the files in the top level directory?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if that was directed at me. My concern there would be cleanly avoid linting node_modules and other content that isn't part of the project. It seems like your approach handles that.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@the-t-in-rtf That was not directed at you, specifically. And, you are correct that we don't want to lint all the third-party material. But, gpii.js, index.js, and possibly package.json are GPII specific, and they aren't being linted (and gpii.js shows lint errors).
However, this is a tangent to this pull request. I'll shut up now, and raise an appropriate JIRA for it.

Joseph and others added 2 commits May 2, 2016 16:13
Set DEBUG flag to true so that progress is printed always.  Also,
tweaked progressCallback() to tidy up its output, and to flush
stdout to ensure that the percentages are printed immediately.
* klown/GPII-1526:
  GPII-1774:  Display progress for PackageKit node add-on.
  GPII-1526:  Fixed lint errors in nodepackagekit unit tests.
@javihernandez
Copy link
Author

@amb26

I've included the latest changes from Joseph and fixed the implementation of Orca's get/set methods (they return promises only if the settings file doesn't exist, and tries to create it). One question, do the operations that require read/write access to files must be enclosed inside a try/catch block, and rejecting the promise if anything goes wrong?

@amb26
Copy link
Owner

amb26 commented May 6, 2016

Yes, they must!

@javihernandez
Copy link
Author

Yes, they must!

Ok, done

@javihernandez
Copy link
Author

@amb26,

is there anything else do you want to see happening before accepting this?

};

if (exists) {
try {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very repetitive. This logic should be captured in the getSettings method itself.
Also, the standard form for a rejection payload is
{
isError: true,
message: "Couldn't get settings: " + err
}

return;
}
}
var getSettings = that.getSettings(payload);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can all just be
return that.getSettings(payload)

@amb26 amb26 merged commit 1968794 into amb26:GPII-1318 May 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants