IRC channel logs
2023-06-06.log
back to list of logs
<rlb>wingo: oh, I guess it was your question wrt my 3.2 vs utf-8 comments above, and just found what I did wrt compile-cps (think you may have pointed me in the right direction a bit back). I just commented out the string-ref primcall converter for the moment. <mirai>RhodiumToad: okay, but how can I have it insert an empty list (without the quote being stripped away?) <mirai>(datum->syntax #f '()) doesn't do <rlb>...that was supposed to be ds<tab> to see if dsmith was back. <rlb>...just noticed your python question, and yeah, there was at least one hard-crash bug johill and I found (think originally discovered when I added randomized byte path arg tests to bup) -- back and forth between python and glibc, and eventually python just worked around it. I *think* cpython may finally handle things mostly right (integrity-wise), though may do so in some odd ways... <rlb>For one thing, it "smuggles" binary data through unicode strings via the reserved surrogates. <rlb>inefficient for bulk work, but at least doesn't mangle anymore (I think) <old>so I've been using Guile for 2-3 years now and I love. But I wonder if I should take the step to learn other lispy language. ofc there's emacs-lisp, but other than that <old>is it worth it to learn an other scheme like racket? Perhaps a CommonLisp instead of Scheme? <old>so in that respect, I would not learn much by using another Scheme <RhodiumToad>if you want to try another lisp dialect, go for a lisp-2 (scheme is a lisp-1) <old>okay so something like CommonLisp <rlb>old: I suppose clojure might be interesting wrt, for example, persistent data structures, its concurrency mechanisms and sequence abstraction... <rlb>Hah, fair enough, if we're moving past "lispy". <mwette>if you want to learn Common Lisp the Paul Graham books are good <rlb>I liked Sonya Keene's (I think it was?) book on CLOS too -- and I think some of the general domain applies to goops. <jpoiret>mirai: you probably want to compare the underlying data instead, using syntax->datum <jpoiret>syntax has additional stuff in it like source properties that will probably interfere with comparison <jpoiret>I have the feeling you shouldn't try to do it either way though, it might be too fragile <old>mwette: not sure about none lisp language <old>why would a guile xtension be installed under the extensions directory instead of just the lib directory of the system? <RhodiumToad>the most important reason is that so you can install the extension for two different guile versions at once <RhodiumToad>ACTION rather peeved at extensions that ignore this rule <old>but say I make a library and also making some guile bindings <old>it is okay for me to just install the library under the system lib directory <RhodiumToad>only if the library doesn't contain the guile bindings <old>all bindings are dynamically generated with the foreign function interface in scheme <old>so I guess that's okay <RhodiumToad>if it's a library with ordinary C entry points and which doesn't need to link against guile itself, yup <cow_2001>any good books on cs anyone should know? something handsony about algorithms and data structures? my math sucks butts. <daviid>RhodiumToad: i'll try to find some time to patch my guile-cairo patch, but it was essential (imo) to remove the hard coded path, so make check and make distcheck pass - this said, i agree that these 'old' libs, linking against guile itself, should install in GUILE_EXTENSION - feel free to patch the patch yourself, but if you do so, please do not re-introduce a hard coded path ... make sure it 'listens' to pre-inst-env and that make <RhodiumToad>what I did to make it work on freebsd with multiple versions is this: <RhodiumToad>CONFIGURE_ARGS+=--includedir='$${prefix}/include/guile/${GUILE_VER}' --libdir='$${prefix}/lib/guile/${GUILE_VER}/extensions' <RhodiumToad>and patch some Makefile.am files to have objdir=$(exec_prefix)/lib/ in place of objdir=$(libdir) <RhodiumToad>the result works with both g-golf and the old guile-gnome <RhodiumToad>(that version of the port is not committed yet, since it's tied up with a whole pile of other work to make concurrent guile version installs work) <daviid>RhodiumToad: ok, i don't have time to look at this now, wrt the (previously) hard coded path, just look at the branch before or at the patch itself ... <daviid>RhodiumToad: lloda did not commit it precisely because he also wish to patch the patch ... <daviid>RhodiumToad: are you still using guile-gnome? just curious <RhodiumToad>if I can get the guile versions stuff committed to freebsd ports, next up will be to make a port for g-golf and/or guile-gi, and at that point I'll abandon the guile-gnome port <daviid>RhodiumToad: you need to patch guile itself for freebsd? also just curious <RhodiumToad>oh, and picking up the latest commits so that spawn works <RhodiumToad>the build fixes are: freebsd sed doesn't accept -i without an argument, freebsd date doesn't accept the same options as GNU date <RhodiumToad>the incorrect type choice is scm_off_t gets the wrong type on 32-bit platforms <RhodiumToad>(freebsd doesn't have the disgusting largefiles shit, off_t is always 64 bits, and gen-scmconfig.c doesn't expect that) <rgherdt>is there a way to capture the warnings issued from `compile-file` into a variable? Tried parameterizing current-output-port and current-error-port without success