<mark_weaver>wingo: I know it's a bit lame, but my x86_64 laptop is dead, so I only have i686 at the moment. It's been a long time since I've been able to compile 'master', let alone to any work on it.. <mark_weaver>and I do have some things I'd like to contribute to it, e.g. rebasing my fixing-letrec-reloaded patches, but at the moment I can't do anything. <mark_weaver>I'd also like to work on merging stable-2.0 into master <mark_weaver>that's good! last time my friends moved, unpacked boxes were lying around for over a month :) <mark_weaver>so, I might considered your current state "done" for some value of "done" <dsmith>Yeah, we still have some unpacked boxes in the garage from when we last moved. <spk121>Hello Guile. Does anyone here speak Arabic or Hebrew or another RTL language? <ijp>stnuoc taht fi sdrawkcab hsilgne daer nac I <mark_weaver>spk121: out of curiosity, why do you ask that question here? <ijp>[full disclosure, I used eval-and-replace with s-reverse in emacs] <spk121>Well, I'm trying to wrap up a bit of GNU Fribidi to convert a Guile string in logical order to visual order and pull that into the ncurses binding. <spk121>And I wanted to blog about it when I get it put together, and I was hoping to drag someone into proofreading an example when I had one to show. <daviid>mark_weaver: [civodul and wingo] something important to mention, wrt the above paste, you see that I have to call glib memdup [g_memdup, bound to gbank-gl-memdup in gbank], instead of directly using bytevector->pointer upon bv: this is because where I can use the result of bytevector->pointer upon all GI functions, it segfault whenever glib tries to free the mem block associated to this pointer, and there are conditions where GI calls <daviid>g_free whithout the 'user' [my] intervention. <daviid>I digged, just a little, and the segfault says 'wrong size <a memory address>, which is not the case when either we or GI calls g_free upon a pointer returned by glib, such as the g_memdup ... <mark_weaver>sneek: later tell daviid: regarding <http://paste.lisp.org/+6SVM>, it seems to me that 'with-typelib' is a bad abstraction in the context of scheme. in general, the dynamic wind may be unwound and later rewound. even if it is never rewound, there may still be references to '?var' still alive after the unwind. instead, you should arrange for 'gbank-tl-free' to be called only after the garbage collector determines that no more <mark_weaver>sneek: later tell daviid: instead, you should arrange for 'gbank-tl-free' to be called only after the garbage collector determines that no more references to '?var' exists. <mark_weaver>sneek: later tell daviid: it's very important that you understand how to deal with memory management issues when writing guile wrappers for C libraries. <zv>Is there any way to get common lisp-style `:before`, `:after` & `:around` for GOOPs methods? <galex-713>I said myself “hey, I should learn opengl”, then “everything is quicker with guile”, then discovered guile-sdl said nothing about opengl, guile-opengl had no working example (couldn’t figure out how to do anything), and guile-figl is unfindable and disappeared from gitorious… <mark_weaver>guile-figl is the old name for guile-opengl, when we weren't sure if we could use the opengl trademark. <mark_weaver>but I've not used it myself, so I can't help much. but 'sly' is an example of a project that uses guile-opengl. <galex-713>mark_weaver: do the old wingo blog particle example can be used to understand how to do the 3d stuff? <mark_weaver>I'm sorry, I've never done *anything* with opengl, so I can't help. davexunit is one person who could help you, and maybe there are others here. <galex-713>I don’t know anything about opengl and learnt about guile a few time ago and I got the crazy idea of implementing a simple voxel engine with guile because the C stuffi s ugly <galex-713>But yeah I just discovered sly under the old name of guile-2d when searching for figl ^^ <galex-713>yet I can’t understand: why is sdl used with #:prefix while opengl isn’t with just the hope the interface already has the gl- prefix <galex-713>also why “:” in guile-sdl and “-” in guile-opengl? <mark_weaver>well, they were written by different people, with different tastes, I suppose. <mark_weaver>the scheme community is old and diverse, and so is the guile community. if you are hoping for consistency across projects, I'm afraid you'll be disappointed. <galex-713>I just hope that’s a bit better than nodejs on this point ^^ <mark_weaver>I've managed to stay out of the js dev world, so I can't say one way or the other. <galex-713>mark_weaver: opengl stuff seems old and dating from 2014, do you think it would be quicker to keep try learning with guile or doing that with C and doing it more slowly but with more resources? <mark_weaver>I'm sorry, I don't know. I would ask davexunit or wingo <galex-713>although, erm, sly is searching for sdl2 while guile-sdl from the gnu.org website only implement sdl1… <mark_weaver>I vaguely recall that davexunit might have started working on sdl2 bindings for guile, but I'm not sure <galex-713>omg wingo’s particle stuff run at 100% CPU (dual core) and it’s smooooooth on this oooooold 32bit computer, that’s wonderfull and such impressive <galex-713>but I’m probably not skilled enough, and maybe that’s not the amazing guile compilation job and even python can do that… or maybe not… <mark_weaver>if it's the post I'm vaguely remembering, that might have made use of an experimental native code compiler <mark_weaver>galex-713: okay, that doesn't rely on the experimental native code compiler I was thinking of. <galex-713>sly’s not working “Unbound variable: sdl2:set-gl-attribute!” :/ let’s wait for him <galex-713>mark_weaver: so there’s already a native code compiler? :) <mark_weaver>wingo hacked up a demonstration, but it's not the real thing <galex-713>Because as far as I know epsilon had since the beginning and positron is trying to reach something approaching ocaml performance <mark_weaver>I should warn you up front, though, that it's currently tricky to make floating point operations run fast on guile. <mark_weaver>currently, floating point values must be heap-allocated, so if you're doing a lot of floating-point math, there will be a lot of allocation, and thus a lot of work for the garbage collector. <mark_weaver>our 'master' branch is able to "unbox" floats in some cases, which helps. <mark_weaver>davexunit can tell you a lot more about this, as he's had to work to make sly run efficiently <mark_weaver>the particle demo by wingo, which runs quite well even with the older 2.0.x virtual machine, is probably the result of wingo understanding very well how guile code is compiled, and writing things in such a way to generate good code. <mark_weaver>we are getting better over time, but I don't want you to have unrealistic expectations at this stage. <mark_weaver>anyway, I have to go to sleep now. it's late here. happy hacking! <galex-713>anyway I first want to just understand opengl, then I’ll do things, and probably without floats <cbaines>2nd question, is there an easy way to sort an alist? Currently I am extracting the keys, sorting them, and then constructing the alist again... <wingo>(define (compare-alist-entries less?) (lambda (a b) (less? (car a) (car b)))) <wingo>(sort alist (compare-alist-entries <)) <wingo>cbaines: re script versus module: don't run anything at the top level, just have functions, and then at the end you do (unless (batch-mode?) (apply main (program-arguments))) or something <Baldtoenails>Is there a way in guile to get a listing of all listening Unix domain sockets on the system? programs like netstat and ss seem to be able to produce that and I doubt they recursively check every file to see if it's a listening socket. <civodul>Baldtoenails: on GNU/Linux you can read /proc/net/udp <davexunit>it's still not particularly optimized, but I can render ~3000 particles at 60fps on my thinkpad x220 <davexunit>dealing with floats is just a fact of life if you use opengl. I use guile 2.1 for all of my work on Sly now because performance is just that much better. <davexunit>I was able to replace the use of a foreign library for matrix math with a pure guile implementation thanks to float unboxing <civodul>davexunit: would be interesting to compare the frame rate with the same code on 2.0 <davexunit>there's additional optimization that can be done on both the guile and opengl sides. <davexunit>my goal is to minimize allocations when rendering. <davexunit>since Sly is functional at the highest level, allocation is just part of life, but it's not so bad. <davexunit>the renderer is "low level" so it's the place for all sorts of imperative speed hacks ***nalaginrut_ is now known as nalaginrut
<Baldtoenails>civodul, I ound /proc/net/unix to have a somewhat nicer interface <Baldtoenails>Not sure what that does if a socket path has a newline in it though <civodul>Baldtoenails: ah yes, i meant /proc/net/unix <civodul>there's also /proc/net/{udp,tcp,tcp6} and so on, for the other socket types <civodul>i think such clunky interfaces assume that newlines in file names never happen :-) <Baldtoenails>To be honest, I think allowing control characters in files is probably a historical mistake <Baldtoenails>Stuff would be a lot simpler if you could just assume there would never be a bell or newline ina file <taylan>Baldtoenails: fully agree. potentially crazy filenames are also the bane of shell scripting. <Baldtoenails>taylan, yeah I looked into my boot scripts a while back and a lot of those things there bsically assume "please don't put newlines into these essential system files" <dsmith>We use svn for lots of stuff. And the windows documents people are fond of putting spaces, '[', ']', '&' and other oddities in filename and paths. Ugh. <wleslie>I'm not actually sure where this thing comes from, but it appears within our zip files full of ESRI ascii grids <wleslie>curiously, you can't do `unzip file.zip '[Content_Types].xml'`; but specifying no output files works. <cbaines>Any advice on easily writing a function that takes a pair as input? I'm using let and car cadr at the moment, and can't quite work out how to use match-lambda to do it? <davexunit>(match-lambda ((first . second) (do-some-stuff first second))) <cbaines>I thought I had tried that before, but was having problems getting it to work (maybe that was with lists though...) <galex-713>did you see all the backlog on opengl/sly earlier in the night? <galex-713>davexunit: do the last sly version work? because I couldn’t find set-gl-attribute! anywhere… <davexunit>galex-713: sly master relies on an as-of-yet unreleased version of guile-sdl2 <davexunit>if you build+install guile-sdl2 from its git repo, it will have everything needed <davexunit>I've been wanting to make releases of both but haven't gotten to it yet <mark_weaver>cbaines, wingo: it seems to me that 'batch-mode?' is not suitable for use within a module to determine whether it was run as a script or merely loaded as a module. <mark_weaver>the problem is that if another script is run, in batch mode, and it loads the module in question, then that module will erroneously conclude that it was run as a script <mark_weaver>however, I have another suggestion to make: put a shebang at the top of the module that arranges to run a procedure such as 'main' from the module after loading it. the shebang will be ignored when the module is loaded from elsewhere. <mark_weaver>cbaines: the 'guild' script included with guile 2.0.x is an example of such a module/script. <galex-713>“sly/window.scm:100:20: Throw to key `sdl-error' with args `("make-gl-context" "failed to create OpenGL context: ~A" "Could not create GL context: GLXBadFBConfig")'.” <davexunit>galex-713: does your gpu not support OpenGL 3.2? <davexunit>galex-713: do you use a dedicated gpu or an integrated one? <davexunit>older intel chips may not support opengl 3.2 <davexunit>or rather, mesa doesn't support opengl 3.2 on them <galex-713>I have an old CPU (core duo), don’t think it has an integrated one <galex-713>I have this from lspci: “00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)” <davexunit>I'm surprised because OpenGL 3.2 is *not* new <galex-713>Before intel put proprietary ME inside CPU to remote control them <davexunit>I have to give more thought about how to support older GPUs <galex-713>So I suppose if I want to play/learn with opengl I have to limit myself to the wingo’s particle stuff? <davexunit>galex-713: you could remove the opengl version specification from (sly window), I think, and see what happens <davexunit>galex-713: sly uses guile-opengl, which wingo wrote <davexunit>sly provides an abstraction on top of it, so you wouldn't normally be dealing with it directly <galex-713>I just wanted to observe how does sly use opengl <davexunit>if you want to learn opengl, I recommend using guile-sdl2 to set up a window and graphics context <galex-713>seems you’re not using guile-opengl directly or am I wrong? I only see inclusion of sdl2 modules <davexunit>you can look at the code in the (sly render ...) modules <galex-713>tried to change the opengl version from init-window to “2.0” then “1.0” and for both I got the same error <davexunit>2.1 is about the earliest version I could even see working <mark_weaver>sneek: later tell cbaines: it seems to me that 'batch-mode?' is not suitable for use within a module to determine whether it was run as a script or merely loaded as a module. <mark_weaver>sneek: later tell cbaines: the problem is that if another script is run, in batch mode, and it loads the module in question, then that module will erroneously conclude that it was run as a script <mark_weaver>sneek: later tell cbaines: however, I have another suggestion to make: put a shebang at the top of the module that arranges to run a procedure such as 'main' from the module after loading it. the shebang will be ignored when the module is loaded from elsewhere. <mark_weaver>sneek: later tell cbaines: the 'guild' script included with guile 2.0.x is an example of such a module/script. <galex-713>davexunit: so then should I still try to get something from sly or should I find stuff elsewhere since it seems it doesn’t work on my machine for some unknown reason while wingo particles stuff does? <davexunit>galex-713: I don't know what the issue is with sly for you <galex-713>(btw I see running things from geiser doesn’t do anything with his particle stuff while doing “guile <file>.scm” does (even “guile -c "$(<file.scm)"” does work, though slo)) <galex-713>wingo: any idea on why “guile -c "$(<FILE.scm)"” can work while running the buffer from geiser don’t (without even any error btw)? <davexunit>galex-713: I can't do anything about it right now <davexunit>could be a bug, but I'm not sure how to test further. <davexunit>I'd probably need to get a hold of an old thinkpad or something to get to the bottom of it <galex-713>davexunit: if you get a thinkpad X60(T) it could even be useful to you since it’s probably the most secure thinkpad you can find on Earth ;) (last released before ME was invented, and first to support LibreBoot) <galex-713>it’s around 100€ on any discount website if you search well enough, and you can regularly find new ones: the most will be in the hands of hackers/free software people, the less waste ^^ <mark_weaver>galex-713: I also use a Libreboot X60 as my primary development machine :) <mark_weaver>(I had a Libreboot X200 as well, which I found superior in most respects, but it developed a hardware problem in the charging circuitry) <mark_weaver>I'm not sure there's reason to consider the Libreboot X60 more secure than the Libreboot X200, dunno. <cbaines>mark_weaver, thanks for the tips about scripts :) <sneek>Welcome back cbaines, you have 4 messages. <sneek>cbaines, mark_weaver says: it seems to me that 'batch-mode?' is not suitable for use within a module to determine whether it was run as a script or merely loaded as a module. <sneek>cbaines, mark_weaver says: the problem is that if another script is run, in batch mode, and it loads the module in question, then that module will erroneously conclude that it was run as a script <sneek>cbaines, mark_weaver says: however, I have another suggestion to make: put a shebang at the top of the module that arranges to run a procedure such as 'main' from the module after loading it. the shebang will be ignored when the module is loaded from elsewhere. <sneek>cbaines, mark_weaver says: the 'guild' script included with guile 2.0.x is an example of such a module/script. <galex-713>mark_weaver: there is one but it’s for paranoid people: X60(T) were released *before* ME was invented therefore there’s absolutely no ME inside and we can be sure of that, while X200(T) was *after* but libreboot can theorically *disable* ME (all ME features stop working, and we’re not even able of re-enabling it), except while Francis/fchmmr (libreboot founder) consider this <galex-713>secure enough, GNUtoo (replicant/coreboot dev) consider chances that ME fakes disabling and keep control too high to use X200 for everything <galex-713>And yes, X200(T) is superior technically, superior ressources, etc. <galex-713>except maybe it’s harder to flash X200T than X60T <galex-713>wingo: guile vbo.scm works, even guile -c "$(<vbo.scm)" works, but guile <vbo.scm doesn’t (and that’s probably for the same reason it doesn’t work from geiser): why? <mark_weaver>galex-713: "there’s absolutely no ME inside and we can be sure of that" is not the relevant question. the relevant question is whether there is something inside that could be used as a backdoor of some kind, or even some minor bug in the hardware that can be exploited. <galex-713>mark_weaver: the correct answer is “we don’t know”, probabilities are smaller than on any computer on X200, but even smaller on X60, that is the thing <mark_weaver>I'm paranoid enough that I don't trust *any* computer made in the last 20 years. <mark_weaver>it's an uncomfortable situation, but I don't know how to do better short of making my own computer from scratch <galex-713>although you still have GTA04 :p it’s even less powerfull but at least you can put it inside a smartphone case ^^ <galex-713>although you have absolutely *no* 3D acceleration on GTA04 <galex-713>mark_weaver: if you want my opinion, it depends of what you want to do with your computer, GNUtoo stays on X60 because he doesn’t do any 3D or graphic or videogame stuff <galex-713>although X60T (which serves as tablet too) is quite practical in everyday life <mark_weaver>I certainly agree that running Libreboot is a *huge* improvement in how much we can reasonably trust that our machines are not "owned" by someone else. <mark_weaver>but the X200 was clearly designed to include a working ME, and in fact there was some non-trivial engineering required to get it working without the ME. I think it's quite good also. <galex-713>imho even a recent computer supporting libreboot would be awesome, that would give free bios/uefi-replacement to more people <mark_weaver>in the intel world, it looks unlikely that we'll ever be able to run a laptop newer than the X200. <mark_weaver>sooner or later we'll have to start using free hardware designs right down to the CPU, I think. lowrisc is one possibility. <galex-713>mark_weaver: no the problem is the cost of this, doing that we would close the community <galex-713>I’d personally prefer we all use “normal” computers without free bioses, in the dev middle, and let free-bios-computer to people who need it the most (like anyone NSA (or anyone else) would try to attack directly individually) <mark_weaver>I'm not sure what you mean by that, but the unfortunate fact is that intel now seems committed to making CPUs that require ME to function at all, and where the ME has to be digitally signed by intel to be accepted. <mark_weaver>and amd seems to be taking that path as well, although they are a bit behind intel on this front. <galex-713>Yeah I know that, still we can try to limit the access to the ME and try to make like secure home networks at least for people who probably wouldn’t be an individual target for such attacks <mark_weaver>IBM POWER might be an option in the meantime, until we have our own free CPU designs. <galex-713>the day we’ll have our own CPU designs, either it will be for an elite, either most of earth’s government would have to fall :p not any army would allow large widespread of free cpu design <mark_weaver>it's feasible that a coalition of countries that individually don't have enough resources to develop a viable CPU, might want a CPU that they can trust, for their own internal security. <galex-713>afaik here in France “backdoor-less CPUs” are hidden in the secret service building below the Invalides, and convoyed with hardened convoys <galex-713>mark_weaver: and how would you get them into US/France/etc.? <mark_weaver>one might have made the same claims about free software long ago <galex-713>and how would you get US/France/etc. not interfering to stop that <mark_weaver>you might be right, but I think you're making some assumptions. it's far from clear what will happen there. <mark_weaver>there are multiple free CPU designs already under development. <galex-713>mark_weaver: do you really believe we could get whole countries doing that? <galex-713>because afaik CPU making is like really expensive and not all countries are doing it right? <mark_weaver>I'm not even sure what it means for "whole countries" to do something. <galex-713>Because if we’re doing it the “market-will-found-this-naturally” way it already failed with openmoko :/ <mark_weaver>well, openmoko had a lot of serious technical problems as well. <galex-713>although nothing says us “a coalition of countries” would have technical problems too <mark_weaver>my point is, the fact that the openmoko failed in the market doesn't mean that nothing else could succeed. <mark_weaver>anyway, this is way off-topic here, and I need to do some other things now :) <mark_weaver>galex-713: but, for what it's worth, it's always great to meet another person who is thinking about this stuff, and using Libreboot, so it's all good! <galex-713>oh ok I got it, it’s because the batch-mode stuff <wingo>with ethreads and the simple memcached implementation <wingo>i can do about 16000 requests/second on this laptop <wingo>without serious tuning or optimization. <wingo>i'll update the ethreads branch but i do not plan on merging it before 2.2 <wingo>there are few things there that should go to guile that i will merge <wingo>but i was able to do away with the concept of 'eports', happily <wingo>i hate documenting bad things <wingo>paroneayea: check out the memcached example on the newly force-pushed wip-ethreads! <wingo>i am interested in your thoughts on that api <wingo>i don't know if the web server based on ethreads works or not, i haven't tried it yet <wingo>i mean, i had tried it back in the day <wingo>but rebasing to have guile ports support suspend-on-block made some the code change and i adapted the code but haven't tried it yet <janneke>wingo: i'd like to get the skip-invalid-go thing going, can you help? <wingo>yes that is a must before the release <wingo>so, i think that is next once i merge this feature thing and update news <wingo>and i will apply it tomorrow or sunday <wingo>so the remaining blocker is the 32-bit build <janneke>how do you feel about installing versioned binaries, such as guile-2.2 <janneke>i sent a trivial makefile patch for that -- possibly only to guix <wingo>there is the ability to add suffixes via ./configure <wingo>i am not sure if it is a guile concern or a distro concern <wingo>it could be a guile concern but i don't know. <janneke>what i do know, is that i don't like running 2 emacses <janneke>and that i also don't like not being able to use geiser for guix when the guile in emacs's path is guile-2.2 <daviid>... so the remaining blocker is ... and bug#20093 <sneek>daviid, you have 3 messages. <sneek>daviid, mark_weaver says: regarding <http://paste.lisp.org/+6SVM>, it seems to me that 'with-typelib' is a bad abstraction in the context of scheme. in general, the dynamic wind may be unwound and later rewound. even if it is never rewound, there may still be references to '?var' still alive after the unwind. instead, you should arrange for 'gbank-tl-free' to be called only after the garbage collector determines that no more <sneek>daviid, mark_weaver says: instead, you should arrange for 'gbank-tl-free' to be called only after the garbage collector determines that no more references to '?var' exists. <sneek>daviid, mark_weaver says: it's very important that you understand how to deal with memory management issues when writing guile wrappers for C libraries. <daviid>mark_weaver: tx! will get back to you on this later, have 2 quizz wrt what you said, but now i'm on something else... but tx you did read and for the comments <dsmith>janneke: Hmm. I had a patch for geiser to work with 2.1 a while back. But for some reason, I could not get it working with a newer geiser. <dsmith>janneke: Basically, in compile*, in evaluation.scm, different args need to be passed to compile <janneke>once we're able to install and run guile-2.0 and 2.2 alongside eachother, iwbn have geiser pick the right one <cmhobbs>i gotta bail for a bit, i may check back in later 