[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-bindings
Subject: Re: [Kde-bindings] Progress report on Py*5 binding generation
From: Shaheed Haque <srhaque () theiet ! org>
Date: 2016-05-01 10:24:40
Message-ID: CAHAc2jcmozQzC+TiX7n5kRhuWdVcCioCi9HjPcQZfagy99AUZA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I forgot to add...
The present code includes a change to the way the sip["decl"] entry is used
in function rules. Instead of being the ", ".join() of all the function
arguments on input to the rule's functor, this is now just the array of
function arguments. The functor should just modify the array as needed
instead of returning a string. The same applies to
sip["template_parameters"].
I'm hoping this is not overly disruptive for you!
Thanks, Shaheed
On 1 May 2016 at 11:18, Shaheed Haque <srhaque@theiet.org> wrote:
> Steve,
>
> I've still not yet had a chance to catch up with all your good works, but
> I have just pushed what I consider usable %MethodCode injection [1]. This
> includes a naive forward port of the PyKDE4 %MethodCode fragments. The
> documentation is updated too. With luck this should provide a good template
> for other forms of code injection. %TypeCode is the obvious next target,
> and with that in place, I think we'll have all the logic in place to
> support most anything PyKDE4 could do but in a sustainable manner.
>
> I'm still in a bit of a crunch time here for the next few weeks, but will
> try to make time to look at your fork and maybe %TypeCode.
>
> FWIW, the naive forward port of the PyKDE4 fragments is more or less a
> simple import of the original code, and this clearly does not apply in many
> cases. What is there is intended more as a demonstration of the techniques
> of using either fixed strings, or functions to generate the custom code
> needed. In support of this, the sip_bulk_generator has a new option which
> can be used to identify rules which have not fired, and likely need to be
> rethought.
>
> Thanks, Shaheed
>
> [1] http://commits.kde.org/pykde5/86e8bdb1ac3e5245cea7c9191c8fbc09dc958066
>
>
> On 30 April 2016 at 14:42, Stephen Kelly <steveire@gmail.com> wrote:
>
>> Shaheed Haque wrote:
>>
>> > +1 for the modular CMake-based stuff.
>> >
>> > If you can get that going without all the sip_bulk_generator stuff, then
>> > that is great,
>>
>> Cool. I have completed some more work on particular frameworks and I
>> created
>> a cmake build for convenience:
>>
>> https://github.com/steveire/frameworks-bindings
>>
>> Build it all with
>>
>> $ mkdir build && cd build
>> $ cmake ..
>> $ make
>>
>> $ ls prefix/lib/python3.5/dist-packages/PyKF5/
>> __init__.py KAuth.so KCodecs.so KCompletion.so KConfigCore.so
>> KConfigGui.so KConfigWidgets.so KCoreAddons.so KDBusAddons.so
>> KGuiAddons.so KI18n.so KItemModels.so KJobWidgets.so
>> KWidgetsAddons.so
>>
>> I still haven't written tests for the generated python modules yet. There
>> are still some things to do before getting to that (namely integrating
>> your
>> MethodCode work).
>>
>> > I'm more focussed on getting through the volume of errors
>> > through automation because of the weaknesses in the Clang automation.
>>
>> I also made some changes to how the clang cindex stuff is used in the
>> sip_generator.py and in the rules_engine.py. I will soon integrate your
>> work
>> on %MethodCode injection into the extra-cmake-modules version of the code.
>> That should actually make the bindings actually useful, because up to now
>> I
>> have been
>>
>> I encourage you to have a look at what is in the extra-cmake-modules and
>> other repos in the mean-time. I have modularized the rules and made it
>> possible to re-use the generic Qt5 rules in the modules, but in a bit of a
>> hacky way. I think more refactoring should be done on the sip_generator
>> and
>> rules to make that kind of thing more of an integral part of the design.
>>
>> However, I don't want to do major refactoring of the version in the extra-
>> cmake-modules repo while you are still changing the version in the pykde5
>> repo.
>>
>> It would be better to not have divergent versions of the generator. Can I
>> somehow convince you to continue your work with the modularized approach?
>> That would eliminate the work created by having divergent versions, and
>> would mean that we are creating modularized bindings, which I think we
>> agree
>> are desirable? It will result in shippable bindings quite quickly as far
>> as
>> I can see.
>>
>> Thanks,
>>
>> Steve.
>> _______________________________________________
>> Kde-bindings mailing list
>> Kde-bindings@kde.org
>> https://mail.kde.org/mailman/listinfo/kde-bindings
>>
>
>
[Attachment #5 (text/html)]
<div dir="ltr"><div><div><div>I forgot to add...<br><br></div>The present code \
includes a change to the way the sip["decl"] entry is used in function \
rules. Instead of being the ", ".join() of all the function arguments on \
input to the rule's functor, this is now just the array of function arguments. \
The functor should just modify the array as needed instead of returning a string. The \
same applies to sip["template_parameters"].<br><br></div>I'm hoping \
this is not overly disruptive for you!<br><br></div>Thanks, \
Shaheed<br><div><br></div></div><div class="gmail_extra"><br><div \
class="gmail_quote">On 1 May 2016 at 11:18, Shaheed Haque <span dir="ltr"><<a \
href="mailto:srhaque@theiet.org" target="_blank">srhaque@theiet.org</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Steve,<br><br></div>I've \
still not yet had a chance to catch up with all your good works, but I have just \
pushed what I consider usable %MethodCode injection [1]. This includes a naive \
forward port of the PyKDE4 %MethodCode fragments. The documentation is updated too. \
With luck this should provide a good template for other forms of code injection. \
%TypeCode is the obvious next target, and with that in place, I think we'll have \
all the logic in place to support most anything PyKDE4 could do but in a sustainable \
manner.<br><br></div>I'm still in a bit of a crunch time here for the next few \
weeks, but will try to make time to look at your fork and maybe \
%TypeCode.<br><div><br></div><div>FWIW, the naive forward port of the PyKDE4 \
fragments is more or less a simple import of the original code, and this clearly does \
not apply in many cases. What is there is intended more as a demonstration of the \
techniques of using either fixed strings, or functions to generate the custom code \
needed. In support of this, the sip_bulk_generator has a new option which can be used \
to identify rules which have not fired, and likely need to be \
rethought.<br></div><div><br></div><div>Thanks, Shaheed<br></div><div><br>[1] <a \
href="http://commits.kde.org/pykde5/86e8bdb1ac3e5245cea7c9191c8fbc09dc958066" \
target="_blank">http://commits.kde.org/pykde5/86e8bdb1ac3e5245cea7c9191c8fbc09dc958066</a><br><br></div></div><div \
class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div \
class="gmail_quote">On 30 April 2016 at 14:42, Stephen Kelly <span dir="ltr"><<a \
href="mailto:steveire@gmail.com" target="_blank">steveire@gmail.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><span>Shaheed Haque wrote:<br> <br>
> +1 for the modular CMake-based stuff.<br>
><br>
> If you can get that going without all the sip_bulk_generator stuff, then<br>
> that is great,<br>
<br>
</span>Cool. I have completed some more work on particular frameworks and I \
created<br> a cmake build for convenience:<br>
<br>
<a href="https://github.com/steveire/frameworks-bindings" rel="noreferrer" \
target="_blank">https://github.com/steveire/frameworks-bindings</a><br> <br>
Build it all with<br>
<br>
$ mkdir build && cd build<br>
$ cmake ..<br>
$ make<br>
<br>
$ ls prefix/lib/python3.5/dist-packages/PyKF5/<br>
__init__.py KAuth.so KCodecs.so KCompletion.so KConfigCore.so<br>
KConfigGui.so KConfigWidgets.so KCoreAddons.so KDBusAddons.so<br>
KGuiAddons.so KI18n.so KItemModels.so KJobWidgets.so KWidgetsAddons.so<br>
<br>
I still haven't written tests for the generated python modules yet. There<br>
are still some things to do before getting to that (namely integrating your<br>
MethodCode work).<br>
<span><br>
> I'm more focussed on getting through the volume of errors<br>
> through automation because of the weaknesses in the Clang automation.<br>
<br>
</span>I also made some changes to how the clang cindex stuff is used in the<br>
sip_generator.py and in the rules_engine.py. I will soon integrate your work<br>
on %MethodCode injection into the extra-cmake-modules version of the code.<br>
That should actually make the bindings actually useful, because up to now I<br>
have been<br>
<br>
I encourage you to have a look at what is in the extra-cmake-modules and<br>
other repos in the mean-time. I have modularized the rules and made it<br>
possible to re-use the generic Qt5 rules in the modules, but in a bit of a<br>
hacky way. I think more refactoring should be done on the sip_generator and<br>
rules to make that kind of thing more of an integral part of the design.<br>
<br>
However, I don't want to do major refactoring of the version in the extra-<br>
cmake-modules repo while you are still changing the version in the pykde5<br>
repo.<br>
<br>
It would be better to not have divergent versions of the generator. Can I<br>
somehow convince you to continue your work with the modularized approach?<br>
That would eliminate the work created by having divergent versions, and<br>
would mean that we are creating modularized bindings, which I think we agree<br>
are desirable? It will result in shippable bindings quite quickly as far as<br>
I can see.<br>
<div><div><br>
Thanks,<br>
<br>
Steve.<br>
_______________________________________________<br>
Kde-bindings mailing list<br>
<a href="mailto:Kde-bindings@kde.org" target="_blank">Kde-bindings@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-bindings" rel="noreferrer" \
target="_blank">https://mail.kde.org/mailman/listinfo/kde-bindings</a><br> \
</div></div></blockquote></div><br></div> </div></div></blockquote></div><br></div>
[Attachment #6 (text/plain)]
_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic