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> 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 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 <dcmertens.p...@gmail.com> > *Sent: *13 February 2022 13:15 > *To: *Ed . <ej...@hotmail.com> > *Cc: *pdl-devel <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> 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 <dcmertens.p...@gmail.com> > *Sent: *13 February 2022 06:10 > *To: *pdl-devel <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
