<paroneayea>above blogpost also reflects a bunch on the role and future of 8sync amidst all the exciting changes happening in the world of Guile async stuff right now :) ***Guest45015 is now known as mvdw
<daviid>hi paroneayea , congrat for the 8sync release! <paroneayea>hey daviid, you're welcome / thanks for noticing :) <paroneayea>the post was as much about getting a release out as it was reflecting on the thrilling new world of async stuff in guile <paroneayea>especially before a likely significant refactor as I explore the suspendable ports stuff ;) <paroneayea>wingo: there's a very small typo in the suspendable ports documentation... use-module instead of use-modules. Are you okay with me pushing a small documentation fix like that directly to master? <wingo>paroneayea: hey wdyt about moving the fluids and parameters documentation to api-control.texi, by dynamic-wind <wingo>seems to group "dynamic extent" things together in a way, dunno <wingo>fluids aren't really about control but they aren't really about scheduling either <wingo>(this is a change i was thinking of making, not that i was proposing that you make) <wingo>in racket, thread cells and parameters are documented in their "concurrency and parallelism" chapter <wingo>fluids aren't actually about thread-local storage, given that their values usually propagate to newly spawned threads <wingo>i think fluids/parameters are mostly about the environment in which we compute <paroneayea>I think having dynamic stuff together makes sense... it's useful for users to understand that there's an underlying shared conceptual model there for all those bits <wingo>having things like current-input-port be usable by random code, and bindable by random users, with useful defaults and without a preestablished lexical connection <paroneayea>I guess before I try overhauling 8sync to use the suspendable port stuff <paroneayea>I should do a more minimalist test... maybe a small irc bot just using suspendable ports. <wingo>istr this person was a noted troll of many language communities <wingo>that said, i enjoyed the piece ;) <paroneayea>I have unsubstantiated suspicions that maybe writing efficient functional code is more possible in a language that supports both functional and imperative code, because it's possible to write imperative code with a functional abstraction, instead of having to rely on the compiler doing the smart work? <paroneayea>but maybe that's also me being massively misinformed about pure functional languages <davexunit>I think it goes to show that software is complicated at a multi-paradigm approach is usually best. <wingo>i didn't mean that i agreed with it entirely <wingo>but i enjoyed it as a polemic :) <davexunit>I also find these arguments break down because people can't agree on what "pure" means <davexunit>at some point, whether you write your own primitives or the language implementation provides them for you, there's imperative code underneath it all. <paroneayea>if we can somehow mitigate quantum uncertainty and perceive our whole universe as a pure functional process, maybe we can make an argument that underneath it all it's all functional programming ;) <paroneayea>ACTION thinks of Sussman's ABSTRACTION BARRIER: DO NOT CROSS warning tape as a response to his troll <paroneayea>so I guess the proper way to remove a whole directory and all its children in Guile would be to use file-system-fold? <paroneayea>or I guess I could (system* "rm" "-rf" dirname) ;) <davexunit>paroneayea: yeah, see delete-file-recursively in (guix build utils) <davexunit>now snarf away, snarf away, snarf away, all! <paroneayea>something I've never been sure of as a convention <paroneayea>whether or not arguments like (lambda (foo?) (when foo? (bar))) <paroneayea>I guess probably the answer is "that's unspecified" <amz3`>hey paroneayea congrats for the release <amz3`>I got an idea right now! I would like but I don't know if I will have the gut to do it. I will port 8sync to suspendable ports on my side and see what we end up with... <wingo>paroneayea: pushed some doc changes, feedback welcome if you have it <paroneayea>wingo: hm, interesting... I get where you're going with the fluids and stdin / stderr but I had to think about it. it's a bit of a hop to a different mental abstraction <paroneayea>so maybe that's useful for forcing a bit more brain exercise, maybe not <wingo>stdin/stderr are the classic example of dynamic binding :) <wingo>if you haven't read that paper, it's worth it! in top 20 useful papers for me. <wingo>maybe it was just useful for me in the moment tho, looking at it again, maybe it's just a bunch of details :) <wingo>however this one is v approachable! <wingo>"delimited continuations in operating systems" <wingo>i confuse things tho, that one doesn't talk about dynamic bindings <wingo>so many oleg + ccshan papers :P <amz3`>it will cool to read that in the train anyway <paroneayea>wingo: I really need to get that cups-service running so I can "print on demand" ;) <paroneayea>ACTION actually procrastinates and prints from Morgan's computer <wingo>ludo said that you could install cups locally as a user and somehow the print dialog would handle it <wingo>that said, i just installed the cups service; worked for me <wingo>ACTION preps a prereleeeeeease <paroneayea>wingo: I think one thing we'll need to do before a real 2.2 release though is test some existing GOOPS programs, given the major rewrite from C->scheme you did <paroneayea>I know a number of people have found problems, davexunit and I included <paroneayea>which, excited to have a move of GOOPS to Guile :) <wingo>they can also be fixed post 2.2 tho, dunno <paroneayea>it also *fixes* a major issue I had with GOOPS previously <wingo>if it's an incompat with 2.0 that wasn't planned <paroneayea>which is that I couldn't do some delimited continuation stuff with some of the GOOPS procedures <paroneayea>I think it was getters/setters/accessors that broke it, but I don't remember. I switched to using slot-set! and friends <paroneayea>if we can get guile-gtk working I'm sure that would be a rather thorough test-case :) <daviid>paroneayea: guile-gnome works fine with 2.1.4 (devel branch), and make check pass. then grip-clutter is a good test (at least for me :) though I'm late to port gnu foliot, which wil be another good test as well <daviid>paroneayea: I have another wip project that combines guile-async2, guile-clutter (and goops of course) and that works fine with 2.1.4 as well <wingo>lol distcheck does -Werror; guile wraps readdir_64; it's deprecated; no distcheck :P <civodul>ah or this is due to discheck failing in the first place? <wingo>i think the goal of the "tarball" build is to run dist <wingo>anyway it starts with a git checkout, not a tarball <wingo>ah i thought i looked at tarball <paroneayea>well I guess the bugs davexunit and I found were filed in the tracker <wingo>civodul: yes but i thought that it wouldn't be included if the compiler didn't do c11 <wingo>last release we had the opposite problem :/ <wingo>you heard about that right? always using the fallback atomics impl, mutex-based :/ <paroneayea>not sure really if there's a nice way to avoid the problems described for tmpnam with making a directory <paroneayea>since I don't think I can do O_EXCL with making a directory with mkdir right? <paroneayea>I guess the chance of collision here is small, and it's just for tests <amz3`>you might create a file lock for the directory to avoid the race condition <paroneayea>amz3`: it's a race condition on creating the directory though, right? wouldn't creating the lock also be subject to the race condition? <amz3`>paroneayea: the lock is procted using O_EXCL like you said <wingo>i guess it's "./configure: line 36377: test: =: unary operator expected" <wingo>civodul: do you recall what the bourneism is for 'if test "$GCC" = yes;' <wingo>could be a gnulib problem; if test $ac_cv_have_decl_localtime_r = no; then doesn't look right <wingo>ACTION has a distcheck going fine of course <wingo>civodul: maybe their gcc -gnu11 doesn't do stdatomic (?) <civodul>wingo: i think the snippet above is fine Bourne shell <civodul>4.8 probably lacks most of c11, indeed <wingo>i thought if $foo = bar could produce the "unary operator expected" error if $foo was unset <wingo>but i think that's just a detail <civodul>you need double quotes around "$foo" <wingo>so configure.ac currently adds -std=gnu11 for all gcc <wingo>which obvs isn't the thing for 4.8 <wingo>not sure how to do that; the whole situation is a mess <wingo>you can't require c99 without downgrading your compiler to only-c99 :( <civodul>you could AC_COMPILE_IFELSE with that flag, or CHECK_HEADER([stdatomics.h]) maybe <ft>The first mantra of posix shell programming is to always double quote parameter expansions, unless you *know* you want the other effect. :) <ft>Btw. can I have an installation of a master build in parallel to stable-2.0 without creating a singularity that kills my neighbor's cat? <wingo>only conflict is actual "guile" binary and guile.info <wingo>but add a program-suffix and you're good i think <wingo>see "parallel installations" in the manual <ft>oh, there's a section in the manual? Nice. /me looks <ft>Looks easy enough. Let's give this a go. :) <wingo>ok, build running, will check with hydra in the morning. night :)