[Vm-dev] Request: VM support for opening browser
nicolas.cellier.aka.nice at gmail.com
Fri Jul 20 14:22:10 UTC 2012
2012/7/20 Esteban Lorenzano <estebanlm at gmail.com>:
> VM is not magically solved, you know? there is people behind that...
> difference is:
> - We have 5 vm maintaners (in their spare time) and 50+ possible image maintainers. And I'm going to ask it again: who is going to maintain it?
> - is not "mirroring" anything... that sentence assumes that what you are asking for something that already exists...
> - complexity is exactly the same in vm side... but Smalltalk is better to program and maintain. Who prevent us to hardcode in the VM? and if that happens... who can change it on the fly to match their needs? Seriously, nothing prevents us to have crapy code (and if you see some code around, you'll notice that). But if we have the essential complexity living in the image, at least we can use a language that can manage this complexity in a proper way.
Between we can and we did, there's a fair bit of magical occuring too...
I say YES, it can be FAR less work to maintain in image FFI than
C/Slang VM plugins when functions are portable (case of third party
libraries built with this purpose), but in some cases it can be worse.
For example, developping interface to Lapack with FFI/DLLCC was at
least 5x more productive than writing VW primitives in my experience.
I did also try more OS-related things with DLLCC, and though
VisualWorks provided an up to date CParser that could parse headers at
that time (hardly longer the case now), it did not solve anything for
me, I had to reflect implementation details in image for each OS, and
for some function points like interfacing with IPC, it was far easier
to use the right tools, I mean provide a compatibility layer
programmed in C. If you ever dealed with union semun & co, you know
what I'm talking of...
If we are speaking of implementing a better cmake/configure, maybe we
have better dragons to fight.
I also don't buy, we are better and have a better language, Morphic is
a good example of what we can come with in term of complexity.
Complexity requires a lot of engineering.
I say we must try hard, experiment, use FFI were we gain, but be
pragmatic rather than dogmatic. Every other argument thrown in these
threads is just wishful thinking.
> Still... your arguments don't convince me, because essentially, what you asking for is to hide the garbage under the carpet, so you cannot see it.
> I prefer to expose it, then someone can clean it.
> ps: Even more seriously, guys: take a look at the existing plugins: many of them are old and kinda obsolete. Nobody has make serious investment on keep them up-to-date and technology changed since last 15 years... this happens because we are not apple or microsoft. We cannot put the needed resources into maintain the VM as it is now.
> But we can maintain it if it lives in the image... because we are Smalltalk programmers, and our community is about Smalltalk... let the environment rule :)
> On Jul 20, 2012, at 1:40 PM, 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?
>> 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...)? 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
>> 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.
>> 2012/7/20 Luc Fabresse <luc.fabresse at gmail.com>:
>>> 2012/7/20 Esteban Lorenzano <estebanlm at gmail.com>
>>>> Well... I also disagree with the argument of safeness.
>>>> For me, saying that is like saying a mennonite community is safer just because they are isolated. They are not. And in any case, the price payed for that isolation is to stay in the 18th century...
>>>> I think putting this solution in vm is a poor solution, that prevents adaptation in time... just like a mennonite community, btw :)
>>>> Frankly... most important question about having it as a plugin is "who will maintain it?"... because problem is not adding a plugin, problem is keep it in time, and match changing outside technologies.
>>> +1 to use FFI
>>> This time, we will add a plugin for URL, next time we will add another one for XXX, and YYYY.
>>> Esteban is right, adding more and more plugins is not the right thing to do IMHO since fewer people can maintain it compared to image side code.
>>> Moreover, we must interact easily/fastly with existing world (OS, libraries, ...).
>>> For the subscription of the VM to www.weightwatchers.fr ;-)
>>>> On Jul 20, 2012, at 9:48 AM, Torsten Bergmann wrote:
>>>>>> I disagree in general with extend vm complexity to add things that can >perfectly work in smalltalk or using a FFI package...
>>>>> Saying you can do this using FFI/OSProcess is a weak argument.
>>>>> "fopen" could be in the Smalltalk image as well - but we have it
>>>>> in the VM.
>>>>> We may include both into Pharo - so nobody has to load FFI + ConfigurationOfExternalWebbrowser.
>>>>> But I dont think that is the route for Squeak, Cuis, ...
>>>>> These Smalltalks may profit from an VM implementation without
>>>>> making them "unsafe" or more bound to native OS with FFI and
>>>>> How can we proceed in the discussion? There are pros and cons
>>>>> for both sides. Should we vote?
>>>>> According to
>>>>> "URL within VM" seems to be the winner ;)
More information about the Vm-dev