Hi, On May 6, 2012, at 9:45 AM, Nicolas Cellier wrote:
> 2012/5/6 Igor Stasenko <[email protected]>: >> On 5 May 2012 18:00, Eliot Miranda <[email protected]> wrote: >>> >>> >>> On Fri, May 4, 2012 at 6:23 PM, Igor Stasenko <[email protected]> wrote: >>>> >>>> Hi, David, all >>>> >>>> i just want to know, if we can use FFI calls, for implementing an >>>> OSProcessPlugin functionality (or at least most of it). >>>> and if there parts which is hard to implement, i would like to know >>>> what and why. >>> >>> >>> Once we have the threaded FFI and the threaded VM then yes, because one can >>> block one thread in a read without blocking the entire VM. But without the >>> threaded VM one needs asynchronous i/o. >>> >> yes, but nobody said, that i can't use non-blocking i/o. >> >> the main advantage which i see for using FFI is being able to deal >> with everything at language level. >> so, bugs can be fixed quickly, things can be improved more easily etc etc.. >> and the main disadvantage is, of course, speed. >> > > No. > The main disadvantage is to expose the complexity of outside world at > user face, when it was once hidden under the VM carpet. And why is that a disadvantage? This is smalltalk. "Users" are developers, not ben laden... is not like we are going to do terrible things with that power. Even if we are newbies, worst thing that can happen is to make mistakes while learning... same as today :) > In the VM, complexity is handled with the "right tools" (cough...) your "cough" is right :). Right tools is what does our life easier, not what is closer to the hardware. > #include machine_specific_stuff.h driven by #ifdef > why_the_hell_is_it_so_complex ;) and include paths library paths > ldconfig etc... > It's of course cough-able because this complexity then spread into m4 > macros for configure scripts and other such niceties. > > Sure, > - when the VM is not able to handle outside world zoo because a lack > of manpower, and because the outside world changed too fast while we > were sleeping happy in our mickey world, > - or if we want more than least common denominator between several > underlying platforms, > then yes, it might be better to adopt your strategy, because we can > get more manpower at image level than at VM level... this is an important issue: is easier to maintain at smalltalk level than c level. And there are more willing hands to code :) > However, it's a kind of pact with the devil: we get the power at the > price of introducing the #ifdef hell in the image. That's simply not true... look at dbxtalk code, if you want. We could do a plugin to deal with that, but we did it with FFI. Plain smalltalk and straightforward (real problem is to compile opendbx libraries, in fact... and I would love to replace them with smalltalk code, but those are just dreams) > Sure, with a good object model, we might think that it will be easier > to handle such complexity. +1 > But then we're just ignoring the efforts of hordes of programmers > maintaining this shit, and redo all in image. horde of programmers (me, for instance) will be most than pleased to be ignored in this case :) > I'm not sure that it will be sustainable... > Unless of course we focus on a single platform. right now OSProcess is also a hell... if Dave chooses to do something else, we are in problems. I prefer a hell in smalltalk than a paradise in C (and of course, vm is not a paradise :) > Your work is very important, because at least, it will enable powerful > single platform extensions. > But as you see, I just wonder how it would help us to continue > providing ubiquity... Same as today, but in a better way :) Lot of plugins don't need to be in VM side if we have a powerful FFI, with callbacks and threads. I think (as a smalltalk programmer and as a vm programmer) that if we can move to image side those plugins, we can focus in the real complexity of the vm, and after all do better things. > > Nicolas > >>>> >>>> If you want to ask, why one would want to do this.. the answer is simple: >>>> we stated previously, that we want to reduce the VM complexity by >>>> implementing things at language side, when it possible, >>>> leaving only key parts to VM. >>>> This is the main reason why i consider implementing OSProcess using >>>> purely FFI, not because of quality of OSProcessPlugin >>>> implementation etc. >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >>> >>> -- >>> best, >>> Eliot >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >
