IRC channel logs
2022-11-29.log
back to list of logs
<whereiseveryone>is anyone able to see this msg? I finally identified with libera and made it to #guile <ft>It's visible alright. <sneek>I've been running for 20 days <sneek>This system has been up 4 weeks, 6 days, 14 hours, 12 minutes <whereiseveryone>in Python, I would just add breakpoint() in the code and run the debugger <whereiseveryone>I want to step through my fibonacci function and print variables and objects as I step <whereiseveryone>It's pretty easy to do this sort of thing with racket also in Dr Racket <dsmith-work>whereiseveryone: There are "comma commands" at the repl. Check out ,help debug <dsmith-work>I've not used them much. I usually use geiser and C-x C-e on some test expression <whereiseveryone>but that doesn't answer how to set a breakpoint in a specific function call like (foo 12) <whereiseveryone>dsmith-work: how do you set breakpoints in geiser for a function? C-x C-e is to evaluate an s-expression <whereiseveryone>It's very straightforward to do what I'm mentioning in the above mentioned languages <dsmith-work>I don't use breakpoints. I just test small things. Or I use pk <whereiseveryone>I tried this once also with a seasoned schemer once (gambit user) and they couldn't figure it out either <whereiseveryone>Does anyone know if it is actually possible to set a breakpoint with guile in a function call? <dsmith-work>You want to break on a call to fib with a specific argument. <whereiseveryone>But I just don't know how to get the debugger into a state of stepping through (fib 12) <whereiseveryone>As you're stating it that would just evaluate fib 12 to be the value <whereiseveryone>apteryx: do you know how to step through (fib 12) in the guile debugger? <dsmith-work>Yeah, that's what I'm thinking. Note, never used it... <whereiseveryone>in case anyone would like to try and learn to use/test out the guile debugger with me <spk121>i made a quick fib. Did ,br fib. Called (fib 12). did several iterations of ,locals ,next and ,bt. Works for me <old>There's been talked on the Guix mailing list for a Guile debugger work group. Maybe it would be interesting to publish a resume of that conversation on the Guile mailing list and have a discussion there <spk121>But the debugger isn't great. I use it as a last resort. <old>I feel like more and more people are having frustation with the current limitation of the debugging infrastructure <old>An yes `pk` is the way of doing thing right now along with REPL. But it's very hard for example to debug multi-threading that way <whereiseveryone>pk has it's place but it is a different thing than step debugging as I'm used to <old>I think I will parse the whole thread in Guix and note the important stuff then make a pulication on guile-devel <whereiseveryone>But unfortunately the inexperienced people that are learning guile struggle to learn how to even debug with guile so they might not be the right people to write the tutorial <old>dsmith-work: Sure. But the state of the art now in Guile is a mix of pk and re-evaluatoion <old>This is can be hard at first for newcomers coming from other runtime that have different paradigm. I come from C so I expect to be able to single step every instruction <old>So maybe a tutorial to show how to debug in Guile using the pk/REPL, but a single stepper debugger is much needed I think <old>My dream? Single step in GDB the instruction of Guile and C in the same window! <old>Sounds like a new blog post soon for that <whereiseveryone>feel free too plop those urls into invidious to protect your four freedoms ;() <whereiseveryone>I guess the guile documentation expects that you are coming from racket ;() <spk121>I do have a whole graphical Guile debugger project here at https://github.com/spk121/Guidance that got 75% complete before I got pulled off to other things. Maybe I can get back to it someday, but, my TODO list is so long. <whereiseveryone>I sent some patches recently to document some C SCM functions so they show up in the repl via ,d metacommand <whereiseveryone>spk121: Should we try to fix the debugger in guile first or document it? <whereiseveryone>It would involve low level hacking and issues as well as providing documentation which I believe should go hand in hand <spk121>whereiseveryone: I don't think the debugger in guile is broken, just limited <whereiseveryone>I want the debugging experience of Common Lisp in guile/geiser. I realize that might be too ambitious ;() <old>spk121: I saw that too. Very interesting <whereiseveryone>I don't think we should stop at just copying format, defmacro, CLOS, etc. from CL <spk121>maybe guix can organize something then. guile outside of guix doesn't really organize or meet, as far as I can tell <old>spk121: maybe that's another problem :/ <whereiseveryone>there's no reason that the guile community has to continue not meeting <whereiseveryone>I think guix is definitely sparking interest and motivation in guile maintenance and improvement in all areas <whereiseveryone>We want a solid language in all areas on which to continue building guix ;) <whereiseveryone>Would people like to attend a first guile debugger meetup in December or January? <old>To be fair, the documentation of Guile and Guix are probably the best I've read along with GCC <old>But there's thing missing, like pk <old>Ofc, it can always be better! <old>I'm not sure if decebmer is a good time. With the holidays coming and end of semester for students <whereiseveryone>and that's what we'll do with time hopefully but I'd like to push it along a little more and stimulate community involvement in improving it <old>I think it would be a good time yes. mid-january. <spk121>I've given up volunteering. Every time I've promised to do something for Guile with a deadline or deliverable, I somehow end up injuring myself or making a fool of myself, haha. But if someone else makes a meeting, I could try to jump in. <old>Maybe worth it to make a doogle or some poll just to be sure <old>spk121: Having inputs and support is a way to contribute without making promised <old>I do believe it's time for the community to gather around more and have a vision or something <old>Don't have to be: We need a debugger in 3 months <whereiseveryone>spk121: The idea is just to get a little more organized and so everyone can be better informed on what they can start working on/towards <dsmith-work>Personally, I've not used debuggers very much. Mostly because they were unavailable.. Just never got into the habit of using them. <old>I would like to participate in such effort. We however need someone that can organize things and take the leadership in that direction for some time <old>I don't think I fit this role personnaly dues to my young age <old>I prefer someone with more wisdom <old>Okay so will you make a poll for a date in january? <old>And how do we do with time-zone? Maybe recording is in order? <old>Yes with an header [ANN] <old>I don't know what it is personnaly. AS long I don't have to enter my email address or personal information I'm fine with it <old>Well if the Guix meetups have been organized on it, I think it's a good fit <old>I hope that your message resonate a little and we get at least a dozen of people and some veterans ^^ <old>well we're 2 so need 3 more :p <whereiseveryone>So, the theme for the first meet will be debugger maintenance and improvement? <dsmith-work>I was chatting with old the other day about stepping through elisp code. Something like that for Guile would be great. <whereiseveryone>We can keep the theme going on debugger work until we feel we should switch our efforts to something else <old>Yes that could be it. Let's not start on something too abstract or generic like: "Future of Guile" <whereiseveryone>I've built a few projects with Common Lisp and the debugger experience in CL is first class <whereiseveryone>I'm here for pragmatic improvements although I realize even those can be ambitious <old>If we can at least have the opinion of others on the state of debugging in Guile, we can grasp a better understanding of the problematic <old>Well we do have to start somewhere right? Having a conversation is the first step <whereiseveryone>Sending a poll to guile-devel to choose the first date is the first step <old>btw should I will send the resume of the conversation on guix-devel to guile-devel or guile-user? <old>I feel that guile-user might have more inputs from users, but the conversation is probably more toward development of Guile <whereiseveryone>Even if we just spend sometime orienting ourselves with the debugger code in guile and the issues for the first meet will be a success. Hopefully guile debugger veterans will be able to make it to lend their expertise <graywolf>Hi, I'm looking for a guile library to process (reading, writing) tar files. Any recommendations? <old>graywolf: There's none to my knowledge. Maybe in Guix they have something? <old>By Guix I meant in their modules <old>That's what I do also <old>I have a small module that unpack the tar into a temporary directory and archive it again when done <old>It's an auto-correction tool for a class I'm given at the university <old>I use Guix to build students project and schedule the guix-packed result into a HPC node :-) <old>It's not much though <graywolf>I need to manipulate details like uid/gid, file times, ..., I did not really figure out how to do it even using the gnu tar. I guess I'll write one. <graywolf>Then follow up question, guile seems to lack srfi 56 (read-byte, ...), how do I do that? <old>graywolf: `ice-9 suspendable-ports` seems to have a `read-bytes PORT DST START COUNT` <old>whereiseveryone: I've sent the resume of debugging conversation on guile-devel <graywolf>whereiseveryone: Ah, so the idea is to basically use the reference implementation that is sometimes attached to the SRFI. <whereiseveryone>graywolf: ya but maybe check out ice-9 first because it might be all you need <mwette>guile-jtd (referenced above) attempts to provide something like python's pdb.set_trace() <mwette>still some issues: e.g., writable locals are boxed and not in the local debug info; needs more love <mwette>the guix developers don't let anything slip under the radar <ArneBab>whereiseveryone: when you’re a newcomer is the best time to write a tutorial aboout the things you understand. It’s the only time you actually have the perspective of other newcomers, and you can ask to get information whether your approach is the right one. <whereiseveryone>ArneBab: How about the things the newcomer doesn't understand and are not documented? I think even Guile intermediate level devs struggle with that <whereiseveryone>As I mentioned above, a pretty seasoned schemer expert (gambit user) couldn't figure out the guile debugger after reading through docs for a few minutes <whereiseveryone>but yeah, in an ideal world, corporations would have chosen scheme and would have funded guile development and Emacs would have been the VSCode that everyone used <haugh>I know this is lighthearted but I strongly disagree. In my opinion there's nothing inherently wrong with the core principles of Python, but rather with popularity itself. Everyone used Python for everything, all at once. Nothing can survive that. <haugh>Personally if I had a multiverse machine I'd like to check out the one where TCL won. <dsmith-work>Everything you can do though their GUIs are acually TCL commands you can script. <haugh>I used to use TCL Expect to script configuration management for edge routers with cost-saving (read: very bad) console-only operating systems. There were tens of thousands of them all over the world. I really don't think I could have managed without expect. <haugh>Years later I land on Guile, and seeing (ice-9 expect) was like a sign from God that I was in the right place. <dsmith-work>Yep. I used expect for automating logging into serial ports on some embedded linux systems. (But later on I added ssh so no longer needed) <gnucode>it is really sad that scheme is still fairly niche. :( <haugh>dsmith-work, the last mile to some of these horrible little black boxes was GSM in a lot of cases. Awful situation but TCL Expect would just keep the connection open and wait. It never failed me. I haven't really used Guile's expect outside of playing around. Is it comparably reliable? <dsmith-work>Never used it. I looked at it *years* (decades?) ago. It seemed to be spinning on getting a char or something. Never looked again. The memory fades. <haugh>gnucode, look at it as an opportunity to see your ideas more readily implemented :) <haugh>Gun to my head I probably couldn't write an unassisted line of TCL right now <gnucode>haugh: fair enough. I wonder how hard it would be to make a "hardened-guile". eg: say that procedures take in an int and returns an int. <dsmith-work>The really sweet thing about TCL is how easy it is (was?) to write C code for it. If you know the inteface to main(), you can write a TCL function/command. <haugh>If you'll excuse me for using language I'm not at all qualified for, Guile's history of interfacing between languages is extremely encouraging to me even though I don't have a specific use case for it. Escape hatches and such, I suppose. <haugh>Sorry, I think that's the wrong repo. I'm aware of one major approach to add typed declarations across the board that was basically abandoned <gnucode>whereiseveryone: are you a fan of cl ?