Re: [webkit-dev] Platform.h vs. makefiles

2020-05-11 Thread Michael Saboff
> On May 10, 2020, at 11:11 PM, Darin Adler wrote: > >> On May 10, 2020, at 10:07 PM, Maciej Stachowiak wrote: >> >> I think the best way to configure WebKit is to use a separate data file, >> neither a header nor a makefile or similar, that defines the options in a >> single place with

Re: [webkit-dev] Offline Assembler build step always computes hashes even when nothing changes

2018-09-16 Thread Michael Saboff
Darin, I can take a look at this. Filed > “Offline assembler always computes hashes even when nothing changes" - Michael > On Sep 16, 2018, at 4:03 PM, Darin Adler >

Re: [webkit-dev] Proposal: Do not support Windows fibers

2017-12-05 Thread Michael Saboff
believe we've fixed all occurrences of calling WebKit/JSC from our non-main cooperative threads. - John > On Dec 5, 2017, at 10:26 AM, Michael Saboff <msab...@apple.com> wrote: > > [Bringing John Lehner from the iTunes team into the discussion] > > Last I knew, the iTunes te

Re: [webkit-dev] Proposal: Do not support Windows fibers

2017-12-05 Thread Michael Saboff
[Bringing John Lehner from the iTunes team into the discussion] Last I knew, the iTunes team uses fibers. IIRC, the thread they use to call into WebKit/JSC only has one fiber, other parts of the app use multiple fibers on one thread but don’t have JS objects active in those threads / fibers.

Re: [webkit-dev] Building WebKit for an iOS device

2017-07-12 Thread Michael Saboff
I’ll add a little to Alex’s comments. I doubt you could build all of WebKit with the public iOS SDK. You certainly can’t sign JavaScriptCore to use JIT memory. Even if could build WebKit and statically linked your code with what you built, there will likely be some mismatch between the

Re: [webkit-dev] Stack Alignment error in LLINT

2015-07-27 Thread Michael Saboff
Rodney, JavaScriptCore assumes that the stack is 16 byte aligned. This may be more restrictive than some OS / ABIs, but there is code to pad appropriately for some platforms. You didn’t say what OS you are running on, but maybe there needs to be a code added for your OS. Turning on C++

Re: [webkit-dev] Stack Alignment error in LLINT

2015-07-27 Thread Michael Saboff
with exceptions on to see if I get the same problem. Regards, Rodney On 07/27/2015 11:24 AM, Michael Saboff wrote: Rodney, JavaScriptCore assumes that the stack is 16 byte aligned. This may be more restrictive than some OS / ABIs, but there is code to pad appropriately for some platforms. You

Re: [webkit-dev] Tagged assertions...

2014-11-06 Thread Michael Saboff
This will add a step that developers will have to remember when changing an ASSERT. There may be developers that want to knowingly keep the same tag. What about creating my own tag values? How will we guard against reusing a tag? So what would be an appropriate tag for an ASSERT in a

Re: [webkit-dev] Using OfflineAsm

2014-09-05 Thread Michael Saboff
Christopher, Let me add a little to Phil’s comments. As Phil says, you shouldn’t expect much if any performance gain going from the C LOOP to one of the assembler back ends if you also don’t plan on enabling JITs. The architectures / OS combinations that work with the LLInt is nearly the same

[webkit-dev] lldb scripted command for JavaScript backtrace

2014-06-25 Thread Michael Saboff
A new python scripted javascript backtrace command and supporting C++ code now exists starting with change set r170432. This is only for lldb and may be replaced in the future when a JIT interface is made available for lldb. The new command is btjs and it can take an optional frame count,

Re: [webkit-dev] Merging back the jsCStack branch

2014-01-29 Thread Michael Saboff
The branch has been merged back to trunk in change set r163027: http://trac.webkit.org/changeset/163027. - Michael On Jan 27, 2014, at 6:00 PM, mhahnenb...@apple.com wrote: Hello WebKitters, The JavaScriptCore team is planning on merging back our temporary development branch (at

[webkit-dev] JavaScriptCore Merge of C Stack Work

2014-01-28 Thread Michael Saboff
for those we can’t test are speculative at best. Obviously, if there are any issues we will support the work of others to get the ports they support working. - Michael Saboff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

2014-01-03 Thread Michael Saboff
On Jan 3, 2014, at 11:28 AM, Geoffrey Garen gga...@apple.com wrote: However I also feel the harm here is debatable enough that people working on/reviewing the code should make decisions instead of there being a project level dictate. It is a new thing, the appropriate usage hasn't yet

[webkit-dev] JavaScript Stack Changes

2013-10-07 Thread Michael Saboff
no means to test those changes. If you maintain the processor specific JavaScript code for one of those ports, send me a reply so we can coordinate changes to minimize breakage. - Michael Saboff ___ webkit-dev mailing list webkit-dev@lists.webkit.org

