I've commited an initial version of the network library. The C server and client example works on Windows, Linux and MacOSX. For building the binaries, I've used SCons, a very nice build system, because you don't have to care about the details like creating XCode or Visual Studio project files or which programs and parameters to use for creating libraries, it just finds the right compiler and works without much settings (with some exeptions, e.g. the "-Wl,-install_name,@executable_path/./libnet.dylib" hack for MacOSX to allow loading libraries from the current local directory). And it is programmable in Python, which is not as nice as Lisp, but much better than Makefiles. Maybe this would be a good idea for the other native parts of Lispbuilder. But at least a good idea would be to provide script files for building the native parts, because it is not always clear how to do it on different systems. And instead of reading some README files it would be better to automate it, like I've done with build-win32.cmd, build-macosx.sh and build-linux.sh.
Currently the Lisp examples (a simple wget and a webserver) works for Windows with Lispworks. With Gentoo and the packaged SBCL (some 1.0.x version) there is a strange bug with callbacks and on Mac with the latest SBCL, looks like it doesn't accept incoming connections, which is strange, too, because the C client/server example works. Maybe this is still a bug with the C library, which I've committed as an extra project, because it may be useful for other projects, too, not only Lisp. If you want to test the system and maybe fix the bugs (I'll have next week some time to test it), you can load the lispbuilder-net project with all binaries from http://www.frank-buss.de/tmp/lispbuilder-net.zip and the C net project from http://www.frank-buss.de/tmp/net.zip (I'll create a file release at Sourceforge, when it works on all 3 platforms). Some things to improve on the Lisp side: The connection class should be used for the wget example, too and should be moved to the lispbuilder-net directory, because could be used for other projects. Maybe together with some other classes it should provide methods for handling arrays of connections, handling write and read schedules and managing creating and destroying (maybe with timeouts) of connections. HTTP related things should be moved out of the classes, but the connection class should be designed to make it easy to add HTTP capabilities. -- Frank Buss, [EMAIL PROTECTED] http://www.frank-buss.de, http://www.it4-systems.de _______________________________________________ application-builder mailing list [email protected] http://www.lispniks.com/mailman/listinfo/application-builder
