IRC channel logs

<galex-713>strangely I can’t find anything related to guile-fiber anymore

<Bob131>Hey everyone. I'm playing with a code base at the moment which makes heavy use of libguile since a lot of the functionality is implemented in Scheme plugins. I noticed that my changes were running exceptionally slowly, so I used callgrind to see if I could work out what was happening

<Bob131>I'm not entirely sure I'm reading this right, but it looks like scm_call_n is taking up a quarter of the CPU time

<Bob131>GC_malloc appears to be taking up the majority of that

<Bob131>is there anything I can do to try and minimise the impact it has on runtime? Dangerous never-run-this-in-prod solutions are perfectly acceptable, I'm just messing around

<civodul>Hello Guilers!

<C-Keen>hi guilers! I am looking for a xmpp library I could port, are you aware of one?

<amz3>héllo

<wingo>jeffers-media: greets :) i have been away on a trip recently but would be happy to help you get started

<wingo>one thing, are you working from paroneayea's recent rebase?

<ArneBab>Bob131: you might want to ask wingo about performance tipps

<Bob131>ah, okay. Will he see that, or should I privmsg/email/etc him?

<Bob131>Thanks, btw

<wingo>hi

<Bob131>hey!

<wingo>probably scm_call_n indicates the virtual machine, so it encompasses many scheme invocations

<wingo>what version of guile?

<Bob131>er, one mo

<Bob131>guile-2.0.11-9.fc24.x86_64

<wingo>ok

<wingo>if you are looking for a "quick" fix, you might consider using guile 2.1.4

<wingo>if you are able to do so

<wingo>a pre-release of what will be 2.2.0 within a couple or a few months

<Bob131>this project has already semi-trashed my ~ prefix anyway, so compiling/installing from source is no biggie

<wingo>otherwise if GC_malloc is taking a lot of time, that probably means you are allocating too much; you could use heapprof to determine where allocations are happening, but that's a bit of wizardry

<wingo>Bob131: one basic question though

<Bob131>shoot

<wingo>so you say it's scheme plugins implementing the functionality

<wingo>are those scheme plugins getting compiled?

<wingo>there's this auto-compilation thing that can happen

<Bob131>I believe so. The Makefile generates *.go files

<wingo>ok :)

<wingo>just wanted to check :)

<Bob131>Scheme is a completely unknown world to me, I'm hacking on the C code :)

<wingo>in that case i think trying guile 2.1.4 is probably the easiest next step :)

<Bob131>aight, tyvm

<Bob131>sorry wingo, I just wanted to ask about sourcing tarballs: Is there a release tarball for 2.1.4, or should I start from master?

<wingo>there is a tarball iirc

<wingo>you will want to build from that

<wingo>as otherwise it will take forever

<wingo>the tarball contains some bootstrap .go files that let the build go faster

<Bob131>the latest I can find is 2.1.3, but the GNU FTP is a bit of a maze :/

<wingo>ah

<wingo>maybe i didn't release 2.1.4 yet :) still 2.1.3 is fine

<Bob131>kk, thanks again

<Sleep_Walker>hi

<Sleep_Walker>I'm looking on GIT tags of guile repository and I can see 2.1.3, 2.0.12, ..., but none of them is on download page - are those still development/unstable releases?

<Sleep_Walker>I found 2.0.12 tarball on ftp

<lloda>2.even.x is stable, 2.odd.x is development

<Sleep_Walker>thanks

<wingo>see alpha.gnu.org for the development releases

<Sleep_Walker>I'm more interested in updating openSUSE package ATM

<Sleep_Walker>2.0.12 looks ready even though the page doesn't mention it

<davexunit>not directly guile related, but this is cool: http://technomancy.us/180

<davexunit>video game with emacs like interface for modifying it on the fly

<davexunit>more inspiration for my work with sly

<lloda>just noticed the new looks in the html manual, is that info?

<ijp>lloda: yes

<davexunit>the manual doesn't look any different to me

<ijp>davexunit: the default css definitely changed at some point with an info upgrade, but I couldn't pinpoint when it happened

<wingo>we can thank guix for that, that i regenerated the docs with a new makeinfo :)

<davexunit>I think it may have been a gnulib update?

<ijp>possibly

<ijp>finally read the "optimising closures in O(0)" paper, I think cps(2) spoiled it for me

<wingo>i think we implement everything in that paper

<ijp>I think so, it all seemed familiar

<davexunit>is it possible to build a statically linked guile?

<davexunit>trying to come up with ways to make standalone binary bundles of games that I've written in Guile

<davexunit>having a version of guile with all the dependent libraries statically linked would go a long way towards that goal.

<galex-713>davexunit: for windows?

<davexunit>galex-713: not at this time.

<davexunit>basically, if I can get a statically linked guile, then I just need to bundle shared libs for the things my game uses the FFI for, and the guile modules themselves, of course.

<galex-713>davexunit: but isn’t guile installed on most distros?

<ijp>no

<galex-713>ah

<davexunit>galex-713: the whole point is not really depend on anything from the host distro

<davexunit>I really don't like bundling, preferring distribution packages, but providing a big bundle that "just works" will mean that people can actually play my games.

<davexunit>something that no one can really do right now.

<ArneBab_>davexunit: that would be great! (and I would be very interested in testing it if you make it work. I’m also lacking a nice distribution mechanism)

<galex-713>davexunit: couldn’t you try to package them as a bundle with sly? and package sly into a distro? or with guile?

<davexunit>galex-713: no.

<galex-713>why?

<davexunit>well, yes, but you're missing the point.

<davexunit>I'm not going to package everything for every distro.

<davexunit>I'm going to provide a binary bundle that runs regardless of the distro.

<galex-713>that’s why I said “bundle” instead of “each game separately”

<davexunit>you're still not getting it.

<davexunit>sorry, I just don't have time to spell it out.

<galex-713>ok

<davexunit>ArneBab_: I'll let you know if I come up with something. the basic idea is to use Guix and mess with the package recipes to do static compilation.

<galex-713>at least maybe having sly packaged could make game distribution just consist in some scm files

<davexunit>and create a wrapper script that sets PATH, LTDL_LIBRARY_PATH, GUILE_LOAD_PATH, and GUILE_LOAD_COMPILED_PATH to the right values.

<davexunit>galex-713: sly is already in a packagable state, but it's not relevant to the distribution method I am seeking here.

<davexunit>*both* ways are needed.

<davexunit>I think bundles suck, but people that play games want to do this: go to game's website, download release, extract it, run executable and have it work.

<wingo>davexunit: can that binary bundle be a docker image?

<wingo>or some other container tech that can mount /gnu in the container

<kyamashita>Hello all! I'm a newbie to Guile and Scheme in general. I was wondering how I'd begin to debug an unusally memory-intensive Guile process.

<kyamashita>I'm trying to implement a very basic Pong-like game using Guile-SDL, but it's taking more than 2GB of RAM within seconds of starting the program. Obviously I've written something odd.

<ijp>you could try gcprof, but I confess I've never used it

<wingo>zow :)

<wingo>is your program all in scheme?

<wingo>your question is a good one and i don't know the answer in general :)

<kyamashita>wingo: Yes.

<wingo>if it's short, pop it in a paste.lisp.org/new :)

<wingo>there are basically three reasons:

<wingo>(1) you're in guile 2.2 and you have an instance of non-tail-recursion; your stack is huge

<wingo>(2) you are allocating some kind of low-level resource that takes a lot of memory, but not freeing it; bugs in guile-sdl are possible here but i understand guile-sdl is quite venerable so these thigns shouldn't exist

<wingo>(3) you are creating many scheme objects but they are all live, somehow

<wingo>those are the main causes

<wingo>IME anyway

<kyamashita>Going to post it soon...

<ijp>(4) gremlins

<kyamashita>Alright: http://paste.lisp.org/display/320978

<ijp>gremlins are notoriously hard to debug, but they can be placated with offerings

<kyamashita>ijp: What types of offerings?

<ijp>milk, cookies, and the odd blood sacrifice

<ijp>kyamashita: fyi, you probably don't want to be doing /

<ijp>(/ 10 3) = 10/3

<kyamashita>I see. Is there a floating-point alternative?

<wingo>ah

<wingo>you may have hit a bug i fixed recently

<ijp>do floor division, not floating point

<kyamashita>Like so? (floor 10 3) = 3

<ijp>floor/

<ijp>er, floor-quotient

<wingo>kyamashita: what platform are you on

<wingo>and what version of guile

<ijp>quotient will be probabl also be fine

<kyamashita>GNU/Linux, using GNU Guile 2.0.11.

<wingo>k

<wingo>32 or 64 bit

<wingo>intel i guess?

<kyamashita>64-bit Intel, yes.

<kyamashita>ijp: What is the difference between floor-quotient and quotient?

<ijp>division is a much more complicated topic than most people care about

<wingo>kyamashita: i think probably you need to create the screen once before your render function. not sure tho. i am not an sdl expert

<ijp>frankly I wish we'd only implemented the two versions

<ijp>oh well

<kyamashita>wingo: So just create one screen globally and then use it in the render function as needed?

<wingo>kyamashita: i think that is probably the thing to do

<ijp>kyamashita: quotient rounds to zero, floor-quotient rounds down

<wingo>lmk if that fixes it, then i explain why it might have fixed it :)

<kyamashita>ijp: Oooh, cool.

<davexunit>wingo: a container would work, but I don't want to rely on the user having root privileges.

<davexunit>nor do I want to rely on the user having access to unpriviliged user namespaces.

<wingo>davexunit: right, just thinking that many of these container things have setuid wrappers somehow that enable namespaces

<davexunit>yeah, but I think it would deter many people that would otherwise give my game a shot

<wingo>like that one that flatpak uses, i can't remember what it's called but it's small and secure, and we should use them...

<davexunit>I'd like to avoid containers entirely.

<davexunit>a static guile (which I just found a package for in guix) will do what I need.

<wingo>ACTION nod

<wingo> https://github.com/projectatomic/bubblewrap <- this

<davexunit>ah

<davexunit>yeah I would just use user namespaces instead

<kyamashita>wingo: Interestingly, I get a segfault now.

<wingo>kyamashita: that's exciting ;)

<kyamashita>Oh, hold on...

<davexunit>I want to write something for guix that exports the closure of a package and wraps it up with a script that will spawn a given binary in a container with a new user namespace

<kyamashita>I defined screen before I initialized video. :-P

<wingo>davexunit: yes!

<wingo>and if the user doesn't have user namespaces but does have bubblewrap, we can use that

<davexunit>oh, since people are talking about guile-sdl, I'll just point this out: https://git.dthompson.us/guile-sdl2.git

<davexunit>wingo: maybe! that would require more work because then we couldn't use call-with-container

<davexunit>so the implementation would have quite a bit more hair

<wingo>ACTION nod

<davexunit>so, guile-sdl is really old, written almost entirely in C, and only supports SDL 1.x.

<davexunit>I wrote guile-sdl2 to use for Sly. right now it only wraps the essentials that I needed to make Sly work, but it's *pure guile*, uses a sane build system, and can added to quite easily.

<davexunit>patches welcome :)

<kyamashita>I saw that when I looked at your code for the Lisp game jam a while back.

<davexunit>SDL2 is way better than SDL 1.x

<kyamashita>Do you think it's stable enough for Guix mainline packaging, or should I take the recipe from your git repo?

<davexunit>kyamashita: it's packaged for guix already.

<davexunit>I need to make a new release sometime, since there's been development since.

<davexunit>kyamashita: here's a package expression for a recent git snapshot of guile-sdl2 https://git.dthompson.us/sly.git/blob/HEAD:/guix.scm#l71

