From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Abou Samra Newsgroups: gmane.lisp.guile.user Subject: Re: Curiosity: Microkernel implemented in Guile ? Date: Wed, 29 Jun 2022 00:23:12 +0200 Message-ID: References: <8735fujyi4.fsf@web.de> <87fsjrap6t.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16456"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Cc: Guile User To: "Dr. Arne Babenhauserheide" Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Wed Jun 29 00:23:48 2022 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 1o6JcY-00044b-0k for guile-user@m.gmane-mx.org; Wed, 29 Jun 2022 00:23:46 +0200 Original-Received: from localhost ([::1]:43310 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o6JcX-0004V1-1H for guile-user@m.gmane-mx.org; Tue, 28 Jun 2022 18:23:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52450) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6Jc8-0004SJ-TB for guile-user@gnu.org; Tue, 28 Jun 2022 18:23:20 -0400 Original-Received: from mout.kundenserver.de ([212.227.17.13]:46881) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6Jc6-0001Yx-JM for guile-user@gnu.org; Tue, 28 Jun 2022 18:23:20 -0400 Original-Received: from [192.168.1.46] ([82.65.251.18]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.184]) with ESMTPSA (Nemesis) id 1MBmDy-1nwMvu1glg-00CDOC; Wed, 29 Jun 2022 00:23:14 +0200 Content-Language: en-US In-Reply-To: <87fsjrap6t.fsf@web.de> X-Provags-ID: V03:K1:sdMZB/ptwsMT+QAg/BTPgNjSA66viFPJultb4YRl0rbrefISRqK dJN9ITKdt2bWinpvwXg7l9F1/OVwaVNVrYwYI3TFMnh1+zTlYj4XRgwY7PTpBntCc3l8ttu LngfrJr+Y1ylY3w/SIePbUE0NBQ/piob9PUA4PpkgK3dTFh9Yv6g4zb7Zt7bfSw3GTQSKio zUHJx84SifuXrKV1xf7dg== X-UI-Out-Filterresults: notjunk:1;V03:K0:lvi7CkkWBKs=:1yqF90leXw0mkpOyd0ydTg e+tao3ZCE+p9dgSLo5JdlHOIeqwuHgrbH1BLHqbXMnaK31FraNKhgQ2G7PlTYY6BM8md0C+rk Ixzj+LFBkDkbwE7ZiNJRePnbsaiM8VC6glIDJFUkDBWQdRDBBeH5M2OkPW8wzHx/2IjWmQpvl ivWWZISHzXu/cBywOVUQC4rZnpb6qngE+hx9cx52HcFLLZ6U6G00O/5keTq8towwO+G75F2d0 xspPzyD8Jt9HpLJvmViAeop04WW0l0/47KBycvIr2l/B2XZbdBZ1lkG5uIxMM911E15T5mDUK bp+f/mwxMHNSnV17L8rq71dqu+In04R4CGOVY06vFVRX7d/Rt9mWkjmIh/Cx3H6u/KJzmCh3B EfaHV1PlV7XGAOS7IXkKQ+ftqQyfpNol4auugxsDDJW9j0scFzzeE8GTV7FZJVIdCYHJKa29k bXV+ptePdxux9yz8xMvJvom+7AsuLWQstzuqRvLifQ1hycGHnzt9TTkavfKR2VmeUwEfHFwuM NXTigpAiSd09RmQpj71lct4SIZtwnAkKzY6i0Jam1e1uVmvenhGKcJUyeOpgTXGFtI+4VPVDf UGOGFvBNIE8VVzqwdkP6rHmWqgV6dhFU+2dT+FDcj5jIkvuVRYyN8ROwXjz0ZeqCemLTovAyy P5Fki6X8NQBwC2njzjx+G90v8/fFfKux+RYDX/tZssNT8cMX4ADXcljvtRcfNV6aZLwQ0FosJ e4vboBrB71BMxTeI50s6ydjExzk6SYnhGFy/Ww== Received-SPF: none client-ip=212.227.17.13; envelope-from=jean@abou-samra.fr; helo=mout.kundenserver.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01 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:18365 Archived-At: Hi, Le 26/06/2022 à 08:22, Dr. Arne Babenhauserheide a écrit : > Jean Abou Samra writes: >> (Also replying to Nala.) On the one hand, you have Guile without >> compiled >> bytecode, which is slow to run, and more importantly painful to use >> because there are no error locations and often no function names in >> error messages. On the other hand, Guile with bytecode takes compilation >> time, which is an impediment in applications where it is merely being >> used as a language that is practical to use for small extensions to an >> existing program, without a need for optimized code. It forces you to >> recompile even if you just touched one file, since otherwise it emits >> ;;; messages about outdated .go files that create noise and/or affect >> correctness. The compilation is impractical to set up when interfacing >> with C if your main function is on the C side since compiling is started >> from the Scheme side. There is no dependency tracking, so you need to >> recompile everything whenever you change one file, which does not >> encourage >> quick experiments. Bytecode is fussy to integrate in installers: when >> the user >> unpacks an archive, you need to ensure that the .go files are unpacked >> after the .scm files, otherwise Guile will consider them outdated. I >> could list more … > Please do! I’ve been trying to get a concrete list for issues hurting > Lilypond for a long time. > > To summarize what I understood so far (with notes): > > - The compilation-messages (I hate them; these also hurt when writing > interactive utilities for the command-line, and I have too many > half-working fixes in script files to still be comfortable; I think I > once had a fix in configuration, but I lost it again — or maybe I had > just hacked Guile) > > - No dependency tracking for the explicit compilation, so changes to > Guile-code used elsewhere require an expensive re-compilation step, > even though compile-times are just what you want to avoid with a > scripting language ⇒ auto-compilation should just work and be > *silent*. Could this be fixed with a tool that recovers those > dependencies from Scheme-files? Something like > ./list-dependent-files.scm --start foo.scm bar.scm baz.scm moo.scm goo.scm > ⇒ bar.scm > baz.scm Add: - There is no simple way to byte-compile when the main   function is in C(++). See the thread https://lists.gnu.org/archive/html/guile-user/2022-02/msg00129.html   about this one. - A smarter strategy than looking at modification dates should   be found for deciding when a bytecode file is outdated, for   example storing a hash of the source file in the bytecode.   This should avoid the problems with extracting and installing. - Unless compilation is made really fast and can be used on-the-fly   for large code chunks, interpreted code should be able to give   meaningful error locations and backtraces. >> Sorry for not exactly bringing enthusiasm to this otherwise interesting >> thread. > Don’t worry. I asked, and I’m glad you answered. There might be things > that cannot be fixed, but I have not yet seen one here. Sure, everything can be fixed with enough time and motivation. We're in the free software world after all, and I have no problem with tinkering with Guile myself to fix issues that affect me. The problem, though, is getting the patches in Guile after they have been produced. For example, exactly three months ago I posted a patch fixing docstrings in curried definitions which would fix a problem that prevents functions defined using curried define from being listed in LilyPond's autogenerated documentation. So far the patch has not received a reply. The same holds for most patches being posted. This is the single one thing that saddens me most about Guile, before all the technical issues. Quite frankly, Guile is on the right path to abandonware. I've said this before and I hoped the discussion would lead to some change, but it didn't seem to happen. > Though I don’t want to give false hope: I am not a core developer, so I > cannot promise fast fixes. I can only promise that I will help pushing > Guile more into the direction that Lilypond needs. In my view, the most significant direction that LilyPond needs is a situation where maintenance fixes can make it to the main branch. Thanks, Jean