Let’s call it a concatenation of circumstances: latest PDL is careful to insert a newline before any Code section in the generated C to protect from this sort of thing having stumbled over it, and the various pp_addpm / pp_line_numbers are also careful to do so. If you are rolling your own versions of any of these functions, then you may experience the problems those measures are designed to fix. Generally I’d advise having just one strategy rather than several, to avoid the worst of all worlds 😉
Best regards, Ed From: David Mertens<mailto:dcmertens.p...@gmail.com> Sent: 13 February 2022 21:09 To: Ed .<mailto:ej...@hotmail.com> Cc: pdl-devel<mailto:pdl-devel@lists.sourceforge.net> Subject: Re: [Pdl-devel] I think the problem here is PDL's, not mine... Oh! Hahaha, so this is almost certainly my problem and not PDL's! Sorry for the noise. Oddly, I use pp_line_numbers elsewhere in this module's PP code, but not for the bad code in this function. Thanks! David On Sun, Feb 13, 2022, 8:32 AM Ed . <ej...@hotmail.com<mailto:ej...@hotmail.com>> wrote: I think the latest PDL’s pp_line_numbers does all this stuff for you (partly because as I’ve enhanced it, I’ve occasionally made mistakes and broken others’ modules, often yours in fact!). My reading of your Prima/Util.xs.PL<http://Util.xs.PL> is it has a hand-rolled pp_line_numbers-ish manual “#line”. That’s up to you, but you risk making your own independent mistakes that I’ve already made and fixed ;-) Personally I’d change your current strategy to use EUMM and also “opt in” to “multi-C”. One benefit is that using “make” means you can have parallel-build, so it initially builds faster. Also, when you’re developing, if you change one function, it will recompile only that function, for a much faster dev cycle. Anyway, fingers crossed that we figure this out! Best regards, Ed From: David Mertens<mailto:dcmertens.p...@gmail.com> Sent: 13 February 2022 13:15 To: Ed .<mailto:ej...@hotmail.com> Cc: pdl-devel<mailto:pdl-devel@lists.sourceforge.net> Subject: Re: [Pdl-devel] I think the problem here is PDL's, not mine... Heh, so the problem might be "mine" insofar as I implemented pp_line_numbers... I wonder if there's is a backslash on the previous line causing this. If that were the case, I should be able to fix it by prepending a newline to the string constructed by pp_line_numbers. Maybe I'll try a dev release in which I do that and we see if that gets rid of the UNKNOWN rest results. David On Sun, Feb 13, 2022, 1:38 AM Ed . <ej...@hotmail.com<mailto:ej...@hotmail.com>> wrote: It’s one I think I’ve seen on very rare failure reports from Slaven. On staring a bit more, I think this: /opt/perl-5.28.2/lib/site_perl/5.28.2/x86_64-linux/PDL/PP/PDLCode.pm:634:45: note: in expansion of macro ‘PP_INDTERM’ is mojibake of colour-codes intended for human consumption. If we ignore the noise, I think the significant error may be the “stray ‘#’ in program” which will be caused by a “#” (possibly your “# line “ stuff) ending up as not at the start of a line. I’d need more information about which version such a thing changed on to say for definite, but I’m not aware of big problems. That report was from PDL 2.067, do you see any others? Best regards, Ed From: David Mertens<mailto:dcmertens.p...@gmail.com> Sent: 13 February 2022 06:10 To: pdl-devel<mailto:pdl-devel@lists.sourceforge.net> Subject: [Pdl-devel] I think the problem here is PDL's, not mine... I was looking over my testers results for my recently released PDL::Drawing::Prima. Here is an odd UNKNOWN test: http://www.cpantesters.org/cpan/report/9881a8cc-8a43-11ec-97fd-77241f24ea8f The problem appears to be a code-gen problem. Is this a fixed issue? David -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel
