IRC channel logs
2022-12-28.log
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>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>anyway, you would need espeak to write its input to stdout for that to work <old>which is why I've used two `open-pipe' instead <old>is it available on Guix? <old>Can't find it in package libnotify <mfiano>Guile has some of the best POSIX support. Don't think you need to shell out and can make the syscalls yourself <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 <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 <old>mfiano: You can use sneek for that :-) <old>sneek: seen dthompson <sneek>dthompson?, pretty sure was seen in #guile 8 days ago, saying: :). <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>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>I sent him an email yesterday with a typo fix for that article and to ask a few questions ;() <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. <mfiano>dthompson: "In CLOS, methods do not accept documentation strings, only generics do." <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 :) <mfiano>COOPS has standard method combination auxiliary qualifiers <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? <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 <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! <mfiano>whereiseveryone: You signed me up for guile-devel? <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. <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. <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. <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 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. <mfiano>I think I finally got a decent guile environment set up, so time to get to business. <mfiano>I think I went into most of that yesterday. <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>Not sure who uses scheme to make big things :) <daviid>whereiseveryone: we all use guile to make big things :) <mfiano>or christine? i forget what their name is. They are very cool people though. <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? <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) <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 :) <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 <daviid>but i see on the prcticle side of things, you are in good company, so back to hack <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 ... <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) <old>whereiseveryone: You can contact me at olivier-dion@proton.me or olivier.dion@polymtl.ca . 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>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? <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 - https://www.nongnu.org/nomad/ - 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? <a12l>What kind of error should I raise in these kind of situations while using Scheme? <mfiano>I forget what channels I see you in all the time but o/ <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 ;) <mfiano>anyway, morning. i woke up looking forward to write real guile code for once. <dthompson>mfiano: I had no idea you were getting into guile all this time. welcome aboard! <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. <mfiano>I think you know what that one was <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>Well either way. Ignore me then. I am getting o l d <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 <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. <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 <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 <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. <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? <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 <old>But it would not be difficult to implement <old>Could be a nice blog post to make <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 <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 <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 <dthompson>I'd like to see pre-scheme realized in guile, personally, but this is very cool, too. <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. :) <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 <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 <drakonis>the main mistake, from what i understand, is that it is aiming to do multiple revisions of this <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 <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.