... wasn't there also some python related work by Stefan? Or is that
unrelated?
Greetings
Dominik
Am Mo., 5. Nov. 2018, 16:20 hat Shaheed Haque
geschrieben:
> I'm afraid that there has been no progress as I am buried in "startup"
> mode. I'm not sure when that might change.
>
> On Mon, 5 Nov 2
Hi Shaheed!
The year is nearing its end, and I wonder if there has been any progress
and/or if you people 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 fixe
I'm afraid that there has been no progress as I am buried in "startup"
mode. I'm not sure when that might change.
On Mon, 5 Nov 2018, 14:02 Philipp A. Hi Shaheed!
>
> The year is nearing its end, and I wonder if there has been any progress
> and/or if you people need help with the bindings!
>
> I
On Sun, Jan 14, 2018 at 7:05 AM, Shaheed Haque wrote:
> Thanks to some upstream fixes, I have the cppyy-based bindings for KF5 and
> also Qt5 (see below) showing signs of life. Notes:
Hi Shaheed,
>
> The packaging has advanced to the point where I think ECM-based
> framework-by-framework binding
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 are a real possibility, with b
El dissabte, 13 de gener de 2018, a les 18:05:45 CET, Shaheed Haque va
escriure:
> Thanks to some upstream fixes, I have the cppyy-based bindings for KF5 and
> also Qt5 (see below) showing signs of life.
> Notes:
This is awesome, i'm really happy we're in a point that framework-by-framework
is
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
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, none of that may be a limiting factor in the
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, none of that may be a limiting factor in the plan you seem to be
> discussing, but it was part of what made me thin
> On Nov 4, 2017, at 4:46 AM, Philipp A. wrote:
>
> Entirely new bindings lead to new applications being written using those
> bindings. Writing applications in Python 2 is an immediate maintenance burden
> and people only do it because of stubborn ideology or a complete lack of
> awareness
On Sat, 4 Nov 2017, Chris Burel wrote:
> I think this is a remarkably short sighted statement. It assumes that people
> that would use these bindings have no existing Python codebase at all, and
> can afford to start a brand new project. The reality is much different.
>
> Let's take a specific
There is a POC-quality implementation of the integration with KDE here:
https://cgit.kde.org/pykde5.git/tree/?h=srhaque-cppyy-bindings&id=19a94fb3ae2b40a985913ed4e49400e02df56dc2
This contains examples of bindings for Akonadi and KDcraw. My next
steps will be to do a few more, and then move on to
Hi Shaheed,
Thank you for the clarifications!
My observation is that *nobody* is likely to help with that problem: the
> framework owners did
> nothing obvious to either keep PyKDE4 going (out of tree) or to help
> Steve with my earlier SIP based efforts (in tree).
>
It's a bit sad, but not too
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, cool, so we just use a path hook and are ready to go right?
https://www.pyth
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,
On Friday 2017-11-03 12:52, Philipp A. wrote:
Am I missing something? Namespaces should be Python modules, not classes.
If we can do represent them this way, the problem is solveable:
https://packaging.python.org/guides/packaging-namespace-packages/
there are two different things that shou
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, especially given the difference between P2 and P3.
>
Python 2? I’m sure we shouldn’t include into our decision making an
obsole
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, especially given the difference between P2 and P3.
>
>
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
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 frameworks contribute to to the same C++
> namespace […]
>
> The prob
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,
>> >
>> > I have a preliminary version of the Cppyy bind
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,
> >
> > I have a preliminary version of the Cppyy bindings generator CMake
> >
> > support available here:
> > https://b
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-experimental-version-of-a/diff
>
> There
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-experimental-version-of-a/diff
There are some TODOs yet to be addressed, but I would appreciate
feedback on how easy it woul
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.
The first thing is that the underlying technology of cppyy,
cling/ROOT, has been under development at CERN for quite a while. It
directly reads regu
26 matches
Mail list logo