[v8-users] Re: ChromeDevTools connected to Inspector, but error responses... missing native JS functions?
Ah that sounds more like the proper way to do it :)
I've not tried interrupts yet, so I'm no use here :)
On Wednesday, 14 November 2018 17:45:03 UTC, Konrad Piascik wrote:
>
> I have attached to node with the program executing in the middle of a
> while/busy loop.
> I think I found what node is doing.
>
> https://github.com/v8/v8/blob/96a039aab14b71069e88c4c04543e6bc9514a0d6/include/v8.h#L7969
>
> void v8::Isolate::RequestInterrupt(InterruptCallback callback, void* data);
> This function stops JavaScript execution and might be the answer to my
> problem. The callback is called on the isolate's thread.
>
> Cheers,
> Konrad
>
> On Wednesday, November 14, 2018 at 10:52:53 AM UTC-5, @soylentgraham wrote:
>>
>> Going off topic now, but can you attach & break into node.js whilst it's
>> in a big blocking function?
>> Or can you only break if you've previously attached? (I've only done
>> light, very-async stuff in node)
>>
>> In long-running funcs (well, accidental massive loops) in chrome I find I
>> struggle to break, so I kinda thought this was how it was, but maybe I'm
>> wrong :)
>>
>>
>> On Wednesday, 14 November 2018 13:55:34 UTC, Konrad Piascik wrote:
>>>
>>> Yeah I can't make any assumptions or impose any requirements about what
>>> the javascript to be executed will look like.
>>> It must be possible since Node.js already does this for long running
>>> JavaScript.
>>>
>>> Thanks for the suggestions and quick responses
>>>
>>> -Konrad
>>>
>>> On Wednesday, November 14, 2018 at 7:53:57 AM UTC-5, @soylentgraham
>>> wrote:
>>>>
>>>> The only way I could interrupt long runs of javascript, assuming you
>>>> can't break it yourself into asynchronous code (via promises/await, this
>>>> is
>>>> the nicest approach IMO me), is adding a yield function to let the event
>>>> loop run (I have other multithread-y reasons for this too, but letting
>>>> external actions run is one)
>>>>
>>>> But if you can't add code at all, you are probably stuck (afaik,
>>>> there's no real interrupting, because you're basically calling one big
>>>> RunJavascript() func on your thread :)
>>>>
>>>> In case it's useful, this is the C++ side, (and I call yield() in JS to
>>>> let other threads do JS calls, and let the debugger interrupt)
>>>>
>>>>
>>>> void TV8Container::Yield(size_t SleepMilliseconds)
>>>>
>>>> {
>>>>
>>>> // gr: temporary unlock, but need to exit too
>>>>
>>>> {
>>>>
>>>> mIsolate->Exit();
>>>>
>>>> v8::Unlocker unlocker(mIsolate);
>>>>
>>>> // isolate unlock for a moment, let another thread jump in and run
>>>> stuff
>>>>
>>>> auto ms = std::chrono::milliseconds(SleepMilliseconds);
>>>>
>>>> std::this_thread::sleep_for( ms );
>>>>
>>>> }
>>>>
>>>> // re-enter after unlocker has gone out of scope
>>>>
>>>> mIsolate->Enter();
>>>>
>>>> }
>>>>
>>>>
>>>> On Tuesday, 13 November 2018 21:06:59 UTC, Konrad Piascik wrote:
>>>>>
>>>>> Hi @soylentgraham,
>>>>>
>>>>> I'm trying to replicate what you're doing as well but am running into
>>>>> some other problems. The most notable of which is that my websocket is
>>>>> on
>>>>> a different thread than my isolate creation.
>>>>> I see from your solution that you're adding the frontend messages to a
>>>>> queue and looking through them in your event loop. My problem is that I
>>>>> have long running javascript that is not intended to exit/return until
>>>>> the
>>>>> program stops. Do you have any suggestions/ideas?
>>>>>
>>>>> Thanks,
>>>>> Konrad
>>>>>
>>>>>
>>>>> On Tuesday, September 18, 2018 at 10:49:43 AM UTC-4, @soylentgraham
>>>>> wrote:
>>>>>>
>>>>>> YetAnotherUpdate
>>>>>>
>>>>>> After some more digging, I found the issue I have is identified node
>>>>>> and chromium too...
>>>>>>
>>>>>> https://github.com/nodejs/node/commit/b1e26128f317a6f5a5808a0a727e98f80f088
[v8-users] Re: ChromeDevTools connected to Inspector, but error responses... missing native JS functions?
Going off topic now, but can you attach & break into node.js whilst it's in
a big blocking function?
Or can you only break if you've previously attached? (I've only done light,
very-async stuff in node)
In long-running funcs (well, accidental massive loops) in chrome I find I
struggle to break, so I kinda thought this was how it was, but maybe I'm
wrong :)
On Wednesday, 14 November 2018 13:55:34 UTC, Konrad Piascik wrote:
>
> Yeah I can't make any assumptions or impose any requirements about what
> the javascript to be executed will look like.
> It must be possible since Node.js already does this for long running
> JavaScript.
>
> Thanks for the suggestions and quick responses
>
> -Konrad
>
> On Wednesday, November 14, 2018 at 7:53:57 AM UTC-5, @soylentgraham wrote:
>>
>> The only way I could interrupt long runs of javascript, assuming you
>> can't break it yourself into asynchronous code (via promises/await, this is
>> the nicest approach IMO me), is adding a yield function to let the event
>> loop run (I have other multithread-y reasons for this too, but letting
>> external actions run is one)
>>
>> But if you can't add code at all, you are probably stuck (afaik, there's
>> no real interrupting, because you're basically calling one big
>> RunJavascript() func on your thread :)
>>
>> In case it's useful, this is the C++ side, (and I call yield() in JS to
>> let other threads do JS calls, and let the debugger interrupt)
>>
>>
>> void TV8Container::Yield(size_t SleepMilliseconds)
>>
>> {
>>
>> // gr: temporary unlock, but need to exit too
>>
>> {
>>
>> mIsolate->Exit();
>>
>> v8::Unlocker unlocker(mIsolate);
>>
>> // isolate unlock for a moment, let another thread jump in and run stuff
>>
>> auto ms = std::chrono::milliseconds(SleepMilliseconds);
>>
>> std::this_thread::sleep_for( ms );
>>
>> }
>>
>> // re-enter after unlocker has gone out of scope
>>
>> mIsolate->Enter();
>>
>> }
>>
>>
>> On Tuesday, 13 November 2018 21:06:59 UTC, Konrad Piascik wrote:
>>>
>>> Hi @soylentgraham,
>>>
>>> I'm trying to replicate what you're doing as well but am running into
>>> some other problems. The most notable of which is that my websocket is on
>>> a different thread than my isolate creation.
>>> I see from your solution that you're adding the frontend messages to a
>>> queue and looking through them in your event loop. My problem is that I
>>> have long running javascript that is not intended to exit/return until the
>>> program stops. Do you have any suggestions/ideas?
>>>
>>> Thanks,
>>> Konrad
>>>
>>>
>>> On Tuesday, September 18, 2018 at 10:49:43 AM UTC-4, @soylentgraham
>>> wrote:
>>>>
>>>> YetAnotherUpdate
>>>>
>>>> After some more digging, I found the issue I have is identified node
>>>> and chromium too...
>>>>
>>>> https://github.com/nodejs/node/commit/b1e26128f317a6f5a5808a0a727e98f80f088b84
>>>>
>>>> So, it looks like the default v8 [platform] isn't chrome-dev-tools
>>>> compatible.
>>>> Ibon's case worked as it has a specific Android platform
>>>> implementation. Chromium and Node also have their own platform.
>>>>
>>>> So, I made the most basic platform proxy possible to work around it...
>>>>
>>>> https://github.com/SoylentGraham/V8InspectorMinimal/blob/master/src/TV8Platform.h
>>>>
>>>> And it works!
>>>> I can now modify code on the fly, execute from the console.
>>>> I can't seem to debug, and pressing pause-execution a few times gives
>>>> me a new assert, but the higher level code is a bit of a mess at this
>>>> point, so I'm probably implementing something wrong...
>>>>
>>>> Still, if anyone else ever finds this problem... V8 alone cannot be
>>>> used with chrome dev tools. (as of 7.1.0.0
>>>>
>>>> 4544e18b0c3845a9fca422cf0903df4803343cf1)
>>>>
>>>> On Friday, 14 September 2018 11:44:33 UTC+1, @soylentgraham wrote:
>>>>>
>>>>> So the core of my issue at the moment, is this assert (UNIMPLEMENTED)
>>>>>
>>>>> void
>>>>> DefaultWorkerThreadsTaskRunner::PostDelayedTask(std::unique_ptr
>>>>> task,
>>>>>
>>>>>
[v8-users] Re: ChromeDevTools connected to Inspector, but error responses... missing native JS functions?
The only way I could interrupt long runs of javascript, assuming you can't
break it yourself into asynchronous code (via promises/await, this is the
nicest approach IMO me), is adding a yield function to let the event loop
run (I have other multithread-y reasons for this too, but letting external
actions run is one)
But if you can't add code at all, you are probably stuck (afaik, there's no
real interrupting, because you're basically calling one big RunJavascript()
func on your thread :)
In case it's useful, this is the C++ side, (and I call yield() in JS to let
other threads do JS calls, and let the debugger interrupt)
void TV8Container::Yield(size_t SleepMilliseconds)
{
// gr: temporary unlock, but need to exit too
{
mIsolate->Exit();
v8::Unlocker unlocker(mIsolate);
// isolate unlock for a moment, let another thread jump in and run stuff
auto ms = std::chrono::milliseconds(SleepMilliseconds);
std::this_thread::sleep_for( ms );
}
// re-enter after unlocker has gone out of scope
mIsolate->Enter();
}
On Tuesday, 13 November 2018 21:06:59 UTC, Konrad Piascik wrote:
>
> Hi @soylentgraham,
>
> I'm trying to replicate what you're doing as well but am running into some
> other problems. The most notable of which is that my websocket is on a
> different thread than my isolate creation.
> I see from your solution that you're adding the frontend messages to a
> queue and looking through them in your event loop. My problem is that I
> have long running javascript that is not intended to exit/return until the
> program stops. Do you have any suggestions/ideas?
>
> Thanks,
> Konrad
>
>
> On Tuesday, September 18, 2018 at 10:49:43 AM UTC-4, @soylentgraham wrote:
>>
>> YetAnotherUpdate
>>
>> After some more digging, I found the issue I have is identified node and
>> chromium too...
>>
>> https://github.com/nodejs/node/commit/b1e26128f317a6f5a5808a0a727e98f80f088b84
>>
>> So, it looks like the default v8 [platform] isn't chrome-dev-tools
>> compatible.
>> Ibon's case worked as it has a specific Android platform implementation.
>> Chromium and Node also have their own platform.
>>
>> So, I made the most basic platform proxy possible to work around it...
>>
>> https://github.com/SoylentGraham/V8InspectorMinimal/blob/master/src/TV8Platform.h
>>
>> And it works!
>> I can now modify code on the fly, execute from the console.
>> I can't seem to debug, and pressing pause-execution a few times gives me
>> a new assert, but the higher level code is a bit of a mess at this point,
>> so I'm probably implementing something wrong...
>>
>> Still, if anyone else ever finds this problem... V8 alone cannot be used
>> with chrome dev tools. (as of 7.1.0.0
>>
>> 4544e18b0c3845a9fca422cf0903df4803343cf1)
>>
>> On Friday, 14 September 2018 11:44:33 UTC+1, @soylentgraham wrote:
>>>
>>> So the core of my issue at the moment, is this assert (UNIMPLEMENTED)
>>>
>>> void
>>> DefaultWorkerThreadsTaskRunner::PostDelayedTask(std::unique_ptr task,
>>>
>>> double
>>> delay_in_seconds) {
>>>
>>> base::LockGuard guard(_);
>>>
>>> if (terminated_) return;
>>>
>>> if (delay_in_seconds == 0) {
>>>
>>> queue_.Append(std::move(task));
>>>
>>> return;
>>>
>>> }
>>>
>>> // There is no use case for this function with non zero
>>> delay_in_second on a
>>>
>>> // worker thread at the moment, but it is still part of the interface.
>>>
>>> UNIMPLEMENTED();
>>>
>>> }
>>>
>>> from
>>>
>>> DefaultPlatform::CallDelayedOnWorkerThread(
>>>
>>> being called by
>>>
>>> protocol::Response V8InspectorImpl::EvaluateScope::setTimeout(double
>>> timeout) {
>>>
>>> if (m_isolate->IsExecutionTerminating()) {
>>>
>>> return protocol::Response::Error("Execution was terminated");
>>>
>>> }
>>>
>>> m_cancelToken.reset(new CancelToken());
>>>
>>> v8::debug::GetCurrentPlatform()->CallDelayedOnWorkerThread(
>>>
>>> v8::base::make_unique(m_isolate, m_cancelToken),
>>> timeout);
>>>
>>> return protocol::Response::OK();
>>>
>>> }
>>>
>>>
>>>
>>> so, SetTimeout in the inspector, explicitly uses something
>>> we[developers] know isn't implemented...
>>> From reading
Re: [v8-users] Arraybuffer
Not sure where to start with this message
a) Not even vaguely related to the original topic, you should start a new
thread when the topic is wildly different.
b) Do not start a new thread.
c) This code is from libav (or actually, maybe ffmpeg). av_XXX are macros,
functions and other values. The AV prefix is a hint to the user (you) that
it's part of the av library. AV stands for audio/visual (or I suppose,
audio/video these days)
d) This is a question that should be on www.stackoverflow.com
e) Please do not reply to this message. (at least regarding this new topic)
On Tuesday, 18 September 2018 21:15:42 UTC+1, dan Med wrote:
>
> I was reading this code but i can't figure outwhat av_..._.. stands for
> is it already opening the connection here?
>
> static int tcp_open(URLContext *h, const char *uri, int flags){struct
> addrinfo hints = { 0 }, *ai, *cur_ai;int port, fd = -1;TCPContext *s
> = h->priv_data;const char *p;char buf[256];int ret;char
> hostname[1024],proto[1024],path[1024];char portstr[10];
> s->open_timeout = 500;av_url_split(proto, sizeof(proto), NULL, 0,
> hostname, sizeof(hostname),, path, sizeof(path), uri);if
> (strcmp(proto, "tcp"))return AVERROR(EINVAL);if (port <= 0 ||
> port >= 65536) {av_log(h, AV_LOG_ERROR, "Port missing in uri\n");
>return AVERROR(EINVAL);}p = strchr(uri, '?');if (p) {
> if (av_find_info_tag(buf, sizeof(buf), "listen", p)) {char
> *endptr = NULL;s->listen = strtol(buf, , 10);
> /* assume if no digits were found it is a request to enable it */
> if (buf == endptr)s->listen = 1;}if
> (av_find_info_tag(buf, sizeof(buf), "timeout", p)) {s->rw_timeout
> = strtol(buf, NULL, 10);}if (av_find_info_tag(buf,
> sizeof(buf), "listen_timeout", p)) {s->listen_timeout =
> strtol(buf, NULL, 10);}}if (s->rw_timeout >= 0) {
> s->open_timeout =h->rw_timeout = s->rw_timeout;}
> hints.ai_family = AF_UNSPEC;hints.ai_socktype = SOCK_STREAM;
> snprintf(portstr, sizeof(portstr), "%d", port);if (s->listen)
> hints.ai_flags |= AI_PASSIVE;if (!hostname[0])ret =
> getaddrinfo(NULL, portstr, , );elseret =
> getaddrinfo(hostname, portstr, , );if (ret) {av_log(h,
> AV_LOG_ERROR, "Failed to resolve hostname %s: %s\n",
>hostname, gai_strerror(ret));return AVERROR(EIO);}cur_ai =
> ai; restart:#if HAVE_STRUCT_SOCKADDR_IN6// workaround for IOS9
> getaddrinfo in IPv6 only network use hardcode IPv4 address can not resolve
> port number.if (cur_ai->ai_family == AF_INET6){struct
> sockaddr_in6 * sockaddr_v6 = (struct sockaddr_in6 *)cur_ai->ai_addr;
> if (!sockaddr_v6->sin6_port){sockaddr_v6->sin6_port =
> htons(port);}}#endiffd = ff_socket(cur_ai->ai_family,
> cur_ai->ai_socktype, cur_ai->ai_protocol);if
> (fd < 0) {ret = ff_neterrno();goto fail;}/* Set the
> socket's send or receive buffer sizes, if specified. If unspecified or
> setting fails, system default is used. */if (s->recv_buffer_size > 0) {
> setsockopt (fd, SOL_SOCKET, SO_RCVBUF, >recv_buffer_size, sizeof
> (s->recv_buffer_size));}if (s->send_buffer_size > 0) {
> setsockopt (fd, SOL_SOCKET, SO_SNDBUF, >send_buffer_size, sizeof
> (s->send_buffer_size));}if (s->tcp_nodelay > 0) {setsockopt
> (fd, IPPROTO_TCP, TCP_NODELAY, >tcp_nodelay, sizeof (s->tcp_nodelay));
> }if (s->listen == 2) {// multi-clientif ((ret =
> ff_listen(fd, cur_ai->ai_addr, cur_ai->ai_addrlen)) < 0)goto
> fail1;} else if (s->listen == 1) {// single clientif
> ((ret = ff_listen_bind(fd, cur_ai->ai_addr, cur_ai->ai_addrlen,
>s->listen_timeout, h)) < 0)goto fail1;
> // Socket descriptor already closed here. Safe to overwrite to client one.
> fd = ret;} else {if ((ret = ff_listen_connect(fd,
> cur_ai->ai_addr, cur_ai->ai_addrlen,
> s->open_timeout / 1000, h, !!cur_ai->ai_next)) < 0) {if (ret ==
> AVERROR_EXIT)goto fail1;elsegoto
> fail;}}h->is_streamed = 1;s->fd = fd;
> freeaddrinfo(ai);return 0; fail:if (cur_ai->ai_next) {/*
> Retry with the next sockaddr */cur_ai = cur_ai->ai_next;if
> (fd >= 0)closesocket(fd);ret = 0;goto restart;
> } fail1:if (fd >= 0)closesocket(fd);freeaddrinfo(ai);
> return ret;}
>
>
> Il giorno mar 18 set 2018 alle ore 21:54 dan Med > ha scritto:
>
>> I know that i
[v8-users] Re: ChromeDevTools connected to Inspector, but error responses... missing native JS functions?
YetAnotherUpdate
After some more digging, I found the issue I have is identified node and
chromium too...
https://github.com/nodejs/node/commit/b1e26128f317a6f5a5808a0a727e98f80f088b84
So, it looks like the default v8 [platform] isn't chrome-dev-tools
compatible.
Ibon's case worked as it has a specific Android platform implementation.
Chromium and Node also have their own platform.
So, I made the most basic platform proxy possible to work around it...
https://github.com/SoylentGraham/V8InspectorMinimal/blob/master/src/TV8Platform.h
And it works!
I can now modify code on the fly, execute from the console.
I can't seem to debug, and pressing pause-execution a few times gives me a
new assert, but the higher level code is a bit of a mess at this point, so
I'm probably implementing something wrong...
Still, if anyone else ever finds this problem... V8 alone cannot be used
with chrome dev tools. (as of 7.1.0.0
4544e18b0c3845a9fca422cf0903df4803343cf1)
On Friday, 14 September 2018 11:44:33 UTC+1, @soylentgraham wrote:
>
> So the core of my issue at the moment, is this assert (UNIMPLEMENTED)
>
> void
> DefaultWorkerThreadsTaskRunner::PostDelayedTask(std::unique_ptr task,
>
> double
> delay_in_seconds) {
>
> base::LockGuard guard(_);
>
> if (terminated_) return;
>
> if (delay_in_seconds == 0) {
>
> queue_.Append(std::move(task));
>
> return;
>
> }
>
> // There is no use case for this function with non zero delay_in_second
> on a
>
> // worker thread at the moment, but it is still part of the interface.
>
> UNIMPLEMENTED();
>
> }
>
> from
>
> DefaultPlatform::CallDelayedOnWorkerThread(
>
> being called by
>
> protocol::Response V8InspectorImpl::EvaluateScope::setTimeout(double
> timeout) {
>
> if (m_isolate->IsExecutionTerminating()) {
>
> return protocol::Response::Error("Execution was terminated");
>
> }
>
> m_cancelToken.reset(new CancelToken());
>
> v8::debug::GetCurrentPlatform()->CallDelayedOnWorkerThread(
>
> v8::base::make_unique(m_isolate, m_cancelToken),
> timeout);
>
> return protocol::Response::OK();
>
> }
>
>
>
> so, SetTimeout in the inspector, explicitly uses something we[developers]
> know isn't implemented...
> From reading things before, Node.js was using the default platform, I
> think now it has it's own platform. Maybe chromium does too...
> Perhaps the demo/unittest debugger/d8/inspector doesn't call settimeout,
> so this hasn't been found with default setups...
>
> Maybe I HAVE to implement my own platform to support chrome dev tools and
> handle delayed jobs...
>
>
> On Thursday, 13 September 2018 17:14:58 UTC+1, @soylentgraham wrote:
>>
>> For any future readers;
>> I went back to trying to build a debug v8 set of libs (wouldnt compile
>> before, added is_component_build=false which I think fixed that)
>> Built with latest master (4544e18b0c3845a9fca422cf0903df4803343cf1)
>>
>> Which forced me to correct a few uses of deprecated functions, including
>> v8::String::NewFromUtf8() with no isolate, so *possibly* that was the
>> source of the crash re: scriptorigin. I now get an origin in CDT (kinda, it
>> still breaks in a VMXX file)
>>
>> Then asserts as before in "code that should never be reached" (see
>> earlier in the thread)
>>
>> [image: Screen Shot 2018-09-13 at 17.08.09.png]
>>
>>
>>
>> On Wednesday, 12 September 2018 17:34:30 UTC+1, @soylentgraham wrote:
>>>
>>> With a lot of back & forth help from Ibon/hyperandroid, we've got a bit
>>> further in working out which things are good, and which are bad.
>>> Feels like we're close, but things are still unstable, and a bit
>>> unresponsive.
>>>
>>> I can kinda break into the code (which only shows *this *in sources)
>>> Still get the assert above from trying to autocomplete too many times.
>>> (albeit after a RunMessageLoop callback now)
>>> And if I add a script origin, I get a crash trying to stacktrace
>>> (immediately when connecting, still trying to figure this out, as my
>>> scriptorigin is okay)
>>>
>>> More stripped back version here (cutting more dependencies out, but all
>>> my setup, inspector, frontend, messaging is in v8minimal.cpp)
>>> https://github.com/SoylentGraham/V8InspectorMinimal
>>>
>>> On Monday, 27 August 2018 13:49:37 UTC+1, @soylentgraham wrote:
>>>>
>>>> Through various sources (ie, googling & github) I've finally got a bit
>>>> of a g
[v8-users] Re: ChromeDevTools connected to Inspector, but error responses... missing native JS functions?
So the core of my issue at the moment, is this assert (UNIMPLEMENTED)
void DefaultWorkerThreadsTaskRunner::PostDelayedTask(std::unique_ptr
task,
double
delay_in_seconds) {
base::LockGuard guard(_);
if (terminated_) return;
if (delay_in_seconds == 0) {
queue_.Append(std::move(task));
return;
}
// There is no use case for this function with non zero delay_in_second
on a
// worker thread at the moment, but it is still part of the interface.
UNIMPLEMENTED();
}
from
DefaultPlatform::CallDelayedOnWorkerThread(
being called by
protocol::Response V8InspectorImpl::EvaluateScope::setTimeout(double
timeout) {
if (m_isolate->IsExecutionTerminating()) {
return protocol::Response::Error("Execution was terminated");
}
m_cancelToken.reset(new CancelToken());
v8::debug::GetCurrentPlatform()->CallDelayedOnWorkerThread(
v8::base::make_unique(m_isolate, m_cancelToken),
timeout);
return protocol::Response::OK();
}
so, SetTimeout in the inspector, explicitly uses something we[developers]
know isn't implemented...
>From reading things before, Node.js was using the default platform, I think
now it has it's own platform. Maybe chromium does too...
Perhaps the demo/unittest debugger/d8/inspector doesn't call settimeout, so
this hasn't been found with default setups...
Maybe I HAVE to implement my own platform to support chrome dev tools and
handle delayed jobs...
On Thursday, 13 September 2018 17:14:58 UTC+1, @soylentgraham wrote:
>
> For any future readers;
> I went back to trying to build a debug v8 set of libs (wouldnt compile
> before, added is_component_build=false which I think fixed that)
> Built with latest master (4544e18b0c3845a9fca422cf0903df4803343cf1)
>
> Which forced me to correct a few uses of deprecated functions, including
> v8::String::NewFromUtf8() with no isolate, so *possibly* that was the
> source of the crash re: scriptorigin. I now get an origin in CDT (kinda, it
> still breaks in a VMXX file)
>
> Then asserts as before in "code that should never be reached" (see earlier
> in the thread)
>
> [image: Screen Shot 2018-09-13 at 17.08.09.png]
>
>
>
> On Wednesday, 12 September 2018 17:34:30 UTC+1, @soylentgraham wrote:
>>
>> With a lot of back & forth help from Ibon/hyperandroid, we've got a bit
>> further in working out which things are good, and which are bad.
>> Feels like we're close, but things are still unstable, and a bit
>> unresponsive.
>>
>> I can kinda break into the code (which only shows *this *in sources)
>> Still get the assert above from trying to autocomplete too many times.
>> (albeit after a RunMessageLoop callback now)
>> And if I add a script origin, I get a crash trying to stacktrace
>> (immediately when connecting, still trying to figure this out, as my
>> scriptorigin is okay)
>>
>> More stripped back version here (cutting more dependencies out, but all
>> my setup, inspector, frontend, messaging is in v8minimal.cpp)
>> https://github.com/SoylentGraham/V8InspectorMinimal
>>
>> On Monday, 27 August 2018 13:49:37 UTC+1, @soylentgraham wrote:
>>>
>>> Through various sources (ie, googling & github) I've finally got a bit
>>> of a grasp of the flow for connecting chrome dev tools to my v8 app. (which
>>> is using a pretty recent HEAD build I've built myself with all default
>>> settings other than compiling as a static lib[s]. v8-version.h says 7.0.0.0)
>>>
>>> I connect via an explicit url (can't quite get json/list/ to show up in
>>> chrome yet)
>>> *chrome-devtools://devtools/bundled/inspector.html?experiments=true=true=127.0.0.1:8008
>>>
>>> <http://127.0.0.1:8008>*
>>> (Not sure how relevant the v8only=true and experiments=true are,
>>> couldn't find any documentation on this)
>>>
>>> This connects to my websocket, and I pass all messages straight to
>>> *Session->dispatchProtocolMessage*
>>>
>>> My channel then gets *sendResponse's* in return, which I send back to
>>> chrome over my websocket.
>>>
>>> Chrome dev tools shows essentially an empty debugger, no sources, no
>>> console output, no errors...
>>>
>>> The responses my isolate/context sends back, suggest maybe I have some
>>> JS symbols/modules missing, which maybe I need to implement?
>>> I'm kinda assuming this, as the debugger. methods succeed, but things
>>> like *Inspector.enable* (which I haven't found anyone implementing, but
>>> some people are implementing Inspector objects, just with different
>>
[v8-users] Re: ChromeDevTools connected to Inspector, but error responses... missing native JS functions?
For any future readers;
I went back to trying to build a debug v8 set of libs (wouldnt compile
before, added is_component_build=false which I think fixed that)
Built with latest master (4544e18b0c3845a9fca422cf0903df4803343cf1)
Which forced me to correct a few uses of deprecated functions, including v8
::String::NewFromUtf8() with no isolate, so *possibly* that was the source
of the crash re: scriptorigin. I now get an origin in CDT (kinda, it still
breaks in a VMXX file)
Then asserts as before in "code that should never be reached" (see earlier
in the thread)
[image: Screen Shot 2018-09-13 at 17.08.09.png]
On Wednesday, 12 September 2018 17:34:30 UTC+1, @soylentgraham wrote:
>
> With a lot of back & forth help from Ibon/hyperandroid, we've got a bit
> further in working out which things are good, and which are bad.
> Feels like we're close, but things are still unstable, and a bit
> unresponsive.
>
> I can kinda break into the code (which only shows *this *in sources)
> Still get the assert above from trying to autocomplete too many times.
> (albeit after a RunMessageLoop callback now)
> And if I add a script origin, I get a crash trying to stacktrace
> (immediately when connecting, still trying to figure this out, as my
> scriptorigin is okay)
>
> More stripped back version here (cutting more dependencies out, but all my
> setup, inspector, frontend, messaging is in v8minimal.cpp)
> https://github.com/SoylentGraham/V8InspectorMinimal
>
> On Monday, 27 August 2018 13:49:37 UTC+1, @soylentgraham wrote:
>>
>> Through various sources (ie, googling & github) I've finally got a bit of
>> a grasp of the flow for connecting chrome dev tools to my v8 app. (which is
>> using a pretty recent HEAD build I've built myself with all default
>> settings other than compiling as a static lib[s]. v8-version.h says 7.0.0.0)
>>
>> I connect via an explicit url (can't quite get json/list/ to show up in
>> chrome yet)
>> *chrome-devtools://devtools/bundled/inspector.html?experiments=true=true=127.0.0.1:8008
>>
>> <http://127.0.0.1:8008>*
>> (Not sure how relevant the v8only=true and experiments=true are, couldn't
>> find any documentation on this)
>>
>> This connects to my websocket, and I pass all messages straight to
>> *Session->dispatchProtocolMessage*
>>
>> My channel then gets *sendResponse's* in return, which I send back to
>> chrome over my websocket.
>>
>> Chrome dev tools shows essentially an empty debugger, no sources, no
>> console output, no errors...
>>
>> The responses my isolate/context sends back, suggest maybe I have some JS
>> symbols/modules missing, which maybe I need to implement?
>> I'm kinda assuming this, as the debugger. methods succeed, but things
>> like *Inspector.enable* (which I haven't found anyone implementing, but
>> some people are implementing Inspector objects, just with different
>> methods) fail
>>
>> *Chrome tools message: {"id":16,"method":"Inspector.enable"}*
>>
>> *Channel response: {"error":{"code":-32601,"message":"'Inspector.enable'
>> wasn't found"},"id":16}*
>> Is this why chrome isn't proceeding with anything?
>> Am I supposed to implement these, or perhaps are they missing from my
>> native blobs when I built my v8 libraries?
>>
>> My overloads of the inspector client functions like
>> *runMessageLoopOnPause* aren't being called, but I assume that's just
>> because I haven't gotten to any stage where commands are being evaluated?
>>
>> Below is what I get when I connect chrome, but then it just sits there :)
>>
>> Thanks for any pointers in the right direction!
>>
>> *Chrome tools message:
>> {"id":1,"method":"Network.enable","params":{"maxPostDataSize":65536}}*
>>
>> *Channel response: {"error":{"code":-32601,"message":"'Network.enable'
>> wasn't found"},"id":1}*
>>
>> *Chrome tools message: {"id":2,"method":"Page.enable"}*
>>
>> *Channel response: {"error":{"code":-32601,"message":"'Page.enable'
>> wasn't found"},"id":2}*
>>
>> *Chrome tools message: {"id":3,"method":"Page.getResourceTree"}*
>>
>> *Chrome tools message: {"id":4,"method":"Profiler.enable"}*
>>
>> *Channel response:
>> {"error":{"code":-32601,"message":"'Page.getResourceTr
[v8-users] Re: ChromeDevTools connected to Inspector, but error responses... missing native JS functions?
With a lot of back & forth help from Ibon/hyperandroid, we've got a bit
further in working out which things are good, and which are bad.
Feels like we're close, but things are still unstable, and a bit
unresponsive.
I can kinda break into the code (which only shows *this *in sources)
Still get the assert above from trying to autocomplete too many times.
(albeit after a RunMessageLoop callback now)
And if I add a script origin, I get a crash trying to stacktrace
(immediately when connecting, still trying to figure this out, as my
scriptorigin is okay)
More stripped back version here (cutting more dependencies out, but all my
setup, inspector, frontend, messaging is in v8minimal.cpp)
https://github.com/SoylentGraham/V8InspectorMinimal
On Monday, 27 August 2018 13:49:37 UTC+1, @soylentgraham wrote:
>
> Through various sources (ie, googling & github) I've finally got a bit of
> a grasp of the flow for connecting chrome dev tools to my v8 app. (which is
> using a pretty recent HEAD build I've built myself with all default
> settings other than compiling as a static lib[s]. v8-version.h says 7.0.0.0)
>
> I connect via an explicit url (can't quite get json/list/ to show up in
> chrome yet)
> *chrome-devtools://devtools/bundled/inspector.html?experiments=true=true=127.0.0.1:8008
>
> <http://127.0.0.1:8008>*
> (Not sure how relevant the v8only=true and experiments=true are, couldn't
> find any documentation on this)
>
> This connects to my websocket, and I pass all messages straight to
> *Session->dispatchProtocolMessage*
>
> My channel then gets *sendResponse's* in return, which I send back to
> chrome over my websocket.
>
> Chrome dev tools shows essentially an empty debugger, no sources, no
> console output, no errors...
>
> The responses my isolate/context sends back, suggest maybe I have some JS
> symbols/modules missing, which maybe I need to implement?
> I'm kinda assuming this, as the debugger. methods succeed, but things like
> *Inspector.enable* (which I haven't found anyone implementing, but some
> people are implementing Inspector objects, just with different methods) fail
>
> *Chrome tools message: {"id":16,"method":"Inspector.enable"}*
>
> *Channel response: {"error":{"code":-32601,"message":"'Inspector.enable'
> wasn't found"},"id":16}*
> Is this why chrome isn't proceeding with anything?
> Am I supposed to implement these, or perhaps are they missing from my
> native blobs when I built my v8 libraries?
>
> My overloads of the inspector client functions like
> *runMessageLoopOnPause* aren't being called, but I assume that's just
> because I haven't gotten to any stage where commands are being evaluated?
>
> Below is what I get when I connect chrome, but then it just sits there :)
>
> Thanks for any pointers in the right direction!
>
> *Chrome tools message:
> {"id":1,"method":"Network.enable","params":{"maxPostDataSize":65536}}*
>
> *Channel response: {"error":{"code":-32601,"message":"'Network.enable'
> wasn't found"},"id":1}*
>
> *Chrome tools message: {"id":2,"method":"Page.enable"}*
>
> *Channel response: {"error":{"code":-32601,"message":"'Page.enable' wasn't
> found"},"id":2}*
>
> *Chrome tools message: {"id":3,"method":"Page.getResourceTree"}*
>
> *Chrome tools message: {"id":4,"method":"Profiler.enable"}*
>
> *Channel response:
> {"error":{"code":-32601,"message":"'Page.getResourceTree' wasn't
> found"},"id":3}*
>
> *Channel response: {"id":4,"result":{}}*
>
> *Chrome tools message: {"id":5,"method":"Runtime.enable"}*
>
> *Channel response:
> {"method":"Runtime.executionContextCreated","params":{"context":{"id":1,"origin":"","name":"PopEngineContextName"}}}*
>
> *Channel response: {"id":5,"result":{}}*
>
> *Chrome tools message: {"id":6,"method":"Debugger.enable"}*
>
> *Channel response:
> {"method":"Debugger.scriptParsed","params":{"scriptId":"9","url":"","startLine":0,"startColumn":0,"endLine":1,"endColumn":0,"executionContextId":1,"hash":"2a70962568dbbde00fb323decd63c2ca137b304c","isLiveEdit":false,"sourceM
Re: [v8-users] Arraybuffer
> First, how big is the data member of the object ?
As I said before. Capacity is the size of the memory allocated that data
points at.
> Is it as big as the actual array buffer length which I declare on
JavaScript
It will be either as big, or bigger. It can grow.
bytes_used will be the size that matches javascript.
> which I can build on top of it a typedarray ?
This is a slightly different question, (and needs clarifying)
When you create a typedarray in C++, it needs an array buffer.
When you create a typedarray in javascript, it will have an array buffer
behind it. (which you may or may not have created in javascript or c++,
there are several ways of approaching this)
> So, when a typedarray is build on top of an areaybuffer instance, how do
I get to call the arraybufferbuilder::append ?
Aha! a more specific question!
Are you trying to call arraybufferbuilder::append in javascript, or c++?
Why? are you trying to make a typedarray bigger? (in javascript or c++?)
I believe once created they're a fixed size in javascript.
I have a feeling on the c++ side, you can't change the size once created
(but I may be wrong, you have direct access to the buffer's buffercontents
via the bufferview...)
Can you make your question a lot more specific? post some code?
On Monday, 10 September 2018 22:38:16 UTC+1, dan Med wrote:
>
> First, how big is the data member of the object ? Is it as big as the
> actual array buffer length which I declare on JavaScript and which I can
> build on top of it a typedarray ?
>
> No, I’m just trying to understand how v8 works, I know it is a big thing
> but at least how it moves then I might read the code and understand, extra
> parts.
>
> So, when a typedarray is build on top of an areaybuffer instance, how do I
> get to call the arraybufferbuilder::append ?
>
>
>
>
>
> On Mon, 10 Sep 2018 at 23:30, @soylentgraham > wrote:
>
>> I'm guessing you may be a bit new to unmanaged-memory languages/systems.
>>
>> buffer is an object, (it's structure/layout will look a bit like it's
>> class declaration, but it's a little more complex than that) that was
>> allocated somewhere sometime, (you can figure out where, but really you
>> don't need to, for this purpose it's just an object)
>> data is a member of that object, that points to some memory (somewhere
>> else, maybe allocated by a different system, in a different place)
>> you have no idea (and you shouldn't need to know, or use the information)
>> the "offset" from the buffer-object to the data. They are not necessarily
>> related, or share the same memory space. (and in most cases, they're not
>> even real memory addresses, they're more like identifiers)
>>
>> Simple Javascript scripts can look like C sometimes (a few variables here
>> and there, a few array creations), but underneath it's doing a lot more
>> moving things around.
>> function x()
>> {
>> var a = new array(10);
>> var b = new array(100);
>> }
>> This may look like it allocates 2 arrays, but more than likely it's doing
>> something radically different with actual memory.
>>
>>
>> > so how can i see the memory management ?
>> As I said, you can't see the javascript side so easily (other than using
>> the v8 debugging/inspector tools)
>> But if you want to see the C-side memory (which MAY be where the data
>> that buffer points at came from) you can make your own allocator that v8
>> can use.
>> If you then breakpoint each call, you'll know when V8 is allocating some
>> memory to use (which may or may not be a direct object in javascript, an
>> array or typed array in javascript may not directly allocate here)
>>
>>
>> class TV8Allocator : public v8::ArrayBuffer::Allocator
>>
>> {
>>
>> public:
>>
>> virtual void* Allocate(size_t length) override;
>>
>> virtual void* AllocateUninitialized(size_t length) override;
>>
>> virtual void Free(void* data, size_t length) override;
>>
>> };
>>
>>
>> void* TV8Allocator::Allocate(size_t length)
>>
>> {
>>
>> auto* Bytes = new uint8_t[length];
>>
>> for ( auto i=0; i>
>> Bytes[i] = 0;
>>
>> return Bytes;
>>
>> }
>>
>>
>> void* TV8Allocator::AllocateUninitialized(size_t length)
>>
>> {
>>
>> auto* Bytes = new uint8_t[length];
>>
>> return Bytes;
>>
>> }
>>
>>
>> void TV8Allocator::Free(void* data, size_t length)
>>
>> {
>>
>> auto* data8 = reinterpret_cast(data);
>>
>> delete[] data8;
>>
>> }
>>
>
