I've got the standard boilerplate for setting up a constructor function, but am
doing many, in a loop:
for (.....) // this is a loop
{
v8::Local<v8::FunctionTemplate> constructor_template =
v8::FunctionTemplate::New(MyInitializer);
constructor_template->InstanceTemplate()->SetInternalFieldCount(1);
void *my_pointer = (some dynamic value);
// Here I want my_pointer to be set on every instance created from this
template
}
So I want every instance created through MyInitializer to contain the value in
my_pointer. The obvious thing would be to have an internal pointer field on
the template, that gets propagated to the instances, but that seems unsupported.
I noticed that FunctionTemplate::New can take a data field, though I'm not sure
where that goes.
On Dec 3, 2010, at 5:49 AM, JulienC wrote:
> Hi Alexandre,
>
> I've just make some investigations and finally I found that "float"
> number seems to be wrong on our arm system
> for example
>> 1/3
> 1.194530457405681e+103
>
> don't know if it can come from BIG_ENDIAN_FLOATING_POINT, nothing
> change when I try to play with it (1/3 always gives the same result).
> we are on an OABI armV4 (arm920t).
>
> Best regards.
> Julien.
>
> On Dec 2, 7:23 pm, Alexandre Rames <[email protected]> wrote:
>> Well this must be a problem with your system then. I just spot that
>> 8.26...e-315 is not in the range of ieee 64bit floating points!
>> You can follow the call chain from
>> CodeGenerator::GenerateRandomHeapNumner 's call to
>> fill_heap_number_with_random_function (codegen-arm.cc)
>> up to
>> static uint32_t random_base(random_state *state) (v8.cc)
>> which uses random_seed().
>>
>> You should try to investigate how your system is linked to v8 here.
>>
>> I think Math.floor does not return an integer on your platform because it
>> can't handle the illegal value generated by your Math.random.
>>
>> Alexandre
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Dec 2, 2010 at 4:39 PM, JulienC <[email protected]> wrote:
>>> Hi Alexandre,
>>
>>> I think that our issue is caused by Math.random() and not Math.floor()
>>> because:
>>> on mac:
>>> >Math.random()
>>> 0.8807874456979334
>>
>>> on arm:
>>> >Math.random()
>>> 8.263547083e-315 // 0.00000000000...826 so floor should return 0 most
>>> of time.
>>
>>> but on arm:
>>> >Math.floor(2.1534)
>>> 2
>>
>>> So floor seems to work correctly if the number is not to big.
>>
>>> Best regards,
>>> Julien
>>
>>> On Dec 2, 5:02 pm, Alexandre Rames <[email protected]> wrote:
>>>> Hi Julien,
>>
>>>> I don't have actual ARM4 hardware, but everything works fine for me on
>>> the
>>>> Simulator when disabling armv7 and vfp3 (equivalent to using armv4 on
>>> v8).
>>
>>>> I don't know too much about the Date issue. It looks like something is
>>> wrong
>>>> in the bindings between v8 and your system.
>>
>>>> A few hints for the Math.floor issue:
>>>> - Use a debug version of the shell to debug / carry your tests.
>>>> - Do you pass the cctests?
>>>> tools/test.py --snapshot --mode=debug -j3
>>>> - Especially do you pass the mjsunit/math-floor.js test?
>>>> ./shell_g --enable-slow-asserts --debug-code --verify-heap
>>>> --max-new-space-size=256 test/mjsunit/mjsunit.js
>>> test/mjsunit/math-floor.js
>>
>>>> - You may want to check the hex value returned by your call to Math.floor
>>>> with gdb / ddd.
>>>> ARMv4 does not use an assembly optimization for Math.floor, so it seems
>>>> unlikely that the result of the computation is false.
>>>> You can try check the double returned by v8 to see if it is correct.
>>>> I could not confirm on a quick test that v8::internal::Runtime_Math_floor
>>>> (runtime.cc) is called, but you may want to put a breakpoint there.
>>>> Otherwise v8 may call a builtin. You can use a breakpoint (with a counter
>>> to
>>>> stop at the right time) in v8::internal::Invoke (execution.cc) around
>>> value
>>>> = CALL_GENERATED_CODE(... (~line 94) .
>>
>>>> I found an interesting issue while investigating your bug: compiling the
>>>> shell in debug mode with the snapshot option on and running with
>>>> noenable_armv7 and noenable_vfp3 generates some incoherency: natives are
>>>> compiled with vfp3 and armv7, so we still execute this code when calling
>>>> them!
>>>> But this has nothing to do with your bug. This won't happen on actual
>>>> hardware, and you would get an illegal instruction exception or so.
>>
>>>> Cheers
>>
>>>> Alexandre
>>
>>>> On Thu, Dec 2, 2010 at 11:35 AM, JulienC <[email protected]> wrote:
>>>>> We are currently using uClibC, it works well for all the system we
>>>>> have (glib + protocol buffer + mplayer + ...).
>>
>>>>> We compile V8, it almost work. But Math.random() returns
>>>>> "8.263547083e-315" and the strange issue for the date.
>>
>>>>> I cannot find if it comes from V8 or uClibC.
>>
>>>>> I've tried unsuccessfully to use a standard libC in our environment
>>>>> but it a to complex modification in our system.
>>
>>>>> Do you have any idea ?
>>
>>>>> Best regards.
>>>>> Julien.
>>
>>>>> On Nov 26, 1:29 pm, Rodolph Perfetta <[email protected]>
>>>>> wrote:
>>>>>> Hi,
>>
>>>>>> I couldn't reproduce your issue, an armv4 build of bleeding_edge
>>> gives me
>>>>>> the right result.
>>
>>>>>> Are the C libraries on your platform working properly? Could you try
>>> and
>>>>>> narrow it down a bit: is it Math.floor or Math.random (or both) which
>>> is
>>>>> an
>>>>>> issue?
>>
>>>>>> Cheers,
>>>>>> Rodolph.
>>
>>>>>> On 25 November 2010 14:09, JulienC <[email protected]> wrote:
>>
>>>>>>> Hi all,
>>
>>>>>>> I currently encounter 2 issues with V8 on armV4 (arm920t), I don't
>>>>>>> know if they are related or not.
>>
>>>>>>> The first is with Math.random() when I try to get a number in 0-9,
>>
>>>>>>> on my mac, it works well:
>>>>>>> >Math.floor(Math.random()*10)
>>>>>>> 2
>>
>>>>>>> on armV4, strange behaviour:
>>>>>>> >Math.floor(Math.random()*10)
>>>>>>> 1.6427083566e-314
>>
>>>>>>> I'm using the trunk but it seems to do the same for all versions.
>>
>>>>>>> The second issue is concerning the Date object, when I try to set a
>>>>>>> date, it always return 01/01/1970...
>>
>>>>>>> on my mac:
>>>>>>> > new Date()
>>>>>>> Thu Nov 25 2010 14:59:26 GMT+0100 (CET)
>>>>>>> > new Date(2009, 11, 30)
>>>>>>> Wed Dec 30 2009 00:00:00 GMT+0100 (CET)
>>
>>>>>>> on armV4:
>>>>>>> > new Date()
>>>>>>> Thu Nov 25 2010 00:00:00 GMT+0000 (UTC) //no time ?
>>>>>>> > new Date(2009, 11, 30)
>>>>>>> Thu Jan 01 1970 00:00:00 GMT+0000 (UTC) // wrong date !
>>
>>>>>>> I hope that someone has any idea about one of those issues.
>>
>>>>>>> Best regards.
>>
>>>>>>> --
>>>>>>> v8-users mailing list
>>>>>>> [email protected]
>>>>>>> http://groups.google.com/group/v8-users
>>
>>>>> --
>>>>> v8-users mailing list
>>>>> [email protected]
>>>>> http://groups.google.com/group/v8-users
>>
>>> --
>>> v8-users mailing list
>>> [email protected]
>>> http://groups.google.com/group/v8-users
>
> --
> v8-users mailing list
> [email protected]
> http://groups.google.com/group/v8-users
--
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
