From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Leo Prikler Newsgroups: gmane.lisp.guile.bugs Subject: bug#44186: Recursive mkdir Date: Mon, 26 Oct 2020 22:05:43 +0100 Message-ID: References: <21802e695ea4472c8aba0a686e6bf025890c64d6.camel@divoplade.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18029"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.34.2 Cc: 44186@debbugs.gnu.org To: d@divoplade.fr Original-X-From: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Mon Oct 26 22:06:08 2020 Return-path: Envelope-to: guile-bugs@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 1kX9gt-0004Y0-Og for guile-bugs@m.gmane-mx.org; Mon, 26 Oct 2020 22:06:07 +0100 Original-Received: from localhost ([::1]:50558 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kX9gs-0003Mx-QT for guile-bugs@m.gmane-mx.org; Mon, 26 Oct 2020 17:06:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53664) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kX9go-0003M7-Li for bug-guile@gnu.org; Mon, 26 Oct 2020 17:06:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58331) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kX9go-0005uG-C9 for bug-guile@gnu.org; Mon, 26 Oct 2020 17:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kX9go-0008KM-74 for bug-guile@gnu.org; Mon, 26 Oct 2020 17:06:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Leo Prikler Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Mon, 26 Oct 2020 21:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44186 X-GNU-PR-Package: guile Original-Received: via spool by 44186-submit@debbugs.gnu.org id=B44186.160374635231989 (code B ref 44186); Mon, 26 Oct 2020 21:06:02 +0000 Original-Received: (at 44186) by debbugs.gnu.org; 26 Oct 2020 21:05:52 +0000 Original-Received: from localhost ([127.0.0.1]:41644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kX9gd-0008Js-G3 for submit@debbugs.gnu.org; Mon, 26 Oct 2020 17:05:51 -0400 Original-Received: from mailrelay.tugraz.at ([129.27.2.202]:13807) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kX9ga-0008Jj-A5 for 44186@debbugs.gnu.org; Mon, 26 Oct 2020 17:05:49 -0400 Original-Received: from nijino.local (217-149-162-161.nat.highway.telekom.at [217.149.162.161]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4CKnRs1GL3z3wXQ; Mon, 26 Oct 2020 22:05:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1603746345; bh=wc/xW5uBVs2e45ULsoFusFvjqlMfQb8y0b+OweN7w8U=; h=Subject:From:To:Cc:Date:In-Reply-To; b=u8+reurlC/aq8Tmrj67VaU/okm28nZ2LIiIGNp35GdTDwgHfjaqIH/9MGfTGe9Vcf uC0IoNPA+371mBF889lPs1AN+vKPO3C1T1HjnJTm9YoEGSiW/WZg9O2wKdB601IR2D b8bOe6BJbY2XjyQTR0PwfhyGCWj0ObWKAcOt14mQ= In-Reply-To: c32611441c32d92d6d6462e4a2db53f2846747e6.camel@divoplade.fr X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.io gmane.lisp.guile.bugs:9912 Archived-At: Hello, divoplade, > So, after a bit of bikeshedding on #guile, it turns out that the > controversy moved to the second commit. Not quite, the second commit just needlessly complicates a patch, that should not be that complicated in the first place. When posting a patch to the mailing list, you should do your best to ensure, that all of your code works as intended (alas, I am getting ahead of myself here a bit). It is easier to prove this for *just* mkdir-p/mkdir-recursive rather than having to test all your wrappers as well. You have been pretty adamant, that you need those wrappers, but they can easily be written in whichever library actually ends up using them as well, so you're just creating more work for yourself for little gain. That's the point I was trying to make in the IRC. > Here is the justification for it. > > When a program user wants to save data to a file, if the place where > to > save the file does not exist yet, there will be an error: "cannot > create file or directory". That's puzzling to the user, because, yes, > the user wants to create that file. If the error is a little more > precise, it will be something in the line of "Please create directory > blah/blah/blah before invoking this program". > > So, the user will wonder why the program was not able to create > blah/blah/blah itself, create it, and re-run the program. This is > more > work for the user, work that could have been easily handled by the > program. That would be a nice story in a vacuum, but in practice few systems work like that. Python errors in a similar way to Guile, but with a nicer message. So does plain Node JS. On the part of Node with all of its single package modules, even there the equivalent to your versions of open-output-file is one package[1] removed from the built-in fs module. > Good behaving programs should (recursively) create the directory > before > trying to write to a file specified by the user. That include log > files > for a daemon, for instance. Emacs org-mode babel tangling uses a > :mkdirp t for a similar reason. In order to simplify the development > of > such programs, and in order to avoid bugs where the developer forgot > to > call (mkdir-recursive (dirname output-file)) before (open-output- > file, > call-with-output-file or with-output-to-file, while still keeping > compatibility of the other programs, I propose to add a keyword > argument to these functions. The programming of such procedures would not get simpler by inlining mkdir-p into open-file. Instead, programs written that way would be harder to understand, as the implicit creation of such directories outside of functions that explicitly exist for this implicit creation will cause (some) confusion as to whether or not implicit creation of directories can/will take place and whether that is actually wanted in this context and erroring is not an acceptable alternative. The addition of mkdir-p/mkdir-recursive/make-directories alone would already enable a writer of org-mode tangle to write whichever helper they need for their (in my opinion rather specific) use case in 2 lines. > I also simplified the mkdir-recursive function, to be closer to > https://gitlab.com/leoprikler/guile-filesystem/-/blob/master/ice-9/filesystem.scm > . I'd prefer it if you didn't credit me for messing up your code. ;) The reason my version works, is because (ice-9 filesystem) has a working implementation of file-ancestors, which it uses to create all ancestors in order. The part you've copied only creates one such directory. With the changes you've made, the directory, that does get created, is the first one in the tree, which does not exist. I'm surprised, that this test passes for you, because it does not pass for me. On a somewhat related note, I am getting closer to a 0.1.0 release of (ice-9 filesystem), which I'll then pitch to the Guix mailing lists. Being an outside module, that means you can use it with Guile versions earlier than 3.0.5, which at least in my eyes sounds like a better solution to your problem of not being able to implement org-babel in Guile. Regards, Leo [1] https://www.npmjs.com/package/fse