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 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
