An update: I switched the hand-rolled pp_line_numbers-like code to just use pp_line_numbers and bumped to v0.14 to make sure I'd get lots of test coverage on lots of platforms quickly. 24 hours later it's all green <http://matrix.cpantesters.org/?dist=PDL-Drawing-Prima%200.14>. :-D
Thanks Ed! David On Sun, Feb 13, 2022 at 8:12 PM Ed . <ej...@hotmail.com> wrote: > 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 <dcmertens.p...@gmail.com> > *Sent: *13 February 2022 21:09 > *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... > > > > 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 > > > > > > > -- "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
