Hello!
I'm trying to build the 6.6 branch tip for WIndows. After installing
depot_tools, I run the following commands in a Visual Studio 2017 prompt:
set DEPOT_TOOLS_WIN_TOOLCHAIN=0
gclient config https://chromium.googlesource.com/v8/v8
gclient sync -r 6.6.346.24
cd v8
gn gen out --args="is_debu
Fixed. I was trying to build 64-bit V8 in a Visual Studio command prompt
configured for 32-bit targets.
On Sunday, April 15, 2018 at 3:54:19 PM UTC-4, Bit Cortex wrote:
>
> Hello!
>
> I'm trying to build the 6.6 branch tip for WIndows. After installing
> depot_tools,
That is, can this method be called from another thread while V8 is running
script code?
--
--
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
Is it safe to call this method from another thread while V8 is running
script code?
--
--
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
C+2, Ben Noordhuis wrote:
>>
>> On Mon, Apr 15, 2019 at 4:33 PM Bit Cortex wrote:
>> > That is, can this method be called from another thread while V8 is
>> running script code?
>>
>> I think the answer is "probably not" but it needs som
Does anyone have any information on the handle-related API changes in
3.19.16?
I can still get my project to compile by #defining
V8_USE_UNSAFE_HANDLES, but how long will that last?
Are the handle-related API changes complete at this point? Will someone
post any documentation or update the embe
> semantics of Persistent, which could affect program operation and
> performance in unexpected ways.
>
> We'll post again once these changes are in and the docs are updated.
>
> Cheers,
> Dan
>
>
> On Friday, June 14, 2013 7:34:02 PM UTC+2, Bit Cortex wrote:
&g
Hi Dan,
In the latest stable source, that Local::New method is marked "//
TODO(dcarney): remove before cutover". Does that mean the new API is still
not finalized and the method is likely to go away?
Thanks!
On Tuesday, September 3, 2013 2:56:12 AM UTC-4, Dan Carney wrote:
>
>
> 1st question i
Hi Ben,
A couple of questions:
1. How does the embedder know what reponse to send to the debugger?
v8::Debug::SendCommand() doesn't return anything.
2. Do you know if the debug protocol change will affect V8's debugging API?
Thanks!
On Sunday, August 24, 2014 4:33:10 PM UTC-4, Ben Noordhuis w
Thank you very much, Ben!
On Tuesday, August 26, 2014 7:52:56 AM UTC-4, Ben Noordhuis wrote:
>
> On Mon, Aug 25, 2014 at 10:02 PM, Bit Cortex > wrote:
> > 1. How does the embedder know what reponse to send to the debugger?
> > v8::Debug::SendCommand() doesn't return
Thanks, Michael. Will the current SVN repository be removed?
On Tuesday, September 16, 2014 3:09:42 AM UTC-4, Michael Achenbach wrote:
>
> Hi!
>
> We're planning to migrate the V8 sources from Svn to Git. The estimated
> timeline for this is 1-2 month.
>
> We won't migrate before all known blocki
V8 experts,
I'm having trouble understanding the task scheduling requirements of the
embedder's v8::Platform implementation. Some questions:
1. Is it a requirement that all foreground tasks for a given isolate be run
on the same thread?
2. Must foreground tasks be run with the isolate lock held
Ben, thanks for your response. Follow-up questions below:
> 2. Must foreground tasks be run with the isolate lock held?
>
> ...yes, you have to hold the lock.
>
Hmm, I just noticed that v8::platform::DefaultPlatform doesn't acquire the
lock to run foreground tasks. On the other hand, the V8 sa
Jochen, thanks for your help. Just hoping to get one more clarification:
On Tuesday, September 22, 2015 at 3:01:28 AM UTC-4, Jochen Eisinger wrote:
>
> Currently, the foreground tasks can run wherever the embedder wants to run
> them, but in the future, we might require that it's safe to access t
V8 experts,
Until recently I've been able to use a very simple procedure to build V8 on
Windows:
1. Clone v8 and check out the required tag
2. Clone gyp and cygwin into build\gyp and third_party\cygwin respectively
3. Run gyp to generate the VS project (without i18n support)
4. Run msbuild to bu
I couldn't get it to work even with the environment variable.
However, with the environment variable set, gyp doesn't complain about
depot_tools, and I can build V8 4.8 using my old build procedure (above).
So far every attempt I've made to use depot_tools has failed. Seems a
bit... particular.
Hello!
I'm building a Linux shared library that incorporates V8. This is working
perfectly with the debug V8 monolith, but not at all with release. I've
noticed that V8's release build produces an archive full of LLVM IR bitcode
files instead of normal ELF objects.
V8 release build args:
e
Hello!
Could someone describe the purpose of the line and column offset properties
of v8::ScriptOrigin? What effect do nonzero values have?
Thanks!
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subs
at 5:05:50 PM UTC-5 Ben Noordhuis wrote:
> On Wed, Nov 11, 2020 at 9:26 PM Bit Cortex wrote:
> >
> > Hello!
> >
> > Could someone describe the purpose of the line and column offset
> properties of v8::ScriptOrigin? What effect do nonzero values have?
> >
> &
Thanks for your responses!
On Friday, November 13, 2020 at 1:22:51 AM UTC-5 szu...@google.com wrote:
> This is used e.g. when your script is inline in
20 matches
Mail list logo
