[webkit-dev] PSA: JSC::UString will retire, String is excited to meet you

[Benjamin Poulain]

Hi WebKit-dev,


Some unifying has been done between String and UString, and it will
soon be time to remove UString entirely.

The benefits of removing UStrings are:
-Simpler code.
-No need to implement each feature in String and UString
-Fewer ref-deref
-Smaller binary (about 44kb smaller on Mac x86_64)

The bug is https://bugs.webkit.org/show_bug.cgi?id=95271
I want to do some more performance testing and hopefully the patch
will land tomorrow.

Cheers,
Benjamin

PS: Gyuyoung Kim has verified the ELF build. Can someone help with the GTK EWS?
PSS: It is likely to break something somewhere, some help after
landing is appreciated.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] CSS Masking in WebKit

[Dirk Schulze]

Hi WebKit folks,

The CSS WG and SVG WG agreed to work on a CSS Masking specification [1]. 
Basically the spec aims to specify the behavior of 
-webkit-mask/-webkit-box-mask on WebKit browsers and SVG Mask/ SVG ClipPath on 
Firefox.

I would like to implement the specification in the next weeks and months. Since 
masking and clipping are basic operations that use the existing capabilities in 
all graphic libraries, and sine we are using it heavily internally in WebKit 
already, I do not plan to introduce a new compiler flag. 

However, some features will be covered by existing compiler flags like SVG Mask 
and SVG ClipPath, allowing to disable these parts.

I created a master bug that covers the work [2].

Greetings,
Dirk

[1] http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
[2] https://bugs.webkit.org/show_bug.cgi?id=95389
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore

[Gergely Kis]

 On Wed, Aug 29, 2012 at 11:34 PM, Fu, Chao-Ying  wrote:

> > On Wed, Aug 29, 2012 at 05:58:10PM +, Fu, Chao-Ying wrote:
> > > Hi All,
> > >
> > >   Before a MIPS buildbot is ready, you can go ahead to
> > change the assembler or any parts of code.  We (MIPS) will
> > test new code and submit patches that are required to fix the
> > MIPS JSC build.  Don't need to worry about breaking the MIPS
> > build.  (I have a cron job that checks out code and builds
> > JSC on a native MIPS Linux every night.)  This is the current
> > process that we use, I think.  Thanks a lot!
> >
> > Hi,
> >
> > more pennies. That is not how the other stakeholders develop
> > inside the
> > WebKit project. There is little to no value for this community if you
> > test behind closed doors. E.g. how can members of this
> > community know that
> > a lack of communication is the lack of issues and not you
> > being reassigned
> > to something else?
> >
> > holger
>
>   Sure.  Will having new MIPS buildbot help to solve this concern?
> If yes, then you should not worry because we promise to help on buildbot.
> Thanks!
>
> Regards,
> Chao-ying
>

Hi Holger,

We are working together with MIPS to update and maintain the MIPS port of
Webkit. We are setting up a buildbot slave to be integrated with
build.webkit.org. First, it will use qemu emulation to run the on-target
tests. However, this is only a temporary measure until we get at least one
board dedicated to this purpose, then our slave will also execute tests on
actual hardware.

It is our current plan to have the initial qemu-only slave set up by next
week. Should we contact you directly or someone else to get the slave
integrated with build.webkit.org?

Would this be acceptable for you?

Best Regards,
Gergely
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore

[Fu, Chao-Ying]

> On Wed, Aug 29, 2012 at 05:58:10PM +, Fu, Chao-Ying wrote:
> > Hi All,
> > 
> >   Before a MIPS buildbot is ready, you can go ahead to 
> change the assembler or any parts of code.  We (MIPS) will 
> test new code and submit patches that are required to fix the 
> MIPS JSC build.  Don't need to worry about breaking the MIPS 
> build.  (I have a cron job that checks out code and builds 
> JSC on a native MIPS Linux every night.)  This is the current 
> process that we use, I think.  Thanks a lot!
> 
> Hi,
> 
> more pennies. That is not how the other stakeholders develop 
> inside the
> WebKit project. There is little to no value for this community if you
> test behind closed doors. E.g. how can members of this 
> community know that
> a lack of communication is the lack of issues and not you 
> being reassigned
> to something else?
> 
> holger

  Sure.  Will having new MIPS buildbot help to solve this concern?
If yes, then you should not worry because we promise to help on buildbot.
Thanks!

Regards,
Chao-ying
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore

[Holger Hans Peter Freyther]

