[webkit-dev] About Integrating JIT for ARM into QT Webkit(QTE4.5.2)?

[Wei Song]

Hi all,
Who know the situation of About Integrating JIT for ARM into QT
Webkit(QTE4.5.2)?
Had it done by Trolltech and it was based in SquirrelFish or
SquirrelFish Extreme, or others?

Thanks.

Wei Song
Mike Ditka   -
"If God had wanted man to play soccer, he wouldn't have given us arms."
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] About Integrating JIT for ARM into QT Webkit(QTE4.5.2)?

[Simon Hausmann]

On Monday 20 July 2009 ext Wei Song, wrote:
> Hi all,
> Who know the situation of About Integrating JIT for ARM into QT 
Webkit(QTE4.5.2)?
> Had it done by Trolltech and it was based in SquirrelFish or 
SquirrelFish Extreme, or others?

Qt 4.5 does not ship with a version of JavaScriptCore that has a JIT for ARM 
processors.


Simon


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] default font size in WebKit

[tonikitoo (Antonio Gomes)]

> If the font size is not specified in the HTML page, what is the default one
> used by webkit?

Haithem, (although i might be wrong) I believe different ports have
different default font sizes. Qt is 14, for example. iirc, windows is
18 ...

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

Re: [webkit-dev] Possibly bogus FrameLoader::originalRequest data

[tonikitoo (Antonio Gomes)]

Bug filed: https://bugs.webkit.org/show_bug.cgi?id=27444

On Fri, Jul 17, 2009 at 4:04 PM, tonikitoo (Antonio
Gomes) wrote:
> Answering myself, that could explain things :
>
> @FrameLoader.h
> (...)
>        // Document loaders for the three phases of frame loading.
> Note that while
>        // a new request is being loaded, the old document loader may
> still be referenced.
>        // E.g. while a new request is in the "policy" state, the old
> document loader may
>        // be consulted in particular as it makes sense to imply
> certain settings on the new loader.
>        RefPtr m_documentLoader;
>        RefPtr m_provisionalDocumentLoader;
>        RefPtr m_policyDocumentLoader;
> (...)
>
> please , could someone confirm ?
>
> On Fri, Jul 17, 2009 at 12:28 PM, tonikitoo (Antonio
> Gomes) wrote:
>> Hi. So I ran into this while developing a feature to qt webkit, but it
>> is possibly not a port specific issue, but webcore.
>>
>> 1) If i load an existent local page (through FrameLoader::load) that
>> redirects (e.g. file:///test1.html redirects to file:///test2.html) ,
>> i get
>>
>> FrameLoader::originalRequest.url() to point to test1.html
>> FrameLoader::request.url() to point to test2.html
>>
>> which seems to be the corrent behavior.
>>
>> 2) After that if i load another local but unexistent file (e.g.
>> file:///unexistent.html) i get:
>>
>> FrameLoader::originalRequest.url() *still* points to test1.html
>> (previous loaded URL)
>> FrameLoader::request.url() points to file:///unexistent.html
>>
>> whereas "originalRequest" pointing to a previous loaded url seems
>> clearly no right.  So, please correct if I am wrong, but
>> there should be a method resetind these data between this two load calls ?
>>
>> also if I skip 1) and go to 2) straigh I get:
>>
>> FrameLoader::originalRequest.url() as an empty URL
>> FrameLoader::request.url() to point to file:///unexistent.html
>>
>> Is that expected ? What data should originalRequest hold in these cases ?
>>
>> thanks
>>
>> --
>> --Antonio Gomes
>>
>
>
>
> --
> --Antonio Gomes
>



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

[webkit-dev] JS: Getter/Setter callbacks at Property level

[Brian Barnes]

I was getting ready to try the first move from SpiderMonkey to Nitro, 
and ran into a large problem.  Right now, all my getters and setters are 
at the property level.  In the documentation I have, Nitro only seems to 
put them at the object level.  This would force a huge refactoring of my 
code (which I'm willing to do if I have to, I would just like to avoid 
it as I have hundred or so objects.)


Is my documentation old, did I miss something, or am I stuck?  If I'm 
stuck, is there any call to have this put into Nitro at some time in the 
future?


[>] Brian


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

Re: [webkit-dev] JS: Getter/Setter callbacks at Property level

[Geoffrey Garen]

Hi Brian.

I don't understand the distinction you're drawing between "the  
property level" and "the object level". Can you explain what those  
mean and give an example of each?


Thanks,
Geoff

On Jul 20, 2009, at 9:14 AM, Brian Barnes wrote:

I was getting ready to try the first move from SpiderMonkey to  
Nitro, and ran into a large problem.  Right now, all my getters and  
setters are at the property level.  In the documentation I have,  
Nitro only seems to put them at the object level.  This would force  
a huge refactoring of my code (which I'm willing to do if I have to,  
I would just like to avoid it as I have hundred or so objects.)


Is my documentation old, did I miss something, or am I stuck?  If  
I'm stuck, is there any call to have this put into Nitro at some  
time in the future?


[>] Brian


___
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] JS: Getter/Setter callbacks at Property level

[Brian Barnes]

In SpiderMonkey, you can create an object, and that object has a 
callback to a getter or a setter in C.  You get the name, look it up, 
return or set a value.  Nitro has that same functionality.


On SpiderMonkey, though, when creating a property, you can also do this:

JS_DefineProperty(context,object,name,value,getter,setter,flags);

Where "getter" and "setter" are direct calls for the property, for only 
that property.  There's no lookup logic in my code.


So, in pseudo code, at object level, we'd have a single getter:

void getMyObjectValues( name ...)
{
  if (name == 'red') return(red)
  if (name == 'green') return(green)
  if (name == 'blue') return(blue)
}

And property level, we'd have 3 getters:

void getMyObjectRed(...)
{
 return(red);
}

void getMyObjectGreen(...)
{
 return(green);
}

void getMyObjectBlue(...)
{
 return(blue);
}

[>] Brian

Geoffrey Garen wrote:

Hi Brian.

I don't understand the distinction you're drawing between "the 
property level" and "the object level". Can you explain what those 
mean and give an example of each?


Thanks,
Geoff

On Jul 20, 2009, at 9:14 AM, Brian Barnes wrote:

