<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. <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 <zacts>it built with clang without any errors <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 =) <zacts>ok, the redports builds have started, I'll bbl in about an hour or so, probably. \\o/ <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>Nevermind, I'm being thick again <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. <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. <madsy>Is there a c function to get the default port? <madsy>To use with scm_display and scm_puts <ijp>scm_current_input_port <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: oh wow thanks for that. this is guile-figl renamed. <davexunit>looks like wingo is working on a release. :) ***dunsmoreb_ is now known as dunsmoreb
<wingo>davexunit: could you test out that repo? <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 <wingo>davexunit: does it work for you? <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. <davexunit>this talk is awesome. the presenter isn't even in the country! <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 <wingo>davexunit: let me give you tarballs <davexunit>but testing the actual release tarball would be better. <wingo>wingolog.org/priv/guile-opengl-0.1.0.tar.gz and wingolog.org/priv/guile-opengl-0.1.0.tar.gz.sig *wingo steps out for a bit <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? <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. <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>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>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? <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>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 :) <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 <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 :-) <wingo>ijp: should we land lua support in master at some point? <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 <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>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 <davexunit>wingo: there's a neat talk at libreplanet right now with 3 people in software coops. <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! <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 :) <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 <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>why doesn't guix provide an appropriate environment for dlopen to do the right thing? <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>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. <didi`>mark_weaver: Thank you. Could I link two ports? Something like (call-with-output-to-file filename (cut pipe-ports (http-get) <> ))? 