<janneke>a mes 0.1 release is prolly not far away but now <davexunit>sneek: later tell civodul I tried to package Ao and failed. <amz3>OrangeShark: sorry for yesterday, I am sick and can't focus. Anyway, I have juice for a couple of hours and I will try to get things going... <amz3>first sorry for the tabs, they appeared in my emacs editor when I updated to 25.1, I was under the impression that this was fixed but it's not <amz3>OrangeShark: regarding `pointer-gc` I think it's good like it is right now <amz3>OrangeShark: Otherwise, putting the finalizer at definition time doesn't seems pratical <rekado>Ao looks very interesting indeed! davexunit: Do you still have the package expression that failed to build? <civodul>i have something almost ready i think <amz3>re: ao, last time I tried it, it was still unstable <civodul>bah "guile: Couldn't find current GLX or EGL context." <wingo>what does it use for opengl? <wingo>surely it doesn't use guile-opengl does it <civodul>does it means it's not doing the right thing somehow? <wingo>i wonder if that failure is a failure to dlopen libgl tho or something <wingo>consider grepping source for dlopen <wingo>i think dlopen/dlsym is heavily used in gl libraries, for various weird reasons <civodul>libepoxy.so.0: error: symbol lookup error: undefined symbol: glXGetCurrentContext (fatal) <civodul>but apparently libepoxy is supposed to dlopen libGL and libEGL <wingo>unrelatedly, we should be thinking about wayland... <void-pointer>How hard is it to build and install Guile on windows and how well does it run? <void-pointer>I don't have a windows machine handy at all, so I can't test it empirically <OrangeShark>void-pointer: I've heard it a bit difficult. I think someone was providing Windows builds for it somewhere. <janneke>void-pointer: i have a cross build patch set ready to be merged, for guix <takside>hey, does anyone have much experience with the gnutls module? <civodul>takside: ask your question and we'll see :-) <takside>ok, I'm just trying to get a basic anonymous tls connection going, but I get "a GnuTLS error was raised by `handshake': No supported cipher suites have been found." <takside>i can put the code on pastebin if it would help <civodul>probably you need to choose the right "priority string" <takside>i tried using "NORMAL", "SYSTEM", and "SECURE" and none worked <takside>and in wireshark the connection just does a SYN, SYN/ACK, ACK, FIN/ACK <civodul>it really depends on what the server wants <civodul>in the code above we use "NORMAL:%COMPAT:-VERS-SSL3.0" <civodul>which works for all the servers we care about <takside>i've just tried changing it to that and have the same result <civodul>you can increase the GnuTLS debugging level to see exactly which cipher suite is requested <takside>thanks for the link by the way, i should have thought to check some guix code for tls examples <civodul>likewise, you can try to reproduce the problem with gnutls-cli, to be sure <takside>ok, i'll try that - so far i've just been trying to connect to socat/openssl to test it <amz3>I am wondering whether I could use gexp with the database library I'm building <amz3>sorry, this is kind of OT, a friend a mine is looking for a fair laptop do you have any to recommend? <amz3>there novena, not sure it's fair... ***Guest51307 is now known as winny
<paroneayea>ACTION has been thinking about how to add capabilities to 8sync's actors subsystem on and off <amz3>it seems like Christopher Meiklejohn is working on an awesome distributed database using erlang called antidote <amz3>actually he is working on such a thing <amz3>seems very innovative, but I'm not sure what "causal+ transaction" means... <civodul>it's funny that the lessons learned in 1975 have been largely ignored since then <civodul>paroneayea: that RPC have a number of defects as a paradigm for distributed programs <wingo>ACTION works on the pthread_cancel thing <wingo>andrzejku: you are welcome to join the channel but i suggest that you "lurk" for a while to catch the vibe <andrzejku>wingo, I use Linux first time when I was 13 years old <amz3>andrzejku: do give you glimpse of the vibe: 0) don't ask question if the answer is in the manual https://www.gnu.org/software/guile/manual/ 1) avoid small talk 2) don't talk about non free software 3) don't talk about patents 4) avoid chatter 5) release code with autotools that works and preferably wait for other people to promote it instead of trying to promote it yourself 7) feel shy about asking questions <amz3>I may have got the vibe wrong. <andrzejku>but wingo is my friend, can I talk with him? <ijp>I've broken all of those rules <amz3>but I read that patents are something like "broken" by some jury in the USA recently <amz3>some juge decided that patents were not good anymore in a given case, which makes patents useless <paroneayea>while it might be referenced in future cases, it wasn't a ruling <paroneayea>it was a good opinion piece, but didn't remove any current threats from patents <wingo>mark_weaver: i convinced myself that the catch handler at module/system/repl/server.sc:116 will never be called in master. wdyt? <wingo>b/c in master accept returns #f on a nonblocking port <davexunit>the cooperative repl server might also be no longer needed now that we have nonblocking IO <wingo>s/port/socket that's not ready/ <davexunit>I'm pretty confident that I'm its only user anyway <wingo>davexunit: read can't be uesfully fiber-ized <wingo>have to implement read in scheme :) <davexunit>well even if it blocked on read, we could wait until there was data in the port before we called it <avoine>davexunit: no I use it too but with gtk's loop <avoine>but that give me segfault sometimes :-/ <avoine>and I use a timer to eval every tick, so no so solid :-S <avoine>I need to migrate to sdl/sly but I never did 3d before <amz3>you don't need 3d knowledge to usesly <davexunit>sly is an experiment that I'm growing less fond of <amz3>you are not interested in a game engine anymore? <davexunit>but there are some serious problems that need to be addressed <avoine>amz3: I'm building a geometry app and cairo is a confortable shoe :P <davexunit>writing a few different types of games, and completing a small game for the lisp game jam has helped me expose the problem areas. <davexunit>I need more time to think about what can be done. <amz3>davexunit: this could be a good (long) read <amz3>davexunit: AFAICT from a user point of view, I think no framework/API manage time well <davexunit>I'd be happy if I could get it right for the particular use-case of game programming <davexunit>some things have been *very* nice about FRP. live asset reloading, for example. <davexunit>it's pretty great to edit some art in GIMP, export, and watch the game automatically reload the sprite and propagate the change to everything that draws it. <amz3>it's called “hot reloading” in javascript community <amz3>I read nothing about time management in the elm documentation <davexunit>hot reloading code is terrible, poor excuse for not having a REPL server :) <amz3>ah I understand it's different from what sly does <avoine>beside from framework and api I think we need a better editor for editing FRP code <amz3>In the library I experimented with which is inspired from elm, there is basically no time handling facility. But what you can do is register timers then change the state, and "wait" for it to be rendered <amz3>avoine: are you thinking about flow / visual programming? <daviid>avoine: fyi, I use guile-a-sync, which permits/integrates well with the gtk main loop <avoine>amz3: yeah kind of, can't find the link but I'll show you tomorrow what I have in mind <daviid>wingo: so far, I've been incapable of debugging our guile-gnome g-iddle-add and friends segfault <daviid>wingo: I beleive it has to do with <gclosure> and gc, but just an intuition really