[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:18:55
Message-ID: CAHAc2jcP6NDiR-m=1aVaYx3LhgrxeCS_kVKH3=DSgomOn6+-Gg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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>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">http://c \
ommits.kde.org/pykde5/86e8bdb1ac3e5245cea7c9191c8fbc09dc958066</a><br><br></div></div><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 class="">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 class=""><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 class="HOEnZb"><div class="h5"><br>
Thanks,<br>
<br>
Steve.<br>
_______________________________________________<br>
Kde-bindings mailing list<br>
<a href="mailto:Kde-bindings@kde.org">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>
[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