Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5

2010-04-20 Thread Aaron Boodman
On Mon, Apr 19, 2010 at 5:53 PM, Peter Kasting pkast...@google.com wrote:
 On Thu, Apr 15, 2010 at 3:41 PM, Aaron Boodman a...@chromium.org wrote:

 I'm not sure what the path is for fetching favicons today. Does
 WebCore just implicitly do it, or does it expose the information to
 the host, who later may or may not make the request?

 Answering this is complicated by the fact that Chromium mostly uses a
 different codepath for all of this stuff than, say, Safari -- e.g. it
 bypasses the IconDatabase and pretty much all other classes/files called
 IconXXX entirely.

Yeah, I looked into this over the weekend, and -- shock! -- it turned
out to be a bigger change than I initially imagined. Since Chromium
has a different backend, that would mean implementing two sets of
changes.

Also, I think it would be wasteful to have WebKit download all linked
icons, even if the hosting browser has no intention of every using
some of them. So I'd want to add code to allow the browser to tell
WebKit which sizes it is interested in.

I still want to do this, but I'm going to have to reduce the priority
a little bit for now. I may come back to it in a month or so.

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


Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5

2010-04-20 Thread Maciej Stachowiak


On Apr 19, 2010, at 11:58 PM, Aaron Boodman wrote:

On Mon, Apr 19, 2010 at 5:53 PM, Peter Kasting pkast...@google.com  
wrote:
On Thu, Apr 15, 2010 at 3:41 PM, Aaron Boodman a...@chromium.org  
wrote:


I'm not sure what the path is for fetching favicons today. Does
WebCore just implicitly do it, or does it expose the information to
the host, who later may or may not make the request?


Answering this is complicated by the fact that Chromium mostly uses a
different codepath for all of this stuff than, say, Safari -- e.g. it
bypasses the IconDatabase and pretty much all other classes/files  
called

IconXXX entirely.


Yeah, I looked into this over the weekend, and -- shock! -- it turned
out to be a bigger change than I initially imagined. Since Chromium
has a different backend, that would mean implementing two sets of
changes.

Also, I think it would be wasteful to have WebKit download all linked
icons, even if the hosting browser has no intention of every using
some of them. So I'd want to add code to allow the browser to tell
WebKit which sizes it is interested in.

I still want to do this, but I'm going to have to reduce the priority
a little bit for now. I may come back to it in a month or so.


You'd probably want an API that lets the embedding app request a  
particular icon size, and picks the best fit from the icon links  
available, taking into account size=any as well. Possible niceties -  
return windows-style .ico or mac-style .icns either if explicitly  
specified, or synthesized from available sizes. Not sure if there is a  
conventional multisize icon format on other platforms.


Regards,
Maciej

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


Re: [webkit-dev] Fwd: CMake WebKit-EFL: initial preview

2010-04-20 Thread Patrick Roland Gansterer
Hi,

Gustavo Sverzut Barbieri:
 Find attached 2 patches.
 
 ? ?- WebKit-EFL-CMake_All-Missing-Patches.patch is a bundle that
 implements CMake support for WebKit-EFL and also adds the missing
 patches to make it compile (but runs with some bugs, needs updating to
 some api changes). Apply it if you want to compile the port (also get
 EFL from svn, see http://svn.enlightenment.org/)
 
 ? ?- WebKit-EFL-CMake.patch is just the CMake support, a single
 CMakeLists.txt and support *.cmake modules
 
 Please take a look if you are interested in CMake for WebKit-EFL.
 
 If you know CMake already, review it and send comments. My team just
 started with CMake some days ago.

Can you please post the patch at bugs.webkit.org.
Maybe you can split it into a CMake and a other stuff part. (Was it already 
before you merged it?)
I'd like to give you some feedback at the bug comments. The CMake file should 
be split into different projects for example.

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


Re: [webkit-dev] Where are bench-alloc-reatained.js and ~-nonretaned.js?

2010-04-20 Thread Balazs Kelemen
Thanks for the commit, Geoffrey! :-)

On 04/19/2010 02:44 PM, Balazs Kelemen wrote:
   Hi folks!

 I am doing some hacking around the GC, and want to test and benchmark it.
 In GC related changes I see results of these two benchmarks, but I do
 not find them in the tree.
 Are those living in the tree? If not, I think it would be useful to
 check-in them.

 Balazs Kelemen


   

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


Re: [webkit-dev] Where are bench-alloc-reatained.js and ~-nonretaned.js?

2010-04-20 Thread Balazs Kelemen
We investigating in multithreading possibilities. In connection with the
GC I try to organize the mark phase into a parallel thread.
The idea is to have 2 heap, serve allocations from the active one, while
marking the other. When the active is full, swap them.
Currently, it is in a non stable and non complete state, and it is not
100% that it will be ever complete.

On 04/19/2010 11:08 PM, Geoffrey Garen wrote:
 Hi Balazs.

 I just checked in those two tests to JavaScriptCore/tests/perf.

 What kind of GC hacking are you doing?

 Geoff

 On Apr 19, 2010, at 5:44 AM, Balazs Kelemen wrote:

   
  Hi folks!

 I am doing some hacking around the GC, and want to test and benchmark it.
 In GC related changes I see results of these two benchmarks, but I do
 not find them in the tree.
 Are those living in the tree? If not, I think it would be useful to
 check-in them.

 Balazs Kelemen

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

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


[webkit-dev] MD5 in WebCore

2010-04-20 Thread 鵜飼文敏
I'm implementing new protocol of WebSocket (
http://www.whatwg.org/specs/web-socket-protocol/ ).
Since it now requires MD5 in handshake, I wonder how I could add MD5 in
WebCore.  For now, there is no MD5 in WebCore.  It is in
WebKitTools/DumpRenderTree to get message digest of image file.

I'm thinking to add new header file as WebCore/platform/MD5.h, which
provides the following functions.

  struct MD5_CTX;
  void MD5_Init(MD5_CTX*);
  void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
  void MD5_Final(unsigned char hash[16], MD5_CTX*);

In Windows platform, it is implemented using Cryptdll.dll.   Is it ok to
copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/platform/win/MD5.cpp,
or move?
In Mac platform, it is provided by CommonCrypto/CommonDigest.h with
#define COMMON_DIGEST_FOR_OPENSSL ?
In Chromium, there is chrome/src/base/md5.{h,cc}.   Should I copy this in
WebCore/platform/chromium, or add dependency to base from WebCore?
How about other ports?  is it ok to link openssl or some other library?  (or
use implementation used in chromium?)

I'm also wonder I need to put these functions in namespace WebCore.

Thanks in advance,
ukai
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] MD5 in WebCore

2010-04-20 Thread Maciej Stachowiak


On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:

I'm implementing new protocol of WebSocket ( http://www.whatwg.org/specs/web-socket-protocol/ 
 ).
Since it now requires MD5 in handshake, I wonder how I could add MD5  
in WebCore.  For now, there is no MD5 in WebCore.  It is in  
WebKitTools/DumpRenderTree to get message digest of image file.


I'm thinking to add new header file as WebCore/platform/MD5.h, which  
provides the following functions.


  struct MD5_CTX;
  void MD5_Init(MD5_CTX*);
  void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
  void MD5_Final(unsigned char hash[16], MD5_CTX*);

In Windows platform, it is implemented using Cryptdll.dll.   Is it  
ok to copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/ 
platform/win/MD5.cpp, or move?
In Mac platform, it is provided by CommonCrypto/CommonDigest.h  
with #define COMMON_DIGEST_FOR_OPENSSL ?
In Chromium, there is chrome/src/base/md5.{h,cc}.   Should I copy  
this in WebCore/platform/chromium, or add dependency to base from  
WebCore?
How about other ports?  is it ok to link openssl or some other  
library?  (or use implementation used in chromium?)


I'm also wonder I need to put these functions in namespace WebCore.


If you put this code in WebCore, it should go in the WebCore  
namespace. I think it would also be a good idea to turn the API into  
something more WebCore-ish, something like:


namespace WebCore {

class MD5 {
MD5(); // what was MD5_Init
addBytes(uint8_t* input, size_t length); // what was  
MD5_Update ; or maybe this should take a Vectoruint8_t?

Vectoruint8_t, 16 checksum(); // what was MD5_Final
};
}

(The key point being to match the coding style guidelines for names,  
but it also seems better to use a class here instead of a struct and  
functions that take a pointer to it.)


Regards,
Maciej

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


Re: [webkit-dev] CMake vs. Apple's build farm

2010-04-20 Thread Bill Hoffman

On 4/20/2010 5:13 AM, Maciej Stachowiak wrote:


1) None of the Mac builders have CMake installed.
2) The organization that maintains the Mac builders is not willing to
let teams use any build systems to build that do not come with the OS,
or to install any custom binaries on the builders, because builds need
to be reproducible.
So, long term is there a way for CMake to come with the OS?  I mean 
gmake is part of the OS, python seems to be OK, how does a tool get 
promoted to such a level?



3) CMake is not part of the standard Mac OS X install for any shipping
version of Mac OS X.
4) LLVM compiles using a separate Makefile-based (and apparently
autoconf and autogen based) build system in OS builds.
5) LLVM uses CMake to build on Windows.
6) The build organization is more willing to install custom tools on
Windows builders.

I think this rules out using CMake to build the mac port. Even if we got
it set up, we'd need to maintain some kind of parallel build system for
production builds via the build farm, which would negate the benefit. It
might be possible to use CMake for Apple's Windows port, but if we
switch away from native project formats at all, ideally we'd like to
switch both ports to the same build system.
I am wondering if you could include the sources to CMake inside the 
source tree for the Mac build farms.  CMake really only depends on the 
C++ compiler, and that is part of the OS.  You could use CMake's 
bootstrap script to build it.   Then run that CMake to generate the 
build.  I could help you create a lean CMake that would only build the 
features used for the build of WebKit.


Since gyp does not require any special software to be installed merely
to build, it seems like a more plausible option at the moment.




Note: this is not to hate on CMake, I just don't want to end up in a
position where we have to maintain two parallel build systems for the
Mac port, or fight with other organizations about the operation of the
build farm. Requiring CMake to be installed at build time seems like a
showstopper from that point of view.

So, rather than install one program, Apple would rather have one of its 
developers maintain a forked build system.  I would of course like to 
see this change.   I would think it would be possible to change this. I 
suppose if enough tools that Apple uses move to CMake, it would become 
OK.  Anyway, what do think about building CMake with the project?


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


Re: [webkit-dev] Fwd: CMake WebKit-EFL: initial preview

2010-04-20 Thread Gustavo Sverzut Barbieri
On Mon, Apr 19, 2010 at 11:34 PM, Patrick Roland Gansterer
par...@paroga.com wrote:
 Hi,

 Gustavo Sverzut Barbieri:
 Find attached 2 patches.

 ? ?- WebKit-EFL-CMake_All-Missing-Patches.patch is a bundle that
 implements CMake support for WebKit-EFL and also adds the missing
 patches to make it compile (but runs with some bugs, needs updating to
 some api changes). Apply it if you want to compile the port (also get
 EFL from svn, see http://svn.enlightenment.org/)

 ? ?- WebKit-EFL-CMake.patch is just the CMake support, a single
 CMakeLists.txt and support *.cmake modules

 Please take a look if you are interested in CMake for WebKit-EFL.

 If you know CMake already, review it and send comments. My team just
 started with CMake some days ago.

 Can you please post the patch at bugs.webkit.org.

will do as soon as we get the .pc generated and installed, otherwise
the external programs cannot know how to link to it.


 Maybe you can split it into a CMake and a other stuff part. (Was it already
 before you merged it?)

It is already, the patch is at
http://people.profusion.mobi/~gustavo/WebKit-EFL-CMake.patch


 I'd like to give you some feedback at the bug comments. The CMake file should
 be split into different projects for example.

Hum... I saw everywhere that it was common to split in multiple
directories, particularly for JavaScriptCore and WebCore. But given
that I wanted to keep it simple, I forced it to be one single file to
make merge into SVN easier. I was also worried about the propagation
of settings and flags to the sub-folders. But yes, I notice that it
will make easier to use INCLUDE_DIRECTORIES() as we'd just have one
target per directory.

Our primary goal is not to join into the recent GYP x CMAKE
discussion, but we need our EFL port fully landed to avoid the
overhead we're doing now. We were using the GTK autotools, as we were
more familiar with it, but given it is slow and messy, the GTK guys
did not want to merge our patches right away, requesting a cleanup of
existing code first. We did part of the cleanup and CMake in parallel,
but CMake worked out quite nice and we don't plan to use GTK's
autotools anymore (but we did send the cleanup we achieved until now).
   That is to say that making it simple to be merged is our first aim.

One more thing I'd like to kindly ask you is if you can also post
patches to the CMake files. This is because our team is already
suffering to match the latest WeKit changes (we have already a huge
queue waiting to be merged, and now patches have to be rebased and so
on). So the more help, the better! :-)

BR,

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Fwd: CMake WebKit-EFL: initial preview

2010-04-20 Thread Adam Treat
I'd really like to see this on bugs.webkit.org with a proper patch splitting 
out the CMake portion.  I understand that this is primarily motivated by your 
desire to see EFL port build, rather than to solve the build system problem, 
but this *DOES* add a new build system to the tree.  I think we have to see if 
we can get the Apple showstopper cleared up.  I think installing CMake sources 
and getting Bill's help to create a streamlined CMake binary is a great idea.

Adam

On Tuesday 20 April 2010 08:29:55 am Gustavo Sverzut Barbieri wrote:
 On Mon, Apr 19, 2010 at 11:34 PM, Patrick Roland Gansterer
 
 par...@paroga.com wrote:
  Hi,
  
  Gustavo Sverzut Barbieri:
  Find attached 2 patches.
  
  ? ?- WebKit-EFL-CMake_All-Missing-Patches.patch is a bundle that
  implements CMake support for WebKit-EFL and also adds the missing
  patches to make it compile (but runs with some bugs, needs updating to
  some api changes). Apply it if you want to compile the port (also get
  EFL from svn, see http://svn.enlightenment.org/)
  
  ? ?- WebKit-EFL-CMake.patch is just the CMake support, a single
  CMakeLists.txt and support *.cmake modules
  
  Please take a look if you are interested in CMake for WebKit-EFL.
  
  If you know CMake already, review it and send comments. My team just
  started with CMake some days ago.
  
  Can you please post the patch at bugs.webkit.org.
 
 will do as soon as we get the .pc generated and installed, otherwise
 the external programs cannot know how to link to it.
 
  Maybe you can split it into a CMake and a other stuff part. (Was it
  already before you merged it?)
 
 It is already, the patch is at
 http://people.profusion.mobi/~gustavo/WebKit-EFL-CMake.patch
 
  I'd like to give you some feedback at the bug comments. The CMake file
  should be split into different projects for example.
 
 Hum... I saw everywhere that it was common to split in multiple
 directories, particularly for JavaScriptCore and WebCore. But given
 that I wanted to keep it simple, I forced it to be one single file to
 make merge into SVN easier. I was also worried about the propagation
 of settings and flags to the sub-folders. But yes, I notice that it
 will make easier to use INCLUDE_DIRECTORIES() as we'd just have one
 target per directory.
 
 Our primary goal is not to join into the recent GYP x CMAKE
 discussion, but we need our EFL port fully landed to avoid the
 overhead we're doing now. We were using the GTK autotools, as we were
 more familiar with it, but given it is slow and messy, the GTK guys
 did not want to merge our patches right away, requesting a cleanup of
 existing code first. We did part of the cleanup and CMake in parallel,
 but CMake worked out quite nice and we don't plan to use GTK's
 autotools anymore (but we did send the cleanup we achieved until now).
That is to say that making it simple to be merged is our first aim.
 
 One more thing I'd like to kindly ask you is if you can also post
 patches to the CMake files. This is because our team is already
 suffering to match the latest WeKit changes (we have already a huge
 queue waiting to be merged, and now patches have to be rebased and so
 on). So the more help, the better! :-)
 
 BR,
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] CMake vs. Apple's build farm

2010-04-20 Thread Bradley Nelson
Would prebuilt checked-in binaries be an option? Can cmake run out of an
arbitrary directory?

-BradN

On Tue, Apr 20, 2010 at 5:25 AM, Bill Hoffman bill.hoff...@kitware.comwrote:

 On 4/20/2010 5:13 AM, Maciej Stachowiak wrote:

  1) None of the Mac builders have CMake installed.
 2) The organization that maintains the Mac builders is not willing to
 let teams use any build systems to build that do not come with the OS,
 or to install any custom binaries on the builders, because builds need
 to be reproducible.

 So, long term is there a way for CMake to come with the OS?  I mean gmake
 is part of the OS, python seems to be OK, how does a tool get promoted to
 such a level?


  3) CMake is not part of the standard Mac OS X install for any shipping
 version of Mac OS X.
 4) LLVM compiles using a separate Makefile-based (and apparently
 autoconf and autogen based) build system in OS builds.
 5) LLVM uses CMake to build on Windows.
 6) The build organization is more willing to install custom tools on
 Windows builders.

 I think this rules out using CMake to build the mac port. Even if we got
 it set up, we'd need to maintain some kind of parallel build system for
 production builds via the build farm, which would negate the benefit. It
 might be possible to use CMake for Apple's Windows port, but if we
 switch away from native project formats at all, ideally we'd like to
 switch both ports to the same build system.

 I am wondering if you could include the sources to CMake inside the source
 tree for the Mac build farms.  CMake really only depends on the C++
 compiler, and that is part of the OS.  You could use CMake's bootstrap
 script to build it.   Then run that CMake to generate the build.  I could
 help you create a lean CMake that would only build the features used for the
 build of WebKit.


 Since gyp does not require any special software to be installed merely
 to build, it seems like a more plausible option at the moment.


  Note: this is not to hate on CMake, I just don't want to end up in a
 position where we have to maintain two parallel build systems for the
 Mac port, or fight with other organizations about the operation of the
 build farm. Requiring CMake to be installed at build time seems like a
 showstopper from that point of view.

  So, rather than install one program, Apple would rather have one of its
 developers maintain a forked build system.  I would of course like to see
 this change.   I would think it would be possible to change this. I suppose
 if enough tools that Apple uses move to CMake, it would become OK.  Anyway,
 what do think about building CMake with the project?

 -Bill

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

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


