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
>>>
>>> *
>>> (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
