IRC channel logs
2017-10-09.log
back to list of logs
<laertus>wow... i finally managed to complete a "guix pull" <Apteryx>laertus: Congratulations for persevering! I hope you'll find like me that it pays off :) <laertus>i do love scheme and am quite intrigued by the whole guix concept and architecture (as far as i understand it) <laertus>so i really, really want it to work out <Apteryx>How do I substitute a single character from a string? <Apteryx>I don't get how string-replace is supposed to be used. <Apteryx>I guess I should use string-map instead. <Apteryx>but then I'm lost as to what the proc to pass to string-map should look like <Apteryx>That is tedious... Am I missing an srfi that would provide convenient substring substitution? <manumanumanu>Apteryx: (lambda (ch) (if (char=? ch #\\char_you_want_to_substitute) #\\char-you-want-to-substitute-to ch)) <manumanumanu>Apteryx: (lambda (ch) (if (char=? ch #\\a) #\\b ch)) replaces all occurances of #\\a with #\\b . abba => bbbb <amz3>so I've wondering whether to post a message on the mailling list about the small blog engine I made <amz3>there is various bugs, the quality is not there yet, but I don't think I will continue on this road because of the bugs are difficult to fix (if possible at all) <amz3>michaelis: the impossible bug, when you register a new account with login & password, the user is redirect to the login page, autocomplete does fill in the forms but the "frontend state" is not updated accordingly <amz3>so you think you can directly submit the form, because the inputs are filled, but in fact you get an error saying the input is not ok <amz3>but that is very linked to my frontend framework, it's not related to guile <michaelis>amz3: That's what I was wondering, if it had anything to do with guile. Never mind then. <ArneBab>amz3: maybe you could write a "lessons learned" message <ArneBab>amz3: what you did, what worked well, what you would now do differently. <ArneBab>amz3: I’m looking forward to reading it! <Apteryx>Can I catch an exit exception to prevent termination of the program? <Apteryx>Geiser lately fails to find any documentation when using C-d C-d... Any advice? I can find everything going in the Guile Reference info manual and using i (search index). <ArneBab>Apteryx: try catch could work, but I didn’t try that yet. <Toga_Virilis>How exactly is (case ... ) implemented in guile? Does it linearly compare all options or does it compile it to some kind of hashing mechanism to do in constant time? <janneke>Toga_Virilis: you can try something like: ,expand (case 0 ((0) 0) ((1) 1) ((2) 1) (else #f)) <janneke>yeah, not really answering your question, but i figured it must be a macro <Toga_Virilis>Maybe it has some heuristics though and compiles to some hash mechanism if it's larger than a certain number of rows or whatever. <Toga_Virilis>But it seems to just go towards (cond [(memv test '(...)) ...] ...) esentially <Apteryx>my handler looks like: (lambda (arg . rest) (format #t "Caught exception: ~a~%" (cons arg rest))) and it prints: "Caught exception: (quit 1)" <Apteryx>It seems I don't have stderr printed though :/ <amz3`>I posted a challenge on the mailing list <Apteryx>If I run: (format (current-error-port) "error!") in my Geiser's REPL, I don't see any output. Why? <Apteryx>same thing in vanilla guile interpreter prints "error!" as expected. <ArneBab>Apteryx: I’m not sure — it’s likely a Geiser function. Maybe checking its documentation for error-port can help. <ArneBab>Apteryx: you might want to check C-h i m Geiser <Apteryx>I'm trying to find something about error port in Geiser docs or on the web, but so far have failed. <ArneBab>Apteryx: you might want to ask in #geiser <Apteryx>Basically the output ports are bound to different values in the REPL vs the Scheme buffer, so when running some function eval'd from another place in the REPL it can output to an invisible place; or so I understand so far. <civodul>Apteryx: you can do (current-build-output-port (current-error-port)) in the REPL, though <sneek>civodul, you have 1 message. <sneek>civodul, roelj says: Bug #22138 does not solve my problem. I notice that when I change the value of 'files to "lib", then it works. Does it do file checking somehow? If so, where does it do that? <Apteryx>civodul: There seems to be different opinions about if it's proper to bind current-build-output-port at the top level vs lazy-evaluating it when it's required. Couldn't we use some guile feature here? I'm no expert but maybe wrap the value of current-build-output-port into a (promise ...)? Would that help? (I'm not totally sure what promises do, but I'm under the impression that they enable delaying <civodul>Apteryx: SRFI-39 parameters need an initial value anyway <civodul>just like current-error-port has an initial value, so does current-build-output-port <Apteryx>can't that initial value be wrapped to be deferred as well? <Apteryx>ACTION is reading about parameters/srfi-39 <bavier>how does dynamic-link search for the named library? <bavier>does it try different extensions? <bavier>I have an issue where '(dynamic-link "/lib64/libz") fails because there is no "/lib64/libz.so", but there is an "/lib64/libz.so.1" <civodul>this is an annoyance on distros that ship ".so" as part of the -devel package <bavier>civodul: hm, my distro doesn't install the .so <bavier>civodul: this is related to a guix configure.ac check to define %libz, btw <bavier>which can be worked around by calling configure with 'guix_cv_libz_libdir=""', so not terrible <civodul>bavier: isn't libz.so in "zlib-devel" or something like that? <Apteryx>apparently we can customize the setter of a parameter using CONVERTER argument but not the accessor, so using deferred evaluation of the value wouldn't be transparent... bummer. <Apteryx>civodul: I guess I'll reopen that Geiser bug after I've verified that I can reproduce it with clear steps. <Apteryx>Isn't current-error-port different than current-build-output-port in the sense that the former is a procedure whilst the later is a variable? If we could agree to make current-build-output-port a procedure as well (by setting the parameter value to one), it would be a definitive workaround... <Apteryx>I'm wrong. Current-error-port *is* a parameter (thanks for pointing this, civodul), not a procedure. If we were to assign a procedure as a value to it, we'd have to use it as ((current-error-port)), which is ugly ;) <ArneBab>amz3: it is so awesome that you can just use the exact path as procedure name <Apteryx>Could anyone advise as to how I could capture error output to a string? The closes I've found is 'with-error-to-file', but this prints to a file. <Apteryx>If nothing better exist I'll output to a tmpnam (temporary file) and read the content back as a string.