Bug 145867

Created attachment 254701 [details] WIP

Created attachment 255055 [details] WIP

Created attachment 255084 [details] WIP

Comment on attachment 255084 [details] WIP View in context: https://bugs.webkit.org/attachment.cgi?id=255084&action=review > Source/WebKit2/Shared/AsyncTask.h:61 > - m_taskFunction = [callee, method, arguments...] { > - (callee->*method)(arguments...); > - }; > + // m_taskFunction = [callee, method, arguments...] { > + // (callee->*method)(arguments...); > + // }; We will require at least GCC 4.9.0 or clang to build this code. I don't have any objection against bumping, but I will have to install newer GCC on the ARM bots before we do it. The question is if it is reasonable for the EFL port maintainers. In nutshell bumping means we will require at least Ubuntu 14.10. > Source/WebKit2/Shared/efl/KeyedDecoder.cpp:1 > +/* Why don't we simply reuse GTK's KeyedEncoder/KeyedDecoder? Their implementation only needs glib, nothing else.

(In reply to comment #4) > Comment on attachment 255084 [details] > WIP > > View in context: > https://bugs.webkit.org/attachment.cgi?id=255084&action=review > > > Source/WebKit2/Shared/AsyncTask.h:61 > > - m_taskFunction = [callee, method, arguments...] { > > - (callee->*method)(arguments...); > > - }; > > + // m_taskFunction = [callee, method, arguments...] { > > + // (callee->*method)(arguments...); > > + // }; > > We will require at least GCC 4.9.0 or clang to build this code. > I don't have any objection against bumping, but I will have > to install newer GCC on the ARM bots before we do it. > > The question is if it is reasonable for the EFL port maintainers. > > In nutshell bumping means we will require at least Ubuntu 14.10. Yes, I also think now is time to consider to bump Ubuntu ver. Let me send a mail to webkit-efl soon. > > Source/WebKit2/Shared/efl/KeyedDecoder.cpp:1 > > +/* > > Why don't we simply reuse GTK's KeyedEncoder/KeyedDecoder? > Their implementation only needs glib, nothing else. If there won't any need supported by EFL, it would be good to use GTK's KeyedDecoder.cpp. Let me check it further.

*** Bug 139643 has been marked as a duplicate of this bug. ***

(In reply to comment #3) > Created attachment 255084 [details] > WIP The patch here is the older one, so I closed the other bug as duplicated. (In reply to comment #6) > *** Bug 139643 has been marked as a duplicate of this bug. *** Do we really need ecore things in platformInitialize/platformFinalize ? Additionally we should add executablePathOfDatabaseProcess() implementation from bug139643 with adding credit to Joonghun.

And I still think we should reuse GTK's KeyedEncoder/KeyedDecoder implementation which need only glib, nothing GTK specific. We could simply move these files from gtk to glib directory.

*** Bug 144625 has been marked as a duplicate of this bug. ***

Created attachment 256640 [details] Patch

(In reply to comment #8) > And I still think we should reuse GTK's KeyedEncoder/KeyedDecoder > implementation which need only glib, nothing GTK specific. > We could simply move these files from gtk to glib directory. Done. I agree with that.

(In reply to comment #7) > Do we really need ecore things in platformInitialize/platformFinalize ? > Additionally we should add executablePathOfDatabaseProcess() implementation > from bug139643 with adding credit to Joonghun. Joonghun, please upload a patch to add executablePathOfDatabaseProcess() after landing this patch.

(In reply to comment #12) > (In reply to comment #7) > Do we really need ecore things in > platformInitialize/platformFinalize ? > Additionally we should add > executablePathOfDatabaseProcess() implementation > from bug139643 with > adding credit to Joonghun. Joonghun, please upload a patch to add > executablePathOfDatabaseProcess() after landing this patch. Ok, please leave it to me. :)

Ossy ping ? Could you take a look this patch ?

Comment on attachment 256640 [details] Patch LGTM. And we can enable it too with executablePathOfDatabaseProcess patch if the tests pass.

(In reply to comment #15) > Comment on attachment 256640 [details] > Patch > > LGTM. > > And we can enable it too with executablePathOfDatabaseProcess patch if the > tests pass. yes, joonghun is going to upload a patch to add executablePathOfDatabaseProcess().

Comment on attachment 256640 [details] Patch Rejecting attachment 256640 [details] from commit-queue. Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.appspot.com', '--bot-id=webkit-cq-01', 'apply-attachment', '--no-update', '--non-interactive', 256640, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit Last 500 characters of output: .h rm 'Source/WebKit2/Shared/gtk/KeyedDecoder.h' patching file Source/WebKit2/Shared/gtk/KeyedEncoder.cpp rm 'Source/WebKit2/Shared/gtk/KeyedEncoder.cpp' patching file Source/WebKit2/Shared/gtk/KeyedEncoder.h rm 'Source/WebKit2/Shared/gtk/KeyedEncoder.h' patching file Source/WebKit2/UIProcess/Databases/efl/DatabaseProcessProxyEfl.cpp Failed to run "[u'/Volumes/Data/EWS/WebKit/Tools/Scripts/svn-apply', '--force', '--reviewer', u'Csaba Osztrogon\xe1c']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit Full output: http://webkit-queues.appspot.com/results/6571805431037952

Created attachment 257267 [details] Patch for landing

Comment on attachment 257267 [details] Patch for landing Clearing flags on attachment: 257267 Committed r187191: <http://trac.webkit.org/changeset/187191>

All reviewed patches have been landed. Closing bug.