<davexunit>djcb: nice! it will be great for some distros to finally have guile 2. <ijp>Do those sentences work well separately, or should I try and make a paragraph out of it? <ijp>they seem fine in plain text/info, but for the pdf, not so much ***sneek_ is now known as sneek
<dsmith>mark_weaver, Well, not that someone would do this, but: scm_t_port port_pair[2]; <mark_weaver>dsmith: okay, but then what do you do with it? there are no public APIs that have scm_t_port arguments. <dsmith>mark_weaver, The old problem with 1.8 in Debian without threads was because the size of some struct changed. <dsmith>mark_weaver, Whoo. I don't remember. Something that changed size when configured --with or --without threads. <nalaginrut>mark_weaver: I thought our current 'let' is the same with 'letpar', or not? <mark_weaver>obviously it's not safe in the general case. in this case, there are no public APIs with scm_t_port arguments, and only guile is allowed to allocate it. <nalaginrut>mark_weaver: well, according to the manual, it's let but work on parallel bindings <nalaginrut>mark_weaver: please concentrate on your current work ;-) <mark_weaver>no, with letpar, the initializers run in parallel, potentially in separate threads. <dsmith>mark_weaver, I do think that as long as compiled user code can't know the sizeof the thing, and that the visible members are all at the same offsets, it should be no problem. <mark_weaver>dsmith: in this case, the user could ask for the size of a scm_t_port, but then what do they do with that? <mark_weaver>anyway, it looks like we're not going to do it that way anyway. <nalaginrut>mark_weaver: last question, does let binds vars in parallel? <dsmith>mark_weaver, RIght. I can't imagine what. <mark_weaver>nalaginrut: it depends what you mean by "parallel". the initializers all run in the same thread in a 'let'. in some unspecified by serializable order. <mark_weaver>nalaginrut: let binds in parallel in the sense that you can do (let ((x 1) (y 2)) (let ((x y) (y x)) (list x y))) => 2 1 <mark_weaver>but 'letpar' runs the right-hand-sides potentially in separate threads... thus in "parallel" in a different sense. <nalaginrut>so x and y could be evaluated in the same time in the same thread in let? <nalaginrut>I think your "parallel" means runs on different threads <nalaginrut>but my "parallel" is "maybe evaluated in same time" <dsmith>nalaginrut, How can it be at the same time unless in different threads on different cores? <nalaginrut>so let won't bind in parallel, right? only letpar does that? <dsmith>Hmm. Nothing to *prevent* let from evaluating bindings in parallel. <dsmith>iirc, there is no specified order. Could be different from one let to another. <nalaginrut>well, the aim to my question is about the performance, if 'let' could bind in parallel, I wonder how to use 'letpar' <dsmith>(let ((v e) ...) body ...) is pretty much identical to ((lambda (v ...) body ...) e ...) , right? (sure hope I got that right) <dsmith>And function application has no defined order. <nalaginrut>so 'let' won't bind in parallel, but bind order may different, right? <dsmith>I think let makes no guarantees. let* does. *nalaginrut have to read manual in detail again, since the manual updated much since then... <dsmith>nalaginrut, I think that's so implementors have freedom to things. <mark_weaver>nalaginrut: there are different meanings of the word "parallel". <mark_weaver>nalaginrut: latpar means "parallel" in terms of concurrent execution in different threads. <nalaginrut>mark_weaver: alas, it's so hard for me since I'm not a native English user ;-P <mark_weaver>'let' is parallel in the sense that all of the variables are *bound* simultaneously, even though the right-hand-side expressions are evaluated sequentially (though in an unspecified order). <dsmith>mark_weaver, Sequentially? Not in some possibly random order? <mark_weaver>nalaginrut: you might think that you should use 'letpar' whenever possible, because concurrent execution is good and potentially more efficient, but beware that you pay a heavy price in thread synchronization costs whenever you do anything involving threads. so it only makes sense if the right-hand-side expressions are already fairly expensive to compute. <cky>mark_weaver: What about if parallelism uses places? <cky>mark_weaver: Surely that's a huge improvement over using shared memory. <mark_weaver>dsmith: take the right hand sides, and shuffle them. the implementation is allowed to pick a different order each time it is evaluated. however, once that random order is chosen, they must be evaluated sequentially. <mark_weaver>e.g. in (let ((x (foo)) (y (bar))) (list x y)), either (foo) will finish executing before (bar), or (bar) will finish executing before (foo). <nalaginrut>OK, I see, so the par-* family functions should use in a scenario that each item needs rather harder computation, or it's totally no need to use it, since it's slower than do it sequentially <mark_weaver>cky: no matter what you do, there is a heavy cost in today's stock hardware. <nalaginrut>mark_weaver: do you think par-map/par-for-each is suit for server request handling? <dsmith>Ok, so implementations are *not* free to automatically evaluate the expressions in multiple threads, possibly in parallel, <mark_weaver>dsmith: correct.. not with 'let' or procedure calls. <dsmith>I thought I read that somewhere it could. Maybe it was a proposal to allow it? <mark_weaver>dsmith: I can't imagine such a proposal would have gotten anywhere. <mark_weaver>cky: the thing is, at the very least, you need to synchronize between threads when to join them before running the body of the letpar. <mark_weaver>dsmith: what I should have written is: e.g. in (let ((x (foo)) (y (bar))) (list x y)), either (foo) will finish executing before (bar) BEGINS executing, or (bar) will finish executing before (foo) BEGINS executing. *mark_weaver works on merging stable-2.0 to master <mark_weaver>we should really do this more often. such big merges are a pain. <mark_weaver>note that github is a particular website that we don't use for guile <sw2wolf>what's the version of master branch ? <sw2wolf>why do we need to checkout stable-2.0 ? <mark_weaver>master will eventually be 2.2, but it's a work-in-progress. I recommend you use stable-2.0 for now. <mark_weaver>actually, we are doing most of our development work directly on the stable-2.0 branch, and only occasionally merge those changes to the master branch. so stable-2.0 is actually more cutting edge. <sw2wolf>i ever downloaded 2.0.7 which cannot work on FreeBSD <mark_weaver>I vaguely recall that there are some unresolved issues with threads on freebsd, but I'm not sure. <sw2wolf>yeah, i am still using 1.8.x under FB <mark_weaver>IMO, the advantages of 2.0 are quite compelling. unless you really need threads, it's probably worth upgrading anyway. <sw2wolf>I install guile-1.8 from FB packages. And in our codes, we ever used (make-tread ...) call ? <sw2wolf>anyway it is better to use guile with thread support <mark_weaver>all other things being equal, perhaps. but 2.0 is vastly superior to 1.8. <sw2wolf>If there is (make-thread ...) call, whether or not we need threaded guile ? <sw2wolf>it doesnot matter. guile-1.18.x works great now. i just want to test 2.x. <wingo>good evening, mark_weaver :-) <wingo>you are a valiant individual <mark_weaver>everything seems good, but I'm getting two ERRORs and a FAIL in sxml.simple.test <mark_weaver>I seem to recall seeing that in stable-2.0 at some point in the past. <wingo>about encoding and latin-1 but non-ascii characters? <wingo>yeah, i would ignore the issue for now -- i/we can fix it later i think <mark_weaver>maybe. I remember coming across the patch that implemented the environment variable for setting the locale, and concluding that I could just skip it in master. <wingo>mark_weaver: master needs that patch <wingo>it will just have a different default <mark_weaver>so the environment variable can be used to avoid setting the locale, and the test depends on that? is that the issue? <wingo>no, that test is related to the default encoding on string ports, i think <wingo>and also, master is more strict than stable-2.0 about ascii versus latin-1 <mark_weaver>but we need that patch because we want to be able to disable the locale-setting behavior via the env var? <wingo>you can still have a locale that can't represent all characters <mark_weaver>would it be possible to postpone 2.0.8 until early next week? maybe monday or tuesday? <wingo>mark_weaver: fine with me, fwiw; tuesday maybe. dunno if civodul has holiday plans next week? <civodul>Monday would be a bad idea (April 1st) <civodul>and i won't be avaiable on Tue evening <mark_weaver>wingo: given that master will install the locale by default, should I remove the explicit GUILE_INSTALL_LOCALE=1 bits during the build? <nalaginrut>will you consider apply colorized-REPL in 2.0.8? If answer is negative, I'll modify it for guildhall <nalaginrut>hmm...how can I check the version and throw out a error if users don't use 2.0.8? <mark_weaver>it's better to check for the functionality you need directly. <mark_weaver>iirc, guile provides the precise version number only in string form. <mark_weaver>or just don't worry about it, and tell users that it won't work in earlier versions. <nalaginrut>mark_weaver: users don't read README or manual you know, even me, I haven't read Guile manual for a while... <mark_weaver>isn't there a hook that you use? can you just check for that hook somehow? <nalaginrut>so I think throw an info then quit is better while they run it <nalaginrut>I'm not sure if I put the check in activate-colorized, and it's called from ~/.guile <mark_weaver>you could perhaps use 'eval-when' to check at compile time <mark_weaver>wingo: okay, I pushed the stable-2.0 merge to master. would you like to look into the sxml.simple.test problems? <mark_weaver>btw, you'll need to clear out language/tree-il/*.go, due to the usual issue with macro dependencies. <ArneBab>is there a way to disable the initial notes from guile? <ArneBab>this stuff: ;;; note: source file /tmp/wisptmp.scm <ArneBab>civodul: yes. Being frustrated with the direction of readable was the reason why I wrote wisp. <ArneBab>civodul: Readable added more and more syntax to optimize for fringe cases and for me that killed the simplicity of lisp. <civodul>i wonder if there's "enough room" for two competing approaches <civodul>ArneBab: back to your original question, there's `current-warning-port' <ArneBab>civodul: different goals. I don’t know, but I actually don’t care. Wisp can be used as simple preprocessor, so there is no need to get support from existing interpreters - except from being able to pass lisp code via stdin. <ArneBab>civodul: where would I put that? .guilerc <civodul>yes: (current-warning-port (%make-void-port "w")) <ArneBab>civodul: it seems that I have to actually put -l ~/.guile into the script <ArneBab>civodul: but now it works. Thank you! <civodul>~/.guile is only read when running an interactive guile, and without -q <ArneBab>civodul: actually there aren’t only 2 competing whitespace-lisp ideas. There’s already SRFI-49, and I think there were some other experiments. <ArneBab>wisp differs by being simpler (just a preprocessor), but if it should not become the dominant indentation based lisp, then it simply joins the other 99% of languages people created. <ArneBab>civodul: the cool part is that I can already program in wisp now, and I can harness all the power of guile. <wingo>mark_weaver: i'll take a look at the sxml things <ijp>nalaginrut: I'm increasingly concerned that you are taking a cargo cult approach to performance <ijp>that might be unfair, but as always, please make sure you are taking the time to profile your program, and making changes where it can actually matter <ijp>civodul: I am _shocked_ to learn that it has taken us this long to document and=> <civodul>it had been reported by Guix people who were unfamiliar with that <taylanub>Is libtool required when using ./configure --enable-shared=no ? Is there more I need to do to disable shared libraries ? ***sneek_ is now known as sneek
<cky>ArneBab: Preprocessor? That sounds terrible, since both SRFI 49 and "readable" are reader replacements, not preprocessors. <cky>ArneBab: Preprocessing seems to add an extra step, whereas the workflow for a reader replacement is the same as the standard workflow, just with a different reader. *ijp is sceptical that anyone can write a non-ugly indentation-sensitive lisp <cky>ijp: Well, ugly is subjective, so.... <cky>ijp: People who are used to S-expressions will probably find anything else ugly. ;-) <cky>Too bad sw2wolf is gone. I was going to tell them that I do mirror the Guile repo onto GitHub, but only the stable-2.0 branch, and only when new releases are tagged. <ijp>well, one issue is that, in the presence of macros, you can't limit it to specific forms <ijp>since people will write forms that expect to be able to take advantage of it <ijp>but, I don't think it can work for arbitrary sexps <ijp>i.e. I don't think lisp has enough syntax for it to work <cky>ijp: Are you talking about "readable", or ArneBab's thing? <ijp>readable and srfi 49 <cky>ijp: Really? I thought that readable can handle all forms. <ijp>I never claimed otherwise <ijp>cky: actually, that's why I find it objectionable <civodul>from the Serveez announcement: "Unless there is a major outcry from users (unlikely), the next release will drop (all pretense of) support for Guile 1.3.4." *civodul wonders if he was born when 1.3 was released <wingo>i honestly wonder if ttn's fork has any non-ttn users <wingo>though imo we should remove that dep ;) <taylanub>I'm trying to cross-compile for iOS, and it complains that it can't find GNU libltdl... <cky>Isn't libltdl just a layer atop libdl or something like that? <taylanub>It sounds wrong to depend on that even when --enable-shared=no is given to ./configure. <wingo>dependency is the nature of dependencies <cky>taylanub: I thought --disable-shared just makes libguile static, but it still can load dynamic modules. *taylanub doesn't know autotools very well. <civodul>it's not autotools, it's your friendly configure script :-) <taylanub>The several layers of file-generation involved in the GNU build system is still very unclear to me. I guess theoretically you could do everything with a Makefile, but then it would be full of platform-checks, so OK, you have a configure script that generates a Makefile from a template Makefile.in (although in truth it first generates config.status, to do that?). But then there's configure.ac to generate the configure script, and <taylanub>Makefile.am to generate the Makefile.in ... WTF ? :P <taylanub>Hahaha, I just opened the autoconf Info manual, and saw the quote at the start of the Introduction section. <cky>taylanub: configure.ac is expanded into a bunch of files (including configure) using some m4 scripts. <cky>taylanub: Makefile.am is expanded into Makefile.in, which is Makefile with some substitutions that configure have to perform. <cky>taylanub: configure is much much much bigger than configure.ac, and Makefile.in is much much much bigger than Makefile.am. <muep>afaik some build their Makefile.in files by hand without automake <taylanub>I know that FFmpeg and MPlayer2 use hand-written configure scripts. <cky>The auto-generated ones have an advantage in that they're really using a DSL, which means they're easier to review. <cky>Well, I mean the source versions are easier to review, not the generated ones. ;-) <taylanub>Hrm, I think I start to understand. A DSL simply has lots of advantages over writing a configure script (which is in sh) manually. Then comes the question why we don't directly use a DSL to transform a Makefile.in into a Makefile, or even use an alternative Makefile format, to which I guess the answer is that sh and make are standard Unix tools and a developer can simply deploy the output configure and Makefile.in files instead of <taylanub>requiring the users to install non-standard tools ... <muep>there are also some quite well known solutions which generate Makefiles more directly from a DSL <taylanub>I reckon some pieces of software require having a special make-alternative installed. cmake comes to mind. <taylanub>And SCons, and Waf. (Looking at the CMake page on Wikipedia ..) <lloda>I switched to SCons after a bad experience with Automake <lloda>I just wish it was in Guile instead of Python <cky>I'm sure Guile will have its own Guile-based make system soon. Just like in the Ruby world there's Rake. <civodul>it can be used like Make, even if that's not the primary application <taylanub>How do I find out how much memory a function-call used ? E.g. I wrote a tail-recursive function which actually still uses as much memory as the non-tail-recursive version, because it piles up a stack of lambdas each calling the next in its body, so the ,trace output is misleading, so to say. <stis>The best is to to a theoretical analysis of the program, but typically you win memory. <stis>Also in guile it is awkward to pile up a hugh stack! <taylanub>(I guess I kind of confused myself there; stack-growth is only a very specific kind of memory-usage, of course.) <wingo>(h(gcprof (lambda () (map list (map list (iota 10000000))))) <civodul>mark_weaver: i just pushed a fix for GMP < 5, but i only tested with 4.3.2 <mark_weaver>I don't know, we'd have to try running numbers.test on a guile built with 4.1 <civodul>i mean, would it /build/ with 4.1? :-) <mark_weaver>I remember wanting to add support for exact roots (other than square roots) and getting nak'd because we had to continue supporting an old version of GMP. but I don't remember the details. <mark_weaver>but I confess I haven't been very careful about making sure that 4.1 supports the GMP functions I've been using in new code. <mark_weaver>OTOH, 4.1 is extremely old, as in the last version of Debian that had a version that old has been moved to the archive. <mark_weaver>I suspect that almost no one is running such an old version. <mark_weaver>well, the above is from vague memory, don't take it as reliable information. <mark_weaver>so GMP 4.2 was released in March 2006, and has been in Debian since sarge. <mark_weaver>so yeah, I'd be really surprised if anyone would be bothered by dropping support for 4.1 <mark_weaver>I'd be glad if we could just forget about GMP 4.1, so I could add exact roots to stable-2.0. <mark_weaver>Four Debian stable releases ago, in case that wasn't clear. The most recent Debian release that didn't have GMP 4.2 or later was Debian woody, released in July 2002. <civodul>so i'm fine with requiring something later than 4.1 <mark_weaver>oops, I see that I corrected myself in a followup to that post I just referenced. actually sarge was the most recent debian release that didn't have GMP 4.2 or later. sarge was released in June 2005. <civodul>everything works fine on FreeBSD 8.2 (but with an old pre-7.2 libgc) <mark_weaver>from what I can see from that old thread, I'd be happy with GMP 4.2 being the minimum required version. <civodul>so wingo, your thread-related fix did the trick <dsmith>Oh no! Someone is trying to ./configure PKG_CONFIG=true <civodul>mark_weaver: ok, then i update README and NEWS <wingo>civodul: the freebsd one? excellent! <wingo>score one for shots in the dark <wingo>and for premature bug-closing ;) <mark_weaver>I was just talking to a freebsd user on this channel in the last day or two who would have been happy to know that. <wingo>that patch was made with both hands ;) <mark_weaver>sneek: later tell sw2wolf apparently stable-2.0 can now be built with threads on freebsd :) <cky>mark_weaver: Maybe I should mirror that commit through to my cky/guile GitHub repo so sw2wolf can use it. ;-) <cky>mark_weaver: since they seem to like using GitHub. :-P <civodul>wingo: i did spend some time on it back then, with access to the machine, but i was clueless <mark_weaver>cky: I really don't see why we need a github mirror. <cky>mark_weaver: It's my private unofficial mirror. <mark_weaver>cky: and I don't get the impression that he cared.. he just asked the question sloppily. <wingo>civodul: many eyes, shallow bugs, & such platitudes <cky>mark_weaver: Just a place to put in my private branches. <wingo>i think i looked at other instances of cond_wait, but would be good for someone else to double-check <cky>wingo: cond_wait? Is this to do with fixing up the spurious wakeups? :-) *cky will be happy to review, as will mark_weaver (I'm sure). :-) <mark_weaver>civodul: oops, thanks for catching my use of GMP 5isms.. ugh. <mark_weaver>also, I think I should just change mpz_inits to multiple calls to mpz_init. more efficient. <civodul>i don't think it'd make a big difference <mark_weaver>maybe not, but I only use mpz_* calls directly in places where I'm worry a lot about the overhead (which is already more than I'd like). and mpz_init and mpz_clear are preprocessor macros as I recall. <mark_weaver>anyway, I'll make sure to test building against an old libgmp in the next couple of days. <jaaso>Is (gnome gdk) installed with guile-gnome. Wierd can not find it