On Wed, Aug 29, 2012 at 05:58:10PM +, Fu, Chao-Ying wrote:
> Hi All,
> 
>   Before a MIPS buildbot is ready, you can go ahead to change the assembler 
> or any parts of code.  We (MIPS) will test new code and submit patches that 
> are required to fix the MIPS JSC build.  Don't need to worry about breaking 
> the MIPS build.  (I have a cron job that checks out code and builds JSC on a 
> native MIPS Linux every night.)  This is the current process that we use, I 
> think.  Thanks a lot!

Hi,

more pennies. That is not how the other stakeholders develop inside the
WebKit project. There is little to no value for this community if you
test behind closed doors. E.g. how can members of this community know that
a lack of communication is the lack of issues and not you being reassigned
to something else?

holger
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore

[Fu, Chao-Ying]

Hi Holger,

  We happily and actively maintain the MIPS port for JSC, and will set up new 
MIPS buildbot soon.
If there are other things that we can help, please let us know.  Thanks a lot!

Regards,
Chao-ying

> -Original Message-
> From: Holger Hans Peter Freyther [mailto:ze...@selfish.org] 
> Sent: Wednesday, August 29, 2012 12:56 PM
> To: Osztrogonac Csaba
> Cc: WebKit Development; Frederic Lepied; Fu, Chao-Ying; 
> Thouraya ANDOLSI
> Subject: Re: [webkit-dev] SH4, MIPS, and legacy-ARM 
> assemblers in JavaScriptCore
> 
> On Wed, Aug 29, 2012 at 12:35:04PM +0200, Osztrogonac Csaba wrote:
> > Hi All,
> 
> Hi,
> 
> my two cents. I failed to engage companies building/using the 
> respective
> architectures and I think the best way forward is to remove them. I am
> happy to prepare a patch for that.
> 
> holger
> 
> PS: Using the proper sender address for webkit-dev
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore

[Holger Hans Peter Freyther]

On Wed, Aug 29, 2012 at 12:35:04PM +0200, Osztrogonac Csaba wrote:
> Hi All,

Hi,

my two cents. I failed to engage companies building/using the respective
architectures and I think the best way forward is to remove them. I am
happy to prepare a patch for that.

holger

PS: Using the proper sender address for webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Is the New XMLParser dead?

[David Hyatt]

On Aug 27, 2012, at 7:17 PM, Adam Barth wrote:

> My position is simple: the code is broken and unused.  As a general
> rule, we shouldn't keep broken, unused code in the tree for extended
> periods of time.  Therefore, we should remove it.

I agree with Adam. We should aggressively cull dead code from the tree. It's 
the only way to keep things tidy. "I may get back to it at some point in the 
future" is a fine statement, but without any firm commitment, it seems best to 
just remove the code from the tree for now. If and when someone steps up to 
actually work on it again, it shouldn't be much work to bring the code back to 
life. Forcing everyone else to deal with code that may or may not ever be 
returned to in the meantime isn't really fair to the rest of the project.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore

[Fu, Chao-Ying]

Hi All,

  Before a MIPS buildbot is ready, you can go ahead to change the assembler or 
any parts of code.  We (MIPS) will test new code and submit patches that are 
required to fix the MIPS JSC build.  Don't need to worry about breaking the 
MIPS build.  (I have a cron job that checks out code and builds JSC on a native 
MIPS Linux every night.)  This is the current process that we use, I think.  
Thanks a lot!

Regards,
Chao-ying


