<dustyweb>needs better docs and a Real Release(TM) but I think the README explains the rationale well <cmaloney>though my mind kept saying "JUST USE JSON" <dustyweb>though I haven't demo'ed it yet in the docs <dustyweb>is you can describe how to transform something like a srfi-9 record or a goops class <dustyweb>when you set up a serializer here you're explicitly describing how it works <dustyweb>though there are some lazy procedures to make describing that in just a couple of lines very easy <cmaloney>iirc Python Pickling is essentialy a memory dump, no? <dustyweb>also not safe to send across the wire because of it <dustyweb>the pain of not knowing whether or not a field was a uri or a string in json-ld is partly what kept me thinking about canonical s-exps <dustyweb>you have to expand it out to its unambiguous form <dustyweb>and then you aren't really working on json anymore <cmaloney>The sad thing about XML is you can spec that nonsense. The sad thing about JSON is you can't. <dustyweb>json has a nice feature in that it provides a few core types and it's easy to parse for pretty much everywhere <dustyweb>json is a good lowest common denominator <dustyweb>but when you want more than that, it gets a bit irritating <cmaloney>Right, save for when you have to ensure type-safety <cmaloney>Funnily enough a friend was lamenting a situation where he was passing XML somewhere <cmaloney>They had to install some black-box tech that would say whether the XML was passing or non-passing <dustyweb>and you can't write an xml parser in 150 lines of code :) <cmaloney>God no. It's like parsing an email address using regex. ;) <dustyweb>I wrote the csexp reader/writer both in 150 SLOC <dustyweb>largely inspired by davexunit's json stuff :) <dustyweb>of course in csexp you need to make sure that both sides know how to interpret type stuff the same way <dustyweb>which is fine if you've just got pretty much the same two programs running, but if you want somthing more complicated... that's another layer to implement <dustyweb>but for what I wanted it for it's not a big deal <str1ngs>hello, I'm messing around with ffi. I'm trying to call the glob libc function. but I'm having trouble figure out how to get the char **gl_pathv field. I can get the int fields but not sure how to handle C string arrays ***Amynka is now known as Marvin
***Marvin is now known as Marviin
***Marviin is now known as Marwin
***Marwin is now known as Amynka
<stis_>hurray, I managed to compile python *arg *kwargs e.g. keyword arguments and optional arguments <stis_>It's lot of work just to reach somewhat accapteble default python environment. <hooverville>dustyweb: i struggled with finding a csv parser that fit my needs earlier in the year. Someone in this channel pointed/provided me with an older module neil van dyke wrote for racket, before it required other racket modules <ArneBab_>dustyweb: I’m currently using guive-csv, but not for anything performance critical <dustyweb>hooverville: ArneBab_: thanks for the feedback <ArneBab_>it works pretty well, gives me lists like (record-1 ((header1 value1) (header2 value2) ...) <amz3`>what do you use to hash password to store in database? <dustyweb>amz3`: I can point you what I do if you like <dustyweb>ACTION ought to make a proper release... <dustyweb>OrangeShark: well, the build script for guix is also pretty simple ;)