Le 17/01/2016 15:47, Eliot Miranda a écrit :
Hi Thierry,
On Jan 17, 2016, at 6:10 AM, Thierry Goubier
<[email protected]> 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
