<rekado>sneek later tell nij There’s a CSV (and more) parser: guix install guile-dsv <rekado>Is it expected that a “compound condition” (SRFI 35) does not satisfy the condition-type? predicate? <rekado>say I (raise (condition (&my-error) (&message (message "Oh no")))), shouldn’t this satisfy all of “my-error?” “message-condition?” and “condition-type?”? <rekado>another thing worth noting: at the location where I construct the compound condition I get a warning “possibly unbound variable `make-compound-condition'” <rlb>wingo: not sure it's relevant, but in case it is, civodul and I recently discussed the possibility of adding a GUILE_EXTENSIONS_PATH and corresponding %extensions-path so that things building on guile could use them instead of LTDL_LIBRARY_PATH. I forget the exact details (can go figure that out if it seems interesting), but it's something I hit while working on lokke, which has it's own shared libs. <wingo>rlb: hey would you mind if we changed "mkdtemp!" to be "mkdtemp" and instead return the path as the result? <wingo>re: GUILE_EXTENSIONS_PATH, sgtm <wingo>rlb: fyi i would like to make a quick 3.0.6 to get the new gnulib out, but there is room for other fixes <wingo>has been 3 or 4 years since we updated gnulib <RhodiumToad>did that thing with the interrupts get tracked down? <wingo>RhodiumToad: nope, not to my knowledge <spk121>wingo: FWIW, I also think returning the path for mkdtemp instead of mutating the string is more scheme-y. But rlb liked it the current way because that's how C's mkdtemp and Guile's mkstemp work <spk121>we went back and forth a bit on it. <leoprikler>Well, mkstemp! and mkdtemp! are not without side-effects in multiple ways, so... ***spk121_ is now known as spk121
<spk121>Maybe we rename mkdtemp! to something like make-directory-from-template so no one expects it to act like C's mkdtemp <civodul>spk121: i agree that mutating the string is not pretty, but in this case i'd value consistency with mkstemp! <civodul>all the POSIX bindings in libguile are very close to their C counterpart <civodul>one can always build higher-level modules on top of that <spk121>civodul: fair. Well, if someone wants me to rework the patch, just let me know. Of if you just want to revert it to get 3.0.6 out, and then revisit the question, that's fine too ***str1ngs_ is now known as str1ngs
<wingo>civodul: honestly i would rather change to deprecate mkstemp! in that case <wingo>mutating string arguments is terrible, it will always cause problems for new users that expect string literals to be mutable, etc <wingo>like deprecate in favor of "mkstemp" which returns two values or something <wingo>(all this said, progress > perfection, so if there is no agreement i am happy to continue with what we have) <rlb>wingo: I'd just favored consistency for now, with the option of having immutable wrappers on top. Could then either publicize the friendly versions more and leave the ! versions as lower-level, or eventually get rid of them. Don't feel strongly about it though -- mostly just thought we'd want the two to match, whichever we pick. <rlb>And of course in this case, the underlying operations are heavy-weight enough that there might not be much justification for the ! versions, so no substantial argument in *favor* of keeping the ! versions in the long run. <wingo>well let's put it this way -- mkstemp! is a terrible interface and we'll avoid problems in the future if we migrate to something that returns results as return values. if that's the case then we should add mkdtemp instead of mkdtemp! <wingo>but -- i can handle that migration e.g. to mkstemp, if we agree about it <joshuaBPMan>so I think the guile manual for set-field in records doesn't work when you try to run the code. <civodul>wingo: ah yes; actually i guess my argument was more about the obscure name than about mutation <civodul>so yes, we could have non-mutating mkstemp/mkdtemp (no bang) ***rekado_ is now known as rekado
<rekado>joshuaBPMan: can you give us a reference to the manual section in question? <joshuaBPMan>Down toward the bottom of that page is a reference toward "set-field". <joshuaBPMan>I get an error that says wrong number of arguments in form (lunch-food). <joshuaBPMan>RhodiumToad: unknown file:206:7: address: Wrong number of arguments in form (address person-address set-person-address) <joshuaBPMan>RhodiumToad: ;;; <stdin>:224:0: warning: possibly unbound variable `set-field' <leoprikler>joshuaBPMan: normally you'd write that as (food lunch-food set-lunch-food!) would you not? <joshuaBPMan>leoprikler: I have no idea what I'm doing bro. :) I just learned about set-field this morning :) <joshuaBPMan>Do you need to specify set-lunch-food! ? According to the guile manual, "In addition, the generic set-field and set-fields macros may be applied to any SRFI-9 record." <leoprikler>tbf I'm not doing too much with SRFI-9 records either <RhodiumToad>also I think you meant (define (dine-out-2) (set-field ...)) <joshuaBPMan>RhodiumToad: Your latest attempt (set-field dine-out (lunch-food) "sandwich") results in this error: <joshuaBPMan>unknown file:225:21: lunch-food: Wrong number of arguments in form (lunch-food) <joshuaBPMan>RhodiumToad: (define (something) ...) defines something as a procedure that accepts no arguments. <joshuaBPMan>that'll make my cookbook image api patch a little coolier. ***metro is now known as metreo
<rlb>wingo: yeah, to be clear, I think it's just fine (and likely preferable, since perf isn't a question) to have mkstemp and mkdtemp as opposed to mkstemp! and mkdetemp! -- was really just leaning against a mismatched mkstemp! and mkdtemp. ***X-Scale` is now known as X-Scale
***metro is now known as metreo
***X-Scale` is now known as X-Scale
***leoprikler_ is now known as leoprikler
<civodul>cbaines: did you find more clues regarding the exception handling issue we discussed yesterday? <cbaines>I tried using with-throw-handler rather than with-exception-handler (with #:unwind? #f), and that seemed to not break things <cbaines>I think you correctly diagnosed the problem that somehow with-exception-handler breaks false-with-exception <civodul>did you manage to boil it down to a simple example? *civodul can never remember which one of with-exception-handler and with-throw-handler is the new one <cbaines>civodul, the example I had was quite simple <cbaines>I don't know why it didn't work for you though <civodul>cbaines: oh actually i did manage to reproduce it <civodul>i've been debugging a weird exception-related issue with inferiors today <rekado>I’m guessing “with-exception-handler” :) <rekado>just because the manual says that “throw” is old but here to stay <civodul>yeah with-exception-handler (the core one, not the R6 one :-)) is the new one