Re: [webkit-dev] WebCore/platform standalone library

[Carlos Garcia Campos]

El mié, 18-03-2015 a las 21:43 -0700, Myles C. Maxfield escribió:
> Hello, all,
> 
> I’d like to announce that I intend to create a standalone static library from 
> the current contents of WebCore/platform over the coming months. This will 
> involve creating a “Platform" top-level directory and moving source files 
> into it, one by one. 

Yes!

> There are a few reasons for this:
> 
> 1. Enforcing the layering between Platform and WebCore. Moving Platform into 
> its own target/directory can guarantee that nothing inside it knows about 
> anything in WebCore.
> 2. Being able to test code in the Platform directory with TestWebKitAPI 
> (without exporting Platform symbols from the WebCore library)
> 3. Managing conceptual complexity.
> 
> Does anyone have any thoughts or feedback?

This has always been blocked by the existing layering violations, what
are your plans for that? I guess we will have WebCore/platform and
Platform at the same time for a while until all layering violations are
fixed?

See the tracking bug:
https://bugs.webkit.org/show_bug.cgi?id=21354

But there are more, I wrote a script to get the list of violations, it's
in Tools/Scripts/check-for-platform-layering-violations

> Thanks,
> Myles
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

[webkit-dev] Running new/modified tests on EWS bots

[youenn fablet]

Hi,

Related to the webkit contributor meeting discussion related to ports,
I would find it useful if EWS bots (gtk, efl, win, ios) were running
the tests that are modified/created by a patch.

The idea would be to turn yellow the port bubble whenever one of these
tests do not pass. Results would be uploaded to bugzilla.

This would give an incentive for patch developers to try fixing the
tests on these ports.
That may reduce (slightly? noticeably?) port maintainers gardening effort.
That would also be valuable when importing test suites.

Any potential issue? objection to move that forward?
Anyone willing to help? Thoughts?

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

Re: [webkit-dev] Running new/modified tests on EWS bots

[Osztrogonác Csaba]

Hi,

I'd like this idea basically, it would be great
if you or somebody else could work on it.

One of my former collegue started to investigate the same
thing 1.5 years before, but it was lost among many tasks
with higher priorities. Feel free to reuse these bugs and
WIP patches: (or file new ones)
- https://bugs.webkit.org/show_bug.cgi?id=117831
- and bugs in its "depends on" list

In my opinion red tree and flakey tets could cause many
problems, because EWS is designed primarily for green tree.
But unfortunately only Mac (and now Win release) bots are green
almost all the time. I can't remember if EFL or GTK bots were
green in the last 1-2 years ever. :-/

Now the tester EWS bots (Mac WK1 and WK2) run all tests. If all tests
pass, there is no problem. But if there is only one failure, it tries
to build and run tests without the patch. If all tests pass, the patch
caused the regression. If there are exactly the same failures on the
trunk and with the patch, the bubble becomes green.

But flakey failures on the trunk can make EWS crazy. I remember that
EWS wasn't able to process any patch for days because of 1-2 flakey
failures on the trunk. If we enabled full or partial testing on
unstable EWSs, they would become very slow, unstable and we would
lost the very quick and stable builder EWSs. Maybe we should have
separated builder and builder-and-tester EWS bots to avoid this kind
of problems, but we would need more hardware for it.

Anyway it would be great if EFL and GTK maintainers could keep the
tester bots green almost all the time. I know it isn't an easy task
and would need more resource. I remember from the QtWebKit era that
1-2 full-time gardener can be enough to keep the tree green, but
it means only minor buildfixes, expected updates, new bug reports
and skipping/marking new failures time to time. To increase the
stabilility, fix regressions, decrease the number of skipped tests
would need much more resource.

Of course, I willingly help you, but unfortunately I don't have
too much time for this topic nowadays. But feel free to cc me
to related bugs and I'll try to help if I can.

br,
Ossy

youenn fablet írta:

Hi,

Related to the webkit contributor meeting discussion related to ports,
I would find it useful if EWS bots (gtk, efl, win, ios) were running
the tests that are modified/created by a patch.

The idea would be to turn yellow the port bubble whenever one of these
tests do not pass. Results would be uploaded to bugzilla.

This would give an incentive for patch developers to try fixing the
tests on these ports.
That may reduce (slightly? noticeably?) port maintainers gardening effort.
That would also be valuable when importing test suites.

Any potential issue? objection to move that forward?
Anyone willing to help? Thoughts?

Thanks,
   Youenn

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

Re: [webkit-dev] Running new/modified tests on EWS bots

[Michael Catanzaro]

This seems to me like an obvious step to take. I'd much rather know
about tests that my patch breaks before pushing rather than afterward.

I guess the potential issue would be build power.

Michael

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

[webkit-dev] Safari browser on Mac OSX complains "AudioContext.createMediaStreamSource" is undefined !

[Sasi San]

Hi-

I am trying to get the live audio input from microphone using AudioContext.
Safari browser complains that the "createMediaStreamSource" is undefined.
here is my sample of JavaScript code. It's not able to create Audio source
node. So I am not able to get the audio sample from microphone in the
OnAudioProcess event handler.

var micGain = audioContext.createGain();
if(!audioContext.createScriptProcessor){
micAudioProcessor =
audioContext.createJavaScriptNode(bufferSize, 1, 1);
console.log('createJavaScriptNode Done');
} else {
micAudioProcessor =
audioContext.createScriptProcessor(bufferSize, 1, 1);
   console.log('createScriptProcessor Done');
}

// Create an AudioNode from the stream.
if(typeof(audioContext.createMediaStreamSource) === 'function') {
micInput = audioContext.createMediaStreamSource(inAudioStream);
micInput.connect(micGain);
}
else {
console.log('method createMediaStreamSource unavailable');
}

Please let me know why Safari is complaining on this API
"createMediaStreamSource ". Is there any other way I can get the live audio
sample from microphone on Safari browser???

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

Re: [webkit-dev] Running new/modified tests on EWS bots

[Xabier Rodríguez Calvar]

O Xov, 19-03-2015 ás 16:46 +0100, youenn fablet escribiu:
> Related to the webkit contributor meeting discussion related to ports,
> I would find it useful if EWS bots (gtk, efl, win, ios) were running
> the tests that are modified/created by a patch.
> 
> The idea would be to turn yellow the port bubble whenever one of these
> tests do not pass. Results would be uploaded to bugzilla.

AFAIK, the only EWS bots running all tests are the Mac ones. It is ok to
have EWS running the at least the affected tests and I guess that
shouldn't take that much computation power (maybe some development to
know which tests need to be run). What would be really nice is having
all tests run, but for that I guess tests bots need to be green, which
is a pace very difficult to maintain for smaller ports.

Br.



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Running new/modified tests on EWS bots

[Carlos Alberto Lopez Perez]

On 19/03/15 16:46, youenn fablet wrote:
> Hi,
> 
> Related to the webkit contributor meeting discussion related to ports,
> I would find it useful if EWS bots (gtk, efl, win, ios) were running
> the tests that are modified/created by a patch.
> 
> The idea would be to turn yellow the port bubble whenever one of these
> tests do not pass. Results would be uploaded to bugzilla.
> 
> This would give an incentive for patch developers to try fixing the
> tests on these ports.
> That may reduce (slightly? noticeably?) port maintainers gardening effort.
> That would also be valuable when importing test suites.
> 
> Any potential issue? objection to move that forward?
> Anyone willing to help? Thoughts?
> 

I think that having an EWS running only the tests that the patch touches
is of limited value because a patch can break unrelated tests.

However running all the tests requires to have the tree green and this
is not possible for GTK or EFL because it will require more manpower
than the currently available.

An idea that comes to mind for running all the tests without requiring
to have the tree green is the following:

1) EWS either run all the tests without the patch or download from
https://build.webkit.org/results the results from the bot for the
revision if they are available.
2) EWS run all the tests with the patch.
3) EWS gets the diff from 1. and 2.
4) EWS runs only the tests that broke from 1 to 2 several times, in
order to discard the ones that are flaky and only report the ones that
on every run fail now.

If I'm not overlooking something, I think that this would allow to
identify what tests a given patch breaks and it won't require to have
the tree green, neither it will be affected by flaky tests.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Running new/modified tests on EWS bots

[Alexey Proskuryakov]

19 марта 2015 г., в 8:46, youenn fablet  написал(а):

> Hi,
> 
> Related to the webkit contributor meeting discussion related to ports,
> I would find it useful if EWS bots (gtk, efl, win, ios) were running
> the tests that are modified/created by a patch.
> 
> The idea would be to turn yellow the port bubble whenever one of these
> tests do not pass. Results would be uploaded to bugzilla.
> 
> This would give an incentive for patch developers to try fixing the
> tests on these ports.
> That may reduce (slightly? noticeably?) port maintainers gardening effort.
> That would also be valuable when importing test suites.
> 
> Any potential issue? objection to move that forward?
> Anyone willing to help? Thoughts?

I think that it's a good idea. The infrastructure added for this could be 
reused for something that we wanted for a long time - on the Mac, we should run 
newly added tests multiple times and also with GuardMalloc enabled, to reduce 
the chances of them being flaky, or uncovering memory corruption. That's a low 
cost in terms of EWS performance.

- Alexey


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

Re: [webkit-dev] Safari browser on Mac OSX complains "AudioContext.createMediaStreamSource" is undefined !

[Chris Dumez]

Jer or Eric would know more about this but 
AudioContext.createMediaStreamSource() is behind a MEDIA_STREAM compile-time 
flag. It appears the mac port does not turn this flag on so Safari does not 
currently support the Media Stream API.

Kr,
--
 Chris Dumez - Apple Inc. - Cupertino, CA




> On Mar 19, 2015, at 9:35 AM, Sasi San  wrote:
> 
> Hi-
> 
> I am trying to get the live audio input from microphone using AudioContext. 
> Safari browser complains that the "createMediaStreamSource" is undefined. 
> here is my sample of JavaScript code. It's not able to create Audio source 
> node. So I am not able to get the audio sample from microphone in the 
> OnAudioProcess event handler.
> 
> var micGain = audioContext.createGain();
> if(!audioContext.createScriptProcessor){
> micAudioProcessor = audioContext.createJavaScriptNode(bufferSize, 
> 1, 1);
> console.log('createJavaScriptNode Done');
> } else {
> micAudioProcessor = 
> audioContext.createScriptProcessor(bufferSize, 1, 1);
>console.log('createScriptProcessor Done');
> }
> 
> // Create an AudioNode from the stream.
> if(typeof(audioContext.createMediaStreamSource) === 'function') {
> micInput = audioContext.createMediaStreamSource(inAudioStream);
> micInput.connect(micGain);
> }
> else {
> console.log('method createMediaStreamSource unavailable');
> }
> 
> Please let me know why Safari is complaining on this API 
> "createMediaStreamSource ". Is there any other way I can get the live audio 
> sample from microphone on Safari browser???
> 
> Thanks,
> Sasi
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Safari browser on Mac OSX complains "AudioContext.createMediaStreamSource" is undefined !

[Sasi San]

Thanks Chris. Is there any other way I can turn that flag?  or Do you any
idea whether it will be supported  in the near furture?

Sasi

On Thu, Mar 19, 2015 at 11:12 AM, Chris Dumez  wrote:

> Jer or Eric would know more about this but
> AudioContext.createMediaStreamSource() is behind a MEDIA_STREAM
> compile-time flag. It appears the mac port does not turn this flag on so
> Safari does not currently support the Media Stream API.
>
> Kr,
> --
>  Chris Dumez - Apple Inc. - Cupertino, CA
>
>
>
>
> On Mar 19, 2015, at 9:35 AM, Sasi San  wrote:
>
> Hi-
>
> I am trying to get the live audio input from microphone using
> AudioContext. Safari browser complains that the "createMediaStreamSource"
> is undefined. here is my sample of JavaScript code. It's not able to create
> Audio source node. So I am not able to get the audio sample from microphone
> in the OnAudioProcess event handler.
>
> var micGain = audioContext.createGain();
> if(!audioContext.createScriptProcessor){
> micAudioProcessor =
> audioContext.createJavaScriptNode(bufferSize, 1, 1);
> console.log('createJavaScriptNode Done');
> } else {
> micAudioProcessor =
> audioContext.createScriptProcessor(bufferSize, 1, 1);
>console.log('createScriptProcessor Done');
> }
>
> // Create an AudioNode from the stream.
> if(typeof(audioContext.createMediaStreamSource) === 'function') {
> micInput = audioContext.createMediaStreamSource(inAudioStream);
> micInput.connect(micGain);
> }
> else {
> console.log('method createMediaStreamSource unavailable');
> }
>
> Please let me know why Safari is complaining on this API
> "createMediaStreamSource ". Is there any other way I can get the live audio
> sample from microphone on Safari browser???
>
> Thanks,
> Sasi
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Safari browser on Mac OSX complains "AudioContext.createMediaStreamSource" is undefined !

[Jer Noble]

> On Mar 19, 2015, at 11:47 AM, Sasi San  wrote:
> 
> Thanks Chris. Is there any other way I can turn that flag?  or Do you any 
> idea whether it will be supported  in the near furture?

Sasi, that is a compile-time flag, so you’d have to build WebKit from source 
with that flag enabled. There’s no guarantee that the code will compile on Mac, 
nor that it will work once compiled.

