***sneek_ is now known as sneek
***apteryx is now known as Guest16909
***apteryx_ is now known as apteryx
<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? <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? <leoprikler>It also differs from your recursive mkdir in that it doesn't create (getcwd) <divoplade>In fact, if the current working directory does not exist, (getcwd) throws <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>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. <z0d>you cannot defend against all errors <z0d>what if someone kills your extracting process? <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>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>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. <leoprikler>Perhaps, but do you not realize how it makes your patch needlessly larger? <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 <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. <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. <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. <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>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