***karswell` is now known as karswell
<wingo>ACTION pushed wip-port-refactor to master <wingo>hehe i deserve none of the credit ;) <janneke>sure, what do you ever for guile and ports ;) <paroneayea>ACTION in the middle of a move, but the movers are moving the heavy stuff we can't, so I'm babysitting anxious pets <paroneayea>catching up on email, lots of cool stuff on guix-devel lately <wingo>i am a dude in need of opinions <wingo>perhaps this chat channel can provide them <wingo>in guile we have read functions for ports <wingo>they return the number of bytes that were read <wingo>it can be zero. if it's zero that means EOF <wingo>i want to add support to nonblocking i/o <wingo>so there is a case where a read could return zero but it's not EOF, it indicates that guile should poll on that fd for readability <wingo>currently the return value of the read function is size_t <wingo>how do i add support for zero-bytes-but-not-eof <wingo>a complication is that the same solution should apply to write functions, where the natural way to indicate that the write would block would be to return zero from the write function <wingo>some options: change return type of read and write functions to ssize_t, and a return of -1 indicates EGAIN <wingo>keep as size_t, and (size_t) -1 means EAGAIN <wingo>keep as size_t, and (size_t) -1 means EOF <davexunit>'(size_t) -1 means EWOULDBLOCK' seems like it would be the least intrusive <wingo>the API and ABI are changing anyway <wingo>we can choose whatever we want <wingo>in that that might be the nicest solution; dunno tho <davexunit>and changing the return type to a signed integer <wingo>there's also the question of how to map this to scheme; read/write functions can be scheme procedures, in master <wingo>so they could return a number of bytes, or #f or some other constant to indicate EWOULDBLOCK <wingo>and likewise calls to read functions from scheme could translate (size_t)-1 return values to #f or something <davexunit>a non-numeric object on the Scheme side sounds good <wingo>i am pretty sure EWOULDBLOCK is the only non-numeric value you would want fwiw <wingo>other values are errors and should throw exceptions <wingo>other values meaning other errno values <wingo>tricky to get all this right <davexunit>since 0 is "I tried to read but hit the end of the road" <wingo>vs "I tried to read but someone gave me a beer, ask me later" ;-) <davexunit>could a single call to 'read' ever return (size_t) -1 bytes? <davexunit>(I don't actually know what that cast evaluates to) <wingo>size_t is pretty irritating, yeah :/ <wingo>size_t in practice is at least the size of a pointer <wingo>so (size_t)-1 is the size of the address space <davexunit>right. so that values works just fine, then. <wingo>heh, read actually returns an ssize_t <wingo>in the positive direction anyway <davexunit>so I guess it *is* possible that 'read' could read (ssize_t) -1 bytes? <wingo>yes but that indicates an error <wingo>unix is trash sometimes but i like read and write, they are well done <wingo>ah in guile it's a size_t now but things can change, this is after the port refactor <wingo>ACTION dinner, back in a bit <ArneBab_>wingo: does the change in API mean that it could break existing programs? <ArneBab_>wingo: and could it be done without that (i.e. by adding a keyword parameter like #:nonblocking #t?) <wingo>ArneBab_: this is in 2.2, see NEWS in master <wingo>i am doing my best, basically :) <wingo>this particular bit is part of port internals -- very few people have implemented ports on that level <wingo>there are some and if they've used the C port API to define a new port type, they will need to adapt their code to keep it working with the new version <wingo>but C and Scheme port users shouldn't have to change anything <wingo>i haven't done any of the nonblocking bits <paroneayea>wingo: I'm very excited to see this moving forward <wingo>feels close to a point where people can implement green threads as a library <wingo>(green threads that block on i/o i mean) <davexunit>ACTION thinks about applying this to his game engine <davexunit>non-blocking I/O could be used for loading assets in the background while the game runs, I suppose. <random-nick>wingo: you said soft ports are embarrassing, are they going away? <wingo>davexunit: why not real threads? <davexunit>wingo: dunno! just thinking out loud. real threads are a possibility, too! <wingo>davexunit: i/o to local files will never be nonblocking without a thread pool fwiw <wingo>you can set a local fd to be O_NONBLOCK <wingo>but it will always poll as readable/writable <wingo>non-blocking i/o is only good for sockets and pipes and things like that <davexunit>one reason I like to do so much in the main thread is because of OpenGL <wingo>libuv for example has a threadpool for dealing with local files <davexunit>you need to do all your GL calls in the thread that has the "context" <davexunit>maybe Sly should have a dedicated rendering thread some day. <davexunit>but for now the main thread works just fine. lots more important things to do before that. <ArneBab_>wingo: given that I’ll be working at the institute at least the next 18 months: Is there a way to fund work on Guile? <davexunit>(the thing that generates the scene to be rendered happens way more than once per frame :X) <wingo>ArneBab_: a good question! i am not sure. what do you think? <wingo>to me funding hackers to work on guile is really helpful, working on bugs and stuff is a good start -- they don't need to be existing maintainers <ArneBab_>are there people who would be open to take money? <wingo>i feel like the limiting factor for me at least and maybe mark and ludo (though i obviously don't speak for them) is time <wingo>so an obvious way to improve that would be to improve the base of contributors that can usefully work on maintenance <wingo>i don't know how to do that though! i have not been in a mode recently where i help other people do things in guile <paroneayea>ArneBab_: I think paying people to do bug wrangling type maintainership is a good idea <wingo>it's been more a place for me to work on things i am interested in, b/c my other work is mostly helping other people do things i sometimes feel i need to run away to my hackplace -- but that's not a good pattern :) <paroneayea>ArneBab_: I'm hire'able in that area btw ;) (but I'm not sure if I'm the best fit since my compiler experience is so low) <wingo>it would be excellent to have paroneayea working on guile for a while!!! <ArneBab_>I cannot offer enough money to actually hire someone. But I’d like to give something around 5-10€ per month for Guile work. <wingo>if we were to ever figure this out, perhaps 'guix europe' could be a useful intermediary <wingo>the french non-profit that ludo et al set up <wingo>we would have to figure out what could be done with what amount of money. if someone did professional work on guile they would need a living wage and it would take a lot of contributors to manage that <wingo>i vote for 10-day weeks with 5-day weekends ;-) <ArneBab_>there might be self-employed people who could do intermediate paid development — like working for a few weeks full-time to implement a given feature <wingo>are there already features out there like that? <ArneBab_>wingo: I know bountysource, which I stopped opposing when they added salt (regular payment which would allow transitioning to regular payments when enough supporters join in) <ArneBab_>wingo: and there’s the free software conservancy <ArneBab_>an example for such a feature could be: build a solution to publish Guile programs (like Sly games) to all major platforms. <wingo>that sounds like a guix bounty, in a way ;-) <wingo>in many ways it seems to me that guix is more fundable than guile <davexunit>I would like to see some of the things in wingo's compiler todo list worked on <davexunit>all those linker hacks, unboxed struct fields, etc. <wingo>for those i think they would make good internship / gsoc-type hacks <wingo>can be a good stepping stone for a compilers hacker to another job, can be a good recruiting tool too, which makes it easier to find funding <wingo>has some interesting details about unix that i didn't know <ArneBab_>so currently the first step would be donating to Guix? <wingo>ArneBab_: guix can receive donations! first step though would be agreeing on what the donations would be for, agreeing with guix europe, etc <ArneBab_>I mostly want to support Guile and leave the decision what is useful to those who currently do the main development <ArneBab_>…or rather: I want devs who are paid by users so they can invest work into supporting the users without fearing that this threatens their income <wingo>ACTION wonders how much to think about windows when thinking about nonblocking io <ArneBab_>if we want to be able to publish programs built with guile to be used by Windows users, that’s likely a necessary evil <ArneBab_>random-nick: it is certainly possible to create hurd bindings for Guile <ArneBab_>shouldn’t even be too complex (though it would require some work) <ArneBab_>I once contributed a bit to Python bindings for the Hurd, and if you choose the high-level interfaces, it shouldn’t be too hard to enable, for example, hurd translators written in Guile Scheme <ArneBab_>…except if that already exists… (I’m not up to date)