I was getting ready to try the first move from SpiderMonkey to Nitro, 
and ran into a large problem.  Right now, all my getters and setters 
are at the property level.  In the documentation I have, Nitro only 
seems to put them at the object level.  This would force a huge 
refactoring of my code (which I'm willing to do if I have to, I would 
just like to avoid it as I have hundred or so objects.)


Is my documentation old, did I miss something, or am I stuck?  If I'm 
stuck, is there any call to have this put into Nitro at some time in 
the future?


[>] Brian


___
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] JS: Getter/Setter callbacks at Property level

[Geoffrey Garen]

Hi Brian.

I see what you mean now.

In JavaScriptCore, there's no API for defining C getters and setters  
individually. There's an API for associating a set of C getters and  
setters with a class, and there's an API for defining a generic  
fallback getter and setter for a class.


I looked briefly, and it seems like it would be relatively easy to add  
an API for adding C getters and setters to a class individually. So,  
that seems like a reasonable feature request.


I'm not sure how important it is to you to be able to add C getters  
and setters to objects, as opposed to classes, individually. I think  
that would be a trickier API to get right. The main challenge is that  
getters and setters of that dynamic nature tend to slow down the  
object system. So, we would either want to engineer a way to avoid the  
performance cost in most cases, or we would want to design a way to  
steer API users away from that particular API in the general case. If  
you have a good example of how this feature would be generally useful  
to API clients, it's still a reasonable request, though.


Geoff

On Jul 20, 2009, at 10:21 AM, Brian Barnes wrote:

In SpiderMonkey, you can create an object, and that object has a  
callback to a getter or a setter in C.  You get the name, look it  
up, return or set a value.  Nitro has that same functionality.


On SpiderMonkey, though, when creating a property, you can also do  
this:


JS_DefineProperty(context,object,name,value,getter,setter,flags);

Where "getter" and "setter" are direct calls for the property, for  
only that property.  There's no lookup logic in my code.


So, in pseudo code, at object level, we'd have a single getter:

void getMyObjectValues( name ...)
{
 if (name == 'red') return(red)
 if (name == 'green') return(green)
 if (name == 'blue') return(blue)
}

And property level, we'd have 3 getters:

void getMyObjectRed(...)
{
return(red);
}

void getMyObjectGreen(...)
{
return(green);
}

void getMyObjectBlue(...)
{
return(blue);
}

[>] Brian

Geoffrey Garen wrote:

Hi Brian.

I don't understand the distinction you're drawing between "the  
property level" and "the object level". Can you explain what those  
mean and give an example of each?


Thanks,
Geoff

On Jul 20, 2009, at 9:14 AM, Brian Barnes wrote:

I was getting ready to try the first move from SpiderMonkey to  
Nitro, and ran into a large problem.  Right now, all my getters  
and setters are at the property level.  In the documentation I  
have, Nitro only seems to put them at the object level.  This  
would force a huge refactoring of my code (which I'm willing to do  
if I have to, I would just like to avoid it as I have hundred or  
so objects.)


Is my documentation old, did I miss something, or am I stuck?  If  
I'm stuck, is there any call to have this put into Nitro at some  
time in the future?


[>] Brian


___
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] JS: Getter/Setter callbacks at Property level

[Brian Barnes]

I'm not sure you get exactly what I'm saying as you put class in places 
where I'd expect property.  For instance:


"
I looked briefly, and it seems like it would be relatively easy to add 
an API for adding C getters and setters to a class individually. So, 
that seems like a reasonable feature request. "


Replacing class with property is what I'd expect here, i.e., each 
property set on an object has it's own getter and setter.  Something like:


void 
JSObjectSetPropertyWithCallback(ctx,object,propertyName,value,getterFunction,setterFunction,attributres,exception);


Also I'm a little worried about the word "dynamic", these are definitely 
static.  I have all the functions created, you just have a pointer to 
them.  If the pointer exist, call it for the value and break out.  If it 
doesn't, go down the chain.  More pseudo code:


void main(...)
{
 obj=JSObjectMake(ctx,NULL,NULL);
 
JSObjectSetPropertyWithCallback(ctx,obj,"red",JSValueMakeNull(),myRedGetter,myRedSetter,attributes,exception);

}

JSValueRef myRedGetter(...ctx...object...exception)
{
 return(JSValueMakeNumber(red_value));
}

bool myRedSetter(..ctx..object..value..exception)
{
 red_value=JSValueToNumber(ctx,value,exception);
}

Here are the benefits (as I see them):

1) I don't need to define classes for objects; right now, the only 
reason I would need to create classes (instead of just passing NULL) is 
to setup the getters & setters.  This reduces workload and generalizes a 
lot of my code


2) The JS engine has already looked up the property by name; with class 
based getters/setters, I also have to lookup the property by name.  With 
property based getters/setters, it's only looked up once and directly 
called to me.  This should be a big savings win and should be more 
simple at the back end (if there's no getter/setter associated with a 
property, just skip forward down the chain.)


I'm not sure how this could be anything but faster then class-based.

[>] Brian

Geoffrey Garen wrote:

Hi Brian.

I see what you mean now.

In JavaScriptCore, there's no API for defining C getters and setters 
individually. There's an API for associating a set of C getters and 
setters with a class, and there's an API for defining a generic 
fallback getter and setter for a class.


I looked briefly, and it seems like it would be relatively easy to add 
an API for adding C getters and setters to a class individually. So, 
that seems like a reasonable feature request.


I'm not sure how important it is to you to be able to add C getters 
and setters to objects, as opposed to classes, individually. I think 
that would be a trickier API to get right. The main challenge is that 
getters and setters of that dynamic nature tend to slow down the 
object system. So, we would either want to engineer a way to avoid the 
performance cost in most cases, or we would want to design a way to 
steer API users away from that particular API in the general case. If 
you have a good example of how this feature would be generally useful 
to API clients, it's still a reasonable request, though.


Geoff

On Jul 20, 2009, at 10:21 AM, Brian Barnes wrote:

In SpiderMonkey, you can create an object, and that object has a 
callback to a getter or a setter in C.  You get the name, look it up, 
return or set a value.  Nitro has that same functionality.


On SpiderMonkey, though, when creating a property, you can also do this:

JS_DefineProperty(context,object,name,value,getter,setter,flags);

Where "getter" and "setter" are direct calls for the property, for 
only that property.  There's no lookup logic in my code.


So, in pseudo code, at object level, we'd have a single getter:

void getMyObjectValues( name ...)
{
 if (name == 'red') return(red)
 if (name == 'green') return(green)
 if (name == 'blue') return(blue)
}

