Author: [EMAIL PROTECTED]
Date: Wed Oct 8 23:55:08 2008
New Revision: 473
Modified:
branches/bleeding_edge/src/codegen.h
Log:
Fix typo in comment (issue 108).
Modified: branches/bleeding_edge/src/codegen.h
==
--- b
Issue 108: comment typo fix
http://code.google.com/p/v8/issues/detail?id=108
Comment #4 by erik.corry:
gode -> code
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preference
Sounds reasonable.
I will scrap this change and rebaseline the test instead.
On Wed, Oct 8, 2008 at 10:43 PM, Kasper Lund <[EMAIL PROTECTED]> wrote:
> Maybe it would be even better to try to submit a patch to the layout
> test itself to stop being so picky about character casing for
> exception m
Issue 105: Implicit call to valueOf has wrong caller
http://code.google.com/p/v8/issues/detail?id=105
Comment #2 by [EMAIL PROTECTED]:
So the point here is that people can see that valueOf is invoked through
our builtin DefaultNumber JavaScript function? It should be possible to
*not* return
LGTM
On Thu, Oct 9, 2008 at 7:46 AM, <[EMAIL PROTECTED]> wrote:
>
> Author: [EMAIL PROTECTED]
> Date: Wed Oct 8 22:39:00 2008
> New Revision: 472
>
> Modified:
>branches/bleeding_edge/include/v8.h
>branches/bleeding_edge/test/cctest/cctest.status
>
> Log:
> Fix typo in include/v8.h (iss
Issue 108: comment typo fix
http://code.google.com/p/v8/issues/detail?id=108
Comment #3 by [EMAIL PROTECTED]:
The include/v8.h typo has been fixed on bleeding_edge branch in revision
472. I'm not
sure about the codegen_typo_fix.patch though: Where is the typo?
Issue attribute updates:
Issue 113: ARM: test-spaces/LargeObjectSpace sometimes fails
http://code.google.com/p/v8/issues/detail?id=113
Comment #1 by [EMAIL PROTECTED]:
(No comment was entered for this change.)
Issue attribute updates:
Status: Accepted
Owner: ---
--
You received this message because yo
Maybe it would be even better to try to submit a patch to the layout
test itself to stop being so picky about character casing for
exception messages?
On Thu, Oct 9, 2008 at 7:41 AM, Mads Sig Ager <[EMAIL PROTECTED]> wrote:
> I agree with Kasper and we already decided to rebaseline another
> layo
Author: [EMAIL PROTECTED]
Date: Wed Oct 8 22:39:00 2008
New Revision: 472
Modified:
branches/bleeding_edge/include/v8.h
branches/bleeding_edge/test/cctest/cctest.status
Log:
Fix typo in include/v8.h (issue 108) and mark test-spaces/LargeObjectSpace
as flaky on ARM (issue 113). [EMAIL
Maybe it would be even better to try to submit a patch to the layout
test itself to stop being so picky about character casing for
exception messages?
On Thu, Oct 9, 2008 at 7:41 AM, Mads Sig Ager <[EMAIL PROTECTED]> wrote:
> I agree with Kasper and we already decided to rebaseline another
> layo
I agree with Kasper and we already decided to rebaseline another
layout test (cyclic-prototype). All of our error messages are
capitalized and as far as I remember, most of the JSC ones are too (I
think this is the only exception I have found). I would prefer to
stay consistent.
Cheers,-- M
Issue 113: ARM: test-spaces/LargeObjectSpace sometimes fails
http://code.google.com/p/v8/issues/detail?id=113
New issue report by [EMAIL PROTECTED]:
Marked as flaky on ARM in test/cctest/cctest.status.
Issue attributes:
Status: New
Owner: [EMAIL PROTECTED]
Labels: Type
Issue 110: Javascript confirmation dialog box problem
http://code.google.com/p/v8/issues/detail?id=110
Comment #2 by [EMAIL PROTECTED]:
Please file this issue in the Chromium issue tracker; see
http://dev.chromium.org/for-testers/bug-reporting-guidelines
Issue attribute updates:
St
Issue 105: Implicit call to valueOf has wrong caller
http://code.google.com/p/v8/issues/detail?id=105
Comment #1 by [EMAIL PROTECTED]:
I'll take a look at this.
Issue attribute updates:
Status: Assigned
Owner: [EMAIL PROTECTED]
--
You received this message because you are list
This seems inconsistent with the other error messages which is
somewhat weird. We should at least consider re-baselining instead...
On Wed, Oct 8, 2008 at 11:16 PM, <[EMAIL PROTECTED]> wrote:
>
> Reviewers: Mads Ager,
>
> Description:
> Change capitalization on an error message -- required for p
So I compiled V8 as a shareable object and then it built and ran just
fine.
I would still like to link this statically though, so any help would
be appreciated.
Thanks,
Jeff
On Oct 8, 9:25 pm, codedread <[EMAIL PROTECTED]> wrote:
> I have a C++ project that I primarily work on in Windows, thoug
I have a C++ project that I primarily work on in Windows, though the
code is portable to other platforms.
I recently linked in V8 and started using it extensively. This works
perfectly in WIndows (add include path, add library path and v8.lib in
Visual Studio).
I was trying to write a Makefile
Reviewers: Mads Ager,
Description:
Change capitalization on an error message -- required for passing
LayoutTests/fast/js/cyclic-proto.html
This matches Safari and Firefox.
Please review this at http://codereview.chromium.org/6363
Affected files:
M src/messages.js
Index: src/messages.j
Issue 112: build fails early on fedora core 9 - 64 bit linux
http://code.google.com/p/v8/issues/detail?id=112
Comment #2 by [EMAIL PROTECTED]:
Closing this bug again. Thanks for the report. This information will
likely be
useful to others.
Issue attribute updates:
Status: Invalid
-
Issue 112: build fails early on fedora core 9 - 64 bit linux
http://code.google.com/p/v8/issues/detail?id=112
Comment #1 by todd.fisher:
Okay, looks like this isn't an issue after all. On fedora core systems the
package glibc-devel.i386 needs to be
installed.
--
You received this message
Issue 112: build fails early on fedora core 9 - 64 bit linux
http://code.google.com/p/v8/issues/detail?id=112
New issue report by todd.fisher:
libstc++ and other dependent libraries appear to be installed. Doing the
following results in
error:
svn checkout http://v8.googlecode.com/svn/trunk/
All suggested changes made, except refactoring. Instead,
scope of an if has been reduced dramatically in
AddFastProperty, eliminating duplicate code. Tested & Linted.
New changes to AddFastProperty uploaded to this changelist.
On 2008/10/08 10:38:25, bak wrote:
> LGTM,
> Lars
>
> http://cod
LGTM
On Wed, Oct 8, 2008 at 4:00 PM, <[EMAIL PROTECTED]> wrote:
> Reviewers: Erik Corry,
>
> Description:
> Make sure to check that the function prototype is a
> real JavaScript object before looking for it in the
> prototype chain during instanceof checks.
>
> Please review this at http://codere
Author: [EMAIL PROTECTED]
Date: Wed Oct 8 07:03:53 2008
New Revision: 471
Modified:
branches/bleeding_edge/src/codegen-ia32.cc
branches/bleeding_edge/src/stub-cache-ia32.cc
branches/bleeding_edge/test/mjsunit/instanceof.js
Log:
Make sure to check that the function prototype is a
rea
On Wed, Oct 8, 2008 at 1:50 PM, Kasper Lund <[EMAIL PROTECTED]> wrote:
> The code is pretty nasty, but I see the point in your change. If
> possible, you should try to use the ugly macros in even more places -
We don't use the macros in Builtins::Setup because it is run before
Top::Initialize so
Reviewers: Erik Corry,
Description:
Make sure to check that the function prototype is a
real JavaScript object before looking for it in the
prototype chain during instanceof checks.
Please review this at http://codereview.chromium.org/6579
Affected files:
M src/codegen-ia32.cc
M s
Author: [EMAIL PROTECTED]
Date: Wed Oct 8 06:33:16 2008
New Revision: 470
Modified:
branches/bleeding_edge/src/code-stubs.cc
branches/bleeding_edge/src/code-stubs.h
branches/bleeding_edge/src/codegen-arm.cc
branches/bleeding_edge/src/codegen-ia32.cc
branches/bleeding_edge/src
LGTM (hairy stuff!)
http://codereview.chromium.org/6341/diff/1/2
File src/macro-assembler-ia32.cc (right):
http://codereview.chromium.org/6341/diff/1/2#newcode595
Line 595: test(function, Immediate(kSmiTagMask));
We normally have an assert here in case we ever decide to tag smis with
a 1
http:
LGTM
http://codereview.chromium.org/6342
--~--~-~--~~~---~--~~
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
-~--~~~~--~~--~--~---
http://codereview.chromium.org/6342/diff/1/8
File src/objects.h (right):
http://codereview.chromium.org/6342/diff/1/8#newcode3168
Line 3168: inline int AsciiStringSize(Map* map);
Needs renaming
http://codereview.chromium.org/6342/diff/1/8#newcode3179
Line 3179: inline void AsciiStringReadBlockI
Reviewers: Erik Corry,
Description:
- Specialized slow-case string equality nine ways based on the
underlying string representation of the two strings involved.
- Renamed ascii and two byte string classes to sequential ascii and
sequential two byte, and renamed IsAscii and friends to
IsA
Reviewers: Erik Corry,
Description:
Improve the generated code for the instanceof operator.
Please review this at http://codereview.chromium.org/6341
Affected files:
M src/code-stubs.cc
M src/code-stubs.h
M src/codegen-arm.cc
M src/codegen-ia32.cc
M src/macro-
The code is pretty nasty, but I see the point in your change. If
possible, you should try to use the ugly macros in even more places -
at least for consistency. Do we have good tests of the issue? Can you
create a regression test case for issue 70?
I guess with a regression test case that shows t
-minline-all-stringops
By default GCC inlines string operations only when destination is
known to be aligned at least to 4 byte boundary. This enables more
inlining, increase code size, but may improve performance of code
that depends on fast memc
Reviewers: Kasper Lund,
Description:
If an allocation is so huge that we cannot code the size needed in the
failure
object then we just return an out of memory failure object (instead of a
retry
after GC failure object). Not all places that checked for
retry-after-GC were
able to handle an immed
On Wed, Oct 8, 2008 at 12:10 PM, Dean McNamee <[EMAIL PROTECTED]> wrote:
>
> Won't memcpy always be an inlined intrinsic?
Not with variable size:
$ cat copy.cc
#include
extern void foo(char* a, char* b, int size) {
memcpy(a, b, size);
}
$ g++ -S -O3 copy.cc
$ cat copy.s
.file "copy.cc"
LGTM,
Lars
http://codereview.chromium.org/6528/diff/1/2
File src/objects.cc (right):
http://codereview.chromium.org/6528/diff/1/2#newcode1223
Line 1223: // Make new properties array if necessary.
Please check if you could refactor the code below. It is used
in other functions.
http://codere
Won't memcpy always be an inlined intrinsic?
On Wed, Oct 8, 2008 at 10:38 AM, Kevin Millikin <[EMAIL PROTECTED]> wrote:
> LGTM.
>
> On Wed, Oct 8, 2008 at 10:31 AM, <[EMAIL PROTECTED]> wrote:
>>
>> Reviewers: Kevin Millikin,
>>
>> Description:
>> Minor adjustments to the object migration code: Wh
Author: [EMAIL PROTECTED]
Date: Wed Oct 8 02:01:10 2008
New Revision: 469
Modified:
branches/bleeding_edge/src/heap.cc
Log:
Minor adjustments to the object migration code: When copying
large objects we use memcpy. If this turns out to be a wash
on the benchmarks, I'd be happy to rip it out
LGTM.
On Wed, Oct 8, 2008 at 10:31 AM, <[EMAIL PROTECTED]> wrote:
>
> Reviewers: Kevin Millikin,
>
> Description:
> Minor adjustments to the object migration code: When copying
> large objects we use memcpy. If this turns out to be a wash
> on the benchmarks, I'd be happy to rip it out again.
>
>
Reviewers: Kevin Millikin,
Description:
Minor adjustments to the object migration code: When copying
large objects we use memcpy. If this turns out to be a wash
on the benchmarks, I'd be happy to rip it out again.
Please review this at http://codereview.chromium.org/6576
Affected files:
M
Author: [EMAIL PROTECTED]
Date: Wed Oct 8 01:05:14 2008
New Revision: 468
Modified:
branches/bleeding_edge/src/runtime.cc
Log:
Fix incorrect short cut test that assumed ASCII strings could be Latin1.
Review URL: http://codereview.chromium.org/6542
Modified: branches/bleeding_edge/src/runti
On Wed, Oct 8, 2008 at 7:26 AM, Kasper Lund <[EMAIL PROTECTED]> wrote:
> LGTM. Should we have a test case for this?
It's only a performance bug, or rather lack of a performance optimization.
>
> On Tue, Oct 7, 2008 at 5:33 PM, <[EMAIL PROTECTED]> wrote:
>> Reviewers: Kasper Lund,
>>
>> Descript
Author: [EMAIL PROTECTED]
Date: Wed Oct 8 00:36:44 2008
New Revision: 467
Modified:
branches/bleeding_edge/tools/visual_studio/v8_snapshot.vcproj
Log:
Fixed wrong filename in Visual Studio project file.
Review URL: http://codereview.chromium.org/6336
Modified: branches/bleeding_edge/tools/
LGTM.
On Wed, Oct 8, 2008 at 9:21 AM, <[EMAIL PROTECTED]> wrote:
> Reviewers: Kasper Lund,
>
> Description:
> Fixed wrong filename in Visual Studio project file.
>
> Please review this at http://codereview.chromium.org/6336
>
> Affected files:
> M tools/visual_studio/v8_snapshot.vcproj
>
>
Author: [EMAIL PROTECTED]
Date: Wed Oct 8 00:24:06 2008
New Revision: 466
Modified:
branches/bleeding_edge/src/codegen-arm.cc
branches/bleeding_edge/src/codegen-ia32.cc
Log:
Moved the function GetValue from the code generator to the Reference
helper class.
As a consequence, also remove
Reviewers: Kasper Lund,
Description:
Fixed wrong filename in Visual Studio project file.
Please review this at http://codereview.chromium.org/6336
Affected files:
M tools/visual_studio/v8_snapshot.vcproj
Index: tools/visual_studio/v8_snapshot.vcproj
47 matches
Mail list logo
