IRC channel logs


back to list of 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>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>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>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:
<sneek>Got it.
<mark_weaver>sneek: botsnack
<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:
<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 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 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.
<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,
<stis_>this is soo fun. Experimental feature only ;-)
<daviid>mark_weaver: done [2 messages]
<mark_weaver>daviid: thanks!
<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>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
<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,
<mark_weaver>okay, ttyl!