Re: [webkit-dev] ReadMe.md on Github

2017-02-21 Thread Konstantin Tokarev
  22.02.2017, 10:18, "Brian Burg" : On Feb 21, 2017, at 10:53 PM, Ryosuke Niwa  wrote: Hi, I recently added ReadMe.md file to WebKit's top-level directory for the convenience of Github users: https://github.com/WebKit/webkit I've added a very abridged instruction on how to checkout & build WebKit for Mac/iOS ports for simplicity. It would be great if we can trim down the amount of information further. I feel like GTK+ port's instruction can be consolidated enough to fit there but we might want to write some script that someone can run to do everything you need like Tools/Scripts/configure-xcode-for-ios-development for iOS first. Let me know what you think of it, and please feel free to post a patch to improve it! This is really great Ryosuke, thanks for your work! We may want to consider a similar consolidation of the Trac Wiki, which is sprawling, mostly outdated, hard to use, and hostile to new developers/passersby.  I think it's a FUD. Also note that on Github wiki is open for editing either for everyone, or for contributors of repo that are given write access.  - R. Niwa___webkit-dev mailing listwebkit-dev@lists.webkit.orghttps://lists.webkit.org/mailman/listinfo/webkit-dev,___webkit-dev mailing listwebkit-dev@lists.webkit.orghttps://lists.webkit.org/mailman/listinfo/webkit-dev  -- Regards,Konstantin ___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] ReadMe.md on Github

2017-02-21 Thread Brian Burg

> On Feb 21, 2017, at 10:53 PM, Ryosuke Niwa  wrote:
> 
> Hi,
> 
> I recently added ReadMe.md file to WebKit's top-level directory for the 
> convenience of Github users: https://github.com/WebKit/webkit 
> 
> 
> I've added a very abridged instruction on how to checkout & build WebKit for 
> Mac/iOS ports for simplicity. It would be great if we can trim down the 
> amount of information further.
> 
> I feel like GTK+ port's instruction can be consolidated enough to fit there 
> but we might want to write some script that someone can run to do everything 
> you need like Tools/Scripts/configure-xcode-for-ios-development for iOS first.
> 
> Let me know what you think of it, and please feel free to post a patch to 
> improve it!

This is really great Ryosuke, thanks for your work! We may want to consider a 
similar consolidation of the Trac Wiki, which is sprawling, mostly outdated, 
hard to use, and hostile to new developers/passersby.

> 
> - R. Niwa
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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


[webkit-dev] ReadMe.md on Github

2017-02-21 Thread Ryosuke Niwa
Hi,

I recently added ReadMe.md file to WebKit's top-level directory for the
convenience of Github users: https://github.com/WebKit/webkit

I've added a very abridged instruction on how to checkout & build WebKit
for Mac/iOS ports for simplicity. It would be great if we can trim down the
amount of information further.

I feel like GTK+ port's instruction can be consolidated enough to fit there
but we might want to write some script that someone can run to do
everything you need like Tools/Scripts/configure-xcode-for-ios-development
for iOS first.

Let me know what you think of it, and please feel free to post a patch to
improve it!

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

2017-02-21 Thread Mark Lam
Oh yeah, I forgot about that.  I think the register state is more important for 
crash analysis, especially if we can make sure that the compiler does not 
aggregate the int3s.  I’ll explore alternatives.

> On Feb 21, 2017, at 5:54 PM, Saam barati  wrote:
> 
> I thought the main point of moving to SIGTRAP was to preserve register state?
> 
> That said, there are probably places where we care more about the message 
> than the registers.
> 
> - Saam
> 
>> On Feb 21, 2017, at 5:43 PM, Mark Lam  wrote:
>> 
>> Is there a reason why RELEASE_ASSERT (and friends) does not call 
>> WTFReportAssertionFailure() to report where the assertion occur?  Is this 
>> purely to save memory?  svn blame tells me that it has been this way since 
>> the introduction of RELEASE_ASSERT in r140577 many years ago.
>> 
>> Would anyone object to adding a call to WTFReportAssertionFailure() in 
>> RELEASE_ASSERT() like we do for ASSERT()?  One of the upside (side-effect) 
>> of adding this call is that it appears to stop the compiler from aggregating 
>> all the RELEASE_ASSERTS into a single code location, and this will help with 
>> post-mortem crash debugging.
>> 
>> Any thoughts?
>> 
>> Mark
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

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


Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

2017-02-21 Thread Saam barati
I thought the main point of moving to SIGTRAP was to preserve register state?

That said, there are probably places where we care more about the message than 
the registers.

- Saam

> On Feb 21, 2017, at 5:43 PM, Mark Lam  wrote:
> 
> Is there a reason why RELEASE_ASSERT (and friends) does not call 
> WTFReportAssertionFailure() to report where the assertion occur?  Is this 
> purely to save memory?  svn blame tells me that it has been this way since 
> the introduction of RELEASE_ASSERT in r140577 many years ago.
> 
> Would anyone object to adding a call to WTFReportAssertionFailure() in 
> RELEASE_ASSERT() like we do for ASSERT()?  One of the upside (side-effect) of 
> adding this call is that it appears to stop the compiler from aggregating all 
> the RELEASE_ASSERTS into a single code location, and this will help with 
> post-mortem crash debugging.
> 
> Any thoughts?
> 
> Mark
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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


Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

2017-02-21 Thread Filip Pizlo
+1

-Filip

> On Feb 21, 2017, at 17:43, Mark Lam  wrote:
> 
> Is there a reason why RELEASE_ASSERT (and friends) does not call 
> WTFReportAssertionFailure() to report where the assertion occur?  Is this 
> purely to save memory?  svn blame tells me that it has been this way since 
> the introduction of RELEASE_ASSERT in r140577 many years ago.
> 
> Would anyone object to adding a call to WTFReportAssertionFailure() in 
> RELEASE_ASSERT() like we do for ASSERT()?  One of the upside (side-effect) of 
> adding this call is that it appears to stop the compiler from aggregating all 
> the RELEASE_ASSERTS into a single code location, and this will help with 
> post-mortem crash debugging.
> 
> Any thoughts?
> 
> Mark
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Why does RELEASE_ASSERT not have an error message?

2017-02-21 Thread Mark Lam
Is there a reason why RELEASE_ASSERT (and friends) does not call 
WTFReportAssertionFailure() to report where the assertion occur?  Is this 
purely to save memory?  svn blame tells me that it has been this way since the 
introduction of RELEASE_ASSERT in r140577 many years ago.

Would anyone object to adding a call to WTFReportAssertionFailure() in 
RELEASE_ASSERT() like we do for ASSERT()?  One of the upside (side-effect) of 
adding this call is that it appears to stop the compiler from aggregating all 
the RELEASE_ASSERTS into a single code location, and this will help with 
post-mortem crash debugging.

Any thoughts?

Mark

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


Re: [webkit-dev] CSS Parse error in element.

2017-02-21 Thread Atul Sowani
I compared the code of TP5 with the code of default qtwebkit in PhantomJS
and did not find any difference. So I think PhantomJS is making use of the
latest version of QtWebKit.

On Fri, Feb 17, 2017 at 4:04 PM, Konstantin Tokarev 
wrote:

>
>
> 17.02.2017, 12:19, "Atul Sowani" :
> > I built the debug-mode binary and verified on x86_64 that I am seeing
> exactly the same crashes (due to enabled asserts) as seen on ppc64le.
>
> That's what I've expected.
>
> >
> > On ppc64le, on the other hand, with release-mode binary, webpage is
> loaded without issues. Only difference in behavior is seen in winding down
> of heap maintainer (and timer) code - which crashes on ppc64le.
>
> Have you reported details of this remaining crash already?
>
> Anyway, you need to upgrade QtWebKit first. Fixing WebKit from 2013 on
> platform that haven't existed at that time has very little practical value
> (and also confuses readers of this list most of whom work with trunk). If
> you have troubles with building QtWebKit TP5 you can ask on webkit-qt list,
> if there are issues with PhantomJS ask on their list. Or you can reach us
> on IRC.
>
> >
> > On Wed, Feb 15, 2017 at 2:18 PM, Konstantin Tokarev 
> wrote:
> >> 15.02.2017, 11:40, "Atul Sowani" :
> >>> Hi,
> >>>
> >>> I am wondering about the behavioural difference of the same code on
> two different platforms, under same conditions. For example, consider
> following code in css/CSSCalculationValue.cpp (under class
> CSSCalcBinaryOperation):
> >>>
> >>> static PassRefPtr 
> >>> create(PassRefPtr
> leftSide, PassRefPtr rightSide, CalcOperator op)
> >>> {
> >>> ASSERT(leftSide->category() != CalcOther &&
> rightSide->category() != CalcOther);
> >>> CalculationCategory newCategory = determineCategory(*leftSide,
> *rightSide, op);
> >>> if (newCategory == CalcOther)
> >>> return 0;
> >>> return adoptRef(new CSSCalcBinaryOperation(leftSide,
> rightSide, op, newCategory));
> >>> }
> >>>
> >>> The values in question are as follows:
> >>> calling CSSCalcBinaryOperation::create from
> parseAdditiveValueExpression
> >>> operatorCharacter 2 = -
> >>> lhs = 1 rhs = 1
> >>> in CSSCalcBinaryOperation::create
> >>> leftSide category = 5
> >>> rightSide category = 1
> >>>
> >>> Now exactly same values cause ASSERT on ppc64le, causing a crash
> whereas it just passes smoothly on x86_64.
> >>
> >> It can be that you are using release build on x86_64, where asserts are
> disabled
> >>
> >>> The C/C++ compiler is identical on both the platforms:
> >>>
> >>> on x86_64:
> >>> # g++ -v
> >>> Using built-in specs.
> >>> COLLECT_GCC=g++
> >>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
> >>> Target: x86_64-linux-gnu
> >>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
> --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
> --program-suffix=-5 --enable-shared --enable-linker-build-id
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
> --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre
> --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
> --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
> --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
> --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
> --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> >>> Thread model: posix
> >>> gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
> >>>
> >>> on ppc64le:
> >>> # g++ -v
> >>> Using built-in specs.
> >>> COLLECT_GCC=g++
> >>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/5/lto-wrapper
> >>> Target: powerpc64le-linux-gnu
> >>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/IBM
> 5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
> --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
> --program-suffix=-5 --enable-shared --enable-linker-build-id
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-libquadmath --enable-plugin --with-system-zlib
> --disable-browser-plugin