From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Avoid GOOPS in (system foreign-object)? Date: Fri, 22 May 2015 09:58:11 +0200 Message-ID: References: <87wq022bn3.fsf@gnu.org> Reply-To: mikael@djurfeldt.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b3a82e2879cfb0516a7058e X-Trace: ger.gmane.org 1432281502 18343 80.91.229.3 (22 May 2015 07:58:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 May 2015 07:58:22 +0000 (UTC) Cc: Andy Wingo , guile-devel To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri May 22 09:58:22 2015 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YvhqV-0000CR-Kg for guile-devel@m.gmane.org; Fri, 22 May 2015 09:58:19 +0200 Original-Received: from localhost ([::1]:60759 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvhqT-0003S1-Kh for guile-devel@m.gmane.org; Fri, 22 May 2015 03:58:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41649) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvhqQ-0003Rt-GZ for guile-devel@gnu.org; Fri, 22 May 2015 03:58:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YvhqP-0003mW-8c for guile-devel@gnu.org; Fri, 22 May 2015 03:58:14 -0400 Original-Received: from mail-wi0-x235.google.com ([2a00:1450:400c:c05::235]:38542) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvhqP-0003m1-14; Fri, 22 May 2015 03:58:13 -0400 Original-Received: by wichy4 with SMTP id hy4so38498100wic.1; Fri, 22 May 2015 00:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=N8nZvU2FEEOfZgIcN2Ut/E0sWVrEt/y9TKIQ41R7R/s=; b=LmtCYCnV5INJGgD+BDD9+3JF2qw6huOhUk2hQYGawzLeSMo3wCE3DMJrcvVb/EP699 Gsji48GGQwJB39+NDKntZdsyWEmf6v4U3t2wnOGB6o8sa8phHnlfsKGH/jzkUnfb7kYU CRhfhxYNbJsIzH4K31VlwvRe9oglkOg6kJiwXIQZGNndHGdArVkH/j1Rg+1Xj5P2R3j4 3bbJSTEUy+VUS34b+OAggphD4Kz4rTPZB4LXZj2oJlaAM3qA5luIMdyq26Hy9DCUUeI+ M68MzxBObI0A7rnvx+uwBvijYO/cNY/uOSJHicYDdkMHghco3qs1Xnt5y5caWX9pzlXJ HyyQ== X-Received: by 10.194.209.130 with SMTP id mm2mr12389880wjc.64.1432281491674; Fri, 22 May 2015 00:58:11 -0700 (PDT) Original-Received: by 10.194.80.167 with HTTP; Fri, 22 May 2015 00:58:11 -0700 (PDT) In-Reply-To: <87wq022bn3.fsf@gnu.org> X-Google-Sender-Auth: jZwJ-MNWdLfeTtzevZBlV1i80t0 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::235 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 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 Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17722 Archived-At: --047d7b3a82e2879cfb0516a7058e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ludovic, Sadly, I nowadays only have time to look at guile-devel briefly now and then. I did this now and happened to see this. Just wanted to say that I think that we (or at least I) at some point in time had the goal to replace structs with pure GOOPS data structures. In the context of FFI, this would allow you to be more flexible than what structs allow, ultimately being able to access arbitrary C structs and C++ structs/classes directly from Scheme. I find that a proper MOP (which maybe still is not fully developed) is a nicer way to handle non-standard access than the strange character strings in struct vtables... Happy hacking! Mikael On Thu, May 21, 2015 at 5:28 PM, Ludovic Court=C3=A8s wrote: > Hello! > > I would like to have foreign object types based on structs rather than > GOOPS classes. > > The rationale is that GOOPS is normally not loaded unless the user > explicitly asks for it; having (system foreign-objects) load it would > add overhead even for users who just want SMOB-like functionality. > > WDYT? > > The preliminary patch attached is an attempt to do that. Somehow, the > creation of GOOPS classes for vtables doesn=E2=80=99t work as I thought, = which > means that =E2=80=98test-foreign-object-scm=E2=80=99 cannot define method= s and so on > (which I agree is useful functionality.) What am I missing? > > Thanks! > > Ludo=E2=80=99. > > PS: The reason I=E2=80=99m looking at it is that I would really want us t= o > release 2.0.12 ASAP, so any changes to this API must be settled. > > --047d7b3a82e2879cfb0516a7058e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ludovic,

Sadly, I nowa= days only have time to look at guile-devel briefly now and then.=C2=A0 I di= d this now and happened to see this.

Just wanted to say that I= think that we (or at least I) at some point in time had the goal to replac= e structs with pure GOOPS data structures. In the context of FFI, this woul= d allow you to be more flexible than what structs allow, ultimately being a= ble to access arbitrary C structs and C++ structs/classes directly from Sch= eme.=C2=A0 I find that a proper MOP (which maybe still is not fully develop= ed) is a nicer way to handle non-standard access than the strange character= strings in struct vtables...

Happy hacking!

Mika= el

On Th= u, May 21, 2015 at 5:28 PM, Ludovic Court=C3=A8s <ludo@gnu.org> w= rote:
Hello!

I would like to have foreign object types based on structs rather than
GOOPS classes.

The rationale is that GOOPS is normally not loaded unless the user
explicitly asks for it; having (system foreign-objects) load it would
add overhead even for users who just want SMOB-like functionality.

WDYT?

The preliminary patch attached is an attempt to do that.=C2=A0 Somehow, the=
creation of GOOPS classes for vtables doesn=E2=80=99t work as I thought, wh= ich
means that =E2=80=98test-foreign-object-scm=E2=80=99 cannot define methods = and so on
(which I agree is useful functionality.)=C2=A0 What am I missing?

Thanks!

Ludo=E2=80=99.

PS: The reason I=E2=80=99m looking at it is that I would really want us to<= br> =C2=A0 =C2=A0 release 2.0.12 ASAP, so any changes to this API must be settl= ed.


--047d7b3a82e2879cfb0516a7058e--