IRC channel logs
2016-07-14.log
back to list of logs
<mordocai>Hello! I'm putting together a short presentation on the "State of the Lisp Family" for my local meetup group tomorrow. Anything cool being done in Guile that I should be sure to mention? I'm already going to mention guix and https://dthompson.us/pages/software/sly.html. <zv>more and more each day <mordocai>zv: Assuming you are still around, anything specific you are excited about? <zv>it's not elisp, thats pretty big in my opinion. <zv>i'm sure there is some historical precedent for goops like systems, but it's better than racket's classes in my eyes. <mordocai>zv: Yeah, as far as GOOPs CLOS is listed as a large influence <zv>yeah but i mean try to put (let ((a 1)) (define (f x) (define b (+ a x)) (define a 5) (+ a b)) (f 10)) into common lisp <zv>you'd probably get an error <ijp>you'll get over clos eventually <zv>guile has the foresight to know you want something more important than errors - peace of mind that your errors wont be mentioned. <ijp>zv: we've been over this. it should be an error *here*. and that outer let isn't adding anything <zv>the internet has always been a less than ideal medium of jokemunication <ijp>it's not foresight, just an outcome of several pieces of complicated code <zv>ijp, think about the statement <zv>what programming language would you want to have hide your errors? <zv>a programming language that lets you feel better? <ijp>I don't program to feel better <zv>this is my last attempt at internet humor <zv>you feel better to program? <mordocai>zv: I want my programming language to automagically fix my errors without telling me of course! /s <zv>i dont know, it all kindof scares my **** out. <zv>the future of computing, the state of lisp <ijp>mordocai: compilers used to try and do that about 30/40 years ago <ijp>back when compilation was expensive <ijp>pl/c had the "feature" of never failing to compile a program <zv>when ijp is in #emacs he's throwing out bocoup bon mots and wacky witticisms <zv>when he's in guile he's all business <mordocai>Yeah, I don't remember all the details but I definitely read about an older lisp that was very "do what I mean not what I say" <zv>yeah, a "variant" of scheme called javascript <ijp>zv: I post funny stuff on here too, but I'm better when I have a steady flow of conversation. It stops me from monologuing <ijp>I posted some doggerel about 24h ago <zv>ah yes, the ijp vaudville act <mordocai>Most of those sections are WIP but I welcome suggestions on any of it of course <daviid>mordocai: nice. did you look at kawa? i recently changed from clojure to kawa for what i have to do in java, because it is GPL _and_ a lot betterabd better integrated to tha java class system <mordocai>daviid: I haven't, I'll take a look though <amz3`>mordocai: there is also guile fiber <wingo>let's release some guile today <lloda>wingo: looked at my revised patchset by any chance? <lloda>I believe someone runs a build farm? can we push the patch there and see what happens. <lloda>Is there even a list of the targets we support? Linux/BSD/Darwin/MinGW/Cygwin all have C99 compilers. Myself I can only test on darwin-amd64 w/gcc and linux-amd64 w/gcc though. <lloda>if we need to support all the Emacs platforms, then I have no idea. <sneek>wingo was here Jul 14 at 09:46 am UTC, saying: i just mailed you :). <civodul>anyone tried Nausicaa on Guile recently? <wingo>an r6rs library collection iirc <wingo>civodul: i found out what the problem was with the stack overflow in 2.0 with a stale boot-9.go <wingo>eval.scm used map for with-fluids, and the "throw" implementation uses with-fluids <wingo>so if there is an error thrown after Scheme throw is installed but before map is defined, bustage <ijp>civodul: I think marco maggi decided a few years back to make it vicare only <wingo>civodul: do you want to add something to libguile.map ? <wingo>i have the set of new symbols but there is nothign there for 2.0.11 etc <wingo>so i am hesitant to introduce a new thing at this point <wingo>scm_c_call_with_blocked_asyncs <wingo>scm_c_call_with_unblocked_asyncs <wingo>scm_pointer_to_procedure_with_errno <wingo>scm_set_automatic_finalization_enabled <wingo>ok, feeling a bit alone here :) <wingo>we can follow up if needed with a 2.0.13 <ijp>the superstitious will feel more comfortable if 2.0.13 is just a fix release <wingo>wtf gnulib update throwing me into an autoreconf loop <wingo>heh, i didn't notice that after some guix environment shenanigans, i was in my 2.2 directory <wingo>good thing i didn't push that tag :) <ArneBab>when I rewrote a function to use an inner named let instead of recursion on the function name, I got a stack overflow in 2.0.11. Did I just do it wrong or is there no tail recursion for named let? <ijp>can you give an example of this happening? <ArneBab>(and used to give a stack overflow, though I don’t see it right now) <ArneBab>(let lp ((x 1.e15)) (if (zero? x) x (+ 1 (lp (- x 1))))) <ijp>well, that code isn't tail recursive, but neither would have been the obvious define version <ArneBab>I guess I fumbled due to the (* a (lp ...)), right? <lloda>wingo: I've sent a revised patchset dropping C99 <wingo>lloda: hehe, i made you give up ;) <lloda>nah, I agree it deserves more discussion <wingo>@#$%^&*( distcheck failed because of guix's friggin linker wrapper <wingo>tarballs are up, please give them a go <wingo>ACTION heads home, will send release notes there <wingo>ftp.gnu.org/gnu/guile/guile-2.0.12.tar.xz <ArneBab>wingo: yay 2.0.12! Thank you very much! <janneke>ACTION 's somewhat proud to have written a minimal somwehat r3rs compliant scheme <janneke>r3rs says: experiment with macros...and my macro experiment seems good enough for and, or, let, letrec...but differs too much from scheme-48-0-21 to be able to use their define-syntax <wingo>janneke: your thoughts welcome re: recent mingw work <wingo>actually, a mingw build of 2.0.12 is welcome :) <wingo>ftp.gnu.org/gnu/guile/guile-2.0.12.tar.xz <janneke>wingo: my cross-build on guix is stalled atm <janneke>about a month ago, it worked on core-updates, but not on master <janneke>i spent a weekend on it and then decided to wait and pray it works when core-updates get merged <janneke>phant0mas helped to look into it...'twas one patch that broke the cross build <janneke>but that patch was also present in core-updates <wingo>we'll get it hydra'd eventually <janneke>wingo: a friend of mine looked into scheme->v8...he said that seems an almost impossible venture as v8 seems tightly coupled with javascript, any thoughts? <ArneBab>wingo: how comes that Guile can consume more than 100% CPU in single-threaded code? <ijp>ArneBab: there is a separate thread used for finalisation <ArneBab>dsmith-work: it actually used 110% ☺ <ArneBab>though it looked cleaner before that change <wingo>there's more to it than that <wingo>in guile 2.0 there is no finalization thread <wingo>but, in both guiles, there can be multiple mark threads <wingo>it's the mark threads generally that take the time. <ArneBab>wingo: I did not realize till now that Guile is taking advantage of multiple threads even if I don’t do that myself <wingo>there's a thread for signal handling as well <wingo>ArneBab: if you can rely on 2.2 (not 2.0), you can have non-tail-recursive algorithms without fear of running out of stack <wingo>ok i think the release is finally done <wingo>web page update queued, savannah news item, documentation updates, upload, release email. <zv>does anyone have any good ideas for keeping track of two (or more) separate lists while folding? <zv>(without just car/cdr) <wingo>srfi-1 fold can fold over two lists at once <zv>its more that I want to take one list and turn it into two lists <zv>converting a letrec into a let <ijp>ah, so multiple seeds <ijp>people generally just pass around lists <zv>i figure I need to take all of the let bindings and generate a *new* let that has (let ((binding1 '*unassigned) (binding2 '*unassigned)) (set! binding1 (lambda blah)) ... ) <zv>it seems a little improper to do that but that sounds sensible <ijp>you can also do something weird by passing around functions <ijp>I think SICP does something like that in the ch 5 assembler for labels <zv>i'll take a look at it <zv>thanks for all your help btw ijp <zv>there are numerous problems to which there are actually no (readily accessible) correct solutions -- its good to have someone that actually knows what they are doing <zv>whoa, new design for the guile docs! <ArneBab>wingo: with 2.0.12 I get "compilation failed" errors when running my wisp scripts from meta/guile: <ArneBab>;;; WARNING: compilation of /home/arne/Dokumente/eigenes/Programme/wisp/language/wisp/spec.scm failed: <ArneBab>wingo: that’s when running a script via <ArneBab>PATH=/tmp/guile-2.0.12/meta:$PATH $ guile -L . --language=wisp -e '(@@ (examples d6) main)' -s examples/d6.w <ArneBab>the script still runs, but it does not compile <ArneBab>or rather: the wisp language spec does not compile <wingo>have you been trying git or just 2.0.11? <ArneBab>… I’m checking something, might be my mistake <ArneBab>wingo: false alarm. I just have to precompile it without setting --language=wisp <wingo>zv: i didn't notice that when i was regenerating things; neat :) <wingo>i guess that's just newer makeinfo or something <ArneBab>and now with 2.0.12, readline support for wisp preserves newlines! <ArneBab>(which makes work in the REPL much nicer) <ArneBab>wingo: I knew about the stack size for 2.2, but I had wondered why I ran into the problem at all. Essentially I had misunderstood when a function call is in tail position… <zv>can I #define something to get the results of a particular macro expansion? in particular letrec*? <wingo>letrec* is a primitive and not a macro whose output you can understand <wingo>see the "fixing letrec, reloaded" paper if you are interested in how to implement letrec* <zv>sicp has just told me that its just a let with 'undefined vars in the beginning -- does that reflect actual implementation? <wingo>sicp has nothing to do with letrec* <wingo>sicp is related to letrec though of course <wingo>see the "fixing letrec" (but not reloaded :) paper for more on how to efficiently implement letrec <wingo>i believe that r6rs also discusses letrec in terms of let <wingo>if you haven't read r5rs it is worth your time <zv>like, the specification? <dsmith-work>wingo: Heh. I see some 2.2 product placement slipped into the 2.0.12 release message <DeeEff[m]>Just skip the ten pages on numbers unless you really like IEEE floating points <zv>another interesting thing i've been grappling with is how to break apart multiple (competing) components. for example the sicp evaluator replacing many functions incrementally -- some are quite large and make future development harder. How can I create what amounts to "a class" with components in guile lisp? <zv>like "I want an evaluator made up of immutable stack frames, simultaneous let definitions and the rest default", place that at the end of my file and then when I execute it I it overrides functions appropriately <zv>i took a look at guile modules and it seems like everything has to be in it's own file <ijp>DeeEff[m]: well, floating point only gets a very brief mention <ijp>I don't know if r7rs went back to the charade of non-floating-point inexacts <ijp>zv: they don't have to be, you can make even them dynamically, but for most purposes one-per-file is best <DeeEff[m]>IIRC R7RS leaves in a lot of parts relating to IEEE floating points. There's even some examples as to how bignums would differ to IEEE in implementation details <DeeEff[m]>that said why has nobody made a scheme with unums yet? <ijp>that'll keep mark_weaver entertained during the dark winter nights <DeeEff[m]>seems like an interesting idea, too bad I don't think I've seen anybody leverage them. <DeeEff[m]>more specifically, unums 2.0 seem really interesting <zv>variable sized integers seem like a difficult proposition <zv>its worth noting that with mantissa & the exponential modular identity you can get arbitrary precision as long as you are manipulating two numbers in the same order of magnitude for the base you are representing in <zv>admittedly people multiple numbers that are more than 2x greater or smaller quite regularly, but I think the precision shrinks logarithmically <zv>if my math class serves <DeeEff[m]>The way things are done in this presentation is really cool -> especially the symmetry in bits. <ijp>zv: bignums aren't that bad <DeeEff[m]>By just flipping between little and big endian readings you can invert entire number systems <ijp>everyone who finished primary school knows the algorithms by heart <ijp>which reminds me, I still need to implement division in mine <DeeEff[m]>zv (IRC): unums 2.0 (or Unums II) are fixed size as well <zv>i guess i'll have to read up on these unums <DeeEff[m]>they improve on the original unums in a couple of clever ways. <zv>it seems like he is proposibing variable width floats <DeeEff[m]>honestly it's a big topic and they don't work like normal numbers. <DeeEff[m]>you should read the link I posted just now too <DeeEff[m]>they expand on some basic operations a bit more <zv>ijp: i'd be curious to see your implementation of long division <zv>of course there are easier methods for bignums, but long division by computer would be neat anyway <ijp>I implemented division in arm assembly recently as an example for someone, but that just repeatedly adds the divisor