Apple does not comment on future releases of Safari, their timing, nor their 
contents.

-Jer

smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] A quick note on Ref and RefPtr changes

[Adam Bergkvist]

On 17/02/15 10:28, Adam Bergkvist wrote:
> On 15/12/14 19:59, Andreas Kling wrote:
>> PS. Once the kinks are ironed out, I’ll also be updating the RefPtr 
>> documentation on webkit.org.
>
> Any progress on this particular part?

Bump.

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

Re: [webkit-dev] A quick note on Ref and RefPtr changes

[Andreas Kling]

> On Mar 19, 2015, at 12:43 PM, Adam Bergkvist  
> wrote:
> 
> On 17/02/15 10:28, Adam Bergkvist wrote:
>> On 15/12/14 19:59, Andreas Kling wrote:
>>> PS. Once the kinks are ironed out, I’ll also be updating the RefPtr 
>>> documentation on webkit.org.
>> 
>> Any progress on this particular part?
> 
> Bump.

I’m currently busy with a few other things but have filed this bug:

> Update the RefPtr 
documentation on webkit.org 

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

Re: [webkit-dev] WebCore/platform standalone library

[Benjamin Poulain]

On 3/18/15 9:43 PM, Myles C. Maxfield wrote:

Hello, all,

I’d like to announce that I intend to create a standalone static library from the 
current contents of WebCore/platform over the coming months. This will involve 
creating a “Platform" top-level directory and moving source files into it, one 
by one.

There are a few reasons for this:

1. Enforcing the layering between Platform and WebCore. Moving Platform into 
its own target/directory can guarantee that nothing inside it knows about 
anything in WebCore.
2. Being able to test code in the Platform directory with TestWebKitAPI 
(without exporting Platform symbols from the WebCore library)
3. Managing conceptual complexity.

Does anyone have any thoughts or feedback?


That's an awesome project. That's gonna be a lot of work.

How do you plan to do the interface between WebCore and Platform?

Between WebCore and WebKit, we use interfaces with pure virtual 
functions that are implemented by the clients.
Between WebCore and the platform, we have headers and each port has its 
own implementation of that interface.


Do you plan to move Platform behind a public interface or keep the 
current model?




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



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

Re: [webkit-dev] WebCore/platform standalone library

[Maciej Stachowiak]

> On Mar 19, 2015, at 1:47 PM, Benjamin Poulain  wrote:
> 
> On 3/18/15 9:43 PM, Myles C. Maxfield wrote:
>> Hello, all,
>> 
>> I’d like to announce that I intend to create a standalone static library 
>> from the current contents of WebCore/platform over the coming months. This 
>> will involve creating a “Platform" top-level directory and moving source 
>> files into it, one by one.
>> 
>> There are a few reasons for this:
>> 
>> 1. Enforcing the layering between Platform and WebCore. Moving Platform into 
>> its own target/directory can guarantee that nothing inside it knows about 
>> anything in WebCore.
>> 2. Being able to test code in the Platform directory with TestWebKitAPI 
>> (without exporting Platform symbols from the WebCore library)
>> 3. Managing conceptual complexity.
>> 
>> Does anyone have any thoughts or feedback?
> 
> That's an awesome project. That's gonna be a lot of work.
> 
> How do you plan to do the interface between WebCore and Platform?
> 
> Between WebCore and WebKit, we use interfaces with pure virtual functions 
> that are implemented by the clients.
> Between WebCore and the platform, we have headers and each port has its own 
> implementation of that interface.
> 
> Do you plan to move Platform behind a public interface or keep the current 
> model?

I don’t think we need a model like the WebCore/WebKit interface. WTF is 
essentially like the proposed Platform library already, and it just exposes 
normal C++ headers and implementation files. I think the main benefit here is 
cleaning up the layering, as opposed to adding more abstraction. In fact, you 
could sort of think of WTF and Platform as logically the same library, with WTF 
being only the parts needed by JavaScriptCore, plus things that are logically 
at the same level (so basically non-GUI and no networking code).

This almost makes me want to suggest a jokey name for Platform. I can’t off the 
top of my head think of a good expansion of OMG, though. Or BBQ.

Regards,
Maciej

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

Re: [webkit-dev] WebCore/platform standalone library

[Benjamin Poulain]

On 3/19/15 2:49 PM, Maciej Stachowiak wrote:



On Mar 19, 2015, at 1:47 PM, Benjamin Poulain  wrote:

On 3/18/15 9:43 PM, Myles C. Maxfield wrote:

Hello, all,