And property level, we'd have 3 getters:

void getMyObjectRed(...)
{
return(red);
}

void getMyObjectGreen(...)
{
return(green);
}

void getMyObjectBlue(...)
{
return(blue);
}

[>] Brian

Geoffrey Garen wrote:

Hi Brian.

I don't understand the distinction you're drawing between "the 
property level" and "the object level". Can you explain what those 
mean and give an example of each?


Thanks,
Geoff

On Jul 20, 2009, at 9:14 AM, Brian Barnes wrote:

I was getting ready to try the first move from SpiderMonkey to 
Nitro, and ran into a large problem.  Right now, all my getters and 
setters are at the property level.  In the documentation I have, 
Nitro only seems to put them at the object level.  This would force 
a huge refactoring of my code (which I'm willing to do if I have 
to, I would just like to avoid it as I have hundred or so objects.)


Is my documentation old, did I miss something, or am I stuck?  If 
I'm stuck, is there any call to have this put into Nitro at some 
time in the future?


[>] Brian


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

Re: [webkit-dev] JS: Getter/Setter callbacks at Property level

[Oliver Hunt]

On Jul 20, 2009, at 11:48 AM, Brian Barnes wrote:

I'm not sure you get exactly what I'm saying as you put class in  
places where I'd expect property.  For instance:


"
I looked briefly, and it seems like it would be relatively easy to  
add an API for adding C getters and setters to a class individually.  
So, that seems like a reasonable feature request. "


Replacing class with property is what I'd expect here, i.e., each  
property set on an object has it's own getter and setter.  Something  
like:


void JSObjectSetPropertyWithCallback 
(ctx 
,object 
,propertyName 
,value,getterFunction,setterFunction,attributres,exception);


Also I'm a little worried about the word "dynamic", these are  
definitely static.  I have all the functions created, you just have  
a pointer to them.  If the pointer exist, call it for the value and  
break out.  If it doesn't, go down the chain.  More pseudo code:
From the point of view of the runtime any property with a getter/ 
setter is dynamic -- they can't be optimised.




void main(...)
{
obj=JSObjectMake(ctx,NULL,NULL);
JSObjectSetPropertyWithCallback(ctx,obj,"red",JSValueMakeNull 
(),myRedGetter,myRedSetter,attributes,exception);

}

JSValueRef myRedGetter(...ctx...object...exception)
{
return(JSValueMakeNumber(red_value));
}

bool myRedSetter(..ctx..object..value..exception)
{
red_value=JSValueToNumber(ctx,value,exception);
}

Here are the benefits (as I see them):

1) I don't need to define classes for objects; right now, the only  
reason I would need to create classes (instead of just passing NULL)  
is to setup the getters & setters.  This reduces workload and  
generalizes a lot of my code


However it takes more memory, the class based properties are  
effectively what are used for the DOM, eg. the getters and setters are  
defined on a prototype object that is shared among all instances of  
the class.




2) The JS engine has already looked up the property by name; with  
class based getters/setters, I also have to lookup the property by  
name.  With property based getters/setters, it's only looked up once  
and directly called to me.  This should be a big savings win and  
should be more simple at the back end (if there's no getter/setter  
associated with a property, just skip forward down the chain.)


I'm not sure how this could be anything but faster then class-based.
If you're using getters and setters you've already destroyed  
performance as getters and setters aren't optimisable so the  
additional cost is likely to be irrelevant.  Additionally the per- 
object instances of the getter/setter function is likely to increase  
memory usage and gc pressure, both of which could actually hurt  
performance.


Note: I'm not saying this isn't a reasonable feature request, i'm just  
trying to emphasise that getters/setters are expensive, and  
performance characteristics are hard to guess without actually  
measuring.


In the mean time you could work around this API deficiency by creating  
a function object and then manually calling __defineGetter__, etc to  
set up your getter/setter code.


--Oliver

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

Re: [webkit-dev] JS: Getter/Setter callbacks at Property level

[Geoffrey Garen]

I'm not sure you get exactly what I'm saying as you put class in  
places where I'd expect property.  For instance:


"
I looked briefly, and it seems like it would be relatively easy to  
add an API for adding C getters and setters to a class individually.  
So, that seems like a reasonable feature request. "


Replacing class with property is what I'd expect here, i.e., each  
property set on an object has it's own getter and setter.  Something  
like:


void  
JSObjectSetPropertyWithCallback 
(ctx 
,object 
,propertyName 
,value,getterFunction,setterFunction,attributres,exception);


What I was referring to when talking about classes was that  
JavaScriptCore has an API for defining classes, and an API for making  
JavaScript objects that instantiate those classes. Currently, that's  
how the API accommodates C getters and setters.


Also I'm a little worried about the word "dynamic", these are  
definitely static.  I have all the functions created, you just have  
a pointer to them.  If the pointer exist, call it for the value and  
break out.  If it doesn't, go down the chain.


What I meant by "dynamic" was that getters and setters that are not  
pre-defined as a part of a class are dynamically added to objects in  
an ad hoc manner, thereby defeating many optimizations in the object  
system.


It would be trivial for the object system to efficiently handle the  
instruction "add this getter / setter to all objects of this class."


It would be challenging, and require substantial design thinking, for  
the object system to efficiently handle thousands of instances of the  
instruction "add this getter / setter to this object."


1) I don't need to define classes for objects; right now, the only  
reason I would need to create classes (instead of just passing NULL)  
is to setup the getters & setters.  This reduces workload and  
generalizes a lot of my code


Indeed, it's a bit more code to create a class, add getters and  
setters to it, and then create an object with that class, than it  
would be to add getters and setters directly to an object. But I don't  
think it's a prohibitive increase in code -- do you?


2) The JS engine has already looked up the property by name; with  
class based getters/setters, I also have to lookup the property by  
name.  With property based getters/setters, it's only looked up once  
and directly called to me.  This should be a big savings win and  
should be more simple at the back end (if there's no getter/setter  
associated with a property, just skip forward down the chain.)


I don't understand the optimization you're describing here, but I can  
tell that, given the current design of JavaScriptCore, classes are  
more efficient than ad hoc properties.


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

[webkit-dev] svn-create-patch acting oddly lately

[Darin Adler]

My patches look like this now:

$ svn-create-patch
svn: Path '../..' ends in '..', which is unsupported for this operation
Index: ../../../../../Users/darin/Safari/OpenSource/WebKit/mac/WebView/ 
WebHTMLView.mm

===
--- ../../../../../Users/darin/Safari/OpenSource/WebKit/mac/WebView/ 
WebHTMLView.mm  (revision 46038)
+++ ../../../../../Users/darin/Safari/OpenSource/WebKit/mac/WebView/ 
WebHTMLView.mm  (working copy)

[...]
$

Yuck!

Do I need to file a bug about this?

-- Darin

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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Peter Kasting]

On Mon, Jul 20, 2009 at 1:28 PM, Darin Adler  wrote:

> My patches look like this now:
>
> $ svn-create-patch
> svn: Path '../..' ends in '..', which is unsupported for this operation


This warning was caused by a change of mine that I checked in a fix for at
noon on Friday.  It shouldn't still happen on an up-to-date
svn-create-patch.  If your svn-create-patch is at least r46054 and this is
happening, something is wrong.

Index:
> ../../../../../Users/darin/Safari/OpenSource/WebKit/mac/WebView/WebHTMLView.mm
> ===
> ---
> ../../../../../Users/darin/Safari/OpenSource/WebKit/mac/WebView/WebHTMLView.mm
>  (revision 46038)
> +++
> ../../../../../Users/darin/Safari/OpenSource/WebKit/mac/WebView/WebHTMLView.mm
>  (working copy)


This seems bad.  I haven't seen this locally but I could have caused it.  Is
there any svn repository for any of the directories above your WebKit
checkout?  If your checkout wasn't quite up-to-date above, does updating fix
this?

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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Peter Kasting]

On Mon, Jul 20, 2009 at 1:55 PM, Eric Seidel  wrote:

> It could also be from http://trac.webkit.org/changeset/45939.


Yes.  Knowing Darin's repository version would help narrow this down.

I am trying different things to see if I can reproduce locally.  Once I can
reproduce I will either fix the problem or back out the offending change
immediately.

If anyone else has this problem, and is up-to-date, please let me know here
or on IRC.  I would love to find out that this is in fact just a problem of
an out-of-date checkout but somehow I doubt it.

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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Adam Barth]

It's kind of sad that we have so many ways of finding the SVN root.
The code in that link isn't right.  You need to look at the UUID to
get the right answer.  See scm.py.

Adam


On Mon, Jul 20, 2009 at 1:59 PM, Peter Kasting wrote:
> On Mon, Jul 20, 2009 at 1:55 PM, Eric Seidel  wrote:
>>
>> It could also be from http://trac.webkit.org/changeset/45939.
>
> Yes.  Knowing Darin's repository version would help narrow this down.
> I am trying different things to see if I can reproduce locally.  Once I can
> reproduce I will either fix the problem or back out the offending change
> immediately.
> If anyone else has this problem, and is up-to-date, please let me know here
> or on IRC.  I would love to find out that this is in fact just a problem of
> an out-of-date checkout but somehow I doubt it.
> PK
> ___
> 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] svn-create-patch acting oddly lately

[Peter Kasting]

On Mon, Jul 20, 2009 at 2:03 PM, Adam Barth  wrote:

> It's kind of sad that we have so many ways of finding the SVN root.
> The code in that link isn't right.  You need to look at the UUID to
> get the right answer.  See scm.py.


My update made us look at the Repository Root field instead of looking at
the error code returned by svn info.  It seems like in practice this should
be as good as the Repository UUID field.  Or do you think I should change
it?

Also, if you and/or Darin were on IRC, I could ask this without annoying all
the other folks on webkit-dev@ :)

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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Joseph Pecoraro]

It's kind of sad that we have so many ways of finding the SVN root.
The code in that link isn't right.  You need to look at the UUID to
get the right answer.  See scm.py.


Yes, I saw scm.py's solution literally yesterday while I was learning  
how to use bugzilla-tool because I switched to git.  In any case the  
newer revision uses a much better approach then the one in this  
changelog (Repository Root) and ultimately the best approach would be  
using the UUID like you suggested.

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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Peter Kasting]

On Mon, Jul 20, 2009 at 2:11 PM, Joseph Pecoraro wrote:
>
> Yes, I saw scm.py's solution literally yesterday while I was learning how
> to use bugzilla-tool because I switched to git.  In any case the newer
> revision uses a much better approach then the one in this changelog
> (Repository Root) and ultimately the best approach would be using the UUID
> like you suggested.
>

I can switch svn-create-patch to using UUID if there are benefits over using
the Repository Root; it'd literally be a four-character change.

In the meantime, I've tried and failed to recreate Darin's problem locally,
so I'm at the mercy of other people to report that they're having this
problem.

In case it helps, the relevant bugs where svn-create-patch was changed seem
to be bug 26999 (source of the original change eseidel mentions) and bug
27323 (source of my updates to the recently-added root calculation code).

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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Darin Adler]

On Jul 20, 2009, at 1:38 PM, Peter Kasting wrote:


On Mon, Jul 20, 2009 at 1:28 PM, Darin Adler  wrote:
svn: Path '../..' ends in '..', which is unsupported for this  
operation


This warning was caused by a change of mine that I checked in a fix  
for at noon on Friday.  It shouldn't still happen on an up-to-date  
svn-create-patch.  If your svn-create-patch is at least r46054 and  
this is happening, something is wrong.


I updated and indeed the new version no longer gives this warning.

Index: ../../../../../Users/darin/Safari/OpenSource/WebKit/mac/ 
WebView/WebHTMLView.mm

===
--- ../../../../../Users/darin/Safari/OpenSource/WebKit/mac/WebView/ 
WebHTMLView.mm  (revision 46038)
+++ ../../../../../Users/darin/Safari/OpenSource/WebKit/mac/WebView/ 
WebHTMLView.mm  (working copy)


This seems bad.  I haven't seen this locally but I could have caused  
it. Is there any svn repository for any of the directories above  
your WebKit checkout?


No.

If your checkout wasn't quite up-to-date above, does updating fix  
this?


No.

-- Darin

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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Darin Adler]

On Jul 20, 2009, at 2:17 PM, Peter Kasting wrote:

In the meantime, I've tried and failed to recreate Darin's problem  
locally, so I'm at the mercy of other people to report that they're  
having this problem.


The key here is that "/Users/darin" is a symbolic link to "/Volumes/ 
Home/darin" — you can probably reproduce this by putting the checkout  
directory inside a symbolic link.


In determineSvnRoot(), $last is ".." and then $svnRoot ends up as "/ 
Users/darin/Safari/OpenSource/WebKit/..", which seems bad. Is rel2abs  
supposed to handle that?


In chdirAndGetDifference(), before is "/Users/darin/Safari/OpenSource/ 
WebKit" and after is "/Volumes/Home/darin/Safari/OpenSource".


-- Darin

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

Re: [webkit-dev] JS: Getter/Setter callbacks at Property level

[Brian Barnes]

How about separate call backs at the class level?  That would solve my  
problem with minimal code movement.  Something like:


JSClassSetPropertyGetterSetter(ctx,class,"red",myRedGetter,myRedSetter);

Would that be more within the design?

BTW, thanks for listening and leading me through some things.  I'm  
basically just asking for an API to save me trouble (though other  
engines have it, so it's not outside the realm) -- and you guys paying  
attention and talking me through things I don't know is very helpful.


[>] Brian


On Jul 20, 2009, at 4:27 PM, Geoffrey Garen wrote:

I'm not sure you get exactly what I'm saying as you put class in  
places where I'd expect property.  For instance:


"
I looked briefly, and it seems like it would be relatively easy to  
add an API for adding C getters and setters to a class  
individually. So, that seems like a reasonable feature request. "


Replacing class with property is what I'd expect here, i.e., each  
property set on an object has it's own getter and setter.   
Something like:


void  
JSObjectSetPropertyWithCallback 
(ctx 
,object 
,propertyName 
,value,getterFunction,setterFunction,attributres,exception);


What I was referring to when talking about classes was that  
JavaScriptCore has an API for defining classes, and an API for  
making JavaScript objects that instantiate those classes. Currently,  
that's how the API accommodates C getters and setters.


Also I'm a little worried about the word "dynamic", these are  
definitely static.  I have all the functions created, you just have  
a pointer to them.  If the pointer exist, call it for the value and  
break out.  If it doesn't, go down the chain.


What I meant by "dynamic" was that getters and setters that are not  
pre-defined as a part of a class are dynamically added to objects in  
an ad hoc manner, thereby defeating many optimizations in the object  
system.


It would be trivial for the object system to efficiently handle the  
instruction "add this getter / setter to all objects of this class."


It would be challenging, and require substantial design thinking,  
for the object system to efficiently handle thousands of instances  
of the instruction "add this getter / setter to this object."


1) I don't need to define classes for objects; right now, the only  
reason I would need to create classes (instead of just passing  
NULL) is to setup the getters & setters.  This reduces workload and  
generalizes a lot of my code


Indeed, it's a bit more code to create a class, add getters and  
setters to it, and then create an object with that class, than it  
would be to add getters and setters directly to an object. But I  
don't think it's a prohibitive increase in code -- do you?


2) The JS engine has already looked up the property by name; with  
class based getters/setters, I also have to lookup the property by  
name.  With property based getters/setters, it's only looked up  
once and directly called to me.  This should be a big savings win  
and should be more simple at the back end (if there's no getter/ 
setter associated with a property, just skip forward down the chain.)


I don't understand the optimization you're describing here, but I  
can tell that, given the current design of JavaScriptCore, classes  
are more efficient than ad hoc properties.


Geoff


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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Peter Kasting]

On Mon, Jul 20, 2009 at 2:24 PM, Darin Adler  wrote:

> The key here is that "/Users/darin" is a symbolic link to
> "/Volumes/Home/darin" — you can probably reproduce this by putting the
> checkout directory inside a symbolic link.
>

Doesn't help on my Windows box at least... all my checkouts are rooted at
symbolic links.

 In determineSvnRoot(), $last is ".." and then $svnRoot ends up as
> "/Users/darin/Safari/OpenSource/WebKit/..", which seems bad. Is rel2abs
> supposed to handle that?


Not sure.  JoePeck and I have talked some on IRC since this code was from
his patch.  He says he's encountered rel2abs() behaving differently on
different systems.  I know so little about Perl that I'm not sure what to do
with that info.

In chdirAndGetDifference(), before is
> "/Users/darin/Safari/OpenSource/WebKit" and after is
> "/Volumes/Home/darin/Safari/OpenSource".


That's definitely bad, and seems like the source of this issue.

It looks from here like the chdir call is causing curdir() to report the
non-symbolic-link form of things.  If that's true, it seems like this
workaround would work:

...
my ($newdir) = @_;
my $before = File::Spec->rel2abs( File::Spec->curdir() );
+ chdir $before;  # Try and force curdir() to report the directory without
symbolic links.
+ $before = File::Spec->rel2abs( File::Spec->curdir() );
chdir $newdir;
my $after = File::Spec->rel2abs( File::Spec->curdir() );
...

Could you try this and see if it works?

Also, any Perl hackers are welcome to chip in here on how the current code
should be improved.  I just looked up docs on the File::Spec module and saw
them mentioning something about realpath() that might be relevant here...

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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Darin Adler]

On Jul 20, 2009, at 2:40 PM, Peter Kasting wrote:

It looks from here like the chdir call is causing curdir() to report  
the non-symbolic-link form of things.  If that's true, it seems like  
this workaround would work:


Makes sense.


...
my ($newdir) = @_;
my $before = File::Spec->rel2abs( File::Spec->curdir() );
+ chdir $before;  # Try and force curdir() to report the directory  
without symbolic links.

+ $before = File::Spec->rel2abs( File::Spec->curdir() );
chdir $newdir;
my $after = File::Spec->rel2abs( File::Spec->curdir() );
...

Could you try this and see if it works?


Sadly, I tried it, and it didn’t have any effect.

-- Darin

PS: It’s OK with me if someone wants to rewrite in python if this  
really is a result of perl badness.

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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Peter Kasting]

On Mon, Jul 20, 2009 at 2:40 PM, Peter Kasting  wrote:

> It looks from here like the chdir call is causing curdir() to report the
> non-symbolic-link form of things.  If that's true, it seems like this
> workaround would work:
>
> ...
> my ($newdir) = @_;
> my $before = File::Spec->rel2abs( File::Spec->curdir() );
> + chdir $before;  # Try and force curdir() to report the directory without
> symbolic links.
> + $before = File::Spec->rel2abs( File::Spec->curdir() );
> chdir $newdir;
> my $after = File::Spec->rel2abs( File::Spec->curdir() );
> ...
>
> Could you try this and see if it works?
>
> Also, any Perl hackers are welcome to chip in here on how the current code
> should be improved.  I just looked up docs on the File::Spec module and saw
> them mentioning something about realpath() that might be relevant here...
>

Looking at this more, this code just looks wrong to me (although, like I
said, I know roughly zero Perl, so my instincts are not trustworthy).

Perhaps instead of the hack above, try adding "use Cwd;" to the top of the
file and then changing this to:

...
my ($newdir) = @_;
my $before = Cwd::getcwd();
chdir $newdir;
my $after = Cwd::getcwd();
...

That seems like it ought to work a lot better.

If that solves your problem, I'll get this reviewed and checked in.

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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Darin Adler]

On Jul 20, 2009, at 2:50 PM, Peter Kasting wrote:


my ($newdir) = @_;
my $before = Cwd::getcwd();
chdir $newdir;
my $after = Cwd::getcwd();

That seems like it ought to work a lot better.


Yes, it does. Hooray!

-- Darin

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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Peter Kasting]

On Mon, Jul 20, 2009 at 2:52 PM, Darin Adler  wrote:

> On Jul 20, 2009, at 2:50 PM, Peter Kasting wrote:
>
>  my ($newdir) = @_;
>> my $before = Cwd::getcwd();
>> chdir $newdir;
>> my $after = Cwd::getcwd();
>>
>> That seems like it ought to work a lot better.
>>
>
> Yes, it does. Hooray!


Awesome.  I'll get this patch up for review.  Thanks for your patience
Darin!

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

Re: [webkit-dev] JS: Getter/Setter callbacks at Property level

[Geoffrey Garen]

How about separate call backs at the class level?  That would solve  
my problem with minimal code movement.  Something like:


JSClassSetPropertyGetterSetter 
(ctx,class,"red",myRedGetter,myRedSetter);


Would that be more within the design?


Yes. That's what I had in mind when I mentioned "an API for adding C  
getters and setters to a class individually."


Geoff

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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Adam Barth]

On Mon, Jul 20, 2009 at 2:17 PM, Peter Kasting wrote:
> I can switch svn-create-patch to using UUID if there are benefits over using
> the Repository Root; it'd literally be a four-character change.

I'm not enough of an SVN expert to know which is better.  I'd prefer
to use one method consistently throughout WebKitTools (ideally by
calling into a common library).

Adam

(Apologies for not being on IRC, I'm in meetings at Berkeley today.)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] JS: Getter/Setter callbacks at Property level

[Brian Barnes]

What should be my next step, here?  Submit a "bug" for this?

[>] Brian

On Jul 20, 2009, at 6:05 PM, Geoffrey Garen wrote:

How about separate call backs at the class level?  That would solve  
my problem with minimal code movement.  Something like:


JSClassSetPropertyGetterSetter 
(ctx,class,"red",myRedGetter,myRedSetter);


Would that be more within the design?


Yes. That's what I had in mind when I mentioned "an API for adding C  
getters and setters to a class individually."


Geoff



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

Re: [webkit-dev] Setting event handlers on the global context

[Drew Wilson]

Ran a quick test on Opera and IE along these lines:
 function onload() { alert("onload"); }


Only firefox displayed the alert dialog when loading this page -
IE/Opera/WebKit do not. So if this behavior is incorrect, at least we have
lots of company.

-atw

On Sun, Jul 19, 2009 at 4:28 PM, Maciej Stachowiak  wrote:

>
> On Jul 19, 2009, at 11:10 AM, Adam Barth wrote:
>
>  I think we should do what Firefox does in the window.onload case.  :)
>>
>> I'm not familiar with the history through.  Is there some particular
>> reason we have our current behavior?
>>
>
> The current behavior is an accident of implementation, but I think the
> relevant applicable spec is somewhat ambiguous. A function declaration
> creates a new var-like binding which shadows the underlying onmessage
> setter.
>
> The relevant spec here is ECMAScript, not HTML5. In ECMA-262, section
> 10.1.3 is what would apply, I haven't checked the proper reference for the
> fifth edition draft. Regarding the declaration of a function with the same
> name as an existing property, it says: "If the variable object already has a
> property with this name, replace its value and attributes." So a vanilla
> property should get replaced with a DontDelete property, but in the case of
> a setter it's not clear whether it should be replaced or shadowed.
>
> It would probably be good to match other browsers. I am curious what IE and
> Opera do here. I would also be curious if ECMAScript 5 is more clear about
> what to do when a function declaration has the same name as a setter
> property, since it supports getters and setters in the spec.
>
>  his would be slightly, but not insanely tricky to fix. The relevant code
> is all in BytecodeGenerator::BytecodeGenerator(ProgramNode*
> programNode), since this only affects global scope. The change could
> have far-reaching consequences so we'd have to be on the lookout for Web
> compatibility regressions if we change this.
>
> Regards,
> Maciej
>
>
>
>> Adam
>>
>>
>> On Sun, Jul 19, 2009 at 10:56 AM, Drew Wilson wrote:
>>
>>> Yes, it happens with window.onload() too (I didn't mean to imply that it
>>> was
>>> a worker-only issue).
>>> This seems like precisely the type of inoperability that the HTML5 spec
>>> should address, but I figured I should get some input here before
>>> bringing
>>> it up there.
>>> -atw
>>>
>>> On Sun, Jul 19, 2009 at 10:31 AM, Adam Barth  wrote:
>>>

 You should test the same thing with window.onload.  If I recall
 correctly, you'll see similar inoperability.

 Adam


 On Sun, Jul 19, 2009 at 9:29 AM, Drew Wilson
 wrote:

> I was writing a new worker unit test and I noticed that all of our unit
> tests set event handlers in worker global context like so:
> onmessage = function(event) { ... do something ... };
> I note that Firefox also allows setting event handlers like this:
> function onmessage(event) { ... do something ... };
> In WebKit, the latter form creates a function at global scope named
> "onmessage" but does not set it as an event handler.
> I'm trying to figure out what the correct behavior should be - I've
> asked
> IanH, and his response was that he dimly recalls that both forms should
> be
> valid "(through a convoluted argument that I forget right now, but
> which
> should be examined carefully by whoever implements this, and which
> requires
> careful examination of at least the ECMAScript spec and maybe also the
> WebIDL and HTML5 specs)" - basically, he wasn't entirely certain and
> thought
> I should check here and with the Mozilla devs to get your opinions.
> Anyone familiar enough with the various specs to make a definitive
> argument
> one way or the other?
> -atw
>
>
>
>
>
>
>
> ___
> 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] Setting event handlers on the global context

[Adam Barth]

You might want to ask someone at Mozilla if they'd be willing to
change their behavior to match everyone else.  The whatwg might be a
good forum for that if you're not sure who to contact individually.

Adam


On Mon, Jul 20, 2009 at 6:30 PM, Drew Wilson wrote:
> Ran a quick test on Opera and IE along these lines:
>  function onload() { alert("onload"); }
> 
> Only firefox displayed the alert dialog when loading this page -
> IE/Opera/WebKit do not. So if this behavior is incorrect, at least we have
> lots of company.
> -atw
>
> On Sun, Jul 19, 2009 at 4:28 PM, Maciej Stachowiak  wrote:
>>
>> On Jul 19, 2009, at 11:10 AM, Adam Barth wrote:
>>
>>> I think we should do what Firefox does in the window.onload case.  :)
>>>
>>> I'm not familiar with the history through.  Is there some particular
>>> reason we have our current behavior?
>>
>> The current behavior is an accident of implementation, but I think the
>> relevant applicable spec is somewhat ambiguous. A function declaration
>> creates a new var-like binding which shadows the underlying onmessage
>> setter.
>>
>> The relevant spec here is ECMAScript, not HTML5. In ECMA-262, section
>> 10.1.3 is what would apply, I haven't checked the proper reference for the
>> fifth edition draft. Regarding the declaration of a function with the same
>> name as an existing property, it says: "If the variable object already has a
>> property with this name, replace its value and attributes." So a vanilla
>> property should get replaced with a DontDelete property, but in the case of
>> a setter it's not clear whether it should be replaced or shadowed.
>>
>> It would probably be good to match other browsers. I am curious what IE
>> and Opera do here. I would also be curious if ECMAScript 5 is more clear
>> about what to do when a function declaration has the same name as a setter
>> property, since it supports getters and setters in the spec.
>>
>>  his would be slightly, but not insanely tricky to fix. The relevant code
>> is all in BytecodeGenerator::BytecodeGenerator(ProgramNode*
>> programNode), since this only affects global scope. The change could
>> have far-reaching consequences so we'd have to be on the lookout for Web
>> compatibility regressions if we change this.
>>
>> Regards,
>> Maciej
>>
>>>
>>> Adam
>>>
>>>
>>> On Sun, Jul 19, 2009 at 10:56 AM, Drew Wilson wrote:

 Yes, it happens with window.onload() too (I didn't mean to imply that it
 was
 a worker-only issue).
 This seems like precisely the type of inoperability that the HTML5 spec
 should address, but I figured I should get some input here before
 bringing
 it up there.
 -atw

 On Sun, Jul 19, 2009 at 10:31 AM, Adam Barth  wrote:
>
> You should test the same thing with window.onload.  If I recall
> correctly, you'll see similar inoperability.
>
> Adam
>
>
> On Sun, Jul 19, 2009 at 9:29 AM, Drew Wilson
> wrote:
>>
>> I was writing a new worker unit test and I noticed that all of our
>> unit
>> tests set event handlers in worker global context like so:
>> onmessage = function(event) { ... do something ... };
>> I note that Firefox also allows setting event handlers like this:
>> function onmessage(event) { ... do something ... };
>> In WebKit, the latter form creates a function at global scope named
>> "onmessage" but does not set it as an event handler.
>> I'm trying to figure out what the correct behavior should be - I've
>> asked
>> IanH, and his response was that he dimly recalls that both forms
>> should
>> be
>> valid "(through a convoluted argument that I forget right now, but
>> which
>> should be examined carefully by whoever implements this, and which
>> requires
>> careful examination of at least the ECMAScript spec and maybe also the
>> WebIDL and HTML5 specs)" - basically, he wasn't entirely certain and
>> thought
>> I should check here and with the Mozilla devs to get your opinions.
>> Anyone familiar enough with the various specs to make a definitive
>> argument
>> one way or the other?
>> -atw
>>
>>
>>
>>
>>
>>
>>
>> ___
>> 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] Haiku + GYP (WAS: Build File Maintenance)

[Jeremy Orlow]

I'm adding a bunch of the GYP experts to this thread and re-naming it for
sanity's sake.  :-)

On Wed, Jul 15, 2009 at 11:20 PM, Maciej Stachowiak  wrote:

>
> If you're willing to give it a shot, then that sounds like a fine idea.
>
>  - Maciej
>
>
> On Jul 15, 2009, at 10:51 PM, Ryan Leavengood wrote:
>
>  On Mon, Jul 13, 2009 at 4:56 PM, Maciej Stachowiak wrote:
>>
>>>
>>> One belated comment on this topic. It would be neat if some port agreed
>>> to
>>> be the guinea pig to see if gyp could plausibly work for more than
>>> Google's
>>> ports. The Wx port probably has the lowest resources of any complete port
>>> in
>>> the tree, so they might not be the best choice of experimental subject,
>>> particularly if for them the process required writing a new gyp back end
>>> and
>>> if they are not yet entirely comfortable going the gyp route.
>>>
>>
>> I would need to discuss it with my student, but what about the brand
>> new Haiku port being the gyp guinea pig? For those who don't know, I
>> am mentoring a student in the Google Summer of Code for the Haiku
>> operating system (http://www.haiku-os.org) and we are working on a
>> native Haiku web browser with WebKit as the rendering engine.
>>
>> I don't know if our port is any better of a choice than the Wx port,
>> since the resources are also small (just two of us for now) and we
>> aren't even in the WebKit tree yet, but I think we still might be a
>> good choice because:
>>
>> 1) We obviously don't yet have a "production" browser using our port
>> so breakage isn't an issue. Plus only my student (Maxime Simon) and I
>> are working on it.
>>
>> 2) I have decent experience with build systems and think I could
>> handle working with gyp and writing a new back end.
>>
>> 3) Haiku generally uses Jam for building and we would like our port to
>> do the same. Rather than adding "Yet Another Build System" to WebKit,
>> we could use gyp and write a Jam backend for it. This can therefore
>> serve as a test of gyp for another platform as well as for another
>> backend.
>>
>> I would rather not have to maintain a Jamfile for WebKit if I can
>> avoid it, and I certainly don't want to burden the other WebKit
>> developers with having to maintain it for what is now (and may forever
>> be) a tiny port. Though we certainly hope Haiku's popularity increases
>> in the future (it hasn't even had a first release anyhow, so there is
>> plenty of room to grow.)
>>
>> Anyhow, I'd be interested in hearing what other people think.
>>
>> --
>> Regards,
>> Ryan
>> ___
>> 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] Haiku + GYP (WAS: Build File Maintenance)

[Mark Mentovai]

This sounds like a good experiment to me too.  I don't know much about
jam (I've generally avoided it in Xcode) but I'd be happy to provide
GYP-side support.

Mark

Jeremy Orlow wrote:
> I'm adding a bunch of the GYP experts to this thread and re-naming it for
> sanity's sake.  :-)
>
> On Wed, Jul 15, 2009 at 11:20 PM, Maciej Stachowiak  wrote:
>>
>> If you're willing to give it a shot, then that sounds like a fine idea.
>>
>>  - Maciej
>>
>> On Jul 15, 2009, at 10:51 PM, Ryan Leavengood wrote:
>>
>>> On Mon, Jul 13, 2009 at 4:56 PM, Maciej Stachowiak wrote:

 One belated comment on this topic. It would be neat if some port agreed
 to
 be the guinea pig to see if gyp could plausibly work for more than
 Google's
 ports. The Wx port probably has the lowest resources of any complete
 port in
 the tree, so they might not be the best choice of experimental subject,
 particularly if for them the process required writing a new gyp back end
 and
 if they are not yet entirely comfortable going the gyp route.
>>>
>>> I would need to discuss it with my student, but what about the brand
>>> new Haiku port being the gyp guinea pig? For those who don't know, I
>>> am mentoring a student in the Google Summer of Code for the Haiku
>>> operating system (http://www.haiku-os.org) and we are working on a
>>> native Haiku web browser with WebKit as the rendering engine.
>>>
>>> I don't know if our port is any better of a choice than the Wx port,
>>> since the resources are also small (just two of us for now) and we
>>> aren't even in the WebKit tree yet, but I think we still might be a
>>> good choice because:
>>>
>>> 1) We obviously don't yet have a "production" browser using our port
>>> so breakage isn't an issue. Plus only my student (Maxime Simon) and I
>>> are working on it.
>>>
>>> 2) I have decent experience with build systems and think I could
>>> handle working with gyp and writing a new back end.
>>>
>>> 3) Haiku generally uses Jam for building and we would like our port to
>>> do the same. Rather than adding "Yet Another Build System" to WebKit,
>>> we could use gyp and write a Jam backend for it. This can therefore
>>> serve as a test of gyp for another platform as well as for another
>>> backend.
>>>
>>> I would rather not have to maintain a Jamfile for WebKit if I can
>>> avoid it, and I certainly don't want to burden the other WebKit
>>> developers with having to maintain it for what is now (and may forever
>>> be) a tiny port. Though we certainly hope Haiku's popularity increases
>>> in the future (it hasn't even had a first release anyhow, so there is
>>> plenty of room to grow.)
>>>
>>> Anyhow, I'd be interested in hearing what other people think.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Haiku + GYP (WAS: Build File Maintenance)

[Bradley Nelson]

I agree. This sounds useful.The backend generators for gyp are moderately
separated out, so you can probably just start a new one in
pylib/gyp/generator.
Please let us know anything we can do to help.

-BradN


On Mon, Jul 20, 2009 at 9:33 PM, Mark Mentovai  wrote:

> This sounds like a good experiment to me too.  I don't know much about
> jam (I've generally avoided it in Xcode) but I'd be happy to provide
> GYP-side support.
>
> Mark
>
> Jeremy Orlow wrote:
> > I'm adding a bunch of the GYP experts to this thread and re-naming it for
> > sanity's sake.  :-)
> >
> > On Wed, Jul 15, 2009 at 11:20 PM, Maciej Stachowiak 
> wrote:
> >>
> >> If you're willing to give it a shot, then that sounds like a fine idea.
> >>
> >>  - Maciej
> >>
> >> On Jul 15, 2009, at 10:51 PM, Ryan Leavengood wrote:
> >>
> >>> On Mon, Jul 13, 2009 at 4:56 PM, Maciej Stachowiak
> wrote:
> 
>  One belated comment on this topic. It would be neat if some port
> agreed
>  to
>  be the guinea pig to see if gyp could plausibly work for more than
>  Google's
>  ports. The Wx port probably has the lowest resources of any complete
>  port in
>  the tree, so they might not be the best choice of experimental
> subject,
>  particularly if for them the process required writing a new gyp back
> end
>  and
>  if they are not yet entirely comfortable going the gyp route.
> >>>
> >>> I would need to discuss it with my student, but what about the brand
> >>> new Haiku port being the gyp guinea pig? For those who don't know, I
> >>> am mentoring a student in the Google Summer of Code for the Haiku
> >>> operating system (http://www.haiku-os.org) and we are working on a
> >>> native Haiku web browser with WebKit as the rendering engine.
> >>>
> >>> I don't know if our port is any better of a choice than the Wx port,
> >>> since the resources are also small (just two of us for now) and we
> >>> aren't even in the WebKit tree yet, but I think we still might be a
> >>> good choice because:
> >>>
> >>> 1) We obviously don't yet have a "production" browser using our port
> >>> so breakage isn't an issue. Plus only my student (Maxime Simon) and I
> >>> are working on it.
> >>>
> >>> 2) I have decent experience with build systems and think I could
> >>> handle working with gyp and writing a new back end.
> >>>
> >>> 3) Haiku generally uses Jam for building and we would like our port to
> >>> do the same. Rather than adding "Yet Another Build System" to WebKit,
> >>> we could use gyp and write a Jam backend for it. This can therefore
> >>> serve as a test of gyp for another platform as well as for another
> >>> backend.
> >>>
> >>> I would rather not have to maintain a Jamfile for WebKit if I can
> >>> avoid it, and I certainly don't want to burden the other WebKit
> >>> developers with having to maintain it for what is now (and may forever
> >>> be) a tiny port. Though we certainly hope Haiku's popularity increases
> >>> in the future (it hasn't even had a first release anyhow, so there is
> >>> plenty of room to grow.)
> >>>
> >>> Anyhow, I'd be interested in hearing what other people think.
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev