IRC channel logs


back to list of logs

<ArneBab>mark_weaver: here’s my simple test report: (with org-source and pdf in )
<ijp>there are benchmarks in guile you could have used
<ijp>at least, I think there are
<ijp>.oO(is it obvious I've never ran them?)
<dsmith>sneek, benchmarks?
<sneek>Someone once said benchmarks is
<mark_weaver>ArneBab: how did you run the code "without the compile step" ?
<mark_weaver>ArneBab: in particular, I have no idea what "RTL-compiler no compile
<mark_weaver>" means or how it was done.
<mark_weaver>but it's meaningless.
<ijp>what's the performance of string concatenation like?
<ijp>not that it matters a whole deal for my current application, but I have a tree-ish structure of strings, and I'm wondering if it would be best to turn it into a list and string-concatenate, or if it's fine to just do the recursive thing
<ijp>hmm, actually neither is a good fit, since what I actually need is string-join
<mark_weaver>ijp: string-concatenate is quite efficient now, but that's fairly recent.
<mark_weaver>oh, sorry.
<mark_weaver>string-concatenate has been good for a long time.
<mark_weaver>string-join is the one that sucked until recently.
<mark_weaver>it's definitely *much* better to do one call to string-concatenate, than to do the recursive thing.
<mark_weaver>ArneBab: anyway, thanks for the writing that up!
<mark_weaver>ArneBab: but the "RTL-compiler no compile"
<mark_weaver>is not right.
<mark_weaver>ijp: string-join is quite efficient in 2.0.9. In all previous versions of Guile, it was O(n^2) in the number of strings being joined (assuming they are about the same size).
<mark_weaver>ijp: what are you working on?
<mark_weaver>sneek: seen civodul
<sneek>civodul was here Jul 19 at 12:16 pm UTC, saying: though QuasiConf looks really nice too :-/.
<ijp>right now, just talking to an api, and dealing with some silly formatting issues
*davexunit has added font rendering to guile-2d via the FTGL library. :)
<davexunit>it's rather primitive atm, but it works which is most important.
<davexunit>I'm having a bit of a tough time writing certain things in a functional style.
<davexunit>trying to avoid mutation when possible and stuff.
<mark_weaver>sometimes it's hard. sometimes it's even a bad idea. what are you trying to do?
<mark_weaver>it's a good thing to try to do though. I certainly try.
<davexunit>I'm just trying to write guile-2d well.
<davexunit>I'm trying to avoid writing mutable data structures, for instance.
<mark_weaver>what's a example of something that you find difficult to do in a functional style?
<mark_weaver>(the reason I ask is that maybe one of us here has a clever idea to make it easier)
<davexunit>well, let's take the main game loop for example.
<davexunit>it's functional, on its own. but once we add in the update/render hook calls the side effects happen.
<davexunit>I was thinking that perhaps there needs to be some game state object that gets passed as an argument to the game loop.
<davexunit>and the return value of update is a new game state object.
<davexunit>but then I worry about the GC, but perhaps that's not so important.
<nalaginrut>morning guilers~
<sneek>Welcome back nalaginrut, you have 1 message.
<sneek>nalaginrut, mark_weaver says:
<nalaginrut>mark_weaver: I realize I've read the Chinese version of this book ;-)
<mark_weaver>davexunit: personally, I wouldn't try to be purely functional for a game engine. the game state for things like bullet hell games are likely to be very large, and there will be a lot of GC churn if you copy all that stuff..
<mark_weaver>well, I dunno. maybe it's not that large.
<mark_weaver>sorry for the flip flopping. I guess I need to think some more on it.
<davexunit>some things will be impure, no doubt about it.
<davexunit>especially a particle system.
<davexunit>perhaps I'm trying to push the functional thing too far here.
<ijp>found a bug in (web request)
<ijp>or rather, I'm just going to check the rfc before I start moaning
<nalaginrut>ijp: this maybe a bug I have to concern
<mark_weaver>davexunit: I'd still try to be functional in most places.
<mark_weaver>davexunit: but I probably wouldn't try to be puritan about it.
<ijp>nalaginrut: url with path "" and a query string
<davexunit>okay. I can always do the things the easier, unpure way first and refactor/rewrite later.
<nalaginrut>ijp: any testcase I can reproduce it?
<ijp>if you make a GET, you will see "GET ?foo HTTP/1.1", when you should get "GET /?foo HTTP/1.1"
<ijp>(equal? (call-with-output-string (lambda (p) (write-request (build-request (string->uri "")) p))) (call-with-output-string (lambda (p) (write-request (build-request (string->uri "")) p)) )) $16 = #t
<ijp>(equal? (call-with-output-string (lambda (p) (write-request (build-request (string->uri "")) p))) (call-with-output-string (lambda (p) (write-request (build-request (string->uri "")) p)) )) $17 = #f
<nalaginrut>ijp: I always test it in browser, I think you test this from a low-level way, so maybe the problem is under the water
<ijp>(use-modules (web request) (web uri)) should cover the imports for that
*nalaginrut testing
<ijp>you won't see the problem in a browser, since it's with guile sending requests, rather than receiving them
<mark_weaver>ijp: could you write bug-guile about it?
<ijp>once I check the rfc, I'll fix it
<ijp>it'll be a one line fix probably
<ijp>"If the abs_path is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource"
<ijp>about as clear as you can be there
<nalaginrut>this bug may cause the route-rule missing in Artanis
<mark_weaver>ijp: that's even better, thanks!
<ijp>it was a little more than one line, but still trivial
<mark_weaver>nalaginrut: it only affects when guile is acting as the web client. it shouldn't affect artanis at all.
<nalaginrut>mark_weaver: oops, not the same book I've read, it's a nice book~
<nalaginrut>mark_weaver: Artanis will get uri as "?foo" when it's "", which will miss the rule "/?foo"
<nalaginrut>well, I don't know if anyone use "/?foo"
<ijp>/?foo is the correct one
<ijp>as far as the _request line_ is concerned
<ijp>but for your rules, you can do whatever you like
<nalaginrut>so I said it's a problem under water, if anyone visit url with browser, it's fine. But if anyone visit in low-level way, it maybe missed, which seems no harm
<nalaginrut>I don't know if there's actual effect for Artanis, browser send the correct url I think
<ijp>it should, yes
<nalaginrut>ijp: but please fix it anyway ;-)
<ijp>email is being prepared as we speak
*nalaginrut is reading EOPL
<nalaginrut>BTW, Artanis has 28 stars now (AD time) ;-D
<mark_weaver>nalaginrut: congrats! I see that one of your stargazers uses RMS's picture :)
<nalaginrut>mark_weaver: well, I was scared too, but I realized he's not ;D
<nalaginrut>will multi-values faster than passing-with-list?
<ijp>if it makes sense to return a list, return a list
<mark_weaver>yes, usually. but I wouldn't muck up your code too much for the sake of little things like this.
<mark_weaver>basically, if the two things are logically part of one object, then they should be one object so you can give it one name.
<mark_weaver>on the other hand, if they are separate, and the procedure needs to return two or more values, then IMO multiple value returns are good for that. opinions differ on this, of course :)
<nalaginrut>so the only advantage of multi-values is the better code-express-style, no efficient anymore?
<nalaginrut>I mean performance
<ijp>the reason it would be faster, would be because it wouldn't need to allocate
<nalaginrut>my understanding is it passes with stack, so no more malloc was called
<mark_weaver>that's right.
<ijp>how are we handling the (lambda args *foo* (apply values args)) pattern?
<mark_weaver>ijp: I think that peval will simplify many of those cases. I'm not sure off hand about that one. Try ,optimize with some examples.
<mark_weaver>ijp: that precise example (with *foo* replaced by something that uses args, obviously) is a bit tricky though, because I think technically the list has to be copied there.
<mark_weaver>but if, for example, the second argument to 'values' is a call to 'list', or maybe even a chain of conses, it will often be smart and simplify it to remove the apply and procedure call.
<mark_weaver>ijp: oh wait. I misread your example as something very different..
<mark_weaver>somehow, I managed to turn it into (apply (lambda args *foo) args)
<nalaginrut>does this form optimize with multi-values?
<mark_weaver>it does a nice job with (lambda args *foo* (apply values args))
<ijp>nalaginrut: if you have a lot of registers, it should just keep them in place
<mark_weaver>it becomes this assembly:
<mark_weaver> 0 (assert-nargs-ge 0 0)
<mark_weaver> 3 (push-rest 0 0)
<mark_weaver> 6 (reserve-locals 0 1)
<mark_weaver> 9 (toplevel-ref 1) ;; `*foo*'
<mark_weaver> 11 (drop)
<mark_weaver> 12 (local-ref 0) ;; `args'
<mark_weaver> 14 (return/values* 1) at (unknown file):2:31
<mark_weaver>so all the arguments are on the stack when the procedure is entered, and it basically just leaves them there for the return.
<nalaginrut>ijp: it sounds good, but your assumption maybe need RTL?
<nalaginrut>so it's optimized with returen/values* which is a multi-values low-level instruction, right?
<ijp>well, I was assuming we were talking about RTL
<ijp>though it was a hypothetical; I don't know much about RTL
<nalaginrut>ijp: ah~sorry, though RTL is the good topic to talk, I was thinking about our current Guile's performance ;-P
<mark_weaver>The RTL compiler doesn't handle it nicely yet, but that will certainly be fixed.
<nalaginrut>if RTL aims to handle it well like this, I'll think the answer to my question is "true" ;-D
<mark_weaver>nalaginrut: everything in that listing is a VM instruction.
<nalaginrut>stackVM instruction
<mark_weaver>the RTL analogue is return-values, but it's basically the same idea. in both cases, arguments and return values are passed on the stack.
<nalaginrut>anyway, my understanding is if you don't want to store the returned value(s) for later using, just return it with multi-values, which may decrease allocation in GC
<mark_weaver>ugh.. I have to retract my earlier statements.
<mark_weaver>it turns out that the 'push-rest' instruction takes all the arguments off the stack and conses them into a list.
<mark_weaver>and the 'return/values*' instruction takes that list and pushes them onto the stack before returning.
<mark_weaver>so it doesn't handle this case nicely.
<mark_weaver>that's a strange case though.
<mark_weaver>it works efficiently when you return a fixed number of values.
<nalaginrut>mark_weaver: is it possible to optimize it like we talked?
<mark_weaver>I have to go afk for a while. we'll have to talk about this later.
<civodul>Hello Guilers!
<mark_weaver>hi civodul!
<mark_weaver>and wingo :)
<wingo>civodul: hope you had a lovely, lovely holiday :)
<mark_weaver>civodul: I guess it hasn't been mentioned yet on the list, but it's now possible to compile non-trivial Scheme code to RTL :)
<mark_weaver>exciting times in Guile land :)
<wingo>civodul: that's on wip-cps-bis
<mark_weaver>wingo: btw, thanks for getting my continued fractions code working again. seeing that was a great relief :)
<wingo>but i'd like to rebase and nicely present it for merging
<wingo>mark_weaver: np :)
<wingo>i'm not sure exactly what i did to fix it, is the thing -- after those two patches i pushed last night it worked, so yay i guess
<mark_weaver>civodul: it's still not used by default though, even on thta branch.
<mark_weaver>yeah, I was confused by that too, but I'm not complaining :)
<civodul>wingo: yeap, it's nice to have long holidays :-)
<civodul>hey mark_weaver!
<civodul>i've seen the new branch with the interesting name, but haven't looked yet ;-)
<mark_weaver>what does "bis" stand for, btw?
*civodul needs to git pull in 2.1
<wingo>"the second instance of the thing"
<mark_weaver>ah, thanks. actually, it did make me remember "V.32bis". I had a modem once with that.
<mark_weaver>(I'm probably showing my age :)
<civodul>the one that could do 56K no?
<mark_weaver>I don't remember actually, but looking it up, it seems it could do only 14.4kbps.
<mark_weaver>at the time it seemed pretty nice. looking back, it was the stone age :)
*mark_weaver started telecommunications with a 300 baud modem :)
<mark_weaver>the nice thing about that was that I could read the text as fast as it came in, so there was no need for a pager :)
*wingo started with a 2400 baud :)
<mark_weaver>wow, you must have been quite young at the time!
<mark_weaver>I didn't even see my first computer until I was about 10, and I was immediately hooked
<mark_weaver>civodul: anyway, on the wip-cps-bis branch, to compile to RTL you need to do this:
<mark_weaver>(use-modules (system vm assembler) (system base compile))
<mark_weaver>(define (run-rtl x) ((assemble-program (compile x #:env (current-module) #:to 'rtl))))
<mark_weaver>(run-rtl 'expr)
<mark_weaver>ArneBab already wrote up something about it, here:
<mark_weaver>(though I confess to having mixed feelings about benchmarks of the new VM posted at this very early stage)
<wingo>for reals...
<wingo>also that benchmark is bogus; it is entirely dead code
<wingo>and it mostly tests gc i think
<mark_weaver>ha, I didn't look carefully to notice that. but the "RTL-compiler no compile" caught my eye. I'm not sure what he meant there.
<wingo>i think he was including compilation time in one of them
<mark_weaver>*nod* that was my guess too, although I didn't see any description of what he did for that test.
<mark_weaver>I think you're right about it being mostly GC, since the (/ i 2) would create heap-allocated fractions half the time.
<civodul>heh, benchmarks
<mark_weaver>of course, as clinger rightly says, benchmarks are a crock :)
<nalaginrut>I think in (let ((ll '(1 2))) ...), ll usually allocated in vm-stack, right? But if the size of ll is larger than GUILE_STACK_SIZE, it'll be allocated in GC, right?
<nalaginrut>so all in heap?
<mark_weaver>the list is always in the heap.
<nalaginrut>nice~I guessed it right~
<nalaginrut>If ll allocated in stack, I was wrong for some assumption
<nalaginrut>and (getenv "GUILE_STACK_SIZE") ==> #f, how can I get the size?
<nalaginrut>I saw scm_getenv_int("GUILE_STACK_SIZE"...)
<mark_weaver>it will optionally use that env var, if present. otherwise, it's a fixed default value set in the vm.
<mark_weaver>why do you want to know?
<mark_weaver>nalaginrut: ll, the reference to the list, is distinct from the list itself.
<nalaginrut>for my first question, I have to know the STACK_SIZE, but now it's useless, since the question have answer, just asking
<mark_weaver>the list is on the heap, but ll (the reference) will often be on the stack.
<mark_weaver>nalaginrut: if you look at the code surrounding the scm_getenv_int("GUILE_STACK_SIZE"...), you'll have your answer.
<nalaginrut>alright, I just grep the line and guessing...
*nalaginrut keep hacking..
*mark_weaver --> zzz
<Arne`>ijp, mark_weaver: I used that test, because I did a multi-language benchmark with it and now I wanted to see how the new guile fares.
<ArneBab__>mark_weaver: the RTL compiler, no compile is without an extra compilation step: just running the wip-cps-bis code without getting the modules.
<Arne`>s/wip-cps-bis code/wip-cps-bis branch/
<ArneBab__>(did you get my recent messages about guile-2d?)
***user_ is now known as goto
<civodul>BTW, did you see how important Guile is: :-)
*civodul lobbied for the paragraph about Scheme
<nalaginrut>anyone remind me the function to "print all exception in a row"? seems it's still not involved in manual
<civodul>nalaginrut: what do you mean?
<nalaginrut>civodul: a proc to print exception caught by catch, anyway, I found with-error-to-string
<nalaginrut>but IIRC there's another proc
<nalaginrut>oh, no, with-error-to-string is not the case
<wingo>print-exception ?
<ijp>not documented
<wingo>bummer :)
<ijp>the name is pretty self explanatory, granted
<add^_>hey davexunit :-)
<davexunit>hey add^_
<add^_>What's up?
<davexunit>not too much. added font rendering to guile-2d over the weekend.
<davexunit>really basic but it works.
<add^_>I gotta restart my whole pathfinding thing, it's a mess..
*add^_ deleted everything basically, and github isn't updated.
<add^_>well, *was* a mess. Until I deleted everything :-)
*add^_ sighs
<nalaginrut>hmm...dunno, IIRC there's no need to pass port in, maybe print-exception
<nalaginrut>anyway, it could solve me problem
<taylanub>I wonger, is it intentional that (letrec ((foo bar) (bar foo)) foo) => #<unspecified> instead of raising an exception ?
***haroldwu_irssi is now known as haroldwu
<civodul>that's a side-effect of the compiler's fix-letrec
<taylanub>Do we intend to change it ? I always thought that there's consensus on that it should be invalid code, but maybe I'm mistaken.
<wingo>perhaps mark_weaver's new fixing letrec pass will change that
<ijp>mark_weaver says he has patches to for fixing-letrec-reloaded
<nalaginrut>I can't use regexp onto a string like "\\x00\\x00\\x01\\x00\\x01\\x00\\x10\\x10\\x00\\x00\\x01\\x00 "
<nalaginrut>but I really need it
<nalaginrut>to parse arbitrary string uploaded as multiform/data
<nalaginrut>which could be a binary file
<wingo>regexps are terrible for that kind of thing
<taylanub>Are you sure a plaintext-search is not sufficient ?
<wingo>especially posix regexps
<taylanub>(If you're searching for that "separator" thing ...)
<nalaginrut>I just split multiform/data with regexp-split as a simplest method
<taylanub>I would actually expect it to work as long as the regexp itself doesn't have any of those weird characters.
<nalaginrut>maybe we need read-util-string
<taylanub>-until- ?
<nalaginrut>well, I mean use certain string as delimiter, like read-delimiter
<ijp>I think read-delimited handles that?
<nalaginrut>but read-delimiter stops when encountered any char in the string
<nalaginrut>I need the whole string as a delimiter
<ijp>ah delims is a set, not a string
<ijp>there might be something in olegs lexing utils thing
<nalaginrut>oh, I wish it could be just one function, rather than add whole package into Artanis
<ijp>looks like I imagined it anyway
<ijp>nalaginrut: do you have functions for parsing/unparsing x-www-form-urlencoded?
<ijp>I have two hackish ones, but if there were proper standards compliant versions, I'd use them instead
<nalaginrut>not yet
<nalaginrut>I'll do that when multipart/form-data done
<nalaginrut>ijp: oh, x-www-form-urlencoded uses base64, so it sounds not so hard
<ijp>base64 doesn't enter into it
<ijp>it's that silly foo=bar&baz=quux thing, only there some annoyances, like escaping &, changinge spaces to +, and normalising newlines
*dsmith remembers 300 baud
<nalaginrut>well, just url-decode url-encode in (web url)
<ijp>none of those are hard problems, but it's a pain it isn't just string-join + uri-encode
<nalaginrut>I use (web url), I think it's fine
<ijp>actually that & is a red herring, that's a html issue
<ijp>anyway I can fix up my version tonight
<nalaginrut>guess what, I never saw 70+ people here, but here're 75
<dsmith>75 is a new record I think
<ArneBab__>civodul: nice!
<civodul>ArneBab__: the GCS thing?
<taylanub>Ugh, `,optimize (force (delay <constant>))' doesn't optimize to <constant>. Is this again related to the top-level reference issue ?
<ijp>no, I just don't think we do any optimisation for promises
<taylanub>Oh ..
<ijp>if you like optimisation passes and sausages, you should never watch either one being made
<add^_>That is quite true though..
<ijp>seriously, all those counters in peval are intimidating to me
<taylanub>Is our delay/force implementation immune to that growing-stack issue ? If yes, I suppose we might want to just (define-syntax delay-force (syntax-rules () ((delay-force exp) (delay (force exp))))) for R7RS compatibility.
<wingo>regardless of whether that is the case or not, r7rs compatibility is not a great argument
<wingo>r7rs wants you to import modules, and names should be defined in those modules
<taylanub>Oh, right, we don't even have the R7RS library system yet. :)
<taylanub>BTW I see the test described in SRFI 45 fails: (define (loop) (delay (force (loop)))) (force (loop)) => error: stack overflow
<taylanub>Oh, we do have SRFI 45.
***h_ll_k_n is now known as hellekin
<dsmith-work>sneek: later tell mark_weaver What is the tiger book?
<dsmith-work>sneek: botsnack
<dsmith-work>sneek: later tell mark_weaver What is the tiger book?
<add^_>Was that a bug test or something? It seemed like sneek dropped it.
<dsmith-work>sneek: later tell mark_weaver tiger book?
<add^_>Huh, wierd
<sneek>Got it.
<dsmith-work>The "is" is there was confusing
<dsmith-work>So if I ask him "later tell mark_weaver What?" he'd probably answer "the tiger book?"
<add^_>So, the "is" is something to be tweaked
<taylanub>Precedence rules! Now if ey took s-expressions instead .. :P
<add^_>Now let's see
<add^_>hey mark_weaver :-)
<mark_weaver>hi add^_! how goes?
<sneek>Welcome back mark_weaver, you have 1 message.
<sneek>mark_weaver, dsmith-work says: tiger book?
<add^_>Not much, still banging my head against the wall :-P
<add^_>And you?
<mark_weaver>having fun with the
<mark_weaver>new RTL compiler :)
<mark_weaver>dsmith-work: remember how that old classic Aho Sethi and Ullman compiler text is called the dragon book? the tiger book refers to a newer book about compilers by Andrew Appel: Modern Compiler Implementation in {C,ML} (there are two that I recall, maybe others)
<mark_weaver>add^_: why are you banging your head against the wall?
<add^_>Because I'm a moron.
<mark_weaver>sounds uncomfortable :)
<mark_weaver>are you having trouble with that barendregt text?
<mark_weaver>I get the impression that it's not an easy book.
<add^_>Well, that too, but I'm thinking about pathfinding. This is like the fourth time I try and think about it. And pathfinding isn't really *hard*...
<add^_>Well, if I listen to people who know how it works..
<add^_>The thing I've realized and understand best is that I don't understand.
<mark_weaver>things are often harder when we sit down to write code than when we listen to others talk about them.
<mark_weaver>that's why writing code is so good for learning.
<mark_weaver>It takes a long time to learn how to write code. I've been doing it for over 30 years and there are still many things I find difficult.
<add^_>You guys are awesome. ^^
<add^_>Guile-dev is way over my head, at least right now.
<add^_>Some day I'll understand more of it :-)
<mark_weaver>no doubt. these things take time.
<mark_weaver>Language implementation is a fairly difficult subject.
<add^_>"fairly" xD
<add^_>For me it'd be "next to impossible"
<mark_weaver>how long have you been writing code?
<add^_>A couple of years I suppose
<add^_>Can't say I've been coding all the time though..
<add^_>Because of health issues.
*add^_ hears an echo in his head "Excuses excuses"
<mark_weaver>it would be unrealistic to expect anyone with only a few years of experience to understand these discussions. don't be so hard on yourself!
<mark_weaver>when I first started studying compilers, I had already been writing code (quite intensively) for about 10 years.
<add^_>Oh? Wow..
<add^_>So you've been studying/coding compilers for about 20 years
<add^_>That's about how long I've lived.
<mark_weaver>although I haven't been studying compilers all that time. just on and off.
<add^_>Could you say that compilers are your nishe?
<mark_weaver>I think that you become discouraged because you set unrealistically difficult goals for yourself.
<add^_>mark_weaver: that's how I work, I never can come up with a realistic project to work on, so I go with whatever I get.
<add^_>Which is usually "Make a 3D modeller in Scheme" or "OS" level.
<add^_>s/I never can/I can never/
<mark_weaver>add^_: have you worked through any textbooks about writing programs?
<mark_weaver>"worked through" means reading and doing many of the exercises.
<mark_weaver>which ones?
<add^_>Well, not many Scheme books, but I used to do C++ (ugh)
<mark_weaver>I'm glad to hear you say that in the past tense :)
<add^_>It wasn't a great start of my programming life
<add^_>Yes, C++ was my starting language -.-
<add^_>I wish it'd had been Scheme or *at least* C..
<mark_weaver>how are you at math?
<add^_>I like math, didn't read much about it in School though, also because of health.
<davexunit>I used to do C++ too, add^_
<davexunit>my first language ever was QBasic.
<mark_weaver>I also started with BASIC. Then Pascal and then C.
<mark_weaver>I wish I'd started with Scheme.
<add^_>I kinda wish I'd read more maths in school, but yeah...
<mark_weaver>add^_: what was the most advanced math you learned?
<add^_>Not very advanced at all.
<add^_>Can't think of the name though
<mark_weaver>did you learn calculus?
<mark_weaver>the reason I ask is to help me make some recommendations of what book to consider working through.
<add^_>I'd love to learn more maths, and am thinking of reading up on more of it sooner or later..
<add^_>I don't know what you learn in the school system you have (in what order)
<add^_>We've touched on a lot of math-basics, but I didn't go through much troughly
<mark_weaver>have you worked through "The Little Schemer" and "The Seasoned Schemer"?
<mark_weaver>ah, good :)
<mark_weaver>How to Design Programs?
<mark_weaver>that might be worth working through. I haven't done so myself, but I've heard good things about it.
<add^_>Which version?
<add^_>The old one?
<mark_weaver>hmm, I don't know. I guess I would assume that the newest one would be best, but admittedly that's just a guess.
<add^_>I guess SICP is a bit hard?
<mark_weaver>well, SICP assumes that you've had more math.
<mark_weaver>that's actually the precise reason I was asking about your math knowledge.
<add^_>Which math do I need to work on to be able to get more out of SICP?
<add^_>Generally speaking
<mark_weaver>well, it's really aimed at people who've studied up to the calculus level.
<ijp>mark_weaver: I think there is a java version of the tiger book too
<mark_weaver>ah yes, that's the one I was forgetting!
<davexunit>the math is the hardest part of SICP, imo.
<mark_weaver>add^_: it's okay, there's no inherent reason why you need to know calculus to write advanced computer programs.. it's just that SICP happens to use calculus ideas in many of its examples.
<add^_>I wonder what I've missed in SICP, I've never really thought "I wish I learned XYZ in school to understand this better".
<mark_weaver>(and in its descriptions and exercises as well)
<ijp>SICP was one giant long lesson in how I was an idiot for not understanding proof by induction in high school
<mark_weaver>more likely, your teachers didn't know how to teach it well.
<add^_>Sounds like my physics/chemistry teachers. ;-)
<mark_weaver>SICP worked wonders for me, but there are other good ways to learn everything that you'd learn in SICP.
<add^_>Well, the first ones were great, just that when they got replaced, they got replaced by total morons.
<add^_>Not morons
<mark_weaver>you can't really understand physics without understanding calculus.
<add^_>People who couldn't explain things*
<add^_>Physics wasn't hard.
<add^_>Until the second teacher taught us wrong..
<add^_>and then the third teacher was very confusing too.
<add^_>mark_weaver: Does that mean I've studied calculus? :-P
<mark_weaver>add^_: for example, can you tell me the derivative of x^2 with respect to x ?
<add^_>Not from the top of my head
<mark_weaver>okay, then you don't know calculus :)
<add^_>Good to know
<ijp>ooh ooh ohh
*ijp waves hand about like the looney at the front of the class
*add^_ needs to look up the word derivative first
<add^_>Nope, dunno.
<mark_weaver>add^_: so the physics that you found easy must have been very elementary.
<ijp>I can still kind of do partial differentiation, but integration is much more foggy
<add^_>God, now I feel like even a bigger moron.
<mark_weaver>integration is hard. I get rusty fast, and have to relearn it again when I need it.
<mark_weaver>(or just use Maxima :)
<mark_weaver>add^_: there's a difference between being a "moron" and not having learned something.
<add^_>Fair enough
<add^_>"Haven't learned anything"
<mark_weaver>If you've worked through the Seasoned Schemer, then you definitely know a lot more than nothing.
<add^_>Now I need to come up with a realistic project.
<mark_weaver>add^_: have you looked at project euler?
<add^_>Good idea
<add^_>Thanks for reminding me of that
<davexunit>I should do more project euler stuff
<add^_>You know, the first think I thought was "how hard is the hardest problem?", I shouldn't answer that question.
<add^_>At least not yet.
<davexunit>I'm halfway through the little schemer.
<add^_>davexunit: The two first books are really nice, I can't answer for the third book yet because I'm not done with it.
<davexunit>I usually find myself working on one of my own projects instead of getting farther through books.
<mark_weaver>the third book (The Reasoned Schemer) is great! one of my favorites.
<mark_weaver>well, all of them are great.
<add^_>I've only heard good things about it.
<add^_>Well, it's good for as far as I've gotten. :-) Which isn't that far but still.
<davexunit>I am a huge fan of the little schemer thus far.
<mark_weaver>add^_: regarding project euler, I'd just do them in order from the beginning. you want to jump ahead, but that's why you get into trouble and get so discouraged.
<ijp>why settle for realistic, when you can fail in the most spectacular fashion?
<add^_>Thanks for all your advice mark_weaver :-)
<mark_weaver>np, and happy hacking! :)
<add^_>Happy hacking to you too
<davexunit>I love the phrase "happy hacking"
<mark_weaver>I picked it up from RMS. It's pretty much his standard way of parting company with another programmer :)
<davexunit>there's something very pleasant about it.
<dsmith-work>mark_weaver: Thanks. I figured, but a search for "tiger book" was not too revealing.
<dsmith-work>mark_weaver: My dragon book is from around '86 or so.
<mark_weaver>taylanub: R7RS' (delay-force x) is not the same as (delay (force x)).. one of the reasons I think that's a bad name for it.
<mark_weaver>R7RS's 'delay-force' is the same as SRFI-45's 'lazy'. Just use SRFI-45.
<mark_weaver>Amusingly, the SRFI-45 promises (implemented in Scheme) are faster than Guile's native promises implemented in C.
<mark_weaver>The reason is that Guile's native promises are thread-safe, so they have to do mutex ops.
<mark_weaver>the SRFI-45 are not thread-safe. you are responsible for protecting a promise if you need to force it from multiple threads.
<davexunit>ah okay.
<taylanub>mark_weaver: It seems `delay' and `force' can be implemented such that their composition is equivalent to `delay-force', e.g. after loading (srfi srfi-45) this seems to be the case, although not by default.
<mark_weaver>ah, okay.
<mark_weaver>well, in any case, I believe that SRFI-45 promises have the same semantics as R7RS promises, but with some different names.
<mark_weaver>(the other one that's different is R7RS 'make-promise', which corresponds to SRFI-45's 'eager'. I don't remember if the usage is the same though.
<mark_weaver>taylanub: do you have a reference to back that claim up? it may be true, but I'd like to understand better.
<mark_weaver>in the reference SRFI-45 implementation, 'delay' is implemented in terms of 'lazy', not the other way around.
<mark_weaver>it's certainly more efficient to use 'lazy', anyway.
<taylanub>I seem to remember reading in R7RS that an implementation may implement `delay' and `force' such that `delay-force' is unneeded, but I can't find that at the moment. I did the (define (loop) (delay (force (loop)))) test with SRFI 45 loaded in Guile though and it worked.
<ijp>well, it won't allways be possible
<taylanub>Ah wait, I think I tested wrong. :\\
<taylanub>Hrm, I get a stack overflow now.
<ijp>(define (ridiculous-example f) (f (delay (*thing*)))) (map ridiculous-example (list force list force))
<mark_weaver>yeah, I doubt they would have included 'lazy' if it was redundant.
<ijp>whoops wrong way round
*ijp sweeps example under the carpet
<mark_weaver>I've decided that I prefer R6RS to R7RS. I intend to get serious about making Guile's R6RS compliance top-notch.
<davexunit>scheme is a weird language. all of these different standards, SRFIs, and implementation differences.
<mark_weaver>it's a very diverse community, which has its pros and cons.
<mark_weaver>it may be better to think of it as a family of closely related languages.
<davexunit>yeah. I treat Guile as its own language.
<ijp>davexunit: lisp has always been prone to splintering
<ijp>CL basically killed most of that outside of scheme
<ijp>okay, I got an email on friday from David Kastrup about an issue he is having in guile, and I can't really make heads or tails of it
<ijp>I've pasted it
<ijp>(since it's personal, I've set it to expire after a week)
*mark_weaver looks
<ijp>it's a module issue of some sort, but since he says he is having trouble reproducing I'm not sure if it's him or us
<ijp>nothing in the referenced commit should have triggered problems, since it was more or less moving a macro to another module
<mark_weaver>ijp: it looks to me like 'define-public' is being used somewhere it hasn't been defined, so it's tried to treat (chord-name->italian-markup re-with-eacute) as a procedure call.
<mark_weaver>and the first thing it does is try to look up 'chord-name->italian-markup', which is not yet bound.
<ijp>define-public is in boot-9 though
<add^_>Meh, I can't seem to understand even the first problem.
*add^_ hasn't been trying all this time but still a fair amount of time.
<mark_weaver>true, but that's still what it looks like.
<mark_weaver>lilypond is kind of a nightmare, because they've done all sorts of hacks that make assumptions about guile internals.
<mark_weaver>a macro is only recognized as such if the macro expander knows about its definition at expansion time.
<ijp>what's the usual evaluation order? do we have one?
<mark_weaver>in guile 1.8, macro expansion was done lazily, so that issue didn't exist.
<ijp>left-to-right is pretty normal in guile, even if we don't guarantee it, right?
<mark_weaver>in practice, it seems to usually be left-to-right, but I don't know how consistent that is. we make no guarantees.
<ijp>so then why would it not blow up on define-public?
<mark_weaver>it's possible that optimizations might change that.
<ijp>I suppose so
<mark_weaver>as you say, 'define-public' is in boot-9, so it's almost certainly in the actual module.
<mark_weaver>however, if the macro expander doesn't know about it, then it won't be treated as a macro.
<mark_weaver>macros are actually stored in the module as procedures.
<mark_weaver>(specially marked)
<ijp>might as well email him back and ask for a pointer to the file, and those responsible for the module trickery they are doing
<mark_weaver>it's the macro expander that recognizes them as macros and treats them as such.
<ijp>that's a good point
<mark_weaver>ijp: you can ask him to email me. I'd be glad to talk to him.
<ijp>okay, will do
<mark_weaver>I think what's happening is that the module import of curried-definitions is being done in such a way that the macro expander doesn't see it.
<mark_weaver>Because Guile 1.8 expanded macros lazily, you could actually define a procedure that used a macro, before the macro was defined, and it would work.
<add^_>I seem to be getting the right answer to the example they give (with all multiples of 3 and 5 from 0-9 becomes 23), but the 1000 one seems to be wrong.
<mark_weaver>(as long as the macro was defined before the macro use was evaluated)
*add^_ feels silly
<mark_weaver>you're probably counting things like 15 twice. that's a common mistake
<add^_>Thanks for the hint though
<mark_weaver>no doubt lilypond has grown a lot of stuff that depends on this laziness.
<mark_weaver>well, I confess that none of the explanations I have given fully explain what's going on there.
<mark_weaver>He asked "Can you think of some scenario where the redefinitions of define and define* (and define*-public) for curried-definitions will survive, while define-public doesn't?", and I still don't have an answer to that.
<stis>evening guilers!
<ijp>nobody has a problem with me just pushing a quick fix to I take it?
*mark_weaver looks
<ijp>the commit message is longer than the patch :P
<mark_weaver>ijp: go for it! thanks :)
<ijp>what's the email for closing in deb bugs again?
<ijp>just NNNNN-done@debbugs ?
<mark_weaver>it would be good to reference the bug number in the commit message.
<mark_weaver>I usually say something like this:;a=commitdiff;h=088cfb7d761b01a2620d78f10e8dbcaa07485a32
<ijp>yes, it would have been... had it not occurred to me after hitting push
<mark_weaver>no worries...
<mark_weaver>thanks again :)
<ijp>mark_weaver: looking through the backlog, I see you and weinholt have been very busy :)
<mark_weaver>indeed! :)
<ijp>what's the state of minigmp these days?
<mark_weaver>I made all the changes that should have been needed to allow its use in Guile.
<mark_weaver>but I haven't actually tried it, or made the changes to the build system to do it.
<mark_weaver>minigmp is apparently used to bootstrap the full gmp library, so it must work at least somewhat.
<mark_weaver>afaik, it's supposed to work.
<ijp>cool cool
<mark_weaver>going afk for a while... ttyl!