IRC channel logs
2023-09-29.log
back to list of logs
<sneek>dsmith, you have 4 messages! <sneek>dsmith, antipode says: The manual you linked to does not say they take "dir file port". Instead, it says it takes a "file port", and the variable is named "dir", indicating that the "file port" is a port for a file that is a directory. <sneek>dsmith, antipode says: You make those the same way you make regular file ports, i.e., with 'open-file'. <sneek>dsmith, antipode says: Unless you have a special file system where you have regular files that are at the same time also directories, passing a regular file port won't do anything useful. <sneek>dsmith, antipode says: So no, most likely it isn't ‘regular file port that is in the same directory'. <dsmith>sneek, later tell antipode Thanks <dsmith>So, the port is for any random file in that directory. <dsmith>For some reason, I've got it in my head that you never just "open" a directory. It's always through some special api. <RhodiumToad>you generally can't actually read directories these days (you used to), but you can definitely open them <RhodiumToad>depending on OS, there are mode flags like O_SEARCH / O_PATH to use specifically for directories <dsmith>Like opendir, readdir, closedir. Yeah back in the day you def could just open them. <dsmith>Used to open *and* then read them. And needed to know the struct for the entries. <dsmith>Thanks. I'll have to play around a bit. <RhodiumToad>(statat (open "somedir" O_PATH) "somefile") basically <dsmith>I'm assuming then the *at funcs just use the fd of the port.. <dsmith>So what's the main advantage or motivation for the *at funcs? Not having to cd and/or /traverse/the/whole/path/to/the/file <RhodiumToad>changing directory is a _huge_ issue in threaded code <dsmith>Ya. Never thought about it. Makes sense. <RhodiumToad>being able to specify a directory handle makes it much easier to walk trees <RhodiumToad>though guild doesn't seem to have an fdopendir or opendirat <dsmith>Hm.. In like 35+ years of C coding, I don't think I've ever made a chdir call.. <dsmith>In shell scripts, lots. But in C? <RhodiumToad>things like ftw/fts often change the directory internally (or did in the past) <rlb>dsmith: if y'all were talking about what I think you were, iirc the "at" variants can also be important wrt performance (so the kerel, etc. doesn't have to re-parse/traverse/etc. the path for every operation), and safety (for related reasons -- i.e. target can't change). <haugh>Is SRFI-19 the extent of the date math available to us? My friends are running circles around me with pandas. It's embarrassing. <wingo>civodul: i looked at rlb's patch set to enable parallel tests. it keeps check-guile but somehow lets automake run things in parallel using the parallel driver. seems ok to me. wdyt? <wingo>iirc it does so by having automake run ./check-guile foo.test, and it has a list of all the tests <wingo>so it can partition them etc <civodul>i haven’t seen the patch (i’m a bit swamped) <civodul>one thing to keep in mind is that we’re not testing the same thing if we run several ./check-guile processes <wingo>well, ./check-guile is still serial <wingo>it's just "make check -j20" that becomes parallel <civodul>i mean: “./check-guile x.test y.test” is not the same as “./check-guile x.test; ./check-guile y.test”, due to state <wingo>ideally there is no state of course... but, yes <civodul>it potentially changes the bug-finding performance of the thing <wingo>i think it would be better to have parallelism in check-guile, in theory, but this is a not-terrible intermediate step <wingo>i guess you would mostly want check-guile to look for a make job server if it is around, to limit parallelism, and default to using all current processors, with an option to limit to serial processing <civodul>but then there are some tests that require single-threadedness <civodul>so maybe Automake is more reasonable, all things considered <wingo>well, i would want to use processes actually, in the hypothetical check-guile parallelism, to enforce isolation of effects <wingo>i am not delighted at depending on more automake "features" but this seems not too terrible <old>and I wonder why my debugging experience with Geiser is not the same and more a `(pk stuff ...)' approach <old>Could we have something like this in Scheme as well. Is this possible? <minima>is there anything that is as safe as `system*' but that will allow to parse the output of a command as you can with, say, `open-input-pipe' <minima>"safe" as in, you feed it with a list of strings, only the first of which will be used as a command <minima>basically, to safeguard against "echo foo; rm some-important-stuff" <minima>oh wait... i see there's a `open-pipe*' <minima>RhodiumToad: this is embarassing <dadinn>I am curious about conventions, whether it's recommended/acceptable to use earmuffs on named parameter variables? <dthompson>dadinn: parameters as in make-parameter? usually those are named like 'current-foo' and earmuffs would be reserved for a op-level mutable variable. <dadinn>dthompson yes, like in (define foo (make-parameter #f)) <dadinn>dthompson the problem is that the non-earmuffed names are already used. I need to somehow differentiate the named parameters. I could either add some suffix to it like "-param", or I was thinking maybe earmuffs could work well too. I clojure earmuffed variables are used to designate dynamic variables, intended to be used for thread-local <dadinn>overriding. Guile named paramaters seem to have the same function, so I assumed similar conventions might be appropriate? <dadinn>dthompson what is a "op-level mutable variable"? <dthompson>a variable defined in a module whose value gets 'set!' at some point. <dthompson>(define-module (foo) #:export (*foo*)) (define *foo* 1) (define (inc-foo!) (set! *foo* (+ *foo* 1))) <dthompson>this is the conventional use of earmuffs in scheme <dadinn>These variables are primarily to be used with parameterize <dthompson>right. I'm saying it's unconvential to use earmuffs for variables that refer to parameters. <dthompson>doesn't mean you can't name things whichever way makes you happiest :) <dadinn>I am trying to contribute an alternate ice-9 expect module using hygienic macros back to Guile. If those earmuffs were frowned upon, it would likely be rejected. <dadinn>I personally think earmuffs would be appropriate for thread-local dynamic variables in a module... but my intuitions likely won't match the guidelines. <dthompson>I'm sure someone could suggest more desirable names during code review. my advice would be don't worry about it too much. :) <dadinn>Thanks a lot for the advice, in that case I'll just go ahead with the earmuffs for now! :] <rlb>dadinn: I'd say that yeah, that's of course the convention in clojure, and I don't think I've ever seen it for that in scheme/guile. In common-lisp, iirc, it was more often an indicator of a global. <rlb>s/was/is/? (Haven't worked a lot in common lisp in a long while.) <rlb>wingo, civodul: thanks for looking at the parallel test harness. I suspect I may at least need to add the (I think still expected) per-file commit message entries, and happy to adjust anything else, if desired. <rlb>And yeah, I suppose we could probably eventually teach guile to talk to make and manage the parallelism itself. Though I also agree that it might not be bad to still keep some per-process isolation (as an option, if nothing else). <rlb>With the parallel test arrangement, you get closer to the same thing if you run ./check-guile foo.test after a failure. With current guile, the envt is (as you suggest) potentially different. <minima>what's the idiomatic way of processing a file and returning a list or an empty list if there's no such file? (if (file-exists? filename) (do-stuff-with-filename) '()) but i'm not very fond of it <minima>that doesn't look very idiomatic to me, and i suspect i might be missing something <RhodiumToad>(or (false-if-exception (do-stuff-with-filename)) '()) perhaps? <RhodiumToad>depending on what you want to do if there's some error other than "file doesn't exist" <minima>RhodiumToad: that seems already much better, thanks! <minima>hm true, maybe i shouldn't let silently fail, which i know it's usually bad practice <RhodiumToad>you specifically want an empty list rather than, say, #f when the file doesn't exist? <minima>well, i'm not completely sure, but yeah i was thinking an empty list would be the easiest down the line <RhodiumToad>I don't see anything especially wrong with using (if (file-exists? ...) ... ...) <RhodiumToad>(and (file-exists? filename) (do-stuff-with-filename)) will return #f for nonexistent file <minima>oh ok, brilliant, that's good to know, thanks - i'll try and rethink the flow a bit - but otherwise i'll go for it then <RhodiumToad>using an empty list for a missing file is also perfectly valid if the situation calls for it <haugh>RhodiumToad, take the current date, add six months to it, then come back here and tell me you're satisfied with the datetime <haugh>It's doable it's just clunky. I think if I were so inclined I would write some SRFI-42 generators but I've already got a ton of stuff to do <haugh>Meanwhile I'm trying to convince my bf that macros are the greatest thing ever and he's just ripping on me because he can generate lists of date indexes with oneliners <RhodiumToad>ACTION tends to do date calculations in Postgres, which is pretty good at them <haugh>That's subjective. With SRFI-19 you need to convert dates to times, extract seconds from times, do math on seconds, and then convert back up to dates. <RhodiumToad>I just tried making a srfi-19 date with 6 months added to the month field, and normalize by converting to julian day and back, and it says that today + 6 months is the 30th of march :-( <RhodiumToad>a good date/time library is actually really hard to do right, and often can't be built on top of the OS standard functions <haugh>you started with `make-date'? I'm not sure but maybe you need to start with current-julian-day or current-modified-julian-day, that could explain the drift <RhodiumToad>so you end up reading the tzdata files directly, and that leads to proliferation of copies of the tzdb, which then all get out of sync <RhodiumToad>I did (current-date), extracted all the fields and passed them to make-date, with 6 added to the month <RhodiumToad>basically it looks like the srfi-19 code just isn't written to handle out-of-range values <haugh>normalizing with the rational date is a great idea that almost solves this problem, I just can't figure out why it's off a bit <haugh>oh no, it's not rolling the year over, nevermind <haugh>it's still "bring your own date math", just with vectors <haugh>SRFI-19 has some great stuff e.g. builtin leap second table, I just feel like a caveman pulling remainders out of additions <dsmith>This bit looked encouraging: "The values can be outside their usual ranges. For example tm:hour normally goes up to 23, but a value say 33 would mean 9 the following day." <sneek>I've been faithfully serving for 14 days <sneek>This system has been up 25 weeks, 5 days, 23 hours, 59 minutes <minima>there's this data (a simple list of strings) that i need to de/serialise to/from a file; a csv + readlines would do but then i started thinking of various concurrency issues and remote edge cases where the file gets corrupted <minima>so i came up with the idea of directly pretty-printing the s-expression to a file and then read it back in one go with `read' <minima>that should give some data-integrity protection, or at least some more than what provided by csv, isn't it <minima>conversely, i suppose i lose the possibility of processing the file one chunk at the time, as `read' will probably load the whole thing in memory, won't it? <minima>this is fine, as my file won't ever grow past a certain size <minima>is the above assessment well founded? <dsmith>Sure. Just keep in mind not all things have a read syntax. (hashes for example) <haugh>I hope goblins' serialization works out. That would be a massive payoff. <minima>yeah, it's a simple list of strings that i'm writing/reading <dsmith>(read) and (write) are designed to do that very thing <minima>haugh: that sounds interesting, i'll look it up <haugh>minima, probably way out of scope for what you're doing and at this point entirely theoretical <haugh>not that you shouldn't get into goblins just be warned thar be dragons <dthompson>haugh: we're working on serialization atm actually <RhodiumToad>haugh: builtin leapsecond table is a misfeature, not a feature