<daviid>paroneayea: I feel sorry to hear you're somehow stuck :( <paroneayea>I managed to figure out a kludge to make it through <paroneayea>daviid: so less dire than when I last spoke in here :) <daviid>paroneayea: oh, great! then you'll make it with your deadline ... <daviid>ACTION just released GNU Guile-CV 0.1.6 <adhoc>i wonder if you can use the CV library to look at the ouput of SDR to auto-tune <rekado>artyom-poptsov1: I’m having weird problems with Guile SSH on a couple of nodes; inside node-eval “(getenv "GUILE_LOAD_PATH")” returns #F, but with a plain remote Guile process, the load path is correct. <rekado>this is fine: ssh hydra@192.168.0.7 guile -c "'(display (getenv \\"GUILE_LOAD_PATH\\"))'" <rekado>artyom-poptsov1: ah, never mind: the problem was that an old guile process was lying around from before the changes to /etc/environment. <rekado>that almost drove me crazy for a couple of days :) <manumanumanu>I reinstalled my system recently, and guile doesn't remember previous repl sessions <ft>manumanumanu: load the readline module in ~/.guile <ft>(use-modules (ice-9 readline)) (activate-readline) <manumanumanu>I already have it, but it doesn't save history between sessions <ft>Then I don't know. That's all I have configured wrt readline and it happily fills ~/.guile_history <ft>You sure you also have the (activate-readline) call? <ft>Sure. Great you found it! <manumanumanu>I know why even. I started guile as root in a sudo shell, so i started guile as root, but with my users home directory ***do is now known as w1gz
<ijp>wingo: I'm a little confused about the 'module-box' vm opcode & how it works with 'equal?' <ijp>after the module system is booted by a call to set-current-module in boot-9.scm, the definition of resolve-module is (define (resolve-module name . args) (if (equal? name '(guile)) the-root-module (error ...)) <ijp>AFAICT, that call to equal? must use a module-box, and so module-box should call public/private_lookup on the variable, which eventually should call resolve-module <ijp>the only way this would not infinite loop, is if (SCM_UNLIKELY (!SCM_VARIABLEP (var))) fails, right? <ijp>(that condition is in "module-box") <wingo>i think the way this works is that when you compile boot-9.scm, the current module is (guile) <wingo>so the reference to equal? gets compiled to toplevel-box <wingo>right? maybe i am forgetting how this works <ijp>that is what I had expected <wingo>toplevel-box uses a module that was captured when the outermost top-level procedure was defined <wingo>which was captured just by doing (current-module) and writing that to a box <wingo>so there's no resolve-module going on for the "equal?" reference in resolve-module <ijp>I thought this is how it should work, but I ended up in a loop on friday when I reimplemented some of the module primitives <ijp>currently I'm special casing equal? because it's the only problem I have with this behaviour, but I would like to figure out why I'm getting a module box rather than a toplevel box <ijp>wingo: this might be related to my read-and-compile issue from before <wingo>could be, yeah; i think the current scheme compilation pipeline will individually expand expressions to tree-il then "join" those expressions; i.e. not expanding the whole file as a toplevel sequence <wingo>the choice of whether to make a toplevel-box or a module-box is from tree-il's toplevel-ref / module-ref <wingo>which is a choice made by the expander: what module the expander thinks is current when it sees a reference <wingo>vs the module that's associated with that reference (syntax object) <wingo>if they are the same, then toplevel ref; otherwise module ref <wingo>this part of guile could be lots better :P <ijp>I guess I should just keep the special case, along with a comment explaining it, for now <dustyweb>bavier`: yeah, that's the basis for CHAMP based hashmaps, which I had mentioned in an email a bit ago to the guile mailing list <dustyweb>the author of the clojurescript implementation of the CHAMP hashes said they'd be okay with us doing a direct port of their implementation and licensing under the LGPL for Guile <ijp>if someone reminds me nearer christmas, I can do it <ArneBab>mostly well, a bit more worry right now since I’m looking for a job after the post-doc <cmaloney>What is this nick change I can't even ... *boom* <dustyweb>yeah I'm not sure if I should switch or not <dustyweb>I've had paroneayea for a long time on here <dustyweb>cwebber is taken by the other Chris Webber <cmaloney>I used to be snap-l for the longest time <cmaloney>until I realized that the name had 0 meaning anymore <cmaloney>was a nick that I chose in a hurry when I connected to efnet on #rgvc <cmaloney>and was chosen because I drank a lot of snapple on trips <dustyweb>paroneayea is a username I had because terrible MUD username I chose when I was 14? <cmaloney>well, your site is dustyweb, so the mapping is still there <cmaloney>so, whole namespace available to you. ;) <dustyweb>I think I need to set up the websocket server to do a keep alive ping <davexunit>at aws summit nyc, not a single guile talk. what gives!? ;) <davexunit>(I don't have time to do a deep dive on your code, but I appreciate the effort you've put in) <manumanumanu>davexunit: the loops are as fast as hand-rolled named lets <ArneBab>manumanumanu: I looked at the docs and they look pretty good. You could export them as texinfo to fit typical style. I can see whether I can whip up a Makefile which automates that. <manumanumanu>except for for/vector which, unless you specify #:length x will grow the vector until the looping is done <ArneBab>manumanumanu: regarding for/list, I think a typical API would rather give the pure version as default and then add a for/list/destructive <manumanumanu>davexunit: i did a pretty deep dive into continuations and loops. Doing a non-tail-recursive cons is not an option. The cost of restoring those continuations is simply too big. <manumanumanu>ArneBab: yeah, that was one of the things I have been thinking about <ArneBab>I think for/list! would be the way to go <ArneBab>manumanumanu: but before saying anything else: congratulations! <davexunit>but you're the one that did the work so I'll take your word for it :) <manumanumanu>Try making a generator that yields the values from a map, you'll see. <manumanumanu>it will be excrutiatingly slow after a couple of thousand iterations <manumanumanu>That's how I tried it. I started a guile-implementation of srfi-whatever (121? the generator one) <ArneBab>manumanumanu: I think for/list! would be right. filter! also returns the results but allows itself to mutate what it gets. <davexunit>I don't understand what generators have to do with not using reverse! <davexunit>the reason to use reverse! is that guile 2.2 does not penalize recursion <davexunit>perhaps I misled you with the continuation safety thing <manumanumanu>davexunit: your suggestion in the reddit thread was to work like map <manumanumanu>but that gets very slow when restoring very long continuations <davexunit>continuation safety is just a minor consideration <davexunit>the main thing is that guile doesn't penalize recursion <davexunit>we're miscommunicating and I can't resolve that right now <manumanumanu>all right. no problem. however: I tested. using a non-tail-recursive cons will penalize jumping in and out with continuations. <ArneBab>manumanumanu: for/list/parallel would have saved me some time a few months ago :) <davexunit>I'm concerned with memory usage and general performance <ArneBab>manumanumanu: is there a way to make for/list/parallel use a thread pool? <davexunit>I shouldn't have mentioned continuation safety, it's irrelevant. <davexunit>I was just looking for additional benefits of a recursive implementation <ArneBab>nice! I like tools which do the right thing *by default* :) <manumanumanu>davexunit: no man, it is a valid concern. However, a tail recursive loop that does a non-destructive reverse at the end will have a lot better performance if you are jumping in and out with continuations. <davexunit>that article explains everything. do with it what you will. <manumanumanu>davexunit: yes, what I have been trying to say is that that seems to be pretty slow when jumping in and out of the recursive function using continuations (delimited or otherwise). I did some testing to find the best approach after the reddit thread, and using an accumulator was MUCH faster than a recursive cons-loop <manumanumanu>the loops are done, apart from some small decision on how to work with user-specified sequence types. as of right now, they don't work at all <amz3>manumanumanu: don't wait (a lot of) reaction/feedback from guile community, post a message to the mailing list and move on <amz3>which happens to be true for any community I know about <amz3>getting into another one project is hard, so feedback is rare <manumanumanu>this migt be my chance to learn how to use mailing lists :) <manumanumanu>ArneBab: I am not sure about the for/list for/list! distinction. for/list is not doing a linear update on any "user-facing" data, but only on the internal accumulator. That is exactly how guile's map-function ran prior to 2.2. <manumanumanu>ArneBab: and it matters only in the case of multi-shot continuations, and that is a rather special use-case <manumanumanu>doing a reverse! will be faster and use less memory, and is what most people should use <manumanumanu>I was about to do what guile 2.2 does for it's map implementation, because that is about as fast as doing a reverse! and is multi-shot continuation safe, but I did some tests, and it is pretty damn slow when jumpin in and out using prompts or call/cc <data_hope>is there a unit test runner for guile that you can recommend? <manumanumanu>data_hope: not sure whether it suits you, but there is srfi-64 <daviid>data_hope: there is one in guile-lib as well <ijp>the end is so close I can taste it (99%) <ijp>that's (module-use! the-scm-module (resolve-interface '(srfi srfi-4))) for those of you playing along at home