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>it doesn't say it anywhere to my knowledge. I'm just speaking from the code bases I've seen out in the wild <mfiano>Yeah same, except Scheme in general, except for Racket because they want to be different anyway. <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. <mfiano>Yeah I've seen his code for years. That's one of my main sources of seen Scheme code. :) <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>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. <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>doesn't seem like they want to collaborate on foss in a community setting... <mfiano>This channel is quiet. It needs users. But they don't just come. <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. <whereiseveryone>I have to find time to read up on dwarf format now before guix days in between work <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 :) <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>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. <mfiano>It will be guile code, but not committed to guile the implementation. <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>Committee B is the "Batteries" team. Implementing SRFIs and new language features and stuff. <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. <mfiano>stream of conscious, patch holes, refactor, repeat <mfiano>Yeah, I brought it up here a couple days ago and yesterday. <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. <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 <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 <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>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? <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 <old>Kolev: Any Scheme really I think <old>I haven't any difficulty with Guile and SICP <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>I use a version of it in at least one, maybe more, of my own projects, though. :) <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)))?