> -Original Message-
> From: Osztrogonac Csaba [mailto:o...@inf.u-szeged.hu] 
> Sent: Wednesday, August 29, 2012 3:35 AM
> To: WebKit Development
> Cc: Holger Hans Peter Freyther; Frederic Lepied; Fu, 
> Chao-Ying; Thouraya ANDOLSI
> Subject: Re: [webkit-dev] SH4, MIPS, and legacy-ARM 
> assemblers in JavaScriptCore
> 
> Hi All,
> 
> I'd like to inquire about the future of MIPS and SH4 assemblers.
> 
> A long time ago we had buildbots for MIPS and SH4 platforms 
> (hosted by Holger).
> But their last builds were at 29th June, machine were 
> stopped, bots were removed
> from build.webkit.org (2 months before!).  Is there anyone 
> interested in maintaining
> MIPS and SH4 buildbots (and probably EWS bots) to catch build 
> failures early?
> 
> Gábor is working on fixing 
> https://bugs.webkit.org/show_bug.cgi?id=79040 and it
> seems the fix will affect all assemblers. But I don't think 
> if it is a good idea
> to try to fix MIPS and SH4 assemblers blindly without EWS and 
> buildbots. And who
> knows if MIPS and SH4 builds work now or not?
> 
> br,
> Ossy
> 
> Filip Pizlo írta:
> > Hi all,
> > 
> > We are actively trying to improve the WebKit JavaScript 
> engine (JavaScriptCore), with new debugging, profiling, 
> memory efficiency, and performance features.  Because 
> JavaScriptCore is a JIT-based engine, this inevitably means 
> doing JIT work, which in turn includes adding new 
> instructions to the JIT assemblers and changing the API 
> between the assemblers and the JIT.
> > 
> > Currently, the maintenance situation in the assembler layer 
> is not great.  We have three well-supported assemblers, 
> X86-32, X86-64, and ARMv7. Then we have three assemblers that 
> appear to be on life support: legacy (non-THUMB2, pre-v7) 
> ARM, SH4, and MIPS.  It is increasingly painful to maintain 
> these three barely-supported assemblers.  None of these 
> assemblers has been updated to support the new JIT or 
> interpreter infrastructure, and there appears to be no 
> ongoing effort to do so.  That means that for progress to be 
> made on X86 and ARMv7, we need to increasingly scatter #if 
> ENABLE(...) noise throughout the system to keep those other 
> assemblers building.  Neither the active JavaScriptCore 
> contributors, nor those running the bots for those hardware 
> platforms, appear to have much interest in maintaining those 
> assemblers, other than the occasional build fix.
> > 
> > This is not a good situation to be in.
> > 
> > So, I am curious: is anyone shipping with the legacy ARM 
> assembler, the MIPS assembler, or the SH4 assembler?
> > 
> > As a secondary question, if you are shipping the legacy ARM 
> assembler, are you doing so because you have legacy ARM 
> hardware or because you have not had the chance to switch to 
> the new ARM assembler in your codebase?
> > 
> > -Filip
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: WTF HashMap iterators to use key/value instead first/second

[Maciej Stachowiak]

I like the idea of this change. Using key and value makes things more readable 
at the site of use than a generic first/second. It's unfortunate that it is 
hard to deploy, but I think it's worth it to work through those challenges.  `

-Maciej

On Aug 28, 2012, at 3:24 PM, Caio Marcelo de Oliveira Filho 
 wrote:

