Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Inline without _Inline #64

Open
gflohr opened this issue Sep 8, 2017 · 0 comments
Open

Use Inline without _Inline #64

gflohr opened this issue Sep 8, 2017 · 0 comments

Comments

@gflohr
Copy link

gflohr commented Sep 8, 2017

This is a feature suggestion.

The "original" ILSM Inline::C requires a temporary directory for storing artifacts created by the compilation step. Inline::Java has the same requirement. The dynamic loader needs a .so, .dylib, .dll, ... and /usr/bin/env java needs a .class file.

ILSMs for interpreted languages do not have that requirement. They use the directory for caching only.

After patching Inline::Ruby to support recent Rubies I have the vague suspicion that the cache directory does not always make a lot of sense for interpreted languages. Rationale:

  • It is ugly!
  • It is really ugly!
  • Did I mention that it is ugly?
  • Its positive effect is negligible for most use cases.
  • It is an unnecessary source of subtle bugs. The same piece of source code can result in different symbol tables depending on conditions only known at run-time in many languages. Perl is an example of such a language.

Okay, admittedly that last objection is a little bit far out but it is still true. What about the last two?

The typical use case for Inline is glue code that exposes an API written in Python, Ruby, ... you name it to Perl. The result of compiling the glue (normally a handful of SLOCs) is cached in Perl by Inline.pm, compiling the thousands of lines of SLOCs of the target library is left to the interpreter of the target language and normally a lot more expensive and cached as byte code anyway.

My suggestions are:

  • Caching the compilation results should be an optional feature for ILSMs. If it is already optional, sorry ... but it should be pointed out in the documentation.

  • It should be possible to disable the caching feature for ILSMs for languages where that is possible. Something like:

    use Inline Ruby => config => directory => undef;

Being able to tell your users that they can interface your software written in Perl with libraries from the ecosystems of Python, Ruby, ... is a great feature. Having to tell them that the drawback of it are _Inline directories scattered all over their storage devices is a major show-stopper for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant