Hi Jeremy,
Thanks for your suggestion, that's looking like the easiest thing to do at
this point. Its a shame the default one is not exposed in the basic API,
it seems like such an obvious requirement, but re-inventing the wheel is
good too :)
I really like the V8 engine, but its C++ leaves a lot to be desired I must
say, it does not make it easy to do what should be trivial things. I am not
knocking it, I am better off with it than without it :)
Thanks,
Gerry
On Tuesday, February 5, 2019 at 3:47:05 PM UTC, Jeremy Bettis wrote:
>
> I have found the easiest thing is to delete the built in console
> (global->Delete) and then add your own.
>
> Setting the console delegate requires using the inspector API and is
> harder.
>
> On Tue, Feb 5, 2019, 8:12 AM <ca...@igalia.com <javascript:> wrote:
>
>>
>>
>> > On Feb 5, 2019, at 10:02 AM, Gerry Sweeney <gez...@gmail.com
>> <javascript:>> wrote:
>> >
>> > Hello Caitlin,
>> >
>> > First of all, thank you for your response, and yes you are right I
>> should have been far clearer in my question, please let me clarify.
>> >
>> > I have a process, is an x64 C++ application that normally runs as a
>> Windows service or a Linux Deamon, its job is to provide a way for our user
>> to write application logic in JavaScript, which we then invoke using a REST
>> type API. Under normal circumstances, this project runs as a service, but
>> when working on the code, it's essentially running as a Windows console
>> application, anything emitted on stdout appears in the console window of
>> the running process. The process is conceptually similar to a Node.js
>> server process.
>> >
>> > This process is written in C++ and embeds V8, and in the current model,
>> we create an Isolate and Context per API request made, and when we process
>> a request, we are loading some JavaScript from a cache and executing it.
>> As part of the embedding, we have created a number of native objects in
>> C++ that are exposed in the JavaScript domain, classes that provide access
>> to the underlying database, memory cache and other relates to web services.
>> >
>> > When we write JavaScript we have to debug it, and in the absence of
>> using CDT for remote debugging (which we are in the process of
>> implementing), we could at least do with using console.log(). We have
>> implemented a websocket interface that on a call by call basis allows our
>> C++ code to send arbitrary content back to the developer (of the
>> JavaScript) workstation.
>> >
>> > So I need a way of implementing console.log() where I can redirect its
>> output to my own websocket. My intention was to create an object called
>> "console" and create a function on that object called "log()" and create an
>> instance of that object in the global namespace, thus simulating the
>> console.log() web developers are used in browsers.
>> >
>> > However, what I found is, without me creating these objects, they
>> appear to already exist in the default implementation of v8. In other
>> words, if I write console.log("Hello, World") the script runs without
>> error, which tells me that the console object exists, and the log()
>> function exists.
>> >
>> > So rather than re-invent the wheel and implement my own version of
>> console.log() I thought it might just be simpler to find a way to capture
>> the output of what already exists. Thing is, I have no idea where to
>> start.
>> >
>> > Also, which console.log() implementation are you using? The one from
>> d8-console.cc? One from Node.js or Chromium? A custom one?
>> > I am assuming that the embedded V8 library includes by default the
>> console object
>>
>> Ah I see you're right, this is now included in the initial context. It
>> looks like you need to use `debug::SetConsoleDelegate(isolate,
>> ConsoleDelegate*)` in order to provide the behaviour you want --- however,
>> I'm not sure how this is exposed to the public API. Inspector folks could
>> help more with that.
>>
>> It looks like by default, the Isolate's console_delegate_ is null, and
>> the builtin console.log returns early if that's the case.
>>
>> > We are using 6.9.167 of the v8 engine in this project.
>> >
>> > I hope that makes more sense now - sorry for the poor quality initial
>> question.
>> > Gerry
>> >
>> >
>> > --
>> > --
>> > v8-users mailing list
>> > v8-u...@googlegroups.com <javascript:>
>> > http://groups.google.com/group/v8-users
>> > ---
>> > You received this message because you are subscribed to the Google
>> Groups "v8-users" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to v8-users+u...@googlegroups.com <javascript:>.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> --
>> v8-users mailing list
>> v8-u...@googlegroups.com <javascript:>
>> http://groups.google.com/group/v8-users
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "v8-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to v8-users+u...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
