[webkit-dev] Rewriting binding code generator, maybe?

2013-06-11 Thread wkcensorshipbypass00010
Niwa, hi, CodeGenerator has already been rewritten in python, combining the following: * Mozilla's xpcom xpidl.py generator * gobject's codegen.py The following work was done: - The xpidl generator was modified to understand Webkit's IDL file format - gobject's codegen.py was modified to

[webkit-dev] Rewriting binding code generator, maybe?

2013-06-11 Thread wkcensorshipbypass00011
Apologies, the link is here: http://git.savannah.gnu.org/cgit/pythonwebkit.git/tree/pywebkitgtk/wkcodegen?h=python_codegen ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-06-11 Thread Filip Pizlo
I think the best way to make such points is to create a bug and post a patch. -Filip On Jun 11, 2013, at 1:32 PM, wkcensorshipbypass00...@mailinator.com wrote: Niwa, hi, CodeGenerator has already been rewritten in python, combining the following: * Mozilla's xpcom xpidl.py generator *

Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-30 Thread Joe Mason
I could have sworn I saw someone in another thread post that they were interested in taking over maintenance of the binding generators (not necessarily relating to a massive rewrite, just for ongoing maintenance, was my impression). But I can't find that email at all now. Does anyone know who

Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-11 Thread Thiago Marcos P. Santos
On Thu, Apr 11, 2013 at 1:36 AM, Eric Seidel e...@webkit.org wrote: I know some folks in our TOK office have expressed strong interest in re-writing it in python for Blink. Perhaps there is an opportunity for some x-project collaboration here. Would be great if both projects could share the

Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-11 Thread Darin Adler
On Apr 11, 2013, at 5:02 AM, Thiago Marcos P. Santos tmpsan...@gmail.com wrote: Would be great if both projects could share the same generators. The part that would be OK to share would be the parsing. The actual code generation needs to change all the time as the internal architecture of

Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-11 Thread Darin Adler
On Apr 11, 2013, at 9:51 AM, Darin Adler da...@apple.com wrote: The actual code generation needs to change all the time as the internal architecture of WebKit and of the JavaScript engine and other things we’re binding change, so we should not try to change that. I meant “we should not try

Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-11 Thread Dirk Pranke
On Thu, Apr 11, 2013 at 9:51 AM, Darin Adler da...@apple.com wrote: On Apr 11, 2013, at 5:02 AM, Thiago Marcos P. Santos tmpsan...@gmail.com wrote: Would be great if both projects could share the same generators. The part that would be OK to share would be the parsing. The actual code

Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-11 Thread Ryosuke Niwa
On Thu, Apr 11, 2013 at 10:12 AM, Dirk Pranke dpra...@chromium.org wrote: On Thu, Apr 11, 2013 at 9:51 AM, Darin Adler da...@apple.com wrote: On Apr 11, 2013, at 5:02 AM, Thiago Marcos P. Santos tmpsan...@gmail.com wrote: Would be great if both projects could share the same generators.

Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-11 Thread Tim Mahoney
On Apr 11, 2013, at 10:12 AM, Dirk Pranke dpra...@chromium.org wrote: I'm not sure how useful a suggestion this is, but ANTLR has a pretty strong framework for separating parsing from code generation and seems like it would be an ideal fit for this… Speaking of other tools, this might be a

Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-11 Thread Leandro Pereira
dpranke, On 04/11/2013 02:12 PM, Dirk Pranke wrote: I'm not sure how useful a suggestion this is, but ANTLR has a pretty strong framework for separating parsing from code generation and seems like it would be an ideal fit for this, except that the tool itself is written in Java. Perhaps that

Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-11 Thread Eric Seidel
I retract my earlier statement. I think that the constraints here between WebKit and blink are different enough that we should only re-examine sharing code after both projects have had a chance to re-write this subsystem to better fit their needs. We originally imported these bindings generators

Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-11 Thread Dirk Pranke
On Thu, Apr 11, 2013 at 10:29 AM, Leandro Pereira lean...@profusion.mobiwrote: dpranke, On 04/11/2013 02:12 PM, Dirk Pranke wrote: I'm not sure how useful a suggestion this is, but ANTLR has a pretty strong framework for separating parsing from code generation and seems like it would be

[webkit-dev] Rewriting binding code generator, maybe?

2013-04-10 Thread Ryosuke Niwa
Hi, Can we rewrite CodeGenerator*.pm in Ruby or Python? I feel that the current code is very hard to understand and hack on. In particular we have CodeGenerator.pm and CodeGeneratorJS.pm (CodeGeneratorV8.pm has been removed), and we need to merge them anyway. I've seen many people expressing

Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-10 Thread Eric Seidel
I know some folks in our TOK office have expressed strong interest in re-writing it in python for Blink. Perhaps there is an opportunity for some x-project collaboration here. On Wed, Apr 10, 2013 at 3:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi, Can we rewrite CodeGenerator*.pm in Ruby or

Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-10 Thread Kentaro Hara
I know some folks in our TOK office have expressed strong interest in re-writing it in python for Blink. Yeah, I'm planning (but in low priority) to rewrite it in Python after cleaning up IDLs and code generators. The difficulty is that CodeGenerator*.pm are not the only target for rewriting.

Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-10 Thread Timothy Hatcher
On Apr 10, 2013, at 6:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Can we rewrite CodeGenerator*.pm in Ruby or Python? I feel that the current code is very hard to understand and hack on. In particular we have CodeGenerator.pm and CodeGeneratorJS.pm (CodeGeneratorV8.pm has been removed),

Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-10 Thread Maciej Stachowiak
As a person who does not know any of Perl, Python or Ruby very well, I find unfamiliar Python the easiest to understand (even though I have more experience with Perl). I feel this would be worthwhile, if not necessarily a top priority. I do hope that this could be done without undue increase

Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-10 Thread Dirk Pranke
On Wed, Apr 10, 2013 at 4:59 PM, Timothy Hatcher timo...@apple.com wrote: On Apr 10, 2013, at 6:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Can we rewrite CodeGenerator*.pm in Ruby or Python? I feel that the current code is very hard to understand and hack on. In particular we have

Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-10 Thread Kentaro Hara
I've seen many people expressing their inability to improve the binding code because of its being written in Perl. Although I agree that the complexity of the binding code partly comes from the fact that it's written in Perl, another big reason is that current code generators are more

Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-10 Thread Timothy Hatcher
On Apr 10, 2013, at 8:17 PM, Kentaro Hara hara...@chromium.org wrote: Now that JSC is the only engine in WebKit and V8 is the only engine in V8, we both can remove a bunch of unnecessary abstractions and IDL attributes that had existed to share code between JSC and V8. In short-term, this

Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-10 Thread Tim Mahoney
If a rewrite does happen, it would be nice to have some generic functionality abstracted away from the specific language generators. For example, the function to add an #include statement to the generated implementation file is currently replicated for every language. JS and V8 have