IRC channel logs

2015-01-25.log

back to list of logs

<vimmonkey>uh..that was weird...
<vimmonkey>was getting a error about deps/dispnew.d didn't exist..had to do a mkdir src/deps heh...
<davexunit>so, json objects are an unsorted key/value structure, which makes sense because they are almost represented as hash tables.
<davexunit>however, if I'm using alists, I would need to preserve the order of the pairs in order for (write-json (read-json some-json)) to equal 'some-json'
<davexunit>does anyone feel lame when they have to use 'reverse'?
<davexunit>hmm I dunno, maybe it's not that big of a deal.
<davexunit>extra whitepace in 'some-json' would be enough to make the above test fail.
*mark_weaver thinks using reverse is okay
<mark_weaver>sometimes it can be hidden by writing code in terms of higher-level procedures
<vimmonkey>just as a heads up, relying on key orders shouldn't be done afaik
<davexunit>vimmonkey: I'm not relying on key orders.
<vimmonkey>davexunit: mist understood the question, sorry. but the ordering of pairs isn't promised anywhere afaik
<davexunit>it's okay, I was going after something that was silly.
<davexunit>since a good number of things can mess with the result, such that equal? returns #f for things a human might consider equivalent
<vimmonkey>ah
<davexunit>like '((foo . 1) (bar . 2)) is not equal to '((bar . 2) (foo . 1))
<mark_weaver>vimmonkey: I think davexunit would like to avoid reversing the orders of all the maps if you 'read-json' and then 'write-json'. technically it shouldn't matter, but I can sympathize with him.
<davexunit>yeah, that's it, but the more I think about it, the more it seems a foolish thing to do because it doesn't actually solve any problem.
<mark_weaver>davexunit: presumably guile-json doesn't preserve the order now, because the hash tables will psuedo-randomize the order.
<davexunit>yeah
<davexunit>I was just overthinking this. :)
<davexunit>I've settled on using vectors for JSON arrays because it was the simplest thing to implement.
<mark_weaver>okay
<mark_weaver>davexunit: one suggestion: instead of choosing based on what makes the guile-json code simpler, choose based on what makes the code on top simpler.
<davexunit>mark_weaver: yes, I've been thinking about that as well.
<mark_weaver>so I would try adapting your guile-json-using code to guile-json based on untagged vectors/alists. then try adapting it to guile-json based on tagged alists/lists. and the compare the results.
<mark_weaver>*and then
<davexunit>yeah I'll do that. dealing with the tags on objects/arrays might be just as annoying as dealing with vectors.
<davexunit>we'll see..
<mark_weaver>davexunit: do you think that 'match' would be good to use on the output of 'read-json' ?
<mark_weaver>well, dunno.
<davexunit>yeah.
<davexunit>that's part of the reason for getting rid of hash tables.
<davexunit>though the uses of match with alists are a bit limited
<mark_weaver>maybe the arrays should be tagged, but not the alists.
<davexunit>heh, that's exactly what I was trying!
<mark_weaver>that way, you could use alist operations directly without tagging/untagging, which would be nice.
<davexunit>yes, that's a big win.
<mark_weaver>here's a bikeshed question: what tag to use? :)
<davexunit>I was thinking just 'array'
<mark_weaver>well, best not to think about that until we figure out where to use tags (if at all)
<mark_weaver>I was thinking that some single-character non-alphanumeric symbol would be good for this.
<mark_weaver>like the use of @ in sxml
<davexunit>hmm, good idea.
<mark_weaver>the choices are: ! $ % & * + - . / : < = > ? @ ^ _ ~
<davexunit>^_~
<mark_weaver>well, a question for another time. first, see if this representation is easy to work with in code that uses 'read-json'
<davexunit>seems easy enough
<davexunit>(match foo ((@ . list-of-stuff) (map bar list-of-stuff)))
<mark_weaver>I think you have to write '@ there
<davexunit>oh yes, that's a typo
<mark_weaver>but yeah, it seems nice enough
<davexunit>this is sort of unrelated, but would you find it useful to include a procedure in guile for fetching values within nested alists? something like (assoc-ref* '((foo . ((bar . 2)))) 'foo 'bar) => 2
<davexunit>it comes in handy, but it is in the "trivial to write on your own" category.
<mark_weaver>dunno, to me it doesn't seem worthy of inclusion in core guile, but maybe it's just that I've so rarely needed such a thing.
<davexunit>okay, that's about what I expected. just curious. :)
<mark_weaver>davexunit: btw, although I'd _much_ rather use a json library with the API you're aiming at, I'm not sure it would be a good idea to change guile-json itself to use this API.
<mark_weaver>well, I guess what I'm saying is that this modified guile-json should be given a different name, since any code written for the existing guile-json won't work with the new one.
<davexunit>hmm.
<mark_weaver>it's too bad that the best name is now already taken by such a suboptimal API.
<mark_weaver>I wish he had asked us for feedback on the API
<davexunit>I asked him about using alists quite some time ago
<davexunit>and wasn't able to convince him then
<davexunit>but now that I have patches, maybe I could, and they could be used in a backwards-incompatible major release bump.
<davexunit>but you make good points, perhaps it should just be a fork.
<mark_weaver>I would totally support this fork, btw.
<davexunit>guix is the only real user of this library that I know of.
<mark_weaver>it's really a completely different API.
<mark_weaver>it goes way beyond the kinds of changes that typically happen in major release bumps.
<mark_weaver>in fact, I wonder if it's any easier to patch it than to rewrite it from scratch.
<davexunit>it was pretty easy to just patch it.
<mark_weaver>well, I guess there's the parser.
<davexunit>I would write the code in a bit of a different style, personally.
<mark_weaver>I wrote a simple json parser a few years ago.
<mark_weaver>used it to scrape some web pages
<davexunit>but the parser has been solid for what I've used it for.
<mark_weaver>okay
<davexunit>I could call my fork guile-sjson or something silly like that
<mark_weaver>the module name(s) should probably be changed also
<davexunit>yup.
<mark_weaver>so that in theory, both variants of the library could be loaded into a single guile session
<davexunit>I didn't intend to fork this thing when I started...
<vimmonkey>lol
<vimmonkey>man..this is wierd, have to ctrl-c and restart make multiple times..it hangs for some reason ..getting further though <_<
***unCork is now known as Cork
***michaniskin__ is now known as michaniskin_
***18VAB17AF is now known as petercommand
<please_help>how do I deal with cstructs that contain cstructs as elements using the FFI?
<vimmonkey>hm, guile-emacs ends up freezing during make, it's trying to make some grammar file with bovine or something
<vimmonkey>huh, a couple of emacs instances are running, if i kill the ones with lower memory usage (under a few mags), it continue
***sethalve_ is now known as sethalves
***__zxq9__ is now known as _zxq9_
<mark_weaver>please_help: use nested lists. i'm afraid it's not documented in the manual (sorry about that), but anywhere that a foreign type is expected, you can pass a list that contains the types of the struct elements. these can be nested.
<mark_weaver>See https://lists.gnu.org/archive/html/guile-user/2012-05/msg00037.html
<jgrant>I'm not sure if it's an issue on my end, but I can't build Guile-Reader on Fedora 21 (Guile 2.0.11).
<jgrant>I'm going to take a shower, see if anyone responds -- if not, I'll ask again later (haven't slept yet.... :^) ).
<jgrant>Brbish.
<jgrant>Actually, if someone is lurking and is curious -- here's the paste. http://paste.lisp.org/display/145367
<jgrant>Okay, really going to shower.
*jgrant might just cheat and install it via Emacs.
<jgrant>Eh, I want it on my actual hostmachine. I figure it out later today or tomorrow.
<jgrant>Peace for now. o/
*jgrant is afk.
***jackhill_ is now known as jackhill
<please_help>I have typedef struct { int a; } A; typedef struct { A a; } B; | do I need special care to access B.a?
<ArneBab>jgrant: it sounds like the texinfo generation failed but everything else worked. Can you try to configure without doc support?
<ArneBab>(or rather without documentation)
<taylanub>please_help: you can access the int field like myB.a.a
<taylanub>please_help: not sure if I got your question right though, or how this is Guile related
<please_help>because it's through the FFI
<please_help>not in C, obviously
<please_help>otherwise the question would be retarded
<please_help>now the question is only a bit retarded
<zacts>davexunit: mark_weaver: http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute <- although you may need to use something like youtube-dl to watch it
<zacts>(sorry, it's a great talk but informit sucks)
<davexunit>zacts: I found a really cool infoq downloader on github
<zacts>oh neat, please share
<davexunit>it generates an html page that you can view locally that syncs with the slides, just like the regular site does
<davexunit>let me find.
<davexunit>zacts: https://github.com/mtayseer/infoq-downloader
<zacts>oh neato, thanks
<zacts>the link I pasted, is by sussman
<zacts>the co-author of SICP
<davexunit>zacts: yes, I've actually watched that once before. I should watch again because I don't remember much of it.
<zacts>ah ok, yeah. I still need to finish it, I just started it, but I think it's great
<zacts>so far
<zacts>he also has a few other new talks on the interwebs too, that are nice
<davexunit>I'm hoping to get sussman to sign my copy of SICP sometime. :
<davexunit>:)
<zacts>ah, I should do that too
<zacts>I own a physical copy also
<zacts>I should get a new copy though, this one is getting worn out
<zacts>The binding is starting to wear, it was a used copy
<zacts>I really hope to in the near future attend a lambdajam conference / libreplanet conference / BSDCON / and a Perl conference
<davexunit>where's lamdajam?
<davexunit>lambda*
<zacts>hm.. I think it's at different locations each year, and there are more than one of them per year internationally
<zacts>but there's always at least one in the US, afaik
<zacts>the last one was in chicago
<zacts> http://lambdajam.yowconference.com.au/
<zacts>lol I just found this http://page.mi.fu-berlin.de/cbenzmueller/papers/C40.pdf
<davexunit>I wish there were an active boston lisp meetup.
<zacts>I have one here in New Mexico
<zacts>they do both lisp and scheme, I should attend, I've just been so busy
<zacts>it's listed on schemers.org actually
<zacts>davexunit: you could start one, I'm sure people would show up
<davexunit>zacts: I haven't the time to start one, but maybe someday.
<zacts>I wish goops was more well documented
<zacts>I wouldn't mind improving it
***cluck` is now known as cluck
***mario-go` is now known as mario-goulart
<jgrant>civodul: o/
<civodul>hey!
<sneek>Welcome back civodul, you have 3 messages.
<sneek>civodul, jgrant says: Hey, just saw the commit updating the location of the new image of the distribution "guix-usb-install". Shouldn't it be "GSD-usb-install", so it doesn't confuse people? GSD explicitly says it's a system distribution and is more/or less the decided on or "good enough" name. :^P
<sneek>civodul, rekado says: I see that the discussion on gnu-system-discuss lives on. Maybe it would be a good idea for you to state there that the naming decision has been made and the discussion no longer needs to continue.
<sneek>civodul, mark_weaver says: I think we should consider changing GSD's grub.cfg to contain entries that look like http://paste.debian.net/142098 (thanks to alezost for that)
<jgrant>Sneek can't determine channels? THat's a bit annoying.
<wingo>evening
<civodul>rekado: i did state it
<civodul>oh, ECHAN
<civodul>hey, wingo
*jgrant is having issues similar to http://lists.nongnu.org/archive/html/skribilo-users/2014-06/msg00002.html -- installing guile-reader.
<jgrant>On Fedora 21, with Guile 2.0.11.
<jgrant>I guess the way I'm using now is fine, via Guix, it's just odd that there seems to be some issue with texi. :^P
<charetjc>guile still supports memoization, yes? the docs don't mention it, but google found a loose page at http://www.gnu.org/software/guile/manual/html_node/Decoding-Memoized-Source-Expressions.html, and I found libguile/memoize.[hc] in the sources.
***charetjc is now known as boxofrox
<wingo>boxofrox: memoization is a general technique; memoized source expressions is a specific implementation technique
<wingo>due to some strangeness with our web hosting it's possible to upload new pages and not delete the old
<wingo>so you might see a page that will be garbage collected in the future :)
<wingo>only it seems that google has made a link to it
<wingo>anyway, as far as implementation goes, it is getting faster steadily though the techniques evolve.
<wingo>s/it is getting faster/guile is getting faster/
<boxofrox>thanks, wingo
***h_ll_k_n is now known as hellekin
<Zerock>Is there a pi constant for Guile?
<davexunit>Zerock: nope.
<davexunit>I defined my own as a floating point number
<davexunit>(define pi 3.141592654)
<Zerock>Fair enough.
<Zerock>(display "%d" 0) is throwing a type error for the second argument. Why? Isn't that a decimal?
<davexunit>Zerock: display doesn't do formatting. the second argument should be a port.
<Zerock>Doesn't %s work though?
<davexunit>you should use 'format' instead.
<Zerock>davexunit: I get a deprecation warning when using (format "~d\\n" 1)
<davexunit>(use-modules (ice-9 format))
<Zerock>Did that.
<davexunit>also, the first argument to format should be a port, or #t, or #f
<davexunit>#t writes to the current output port, #f returns a string
<Zerock>Thank you very much.
<davexunit>yw!
<Zerock>I'm picking up Scheme for use with GNU mcron. Trying to retain as much, and deviation from what I'm used to throws me off sometimes. I guess I assumed formatting to be a thing since Emacs Lisp has formatting in its (message) function.
<Zerock>as much as possible*
<davexunit>Zerock: elisp and scheme are quite different in many ways.
<Zerock>Yep.
<davexunit>whoa, didn't realize mcron is pure guile.
<davexunit>that's great1
<davexunit>great!*
<Zerock>Written in Guile and extended with Guile.
<davexunit>that's the way to do it. :)
<Zerock>This is my first functional language. I know 5 imperative/OOP languages.
<Zerock>I am enjoying it so far.
<davexunit>happy hacking :)
<Zerock>Is there a way to make the interpreter shut up about compilation? I want it to compile, but I don't want it to tell me all about it every time I make a change.
<davexunit>I don't know how, but maybe there is.
<Zerock>Meh. Not a big deal. I'm just not used to it.
<Zerock>First time dealing with an interpreter that compiles and tells you about it.
<davexunit>Zerock: you can pass --no-auto-compile to guile
<davexunit>to (I think) use the interpreter instead of the compiler
<Zerock>I do like the compilation for other programs like mcron, though.
<Zerock>Like I said, no big deal.