The version of Node.js I used is 10.21.0. I modified BUILD.gn under deps/v8 folder: I set V8_TRACE_IGNITION=true and I rebuilt Node.js using ./configure after that. Then I run "node --trace-ignition xx.js". I expected to trace the ignition's behavior. But it said bad option. I was wondering where I did wrong.
I was wondering where I did wrong.
To get an answer to that, you'd have to describe exactly what you've done, e.g. by posting the patch showing your edits to the file.
That said, modifying BUILD.gn is not necessary to get --trace-ignition to work. Simply use gn args out/<your_output_dir> to edit your build settings as usual, and add v8_enable_trace_ignition = true.
Related
I want to know how does the DIG (Domain Information Groper) command really works when it comes to code and implementation. I mean when we enter a DIG command, which part of the code in FreeBSD or BIND hits first.
Currently, I see that when I hit the DIG command, I see the control going to a file client.c. Inside this file, following function is called:
static void
client_request(isc_task_t *task, isc_event_t *event);
But how does the control reach to this place is still a big mystery for me even after digging a lot into 'named' part of the BIND code.
Further, I see this function being called from two places within this file. I tried to put logs into such places to know if control reaches to this place through those paths, but unfortunately that doesn't happen. It seems "Client_request()" function is somehow being called from outside somewhere that I am not able to figure out.
Is there anybody here who can help me out to resolve this mystery for me ?
Thanks.
Not only for bind but to any other command, within FreeBSD you could use ktrace, it is very verbose but could help you to get a quick overview of how the program is behaving.
For example, in latest FreeBSD's you have drill command instead of dig so if you would like to know what is happening behind scenes when you run the command, you could give a try to:
# ktrace drill freebsd.org
Then to disable tracing:
# ktrace -C
Once tracing is enabled on a process, trace data will be logged until
either the process exits or the trace point is cleared. A traced process
can generate enormous amounts of log data quickly; It is strongly
suggested that users memorize how to disable tracing before attempting to
trace a process.
After running ktrace drill freebsd.org a file ktrace.out should be created the one you could read with kdump, for example:
# kdump -f ktrace.out | less
That will hopefully "reveal the mystery", in your case, just replace drill with dig and then use something like:
# ktrace dig freebsd.org
Thanks to FreeBSD Ports system you can compile your own BIND with debugging enabled. To do so run
cd /usr/ports/dns/bind913/ && make install clean WITH_DEBUG=1
Then you can run it inside debugger (lldb /usr/local/bin/dig), break on the line you are interested in and then look at backtrace to figure out how the control reached there.
I've been following this Suave tutorial:
https://legacy.gitbook.com/book/theimowski/suave-music-store/details
And in general this looks good. However, I was trying to make it work with Linux and for some reason I was unable to compile it with code when TargetFramework was set to "net461" (Target Framework not found), so I tried changing it to "netcoreapp2.0". It compiled, but I hit a problem later on:
https://theimowski.gitbooks.io/suave-music-store/content/en/css.html
At the end it says to add a WebPart:
pathRegex "(.*)\.(css|png)" >=> Files.browseHome
which fails for me. All compiles, but I get
This page isn’t working
localhost didn’t send any data.
I took a look at Suave's source code and it turned out that "Files.browseHome" searches for a file under "ctx.runtime.homeDirectory".
I noticed that this is set on my machine to:
/home/<my_user_name>/.nuget/packages/suave/2.2.1/lib/netstandard1.6
and obviously, that's not my project directory, so no wonder it couldn't find the file.
My question here is: what shall I do in order to make my Suave app handle my css/png files correctly using Files.browseHome ?
EDIT:
Just found out that replacing the WebPart with:
pathRegex "(.*)\.(css|png)" >=> Files.browse "/home/<my_username>/<path_to_my_project>/bin/Debug/netcoreapp2.0/"
works fine, but it looks ugly. Any idea how to make it better ? Basically I don't want to be forced to hardcode the absolute path anywhere.
I think the answer is to be found in https://suave.io/files.html, which suggests creating a config as follows:
let config =
{ defaultConfig with homeFolder = Some (Path.GetFullPath "./public") }
The path returned by Path.GetFullPath will depend on the current working directory that your app sees when it's started (which will, in turn, depend on how you start the app: from the command line, from a systemd unit file, etc.) There are too many possible variables here for me to be able to give you exact instructions, but if your startup method can cd into an appropriate folder before starting your Suave server, then that should solve your problem.
If you run into difficulties with getting the current working directory set correctly, then you could just hardcode the full path in the config:
let config =
{ defaultConfig with homeFolder = Some "/home/<your_username>/<path_to_your_project>/bin/Debug/netcoreapp2.0/" }
But that's kind of ugly, and not really portable (you'd have to modify that path again once you deploy the app). So I'd recommend the approach of making sure your start script does a cd to the right location, then using Path.GetFullPath with a relative path. Alternately, you could have a config file that gets read in at app startup where you specify the home path, or pass it in as an environment variable... All kinds of possibilities. Just make sure that your code can be handed some information on startup that specifies the correct "home" folder, and then put that in your Suave config as I've shown, and that should solve it.
I am trying to make this slack bot run : https://github.com/lmammino/norrisbot
I am not very skilled with npm and node yet, but I follow his instructions and try to run the bot with the help of the npm start command.
Here's the output I get :
F:\norrisbot>npm start
> norrisbot#1.0.5 start F:\norrisbot
> node bin/bot.js
F:\norrisbot>
No error, but nothing happens either in the console or the slack general channel...
By the way I set up my BOT_API_KEY variable correctly (with the token.js method)
By your command prompt it's clear you're running in Windows. The operations for running Node properly in Windows are different in several ways from Mac/Linux, and a LOT (most?) of developers don't address these because they're on Mac/Linux themselves. Path formats, file locations, how you expose environment variables, and all sorts of things are different in Win.
Try hand-editing bin/bot.js in your locally cloned copy of the repo. Find this line at the end of the file:
norrisbot.run();
Change it to read as follows:
console.log('Running Norris Bot');
norrisbot.run();
console.log('Ran Norris Bot');
I bet you will find that either NEITHER of these lines gets printed, or only one does.
If NEITHER line gets printed, the issue is with the npm command improperly formatting the path to the executable script for Windows users. In that case, try running it as (make sure NodeJS is in your PATH):
node bin/bot.js
If only the FIRST line gets printed, there is almost certainly a bug elsewhere in the module itself. I didn't evaluate all of its code, and I'm not on Windows myself at the moment - I just use it often enough to be aware of its differences. But either way it will get you started on finding the issue, and if it's truly a bug, you can pursue the bug report I see you've already filed in Github.
NOTE: Here is an example repo with the problem.
When I run ./gulp js, the process works (creates the expected files on the file system), but the task never completes... just hangs indefinitely:
ss http://zc.d.pr/4C9U/3GG90rpz+
I figure I'm not returning something somewhere, or invoking a callback correctly, but after hours of tinkering, head-banging, and Googling, I haven't found a solution.
Can someone help me out here?
If it makes a difference, I'm currently using node v4.1.0. All other dependencies and versions are in the example repo linked above.
EDIT: Original inspiration for this gulp recipe came from https://truongtx.me/2015/06/07/gulp-with-browserify-and-watchify-updated/
However, I couldn't get transform to work as that author suggested, which led me to https://github.com/substack/node-browserify/issues/1198#issuecomment-89948202
Of course—as it always happens—I think of something new to try just after I post to SO and it appears to work.
doh http://zc.d.pr/11uMa/5gghjbCx+
You can see my full changeset here: https://github.com/neezer/gulp-browserify-hanging-task/commit/8156e182c04c2e76c5739e31f5a6e417dda01b70
TL;DR Basically I tried the suggestion in the last comment on the aforementioned issue from my question, where I pass the file object itself to browserify instead of the file path, and lo-and-behold, the task finishes now.
I don't pretend to know why that fixed the issue, so if anyone would like to explain, I'd love to learn. ;)
I'm trying to follow the instructions outlined here:
http://www.webrtc.org/native-code/development#TOC-Before-you-start;
but "fetch webrtc" fails with a message that implies a file (src/buildtools/linux32/gn.sha1) is not found. See this post for more detail on the error message:
https://groups.google.com/forum/#!topic/discuss-webrtc/Dt-GRIlLVe4
I've walked through installation of all the "prerequisite software" as described on the above page, but consistently hit the same error. I'm doing this from a Ubuntu 14.04 LTS machine, any thoughts on what I might be doing wrong?
gn is a replacement for gyp to generate Ninja files. I don't think it's required yet (gn is a work-in-progress), but that's likely what you're missing. You could comment out gn from the DEPS and see if things work.
Answering my own question here...
It appears that the problem is related to the fact that I am behind a proxy
and the --no_auth option is used (in depot_tools) when the download_from_google_storage.py script is called.
After reading this post: https://github.com/GoogleCloudPlatform/gsutil/issues/241
I modified my copy of "download_from_google_storage.py" so that the --no_auth option would have no affect. I also created a ~/.boto file with three lines:
[Boto]
proxy = my.proxy.goes.here.com
proxy_port = PROXY_PORT_NUMBER
Then I re-ran "fetch webrtc" and it completed successfully in about 75 minutes.
Go figure...