<paroneayea>8sync-on-top-of-fibers finally working enough that my MUD works :) <cmaloney>is there a way to take a list '(#f #t #t) and "and" the list (so it returns #f in this case) <daviid>cmaloney: no, you have to write your own and-l, since and is a macro ... <cmaloney>I found and-map, which does what I wanted it to do. <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>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
<ijp>wingo: are you around, I want to pick your brain about something <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 <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 <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)) ...)) <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>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 <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 dthompson.us. It's been expired for almost 2 months now. <davexunit>unfortunately my certs cannot be renewed anymore for some reason <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 <davexunit>paroneayea: yeah, maybe my client is too old <paroneayea>davexunit: oh, maybe you have the issues rekado_ and I did <paroneayea>I wrote something to the mailing list a while ago <paroneayea>davexunit: Hey wait! I thought guix was the land of fearless upgrades! :) <davexunit>paroneayea: not when 'guix pull' doesn't work. 'guix pull' is the achilles heel and it's frustrating <paroneayea>davexunit: I don't use guix pull btw, I do guix-from-git only <paroneayea>and it isn't something we should expect of people