IRC channel logs

2022-12-30.log

back to list of logs

<lilyp>mfiano: in case any of this wasn't answered: tests don't need to be modules, a good folder layout has the module tree – if you're mixing C and guile, use src/**/*.{c,h} and modules/**/*.{scm}
<mfiano>Thanks. I don't do C, so I'm safe on that part.
<mfiano>I'm reading TSPL4 and it says that it is idiomatic to use square brackets in addition to parentheses to make certain nested forms easier to read, like let and cond. I can't say I've seen this too much outside of Clojure and Racket. What does idiomatic Guile say to this?
<whereiseveryone>mfiano: it says to not do it
<whereiseveryone>but some do
<whereiseveryone>it's a matter of preference
<whereiseveryone>guix project does not do that
<mfiano>Who or where says this?
<whereiseveryone>but spritely does iirc
<whereiseveryone>it doesn't say it anywhere to my knowledge. I'm just speaking from the code bases I've seen out in the wild
<whereiseveryone>guile codebases, that is
<whereiseveryone>you see that more in the racket community
<mfiano>Yeah same, except Scheme in general, except for Racket because they want to be different anyway.
<whereiseveryone>I prefer to just use parens for everything
<whereiseveryone>it's much simpler
<whereiseveryone>just one token
<mfiano>I don't think I've ever seen Scheme that isn't Racket with square brackets. Though I guess I don't read too much Scheme.
<whereiseveryone>I find the square brackets confusing
<whereiseveryone>but that's just my preference
<mfiano>I am still torn.
<whereiseveryone>see the Guix code base
<whereiseveryone>for their style
<mfiano>No thanks.
<whereiseveryone>ha k
<whereiseveryone>or see dthompson's code
<whereiseveryone>haunt
<whereiseveryone>etc.
<whereiseveryone>no square brackets there iirc
<mfiano>Yeah I've seen his code for years. That's one of my main sources of seen Scheme code. :)
<whereiseveryone>arun isaac also doesn't use em
<whereiseveryone>I recommend his code. He has some really interesting projects
<mfiano>You know what?
<mfiano>I don't care what's idiomatic, because I'm not in CL land anymore. I shouldn't be afraid to post a snippet of code without pages of backlog offering style suggestions totally orthogonal to the question I asked.
<mfiano>That is literally what happens to everyone, no matter their experience, in the CL community. I never understood it.
<whereiseveryone>I thought people have different idioms in the CL community also?
<whereiseveryone>All I am saying is that certain groups and individuals have their idioms in the same way that various C projects have various styles. Not everyone follows the same style and that's cool.
<mfiano>There are 2 or 3 major style guides, with some conflicting recommendations. Then there are really old Lisper wisdom you are expected to know because a famous Lisper made some slides 40 years ago. And, then there is just the really opinionated nature of Lispers in general
<mfiano>I'm just saying, I cared more about style in CL because CL is this monolithic thing where everyone was watching you closely to make sure you were doing things right, otherwise you couldn't really ask a simple question about a snippet of code.
<whereiseveryone>I just use the aggressive-indent-mode style guide. Ain't nobody got time for style guides ;()
<mfiano>In Scheme, it's more build your own, do it your own way
<whereiseveryone>> otherwise you couldn't really ask a simple question about a snippet of code.
<whereiseveryone>I think that vibe is changing in the recent CL community though
<mfiano>It is recently. There are still 2 or 3 individuals that spoil it though, leaving walls of text whenever a paste link appears.
<whereiseveryone>CL community seems to be more inclusive now...
<whereiseveryone>hexmeme?
<whereiseveryone>s/hexstream?
<mfiano>i dont think they visit irc
<whereiseveryone>mfiano: this was a bit wild: https://github.com/Hexstream/enhanced-eval-when/issues/1#issuecomment-1343911147
<whereiseveryone>doesn't seem like they want to collaborate on foss in a community setting...
<whereiseveryone>but otherwise, the cl community at #common-lisp:matrix.org is nice
<whereiseveryone>and beach and Bike, at clschool, sicl, etc. and others
<whereiseveryone>I admire that they started something like clschool
<whereiseveryone>I think guile needs something like clschool
<mfiano>I don't think it does.
<whereiseveryone>not sure why you think that
<mfiano>This channel is quiet. It needs users. But they don't just come.
<whereiseveryone>I think the docs could be even better
<whereiseveryone>the docs are fine for a veteran as yourself but for a newbie it leaves a lot to be desired I think
<whereiseveryone>and I don't think guile should just be an elitist programmer community
<mfiano>Andy is just one person, and he is very hesitant to add new features. Even fibers is still a library because its his responsibility to make sure Guile is stable on a bunch of different architectures. But, he has said in the past he works best alone. I admire his responsibility as a project maintainer. You have to know when to say no, and when to make a breaking change and drop some users. Andy knows
<mfiano>how to do that well, but at the same time, it doesn't move fast.
<mfiano>and it doesn't get new features added fast, like some other languages, even those with single developers.
<mfiano>Because of that, we have few users, relatively speaking, but long time devoted users.
<mfiano>That is my take, anyway.
<whereiseveryone>well hopefully we can improve the debugger somehow
<whereiseveryone>;()
<whereiseveryone>I have to find time to read up on dwarf format now before guix days in between work
<whereiseveryone>and take a good read of the debugger code
<mfiano>I would much rather have a stable language I can depend on, than something that falls over like a deck of cards (like Nim)
<whereiseveryone>mfiano: Are you interested in understanding and contributing to the guile src code (C parts included) itself or you don't care to much about that?
<mfiano>Users aren't very important to me, nor are users of my code. I spent many years maintaining libraries. I just like to code now :)
<whereiseveryone>I haven't used Nim enough to see it fall like that but thanks for the insight
<mfiano>That sounded a little harsh, but whatevs :)
<whereiseveryone>haha
<mfiano>But that may change with Guile. It seems there are a lot of holes I can fill once I get coding.
<mfiano>Well holes that interest me, anyway.
<whereiseveryone>you're like the composers that play their own music only for themselves and their friends (who are also composers)
<whereiseveryone>which is also cool and funny in a way
<whereiseveryone>I'll be happy to use your code if that means that your code is contributions to guile ;()
<mfiano>It won't be. I don't C, and Andy recommends language extensions be libraries anyway.
<whereiseveryone>there's probably a lot to do in scheme also
<mfiano>It will be guile code, but not committed to guile the implementation.
<whereiseveryone>k
<whereiseveryone>in that case I'll just take ideas from your guile code once you start publishing thanks in advance ;()
<mfiano>Maybe though. I will be join the R7RS-large Committee B team soon, so some of that work may eventually make it into Guile.
<mfiano>joining*
<whereiseveryone>cool!
<whereiseveryone>what does the process for that look like?
<mfiano>Committee B is the "Batteries" team. Implementing SRFIs and new language features and stuff.
<whereiseveryone>is it as bureaucratic as becoming a debian developer?
<whereiseveryone>or simpler process?
<mfiano>I don't know. Ask jcowan.
<whereiseveryone>or you just send patches for new language features?
<mfiano>But I can't think that far off. I have a project idea that will take me a few weeks to write out a design document for, before I can even think about coding anything.
<whereiseveryone>what's your process for writing design docs?
<whereiseveryone>tldr
<mfiano>stream of conscious, patch holes, refactor, repeat
<whereiseveryone>does it involve diagrams of any sort?
<mfiano>No
<whereiseveryone>cool
<whereiseveryone>PSA: https://luis-felipe.gitlab.io/guile-proba/
<mfiano>What are you announcing?
<whereiseveryone>guile-proba
<whereiseveryone>version 0.2.0
<mfiano>Yeah, I brought it up here a couple days ago and yesterday.
<whereiseveryone>oh didn't see that
<whereiseveryone>;()
<whereiseveryone>I just forwarded that from #guile-steel lolz
<mfiano>It had a problem building on latest guix yesterday, and I told the author I'd try again tomorrow.
<mfiano>He can't reproduce. That's computers for ya.
<whereiseveryone>so much for the nix thesis
<mfiano>I have too much stuff to do already. I have to learn autotools and everything, so I can tell guix to either install library source code in the %load-path so others can depend on it...OR install an application executable on PATH for non-libraries.
<mfiano>But for now, I'm going to go relax and read some more of the scheme programming language fourth edition
<whereiseveryone>I need to get back to reading that. That's such a lucid book.
<whereiseveryone>unlike clhs...
<whereiseveryone>k g'night! off ta bed
<sneek>dsmith: Greetings :D
<dsmith>sneek, botsnack
<sneek>:)
<dsmith>!uptime
<sneek>I've been running for one month and 21 days
<sneek>This system has been up 9 weeks, 2 days, 12 hours, 41 minutes
<Kolev>I wish Guilemacs was off the ground.
<Kolev>I want my environment in Guile.
<old>Is epoll plan for core Guile? Right now there's only an interface in fibers
<Kolev>How to learn Scheme? Books?
<dthompson>Kolev: you might find this Scheme primer useful! https://spritely.institute/static/papers/scheme-primer.html
<daviid>Kolev: and https://scheme.com/tspl4/, also https://ds26gte.github.io/tyscheme/index.html
<old>Kolev: Not Scheme specific, but it uses the Scheme language: https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/index.html
<dthompson>does anyone know why continuations captured from an exception handler are not resumable?
<dthompson>my understanding is that a non-continuable exception is non-continuable because it will raise a &non-continuable exception after running the handler if you don't abort the continuation.
<dthompson>however I'd expect to be able to capture a continuation in the handler, resume it later, and be greeted with the &non-continuable exception. instead I get an "expecting resumable continuation" error.
<dthompson>what am I missing?
<dthompson>on the flip side, if a continuable exception is raised any captured continuations in an exception handler *are* resumable. I'm guessing this has to do with the call to the handler being in tail position.
<dthompson>but I don't really know. there's no continuation barrier being setup for non-continuable exceptions.
<daviid>sneek: later tell dsmith hny! i missed your brief appearance here today :), but wanted to ask you, would you agree to add our bot to ... also receive botsnacks from the #spritely channel?
<sneek>Okay.
<dthompson>alternate question: does anyone have tips on how to inspect vm continuation objects to find out *why* they are not resumable. like if I could see where a C stack frame was captured that would go a long way to understanding the underlying issue.
<old>dthompson: I think it's not continuable because the stack has been unwinded already
<old>While a continuable exception would be one where you can restart the computation since the stack is still intact
<dthompson>I'm using with-exception-handler's default of not unwinding the stack
<old>have you try with prompt instead?
<dthompson>I'm using prompts to capture continuations. with-exception-handler is also implemented using prompts.
<dthompson>I'm working on a problem where I'd like to re-raise an exception in another context but have the stack setup in such a way that the backtrace shows the frames of where the error first occurred, not where it was re-raised.
<dthompson>exceptions do not capture the stack in which they were made, so I feel like my only option is to capture a continuation with the chunk of the stack I'm interested in preserving.
<old>(make-stack k ...) ?
<old>you should get the stack of the captured continuation in your prompt handler
<dthompson>you can grab a stack object, but that won't do any good because guile's default exception handler has no way to use it
<dthompson>if you do ,bt in the REPL it displays the stack where the exception object was raised. if you're re-raising an exception from elsewhere, you lose the original stack info.
<dthompson>"origin stack preservation for re-raised exceptions" might be a good marketing phrase for what I want ;)
<dthompson>the bigger question I have is: why don't exception objects capture the stack in which they originated? in other languages I can call a function/method to print out a backtrace with only an exception object.
<dthompson>which means I can freely pass that object around wherever and still have the necessary context to make sense of the exception.
<old>something like python: traceback.print_exception ?
<old>But moving the exception around and doing it some place else than in the handler?
<old>I'm sorry I don't quite understand your use case I think
<Kolev>old: SICP works with Guile?
<old>Kolev: Any Scheme really I think
<old>I haven't any difficulty with Guile and SICP
<holomorph>dthompson: what ever happened to ice-9 json
<dthompson>holomorph: it get mired in too many patch review comments for me to want to continue with it and guile-json took off.
<dthompson>s/get/got/
<dthompson>I use a version of it in at least one, maybe more, of my own projects, though. :)
<holomorph>dthompson: dang. well i'm glad it lives on
<graywolf>Hi, assuming I have a list l, and want to call a procedure for each item together with its index, is there more elegant way then (for-each proc l (iota (length l)))?