<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>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
***vup2 is now known as vup
***X-Scale` is now known as X-Scale
<manumanumanu>anything that works with more than one block fails for me (or at least, I believe that is the issue) ***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. guile-readline.so, 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 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>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>dsmith-work: yes that is one of the reasons. pretty sure i got that right <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>usually I make a one-off emacs macro for doing the text transformation <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 ***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? <dsmith-work>Anyone ever use emacs multi-cursor stuff for those kinds of mass edits instead of macros? <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 .. <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>Seems like it would be useful, but not used enough for me to remember how. <leoprikler>particularly, I always spawn one to many when I try to use them