IRC channel logs


back to list of logs

<whereiseveryone>is anyone able to see this msg? I finally identified with libera and made it to #guile
<whereiseveryone>i think?
<ft>It's visible alright.
<whereiseveryone>ft: good to hear
<ArneBab>whereiseveryone: yes, I see you
<whereiseveryone>ArneBab: great!
<dsmith-work>UGT Greetings, Guilers
<dsmith-work>sneek: botsnack
<sneek>I've been running for 20 days
<sneek>This system has been up 4 weeks, 6 days, 14 hours, 12 minutes
<whereiseveryone>How can I set a breakpoint for (fib 12)?
<whereiseveryone>I'm confused on how to do this with Guile's debugger
<whereiseveryone>in Python, I would just add breakpoint() in the code and run the debugger
<whereiseveryone>same for Common Lisp except I'd use (break)
<whereiseveryone>but Guile has no such thing from what I've seen in the docs
<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
<dsmith-work>whereiseveryone: Documneted here:
<whereiseveryone>dsmith-work: I've seen that already
<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've seen people doing that approach before
<dsmith-work>Old habits
<whereiseveryone>I've used the pk macro also
<whereiseveryone>to print debug
<whereiseveryone>But what I'm trying to do here is different
<whereiseveryone>to that
<whereiseveryone>I tried this once also with a seasoned schemer once (gambit user) and they couldn't figure it out either
<whereiseveryone>We tried reading the docs but it wasn't clear how to do this
<whereiseveryone>Does anyone know if it is actually possible to set a breakpoint with guile in a function call?
<whereiseveryone>maybe it's not possible currently?
<dsmith-work>Have you tried ",br proc-name"
<whereiseveryone>but that doesn't do what I'm talking about
<whereiseveryone>I want to set a breakpoint on a function call
<whereiseveryone>(fib 12)
<whereiseveryone>not on a function
<whereiseveryone>,br fib
<whereiseveryone>not that
<whereiseveryone>,br (fib 12)
<dsmith-work>You want to break on a call to fib with a specific argument.
<whereiseveryone>I'm befuddled
<whereiseveryone>yes, exactly
<dsmith-work>YEah, I don't think that's possible.
<whereiseveryone>So, how does Guile want me to step through a program then?
<whereiseveryone>It doesn't?
<whereiseveryone>only pk and reading stacktraces as they come?
<whereiseveryone>What are all the debug metacommands for then?
<whereiseveryone>It looks like there is a ,locals ,up ,down ,next ,step
<whereiseveryone>But I just don't know how to get the debugger into a state of stepping through (fib 12)
<whereiseveryone>frustrating ;)
<dsmith-work>If you evaluate (fib 12) doesn't it break at fib?
<whereiseveryone>As you're stating it that would just evaluate fib 12 to be the value
<whereiseveryone>You mean to first do `,br fib`?
<whereiseveryone>Then to try to evaluate `(fib 12)`?
<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>here's my opinionated guile fib for testing:
<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
<whereiseveryone>dsmith-work: doing `,bt fib` prints the following
<whereiseveryone>Nothing to debug.
<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
<whereiseveryone>old: that sounds like a great idea
<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
<whereiseveryone>I just want something as good as pdb
<whereiseveryone>which isn't that good
<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>I want to step through guix code.
<whereiseveryone>pk has it's place but it is a different thing than step debugging as I'm used to
<old>yes I agree
<whereiseveryone>I'd like to have both
<whereiseveryone>pk and proper step debugging
<old>I think I will parse the whole thread in Guix and note the important stuff then make a pulication on guile-devel
<whereiseveryone>old: that sounds awesome! You're a saint for doing that
<dsmith-work>A good guole debugging tutorial would be wonderful.
<whereiseveryone>dsmith-work: yup
<dsmith-work>And a guile one even better
<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
<whereiseveryone>and the experienced guilers don't care to write the tutorial lol
<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
<whereiseveryone>it's an interesting chicken egg problem
<whereiseveryone>chicken egg documentation problem
<whereiseveryone>a classic
<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
<whereiseveryone>I think a tutorial for both would be great
<old>My dream? Single step in GDB the instruction of Guile and C in the same window!
<whereiseveryone>That should be possible
<old>Sounds like a new blog post soon for that
<whereiseveryone>It's possible with CPython:
<apteryx>pk is not even documented ^^
<whereiseveryone>feel free too plop those urls into invidious to protect your four freedoms ;()
<whereiseveryone>let's document pk
<whereiseveryone>I guess the guile documentation expects that you are coming from racket ;()
<whereiseveryone>so you already know what pk is and are in the know
<spk121>I do have a whole graphical Guile debugger project here at 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>hopefully someone will review them
<whereiseveryone>it's sent from jgart
<whereiseveryone>spk121: I saw that before
<lloda>have you tried
<whereiseveryone>spk121: Should we try to fix the debugger in guile first or document it?
<whereiseveryone>Would people be interested in a guile debugger maintenance meetup?
<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>s/debugger current issues I mean
<whereiseveryone>Well, we can meet up to discuss how it is limited and to improve it
<whereiseveryone>I'm all for improving the debugger
<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>spk121: that's a problem
<whereiseveryone>there's no reason that the guile community has to continue not meeting
<whereiseveryone>we can organize it
<whereiseveryone>I think guix is definitely sparking interest and motivation in guile maintenance and improvement in all areas
<old>I agree
<whereiseveryone>We want a solid language in all areas on which to continue building guix ;)
<whereiseveryone>That includes the debugger
<whereiseveryone>I need a better debugger in order to understand Guix better
<whereiseveryone>I need better Guile docs in order to understand Guix better
<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
<whereiseveryone>It can be better
<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
<whereiseveryone>old: good point
<old>I think it would be a good time yes. mid-january.
<whereiseveryone>yup mid-january sounds good
<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
<whereiseveryone>I can invite Arun Isaac. He would probably come to it.
<whereiseveryone>as he's interested in helping with these efforts
<old>spk121: Having inputs and support is a way to contribute without making promised
<whereiseveryone>spk121: I'll make the meeting
<whereiseveryone>spk121: and there will be no deadlines or rush
<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
<whereiseveryone>old: I agree
<dsmith-work>Personally, I've not used debuggers very much. Mostly because they were unavailable.. Just never got into the habit of using them.
<whereiseveryone>fixing the debugger can be a 2 year long project or longer
<whereiseveryone>it's just ongoing
<whereiseveryone>be the important part is that we have a roadmap to follow
<whereiseveryone>no matter how long it will take
<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
<whereiseveryone>old: I can do that for now
<old>I don't think I fit this role personnaly dues to my young age
<whereiseveryone>I've done it for Guix before
<old>I prefer someone with more wisdom
<old>okay great!
<whereiseveryone>We can just invite the people that have the wisdom hahaha
<whereiseveryone>I'm not a guile veteran by any means
<old>Okay so will you make a poll for a date in january?
<whereiseveryone>but I have contributed a lot to Guix over the past few years
<whereiseveryone>and have worked on small guile projects
<whereiseveryone>old: sure
<old>And how do we do with time-zone? Maybe recording is in order?
<whereiseveryone>Send it to the guile-devel mailing list?
<whereiseveryone>We can do a recording over bug blue button
<whereiseveryone>If everyone is ok to use big blue button?
<old>Yes with an header [ANN]
<whereiseveryone>nixnet offers a free instance that I've used countless times for Guix packaging meetups:
<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
<whereiseveryone>old: yup no need to enter any of that with BBB
<whereiseveryone>BBB is free software and is used by the FSF
<old>Well if the Guix meetups have been organized on it, I think it's a good fit
<old>okay awesome
<whereiseveryone>The last major Guix conferences were held on BBB
<whereiseveryone>The perk of BBB is that it has recording built in
<old>I hope that your message resonate a little and we get at least a dozen of people and some veterans ^^
<whereiseveryone>TBH I think if just 5 people show up it would be a success
<whereiseveryone>We don't need 20 people to show although that would be great too
<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>old: agreed
<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>true :p
<whereiseveryone>I'll do that later today or tomorrow
<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>I agree it should be a message to guile-devel
<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
<dsmith-work>wingo: This means you
<whereiseveryone>wingo: yup ;()
<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
<whereiseveryone>graywolf: old guix just shells out iirc
<old>That's what I do also
<whereiseveryone>yup so maybe just do that ;()
<old>I have a small module that unpack the tar into a temporary directory and archive it again when done
<whereiseveryone>cool where's that?
<whereiseveryone>do you have a public git repo?
<old>It's an auto-correction tool for a class I'm given at the university
<whereiseveryone>cool, could you share it ;()
<whereiseveryone>I'd like to read it
<old>I use Guix to build students project and schedule the guix-packed result into a HPC node :-)
<whereiseveryone>if you don't mind
<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?
<whereiseveryone>old: cool thnx!
<whereiseveryone>graywolf: you might be able to load srfi-56 somehow
<whereiseveryone>graywolf: see here for example how to do that iirc:
<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
<whereiseveryone>old: cool, thnx for doing that!
<graywolf>whereiseveryone: Ah, so the idea is to basically use the reference implementation that is sometimes attached to the SRFI.
<graywolf>Thanks for the pointers everyone :)
<whereiseveryone>graywolf: ya but maybe check out ice-9 first because it might be all you need
<whereiseveryone>no probs
<mwette>guile-jtd (referenced above) attempts to provide something like python's pdb.set_trace()
<whereiseveryone>mwette: cool
<whereiseveryone>mwette: should that be consolidated into guile?
<whereiseveryone>would it be accepted? or should it stay as a lib?
<mwette>still some issues: e.g., writable locals are boxed and not in the local debug info; needs more love
<whereiseveryone>mwette here's some more jtd love:
<mwette>the guix developers don't let anything slip under the radar
<whereiseveryone>nope ;()
<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.
<ArneBab>(or how to do it better)
<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
<ArneBab>whereiseveryone: just ask about those. You may want to read — there I documented my path from Python to Scheme.
<whereiseveryone>ArneBab: I've already read that a few times
<whereiseveryone>ArneBab: thanks for the blog post
<whereiseveryone>I still like Python because that's how I feed my children.
<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>There *are* worse things than Python.
<dsmith-work>TCL is still alive and well in Xilinx land
<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.
<dsmith-work>Long long ago, Guile actually had Tk in it.
<dsmith-work>And so bits of TCL also.
<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>gnucode, BE WARNED
<gnucode>what we have a typed guile ?
<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
<whereiseveryone>haugh: gnucode toyhoyn has a typed guile
<whereiseveryone>it's called theme-d
<gnucode>interesting! two options!
<haugh>that's it, doesn't look as abandoned as I thought!
<whereiseveryone>Common Lisp has pretty nice typing support but it's not Guile ;(
<gnucode>that's pretty cool!
<gnucode>whereiseveryone: are you a fan of cl ?
<whereiseveryone>ya, I am but I'm also a fan of guile and guix
<gnucode>whereiseveryone: fair enough
<whereiseveryone>guix is my cl package manager
<flatwhatson>lloda: thanks for merges :)