You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
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.The text was updated successfully, but these errors were encountered: