2012/5/6 Esteban Lorenzano <[email protected]>: > 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 :) >
Well, simplicity is also a goal. A system that a single person can understand... Think Cuis. Especially in Smalltalk there is nothing private, API are not that easy to identify and it's so easy to use a package at the wrong level... Also, another drawback is having to mirror all the foreign system in your image (like you are on Mac intel and have plenty of code for handling Linux libraries, Windows, Solaris, FreeBSD, Smartphones etc...). Unless you automatically load those packages at startup (and more difficult, unload at snapshot)... >> 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) > Exactly, it may remain a dream... It's not true in this specific case because opendbx took all the burden of ubiquity... That's why it is so complex to compile ;) >> 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 :) > It's not the problem of ignoring, it's more the problem of under estimating the required work... >> 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. > There's something that always amazed me: plugins are supposed to be pluggable and while I understand why they depend on some Kernel-VM services, i don't really see why the contrary has to be true. Is it a packaging problem? A distribution problem? I'm all for a better and more powerfull FFI (without threading we can't have efficient asynchronous IO implemented at image level, just a poor man polling one indeed...) But I continue to think there is a price. Is the unix style select() ubiquitous or should I use WaitForMultipleObject() on Windows? Are specification of read/write streams implementation machine independant (bsd/sysv/others...) - AFAIR the selection is implemented with macros... are the fcntl call to set non blocking portable ? Nicolas > >> >> 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. >>> >> > >