I’d like to announce that I intend to create a standalone static library from the 
current contents of WebCore/platform over the coming months. This will involve 
creating a “Platform" top-level directory and moving source files into it, one 
by one.

There are a few reasons for this:

1. Enforcing the layering between Platform and WebCore. Moving Platform into 
its own target/directory can guarantee that nothing inside it knows about 
anything in WebCore.
2. Being able to test code in the Platform directory with TestWebKitAPI 
(without exporting Platform symbols from the WebCore library)
3. Managing conceptual complexity.

Does anyone have any thoughts or feedback?


That's an awesome project. That's gonna be a lot of work.

How do you plan to do the interface between WebCore and Platform?

Between WebCore and WebKit, we use interfaces with pure virtual functions that 
are implemented by the clients.
Between WebCore and the platform, we have headers and each port has its own 
implementation of that interface.

Do you plan to move Platform behind a public interface or keep the current 
model?


I don’t think we need a model like the WebCore/WebKit interface. WTF is 
essentially like the proposed Platform library already, and it just exposes 
normal C++ headers and implementation files. I think the main benefit here is 
cleaning up the layering, as opposed to adding more abstraction. In fact, you 
could sort of think of WTF and Platform as logically the same library, with WTF 
being only the parts needed by JavaScriptCore, plus things that are logically 
at the same level (so basically non-GUI and no networking code).

This almost makes me want to suggest a jokey name for Platform. I can’t off the 
top of my head think of a good expansion of OMG, though. Or BBQ.


Have you seen the "clean" interface of ResourceHandle? :)

The client layers tend to get cleaner over time while the lower layers 
tends to become messier.

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

Re: [webkit-dev] WebCore/platform standalone library

[saam barati]

I think JavaScriptCore will need access to 'platform', too, to implement some 
ES6 features. 




Saam

On Thu, Mar 19, 2015 at 2:50 PM, Maciej Stachowiak  wrote:

>> On Mar 19, 2015, at 1:47 PM, Benjamin Poulain  wrote:
>> 
>> On 3/18/15 9:43 PM, Myles C. Maxfield wrote:
>>> Hello, all,
>>> 
>>> I’d like to announce that I intend to create a standalone static library 
>>> from the current contents of WebCore/platform over the coming months. This 
>>> will involve creating a “Platform" top-level directory and moving source 
>>> files into it, one by one.
>>> 
>>> There are a few reasons for this:
>>> 
>>> 1. Enforcing the layering between Platform and WebCore. Moving Platform 
>>> into its own target/directory can guarantee that nothing inside it knows 
>>> about anything in WebCore.
>>> 2. Being able to test code in the Platform directory with TestWebKitAPI 
>>> (without exporting Platform symbols from the WebCore library)
>>> 3. Managing conceptual complexity.
>>> 
>>> Does anyone have any thoughts or feedback?
>> 
>> That's an awesome project. That's gonna be a lot of work.
>> 
>> How do you plan to do the interface between WebCore and Platform?
>> 
>> Between WebCore and WebKit, we use interfaces with pure virtual functions 
>> that are implemented by the clients.
>> Between WebCore and the platform, we have headers and each port has its own 
>> implementation of that interface.
>> 
>> Do you plan to move Platform behind a public interface or keep the current 
>> model?
> I don’t think we need a model like the WebCore/WebKit interface. WTF is 
> essentially like the proposed Platform library already, and it just exposes 
> normal C++ headers and implementation files. I think the main benefit here is 
> cleaning up the layering, as opposed to adding more abstraction. In fact, you 
> could sort of think of WTF and Platform as logically the same library, with 
> WTF being only the parts needed by JavaScriptCore, plus things that are 
> logically at the same level (so basically non-GUI and no networking code).
> This almost makes me want to suggest a jokey name for Platform. I can’t off 
> the top of my head think of a good expansion of OMG, though. Or BBQ.
> Regards,
> Maciej
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Maciej Stachowiak]

> On Mar 19, 2015, at 3:44 PM, saam barati  wrote:
> 
> I think JavaScriptCore will need access to 'platform', too, to implement some 
> ES6 features. 

Anything needed for JavaScriptCore should go to WTF. Otherwise there is no 
point having a separation.

 - Maciej

> 
> Saam
> 
> 
> On Thu, Mar 19, 2015 at 2:50 PM, Maciej Stachowiak  > wrote:
> 
> 
> > On Mar 19, 2015, at 1:47 PM, Benjamin Poulain  wrote:
> > 
> > On 3/18/15 9:43 PM, Myles C. Maxfield wrote:
> >> Hello, all,
> >> 
> >> I’d like to announce that I intend to create a standalone static library 
> >> from the current contents of WebCore/platform over the coming months. This 
> >> will involve creating a “Platform" top-level directory and moving source 
> >> files into it, one by one.
> >> 
> >> There are a few reasons for this:
> >> 
> >> 1. Enforcing the layering between Platform and WebCore. Moving Platform 
> >> into its own target/directory can guarantee that nothing inside it knows 
> >> about anything in WebCore.
> >> 2. Being able to test code in the Platform directory with TestWebKitAPI 
> >> (without exporting Platform symbols from the WebCore library)
> >> 3. Managing conceptual complexity.
> >> 
> >> Does anyone have any thoughts or feedback?
> > 
> > That's an awesome project. That's gonna be a lot of work.
> > 
> > How do you plan to do the interface between WebCore and Platform?
> > 
> > Between WebCore and WebKit, we use interfaces with pure virtual functions 
> > that are implemented by the clients.
> > Between WebCore and the platform, we have headers and each port has its own 
> > implementation of that interface.
> > 
> > Do you plan to move Platform behind a public interface or keep the current 
> > model?
> 
> I don’t think we need a model like the WebCore/WebKit interface. WTF is 
> essentially like the proposed Platform library already, and it just exposes 
> normal C++ headers and implementation files. I think the main benefit here is 
> cleaning up the layering, as opposed to adding more abstraction. In fact, you 
> could sort of think of WTF and Platform as logically the same library, with 
> WTF being only the parts needed by JavaScriptCore, plus things that are 
> logically at the same level (so basically non-GUI and no networking code).
> 
> This almost makes me want to suggest a jokey name for Platform. I can’t off 
> the top of my head think of a good expansion of OMG, though. Or BBQ.
> 
> Regards,
> Maciej
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

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

Re: [webkit-dev] WebCore/platform standalone library

[Anders Carlsson]

> On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak  wrote:
> 
> This almost makes me want to suggest a jokey name for Platform. I can’t off 
> the top of my head think of a good expansion of OMG, though. Or BBQ.

I think putting platform code in a separate namespace would be a good first 
step. Then we can weed out the layering violations and ultimately move 
everything to a separate library.

- Anders (who’s not going to propose any namespace names)


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

Re: [webkit-dev] WebCore/platform standalone library

[Maciej Stachowiak]

> On Mar 19, 2015, at 5:19 PM, Anders Carlsson  wrote:
> 
> 
>> On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak > > wrote:
>> 
>> This almost makes me want to suggest a jokey name for Platform. I can’t off 
>> the top of my head think of a good expansion of OMG, though. Or BBQ.
> 
> I think putting platform code in a separate namespace would be a good first 
> step. Then we can weed out the layering violations and ultimately move 
> everything to a separate library.

I think it would also be fine to start by moving every file that doesn’t 
contain a layering violation and then fix the remainder. Moving the files could 
be done together with changing the namespace, or as a separate pass.

Regards,
Maciej


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

[webkit-dev] Modern image formats for WebKit

[ChangSeok Oh]

Hi WebKittens.

I just saw apng support landed on webkit main stream. [1] (even it works 
for gtk port only now)
So I suddenly wonder if webkit community is getting interested in 
bringing other modern image formats like webp or jpeg-xr into webkit.

If so, I can lend my hands for it.

For webp support, as you know, we can reuse blink's codebase. [2]
For jpeg-xr supprot, I have a rough sketch for it [3] (it might be 
outdated or not fit tot of webkit though, bringing it to webkit is just 
a piece of cake. ;))


My intention is not to argue which format is better, just to ask 
community's thoughts, preferences  or like that.


[1] https://bugs.webkit.org/show_bug.cgi?id=17022
[2] 
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/image-decoders/webp/WEBPImageDecoder.cpp&q=webpima&sq=package:chromium&l=1
[3] 
http://cgit.collabora.com/git/user/kevino/Blink.git/commit/?h=jxr-support&id=2ac58312a5aae502aacc1c55c0bfdff767ab82a2


BR.

--
ChangSeok

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

Re: [webkit-dev] WebCore/platform standalone library

[Myles C. Maxfield]

I do not intend on changing any interfaces or semantics. I only intend to 
change where code lives and library boundaries. There is no need to increase 
the scope of this project.

Also, I do not intend on making up a comical name.

--Myles

