Yes - the reason I've been trying to learn FFI is specifically to get TensorFlow integration.
I want a better ML workbench. > On Nov 2, 2017, at 9:08 PM, Ben Coman <b...@openinworld.com> wrote: > > > > On Fri, Nov 3, 2017 at 11:10 AM, horrido <horrido.hobb...@gmail.com > <mailto:horrido.hobb...@gmail.com>> wrote: > Sounds like it's possible to call into TensorFlow (Python) from Pharo. That > would give Pharo a tremendous boost for machine learning applications. > > Am I right? > > Tensorflow has a C API for FFI from other languages. > * https://www.tensorflow.org/install/install_c > <https://www.tensorflow.org/install/install_c> > * https://www.tensorflow.org/extend/language_bindings > <https://www.tensorflow.org/extend/language_bindings> > > cheers -ben > > > > kilon.alios wrote > > Maybe you talk about TalkFFI which aumatically wrapped C libraries for > > Pharo and i think Squeak as well but used Nativeboos, i think > > > > http://forum.world.st/TalkFFI-automatic-FFI-generation-for-Pharo-td4662239.html > > > > <http://forum.world.st/TalkFFI-automatic-FFI-generation-for-Pharo-td4662239.html> > > > > On the subject of Fortran yes you can use UFFI if Fortran code is compiled > > as a DLL (or equivelant non Windoom OSes) > > > > https://software.intel.com/en-us/node/535305 > > <https://software.intel.com/en-us/node/535305> > > > > Dynamic Library format are not exclusive to C for generation , many > > languages can generate them so even though UFFI is used predominatly for C > > any language that can generate a DLL without any name mangling should be > > accessible via UFFI. > > > > if DLL generation is not possible, then you can drop down to my solution > > of > > Shared Memory Mapped Files. Which means you make an executable in Frotran > > (or any other language) that contains the code you want to access and > > creates a shared memory region and you can access that region from Pharo > > via UFFI. > > > > This is how I built my CPPBridge project. Which one can use as a template > > for generating similar bridge for Fortran or any other language where the > > generation of DLLs is not practical or possible. > > > > The shared memory region can be used also as a means of communication > > additional to sharing live state, memory mapped files automatically save > > the live state so next time you open the file it behaves as you would > > expect a Pharo image to behave by restoring the live state. A means to > > extend Pharo image to include memory not managed by the VM. > > > > Because memory mapped files is mechanism of the OS Kernel and is also the > > mechanism used for the loading of dynamic libraries like DLLs there is > > also > > no loss of performance and is the fastest way of communication between > > languages, libraries and applications. > > > > So yes using Fortran code is possible via UFFI in more than one way. > > > > But in the end it should be noted here that because IPC mechanisms (common > > way of using libraries from other languages) are based on core OS > > functionality like , memory managment, sockets , pipes, etc its not hard > > to > > use libraries from any language from inside any language. > > > > So Pharo can use Fortran libraries and Fortran can use Pharo libraries, > > its > > also possible to retain live coding even when executing code written in > > another language through various means. Recently I was succesful in making > > Python into a basic live coding enviroment , meaning code that when > > changed > > in the source file it updates also existing live intances as you expect in > > Pharo. Python also supports memory mapped files so its possible to create > > a > > joined live coding enviroment and live image that containes both Pharo and > > Python bytecode. Of course without touching VM source code. > > > > Even though live state is not tricky to retain for compiled languages, > > live > > code can be a bit trickier to do but still not impossible or that hard as > > most would assume. > > > > Sky is the limit. > > > > Bottom line is that if you have a favorite library in any language you can > > use it from inside Pharo with at worst a few hundrend lines of setup code > > you can create as a library and of coure reuse next time you want to use > > again a library from another language without having to write a line of > > additional code. The technology is available is just a matter of learning > > how to use it. Especially if its a very large libraries it will be > > thousands times easier than trying to replicate the functionality in > > Pharo. > > > > > > > > On Fri, Oct 27, 2017 at 6:26 PM Sean P. DeNigris < > > > sean@ > > > > > > wrote: > > > >> Ben Coman wrote > >> > it seems to hint how to do it from Pharo UFFI. > >> > >> Slightly OT: I remember years ago, someone (Dave Mason?) demoed a library > >> which automatically created FFI wrappers for C libs. I never heard > >> anything > >> about it after that, which is sad, because I was amazed and wanted to use > >> it! > >> > >> > >> > >> ----- > >> Cheers, > >> Sean > >> -- > >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >> <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> > >> > >> > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> > >
