From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dimitris Papavasiliou Newsgroups: gmane.lisp.guile.user Subject: Re: Need help embedding Guile Date: Wed, 22 Dec 2021 11:41:22 +0000 Message-ID: References: <2a789e248ef8d1922caec7af553cf26e9b360619.camel@telenet.be> <87ee65shtv.fsf@laura> Reply-To: Dimitris Papavasiliou Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8998"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Maxime Devos , "guile-user@gnu.org" To: Olivier Dion Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Wed Dec 22 12:47:47 2021 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n005z-00026L-H1 for guile-user@m.gmane-mx.org; Wed, 22 Dec 2021 12:47:47 +0100 Original-Received: from localhost ([::1]:55946 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n005y-0003rx-H7 for guile-user@m.gmane-mx.org; Wed, 22 Dec 2021 06:47:46 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52810) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mzzzy-0003HM-UE for guile-user@gnu.org; Wed, 22 Dec 2021 06:41:38 -0500 Original-Received: from mail-40133.protonmail.ch ([185.70.40.133]:28821) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mzzzw-00082A-Ot for guile-user@gnu.org; Wed, 22 Dec 2021 06:41:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.ch; s=protonmail2; t=1640173283; bh=Hm1nf0TVhs2GDgnYlzFapzlIMdZjGUhG8sbzbNGZQIs=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc; b=hz8S2LJ3icOwyvAgcBUQhQMCx+beUxdiUX7e2Jq25DVD36JVlAVaPRgmv7xwkrzaj Mg3satYaRbkg3S8UQFgeo+NXCOe2D0IffJaEvZZz1d9lbKLO3QfHQ6LeeyD9zJQtcF uuMn64/vTPjWnQ5Lkv9qxA3Ua02OOLO6ZaoL1K7XhVdBburt62p/a0lVZg+nyB3gC6 kPgcOWTA50+ZCdh61sIp0kWKdn/1ic+cKsnk6P7nI/peAvTeiinD+QFnE8zRTQq2/4 aR7YBS+/LB0LlXgLT/9LhUHgyZKTOyyVFjKNuYyCeMS22p7nIpqkCUCmOV4kr9RPX7 rStpu87HFg4Wg== In-Reply-To: <87ee65shtv.fsf@laura> Received-SPF: pass client-ip=185.70.40.133; envelope-from=dpapavas@protonmail.ch; helo=mail-40133.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.io gmane.lisp.guile.user:17900 Archived-At: Hi Olivier, Thanks for chiming in! On Wednesday, December 22nd, 2021 at 12:39 AM, Olivier Dion wrote: > From this description, what I understand is that you want to use Scheme > as a configuration file for batching the operations to be done in a > second phase in C++. >From an architectural point of view, the situation is probably similar to simple configuration parsing, as you say. In practice though, the scope of Guile's role won't be nearly as limited as what this might imply. In a way, what I'm working on, can be described as a "compiler" for geometry. That is to say, it reads in the description of geometry in some language and then evaluates it and dumps it in a format that can be used for e.g. 3D printing. Guile (amongst other options) supplies the language frontend. For example, one might invoke it on the shell like this: $ compile hollow_cube.scm Here, `hollow_cube.scm' would contain, say: (write-stl "hollow_cube.stl" (difference (cube 2 2 2) (cube 1 1 1))) When the `cube' procedure is evaluated, it creates a node in the C++ backend that evaluates to the geometry of a cube. Similarly `difference' creates a node, with edges to the two cubes, which when evaluated computes their boolean difference and so on. Of course, in this instance, the Scheme code amounts to little more than what might be termed a configuration file, but imagine the code to create a complex mechanical part and the situation is (conceptually) quite different. Creating the complete graph before evaluation begins in the second phase is probably not necessary (nodes could be evaluated as they're created), but it creates the opportunity for certain optimizations (like dead code elimination for instance). This makes some sort of forcing/ensuring that Guile has terminated desirable. > However, I failed to see why you need to finalize these objects > since you're going to use them in your second phase? Foreign objects currently come in two categories: 1. Complete geometric operations such as `cube' and `difference' above. These are allocated on the C++ side and a so-called "smart pointer" (shared_ptr) is exported to Scheme. Failure to finalize this retains a reference on the C++ side, which would prevent destroying the operation. Since these can get quite large in terms of memory, destroying them after they're no longer needed can be essential. 2. "Complex" arguments to the above operations such as transforamtions, planes, points, etc. which are C++ classes, for which the destructor needs to be called in one way or the other. These are generally passed by value to the operations and can therefore be freed once the first phase is complete. > One way I think of would be to fork the process and create your C++ > objects in a shared memory area between the parent and the child. Once > Guile is done reading your inputs, the child process dies and all its > memory is reclaimed by the OS. I have considered that but, besides the fact that it seems a bit heavy-handed, it still won't allow me to make sure the C++ objects are properly finalized. This creates two problems: for one, some object might need finalization that's more than just freeing memory and I'd have to make sure that this isn't the case for each specific type (which typically come from external libraries). And for another, these would show up as leaks in tools such as Valgrind, which would make checking for memory bugs difficult. One idea would be to simply call `scm_gc()' and `scm_run_finalizers()' until the latter returns 0. As far as I can see, this should ensure all finalizers are called, assumming no references to any foreign objects remain, but I see no way of ensuring the latter short of process termination... Dimitris