<fangism>anyone here test geda tools like gschem against guile-2.0.x? <fangism>a fellow fink package maintainer reports that schem fails with the following (the guile 2.0 dependency built cleanly, however): <fangism>> 157: 1 [catch #t #<catch-closure 107600c60> ...] <fangism>> ?: 0 [apply-smob/1 #<catch-closure 107600c60>] <fangism>and gschem works fine with guile-1.8.x <ArneBab>fangism: there are some incompatibilities between 1.8.x and 2.0.x <fangism>ArneBab: is there a good set of recommendations for migrating to 2.0? or list of things to check? <ArneBab>fangism: I don’t know - I think most folks who really know are offline right now <ArneBab>wingo, civodul: can you help fangism? <ArneBab><fangism> ArneBab: is there a good set of recommendations for migrating to 2.0? or list of things to check? <civodul>fangism: no particular recommendations: try to build the thing with 2.0, and then check for each issue in NEWS or here <civodul>wingo: BTW, i chatted with dmalcolm of libgccjit at the Cauldron, and he's looking for users :-) <wingo>i'm getting to a point where i could use it <civodul>it's 72 functions to wrap, so the bindings should be quite easy <wingo>i thought it was a c++ interface <ArneBab>wingo: the sample client uses a C-API <civodul>i told you: he's really looking for clients ;-) <ArneBab>the Python bindings look a bit overly complex <ArneBab>but I guess the easier ffi in guile should make this much easier to integrate <ArneBab>wingo: do you think about using gccjit for native compilation? <nalaginrut>hmm...does that mean the brand new assembler/linker/loader are redundant? <wingo>ArneBab: could be useful once we have a low-level compiler; i would start with our own thing though so we know what we want <ArneBab>it would be cool to have Guile code which can utilize all the optimization of GCC *wingo sets psyntax on fire <wingo>the so-called "efficiency" hacks in psyntax are ridiculous <wingo>they make the whole thing too baroque to hack on <nalaginrut>wingo: does it really show "efficiency" in practice? <wingo>in practice expansion is a small fraction of compilation time <wingo>it could be bigger and that would be fine <wingo>maybe we can convince mark_weaver to rewrite psyntax *taylanub wonders about the status of Guile Emacs <taylanub>there were some new commits in a wip branch a month or so ago but again nothing since then. I should try out this branch though; I think it does kind of replace the Elisp engine <ArneBab>a month ago is just before mid-term, right? <taylanub>ArneBab: pretty much, yes. it's May 19 to Aug 18. latest commit I see is June 26. *wingo busy unfortunately, but thanks <wingo>literally finishing some guile patches then a luajit meeting then i need to get some v8 patches in <nalaginrut>everyone, everywhere, everything are talking about JIT... <nalaginrut>ArneBab: I've read you post about TCO in c++, and I tried c++0x lambda, it can do TCO too, if well coded <ArneBab>nalaginrut: I’m glad the article got you interested ☺ <nalaginrut>ArneBab: I don't think C++ spec guarantee anything about TCO, but std::function can be optimized with gcc <nalaginrut>well, anyway, it's just interesting thing, we can't use recursive call in C++ IMO <nalaginrut>as you said, don't rely on the optimizing option <ArneBab>so you’re then not writing for a standard but for a compiler - with hopes that (a) other compilers might be able to do the same, and (b) the compiler does not remove the optimization at some point in favor of some other optimization. <nalaginrut>unless c++ spec guarantee something TCO, or we can just play it as toy... <ArneBab>though guile might be able to state “we’re GNU, with GCC we can do” <nalaginrut>I mean the same with "tail call with lambda in C++0x" <nalaginrut>maybe 'lambda' here is bad word, just defined a function in a function <nalaginrut>IMO, whether to use TCO depends on the spec of language, for Scheme, we should use of course ;-) *nalaginrut has to go for supper <ArneBab>If you want to write a tutorial on Guile, this talk sounds like it should be required hearing: rtmp://rtmp.ep14.c3voc.de:1935/stream/saal2_native_hq ***Turkish_pizza is now known as Froggy_G
***Froggy_G is now known as quintessential_l
***quintessential_l is now known as dirtystache
<quxbam>hi, can someone help me getting guile-wm to work? <quxbam>i've cloned the git-repo and compiled and everything seems fine <quxbam>but i receive following error when trying to start: <quxbam>~/git/guile-wm $ guile-wm -i wm-init-sample.scm <quxbam> 157: 6 [catch #t #<catch-closure 3babc0> ...] <quxbam> ?: 5 [apply-smob/1 #<catch-closure 3babc0>] <quxbam> 63: 4 [call-with-prompt prompt0 ...] <quxbam> 67: 2 [begin-event-loop "wm-init-sample.scm" "/tmp/guile-wm.log"] <quxbam> 124: 1 [xcb-connect! ":0" "localhost"] <quxbam> ?: 0 [connect #<input-output: socket 16> 1 "/tmp/.X11-unix/X0"] <quxbam>ERROR: In procedure connect: Connection refused~/git/guile-wm $ guile-wm -i wm-init-sample.scm <quxbam> 157: 6 [catch #t #<catch-closure 3babc0> ...] <quxbam> ?: 5 [apply-smob/1 #<catch-closure 3babc0>] <quxbam> 63: 4 [call-with-prompt prompt0 ...] <quxbam> 67: 2 [begin-event-loop "wm-init-sample.scm" "/tmp/guile-wm.log"] <quxbam> 124: 1 [xcb-connect! ":0" "localhost"] <quxbam> ?: 0 [connect #<input-output: socket 16> 1 "/tmp/.X11-unix/X0"] <quxbam>ERROR: In procedure connect: Connection refused <davexunit>anyway, it looks like the connection to the X server has been refused <davexunit>I never encountered that error when using guile-wm <quxbam>well, i'm trying to use it in a chroot on a android tablet <quxbam>but at the other hand, it seems that evry other wm works fine <quxbam>for example i3wm or xfce or even gnome <quxbam>but guile-wm is a mature piece of language which i'm interested in learn <davexunit>guile-wm is a way younger project with almost no users, so it's possible that a patch might be needed to support your configuration. <davexunit>that's just speculation, of course. if you continue to have problems, you could try filing an issue with the author, mark witmer. <davexunit>he doesn't respond fast, but he will respond eventually. <quxbam>perhaps I describe the situation a bit more en detail: basically my chroot hasn't got an xserver and when i start something i export DISPLAY=:0 on which a xserver app is listening <quxbam>so the same problem would probably occur if i would use it over ssh -X ... <mark_weaver>quxbam: one important difference between guile-wm and other window managers is that guile-wm uses guile-xcb, which handles talking to the X server directly, whereas most other window managers use libX11 or libxcb to talk the X server. <quxbam>at the moment, yes i3. when starting guile-wm, i get the same error with and without running wm <davexunit>quxbam: I'm afraid I just don't know enough about X to be much help. sorry, I hope you get guile-wm running because it's awesome (if buggy) <mark_weaver>it's possible that guile-xcb makes some assumptions that aren't true on android, and it's also possible that android's libX11 and libxcb have been patched to handle android, but guile-xcb hasn't been. <dsmith-work>quxbam: That may not be the current problem, but you can only run one WM on an X server. <quxbam>my xserver is not run in the chroot, it's a app which i start and which i can sadly not instruct <quxbam>so it's basically a display which listens and takes everything <quxbam>and therefor the file it can't connect to isn't needed at all <quxbam>but it merely doesn't exist, at least with ls it isn't shown <mark_weaver>or it might not be in the chroot; or it might be listening on a TCP socket.. <quxbam>i'll do everything if you instruct me a lil bit more <mark_weaver>quxbam: on GNU/Linux systems, "netstat --listen" will show the sockets that are being listened to. if you can run it, maybe it will give a clue about what socket the X server is listening on. <dsmith-work>Well, on Linux, I'd do a "netstat -lnp" to see what processes are listening on what ports, to see what the Xserver is doing. <daviid>hello guilers! mark_weaver, nice to 'see' you around <quxbam>unix 2 [ ACC ] STREAM LISTENING 41412 @/tmp/.X11-unix/X0 <dsmith-work>The -l is listening ports. The -n is no name resolution, the -p is PIDs <mark_weaver>quxbam: so it looks like /tmp/.X11-unix/X0 is being listened to, but I guess that's not in your chroot. <mark_weaver>probably the usual mature libraries to talk to the X server will fallback to the TCP port, but maybe guile-xcb doesn't do that (yet). <quxbam>hmm, can i instruct it to do that? <mark_weaver>well, it's not quite that simple. the relevant code is in guile-xcb/xcb/xml/auth.scm <mark_weaver>see the definition of 'sock' in there, and the call to 'connect'. it's using AF_UNIX, which means it's connecting to a UNIX-domain socket. the code would have to be extended to connect to a TCP socket instead. <mark_weaver>I don't have time to walk you though the whole process though. <mark_weaver>I don't know much about the X protocol either. it might be that other changes are needed. <quxbam>it's nice that you are so helpful to a stranger :) <mark_weaver>it might be simpler to somehow propagate /tmp/.X11-unix/X0 into your chroot. <quxbam>i already looked outside the chroot for it, but haven't found it <mark_weaver>one obvious way to propagate /tmp/.X11-unix into the chroot is to use a bind mount. <davexunit>quxbam: #guile is a happy place full of helpful folks <quxbam>i've caught the lisp-fire since last august, and it's like an adiction <mark_weaver>quxbam: it might be worth emailing mark witmer, and asking if he'd be willing to add support for connecting to the X server via a TCP socket. <mark_weaver>and it might help to explain the motivation for this... <quxbam>but perhaps it is a bit a too exotic combination <quxbam>perhaps i should accept emacs as my wm <quxbam>by the way, any news about guile emacs? i heard this summer of code they try to finish it... <mark_weaver>bipt (who is sometimes here on channel) is working on it again this summer, but he tends to work with very little outside communication and then give us big code dumps from time to time. I haven't heard an update recently. <quxbam>yes, i've already cloned it, but i thought, that it isn't the main repo <quxbam>considering the low count of devs <quxbam>with such an interesting project <mark_weaver>bipt is the only one really working on it right now, afaik. <quxbam>hmm, that sounds, that it isn't that propably to be embraced by the maintainers <mark_weaver>if I were to hazard a guess, I'd say that there's a lot more work on his laptop hard drive that's nowhere else right now. <mark_weaver>quxbam: we gave him access to the main guile repo, and he merges his work from time to time. <mark_weaver>last I knew, RMS was in favor of rebasing emacs on guile when it's ready. <mark_weaver>(I can't speak for the rest of the emacs community though) <quxbam>good to hear, i'd really love that change <davexunit>I want guile emacs badly, but the rest of the emacs community doesn't seem thrilled. <mark_weaver>I suspect there is concern that scheme will somehow displace emacs lisp, or at least that it will become a multi-lingual community which brings some disadvantages... <mark_weaver>but on the other hand, I suspect that at some point it will become a clear win from a technical perspective, and at that point the opposition will likely become marginalized. <quxbam>the fact, that it will be possible to run emacs programms without emacs is very nice <mark_weaver>for example, guile may be able to run programs like Gnus and W3 a lot faster. <mark_weaver>and there are lots of bindings for external libraries available for Guile. Imagine having access to all of GTK and Gnome from emacs, for example. <quxbam>yep, that would turn emacs into a scriptable vlc player <mark_weaver>I suspect threads will be harder than it seems though, because emacs makes heavy use of global variables that aren't protected by any kind of thread sync. <mark_weaver>you could have threads, but those threads couldn't really access emacs at all. <quxbam>they could be used for in scheme written progs and extensions <quxbam>so it would be already great, hungry functions could be incrementally rewritten in scheme <davexunit>I was just listing off guile features that the elisp interpreter didn't have <davexunit>quxbam: I do worry about writing emacs extensions in scheme. <davexunit>obviously I think scheme is leaps and bounds better than elisp, but I don't know how it well affect the community. <davexunit>on the other hand, should we forever use an inferior language and wait for other editors with more powerful extension languages to take over? <quxbam>at the weekend i nuked the emacs-stack becaus it doesn't optimize tail calls <quxbam>which other editors with more powerful extension languages? <mark_weaver>mit scheme comes with a emacs-like scheme-based editor called "edwin". <mark_weaver>the thing is, it would be an enormous amount of work to rewrite all the great functionality that's in emacs. <mark_weaver>so these other editors seem very primitive by comparison, even if they're built on a great foundation. <davexunit>absolutely. I certainly would not be in favor of ditching elisp entirely. but should we try to slowly phase out elisp and replace it with scheme over the course of many years? <daviid>mark_weaver: speaking of guile-gnome, i'd like to push my patches to the devel branch. i'm close to a new release now, it would be really nice to get it done, so distro could rebase on it [2.16.3] and get rid of guile-1.8... would you have a bit of time to look at those? appart from proof reading, i need help with the last one [i've emailed guile-devel with details ...] <quxbam>i think that this will naturally happen, because of the benefits <mark_weaver>davexunit: it's a good question, and one that's likely to cause worry for many in the emacs community who are very comfortable with elisp and don't yet know scheme. <davexunit>mark_weaver: I've seen the worry first hand. <davexunit>it will have to be a slow evolution, I think. no radical changes that scare people away. <quxbam>yes, but thats possible through the very high compatibility <davexunit>it's a social and political issue more than a technical one. <quxbam>the emacs compiler complains a lot about obsolete functions, which are still supported <quxbam>so that would be a possibility to suggest new behaviour to persons which begin taming that beast <davexunit>another issue is that people could also choose another language besides scheme or elisp that runs on the guile vm to write extensions in. <mark_weaver>daviid: I just finished my housing move yesterday, so I will have some more time finally, but I have a huge amount of high-priority backlog work, not the least of which is upgrading my server to debian wheezy (now that squeeze no longer as security updates for the arch I'm on), and moving my server to a new physical home, since the place it's currently at is going away soon. <davexunit>right now there's not really an alternative, but if javascript or lua support got better... <mark_weaver>daviid: there's also the problem that, again, I'm not very familiar with either gnome or guile-gnome. <mark_weaver>daviid: if wingo doesn't have time to look at it, it may be that we should trust you to do the right thing :) <daviid>mark_weaver: ok, i understand. i'll push soon, it's a devel branch anyway <mark_weaver>daviid: sounds good! sorry I haven't been able to help more. <daviid>mark_weaver: i don't think wingo has time to look at that right now. i fell very confortable with the work i've done, i just need to tweek the last patch or the checking suite <daviid>mark_weaver: it's fine, you've been very busy with so many things... <quxbam>i'll be back later, will toy a bit with my socket