<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 <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 <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>I've settled on using vectors for JSON arrays because it was the simplest thing to implement. <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. <davexunit>yeah I'll do that. dealing with the tags on objects/arrays might be just as annoying as dealing with vectors. <mark_weaver>davexunit: do you think that 'match' would be good to use on the output of 'read-json' ? <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. <mark_weaver>that way, you could use alist operations directly without tagging/untagging, which would be nice. <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>the choices are: ! $ % & * + - . / : < = > ? @ ^ _ ~ <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>(match foo ((@ . list-of-stuff) (map bar list-of-stuff))) <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. <mark_weaver>it's too bad that the best name is now already taken by such a suboptimal API. <davexunit>I asked him about using alists quite some time ago <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. <davexunit>guix is the only real user of this library that I know of. <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>I would write the code in a bit of a different style, personally. <davexunit>but the parser has been solid for what I've used it for. <davexunit>I could call my fork guile-sjson or something silly like that <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>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. <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 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. ***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? <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 <zacts>(sorry, it's a great talk but informit sucks) <davexunit>zacts: I found a really cool infoq downloader on github <davexunit>it generates an html page that you can view locally that syncs with the slides, just like the regular site does <zacts>the link I pasted, is by sussman <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>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. : <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 <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 <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
<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. <jgrant>Sneek can't determine channels? THat's a bit annoying. <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 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/ ***h_ll_k_n is now known as hellekin
<Zerock>Is there a pi constant for Guile? <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>davexunit: I get a deprecation warning when using (format "~d\\n" 1) <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>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. <davexunit>Zerock: elisp and scheme are quite different in many ways. <Zerock>Written in Guile and extended with Guile. <Zerock>This is my first functional language. I know 5 imperative/OOP languages. <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. <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.