IRC channel logs
2016-05-14.log
back to list of logs
<amz3>what's the equivalent of if __name__ == '__main__' in Guile? <amz3>I'd like to execute some code in a module only if it's executed <amz3>and not when it's imported <amz3>It's looks like eval-when might be the solution <amz3>but it doesn't provide a `exec' condition <amz3>but you can't import this module, can you? <janneke>sure: (use-modules ((schikkers music))) <janneke>either that, or run it: schikkers/music.scm <wingo>any savannah status yet? it seems i still can't push b/c mail shenanigans <amz3>my server code I use `call-with-sigint' from the webserver, so that when user hit Ctrl+C the server close database and port <amz3>1) I need to hit Ctrl+C twice to exit <wingo>i have experienced the double ctrl-c problem too <wingo>i tried to debug it but did not succeed <amz3>2) It seems to me the port is not closed, because when I try to run the server again, it's tells me the port is taken <amz3>the port is called `socket' in the code <amz3>wait, it seems to work right now for some reason <amz3>I can't reproduce the second issue right now, strange <amz3>it also fails to parse twitter html <amz3>if someone is looking for a good reason to dive in to parser code :) <amz3>maybe it's sxpath that fails, the error I got is not verbose enough <amz3>search engine is indexing <3 <davexunit>number->string is a symbol, not a procedure call. <mejja>"Number: " is a string not a procedure. <mejja>You have to write ("Number: " ...) as (list "Number: " ,,) <trough>Thank you. I thought that it would return a list without the (list ...) <ArneBab_>roelj: I generally have two emacsen open: my dedicated mu4e emacs and the emacs daemon (for emacsclient). <roelj>ArneBab_: So how exactly does the emacs daemon work for you? <roelj>ArneBab_: Because I never really understood the purpose of running Emacs as a daemon.. <micro`>Not actually 'creating' the functions <stis>micro: it look to me that you need syntax-case <micro`>Does syntax-rules have a deficiency that syntax-case overcomes? <micro`>(Haven't read that far yet in TSPL.) <ArneBab_>roelj: I have an init-script (actually an openrc script) which sets up Emacs for user arne at system boot. Starting emacs takes about 30s. But getting it with emacsclient takes well <1s. <micro`>@stis, @random-nick: Cheers. Will do more reading. <roelj>ArneBab_: Wow! What takes so long to start Emacs? <ArneBab_>roelj: because I have tons of packages in it :) <ArneBab_>lots of customization which stacked up over more than a decade <roelj>How much lines of code is your .emacs? <ArneBab_>I’ve been planning to reduce the code, since many parts could be replaced by elpa packages nowadays <roelj>ArneBab_: Damn.. that is a lot of code indeed. <alezost>ArneBab_: you can significantly reduce that start time if you get rid of (require 'foo). Requiring is needed in very rare cases, most of the times wrapping your settings in with-eval-after-load is enough <ArneBab_>doesn’t removing require increase the runtime when I first use the code? <ArneBab_>amz3: what I deem as most problematic in the current situation is that when I start with a script, I use -e main, but when I turn it into a module with (define-module ...), I have to switch to -e "(@@ (package module) main)" <ArneBab_>so I’d wish that guile -e FUN would be run in the context of (current-module) when I give -s <ArneBab_>then we would have one header which says “run this as a script, using the function defined in the header” <alezost>ArneBab_: yes, but as for me loading a package at run-time is much better than 30s Emacs start-up time; but of course you decide what is better for your .emacs :-) <amz3>ArneBab_: I don't understand <amz3>ArneBab_: I understand now <amz3>I understand the difference now <amz3>ArneBab_: I defined the main outside the module, so that I only do `exec guile -L $(dirname $(dirname $0)) -e main -s $0 "$@"' <amz3>your solution is more elegant <ArneBab_>amz3: how do you define main outside the module? <amz3>before the define-module is done <ArneBab_>actually your solution is much nicer — I did not know that that would work. <amz3>it's janneke solution :) <ArneBab_>that fixes one further problem I encountered when starting into Guile <janneke>amz3: i actually like the solution of using (@@ (package module) main) a lot too <ArneBab_>…you still need to adjust the main when you turn the script into a module, right? <ArneBab_>I’d like to get to a point where I add (define-module ...) to turn something into a module and do not need to add anything else <amz3>defining the main outside the module is strange and also requires to resolve somehow the module... <janneke>no, you can have two mains, the outer just invokes the inner <ArneBab_>but the outer has to resolve the inner, right? <wingo>amz3: did you get an answer about the port still being held? <wingo>i know why but i have to google for it <amz3>I don't understand because I can't reproduce it all the time <amz3>It's not big deal anyway <wingo>yeah it's a unix thing, not a guile thing <wingo>so you have to (setsockopt sock SOL_SOCKET SO_REUSEADDR 1) before you bind <wingo>see make-default-socket in (web server http) <stis>Hmm 2.1. just did a segfault with scheme only code. Maybe a gc bug cause it just happens very seldom and a second try was successful for me. <wingo>stis: if you can minimize the test case i'm interested :) <wingo>still not able to push to guile git <stis>sorry It was a 30s compile and load that was massive. I can only make some statistics of how often it happens and it is very very seldom. <stis>FYI the code is scheme code that compiles and generates a C file that represent a prolog VM that I run interacting well with the guile-vm <wingo>civodul: do you know any more details re: inability to push to sv? <ArneBab_>so I think given that we have to adjust the code for the module somewhere, I actually like the @@ better. <ArneBab_>but I would prefer not having to adjust it at all. The workflow I’d like to see would be that I define the module and the -e main just keeps working <stis>gosh 2.1 is fast, blazingly fast <stis>It will be interesting to see ecravens benchmark with a proper compiled guile 2.1 <ecraven>does guile 2.1 use multiple threads by default? <ArneBab_>amz3: I finally read info on the invocation, and “For compatibility with some versions of Guile 1.4” we can actually use the much shorter form -e '(module)' -s "$0" "$@" <ArneBab_>which is translated into '(@ (module) main)' <wingo>civodul: have you pushed? for me it hangs and fails <ArneBab_>amz3: yes — but I’m not sure whether following the info and sticking to @@ wouldn’t be better: it’s then the same as in actual code. <ArneBab_>can I actually define multiple modules in one file? <ArneBab_>wingo, mark_weaver: what’s the risk that the 1.4 syntax for the guile -e option will stop working? guile -e '(foo)' -s "$0" "$@" <janneke>ArneBab_: *sweet*, I didn't know this, thanks. <ArneBab_>janneke: same for me — until I checked the manual today :) <ArneBab_>paroneayea: natural language parsing with the engine which runs google translate <wingo>ArneBab_: i did not know about that syntax <wingo>reading the docs makes me think "symbol" is spelled wrong :P <wingo>seeing it too many times in a row <wingo>ArneBab_: regarding the future -- i can't say. it could be that the guile 1.4 way is the right thing. <wingo>but if the 1.4 way is the right thing then the documentation should be rewritten to indicate that it's an equally valid option <wingo>re 1.4 i think it was only ttn's fork of 1.4 that did that <ArneBab_>wingo: should I ask in the mailing list before creating a patch for the documentation? <wingo>ArneBab_: i think a patch is a good discussion piece :) in this case the patch is the same size as the msg you would send <wingo>ArneBab_: when you send it, be sure that you're arguing for the right thing :) i mean, we can agree to support this feature. my bigger concern is that we recommend good interfaces that are appropriate <wingo>and if we are recommending -e '(@ (foo) main)' and that's just unnecessarily verbose, we should recommend something else, it seems to me <wingo>i wish, for the nth time, that #!/path/to/guile ... could take more than one argument <wingo>i think i would be prepping a 2.1.3 right now if it weren't for this irritating savannah thing <wingo>i guess i can still make progress but jeepers <ArneBab_>wingo: I think that using the shell trick is really elegant <ArneBab_>elegant in a technical way: different parts of the system interacting to form something greater <wingo>you mean the #! trick? hoo i dunno, it should *not* be necessary :/ <wingo>to me when i see it, i see mainly the ugliness of the restriction that caused us to make it :P <ArneBab_>the #!… is an existing method, and the same goes for exec. Using #! !# as multiline comment syntax is a really elegant way to build on that, since it allows to use arbitrary preparation in the script. <ArneBab_>it eliminates the need to build something special into the language itself <wingo>what if #! were just treated as a comment on the first line? <ArneBab_>the if __name__ == "__main__" in Python is essentially just a hack to add that, since Python as language does not allow using the shell deferring. <ArneBab_>wingo: in Scheme that’s the case, right? <wingo>ArneBab_: you mean in guile or in some scheme standard? <ArneBab_>(though I wish #! ... !# had gone into r7rs <wingo>#! begins a multiline comment and *requires* a !# <random-nick>afaik the r6rs has something like #!r6rs is a comment <ArneBab_>what’s inconsistent is that #!... in the first line is a special case… <wingo>the only reason for the #! / !# business is unix's inability to have multiple arguments to a #! line. <ArneBab_>and I think that’s for backwards compatibility <wingo>it is a bug that got blessed as a feature <ArneBab_>is there anything which depends on the bug? <wingo>dunno, don't care. if we can't fix basic things like this unix is doomed to the trash-heap <wingo>surely there would be ways of progressively allowing for better forms of #! <trough>mejja that doesn't sound like a good slogan. <trough>Especially coming from #guile. "Hey, we're not so bad!" <ArneBab_>wingo: given that I see lots of breakage on the Solaris cluster in our institute, I am actually very happy for restrictions which stay in place… <wingo>ah, nice to know the new url for that one <wingo>ecraven: it seems you rebuilt your guile 2.1. thanks! <trough>Is there a simple way to send a return value to two procedures? <trough>Do I need to bind the output to a variable? <trough>Or is there some function to split the output to two procudures? <wingo>ACTION very pleased with the results there <stis>looks good, does anybody know what the fibc test is doing? <trough>random-nick: Do you mean binding the return value to a variable, or some other trick with a let form? <random-nick>trough: just binding the return value to a variable in the let form <random-nick>well that is a weird way of using continuations, but it's a benchmark after all... <wingo>lol last week i was all like "these benchmarks are stupid" but now that guile 2.1 is doing better i am thinking "what lovely benchmarks" <cbaines>any idea how to get assoc-ref* to work in a repl? Its telling me that the variable is unbound? <wingo>cbaines: where do you know assoc-ref* from? <wingo>basically guile provides a set of bindings in its default environment; assoc-ref* is not one of them <wingo>so you need to import the module that provides that binding <wingo>you need to do (use-modules (guix whatever)), substituting (guix whatever) for the name of the module that provides assoc-ref* <shanemikel>what's the best way to get comfy wih scheme for somebody with some experience with fp (haskell) and already sort of comfortable with elisp <cbaines>Ok, its (guix import utils) for refrerence, thanks wingo :) <wingo>shanemikel: good question! if you know those languages then i think reading the guile manual would probably give you what you need <wingo>but of course building a program to solve some problem you have, in parallel, would be the thing to really make you feel comfortable <random-nick>some people recommend reading sicp, but I think that reading sicp just because of scheme is a little pointless <ng0>I'm giving guile2 on gentoo another try. there was the question and bug for 6 years sitting around which mostly involved slotting. I wonder with the little knowledge of guile i have, is guile2.0.11 backwards compatible to 1.8 and earlier? <wingo>ng0: hard to say. the fullest story is in NEWS; if you are upgrading from 1.8 I very much suggest that you read NEWS <ng0>I am not upgrading, I am trying to dig into the mess that is the bug left in gentoo. they had very much slotting with guile-1, and some packages still depend on 1, current status is getting checked. for me the only thing I did built was guile2 based. Okay, I'll read NEWS then and see what can be done. thanks <nobody_>do any of the "Little" books have good coverate of base (including threads)? I could use some exercises because I tend to be over-ambitions in the problems I invent :) <random-nick>nobody_: well for threading you best consult the guile manual <nobody_>my experience with concurrency is actually pretty thin <random-nick>that contains information about concurrency in guile <nobody_>actually, it looks like SICP might be the right thing for me.. they seem to cover concurrency