IRC channel logs

<paroneayea> http://dustycloud.org/tmp/mudsync-on-8sync-fibers.png 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) http://git.savannah.gnu.org/cgit/guile-cv.git/tree/cv/support/utils.scm?h=devel

<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>hi

<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>hmm

<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 https://wingolog.org/archives/2016/02/04/guile-compiler-tasks 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

<dsmith-work>heh

<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 dthompson.us. 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() ?)

<dsmith-work>Ooo. https://www.gnu.org/software/guile/manual/html_node/File-System.html#index-scm_005fsendfile

<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

<paroneayea>;)

<davexunit>paroneayea: not when 'guix pull' doesn't work. 'guix pull' is the achilles heel and it's frustrating