Re: [webkit-dev] CMake vs. Apple's build farm

2010-04-20 Thread Darin Adler
On Apr 20, 2010, at 10:06 AM, Bradley Nelson wrote:

 Would prebuilt checked-in binaries be an option?

No.

-- Darin

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


Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5

2010-04-20 Thread Stephan Assmus
Hi,

Darin Adler wrote:
 On Apr 15, 2010, at 3:41 PM, Aaron Boodman wrote:
  On Thu, Apr 15, 2010 at 3:25 PM, Maciej Stachowiak m...@apple.com
 wrote:
  Well, it's hard to truly have consensus on adding feature without
 knowing what it is. That being said, I at least would love to see a more
 specific proposal for what we could do with link size.
  
  I want to support bigger icons for the tabs in Chromium.
  
  I'm not sure what the path is for fetching favicons today.
 
 To load an icon you call retainIconForPageURL and then later call
 iconForPageURL once the icon is loaded. The iconForPageURL function takes an
 IntSize.
 
 But if you look at IconRecord.cpp you will see that at the moment the size
 isn’t yet used.

Indeed. The method can return a BitmapImage instance, which may contain several 
bitmaps of different size. In the Haiku port, I've temporarily made some useful 
BitmapImage methods public, to iterate over all images contained in the object 
and find the one with the size I want (in the browser code later on). Is there 
a better way to do this? How do other browser projects handle this? Would a 
patch to make some BitmapImage methods public have good chances of being 
accepted or is there another vision?

Best regards,
-Stephan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] CMake as a build system?

2010-04-20 Thread Peter Kasting
On Tue, Apr 20, 2010 at 1:26 AM, Patrick Roland Gansterer par...@paroga.com
 wrote:

 Bradley Nelson:
  1. Ability to incrementally transition on Windows. It took us about 6
   months to switch fully to gyp. Previous attempts to move to scons had
   taken a long time and failed, due to the requirement to transition while
   in flight. For a substantial period of time, we had a hybrid of checked
 in
   vcproj and gyp generated
 CMake should be treated like a separate buildsystem like qmake or gyp
 during a
 possible switch.


The point was that we wanted to be able to switch over in a gradual fashion,
not by constructing a complete, functional parallel build system and then
throwing the switch.

If you take a look in the current vcprojs you can't understand them more
 easy
 than compared to CMake IMHO.
 Anyway: How often do you look at these settings? I use the IDE only for
 writing code and debugging. I do all my buildsystem changes directly in the
 CMake files. If i see the source files in the IDE I'm already happy. Do you
 have other requirements?


AIUI, readability isn't the issue, it's the ability for e.g. Visual Studio
to correctly understand dependencies itself so that incremental builds from
inside the IDE (which is where most Windows Chromium developers do their
builds) work correctly and are as fast as possible (e.g. the null build
should take close to zero time and not have to rerun steps or relink
executables).

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


Re: [webkit-dev] CMake as a build system?

2010-04-20 Thread paroga
On Tue, 20 Apr 2010 10:53:55 -0700, Peter Kasting pkast...@google.com
wrote:
 AIUI, readability isn't the issue, it's the ability for e.g. Visual
Studio
 to correctly understand dependencies itself so that incremental builds
from
 inside the IDE (which is where most Windows Chromium developers do their
 builds) work correctly and are as fast as possible (e.g. the null build
 should take close to zero time and not have to rerun steps or relink
 executables).
I have an other big project running with CMake, but I didn't see such a
problem.
When you declare the correct dependencies CMake does a nerly perfect job
IMHO.
No rebuild time when nothing changed and no outdated objectfiles.

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


Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5

2010-04-20 Thread Peter Kasting
On Tue, Apr 20, 2010 at 10:48 AM, Stephan Assmus supersti...@gmx.de wrote:

 In the Haiku port, I've temporarily made some useful BitmapImage methods
 public, to iterate over all images contained in the object and find the one
 with the size I want (in the browser code later on). Is there a better way
 to do this? How do other browser projects handle this? Would a patch to make
 some BitmapImage methods public have good chances of being accepted or is
 there another vision?


In Chromium, we use ImageSource instead of BitmapImage for this, because
ImageSource already has public functions for everything you want (e.g.
frameCount(), frameSizeAtIndex(), etc.), and thus no changes are needed.
 When we have some data blob that represents the favicon and we need to pick
a good image (size) out of it, we just instantiate an ImageSource directly.
 Take a look at WebImage::fromData() in
http://trac.webkit.org/browser/trunk/WebKit/chromium/src/WebImageSkia.cpp .

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


Re: [webkit-dev] MD5 in WebCore

2010-04-20 Thread Michael Nordman
In webcore, should we use the same impl on all platforms rather than use
cryptdll on windows and md5.cc elsewhere?

For chrome, I don't think we can have a dependency between
WebKit/WebKit/chromium and /src/base/, and 'base' depending on 'webkit' also
doesn't work. How can we avoid replicating the code? I guess having
webcore's MD5 be platform specific could help us along those lines?


On Tue, Apr 20, 2010 at 4:12 AM, Maciej Stachowiak m...@apple.com wrote:


 On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:

 I'm implementing new protocol of WebSocket (
 http://www.whatwg.org/specs/web-socket-protocol/ ).
 Since it now requires MD5 in handshake, I wonder how I could add MD5 in
 WebCore.  For now, there is no MD5 in WebCore.  It is in
 WebKitTools/DumpRenderTree to get message digest of image file.

 I'm thinking to add new header file as WebCore/platform/MD5.h, which
 provides the following functions.

   struct MD5_CTX;
   void MD5_Init(MD5_CTX*);
   void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
   void MD5_Final(unsigned char hash[16], MD5_CTX*);

 In Windows platform, it is implemented using Cryptdll.dll.   Is it ok to
 copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/platform/win/MD5.cpp,
 or move?
 In Mac platform, it is provided by CommonCrypto/CommonDigest.h with
 #define COMMON_DIGEST_FOR_OPENSSL ?
 In Chromium, there is chrome/src/base/md5.{h,cc}.   Should I copy this in
 WebCore/platform/chromium, or add dependency to base from WebCore?
 How about other ports?  is it ok to link openssl or some other library?
  (or use implementation used in chromium?)

 I'm also wonder I need to put these functions in namespace WebCore.


 If you put this code in WebCore, it should go in the WebCore namespace. I
 think it would also be a good idea to turn the API into something more
 WebCore-ish, something like:

 namespace WebCore {

 class MD5 {
 MD5(); // what was MD5_Init
 addBytes(uint8_t* input, size_t length); // what was MD5_Update ;
 or maybe this should take a Vectoruint8_t?
 Vectoruint8_t, 16 checksum(); // what was MD5_Final
 };
 }

 (The key point being to match the coding style guidelines for names, but it
 also seems better to use a class here instead of a struct and functions that
 take a pointer to it.)

 Regards,
 Maciej


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


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


Re: [webkit-dev] MD5 in WebCore

2010-04-20 Thread Alex Russell
Hate to ask a dumb question, but why MD5? Isn't it on its last legs as
a secure hash? New protocols should be avoiding it.

On Tue, Apr 20, 2010 at 11:48 AM, Michael Nordman micha...@google.com wrote:
 In webcore, should we use the same impl on all platforms rather than use
 cryptdll on windows and md5.cc elsewhere?
 For chrome, I don't think we can have a dependency between
 WebKit/WebKit/chromium and /src/base/, and 'base' depending on 'webkit' also
 doesn't work. How can we avoid replicating the code? I guess having
 webcore's MD5 be platform specific could help us along those lines?

 On Tue, Apr 20, 2010 at 4:12 AM, Maciej Stachowiak m...@apple.com wrote:

 On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:

 I'm implementing new protocol of WebSocket
 ( http://www.whatwg.org/specs/web-socket-protocol/ ).
 Since it now requires MD5 in handshake, I wonder how I could add MD5 in
 WebCore.  For now, there is no MD5 in WebCore.  It is in
 WebKitTools/DumpRenderTree to get message digest of image file.
 I'm thinking to add new header file as WebCore/platform/MD5.h, which
 provides the following functions.
   struct MD5_CTX;
   void MD5_Init(MD5_CTX*);
   void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
   void MD5_Final(unsigned char hash[16], MD5_CTX*);
 In Windows platform, it is implemented using Cryptdll.dll.   Is it ok to
 copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/platform/win/MD5.cpp,
 or move?
 In Mac platform, it is provided by CommonCrypto/CommonDigest.h with
 #define COMMON_DIGEST_FOR_OPENSSL ?
 In Chromium, there is chrome/src/base/md5.{h,cc}.   Should I copy this in
 WebCore/platform/chromium, or add dependency to base from WebCore?
 How about other ports?  is it ok to link openssl or some other library?
  (or use implementation used in chromium?)
 I'm also wonder I need to put these functions in namespace WebCore.

 If you put this code in WebCore, it should go in the WebCore namespace. I
 think it would also be a good idea to turn the API into something more
 WebCore-ish, something like:
 namespace WebCore {
     class MD5 {
         MD5(); // what was MD5_Init
         addBytes(uint8_t* input, size_t length); // what was MD5_Update ;
 or maybe this should take a Vectoruint8_t?
         Vectoruint8_t, 16 checksum(); // what was MD5_Final
     };
 }
 (The key point being to match the coding style guidelines for names, but
 it also seems better to use a class here instead of a struct and functions
 that take a pointer to it.)
 Regards,
 Maciej

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



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


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


[webkit-dev] Warning: expect commit-queue delays

2010-04-20 Thread Eric Seidel
The commit-queue [1] is up to 28 patches (20 bugs) due to the tree
being red most of yesterday and all of last night.  It's green now and
landing things, but it will take it most of today to catch up.

Anything time-sensitive that you need landed should be landed manually. [2]

Sorry for the delay.  I'll let you know when we're back to normal.

-eric

1.  You can see the list of bugs here:
https://bugs.webkit.org/buglist.cgi?query_format=advancedbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDfield0-0-0=flagtypes.nametype0-0-0=equalsvalue0-0-0=commit-queue%2Border=Last+Changed

2. webkit-patch can help with manual landing:
webkit-patch land-from-bug BUGNUMBER (--build and --test optional)
or
webkit-patch land (--build and --test optional)
if you already have it in your tree.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] MD5 in WebCore

2010-04-20 Thread Jeremy Orlow
Agreed.  Can you give us a pointer to the email thread this decision was
made on?

