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 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)
