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

[Igor Stasenko]

On 20 July 2012 16:31, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
>
> 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 ?

in this case the source of speedup was purely about properly using OS
functionality.
The required functionality was: return all directory entries.
A plugin , unfortunately, provides only one primitive suitable for
doing that: get n-th entry in file directory.
And implementation is very ineffective: open directory, skip entries
up to n-th element, return n-th element, close directory.

The plugin doing a nice thing to hide the OS-specific directory handle
from the eyes of smalltalkers..
but this comes at cost like having O(n!) instead of O(n) to read all
directory entries.

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



-- 
Best regards,
Igor Stasenko.