IRC channel logs


back to list of logs

***sneek_ is now known as sneek
***apteryx is now known as Guest16909
***apteryx_ is now known as apteryx
<cbaines>divoplade, o/
<divoplade>It works!
<divoplade>sneek, botsnack
<divoplade>So, I was trying to write a patch to provide a recursive mkdir function, but I have open questions
<divoplade>Like: where should I write it? Where should I document it? How do I test it?
<leoprikler>For the record, have you tried yet? ;)
<divoplade>I'm only interested in the recursive mkdir function
<divoplade>As far as I can see, this is the same function as mkdir-p from guix, right?
<divoplade>Not really, in fact
<leoprikler>Not quite, but it should be have similar to it.
<leoprikler>s/be have/behave/
<leoprikler>It also differs from your recursive mkdir in that it doesn't create (getcwd)
<divoplade>I've updated this
<divoplade>In fact, if the current working directory does not exist, (getcwd) throws
<divoplade>So it's not possible to fix
<divoplade>And as suggested, I wrote it as scheme
<leoprikler>Okay, as a bit of bikeshedding I really don't think you need to modify all procedures, that might open an output file to have an mkdir parameter
<leoprikler>Most programs ensure that those directories exist once at the start of execution.
<divoplade>I've re-written the mkdir to be closer to yours
<divoplade>For the mkdir parameter in output files, that's what emacs org-mode uses
<divoplade>When tangling, you can pass :mkdirp t, so that org-mode will create the directory if it does not exist before tangling
<leoprikler>Okay, but that's a specific use-case of emacs org-mode.
<leoprikler>There is a large class of programs, that do not need to call mkdir-p on demand.
<divoplade>For a more general view, I think it is more consistent with the behavior of these functions to create the file if it does not exist
<leoprikler>Hence why you see this function in org-mode and not the emacs core.
<leoprikler>"Create the file" != "Create the entire directory structure"
<divoplade>I have a hard time thiking of a case where you would want to create the file if it does not exist, but fail if the directory does not exist
<leoprikler>Okay, assume the following:
<leoprikler>You begin extracting some files from an archive, and that takes a long time.
<leoprikler>While you are doing so, someone recursively deletes the directory you're working in.
<leoprikler>I think it is perfectly acceptable to error hard in such a scenario.
<divoplade>And what if someone deletes just a file?
<divoplade>Or overwrite it
<z0d>you cannot defend against all errors
<z0d>what if someone kills your extracting process?
<leoprikler>Then they're free to do whatever.
<leoprikler>Still I'd reason that the person who just deleted your extraction directory does not want you to recreate it on the next file.
<divoplade>Now consider this. You want to create a server, but you let the caller tell you where to write the log file. So for instance, it's /var/log/fancy/directory/structure/file.log. You want to call open-output-file, but create the directory recursively.
<leoprikler>divoplade: Calling (mkdir-p (dirname logfile)) is not a huge code overhead for the server.
<divoplade>That's right, so it's not too heavy to put in guile!
<divoplade>Also, if you look at open-output-file, you will see that it's just a wrapper for open-file
<divoplade>So I'd reason that open-output-file should not be included in guile!
<divoplade>(well, I would not say that of course)
<leoprikler>I think you're strawmanning here.
<divoplade>The situation is quite similar
<divoplade>There are a few case where you want open-output-file, and a few cases where you want another open-file than open-output-file
<leoprikler>"quite similar" is a matter of interpretation.
<leoprikler>You actually rarely want to interact with either of them.
<leoprikler>Instead, you'd like to have clean functions like call-with-output-file that set up the file descriptor etc. and close it when no longer needed.
<leoprikler>open-output-file and open-file exist for those cases where you need to do something very different.
<divoplade>That's just moving the discussion, as I propose to add the mkdir argument to call-with-output-file too.
<divoplade>For log files, it's even the with-output-to-file level that's relevant.
<divoplade>(and with-error-to-file)
<leoprikler>Perhaps, but do you not realize how it makes your patch needlessly larger?
<divoplade>It's not needless
<divoplade>I've been annoyed by a lot of errors of "cannot create file" when I wanted to create a file, because the parent directory in fact did not exist
<divoplade>That's very puzzling for newcomers
<libfud>is that a bad thing?
<libfud>not the puzzling part
<divoplade>I think so.
<libfud>sure, a more descriptive error would be good
<libfud>but creating a file is different from making a directory
<divoplade>"a more descriptive error would be good": no, because this error would need to be handled by the programmer, not the user
<libfud>mkdir will make a directory if the parent directories preceding it exist, but requires the -p flag to create those parents when they don't exist
<libfud>I just barged into a conversation without reading much of the preceding context
<libfud>it's been a long few weeks for me
<leoprikler>Not exactly the same behaviour due to the slightly better error as libfud suggest, but still
<divoplade>leoprikler, precisely. Now imagine that it happens because the user wanted to save some data to a file in a hierarchy that did not exist yet.
<leoprikler>"Oh no, we need to change the Python standard library, because I'm too lazy to call mkdir(parents=True)
<divoplade>My point is, you want to call that mkdir function every time you open a file for output.
<divoplade>Why not make it easier?
<leoprikler>In most contexts, the user will ensure that this hierarchy exists as they select the save file (GUI applications) or the software can call (mkdir-p (dirname f)) before saving.
<divoplade>(or nearly every time, agreed)
<leoprikler>It does not make things easier.
<libfud>you can add your own abstraction
<libfud>we are talking about calling a function in a programming language right?
<libfud>why not make your own function to handle non-existent directories and put it in your own library
<leoprikler>Because that single-function library won't be included in Guix.
<libfud>oh, that's what this is about
<libfud>I need to go to bed
<leoprikler>divoplade: Anyway, changing all open-file wrappers to add mkdir-p to them makes the functions (and your patch) needlessly larger for little (if any) benefit.
<divoplade>So the user does not need to care if the file does not exist, but it will need to jump through hoops of mkdirs (and, as I know users, "sudo mkdir") if there is a backtrace.
<leoprikler>why should anyone want to invoke "sudo mkdir" on a backtrace?
<leoprikler>wtf are you on?
<divoplade>What does that mean?
<leoprikler>What I am saying is that adding mkdir-p and *just* mkdir-p already covers all the cases in which a library might want to first ensure that a directory exists before calling (open-file) or any of its variants.
<leoprikler>As such it is not needed to directly modify open-file etc.
<leoprikler>It then follows, that mkdir-p as a variant of mkdir can be put closely to where that is defined, i.e. in posix.scm and documented along with mkdir under POSIX > File System
<leoprikler>Alternatively, were you to add a large number of non-standard filesystem extensions, you could write that as (ice-9 filesystem), like I am currently doing.
***jonsger1 is now known as jonsger
***amiloradovsky1 is now known as amiloradovsky