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

[Nicolas Cellier]

2012/7/20 Camillo Bruni <camillobruni at gmail.com>:
>
>
> 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...)
>

Agree. Alas, the devil is in the detail, name it 'almost'.
Is the function name the same on every OS ?
Where/how do you find the library name, version, path, dependencies ?
Is the function a macro in some .h (using internal FILE structure
details for example) ?
Does it use enum or any other encoded integer ?
Are the structures portable (I mean those which are not allocated by a
function call) ?

> 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 say this is an encouraging start point, but not enough to prove the
concept you must replace a whole plugin.
Though, I think that FilePlugin is a very difficult candidate to start with...
For non blocking I/O, how do we encode the necessary fcntl flags in a
portable manner ?
Do we replicate the OS-specific flag encoding in the image ?
Or do we use one native thread per function call thru threaded FFI ?

It would also be fair to detail the source of speed-up:
- replacing generic FFI typechecking by native boost mechanism ?
- using simpler structures than FIle plugin ?
- bypassing some safety checks ?

>
> 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).
>

I can only encourage you to continue the hard work and come back with the proof.
Though I play the role of Cassandra, I wish you good luck and success.

Nicolas