IRC channel logs


back to list of logs

<paroneayea> whew
<paroneayea>8sync-on-top-of-fibers finally working enough that my MUD works :)
<daviid>paroneayea: great!
<cmaloney>is there a way to take a list '(#f #t #t) and "and" the list (so it returns #f in this case)
<cmaloney>my google-fu is failing me
<daviid>cmaloney: no, you have to write your own and-l, since and is a macro ...
<daviid>cmaloney: there is one here if you want [line 109 -> 114)
<cmaloney>I found and-map, which does what I wanted it to do.
<cmaloney>Thank you. :)
<cmaloney>(and-map identity /list/)
<daviid>cmaloney: cool, but its not in guile manual, where did you find it?
<cmaloney>I found it in the racket stack overflow pages
<manumanumanu>dsmith-work: thanks. I just wondered if there was anything specific
<manumanumanu>cmaloney: srfi-1 has every.
<manumanumanu>cmaloney: (every values '(#t #t #f))
<manumanumanu>which is the schemey version of racket's and-map
<manumanumanu>but hey, guile has and-map it seems :)
<manumanumanu>if you are trying to write portable code, you should probably just rely on srfi-1 and cond-expand IMHO
<manumanumanu>or implement it yourself. it is like a 4 line function :)
***rubdos_ is now known as rubdos
<cmaloney>manumanumanu: Thank you.
<ijp>wingo: are you around, I want to pick your brain about something
<wingo>sorta around
<wingo>what's up?
<ijp>basically, I was wondering what thought had been given to static linking in guile, and if so, how it could translate to my guile-js
<wingo>only some partial thought. i don't see the whole solution
<wingo>at least in my head i mean
<ijp>right now, for testing, I've been essentially building a small map in the file when I test it, and that maps module paths to the compiled unit
<wingo>makes sense
<wingo>i think as far as i got was on the "linking multiple modules together"
<ijp>I feel like, in principle, we can usually statically determine this
<ijp>most people are using define-module, and so it should be possible at compilation (macro expansion) time to embed some information about what is required
<wingo>yes i think you're right, but there is the danger that we might change guile's semantics if we made a core change
<wingo>i mean, that might be a good thing of course :) but it's a tricky area to work in
<ijp>right, I don't think this is a part of guile I really want to be touching right now
<ijp>I wonder what the "reasonable first step" is for me, then.
<ijp>paroneayea: thoughts?
<ijp>I could formalise the "manually build the map" I've already been doing, with the understanding that we would move to a solution more like what is described in the blog post once I have a better understanding of the linking process
***bgardner_ is now known as bgardner
<ijp>essentially, a small file that includes all the files you want bundled, plus which guile builtin modules it depends on (not a full dependency tree, the tool would recursively include those)
<ijp>nothing too fancy (main "foo.js" (depends ((foo bar) "foo/bar.js") ((srfi srfi-1)) ...))
<dsmith-work>ijp: Sounds like a linker
<ijp>it is a linker
<ijp>it's just a really bad one
<paroneayea>ijp: so when a user compiles a Guile program -> JS, it includes everything they need for that Guile program?
<paroneayea>a somewhat or even really bad linker is ok, this could always be refactored later right?
<ijp>right now, when you do guild compile foo.scm --to=javascript, you get a file that just represents that module, as you would expect from a .go
<ijp>so afterwards you would need to link it
<paroneayea>ijp: so this would be one big recursively built js file?
<paroneayea>it seems fine for now, maybe even in the future we'd have better ways to distribute javascript with programs where they can be linked together dynamically without it being a nightmare, but I agree that for the moment this is probably what people want
<paroneayea>ijp: my view is you should do the thing you think is reasonably cleanest that you can get going with. in the future if a better way becomes clear, that can be refactored
<ijp>the two issues are: 1. Can I infer the dependencies, and 2. If not, and I infer the pathnames for linking
<paroneayea>ijp: I guess anyone who uses (@@ (foo) bar) is pointing a shotgun footward too, huh? :)
<ijp>indeed, but they knew that at the time
<davexunit>I use @@ sometimes for what I consider to be a legitimate reason
<davexunit>in order to use private APIs from another module in the same project. that way the private API is never exposed to users.
<paroneayea>yeah I find @@ is useful for when you either have a) cycles that are really hard to work around or b) need to use something that really shouldn't-be-exposed-normally, eg in testing
<paroneayea>but I know it's a foot-gun :)
<paroneayea>ijp: anyway your plan seems like a good direction to explore. Go for it!
<ijp>davexunit: I haven't done it in a while, but I always bundled those in (project private submodule)
<paroneayea>ijp: that's still a lot of work for unit tests I feel like
<paroneayea>ACTION shrugs though
<paroneayea>"unit tests aren't real world code" anyway
<wingo>ijp: if you want advice, for me it's "be just as dynamic as guile" -- e.g. implement the caching module variable lookups etc for top-level and cross-module references
<wingo>guile is not so nice here but that's probably the path of least friction -- there are optimizations possible but for me they would be more appropriate as a next step
<ijp>I'm not sure I can be "as dynamic as guile" in the guile-js context
<ijp>or maybe I just misunderstand you
<ijp>all I'm really thinking about is deployment, and what work it is reasonable to expect a user to do w.r.t. dependencies
<ijp>is there a template for things that go in (scripts *) ?
<ijp>do we have a procedure to copy from another port?
<paroneayea>ijp: hm, I don't know of one... I've just read bytevectors in chunks from one port to another
<anon9002>davexunit: It seems you forgot to renew your SSL certificate on It's been expired for almost 2 months now.
<davexunit>anon9002: yes I know
<davexunit>unfortunately my certs cannot be renewed anymore for some reason
<paroneayea>davexunit: D:
<paroneayea>on Let's Encrypt?
<dsmith-work>ijp: Is one port a file and the other a socket? (as in, can you use sendfile() ?)
<rekado_>davexunit: can’t you just remove /etc/letsencrypt and start over?
<ijp>dsmith-work: sendfile might work for me, thanks
<paroneayea>dsmith-work: ijp: one caveat is that I think sendfile doesn't work with (ice-9 suspendable-ports), if you intend the code to work with that later
<paroneayea>or at least, doesn't right now
<davexunit>paroneayea: yeah, maybe my client is too old
<davexunit>but my guix is hopelessly out of date
<davexunit>and I cannot update
<davexunit>I have to start from scratch
<paroneayea>davexunit: oh, maybe you have the issues rekado_ and I did
<paroneayea>I wrote something to the mailing list a while ago
<davexunit>oh I haven't been paying attention
<paroneayea>davexunit: Hey wait! I thought guix was the land of fearless upgrades! :)
<davexunit>I should do a search when I have a chance
<davexunit>paroneayea: not when 'guix pull' doesn't work. 'guix pull' is the achilles heel and it's frustrating
<paroneayea>ah yes
<davexunit>ACTION goes afk, will read backlog later
<paroneayea>davexunit: I don't use guix pull btw, I do guix-from-git only
<paroneayea>that's clearly not what we recommend
<paroneayea>and it isn't something we should expect of people