[Vm-dev] Request: VM support for opening browser
nicolas.cellier.aka.nice at gmail.com
Fri Jul 20 14:31:08 UTC 2012
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:
> 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
> 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.
More information about the Vm-dev