<ruffni>anyone using emacs/geiser for guile? <nly>ah, already disconnected <daviid>nly: cool - though for now, it really needs a rebuild every now and then ... does this at least grabs the devel branch? also, the test suite needs guile-lib, i didn'tsee it in the list of packages it depends on ... unless i msunderstood something maybe, i don't use guix <daviid>nly: because of the former arg above, even if just to sort 'passively' use g-golf, i's recommend to install from the source tree, checkout the devl branch and use the autotool, so yu can pull and make every now and then ... <daviid>nly: of xourse it is nice to have this 'pre-package' definition for guix, thanks again, it will become very usefull as soon as g-golf itself is a bit more stable <daviid>nly: by 'every now and then ...' i mean several time a day ... <nly>daviid it should be a two line change to update ggolf to a new commit version <daviid>nly: as you wish of course, you'll have to that several times a day for the next few months <nly>daviid in guix there is no concept of pulling from a branch, you need to use the commit <daviid>i know, which is why in active devel mode, i'd rather stick to the autotool chain version <nly>nomad-local pkg builds what you have checked out atm <daviid>ok, i'm happy if it works fine this way for you <nly>daviid for tests, guile-lib is in there :) <daviid>str1ngs, nly, I'm now going to work on intance initialization, so that passing 'construct-only property values works, which currently fails ... in the mean time, please report any other problem ... ***sneek_ is now known as sneek
<str1ngs>sneek: later tell daviid. I develop using autotool's but we try to keep a guix definition as a snapshot. so g-golf.scm is just there to be helpful for anyone using guix. I asked nly to seperate it encase at one point you wanted to snarf it for guix.scm. <str1ngs>nly: I forget to mention the g-golf definition leaves orphaned files IIRC. might need to remove recursively the copied paths <wingo>allows for contification of private bindings <lloda>wingo: how do you set -O actually <wingo>lloda: well, -O3 with guild-compile <wingo>otherwise, optimizations-for-level from (system base optimize) <ecraven>wingo: thanks! very sorry I'm a (very much) slow in reacting atm <wingo>i am hoping guile can jump into the top 4 or so <lloda>wingo: I was looking for a setting in .guile or maybe a flag. Something that works with autocompilation. It doesn't look like I can set (optimizations-for-level) <wingo>you can set %auto-compilation-options <wingo>unfortunately no shorthand for -Wall -O3 <ecraven>the problem with raising the cpu time limit to 10 minutes is that it takes forever to run the benchmarks :-/ <ecraven>some benchmarks on some implementations run into infinite loops, so they take the full 10 minutes for those <wingo>ecraven: how many threads do you allow to the benchmarks? <wingo>guile will happily use e.g. 8 threads, for marking <ecraven>I haven't knowingly limited anything <wingo>so in practice the wall-clock time limit might be 2 minutes for guile (e.g.) <ecraven>about safe vs. unsafe I'm a bit torn... on the one hand, it's a benchmark, so stuff should run as fast as it can run <wingo>or less, considering that the current limit is 5 <ecraven>is there a way to set a time limit without impact on the number of threads? <wingo>the thing with the unsafe optimizations is that it's not comparing like to like <ecraven>well, in some ways, it is.... how fast does code from this implementation run at *best* <ecraven>if an implementation doesn't support unsafe constructs, that's ok.. <ecraven>maybe I need to specify more clearly that speed is *not* the most relevant thing in choosing an implementation <ecraven>people should definitely *not* just pick the winner of the benchmarks... there are a lot of other metrics to look at when deciding on the best implementation for a given problem <wingo>i have found the benchmarks to be useful but that definitely limits utility for me <wingo>ecraven: given that the implementations that can do unsafe optimizations generally run fast, perhaps it would be reasonable to run both safe and unsafe variants of chez/gerbil/gambit <ecraven>wingo: I'm working on that, I've been trying to move everything into containers, so that I can more easily just run different versions <ecraven>but real life is interfering hard at the moment :D <wingo>ecraven: fwiw i don't think you necessarily need containers for two different options to a single scheme :) <jonsger>ecraven: to run different versions you could use guix :) <wingo>that doalarm perl hack is really cute <ecraven>jonsger: indeed, but I don't run guix on my main machine, so I need some sort of container/vm anyway <wingo>it's quite possible to run guix as a user fwiw <wingo>without using it as a full os <wingo>but, it's probably not the shortest path to victory :) <ecraven>the master plan is to move everything into containers, so that I can even run stalin or other systems that are not supported on my current setup <ecraven>then I'll add Open Genera to the benchmarks :P <wingo>it's probably way past time that guile had its own benchmark suite... <lloda>wingo: looks like there should be a way to just say -Ox instead of having to list all the options <lloda>I have a question about vm assembly and unboxing, but I don't know how to ask it without abusing your time <lloda>so let me know if you're ever bored <lloda>then (define x (ra-copy 'f64 (ra-iota #e1e3))) <lloda>then look at ,disassemble (lambda () (ra-fold + 0 x)) <lloda>(define y (let ((y (make-typed-array 'f64 0 #e1e7))) <lloda>(array-index-map! y (lambda (i) i)) <lloda>(let loop ((a 0) (i 0)) (if (= i #e1e7) a (loop (+ a (f64vector-ref y i)) (+ 1 i)))) <lloda>but in that, you can see all the unboxed stuff, fadd, etc <lloda>I just don't understand the disassembly of (lambda () (ra-fold + 0 x)) <wingo>how does (ra-fold + 0 x) know that x is an f64vector? <wingo>or an array of f64 values anyway <lloda>the f64vector-ref call is inlined <lloda>ra-fold calls ra-for-each which looks at the type of ra and inlines the appropriate -ref call <lloda>I checked by quoting the macro output <lloda>this is in mod/newra/map.scm <wingo>incidentally... i think unboxed arrays are a classic case for run-time compilation, to specialize on element type and array shape <wingo>for me if i ,disassembly the lambda, it's just a trampoline call to ra-fold <lloda>so the loop isn't there then <lloda>how can you look at the disassembly of that then <wingo>you would need to define ra-fold as (define-inlinable ...) <wingo>well first of all there's no backwards branch, right? <lloda>but I couldn't define-inlinable b/c ra-fold uses case-lambda <lloda>which I need, because it takes var args <lloda>and if I don't fix the arity, I cannot use macros beyond that <lloda>I had a look whether define-inlinable could handle case-lambda, but didn't get far <wingo>that's what's needed tho. probably would have to be a "custom" version of define-inlinable <lloda>I could write 1-arg 2-arg versions etc and look at the disassembly of those <lloda>re: run-time compilation, what's the difference with writing a macro? do you have an example maybe <lloda>I see that you could compile each case on demand and keep a cache or something <lloda>instead of precompiling a big table that takes so long <civodul>"ra" reminds me of Guile's old array API :-) <lloda>civodul: that's where it comes from :D <wingo>lloda: yes you could compile on demand only the set of types that you are interested in. also at that point you have access to the value of e.g. the procedure being folded, so you might be able to do more transformative optimizations <wingo>it's not a configuration that i regularly test <wingo>considering that guile itself is only compiled with -O2 <civodul>speaking of which, how do you folks like auto-compilation? *wingo witholds opinion for the time being :) <civodul>(1) love it! (0) no opinion (-1) hate it <lloda>wingo: I'll go back to -O2 for regular work <wingo>survey results are currently n=1 :) <wingo>civodul: you should go ahead and say what you don't like about it :) <nly>is there a manual on writing manuals (maybe using guile) ? <civodul>wingo: wait, i didn't say i didn't like it! :-) <civodul>in a project i write a makefile that runs "guild compile" <civodul>and for code snippets, auto-compilation isn't useful to me, and it gets in the way <civodul>i have to put GUILE_AUTO_COMPILE=0 here and there, just so i don't see those messages <wingo>civodul: otoh i really like that warnings run by default with auto-compilation <wingo>very helpful to know ahead-of-time that i forgot to rename something <civodul>i think i've occasionally relied on auto-compilation, notably for warnings <civodul>but the costs outweigh these occasional benefits for me <civodul>because then there are also cache invalidation issues <civodul>like when you have an ABI break, you have to know that you "just" need to rm -rf ~/.cache <wingo>civodul: yeah i guess I don't have ABI concerns much, the cases in which i find autocompilation helpful don't have a lot of records etc <wingo>and the abi concerns are there for most distribution platforms that aren't guix :) <wingo>the abi concern is basically record layout, right? <wingo>i would be unhappy i think if guile's performance weren't predictable. if you have to fall back to an interpreter that's a definite hazard <wingo>with auto-compilation, at least you know users are running things compiled more or less well <wingo>without, i think performance problems can be a little hard to troubleshoot <wingo>we could do away with the cache but that would be terrible for startup time i think? <wingo>guile's compiler isn't optimized for low latencies as you know... <gjanssens>We've seen cache invalidation issues in the past with gnucash as well <gjanssens>But those were mostly in the transition period where gnucash decided to precompile its scheme sources and users had more recent caches of a previously installed (and autocompiled) gnucash <gjanssens>There are still occasional hiccups with autocompiled caches as users can have their own scheme sources loaded in gnucash which we obviously can't precompile <chrislck>meanwhile chris exploring #guix occasionally but thinks it's more difficult than syntax-case :) <civodul>wingo: yes the abi concern is mostly for records <civodul>perhaps we shouldn't have inlined those accessors in the first place, who knows <civodul>if auto-compilation didn't exist, we could simply emit a one-line warning, like "no compiled code for x.scm; using the interpreter" <civodul>then you know you should run "guild compile x.scm" <wingo>that doesn't necessarily solve the abi probs tho, right? <wingo>it's certainly possible to have an out-of-date manually-compiled file <civodul>no, that doesn't solve the abi problem in the general case <civodul>if you compile, you have to be aware of what an abi is <jcowan>Chicken requires you to use the compiler to visit all libraries, but not necessarily to compile them: "csc -J -P" generates *.import.scm files for each library defined in the input, plus syntax checking on the input. These import files must exist to import anything; they can be compiled or not, though it's not really expensive to use source unless your library uses heavy macros. <str1ngs>daviid: the make-instance-argument fix looks good. Also now some tests that previously failed are passing from returning functions. Looks like I can do some more porting to g-golf now. <codesections>This works. *However*, if I suspend the Guile repl with ^z, and run it in the background with `bg`, it stays "stopped" and no longer accepts commands through `nc` <codesections>So, my question is: is there any way to run Guile as a background process but still accepts commands from the port on which it's listening? <codesections>(I assume I must be missing something simple, since that would seem to be the main point of the `--listen` option and seems necessary for, e.g, Emacs integration) <nly>append a '&' to the guile command <jcowan>If you stop a process, it's not going to be able to respond to the socket or anything else. The trick is to start it in the background. <nly>^ and the explanation, sry i am having dinner <nly>jcowan, since you're here, i meant to ask you are you the person who wrote the lojban manual? <jcowan>"I am large, I contain multitudes." <codesections>@nly @jcowan thanks, but that doesn't seem to work. When I run `guile --listen &`, I am given a guile prompt but then immediately told that guile is stopped (the text `[1] stopped guile --listen` is printed to the console) <nly>ah yes, i didn't read your question properly, you had already tried that sorry <nly>i would just leave a shell open with guile in it? is that an option? <codesections>I guess? I was hoping to use a guile server to control my window manger and would kind of hate to leave an extra shell open. Though I guess I could <codesections>I still feel like I must be missing something simple, though. Clearly things like Geiser have a way to solve the issue <nly>i searched and see commands like 'nohup' 'disown' <nly>sorry, i am just guessing atm <str1ngs>codesections is your window manager written in guile? <codesections>No. I'm really just experimenting at the moment, but I'm using bspwm which is controlled through shell scripts. Since I'd rather code in a scheme, I thought I'd control it through some sort of scheme scripts instead <codesections>And I played around with a few options, but then I thought that the start-up time for various scheme interpreters is a bit long for that sort of thing and it would be nice if I could leave one running and listening <codesections>and `guile --listen` _seems_ like it'd be perfect for that <str1ngs>note these functions don't block so you will need to bock at the end of your script. also this is connectable via geiser with geiser-local-connect <str1ngs>you could loop with a call to poll-sever and a sleep to handle blocking. and forgo using a thread for poll-server <codesections>Interesting, thanks. I guess I was confused about that sort of functionality being built in with `--listen`? <str1ngs>actually just using poll-server will block and loop for you <str1ngs>I'm not sure what server --listen uses. I would use a coop server personally. guile --listen is really just there to provide a REPL from a command line it's not as flexible as the REPL I linked. <str1ngs>but then you would need to demonize this as well. in which case I advise just starting it in a tmux or screen session. which you can then attach detach from. that's the trivial approach <str1ngs>also this function deletes the socket file. with no sanity checking which might not be good for you use case. <manumanumanu>Ahoy friends! Reading the NEWS section for 2.9.4. Wow! 3.0 is going to be an amazing release <manumanumanu>civodul: regarding transients: They don't even have to be exported. They would still speed up procedures like vlist-map, where building a new vlist would become a lot faster, because we wouldn't have any intermediate results where we say we don't need it. <civodul>although vlist-map is probably not a good example, is it? <civodul>i mean in the end you have to allocate all these vectors <jcowan>you could say "setsid guile --listen </dev/null >/dev/null &" to disconnect Guile completely from the terminal. <manumanumanu>civodul: well this is embarrassing. I have misunderstood VLists. I thought they were in a similar vein to fectors/pvectors. Transients won't do much good at all! And now I understand why they are hard to get thread safe :D <manumanumanu>I don't know where I got that idea from. Sorry for bothering you.