Hi Filip,
we (Gabor Loki and me) are the maintainers of the traditional ARM port,
and we are willing to fix all issues. Just let us know what we need to do.
You can assign the necessary bug reports to us and we are available in the
#squirrelfish (or #webkit) channel as well.
Regards,
Zoltan
Hi
Hi,
We (STMicroelectronics) are the maintainer of SH4 port.
We would like to continue maintaining it.
Could you please let me know what we need to do ? and feel free to assign
for me any bug related to SH4.
Regards,
Thouraya.
___
webkit-dev mailing
Hello,
I'm working on adding setWindowIsKey to LayoutTestController for WK2. Lack
of this function prevents from passing few layout tests (eg.
fast/dom/Window-onFocus.html,
fast/events/blur-focus-window-should-blur-focus-element.html).
New implementation posts synchronic message to
The problem is that as we make changes we end up breaking the SH4, MIPS,
ARMvOld builds, which we are ostensibly not allowed to do, and so have to spend
significant amounts of time trying to ensure that the builds don't break/start
failing horribly, and then having committed the patch[es] we
Is there a way to reduce these costs other than deleting the slower-maintained
JITs? For example, could we temporarily freeze the JIT (perhaps the whole JSC
engine somehow) at old versions somehow for architectures that may take time to
catch up?
Regards,
Maciej
On Jun 22, 2012, at 10:52 AM,
That would be the ifdef hell we currently deal with.
One option (that would keep everything building till appropriate people have
fixed whatever needs to be fixed) would simply be to disable the JIT for
effected platforms everytime something changes that is too difficult for us to
blindly
Hello,
I am now able to build a static lib for iOS simulator and device using
llint instead of the classic interpreter, after murking around with
the codebase for a short while.
This is much needed when we embed JS inside an ios app since we are
unable to run JS using the JIT.
A few missing
True, most of the changes are trivial. The problem is that the changes are
usually appear without prior notice. A patch which depends on new macro
assembler instructions, will obviously break the build, and we are not
necessary there to fix it immediately. I think most improvements require
time to
On Jun 22, 2012, at 12:43 PM, Zoltan Herczeg zherc...@webkit.org wrote:
True, most of the changes are trivial. The problem is that the changes are
usually appear without prior notice. A patch which depends on new macro
assembler instructions, will obviously break the build, and we are not
How do I submit the patch for review? Please let me know.
http://www.webkit.org/coding/contributing.html
Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Hi Filip,
We will be fine, if the MIPS build isn't ok due to new features or changes.
You can go ahead to check in patches for your targets (even with MIPS JIT
disabled).
Ex: Suggested by Oliver
http://lists.webkit.org/pipermail/webkit-dev/2012-June/021267.html
We can catch up to fix. This
I don't want adding instructions to SH4, MIPS, and legacy ARM to be a
blocker for JSC work.
I didn't say you have to wait. I just said you should notify us that
something is coming which will break the build.
Regards,
Zoltan
___
webkit-dev mailing
Ah, sorry, I misunderstood!
What about having a convention that assembly port maintainers are CC'd on bugs
that require new assembler support?
This will give you probably 10 hours heads up before the patch lands.
-F
On Jun 22, 2012, at 9:29 PM, Zoltan Herczeg zherc...@webkit.org wrote:
I
13 matches
Mail list logo