<kyamashita>Cool! Guix is so nifty!

<davexunit>the main things that are missing from guile-sdl2 right now are the various surface functions for using software rendering (I don't use software rendering) and wrappers for some event types like joystick events

<kyamashita>davexunit: I'll need software rendering for my purposes (go VESA video driver!). Maybe once I'm good enough with Guile I can contribute some code.

<davexunit>the other issue with guile-sdl2 is that it doesn't work on OS X and after several attempts to fix it I've just given up

<kyamashita>wingo: Memory usage doesn't go above 200MB now.

<wingo>i guess that's good? still seems a bit high

<wingo>so, the explanation

<wingo>ACTION looks for the reference

<kyamashita>wingo: Not nearly as high as 2500MB. :-)

<wingo>hehe

<wingo>kyamashita: this is an example of case (2) in a way: allocating a low-level resource but not freeing it

<wingo>now when gc happens, whatever memory a screen takes up (i assume it's a pixel grid and some related stuff) will be freed

<wingo>and in guile we have gc

<wingo>and gc runs after guile realizes that you've allocated a bit and that it should clean up.

<wingo>how to know when you've allocated a bit? that's easy, just count the bytes that were allocated by the gc.

<wingo>however...

<wingo>with objects that might hold on to some kind of foreign resource like an array of pixels

<wingo>guile doesn't see the pixels because they were allocated e.g. by sdl and not by guile

<wingo>so you just allocated like a megabyte but Guile only saw that you allocated 16 bytes.

<kyamashita>Oh gosh, I see now. And at 30 FPS, that adds up quickly.

<wingo>so guile doesn't think it's time to GC after like only 1000 renders, you only allocated say 16 * 1000 bytes from guile's perspective

<wingo>whereas in reality you probably allocated like 1 GB or more

<wingo>of course, this particular pattern of allocating a lot is going to be slow and if you can allocate outside of your render function like you did, then that's better.

<wingo>but even what you had should work.

<wingo>so the guile interface to let guile know that you did some mallocation is scm_gc_register_allocation

<wingo> https://www.gnu.org/software/guile/manual/html_node/Memory-Blocks.html#Memory-Blocks

<davexunit>I have a similar issue with OpenGL. I can free GL objects when guile's GC reclaims their Scheme wrapper objects, but allocating a lot on the GPU has no effect, of course, on when guile's GC will run

<wingo>i think guile-sdl is too old to call this function, that didn't exist back then

<wingo>so the real bug fix would be to make guile-sdl call this function appropriately, or something like that.

<wingo>AFAIU anyway.

<wingo>anyway your scheme was nice and tasteful and i hope you have fun hacking in guile :)

<kyamashita>Thanks! Guix got me started, and I think I'm going to be sticking around for a long while. :-)

<rekado>There seems to be a problem with the info manual.

<rekado>section “6.17.1.1 Expression Syntax” shows the short-hand syntax for quote and quasiquote

<rekado>but it’s rendered like this: (quote DATA)

<rekado>’DATA

<civodul>interesting, i was looking at that section too :-)

<civodul>yes

<rekado>(quasiquote DATA)

<rekado>‘DATA

<civodul>ACTION realizes Guile's manual doesn't have a good introduction to quoting

<rekado>civodul: are you also replying to Vincent’s email…?

