Re: [Pdl-general] PDL::OpenCV update

[Ingo Schmid]

Hi Ed,

no coding time at the moment, sorry. I will try to squeeze that in tonight.

Let me just say that I do not understand why there needs to be one
common typemap file for all OpenCV modules while they have their own
separate makefiles etc. One single place for each module. This I was
talking about when using encapsulation.

Ingo

On 5/7/2022 6:10 PM, Ed . wrote:


Hi Ingo,

You raise very interesting and important points, which is why there
are quite a few words here!

The P:OpenCV distribution will have common infrastructure (the C and
PP definition wrappers’ generation code, and the XS typemap) among the
various non-“core” modules (VideoCapture and Tracker being two).

Shared infrastructure is better than having copies of things
everywhere, which becomes obvious as soon as part of such
infrastructure needs changing. Doing that in more than one place is
error-prone and time-consuming. That is the driving reality behind the
approach of DRY (don’t repeat yourself). It also makes for slightly
smaller distributions, which isn’t a bad thing either.

I appreciate your thought about “encapsulation”, but if you really,
truly wanted to have proper encapsulation you would bundle a full copy
of PDL with the distribution, as well as a full copy of Perl itself,
and also a C compiler, and perhaps (just in case) the operating system
– in each of the submodules (Tracker, VideoCapture, etc). I trust you
would agree with me that would not be a good idea. Ergo, while I like
the idea of being as backwardly-compatible as possible, we are already
there: I do not regard it as desirable to be compatible with earlier
versions of PDL.

Regarding the cross-dependencies you refer to between OpenCV modules,
your words sound like you are referring to something that still exists
in the code as currently in the repo. However, apart from the
initTracker and updateTracker, which I haven’t finished changing from
your versions yet (the “unpicking” I alluded to), no such
cross-dependency exists. The Tracker does not in any way need to know
about VideoCapture, which is why neither our code does that, nor does
the actual OpenCV library. Please help me understand what you were
referring to.

I am still waiting for the GDB stack trace of the segfault you
mentioned. Given all of us (including you) have limited time, I
believe it is the best use of time to start with providing bug-hunting
information /if asked for/, before zooming out to the strategic
thinking 

Best regards,

Ed

*From: *Ingo Schmid <mailto:ingo...@gmx.at>
*Sent: *07 May 2022 13:56
*To: *Ed . <mailto:ej...@hotmail.com>; perldl
<mailto:pdl-general@lists.sourceforge.net>
*Subject: *Re: [Pdl-general] PDL::OpenCV update

Hi Ed,

sorry, apparently I didn't see that warning. I think eventually,
PDL::OpenCV should not require such a recent PDL release, if
reasonably manageable. I say eventually, not in this early stage.

My point about typemaps in module directories is, once we start adding
modules left and right, updating one common typemap file is breaking
encapsulation and, I think, not needed. The P:O:Tracker should have a
typemap just for the TrackerWrapper, same for the VideoCapture, etc.

I would try to avoid cross-dependencies on the XS level if possible.
E.g. the tracker may need to know how to read videos, but can do that
using the VideoCapture perl interface, it does not require knowledge
of its typemap.

Does that make sense?

Ingo

On 5/7/2022 12:04 AM, Ed . wrote:

Hi Ingo and all,

The real kudos belongs to Ingo (as it does with the native complex
stuff), which is why the current opencv.pd there says “AUTHOR:
Ingo Schmid and the PDL Porters”. However! We aren’t at the level
of a releasable module yet, as evidenced by this segfault, and the
still-small number of bound functions.

The typemap is indeed not found on PDL 2.078 and below, because
the typemap-parsing code copy-pasted from ExtUtils::ParseXS in
PDL::PP only just got fixed. That was the prompt for me to push
out 2.079. You will have seen, when you ran Makefile.PL, it
warning that it didn’t have the required PDL 2.079. Please act on
that warning and install latest PDL 

To answer your specific question, no, a top-level typemap is
vastly better. Each pointer-type needs identical T_PTROBJ_SPECIAL
code, and it would be pointless duplication (and add to the
maintenance burden) to have it copied in each subdirectory. Please
take a look in the top-level typemap to see if you agree 

No, t/opencv_basic.t is not obsolete. If it is segfaulting, that
is a bug. Please first of all do “make realclean”, ensure you have
the latest released PDL, then if it is still happening, please
follow this process:

 1. Rerun “perl Makefile.PL” (this will update the timestamps on
Makefiles, prompting a full rebuild)
 2. Edit your generated top-level Makefile to add “-g” to the
“OPTIMIZE =” line to gene

Re: [Pdl-general] PDL::OpenCV update

[Ed .]

Hi Ingo,

You raise very interesting and important points, which is why there are quite a 
few words here!

The P:OpenCV distribution will have common infrastructure (the C and PP 
definition wrappers’ generation code, and the XS typemap) among the various 
non-“core” modules (VideoCapture and Tracker being two).

Shared infrastructure is better than having copies of things everywhere, which 
becomes obvious as soon as part of such infrastructure needs changing. Doing 
that in more than one place is error-prone and time-consuming. That is the 
driving reality behind the approach of DRY (don’t repeat yourself). It also 
makes for slightly smaller distributions, which isn’t a bad thing either.

I appreciate your thought about “encapsulation”, but if you really, truly 
wanted to have proper encapsulation you would bundle a full copy of PDL with 
the distribution, as well as a full copy of Perl itself, and also a C compiler, 
and perhaps (just in case) the operating system – in each of the submodules 
(Tracker, VideoCapture, etc). I trust you would agree with me that would not be 
a good idea. Ergo, while I like the idea of being as backwardly-compatible as 
possible, we are already there: I do not regard it as desirable to be 
compatible with earlier versions of PDL.

Regarding the cross-dependencies you refer to between OpenCV modules, your 
words sound like you are referring to something that still exists in the code 
as currently in the repo. However, apart from the initTracker and 
updateTracker, which I haven’t finished changing from your versions yet (the 
“unpicking” I alluded to), no such cross-dependency exists. The Tracker does 
not in any way need to know about VideoCapture, which is why neither our code 
does that, nor does the actual OpenCV library. Please help me understand what 
you were referring to.

I am still waiting for the GDB stack trace of the segfault you mentioned. Given 
all of us (including you) have limited time, I believe it is the best use of 
time to start with providing bug-hunting information if asked for, before 
zooming out to the strategic thinking 

Best regards,
Ed

From: Ingo Schmid<mailto:ingo...@gmx.at>
Sent: 07 May 2022 13:56
To: Ed .<mailto:ej...@hotmail.com>; 
perldl<mailto:pdl-general@lists.sourceforge.net>
Subject: Re: [Pdl-general] PDL::OpenCV update


Hi Ed,

sorry, apparently I didn't see that warning. I think eventually, PDL::OpenCV 
should not require such a recent PDL release, if reasonably manageable. I say 
eventually, not in this early stage.

My point about typemaps in module directories is, once we start adding modules 
left and right, updating one common typemap file is breaking encapsulation and, 
I think, not needed. The P:O:Tracker should have a typemap just for the 
TrackerWrapper, same for the VideoCapture, etc.

I would try to avoid cross-dependencies on the XS level if possible. E.g. the 
tracker may need to know how to read videos, but can do that using the 
VideoCapture perl interface, it does not require knowledge of its typemap.

Does that make sense?

Ingo
On 5/7/2022 12:04 AM, Ed . wrote:
Hi Ingo and all,

The real kudos belongs to Ingo (as it does with the native complex stuff), 
which is why the current opencv.pd there says “AUTHOR: Ingo Schmid and the PDL 
Porters”. However! We aren’t at the level of a releasable module yet, as 
evidenced by this segfault, and the still-small number of bound functions.

The typemap is indeed not found on PDL 2.078 and below, because the 
typemap-parsing code copy-pasted from ExtUtils::ParseXS in PDL::PP only just 
got fixed. That was the prompt for me to push out 2.079. You will have seen, 
when you ran Makefile.PL, it warning that it didn’t have the required PDL 
2.079. Please act on that warning and install latest PDL 

To answer your specific question, no, a top-level typemap is vastly better. 
Each pointer-type needs identical T_PTROBJ_SPECIAL code, and it would be 
pointless duplication (and add to the maintenance burden) to have it copied in 
each subdirectory. Please take a look in the top-level typemap to see if you 
agree 

No, t/opencv_basic.t is not obsolete. If it is segfaulting, that is a bug. 
Please first of all do “make realclean”, ensure you have the latest released 
PDL, then if it is still happening, please follow this process:

  1.  Rerun “perl Makefile.PL” (this will update the timestamps on Makefiles, 
prompting a full rebuild)
  2.  Edit your generated top-level Makefile to add “-g” to the “OPTIMIZE =” 
line to generate debug symbols (this gets propagated to subdirs by EUMM’s 
“PASTHRU_*” mechanism)
  3.  Run: make
  4.  Run: gdb perl -ex 'run -Mblib t/tracking.t'
  5.  In gdb, run: bt
  6.  Copy-paste the backtrace output which should show where the segfault 
originated
Then please open an issue on the repo with your “perl -V” output and PDL 
version, together with the stack-trace created above.

The above should go in an enhanced dev guide as we discusse

Re: [Pdl-general] PDL::OpenCV update

[Ed .]

Hi Ingo and all,

The real kudos belongs to Ingo (as it does with the native complex stuff), 
which is why the current opencv.pd there says “AUTHOR: Ingo Schmid and the PDL 
Porters”. However! We aren’t at the level of a releasable module yet, as 
evidenced by this segfault, and the still-small number of bound functions.

The typemap is indeed not found on PDL 2.078 and below, because the 
typemap-parsing code copy-pasted from ExtUtils::ParseXS in PDL::PP only just 
got fixed. That was the prompt for me to push out 2.079. You will have seen, 
when you ran Makefile.PL, it warning that it didn’t have the required PDL 
2.079. Please act on that warning and install latest PDL 

To answer your specific question, no, a top-level typemap is vastly better. 
Each pointer-type needs identical T_PTROBJ_SPECIAL code, and it would be 
pointless duplication (and add to the maintenance burden) to have it copied in 
each subdirectory. Please take a look in the top-level typemap to see if you 
agree 

No, t/opencv_basic.t is not obsolete. If it is segfaulting, that is a bug. 
Please first of all do “make realclean”, ensure you have the latest released 
PDL, then if it is still happening, please follow this process:

  *   Rerun “perl Makefile.PL” (this will update the timestamps on Makefiles, 
prompting a full rebuild)
  *   Edit your generated top-level Makefile to add “-g” to the “OPTIMIZE =” 
line to generate debug symbols (this gets propagated to subdirs by EUMM’s 
“PASTHRU_*” mechanism)
  *   Run: make
  *   Run: gdb perl -ex 'run -Mblib t/tracking.t'
  *   In gdb, run: bt
  *   Copy-paste the backtrace output which should show where the segfault 
originated
Then please open an issue on the repo with your “perl -V” output and PDL 
version, together with the stack-trace created above.

The above should go in an enhanced dev guide as we discussed, and I have just 
added it to https://github.com/PDLPorters/pdl/issues/393.

Best regards,
Ed

From: Ingo Schmid<mailto:ingo...@gmx.at>
Sent: 05 May 2022 10:56
To: Ed .<mailto:ej...@hotmail.com>; 
perldl<mailto:pdl-general@lists.sourceforge.net>
Subject: Re: [Pdl-general] PDL::OpenCV update


Hi

kudos to Ed for carving out a full module from my proof of concept level code.

For those trying this WIP package, keep reading. This is not yet a release, no 
Ed?

There appears to be an issue with the typemap.

heiner:[PDL-OpenCV]$ make
make[1]: Entering directory '/data/ingo/git/PDL-OpenCV/Tracker'
"/usr/bin/perl" "-I/usr/local/lib/x86_64-linux-gnu/perl/5.34.0" 
"-MPDL::PP=PDL::OpenCV::Tracker,PDL::OpenCV::Tracker,Tracker,," tracker.pd
The type =PDL__OpenCV__Tracker= does not have a typemap entry!
make[1]: *** [Makefile:859: Tracker.pm] Error 255
make[1]: Leaving directory '/data/ingo/git/PDL-OpenCV/Tracker'
make: *** [Makefile:542: subdirs] Error 2
heiner:[PDL-OpenCV]$ grep -Ri tracker typemap
PDL__OpenCV__Tracker   T_PTROBJ_SPECIAL

On my box it doesn't look at the top level typemap file in the subfolders. I 
can get by this error when copying the typemap file into the Tracker folder. 
That is then followed by the same error for VideoCapture and VideoWriter.

Fixing these, the t/opencv_basic.t is segfaulting. I guess this test file is 
obsolete since MatWrapper is a transient thingy now? In this case, it should be 
deleted.

Conceptually, wouldn't it be better to have a typemap file for each module in 
its own folder instead of the kitchen sink top-level typemap?

Ingo
On 5/5/22 01:58, Ed . wrote:
Hi pdl-general folks,

A quick update on this: Ingo and I are still working on it. The build process 
has been simplified so that the local C/C++ wrapper is part of the main project 
and the build is a normal PDL-ish one. The repo URL is now 
https://github.com/PDLPorters/PDL-OpenCV (the previous URL will redirect to 
that).

There is now a skeletal wrapper-generation structure in place, both for the 
C-wrapper and the PDL PP functions. Once the rest of the Tracker-updating code 
has been unpicked so that it can be done from Perl via generated wrapper, and 
the wrapper-generators are generalised, the Python binding-generator’s data 
(see my script on https://github.com/PDLPorters/pdl/issues/362) will be able to 
be used to generate a PDL binding for a fairly large part of OpenCV (indeed, it 
looks like it will be straightforward to bind a larger part than “gocv”, the 
current Go binding, does).

Best regards,
Ed

From: Ingo Schmid<mailto:ingo...@gmx.at>
Sent: 19 April 2022 10:50
To: perldl<mailto:pdl-general@lists.sourceforge.net>
Subject: [Pdl-general] PDL::OpenCV update


Hi

I just pushed a new version to github.

https://github.com/fantasma13/PDL-OpenCV.git

It should be working at least on linux. Please read the INSTALL document. It is 
a two step process.

It is basic but works.

Ingo


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] PDL::OpenCV update

[Ingo Schmid]

Hi

kudos to Ed for carving out a full module from my proof of concept level
code.

For those trying this WIP package, keep reading. This is not yet a
release, no Ed?

There appears to be an issue with the typemap.

heiner:[PDL-OpenCV]$ make
make[1]: Entering directory '/data/ingo/git/PDL-OpenCV/Tracker'
"/usr/bin/perl" "-I/usr/local/lib/x86_64-linux-gnu/perl/5.34.0"
"-MPDL::PP=PDL::OpenCV::Tracker,PDL::OpenCV::Tracker,Tracker,," tracker.pd
The type =PDL__OpenCV__Tracker= does not have a typemap entry!
make[1]: *** [Makefile:859: Tracker.pm] Error 255
make[1]: Leaving directory '/data/ingo/git/PDL-OpenCV/Tracker'
make: *** [Makefile:542: subdirs] Error 2
heiner:[PDL-OpenCV]$ grep -Ri tracker typemap
PDL__OpenCV__Tracker   T_PTROBJ_SPECIAL

On my box it doesn't look at the top level typemap file in the
subfolders. I can get by this error when copying the typemap file into
the Tracker folder. That is then followed by the same error for
VideoCapture and VideoWriter.

Fixing these, the t/opencv_basic.t is segfaulting. I guess this test
file is obsolete since MatWrapper is a transient thingy now? In this
case, it should be deleted.

Conceptually, wouldn't it be better to have a typemap file for each
module in its own folder instead of the kitchen sink top-level typemap?

Ingo

On 5/5/22 01:58, Ed . wrote:


Hi pdl-general folks,

A quick update on this: Ingo and I are still working on it. The build
process has been simplified so that the local C/C++ wrapper is part of
the main project and the build is a normal PDL-ish one. The repo URL
is now https://github.com/PDLPorters/PDL-OpenCV (the previous URL will
redirect to that).

There is now a skeletal wrapper-generation structure in place, both
for the C-wrapper and the PDL PP functions. Once the rest of the
Tracker-updating code has been unpicked so that it can be done from
Perl via generated wrapper, and the wrapper-generators are
generalised, the Python binding-generator’s data (see my script on
https://github.com/PDLPorters/pdl/issues/362) will be able to be used
to generate a PDL binding for a fairly large part of OpenCV (indeed,
it looks like it will be straightforward to bind a larger part than
“gocv”, the current Go binding, does).

Best regards,

Ed

*From: *Ingo Schmid 
*Sent: *19 April 2022 10:50
*To: *perldl 
*Subject: *[Pdl-general] PDL::OpenCV update

Hi

I just pushed a new version to github.

https://github.com/fantasma13/PDL-OpenCV.git

It should be working at least on linux. Please read the INSTALL
document. It is a two step process.

It is basic but works.

Ingo

___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] PDL::OpenCV update

