I've made a start on some Wiki pages for ReaScript, based on the existing web pages for the moment. From REAPER's output I've created placeholder Wiki entries for each of the API function. There are places for example scripts in Perl and that other language...

Wow, thanks! Technical note, I have always had a soft spot for Perl and have written probably a million lines of Perl in my life, but I have to admit that managing embedding Python is a much easier process than Perl, and it's a shame that Perl doesn't have a standardized foreign function interface the way Python does. If there are any perlembed gurus out there, please drop me a PM or email. I don't understand why redirecting stderr before executing embedded perl scripts doesn't collect Perl syntax/compile errors the way it does in Python.

Silly questions... If you're embedding Perl within REAPER, why do I need to have Perl installed on my PC? What do you mean by perlembed? Do you mean the same as in the Perl documentation "perlembed - how to embed perl in your C program"? How are you invoking Perl?

Yes, that perlembed. We are embedding Perl but linking to it dynamically, so the user needs the perl/python dll/dylib on their machine. Linking statically (ie. packaging Perl and Python with Reaper) would double the size of the installer...

Hi Schwa, Sorry to take so long getting back to you. I did a little digging around, re Perl script compile errors and found some very bare pointers... Are you called the Perl script with eval_pv or eval_sv? This advice from Nick Ing-Simmons may be useful to you if so. Both of these functions are like Perl's eval() function, and they leave the value of $@ set appropriately. You can get at the value of Perl's $@ variable with the ERRSV macro, like this if (SvTRUE(ERRSV)) { char *error_message = SvPV_nolen(ERRSV); } Getting this information is like pulling your own teeth out, but without the inherent charm and sheer fun that pulling your own teeth out offers. So then, as long as you have the ERRSV macro defined, given the information that ERRSV is what we need, re-reading the perlembed man page is a little more informative. static PerlInterpreter *perl = NULL; int main(int argc, char **argv, char **env) { char *embedding[] = { "", "persistent.pl" }; char *args[] = { "", DO_CLEAN, NULL }; char filename [1024]; int exitstatus = 0; STRLEN n_a; if((perl = perl_alloc()) == NULL) { fprintf(stderr, "no memory!"); exit(1); } perl_construct(perl); exitstatus = perl_parse(perl, NULL, 2, embedding, NULL); PL_exit_flags

Thanks Mike. The issue is sort of complicated (or else it wouldn't be an issue I guess). We don't use a persistent interpreter because we don't want state from one script run to pollute the state of the next script run. And without a persistent interpreter (or maybe even with one), ERRSV doesn't get set on compile errors, only on run-time errors. The problem is probably at a level of complexity where it's almost not worth dealing with any more. Perl users may just have to live without compile errors.

Ok, I'm wasting my time looking at stuff you've already tried.