[Vm-dev] Request: VM support for opening browser
siguctua at gmail.com
Sat Jul 21 12:12:16 UTC 2012
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:
>> 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 ?
in this case the source of speedup was purely about properly using OS
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
>> 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