2012/5/6 Igor Stasenko <[email protected]>: > since most of Nicolas concerns were answered by others, there's only > one thing i'd like to say about: > platform-specifc zoo. > > At first look it can be scary, but look at opengl binding using > nativeboost: we were able to deal with it > at image side. And in our case a platform-specific code is maybe less > than 1% of total codebase of all NBOpenGL code. >
Well, like opendbx, maybe because opengl has quite standard interface... > Remember an endless issues "B3DAccelerator doesn't works, XYZPlugin > doesn't works", because of all this ldconfig/etc mess.. By the way, a wrong decision in the VM totally messed up the way FFI search and find libraries too. This decision was related to plugins, since the goal was to limit the possibility of loading a wrong plugin. So the looked up paths were restricted for plugins. Unfortunately, the same primitive is shared by FFI, and we also restricted the FFI search path... But it would be a mistake to try to mimic underlying platform rules with in-image code. That's a waste of time, energy and cannot fit settings that are customizable! What we need instead is to correct the VM and just use existing platform mechanism. We also need to add a possibility to bypass it and use our own specific library paths when we want to. > Every time we have such issue, we need to look at VM code, patch it, > and rebuilt it again. > That means more time and more people involved every time there are > issue in VM side. > In contrary, if problems like this arising in FFI world, users can > easily patch the code by they own, > and have stuff working in minuted instead of days (or even months) > waiting till new VM build will be released. > I agree. For our own use, it's not a problem because we can compile our own VM. But when it comes to distributing, yes, this is an heavy burden we drag... As for the user, yes, a DIY can make a workaround possible and that's better than nothing. See the library path example above... But imagine you want to distribute a software made with Pharo. What you gonna tell to your user if you don't have a generic solution that works and only workarounds? DIY ? Maybe I'm old, but I remember of Smalltalk distributions that just work... > Especially for OSProcess: why i targeting it? Because it exposing most > basic kernel functionality, which can be found on all systems. That > means there much less likely will be the problems with linkage with > right libs etc. Since OS kernel is there and cannot disappear. > As Eliot said, it's hard to solve it entirely with FFI, and it's better to have a single primitive that fork, close file descriptors except a list to keep opened (pipes) and exec... > And last but not least, of course, avoiding problem of minimal common > denominator. For any software experts, i guess , it is important to be > able to access the full potential of a system, not a small portion of > it. > It might be not that important for people with "living in sandbox" > mindset, but if you really approach with goals like "i want to > implement a modern application on this system using this language" > then you probably > will start worrying about limitations sooner or later, as well as, how > easy you can change it to adopt to your needs. > I can only agree with that. Nonetheless, it's also Pharo's responsibility to provide the common denominator. Nicolas > -- > Best regards, > Igor Stasenko. >