> On Mar 19, 2015, at 3:03 PM, Benjamin Poulain  wrote:
> 
>> On 3/19/15 2:49 PM, Maciej Stachowiak wrote:
>> 
>>> On Mar 19, 2015, at 1:47 PM, Benjamin Poulain  wrote:
>>> 
>>> On 3/18/15 9:43 PM, Myles C. Maxfield wrote:
 Hello, all,
 
 I’d like to announce that I intend to create a standalone static library 
 from the current contents of WebCore/platform over the coming months. This 
 will involve creating a “Platform" top-level directory and moving source 
 files into it, one by one.
 
 There are a few reasons for this:
 
 1. Enforcing the layering between Platform and WebCore. Moving Platform 
 into its own target/directory can guarantee that nothing inside it knows 
 about anything in WebCore.
 2. Being able to test code in the Platform directory with TestWebKitAPI 
 (without exporting Platform symbols from the WebCore library)
 3. Managing conceptual complexity.
 
 Does anyone have any thoughts or feedback?
>>> 
>>> That's an awesome project. That's gonna be a lot of work.
>>> 
>>> How do you plan to do the interface between WebCore and Platform?
>>> 
>>> Between WebCore and WebKit, we use interfaces with pure virtual functions 
>>> that are implemented by the clients.
>>> Between WebCore and the platform, we have headers and each port has its own 
>>> implementation of that interface.
>>> 
>>> Do you plan to move Platform behind a public interface or keep the current 
>>> model?
>> 
>> I don’t think we need a model like the WebCore/WebKit interface. WTF is 
>> essentially like the proposed Platform library already, and it just exposes 
>> normal C++ headers and implementation files. I think the main benefit here 
>> is cleaning up the layering, as opposed to adding more abstraction. In fact, 
>> you could sort of think of WTF and Platform as logically the same library, 
>> with WTF being only the parts needed by JavaScriptCore, plus things that are 
>> logically at the same level (so basically non-GUI and no networking code).
>> 
>> This almost makes me want to suggest a jokey name for Platform. I can’t off 
>> the top of my head think of a good expansion of OMG, though. Or BBQ.
> 
> Have you seen the "clean" interface of ResourceHandle? :)
> 
> The client layers tend to get cleaner over time while the lower layers tends 
> to become messier.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Myles C. Maxfield]

Sorry, I missed some of this thread before sending my reply. 

First, I'm going to try to get as far as I can by only moving over the 
non-layer-violating code. Therefore, for the interim, we will have both old and 
new directories. Then I will work on removing layering violations, one by one. 
These things will be taken on a case by case basis.

--Myles

> On Mar 19, 2015, at 10:07 PM, Myles C. Maxfield  wrote:
> 
> I do not intend on changing any interfaces or semantics. I only intend to 
> change where code lives and library boundaries. There is no need to increase 
> the scope of this project.
> 
> Also, I do not intend on making up a comical name.
> 
> --Myles
> 
>>> On Mar 19, 2015, at 3:03 PM, Benjamin Poulain  wrote:
>>> 
 On 3/19/15 2:49 PM, Maciej Stachowiak wrote:
 
 On Mar 19, 2015, at 1:47 PM, Benjamin Poulain  wrote:
 
 On 3/18/15 9:43 PM, Myles C. Maxfield wrote:
> Hello, all,
> 
> I’d like to announce that I intend to create a standalone static library 
> from the current contents of WebCore/platform over the coming months. 
> This will involve creating a “Platform" top-level directory and moving 
> source files into it, one by one.
> 
> There are a few reasons for this:
> 
> 1. Enforcing the layering between Platform and WebCore. Moving Platform 
> into its own target/directory can guarantee that nothing inside it knows 
> about anything in WebCore.
> 2. Being able to test code in the Platform directory with TestWebKitAPI 
> (without exporting Platform symbols from the WebCore library)
> 3. Managing conceptual complexity.
> 
> Does anyone have any thoughts or feedback?
 
 That's an awesome project. That's gonna be a lot of work.
 
 How do you plan to do the interface between WebCore and Platform?
 
 Between WebCore and WebKit, we use interfaces with pure virtual functions 
 that are implemented by the clients.
 Between WebCore and the platform, we have headers and each port has its 
 own implementation of that interface.
 
 Do you plan to move Platform behind a public interface or keep the current 
 model?