[Ed .]

Hi pdl-general folks,

A quick update on this: Ingo and I are still working on it. The build process 
has been simplified so that the local C/C++ wrapper is part of the main project 
and the build is a normal PDL-ish one. The repo URL is now 
https://github.com/PDLPorters/PDL-OpenCV (the previous URL will redirect to 
that).

There is now a skeletal wrapper-generation structure in place, both for the 
C-wrapper and the PDL PP functions. Once the rest of the Tracker-updating code 
has been unpicked so that it can be done from Perl via generated wrapper, and 
the wrapper-generators are generalised, the Python binding-generator’s data 
(see my script on https://github.com/PDLPorters/pdl/issues/362) will be able to 
be used to generate a PDL binding for a fairly large part of OpenCV (indeed, it 
looks like it will be straightforward to bind a larger part than “gocv”, the 
current Go binding, does).

Best regards,
Ed

From: Ingo Schmid
Sent: 19 April 2022 10:50
To: perldl
Subject: [Pdl-general] PDL::OpenCV update


Hi

I just pushed a new version to github.

https://github.com/fantasma13/PDL-OpenCV.git

It should be working at least on linux. Please read the INSTALL document. It is 
a two step process.

It is basic but works.

Ingo

___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] PDL::OpenCV update

[Ingo Schmid]

Hi,

Adam, glad to hear! Please give it a try! I've just pushed a new version
with workin video read/write. So this gives PDL now a video reader.

I have two questions for further development.

1. OpenCV is huge. Every method needs a C wrapper which needs a PP
function. So, code generation is almost certainly a must. As you can
see, some functions are already generated but this is more of a hack than.

My needs and time are limited at the moment, so I may not do great
developments beyond what is present in the near future. Ideally, a
parser for hpp files would generate wrapper code and a PP api. I guess
this can be done for a large subset of OpenCV methods with tweaks here
and there. I guess the Inline::CPP parser could be a starting point?

2. The build system is a hack. The cw directory contains C++ wrappers
that use cmake and are partly generated using Makefile.pm. So, cmake
needs to run successfully and you need to make install so that
PDL::OpenCV can find the shared object. I think the PDL::OpenCV modules
should link directly against the cw/build directory avoiding the install
step. If cmake is not successfully finding libs, I guess using something
like ccmake to set paths etc. updating the cmake cache after code
generation should work in many situations. I guess in the end an
Alien::OpenCV module should take care of the C wrapper, which is somehow
conflicting with code generation.

Again, I may or may not be able to significantly change the current
behaviour.

I suppose substituting Mat by UMat in the wrapper could provide seamless
OpenCL integration? Anyone has experience with this?

Looking forward to your feedback.

Ingo

On 4/19/22 15:54, Adam Russell wrote:

Great work! Thank you for doing this. I was recently Looking to use
OpenCV via Perl and hit a bit of a wall. I am looking forward to
trying this.
Best Regards,
Adam

Date: Tue, 19 Apr 2022 11:50:04 +0200
From: Ingo Schmid 
To: perldl 
Subject: [Pdl-general] PDL::OpenCV update
Message-ID: <84d3e8c1-9350-6213-2a3f-50673e741...@gmx.at>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Hi

I just pushed a new version to github.

https://github.com/fantasma13/PDL-OpenCV.git

It should be working at least on linux. Please read the INSTALL
document. It is a two step process.

It is basic but works.

Ingo


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general
___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] PDL::OpenCV update

[Adam Russell]

Great work! Thank you for doing this. I was recently Looking to use OpenCV via 
Perl and hit a bit of a wall. I am looking forward to trying this.
Best Regards,
Adam

Date: Tue, 19 Apr 2022 11:50:04 +0200
From: Ingo Schmid 
To: perldl 
Subject: [Pdl-general] PDL::OpenCV update
Message-ID: <84d3e8c1-9350-6213-2a3f-50673e741...@gmx.at>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Hi

I just pushed a new version to github.

https://github.com/fantasma13/PDL-OpenCV.git

It should be working at least on linux. Please read the INSTALL
document. It is a two step process.

It is basic but works.

Ingo
___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general