From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Michael Tuexen Newsgroups: gmane.lisp.guile.devel Subject: Re: Initial SCTP support for the upcoming 1.6.5 release Date: Mon, 23 Aug 2004 21:54:31 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <3FE09419-F53E-11D8-B290-000D932C78D8@lurchi.franken.de> References: <28C61BE4-EB92-11D8-9129-000D932C78D8@lurchi.franken.de> <02FA4EE0-EFA6-11D8-B63D-000D932C78D8@lurchi.franken.de> <87ekm67wis.fsf@trouble.defaultvalue.org> <58846D32-F2D5-11D8-9904-000D932C78D8@lurchi.franken.de> <87oel2r7p3.fsf@zip.com.au> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1093290904 25098 80.91.224.253 (23 Aug 2004 19:55:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 23 Aug 2004 19:55:04 +0000 (UTC) Cc: guile-devel@gnu.org, Rob Browning Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Aug 23 21:54:53 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BzKu5-0008Oo-00 for ; Mon, 23 Aug 2004 21:54:53 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BzKyY-0000pM-7g for guile-devel@m.gmane.org; Mon, 23 Aug 2004 15:59:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BzKyV-0000p6-H4 for guile-devel@gnu.org; Mon, 23 Aug 2004 15:59:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BzKyT-0000nw-D3 for guile-devel@gnu.org; Mon, 23 Aug 2004 15:59:27 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BzKyT-0000np-AE for guile-devel@gnu.org; Mon, 23 Aug 2004 15:59:25 -0400 Original-Received: from [193.175.24.27] (helo=ilsa.franken.de) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BzKtu-0006np-By for guile-devel@gnu.org; Mon, 23 Aug 2004 15:54:42 -0400 Original-Received: from [192.168.1.22] (p5089DFB7.dip.t-dialin.net [80.137.223.183]) by ilsa.franken.de (Postfix) with ESMTP id D10CE245CF; Mon, 23 Aug 2004 21:54:35 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <87oel2r7p3.fsf@zip.com.au> Original-To: Kevin Ryde X-Mailer: Apple Mail (2.619) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:4017 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:4017 Hi Kevin, the problem is that this function is defined in socket.c and the structures I'm interested in are SCTP specific. As far as I understood the comments on the list it is not appropriate that SCTP stuff is used that fil (or in guile at all). Since the set/getsockopt function does not reference any specific structure it would be a possibility of have it provided as generic as it is in C and I would write some scheme functions to transfer the SCTP specific data into the generic one. This would allow me to provide a C based module to provide SCTP functionality without using my own version guile which I want to avoid, because it is difficult for me to test all the platforms. BTW, do you know how handle a function like SCM_DEFINE (net_sctp_recvmsg, "sctp-recvmsg!", 2, 2, 0, (SCM sock, SCM str, SCM start, SCM end), "Return data from the socket port @var{sock} and also\n" .... "descriptor: any unread buffered port data is ignored.") #define FUNC_NAME s_net_sctp_recvmsg { int rv; .... return scm_list_4 (SCM_MAKINUM (rv), address, SCM_MAKINUM (flg), s_sinfo); } #undef FUNC_NAME in a module? I have not found an example for C based modules for guile yet. Everything distributed with guile is scheme based, I think. Best regards Michael On Aug 23, 2004, at 2:58 AM, Kevin Ryde wrote: > Michael Tuexen writes: >> >> Could the setsockopt and getsockopt functions be extended such that >> they support an arbitrary length opt_value? > > The best is for the guile code to understand the data passed so it can > do a sensible conversion. You'll have to say what you're trying to > use. > _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel