IRC channel logs


back to list of logs

<joshuaBPMan>hey guile people. I've got a lot of records for my sway service...What's the sly way to iterate over all of the fields of a record?
<joshuaBPMan>I'd rather not have to hardcode how to access every record. It would be coolier if I could somehow turn every record into a list.
<joshuaBPMan>I'd hate to have to make 5 functions like so:
<joshuaBPMan>It would be nice to just have 1 function for all of that.
<rekado>record-type-field-names might be helpful
***X-Scale` is now known as X-Scale
<joshuaBPMan>rekado: thanks
***vup2 is now known as vup
***X-Scale` is now known as X-Scale
<manumanumanu>rekado_: I submitted this:
<manumanumanu>anything that works with more than one block fails for me (or at least, I believe that is the issue)
<manumanumanu>I offload everything to pandoc right now, though.
<manumanumanu>rekado_: I am not using guix on this machine though.
<dsmith-work>Happy Friday, Guilers!!
<civodul>hey dsmith-work!
<civodul>happy Friday!
***X-Scale` is now known as X-Scale
<mwette>sneek later tell nly, with fix to nyacc ffi-helper I was able to generate a guile wrap for libfuse. If you want to try I would need to send it to you as oto big (at 200 kB) to paste. I'm guessing it would need some front-end work to make useful.
<wingo>ok i have a rewrite of dynamic linking that seems to work, except for one case -- loading .so files from build trees
<wingo>e.g., which is in guile-readline/.libs/ and not guile-readline/
<wingo>still working on how to deal with that. have i mentioned that i hate libtool
<wingo>probably it would be sufficient on most systems to add .libs/ to each entry in LTDL_LIBRARY_PATH
<wingo>since that var is essentially only used in an uninstalled context
<spk121>wingo: Sounds like a sensible idea w.r.t. paths. My frustration with libtool is great, and has been leading me to dump automake in some projects for autoconf-only builds
<wingo>sadly the path of least resistance may be making a special loader for .la files
<wingo>as i think we have what we want with the "dlname" and "installed" fields
<wingo>spk121: is in the excise-ltdl branch in git, fwiw
<wingo>at least that code can be in scheme tho
<rlb>wingo: will LTDL_LIBRARY_PATH augmentations still work for both build and install trees, or is there some other approach?
*rlb will also try to get some time this weekend to tests against that branch...
<dsmith-work>wingo: How do you make auto* tools *not* use ltdl ?
*dsmith-work looks at the excise-ltdl branch
<spk121>dsmith-work: wingo's talking about excising the libltdl dependency from guile itself and instead just trying to use dlopen() directly when loading guile extension libraries, since most OS's have a dlopen() these days
<spk121>but with regards to autotool builds, libtool is the only way to make *.so shared libraries if you are using automake
<spk121>(only supported way, anyway)
<dsmith-work>Ok, that's what I thought. (re libtool)
<spk121>Lately, I've been exploring using only autoconf + make and skipping automake just to avoid libtool. Probably a waste of time, but, the '.libs' directory stuff and the many configure tests that libtool does annoy me
<spk121>GNU ncurses, for example, skips automake and does only autoconf
<dsmith-work>I had some issues cross compiling something. I think it was guile, but now I'm not sure. I just rm'ed all the .la files and it made things all better.
<dsmith-work>Pretty sure I was updating to guile 3.x in buildroot.
<dsmith-work>wingo: Please if you can, somehow provide different errors for the .so not being found, and the init function returning an error.
***leoprikler_ is now known as leoprikler
<wingo>hehe adding on .libs works
<wingo>dsmith-work: yes that is one of the reasons. pretty sure i got that right
<dsmith-work>wingo: Sweet! Thank you!
*sneek cheers
<soda__hobart>is there an easy way to import a C enum into a guile program's symbol table or whatever it's called?
<wingo>soda__hobart: no that turns out to be hard -- either you parse the C or you parse the DWARF. i think luajit has the nicest interface in this regard
<soda__hobart>hmmm... what to do? i guess i will just cut-and-paste the variables for right now.
<davexunit>I just copy/paste fwiw
<justin_smith>there's likely some $EDITOR magic to make that easier
<davexunit>usually I make a one-off emacs macro for doing the text transformation
<davexunit>for enums with lots of entries
<soda__hobart>yeah, there's a few dozen when it's all said and done
<justin_smith>editor macros are like the 80/20 version of having a parser, except it's more like 95/5
<wingo>soda__hobart: honestly that is what i would do
<soda__hobart>maybe i can try using sed or awk or something
***rekado_ is now known as rekado
<rekado>I’m using Emacs macros a lot, but I often wish I could figure out how to replace “M-x zap <down> <down> RET” in the macro with the thing that was selected (zap-to-char, for example).
<davexunit>often the approach is: wrap line in parens, downcase the name, replace underscores with dashes
<davexunit>my approach, that is. I use C-x ( to record the actions needed for one line then F4 to replay it for the rest of the lines.
<soda__hobart>yup, maybe be real fancy and make it of of those special variables with the asterickses
<davexunit>often enough there are things I have to do manually but a macro handles the bulk of the work.
<davexunit>and once it's done you never have to deal with it again
<leoprikler>soda__hobart: you might want to take a look at nyacc
<leoprikler>it can parse the header files and generate ffi code for you, including enum handling
<leoprikler>thing is, in its current configuration it does really much, so if you want to limit it to a select few enums you have to code that up on your own
<wingo>leoprikler: neat! i should look more into nyacc one day
<justin_smith>iirc that's what luajit has right? it uses a parser of the h file to code gen?
<leoprikler>so should I :)
<dsmith-work>Anyone ever use emacs multi-cursor stuff for those kinds of mass edits instead of macros?
<wingo>not me
<wingo>that's kinda like C-x r t tho
<mwette>I use C-x ( ... C-x ) to record macro then C-x e ...
<dsmith-work>And newish emacs you can then just keep doing e e e e ..
<davexunit>or F4
<rekado>(I use F3 to record and F4 to play back)
<rekado>dsmith-work: I always forget which of the mc/ commands are the right ones and waste too much time there.
<rekado>but for me macro playback with F4 is terribly slow because it doesn’t record the command I invoke with M-x but instead records that I invoked M-x …
<dsmith-work>rekado: Yeah, I've never figured it out either.
<dsmith-work>Seems like it would be useful, but not used enough for me to remember how.
<leoprikler>multi-cursors are weird
<leoprikler>particularly, I always spawn one to many when I try to use them
<rekado>same here!