On Fri, Mar 18, 2016 at 10:06 AM, Damien Pollet <[email protected]> wrote:
> Hi Mariano, I just saw your comment in OSSUnixSystemAccessor >> getcwd and > wondered if there's a feasible plan for errno? What if the VM provided a > known accessor function around the global/macro/whatever errno is defined > as? > > Hi Damien, Unfortunately, that comment you read there happens not only for getcwd() but for every function that writes into errno. I already sent this to the mailing list and was discussed [1]. I have also chatted with Esteban about this, and Eliot said in VW VM they have something like this. To conclude, we lack such a support from FFI backend. We hope to add that at some point. Maybe Ronie will have some time to play with this? [1] http://forum.world.st/Question-about-errno-and-NB-FFI-td4867192.html > On 26 January 2016 at 08:15, stepharo <[email protected]> wrote: > >> super! >> >> Stef >> >> >> Le 25/1/16 23:27, Mariano Martinez Peck a écrit : >> >> Hi guys, >> >> OK, I have a first working version and so I wanted to share it with you. >> >> I have not yet the time to start writing the doc since I just finished >> the first pass on the code. Tomorrow I will start with the doc. But I >> thought some of you may be interested in taking a look even without formal >> "doc" (and some feedback/iteration may avoid re-writing docs..). >> >> If you have no clue what I am talking about, then this summary is for you: >> >> *----------* >> *When we use FFI to call a certain library it's quite common that we >> need to pass as argument certain constants (for example, SIGKILL to >> kill()). These constants are defined in C header files and can even change >> it's value in different paltforms. * >> *These constants also are sometimes defined by the C preprocessor and so >> there is not way to get those values from FFI. If you don't have the value >> of those constants, you cannot make the FFI call. * >> *----------* >> >> I have tested the tool in OSX and CentOS using latest Pharo 5.0. It won't >> work in Windows right now. As usual, all classes and methods have comments >> and there are enough tests. >> >> At the end, I decided the C program will output a very naive Smalltalk >> literal array kind of thingy. The tool then parses that output and directly >> creates a init method (which is compiled into the SharedPool class) for >> that platform which is then called automatically at startup (only if >> initialization is needed). >> >> As for real examples, I started to write constants for libc: signal.h >> (to use kill()) , wait.h (to use wait() famility), fcntl.h (to use ... >> xxx()) , and errno.h. You can take a look to the >> package 'FFICHeaderExtractor-LibC'. >> >> Note that for running the tests you need 'cc' findable by path in OSX and >> 'gcc' in Unix. >> >> To load the code in a latest Pharo 5.0, execute: >> >> Metacello new >> baseline: 'FFICHeaderExtractor'; >> repository: >> 'github://marianopeck/FFICHeaderExtractor:master/repository'; >> load. >> Any feedback is appreciated. >> I will start writing the doc now. >> BTW: Big thanks to Eliot Miranda which helped me answering noob questions >> and providing useful code and guidelines. >> Best, >> >> >> On Sat, Jan 23, 2016 at 1:12 PM, Eliot Miranda < >> <[email protected]>[email protected]> wrote: >> >>> >>> Hi Denis, >>> >>> On Jan 23, 2016, at 7:30 AM, Denis Kudriashov < <[email protected]> >>> [email protected]> wrote: >>> >>> >>> 2016-01-22 22:35 GMT+01:00 Eliot Miranda < <[email protected]> >>> [email protected]>: >>> >>>> Let's measure this. Let's say we have 8 platforms (that's an >>>> underestimate, because different Linux distributions may have different >>>> values for certain constants), but 8, which is 4 basic platforms times 32- >>>> & 64-bits. We have Mac x86 32-bit, Mac x64 64-bit, Windows x86 >>>> 32-bit, Windows x64 64-bit, Linux x86 32-bit, Linux ARM 32-bit, Linux x64 >>>> 64-bit, and soon enough there will be more. Further, there may be >>>> different versions over time. >>>> >>>> So each of those initialization methods has >>>> - 1 slot for the global variable to be assigned >>>> - 1 slot for the literal value to assign to it >>>> - 3 bytes of bytecode per initialization for small methods, 4 for large >>>> methods. Let's say 4. >>>> >>>> So the overhead in 32-bits is 12 bytes per constant, and in 64-bits is >>>> 20 bytes. So the overhead per constant for all platforms is 96 bytes per >>>> constant in 32-bits and 160 bytes per constant for 64-bits. A full system >>>> with sockets, files, a database connexion etc could easily exceed 100 >>>> constants. I think it would be nearer 1000. So the overheads are in the >>>> 10- to 100-k byte range (100k ~= 0.5% of the image) on 32-bits. That's low >>>> but it's also pure overhead. Every GC has to visit them. Every senders >>>> and implementors has to visit them, but they offer nothing of value. >>>> Whereas the small parser for whatever notation is used to store the >>>> constants externally (if they are needed in a given deployment) has a small >>>> constant overhead; its simple code. >>>> >>>> Further, you still need the machinery to export the constants to be >>>> able to generate these initialization methods. If you've got the machinery >>>> and you don't need the methods why bother to generate the methods? >>>> >>>> As the Scots say, many a mickle makes a muckle. >>> >>> >>> Thank's Eliot for such detailed explanation. It makes sense. >>> But personally I prefer Smalltalk solution although Smalltalk itself is >>> pure overhead comparing to C. >>> >>> >>> I can see the draw of the pure Smalltalk. Simplicity and brows ability. >>> But imagine a tiny headless image deployed on containers, say 2mb. Now >>> 100kb of initialization code doesn't look so good :-). Anyway I'm beating >>> a dead horse. Mariano is generating initialization methods. >>> >>> >>> My question was raised by Mariano idea to save ston files in methods. I >>> think it can reduce problems which you described. >>> But then literal array syntax can be more suitable than ston. >>> >>> >>> I just want to be clear, I'm neutral about the notation used to export >>> info from the C file. Liberal array syntax, chunk source format, ston, >>> xml. It doesn't matter as long as it's convenient at expressing an >>> attribute dictionary from names to attributes such as value, size, offset. >>> Don't get hung up on the specific notation. If one were to go with the >>> external file the only real requirements are that it be reasonably compact >>> and quick to parse. That might kill xml but leave plenty of other >>> candidates. >>> >>> >>> _,,,^..^,,,_ (phone) >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > -- Mariano http://marianopeck.wordpress.com
