2012/5/8 Igor Stasenko <[email protected]>: > On 7 May 2012 20:15, Eliot Miranda <[email protected]> wrote: >> >> >> >> On Sun, May 6, 2012 at 9:14 AM, Nicolas Cellier >> <[email protected]> wrote: >>> >>> 2012/5/6 Igor Stasenko <[email protected]>: >>> > On 6 May 2012 17:08, Nicolas Cellier <[email protected]> >>> > wrote: >>> >> 2012/5/6 Guillermo Polito <[email protected]>: >>> >>> >>> >>> >>> >>> On Sun, May 6, 2012 at 2:16 PM, Esteban Lorenzano <[email protected]> >>> >>> wrote: >>> >>>> >>> >>>> <snip> >>> >>>> 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 :) >>> >>>> >>> >>> >>> >>> Just think how many times you took a development image and used it in >>> >>> several platforms. At least I don't. Same happened when I used >>> >>> Eclipse. I >>> >>> didn't share my eclipses between systems. Even, I had several eclipse >>> >>> installations with their own plugins (just like images, hehe). >>> >>> >>> >>> Probably with jenkins, metacello, and kernel/bootstrap we can generate >>> >>> distributions per platform (With the possibility of an all-in-one >>> >>> distribution for the ones who like that). >>> >>> >>> >>> Guille >>> >> >>> >> Yes, I understand that we can live without this feature... >>> >> - If we can reconstruct images easily (one of the goal of Pharo) - I >>> >> mean not only code, but any object (eventually with Fuel) >>> >> - If we solve the bootstrap problem (or if we can still prepare an >>> >> image for cross platform startup) >>> >> - If we don't forget to always talk (send messages) thru an abstract >>> >> layer, and never directly name the target library, >>> >> >>> >> Since I didn't have all these tools in the past, I were forced to use >>> >> development images across different platform a lot, and yes, it was >>> >> not following the mainstream rules (a la "we can reconstruct all from >>> >> scratch") but damn powerful. >>> >> For deploying applications, it also is very powerful and cheap. >>> >> Personally, I would feel sore to lose it. >>> >> >>> > >>> > But look at the root of what we are talking about: N bytes in VM >>> > versus M bytes in image to support certain functionality. >>> > I think if you need it, you will make sure that those bytes is there >>> > and properly packaged with you application. >>> > >>> >>> Unfortunately, it's more than moving code... >>> What I mean is that when I need to pass an O_NONBLOCK flag to a FFI >>> call, it's going to be a problem because I have to know how this >>> information is encoded on each and every platform I want to support. >> >> >> But there are solutions to this which mean you *don't* have to know. I >> wrote a prototype for VisualWorks that maps a SharedPool to these externally >> defined variables. Here's how it works. >> >> For each group of C constants, e.g. i/o constants, one populates a subclasss >> of SharedPoolForC with the variables one wants to define, and in a >> class-side method one defines the set of include files per platform that one >> should pull in to evaluate the constants. SharedPoolForC has code in it to >> automatically generate a C program, and compile it, e.g. to provide a shared >> library/dll for the current platform. The C program is essentially a >> name-value dictionary that maps from the abstract name #O_NONBLOCK to the >> size and value for a particular platform. SharedPoolForC also contains code >> to load the shared library/dll, extract the values and update the pool >> variables automatically. >> >> The deployment scheme is as follows, at start-up the system asks each >> SharedPoolForC subclass to check the platform and see if the platform has >> changed. If it hasn't changed, nothing needs to happen. If it has changed >> the system attempts to locate the shared library/dll for the current >> platform (the platform name is embedded in the dll's name), and update the >> pool variables from that dll, raising an exception if unavailable (and the >> exception could be mapped into a warning or an error to suit). So to deploy >> e.g. a one-click one needs to generate the set of dlls fort the platforms >> one wants to deploy on. >> >> The development scheme is simply to run a method on the SharedPoolForC when >> one adds some class variables and/or changes the set of include files which >> turns the crank, generating, compiling and loading the C file to get the >> value(s) for the new variable(s). >> >
Having an in-image C-parser is a pain (VW/DLLCC parser is not maintained and cannot parse modern headers). So I agree, the best is to use an external C preprocessor/compiler, it's up to date. We thus replace C with C, so it seems more or less equivalent... Is it? We mirror these defines in image with a bunch of OSAPI subclasses. We have also to handle different structure layout if some or our API functions are picking-fields-macros... Also across several linux distros, one has glibc 4.5 and libm 4.8, the other glibc 5.1 but libm 4.3, plus opengl, ssl, etc... A lot of combinatorial... So we cleverly decide to reify each library, and subclass them with each major version, so as to program an OSAPI by composition. We then just have to prepare a configuration file. And if we are very clever, maybe we can query the OS and create a sort of autoconf... To ease our task, each OS provides more or less the same functions, but these are not packaged the same. Two functions are in same library in this OS, and two different libraries on another. Or we have several concurrent implementations (like winsock wsock2)... Some of these nice features of the real world are also polluting the C code of our plugins with #ifdef #include and platform dependent files, but some of the concerns are separated in makefiles at compile time and mainstream cmake and other shits help us a bit. In FFI, I still have the feeling that it is worse simply because we have to resolve the macros and care for differences that would not appear in our C source (only in machine dependent includes), and also care for library packaging if we want to use composition... It's not that it's not doable, it's that we gonna reinvent gaz plant and it gonna be so boring... I'd like to see a proof of concept, even if we restrict to libc, libm, kernel.dll, msvcrt.dll ... Bonus, imagine I install a brand new Linux v3.x.x Because we have a simpler VM, and they care of compatibility, I can recompile the VM, the plugins and restart my favourite image with reduced cmake activity. Unfortunately files are not accessed via a plugin but via FFI, the FILE structure layout changed, I used a picking-fields-macro (like getc, feof, FD_SET or ...) and my image crashes at startup... I have to extract the new structure/defines on v3.x.x, restart an old kernel v2.y.y, prepare in-image structure for new OS, save the image, restart kernel v3.x.x. Phew... I ain't got the feeling we simplified the tool chain in this case too. Nicolas > Yes, i remember you told about it some years ago ;) > > But this requires a platform with compiler installed. otherwise your > system won't be able to adopt to new environment. But of course there > is a solution to that as well: keep a database for every platform in > image, > and detect platform on startup, hoping that everything is in sync :) > And if not, then it usually means that guy using either non-standard > distribution, or custom built kernel etc.. At this point i would stop > worrying about it, since if he is good enough to be able to customize > own system, he can deal with FFI troubles in no time.. > and usually those guys having compiler installed :) > > Also, if system supports binary distributions, then we're in same boat > as any other binary compiled and distributed for that platform.. (need > to elaborate that?) > >> An alternative scheme would generate a program that would print e.g. STON, >> which could be parsed or evaluated to compute the values. This would have >> the advantage that the definitions of the values are readable and editable >> by mere humans. So I think I'd discard the shared library/dll approach and >> keep it simple. >> >> > Indeed. Again, generate C code.. a bit more code doesn't hurts. > > > -- > Best regards, > Igor Stasenko. >
