<ijp>mark_weaver: hmm, last time I read someone's explanation of the fast fib method, it didn't click in (even though I remember I had done that exercise in sicp N years ago), but that code was really transparent <ijp>sort of a "duh" moment <mark_weaver>ijp: does SICP have an exercise involving that method? <ijp>er, oops, scroll down a bit :) <nalaginrut>and there're hundreds lines changes each day during these weeks <mark_weaver>it'll probably slow down a bit for a while. wingo will be quite busy for the next month or so. <ijp>good, that will give me time to figure it out <mark_weaver>I'll see what I can do in the meantime. the next thing I'll do on that branch is to get prompts working with RTL. <mark_weaver>and of course there are also some missing optimizations that are quite important. <mark_weaver>there's some stuff to do in stable-2.0 as well. I need to fix (ice-9 popen) thread-safety, and do something about the async/mutex mess. and I'd like to get in the improved R6RS exception handling stuff, and we should probably release 2.0.10 soonish. <nalaginrut>what's in 2.0.10? I think we have few bugs fix ;-) <mark_weaver>lots of bug fixes. I forget exactly what else. look at the git logs. <nalaginrut>I'm so comfortable with 2.0.9 that I thought there'd be few bugs remain ;-P <mark_weaver>multiplication is about 3 times faster than in 2.0.9. <mark_weaver>(because I added optimized assembly code for it to the VM) <mark_weaver>well, multiplication of small exact integers anyway (fixnums) <mark_weaver>I also added optimized fixnum assembly code for ARM processors. <mark_weaver>currently, fixnum (+ - *) are optimized for 32-bit x86, 64-bit x86, and ARM. <mark_weaver>(and no ASM fixnum optimization for 32-bit x86 or ARM before) <mark_weaver>also a bunch of R6RS fixes, thanks for lots of bug reports from weinholt :) *dsmith wonders if there will be a 2.2 christmas present... <nalaginrut>oh~I want to thank him too, I borrowed some crypto Scheme modules from his industria <mark_weaver>dsmith: I think probably not. There are some other things I'd like to get into 2.2, like UTF-8 internal representation of strings, improved regexp API, and maybe some ports improvements that would break ABI compatibility. If we don't get them into 2.2, they'll have to wait for 2.4. <mark_weaver>if we rush 2.2, then those things would have to wait, and that would be a shame IMO. <dsmith>Well, I didn't mention the year... <nalaginrut>I think it's no hurry for 2.2, especially we may not have very strong AOT till 2.2 <mark_weaver>yeah, our regexp API is turrible, as wingo would say. <nalaginrut>If possible I expect to improve regex in a day, since Artanis may depend on it strongly <ijp>then it's simple, depend on irregex <dsmith>mark_weaver, What did you think of civoduls suggestion for gdbm to provide it's own guile interface? <ijp>shouldn't be bad, since it compiles to a DFA I think <mark_weaver>dsmith: my gut feeling is "makes sense to me", but I haven't thought much about the relevant issues. <dsmith>It just struck me as brilliant. "Why didn't I think of that?" <dsmith>Every gnu library ought to provide its own guile interface... <ijp>civodul suggested it to me back when I did the (system foreign) version, but I never followed up on it <ijp>but I think of that module mostly as a tutorial <mark_weaver>the only slight problem is when packages feel the need to support guile 1.8 as well, and then you end up with a bunch of ifdefs and cruft. <mark_weaver>I think we should try to get some guile-related modules added to gnulib to smooth some of that over. <nalaginrut>in long term plan of Artanis, I expect it works with other modules from Guildhall, but Artanis provides some basic module for simple usage, as a self-contain project. But users may work with other modules easily take advantage of Guildhall <mark_weaver>nalaginrut: I agree with ijp: just use irregex. it seems very nicely done. *nalaginrut reading irregex manual <dsmith>Does it actually build a DFA, or just compile down to a string and let the system regex handle it? <ijp>dsmith: it's all scheme <ijp>yeah, I've double checked, it definitely makes a dfa <nalaginrut>before Guildhall become mature, I have to add them such like irregex into the repo <nalaginrut>I wonder if export more things would consume more memory? or it's just a problem of name pollution? <ijp>I don't think the number of names you export is ever going to be a real memory problem <nalaginrut>I guess so, butit's better to get a explain from implementation view <ijp>well for a start, even names you don't export can be accessed <ijp>so the only difference is in the interface object I think *nalaginrut has to export useful things manually from irregex... <ijp>I'm going to be honest, I think this is a ridiculous concern <ijp>be as careful with exports as you like, I'm saying worrying about memory there is ridiculous <nalaginrut>well, seems either private and public symbols are put into an obarry of module struct <mark_weaver>nalaginrut: again, I agree with ijp. write the cleanest code you can, and don't worry about little bits of memory here and there. <mark_weaver>many programs have been ruined by premature optimization <nalaginrut>yes, but I realize that premature programer incline to premature optimization ;-P <mark_weaver>I didn't know about ETags. I can see their utility, but now I'd like to use a browser that doesn't send them. <taylanub>WWW technologies have gotten so complex/bloated that trying to make them secure seems an uphill battle. And then there's even more new technologies coming along all the time (HTML5 things), centered on the "browser as a platform for any program" mentality and no strong regard for security, from what I see. <taylanub>Maybe I'm just a victim of my own FUD but I'd like to see some vastly simpler technologies come back. Especially for something like Tor Hidden Services, which tend to aim for ultimate security, it's kind of silly to be based on the bloated WWW. <nalaginrut>browser is unsafe, let's communicate with HTTP only ;-D <taylanub>It seems that even HTTP itself has some nasty bloat (how many kinds of headers are there?) .. maybe Gopher would be a better choice. :P <taylanub>Hrm, it would be neat if we had an endianness parameter, that changes what `native-endianness' returns and how procedures like `bytevector-u16-native-ref' behave. <wingo>taylanub: target-endianness from (system base target) <taylanub>wingo: Neat .. if it will remain perhaps we could document it. <wingo>one day you will send in a patch for one of these "would be nice" things you talk about :) <taylanub>wingo: How about we extend (rnrs bytevectors) to make `native-endianness' be a parameter (parameters are procedures too, thankfully). (I'll do it if you think the idea is fine!) <taylanub>Hrm, it will probably slow things down. Bytevector operations, *especially* native ones, should be as fast as possible I think. <nalaginrut>when I parse multiform/data, I have to convert bytevector of body to string, then split the string with boundary, then convert the sub-string to bytevector for output, I think it's not so efficient in this way. <nalaginrut>However, I just finish the function, it's not a proper time for optimization <wingo>taylanub: i'm pretty sure that's a bad idea <wingo>we have a good solution already -- the endianness arg, which can be the result of a call to a parameter <wingo>if you want sugar for some purpose, you can define it -- but you need low-level primitives to implement it <wingo>that's what the bytevector interface is <taylanub>Different issue: wouldn't it be more efficient if we supported explicit bytevector-u16{le,be}-ref etc. procedures ? The current API as defined by R6RS could be implemented on top of that, and in fact a Scheme implementation like (define (bytevector-u16-ref bv idx endianness) (case endianness ...)) should be statically optimizable into a direct call to an explicit-endianness procedure when the endianness argument is a literal constant, <taylanub>so it should even make some existing code using the R6RS API more efficient, no ? <wingo>it's not necessarily the case <wingo>dunno, it's not terribly important <lloda`>I read a bit of bytevectors.c when I was reviewing the array stuff ***haroldwu_irssi is now known as haroldwu_away
<jmd>How do I test if a list is empty? <jmd>Ahh thanks. I was trying nil? <taylanub>jmd: (Note that the empty list is an atomic object, so if your variable holds it then you lose the identity of your list.) ***haroldwu_away is now known as haroldwu_irssi
<amgarching>Hi! Is there a fallback for define-syntax-rule in 1.8 <wingo>you have to (use-modules (ice-9 syncase)) i think <wingo>also it doesn't work in as many situations as in 2.0 <taylanub>amgarching: I posted an off-the-top-of-my-head implementation in #scheme but maybe you're better off stealing it from the Guile 2 sources. <amgarching>taylanub: in guile-2 psyntax implementation seems to be machine generated <ijp>remember to use cond-expand <ijp>define-syntax-rule is in boot-9 <taylanub>amgarching: Ah OK. My implementation doesn't handle a docstring, other than that I tested it once, using the example in the Guile manual. <amgarching>ice-9/boot-9.scm in 2.0.5-deb uses define-syntax-rule, does not define <taylanub>scheme@(guile-user)> (define-syntax-rule (begin/serial e ...) (begin (list 1 2 3))) <taylanub>scheme@(guile-user)> (begin/serial 0 4 1) *taylanub wonders why `syntax-rules' doesn't take a docstring. <ijp>huh, I could have sworn <ijp>amgarching: no, you're right it is in psyntax <ijp>there are two psyntax files <ijp>psyntax.scm is the source, psyntax-pp.scm is the translated version for bootstrapping <amgarching>Do I need to export macros in 1.8 in some special way? <taylanub>Maybe #:export-syntax .. I've seen that in some file today. *taylanub guesses that amgarching is the person who had mysterious performance issues with 2.0 .. did I guess right ? <wingo>i assume you have read the NEWS about syntax-rules and guile 2.0 ? <taylanub>(Hrm, nothing particularly mysterious: apparently the main concerns were start-up time, and slower non-compiled code which was misunderstood to be a common occurrence. The part that remains mysterious to me is the claim that the factorial of 10000 is computed 3x faster in 1.8 than in 2.0. Could be true, but would be a whacky benchmark.) <amgarching>Following onbservation if I also issue (use-modules (ice-9 syncase)) after (use-modules (guile compat)) then it works. Isnt the import in (guile compat), see pastebin, enough? <taylanub>amgarching: So you're just using Guile 1.8 because there's no 2.0 in the repos of your distro ? Would be highly advised to just compile the latest release yourself. <ijp>wingo: where should I start in trying to understand the new vm? <wingo>ijp: for the vm itself, i would start with the mails i sent to the list as things were merged in <wingo>i've never written up a full exegesis though <wingo>for the compiler i would start with the cwcc paper from kennedy <wingo>i hope to write everything up soon <wingo>vm-engine.c is not unreadable though <wingo>you have to skip the first part which is the old vm <ijp>is it the patches in may you are talking about? <ijp>or the more recent ones <wingo>yes at the end of may, beginning of june i think <wingo>the vm hasn't changed significantly since then <civodul>taylanub: who's this person complaining about Guile 2 speed? <civodul>looks like for kids nowadays it's easier to write stuff in reddit than in an email <taylanub>civodul: Ey was on the mailing-list too ... <wingo>amgarchIn9: yes, that was one of the issues <ijp>civodul: heh yeah, and we got that one bug fix from mark because someone was moaning on stackoverflow <civodul>taylanub: ah but that was an unsubstantiated claim actually <civodul>we don't know what he's been running that led him to say "it's slower" <civodul>or maybe he answered in the reddit thing <taylanub>"I'll hand you a link to my report, as soon as it is ready, which contains the test scripts (guile + bash). I'll link to those scripts as well." 27 days ago <taylanub>Let's just forget about it until then ? :P <civodul>maybe his rant got more audience than a release announcement, who knows <amgarching>Is there a way to re-export everything from a e.g. (ice-9 syncase) module? ***ijp` is now known as ijp
<taylanub>amgarching: Not with any documented API I'm afraid but I hope someone proves me wrong. <mark_weaver>amgarching: is there a reason you're still targetting 1.8? 2.0 is now in debian stable, fedora, and ubuntu. <dsmith-work>And didn't you need to use-syntax instead of use-module for syncase anyway? <mark_weaver>amgarching: anyway, what you're asking can certainly be done, but I think it involves using at least one undocumented interface (module-for-each). <mark_weaver>I think it's better to provide an explicit list of the re-exported bindings. <lloda>syntax-case is quite broken in 1.8. Even syntax-rules is broken in 1.8. <mark_weaver>but, having said all that, you *could* do what you want like this (untested): (let ((syms (module-map (lambda (name var) name) (resolve-interface '(ice-9 local-eval))))) (module-re-export! (current-module) names)) <mark_weaver>internationalization is also quite broken in 1.8, and lots of other things. <taylanub>civodul: BTW are you sure `guile -c' uses the evaluator and doesn't first compile the expression ? "guile -q -c '(begin (display ((@ (system vm program) program?) (lambda () 0))) (newline))'" outputs #t for instance. <mark_weaver>taylanub: closures created by the evaluator are programs, because the evaluator runs in the VM. <mark_weaver>guile -c '(eval-when (compile) (display "hello\\n"))' doesn't print anything. <mark_weaver>taylanub: see 'make-fixed-closure' in ice-9/eval.scm <taylanub>Interesting .. maybe it's the same with the REPL then ? <civodul>taylanub: yeah, see command-line.scm <taylanub>Ahh, I probably misinformed a poor sap a couple weeks ago then. :( <mark_weaver>taylanub: yes: (program? (primitive-eval '(lambda () 0))) <mark_weaver>but the created programs are just trampolines, essentially. <taylanub>Aha. *Goes to read what a trampoline is.* <mark_weaver>well, they're closures that use free variables to store the evaluator environment and code. <taylanub>Oh, I need to go, catch the bus, laters! <amgarching>mark_weaver: thanks! I was distracted. I think I will let Debian Lenny alone. It is becoming cumbersome. <mark_weaver>lenny! security updates for that one ended long ago :) <amgarching>I know. That is where I introduced the first use of define-syntax-rule which caused the whole <amgarching>I was quite surprised that your. mark_weaver, (expt matrix 10000) works for fibonacci numbers. Is it "official" to define-method's for built-in arithmetic ops? <mark_weaver>amgarching: (expt <obj> <non-negative-exact-integer>) needs only '*' to be defined on <obj> (possibly using goops) <mark_weaver>essentially, (expt <obj> N) is evaluated as (* <obj> ...) with N instances of <obj>, if N is an exact non-negative integer. <mark_weaver>that's not really how it works internally, but that's the semantics. <mark_weaver>internally, the only difference is that it uses the usual fast exponentiation algorithm (the one that runs in O(log N) time where N is the exponent), so it uses '*' in a different pattern. <nalaginrut>well, I'm glad to see a naive project growing up ;-P <mark_weaver>I confess to finding continued fractions kind of addictive, but maybe it's just me :) ***ijp` is now known as ijp
<ijp>rational->continued is a simple unfold <ijp>actually, I started reading that gosper.txt a while back <ijp>but the version I had was horribly formatted <mark_weaver>ah, I thought this kind of thing would be up your alley :) <mark_weaver>I've been poking at an implementation of continued-fractions arithmetic in Guile for a while now. <ijp>they're a really cool application of lazy evaluation <mark_weaver>I'm reasonably sure it's right, so if you don't have time to look now, I'll just push :) <mark_weaver>wingo: actually, nvm, I shouldn't waste your time with this fairly obvious small stuff. <mark_weaver>(solve-parallel-move '(6 5 1 2 3 4) '(0 1 2 3 4 5) 7) => ((6 . 0) (1 . 7) (5 . 1) (7 . 2) (4 . 5) (3 . 4) (2 . 3)) <mark_weaver>so r[3] ends up with the value from r[7], when it should have gotten r[2] <mark_weaver>I'll take care of it.. time to think about parallel moves :) <mark_weaver>to my mind, the way to do parallel moves seems to be to compute the SCCs, and then traverse the SCCs in reverse topological order. for each SCC, go around the cycle, with the temp register used in one place in the cycle. <mark_weaver>wingo: but what you wrote seems to be much simpler than that. but I don't see how it could be done simpler. <mark_weaver>I guess I should actually try to understand what you wrote. <wingo>i might have missed one of your lines <wingo>last one was "i'll take care of it" <mark_weaver>(assuming you got the earlier ones about there being a bug in the parallel moves solver, and an example where it fails) <wingo>it's possible to solve with one temporary *mark_weaver suspects it's a fundamentally flawed method. <wingo>i'm not sure i understand the bug <wingo>you said: (solve-parallel-move '(6 5 1 2 3 4) '(0 1 2 3 4 5) 7) => ((6 . 0) (1 . 7) (5 . 1) (7 . 2) (4 . 5) (3 . 4) (2 . 3)) <mark_weaver>yes, and 3 ends up with the value that was in 7 (the temp) <mark_weaver>3 should end up with the value of 2, as per the input spec. <mark_weaver>anyway, I think I know how to efficiently solve this problem. if you don't want to deal, I can just do it :) <mark_weaver>well, there is one piece I still need to figure out. I'm sure this is a standard problem in graph theory but I'm blanking on what it's called and having trouble finding the right search term. maybe someone here can help. <mark_weaver>in each strongly-connected component, I need to find a path, composed of the edges in the directed graph, that traverses each vertex exactly once. <wingo>might have appropriate references as to the terminology <mark_weaver>I'll be damned if I'm going to reward those knowledge hoarders! I'll figure it out without them :) <mark_weaver>oh wait, duh. in this special case, where each node in an SCC is guaranteed to have exactly one incoming edge and exactly one outgoing edge, the problem is trivial. just follow the edges. <mark_weaver>(assuming only that each register appears at most once in SRC, and at most once in DST, and that TMP is not found in either of them) <mark_weaver>turbofail: thanks! I'm curious how their solution compares with mine. <mark_weaver>wingo: fyi, one fundamental problem with the current 'solve-parallel-move' is that you assume that one you've eliminated the trivial moves, that you can just pick the first move that remains to break the cycle. but in general, not every node that remains will be part of a cycle. <mark_weaver>I keep forgetting that the graph we're dealing with is highly constrained. <mark_weaver>wingo: can we assume that each register appears at most once in SRC ? <mark_weaver>but presumably we *can* assume that each register appears at most once in DST. <dsmith-work>mark_weaver: writing to the same reg more than once sounds like a bug.. <mark_weaver>ah, I see now. because each register has at most one incoming edge, and in a cycle every register has an incoming edge from another register in the same cycle, cycles cannot have any edges coming in from outside of the cycle. <mark_weaver>which means that there can be at most one non-trivial strongly-connected-component. it can have outgoing edges to single registers, but that's it. <wingo>mark_weaver: np, it often takes words to think properly :) <mark_weaver>is there a better than O(n^2) version of 'delete-duplicates' in guile core somewhere? <mark_weaver>*nod* yes, I already had that in mind. just wondering if it's already somewhere in guile core, to prevent duplication. ***ijp`` is now known as ijp