>>> 
>>> I don’t think we need a model like the WebCore/WebKit interface. WTF is 
>>> essentially like the proposed Platform library already, and it just exposes 
>>> normal C++ headers and implementation files. I think the main benefit here 
>>> is cleaning up the layering, as opposed to adding more abstraction. In 
>>> fact, you could sort of think of WTF and Platform as logically the same 
>>> library, with WTF being only the parts needed by JavaScriptCore, plus 
>>> things that are logically at the same level (so basically non-GUI and no 
>>> networking code).
>>> 
>>> This almost makes me want to suggest a jokey name for Platform. I can’t off 
>>> the top of my head think of a good expansion of OMG, though. Or BBQ.
>> 
>> Have you seen the "clean" interface of ResourceHandle? :)
>> 
>> The client layers tend to get cleaner over time while the lower layers tends 
>> to become messier.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Modern image formats for WebKit

[Myles C. Maxfield]

Are there no existing libraries that can be conditionally linked with for 
supporting these formats? In the long term, it seems like bad design to have 
WebKit have its own custom decoders.

If that isn't an option, it seems fine to me provided that the decoders' 
sources are all close together (for some definition of close) and not peppered 
throughout WebKit.

> On Mar 19, 2015, at 9:38 PM, ChangSeok Oh  wrote:
> 
> Hi WebKittens.
> 
> I just saw apng support landed on webkit main stream. [1] (even it works for 
> gtk port only now)
> So I suddenly wonder if webkit community is getting interested in bringing 
> other modern image formats like webp or jpeg-xr into webkit.
> If so, I can lend my hands for it.
> 
> For webp support, as you know, we can reuse blink's codebase. [2]
> For jpeg-xr supprot, I have a rough sketch for it [3] (it might be outdated 
> or not fit tot of webkit though, bringing it to webkit is just a piece of 
> cake. ;))
> 
> My intention is not to argue which format is better, just to ask community's 
> thoughts, preferences  or like that.
> 
> [1] https://bugs.webkit.org/show_bug.cgi?id=17022
> [2] 
> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/image-decoders/webp/WEBPImageDecoder.cpp&q=webpima&sq=package:chromium&l=1
> [3] 
> http://cgit.collabora.com/git/user/kevino/Blink.git/commit/?h=jxr-support&id=2ac58312a5aae502aacc1c55c0bfdff767ab82a2
> 
> BR.
> 
> -- 
> ChangSeok
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Modern image formats for WebKit

[ChangSeok Oh]

> Are there no existing libraries that can be conditionally linked with for 
> supporting these formats? In the long term, it seems like bad design to have 
> WebKit have its own custom decoders.

Yes. there are of course. libwebp, libjxr are available on linux based systems 
and also seem available on mac and Windows. [1]
Both are BSD license so that there is no license issue to port them for any 
platforms if necessary.
I’m not telling about inventing new wheels for them, but adding a kind of a 
glue layer in webkit as png, gif and png supports do. ;) (e.g PNGImageDecoder.* 
JPEGImageDecoder.*)

[1] https://developers.google.com/speed/webp/download 

 https://jxrlib.codeplex.com/releases/view/107208 

 https://packages.debian.org/wheezy/webp 

 https://packages.debian.org/sid/utils/libjxr-tools 



ChangSeok

> On Mar 20, 2015, at 2:21 PM, Myles C. Maxfield  wrote:
> 
> Are there no existing libraries that can be conditionally linked with for 
> supporting these formats? In the long term, it seems like bad design to have 
> WebKit have its own custom decoders.
> 
> If that isn't an option, it seems fine to me provided that the decoders' 
> sources are all close together (for some definition of close) and not 
> peppered throughout WebKit.
> 
>> On Mar 19, 2015, at 9:38 PM, ChangSeok Oh  wrote:
>> 
>> Hi WebKittens.
>> 
>> I just saw apng support landed on webkit main stream. [1] (even it works for 
>> gtk port only now)
>> So I suddenly wonder if webkit community is getting interested in bringing 
>> other modern image formats like webp or jpeg-xr into webkit.
>> If so, I can lend my hands for it.
>> 
>> For webp support, as you know, we can reuse blink's codebase. [2]
>> For jpeg-xr supprot, I have a rough sketch for it [3] (it might be outdated 
>> or not fit tot of webkit though, bringing it to webkit is just a piece of 
>> cake. ;))
>> 
>> My intention is not to argue which format is better, just to ask community's 
>> thoughts, preferences  or like that.
>> 
>> [1] https://bugs.webkit.org/show_bug.cgi?id=17022
>> [2] 
>> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/image-decoders/webp/WEBPImageDecoder.cpp&q=webpima&sq=package:chromium&l=1
>> [3] 
>> http://cgit.collabora.com/git/user/kevino/Blink.git/commit/?h=jxr-support&id=2ac58312a5aae502aacc1c55c0bfdff767ab82a2
>> 
>> BR.
>> 
>> -- 
>> ChangSeok
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev

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