IRC channel logs
2014-03-31.log
back to list of logs
<zacts>mark_weaver: I'm having such a difficult time giving up my modal editing <zacts>will you guys still accept patches if I use evil-mode when editing scheme? :D <mark_weaver>heh. I don't care what editor you use, as long as the code you submit follows our conventions. <mark_weaver>I've never used any of the vi-like modes in emacs. I suspect that you're losing out on many of the advantages of emacs by using such a mode, but that's your business, not mine :) <mark_weaver>in particular, 'paredit-mode' has dramatically improved my productivity editing scheme code, and I don't know how you'd use it in evil-mode. <mark_weaver>(though I should warn that paredit has a steep learning curve) <zacts>mark_weaver: I don't mind steep learning curves, I'm coming from vim and I know about emacs. I'm a nerd. <zacts>(I was j/k btw) But yeah, I do like modal editing. <zacts>mark_weaver: I'm looking at contributing to emacs evil-mode. I'll try it with geiser and paredit. <nalaginrut>Is there any way to disassemble a delimited-continuation object? I tried ,x but it shows no info available <ArneBab>zacts: to get modal editing, you could also look at control-lock-mode and god-mode <ArneBab>zacts: I generally use control-lock-mode for spell-checking: hit äü to enable control-lock-mode (via key-chord-mode) and then just hit , to go to the next mistake and . to cycle through the corrections. <ArneBab>mark_weaver: do you still have a few minutes (or are you short of heading to bed)? <civodul>and a new "Sponsored by the Free Software Foundation"... <nalaginrut>ijp: it's too bad, I fixed my program. The fixed semantic of shift/reset can't work under Guile, but it works on Racket. <nalaginrut>And the old version can run on Guile but not Racket <nalaginrut>ijp: anyway, I think it's my problem when I mixed 'abort' and shift/reset <roelj>I added a guile interpreter to my C program and defined some extra functions for it, but now I'd like to load a script that uses these extra functions that are only available when guile is loaded from my program.. Is there a way to do that? <artyom-poptsov>roej: Hi! If I understood you right, you have a C program that uses libguile and you want to use your functions from a Scheme script. <bhattigurjot>hello, I wanted to ask how much of a work is to upgrade a software from old guile (1.6) to the latest one? <bhattigurjot>What would be the best way to do it? I mean the workflow, how shall I proceed with it? <ArneBab>bhattigurjot: did you embed guile into your program? <bhattigurjot>ArneBab: actually it is not my program, there's an old software available and I'm trying to upgrade it <ArneBab>I can’t really give you all info I’d like to (being a newbie to Guile myself), but I hope I can help with a few questions… <ArneBab>bhattigurjot: for deeper knowledge you’ll have to wait for wingo, ijp, mark_weaver or some other experts <wingo>bhattigurjot: the first thing to do is to read NEWS, it has all the details <ArneBab>did you try to just build the program with the new guile? (there were a lot of changes since 1.6) *ArneBab better stops giving possibly wrong advice <bhattigurjot>wingo: there are lots of news files there for each update.. shall I go through them all starting from 1.6? <civodul>bhattigurjot: if it has C code, the switch from 1.6 (last release 10 years ago) to 2.0 will be a bit of work <wingo>bhattigurjot: yes, i'm afraid that's the thing to do <civodul>if it doesn't, it might just work or need reasonable adjustments <civodul>the C API changed noticeably in the 1.6->1.8 switch <bhattigurjot>civodul: how shall I check the amount of guile being used in the code? <lloda>you have to look for all the functions that start gh_... <lloda>replace them by modern equivalents scm_... <ArneBab>wingo: damn, I read the NEWS myself, and now I really, really want to use guile 2.2… ☺ <bhattigurjot>lloda: ok.. so how do I setup my environment? Use a virtual box.. install guile latest... and try to compile the software to see the error? <ArneBab>and I hope, there’ll be a guile-emacs GSoC project again - which then finally gets guile-emacs into prroduction <bhattigurjot>for instance: gh_new_procedure should be replaced with scm_new_procedure ?? <lloda>bhattigurjot: environment, that could work. I just define GUILE=... before configure/build so I have different versions side by side. <lloda> bhattigurjot: for the functions, look at the NEWS as wingo said. Some functions are just named differently now, not just gh_ -> scm_. For example if you look up gh_int2scmb, you'll see this line in NEWS: 'gh_int2scmb - replaced by gh_bool2scm'. <lloda>It's probably useful to have the docs for both 1.6 and 2.0 side by side. <bhattigurjot>lloda: okay.. and I was just using the grep command to see where is this guile-1.6 specified <lloda>You mean to do #ifdef GUILE_2 and such? I've never done that myself. <lloda>well if you need to do things where different versions are incompatible, then you would need to do it. But not otherwise. <bhattigurjot>in aclocal.m4 file here it checks for the guile_progs, guile_flags, guile_check, guile_module_check... <bhattigurjot>these checks, do they check for the version or just the guile availability? <lloda>you can check for the version too. For example in guile-figl:configure.ac you see <lloda>but there are other older macros... <lloda>honestly I've never checked for the version, after I upgrade I forget about older ones :-/ <bhattigurjot>in my software, there is no GUILE_PKG ... just GUILE_PROGS <bhattigurjot>where it set paths to Guile interpreter, config and tool programs <bhattigurjot>so I guess I don't really have to worry about setting the guile version in the code <lloda>it's just that when something doesn't work (compile failure, likely) you won't immediately know that it's because Guile is too old. But other than that, I don't think so. <bhattigurjot>okay.. so first step I should follow is to set up my env. with latest guile and see what's the first error I encounter.. <wingo>though i would recommend reading NEWS first :) <bhattigurjot>ok.. thankyou .. what is the general time everyone is available on IRC? <ArneBab>wingo: I just saw that you updated this in master, replacing the “imperfect emacs lisp-support” with “excellent emacs lisp” <davexunit>bhattigurjot: you should used 2.0.11. it is the latest stable release. <mark_weaver>bhattigurjot: "./configure && make && make check" is usually reasonable for most users. <mark_weaver>bhattigurjot: if you do "apt-cache show guile-2.0", what version number is shown? <mark_weaver>bhattigurjot: "apt-get build-dep guile-2.0" should install all the build dependencies you need. <bhattigurjot>mark_weaver: in my gsoc proposal I set my milestone of 10 days to upgrade the guile library.. do you think it's sufficient? <mark_weaver>also, what version number does "apt-cache show libgc-dev" report? <mark_weaver>you mean converting Dr Geo to use guile 2? I'm sorry, I have no idea. It depends how much code there is in Dr Geo, your experience level, and how efficiently you work. <bhattigurjot>also "apt-get build-dep guile-2.0" shows "E: You must put some 'source' URIs in your sources.list" <mark_weaver>bhattigurjot: so you need to edit the file(s) /etc/apt/sources.list, and possibly the files in /etc/apt/sources.list.d/*, and for every line that starts with "deb ", insert a line below it that's exactly the same except with "deb " replaced by "deb-src " <mark_weaver>bhattigurjot: yes, you should compile guile-2.0.11 from source code. but in order for "apt-get build-dep" to work it needs to know about the build dependencies, which are in the source package index. <mark_weaver>after you make those edits to /etc/apt/sources.list, run "apt-get update" and then try the "apt-get build-dep" command again. <mark_weaver>bhattigurjot: good! now I'd suggest "./configure && make && make check" in a freshly unpacked guile-2.0.11 <bhattigurjot>mark_weaver: what's the usual time that I can catch you on IRC? <bhattigurjot>mark_weaver: its suck at " GUILEC ice-9/psyntax-pp.go " from 7 minutes or so <mark_weaver>bhattigurjot: be patient, it takes a while to bootstrap <mark_weaver>guile's compiler is written in guile. at this point, the compiler is being interpreted, so it's very slow. <mark_weaver>it gets progressively faster as more modules of the compiler are compiled. <ijp>it's not stuck, it's digesting <bhattigurjot>ok.. yeah its progressing but really slowly.. and does " make -j4 " instead of "make" would have any difference? <ijp>not as much as you'd think <ijp>once boot-9 and psyntax are done, it'll speed up <mark_weaver>bhattigurjot: you'd also find that after everything else is compiled, if you needed to recompile psyntax-pp.go it would be fairly quick. <mark_weaver>but when the entire compiler is interpreted, it's very slow. <mark_weaver>I actually have a trick I sometimes do, when I want to recompile everything (e.g. because of a compiler optimization improvment): I delete each .go file individually and remake it, one by one. much faster. <mark_weaver>from the module directory, I do something like: for file in $(find . -name \\*.go); do rm $file; make; done <dsmith-work>mark_weaver: Do you ever run into dependancy issues with that? <mark_weaver>dsmith-work: If there's a problem, I'm not aware of what it would be. <mark_weaver>bhattigurjot: I haven't measured it, but several times faster at least. <wingo>mark_weaver: usually when i want to do that i "touch module/ice-9/eval.scm && make -j8" <wingo>and if i don't want to wait on eval.scm recompiling, i touch the .go instead <dsmith-work>mark_weaver: Oh, I don't don't know. Something like it comples soeme thing first usign the old .go files without the advantage of the just introduced changes/advantages. <mark_weaver>dsmith-work: I could imagine extreme cases where this wouldn't work, e.g. for macros that expand into macro definitions, if those macros are changed to generate different macro definitions, this trick method might not quite do the right thing. <mark_weaver>e.g. you might use an old .go file that had the old version of the macro-generating-macro. <mark_weaver>oh, if you double-clicked in some GUI program, it might launch some fancy log viewer program or something. <bhattigurjot>yeah.. "Could not open the file /home/scott/guile-2.0.11/check-guile.log." <mark_weaver>bhattigurjot: no, XFAIL doesn't count. don't worry about that test. <mark_weaver>bhattigurjot: now "sudo make install" and "sudo ldconfig" <bhattigurjot>"sudo ldconfig" gives "/sbin/ldconfig.real: /usr/local/lib/libguile-2.0.so.22.7.2-gdb.scm is not an ELF file - it has the wrong magic bytes at the start." <mark_weaver>bhattigurjot: most likely, it's because your internet service provider has a hacked name server that always redirects you to their web page when you type in a non-existent host name. <mark_weaver>btw, unfortunately you'll get that warning about "libguile-2.0.so.22.7.2-gdb.scm" every time you install a new package that contains a shared library. it's a harmless warning, but if it gets on your nerves too much, you can remove the file for now. <mark_weaver>it enables nicer debugging with very recent GDB that supports integration with Guile, but your GDB is probably too old for that anyway. <mark_weaver>the proper fix will probably be to fix 'ldconfig' to be more tolerant of non-ELF files in /usr/local/lib <mark_weaver>alternatively, maybe people will pressure the GDB folks to look for that file in a different place, dunno. <mark_weaver>yes, and I still don't understand what you're asking. <bhattigurjot>oh well you said a proper fix is to make 'ldconfig' more tolerant of non-ELF files .. I was asking how should I do that? <bhattigurjot>do i need to make some changes regarding that or this is something else entirely? <mark_weaver>I'm not suggesting that you do that, and I don't know the answer off hand. <mark_weaver>the developers of GDB and ldconfig will hash it out, I suppose. <bhattigurjot>here;'s the make error for drgeo now: ../drgenius_config.h:28:22: fatal error: guile/gh.h: No such file or directory <mark_weaver>I can answer some questions, but I don't have time to walk you through the entire process. <bhattigurjot>what would be the ideal way to move now.. change the syntax and code (taking help from the manuals) wherever I encounter the error in make process or first go through the news and manuals? <mark_weaver>bhattigurjot: if you look in the NEWS file in guile-1.8.x, you'll an entry "The GH interface is now subject to the deprecation mechanism". In there is mentions a section of the 1.8 manual "Transitioning away from GH". I suggest you start there. <bhattigurjot>sed command ... will that be helpful or is it too extreme? <mark_weaver>I would instead use a decent editor. for one thing, 'sed' will not reformat the code properly in most cases, e.g. for multi-line expressions. <mark_weaver>also, in many cases the calling conventions are different, so it's not a simple find/replace. <mark_weaver>in general, when it says "use XXX instead", that doesn't necessarily mean that the calling convention is the same. <mark_weaver>well, I don't know. maybe they call attention to cases where the calling convention is different, I'm not sure. <mark_weaver>(I never used the gh interface; that was before my time here) <bhattigurjot>okay.. so it's better to do it manually with a help of grep <saul>bhattigurjot, one of the things that people have encountered when migrating software to Guile 2.0 is that macros can no longer be referenced before they've been defined. <mark_weaver>fwiw, most experienced programmers use either emacs or vim. there's a bit of a learning curve to both of them, but I think you'll find that the time spent learning them will be very well spent. <saul>bhattigurjot, are you working on migrating Dr Geo to Guile 2.0 ? <ijp>in soviet russia, emacs learns you <mark_weaver>(IMO, emacs is by far the best editor, but this is a controversial topic and many prefer vim) <ijp>as long as you agree that eclipse is the great satan, we're cool <mark_weaver>fwiw, I used 'vim' as my primary editor for many years, so I have some standing to make a fair comparison between vim and emacs. <bhattigurjot>mark_weaver: I'll take your word for it.. I've never used emacs.. <mark_weaver>saul: IMO, we shouldn't overwhelm bhattigurjot with these details at this time. Those issues may not even arise in this case. <mark_weaver>the first step is to change the C code away from the GH interfaces. then we can cross other bridges as we come to them. <dsmith-work>bhattigurjot: fwiw, I went throught the upgrade procsess with scwm. It was at guile 1.4.x, now at 2.0. Going though the changes I made might help. <dsmith-work>Some things are not obvious, like using scm_is_eq instead of ==. <bhattigurjot>I think its better I start doing it now... it seems quite a long process <dsmith-work>When something is deperecated but before it is removed, the the something is often just a wrapper around the new way. <dsmith-work>When skipping versions, (like 1.4 -> 2.0) it's useful to get the intermediate versions and examine those wrappers as a reference. <dsmith-work>I don't remember exatly what it was, but I did need to do that. <dsmith-work>Like the 1.6 replacement for a 1.4 function doesn't exist in 2.0, because IT was deprecated in 1.8. <bhattigurjot>But I think the second one would be more time consuming.. no? <mark_weaver>one issue is that I will be less able/interested to help you debug problems with 1.8, since I've never really used it myself. <dsmith-work>Personally, I'd just do the big leap and then handle the edge cases as needed. <mark_weaver>bhattigurjot: out of curiosity, what is the larger GsoC project of which this upgrade is a part? <bhattigurjot>o my.. i should sleep now.. its pretty late and I've a test tomorrow... thankyou everyone so much for you help ^_^ <ArneBab>davexunit: what I wanted to say on licensing last week: My requirement is copyleft and GPL-compatible. If you’d want to use the text along with cc by-sa, I would not mind dual-licensing. <davexunit>ArneBab: was this for the write-up about coroutines? <didi>Is `[]' synonym of `()'? I'm having difficulties finding it in the manual. <didi>mark_weaver: Oh, can you change it? Also, is there other characters in this set? <mark_weaver>there are no other brackets that can be made equivalent to () in the standard reader. <didi>OK, I found (info "(guile) Read/Load/Eval/Compile") which might help. <mark_weaver>at present, there are only APIs for configuring it globally, which is a bad idea because it violates modularity. <mark_weaver>(i.e. changing the 'read' options globally might affect the behavior of other code) <mark_weaver>I've done some work to improve this situation, but it's a work in progress. <mark_weaver>so far, the only read options that can be reasonably tweaked within a single file without affecting other code are case-sensitivity and curly-infix (SRFI-105) mode. <zacts>mark_weaver: I've discovered that there is indeed an evil-paredit mode that is 98% functional. <zacts>so it looks like I can retain my modal editing when editing with scheme. sometimes I may do m-x, but I have an alternate binding for that that doesn't use meta. <dsmith-work>The test-out-of-memory on master is failing for me. 64bit. "Bad GET_MEM arg" 