How do I debug native packages?

[flimzy]

I'm trying to tinker with the GopherJS implementation of runtime.go, to flesh out the Callers() method, which is needed by a third party package I want to use.

I'm having a heck of a time debugging, though. I haven't found the "secret sauce" to make my changes to GopherJS's ./compiler/natives/runtime/runtime.go file effectual for my third-party packages.

There must be a simple step I'm overlooking.

I've tried (within the gopherjs checkout):

go clean; go build; go install

This successfully updates the gopherjs binary, but doesn't seem to (always?) update the native packages.

In my third party package, I've attempted

go clean; gopherjs test

But that also has no effect, as demonstrated by utterly breaking runtime.go by introducing obvious typos... But the tests still execute, with no compilation failure.

Clues?

[neelance]

Yeah, I know what you're talking about. The reason is that GopherJS only compiles if the source files or the GopherJS binary itself have a newer timestamp than the output file. This check currently does not include the natives files. The easiest solution right now is to touch the GopherJS binary to force it to recompile everything. In the long term we should probably use go generate to include the native files into the binary itself. @shurcooL Can your tool help here?

[flimzy]

Thanks for the touch hint, @neelance.

[dmitshur]

In the long term we should probably use go generate to include the native files into the binary itself. @shurcooL Can your tool help here?

Absolutely. You're referring to vfsgen, right?

[dmitshur]

@neelance, if you can tell me what files need to be embedded, and where they are used, I can look at making a PR. It's quite easy.

[neelance]

@shurcooL The files here https://github.com/gopherjs/gopherjs/tree/master/compiler/natives are used here

gopherjs/build/build.go

Line 149 in 6ed7594

if nativesPkg, err := Import("github.com/gopherjs/gopherjs/compiler/natives/"+importPath, 0, "", nil); err == nil {

. It's not that trivial, because we need to add the VFS abstraction at several places.

[dmitshur]

I can get it started by making a PR that simply creates that VFS. Next step will be to use it in all appropriate places.

[dmitshur]

An important question is where to place the virtual filesystem variable that will hold the native package data.

I've noticed that the https://github.com/gopherjs/gopherjs/tree/master/compiler/natives directory itself is empty, there's no package there. All natives are in subdirectories. It seems attractive to create a package at the root and place the variable there, for example:

"github.com/gopherjs/gopherjs/compiler/natives".Data

For generating the VFS for statically embedding it, it will complicate matters a little, since we'll want to include the entire natives folder but skip all files in the root, only keeping subdirectories.

If it's desirable to simplify that, then it can be done by placing the VFS variable elsewhere. Or moving the natives data. So that the entire directory can be embedded without having to filter out files.

I'll make the PR so you can look it over, and let me know if you feel it's okay or too complex.

[dmitshur]

Created #369, please take a look and tell me your thoughts.

[dmitshur]

Any thoughts on this so far?

[gmlewis]

I have a Go app that binds to three.js and would like to open up the Chrome dev console and poke around in all the generated JavaScript code to figure out what is going on. I found this thread description and apologize for hijacking the thread, but I can't seem to find any basics anywhere on looking around.

For example, I have a global platformMesh variable in my Go code, and I try to dump it like this:

    log.Printf("platformMesh=%#v", platformMesh)

and all I get in the Chrome dev console is:

2016/04/07 08:41:53 platformMesh=&js.Object{object:(*js.Object)(0x1)}

whereas I would really like to access the JavaScript object. I looked through the generated JavaScript code and I see things like $global and $packages but they are hidden behind a (function(){...})() and my JavaScript fu is failing me.

Is there a collection of known best-practices for debugging gopherjs-generated JavaScript code?

[neelance]

Try println(obj), that one translates to console.log(obj). Then you should even be able to expand the object in Chrome's dev console.

[gmlewis]

Awesome. Thanks, @neelance!

[dmitshur]

In the long term we should probably use go generate to include the native files into the binary itself.

That has been implemented in ab917e0, so I'd like to follow up. Is there anything else that needs to be done here?

When I think about it, I'm not quite sure how that change helps this issue (but I haven't fully thought it out, I welcome comments). I think embedding natives into the gopherjs binary was primarily done so that the gopherjs binary could perform compilation successfully even if its source code is no longer in GOPATH (since it now has all its assets baked in). Edit: It might've also been done to help vendoring, right @neelance? (I wish the commit message mentioned some motivation. :P )

Prior to that change, I did the following inside gopherjs repo when modifying natives (it's something I've done a lot recently during development and testing of #454):

touch tool.go && go install

Now that we have natives accessed through the VFS abstraction, what should the best approach be to make changes to natives and install them?

Naively, I would do the following right now:

touch tool.go && go install -tags=dev

The dev build tag will make it so that natives are accessed directly from disk (see fs.go file) instead of from the fs_vfsdata.go file. The fs_vfsdata.go file is only updated when doing go generate github.com/gopherjs/gopherjs/.... So, alternatively, I could do touch tool.go && go generate github.com/gopherjs/gopherjs/... && go install, but that doesn't seem advantageous.

So that brings me back to the question, is there a better way to make and test changes to natives other than touch tool.go && go install -tags=dev? /cc @neelance

[dmitshur]

In the comment above, which I posted in May, I asked:

Is there anything else that needs to be done here?

Based on no replies, it sounds like there isn't. I've looked over this issue and don't see anything immediately actionable here – it looks like a question that has been mostly answered.

In order to keep open issues more actionable, I'll close this. Feel free to re-open if needed.