On Tue, Apr 20, 2010 at 12:12 PM, Alex Russell slightly...@google.comwrote:

 Hate to ask a dumb question, but why MD5? Isn't it on its last legs as
 a secure hash? New protocols should be avoiding it.

 On Tue, Apr 20, 2010 at 11:48 AM, Michael Nordman micha...@google.com
 wrote:
  In webcore, should we use the same impl on all platforms rather than use
  cryptdll on windows and md5.cc elsewhere?
  For chrome, I don't think we can have a dependency between
  WebKit/WebKit/chromium and /src/base/, and 'base' depending on 'webkit'
 also
  doesn't work. How can we avoid replicating the code? I guess having
  webcore's MD5 be platform specific could help us along those lines?
 
  On Tue, Apr 20, 2010 at 4:12 AM, Maciej Stachowiak m...@apple.com
 wrote:
 
  On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
 
  I'm implementing new protocol of WebSocket
  ( http://www.whatwg.org/specs/web-socket-protocol/ ).
  Since it now requires MD5 in handshake, I wonder how I could add MD5 in
  WebCore.  For now, there is no MD5 in WebCore.  It is in
  WebKitTools/DumpRenderTree to get message digest of image file.
  I'm thinking to add new header file as WebCore/platform/MD5.h, which
  provides the following functions.
struct MD5_CTX;
void MD5_Init(MD5_CTX*);
void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
void MD5_Final(unsigned char hash[16], MD5_CTX*);
  In Windows platform, it is implemented using Cryptdll.dll.   Is it ok
 to
  copy WebKitTools/DumpRenderTree/win/MD5.cpp to
 WebCore/platform/win/MD5.cpp,
  or move?
  In Mac platform, it is provided by CommonCrypto/CommonDigest.h with
  #define COMMON_DIGEST_FOR_OPENSSL ?
  In Chromium, there is chrome/src/base/md5.{h,cc}.   Should I copy this
 in
  WebCore/platform/chromium, or add dependency to base from WebCore?
  How about other ports?  is it ok to link openssl or some other library?
   (or use implementation used in chromium?)
  I'm also wonder I need to put these functions in namespace WebCore.
 
  If you put this code in WebCore, it should go in the WebCore namespace.
 I
  think it would also be a good idea to turn the API into something more
  WebCore-ish, something like:
  namespace WebCore {
  class MD5 {
  MD5(); // what was MD5_Init
  addBytes(uint8_t* input, size_t length); // what was MD5_Update
 ;
  or maybe this should take a Vectoruint8_t?
  Vectoruint8_t, 16 checksum(); // what was MD5_Final
  };
  }
  (The key point being to match the coding style guidelines for names, but
  it also seems better to use a class here instead of a struct and
 functions
  that take a pointer to it.)
  Regards,
  Maciej
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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


Re: [webkit-dev] MD5 in WebCore

2010-04-20 Thread Maciej Stachowiak


On Apr 20, 2010, at 11:48 AM, Michael Nordman wrote:

In webcore, should we use the same impl on all platforms rather than  
use cryptdll on windows and md5.cc elsewhere?


For chrome, I don't think we can have a dependency between WebKit/ 
WebKit/chromium and /src/base/, and 'base' depending on 'webkit'  
also doesn't work. How can we avoid replicating the code? I guess  
having webcore's MD5 be platform specific could help us along those  
lines?


I'd rather use a platform-independent MD5 implementation in WebCore if  
possible.


Since the MD5 code itself has (presumably) minimal dependencies,  
perhaps we could put it in WTF. I don't know if that would help  
Chromium's dependency issues.


Regards,
Maciej




On Tue, Apr 20, 2010 at 4:12 AM, Maciej Stachowiak m...@apple.com  
wrote:


On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:

I'm implementing new protocol of WebSocket ( http://www.whatwg.org/specs/web-socket-protocol/ 
 ).
Since it now requires MD5 in handshake, I wonder how I could add  
MD5 in WebCore.  For now, there is no MD5 in WebCore.  It is in  
WebKitTools/DumpRenderTree to get message digest of image file.


I'm thinking to add new header file as WebCore/platform/MD5.h,  
which provides the following functions.


  struct MD5_CTX;
  void MD5_Init(MD5_CTX*);
  void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
  void MD5_Final(unsigned char hash[16], MD5_CTX*);

In Windows platform, it is implemented using Cryptdll.dll.   Is  
it ok to copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/ 
platform/win/MD5.cpp, or move?
In Mac platform, it is provided by CommonCrypto/CommonDigest.h  
with #define COMMON_DIGEST_FOR_OPENSSL ?
In Chromium, there is chrome/src/base/md5.{h,cc}.   Should I copy  
this in WebCore/platform/chromium, or add dependency to base from  
WebCore?
How about other ports?  is it ok to link openssl or some other  
library?  (or use implementation used in chromium?)


I'm also wonder I need to put these functions in namespace WebCore.


If you put this code in WebCore, it should go in the WebCore  
namespace. I think it would also be a good idea to turn the API into  
something more WebCore-ish, something like:


namespace WebCore {

class MD5 {
MD5(); // what was MD5_Init
addBytes(uint8_t* input, size_t length); // what was  
MD5_Update ; or maybe this should take a Vectoruint8_t?

Vectoruint8_t, 16 checksum(); // what was MD5_Final
};
}

(The key point being to match the coding style guidelines for names,  
but it also seems better to use a class here instead of a struct and  
functions that take a pointer to it.)


Regards,
Maciej


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




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


Re: [webkit-dev] MD5 in WebCore

2010-04-20 Thread Maciej Stachowiak


On Apr 20, 2010, at 12:45 PM, Jeremy Orlow wrote:

Agreed.  Can you give us a pointer to the email thread this decision  
was made on?


Discussion was on the IETF hybi list (which is trying to standardize  
the WebSocket protocol). I encourage anyone in the WebKit community  
who is interested in WebSocket to join the hybi list: https://www.ietf.org/mailman/listinfo/hybi




On Tue, Apr 20, 2010 at 12:12 PM, Alex Russell  
slightly...@google.com wrote:

Hate to ask a dumb question, but why MD5? Isn't it on its last legs as
a secure hash? New protocols should be avoiding it.


In the case of WebSocket protocol, the hash doesn't need to be  
cryptographically secure. Forging the hash is not a consideration. To  
give a rough outline, the hash is used like this:


1) The browser sends a few pieces of information to the server  
(including the Origin, a string specifically identifying the WebSocket  
protocol, etc).

2) The server combines some of this info and computes a hash.
3) The hash is returned to the client, which verifies it.

Steps 2 and 3 are the ones that use MD5. The reason for this handshake  
is to defend against cross-protocol attacks. The server responds with  
information based on unique parts of the request, to avoid the  
likelihood that a response from a non-WebSocket server won't  
accidentally look like a valid handshake. A hash is used to reduce the  
risk that a server that just echoes back pieces of the response may  
look like a valid handshake respnse.


I don't believe a cryptographically secure hash is needed here, it  
could have been something as simple as CRC-32, for example. I think  
the reason to pick MD5 was that it's well known and widely available  
as a library for many popular programming languages.


Regards,
Maciej




On Tue, Apr 20, 2010 at 11:48 AM, Michael Nordman  
micha...@google.com wrote:
 In webcore, should we use the same impl on all platforms rather  
than use

 cryptdll on windows and md5.cc elsewhere?
 For chrome, I don't think we can have a dependency between
 WebKit/WebKit/chromium and /src/base/, and 'base' depending on  
'webkit' also

 doesn't work. How can we avoid replicating the code? I guess having
 webcore's MD5 be platform specific could help us along those lines?

 On Tue, Apr 20, 2010 at 4:12 AM, Maciej Stachowiak m...@apple.com  
wrote:


 On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:

 I'm implementing new protocol of WebSocket
 ( http://www.whatwg.org/specs/web-socket-protocol/ ).
 Since it now requires MD5 in handshake, I wonder how I could add  
MD5 in

 WebCore.  For now, there is no MD5 in WebCore.  It is in
 WebKitTools/DumpRenderTree to get message digest of image file.
 I'm thinking to add new header file as WebCore/platform/MD5.h,  
which

 provides the following functions.
   struct MD5_CTX;
   void MD5_Init(MD5_CTX*);
   void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
   void MD5_Final(unsigned char hash[16], MD5_CTX*);
 In Windows platform, it is implemented using Cryptdll.dll.   Is  
it ok to
 copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/platform/ 
win/MD5.cpp,

 or move?
 In Mac platform, it is provided by CommonCrypto/CommonDigest.h  
with

 #define COMMON_DIGEST_FOR_OPENSSL ?
 In Chromium, there is chrome/src/base/md5.{h,cc}.   Should I copy  
this in

 WebCore/platform/chromium, or add dependency to base from WebCore?
 How about other ports?  is it ok to link openssl or some other  
library?

  (or use implementation used in chromium?)
 I'm also wonder I need to put these functions in namespace WebCore.

 If you put this code in WebCore, it should go in the WebCore  
namespace. I
 think it would also be a good idea to turn the API into something  
more

 WebCore-ish, something like:
 namespace WebCore {
 class MD5 {
 MD5(); // what was MD5_Init
 addBytes(uint8_t* input, size_t length); // what was  
MD5_Update ;

 or maybe this should take a Vectoruint8_t?
 Vectoruint8_t, 16 checksum(); // what was MD5_Final
 };
 }
 (The key point being to match the coding style guidelines for  
names, but
 it also seems better to use a class here instead of a struct and  
functions

 that take a pointer to it.)
 Regards,
 Maciej

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



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


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

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


___
webkit-dev mailing list
webkit-dev@lists.webkit.org

[webkit-dev] Volcano

2010-04-20 Thread Eric Seidel
I should have asked sooner...

Are any folks stuck here after the WebKit conference due to the volcano?

If so, drop me a line.  I'd like to at least offer lunch and possibly
some in-person hack-time.

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


Re: [webkit-dev] Experimental new code reviews

2010-04-20 Thread Adam Barth
At the risk of inspiring friendly competition, I've turned Andrew's
demo into a patch:

https://bugs.webkit.org/show_bug.cgi?id=37886

Adam


On Tue, Apr 20, 2010 at 12:24 PM, Andrew Scherkus scher...@chromium.org wrote:
 Here's the prototype I made during the hackathon that simply uses a bunch of
 Javascript to make it easier to type up comments:
 http://ascherkus.appspot.com/bugzilla/index.html
 I'm not a WebKit reviewer, but from what I gathered during the session
 there's a lot of copying and pasting involved.  I focused on trying to fix
 that particular issue.
 Double click a line to add a comment.  Code context + comment gets appended
 into the patch comment box.  It's purely visual -- nothing gets persisted.
 Andrew
 On Mon, Apr 19, 2010 at 4:20 PM, Ojan Vafai o...@chromium.org wrote:

 I don't know if it's up anywhere. The other group's approach adds more
 directly upon the current review system. I don't think we need to choose one
 vs. another (at least not in the short term). Not that you were suggesting
 that.
 Ojan

 On Mon, Apr 19, 2010 at 4:06 PM, Adam Barth aba...@webkit.org wrote:

 +scherkus

 On Mon, Apr 19, 2010 at 4:01 PM, Maciej Stachowiak m...@apple.com wrote:
 
  I heard another group coded up a different approach to improving
  reviews -
  does anyone have a URL for that, so we can compare?
  Cheers,
  Maciej
 
  On Apr 19, 2010, at 3:35 PM, Ojan Vafai wrote:
 
  At the hackathon last Tuesday, a few of us put together mashup style
  rietveld integration with bugs.webkit.org. It currently requires a
  chrome
  extension. We'll integrate properly with bugzilla based on feedback if
  this
  seems to be a value add for the project.
 
  http://webkit-rietveld.googlecode.com/svn/trunk/chrome-extension/webkit-cr.crx
  You can try it out on the *last* attachment
  on https://bugs.webkit.org/show_bug.cgi?id=37531.
  You'll see another link next to each attachment labelled Fancy
  Review.
  This loads a page much like the current review page, but
  with wkrietveld.appspot.com in the top frame (wkrietveld is our fork of
  rietveld). You can then make comments in rietveld. When you click the
  submit
  button, the comments are published *both* in Reitveld and
  to bugs.webkit.org.
  We do not intend to remove the old code review system for people who
  prefer
  to stick to that.
 
  Known issues:
  -Currently, only works with patches that are uploaded using
  webkit-patch
  upload --fancy-review.
  -Due to using a chrome extension rather than a tighter integration,
  some
  things are a bit janky (e.g. the initial load).
  -Each time a patch is uploaded, it currently creates a new rietveld
  issue.
  Ojan ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 



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


Re: [webkit-dev] Volcano

2010-04-20 Thread Philippe Normand
Hi,

I'm stuck in SF until sunday, unless I can find a flight earlier...
Hacking from a café there on some GTK fullscreen video support :)

