<davexunit>basically my plan is to start enough useful projects and hope that other people do the rest :P <paroneayea>davexunit: that might require clear paths to contributions and etc :) <davexunit>thanks. Sly needs it, but it should be useful for other projects, too. <nilg>any idea of a function like display, but that returns a string instead of printing the object? <artyom-poptsov>nilg: Hi. I think you should try this: (object->string 'test display) <artyom-poptsov>(format #f "~a" 'test) should work equally well. But probably using 'format' in this case is a bit overkill. <nilg>artyom-poptsov: format would be useful in my case, thanks! however typing format under the guile shell gives me "#<procedure .... | (deprecated-format-string-only)" <nilg>This is seems to say there is a newer way for formatting strings <nilg>I tried (help format) but it says there is no documentation... Still looking... <ArneBab>adhoc: imo Python set a new standard for readability of code for not-yet-programmers. <ArneBab>nilg: there’s an advanced format in ice-9 <nilg>How to convert a list into function all arguments? Well basically I'm trying to write a helper function for format, like: <nilg>(define (my-format-logger msg . args) (my-logger (format #f msg . args))) <nilg>but guile doesn't seem to accept that, I'm getting the error: <nilg>... failed to match any pattern in form (format #f msg .args) <nilg>I mean "(format #f msg . args)" <nilg>I found the solution with apply! :-) <taylanub>amz3: I author the bytestructures library. and yes, SRFI-60 is probably a good way to work with numbers as bits. <amz3>in the end i use sfri-60, integer->list and the reverse function to pack/unpack integers using z order curve numbers <amz3>btw the code i paster before is not correct, I forgot to zip and convert the bit list to a 64 bits list <taylanub>amz3: yeah, bytestructures is primarily for working with whole bytes. struct bit-field support a la C is just for completeness' sake <taylanub>so it sounds like SRFI-60 is the right choice for your use-case <amz3>z order numbers is packing techniques used in games to build indices and compute intersection <amz3>it convert a vector of number into a single number, collocated vectors end up in near each other in the projection <amz3>so you can store the vector in an order hashmap and do range queries, using some technic I don't know yet <amz3>one intersting property is that given znumber(A) and znumber(B), if C is between A and B then C share the biggest common prefix between znumber(A) and znumber(B) <amz3>s/C share/znumber(C) share ***lloda` is now known as lloda
<paroneayea>not sure why that's perceived better than a general function <davexunit>and while I'm at it, I'd like a replacement for 'format' that uses s-expressions instead of a format string!! <amz3>(print "Héllo World, " ~s (list "amz3")) <amz3>the last argument must always be a list or it doesn't work <amz3>I'm trying something for my last project, I try to build components that are easy to test but otherwise I just write the code without testing the code <amz3>this is because I always come back to rewrite the thing so I end up always writing more tests <amz3>also, I don't have the big picture in mind <amz3>at least I have a few tests <amz3>yes, I just did this for the fun <davexunit>looks like we've gotta get that code ported to guile. <ArneBab>paroneayea: essentially that’s just a short form for "The answer is {answer}".format(**locals()) <ArneBab>but without making clear that it uses locals() <ArneBab>I just wrote a very crude (but working) implementation of SRFI-97: (define-syntax-rule (srfi n e ...) (primitive-eval `(use-modules (srfi ,(string->symbol (string-append "srfi-" (substring (symbol->string 'n) 1))))))) <ArneBab>(especially without primitive-eval…) <ArneBab>It allows doing (srfi :42 lazy) (list-ec (: x 5) x) <davexunit>(srfi :42 lazy) could expand to (use-modules (srfi srfi-42)) <ArneBab>I did not get lucky with syntax-case yet… <davexunit>syntax-case will let you use something akin to quasiquote but for syntactic expressions <ArneBab>I think I should give it another try <ArneBab>the example is simple enough that it should be doable <davexunit>and the guile manual has good info about syntax-case <roelj>Can guile be run on MS Windows? <roelj>And has anyone tried? I see it's in the repository of MSYS2, but mine crashes instantly (even when trying guile --version). <ArneBab>davexunit: somehow I don’t really grok syntax-case yet…_ <ArneBab>(or rather: how do I avoid “reference to pattern variable outside syntax form in form id”) <ArneBab>I want to call a function on the variable name and use the new name <davexunit>I can't remember the details, but what I think you want to do is convert the syntax to a datum, use symbol-append to make the identifier you really want, and then convert that back to syntax. <ArneBab>Now I can do (srfi :42 lazy) (list-ec (: x 5) x) <ArneBab>what’s the procedure for getting this into Guile as srfi-97? <davexunit>ArneBab: roughly: add the relevant module to the source tree, tell Makefile.am to build it, add unit tests, add documentation, send patch to guile-devel. <ArneBab>Or rather: how could this best be supported (so srfi's which use it work in guile automatically)? <ArneBab>unit-tests will take a bit of reading up to do… <davexunit>that I don't know. I'm not sure what extra stuff like 'lazy' actually means to SRFI-97 <ArneBab>as far as I understand it has no real meaning <ArneBab>maybe it should be tested against the names defined in srfi-97 <davexunit>ArneBab: and FYI, you could use symbol-append instead of converting symbols to strings and back again <ArneBab>I need to strip the first character, can I do that in a symbol? <ArneBab>I could however keep the string-conversion to a minimum <ArneBab>(symbol-append 'srfi- (string->symbol (substring (symbol->string id) 1)))) <davexunit>ah yeah you'll have to do some string manipulation because of that leading : <davexunit>ArneBab: that location doesn't make sense. the correct module is (srfi srfi-97) <ArneBab>can a SRFI be used to provide a SRFI compatibility layer? <ArneBab>I guess on the practical level you’re right