IRC channel logs


back to list of logs

<blu3r4d0n>Hey all :0
<blu3r4d0n>I am having a bit of a problem
<blu3r4d0n>I'm trying to use the chickadee engine
<blu3r4d0n>I built guile-opengl from source and installed it
<blu3r4d0n>and guile isn't seeing that I installed it
<marusich>blu3r4d0n, the first question I'd ask is: is it on your GUILE_LOAD_PATH?
<blu3r4d0n>Probably not
<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
<sneek>Will do.
<wingo>anyway we'll see with -r if spam comes back
<eldritch14>With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates!
<eldritch14>I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard
<eldritch14>Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal
<eldritch14>A fascinating blog by freenode staff member Matthew 'mst' Trout
<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 :)
<wingo>ok let's give that a go :)
<wingo>tx for the tip
<weinholt>sure thing
<snape>wingo: I can't join #guix
<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”.
<mbuf>rekado, me too
<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
<OrangeShark>Happy day before Friday
<cryptocat1094>:/ #guix now requires invites?
<snape>cryptocat1094: it's a configuration error it seems
<snape>due to a tentative to avoid spammers
<cryptocat1094>I figured that was why it'd been done.
<cryptocat1094>snape: Who should I notify about it?
<snape>it's done
<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
<wingo>to get yourself into guix
<wingo>then /msg ChanServ op #guix
<wingo>then /mode -r
<wingo>then /mode +q $~a
<cryptocat1094>rekado: Oh, thanks.
<daviid>hello! it appears I can't join #guix either, same as snape here
<daviid>*** 473 daviid #guix Cannot join channel (+i) - you
<daviid> must be invited
***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)?
<cryptocat1094>I think it's client-dependent.
<rain1>the mode is +Fir
<rain1>we need -Fi they stop people joining
<cryptocat1094>On weechat I can do /mode #guile
<rekado>I cannot seem to change anything on #guix. Can’t op.
<rain1>rekado: maybe i can help you do it
<rekado>I’d be happy if you could.
<rain1>msg chanserv invite #guix
<rain1>if you do this, I think chanserv will invite you into the room
<rain1>then you could /join it
<rekado>well, now I can
<cryptocat1094>I'm not authorized. :/
<daviid>yes, only those that are in access list can
<rekado>rain1: thank you very much!
<cryptocat1094>Sucks to be me.
<rain1>glad to help!
<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>i'm on #guix as well now, tx
<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>it's possible...
<rain1>hopefully that wont happen any time soon
<cryptocat1094>I'm honestly surprised it didn't happen two decades ago.
<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)
<daviid>ACTION thinking loudly
<rekado>is tensorflow not usable from Guile?
<daviid>rekado: it's in C++ right?
<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>not directly I mean
<daviid>caffee is in C++ as well
<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>*one guiler
<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?
<cryptocat1094>Autotool for Guile?
<daviid>cryptocat1094: autotool is not for any language, but guile is autotool chained yes
<daviid>so to speak
<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.
<cryptocat1094>That's unfortunate.
<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 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 “”.
<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
<cryptocat1094>And there's some sort of dependency resolution?
<rekado>cryptocat1094: no, nothing.
<OrangeShark>cryptocat1094: I wrote this
<rekado>cryptocat1094: the configure script only performs checks and aborts if a check fails.
<cryptocat1094>I see... so how do you get your libraries?
<weinholt>cryptocat1094, here's a package manager that works with guile to some extent
<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 ...
<cryptocat1094>weinholt: Huh, neat.
<OrangeShark>cryptocat1094: also helpful list of guile libraries and related guile software
<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 choice is for potluck
<daviid>my vote goes to potluck (I meant)
<rekado>daviid: can it be used already?
<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>rekado: here
<cryptocat1094>jlicht: The modularity is good indeed.
<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.
<cryptocat1094>I think that was fixed since?
<cryptocat1094>nvm, stable seems to still have the issue.
<rekado>cryptocat1094: the configure script that is generated from aborts when a dependency is not satisfied. But it is up to you to specify the checks in 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>Which is why I'm thinking of getting back into it
<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?
<cryptocat1094>daviid: I do 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>rekado: Thanks.
<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>daviid: cryptocat1094: the code for the template is
<daviid>OrangeShark: tx
<OrangeShark>the blog post, I try my best to explain the various things in the template
<OrangeShark>cryptocat1094: for dependency on a guile library, you can use what rekado suggest, a macro called GUILE_MODULE_REQUIRED. There is some others described in
<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>Hi all
<amz31>I would love something like that in guile
<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
<daviid>ok, tx
<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>daviid: tx :)
<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
<cryptocat1094>OrangeShark: Thanks for the skeleton
<OrangeShark>cryptocat1094: no problem, there is more you can add to it like documentation and testing. I need to get around to adding it
<cryptocat1094>So should one rely on GUILE_MODULE_REQUIRED or pkg-config?
<cryptocat1094>Oh. PKG_CHECK_MODULES is a thing.
<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
<cryptocat1094>OrangeShark: So that is yours?
<cryptocat1094>-_- nvm, it's written right at the top.
<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
<OrangeShark>amz31: pyxel seems pretty neat
<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>it will come
<amz31>well, I think you already use it? you said you rewrote personal tools in guile
<amz31>also you use guix
<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
<cryptocat1094>(Which was instead written in Python and similar)
<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: me too
<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
<cryptocat1094>(My own code is, naturally, not malicious so that's fine.)
<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 wants me to run and what say... 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.
<weinholt>quite true
<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.