IRC channel logs

2015-02-12.log

back to list of logs

<please_help>so, when will guile completely replace elisp?
<cluck>when it's ready to
<please_help>well, how far is it from being ready to replace elisp then?
<cluck>when it's ready
<please_help>(tm)
<mark_weaver>please_help: there are no plans to replace elisp in emacs.
<mark_weaver>what we hope for is to replace emacs's elisp interpreter with guile's implementation of elisp.
<please_help>what's the difference?
<davexunit>please_help: guile's vm is more efficient and featureful than the elisp interpreter
<davexunit>picture a world where emacs had threads, or a CFFI, or delimited continuations
<please_help>no, I mean, what's the difference between the implications of replacing elisp by guile and elisp by guile's elisp
<mark_weaver>we intend to replace the implementation of the elisp language. we do not intend to replace the language.
<mark_weaver>in other words, there's no plan to rewrite all the millions of lines of elisp code in scheme.
<mark_weaver>or even to deprecrate elisp and write most new emacs code in scheme
<please_help>not even give the possibility to write guile scripts while still maintaining an elisp interface?
<mark_weaver>it will be possible to use scheme to write code in emacs, but the emacs community would prefer to stick to elisp.
<mark_weaver>and when I say "will", that's assuming that the emacs community agrees to use guile, which is not yet a given.
<nalaginrut>morning guilers~
<davexunit>hey nalaginrut
<mark_weaver>also, although davexunit mentioned "a world where emacs had threads", that's not going to be possible either, because emacs code is not written to be thread safe.
<please_help>but can't you run scripts in individual threads?
<please_help>better than nothing
<nalaginrut>well, well, guys, where is the 'quick start' about GuixSD for USB?
<mark_weaver>it will be possible to use threads, but almost all elisp code will be limited to one thread, since elisp makes use of global state all over the place without any locking.
*nalaginrut happens to have an old physical machine for testing it
<mark_weaver>nalaginrut: that's a question for #guix, not #guile
<please_help>also, can you do thread safety analysis?
<mark_weaver>please_help: it would be a massive project to make emacs thread safe, and it's not even clear that it's a good idea.
<mark_weaver>but it would certainly be good if some selected long-running functions would be done in another thread, e.g. some of the code in Gnus or emacs-w3m.
<davexunit>mark_weaver: yes, you're right. I guess my point was: guile has a large number of useful features that the elisp interpreter doesn't.
<mark_weaver>indeed!
*mark_weaver goes afk for a while...
<davexunit>but yeah, the entire emacs codebase is pretty much the wild west. dynamic scoping + mutation everywhere.
<davexunit>yet somehow it all comes together to form a really great tool.
<nalaginrut>agreed, these two 'features' (if we don't call them bugs) are big headache for me!
<davexunit>ugh, ruby gems seem to often assume in their build scripts that you are using their git repo: https://github.com/rspec/rspec-core/blob/master/rspec-core.gemspec
<davexunit>which is certainly not the case when building a guix package. even if you use git-fetch, the .git dir is removed.
<grantixx>What was the name of that project civodul did that ran Guile right on top of Linux.
<grantixx>?
<grantixx>Ah, boot-to-guile.
<grantixx>I wonder if there's any reason to use this is over a proper Distro like GuixSD?
<davexunit>grantixx: just for fun, really.
<nalaginrut>seems boot-to-guile become a feature of GuixSD?
<grantixx>nalaginrut: As I understand it, yes.
<nalaginrut>when I encountered error to mount hard disk, GuixSD boot to guile anyway
<davexunit>nalaginrut: the initrd is a guile program
<davexunit>which is why you get a guile REPL when something goes wrong
<nalaginrut>yeah, there should be guile-colorized #advertisement
<grantixx>davexunit: Is there anything interesting one could do via boot-to-guile that one could not via GuixSD?
<davexunit>not that I know of
<davexunit>nalaginrut: package it for guix :)
<grantixx>I kinda really just want Guile at the near Hardware level I think is what it comes down to. What was the name of that system that one could write Linux kernel modules in Scheme in?
<nalaginrut>grantixx: I believe what you want is actually guile-hurd, not linux
<nalaginrut>although you can write linux modules with Guile anyway
<grantixx>nalaginrut: I've pretty much given up on the Hurd to be a decent and viable solution to Linux. X15 is real interesting but braur doesn't look like he's going to donate his project to GNU.
<nalaginrut>personally, I don't think it's a good way for doing so in a monolithic kernel
<grantixx>nalaginrut: There was a project, for some scheme, that allowed one to write modules for Linux. No idea what it was called, it's level of completetion, or implementation it ran on though.
<grantixx>For sometime now, I've been considering messing with implementing a basic microkernel in C that is just enough to implement Guile and work up from there... I don't know what all would be required there though. To get Guile working is a big task... maybe I could just bootstrap it and allocate someother system to compile Guile.
<davexunit>the hurd hackers found a way to use tinyscheme in the early boot process
<davexunit>which makes certain things a lot easier to hack on and debug, I hear.
<please_help>Why limit yourself to the kernel level? Grab an FPGA and start working on the next generation of lisp machines ;)
<davexunit>ludo would like guile to be able to replace tinyscheme for this purpose
<grantixx>please_help: The problem is that FPGAs are horribly proprietized.
<nalaginrut>for micro-kernel, it's easy and secure to write 'modules' with any dynamic languages
<davexunit>but we'd need to produce a minimal, statically linked guile.
<grantixx>No free toolchains, no percieved need for them at large.
<nalaginrut>actually these 'modules' are servers
<grantixx>If such a thing existed, I would surely jump on the FPGA train.
<grantixx>I'm doubtful such a thing will come about before home-fabrication is real cheap.
<grantixx>Which is likely another 10-15+ years...
<nalaginrut>grantixx: the FPGA model which is powerful enough to support lisp-machine is too expensive to me, no mention it's expensive proprietary IDE
<nalaginrut>that's one of the reasons why I still don't try lisp-machine on FPGA
<please_help>I don't think home-fabrication is particularly expensive already, but that's merely what I've been told
<grantixx>nalaginrut: Yeah, price is not the issue for me. I would find the funds if this was viable -- but the lack of a free-toolchain is non-recoverablne in my eyes.
<nalaginrut>even they provided free(as in free beer) FPGA IDE, they provides less models for free users
<grantixx>please_help: Printing a fpga from schematics only, at home?
<nalaginrut>and these free model are expensive to buy #OMG
<grantixx>I'm speaking free as in freedom, but yes, they are still targeted at industry only.
<please_help>I think the Nios II tools (for eclipse) are free (as in beer)
<please_help>they're for altera FPGAs
<nalaginrut>there's no free lunch in this world, but at lease give me some freedom
<please_help>not printing an FPGA schematic, printing a circuit board
<grantixx>I would probably just go into compeng if I knew there was a market for Free as in Freedom FPGAs.
<grantixx>That would be a company or non-profit I think that would really fit a need well.
<nalaginrut>FPGA in freedom? it means large money(cost)
<wleslie>so, how do you know an FPGA will be powerful enough to run your model until you have an FPGA you can try it on?
<zacts>hello
<grantixx>wleslie: You don't. You guess and hope.
<nalaginrut>wleslie: there's several projects IIRC
<nalaginrut>wleslie: I just saw their needs of hardware
<nalaginrut>I think it needs Xilinx SpartanIII at least, which cost near $282 in taobao
<nalaginrut>taobao is the cheapest shop in China as I know
<please_help>To know if an FPGA is powerful enough, you do simulation
<please_help>most vendors should offer simulators, and you can do generic simulation which can report your footprint and whatnot
<wleslie>right, so there's ISE Simulator and ModelSim. was not aware of these.
<wleslie>nonfree junk, though.
<nalaginrut>FPGA toolchain is still blackbox for me, I can learn nothing from a nonfree junk
<please_help>icarus verilog is OSS it seems
<please_help>only building the .bit file should require the use of nonfree software (assuming there are no current fpga vendors with opensource tools for this)
<please_help>oh, it looks like icarus verilog might be able to compile to a .bit (and it's opensource)
<nalaginrut>I haven't tried icarus verilog, but I wonder if it works for popular FPGA board?
<nalaginrut>I think the hard problem is that FPGA IDE or toolchains are provided by its hardware venders, and it's not easy to make it work for a third-party toolchain
<nalaginrut>it looks similar to the old time before GCC was born...
<please_help>there's also https://github.com/Wolfgang-Spraul/fpgatools but it only supports a single chipset ;)
<mark_weaver>boot-to-guile was essentially an early experimental prototype of GuixSD's initrd
<mark_weaver>or put another way, GuixSD's initrd is based on boot-to-guile
<mark_weaver>grantixx, nalaginrut: ^^
<mark_weaver>grantixx: what does it mean to be "a decent and viable solution to linux" ? there are solutions to problems. I don't know what a "solution to linux" even means.
*mark_weaver catches up on the backlog
<grantixx> mark_weaver: Solution as in a viable kernel, that's not a hybrid.
<mark_weaver>I've heard that someone is working on the last remaining pieces needed to compile bitstreams for at least one FPGA.
<grantixx>The "mircokernel solution", which yeah, maybe solution holds too strong of a connoation.
<mark_weaver>I'm not sure what makes you think that there will be no free toolchain for 10-15 years.
<grantixx>mark_weaver: I mean for a whole series of boards, not just one. Even if there was an all free toolchain for one FPGA, I'm dubious it'll be close to feature comparable to what the non-free provides.
<mark_weaver>I vaguely recall that it might be the same people who are working on Milkymist / Mixxeo.
<grantixx>Another issue is the barrier to entry for such a thing is amazingly high, to design an FPGA and associtative toolchain that is even close to comparable to what the likes of Altera & Xilinix ship standard -- from what I can tell and have been told.
<mark_weaver>umm, we're not talking about designing an FPGA
<mark_weaver>people could say the same thing about free software in general, and did for many years.
<grantixx>Design on the gateware level, but yeah, poorly phrased.
<mark_weaver>everyone was dubious that the GNU project could possibly get off the ground.
<grantixx>It would be very odd to me for us to have an all FOSS toolchain for an FPGA, and if say we tried to implement a Risc board or something it not be free.
<mark_weaver>and then they were dubious that "it'll [ever] be close to feature comparable to what the non-free provides."
<mark_weaver>it's just defeatest non-sense.
<grantixx>Were they though to that later point? I'm not old enough to know, but I thought a lot of the stuff was just recently proprietized and a lot of software was still academic and some non-formal decleration of "free".
<mark_weaver>if we had even one FPGA that we could compile to, that would be hugely important. but you're making it sound like it wouldn't be good enough unless it supported "a whole series of boards"
<mark_weaver>it's like suggesting that our liberation of the Thinkpad X60 and X200 isn't good enough, because we haven't liberated the entire Thinkpad line.
<mark_weaver>you're just spouting nonsense
<mark_weaver>this stuff is hard. we do what we can, and build from there.
<grantixx>mark_weaver: Nah, the end goal (I think) should be to have a whole lineage of free-fpgas. My point I was trying to make, was that comparable features are important now.
<grantixx>My desired end goal does not conflict with the more immediate issue that needs to be tackeled, to be feature comparable with modern fpgas.
<grantixx>mark_weaver: Do you know if there are any such attempts by projects like lowRisc?
<mark_weaver> http://m-labs.hk/ is the new home of the people who gave us the Milkymist One and Mixxeo, which use free hardware designs down to the gate level running FPGAs. They are the ones to talk to about this. They apparently have an #m-labs channel here.
<mark_weaver>*running on FPGAs
<nalaginrut>mark_weaver: seems it's impossible to make free FPGA anyway, I know it's very difficult, money is just part of it
<grantixx>lowRISC generally seems very promising, I know they are using Chisel to implement a RISC-V board ontop of a FPGA ... but I suspect that much of that toolchain is not free sadly, even though the board implemented on it will be.
<mark_weaver>what does it mean for an FPGA to be free?
<mark_weaver>an FPGA is a physical object
<mark_weaver>like a computer
<mark_weaver>what we need is software that can use an FPGA
<grantixx>mark_weaver: Free Hardware schematics?
<mark_weaver>it is not entirely unlike writing software to use a computer.
<mark_weaver>right now, free designs for an FPGA would be rather useless to us, because we lack the means to turn such a design into hardware
<grantixx>mark_weaver: Yeah, until small scale fabrication is semi-viable it's pracitcally useless.
<mark_weaver>for now, we are limited to figuring out how to use existing chips.
<grantixx>Though idelogly, not so much.
<nalaginrut>I think it's because GNU aims software part, so it's worthless for GNU to consider it
*grantixx looks to see if the "Free Hardware Foundation" is a thing.
<mark_weaver>one reason why FPGAs are important for us is because they make it practical for us to start experimenting with free hardware designs and making them executable.
<mark_weaver>there are already *tons* of free hardware designs. see opencores for example
<mark_weaver>but in practice they are just used as building blocks to make proprietary chip designs.
<please_help>There's not much of a reason to want free FPGAs anyway. Typically, FPGAs are too slow for real hardware, so you'd use an FPGA for testing your design, and then produce real hardware when you're happy with the result.
<nalaginrut>the vendors don't reveal all things, it's different from x86
<grantixx>mark_weaver: Well do we have many free-hardware designs for things like videocards, soundcards, etc?
<please_help>free FPGA toolkits are another matter, of course.
<nalaginrut>well, I speak too quickly, even x86 there's blackbox too...
<nalaginrut>IMO open CPU cores are
<grantixx>please_help: Eh, Moore's law and all that.
<mark_weaver>grantixx: read about the "Milkymist One" and the "Mixxeo"
<nalaginrut>IMO open CPU cores are 'software' to me... ;-)
<please_help>grantixx: http://en.wikipedia.org/wiki/Open_Graphics_Project
<grantixx>mark_weaver: I said many, not a few sucess stories.
<grantixx>If there is a notable amount of free chips.
<mark_weaver>grantixx: this is ridiculous. you are just wasting my time
<grantixx>please_help: Oh, very neat; Ty.
<grantixx>mark_weaver: I asked "many" regarding video/sound cards in response to you saying there were many chips generally on opencores. You offering 2 relatively sucessful cards does not mean that there are "many" free video/sound cards compared to chips.
<grantixx>If I was too nuanced, in any case, you were to filled with vitrole for the situation that occured.
<grantixx>too much vitirol*
*nalaginrut is planning to steal arg.scm from GNU dmd...so good thing for Artanis cli tools...
*nalaginrut is researching args.scm and getopt-long to see which is better...
<zacts>hello guilers
<Chaos`Eternal>nalaginrut, why not just let user write sexps in cmd-line...
<nalaginrut>Chaos`Eternal: there're so many muggles in this pretty world
<wingo>moin
<grantixx> coi
<zacts>hi
<lloda`>hi wingo, question
<lloda`>if (define a (values 1 2)) works
<wingo>shoot :)
<lloda`>shouldn't (define-values (a b) (values 1 2 3)) work also?
<lloda`>in 2.1, the second doesn't
<wingo>i think the semantics are that "normal" continuations that accept 0 or 1 value will truncate, but contexts that request a specific number of values will error if the number of values is not exact
<wingo>but i wish i had written that down and/or had test cases and a rationale etc :(
<lloda`>I like the behavior of dropping extra values better
<lloda`>it's awfully convenient
<wingo>it can be implemented fairly easily, but you'd have to argue a bit on the list :)
<wingo>internally in the cps, truncating continuations are represented like (call-with-values (lambda () exp) (lambda (val . rest) ...))
<wingo>and if the "rest" is unused it isn't consed or allocated to a register
<lloda`>can a (truncate-values ...) be written? you'd need to look at the continuation, it seems to me
<lloda`>or put another way
<lloda`>how do I write a define-values that truncates on top of the one that is strict?
<lloda`>also 2.0.9
<lloda`>(let-values (((a b) (values 1 2 3))) a) => 1
<lloda`>but 2.1.0
<lloda`>(let-values (((a b) (values 1 2 3))) a) => error: values, continuation, etc
<wingo>lloda`: that could be because of bad optimizations in 2.0, or an unwanted change -- i don't know
<wingo>2.0 was less principled about continuatoins and values
*wingo biab
<lloda`>principled is good is the principles are good
<lloda`>arguments for truncating
<lloda`>1) compatibility
<lloda`>2) logical extension of behavior with 0 and 1 values
<taylanub>lloda`: WDYM "behavior with 0 and 1 values"?
<taylanub>isn't it an error to provide a value where zero were expected?
<wingo>taylanub: (begin (values 1 2 3 4 5) #f)
<wingo>and, it's not an error to provide an unexpected number of values -- it's unspecified :)
<wingo>o/~ nasal demons o/~
<lloda`>so is there a context that requests 'specifically zero values'?
<wingo>lloda`: (call-with-values foo (lambda () ...))
<lloda`>right, right
<taylanub>wingo: RnRS kind of "is an error" :)
<wingo>taylanub: the r5rs and r7rs don't use that language in this case
<taylanub>forbidding values in continuations that expect none would be .. funny. I suppose it would incur overhead on every expression or something? :P
<taylanub>wingo: oh, is it literally unspecified in them?
<wingo>the continuation in (begin (foo) #f) is not the same kind as (call-with-values foo (lambda () #f))
<wingo>(begin x y) -> (call-with-values (lambda () x) (lambda vals y))
<mark_weaver>lloda`: the behavior you want is easy for you to arrange. just add a (. dummy) to the end of the receiving continuation
<mark_weaver>however, if we made that behavior automatic, there would be no good way to acheive strictness
<mark_weaver>*achieve
<mark_weaver>lloda`: what you could do, if you want, is to make a module redefining things like 'call-with-values', 'receive', 'define-values', etc, that adds that (. dummy) to the end.
<mark_weaver>and then the continuations created in your own code would all have the automatic truncating behavior.
<taylanub>weird, r7rs says "the effects of ... is unspecified" (p.52) instead of the usual "... is an error" when speaking of passing the wrong number of values to a continuation
<mark_weaver>do the standards say that zero values are expected in the non-tail forms of a 'begin'? I would think that any number of values would be allowed there.
<mark_weaver>I'm not sure I'd consider those to be cases of truncation, but rather obliviousness :)
<mark_weaver>well, in any case, those continuations would be of the form (lambda dummy ...)
<mark_weaver>sorry, I should have read the whole backlog before typing.
<taylanub>mark_weaver: it explicitly says that non-tail expressions discard any values they're passed
<taylanub>not sure if it wouldn't be better if implementations were at least allowed to signal an error on that if they want; e.g. C compilers warn about unused expression values after all.
<mark_weaver>taylanub: well, it would render virtually all scheme code incorrect
<mark_weaver>all existing scheme code, I mean. it would all have to be rewritten
<mark_weaver>(it's possible to write code that would be compliant with such a requirement, but I don't know that I've ever seen any :)
<mark_weaver>at least not anything non-trivial
<mark_weaver>but yeah, if we were redesigning scheme from scratch, maybe it should have been done that way, dunno.
<lloda`>thanks mark_weaver, I had not thought that (define-values (a b . c) ...) would work, but it goes right through to the call-with-values arg list, so it does work I can deal. Same for let-values
<lloda`>receive is one that can't be used in that way
<lloda`>these all behave differently in 2.0.9, I don't know if that was noted in the NEWS
<mark_weaver>lloda`: using receive that way works for me
<mark_weaver>lloda`: what expression did you try, and what was the error?
<lloda`>(receive (a b . c) (values 1 2 3) a) => failed to match pattern
<lloda`>the macro looks at list-of-atoms specifically I guess
<lloda`>haven't looked at that one
<mark_weaver>that expression works for me on 2.0.11 after importing (ice-9 receive)
<lloda`>my question was about 2.1
<lloda`>in 2.0.9 you can even do (receive (a b) (values 1 2 3) a) => 1
<lloda`>which you say it should be illegal
<lloda`>if it just channels call-with-values I mean
<mark_weaver>yes, this was all a mess in 2.0
<lloda`>worked great for me ;p
<mark_weaver>looking at the code in module/ice-9/receive.scm, it looks like it should obviously work. could be a bug in master.
*mark_weaver rebuilds master to test
<mark_weaver>lloda`: you may not have hit them, but there were several bugs related to truncation of multiple-value that were hard to fix.
<mark_weaver>*multiple-values
<lloda`>I appreciate the work of the maintainers, mark_weaver
<lloda`>(. rest) is acceptable
<mark_weaver>thanks :)
<lloda`>was there a define-match at some point in Guile, or am I remembering wrong?
<mark_weaver>lloda`: not that I remember, but you could easily define such a thing using 'match-lambda*' from (ice-9 match) in the second argument to 'call-with-values'.
<taylanub>mark_weaver: I thought it would make sense when combined with changing all "returns an unspecified value" procedures to "returns zero values"
<mark_weaver>that would also break a lot of code
<mark_weaver>note also that things like (eqv? "" "") return an unspecified value, according to R5RS
<mark_weaver>in Guile, there is a specific "unspecified value" that is often used in cases where zero values would naturally be appropriate, but it is important to keep in mind that in the standards, it really means "could be _any_ single value" (e.g. a random number, or whatever)
<mark_weaver>well, (eqv? "" "") really returns an unspecified _boolean_ of course
*mark_weaver goes afk for a while
<dsmith-work>Thursday Greetings, Guilers
***mario-go` is now known as mario-goulart
<robertle>hi everyone, I am trying to understand register VMs and am looking at guile as an example.
<robertle>i am looking at vm-engine.c, but fail to locate the actual registers! are they just on the main stack as well?
<robertle>or in other words: are "locals" in there the registers?
<dsmith-work>robertle: I can't answer your queston, but doc/ref/vm.texi might
<robertle>right, that looks very promising
<robertle>thanks, should have checked that first. somehow I always assume there is no documentation, probably from my own stuff ;)
<dsmith-work>heh
<dsmith-work>robertle: And you are looking at git master, instead of the stable branch?
<dsmith-work>robertle: Because 2.0 has a different vm than 2.1
<robertle>hmm, I am looking at master. but I am confused about the terminology, is 2.1 leading up to 2.2? I was hoping that I would be looking at the 2.2 branch with the register-absed VM and CPS lang as described http://wingolog.org/archives/2013/11/26/a-register-vm-for-guile
<dsmith-work>Yes, 2.1 is leading to 2.2
<dsmith-work>The git master branch is 2.{1,2}
<robertle>great
<paroneayea>so
<paroneayea>has any #guile person gotten guilemacs to compile? :)
<paroneayea>and run?
<dsmith-work>paroneayea: Not I. I started messing with it a while ago, but didn't have a lot of initial success, and haven't looked since.
<bipt>paroneayea, i have :)
<bipt>paroneayea, have you tried the instructions on http://emacswiki.org/emacs/GuileEmacs ? they've been used successfully by a few people, and i don't think i've gotten any bug reports about them from people on GNU-based systems
<bipt>i'm testing it now, as i don't think i ever tried nicferrier's final version and i'm used to just installing it into /usr/local
<paroneayea>hey bipt
<paroneayea>yes
<paroneayea>I've been trying to do it without doing "make install"
<paroneayea>no luck
<paroneayea>I can pastebin the error
<bipt>sure, i can take a look
<bipt>i'm not sure it can work without installing guile, even if into a place in your home directory. or alternatively without doing whatever "meta/guile" and friends do to use the library without installation
<bipt>emacs does not need to be installed, as it just loads everything from its source directory no matter what
*paroneayea seems to have permamently screwed up his kinesis, so a bit distracted
<paroneayea>bipt: so I'm running debian testing
<paroneayea> http://www.emacswiki.org/emacs/GuileEmacs I basically followed the installation script instructions here
<paroneayea>with the exception that I did --with-x=no
<paroneayea>on the emacs configure
<paroneayea>I tried both with and without it
<paroneayea>but it was failing on display
<paroneayea>and fails both way the same, so I guess it doesn't matter
<paroneayea> http://pamrel.lu/6e2a7/ is the error I get
<paroneayea>bipt: I *could* try doing a make install not to my home directory, but I guess I really hate installing things outside of a package manager!
<paroneayea>I did do a make install thus
<paroneayea>but it's to my home directory
<paroneayea>hnot the system
<bipt>whoa, this looks very wrong. let me check my dispnew.x
<paroneayea>thanks bipt :)
<paroneayea>if I get it working I'd love to make a guilemacs guix package
<paroneayea>whew, ok, fixed my kinesis :)
<paroneayea>what a relief
<bipt>paroneayea, does `which guile-snarf` in your compilation environment show the path to guile-snarf from my guile branch?
<civodul>sneek: later tell wingo would be nice if you could advertise the potluck a bit more (see guile-user) :-)
<sneek>Will do.
<paroneayea>bipt: nope
<paroneayea>shows /usr/bin/guile-snarf
<bipt>it won't work with guile-snarf from master, and the result will be that src/*.x will be full of garbage instead of just `defsubr' calls
<bipt>ok, please try setting $PATH to include the guile installation directory, make clean and try again
<bipt>also, it probably will not work without x enabled, b/c there is a complicated initialization bug i don't think i've fixed yet
<bipt>to include the guile install directory before /usr/bin, i should say
<paroneayea>oic
<paroneayea>I think
<paroneayea>bipt: no worries, I didn't actually want to disable X :)
<paroneayea>I just thought, maybe it was display related for X reasons
<paroneayea>running make now!
<paroneayea>and thanks for your help bipt
<bipt>no problem, thanks for testing
<paroneayea>I think I figured out what's wrong with the stuff I did from the wiki
<paroneayea>appends to the $PATH at the wrong end
<paroneayea>so /usr/bin/ takes priority
<paroneayea>it's now snarfing correctly ;)
<bipt>i will try to remember to submit my guile-snarf fix upstream soon, because pkg-config doesn't help with finding scripts and a lot of people have run into that problem
<bipt>oh! good catch, i'll update the page
<paroneayea>\\o/
*paroneayea excited to try out guilemacs
<paroneayea>bipt: btw, are your changes from gsoc far from hitting guile 2.2?
<paroneayea>since it looks like guile 2.2 is advertising full emacs lisp support
<bipt>i should warn you that it is not that useful for day-to-day use yet, just for the amazing experience of running all of emacs on the guile vm :-)
<paroneayea>bipt: yeah I'm sure that's true, but I Want To Believe (TM) in guilemacs
<paroneayea>and the proof in the pudding is in the execution
<paroneayea>proof of*
<ijp>civodul: I should probably do something this year, since I didn't last year
<paroneayea>bipt: also, are you thinking of doing another gsoc?
<ijp>I might apply to do guile-on-js
<paroneayea>ijp: !!
<paroneayea>wait, js-on-guile you mean? :)
<ijp>already exists, kinda
<paroneayea>or do you want to get guile running in the browser?
<ijp>yes, in the browser
<paroneayea>:O !!!!
<paroneayea>ijp: what route will you take?
<paroneayea>ijp: I am thrilled with this idea, as you already may know, as I think I showed you my blogpost
<ijp>paroneayea: cps->js and a shim
<paroneayea>\\o/ that would be thrilllling
<ijp>I already know basically how to do it, I just never have time
<paroneayea>ijp: please apply for that!
<bipt>paroneayea, my work is not in 2.2 yet but i'll see what i can do to get the important stuff upstream
<paroneayea>bipt: \\o/
<bipt>paroneayea, i'm not doing gsoc this year. i am considering attempting a crowdfunding campaign so i can get it in a state where it could reasonably be merged into emacs
<paroneayea>ijp: if you do the guile->javascript gsoc, I'll personally donate $100 to your summer "stipend"
<paroneayea>bipt: oh shit, I'd also donate to that!
<paroneayea>bipt: btw if you want to talk crowdfunding
<paroneayea>you may know that I have done a few free software crowdfunding campaigns!
<paroneayea>I am happy to give advice
<civodul>ijp: definitely!
<bipt>paroneayea, that would be really useful if i end up doing it, and i will keep it in mind :-) it was actually the mediagoblin campaigns that gave me the idea
<paroneayea>bipt: neat!
<paroneayea>the FSF might be interested in hosting it if you were going that route or not. But anyway
<paroneayea>I think it would be great!
<paroneayea>you pre-have-my-donation!
<civodul>guile-on-js would be great
<paroneayea>guile on JS would be *so great*
<cluck>+1
<bipt>+2
<cluck>guile on asm.js would be awesome, instant lisp machine everywhere ff runs
<paroneayea>it would be great, beyond great, to be able to write code that can be shared on the backend and frontend in guile
<paroneayea>browser/server
<paroneayea>and would I think help well position guile for gaining good traction in the webdev space