<civodul>somehow, `,@' seems to be non-obvious, how can it be? :-)

<civodul>rekado: yes!

<ng0>I have a question.. We took on outside of Gentoo portage the task of the issue with Gentoo's 6 years old bug regarding guile version push. My personal opinion after a while is now that I do not want to help their internal whatever horse they are riding to keep 1000 years of backwards maintenance and multislotting.. so maybe finish the eselect but nothing more. My question is, is my approach at wanting to

<ng0>entirely drop 1.8.8 right, is 2.0.x the more common version now?

<wingo>there are still some programs that have not updated to 2.0.x AFAIU; dropping 1.8 would drop those programs

<wingo>whether that is ok or not, i do not know :)

<ng0>I ask because 1.8.8 is kept as the old stable

<wingo>for me there is no harm in keeping 1.8.8 around, if you can do so anyway, unless the bug reports and patches are too many

<ng0>when the next release happens and you move on to 2.2 or what it was, will 2.0.x become old stable?

<ng0>well the bug is mostly human now

<wingo>after 2.2 is out, 2.0 will become the old stable, yes

<wingo>but it will be easier to go from 2.0 to 2.2 than from 1.8 to 2.0 i think

<ng0>human bug as in, I do not want to help them fix their failed internal communications. I can do nothing more than make my changes visible and ask them to find a consensus on what to do

<ng0> https://bugs.gentoo.org/show_bug.cgi?id=355355 the eselect (for switching versions and setting symlinks) and the versions i made public are a bit buggy still I found out.

<rekado>ng0: lilypond is one of the biggest users of guile 1.8.

<ng0>hm

<rekado>ng0: dropping that would not be good.

<rekado>but: this doesn’t mean you cannot change the default

<rekado>as long as “guile-compat” or something is still provided.

<civodul>rekado: i've just replied to Vincent, feel free to share your thoughts

<rekado>civodul: I also just replied, heh :)

<civodul>cool :-)

<ng0>ACTION *sigh* seems like I have to debug the eselect and their ebuilds then

<ng0>thanks

<rekado>ng0: or you could walk away from Gentoo and embrace Guix ;)

<ng0>good news is though that 2.0.11 and 2.0.12 on their own build

<wingo>:-)

<ng0>I already use GuixSD and mainly keep Gentoo for the sake of maintaining one overlay.. the overlay which got recently in the inofficial list of gentoo and which i started to transition to a guix style "overlay"

<ng0>*already use GuixSD primiarly

<rekado>ng0: as soon as I could I just walked away from a steaming pile of custom Fedora/CentOS packages. Packaging for Guix has spoilt me.

<ng0>wanting to fix the guile bug might be just to show them that it's too funny that they kept the bug around for 6 years or more. one of the major reasons I did not get involved in upstream.

<ng0>Gentoo for me is a failing experiment which has its good and bad points to learn from

<ng0>this gentoo overlay also packages GNUnt suite and guix for gentoo.. so a reason to continue maintaining both and debugging the guix on gentoo ebuild

<ArneBab_>davexunit: thank you!

<ArneBab_>davexunit: well, actually… (worst possible start of a message ☺) … people want to go to a website and play right away.

<ArneBab_>davexunit: so if you could make the game compile down to a statically linked asm.js executable to be run directly in the browser, that would be the ideal release method for the users

<davexunit>ArneBab_: well sure, but that could never work for a variety of reasons

<jeffers-media>wingo: http://git.hcoop.net/?p=bpt/emacs.git is the one i am using

<jeffers-media>referenced from https://www.emacswiki.org/emacs/GuileEmacs

<amz3`>o/

<jeffers-media>anyone happen to know why loading byte-compiled libraries in guile/emacs is not supported?

<jeffers-media>figuring that out seems like it would be a big win for reducing load-up time

<jeffers-media>looking through the git history, and see a few references to "force loading from source", but no real explanation why

<amz3`>no sorry!

<amz3`>I never heard of byte compiling scm files dynamically

<amz3`>but I did not hear much either

<amz3`>;)

<amz3`>good to know more people get interested in guile-emacs :)

<galex-713>of course it’s interesting!

<galex-713>scheme is well better built than elisp, so we could get better programming working without emacs but also with emacs \\o/

<amz3`>I don't know if guile-emacs is meant to be compatible with scheme

<amz3`>I mean if it's possibleto program guile-emacs in scheme

<amz3`>Or will be...

<galex-713>yes it is

