e need help with the bindings!
>
> I’d really like to revive my IPython console in Kate :D
>
> Best, Philipp
>
> Shaheed Haque schrieb am Sa., 13. Jan. 2018 um
> 19:06 Uhr:
>
>> Thanks to some upstream fixes, I have the cppyy-based bindings for KF5
>> and also
Hi Luca,
On 15 January 2018 at 08:24, Luca Beltrame wrote:
> Il giorno Sat, 13 Jan 2018 18:05:45 +
> Shaheed Haque ha scritto:
>
> Hello Shaheed,
>
> >1. The packaging has advanced to the point where I think ECM-based
> >framework-by-framework bindings a
Thanks to some upstream fixes, I have the cppyy-based bindings for KF5 and
also Qt5 (see below) showing signs of life. Notes:
1. The packaging has advanced to the point where I think ECM-based
framework-by-framework bindings are a real possibility, with both Py2 and
Py3. AFAICS, this add
shaheed added inline comments.
INLINE COMMENTS
> turbov wrote in FindPythonModuleGeneration.cmake:217
> As for me, I would remove whole this part of "brute forcing" available clang
> version. I can't see how it could work w/o additional hints due a location
> of `libclang` is not a standard di
Hi all,
I just realised that the Python binding effort is not setting the default
visibility for symbols using the -fvisibility=xxx option when processing
the header files [1]. Of course I can see the export macros set by the
likes of attica_exports.h, but I don't see where the compiler default is
shaheed added inline comments.
INLINE COMMENTS
> shaheed wrote in FindPythonModuleGeneration.cmake:212
> The original code had a minimum requirement of either 3.8 or 3.9 (I don't
> recall exactly, but the code here implies 3.8 is the minimum). Newer versions
> are fine.
I remembered as soon as
shaheed added inline comments.
INLINE COMMENTS
> turbov wrote in FindPythonModuleGeneration.cmake:212
> What distribution is this? Why only 3.8 and 3.9?? Why not 4.0 or 5.0???
>
> I've just checked Ubuntu 14.04 (Clang 3.3 to 3.9 available) and 17.10 (up to
> 5.0 available)... installing `libcla
shaheed added a comment.
I'm afraid your's truly might take a bit of the blame. The basis of the logic
was likely my original Python code, which did just enough to make Ubuntu work.
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D8780
To: turbov
Cc: shah
I have made an attempt to get roughly all the bindings I was previously
attempting with SIP to be (a) generated and (b) built.
As of now, we have:
- Customisations with a diffstat that reads "21 files changed, 20
insertions(+), 48 deletions(-)".
- All but 5-6 of the formal tier 1, 2 and 3 framewo
Philipp,
On 5 November 2017 at 14:48, Philipp A. wrote:
> Hi Shaheed, Chris,
>
> Shaheed Haque schrieb am Sa., 4. Nov. 2017 um
> 18:35 Uhr:
>
>> FWIW, I already tried that (types.ModuleType is itself a perfectly
>> subclassable class!) […]
>>
>> Now, n
e on to the TODOs listed
earlier.
On 4 November 2017 at 17:35, Shaheed Haque wrote:
> Wim, Philipp,
>
> On 4 November 2017 at 16:45, Philipp A. wrote:
>> Hi Wim!
>>
>>> So now I have a (C++) namespace 'A' that bears no relationship to anything
>>
Wim, Philipp,
On 4 November 2017 at 16:45, Philipp A. wrote:
> Hi Wim!
>
>> So now I have a (C++) namespace 'A' that bears no relationship to anything
>> to do with the file system or any type of Python packaging: it exists only
>> in memory for the duration of the python session.
>
>
> Yeah, coo
Hi Philipp,
On 3 November 2017 at 14:09, Philipp A. wrote:
> Hi Shaheed,
>
> Shaheed Haque schrieb am Fr., 3. Nov. 2017 um 14:16
> Uhr:
>>
>> Philipp,
>>
>> - my overall understanding of this technique is that it may end up
>> being fragile, especia
Philipp,
On 3 November 2017 at 12:52, Philipp A. wrote:
> Hi Shaheed,
>
> Thank you so much for all your work!
>
>> a framework-by-framework integration of the binding generation logic (as
>> previously pioneered by Steve) probably cannot work in general because there
>> are cases where multiple
Albert,
On 2 November 2017 at 21:43, Albert Astals Cid wrote:
> El dijous, 2 de novembre de 2017, a les 18:22:38 CET, Shaheed Haque va
> escriure:
>> A progress update...
>>
>> On 24 October 2017 at 13:05, Shaheed Haque wrote:
>> > Hi all,
>> >
>
A progress update...
On 24 October 2017 at 13:05, Shaheed Haque wrote:
> Hi all,
>
> I have a preliminary version of the Cppyy bindings generator CMake
> support available here:
>
>
> https://bitbucket.org/wlav/cppyy-backend/pull-requests/6/an-interim-experimen
H_DIR some_framework_INCLUDE_DIRS
H_FILES )
Thanks, Shaheed
On 16 October 2017 at 16:16, Shaheed Haque wrote:
> As promised, here is an interim update on the investigation into the
> use of cppyy-based bindings for KF5 (and more...) instead of SIP-based
> bindings.
>
> Th
of
effort, I am hopeful that we can get to some REALLY
easy-to-develop-and-maintain bindings.
[1] There is a bug with the binding producing stuff for private definitions.
[2] There is a bug with missing globals.
On 7 September 2017 at 10:23, Shaheed Haque wrote:
> [ Copying in kde-frameworks-
shaheed added a comment.
In https://phabricator.kde.org/D7736#154948, @jasontibbitts wrote:
> I hate to add a ping without any useful review, but I'm quite interested in
this effort as I have a pykde4-based application which I would really like to
get ported to the modern frameworks. Cu
shaheed added a comment.
My suggestion would be to focus any review efforts in this order:
1. files in the top level directory.
2. possibly files the ./templates subdirectory.
3. __init__.py and CMakelists.txt in the ./PyKF5 subdirectory. Ignore all
other files therein.
REPOSITORY
shaheed added inline comments.
INLINE COMMENTS
> lbeltrame wrote in CMakeLists.txt:49
> Don't use `find_package(FOO REQUIRED)`. Use `find_package(FOO)` then
> `set_package_properties(FOO TYPE REQUIRED...`. There are many examples in KDE
> git you can use. You will need to include FeatureSummary
shaheed added a comment.
My comments here are phrased as if this SIP-based approach was the solution
eventually adopted (cppyy might be different). With that said...
This...
> (this thing is huge).
and this...
> One question: would it be possible to have the bindings per-fr
shaheed edited the summary of this revision.
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D7736
To: shaheed, lbeltrame
Cc: #frameworks, #build_system
shaheed retitled this revision from "Not-to-be-merged review fo Python bindings
generator" to "Not-to-be-merged review of Python bindings generator".
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D7736
To: shaheed, lbeltrame
Cc: #frameworks, #build_system
shaheed edited the summary of this revision.
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D7736
To: shaheed, lbeltrame
Cc: #frameworks, #build_system
shaheed created this revision.
Restricted Application added projects: Frameworks, Build System.
Restricted Application added subscribers: Build System, Frameworks.
REVISION SUMMARY
As per https://marc.info/?l=kde-core-devel&m=150464598710128&w=2, this is a
snapshot of the current state of the S
[ Copying in kde-frameworks-devel as suggested ]
On 5 September 2017 at 22:12, Shaheed Haque wrote:
> A lot of progress has been made in the last 18 months or so:
>
> THE TOOLING
> ===
>
> We have:
>
> - A pretty powerful KDE-independent automatic bindi
shaheed added a comment.
I did some negative testing, and from what I can see, 3.8 might well be OK
for the ECM fork. My version depends on 3.9 (for example, there are some
new constants defined by clang which I use), but I've no idea if this will
ever be merged.
REPOSITORY
R240 Extra
shaheed added subscribers: kde-buildsystem, shaheed.
shaheed added a comment.
Fwiw, I think that a specific version check may not be needed. The original
code I wrote, which I assume Steve may have simply carried forward in the
cmake ecm logic, DID have a version check but only because the
shaheed added inline comments.
INLINE COMMENTS
> skelly wrote in sip_generator.py:172
> It was possible to handle exports without looking for the text EXPORT in the
> MACRO NAME. Why is deprecated different?
Because the expansion of the attribute in this case contains not a string, but
a compi
shaheed added inline comments.
INLINE COMMENTS
> skelly wrote in rules_engine.py:494
> Does the docs match the code if you add this here? Why is this in this commit?
Yes. Why not?
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D4509
EMAIL PREFERENCES
htt
shaheed added a comment.
I think the scope of the changes in this commit are perfectly reasonable. I
don't think it is unreasonable to group them either.
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D4509
EMAIL PREFERENCES
https://phabricator.kde.org
shaheed added inline comments.
INLINE COMMENTS
> skelly wrote in rules_engine.py:58
> I don't think this should be here.
I disagree. Having this in the code suppresses the false positives which are
caused by the "_" used by gettext.
> skelly wrote in rules_engine.py:704
> I don't think the com
shaheed added a comment.
The PEP-8 changes are some blank line changes.
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D4509
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: shaheed, #build_system, #frameworks, skelly
shaheed created this revision.
shaheed set the repository for this revision to R240 Extra CMake Modules.
Restricted Application added projects: Frameworks, Build System.
Restricted Application added subscribers: Build System, Frameworks.
TEST PLAN
Add to the unit tests and verify the result is m
shaheed retitled this revision from "Some comment-only tidyups and PEP-8
fixes." to "Python bindings: Some comment-only tidyups and PEP-8 fixes.".
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D4509
EMAIL PREFERENCES
https://phabricator.kde.org/settings/p
shaheed created this revision.
shaheed set the repository for this revision to R240 Extra CMake Modules.
Restricted Application added projects: Frameworks, Build System.
Restricted Application added subscribers: Build System, Frameworks.
TEST PLAN
No code changes.
REPOSITORY
R240 Extra CMake
uiAddonsmod.sip is
not removed. It is only ever created when cmake is run.
Is this as expected?
On 18 January 2017 at 21:16, Stephen Kelly wrote:
> On 01/18/2017 12:41 PM, Shaheed Haque wrote:
> > Hi Steve,
> >
> > I have verified this works on KDE/master, and will close th
.. Passed0.53 sec
Start 6: kiconutilstest
6/6 Test #6: kiconutilstest ... Passed0.08 sec
100% tests passed, 0 tests failed out of 6
Total Test time (real) = 1.03 sec
Thanks,
Shaheed Haque
//git.reviewboard.kde.org/r/129760/
>>
>> On January 5th, 2017, 10:56 p.m. UTC, *Stephen Kelly* wrote:
>>
>> I've added the change to the unit test. It already passes, so it's not clear
>> to me what else is needed from this review request.
>>
>> On
7;ve added the change to the unit test. It already passes, so it's not clear
> to me what else is needed from this review request.
>
> On January 5th, 2017, 11:06 p.m. UTC, *Shaheed Haque* wrote:
>
> What version of SIP compiler and C++ compiler are you using? I'm on:
>
&
> On Jan. 5, 2017, 10:56 p.m., Stephen Kelly wrote:
> > I've added the change to the unit test. It already passes, so it's not
> > clear to me what else is needed from this review request.
>
> Shaheed Haque wrote:
> What version of SIP compiler and
kde.org/r/129760/#review101827
---
On Jan. 3, 2017, 12:47 p.m., Shaheed Haque wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
>
... Passed0.08 sec
100% tests passed, 0 tests failed out of 6
Total Test time (real) = 1.03 sec
Thanks,
Shaheed Haque
44 matches
Mail list logo
