I'm a relative newbie to WebAssembly, but I've been working with it and Emscripten for about a month now, and have a decent familiarity with the minimal build kits.
When it comes to debugging, I am finding that I cannot find how get the most out of both Chrome and Firefox environments.
In Firefox 68.0.1 my Source Map files load and I can map them correctly to my C/C++ source files.
I cannot, however, see the local stack. I can see all the local variables, but as I step through my wasm code, as FF displays it, it's pushing things to a stack I can't see, and keeping track of that manually is a pain.
Chrome 76, by contrast, gives me the stack, will let me add the Source Map to see my C/C++ references, but I cannot get it to give me any kind of wasm code to step through, either my own wast file, or its own disassembled version.
All wasm I load, either from node http-server or from emscripten emrun, shows me my source code in the "Sources" tab of DevTools, but there is a second node under localhost that is labeled "top/(no domain)." I've tried loading a simple module with no success.
I would like to either figure out how to view the local stack in FireFox or get Chrome to show me the wasm disassembly (preferably both). Chrome seems to do so for WebAssembly Studio and I cannot find out why
Related
I recently installed the preview version of visual studio and created a new .net maui blazor hybrid app.
When debugging the app, a window shows up and everything works just as expected.
However when i go to the bin folder and run the exe that is located there the window does not come up.
In the windows event logs i can see the following:
Exception Info: System.DllNotFoundException: Unable to load DLL 'Microsoft.ui.xaml.dll' or one of its dependencies
And indeed that dll is missing from the bin folder.
What does visual studio do to make this work? How can i just run the exe?
Right now we only support so-called “packaged” apps. Those you need to publish to an MSIX and install in order to run.
We’re working on adding the unpackaged scenario as well, you can track that here: https://github.com/dotnet/maui/issues/3166
While searching for the above issue I noticed a couple of others ones though. According to this and this it might already be possible right now, you might want to try!
I have an app that I started using the out of the box MAUI project template. I have been running it on both a local Android emulator and a remote Mac emulator. It had been working on both, and then today after running it on Android for a while, I changed the debugger to use the Mac emulator. It immediately refused to compile, and listed every Android class reference as "type or namespace [blah] could not be found". After playing with several things, I found that if I commented out the "using Java.Net" on the default MainPage.xaml.cs, all of the compiler errors went away. If I uncomment it again, then all 20 something compiler errors show up again. This is the out of the box MainPage.xaml that came with the project template, plus one click event handler that I added - is there some known issue here?
As I said, it was working fine for nearly two weeks, and then just went bananas on me today. Haven't added any nuget packages or anything like that - just been writing code.
Thanks.
You've described the issue in your question:
using "Java.Net" on the default MainPage.xaml.cs.
That won't compile for any platform except Android.
It doesn't exist on the default MainPage.xaml.cs (which you could have verified by creating a new project).
My recommendation: Start over with a fresh project. Add again whatever you added, and see if that using appears again. If it does, you've added something Android specific. Which doesn't make sense, on a cross-platform page.
If using does appear again, and you don't understand why, then add to your question the exact code which, when added to page, causes using Java.net; to appear.
If you were following some example, also add a link to the example web page.
UPDATE
I have a theory about how that using got there:
I bet you added a reference to some class which exists in Java.net namespace.
So Visual Studio gave you an option to add a "using".
If that happens again, and a "using" mentions Android or Java, DON'T add the using, UNLESS you are in a file inside your project's Platforms/Android folder.
Some class names exist both in an Android or Java namespace, and in a .Net or Maui namespace. In cross-platform code, pick the cross-platform using, not the platform-specific one. If they are in different namespaces, they are different classes - even if the names are the same.
Back in the day I was debugging node.js applications using the ChromeDevTools. Breakpoints would be synced or reset on remote, so that no matter what, the breakpoints in the Eclipse breakpoint window would always match the actual breakpoints.
Also, setting up the Source Mapping as described here would cause Eclipse to break inside my actual local files, not in a read-only V8 window.
These days, ChromeDevTools is outdated and unmaintained. I started using Nodeclipse and their V8 debugger.
But now, when debugging, Eclipse keeps breaking on breakpoints I had already unset or removed. Seemingly irregardless of my setting here:
Also, whether or not it's a break point I meant to break on, A new read-only editor opens with the V8 (Chromium) icon in stead of the javascript-icon. If the original name was e.g. index.js, the script that opens is index.js (20).chromium.
What is changed? How exactly does one set up the Nodeclipse V8 debugger for proper breakpoint syncing and source mapping?
There is nice intro info given, but still a discussion should follow, that does not fit to StackOverflow format. Please create and follow with an issue on https://github.com/Nodeclipse/nodeclipse-1/issues
These days, (since Nodecipse 0.2) Launch configuration is created automatically, so most users may even don't know about it existence. And it is needed to be recalled looking at code how actually launch configurations are created and synced. Related source are here:
https://github.com/Nodeclipse/nodeclipse-1/tree/master/org.nodeclipse.debug/src/org/nodeclipse/debug/launch
I configured the coffeescript compiler to run map (-m) using IntelliJ with NodeJS.
I assume with the source maps I should be able to debug in coffeescript files in Chrome developer tool. The enable souce map was checked. I tried to open any .coffee file but got the "Cannot GET /path.../foo.coffee" error. The folder of where the coffeescript files resides in the sources explorer was weird. ../../../../../Web/src/test/webapps/installManager
I think it reflects what's in the map.
"sourceRoot": "../../../../..",
"sources": [
"Web/src/test/webapps/installManager/app.coffee"
],
I do have sourceMappingURL in my js files.
/*
//# sourceMappingURL=Common.map
*/
The following is my configuration for running the Coffeescript compiler:
Application Parameters:
-cwm /home/repository/svn/ding/Web/src/test/webapps
Why can't Chrome get the coffee file since that the maps are available now? Is it because of the path in the sourceRoot and sources in the maps?
I was able to add workspaces in Chrome canary and map them and even do the bidirectional editing but I still can't debug (can set breakpoints but the debugger never stopped at the breakpoints).
Thank you
I fixed my problems - it was all in the cross references between the js coffee and map files. As soon as I configured it so that the transpiled .js was placed right next to the coffee (and the map, it picked it up.
I have installed the Chrome Dev Tools Eclipse plug-in as described on http://code.google.com/p/chromedevtools/ and debugging JavaScript basically works. I can set breakpoints in my JavaScript source files and when I run the JavaScript code in Chrome, Eclipse stops the execution and opens the Debug perspective. Stepping through the code works fine, and I can also see the local and global variables in the Variables view.
When clicking on one of the variables, the detail view shows an error message, though:
Helper script failed on remote: _com_chromium_debug_helper is not defined
Did I miss something during the installation?
Update
Added an issue on the project's page: http://code.google.com/p/chromedevtools/issues/detail?id=85
Most likely you should open an issue at the project page. It is definitely a bug and fixing it might require additional context from you.
This is internals of ChromeDevTools SDK's workaround for WebKit Remote Debugging protocol limitations.