Re: [webkit-dev] LLInt alignment problem on ARM

2013-09-26 Thread Michael Saboff
I’m wondering if the alignment is the traditional ARM vs Thumb 2. The movw after lint_begin with hex 0xe30b3eef is a Thumb 2 instruction. - Michael On Sep 26, 2013, at 9:24 AM, Oliver Hunt oli...@apple.com wrote: I believe that there’s a mnemonic that forces alignment that we could

Re: [webkit-dev] Instrumenting the LLint interpreter

2013-07-11 Thread Michael Saboff
The LLint is used to execute Javascript the first time a function is run. If code is executed multiple times, the baseline JIT will come into play. For Javascript that executes once or very few times, only the LLint is used. - Michael On Jul 11, 2013, at 12:51 AM, Abhishek Bichhawat

Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?

2013-03-11 Thread Michael Saboff
Maciej, *I* deemed using a character type template for the HTMLTokenizer as being unwieldy. Given there was the existing SegmentedString input abstraction, it made logical sense to put the 8/16 bit coding there. If I would have moved the 8/16 logic into the tokenizer itself, we might have

Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?

2013-03-11 Thread Michael Saboff
to limitations on how then interact with their networking stack. In any case, I don't plan to implement that design anytime soon, and I'm sure we'll have plenty of time to discuss its merits in the future. Adam On Mon, Mar 11, 2013 at 8:56 AM, Michael Saboff msab...@apple.com wrote: Maciej, *I

Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?

2013-03-07 Thread Michael Saboff
There is an all-ASCII case in TextCodecUTF8::decode(). It should be keeping all ASCII data as 8 bit. TextCodecWindowsLatin1::decode() has not only an all-ASCII case, but it only up converts to 16 bit in a couple of rare cases. Is there some other case you don't think we are handling? -

Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?

2013-03-07 Thread Michael Saboff
be beneficial. -- Darin Sent from my iPhone On Mar 7, 2013, at 10:01 AM, Michael Saboff msab...@apple.com wrote: There is an all-ASCII case in TextCodecUTF8::decode(). It should be keeping all ASCII data as 8 bit. TextCodecWindowsLatin1::decode() has not only an all-ASCII case

Re: [webkit-dev] YARR example

2013-01-04 Thread Michael Saboff
. Is this implementation specific, do I need to use other notation to indicate case insensitive matching? Regards, Ognian On Thu, Jan 3, 2013 at 6:28 PM, Michael Saboff msab...@apple.com wrote: Ognian, YARR is the regular expression engine for the JavaScriptCore part of webkit. It can find the matches

Re: [webkit-dev] YARR example

2013-01-03 Thread Michael Saboff
Ognian, YARR is the regular expression engine for the JavaScriptCore part of webkit. It can find the matches, but you would need to write other C++ code to do the replacement. The String.replace() method will do what you want in JavaScript. - Michael On Jan 3, 2013, at 4:16 AM, Ognian

Re: [webkit-dev] question about jsc

2012-10-29 Thread Michael Saboff
The output of undefined is normal. It is the result of the expression you entered. jsc is basically returning the result of the expressions you enter. Both var and print themselves evaluate to undefined. If you try x = 1; you'll get 1 as that expression returns 1. Concerning testing, If

Re: [webkit-dev] 8 Bit String Handling in Render Text Code

2012-10-16 Thread Michael Saboff
Got a patch for review to change the macro to ENABLE_8BIT_TEXTRUN. (https://bugs.webkit.org/attachment.cgi?id=168988action=review) - Michael On Oct 15, 2012, at 2:44 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 15, 2012, at 9:56 AM, Michael Saboff msab...@apple.com wrote: I

[webkit-dev] 8 Bit String Handling in Render Text Code

2012-10-15 Thread Michael Saboff
I recently landed r131311 which adds code to handle 8-bit strings in the render text path. The code also puts HTML text into 8-bit strings. The reason for this announcement is that the handling of 8-bit text on the render path is disabled on non-Mac platforms. Most platforms have platform

Re: [webkit-dev] A proposal for handling failing layout tests and TestExpectations

2012-08-15 Thread Michael Saboff
It seems to me that there are two issues here. One is Chromium specific about process conformity. It seems to me that should stay a Chromium issue without making the mechanism more complex for all ports. The other ports seem to make things work using the existing framework. The other

[webkit-dev] 8 Bit Strings Turned On in JavaScriptCore

2011-11-18 Thread Michael Saboff
will be done using 8 bits except where string escapes require 16 bit strings. - Michael Saboff msab...@apple.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] 8 Bit Strings Turned On in JavaScriptCore

2011-11-18 Thread Michael Saboff
On Nov 18, 2011, at 11:18 AM, Adam Roben wrote: On Nov 18, 2011, at 2:14 PM, Michael Saboff wrote: Although the UChar* characters() method for the various string classes still works, all new code should check what flavor a string is constructed by using the new is8Bit() method