[Vm-dev] Request: VM support for opening browser

[Camillo Bruni]

On 2012-07-20, at 13:40, Nicolas Cellier wrote:

> 
> For me, it's not about safety.
> It's about mirroring outside word complexity in the image, including
> the includes files when it comes to FFI.
> Even the simpler case of shells is boring. What is the OS-universal
> command to open a web browser? Does it take user preference into
> account ? Shall we strip some environment variables when we launch a
> 64bit app from a 32bit one?
> 
> How do ruby/python/java/... open an URL?
ruby and python both seem not to have a static (vm-side) solution for 
this problem:

http://stackoverflow.com/questions/152699/open-the-default-browser-in-ruby
http://stackoverflow.com/questions/4216985/python-call-to-operating-system-to-open-url

so the solution is language-side, as it should be!

> The uncontested advantage of in-image code is that you can
> change-evaluate it in fast loops.
> The second advantage is simpler distribution of code (rather than
> VMMaker sources + pre-compiled plugin binaries). Though, plugins
> should be pluggable.
> 
> But what do you gain about factoring and maintaining code working for
> all OS/versions? How do you avoid hardcoding machine specific stuff
> (paths, executable names etc...)?

Obviously you have to do that. But for instance you can rely on FFI
and Posix, that cut's down the problem space quite effectively. Of course
you'll still have to deal with certain OS specific issues, but that's
already the case in 2.0 with FileSystem...

> You have to plug into rather than
> re-program existing system capabilities, so you have to reify these
> capabilities and all query/configuration services. In worst cases, if
> you have to use FFI, it can take the form of preprocessor directives,
> you know the kind of boring stuff configure or cmake, try to
> address...

not really... I mean you can simply resolve methods using dlsym, and
your almost done. Besides you leave out the fact that most plugins
are written in SLANG anyway, so there you have your preprocessor written
in a pseudo smalltalk. However if you use the full power of ST you get
away quite nicely (and in many cases much much faster...)

So even if you have to write a preprocessor like thingy, you're still
better off than with VM-side code.

> Opening an URL is a very simple test case though, so I'd say Pharo
> shoud experiment and recreate an in-image mirror of the plugin (I mean
> with same capabilities) using OSProcess shells. It will bring more
> feedback before we can vote.

We reimplemented the FileSystem primitives in NativeBoost, which is not
simply calling an external function, but holding on to a reference when
you loop over the directory.

Outcome? We were 40times faster than the C plugin with 3 classes added to
the system... 


I don't really think there is something to vote about, at least here at
RMoD the mindset is pretty clear :) (on the FFI side of the world).