Hi Eric,
Many apologies for the redness. These changes are pretty much
complete now, so hopefully there shouldn't be any more big file moves
like this too soon.
One thing that was hugely useful in minimizing the breakage as much as
possible while making these changes was the ews bots – t
On Aug 13, 2010, at 3:17 AM, Alexey Proskuryakov wrote:
> Of course, there is the special case of fast/js tests, which we (I think)
> still hope to run without a WebView one day. For that, keeping JS separate is
> obviously desirable.
Absolutely agreed - and these can already be run in a comman
Hi,
Apologies, I've introduced some red to the tree, a test on Qt needs some new
expected results adding, and I can't find where they're kept.
The test is tst_QWebFrame::connectAndDisconnect(), the new output is correct
(the format for some exception messages has changed slightly), if someone c
Problem solved, thanks to mitzpettel!
cheers, G.
On Nov 15, 2010, at 8:24 PM, Gavin Barraclough wrote:
> Hi,
>
> Apologies, I've introduced some red to the tree, a test on Qt needs some new
> expected results adding, and I can't find where they're kept.
>
On Dec 16, 2010, at 9:45 PM, 谢愈挺 wrote:
> I have a question about "StringImpl::create()". Is it can only input latin1
> data?
Yes, this method takes latin1 data all const char* arguments in WTFString are
handled as latin1.
String::fromUTF8 can be used to create strings with utf8 data.
> If it
On Apr 13, 2011, at 5:32 PM, Mo, Zhenyao wrote:
> What value should we return for hash(NULL)?
From the top of the file:
// The hash() functions on StringHash and CaseFoldingHash do not support
// null strings. get(), contains(), and add() on HashMap
// cause a null-pointer dereferen
I had a partially working solution to this using the deallocation stack member
of the Win32 Thread Information Block, see
https://bugs.webkit.org/show_bug.cgi?id=26276 &
http://en.wikipedia.org/wiki/Win32_Thread_Information_Block – but I didn't
manage to get this working consistently. Perhaps
Hi Adam,
Yes, I believe our current thinking is that the external interface to String
lengths / indices should all be in size_t (though unless we believe we need to
support strings > 4GB we should keep the length stored as a 32 bit value
internally). There are a couple of bugzilla bugs relevan
On Oct 27, 2011, at 3:00 PM, Eric Seidel wrote:
> If you're still using old-run-webkit-tests for your work, I would
> *love* to know and fix any issues you may have with NRWT.
Hi Eric,
Unless there is a trick to this that I am unaware of, I think NRWT doesn't
support running 32-bit tests on a 6
-d should work fine on ARM - check your build settings, is any #ifndef NDEBUG
code getting built?
In addition there are a set of switches in dfg/DFGCommon.h that include ones to
enable further dumping of the intermediate representation.
G.
On Nov 29, 2011, at 2:51 AM, vahagvahag wrote:
>
> H
On Dec 2, 2011, at 12:10 PM, venkeng koon wrote:
> Hi!
> I have started to invistigate SFX and now have some information about it.
> But I have still had some quetions and will be very gratefull if you could
> help me.
> First. Does SFX support multithreading? Can he compile several funcotion a
Hi Andy,
> As you probably know, the ECMA TC39 committee is slowly approaching
> consensus on a new revision of the ECMAScript language. The interim
> results of this process have gone under various names: Harmony, ES.next,
> and ES6. They are the same thing. This mail is intended to open the
>
On Jan 10, 2012, at 7:33 AM, Andy Wingo wrote:
> Hello JSC hackers,
>
> I've been thinking for some time now that there is room for another
> command-line shell for JSC.
Hi Andy,
Yes!
Some more things to add to the wish list:
* tab completion (e.g. "Math.si" -tab-> Math.sin)
* p
On Mar 9, 2012, at 12:30 PM, Mark Rowe wrote:
> What you'll find is that the vast majority of SVN users are simply not
> participating in this email thread. You'll also find that many people that
> use git-svn are happy enough with the status quo since it gives those who
> chose to use it most
On the topic of JIT support, the baseline JIT's role is increasingly only to
serve only to gather profiling data for the DFG JIT, and if you want high
performance JavaScript on your platform you need to have the DFG JIT enabled.
As the purpose of the two JITs becomes increasingly coupled it may
JSC already supports private named properties – you just need allocate a
'PrivateName' object & use this as a property name.
cheers,
G.
On Aug 23, 2012, at 1:04 PM, Adam Barth wrote:
> Another approach might be to implement hidden properties in
> JavaScriptCore, but I don't know what would be
Hi Yuqiang,
I think that this could be a good refactoring for the MacroAssembler – to move
all ( Ptr->32 / Ptr->64 ) remapping into MacroAssembler.h, introduce a Imm64,
rename all the current *Ptr* methods in MacroAssemblerX86_64 to *64*, etc –
please feel free to put up patches for this, and c
On Oct 15, 2012, at 7:13 AM, Gergely Kis wrote:
> Should we CC someone directly on these bugs to make the reviews easier?
Likely reviewers would be me, Oliver, Filip or Geoff, feel free to cc.
cheers,
G.
___
webkit-dev mailing list
webkit-dev@lists.webk
These rules generally look great. One suggestion:
On Nov 5, 2012, at 8:47 AM, Geoffrey Garen wrote:
> (5) Adopt the convention that any function that is not as trivial as "int x()
> { return m_x; }" moves out of the class declaration.
How about we simplify this slightly to:
(5) Adopt the conve
On Jan 24, 2009, at 8:36 PM, x yz wrote:
Just build webkit on XP using cgywin, not tested yet. I want to port
to 32bit MIPS, it seems I need to touch JIT and rewrite assembler
folder.
Once you have the bytecode interpreter up and running on MIPS, I'd
recommend starting by just trying to p
On Feb 6, 2009, at 2:52 PM, x yz wrote:
1.what's the meaning of ALTERNATE_JSIMMEDIATE and slow case?
On x86-64 we use a different implementation of the class JSImmediate.
See JSImmediate.h.
Re 'slow case', in the JIT code generation is performed as two passes
over the bytecode – see JIT::
mplementation will remain in the jit folder.
I'd suggest that in attempting to port the jit, WREC would be a good
place to start.
cheers,
G.
rgds
joe
--- On Mon, 2/16/09, x yz wrote:
From: x yz
Subject: Re: [webkit-dev] want to port JIT to MIPS - when WREC/JIT
enabled?
To: &q
se2???
thanks for your time!
joe
--- On Sun, 2/22/09, x yz wrote:
From: x yz
Subject: Re: [webkit-dev] want to port JIT to MIPS
To: "WebKit Development" , "Gavin
Barraclough"
Date: Sunday, February 22, 2009, 4:34 PM
Thanks a lot otherwise I have misunderstanding. Yes I&
one by one).
cheers,
G.
On Feb 26, 2009, at 5:39 PM, x yz wrote:
yes but if isSSE2Present() returns false the code becomes very
simple so I doubt it may be slow.
what's the benefit to enable/disable ALTERNATE_JSIMMEDIATE?
thanks
joe
--- On Fri, 2/27/09, Gavin Barraclough wrote
On Feb 27, 2009, at 4:55 PM, x yz wrote:
The regTx seems to be working registers here, yet their definition
are regparm(3) registers for function arugments. Such usage would
cause conflict on other platforms. May I suggest that we use
individual defined set of regs for func i/o argument and
On Mar 4, 2009, at 2:22 AM, zhenghe zhang wrote:
When running a webpage, and the javascriptcore will parse the
javascript function, and will obtain some identifiers. I don't know
how to
store these identifiers and where to store these identifiers.
These identifiers are stored in the identi
static const int
patchOffsetPutByIdStructure =
7;
static const int
patchOffsetPutByIdPropertyMapOffset = 22;
static const int
patchOffsetGetByIdBranchToSlowCase = 13;
thanks for help, I'm stucked here now.
joe
--- On Sat, 2/28/09, Gavin Barraclough
wrote:
From: Gavin Barraclough
Sub
On Mar 18, 2009, at 11:06 AM, Mike Hommey wrote:
An earlier call to JSC::JITStubs::cti_op_call_NotJSFunction works
and a lot
of other stub functions are called before the crash, so it means
most of
the JIT works, but it is failing in a subtle way.
I'd suggest trying to produce a reduction
I think I can see a bug here – the compile guard on the definition of
VoidPtrPair in JITStubs.h isn't right.
#if PLATFORM(MAC)
should be changed to
#if !COMPILER(MSVC)
(and the else case should #error if compiled on x86-64, if it not 64-
bit safe).
The MSVC version of this structure works
Maciej,
This sounds good, and sounds like it could clean things up a lot.
In the breakdown below you don't explicitly mention what would happen
to h/w specific macros like PLATFORM_X86, though you do mention 'CPU'
in your email, OOI are you thinking something like?:
CPU()
Examples:
On May 19, 2009, at 12:55 PM, Kenneth Christiansen wrote:
Great! I notices that RegExp.h still includes WREC, will that be
changed?
WREC should be removed completely fairly soon. We just wanted to
leave some overlap with YARR and WREC both in ToT, in case we needed
to revert back to WRE
Hi Zoltan,
I don't think so. It is not worth to do it on a desktop pc since
interpreter is always slower than JIT. However, the story is
different for
embedded systems, when they enter low-memory mode.
Whilst it is certainly true that this would likely be of most benefit
on embedded platf
This code is designed to keep the stack correctly aligned, and appears
to be working correctly. If you think there is a bug here, please
report it at bugs.webkit.org.
cheers,
G.
On Jun 2, 2009, at 5:26 PM, x yz wrote:
I don't know how to file bug so I posted here.
In privateCompileCTIMa
Hi Zoltan,
I'm a little confused – maybe I'm misunderstanding you, but the JIT
does just subtract a fixed amount from the stack pointer on entry (28
on x86, for a total frame size including return address, caller frame
pointer and callee preserved registers of 48, a multiple of 16 to
pres
On Jun 4, 2009, at 5:49 AM, Zoltan Herczeg wrote:
Hi Gavin,
the alignment error was not your fault. When you start porting the
JIT,
you need to keep many things in your head, and I totally forgot about
stack alignment. The entry and exit functions are not portable, and
you
have to arrange
We check in JIT code for cases where arity match, and skip the call to
the stub; this function is only called if there is a mismatch to be
resolved. The function would probably be better named something like
'cti_op_call_handleArityMismatch'.
cheers,
G.
On Jun 4, 2009, at 1:50 PM, Toshiya
On Jun 9, 2009, at 2:38 PM, Akos Kiss wrote:
Dear Community,
Today, we realized that there is a new ARM JIT port for WebKit. (http://trac.webkit.org/changeset/44514
) Congratulations on getting this working!, great job.
Hi Akos,
Thank you! Just to clarify, we have just landed a ARMv7 archi
Hi Andrew,
It certainly sounds likely this is a bug, and the best person to
comment on it is probably Oliver, who is not on this list.
Could you please file a bug at bugs.webkit.org?
Many thanks,
G.
On Jun 10, 2009, at 11:26 AM, Andrew Webster wrote:
I've been tracking down a memory leak
On Jun 10, 2009, at 1:15 PM, Toshiyasu Morita wrote:
--- On Wed, 6/10/09, Geoffrey Garen wrote:
>I'm having a hard time understanding from your comment what
optimization changes you think are appropriate, but if you can
produce a patch that implements
> your idea, and shows a benefit on a
Toshiyasu,
On Jun 10, 2009, at 2:24 PM, Toshiyasu Morita wrote:
Why does the arity check need to be in the caller, and not the callee?
The majority of call sites always call to the same callee, and we can
optimize these cases for calling that same function repeatedly.
Within the optimize
On Jun 11, 2009, at 10:20 AM, Toshiyasu Morita wrote:
I've tracked down a crash in our JIT port to a problem with the
trampoline generation.
The symptom of the crash is: the ScopeChain becomes corrupted and
acquires the value of 1.
void
JIT::privateCompileCTIMachineTrampolines(RefPtr*
And here, I have to make a short comment on the non-acceptance of
our ARM
JIT implementation. In your mail you mention that you would remain
reluctant to accept a duplicate of the JIT into the tree, rather
than a
port of the existing JIT utilizing the MacroAssembler abstraction.
Well,
did y
I believe the C spec requires that files end in a newline, though I
couldn't comment on the c++ spec. Possibly redundant to list this as
WebKit style issue, if required by the language?
G.
On Sep 3, 2009, at 10:11 AM, Darin Adler wrote:
On Sep 2, 2009, at 11:18 PM, Brent Fulgham wrote:
On Sep 3, 2009, at 3:51 PM, Peter Kasting wrote:
On Thu, Sep 3, 2009 at 3:46 PM, Darin Adler wrote:
On Sep 3, 2009, at 8:43 AM, David Levin wrote:
There should only be a single space before end of line comments. An
exception is if one is lining up several end of line comments.
I don’t thin
On Nov 4, 2009, at 8:37 AM, ll Jefferry wrote:
Hi,
when i reading the jit for arm source code, i am not very clear the
functionality of the flowing functions:
ctiTrampoline
This code is used when entering from the C runtime into JIT generated
code. JIT generated code does not ne
From http://lists.webkit.org/:
ListDescription
webkit-help [no description available]
Hmmm, yes, there would seem to be some scope to make that a little
more descriptive! ;-)
G.
On Nov 17, 2009, at 11:46 PM, Zoltan Herczeg wrote:
Hi
On Dec 2, 2009, at 9:57 PM, Dan Bernstein wrote:
I am satisfied with the existing rule.
+1
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Mar 31, 2010, at 10:08 AM, Alexey Proskuryakov wrote:
On 30.03.2010, at 22:44, barraclo...@apple.com wrote:
+WebCString::operator WTF::CString() const
There probably should be a "using CString" directive in CString.h -
we do that for all public symbols in WTF.
There should be ... http
On Apr 1, 2013, at 12:36 PM, Glenn Adams wrote:
> correction... NTSC = Never The Same Color (twice)
How do we intend to implement this? – any pseudo random behaviour needs to be
cryptographically secure to avoid risking an information leak here.
G.
_
On Jun 18, 2013, at 10:16 PM, Ryosuke Niwa wrote:
> On Tue, Jun 18, 2013 at 7:20 PM, Simon Fraser wrote:
> On Jun 18, 2013, at 7:11 PM, Darin Adler wrote:
>
>> On Jun 18, 2013, at 7:05 PM, Ryosuke Niwa wrote:
>>
>>> Why don't we call it requireStyleResolver() instead?
>>
>> I’m warming to t
I find ‘requireStyleResolver()’ a little confusing. My first expectation is
often that a method is an imperative command on the receiver, so I first read
'requireStyleResolver()’ as mandating that the document now requires a
StyleResolver, rather than referring to the need of the caller.
In a
On Jul 12, 2013, at 9:59 PM, Jake wrote:
> getting on your standards soapbox
OOI standards conformance is a WebKit project goal.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
The spec (http://www.khronos.org/registry/typedarray/specs/latest/) says
"Constructors: None”, looks like FireFox is right, we should probably just
remove this.
G.
On Aug 14, 2013, at 12:34 AM, Filip Pizlo wrote:
> And on a similar note: ArrayBufferView. What's that all about?
>
> Previousl
I’m a bit of a luddite and edit my change log entries by hand.
The old format is more amenable to this, the new format is a regression.
cheers,
G.
On Aug 21, 2013, at 2:25 PM, Ryosuke Niwa wrote:
> On Wed, Aug 21, 2013 at 2:04 PM, Ryosuke Niwa wrote:
> Hi,
>
> I have noticed that the change l
On Dec 2, 2013, at 10:53 AM, Geoffrey Garen wrote:
> Hi Alexei.
>
>> To my knowledge, an object's prototype is consulted when a property is not
>> found on the object itself. Any new property is written to the object, never
>> its prototype.
>
> That’s not quite right. The prototype chain is
Hi,
This feature is now stable & I think this is enabled on all ports, I plan to
remove the #ifdefs.
cheers,
G.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Yay! – that was annoying, thank you for the fix Ossy!
On Feb 5, 2014, at 12:29 AM, Osztrogonác Csaba wrote:
> Hi,
>
> Fix already landed in http://trac.webkit.org/changeset/163167 ;)
>
> Ossy
>
> Gyuyoung Kim írta:
>> Hello Oliver,
>> I'm really sorry about the inconvenience to you. Let me tr
Regards,
> Eva Balazsfalvi
>
>
> Gavin Barraclough wrote:
>> Hi,
>>
>> This feature is now stable & I think this is enabled on all ports, I plan to
>> remove the #ifdefs.
>>
>> cheers,
>> G.
>
> ___
On Jul 28, 2014, at 12:47 PM, David Farler wrote:
> - Swift is a fully supported, albeit new, language starting in Xcode 6.
I think you missed a word off the end of this sentence – Swift support is
available in Xcode 6 beta. ;-)
Too soon.
G.
___
we
Yep, looks like a pretty straightforward problem – the timer nesting level
should also be being cleared before the early return in DOMTimer::fired.
Please file a bug!
cheers,
G.
> On Oct 10, 2014, at 8:19 AM, 陈浩 wrote:
>
> Hi, all,
>
> I am confused about the nesting level of DOMTimer.
>
>
Gotta say, ‘singleton’ seems like a really good name for singletons.
G.
> On Jan 28, 2015, at 7:06 PM, Filip Pizlo wrote:
>
> This is shorter: Class::singleton()
>
> It's also more consistent with the rest of our style (we usually don't put
> "get" in getter names).
>
> -Filip
>
>> On Jan
> On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak wrote:
>
> Web Abstraction Toolbox (it’s hard to tell the difference between wat and WTF
> sometimes…)
+1
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listi
> On Nov 1, 2015, at 7:40 PM, Darin Adler wrote:
>
> 3) Can you help me come up with a super-efficient algorithm to do this
> serialization?
Table lookup? FP conversion code is hard, and this is a relatively small number
of strings.
You could also flatten all the strings into one big string,
> On Nov 1, 2015, at 7:40 PM, Darin Adler wrote:
>
> 3) Can you help me come up with a super-efficient algorithm to do this
> serialization?
Oh – I guess if you just store the fractions as BCD & unpack you can get the
table size down to 512 bytes.
If you decide against truncating the values &
Hi folks,
We’re back in action! – we should have enough of our infrastructure up to keep
the build green & guard against regressions, so the repository is open again to
commits.
We’d really like to minimize broken builds over the next day as any backlog of
patches is being landed. We can all d
architectures. The best
> person to talk to about that is Gavin Barraclough. The next
> architecture on the roadmap is X86-64.
Jon, Mario,
As Darin says, we plan to look at x86-64 in the very near future.
We see this as a good gateway to further architectures (as well as
being an important arc
On Dec 25, 2008, at 3:51 AM, Oliver Hunt wrote:
You can manually align the memory, eg.
char* memory = malloc(size + alignment - 1);
memory += alignment;
memory &= ~(alignment - 1)
return memory;
Oops, think you meant:
memory += (alignment - 1);
G.
The obvious problem with this is tha
67 matches
Mail list logo
