<Guest20410>davexunit: I did not know you did work on a libtoxcore binding for guile, are you still active wrt this project? did you have any specific goal? just curious... <davexunit>daviid: it's not an active project. tox is a rather toxic project these days <daviid>davexunit: do you mean 'bad', if so, any other alternative? I use toxic actually :) [the ncurse client] <davexunit>I think the community is not nice and the project itself seems to be stagnating <daviid>I did not know ring, thanks for the pointer <davexunit>I had a lot of fun at the time writing toxcore bindings <davexunit>it would automatically accept friend requests and echo back whatever messages you wrote to it <daviid>davexunit: I tried to help them, but they refusd to copy on savannah and use a mailing list, so I don't want to help... <davexunit>they think that you can only make releases when the software is stable and that everyone should just build from git master until then. <fantazo>the github dislike is strong in here. <davexunit>so in general their project management is super weak. <daviid>davexunit: I'll look into ring,l thanks <davexunit>my current issue with ring is that it's too hard to build without using a bunch of bundled, possibly forked, third-party dependencies <davexunit>but I've made that concern heard, I think, and I hope to see it addressed. <daviid>fantazo: github is a big disaster, imo, it promotes a 'single mind' work flow, kill pricacy principles, and everybody who's there is just loo9king to become famous, it is just all wrong from thye beginning to the end <daviid>my 2c in this profundly decadent world <fantazo>daviid, hmm the workflow is imho fine. and it was better than say gitorious or sourceforge was at the time. <fantazo>the "everybody is there to become famous" well that's what basically why people do any open stuff I guess. <fantazo>ah, I'm again misanthropic, what should I say I dislike this world. it's a joke. a joke of a life, I'm living. <daviid>fantazo: the principle and main idea behind the fsf and GPL LGPL s/w is to help to build a better world, not to become famous :), but i don't want to talk about this here and now <daviid>davexunit: ok, I hope ring listen to your concern, I was hoping a nice, small and clean C API library ... <daviid>fantazo: and the wrok flow is just terrible, imo <fantazo>daviid, the work flow is IMHO better than savanah, gitorious, gitlab. it's like mail, it sucks, but it sucks less. <fantazo>I never ever have seen any FSF promoter who really built a better world. it all looks RMS style shitty to me. <fantazo>I was once a big idealist of the damn idea. but in my eyes it all died in a big damn fire. when people like RMS behave in a way is just plain poisoning the well. <sapientech>mark_weaver: amz3` dsmith-work thanks for getting back. I would rather not use define-macro, but this is how the code originally came <sapientech>i plan to eventually switch to the modern pattern syntax <sapientech>the only changes i've made is to turn the macro def files into modules. ill try to work on a small example--the macro im having issues with is quite large <mark_weaver>fantazo: how exactly is RMS behaving that you think "is just plain poisoning the well" ? <fantazo>mark_weaver, eating stuff from his feet? <fantazo>mark_weaver, attacking people because they say Linux and not GNU/Linux? <fantazo>mark_weaver, exploding about senseless questions at presentations? <mark_weaver>do you have anything to contribute here other than venom? <fantazo>look, people describe me sometimes as a philosopher, so I ask. <fantazo>because I'm interested in guile scheme. <mark_weaver>well, if you want to talk about guile some time, that would be a welcome change <fantazo>because I want I like a community to talk to, maybe finding friends to develope stuff. <fantazo>mark_weaver, I do talk about guile. at the last occasion I asked about the compiler tower. <mark_weaver>when I search for your nick in my log of this channel, rather little of what you have to say is about guile <fantazo>well, then. then I do the only positive thing in your view, leaving the channel. Thank you for making my life a little bit less social again. <mark_weaver>so, the problem there is that the macro expands into a mixture of definitions and non-definitions that are interleaved <mark_weaver>in scheme, internal definitions within a body must precede all non-definitions. <mark_weaver>specifically, the 'set-record-type-printer!' calls are non-definitions. <mark_weaver>one hack to make this work would be to change those into definitions to dummy variables <mark_weaver>e.g. change (set-record-type-printer! ...) into (define ,dummy (set-record-type-printer! ...)), where dummy is a freshly generated symbol <mark_weaver>(that last complication would not be necessary if you were using modern hygienic macros) ***spauldo-afk is now known as spauldo
<mark_weaver>the reason this macro works at the top-level environment is because at the top-level, definitions and non-definitions can be freely intermixed. <sapientech>mark_weaver: perfect answer that makes total sense <sapientech>mark_weaver: instead of making them dummy variables, could i also just rearange them? <mark_weaver>well, you could put them at the end, but that would lead to another problem: you would not be able to put any definitions after a 'define-el-slist' macro use. <mark_weaver>in scheme, within an inner definition context, the 'begin' form is a *splicing* operator, so the contents of the 'begin' is spliced into the surrounding body. <mark_weaver>so, all of the stuff within the 'begin' that this macro expands to are actually spliced into the surrounding context. <mark_weaver>and if there are non-definitions at the end of that 'begin', then it will effectively prohibit any further definitions in the body where 'define-el-slist' is used. <sapientech>mark_weaver: ah interesting, i was experimenting with creating definitions in a begin, and was suprised they were accessable in the surrounding env, <mark_weaver>if you wanted to create a nested block of definitions that were not visible from outside, wrap them in (let () ...) instead <mark_weaver>but in this case, you presumably want those definitions to be accessible from the outside <sapientech>mark_weaver: yes the point is to give those defs to the user <sapientech>slightly tangential, but why exactly to they define a bunch of symbols with gensym? couldn't they just have, instead of (define ,some-sym..) just do (define name-of-proc ...) <mark_weaver>I can think of at least two reasons: (1) if they did that, you would not be able to use 'define-el-slist' more than once in the same body, and (2) it could lead to unintended variable capture, e.g. if the outer code happened to use the same name as the macro did. <mark_weaver>in practice, lisp programmers work around this by choosing long variable names that they hope will not conflict with variables used by the user. <sapientech>okay cool that makes sense, was wondering if it had to do with inner definition rules, but that wouldn't make sense since they are inner defines anyway <mark_weaver>hygienic macros take care of all of this very nicely <sapientech>mark_weaver: well one way to appreciate hygenic macros is to deal without them first :) <lfam>One often comes to appreciate some feature *just* as they need it ;) <sapientech>great, should be good to go, appreciate the help <lfam>Don't ask me, I'm quite ignorant :) <mark_weaver>but it would be great to have a JIT at some point too <davexunit>a compiler that makes me compilers just when I need them, now that would be something <spauldo>amz3`: I figured out how to do it (I think), but I've got other issues I'm trying to figure out. <spauldo>you know it's time for a desktop cleanup when you've got enough xterms open to blanket eighteen desktops. <spauldo>so, anyone here know of a way to find out what symbols are defined in a .go file? I've looked in the docs and came up empty. <spauldo>and googling "symbol" for something involving lisp isn't horribly helpful <mark_weaver>spauldo: in the general case, it's tedious. in 2.0.x, a .go file does not contain a list of definitions, but rather executable code for our virtual machine that, when run, creates the definitions by executing VM instructions. <mark_weaver>in the common case where the .go file defines a single module, you could load it and then iterate over the bindings in the module using 'module-for-each' <mark_weaver>out of curiosity, why do you want to do this? why not just look at the source code? <spauldo>ah. Yeah, I can see how that'd make it hard. I didn't know if it had a debugging section that contained those or not. <spauldo>I was trying to figure out if my changes to this library code were going in or not. I'd compile the guile-sdl2 library and none of my new definitions would be in it. Deleted my cache and all, couldn't figure it out. <mark_weaver>in 2.2.x .go files are just ELF files, so you should be able to make use of tools like 'objdump' I guess <spauldo>Turns out I had ran a 'make install' back when I first started playing with it. I only asked because I figure that knowledge might be good to know in the future. <spauldo>yeah, I just had to install it again and delete the cache out of /usr/local. Total brainfart. <sapientech>mark_weaver: hey also was thinking, couldn't i make my own macro, like define-record-printer instead of creating a dummy def? <mark_weaver>it would need to expand into a dummy ref, but at least you'd only have to do it in one place <mark_weaver>I was about to say that if you made it a hygienic macro, then you could avoid doing the gensym, but I'm actually not sure that would work if you use this hygienic macro within an old-style 'define-macro' <mark_weaver>it might be that the old-style 'define-macro' discards the "marks" that are needed to make hygiene work. <sapientech>working as in, it passed through to the next issue, but not so sure about the (define (gensym) ...) step <sapientech>i defined that in a separate file, and then use it in the macro like this: (define-record-printer ,rec (lambda () ...)) <mark_weaver>for one thing, you're defining a procedure there, whose body will not be executed unless the procedure is called. <mark_weaver>and it won't actually call 'gensym'. it will instead define 'gensym' to be this procedure that calls 'set-record-type-printer!'. <mark_weaver>normally, you could fix this by simply changing "(gensym)" to "dummy" <sapientech>dont i want to be defining a procedure though? i just want this macro to turn into a define procedure, which is what it's doing <mark_weaver>but, as I said before, I think the hygiene might be defeated by using this hygienic macro within a non-hygienic macro, because the latter discards the extra syntactic information that enables hygiene. <sapientech>mark_weaver: suppose some of this is over my head <mark_weaver>defining this as a procedure would be fine if you ever called it. <mark_weaver>when do you suppose the 'set-record-type-printer!' call would be run? <ijp>mark_weaver: yeah, the discarding makes it really difficult to compose defmacros, I've got a thing I copied from eli on #racket for making it slightly nicer somewhere... <sapientech>mark_weaver: it is called anytime i do (display graph) where graph is (define graph (make-name-of-record)) <sapientech>mark_weaver: yeah it actually seems to be working <mark_weaver>if you call (set-record-type-printer! record print-proc), then 'print-proc' will be called when you call (display graph) <mark_weaver>but I'm asking a different question. I'm asking when (set-record-type-printer! record print-proc) will be called?> <mark_weaver>ijp: circular syntax objects are indeed to be expected in R7RS at least, within quoted datums. <ijp>yeah, I think I finally got an affirmative on that in #racket the other day <sapientech>mark_weaver: not sure, i imagine somewhere in the mess of a macro <mark_weaver>I don't see how it could happen with the code you pasted <sapientech>mark_weaver: would showing you the expanded macro help? <mark_weaver>you are defining a procedure with a name that cannot be known to the outside, and that will never be called. <mark_weaver>although using it within a non-hygienic macro might allow its name to be known to the outside, but if it somehow works, it will be because of another problem elsewhere. <sapientech>mark_weaver: sure, but this definition is not meant to be accessable to the user <mark_weaver>(possibly by causing the actual 'gensym' procedure to be rebound to this procedure, in which case 'gensym' will not longer work as expected, but instead will cause your record printer to be defined) <sapientech>btw i changed (gensym) to dummy, which is working... <mark_weaver>I'm sorry, but I don't have time to continue trying to explain this. maybe someone else wants to try. <sapientech>mark_weaver: yeah for sure, thanks for all the help though! <mark_weaver>actually, having thought about it a bit more, the hygiene of 'define-record-printer' should not be affected by its use within a non-hygienic macro, so if you change (gensym) to dummy, that should be fine. <mark_weaver>the reason is that macros are expanded starting from the outside and working inwards. <mark_weaver>so the 'define-el-slist' macro is expanded first, and its expansion will include uses of the 'define-record-printer' macro. only later will the 'define-record-printer' macros be expanded. <mark_weaver>so the "marks" attached to the 'dummy' identifier introduced by the 'define-record-printer' macro cannot be discarded by the 'define-el-slist' macro, because 'define-el-slist' does its work earlier. <sapientech>mark_weaver: thanks for your brain being bugged by the issue, and thinking about it over other work :):) <sapientech>so much to learn, appreciate your expertise, this helps a lot <spauldo>hrm, any way to turn off auto compilation in the .guile file? The documentation for <spauldo>%auto-compilation-options is sparse at best, and its definition in the guile source code doesn't give any clues either. <spauldo>ACTION thinks he's just going to have to download the guile source for handy grepping <mark_weaver>you can also set GUILE_AUTO_COMPILE=0 in the environment <mark_weaver>GUILE_AUTO_COMPILE has the advantage of being documented <spauldo>Ah, OK. I was trying to just change how geiser calls it so that I wouldn't get caching while working on stuff in emacs. <mark_weaver>I know you thought it might have been a problem, but the problem turned out to be elsewhere <mark_weaver>one important note: guile debugging is a *lot* better for compiled code <spauldo>really? I wouldn't have expected that. <mark_weaver>there's no reason why it couldn't be made better for evaluated code, but less effort has been spent on that. <mark_weaver>mainly because in practice we almost always use compiled code <spauldo>and yeah, I'm making changes to a library and testing it with code outside the library, and since I'm a noob I wanted to eliminate any unexpected issues from cached old versions. <mark_weaver>if the source file is newer than the .go file, it will be recompiled <mark_weaver>I would suggest leaving auto-compilation enabled unless you discover an actual problem with that. <spauldo>OK. I wasn't sure on that. The docs say something about it, then go on about how there's no dependency tracking for it, and since it's a library I wasn't sure if it'd see changes to a module that's called by another module. <mark_weaver>there is an issue there, and it has to do with macros. if you change a macro, that won't trigger auto-recompilation of code that uses that macro. <spauldo>OK. So I'll need to delete the cache then if I do macro work, I take it? <spauldo>or is there a better method for dealing with this? <mark_weaver>if you change a macro, make sure to recompile any modules that use that macro. <spauldo>sounds easy enough. I don't expect to change any macros, although who knows? I might end up writing one or two. I gotta get the code to work, first. <mark_weaver>deleting the entire cache would also work, although that's a big hammer. <spauldo>thanks, man. That clears some things up for me. <spauldo>sweet! I can draw lines in sdl2 now. Can't set the render draw color to black for some reason, but I can draw white on a magenta background. <spauldo>good stopping point for the night. Thanks for everyone's help. ***spauldo is now known as spauldo-afk
<amz3`>sapientech: rgraph looks interesting <rekado_>Does anyone here have experience doing Guile web development in a REPL? <rekado_>I'm getting tired of restarting my little application for every minor change. <rekado_>should I start Guile with --listen and then attach Geiser somehow or is there a better way? <mark_weaver>rekado_: geiser has support for that. see "Connecting to an external Scheme" in section 3.1 (Starting the REPL) of the Geiser manual, specifically M-x connect-to-guile <mark_weaver>rekado_: and geiser has several commands for evaluating individual definitions or buffers, see section 5.1 (Scheme buffers) <rekado_>thanks; I couldn't get this to work, but if that's the way it's normally done I'll just try harder. <rekado_>(I normally use Geiser in the simplest possible way. Never attached to a running Scheme process.) <mark_weaver>I confess I don't have personal experience with this. I'm still using stone tools, mainly because I haven't allocated the time to learn geiser well. <mark_weaver>so maybe there's something I'm missing here. some other people around here use geiser much more, so I'll let them chime in. <rekado_>ah, I see why it isn't working. I'm not using the right shebang. <mark_weaver>(my stone-tools approach involves using the ,m command from the REPL to switch to the appropriate module, and then pasting in my modified definitions via emacs to the REPL) <rekado_>I'm using a Guile script to start the web server, but something about the order of the arguments in the extended shebang must be wrong. <rekado_>yeah, I'm mostly using stone tools as well. About to advance to the bronze age. <alezost>rekado_: "M-x connect-to-guile" (or "M-x geiser-connect" in general) is for connecting to a port; if you specify a socket file to --listen option, then "M-x geiser-connect-local" is the way to go <rekado_>one more question about using Geiser with a local REPL and (web server): when my program encounters an error I see a backtrace on stdout, but in Geiser I don't see anything and I cannot debug anything. <rekado_>how to inspect the current state of the process through the REPL in this case? <rekado_>my Guile script has an extended shebang that includes "--debug" and "--listen". Its purpose is to start the web server with "run-server". <rekado_>does this happen in another thread and thus prevents me from accessing its state from within the REPL? <rekado_>I can load new definitions just fine, but I'd really like to inspect the backtrace in the REPL. <davexunit>I suspect there is some way to make this happen, but I haven't dug deep into it. I'd like to have it for Sly. <rekado_>it would really be a very cool feature, making development much nicer. <paroneayea>rekado_: I'm currently building up a number of web utilities as I'm coding pubstrate... I might be interested in seeing where we're hitting overlap, aside from just formencoded data :) <paroneayea>ACTION thinking of spinning off a guile-webutils repo <paroneayea>currently I'm working on signed session cookies, and will probably write a form handling library soon <paroneayea>rekado_: what are you writing, out of curiosity? <paroneayea>hey, I was able to borrow the rfc2616 date parsing straight from guile's http library <paroneayea>one thing I'm not in the habit of that everyone else seems to be <paroneayea>is having my procedures accept a port to write to <paroneayea>I usually just seem to have a *->string operation that writes to a string instead.. <davexunit>and you can have a port that writes to a string! <paroneayea>I guess it's also always trivial to write a *->string wrapper around any port-accepting function <davexunit>(lambda (foo->string foo) (call-with-output-string (lambda (port) (write-foo foo port)))) <rekado_>paroneayea: I'm currently writing the backend part for dealing with chunked file uploads (via FineUploader) <rekado_>paroneayea: the final goal is to have a web interface for a bioinfo tool we've developed. <davexunit>a sign that robin is coming back to guile-emacs development? <amz3`>there's a competition at hackerrank for machine learning, it requires facebook login tho <amz3`>it feels good to use guile 2.1.3 :) <amz3`>the backtrace in emacs 25 is so much more helpful <paroneayea>amz3`: what's that about emacs 25? what's the difference between that and emacs 24? <amz3`>with emacs 24, when you 'M-x compile' some guile stuff.scm, the output in the compilation buffer is colored and you can click on a line of the backtrace to jump to the correct line in the file if it's open <amz3`>in emacs 24, compilation buffer is plain text only <amz3`>this makes me think I should git pull my emacs repo and rebuild <amz3`>the repository is so massive <amz3`>git clone --depth=1 git@github.com:emacs-mirror/emacs.git <paroneayea>amz3`: ah cool, I don't use M-x compile but probs should <amz3`>paroneayea: how do you do? you have a terminal aside? <amz3`>I have some unit tests, that's why I M-x compile often <paroneayea>amz3`: I'm usually hacking through emacs + geiser and evaluating some things as I go with C-M-x/C-c C-c, C-c C-b, and compiling specific buffers with C-c C-k (which gives some nice feedback on errors), and then when I exit out of whatever "guile --listen" I'm connected to, I run a "make check" <amz3`>I have an issue with geiser-eval, it's that it creates 2 buffers one for the REPL and another for debug <paroneayea>amz3`: I don't do make check that often, since I usually evaluate tests as I'm writing them, but I probably should use more often <amz3`>the debug buffer never happens to be displayed <amz3`>so you kill *geiser dbg* when it pops? <paroneayea>C-c C-z allows fast hopping back and forth between a buffer you're hacking on (or C-c C-a if you want to "jump into" its module) and the REPL <amz3`>I have another issue, it's that geiser fails to eval my emacs code for some reason <amz3`>it always ask to do M-x run-guile or something <paroneayea>for me, live hacking with geiser is probably why I feel so productive in guile <amz3`>yeah, i am so much bad at live hacking <amz3`>someone should do a tutorial or something <amz3`>a friend of mine is looking for learning elisp, I'm trying to convince him to learn guile but it's difficult <amz3`>he says there is too much elisp in emacs <paroneayea>well that'll probably always be true, but maybe eventually we'll have guile-emacs as mainline, and scheme will be an option for the elisp-wary :) <roelj>I have a C library linked with libguile in the same directory as my Scheme file. I use (load-extension "./<filename>" "init") to load it. Now Guile throws an error "file not found", but the file is there!! <roelj>I guess I need to run it without Geiser then <dsmith-work>roelj: Strace will show you exactly what files guile is trying to open and where in the filesystem it thinks they should be. <lfam>Not much to learn. `strace -f your-program-here` <lfam>Then you just have to read a few thousand lines of syscalls <lfam>Okay, I guess there is something to learn ;) I didn't know about that <dsmith-work>You can give -e a comma list of syscalls, but there are also some groups, like "file". <roelj>dsmith-work: Cool, that is handy indeed. <roelj>Argh.. In a regular 'guile' it works just fine. In Guile via Geiser, it doesn't <roelj>I verified that (getcwd) is in the right directory. <roelj>I also tried an absolute file path <roelj>Right.. I found the problem.. The Guile installed with Guix fails to load the library, while the Fedora-provided Guile loads it just fine. <sapientech>quick question that i can't find online. If i have a macro that takes n parameters, it works when i do (macro parameters...) but not when i do (apply macro '(parameters)) <sapientech>says source expression failed to match any patern in form `macro`