Le 17/01/2016 15:47, Eliot Miranda a écrit :
Hi Thierry,
On Jan 17, 2016, at 6:10 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Eliot,
I still don't understand why this platform-specific data (external datatypes sizes, constants values) has to be written as a json file and not as Smalltalk code ?
It can be any notation that is easy to parse. One could use pure Smalltalk, json, ston, xml. I thought ston /was/ a form of Smalltalk aimed at representing key/value pairs, in which case it seems ideal.
What are the objectives for this notation? My take (feel free to suggest a better set) is:
a) be quick to parse since these files are parsed on start-up when the platform is different from that the image was snapshot red on
b) be human readable. The flexibility of being able to version, edit, search and diff these files seems useful
c) be reasonably straight-forward to generate from C. But hey, it's only code :-)
Agreed to all points, of course :) I do think b and a; c is ok.
If I write an interface to an external lib, I'd like to benefit from nice access to Smalltalk code to, say, test versions of the external libraries, set external types based on system information, etc, etc... instead of having to deal with all those various json files outside my normal workflow.
Okay, I can write smalltalk code which runs those C tests programs, extract their output, model them in smalltalk and generate the jsons from there... but, then, I really don't understand why I have to write those jsons then every user loads those jsons instead of just running that setup code I have in my external library smalltalk support package ?
You /don't/ have to write them ever. They are written for you by the FFI shared pool.
Yes, that was understood.
So you're suggesting the C program output a Smalltalk method that looks like:e.g.
initializeMYSQLMac32 MYSQL_ENABLE_CLEARTEXT_PLUGIN := 123. MYSQL_INIT_COMMAND := 234. MYSQL_OPT_BIND := 345
So the trade off you're discussing is whether it is valuable to keep these in the image or not. For me these initialize toon methods are overhead. They get parsed as infrequently as possible. So personally I prefer to use several external files that are parsed infrequently instead of the overhead of several initialization methods that are run infrequently.
For example, if I were deploying on some embedded arm device, the initialization method would be something I'd have to strip from the image. Seems easier to just parse an external file to me.
Well, for me, on a pure technical basis, no. - It adds one failure point: reading one more file at startup. - It adds management issues: slight version differences in an external libs may force me to add context-dependent json file loading.
I like the use of Smalltalk for eg user interface opening code where - we want a UI construction tool to edit an e excitable representation of the interface - there is only one version of the UI method
But with these interface descriptions we could easily end up with a 32-bit and a 64-bit version for every UNIX variant plus Mac OS and Windows. You could easily have ten long methods with overheads in the tens of kilobytes. Seems a waste to me.
No really. You have the same complexity, either in a json or in an init file; and the same level of customization or even more flexibility (you can decide to set those initialisation methods in different packages, and have the flexibility to slice / share the way you like... 64bits / 32bits, 64bits ARM + MIPS are the same except one constant, etc...). It's a bit like dealing with those configure scripts: in C, if you really want multiplatform support, you write #ifdef macros and shell scripts to query the build platform for you... I just prefer to do it in Smalltalk if I have to. But I guess that I could still do it by hacking the FFI layer anyway :) And I'd be happy to see a system modeling layer in Smalltalk (one which knows how to query hardware/software capabilities at startup) since it opens up yet unforeseen possibilities (switching on an OpenCL acceleration layer on supported platforms with the right driver version?). Thierry