> Hello,
> 
> I would like to propose we change HashMap iterators to use 'key' and
> 'value' instead of 'first' and 'second'. The work is being tracked in
> the bug https://bugs.webkit.org/show_bug.cgi?id=82784.
> 
> The idea came from https://bugs.webkit.org/show_bug.cgi?id=71063#c2. I
> argue that this change will make code more readable, specially in
> situations where either the key or the value is a pair. One example of
> this situation is in
> Source/JavaScriptCore/bytecompiler/NodesCodegen.cpp
> 
> GetterSetterMap::AddResult result =
> map.add(node->name().impl(), pair);
> if (!result.isNewEntry)
> -result.iterator->second.second = node;
> +result.iterator->value.second = node;
> 
> another one is in
> Source/WebCore/platform/graphics/chromium/TiledLayerChromium.cpp
> 
> for (CCLayerTilingData::TileMap::const_iterator iter =
> m_tiler->tiles().begin(); iter != m_tiler->tiles().end(); ++iter) {
> -int i = iter->first.first;
> -int j = iter->first.second;
> -UpdatableTile* tile = 
> static_cast(iter->second.get());
> +int i = iter->key.first;
> +int j = iter->key.second;
> +UpdatableTile* tile = static_cast(iter->value.get());
> 
> I also think that in "non-pair key and non-pair value" situations the
> readability is improved.
> 
> One downside of this change is that STL uses first and second in its
> maps so that would confuse people. After inspecting the whole
> repository for 'first' and 'second', the usage of std::map in WebKit
> is an exception not a rule, IMHO this makes the confusion less
> troublesome.
> 
> Are there other downsides am I missing? What do you guys think? Unless
> we figure this is a bad change for the project, I intend to land it.
> 
> I've attempted to land this previously, I found out it caused a major
> breakage in some internal builds. I apologize for that inconvenience
> and the time lost.
> 
> I'm looking into ways to make the transition smoother, but until now
> couldn't find a solution that doesn't require C++11. Either way, if we
> land this change, I'll sync with developers from the affected ports
> that I know could be internally affected to avoid more breakage.
> 
> 
> Best regards,
> 
> -- 
> Caio Marcelo de Oliveira Filho
> openBossa @ INdT - Instituto Nokia de Tecnologia
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: WTF HashMap iterators to use key/value instead first/second

[Joe Mason]

I'm in favour of this change, as WTF::HashMap is not std::map and having the 
interface be almost like std::map in some ways, but totally unlike it in other 
ways, is more confusing than a clean break would be.

From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of Caio Marcelo de Oliveira Filho [caio.olive...@openbossa.org]
Sent: Tuesday, August 28, 2012 6:24 PM
To: webkit-dev@lists.webkit.org
Subject: [webkit-dev] Proposal: WTF HashMap iterators to use key/value  instead 
first/second

Hello,

I would like to propose we change HashMap iterators to use 'key' and
'value' instead of 'first' and 'second'. The work is being tracked in
the bug https://bugs.webkit.org/show_bug.cgi?id=82784.

The idea came from https://bugs.webkit.org/show_bug.cgi?id=71063#c2. I
argue that this change will make code more readable, specially in
situations where either the key or the value is a pair. One example of
this situation is in
Source/JavaScriptCore/bytecompiler/NodesCodegen.cpp

 GetterSetterMap::AddResult result =
map.add(node->name().impl(), pair);
 if (!result.isNewEntry)
-result.iterator->second.second = node;
+result.iterator->value.second = node;

another one is in
Source/WebCore/platform/graphics/chromium/TiledLayerChromium.cpp

 for (CCLayerTilingData::TileMap::const_iterator iter =
m_tiler->tiles().begin(); iter != m_tiler->tiles().end(); ++iter) {
-int i = iter->first.first;
-int j = iter->first.second;
-UpdatableTile* tile = static_cast(iter->second.get());
+int i = iter->key.first;
+int j = iter->key.second;
+UpdatableTile* tile = static_cast(iter->value.get());

I also think that in "non-pair key and non-pair value" situations the
readability is improved.

One downside of this change is that STL uses first and second in its
maps so that would confuse people. After inspecting the whole
repository for 'first' and 'second', the usage of std::map in WebKit
is an exception not a rule, IMHO this makes the confusion less
troublesome.

Are there other downsides am I missing? What do you guys think? Unless
we figure this is a bad change for the project, I intend to land it.

I've attempted to land this previously, I found out it caused a major
breakage in some internal builds. I apologize for that inconvenience
and the time lost.

I'm looking into ways to make the transition smoother, but until now
couldn't find a solution that doesn't require C++11. Either way, if we
land this change, I'll sync with developers from the affected ports
that I know could be internally affected to avoid more breakage.


Best regards,

--
Caio Marcelo de Oliveira Filho
openBossa @ INdT - Instituto Nokia de Tecnologia
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] removing vendor prefix from CSS animations, transitions

[Jussi Kukkonen]

On Thu, Aug 23, 2012 at 8:55 PM, Simon Fraser  wrote:
> On Aug 23, 2012, at 1:06 AM, Jussi Kukkonen  wrote:
>> How about Animations and Transitions, is there a reason for me to not
>> send patches that enable the unprefixed properties and events in those
>> specs at this point?
>
> I  think we should review the current working draft of the specs, and 
> understand
> how far we deviate from them (in the form of a set of filed bugs), rather 
> than doing
> a cowboy unprefixing like the other vendors.
>
> Simon
>

For what it's worth, It seems webkit passes the Nokia submitted tests*
with one exception where the test might actually be wrong
(animation-iteration-count-003 sets an invalid iteration count value
and the result is not defined in the spec).

Jussi

*) http://test.csswg.org/source/contributors/nokia/submitted/css3-animations/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore

[Gergely Kis]

Hi All,

We are working on updating WebKit MIPS support. In particular we have a
work in progress LLINT and DFG implementation for MIPS.

We already have results (mozilla testsuite, sunspider and v8 benchmarks run
reasonably well), but there are still some bugs that need to be fixed
before we can submit this work.

Regarding https://bugs.webkit.org/show_bug.cgi?id=79040, feel free to
contact us if you need help with the MIPS specific bits.

Regarding the MIPS buildbots: I will check internally if we can host a MIPS
build slave (possibly including different boards) for the webkit project,
and get back to you.

Best Regards,
Gergely

On Wed, Aug 29, 2012 at 12:35 PM, Osztrogonac Csaba wrote:

