IRC channel logs

<paroneayea>oh, well

<paroneayea>I guess binary data :)

<rlb>mark_weaver: offhand, I wouldn't expect property lists to be bundled either

<rlb>i.e. I'd expect to build on top of strings, but I admittedly don't know the particulars well

<rlb>mark_weaver: mostly just wondered what bits that emacs had gotten right might be borrowed (if any)

<rlb>mark_weaver: meh -- forgot the arm fix *again* -- uploading -7 to fix it soon.

<zacts>is it possible to build guile with another GC besides boehm-gc?

<zacts>bohem

<zacts>whatever it is

<mark_weaver>zacts: no, we currently support only bdwgc

<zacts>ah ok

<zacts>just curious

<zacts>has anyone tested building guile with musl-clib?

<mark_weaver>I haven't even heard of that

<zacts>I wonder about using guile on Dragora Gnu/Linux

<zacts>mark_weaver: just a sec.. let me find the link.

<zacts> http://www.musl-libc.org/

<zacts>it's aimed for lightweight embedded systems

<mark_weaver>paroneayea: the default port encoding is the encoding of the current locale.

<zacts>Dragora3 is going to use musl as its default C library

<mark_weaver>paroneayea: the REPL automatically sets the locale according to the environment variables.

<mark_weaver>paroneayea: for guile scripts, you need to set the locale yourself. (setlocale LC_ALL "") sets the locale according to the environment variables.

<mark_weaver>(in guile 2.2 and beyond, that will be done automatically by guile scripts using the 'guile' executable.

<mark_weaver>)

<mark_weaver>for programs using libguile, it is the responsibility of the main program to set the locale.

<mark_weaver>zacts: I haven't heard any reports of linking guile against musl

<mark_weaver>paroneayea: there's also a %default-port-encoding fluid variable that you can set.

<mark_weaver>sneek: later tell paroneayea I answered your questions about default port encoding, but you weren't around. the logs are here: https://gnunet.org/bot/log/guile/2014-09-28#T482386

<sneek>Got it.

<mark_weaver>sneek: botsnack

<sneek>:)

<cky>zacts: Böhm. :-D

<cky>(Well, actually the author uses Boehm, but still originally derived from Böhm.)

<paroneayea>sneek: mark_weaver: saw, thanks for the clarification :)

<sneek>Welcome back paroneayea, you have 1 message.

<sneek>paroneayea, mark_weaver says: I answered your questions about default port encoding, but you weren't around. the logs are here: https://gnunet.org/bot/log/guile/2014-09-28#T482386

<civodul>Hello Guilers!

<janneke>hi civodul!

<stis_>hej civodul!

<tadni>So, any news from Stefan about Guilemacs' chances of going mainline?

<tadni>Last I saw, he was more interestend in slowly shifting it to CL.

<bipt>tadni, nothing direct, but posts like http://permalink.gmane.org/gmane.emacs.devel/174750 have seemed at least less negative than the initial discussion

<tadni>It'd be very odd, if GNU ended up with two Emacs.

<tadni>Seeing that GNU Distro is probably going to offer a very heavy Scheme based desktop, if it doesn't make it in ... I see it still shipping in this "Emaculate" DE of sorts.

<bipt>tadni, gnu has two implementations of common lisp and three implementations of scheme, so it wouldn't be that strange :p

