Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Pre-Release Discussion

Reply
 
Thread Tools Display Modes
Old 01-25-2010, 07:29 AM   #1
MikeLacey
Human being with feelings
 
Join Date: Dec 2006
Location: UK
Posts: 789
Default RPR_include() test result -- and a comment

Tested using Perl, included a file containing.

use strict;
use constant CURR_PROJ => 0;

and sub routine definitions.

No errors or problems.

============================

Schwa, Justin, Chris,

This is a significant change and to some extent will make it much easier to share code with others and to re-use subroutines etc.

However, and please don't think I'm unappreciative of the work involved and the speed of development, I don't think this step is in the right direction.

RPR_include() will work to an extent but doesn't address some basic issues and will eventually cause more issues with code sharing than it solves.

Each variable and subroutine declared in the included file share the same name-space as the main script - so you will get variables in the main script inadvertently being given the same name. Each included file pollutes the main script's name-space and that problem will get worse the more code is shared (it will get worse as ReaScript gets more popular)

The ideal way to implement ReaScript in Perl would be the same way the FFI module is implemented. A short .PM file and a DLL. To use Perl within REAPER you would simply say:

PHP Code:
use RPR
And the RPR module would provide access to the REAPER routines, using FFI, as REAPER does now.

This would be a far cleaner way of implementing ReaScript in Perl:
  • user written modules (.pm files) would be able to call RPR routines
  • users would be able to provide each other with vastly simplified methods for accessing REAPER objects
  • user written modules would have their own name-spaces - variables and sub names would not collide.

Again, please don't think I'm unappreciative or moaning because things aren't "just-so". But please do look again at the basic FFI mechanism and consider implementing it in a .dll invoked by a .pm. Looking at the way it's implemented at the moment (that means guessing, just so you know ) I suspect that you have the guts of the code you need already - that is the routines that use FFI to call REAPER functions.
__________________
Mike Lacey, Leicestershire, UK
MikeLacey is offline   Reply With Quote
Old 01-26-2010, 02:59 AM   #2
MikeLacey
Human being with feelings
 
Join Date: Dec 2006
Location: UK
Posts: 789
Default

.. bump ..
__________________
Mike Lacey, Leicestershire, UK
MikeLacey is offline   Reply With Quote
Old 01-26-2010, 06:53 AM   #3
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 15,750
Default

Although the conventional way to embed Python and Perl obviously has advantages for users, the way Reaper does it now has major advantages from our side, including:

- Linkage is completely dynamic, nothing additional for us to compile, distribute, or provide installation/compatibility support for. (Also the header and embedding modules would be fairly sizable with 300 exported functions.)

- The metadata step happens at run-time, rather than at compile time via SWIG or similar. This means the metadata is not frozen into the embedding module but is guaranteed to be compatible with whatever version of Reaper is running.

- Run-time "compiling" of user scripts lets us do meta-level tricks, like having the script itself bail on recursion.

So, unfortunately, traditional embedding is not likely to happen any time soon.
schwa is offline   Reply With Quote
Old 01-26-2010, 08:53 AM   #4
MikeLacey
Human being with feelings
 
Join Date: Dec 2006
Location: UK
Posts: 789
Default

Ok, thanks for your response schwa, perhaps you'll revisit the issue in due course.
__________________
Mike Lacey, Leicestershire, UK
MikeLacey is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 05:25 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.