> Hi All,
>
> I'd like to inquire about the future of MIPS and SH4 assemblers.
>
> A long time ago we had buildbots for MIPS and SH4 platforms (hosted by
> Holger).
> But their last builds were at 29th June, machine were stopped, bots were
> removed
> from build.webkit.org (2 months before!).  Is there anyone interested in
> maintaining
> MIPS and SH4 buildbots (and probably EWS bots) to catch build failures
> early?
>
> Gábor is working on fixing 
> https://bugs.webkit.org/show_**bug.cgi?id=79040and
>  it
> seems the fix will affect all assemblers. But I don't think if it is a
> good idea
> to try to fix MIPS and SH4 assemblers blindly without EWS and buildbots.
> And who
> knows if MIPS and SH4 builds work now or not?
>
> br,
> Ossy
>
> Filip Pizlo írta:
>
>> Hi all,
>>
>> We are actively trying to improve the WebKit JavaScript engine
>> (JavaScriptCore), with new debugging, profiling, memory efficiency, and
>> performance features.  Because JavaScriptCore is a JIT-based engine, this
>> inevitably means doing JIT work, which in turn includes adding new
>> instructions to the JIT assemblers and changing the API between the
>> assemblers and the JIT.
>>
>> Currently, the maintenance situation in the assembler layer is not great.
>>  We have three well-supported assemblers, X86-32, X86-64, and ARMv7. Then
>> we have three assemblers that appear to be on life support: legacy
>> (non-THUMB2, pre-v7) ARM, SH4, and MIPS.  It is increasingly painful to
>> maintain these three barely-supported assemblers.  None of these assemblers
>> has been updated to support the new JIT or interpreter infrastructure, and
>> there appears to be no ongoing effort to do so.  That means that for
>> progress to be made on X86 and ARMv7, we need to increasingly scatter #if
>> ENABLE(...) noise throughout the system to keep those other assemblers
>> building.  Neither the active JavaScriptCore contributors, nor those
>> running the bots for those hardware platforms, appear to have much interest
>> in maintaining those assemblers, other than the occasional build fix.
>>
>> This is not a good situation to be in.
>>
>> So, I am curious: is anyone shipping with the legacy ARM assembler, the
>> MIPS assembler, or the SH4 assembler?
>>
>> As a secondary question, if you are shipping the legacy ARM assembler,
>> are you doing so because you have legacy ARM hardware or because you have
>> not had the chance to switch to the new ARM assembler in your codebase?
>>
>> -Filip
>>
> __**_
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/**mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore

[Osztrogonac Csaba]

Hi All,

I'd like to inquire about the future of MIPS and SH4 assemblers.

A long time ago we had buildbots for MIPS and SH4 platforms (hosted by Holger).
But their last builds were at 29th June, machine were stopped, bots were removed
from build.webkit.org (2 months before!).  Is there anyone interested in 
maintaining
MIPS and SH4 buildbots (and probably EWS bots) to catch build failures early?

Gábor is working on fixing https://bugs.webkit.org/show_bug.cgi?id=79040 and it
seems the fix will affect all assemblers. But I don't think if it is a good idea
to try to fix MIPS and SH4 assemblers blindly without EWS and buildbots. And who
knows if MIPS and SH4 builds work now or not?

br,
Ossy

Filip Pizlo írta:

Hi all,

We are actively trying to improve the WebKit JavaScript engine 
(JavaScriptCore), with new debugging, profiling, memory efficiency, and 
performance features.  Because JavaScriptCore is a JIT-based engine, this 
inevitably means doing JIT work, which in turn includes adding new instructions 
to the JIT assemblers and changing the API between the assemblers and the JIT.

Currently, the maintenance situation in the assembler layer is not great.  We 
have three well-supported assemblers, X86-32, X86-64, and ARMv7. Then we have 
three assemblers that appear to be on life support: legacy (non-THUMB2, pre-v7) 
ARM, SH4, and MIPS.  It is increasingly painful to maintain these three 
barely-supported assemblers.  None of these assemblers has been updated to 
support the new JIT or interpreter infrastructure, and there appears to be no 
ongoing effort to do so.  That means that for progress to be made on X86 and 
ARMv7, we need to increasingly scatter #if ENABLE(...) noise throughout the 
system to keep those other assemblers building.  Neither the active 
JavaScriptCore contributors, nor those running the bots for those hardware 
platforms, appear to have much interest in maintaining those assemblers, other 
than the occasional build fix.

This is not a good situation to be in.

So, I am curious: is anyone shipping with the legacy ARM assembler, the MIPS 
assembler, or the SH4 assembler?

As a secondary question, if you are shipping the legacy ARM assembler, are you 
doing so because you have legacy ARM hardware or because you have not had the 
chance to switch to the new ARM assembler in your codebase?

-Filip

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev