IRC channel logs
2025-01-19.log
back to list of logs
<dodoyada>ayyy, this works! for "BEGIN;", "COMMIT;", and "ROLLBACK;" you have to use sqlite-exec instead of sqlite-prepare <jmes>Is there an SRFI or something that does this (https://bpa.st/6N6Q) already? I find building a list using conditional expressions (∴ excluding #f & #<unspecified>) a quite common thing to do. <jmes>Or maybe you folks have some smarter way of doing it that I overlooked. <shawnw>(filter (lambda (elem) (not (or (unspecified? elem) (not elem)))) xs) or the like? <jmes>shawnw: Thanks, that's a much cleaner way to write "cond-list". I'm still curious if it is defined in some SRFI though 🤔 <mwette>lechner: it looks to me like a lambda form did not get converted to a pointer <rlb>I don't know that I'll do anything about it right now, but is there any (general) reason for us to avoid using _r variants when they're available, e.g. ttyname_r()? <mightysands>Hey, I'm thinking of teaching myself scheme or common-lisp, but I noticed that producing executable binaries in Steel Bank Common Lisp is pretty large (23M for "hello world"). I've heard scheme is more minimalist but that there isn't really a way to generate binaries in scheme. Is this true ? <rlb>mightysands: "it depends" -- guile itself isn't currently oriented that way, but I believe some other schemes may be. <rlb>Though even once it's "ready", it might not be aimed at what you want. <mightysands>rlb: How do you mean exactly when you say that guile itself isn't oriented in that way ? <rlb>Guile's more like perl/python/ruby in the sense that it expects you to share libguile and its attendant lib tree among multiple applications/scripts/etc. Whether you're writing a #!/usr/bin/guile... script or compiling/linking a binary against libguile. <rlb>You'll still have the /usr/share/... tree of scheme files (at least the compiled .go files). <rlb>(Though of course you *could* strip that down to just what you need for your application if you were determined, and you *could* put all of those into a single file, etc. -- but that'd be nontrivial effort.) <mightysands>Ah, so Common-lisp or Racket might be better if I want it to run on a machine which might not have a guile interpreter ? <rlb>I imagine that depends on the common lisp (don't really know racket). And perhaps. Guile's pretty common these days, so a dependency (in say debian) on guile-3.0-libs might not be a big hurdle, but, dunno. <rlb>(compared to other things I'd looked at in the past) <mightysands>I'm thinking I might install guix over the next year or so. In the meantime, I'm wanting to practice writing a fuzzer and other tools for teaching myself cybersecurity, as well as likely setup a website or two. Given this, do you have any idea if Guile or common-lisp might be a better fit ? <rlb>If I were building a web (http(s)) *server* type thing, personally, I'd probably use clojure proper because that's once of its core competencies and it's quite capable there (*and* I have a good bit of experience there), but if I wanted to learn a lispish language and/or *programming* better, I'd pick a scheme over pretty much anything else to start. <mightysands>I'm surprised by that. Given that clojure runs on the JVM, I'd imagine it'd be more resource intensive and be quite slow <rlb>Hmm, hard to speak generally, but I tend to position the *jvm* below c/c++/rust/etc. but above a lot of other common things things like python/perl/ruby, wrt performance, and I suspect it's a good bit faster than guile on average, and other lisp-ish languages that don't compile to native code, *but*... <rlb>Performance can vary widely, depending on the specfic tasks/libs/etc., and *clojure* on the jvm isn't going to be nearly as fast as careful java code on average, but there's a lot you can do with type hints, etc. to get it much closer much of the time when you need to to. <rlb>And the jvm has its own tradeoffs, though on the plus side, you can generate an uberjar that's likely to still work exactly the same many years from now on a much newer jvm... <rlb>As roughly always, everything involves many tradeoffs. <rlb>If you're concerned about 23m binaries (and not saying you shouldn't be), and you don't want to solve that via amortizing the cost of a shared base across apps, then I suspect you'll narrow the field quite a bit. <mightysands>What confuses me is that Guile is an implementation of scheme, as one can write anything they want in scheme, but all the documentation about guile I find online only talks about using it as an extension for C programs... <mightysands>Surely what one can write in common-lisp, one could write in guile scheme ? <rlb>That's been one of guile's focuses for a long time, and it is notable on that front, i.e. solid C api for scheme, etc. <rlb>mightysands: ...and sure, but that's a much broader question -- and true for any/every other language? :) <rlb>And *lots* of non-technical factors involved, e.g. why is python one of, if not the most, "popular" language. <mightysands>well, python is because people are lemmings and Google wrote in Python which set a trend circa 2009 iirc <rlb>I'd argue, for example, that as long as you're willing to hand-wave away all kinds of questions (e.g. security-related) you shouldn't have, being able to just add a single line to your project and automatically download 200+ deps from "somewhere" that then "work", is hard to compete against if you're not. <rlb>There's finally a bit more attention being paid to those questions (in recent years), but you don't have to look far to see how often it still goes wrong. <mightysands>rlb: That's the thing, I'd rather avoid having 100 dependencies for a simple program. It's what puts me off of using Rust. Most of their help forums consist of people recommending more packages <mightysands>Rust is a nice lang. But lispers seem more self-sufficient by nature on average - so I'm wanting to learn a lisp <rlb>If you think you may be headed for guix, that'd probably decide it for now for me -- can always change your mind, and much of what you learn about the language will transfer just fine. <mightysands>Guile will be useful given it's integral to running Guix - but is it fast/small/portable enough for me to run scripts relating to red/blue teaming? CL might be better for that, but then people keep recommending racket <rlb>Though racket might (haven't really used it myself) be a more learning oriented envt to start -- dunno. <rlb>I don't think I know enough about your particular domain to be much help wrt those constraints. <mightysands>From what I've seen, there's a lot more material out there relating to both Guile and CL - so as far as education resources go, racket is the hardest I think <mightysands>Turns out Racket's compiled binaries just contain the Racket compiler itself as well, so for my purposes, Racket has 0 advantages over CL <mightysands>So I'd like to ask, (I appreciate your help so far in helping me decide), have there been any prominent examples of applications/Tools being written in Guile ? <rlb>gnucash, at least in the past, not sure what it's doing now. (all of guix of course) <rlb>Also, make and gdb (can) use it as an extension language now... <rlb>But other than clojure and emacs, are there many lisp-family languages with a lot of "prominent" tools/apps, at least public/non-proprietary ones? <dsmith>Scheme is a beautiful language. But it then biases you. (ar at least me). When I see CL, it's just... icky. <dsmith>Well, autocad was (is) extensible in a lisp. <rlb>Sure, though of course that goes in the proprietary bin, and I think I've heard stories about govt/mil/financial/industrial use, etc. <dsmith>Not sure about now, but the exchange format for EDA stuff was s-exp based. (probably becuse a lot of the tools were in lisp) <rlb>there's also sxml iirc <rlb>docbook, etc. I mean <dsmith>mightysands, Check that guile-software link ^^ <rlb>and of course iiuc, (effectively) mathematica <ttz>It's pretty much a work in progress, but I already have some interesting results regarding functional mappings for Guile: I benched (language cps intmap), SRFI-146 HAMT and my own implementations of a splay tree, the two flavors of patricia trees, and a B-tree. Overall, the B-tree is competitive with the hash-table for lookups and performs within a factor 10 for insertions on small mapping sizes, and 5 for bigger mappings. <ttz>Also of note, The Guile's SRFI-146 implementation is rather slow, and data-structures from (pfds) are either slow or buggy (I couldn't get the HAMT to work, help wanted if someone is using it) <ttz>Any comments are welcome :) <rlb>ttz: just checking - you didn't happen to try fash? <rlb>Only asking because I'm curious. <rlb>ttz: pfds did have some bugs (used to use it for lokke before I switched to fash -- might have some patches if you want to pursue it) <ttz>can you point me to fash ? <rlb>And note that it doesn't currently have a delete operation. <ttz>I can only see only see one branch and three commits <rlb>oops "git log -p --follow mod/lokke/fash.scm" -- it moved. <lechner>mwette / Thanks! I am so lost. The error occurs only when I try to authenticate via PAM in a Guile script but not in the regular ELF getty, but i know it happens on the pam_guile.so module side. Is there any way to get a location for the error? <mwette>it says this call: pam_sm_acct_mgmt <mwette>ACTION thinks standalone guile programs may be doable; working it again <lechner>that's on the consumer side, but the error occurs on the module side. it only happens when the executable is already in Guile mode (scm_thread) I think <lechner>there is no Guile call by that name on the module side <lechner>everything i say is highly speculative at this point. i have to think it through <lechner>my module is a shared object that calls libguile <ttz>rlb: so I benched your fash (used the commit 21a4f19bcb). It is really good on small mappings (32 elements): it performs better than a b-tree for insertion with similar look-ups times. However it does not seem to scale as good as the b-tree since on bigger mappings (1e6) the b-tree is faster on insertion with still similar look-up times. <mwette>lechner: maybe use gdb; I think the w/guile version can print guile objects <rlb>mwette: also, some bits in guile's source tree gdbinit that might be relevant... <rlb>./gdbinit in the source <rlb>ttz: thanks, though it's really wingo's, rather than mine. <rlb>And sounds at least from that testing like fash would be better for (guessing) the common cases, i.e. I suspect in say clojure I'm dealing with < 100k items much/most of the time -- though might also be interesting to evaluate the overhead, i.e. how much space does each one require, etc. <ttz>Idk really know how to measure it so I just had a look at a top while running the benches for each at 1e7 elements : my btree tops at 7% usage while fash at 10%, so I'd say there is a 50% memory overhead. <rlb>(I pulled some of the 32-bit fixes forward and fixed some test issues.) <rlb>Though that's probably easier to look at as the applied patches via gitk, etc. <rlb>I just noticed earlier that gitlab may not actually render all the commits in its history, i.e. those applied patches are missing it the gitlab "history", but they're fine via git log --graph, gitk, etc.