<davexunit>dustyweb: soooo remember that I time I wrote a json module but it never got merged so everyone just uses some hacked version of it or guile-json? I have some thoughts... <davexunit>1) we should probably just do what racket does and use vectors to represent json arrays and alists for objects <davexunit>2) we should do what sxml does and use symbols for object keys <davexunit>3) I can't remember what you chose, but I think the symbol 'null' is as good a value for the json null value as anything else <dustyweb>davexunit: I don't think racket does that <dustyweb>davexunit: not from where I've been using it <dustyweb>davexunit: racket uses immutable hasheq tables for the dictionaries <dustyweb>davexunit: because racket has builtin reader/writer support for immutable hashtables... a good idea! we should follow their lead :) <dustyweb>get real immutable hashmaps that we're reasonably happy with <MaliRemorker>a much bigger program used for generating Fortran programs that specialise in solving certain kinds of partial differential equations in two dimensions has still some way to go <MaliRemorker>i'm trying to generate documentation from the code itself - i've used documentation strings inside define regions -- and i've seen that guild supports something like that via doc-snarf <MaliRemorker>but it doesn't capture the doc string, unless comments like `;;' are also included with the definition <MaliRemorker>So, short of writing doc-snarf myself, is there any way around this? <MaliRemorker>By the way, is there a place where can register new-born baby Guile projects? ***MaliRemo` is now known as MaliRemorker
***drmeister_ is now known as drmeister
<ecraven>why does (exit 0) not actually exit guile? <ecraven>hm.. strange, on the repl it works, just not in my program <davexunit>dustyweb: O(n) access is faster in nearly all cases <davexunit>but last I checked the Racket docs they used vectors for arrays, that's what I was talking about for copying Racket. <davexunit>but since everyone has their own preference for how json should be represented I think I'm just going to keep stashing my own preferred implementation in my projects for now <Apteryx>Has anyone tried comparing compilation times between Guile & G++? Given that C++ is statically typed, it can probably be faster, but I'm curious. It could be our ideal benchmark (be as fast as G++) ;) <OrangeShark>davexunit: what about allowing users to pass their preference? <MaliRemorker>i'd rather like more optimised (byte)code versus quicker compile times <Apteryx>yes, something like that. 10000 lines of a "similarly" complex program or something. <Apteryx>or 1000 lines, it doesn't really matter <MaliRemorker>okay, i come here once, or twice per year so maybe i shouldn't return the greetings <Apteryx>MaliRemorker: Guile faster compilation speeds (as well as lower memory footprint) would benefit Guix enormously! It's using more than 1GB and needs like 30 minutes on my i3 class hardware. Guile 2.0 used to take maybe 250 MB ram and was maybe twice as fast to compile. <Apteryx>So, if we had some benchmark to see how we compare with other serious and complex compilers such as g++, I think it'd be interesting! It'd gives us an (vague) idea of how much faster we could be. <davexunit>OrangeShark: I don't really like that idea. nothing else really does this. <davexunit>IMO parsing JSON to primitive guile types (cons, numbers, vectors, strings, symbols) is the best move <MaliRemorker>Apteryx but g++ complies to machine code from a more primitive language; rather some other bytecode compiler ... javac+clojure? <davexunit>Apteryx: turning off compiler optimizations will help reduce that time <davexunit>guile 2.0 did roughly no optimization so it compiled things a lot faster <OrangeShark>davexunit: but then everyone has their own forks because they prefer some different data types <davexunit>OrangeShark: that can all be put to bed by including one implementation in guile <davexunit>every language has a basic json module in their standard library. <davexunit>the one that can be implemented *today* without changing other parts of guile <MaliRemorker>from reddit: For school I have been tasked with the creation of a text based game in QBASIC. However its eccentric features have left me confused and I would like to ask how would one go about doing this? Particularly the creation of something like a json parser for a more dynamic level creation experience. Thank you in advance! <Apteryx>MaliRemorker: agreed it's an imperfect comparison but an interesting one non the less. <Apteryx>davexunit: I think some optimizations are already turned of for Guix. <davexunit>and I spent a lot of time writing 2d games in it <davexunit>which was fun because to render efficiently you got to write your own subroutines to poke the right buffer in memory <MaliRemorker>davexunit: qbasic was my first language, too. bit i was only writing textual games <MaliRemorker>well, i didn't have a pirated copy of c++ compiler anywhere near in my country which was under economic sanctions at the time <Labu>I didn't find where usage of optional key word argumen is documented in the documentation. I find documentation about how I can build function which take these but nothing about use it. <Labu>hello manumanumanu I found it when just I have written my message <manumanumanu>great! if you ask a question, be sure to stick around! some of us are slow to reply :D <Labu>indeed procedure index is very helpful but I was looking for a general usage so I had pain to find what I want to known <Labu>by chance guile documentation is very good <Labu>I have this little test code whch throw an error from web lib <Labu>the error is "unexpected body type" but it's a string <Labu>If I try with simple string I don't get this error <amz3>Labu: what is the backtrace? <Labu> 283:29 1 (#<procedure f0fc80 at web/server.scm:275:3 ()>) <Labu> 0 (scm-error misc-error #f "~A" ("unexpected body type") #f) <Labu>ERROR: unexpected body type <Labu>my version is a BSD port and is pretty old (2.0.14) <Labu>same error on debian with 2.0.13 <spk121>(sprintf "%10.2f %10.2f %c %10s\\n" 3.14159 1.414 #\\x "hello") <Labu>when I try in REPL templatize itworks fine <Labu>spk121: great do you prefer C string formating style ? the common lisp style is good too there are surely some implementation for guile <daviid>spk121: nice! but why? format does all that (and much more...?), curious, what motivated you <Labu>daviid: I don't know guile hasa built in format features. it's great <Labu>other scheme implementations don't implement it <spk121>labu: Guile's format it better. But when porting C to scheme, I want the output to be exactly the same. <spk121>daviid: to help me port a program from C to scheme and get the output exactly the same. <daviid>spk121: and that is not possible using format? <daviid>spk121: nerver mind, i was just curious <spk121>daviid: very possible, but, annoying in practice to get the format exactly right <daviid>spk121: i think alex shinn wrote a sophisticated printing 'lib', can't remember where it is <daviid>but you probably know that of course... <daviid>spk121: i see that sprintf could be nice for newbies, format is a bit intimating at first... <spk121>daviid: for example the guile format string for "%f" in C is "~,6,2,,,,'ee" which is a bit unwieldy <spk121>erm "%e" I mean. 6 digits of precision, two digits of exponent, lowercase e exponent. <daviid>yes, I use a few of these unwieldy expr in guile-cv :) <dustyweb>(string->jsexpr "{\\"hi\\": \\"friend\\", \\"pets\\": [\\"cat\\", \\"puppy\\", \\"rat\\"]}") <dustyweb>'#hasheq((hi . "friend") (pets . ("cat" "puppy" "rat"))) <dustyweb>is reader syntax for immutable hasheq tables <dustyweb>O(n) is faster except when it isn't, and when it isn't is a much more severe scenario than the case where it's an operation I think <dustyweb>ACTION works with some truly large json documents