IRC channel logs


back to list of logs

<mark_weaver>zacts: you've definitely earned a place in our THANKS file, btw. If you give me your name, I'll add you to the fixes section.
<zacts>cool! sure.
<mark_weaver>if you've gotten to the point of "GUILEC", then this alignment bug is fixed, at least, and most likely the rest is good too.
<zacts>yep, it just started GUILEC now
<mark_weaver>cool :)
<zacts>it built with clang without any errors
<mark_weaver>zacts: excellent! can you also run "make check" ?
<mark_weaver>(I don't expect problems, but since you have everything set up, it's worth a check)
<mark_weaver>and then you could add the patch to your freebsd ports recipe and see how it does in redports.
<zacts>no 'make check' failures on i386 gnu/linux + clang.
<zacts>I'll test redports, just a sec.. and then once those builds start I've got to make some dinner.
<zacts>but, I'll keep you updated on the progress.
<zacts>thanks again for your help =)
<mark_weaver>that's great news! thanks again :)
<zacts>ok, the redports builds have started, I'll bbl in about an hour or so, probably. \\o/
<mark_weaver>cool :)
<madsy>When I compile a file, guile complains that some some code expected an assoc list, but the variable as defined is 0. But I don't want it to evaluate the variable yet.
<madsy>So what am I doing wrong?
<madsy>Nevermind, I'm being thick again
<ijp>glad we could help
<zacts>mark_weaver: so far I'm getting 'success' for i386, I still have a few to go. (redports)
<zacts>nice I'm only waiting on one i386 now
<zacts>all redports builds finished with success. nice, now I'm thinking it will only take a few days to a week to have a port in FreeBSD.
<mark_weaver>sounds great!
<zacts>I'm done with this project for tonight, I'll wait until I hear back from kwm, my mentor on the FreeBSD side of things for this project.
<zacts>but yeah, thanks a bunch for all of your help.
<mark_weaver>glad to help :)
<madsy>Is there a c function to get the default port?
<madsy>To use with scm_display and scm_puts
<ijp>C names are usually listed underneath the C names in the manual (where they exist), but the mapping is fairly easy to remember
<ijp>prefix with scm_, change - to _ , ? to _p, ! to _x, etc.
<ijp>under the scheme names*
***Fuuzetsu_ is now known as Fuuzetsu
***Fuuzetsu is now known as Guest27056
*wingo imports figl as a gnu project
<muep>whoa, modern opengl accessible from guile?
<davexunit>muep: are you talking about
<muep>no idea. I just took a look at
<davexunit>muep: oh wow thanks for that. this is guile-figl renamed.
<davexunit>looks like wingo is working on a release. :)
<davexunit>wingo: need any help?
***dunsmoreb_ is now known as dunsmoreb
<wingo>davexunit: could you test out that repo?
<wingo>some things changed
<wingo>e.g. what was (figl gl) is now (gl)
<wingo>other than that everything should be the same i think
*wingo working on a web page, and uploading docs
<davexunit>wingo: sure thing
<wingo>davexunit: does it work for you?
<wingo>i could make a release now
<wingo>actually i should give you a tarball
<davexunit>wingo: I am currently attending the (awesome) libreplanet keynote
<davexunit>I will test after the talk finishes. sorry for delay.
<wingo>heh, np, enjoy :)
<davexunit>this talk is awesome. the presenter isn't even in the country!
<davexunit>streaming via jitsi and tor
<wingo>who is presenting?
<davexunit>jacob appelbaum
<mark_weaver>jacob appelbaum rocks
<wingo>ah, nice
<davexunit>it's a really awesome talk.
<davexunit>streaming with fully free software.
<davexunit>there were a bunch of streaming problems yesterday but this presentation is flawless so far.
*wingo made a release, waiting on the gnu ftp uploader job to run
<davexunit>wingo: testing now
<wingo>davexunit: let me give you tarballs
<davexunit>I just built from git HEAD
<davexunit>but testing the actual release tarball would be better.
<wingo> and
*wingo steps out for a bit
<davexunit>wingo: things look good
<davexunit>my example programs continue to work
<davexunit>see ya and thanks.
<davexunit>I will write a guix package for guile-opengl.
<madsy>When using guardians, how do I differ between "nothing to clean up" from "no references in the guardian object" ?
<davexunit>madsy: I don't think there is any distinction.
<ijp>a guardian only returns an object if it is to be cleaned up
<davexunit>you either get an empty list or a non-empty list when calling the guardian procedure.
<ijp>if you get nothing returned, you have nothing to clean up
<madsy>Okay, so I just have to keep track of how many objects I added to the guardian by other means
<davexunit>I don't know how you could track that. *you* don't add to the guardian explicitly.
<ijp>madsy: what are you trying to accomplish?
<madsy>ijp: Cleaning up some resources before objects are claimed by the GC
<ijp>why can't you clean it up when the guardian returns it?
<davexunit>I do that in guile-2d.
<ijp>and how would a guardian help you do that in the first place
<davexunit>I periodically check the guardians by looping until it returns nothing
<ijp>you would need to track the things you put into the guardian anyway, which either means you use a weak table, which doesn't prevent collection, or you use a normal table, and it never gets collected and so would not appear in the guardian
<davexunit>I use guardians to clean up OpenGL objects like textures and shaders.
<ijp>unless I'm misunderstanding your intentions, in which case feel free to correct
<madsy>ijp: That's exactly what I'm doing. But I understand I have to keep track of how many objects I added, to know when I'm done.
<davexunit>when the user stops referring to a texture object (that includes the GL texture id) I catch it in the guardian and call the appropriate cleanup function.
<madsy>davexunit: me too
<ijp>madsy: why do you need to know when you are done?
<davexunit>manually memory management of GPU resources.
<madsy>ijp: Because I don't want leaks? Sometimes you have to clean up all the resources before you can continue
<madsy>ijp: Anyways it's not a problem. I'll just keep track of the objects myself
*davexunit goes out for lunch
<ijp>in my mind I am picturing a different way of doing this, but with weak links
<ijp>but they don't interact with the guardians quite right, IIRC
<madsy>Another question: utf8->string converts utf8-bytevectors to strings. But it copies the whole bytevector including every leading zero. Is that by design? If so, how do I work around that.
<ijp>0s are codepoints too
<madsy>0 alone is a null terminator. Maybe some code points use 0, but that's only with a matching prefix
<madsy>So \\x0 \\x0 \\x0 \\x0 ... is meaningless to have in a string
<ijp>no, 0 itself is a codepoint
<ijp>the codepoint for NUL
<ijp>from a unicode point of view, it is meaningful
<ijp>you can have it in any guile string you want
<madsy>If that was the case, wouldn't it break backwards compatibility with 7-bit ASCII?
<ijp>it breaks C strings, not ASCII
<ijp>I do not think we have a way to convert only a range of a bytevector
<madsy>Yeah, at least not according to the manual
<madsy>I have the actual string length, and the string is 7-bit ASCII
<madsy>That is, the length which is a subset of the bytevector
<madsy>I could copy the subrange into a new bytevector I guess
<ijp>you could use substring/shared and string-index
<ijp>all in all, I'm not sure it'd be worth it
<ijp>actually, just substring, since it's copy-on-write
<artyom-poptsov>Hello Guilers
<artyom-poptsov>I released Guile-SSH 0.6.0:
<artyom-poptsov>I'm not sure that there are a lot of people who interested in it, but anyway -- any comments and bug reports are welcome.
<zacts>ooh cool
<zacts>what is guile-ssh? is it a wrapper around openssh, or a full implementation?
<zacts>and how do the goals of guile-ssh compare with the goals of mosh?
<zacts>artyom-poptsov: ^
<artyom-poptsov>Hi zacts
<artyom-poptsov>It is wrapper to libssh library -- see
<artyom-poptsov>So no, this is not a full implementation of SSH protocol.
<artyom-poptsov>I started this project because I needed access to the SSH protocol from a Scheme program and I found nothing similar to it.
<artyom-poptsov>So I hope that Guile-SSH will be able to fill this niche.
<artyom-poptsov>zacts: Answering your question on mosh -- building of a fully-functional SSH server/client isn't the main goal of Guile-SSH (at least at the moment), although its distribution contains example of a simple server and client (see `examples' directory). The main goal is to provide a convenient API for Guile programs to allow them to communicate securely with each other or with standard SSH server/client implementations.
<wingo>guile-ssh looks really nice :)
<artyom-poptsov>Thanks wingo
<tupi>artyom-poptsov: sounds great. i am thinking to try it to distribute work over available computers ... i.e (define (computer-par-map code ips) ..)
<artyom-poptsov>tupi: Cool. AFAIK, civodul is going to use Guile-SSH for the similar task in GNU Guix -- to distribute jobs among machines in a build farm.
<tupi>nice, i'll keep an eye and talk to him if needed. distributed-par-map sounds better as a function name :)
<wingo>would be nice to be able to ship continuations over the wire
<davexunit>whoa. that sounds like wizardry.
<artyom-poptsov>tupi: yeah, probably distribution of compilation jobs is not exactly what you want to do, but I think these two ideas have some common points :-)
<davexunit>artyom-poptsov: congrats on the release
<artyom-poptsov>davexunit: Thanks.
<wingo>ijp: should we land lua support in master at some point?
<wingo>evening, civodul :)
<civodul>howdy wingo!
<civodul>so you're reply to my June email ;-)
<wingo>i was reading mail back then but it seemed i missed some even then ;)
<civodul>congrats on the Guile-OpenGL release, BTW!
<madsy>Nice timing. I Just got my opengl working in guile too :-D
<madsy>OpenGL 4.3 support with OpenGL and GLFW
<madsy>Pretty slow though
<wingo>madsy: fwiw there are generated docs up at
<wingo>should that be of use in your endeavors
<madsy>wingo: I did doc snarfing, and my opengl function parser adds the OpenGL 4 manpages to the SCM_DEFINEs
<madsy>So glprotos.txt is lik 160,000 lines
<madsy>Err.. glprotos.cpp
<madsy>So indeed I have docstrings for all the OpenGL functions. It makes Geiser cry when doing auto-completion
<madsy>wingo: I didn't ue guile-opengl. I implemented OpenGL myself for my demo engine
<madsy>I should make a wrapper for most functions though. I use bytevectors for pointer arguments. Pretty ugly to work with directly
<wingo>yes but i meant to say that you could use the doc snarfing pipeline, as it produces proper texinfo
<wingo>but whatever :)
<davexunit>wingo: there's a neat talk at libreplanet right now with 3 people in software coops.
<wingo>davexunit: neat!
<davexunit>between these people and your writings, I think working in a coop is something that I want to try out.
<madsy>wingo: Proper doc snarfing? What do you mean? :)
<civodul>hey artyom-poptsov, congrats to you too!
<civodul>i should give it a spin
<artyom-poptsov>Thank you
<artyom-poptsov>BTW, hi civodul ;-)
<civodul>hello :-)
<madsy>Boo.. OpenGL in guile was slower than I expected :/
<madsy>Time to figure out where the bottleneck is
<wingo>madsy: have you seen the docs? the conversion to texinfo is pretty good :)
<wingo>could be better of course
<madsy>Looks good. I think I botched up the formulas in the manpages, but apart from that, my texinfo mostly survived the conversion.
<madsy>Or maybe formulas can't be shown in texinfo's text format which guile uses
<wingo>i think it's the latter -- usually formulas in texinfo are actually raw tex
<madsy> :)
<wingo>nice :)
<davexunit>wingo: while writing a guix package for guile-opengl a problem was found. expressions like (dynamic-link "libGL") should be changed to point at the absolute path to the library.
<wingo>why doesn't your guix environment have a working dlopen setup?
<davexunit>it does, but it should point to the specific version of the shared library that it was built to work with.
<davexunit>civodul recommended this approach and that I file a bug with you. :)
<wingo>i don't think that is how the dynamic ffi is meant to work :)
<civodul>it's just the equivalent of getting the right -L flags, substituting @GUILE@, etc.
<wingo>that's early binding...
<wingo>why doesn't guix provide an appropriate environment for dlopen to do the right thing?
<wingo>dunno :)
<wingo>just using (dynamic-link "libGL") allows a built guile-opengl to work even if the libgl is upgraded and changes the library version
<wingo>but anyway, headed to sleep
<wingo>we can talk about that tomorrow :)
<didi`>How do I write the bytes of a bytevector to a file? I'm writing a procedure that downloads a file using HTTP. I can get either a port or a bytevector with `http-get'. Now I want to write either of them to a file.
<mark_weaver>didi`: 'put-bytevector' from (rnrs io ports)
<didi`>mark_weaver: Thank you. Could I link two ports? Something like (call-with-output-to-file filename (cut pipe-ports (http-get) <> ))?
<mark_weaver>sorry, not for this case.
<mark_weaver>we have 'sendfile', but you can't use that here.