IRC channel logs


back to list of logs

<daviid>singpolyma: i just wanted to offer a few comments to the very well written (as usual) dthompson's goops related blog - and i'd like to add, after those coments i made, especially for the new comers who wouldn't know, that dthompson is one of the rare goops wizard! I invite the new comers here, who are interested in using goops, to read dthompson's code: not only is he a goops wizard, but his programming style is as perfect as a human
<daviid>can expect it to be, and his project structuring and organization is also always extremely well thought and an example
<old>I've refactored your mcron job. I have not test it though
<old>I don't know if notify-send could accept the body of the message from stdin.
<mfiano>whereiseveryone: Doesn't make much sense, and a lot of it is spread across different SRFI's already
<mfiano>A lot of it really only makes sense for CL
<mfiano>I don't know how much % of the stuff that doesn't already exists in some SRFI or Guile function
<mfiano>daviid: Thanks for the extensive details!
<whereiseveryone>daviid: daviid != davidthompson TIL
<whereiseveryone>old: thanks!
<whereiseveryone>I tried it but it's not working. I'm going to push what I changed to a branch in case you have some further advice.
<whereiseveryone>old: someone mentioned the other day that what I might need here is pipeline instead of open-pipe
<old>the problem with pipeline is that you need to pass the same fortune to two different processes
<old>If espeak can `tee' its input to stdout and if notify-send can get its input from stdin then yes you can use pipeline
<whereiseveryone>looks like that answer does what I was doing before with the non cool non guile way
<old>ehh not great
<old>anyway, you would need espeak to write its input to stdout for that to work
<whereiseveryone>how about with notify-pipe?
<old>which is why I've used two `open-pipe' instead
<old>is it available on Guix?
<whereiseveryone>but notify-pipe is a script
<old>Can't find it in package libnotify
<whereiseveryone>the author of that SO post has it posted as a snippet
<whereiseveryone>notify-pipe is a code snippet shell script in that SO post
<whereiseveryone>it's a hack
<mfiano>Guile has some of the best POSIX support. Don't think you need to shell out and can make the syscalls yourself
<whereiseveryone>that's hardcore
<whereiseveryone>but I'll make it my NY resolution
<mfiano>Nope, still in software :)
<mfiano>Closer to hardcore though
<whereiseveryone>mfiano: any tutorials you can recommend on making syscalls like that instead of shelling out?
<mfiano>I don't think a tutorial would help. libc is so unportable it's not even funny
<whereiseveryone>Or I just have to wait till I'm at C hacker level after reading specs and man pages for 20+ years
<whereiseveryone>How is SICL dealing with it?
<whereiseveryone>Sorry wrong room ;()
<mfiano>Yeah david thompson is dthompson on irc, but doesn't stay connected when they are inactive, so trying to contact them, like i have been, proves difficult
<mfiano>oh and he's here now!
<old>mfiano: You can use sneek for that :-)
<old>sneek: help
<old>sneek: seen dthompson
<sneek>dthompson?, pretty sure was seen in #guile 8 days ago, saying: :).
<old>sneek: botsnack
<mfiano>Good to know. I don't use bots much. I know he's on mastodon if i _really_ needed him
<mfiano>He is such a nice guy though, and I admire his years of game development-related Scheme work he has shared with us in #lispgames
<mfiano>He has been a big inspiration in my own work for years
<mfiano>dthompson: ^ :)
<mfiano>The reason I was trying to contact him, is because some details about CLOS in his GOOPS vs CLOS article are slightly inaccurate on the CLOS side. It was a very good article though, and the points he made are exactly the ones that I gathered by reading the manual.
<whereiseveryone>mfiano: I would just send him an email
<whereiseveryone>I sent him an email yesterday with a typo fix for that article and to ask a few questions ;()
<dthompson>hi mfiano! what did I get wrong?
<mfiano>Oh hi dthompson! One moment while I recollect
<dthompson>all the code I used in my blog post was code I tested inside on SBCL first.
<dthompson>inside of*
<mfiano>dthompson: "In CLOS, methods do not accept documentation strings, only generics do."
<mfiano>This part is wrong.
<mfiano>See the BNF
<dthompson>mfiano: thanks!
<mfiano>There was more...still looking
<dthompson>I must have done something wrong when I tried
<mfiano>Hmm I did one pass and didn't see anymore. Let's say that is all for now :)
<mfiano>But one thing I absolutely agree with in your article...
<mfiano>GOOPS actually leans on the arity mismatch in its documentation and implementation. I love that. COOPS (Chicken) is much more closer to CLOS if you wanted that, but doubtful :)
<dthompson>I like the name more!
<mfiano>COOPS has standard method combination auxiliary qualifiers
<dthompson>I'd like to one day add those to GOOPs
<mfiano>I don't like it though. It's too much like CLOS. I really like the extra features GOOPS brought, and I agree with the features it dropped
<mfiano>Like, can i tell you something about the around/before/after qualifiers?
<dthompson>fixed the blog post btw. thanks again.
<mfiano>Well specifically for AROUND...
<mfiano>I do not like AROUND whatsoever. It seems very useful, but it can pose a really huge problem.
<mfiano>If a supplying library both defines a generic and supplies an around method that is intended to do some work before and after any user defined methods....
<mfiano>If a user were to define their own around method for any of their own types specialized....
<dthompson>let me guess: those more specialized methods would run *first*
<mfiano>and they never call CALL-NEXT-METHOD, the protocol is ruined, and the supplying library's AROUND method is never called.
<mfiano>and it might be important that it is, because the around method determines the return value
<dthompson>yeah, you can get into trouble all over the place if you forget to call the next method
<mfiano>You can't prevent someone from defining an around method, so your protocol must also be in prose stating they either cannot do so, or must call call-next-method if they do, or something like that
<mfiano>it's a real pain
<dthompson>I wonder if there's something better than can be done. even with those problems, I have some code that would be much cleaner if I had the around qualifier.
<dthompson>I once looked at dto's source code for his "testament of the white cypress" game and that sold me on the utility of before/after/around
<mfiano>Yes, they are definitely useful.
<mfiano>They do add a lot of complexity though, and footguns for users.
<mfiano>It seems like a valid tradeoff to exclude them, but maybe it can be implemented with the MOP (does GOOPS have that like COOPS does? I forget), as a library.
<dthompson>there is a MOP, yes. I don't know if it's flexible enough to implement this. perhaps it is but I haven't seen how yet.
<dthompson>but hey thanks for all the good info! I am going to step away from the computer for the evening now.
<dthompson>I fixed a little bug in chickadee, so I feel accomplished. :)
<mfiano>Sure, thanks for the writeup. I enjoyed it!
<whereiseveryone>old: what's your email?
<whereiseveryone>this fails:
<dthompson>mfiano: glad someone read it! later!
<whereiseveryone>old: nm found it
<mfiano>whereiseveryone: You signed me up for guile-devel?
<mfiano>Oh, you CC'd me...
<whereiseveryone>mfiano: ya
<whereiseveryone>I bcc'ed you iirc
<mfiano>Got it, cool.
<mfiano>Threw me off is all.
<mfiano>A question of heresy: Anyone have any success in bringing geiser-like functionality to vim/neovim, or anything remotely comparable?
<mfiano>I use Emacs, but also vim if I can get away with it.
<whereiseveryone>mfiano: ya
<whereiseveryone>works with vscode and everything
<whereiseveryone>for the cool kids using vscode with guile...
<whereiseveryone>but also any lsp client
<mfiano>There are no instructions on how to use that with vim/neovim's client. I spent a while trying to get that to build only to find that out I have no idea how to use it.
<whereiseveryone>ya me neither
<whereiseveryone>i think you may be stuck in emacs again ha
<whereiseveryone>we need an emacs-lsp-server
<whereiseveryone>so that we can send all the emacs functionality through json-rpc
<whereiseveryone>via the lsp protocol
<whereiseveryone>or whatever is possible
<whereiseveryone>scheme-lsp-server depends on geiser so it is sort of doing that
<whereiseveryone>but don't quote me as I haven't studied that code base ;()
<flatwhatson>afaics the "geiser" used there is actually the scheme-side stuff for geiser
<flatwhatson>geiser is basically an emacs interface which communicates with a back-end implemented in each scheme
<flatwhatson>so scheme-lsp-server "uses geiser" but there's no elisp involved, just repurposing the backends
<mfiano>conjure seems to be closer to what I was looking for anyway
<mfiano>runs guile that listens on a socket, then talks to that for evaluating things.
<mfiano>nothing complicated
<flatwhatson>ah nice, straightforward repl support
<flatwhatson>geiser also supports completion, jump-to-definition, documentation lookup
<flatwhatson>also flycheck-guile does on-the-fly compilation error/warning display, by running "guild compile ..." in the background & parsing the output
<flatwhatson>there might be some "compile command" integration in vim to do similar, i find it quite useful for things like undefined references due to typos
<flatwhatson>also welcome mfiano, i've enjoyed your lisp content over the years, hope you'll enjoy your time with guile!
<mfiano>flatwhatson: Thank you, as have I yours.
<mfiano>I remember you being a doom maintainer at or around a time I was.
<flatwhatson>yes i still use & contribute to doom a bit, mainly to keep scheme support decent :)
<flatwhatson>i feel like there's a bit of a "scheme renaissance" happening, it's a good time for builders & communicators to join the community
<mfiano>I like that :)
<mfiano>I have used CL for so long, and while I do prefer it for some things, recently I have really begun to appreciate Scheme. I like how it is minimal and you can bring along just what you need. CL is just too old, large, not-very-cohesive-as-a-whole, standardized, beast. Not the best tool for every job :) I really appreciate the more Unix-like philosophy the Scheme community takes.
<mfiano>and Guile is by far my most preferred implementation, after browsing around on and off for a good year or so.
<whereiseveryone>old: this macro just adds the debug symbols to each package?
<mfiano>I think I finally got a decent guile environment set up, so time to get to business.
<whereiseveryone>mfiano: Why is guile the preferred implementation in your view?
<mfiano>I think I went into most of that yesterday.
<whereiseveryone>darn I must have missed it
<mfiano>Does anyone have a tips or resources they can share on how they prefer to organize modules in a complex program (something more than just a single-file "script")?
<mfiano>flatwhatson: maybe?
<whereiseveryone>mfiano: That was mentioned yesterday also ;()
<mfiano>Not sure who uses scheme to make big things :)
<whereiseveryone>check out all of dthompson's projects
<daviid>whereiseveryone: we all use guile to make big things :)
<whereiseveryone>and spritely
<whereiseveryone>and daviid
<whereiseveryone>mfiano: #spritely
<mfiano>Yeah i know of chris's work
<mfiano>or christine? i forget what their name is. They are very cool people though.
<whereiseveryone>you want a bigger repo than that?
<mfiano>I don't want a big repo.
<daviid>and guile-cv, g-golf - as i said earlier, definitely all dthompson projects, haunt, chickadee ..
<mfiano>I wanted a set of tips or tricks in prose.
<daviid>mfiano: you did organize things in packages in cl, no?
<mfiano>I did.
<daviid>then just do the same, in modules
<flatwhatson>basic project structure is to either add your project root or an immediate subdirectory (eg. src/) to guile's load-path
<mfiano>cl packages are a bit different than r6+ modules though
<mfiano>kinda can't really compare them imo
<flatwhatson>pick a top-level namespace for your modules, and then structure things under that. file-per-module, so my-project/some/module.scm -> (my-project some module)
<whereiseveryone>there's no package.lisp
<whereiseveryone>and no .asd file
<mfiano>flatwhatson: Should i use library or define-module?
<mfiano>Seems the former expands to the latter anyway
<flatwhatson>mfiano: most guile projects stick to define-module, it's "not portable" but scheme portability is complex enough that it needs to be an explicit goal of your project
<mfiano>But if you are going portable, which is hard anyway, prob don't want to depend on guile modules :)
<whereiseveryone>Those are two different styles I've seen in the wild
<whereiseveryone>They both are valid
<daviid>i was refrring more to the 'semantic spliting' of things, so to speak -
<daviid>mfiano: if you plan to use goops, it won't be portable anyway
<mfiano>Right. I don't care about being portable. That's a task and a half to keep up with even where it's easy in CL
<mfiano>I just want to get work done.
<daviid>but i see on the prcticle side of things, you are in good company, so back to hack
<mfiano>ACTION is old
<mfiano>But I'm not old. Hi old.
<whereiseveryone>define-module is probably what you want if you don't care about portability and want to do things like a guiler
<flatwhatson>just accepting guile as-is is a good place to start, there's a lot more functionality covered in the standard library than might seem at first glance, and very little of it counts as "portable" scheme
<mfiano>Yeah I noticed. standard guile is a lot of r6rs, in subtly incompatible ways, but that doesn't bother me
<daviid>define-module, also because it has the goops interface to let you merge generics - none of the r6[7] library interface have those options ofc ...
<mfiano>Yes, that is a nice feature
<flatwhatson>there's plenty more beyond r6rs though. (ice-9 match) (ice-9 peg) (ice-9 ftw) are my top picks for "getting work done"
<mfiano>Yes, much more on top of that even. I read the Guile manual from top to bottom and I was quite impressed.
<mfiano>I think before I dive in I'm going to read TSPL4 though. Just because, I like reading, and I am quite new to the Scheme way of thinking (some things are surprisingly different from CL that took me a while to get used to so far)
<whereiseveryone>sneek: later tell old: Are you planning to publish a package for the heredocs? I'd like to use em in my Guix code
<sneek>Will do.
<whereiseveryone>sneek: botsnack
<old>whereiseveryone: You can contact me at or . Althouth the latter is my university email, I'm not sure if it will be valid after this spring
<old>whereiseveryone: Yes the define-wf-package macro could probably use option transformer of Guix instead. I did that at a time I did not know about it :-/
<old>whereiseveryone: I've sent a RFC for having string interpolation in `ice-9 boot` It does not support whitespace trimming though.
<old>I could probably package it as a libray for now
<old>thanks for the invitation to Guix days btw
<whereiseveryone>old: That's great that you sent a patch for that! Hopefully someone will review and merge it. I love the idea/feature
<whereiseveryone>janet has a heredoc syntax like that also
<whereiseveryone>it uses backticks ``
<whereiseveryone>I'll decide on a day and time for the guile meetup at Guix Days soon and then I'll update the post to the guile-devel mailing list
<old>Hopefull. I was hoping for so feedback from the community since its an RFC and not a PATCH
<old>s/so feedback/some feedback
<old>backticks could be nice, but I wanted a solution that would not mess with paredit :-)
<old>+ hash read extension is very easy and the way to go to extend the reader
<old>Great. Thanks for your implication on this!
<old>truly appreciate that
<Kolev>Anybody written a GNOME app in Guile?
<drakonis> oooo
<old>I want to see a Guile with D lang
<old>What would be the consequence of two GC on the runtime
<daviid>Kolev: nomad, but their author had to step back for some personal reason - - in the past, i wrote a few using guile-gnome, gnu foliot for example [which i need to rewrite using g-golf, it still is using guile-gnome]
<Kolev>daviid: how does Nomad differ from Nyxt?
<daviid>Kolev: no idea
<a12l>I'm doing
<a12l>What kind of error should I raise in these kind of situations while using Scheme?
<mfiano>hi drakonis!
<mfiano>I forget what channels I see you in all the time but o/
<drakonis>small world, innit?
<mfiano>I remember a year ago when I was just learning Guile you were very active in this channel anyway.
<mfiano>nah not really. just too many people ;)
<drakonis>i'm everywhere that i find noteworthy
<mfiano>anyway, morning. i woke up looking forward to write real guile code for once.
<drakonis>ah, suddenly guile, eh?
<dthompson>mfiano: I had no idea you were getting into guile all this time. welcome aboard!
<drakonis>in the end, guile claims us all
<mfiano>I've been here for about a week learning scheme seriously for the first time. last year i read the manual top to bottom but a CL collaboration abruptly picked up and interrupted me.
<drakonis>good to have you back then!
<drakonis>a CL collaboration, was it?
<mfiano>I think you know what that one was
<drakonis>hmmm, my memory fails me
<drakonis>either way, its good to have you on board
<mfiano>My memory is coming back to me. I think you were following us
<mfiano>Maybe not
<drakonis>i dont think so
<mfiano>Well either way. Ignore me then. I am getting o l d
<drakonis>we all are
<drakonis>that said, did you like scheme, coming from CL?
<drakonis>mfiano: how's guile scheme treating you?
<drakonis>i'm looking forward to when the new gc enters
<drakonis>its a good time to be schemin'
<drakonis>that and ziggin'
<mfiano>drakonis: it's been good, thanks!
<mfiano>sorry, i just had a quick video chat with dthompson.
<mfiano>drakonis: i absolutely love it so far
<mfiano>I messed with clojure like 5 years ago for a bit, but too much hand holding and opinionated...and I have been following Julia for quite a few years...both very scheme like but nowhere near scheme, if that makes sense.
<drakonis>julia has a bit of scheme in it
<mfiano>but of all the schemes, guile is hands down my favorite
<mfiano>sadly my actual programming experience is probably >95% CL, so it's tough to get up that initial bump sometimes.
<mfiano>luckily I'm not one of the many CLers that doesn't see value in other languages. Guile is very exciting to me for some project ideas I have where it would make more sense than CL.
<drakonis>going from CL to scheme is perhaps easier than scheme to CL
<drakonis>i have a hard time because CL is giant and inconsistent
<drakonis>plus the community
<mfiano>yeah, guilty there :)
<mfiano>It's hard to understand the CL community unless you've been a CL user for a long time
<a12l>Is there an easy way to lookup the definition of a procedure from the standard library? E.g. from the REPL similar how you can lookup elisp functions inside Emacs
<mfiano>try ,help for more
<a12l>mfiano: I did run `,a string=\?` (trying to lookup the def. of `string=?`), but I only got `(guile): string=? #<procedure string=? (#:optional _ _ . _)>`. I can't find a way to get the whole def. of the function.
<mfiano>you might need to ,module
<a12l>When I run ,help a
<old>,describe string=?
<old>,a is for ,apropos and wil list stuff matching a regexp
<a12l>old: describe only shows the documentation for the function, and not it's implementation? Or I'm missing something? Can't find an answer when I run `,help describe`
<drakonis>mfiano: which project ideas do you have in mind for guile?
<old>a12l: for the implementation like the source code?
<a12l>old: Yes :)
<mfiano>drakonis: It's a secret, but let's just say there will be 1 more graphics programmer around these parts
<old>I don't think that this is available currently
<drakonis>very nice.
<old>But it would not be difficult to implement
<old>Could be a nice blog post to make
<drakonis>guile and scheme needs people.
<a12l>The reason I want to look at the implementation is that I need to write a string comparison procedure, but can't use any of the default ones. But I want to know how you traverse strings and compare them to other strings in a good way, and I figured that the string comparison functions in the standard library are the best one to read
<old>I think that source code reflection work only for GOOPs method
<old>I might be wrong here
<drakonis>oh and fosdem 2023's schedule is up
<drakonis>those are some good talks
<drakonis>esp. the ones here
<drakonis>has a will byrd talk
<dthompson>what a stacked line up
<old>a12l: best thing I would recommend for now, keep a source tree of Guile somehwere and open the source from there in your editor
<dthompson>perhaps the best ever
<drakonis>the most stacked deck in years
<mfiano>"Zig and Guile for fast code and a REPL" :thinking:
<mfiano>Sorry, but I think I'd rather have the dynamism stretching throughout my entire world
<drakonis>its actually a way to call zig code from guile instead of relying on c
<mfiano>Oh that's neat
<dthompson>I'd like to see pre-scheme realized in guile, personally, but this is very cool, too.
<drakonis>that too!
<drakonis>i appreciate the rust callouts
<a12l>old: Thanks for the tip! Actually thought of that first, but wanted to know if there was an easier way. The problem is that you've to find the definition of the procedure in the mix of all the usages of the function. :)
<drakonis> given this
<old>a12l: Typically I do: grep "define string=?" or something like that
<old>Guile is grep friendly enough that you get the "define" even if the procedure is in C
<drakonis>i'd like to see rust's developers quit it with the imperialism
<mfiano>I am lookinf most forward to the Andy's GC talk.
<roelj>I'm trying to cross-compile Guile, but it seems that the configure step looks for an already-installed Guile (and finds an old version which fails the configure step in my case). Why is that?
<old>a12l: So you can do `method-source` on a GOOP method to get the definition of it. Which is quite awesome imo
<old>a12l: Would be nice to have that for normal procedure
<old>roelj: You probably need guild for cross-compiling Guile objects
<roelj>old: Well, I'm just trying to compile the guile source tarball. I thought it could build itself without relying on an already-built Guile?
<old>Make sens. I'm not familiar enough with the build infrastructure though
<roelj>Thanks tho :)
<drakonis>i wonder if byrd's talk will create another chunky scheme project
<old>eeeh why is there so much talk about C ABI when it does not even exist
<old>It's System V ABI for Linux
<a12l>old: Thanks for the tips! I'll try to use them
<lilyp>while there is no singular C ABI, people generally say "C ABI" when they mean linking to C code
<old>I see
<drakonis>the main mistake, from what i understand, is that it is aiming to do multiple revisions of this
<drakonis>also encode way too much stuff there
<lilyp>and FWIW the idea behind those is pretty much the same on any platform
<lilyp>you get some function pointers (courtesy of dlopen and dlsym) and you jump to them while your memory and registers have some particular contents
<old>Would all of this be unessary if the calling convention and data representation are available in an ELF section, instead of only the symbols?
<lilyp>in your case, the ELF would only tell you how to lay out the registers and stuff, which the compiler can already figure out anyway
<lilyp>(that is assuming you have a consistent layout)
<lilyp>more importantly with languages that aren't C, you get funny symbols that no one in their right mind would want to type out
<lilyp>At least I wouldn't want to write _ZNK3MapI10StringName3RefI8GDScriptE10ComparatorIS0_E16DefaultAllocatorE3hasERKS0_
<old>Right. Reason #1 I hate debugging a C++ program
<old>Terrible backtrace and symbols resolution is a pain. Even unmangled
<lilyp>GDB should handle those, though
<lilyp>and transform them into beautiful Map<...>::has(...)
<lilyp>(even without debugging symbols)
<old>but having to `break Map<MySuperType>::has` is .. not fun
<lilyp>fair enough, but break has should set that one too
<old>My debugging experience C++ is terrible compared to C. Rust has been better on that point
<lilyp>what do you mean debugging Rust? Rust has no bugs :P
<old>oh right I forgot. the entire world is being rewritten in Rust. Can't have any bug in that
<drakonis>rust will take over the world
<old>In any case, it was easier to single step in Rust than C++ with a bunch of std::unique_pointer<....> and lambda functions
<old>You want to single step into your mapped procedure? Forget about it, you must single step the libc++ iterator procefure first!
<old>Then don't forget to single step the deference of the iterator!!
<old>drakonis: I hope not
<lilyp>in my personal experience with Guix, nothing has debug symbols, so you're single-stepping instructions anyway
<old>I hope that Scheme does :-0
<old>Don't want to try --with-debug-info=package ?
<lilyp>doesn't matter whether C, C++, or Stalin-compiled Scheme
<lilyp>ehh, too much work most of the time
<lilyp>as already said, break works with mangled symbols, which is enough for me as someone who can lexically analyse C++
<lilyp>under the assumption that grep works, which does not hold if you're browsing code on github
<old>I often find myself doing: guix build -S package
<old>then I can freely grep what I need in there
<old>Never opening a github link if I don't have to
<lilyp>yeah, that's probably good praxis
<ArneBab>I won’t present about Guile at FOSDEM this year — have no big new things, just incremental progress and practical work.