Re: [webkit-dev] Rewriting binding code generator, maybe?
dpranke, On 04/11/2013 02:12 PM, Dirk Pranke wrote: I'm not sure how useful a suggestion this is, but ANTLR has a pretty strong framework for separating parsing from code generation and seems like it would be an ideal fit for this, except that the tool itself is written in Java. Perhaps that is a show-stopper? I'm not actually aware of any similar parser-generator tools that have similar architectures but are in more WebKit/Blink-friendly languages, but maybe they exist? Pyparsing is a nice little library that requires no code generation (grammar is written in pure Python) and is very simple to use. Their website lives at http://pyparsing.wikispaces.com/. Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Reflecting pixel delta distance in ImageDiff
On Fri, Jun 15, 2012 at 8:24 PM, Tony Payne tpa...@chromium.org wrote: Looking at the code for CG, gtk and Win versions of ImageDiff, I think they already do something similar. Is this correct? The GTK and Efl produces a grayscale image, where the pixel goes from black (no difference) to white, gradually, proportional to the euclidean distance between both pixel colors inside a RGB cube (sort of, as alpha channel is also considered). -- Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Reflecting pixel delta distance in ImageDiff
On Fri, Jun 15, 2012 at 8:27 PM, Ryosuke Niwa rn...@webkit.org wrote: People with Protanomaly like myself won't be too happy about it. I'm already having a really hard time finding the red pixels on diffs without zooming. Perhaps generating a list of rectangles where there are differences would help produce some interactive result with some marching ants bounding boxes that when clicked, zooms in to show the details? Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A massive rebaseline needed for r117672
On Sat, May 19, 2012 at 9:00 AM, Dumez, Christophe christophe.du...@intel.com wrote: I took care of the rebaseline for EFL port at: https://bugs.webkit.org/show_bug.cgi?id=86940 I just need a committer to cq+. Done. Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Committing EFL baselines
On 10/17/2011 04:13 PM, Raphael Kubo da Costa wrote: Anyway, are there any options besides simply svn commit'ting all these files? I'm thinking in uploading the text baselines (which are small) first. When these are in place, we could work together to diminish the amount of pixel baselines by adopting things like ScrollbarMock and such. Sounds like a plan? Cheers, Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] layout tests cannot set Generic RGB Color Profile on headless MacPro?
Elliot, On 10/07/2011 05:05 PM, Elliot Poger wrote: Presumably connecting to a KVM or other fake monitor, as Ryosuke mentions, would work. You could try connecting VGA pins 4 (id2) and 11 (id0) to pin 5 (ground). This will signal the video controller that there's a monitor which supports 1024x768 resolution; could also work if only pin 11 is grounded as well. Can be done with a paper clip. Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Contributor list (was: Do you maintain OS(WINCE)?)
Ryosuke, On 09/13/2011 07:06 PM, Ryosuke Niwa wrote: Yeah, they're outdated to say the least. Can we merge those two lists? I think we can move information inside committers.py into a JSON file and load it automatically on the wiki. I don't know how to add arbitrary HTML on a wiki page, but I made a page that loads loads committers.py and presents it in a web-friendly way: http://people.profusion.mobi/~leandro/webkit-contributors.html With filtering by port or area of expertise this can be quite handy. Thoughts on how this could be improved? Specially if it can be kept up to date without too much work. Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do you maintain OS(WINCE)?
Antonio, On 09/13/2011 04:00 PM, Antonio Gomes wrote: I believe it was maintained by Torch Mobile, and, according to George Staikos, it is not part of the plans any more (Torch was acquired by RIM). AFAIR, Patrick Gansterer (paroga) is still working on the WinCE port. He usually informally reviews CMake-related changes. Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do you maintain OS(WINCE)?
On 09/13/2011 06:45 PM, Eric Seidel wrote: We don't even have a way to view what ports exist! There is a ports.py file, in the same spirit there is a committers.py file, even though it does contain only a fraction of all the ports. Were it better maintained, one could add references to each contributor in committers.py. Being machine-readable, a post-commit hook that updates a page in the Wiki can be added to provide the same info in a human-readable format. Sheriffbot could also be teached about this. Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] More ports on nightly.webkit.org?
Adam, On 09/12/2011 03:10 PM, Adam Barth wrote: Do any ports besides the Apple ports produce nightly builds that end-users might be interested in using? If so, it might make sense to expand the offerings on http://nightly.webkit.org/ to include more choices. For example, Linux users might enjoy a nightly build that runs on Linux. Excellent. I can provide at least WebKit-EFL/Linux packages. If it's easy to generate packages for other Linux ports as well (GTK and Qt ports I know that are easy to build; never tried Wx and Chromium), I can give a try in writing and maintaining a bot that does that. OTOH, providing binary packages for Linux isn't an easy task. Different packaging standards, ABI differences, etc, makes binary distribution a nightmare: even if a new set of libraries are installed, there is no warranty that the browsers will pick those up or even if it will work at all (not really an issue for nightly builds but annoying nonetheless). If there's an agreement of which Linux distribution should be supported by n.w.o, things will be a lot easier. Cheers, Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Committing EFL baselines
Hi. What's the preferred way to commit a ton of baselines for a port that currently has none? On our internal EFL tree, there is about 125MB of baselines for both pixel and text tests. Unfortunately we were unable to share our baselines with similar ports, due to slight differences in results. This is pretty much unreviewable, so I pretend to commit this directly, in batches (one commit per toplevel directory in LayoutTests/platform/efl) in the next weeks. Any objections or suggestions? Cheers, Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Committing EFL baselines
On 09/12/2011 05:36 PM, Ryosuke Niwa wrote: On our internal EFL tree, there is about 125MB of baselines for both pixel and text tests. Unfortunately we were unable to share our baselines with similar ports, due to slight differences in results. What are differences you're seeing? Most differences are because the EFL port doesn't change the viewport size because of the scrollbar: it is drawn on top of the content on the EFL port by default. So there is a little more room horizontally, and then text results are slightly different from GTK+'s (which uses the same font backends, for instance). In those tests that only draws colored rectangles, the render tree is pretty much the same as any other port's. However, in these tests, the pixel results are rendered with colors slightly different from the expected. Almost no difference to the naked eye. I suspect either some rounding problems inside Cairo, or wrong color profile. Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Code Search for webkit.org
On 09/08/2011 06:57 PM, Adam Roben wrote: On Sep 8, 2011, at 5:52 PM, Eric Seidel wrote: I'm curious how other developers search the WebKit code? I use git grep or Xcode/Visual Studio's find functionality. But I trust git grep more for code that might run on other platforms. I also use git grep. I tried ctags for a while but it didn't work that well with multiple implementations for the same function/method. BTW, with the recent news that Google is axing Labs, I don't know if Code Search will be available for much longer. It'd be sad; it's a nice tool. Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
On Sun, Jul 10, 2011 at 2:52 PM, Adam Barth aba...@webkit.org wrote: These changes might increase the number of image baselines we store in the tree for chromium-mac-derived ports (because there will be fewer redundant fallback paths), but I expect that cost to be relatively small because essentially every port has different image baselines anyway. I like this idea, in general. However, since some ports (GTK+ and EFL, for instance) shares the same backends (Cairo, FontConfig, Pango, etc.), pixel tests are often the same. So, to minimize the size and maintenance effort of the LayoutTests, I think it would be a good idea to have baselines for the backends, with fallbacks for the ports. This of course wouldn't be a fallback tree, but would be simpler than what we currently have. OTOH, I'm not sure if this would help ports other than the ones mentioned. Comments? Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Renaming the blog (was Re: WebKit blog post proposal: Remote debugging with Web Inspector.)
On Mon, May 2, 2011 at 5:45 AM, Adam Barth aba...@webkit.org wrote: On Sun, May 1, 2011 at 2:27 AM, Maciej Stachowiak m...@apple.com wrote: On 2011-04-30, at 22:11, Pavel Feldman wrote: Back in the day, we named it after Hyatt's old blog. At this point, it might be that no one remembers it or gets the reference. Does anyone have any clever references involving WebKit? The only clever thing I can think of (and it's not very clever) is to make some play on -webkit-foo vendor-prefixed CSS features. (...) I'd suggest The Daily WTF (as a tribute to our greatest sub-library), but sadly someone already got a blog with this name. Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Who are the EFL reviewers?
On Mon, Apr 11, 2011 at 1:08 PM, David Levin le...@chromium.org wrote: Hi, Is it possible to promote some other peoples to reviewers in the EFL port? A step that I usually suggest to chromium folks before becoming reviewers is to actually do reviews on patches. Do everything except the r+ (with the submitter's permission). We (me, Lucas De Marchi, and Rafael Antognolli) are already informally reviewing patches; our reviews are then used by an official reviewer that either gives a r+ or rs+ based on our comments. I'm not currently allocated to work on WebKit, but if that would speed up the review queue (and provide some relief on Antonio and Kenneth, who have been primarily reviewing EFL patches), I could be a reviewer, yes. However, only one reviewer isn't optimal; I've worked mostly on the build system (besides quick fixes here and there), and Rafael and Lucas worked deep on the port, so they know more about how things work internally. It would be nice if one of them could also become a reviewer, but I can't speak for them. Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build Slave Shutdown
On Thu, Dec 16, 2010 at 3:05 PM, William Siegrist wsiegr...@apple.com wrote: Our buildbot allows for anonymous people to trigger things on the slaves, and it is like this on purpose for ease of use. However, that means it is possible for a malicious person to do things like shutdown all of the slaves. That is what happened last night around 10:30pm PST, from 66.57.13.12, and that is why the slaves are offline. Something weird happened when the EFL slave was shut down. It runs as an unprivileged user, but for some reason, the log file (twisted.log) and various other files inside the SVN checkout were owned by root. I initially thought the other admin restarted the buildslave service as root by mistake, but this isn't the case. I've fixed the permissions and the buildslave is up and running again, but I'm still a bit worried about this. chkrootkit does not ring any bells, and disk corruption is unlikely as this is both pontual and the slave is an Amazon EC2 instance. Quick searches on Google didn't return anything useful, so I ask: have things like this happened before? Thanks, Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Build slave: requesting username/password pairs
Hi. I've setup a machine to run as as a build bot for the EFL port. Instructions in the wiki says I should ask for a username/password pair here, so here I am. The necessary configuration to be sent to build.webkit.org was submitted as a patch on bug #47290. On a related note, the EFL EWS is already running. A patch to add the status bubble on Bugzilla has been submitted on bug #47277. Cheers, Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Add WebKit EFL component on Bugzilla
Hi. Could anyone please add a WebKit EFL component on Bugzilla? Thanks, Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Help with review of EFL CMake patches?
Patrick,
On Mon, May 3, 2010 at 6:09 PM, Patrick Roland Gansterer
par...@paroga.com wrote:
(...) but there a some parts which are not good for a general buildsystem.
E.g. INCLUDE(Options${PORT}) doesn't support different ports well, since
ports share some parts. (There some other points too; I'll post them on the
bug)
The idea of a Options${PORT} file is to put only the port-specific
checks and defaults there. They'll be different for each and every
port, and even if they're roughly the same, I don't think they should
be inside the same file, for two reasons: 1) it eases the review
process whenever one tries to update port-specific rules: the changes
to ${PORT} files shouldn't break any other port; and 2) it keeps the
main files cleaner.
Regarding (2): In the beginning, the EFL port would use autotools (as
used by the GTK+ port), but despite its syntax not helping maintain a
clean file, having lots of conditionals for the EFL and GTK+ port made
that build system, which was already difficult to maintain, a lot
worse. This is akin to having port-specific stuff into
platform-independent files, by #ifdefing things around. Sometimes it
is needed, but I think this should be avoided as much as possible.
Cheers,
--
Leandro
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing new port: EFL
Gustavo, On Tue, 2010-02-23 at 18:09 -0300, Gustavo Noronha Silva wrote: As everyone knows our build system is one of the slowest, so adding complexity to it may not be always a good idea. The changes to the build system should not impact its performance: checks to choose which files to compile/dependencies to add are performed only when running the configure script. Everything else should work as it is right now. Cheers, Leandro signature.asc Description: This is a digitally signed message part ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing new port: EFL
Eric, On Mon, 2010-02-22 at 11:19 -0800, Eric Seidel wrote: I have a few questions (and I assume others are curious to the answers as well): - Who maintains this port? (Samsung I assume.) ProFUSION and Samsung. - Is this an active port? (Are there plans for the EFL contributors to work upstream?) Yes, we want to work directly with upstream. ProFUSION itself will keep working on it even if contracts are over, as it is a great component for EFL and we invest a good amount of work in EFL-related technologies as it is part of our service offerings. I am doing the cleanups required by the upstream task, merge of GTK+'s and EFL's build system, and will do further works on unifying both GTK +'s and EFL's codebases. There are other people working on this port, however: - Rafael Antognolli antogo...@profusion.mobi, working on the port since August last year, did a great amount of work to get optimizations and fixes. - Gustavo Sverzut Barbieri barbi...@profusion.mobi, core developer of EFL, rewrote the WebKit/efl/ based on initial port by INdT. Is now the manager and internal ProFUSION reviewer. - Lucas De Marchi lucas.demar...@profusion.mobi, working to fill the gaps, like missing APIs in WebCoreSupport. - Raphael Kubo da Costa k...@profusion.mobi, worked on alternative backing store scaling to speed up zooming in mobile systems. - Does the EFL port have a DumpRenderTree implementation? (And if so, can it run the LayoutTests? What percentage pass?) Not yet, but we'll surely add it in future as we want to have automated tests just like Qt. Cheers, Leandro signature.asc Description: This is a digitally signed message part ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Announcing new port: EFL
Hi. I'm proud to announce a new WebKit port: to the Enlightenment Foundation Libraries (EFL). This port was made by ProFUSION on behalf of Samsung Electronics, which now wants to contribute it back upstream. It is based on the previous work by INdT, but most of WebKit/efl has been rewritten to fit better to the EFL architecture. The files that include INdT's work have their copyright listed accordingly. Some patches are already on the bugzilla, awaiting review: #35059, #35084 and #35087. There are more on their way. Regards, Leandro ProFUSION embedded systems signature.asc Description: This is a digitally signed message part ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
