<chrislck>it looks like (case str (("a" "b" "c") "str is 'a' 'b' or 'c'")) should work but doesn't. is it intentional? <Guest93493>chrislck: case do not worj with strings, you'd nee to use string->symbol ***Guest93493 is now known as daviid
<daviid>chrislck: I thnk it is described in the manual? <chrislck>but agree string->symbol sounds like the way to proceed <RhodiumToad>case compares with eqv? and that's not what you want for strings <RhodiumToad>that it compares with eqv? is documented, the consequences mostly aren't <lispmacs>is there some built-in or SRFI shortcut procedure for the common (set! lst (cons value lst)) operation? <lispmacs>seems like something that somebody would have thought of already <chrislck>because the powers that be want you to try avoid this construct ;) ***daviid is now known as Guest78798
***Guest78798 is now known as daviid
<lloda>When I learned about match I stopped using case, even for symbols. <lloda>Error on no match is almost always what I want, so it also saves me from having to write an else <zig>I read racket in its new language will make "error on no match" default in 'cond' and 'case' <zig>on the subject of record, using guile-next 2.9.5. I have two things to report: <zig>a) the manual, says the follow: Scheme Procedure: record-accessor rtd k <zig> Returns the record field accessor procedure for the kth field of the record-type descriptor rtd. <zig>but when I use a number of argument K, it fails: <zig>the print error is: ice-9/boot-9.scm:1650:16: In procedure raise-exception: <zig>Error while printing exception. <lloda>yeah that's when the exception printer throws. I'm not sure why it doesn't at least print the k & the args to the handler. I have that patched in my boot-9.scm. <lloda>that could be a bug in the exception printer, but regardless <lloda>also now every error backtrace starts there, and it's the only line that gets printed until you ,bt which isn't very informative ***ng0_ is now known as ng0
<zig>I added a 'record store' to babelia, that allows to defined a subspace for whatever record type you defined with the following code: (define rstore (make-rstore engine '(rstore) <document>)) <zig>where <document> is the record type identifier. <zig>Then you can do one of the following: <zig>- (rstore-insert transaction rstore instance) <zig>the above procedure will return an unique identifier as bytevector. <zig>- (rstore-update transaction rstore uid instance) will return no value <zig>- (rstore-delete transaction rstore uid) will delete the record with unique identifier UID <zig>it rely on r6rs record reflection (which works with srfi-9 record, they also work with r7rs records) <zig>now I can stop procrastinating a do the actual web ui stuff. <zig>or leave that to downstream :) <zig>btw compilation times are good with guile 2.9.5 <zig>I think, ui is difficult mainly because there is lot of input, hence lot of validation, and so far I am not good at validation. <bandali>i'd like to know how i could have a custom name for the front page of my site/blog <bandali>i found `page-file-name', but am not sure how to use it in a layout <bandali>okay i think librelounge.org does something like that; i'll check their sources <rekado_>bandali: what do you mean by “custom name”? <bandali>rekado_, sorry, i meant a different <title> <bandali>i prefer a simple <title>xyz</title> for my front page, rather than <title>recent posts - xyz</title> <bandali>rekado_, great, will check it out, thanks a bunch <manumanumanu>jcowan: Thanks, John. I have always wondered why parameters or fluids aren't more often used, at least inside the parts of a program not exposed to the outer world. Then I saw that srfi-166 mentions specifically _not_ using parameters in favour of the environment monad, and jumped to conclusions. <jcowan>Fluids are really problematic in the presence of threads because they are normally implemented with shallow binding. <jcowan>IMO we don't really understand the full power of parameters yet <manumanumanu>jcowan: I have always found (parameterize ...) to be a very nice way to let programs change internal behaviour of otherwise opaque code. Keyword arguments are nice as well, but there are times when parameters are nices to use.