<rlb>mark_weaver: for example, I'd imagine that having a pre-generated/cached hash-code for every string may help quite a bit wrt perf when you're dealing with strings as members of hash-sets and hash-maps. <mark_weaver>hmm. strings are mutable (unfortunately), and that presents complications, especially when one considers multiple threads. <mark_weaver>well, maybe it does. I'd have to think about it some more. <mark_weaver>yeah, so I think the problem is this: if strings include a cached hash, then we either have to update the hash every time the string is modified, or we have to empty the cache and then lazily regenerate it and store it when the hash is computed for that string. <mark_weaver>and then 'hash' essentially becomes a writer for that string object, and then you can no longer assume that it's okay for multiple threads to ask for the hash of a string without thread synchronization. <mark_weaver>so I think it's problematic, at least as long as we have mutable strings (which we'd love to get rid of eventually) <mark_weaver>basically, we'd have to make 'string-set!' recompute the hash, and that would make it an O(n) operation. <rlb>mark_weaver: wasn't even thinking of mutable strings -- have to fix that too for the clojure dialect (and then we can just add it to the clojure/guile string rep) <mark_weaver>in typical scheme programming, it's fairly rare to mutate strings. <rlb>and we'll probably just have something like the cljs to/from guile conversion functions <mark_weaver>and when it is done, it is usually done within some internal variable of a procedure. <rlb>i.e. convert any incompatible clojure data structures to/from their guile "counterparts" <rlb>(strings being the first obvious one) <mark_weaver>so you could simply declare that guile-clj assumes that any strings used by it will henceforth not be mutated. <rlb>more thinking of using an immutable wrapper that (if we decide it's important) also pairs the perhaps native guile string with a hash-code -- but really just speculating wildly atm <rlb>is srfi-9 a likely candidate for fairly efficient new types (for now)? <mark_weaver>rlb: you can make a read-only copy of an existing string using (substring/read-only str 0) <rlb>ok, good -- though may still need to wrap other bits with it <mark_weaver>if the original string is later mutated, it will be copied (copy-on-write) <rlb>anyway have to go for now -- bbl *rlb also needs to post some target.scm patches for review and/or commit <rlb>I need to get back up to speed wrt how upstream guile commits should be handled these days <rlb>i.e. may still have commit rights, but I don't suspect I should just start committing ;> <mark_weaver>rlb: please post patches to guile-devel in "git format-patch" form. <mark_weaver>please don't commit until you get okay for a maintainer (wingo, civodul, or I) <daviid>hum, seems like guile-clutter get-*color methods, gooping core get_*color clutter procedures|functions are not properly wrapped by default, unlike set-*color methods, will have to fix that <daviid>just speaking loudly :) have to run, bbl <rlb>mark_weaver: of course -- wouldn't think of it (wrt commit) -- just didn't know what the current process was yet. <paroneayea>bipt: your email update to the emacs-devel list was just really, really great :) <ijp>okay, but since I have seniority here, richi235 will be first to go <ijp>((lambda (i j s) `(,s ,j ,(+ i j) ',s)) 0 1 '(lambda (i j s) `(,s ,j ,(+ i j) ',s))) <ijp>I'd want to benchmark it against fingertree backed sequences though <ijp>rlb: I have a module called fectors that you might be interested in <ijp>it's in a separate repo because it is not actually persistent, but semipersistent <zRecursive>I donot know why i donot want to use Scheme since i have been using CL ? <sneek>Welcome back zRecursive, you have 1 message. <sneek>zRecursive, mark_weaver says: I didn't know it at the time, but Guile includes a predicate 'unspecified?' that does (eq? x (if #f #f)), so you can use that. <ijp>rlb: anyway, if you don't want either (pfds sequences) or (fectors), I could implement clojurish vectors, but probably not till tomorrow, or sunday <ijp>friday night being "get together with other people and watch cartoons" night <nalaginrut>three years, I've been seeing 66 people everyday, I love this year anyway <Ulrar>Would someone happen to know where scm_install_gmp_memory_functions is defined ? I'm trying to compile something and I get an undeclared error <civodul>Ulrar: in libguile/numbers.h, but it appeared in recent 2.0 versions <civodul>oh, 2.0.4 actually, which is not so recent <Ulrar>I have 2.0.2 installed, and I already had to patch it myself to get it to compile <Ulrar>Thanks, I guess I'll write an ebuild for an up to date version <civodul>yeah 2.0.2 is from July 2011, so it's a good idea to upgrade <Ulrar>Didn't know it was that old. The last ebuild in the portage tree is 2.0.0. But I found an overlay with 2.0.9 <civodul>i think Fulax is responsible for this :-) <wingo>civodul: re guile-charting, i use it on 2.0 / 2.2 <wingo>civodul: are you fetching it from gitorious? <nalaginrut>IMO, it's too old before 2.0.5 since too many things changed <Ulrar>Okay, everything works fine with 2.0.9, thanks :) <civodul>wingo: ah no, from the git repo at wingolog.org <wingo>nalaginrut: no, a charting library ;) <wingo>how did it get to be that everyone thought it was on my site, i wonder? <wingo>probably lack of communication <wingo>it's on gitorious, anyway :) <wingo>(define *updated* "8 June 2007") *wingo tries to figure out again how the docs generation works *civodul updates the Guix package *wingo should put in more examples <civodul>wingo: could you upload a .sig as well? <wingo>civodul: i.e. gpg -b -a foo.tar.gz ? <wingo>gnupload usually does this for me ;) *wingo added a bunch of guile-charting examples <davexunit>dsmith-work: arr, that explains why everything is translated into pirate speak on reddit today. <rlb>ijp: thanks -- and don't do anything (specifically for me) yet -- this is all still just mostly speculative. ***DeeEff_ is now known as DeeEff
<davexunit>wingo_: that's great! one recommendation: wrap the image in an anchor tag that links to the full-size image. <wingo_>the image actually is full-size ;) but sure <davexunit>yes it is, but you have to inspect a bit to get that version. <davexunit>right click, 'copy image location', paste in new tab. <davexunit>the screenshot is really nice. if I ever need to chart something, I will try this out. <davexunit>what type of graph is in the upper-right of the screenshot? <wingo_>davexunit: it's a performance series -- measures throughput of a benchmark after different warmup times <wingo_>the colors show various percentiles <wingo_>totally lacking on documentation... <daviid>wingo_: speaking of cairo, there is a guile-clutter problem, when interacting with cairo. I say problem because there is no bug, but the expected does not happen :) <daviid>here is: if the draw procedure|method you connect to the draw signal of a clutter canvas draws something depending on time, like a clock, although I can track the signal gets emited and the draw procedure called upon invalidate, the canvas content is never refreshed [the first call to invalidate does draw the clock, then it 'fixes']. <daviid>so this call ... (call-with-new-thread (lambda () (while #t (sleep 1) (invalidate (get-content clock))))) ... does nothing. I wonder if it is because of a sync problem, and if it is because we are not using clutter_threads_add_timeout, the only difference between my code and the clutter-canvas.c example <daviid>the example i wrote is not ready for commit yet, but i'll see if i can cook a small one for you to look at... unless you have some ***develope_ is now known as developernotes
<daviid>^^ it should work with your version of clutter as well, but need to change (clutter-main) by (g-main-loop-run loop) [and adding (loop (g-main-loop-new)) in the let...] <daviid>it a self, complete and runnable example that shows the problem [chmod a+x clock-test.scm; ./clock-test.scm] <jralls>Does anyone know why stable-2.0 crashes when snarfing guile-procedures.texi but master doesn't when building with clang from Xcode 5.1 and later? <wingo>jralls: master and 2.0 have different vms. it could be that the 2.0 vm is using some kind of unspecified behavior in c that clang is taking advantage of <mark_weaver>jralls: that snarfing is the first time the guile executable is run during the build. so it's not to do with the snarfing. <fangism>i've encountered that issue before, it was recommended [here] to de-optimize vm.c with some version of xcode's clang <fangism>i only have up to xcode 4.6, so I don't know if newer versions are affected <mark_weaver>jralls: this past March, just before the 2.0.11 release, I got guile working on x86_64 with the most recent clang release at that time, and used some of the sanitizers to find a bunch of problems and fix them. <mark_weaver>but there have been problems reported with the clang in Xcode. <mark_weaver>there's been a new LLVM/clang release since then. at some point I could try again with the latest clang.f <jralls>mark_weaver: Was that Clang direct from LLVM or Apple's version from Xcode? <jralls>I think then that there must be something that Apple did. The breakage started with Xcode 5.1 which was released last January. <fangism>miscompilation of vm.c was also present with xcode 4.6 <mark_weaver>well, either it was an Apple-specific patch, or else it was something added to LLVM since the version I tried. <mark_weaver>there's also a known problem on i686 with clang. I posted a patch, but haven't yet committed it to the repo. <jralls>Fangism: Interesting. That was apparently fixed, at least briefly, because I've been falling back to Xcode 5.0 for building GnuCash. <jralls>mark_weaver: I'm *on* x86_64, but I usually build with -arch i386. <mark_weaver>ah, well, that might be the problem then. let me dig up the patch. <jralls>Fangism: It looks to me like the Fink build script tries to force using gcc-4.2, meaning that it won't work for any Xcode after 4.2. <mark_weaver>sha256sum 42422bac46cf807071f2a4312ed3dda963ea57ba802c7e74050d39a8f51874ab <sjoerd`>Which version of bdwgc is currently used for compilation? <rlb>working with #debian-arm and #debian-bootstrap to try to track down the arm compilation failure. In case it rings any bells here, it looks like this is one of the sections that's failing with "vm.s:14591: rdhi, rdlo and rm must all be different": <jralls>mark_weaver: I'm having trouble getting a clean download of that. <rlb>And it also looks like it may have been the switch in sid from gcc 4.8 to gcc 4.9 that precipitated the problem. <taylanub>sjoerd`: it's a run-time dependency (shared library). I think at least versions 7.2 and up work with the stable as well as master branches (or maybe the latter might require 7.4) <sjoerd`>I am having issues when attempting linking against the master of bdwgc <mark_weaver>jralls: hmm, maybe the line endings are getting converted on your end, or something. <sjoerd`>it's friday, never mind... should obviously use the headers from the same revision <jralls>OK, I got a clean one with curl. That fixes it, thanks. Is there a reason not to commit that? <mark_weaver>jralls: well, the problem is that SCM_ALIGNED is not always defined. we define it on compilers that we know how to specify alignment for, but it appears there's no portable way to specify alignment for statically-allocated structures in the older C standards. <mark_weaver>in other places where SCM_ALIGNED is used in Guile, there is always a fallback strategy when SCM_ALIGNED is undefined, which basically defers the work to runtime. <mark_weaver>rlb: so the relevant code is line 365 of vm-i-scheme.c <jralls>mark_weaver: Right. So when it's not defined, or rather defined to "", then the patch is a no-op and won't affect those cases. The issue is rather that it might break other compilers for which it is defined. <mark_weaver>yeah, I guess that since rlo and rhi are not initialized before the asm, gcc has license to assign the same registers to those as for the other two (input) arguments. <mark_weaver>jralls: well, it's not defined at all in those cases, so it would trigger an error. but yeah, for now we could just put those SCM_ALIGNED calls within #ifdef SCM_ALIGNED <mark_weaver>technically, it doesn't guarantee alignment on obscure compilers, but I suppose that would be no worse than what we currently have. <jralls>mark_weaver: Why not define SCM_ALIGNED to do nothing instead of leaving it undefined? <mark_weaver>jralls: well, in these cases, most compilers in practice will provide the correct alignment even without being asked, so these can be silently left out without causing problems. <jralls>mark_weaver: Right, so why clutter up the code with #ifdefs? <mark_weaver>jralls: however, in some other use cases of SCM_ALIGNED, there may be no reason to believe that compilers would normally use the right alignment. and I don't want those to be silently ignored when SCM_ALIGNED is unavailable. <mark_weaver>starting in guile 2.2, I think we can probably just declare that we require a means to specify alignment for static structures. <mark_weaver>and thus stop supporting compilers that don't provide such a mechanism. <jralls>mark_weaver: Yeah, I bet they are. But it's not a problem in 2.2, at least not for Xcode6. <jralls>mark_weaver: Ah, so there are other use cases where it's useful to fail to compile when SCM_ALIGNED isn't defined. OK. <rlb>mark_weaver: so we need to reserve the registers, perhaps? <mark_weaver>rlb: well, I'd like to find a solution that still gives GCC as much freedom as possible, while guaranteeing that the registers are distinct. not sure off hand how to do that. *mark_weaver reads the relevant GCC docs <rlb>ok, though for now we could use a short-term fix -- that or I may need to declare guile-2.0 build-dep "gcc 4.8". Though fro the broader transition away from gcc 4.8, I think I might prefer a workaround if the perf impact isn't too high. <mark_weaver>rlb: maybe the best solution is to include '&' in the constraints for the two output registers. <mark_weaver>that tells GCC that the register is "modified before the instruction is finished with the input operands. Therefore, this operand may not lie in a register that is used as an input operand [...]" <mark_weaver>hmm, I wonder how long the '&' register constraint has been supported by gcc. <mark_weaver>rlb: I think the right fix is to change the two occurrences of "=r" on line 366 of vm-i-scheme.c to "=&r" *mark_weaver goes afk for a while <fangism>jralls: the gcc in fink is merely a disguise, it's actually a wrapper to clang <fangism>and that snippet you saw is conditional to darwin9 only <fangism>we try to keep the same info files usable across multiple OS versions <rlb>mark_weaver: ok, so "=&r" quashes that warning, now we just have this: <jralls>Fangism: That depends on the Xcode version. In Xcode3, there is no clang. In Xcode 4, gcc is linked to llvm-gcc, a different front end from clang; but in Xcode 4.0 - 4.2, the actual gcc was also provided as gcc-4.2. Xcode 4.4 removed that, and Xcode 5 and later removed llvm-gcc and linked gcc to clang. <fangism>jralls: basically, fink has logic to handle various cases from xcode 2.5 to present-day, following the evoluation of what shipped with each xcode <jralls>fangism: OK. That logic isn't apparent from this file alone. <fangism>"choose reasonable defaults, and override as necessary" is the unspoken policy :) <rlb>mark_weaver: and I have the whole file (abt 800k iirc) <jralls>fangism: BTW, as of yesterday it's out of date: Apple pushed Xcode 6 to Mavericks and Yosemite via App Store Update. <jralls>But I suggest that mark_weaver's patch is a better solution than compiling with O0. <fangism>jralls: the fink core team has been tracking that behind the curtain :) some seeded developers have pre-emptively tested and updated packages <fangism>jralls: you're welcome to participate/eavesdrop/lurk/make-jokes in #fink <rlb>sorry forgot to post the error here <rlb>vm.s:13691: Error: bad immediate value for offset (4096) <jralls>fangism: No thanks. I gave up on Fink years ago and build separate application bundles with jhbuild. Prevents dependency-hell and allows drag-and-drop installation. <fangism>jralls: understandable, fink is not intended for App bundle -style packaging (though it does have some support for it) <mark_weaver>rlb: I don't know what source code that corresponds to. <mark_weaver>rlb: it may be that there's a compiler bug on ARM for huge functions (like our VM) <rlb>ok, sounds plausible <mark_weaver>rlb: the only occurrences of inline asm I'm aware of off-hand for ARM in guile are the ones on lines 315-374 of vm-i-scheme.c <mark_weaver>and that asm snippet doesn't look like it came from any of those. <rlb>right -- I wouldn't assume this had anything to do with the asm issue <rlb>I suspect they may just be two separate issues with gcc 4.9 <mark_weaver>anyway, now I really have to go afk. I should be back in an hour or so. <rlb>np and thanks -- at this point I think I'm likely to build-dep gcc 4.8 and then we can pursue the bug independently. <rlb>(I'll also file a bug on the topic) <Ulrar>Is there some version or option of http-post for https ? <mark_weaver>currently, Guile's built-in web client doesn't support https, at least not out of the box. <mark_weaver>GNU Guix supports https using the guile-gnutls bindings. I suspect that code still uses most of the Guile web client stuf. <Ulrar>Ha, that api isn't available over http. I guess I'll try guile-curl then <mark_weaver>indeed, Guix uses GnuTLS combined with Guile's web client to download via https. <Ulrar>It's for a weechat script, weechat depend on curl so I guess it'd be easier to install guile-curl than gnutls + guile-gnutls <davexunit>guile-curl's API is real strange, but it works. <Ulrar>definition in expression context, where definitions are not allowed, in form (define handle (curl-easy-init)) <Ulrar>so what is the correct way to define the handle in a function ? <taylanub>you can also have a sequence of definitions at the beginning of a lambda body (or let body or ...), before the first expression <taylanub>(doing that is equivalent to using a `letrec*' form for those bindings and making the rest of the lambda body the body of that letrec*.) <Ulrar>let: bad let in form (let handle (curl-easy-init)) <ijp>of course, that's not how let works <Ulrar>I already searched how to do that earlier and I gave up. I must be missing some basic concept <ft>(let ((handle (curl-easy-init))) ...) - maybe? <ft>(Never used guile-curl) <taylanub>Ulrar: let me recommend going through a generic Scheme tutorial. :) (That being said, I don't know of any .. damn) <Ulrar>Yeah, started one earlier today, but I wanted to try stuff out. Guess I should finish reading it <richi235>well, the "Hello Scheme" node of the gnu info documentation shipped with guile is quite good <Ulrar>yay, it works \\o/. So the weechat api supports https but doesn't support setting content-type, the guile http-post support setting it but doesn't support https, and guile-curl support both <wgl>Just got repositories for guile (wip) today as noted on http://www.emacswiki.org/emacs/GuileEmacs. Built guile, half a dozen other required libraries. Then switched to build the relevant emacs/guile, and ran into problem with guile-snarf generating some suspicious-looking code in lread.x, leading to compile failures. Does anyone have ideas about what might be wrong?