I'm rewriting some perl/charting software in Raku but have run into an issue using the ChartDirector perl5 module (link below) via Inline::Perl5. The module is basically a perl interface to a DLL; using the module via Inline::Perl5 seems to work for method calls explicitly included in the code - but most of the method calls are executed via the autoload 'catch all' mechanism in perl5. These do not work in my raku code.
My question is can I expect this sort of application to work using Inline::Perl5? (perhaps there is no way to 'catch' these autoload'd method calls) and, if so, how to make it so.
Thanks for any pointers, suggestions.
wf
ChartDirector software (excellent graphics/charting software - have used it for nearly 2 decades with perl): https://www.advsofteng.com/index.html
Quoting verbiage (simplified), version info, and code from the start of a chartdir forum thread about this:
I'm using
Inline::Perl5
which works with every other module I've tried.I'm hitting problems reproducing the "first project" example on the chartdir site.
using chartdir 6, freebsd 12.2 (intel platform), raku 2022.04, perl 5.32.1.
#!/usr/bin/env raku
use lib:from<Perl5> '/usr/local/lib/perl5/site_perl';
use Inline::Perl5;
my $p5 = Inline::Perl5.new;
$p5.use('perlchartdir') ;
my $data = [85, 156, 179.5, 211, 123];
my $labels = ["Mon", "Tue", "Wed", "Thu", "Fri"];
my $c = $p5.invoke( 'XYChart', 'new', 250, 250);
$c.setPlotArea(30, 20, 200, 200);
$c.addBarLayer($data);
$c.xAxis().setLabels($labels);
$c.xAxis().setLabels($labels);
$c.makeChart("simplebar.png");
All seems fine (i.e., data-dumping
$c
after line 8 shows a large/reasonable looking structure) until line 9 where I receive "No such methodsetPlotArea
for invocant of typeXYChart
". Line 10 does appear to work (no complaints) - remaining 3 lines don't (same type of error as for line 8).
And quoting some feedback that was given by Peter Kwan, the primary dev of chartdir:
I have never used Raku before. For your case, the methods that fail seem to be AUTOLOAD methods. ... I suspect may be Raku does not support Perl AUTOLOAD, so it reports undefined methods as not found instead of forwarding it to the "catch all" method. Or may be some additional things need to be imported for it to use the AUTOLOAD.
As dwarring notes in the comments below this SO question, Inline::Perl5 does support autoload (and has for 7 years), so perhaps that aspect is a red herring?
gratefully responding to p6steve's response, I am providing some additional information ..
The full output from various representations of $c (the XYChart object) is included here: https://pastebin.com/gY2ibDaM (hope it's ok to use pastebin for this (still finding my way through stackoverflow)) - the output was 600+ lines long and wasn't sure what I could usefully edit out).
to summarize though ..
dd $c returns nil (although prints out the equivalent of $c.perl (below) to stdout (not sure why))
say $c.perl returns:
XYChart.new(inline-perl5 => Inline::Perl5.new(thread-id => 1), wrapped-perl5-object => NativeCall::Types::Pointer.new(34651088744))
say $c.^methods returns:
(WHERE addHLOCLayer ACCEPTS WHY can new isa rakuseen defined getYCoor addHLOCLayer3 raku yZoneColor Numeric addLineLayer addAreaLayer DESTROY BUILDALL gist perl WHICH sink bless getYValue Str addBarLayer new_shadow_of_p5_object AT-KEY)
finally, say Dump $c (using Data::Dump module) yields about 600 lines of output (included in the pastebin output).
Hi wingfold and welcome to the raku SO tag!
I wonder what you get with
dd $c;
just before the line$c.setPlotArea(30, 20, 200, 200);
- e.g. is $c truly an XYChart object?If so then what does
$c.^methods
(the '^' indicates a meta method ... in this case you should get a list of the available methods).Please do post the results here and hopefully that will help the diagnosis...
Thanks for the info!
Having seen the output of the $c.^methods call, it is clear that $c has no method
$c.setPlotArea
(reading the error message says the same - perhaps I should have given that due weight!)I do not know the Inline::Perl5 module well, but I have seen similar issues with Inline::Python.
My experience in Python is that the target language objects only expose their "direct" methods and do not automatically pull in all the composed methods that they can perform.
My workaround has been on the lines of an "eval" style approach, something like:
Hope this helps!