On May 6, 2012, at 1:16 PM, Nicolas Cellier wrote: > 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...
yeah, is a goal, but also is a goal "everyone being capable to modify their system", and that is much easy if all system lives inside image, and not hidden in a plugin. > > 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)... well nobody (except Marcus and myself) complains against one-click packaging, and it's exactly that :) nah, seriously: yes, this is an issue and we need to think about that to have a good solution (btw, OSProcess and many other plugins are also not available for all platforms, just mac, win and linux). > >>> 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 ;) in fact, opendbx just provides a common api to different backends... and that's perfectly doable in smalltalk (also it should be much easier than doing it in C) > >>> 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... problem is that if you have "right tool" (and I think Pharo is), complexity is automatically reduced :) > >>> 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? Is because they are not plugins at all, because without them image don't start (think on FilePlugin, for instance... since image need it to load changes and sources, you can't drop it –unless we put sources inside image), but well... there are more. I think is a design problem (and by the way, a design problem we can solve by having plugins inside image :P) > > 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 ? Every benefit has its drawbacks... and we need to take steps to mitigate them... but I just don't think in this case we can list "overcomplexity" as a drawback, I think is quite the opposite: it will reduce accidental complexity (essential complexity will always be there: in a plugin or in Pharo). I'm more worried about having all-platforms-specific-stuff inside image... but we can mitigate that with fuel, and making loadable packages when running the image... I don't know, I'm just thinking while writing, so, this is probably stupid :) Esteban > > 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. >>>> >>> >> >> >
