IRC channel logs


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
<zv>oh tons
<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>goops is interesting
<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
<mordocai>And i LOVE CLOS
<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
<ijp>on the contrary
<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
<mordocai>zv: Nah, that never does what I mean
<mordocai>I was thinking of Interlisp of course
<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>Got my guile portion "done". I welcome pull requests and/or suggestions. Will be doing presentation in... 16 hours.
<mordocai>I'm also going to record it
<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
<daviid>here are 2 links if you are interested: and
<mordocai>daviid: Added to the presentation
<daviid>cool, you're fast!
<amz3`>mordocai: there is also guile fiber
<wingo>let's release some guile today
<lloda>wingo: looked at my revised patchset by any chance?
<wingo>i just mailed you :)
<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.
<dsmith>sneek, uptime
<dsmith>sneek, botsnack
<dsmith>sneek, seen wingo?
<sneek>wingo was here Jul 14 at 09:46 am UTC, saying: i just mailed you :).
<dsmith>Cool. Looks like he is up
<dsmith>(power outage last night)
<wingo>sneek: botsnack :)
<civodul>anyone tried Nausicaa on Guile recently?
<davexunit>what's that?
<wingo>is that still a thing?
<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>very interesting
<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
<wingo>funny stuff
<ijp>civodul: I think marco maggi decided a few years back to make it vicare only
<dsmith-work>Morning Greetings, Guilers
<wingo>civodul: do you want to add something to ?
<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>small set btw
<wingo>ok, feeling a bit alone here :)
<wingo>i just release.
<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>or not? blah
<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>this script uses gigabytes of data:
<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?
<ArneBab>damn… thank you!
<lloda>wingo: I've sent a revised patchset dropping C99
<wingo>lloda: hehe, i made you give up ;)
<wingo>sorry 'bout that
<wingo>it's just a bit complicated
<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
<ArneBab>wingo: yay 2.0.12! Thank you very much!
<janneke>hey wingo!
<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>fun :)
<wingo>janneke: your thoughts welcome re: recent mingw work
<wingo>actually, a mingw build of 2.0.12 is welcome :)
<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>guile gives it 110%
<ijp>ArneBab: there is a separate thread used for finalisation
<dsmith-work>ijp: I like the first answer better
<ArneBab>in the garbage collector?
<ArneBab>dsmith-work: it actually used 110% ☺
<ArneBab>ijp: I now changed my script to actually be tail-recursive:
<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>SICP exercise 4.20
<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>i see
<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
<ijp>no sweat
<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>;;; ERROR: no such language wisp
<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>it does not ring bells
<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
<ArneBab>wingo: sorry
<wingo>np :)
<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
<zv>i'll take a look
<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?
<wingo>dsmith-work: :)
<DeeEff[m]>ijp (IRC): yes, those.
<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
<DeeEff[m]>I'll try to find the presentation on them
<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