<tadni>bipt: Well yeah, but neither CLs are used that much (Clisp used a decent amount -- not close to SCBL (which irrelevantish because they are standardized enough where differences don't really matter all that much). And, the only Scheme really used at all is Guile.

<davexunit>is it possible to module-set! a private variable in a module?

<civodul>bipt: i think these figures are underestimated :-)

<tadni>Emacs would still be very popular and guilemacs would likely get very popular in it's GNU Distro niche -- causing some possible fragmentaiton.

<mark_weaver>davexunit: yes

<mark_weaver>tadni: what do you mean by "the only Scheme really used at all is Guile" ?

<tadni>mark_weaver: In terms of GNU Schemes.

<tadni>Kawa and MIT-GNU Scheme aren't really ever used for anything, from what I can see.

<mark_weaver>well, I think that's an exaggeration.

<civodul>i also think it's an exaggeration

<mark_weaver>what you can see is limited

<mark_weaver>(same goes for any of us)

<bipt>tadni, wrt merging with standard emacs, it's a little early to talk about that in any definite way, imho

<davexunit>mark_weaver: thanks

<mark_weaver>I think there will be resistance until guile-emacs is very clearly superior the original emacs. and I think we can accomplish that with some more time. When GNUS users see much better performance, and when people start playing around with all of the third-party library bindings available for Guile, etc, then it'll probably happen.

<bipt>guile-emacs has reached some significant milestones, but still needs a lot of work, and "works, but very slowly" probably doesn't sound so great without a lot of context

<mark_weaver>RMS wants it, and when the users want it too, the developers will come around, I think.

<daviid>what are the english names of #\\" and his opening/closing friends?

<civodul>double quotes?

<mark_weaver>daviid: there is none. the set of character names available is very limited. search for "_charnames[]" in chars.c. there are a couple of lists of names, and that's it.

<daviid>civodul: i'm asing because I now identified the changes git reports where at first glance it seemed 'no chage', precisly because the original doc [clutter] has changed the " for the "I don't how to call them" opening/closing... watcjing the git commit with emacs is clear, but copy/paste to lisppaste.org got them back to double quotes

<daviid>mark_weaver: thanks

<daviid>mark_weaver: civodul so I wanted to make a snmal text to explain why I have to send what appears to be a non patch stricktly trelated to previously existing documentation [*.texi files that were in 1.10 binding]

<daviid>mark_weaver: charnames, gives me the wish to call them 'charmants' haha

<daviid>charmant double quotes

<mark_weaver>daviid: probably you should use #\\xNNNN where NNNN is the unicode code point in hex.

*daviid won't win a dactylo contest, he constantly hits [too many] bad keys

<daviid>mark_weaver: good idea!

<mark_weaver>alternatively, you could just put the raw unicode character right in there, after the "#\\". we support that too.

<mark_weaver>though I'm not sure how guile 1.8 would deal with any of this.

<daviid>guile-1.8 can't run clutter 1.12.2, neither guile-gnome devel ...

<mark_weaver>okay. in the past, wingo told me that guile-gnome still aims to support 1.8, but that was a long time ago. I'm okay with it, anyway.

<daviid>mark_weaver: that is true up to the existing stable, 2.16.2

<mark_weaver>just make sure to encode the source code at UTF-8 if it has any non-ascii characters.

<mark_weaver>s/at/as/

<daviid>debian has all its guile-gnome-platform packages based on 2.16.2 and depending on guile-1.8

<mark_weaver>that's really too bad.

<daviid>guile-1.8 will be whithdrawn form testing any time now

<daviid>mark_weaver: yes [utf8...]

<daviid>mark_weaver: as soon as i find a solution to the corba related patch we can release 2.16.3, stricktky dependiong on guile-2.0

<mark_weaver>sounds good to me, thanks for all of your work on this!

<mark_weaver>rlb: is it true that jessie will not have guile-1.8? (I'm okay with that, fwiw)

<taylanub>I seem to remember Kastrup worrying/complaining about that too, since LilyPond is apparently still on 1.8

<daviid>mark_weaver: yes, severity level of 'bug' debian automatic messages for packages depending upon guile-1.8 has raised from normal to serious and emails were sent to all maintainers

<daviid>I can forward that email to you if you like

<stis_>Yes yes yes, I got tabling working in guile prolog!!!

<mark_weaver>daviid: sure, I'd be curious to see it!

<stis_>check out, http://paste.lisp.org/display/143879

<stis_>this is soo fun. Experimental feature only ;-)

<daviid>mark_weaver: done [2 messages]

<mark_weaver>daviid: thanks!

<daviid>np

<mark_weaver>taylanub: yeah, I've been working with David Kastrup privately to try to get LilyPond working with Guilev2.

<mark_weaver>stis_: I confess I don't know what "tabling" is, so I can't really comment, but I'm glad you're having fun!

<paroneayea>stis_: oooooh fun looking :)

<stis_>I implemented recursive data structures in gule log, so basically a large class of recursive predicates that previously diverged no produces a term that is self refrential

<daviid>mark_weaver: excellent! [lilypond..] any idea how far this goal is from being achieved?

<stis_>the example constructed the recursive term (( ... . ...) . (... . ...))

<mark_weaver>hard to say

<mark_weaver>oh, interesting.

<stis_>so tablingis memoisation that can handle recursiveness e.g. when the predicate includes the predicate again inside it's logic

<stis_>that normally diverges

<mark_weaver>sounds cool!

<mark_weaver>stis_: my knowledge of prolog is _very_ old and rusty, but I seem to recall traditional unification algorithms going out of their way to detect recursive structures and prohibiting them, presumably because it can lead to problems.

<mark_weaver>but I don't remember what those problems are.

<mark_weaver>s/recursive/cyclic/

<mark_weaver>I also vaguely remember reading of some attempts to overcome that limitation.

<stis_>it's possible to do unification for cyclic terms, swi prolog got them

<mark_weaver>okay

<stis_>this is a recent additions of the prologs that supports them.

<mark_weaver>what other prologs support cyclic terms, besides swi?

<mark_weaver>(just curious)

<stis_>I found YAP prolog also support this notion that is called rational trees

<mark_weaver>stis_: is your support for cyclic terms based on published paper(s)? if so, I'd be curious to see them.

<mark_weaver>my vague recollection is that cyclic terms could lead to invalid deductions without special handling.

<stis_>no as usual I think too much by myself.

<mark_weaver>hehe :)

<stis_>yep if there might be issues it's good to read up and prevent them if possible. IF you have a link please help me out.

<mark_weaver>well, these vague recollections are from hanging out in Stanford bookstore sampling books back in 1998 or so. I don't remember where I got it.

<stis_>anyhow it's getting late, we could take up this thread later,

<stis_>cu

<mark_weaver>okay, ttyl!

IRC channel logs

2014-09-28.log