On Sat, Jun 13, 2009 at 5:01 PM, Marc Feeleyfeeley@iro.umontreal.ca wrote:

I've tried to come up with a simpler example than server.scm/client.c to explain how to write the C and Scheme code.

Thanks, I've got it working with a few minor modifications like the -I and -L flags to gcc. I still have a couple of questions (and a suggestion), mentioned below.

<snip>

int stdio_settings;         /* default stdio I/O settings */    ___mod_or_lnk (*linker) ___P((___global_state_struct*),());  /* linker C function */

Do we need to provide this linker function because the entry point of the executable is generated from our code, instead of the code in gambit.h?

Maybe it would be better (easier for the programmer) if the following were done:

gambit.h: ------------------------------------------------------------------------ #ifndef ___SCHEME_LIB_LINKER #define ___SCHEME_LIB_LINKER NULL #endif

#define ___setup_params_reset(x) _setup_params_reset((x),___SCHEME_LIB_LINKER) -----------------------------------------------------------------------

The _setup_params_reset sets the value of linker if ___SCHEME_LIB_LINKER is not NULL.

scmlib_.h (generated by gsc along with scmlib.c and scmlib_.c): --------------------------------------------------------------------------- #ifndef ___SCHEME_LIB_LINKER #define ___SCHEME_LIB_LINKER ___20_scmlib_ #endif

___BEGIN_C_LINKAGE extern ___mod_or_lnk ___SCHEME_LIB_LINKER (___global_state_struct*); ___END_C_LINKAGE --------------------------------------------------------------------------- Using the above method, the end programmer would only have to include scmlib_.h, instead of being bothered with the all the #defines. If required he would still be able to set the ___SCHEME_LIB_LINKER manually (maybe a macro ___setup_linker could be provided for that). The above scheme will also maintain compatibility with earlier code (unless someone has explicitly defined ___SCHEME_LIB_LINKER, in which case another obscure name could be chosen).

The C code would then look like: --------------------------------------------------------------------------- #define ___VERSION 404004 #include "gambit.h" #include "scmlib_.h" #include <stdio.h>

/* The definition below could also go into scmlib_.h */ extern int hello( char *str ); /* defined in scmlib.scm */

int main( int argc, char **argv ) { ___setup_params_struct setup_params;

___setup_params_reset( &setup_params );

/* This could also be engulfed by the wrapper macro suggested above */ setup_params.version = ___VERSION;

___setup( &setup_params ); /* setup Scheme library */

printf( "returned %d\n", hello( "montreal" ) ); printf( "returned %d\n", hello( "world" ) );

___cleanup(); /* cleanup Scheme library */

return 0; } --------------------------------------------------------------------------------

#define ___VERSION 404004

Why is this definition required? Is it just a form of a check to alert against using different versions?

-aditya

On Sat, 2009-06-13 at 07:31 -0400, Marc Feeley wrote:

% gsc -link scmlib.scm
% gcc main-c-app.c -D___LIBRARY scmlib.c scmlib_.c -lgambc
% ./a.out
hello montreal
returned 8
hello world
returned 5

*/

Marc:

Once again examples of mixing C and Scheme code on this list contain incorrect gcc compiler options. You will quite possibly get incorrect results in the executable if you don't include -fwrapv, -fno-strict-aliasing, -mieee (on x86), etc., etc., all those options that you work so hard to get right in gsc-cc-o.bat.

I recommend that you put together shell-scripts:

gsc-compile-c-to-o gsc-link-c-to-scheme

that will have the correct options.

This is bug 103.

Brad

So it doesn't seem like the right solution to package all of these decisions in a single script.

What is the right abstraction?

I guess that the right abstraction is - conservative: it always works - end user-oriented: it should work out of the box for those who know nothing and don't want to know more. A few others will tweak it manually. Most people do *not* need unusual (sic) compiler options, or to select the calling convention.

In short: It's better to make it work out of the box for 90% of the users than to make something highly (and with difficulty) configurable for the rest 10%.

Package the "stupid" scripts, and let other users do everything manually as before…

P!

On 14-Jun-09, at 11:58 PM, Bradley Lucier wrote:

On Jun 14, 2009, at 11:32 PM, Adrien Piérard wrote:

...

...

So it doesn't seem like the right solution to package all of these decisions in a single script.

What is the right abstraction?

I guess that the right abstraction is

• conservative: it always works
• end user-oriented: it should work out of the box for those who know

nothing and don't want to know more. A few others will tweak it manually. Most people do *not* need unusual (sic) compiler options, or to select the calling convention.

For some reason I didn't get Marc's reply (I see it on the list archive, though).

Anyone building applications or dynamically-loadable libraries, or calling scheme from C, or ... will have to know *something* beyond

gsc file gsi file

Perhaps the following flags from the makefiles could be exported somehow (have a script that a user can run (in their .bashrc or .cshrc file?) that will add them to one's environment, as GSC_FLAGS_OBJ or something), or perhaps they could just be used in the examples on this list or in the documentation as symbolic variables.

Here's the idea I will implement. Let me know ASAP if you have suggestions.

The gsc compiler will have some new options. Currently there is:

gsc -c foo.scm generate foo.c from foo.scm gsc -link foo.scm generate foo.c and foo_.c from foo.scm gsc -dynamic foo.scm generate foo.o1 from foo.scm

I will add two new options:

gsc -obj foo.scm generate foo.o (or foo.obj) from foo.scm gsc -exe foo.scm generate foo (or foo.exe) from foo.scm

As with the above -c, -link and -dynamic options the name of the file can be chosen with the -o option and C compiler and linker options can be added with the options -cc-options and -ld-options .

The C compiler and linker knowledge will be encapsulated in the gsc- cc.bat script (renamed from gsc-cc-o.bat), which will perform the appropriate action(s) depending on command line arguments and environment variables. With no command line argument the gsc-cc.bat script will dump its knowledge to stdout. The format will be along the lines of:

GSC_CC_COMMAND="gcc -O1 -fwrapv ..." GSC_LINK_COMMAND="ld ..."

That way the user can use this knowledge in his own build procedure, as in

% `gsc-cc.bat` make

There will also be an environment variable GSC_CC_DEBUG which dumps to stdout a trace of the command(s) that the script is executing. So you can do:

% GSC_CC_DEBUG=1 gsc foo.scm

or

% GSC_CC_DEBUG=1 make

One remaining issue... what should be the default gsc option? Currently it is -dynamic, but for consistency with other compilers, and in particular C compilers, perhaps the -exe option should be the default. That way you can do:

% gsc foo.scm % ./foo

and to get a dynamically loadable library you will have to do:

% gsc -dynamic foo.scm % gsi foo

Marc

Bradley Lucier wrote:

On Jun 15, 2009, at 9:33 AM, Marc Feeley wrote:

...

One remaining issue... what should be the default gsc option? Currently it is -dynamic, but for consistency with other compilers, and in particular C compilers, perhaps the -exe option should be the default. That way you can do:

% gsc foo.scm % ./foo

and to get a dynamically loadable library you will have to do:

% gsc -dynamic foo.scm % gsi foo

I think with dynamic languages like Scheme and Lisp with a REPL and a large runtime, the default should remain -dynamic.

I would like to agree with Brad. Scheme users, especially new ones, should be encouraged to used dynamicly compiled sources, and the good way of encouraging them (or let them know it exists) is to have this as the default compilation format. :) This should encourage dynamic development, which is at the core of languages like Scheme!

Having the -exe flag will sure simplifies the standalone executable build process though! hehe Thanks Marc!

David

GHC has a neat ghc --make command, which basically does (half of) what you are going to do http://www.haskell.org/ghc/docs/latest/html/users_guide/modes.html#make-mode Can gambit too, follow dependencies the same way and build too object files when it sees a load/include and that the file is there (and that no static analysis shows this load is in fact dynamically bound to a function that returns the pi-th root of the golden ratio)

I wouldn't want this. It's common in Gambit for LOAD to be ambiguous, i.e. if you want your module to be compiled, you compile it; if you want it to be interpreted, you don't compile it. I switch between interpreted/compiled a good bit for individual modules for debugging, interactivity, quick development, etc.

If Gambit ever adopts a module system, we may have enough information to rationalize about the modules, and this may be possible.

Here are some thoughts:

On Sun, 14 Jun 2009 17:29:36 +0300, Marc Feeley feeley@iro.umontreal.ca wrote:

Thanks for the suggestion. The problem is that there are so many different ways that the C code generated by gsc can be used (creating a .o file, creating an executable, creating a plugin, etc). Depending on the case you may want some unusual C compiler options, like selecting the calling convention, position independent code, profiling, etc.

Regardless of the diversity of use, .o files will be generated. The diversity consist in the content of the .o files and in their linking.

The content is influenced by flags: - language dependent options - machine dependent options - translation step dependent options - warning and debugging options - optimization options

The options can be: - implicit/explicit - required/optional

There are two kind of code uses: - linking - calling

The .o files are linked into modules: - executables - libraries

The calls can be inter/intra modules.

It seems that the objective is geting the linking and the calling right. Maybe a matrimonial agency is required :-)

So it doesn't seem like the right solution to package all of these decisions in a single script.

What is the right abstraction?

Scheme code and/or makefiles ?

________ Information from NOD32 ________ This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com