<blu3r4d0n>I built guile-opengl from source and installed it <marusich>blu3r4d0n, the first question I'd ask is: is it on your GUILE_LOAD_PATH? <blu3r4d0n>I honestly don't know where the ./configure; make; make install; installed the modules. I'm assuming somewhere in /usr <blu3r4d0n>I think I'll try installing with guix instead of building it myself ***lavaflow_ is now known as lavaflow
<ng0>sneek: later tell civodul: you might want to check the channel settings for #guix, I am registered and logged in to services, but I'm still locked out of the channel. that's taking spam protection a bit too far ***heroux_ is now known as heroux
<wingo>sneek: later tell ng0 i think the only change we made was /mode +r <wingo>anyway we'll see with -r if spam comes back <weinholt>wingo, "mode +q $~a" seems to work rather well for #chez and #scheme <wingo>weinholt: what does that do ? :) <wingo>after all these years, my irc-fu is minimal <weinholt>it means that only registered users can talk, but everyone can join <weinholt>at least that's what they say it means :) <snape>"Cannot join channel (+i) - you must be invited" <ng0>you probably wanted +r yesterday <sneek>Welcome back ng0, you have 1 message. <sneek>ng0, wingo says: i think the only change we made was /mode +r <ng0>no, you'Ve definitely set a different mode. <wingo>ng0: since then things changed, plz read the logs <ng0>I've set +r to #gnunet yesterday, and I can still join it. <ng0>okay, but I still get the same message (wrt "invite only") <wingo>the only thing i did was +r and then later -r then +q $~a <wingo>i can't speak for any other op (civodul, mark weaver i think are the others) <ng0>just take it as a feedback for #guix. I get the same message as snape, and I'm logged in to the services <wingo>ACTION nod. i am not an op in guix i don't think <rekado>hmm, I can’t join #guix any more. Says “you must be invited”. <OrangeShark>blu3r4d0n: I believe the default would install to /usr/local You would need to add that to your GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH <snape>cryptocat1094: it's a configuration error it seems <snape>due to a tentative to avoid spammers <rekado>cryptocat1094: I already notified Mark about this. <rekado>I notified Mark before to get ops permissions on #guix, and it seems that while he setting this up for me he accidentally borked #guix. <wingo>rekado: i think you have op permissions, according to /msg ChanServ access #guix list <wingo>so, do "/msg ChanServ invite #guix" perhaps <daviid>hello! it appears I can't join #guix either, same as snape here <daviid>*** karatkievich.freenode.net 473 daviid #guix Cannot join channel (+i) - you ***are is now known as Guest37612
<rain1>I think civodil will be around soon, and can fix it <daviid>fwiw, my nick is registered, I'm on #scheme now too (which did set chan to +q $~a as well I think ... don't know why this happens, irc-fu is zero+ here :) <rain1>rekado: you could fix it, even if you cannot join the channel. I think you can set the modes from outside <daviid>what is the command to ask what the channel mode(s) is(are)? <rain1>we need -Fi they stop people joining <rekado>I cannot seem to change anything on #guix. Can’t op. <rain1>rekado: maybe i can help you do it <rain1>if you do this, I think chanserv will invite you into the room <daviid>yes, only those that are in access list can <daviid>I think it would be just removing the +i, so maybe /mode -i <rain1>it is just +r now: so you need to be registered to joi <daviid>fwiw, I think civodul is on holiday <daviid>blu3r4d0n: did you solve your problem (guile-opengl)? <rekado>wingo: thank you, too, for the instructions. I did not see them before. <rekado>neat trick to invite yourself to a channel that you cannot join directly. <daviid>my fear is that these bots could register (?) <rain1>hopefully that wont happen any time soon <daviid>we need a good machine learning lib accessible from guile, FANN is a possibility, most others are written in langs we can't bind ... (at least nt easily) <rekado>is tensorflow not usable from Guile? <rekado>(I’m still trying to build it for Guix without Bazel, which depends on dozens of Java libraries.) <daviid>rekado: also, 'end-users' use keras, not tensorflow <daviid>right now the only one we could 'immediately' bind is FANN <rekado>it’s mostly C++ but it has Python bindings. I don’t know if they use the C++ stuff directly or if they bind to something else. <daviid>rekado: good bindings to C++ lib is dam hard <daviid>otherwise I'd use OpenCV for Guile-CV (and Vigra, but not 'only' Vigra) <daviid>rekado: one need to wrap in C first, and that means you know pretty well C++ (I don't, anything below clos isn't worth it imo :)) and it's only easy if the C++ code is super star clean ... <daviid>rekado: and for one guilers, they have a couple of thousands pythonists ... to serve clean and feed the snake :):) <daviid>anyway, I'm thinking about this ... I'll see what I can do <cryptocat1094>Guile went the way of using Guix as its package-manager correct? <daviid>cryptocat1094: no, we all (almost all) use the autotool chain for our projects, then distro make their packages ... obviously guix makes theirs using guile ... _but_ we have potluck, which needs love ... (if I had several life :):) I'd work on it <daviid>cryptocat1094: what are you working on? <daviid>cryptocat1094: autotool is not for any language, but guile is autotool chained yes <cryptocat1094>I essentially haven't used autotool so I don't quite know how it'd work. Is there any blog post or anything about the current state of Guile? <daviid>cryptocat1094: the current state of guile is its reference manual and its NEWS files <rekado>cryptocat1094: autotools is … special. <rekado>cryptocat1094: it’s pretty verbose and is notoriously difficult to learn for newcomers. <rekado>cryptocat1094: many people (myself included) copy the autotools files of existing similar projects to get started. <rekado>cryptocat1094: the idea is simple, though: you have a configure.ac file, which is a template for a generated “configure” shell script. <rekado>that script is run by the user (or the package manager) to make sure the build environment is sane. <rekado>when automake is used, a Makefile is generated from a simple template “Makefile.am”. <rekado>the syntax is a bit odd as it relies on certain naming conventions to be followed. <rekado>the result is a portable configure script that generates a portable Makefile, which supports all common targets. <rekado>a user / packager would only have to do the usual “./configure && make && make install” to configure, build, and install the package. <rekado>autotools is NOT a package manager; it just provides a flexible interface to package managers that follows age-old conventions. <rekado>there should be an easier way for Guile developers to autotoolify their project, but I don’t know of any such efforts. <daviid>but that would make it difficult for other distro to pick and package your project <rekado>cryptocat1094: the configure script only performs checks and aborts if a check fails. <daviid>rekado: the effort started, it is potluck, but for some reason, none of the gulers/guiers took the flag after andy ... it's the package manager we all want for guile based projects though ... <daviid>that is one of our problem as well, is that 4 guilers worked on 4 diffs package manager for guile, instead of all working on 1 ... no flamewar, neither critique, just saying we should sometmes coordinate our efforts <daviid>guldhall, potluck, akku and there is another one that I forgot <daviid>my vote goes to potluck (I meant) <cryptocat1094>So build system is GNU standard. Dependency is "you're on your own" and we have four wip package/dependency managers. <daviid>rekado: there is thread describing its status, let me check <daviid>cryptocat1094: what are you working on, or trying to acheive? I don'tunderstand what you are trying to do ... it would help (me at least) to understand what you are trying to do <cryptocat1094>daviid: I'm trying to get started making more than toy scripts. <cryptocat1094>daviid: I typically work with more mainstream languages that have a fairly different ecosystem. <jlicht>cryptocat1094: I shamelessly copied a autotools-based setup from a different project (similar to what OrangeShark describes), and use GNU Guix as a package manager on top of this. The nice thing is that I can replace either the build system or the package manager parts separately, at some point in the future <daviid>cryptocat1094: ok, but any particular lib/objective in mind? <cryptocat1094>daviid: Currently not any in particular, but I do want to get involved with Guix at some point. <cryptocat1094>Does autotool for Guile have the ability to detect you're missing dependencies? <daviid>cryptocat1094: anyway, to hack in guile you don't need any packager, nor to autotool chain :), just fire emacs (install geiser) and M-x run-guile ... <cryptocat1094>I'd messed a bit while stdlib-only scripts for some things. I then put that on the backburner when I found that Debian failed to package guile-gnutls. <rekado>cryptocat1094: the configure script that is generated from configure.ac aborts when a dependency is not satisfied. But it is up to you to specify the checks in configure.ac first. <daviid>cryptocat1094: guile is in most distro, what's yours? <cryptocat1094>daviid: Mostly Debian. Use of Guix though makes the whole gnutls issue no longer a significant block. <cryptocat1094>rekado: Ah I see. Is there a commonly approved/used way of checking for them? <rekado>cryptocat1094: in many cases you can use pkg-config macros to check for libraries. <rekado>cryptocat1094: for Guile modules there are also macros to check. <daviid>cryptocat1094: ok, because you don't want to loose your time checking for guile dependencies, that's all done by distros ... don't you have a working guile? <daviid>so why are you asking about guile dependencies then? I don't get it <rekado>cryptocat1094: here’s an example for such a macro: GUILE_MODULE_REQUIRED([sdl2]) <rekado>cryptocat1094: this will check at configuration time whether the “sdl2” Guile module is available; if not it will abort. <rekado>cryptocat1094: if you want to let your project use a conventional build system I recommend picking an existing project that uses autotools, such as Chickadee. <cryptocat1094>daviid: I meant dependencies such as, for example, Chickadee if I were making a game in Guile. <daviid>cryptocat1094: I second rekado, pick an already autotool chained project, also, there is a template written bu OrangeShark, good to read for beginners <daviid>cryptocat1094: are you going to use C or only guile? <daviid>OrangeShark: where is you template again? <daviid>rekado: yes, thanks! cryptocat1094 ^^^that's a good start, then even though, pick an existing project <daviid>I'd pick up some that conforms to the gnu coding standard for instllation locations, guile-lib, or guile-cv (if you need/use C) <OrangeShark>the blog post, I try my best to explain the various things in the template <daviid>OrangeShark: I would only do that if the lib is tiny and very stable (couple of scheme files almost immutable ...) otherwise, I definitely would check the version, and that means using autotool chain macro instead ... <daviid>anyway, I ed to focus on something else, cryptocat1094 good luck, and ask here, we'are always happy to (try to) help ... <OrangeShark>daviid: oh true, versions can have interface changes. What macro would be able to check the version? <daviid>OrangeShark: I'd use pkg-config, not guile <OrangeShark>daviid: does that mean we should be creating .pc files as well? <daviid>or call pkg-config from guile I mean ... <daviid>OrangeShark: imo, good projects already provide a .pc file <daviid>imo they 'have to', which is why I added it for guile-lib when I started to co-maintain, even though it is pure scheme ... <daviid>and now we can depend on a specific version of guile-lib, not just check that guile-lib is there ... <daviid>imo, it is essential in the long run ... <daviid>have to concentrate on other things now ... bbl <amz31>it's pixel game engine or somehting like that <daviid>amz31, hi, what do you thing about gdbm? just curious, we have an unmaintained binding somewhere <amz31>daviid: gdbm doesn't support ACID transactions otherwise, if the architecture support is enough and that a _persistent to disk hash table_ is enough then it's ok <amz31>if you compare to wiredtiger, wiredtiger support only x86 and maybe arm. It support ACID transactions. And it can do range/slice queries like give me everything that has ABC as prefix <daviid>I wish one of us pick guile-squee and turns t a top notch postgres'modern' binding and ultra well maintained lib ... <amz31>I had that in my todo list, but I changed my mind <daviid>too bad :(, you'd be the one guiler to do this very well ... :) <amz31>IIRC there is a guile project that use bsddb, maybe it can help <amz31>I mean I know there is guile project that use bsddb, but I don't remeber the name of the guile project. It's the project that implements a distributed game engine for MUD/RPG games <OrangeShark>daviid: ah true, when I think about other languages, version checking is typically part of the package manager. In C and C++ world, they use pkg-config so you don't have to depend on one. hmmm <OrangeShark>cryptocat1094: no problem, there is more you can add to it like documentation and testing. I need to get around to adding it <OrangeShark>cryptocat1094: I think more projects need to provide .pc files to be able to work with pkg-config. I don't think many of them currently provide this <cryptocat1094>OrangeShark: I see. Still, it's good to know. (I have a feeling I'll have to learn autotools sooner than later anyway) <OrangeShark>cryptocat1094: my blog post should provide enough information, plus links to learn more, about the template I provided <amz31>daviid: what's up regarding gnome introspection? <amz31>cryptocat1094: what are you working on? <daviid>amz31: I haven't found the time, but I hope I will this year <cryptocat1094>amz31: Getting up to speed with Guix so I can start using it more and, hopefully, contributing to its ecosystem. Also probably rewriting some of my personal utils in Guile at some point. <amz31>cryptocat1094: I have been doing guile and scheme in my free time for 4 or 5 years or so <cryptocat1094>amz31: I'm a fair bit newer to any serious attempts to use it. <amz31>well, I think you already use it? you said you rewrote personal tools in guile <cryptocat1094>Some, I stopped when I rammed into difficulties due to Debian and its packaging. My recent "discovery" of Guix has removed that restriction. <cryptocat1094>Basically anything that required network capacities was held back by Debian failing to package guile-gnutls <amz31>I came to guile first, before knowing about guix because of the parenthesis <amz31>guix is nice, but right now it doesn't work for me <cryptocat1094>I first started playing with Guile because I wanted to play around and learn basics of "Functional Programming". <amz31>I want to have a file copied from the build directory to the build closure using the right paths <amz31>cryptocat1094: it was made obvious by functional javascript <amz31>at least I came from this backgroud <amz31>then I discovered guix and immutability <cryptocat1094>I never liked JavaScript much. I always saw it used mainly as a suspicious way to run untrusted (and untrustworthy) code on my machine. <amz31>I think it's a powerful concept that when applied solve problem that otherwise would require many ad-hoc algorithms <amz31>that's also about sharing the cost of producing the content <amz31>seems to me the economy wants to share the cost of running the Internet <cryptocat1094>Oh yes. But there's a nuance between what NoScript tells me eff.org wants me to run and what say... amazon.com wants to run. <amz31>that's without the code you don't know what runs <amz31>even with the code of browser is so complicated that you don't know if there is tricks even in code you can read <weinholt>cryptocat1094, there is no open request to package guile-gnutls in debian, did you send one? <cryptocat1094>weinholt: I did not. Though my use of stable would have hindered results anyway unless they were also backported. <cryptocat1094>I also looked at Nix and iirc they ran into some problems. I'm unable to find back the mailing list thread as it seems to have been moved to Google Groups? <cryptocat1094>Ah the old site is still up, though for some weird reason the github repository links to google. <cryptocat1094>Still, I'll have some free time soonish where I can possibly mess around with Guix.