IRC channel logs


back to list of logs

<adhoc>afternoon all
<adhoc>what does guiles support look like on arm ?
<adhoc>i'd like to downsize a bunch of old kit and looking at a few raspberry pi's
***johnp is now known as johnp`
<janneke>ACTION is amazed how far you can get with a broken implementation of OR that evaluates certain expressions more than once
<webshinra>a probable next step on my guile c++ wrapper
<webshinra>will be to handle an oo version of vector
<webshinra>janneke: well, you can go as far as you wish as side-effect can ever be handeled separatly
<adhoc>webshinra: have you looked at D too?
<adhoc>or any other languages like Rust?
<webshinra>D suck, rust is very interesting, why ?
<janneke>webshinra: right...
<janneke>side-effects evil
<roelj>How can I specify the 'content-type' in the http-post function in (web http)?
<roelj>I tried #:headers '((Content-Type . "application/json")), but that adds two Content-Type lines to the header, one with plain/text and one with application/json.
<roelj>Apparently, using lowercase 'content-type' does the trick.
<janneke>roelj: good for you...that darn shift key, who invented it? ;-)
<spk121>ACTION gives up on fixing Guile's primitive-fork on Cygwin and Msys
<random-nick>spk121: is there a way to fork on windows without cygwin?
<daviid>spk121: that's too bad! so, is this impossible then? and what about people saying threading is not working on Win?
<spk121>daviid: threading, but not forking, works for me on Cygwin and Mingw with a patchset i haven't pushed yet.
<daviid>spk121: good news!
<spk121>random-nick: I was stupid enough to try to make my own fork. A fool's errand. I understand now why Cygwin's fork is so complicated.
<janneke>spk121: have you looked at glib?
<janneke>ACTION has used g_spawn_sync for LilyPond's mingw port
<spk121>janneke: I think making Guile work on Cygwin with threads but without fork is good enough for my purposes.
<spk121>janneke: but I'll check out at g_spawn_sync
<janneke>for an example, if that helps
<spk121>janneke: thanks!
<taylan>what's the right way to add a feature to cond-expand? I can't seem to get cond-expand-provide to work correctly. I defined a helper module in which I do (cond-expand-provide (current-module) (list 'foo)) and then import that module, but still don't get foo
<taylan>hm, works in the repl, maybe I did something else wrong...
<amz3`>opendht seems a good candidate for guile bindings
<amz3`>AFAIU it's the project that powers GNU Ring
<amz3`>funny stuff, if you ddh "gnu ring" the first result is a microsoft app store
<random-nick>I thought ddg marked sites as official
<amz3`>indeed, the "box" displays the offocial website
<amz3`>indeed, the "box" displays the offocial website
***random-nick is now known as Guest87807
***random-nickname is now known as random-nick
<marusich>I see the phrases "dynamic extent," "dynamic scope," and "dynamic state" used in various places in the manual. Are these intended to mean the same thing?
<marusich>Also, "dynwind context"
<random-nick>no, dynamic state has to do with fluids
<random-nick>iirc in the manual dynamic scope is used as another name for dynamic binding
<marusich>OK. I can see how "dynamic state" refers to an actual object type, since it has getters and the like.
<marusich>It just isn't clear to me if the others - "dynamic extent," "dynamic scope," "dynwind context" - are just meant to refer to the same thing, or if they are actually distinct terms with their own definition.
<marusich>A specific example is in the documentation for parameterize: "Establish a new dynamic scope with the given PARAMs bound to new locations and set to the given VALUEs."
<marusich>Here, is "dynamic scope" being used descriptively (i.e., to roughly convey an idea), or is it referring to a precisely defined notion of "dynamic scope"?
<amz3`>marusich: I don't understand that part either
<random-nick>marusich: basically, there dynamic scope in the implementation of parameters means dynamic state
<random-nick>marusich: but generally dynamic scope is the scope in a dynamic binding system
<random-nick>a dynamically bound variable's value is determined in the dynamic scope, not the lexical scope like normal variables in scheme
<random-nick>s/determined in/looked up in
<random-nick>for dynamic extent vs dynwind context, I'm not sure
<random-nick>as far as I understand, a dynwind context is a dynamic extent with a dynamic wind?
<random-nick>the manual should be a little clearer about that terminology
<marusich>OK. That basically makes sense to me.
<marusich>I still feel like "dynamic extent" is not clearly defined in the sense that a "dynamic state" is (i.e., a "dynamic state" is clearly a usable abstraction, with getters etc., while a "dynamic extent" is apparently something vaguer)
<random-nick>yes, dynamic extent is not really a value
<marusich>But I get the idea, espcially after you mentioned the difference between "dynamic scope" and "lexical scope".
<marusich>Thank you for the explanation.
<random-nick>I think the term dynamic extent exists only to describe the concept of a dynamic wind
<marusich>Speaking of which, do you have any idea why the term "wind" is used there?
<marusich>It brings to my mind the image of winding a crank, as if to move us one level lower on an elevator or something.
<marusich>Is that the idea?
<random-nick>I do not know
<marusich>Well, at least we know it's not supposed to be wind, as in the atmospheric phenomenon :)
<random-nick>marusich: pretty sure slyfox is right, it has to do something with unwinding and rewinding a stack