<ozzloy>anyone here going to maker faire? <ArneBab_>wingo: Tools using Guile are already interfacing C with Scheme in complex ways. Remember the Lilypond breakage: That must not happen again. What you’re proposing sounds like a change in the *stated goal* for using C with Guile (I remember the reference manual actually stating reasons for the current way of doing it) <wingo>i feel like i'm being lectured here :P <ArneBab_>I got more conservative by the years (through seeing more and more breakage) <wingo>the reference manual also lauded our high-performance C interpreter <wingo>which was just stockholm syndrome :) <wingo>praise the thing we have because we have it, etc <ArneBab_>but replacing that text did not cause regressions (because everything got faster with your changes) <ArneBab_>“we have a high perf C interpreter” → “we have a higher perf Scheme interpreter” <ArneBab_>the problem I see is that we cannot know how people use Guile. <ArneBab_>asking here does not help — if companies use it, the employees might not even be allowed to tell <ArneBab_>which reminds me of an email I wanted to write to guile-user… <ArneBab_>and the manual says “better use prompts” <ArneBab_>wingo: what’s to gain by making call/cc faster? <ArneBab_>wingo: (essentially what I say *should* come down to: This is a change in policy which should be discussed with all stakeholders, also the ones who aren’t easy to reach) <wingo>adding the compiler certainly caused regressions :) <ArneBab_>(and stakeholders means here: Most people who use Guile — maybe approximated by writing something on the website, inviting all interested parties into the mailing list for discussion) <wingo>between breaking lilypond and having a faster guile, i think people have voted -- some people vote with 1.8 and most with 2.0 <wingo>anyway, you are right that i would need to find people that use continuations but there are many advantages. a topic for another day tho. <wingo>i think too often we fear change instead of evaluating options in an even-handed way <ArneBab_>ACTION feels like the old policy uncle ☺ <wingo>yeah i don't need one of those ;) <ArneBab_>would you have done the changes which hit LilyPond if you had known back then that 6 years later LilyPond would still be locked to Guile 1.8? <civodul>i think there's a paradox here: lily has a lot more direct users than Guile itself, and has/used to have more developers too <civodul>it's unclear to me how we reached the point that "upgrading" lily to 2.0 never happened <civodul>i know there are hard technical issues, and bugs, but still <ArneBab_>from what I gather (reading lots of mailing lists and such) is that they hit multiple roadblocks <ArneBab_>and at some point the frustration got so big that they did not want to go forward anymore <civodul>but if you look carefully, "they" is typically one person :-) <ArneBab_>and it seems that there were only few people actually working on the Lily-Guile interface <ArneBab_>similar to our situation where mostly wingo is working on the compiler <civodul>anyway i think it's clear to all of us that we don't want to gratuitously break everyone else's project <ArneBab_>My wish for Guile is to be a base for software which never breaks on an update. <ArneBab_>I know — the article actually says “almost never” <ArneBab_>but never breaking as a goal means that I actually stop and think about ways to avoid the breakage — even if they mean work for me. <ArneBab_>When I want software to never break, I know that I missed my goal when something breaks, so I will only do that if it is necessary to reach a much more important goal. <ArneBab_>essentially it’s this point: “this single line of code will probably save more people more time than most of the other lines in the project!” <wingo>of course. i think you are preaching to the choir arne <ArneBab_>considering how much effort went into making sure that 2.0 and 1.8 can be installed side-by-side, I think you’re right. <wingo>sorry to be a grouch, i just don't like the implication that i don't think about ways to avoid breakage :) <ArneBab_>I’m sorry for implicating that (I see I did…) ***peterbrett_work1 is now known as peterbrett_work
<wingo>ACTION grouses that `sleep' only accepts integers <wingo>clearly `sleep' should just accept a floating-point number <wingo>but, this time i just used usleep anyway ;) <civodul>bash is becoming a trendy compilation target :-) <wingo>ACTION has a shim working to allow non-blocking ports to be passed to blocking C port operations <wingo>civodul: just using poll is a great simplification :) <wingo>a read or write can return -1 to indicate EWOULDBLOCK <wingo>and in that case the ports code calls the ptob's "read_wait_fd" or "write_wait_fd" method <ArneBab_>civodul: it would be nice to have something which can compile bash to batch <wingo>which it can wait on synchronously or add to a poll set and do something else <wingo>the c code waits synchronously of course <wingo>i think i will be able to remove the input_waiting() ptob function but we'll see <ArneBab_>isn’t sleep defined in a RnRS? (I didn’t find it) <ArneBab_>if not, we could simply add float support… <wingo>we can add support for non-integers regardless :) <ArneBab_>where is sleep defined? (I only find the C-definition in lib/unistd.in.h) <ArneBab_>wingo: did you see my patch for -e '(module)'? <wingo>yes, haven't had cycles to work on it yet <wingo>there, now in the right channel ;) <wingo>which one can do concurrently with other activities! <wingo>i didn't really document that module, i dunno what our compatibility story for it is <wingo>civodul: feedback very welcome! <wingo>need to mention the incompatible-ish change that reading from a non-blocking port will no longer throw an error if it would block <wingo>i think it's probably ok but it is a slight change <civodul>i wonder if people tried to implement non-blocking i/o by catching 'system-error <civodul>so libguile keeps track of which ports have O_NONBLOCK? <wingo>i think it's almost impossible to do that <wingo>catching 'system-error i mean <wingo>tx! it doesn't do writing data yet tho ;) <wingo>guile doesn't keep track of which ports are blocking, no <wingo>maybe it should be it could get out of sync with the fd <wingo>you have to fcntl the file descriptor to make it nonblocking <civodul>the current-read-waiter/current-write-waiter thing looks like a nice API <civodul>wingo: so it just checks for EWOULDBLOCK on all fports, right? <wingo>the generic read/write routines just check for EWOULDBLOCK, assuming that blocking reads/writes don't produce them <wingo>s/generic/fports/ as you say <civodul>i think we need current-exception-waiter too, no? <civodul>since select(2) distinguishes between read/write/exceptions <wingo>you could be right of course <wingo>well i don't know. thing is, the waiter is called with an intention <wingo>(-> you call the current read waiter) <wingo>and then the events that you wait on for a read are POLLIN <wingo>but you also get POLLERR and all the rest <wingo>so the next time you loop and try to read(2) you should get the error because the fd is in an error state <wingo>and that would propagate the exception <wingo>there are not enough tests for non-blocking ports tho <civodul>but for a read+write port, which waiter would you call upon error? <wingo>you call the waiter before the poll <wingo>so if you are doing a read-char and it EWOULDBLOCK <wingo>then you call the read waiter <civodul>select/poll is left to the user or the scheduler <civodul>and that's where exceptions would be handled <wingo>so if the fd gets POLLERR in its revents <wingo>then the fd becomes readable <wingo>and the thread continues and tries a read again <civodul>right, but what to do upon POLLERR is the decision of the scheduler <wingo>at which point the exception comes from the second read <wingo>i will rebase ethreads in some side branch, removing the bit about eports and stuff <wingo>so it just adds ethreads, basically <wingo>can maybe be something paroneayea could use or something <wingo>more experimentation needed :) <civodul>not entirely sure what to think of this "subscriptions" thing <davexunit>I haven't fully grokked what makes "subscriptions" different from FRP <wingo>i find elm to be smarmy but maybe it's just really helpful and awesome ;) <davexunit>some real software engineering under the hood, but way oversold. <civodul>it's definitely hype and super PR it seems, combined with good ideas <davexunit>did you know that static typing could solve world hunger? <civodul>it's heavily-sold, don't know if it's oversold :-) <civodul>i mean it seems to be much better than pretty much everything else in this space <civodul>with the exception of hiphop maybe, Fulax? :-) <davexunit>yeah I guess, but that's also not saying much. <davexunit>and Elm is drastically changing with each new release <davexunit>they used to apply the PR machine to FRP, now they back off from it. <davexunit>how long until someone thinks that subscriptions aren't cool anymore? <paroneayea>wingo: cool! know of a nice way to ensure blocking reads and blocking writes while testing easily so I can see if 8sync is correctly integrating with this? :) <civodul>ACTION thinks davexunit is jealous of all the hype ;-) <civodul>davexunit: we need sly.org to tell the world how beautiful Sly is! :-) <davexunit>I still very much enjoy using Sly's FRP implementation. it's a nice way to model the top-level state of an interactive application, and several times I have been surprised at how easy it was to add/remove/modify something and have the effects propagate through the system. <davexunit>maybe it's part jealousy, but also part of anti-Haskell sentiments. <paroneayea>the main argument in the Elm "why we're changing" document seemed to be "FRP was hard for users to learn", but I don't find that super convincing <paroneayea>playing with Sly really forced me to rewire my brain, but I think that was a good experience <civodul>the new code seems to be hiding things under the carpet at first sight <davexunit>yeah, you can make the same argument that ML syntax is hard for users to learn. <paroneayea>I guess to answer my own question: just do a really large read/write operation will probably work :) <davexunit>I find ML syntax difficult because I'm not used to it. <davexunit>civodul: I was very happy to see that my game ran for you. until then I wasn't sure if it was a "works on my machine" thing. <civodul>davexunit: all i had to do was to follow the instructions on the web page, so i was happy too <civodul>now i'm waiting to run paroneayea's game ;-) <paroneayea>civodul: want me to turn it on again so you can connect? :) <paroneayea>ACTION is currently tethering on his phone until monday since he just moved, hence not having the server up <wingo>paroneayea: so yeah i don't know! (ice-9 sports) doesn't even do writing yet <wingo>and many of the other port operations aren't yet implemented on top of sports <wingo>and to really test it you will want to "install" sports <wingo>meaning (set! (@@ (guile) read-char) (@ (ice-9 sports) read-char)) <paroneayea>or better yet, use something like tintin++... but that's not packaged yet in guix :) <ArneBab_>davexunit: “I might argue that Elm was never about FRP.” ← at this point I might stop believing anything the author says until it’s at least 5 years old. <davexunit>I shouldn't hate on Elm so much, but I have an allergic reaction to so much marketting. <ArneBab_>I’m becoming somewhat conservative in my tech choices. Elm is a good example for the things which drive me to that. <ArneBab_>The good part is: That makes Guile and Emacs all the more attractive :) <civodul>sounds fun, reminds me of a game i played when i was a kid <wingo>tfw you look at your old code and see "cdar" <wingo>yay, ethreads working with ports <wingo>hard to remember how to use them though <daviid>(ice-9 sports), now, just using guile we'll going to be fit, no more gym boaring stuff :) <davexunit>I think it's an homage to the Huey Lewis and the News album <paroneayea>looking at slow-path and fast-path in read-char, and slow-path using call-with-values <paroneayea>you might remember that I found out that this was really slow <paroneayea>I wonder if that might make slow-path faster? :) <paroneayea>I have a suspicion that if you apply it you'll see a significant speedup in (ice-9 sports) :) <daviid>compiling master, what flag should I pass to get this fast guile-2.2 version? or is it the default? <wingo>in guix you can just guix package -i guile-next <wingo>probably you want to do rather "guix environment --ad-hoc guile-next" i guess <wingo>daviid: on debian testing i don't have to do anything in particular <daviid>wingo: oh no, terrible, I'm not using guix yet :( nobody's perfect haha <wingo>just install the build-deps for guile and then make <wingo>then ./autogen.sh && ./configure --prefix=/opt/guile-2.2 && make <daviid>wingo: ok I'm doing make. I was wondering if I shouls set something to 'O2' [iirc] to get a faster compiled guile-2.2 <wingo>if you build from a tarball it's much faster <wingo>if you don't have CFLAGS set <daviid>wingo: I wanted to check master, so I'll be patiet <wingo>more precisely the default is -g -O2 <daviid>yeah, make j4, just warming my room now :) <wingo>paroneayea: for some reason lists.gnu.org is not responding <wingo>i don't see call-with-values as being slow in my measurements but i could be missing something <wingo>in particular in that case it gets contified away