<paroneayea>ArneBab_: I think you especially will find that link interesting <paroneayea>since it's "determine parens by indentation" among other things <marusich>I notice that some variables etc. begin with a % in guile. Does it mean anything? I searched using Google and looked at every occurrence of % in the Guile manual, but I couldn't find a definitive answer. <artyom-poptsov>marusich: Hi. AFAIK, one convention is that global variables that should be immutable (that is, changing of such variables will have serious or undesired consequences) should be named with '%' as a prefix. like this: '%global-immutable-variable' <artyom-poptsov>In case of procedures, prefix '%' may indicate that this procedure is a low-level one and potentially dangerous. <marusich>Hm, interesting. Thank you for the info and the links. <artyom-poptsov>nalaginrut: Hi. Hmm, do you mean that '%' convention is somewhat unusual for Lisp? <artyom-poptsov>My guess is that '%' was introduced to distinguish global mutable variables from immutable ones. <nalaginrut>but maybe it's different in Scheme? I don't know ;-P <artyom-poptsov>Heh, but I'd love to hear any thoughts on '%' from more experienced Lisp programmers. <nalaginrut>personally, I add % before an inner or low-level thing <artyom-poptsov>nalaginrut: Alright, that's the common usage of '%', I guess. Is there any Scheme coding style guide that explicitly mention this convention? <nalaginrut>I never know that, I think it's some kind of word of mouth... <nalaginrut>anyway, a natural rule often generated in this way <wingo>mark_weaver: re: building on i686, excellent! <fps>hmm, what is the usual way of signalling error conditions from within a procedure? <fps>artyom-poptsov: that's what i would use mostly in c++, but i'm a guile noob <fps>ok, will look up guile exceptions <fps>artyom-poptsov: thanks <wingo>civodul: i mentioned the ltdl thing on my blog because mark_weaver and i had discussed it here iirc <wingo>i agree that though we can mention plans, observations, opinions etc elsewhere we should discuss on guile channels :) <civodul>yeah and that bit sounded like "the libtool hackers are a bunch of assholes" <wingo>mmm, it's not that libtool is unmaintained, ltdl was unmaintained at that point <civodul>well, a casual observer could say that Guile is equally unmaintained <civodul>by looking at the last release date of 2.0 <wingo>this was 2008 or 2009 or so, mind you... <civodul>but yeah, Libtool is probably not very active, that's for sure <wingo>but i think that what ltdl offers us is approximately of zero value <civodul>it has small value, because it's a small piece of code <civodul>but i would not want to reimplement the portability stuff in Guile <civodul>in a project at work people did reimplement that sort of stuff <wingo>it would be nice to (dynamic-link "libm") and have it work even if libm.so isn't there <wingo>to be able to specify soversions you are compatible with also <wingo>i.e. if only libm.so.N.M.O is there <wingo>i think ltdl would not make a bad gnulib module but as a separate project it's too much trouble <wingo>and the .la stuff is bonkers <civodul>so you're saying it would be fine if we bundled it? <wingo>yes, and partially evaluated it against our needs :) <civodul>libltdl has been around for ages, so one is unlikely to find a distro that doesn't have it <civodul>regarding versions, .so.xyz is probably not the right way to go <civodul>i think symbol versioning is more appropriate <civodul>because you wouldn't know what do put as the "xyz" in ".so.xyz" <civodul>so this is just to say that it's not all that trivial <wingo>that doesn't meet the use case at least. you want to be able to load libraries like libsqlite3 without caring whether the .so link is there or not <wingo>and without forcing debian and other users to install -dev packages <civodul>sorry i had misunderstood what you meant <wingo>there's *also* the question about wanting to load a lib with a single major soversion <civodul>yes, but that's where i think dlvsym might be better <wingo>could be, yeah, but ltdl doesn't support that <wingo>i am unwilling to wait for ltdl to be everywhere and to have to have compat code to ltdl versions. i think the amount of code we are talking about if we incorporated this lib would be 500 lines *at most*. that to me says we should bundle it, no question <wingo>if it were in gnulib that would make more sense <civodul>that it's already "everywhere" for my notion of everywhere, and that we *removed* the bundling of ltdl in Guile years ago, suggests to me there's no reason to go back and revisit that decision <wingo>so, i meant "the new hacked version of ltdl" <wingo>and regarding history: i think the landscape of operating systems is different now than it was in 2008. we can just rely on dlopen now and maybe have a windows implementation. <wingo>and maybe end up pushing the windows implementation to gnulib <civodul>just to be clear, i'm actually fairly rather open on these issues, contrary to the impression i give ;-) <civodul>what i'm opposing to is throwing the baby with the bathwater <wingo>yeah i'm not proposing to change anything right now <civodul>and discuss these things with those which i consider to be "members of our team" <wingo>we'd need a reason, some sort of cost-benefit thing <civodul>that means libtool people, gnulib people, etc. <civodul>and think not of our own little short-term Guile benefits, but that of the greater team <wingo>you are better at that than i am, i think :) whenever i propose something to gnulib or libtool it fizzles out <civodul>and don't gratuitously piss off Eli and others who struggle with Guile on Windows <civodul>well i'm not saying it's easy, there's a "communication cost" as you put it <civodul>but doing it our own way has its costs too <wingo>it fizzles out and so i end up not doing the thing <civodul>i mean it can be tricky, and it's not a very rewarding task <civodul>i'm no different in that respect ;-) <civodul>but we must put some effort in that direction <wingo>i don't mean to push this work off to you either :) <wingo>so i guess saying it's a natural thing is missing the point <civodul>saying "we can do better than 'them'" is missing the point <wingo>but even then i think there are valid reasons to avoid building a distributed system subject to combinatoric composition, with separately released modules on wildly different release and deployment schedules <wingo>(i meant that i was missing the point) <wingo>(not a criticism of you but of myself) <civodul>there are technical issues, and social issues <wingo>i disagree with that, i guess :) <wingo>we often have choices to re-use or to re-implement and there are costs and benefits and sometimes we will do one and sometimes the other <wingo>saying "we can't live in our own world" is not useful imo :) we can always choose to implement. it might not be a good decision but we _can_ do it :) <wingo>sometimes a good decision, sometimes a bad one. <wingo>as a programming language implementation, we implement patterns of all sizes; we don't dynamically link to a ConditionalBranchProviderImplementation :) <wingo>but we do link to libc of course <wingo>and in between, many choices <wingo>the friggin error codes from libltdl <civodul>it has it warts and all that, no disagreement here <wingo>it's always "file not found". and the worst thing is, they are constrained to emit those codes because of something about their use case <wingo>which is a use case that we don't care about <wingo>but to fix it you have to think hard about abstractions that don't matter to users <wingo>and in practice: that bug is *still* there, unfixed, after probably about 10 years. <wingo>whereas if it were in guile it would be fixed. completely bonkers <wingo>no i really think that particular use case didn't matter to guile <wingo>but ok, we can keep on telling users to strace their guile processes to figure out what file ltdl is failing to load :) <wingo>ACTION did an apt-cache rdepends on libltdl and got a surprisingly long list of projects, wonders what these projects find of utility in ltdl <civodul>that agressive rhetoric, "bug is *still* there", is exactly what we dislike of dak <civodul>dak keeps repeating everywhere that Guile is "unmaintained and broken beyond repair" <wingo>i have to figure out why i am communicating in this bad way, that's not what i meant to do <wingo>i do think there is something wrong with the situation and it's not the fault of the libtool maintainers, or at least i don't hold them at any fault <wingo>i would like to find a way to criticize both libtool and the organization of our project without claiming that libtool people are assholes (something that i did not intend to do, and tbh i am not sure that's what i did; could it be you are making the project->people link too strongly? dunno) <civodul>i can hear the technical criticism, and i agree with a large part of them <civodul>but i think that saying publicly that "project Foo is unmaintained" is aggressive <civodul>and hostile towards the people behind Foo <civodul>i understand that was not your intent <wingo>so here's what i was trying to say. this bug is there and unfixed, and it's not because people haven't tried to fix it. <wingo>i know i've spent many hours on it and i think other people have as well. <wingo>and i suggest it's something about our social organization that is preventing some things from being fixed. <wingo>for me specifically telling me to go back and spend more time there is... well it's unlikely that i do it :) hence the knee-jerk nope, just not somewhere i feel it's productive to spend my time <wingo>i apologize for indirectly suggesting that the libtool maintainers were somehow irresponsible, i'll try to avoid that in the future <wingo>and so for me the expected effect of this social division is probably a prolongation of the current set of bugs. not critical bugs but they sure are irritating. <civodul>maybe i was just underestimating the badness of the situation, too <wingo>well, i had forgotten it mostly, i was just roused into vehemence remembering some of the bugs :) this indignation too will pass away :) <ArneBab>paroneayea: nice! that looks roughly like wisp-on-the-fly ☺ <dsmith>wingo, make check passes on my 32bit single core system <dsmith> time (git clean -dxf; ./autogen.sh && ./configure && make -j2 && make check) <wingo>good that make check passes tho <dsmith>model name : Intel(R) Pentium(R) M processor 1.70GHz <wingo>(use-modules (rnrs bytevectors)) (define (sum bv) (let ((len (bytevector-length bv))) (let lp ((i 0) (sum 0.0)) (if (<= (+ i 4) len) (lp (+ i 4) (+ sum (bytevector-ieee-single-native-ref bv i))) sum)))) <wingo>then (define fv (make-f32vector #e1e7 1.0)) <wingo>i get 0.175s on this machine <wingo>but anyway you should see 0 gctime <wingo>because all the floats are unboxed in that loop <wingo>i am going to give a go at unboxing 64-bit ints this evening on the train <wingo>it seems reasonable given that so many instructions work on integers in the range [0, most-positive-fixnum] <wingo>in that loop i should be able to unbox the other loop variable too <wingo>sadly for some reason bytevector-length isn't getting hoisted; had to do it manually :P <dsmith>;; 0.718000s real time, 0.702000s run time. 0.000000s spent in GC. <dsmith>wingo, And it's v2.1.1-29-g13edcf5 <wingo>i was getting around 60 cycles per loop iteration, you get around 120 cycles <wingo>which i guess is explained by the difference in age of these machines, dunno tho <taylan>wingo: it works now :) only problem is progress reporting at presence of multiple threads. is there anything I can do short of using mutexes (ew)? <taylan>ACTION checks the Guile manual's Scheduling section <taylan>oh, maybe mutexes aren't so bad with with-mutex <taylan>hmm, monitor also looks interesting <taylan>in fact it might be exactly what I need <wingo>i think monitor is probably not what you need <wingo>i'm not really sure what it's supposed to do, tbh <wingo>pretty sure (with-mutex (make-mutex) FOO) is a no-op, semantically :P <taylan>oh, I hoped it does some magic so that (par-for-each (lambda (x) ... (monitor FOO)) xs) ensures FOO not overlapping <wingo>i think maybe it used to do something like that <wingo>when we had our old expander <wingo>embedding the mutex into the AST or something <wingo>funny, no bug reports on that :) <taylan>not sure if I saw 'monitor' anywhere else than in Guile, so maybe nobody uses it, although it seems perfect for this use case <taylan>hmm, Objective-C has @synchronized(obj){ ... } where a mutex is "derived" from obj <wingo>yeah so that's been broke since 7902c547 in 2009 <wingo>our threading story is kinda scary :/ <taylan>I find it very neat that we can just (begin-thread ...) and such though. and let-binding a mutex outside the par-for-each then using with-mutex should fulfill my use-case, and that's very clean too. <wingo>lexical scoping + threads is pleasant <cmhobbs>hey folks! can i execute an external command with guile kind of like how backticks or %x{} works in ruby? <cmhobbs>also, is there any batteries-included bits for parsing JSON? <mark_weaver>cmhobbs: there's 'system' and 'system*' for running commands <cmhobbs>cool, thanks! i'll dig those up in the reference manual <cmhobbs>i wish i had the reference manual in info <cmhobbs>is the reference manual on the website different than the info pages? <mark_weaver>as for JSON, there's guile-json, an external package, although we're not happy that they use hash tables for represent JSON objects, so davexunit has a proposed library that will soon be part of core guile. just needs some more revisions before it goes in. <mark_weaver>cmhobbs: the reference manual on the web site is the same as the guile info manual <cmhobbs>for whatever reason i thought they were different <djcb>oh, nice to hear about the json lib <cmhobbs>that'll make my life easier since i can just hit the info pages from right inside emacs <mark_weaver>I recommend the info manual, because you can easily look things up in the index with the 'i' command. <cmhobbs>ig uess i could look at the manual in emacs online with eww but meh <mark_weaver>info is *much* more efficient to use than the web manual <djcb>once you have the key bindings in your muscle memory <taylan>Petit_Dejeuner: I think the main problem is that they generally don't go well with functional programming style <jjwatt>clojure handles them pretty well in a functional style <taylan>I was about to mention Clojure maps :) <taylan>sorta kinda have a distant plan of writing an SRFI for something like them, distinct from SRFI-126 <davexunit>jjwatt: those are a different data structure entirely <taylan>^ they're immutable maps, not contentional hash tables <davexunit>many of us really want persistent hash tables and vectors in guile core <davexunit>but conventional imperative, mutable hash tables are useful in some cases <taylan>davexunit: have you looked into ijp's pfds? <Petit_Dejeuner>Racket has something similar for dictinaries. hash-ref and hash-set (note the lack of !) <davexunit>taylan: yes, he has an implementation and so does wingo <davexunit>wingo experimented with them and gave them cute names like "fector" and "fash" <taylan>ijp's vectors were also called fector, didn't know of fash <taylan>"map" is probably too prone to confusion with map procedures <dsmith-work>wingo: 64bit Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz <dsmith-work>wingo: And the time there is ;; 0.280389s real time, 0.280121s run time. 0.000000s spent in GC. <jeffrin>is it necessary to learn calculus to learn HTDP ? <alexshendi>Hi folks, I built guile 2.1.1 on OpenBSD/amd64, but 3 of 37 tests fail. Is anyone interested in the output? <davexunit>alexshendi: sure! I would send the report + logs to bug-guile@gnu.org <alexshendi>davexunit: Where are the logs located? I did "gmake check > CHECK.LOG 2>&1" is that sufficient? <davexunit>log files should have been automatically written to a test-suite.log file or something similar <alexshendi>I have now run "check-guile" wich writes a "check-guile.log". Is this correct? <davexunit>alexshendi: sounds right. take a peek inside and see if the relevent backtraces and such are in there. <alexshendi>davexunit: It looks relevant but is about 3 MB in size. Should I gzip it and attach it or put it on my website and send a link? <davexunit>I think a guile maintainer could answer this better than I could. <davexunit>mark_weaver, civodul: what logs should alexshendi send to report test failures? <civodul>check-guile.log should have everything <cmhobbs>where would i find docs on the system/system* modules or can someone point me to example usages of them, please? <cmhobbs>oh disregard, i think i'm being dumb <cmhobbs>i'm liberally applying parenthesis where they don't belong <cmhobbs>it'd still be nice to see the docs for that procedure, though <davexunit>cmhobbs: they are in the POSIX section of the manual <cmhobbs>yeah, that's where i was digging. searching for "system" was too ambiguous of an option <davexunit>also, you can use REPL metacommands to get docstrings <cmhobbs>hopefully (but probably not) last question for the day: what docs should i look at if i want to get some data from an api? something like curl in gnu+linux or ruby's net::http <davexunit>section 7.3.8 has information about guile's http client <davexunit>http-get is the procedure you want most likely <davexunit>https support requires using a third party library <cmhobbs>i'm going to pull info from an api over http (no ssl) and use that to execute a few system commands <davexunit>so https is more work than it should be right now. <cmhobbs>automating some things at the office and i'm using it as an opportunity to further practice guile <davexunit>this was back when I did all the graphics programming in C and used libguile to embed guile into the program. things sure have changed for me since. :) <davexunit>and knowing that guile master now has unboxed floating point ops... I think I made the right choice to move to pure Scheme. <davidh>is there a way to redirect the output of `system'? <cmhobbs>how do i actually get to the response body from http-get? <davexunit>it's the second value returned from http-get <davexunit>at the REPL you should see both printed, for example <davexunit>see call-with-values or let-values for dealing with procedures that return multiple values <cmhobbs>i think my problem is that the response body is actually empty <cmhobbs>now that the body isn't empty, i'm getting a wierd format that i didn't expect: <cmhobbs>#vu8(123 116 101 115 116 58 39 100 97 116 97 39 125) <cmhobbs>any idea what that might be? it should be plain text <cmhobbs>again, sorry for the pile of questions <davexunit>guile will automatically convert the response to a string if the content type makes sense <cmhobbs> #<<response> version: (1 . 0) code: 200 reason-phrase: "OK" headers: ((content-type application/octet-stream) <cmhobbs> (accept-ranges bytes) (etag "3901519478" . #t) (last-modified . #<date nanosecond: 0 second: 59 minute: 10 hour: <cmhobbs>21 day: 11 month: 11 year: 2015 zone-offset: 0>) (content-length . 13) (connection close) (date . #<date nanosecon <cmhobbs>d: 0 second: 43 minute: 54 hour: 17 day: 12 month: 11 year: 2015 zone-offset: 0>) (server . "EC2ws")) port: #<clos <davexunit>utf8->string will convert a bytevector to a string <cmhobbs>now to convert this to something useful <cmhobbs>utf8->string should be provided by ice-9 iconv, right? <cmhobbs>i keep getting 'unbound variable' for it <cmhobbs>this is why one shouldn't program while exhausted ;) <fantazo>emacs is planned to use guile? I read that once somewhere. <fantazo>OrangeShark, ok. is that even emacs then? I mean emacs is known for its elisp runtime <OrangeShark>fantazo: which is why guile is working to support elisp <OrangeShark>guile-emacs is available on guix, but I haven't tried it yet <ArneBab>OrangeShark: guile-emacs from guix works for me <ArneBab>OrangeShark: at least guile-emacs works well enough that it can execute org-mode to export my PhD thesis to LaTeX. <OrangeShark>ArneBab: that is great, I need to try it out when I have the chance to <ArneBab>it’s still slow because it precompiles all modules everytime it starts, but I think it’s already really impressive <ArneBab>OrangeShark: if you already use guix, it is really easy to get guile-emacs — it builds right away ***thomas_ is now known as Guest70756
<daviid>wingo: heya! how far from the top of your todo list is #20093 ? any approximate idea about when you plan to work on it ? <ArneBab>unknown_lamer: that’s what I do at work… <cmhobbs>mark_weaver: given you don't recommend the existing json parsing module and dave's module isn't in guile yet, what do you recommend for parsing json? <cmhobbs>also, since i control the data i'm going to be consuming and it's just a string, is there a better string i can feed into guile? <davexunit>we just think it can be done better for core guile <cmhobbs>unknown_lamer: you people quit emacs? that's insane! <cmhobbs>davexunit: alrighty. would there be a more useful string? <unknown_lamer>maybe I should rewrite my crappy python hack kodi remote in guile <cmhobbs>i'm at that point with guile where i mostly know what i want to do and it just takes some trips through the reference manual to get me to my finished product <unknown_lamer>davexunit: a few more features I ahven't committed, but it's fugly and I was wanting to make it more useful and the code is so bad I can't so... <cmhobbs>like a baby deer trying to stand, heh <unknown_lamer>please tell me the new guile web framework supports POST without it being a huge pain finally... that's pretty much the reason I went with cgi.py before heh <cmhobbs>yeah, i used to use common lisp really heavily so guile flows well <davexunit>unknown_lamer: the (web ...) family of modules do pretty much everything I've needed. <davexunit>I don't use any web framework like artanis because I have my own preferences <davexunit>I use pattern matching to handling routing rather than a convential string-based routing system. <davexunit>has a variety of subcommands for doing helpful tasks like compiling <cmhobbs>just noticed it when installing guile-json <Xe>i keep getting this when trying to use guile <cmhobbs>i'm not sure what's going on there but have you tried loading it from just plain old sh? just incase zsh has some strange PATH issues? <Xe>debian package manager <Xe>then removed the debian version and tried to `make install` guile <Xe>then I got that error <Xe>and continue to get it no matter what <Xe>even after uninstalling guile completely <mark_weaver>well, libguile has a compiled-in location where to look for ice-9/boot-9.go, and apparently it's not there <mark_weaver>I would make sure everything it cleared out and try the debian package again. <mark_weaver>and then we can try running it within 'strace' to find out what's going on. <mark_weaver>you can also run guile directly out of the built source directory by running "./meta/guile" <mark_weaver>that should arrange to use all the things from within the source directory itself. <mark_weaver>sounds like maybe you installed the package and then manually removed that file? <mark_weaver>the strace includes the line: stat("/usr/share/guile/2.0/ice-9/boot-9.scm", 0x7fff3ebbc6f0) = -1 ENOENT (No such file or directory) <Xe>reinstalling that package fixed it <nalaginrut>ACTION implemented tables in guile-lua-rebirth according to Lua-5.0 <amz3>how is going you hacking cmhobbs <cmhobbs>yeah, going well. building some stuff at work to automate image creation for some of our machines <cmhobbs>it's a ruby project but i'm using guile as glue <amz3>well, I'm kinda doing nothing :D <amz3>I'm writting some package for guix for software I need some stuff <cmhobbs>i'd like to use it as my primary package manager and os some day <davexunit>I packaged up my game engine for guix to do integration testing <amz3>otherwise I hack on guile-wiredtiger, a leveldb like library <davexunit>got all of the issues with the build system worked out. <amz3>davexunit: you debug guix with sly? <davexunit>I use guix to make sure that my code builds the way I expect it to <amz3>I'm wondering, whether, maybe, if it's possible, one day, if it's a good thing <amz3>to have a guix builder for pure guile packages :) <davexunit>I want to combine guix and sly to make a dungeon crawling rpg called "dependency hell" <davexunit>and the details of the packages are used as input to the dungeon generator <cmhobbs>i'm trying to decide between trying to become a savannah hacker or finding bits of guix to help with for my spare time right now <cmhobbs>guix would help with my guile progress, i think <civodul>davexunit: don't forget TeX Live too ;-) <bavier>davexunit: sounds like an excellent game idea <davexunit>I think an interactive package visualization program in Sly would be fun, too. <cmhobbs>the guts of that work, receive and friends <cmhobbs>and it returns the byte vector i want when it complains about wrong type to apply <davexunit>I need to come up with a very easy, but neat, thing to demo in a screencast for Sly <cmhobbs>awww yeah, guile code up in this repository at work. pullreq approved