unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Leo Prikler <leo.prikler@student.tugraz.at>
To: divoplade <d@divoplade.fr>
Cc: 44186@debbugs.gnu.org
Subject: bug#44186: Recursive mkdir
Date: Tue, 27 Oct 2020 10:19:50 +0100	[thread overview]
Message-ID: <e4dc1cfef4da3e35e73fc00129b2f1be68fd9e55.camel@student.tugraz.at> (raw)
In-Reply-To: <064c08f86112e49533000738aa01f98314d3b08b.camel@divoplade.fr>

Hello,

Am Dienstag, den 27.10.2020, 08:01 +0100 schrieb divoplade:
> I think I have made my point for the second commit. I intend this
> change to be user-centric: it would be better to confuse the
> developer
> of a guile program than the user of said program. Anyway, this will
> not
> confuse anyone because creating the directory is not the default
> behavior.
I am very not pleased with this distinction of "user" and "developer". 
Even assuming there is some, it would be wiser not to confuse the
latter, as then they can assure on their own terms, that the former
won't be confused either.  When you've reached the point, where "even"
the latter can't tell you what exactly will happen, how exactly are you
going to ensure the former won't be confused in the event something
*does* go wrong?  Spoiler warning: Returning #t on error won't actually
fix them.

> As for the first commit:
> 
> Le lundi 26 octobre 2020 à 22:05 +0100, Leo Prikler a écrit :
> > 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.
> 
> Exactly, it does not pass the test, because I still can't run them.
That's one way to see it.  For the record, I didn't actually run your
test, but instead copied your code as well as a test into a separate
file rather than building all of guile.  That's an easier way of
prototyping.

> In which file do I write the code, I feel the ports module is not the
> best place.
That's because it isn't.  The only reason you could be led to putting
it there is because of your insistence on the second patch (recall,
that it is not at all needed) along with possibly a belief, that the
only reason to recursively make a directory is to put files at their
root, which is also wrong.

As I have been suggesting multiple times already, you could potentially
maybe drop your second patch without making much impact on those
developers and users, who receive an error when opening a file port
without ensuring the parent directory to exist.  That would allow you
to put mkdir-recursive into the posix module (and test it along with
it) even if it isn't strictly POSIX.  If that's not your cup of tea and
you have more than just mkdir-recursive to add, you might want to put
it into a different module.

Please also note, that Guile also doesn't particularly need *your*
implementation of mkdir-p (or mine for that matter).  Ludovic Courtès,
who you might remember being a co-maintainer along with Andy Wingo,
wrote mkdir-p for GNU Guix, so whether or not it gets included here is
much rather a question of whether or not they want to relicense it
under the LGPL.

> How do you run the tests? When I run "make check", I get 1 of 39
> tests failed, the test-out-of-memory test. It does not even try to
> run the ports test.
Have a look at test-suite/Makefile.am.

Regards, Leo






  reply	other threads:[~2020-10-27  9:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <6ff632f5c1e378647cecc7177b7018fb8a0ee6d4.camel@divoplade.fr>
     [not found] ` <86sga420pw.fsf@gmail.com>
2020-10-23 22:00   ` bug#44186: Recursive mkdir divoplade
2020-10-23 22:07     ` zimoun
2020-10-23 23:32       ` Bengt Richter
2020-10-24  6:17         ` divoplade
2020-10-25  4:13           ` Bengt Richter
2020-10-25  7:45             ` Ricardo Wurmus
2020-10-25  9:07               ` divoplade
2020-10-25 10:44                 ` divoplade
     [not found]     ` <handler.44186.B.16034904223692.ack@debbugs.gnu.org>
2020-10-23 22:46       ` divoplade
2020-10-26 21:05     ` Leo Prikler
2020-10-27  7:01       ` divoplade
2020-10-27  9:19         ` Leo Prikler [this message]
2020-10-27 10:21           ` divoplade

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e4dc1cfef4da3e35e73fc00129b2f1be68fd9e55.camel@student.tugraz.at \
    --to=leo.prikler@student.tugraz.at \
    --cc=44186@debbugs.gnu.org \
    --cc=d@divoplade.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).