<amz3`>ah ok cool

<galex-713>guile-emacs means guile is the elisp engine AND you can switch languages, and import functions/variables from one language to another

<amz3`>wow!

<galex-713>means everything in guile is available to emacs and vice versa

<amz3`>really, is it written as a frontend of guile?

<amz3`>is elisp a frontend for guile?

<galex-713>also means if we implement, like, lua or python in guile, people will become able to extend emacs with these languages

<amz3`>wow!!!

<galex-713>amz3`: in guile-emacs, yes

<amz3`>that's very interesting

<galex-713>yeah, that’s the power of guile-emacs

<amz3`>I should be doing that instead

<galex-713>And that was the initial purpose of guile: bring the emacs advantage to a larger world, with more languages and more interfaces

<amz3`>yes I know that

<rekado>judging from the discussions on emacs-devel that’s unlikely to happen, though.

<galex-713>The problem is currently it seems only templeton is working on it, and it’s quite slow (not because of elisp implementation afaik, maybe other stuff, related to buffers, io, or dunno)

<galex-713>rekado: why?

<rekado>official code would still be elisp.

<galex-713>currently it works, it’s only really really slow

<rekado>just using guile as a vm

<galex-713>rekado: ahh, yeah of course

<galex-713>rekado: emacs will still be in elisp, and official extensions in elisp too

<galex-713>rekado: but people will be able to share plugins in other languages, that’s the cool stuff

<rekado>yeah

<amz3`>that's cool indeed

<galex-713>Also it means if an not-elisp extension become really popular, we can implement it in elisp and bring new ideas from people who don’t do lisp

<amz3`>java on guile @_@

<galex-713>(but will become more likely to understand lisp is so cool)

<amz3`>I will see this happend ;)

<galex-713>amz3`: did you know java is already implemented in a branch of gcc? :p

<amz3`>happen

<amz3`>galex-713: no

<galex-713>yes, and it compile to native code

<galex-713>gcj or something like that

<galex-713>(also to jvm if you want)

<galex-713>What I’d particularely like is it means everything that would currently be “easier” for most people to do in “other famous language”, we could study *why* it’s not as easy yet in scheme, and make so it become as much easy or even easier in scheme

<amz3`>this is already an on going debate galex-713

<amz3`>why would this make easier?

<galex-713>s/scheme/lisp/

<galex-713>Because lisp is a true programming language

<jeffers-media>galex-713: much of the slowness is due to interpreting elisp files at startup

<galex-713>jeffers-media: of the slowness? at startup? I was speaking of slowness long after startup completely finished

<galex-713>slow startup is not so much a problem to me

<galex-713>and anyway, that will be solved either by compiling to .go the elisp, either by improving guile VM, either by compiling to native code

<jeffers-media>galex-713: ahh, yeah im curious where the real bottlenecks are, since the todo references dynamic scope, gc, and buffer issues

<jeffers-media>or whether its an all of the above

<galex-713>jeffers-media: yeah I knew for buffer issues too, forgot for dynamic scope (but yeah, it would make sense), and thought to gc but then recalled: if guile is the engine, then gc is the guile’s gc right?

<jeffers-media>galex-713: yeah you're right about gc not being the problem, but us not optimizing after gc

<galex-713>ok

<amz3`>what's your next action jeffers-media

<amz3`>or actions? regarding guile-emacs

<rekado>galex-713: gcj only implements a subset of java 1.5. It’s barely enough to bootstrap OpenJDK 6 with IcedTea.

<amz3`>jeffers-media: you would like to know whether it's possible to compile scm files dynamically right,

<amz3`>?

<amz3`>I think it does this automatically when you 'use-modules' things

<galex-713>rekado: ah ok, thx

<jeffers-media>amz3`: well i just recently istalled it from source, so my plan was to get an idea of the major issues, get familiar with the source code, and plunge in!

<amz3`>which sources are you using?

<amz3`>do you have paroneayea version?

<jeffers-media>wingo mentioned that as well, i posted it above

<amz3`>where is it?