Philippe

On Tue, 2010-04-20 at 13:19 -0700, Eric Seidel wrote:
 I should have asked sooner...
 
 Are any folks stuck here after the WebKit conference due to the volcano?
 
 If so, drop me a line.  I'd like to at least offer lunch and possibly
 some in-person hack-time.
 
 -eric
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 



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] Volcano

2010-04-20 Thread Evan Martin
I am down for a post-gathering SF hackathon.  Name a cafe and time.  :)

On Tue, Apr 20, 2010 at 2:00 PM, Philippe Normand pnorm...@igalia.com wrote:
 Hi,

 I'm stuck in SF until sunday, unless I can find a flight earlier...
 Hacking from a café there on some GTK fullscreen video support :)

 Philippe

 On Tue, 2010-04-20 at 13:19 -0700, Eric Seidel wrote:
 I should have asked sooner...

 Are any folks stuck here after the WebKit conference due to the volcano?

 If so, drop me a line.  I'd like to at least offer lunch and possibly
 some in-person hack-time.

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



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


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


Re: [webkit-dev] Volcano

2010-04-20 Thread Philippe Normand
Currently in 1195 Oak st but it closes at 5pm. Eric suggested Cafe Abir
on 1300 Fulton st.

I have to go tomorrow afternoon to Sunnyvale for a meeting but in the
morning I should be in the Cafe Abir :)

I'm open to any suggestion anyway! Currently staying in Haight st around
#800, I'd prefer to stay around if possible.

Philippe

On Tue, 2010-04-20 at 14:37 -0700, Evan Martin wrote:
 I am down for a post-gathering SF hackathon.  Name a cafe and time.  :)
 
 On Tue, Apr 20, 2010 at 2:00 PM, Philippe Normand pnorm...@igalia.com wrote:
  Hi,
 
  I'm stuck in SF until sunday, unless I can find a flight earlier...
  Hacking from a café there on some GTK fullscreen video support :)
 
  Philippe
 
  On Tue, 2010-04-20 at 13:19 -0700, Eric Seidel wrote:
  I should have asked sooner...
 
  Are any folks stuck here after the WebKit conference due to the volcano?
 
  If so, drop me a line.  I'd like to at least offer lunch and possibly
  some in-person hack-time.
 
  -eric
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 



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] Leak in UIWebView?

2010-04-20 Thread Thomas Hauk
I've posted this question to devforums.apple.com as well as to Stack  
Overflow (go to http://stackoverflow.com/questions/2557964/uiwebview-leak-can-someone-confirm 
 to see it) and have not gotten any answer, so now I'm reaching out  
to webkit-dev for some help.


I am developing an iPhone application that contains embedded HTML  
resources. The following code leaks memory only on the device (at  
least 75% of the time) when I try to create a NSURLRequest for an HTML  
file in the application bundle. My base SDK is 3.1.2 (also tried with  
3.1.3), and I'm running this on a first-gen iPod Touch running 3.1.3.  
This does not leak in the Simulator. If I comment out the call to  
loadRequest: all is well.


NSString* resourcePath = [[NSBundle mainBundle] resourcePath];
NSString* filePath = [[resourcePath  
stringByAppendingPathComponent:@html]

   stringByAppendingPathComponent:@dummy.html];
NSURL* url = [[NSURL alloc] initFileURLWithPath:filePath];
NSURLRequest* request = [NSURLRequest requestWithURL:url]; // leak!
[browserView loadRequest:request];
[url release];

I can reproduce this leak in a freshly-generated Window-based or  
Navigation-based project, with essentially only the above code plus  
the addition of a UIWebView object in the generated xib. The stack  
trace for the leak seems to be entirely within the Apple side of  
things. The HTML file can be as simple as a file with the word test  
in it (i.e. it doesn't need to be valid HTML).


What am I doing wrong?

--
Thomas Hauk
Shaggy Frog Software
www.shaggyfrog.com

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


Re: [webkit-dev] Leak in UIWebView?

2010-04-20 Thread Simon Fraser

On Apr 20, 2010, at 3:35 PM, Thomas Hauk wrote:

 I've posted this question to devforums.apple.com as well as to Stack Overflow 
 (go to 
 http://stackoverflow.com/questions/2557964/uiwebview-leak-can-someone-confirm 
 to see it) and have not gotten any answer, so now I'm reaching out to 
 webkit-dev for some help.
 
 I am developing an iPhone application that contains embedded HTML resources. 
 The following code leaks memory only on the device (at least 75% of the time) 
 when I try to create a NSURLRequest for an HTML file in the application 
 bundle. My base SDK is 3.1.2 (also tried with 3.1.3), and I'm running this on 
 a first-gen iPod Touch running 3.1.3. This does not leak in the Simulator. If 
 I comment out the call to loadRequest: all is well.
 
 NSString* resourcePath = [[NSBundle mainBundle] resourcePath];
 NSString* filePath = [[resourcePath stringByAppendingPathComponent:@html]
   stringByAppendingPathComponent:@dummy.html];
 NSURL* url = [[NSURL alloc] initFileURLWithPath:filePath];
 NSURLRequest* request = [NSURLRequest requestWithURL:url]; // leak!
 [browserView loadRequest:request];
 [url release];
 
 I can reproduce this leak in a freshly-generated Window-based or 
 Navigation-based project, with essentially only the above code plus the 
 addition of a UIWebView object in the generated xib. The stack trace for the 
 leak seems to be entirely within the Apple side of things. The HTML file 
 can be as simple as a file with the word test in it (i.e. it doesn't need 
 to be valid HTML).
 
 What am I doing wrong?

Not filing this at http://bugreporter.apple.com :)

Simon

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