IRC channel logs


back to list of logs

<daviid>paroneayea: I feel sorry to hear you're somehow stuck :(
<paroneayea>well! since I said all that
<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 ...
<paroneayea>yeah I think so
<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@ guile -c "'(display (getenv \\"GUILE_LOAD_PATH\\"))'"
<artyom-poptsov1>rekado: Hi! Okay, I'll check it the next few days.
<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 :)
<artyom-poptsov1>rekado: :-)
<manumanumanu>I reinstalled my system recently, and guile doesn't remember previous repl sessions
<manumanumanu>Is there any way I can activate that?
<ft>manumanumanu: load the readline module in ~/.guile
<manumanumanu>it is already loaded
<ft>(use-modules (ice-9 readline)) (activate-readline)
<manumanumanu>I already have it, but it doesn't save history between sessions
<manumanumanu>i have history within a session
<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?
<manumanumanu>my .guile_history is owned by root
<manumanumanu>that's why
<manumanumanu>for pointing me in the right direction
<ft>Sure. Great you found it!
<manumanumanu>now it works
<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
<dsmith-work>Monday Greetings, Guilers
<paroneayea>wingo: bonk, back at you
<wingo>lgtm then!
<paroneayea>wingo: woo, merging
***do is now known as w1gz
<cmaloney>Good AM
<ijp>wingo: I'm a little confused about the 'module-box' vm opcode & how it works with 'equal?'
<wingo>how do you mean?
<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
<bavier`>looks like fun reading:
<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
<bavier`>dustyweb: cool!
<ijp>ACTION downloads
<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>dustyweb: nice!
<dustyweb>heya ArneBab
<dustyweb>how goes
<ArneBab>mostly well, a bit more worry right now since I’m looking for a job after the post-doc
<ArneBab>how about you?
<dustyweb>I'm ok
<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>but is it perhaps a bit silly?
<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
<cmaloney>(iced tea).
<dustyweb>paroneayea is a username I had because terrible MUD username I chose when I was 14?
<cmaloney>I don't drink the stuff anymore
<holomorph>dustyweb: as good a reason as any!
<cmaloney>well, your site is dustyweb, so the mapping is still there
<dustyweb>well, my site is :)
<dustyweb>not quite dustyweb
<dustyweb>but close
<cmaloney>Should register dustyweb as well. ;)
<dustyweb>but a more recognizable connection
<cmaloney> is available. ;)
<cmaloney>as is
<cmaloney>and appears to be squatted
<cmaloney>so, whole namespace available to you. ;)
<cmaloney>just call me the enabler.
<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!? ;)
<manumanumanu>I could really need some feedback for if anyone is interested. They are done now.
<manumanumanu>and work pretty darn well, at least on 2.2.
<davexunit>any benchmarks? bytecode analysis?
<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.
<ArneBab>(later today)
<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.
<ArneBab>or rather: for/list!
<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>hm, maybe …
<ArneBab>not that sure anymore :)
<davexunit>manumanumanu: okay
<davexunit>I'm a little skeptical of that claim
<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>davexunit: They have the same problem in racket.
<manumanumanu>Try making a generator that yields the values from a map, you'll see.
<davexunit>what do generators have to do with this?
<manumanumanu>it will be excrutiatingly slow after a couple of thousand iterations
<manumanumanu>well, implement a generator with continuations :)
<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!
<ArneBab> ← list!
<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
<manumanumanu>let me show you
<davexunit>the main thing is that guile doesn't penalize recursion
<davexunit>no time, sorry
<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 not concerned with continuations
<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?
<ArneBab>or does it already do?
<manumanumanu>ArneBab: it does already
<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* :)
<davexunit>see this article from wingo
<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>we continue to talk past each other.
<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>but that is a digression
<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
<manumanumanu>amz3: I know that.
<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