<jeffers-media>i don't think so, since i got it directly from the btempletons repo

<jeffers-media> http://git.hcoop.net/?p=bpt/emacs.git

<amz3`>this is not good

<amz3`>paroneayea: where your fork of guile-emacs, please?

<amz3`>I will have a look at the code too, but at least we should work on the most recent version

<jeffers-media>amz3`: sounds good, im looking online for the rebase, i think its mentioned in an old email on guile-devel

<galex-713>amz3`: paroneayea? it’s not anymore bpt who dev it?

<jeffers-media> https://gitlab.com/dustyweb/guile/tree/merge-bipt-elisp-wip

<daviid>rotty: hello! g-wrap fails against 2.1.3, would you have the time and the wish to fix this for us?

<amz3`>thx jeffers-media

<amz3`>maybe I should learn some elisp to start with

<jeffers-media>amz3`: thats the elisp branch btw, not guile-emacs

<amz3`>I understand now

<amz3`>jeffers-media: you know scheme? elisp? guile?

<jeffers-media>scheme, guile, and the theory of elisp, but not the syntax, you?

<amz3`>I don't know guile internals, but I know scheme

<amz3`>no I don't know elisp yet

<galex-713>me too, except I better know elisp than scheme

<jeffers-media>cool cool, the guile manual is great

<galex-713>the elisp manual is kinda well made too ;)

<galex-713>Yet scheme is “a real language”

<rekado>paroneayea has already pushed the merged changes to the “wip-elisp” branch of the Guile repository.

<rekado>see https://lists.gnu.org/archive/html/guile-devel/2016-03/msg00042.html

<amz3`>thx rekado

<galex-713>amz3`: <galex-713> amz3`: paroneayea? it’s not anymore bpt who dev it?

<amz3`>galex-713: I don't know

<amz3`>galex-713: they did not commit something new

<rekado>galex-713: paroneayea has recently rebased/merged bpt’s changes to prevent bitrot.

<galex-713>rekado: bitrot?

<rekado>as guile moves on changes that were made in the past may become outdated.

<rekado>eventually they no longer apply cleanly

<rekado>at that point the old changes become a burden

<galex-713>ah ok

<galex-713>yeah well a rebase then :)

<amz3`>both branch are in sync now, almost

<galex-713>both? you mean master and paroneayea’s or paroneayea’s and bpt’s?

<amz3`>master and wip-elisp branch

<amz3`>bpt's work can not bitrot since the elisp branch did not evolve per se

<galex-713>amz3`: ah, then paroneayea’s is just the wip-elisp branch of the guile repo? :D

<amz3`>galex-713: yes, I think

<galex-713>cool

<galex-713>amz3`: so if you have elisp-supporting guile installed on system and want to try guile-emacs, can you make *your* installed version of emacs/emacs-site-lisp use guile, or do you have to recompile emacs to use the system guile, or do you have to recompile guile too?

<amz3`>galex-713: I'm not sure I only done it on guix and I did not bother looking at the package

<galex-713>ok

<amz3`>but indeed I think you need the version of guile with elisp and guile-emacs proper

<galex-713>amz3`: remember-me: you use guix with debian or guixsd?

<amz3`>you can't point an old emacs to new guile-emacs' elisp

<galex-713>ah ok

<jeffers-media>if you guys want to compile yourself, use guix environment --pure guile-for-guile-emacs

<amz3`>galex-713: I have laptop with guix, my main machine still run ubuntu

<rekado>galex-713: you need changes to both guile and emacs.

<galex-713>erf, ubuntu

<rekado>galex-713: you cannot just make your regular emacs use guile.

<galex-713>rekado: ah ok

<jeffers-media>and then use that environment to build the guile branch

<galex-713>ok, you have to build guile first

<rekado>jeffers-media: I think we should update the package expression for guile-emacs in Guix.

<rekado>the package still uses the bpt repo.

<jeffers-media>sounds good

IRC channel logs

2016-07-21.log