<mwette>not really. The converter needs to be re-written, though. It works directly on the syntax trees emitted by parse-c99. The tricky part is that when type T is defined in C, you may need to provide not only the scheme hooks for T, but also for T* and T**, etc. And then you need to handle dereference and pointer operations. <mwette>If you make an object, say x, of type T in scheme, and a functions wants the pointer, ffi-help provides (pointer-to x) <leoprikler>Maybe, but in my personal use case, I think I want to use ffi-helper to extract function pointers and enum values while writing most of the serious wrapper code in the same module <leoprikler>so it's a step lower than what you are doing in basically letting the user access everything for free <leoprikler>I'll definitely have a look at nyacc at some later point and perhaps write my tryhard frontend <mwette>If I understand, you would want to list a set of C declarations visible in some set of includes, and get just those expanded. I have not done that, but it swould be not too hard. <mwette>So the ffi-helper is good about keeping definitions you want and expanding the ones you don't. <leoprikler>(plus maybe another symbol table for global #defines) <mwette>I don't know what you mean by raw pointer types. <leoprikler>i.e. struct foo { int bar; int baz; } would get a parse-c-foo-struct procedure <mwette>but often structs include structs. You may want to check out nyacc's expand-typerefs procedure. <mwette>i.e., struct foo { some_funky_t bar; another_funky_t baz; } => struct foo { int bar; double baz; } <leoprikler>perhaps there might arise the occasion, where one wants that in nested lists <mwette>to expand-typerefs you pass a declaration and a "keepers" list and it expands everything except the keepers <leoprikler>but I think flattening them to basic types should be fine in most cases <mwette>For simple, stuff you should be OK. For collections of functions that use multiple types you'll appreciate what the ffi-helper does. <leoprikler>oh, sure, for huge libraries like gtk, stuff like ffi-helper is invaluable <leoprikler>but for small examples like wordexp(3), I would like to have my embedded systems friendly solution :) <leoprikler>(also for semilarge ones like libmpdclient, where handwriting a wrapper in C or scheme is very possible) <leoprikler>Really, the only thing I would actually need here, that isn't in Guile itself already, is the extraction of enums <daviid>str1ngs: fwiw, g-golf (can) makes and parses array of (utf8) strings <leoprikler>yeah, we already noted that over in the guix channel <leoprikler>just for reference, what does your utf8 argv parser look like? <daviid>leoprikler: here (g-golf gi utils) <daviid>scm->gi - or scm->gi-strings for the core mplementation <daviid>str1ngs: any particular eason why tou did not use this? just curious <leoprikler>and as far as I can see, you have to do some extra work for refcounting/GC in that code, that probably doesn't apply <daviid>ah ok - yes, one ned to keepo a pointer to the string, iirc <str1ngs>daviid: oh I just want to use wordexp for globing and expansion. <str1ngs>nothing g-golf related. though I might use it in nomad <str1ngs>daviid: I'd like to add 'expand-file-name like emacs to nomad. <leoprikler>Is this perhaps related to the missing tab completion? 🙃️ <str1ngs>actually nomad's tab completion ala emacsy is pretty good. only place it needs work is M-: (<TAB> it can handles symbols but not expressions <leoprikler>I think I can recall it not working in find-file, but expanding ~ and variables is very much appreciated too <str1ngs>yes, sorry that does not expand. I'll like to improve on that. though find-file etc. is kinda something I hope others hack on. My primarily focus has been on extensible for the web browser. though these are all building blocks. since adding 'expand-file-name that could be used in completer of 'find-file <str1ngs>emacsy does expand ~/ during 'find-file though it's kinda clunky on in the each-area to use. <daviid>str1ngs: ok - is this wordexp binding in nomad? <str1ngs>I would like to add something like this to guile to be honest. kI miss filepath.Glob from g <daviid>str1ngs: and do you need this to be portable accross OS, or on linux only <str1ngs>I think wordexp is POSIX so should be reasonable portable. *str1ngs looks at windows <daviid>str1ngs: if posix, it means 'none native window', i guess <str1ngs>also whatever systems support guiles FFI. think all the major ones do. <daviid>msys2, cygwin will be ok of course <daviid>str1ngs: i was asking because i also have some, in grip <str1ngs>aye. with WSL though on windows it should work. which is what I use when I *have* to use windows. <str1ngs>though windows support on nomad is long way off. <str1ngs>think that's something that will need to be contributed. <daviid>don' know wsl - i use msys2 when i have to ... <daviid>i thought you wnted something ourtside nomad <daviid>otherwise, you could reuse (gi-scm wordexp-ptr 'strings) <str1ngs>daviid: right I just might make it a module <daviid>and (scm->gi "("your" "strings" "here") 'strings) <daviid>no, but an arry of pointers, but g-golf also has GList and GSList as well ... <daviid>actually, GSList 'only', never had a use case for GList <daviid>yand (scm->gi "("your" "strings" "here") 'gslist) <daviid>str1ngs: all this is in (g-golf gi utils), feel free to use, snarf ... and test :) <daviid>let me know if you need GList, i can cook that for you (and g-golf) <daviid>str1ngs: grip has (grip file) and ()grip path) - the former uses a glob as well <str1ngs>I'll need to use GList eventually though not for this. because I only use GLib/Gtk in the graphical abstraction. the core of nomad just scheme primitives so most things will work despite a graphical toolkit. <str1ngs>daviid: can grip do something like this "~/*/*" ? <str1ngs>expands all files as a list of the second leaf directory in ~/ <daviid>str1ngs: you mean you'll need GList in nomad? if that's so, you probably have a webkit/gtk function in mind? so far, i only did need GSList, but GList is on the todo ... far below GIInterface (full implementation), and so far below GICallbacks as well <daviid>str1ngs: not the ~, but it will understand * and any regexp that glob.scm understand <daviid>$10 = ("./child-property-prev.scm" "./short-methods" "./gdk.scm" "./hw-app.scm" # …) <str1ngs>daviid: nothing in mind right now. though I'm bound to run into something <str1ngs>I guess I find stuff like this handly. (glob "~/[a-c]*") <daviid>str1ngs: i think guix does a better job then grip here <str1ngs>I'll check guix. it's more of a extended use case other then nomad. <str1ngs>if I can avoid wordexp would be better since this is a thing (glob "$(uname -a")). you can turn this off but still. <daviid>you definitely can avoid wordexp, but i don't fully understand the above sentence <str1ngs>worexp can do command substitution though you can turn it of if you pass the WRDE_NOCMD flag. without it you can do this. (glob "$(rm ~/*)") <daviid>ok, i thought you wanted to retreive filenames, cmd substitution is another thing .. <str1ngs>probably what I need glob-match? from (guix glob) coupled with a tilde expanded. wordexp is low effort on my part since it does both. <pkill9>eval is telling me one of the variables in the expression i gave it is unbound, what could be the issue? <daviid>right, grip uses glob to, but i see the guix implementation is nicer - and you use/know guix already ... <str1ngs>pkill9: we'd have to see the expression. though probably you want this `(display ,foo) <pkill9>it says command-prefix is unbound <pkill9>I try unquoting it, i assume it will work, but it would be nice to be able to just pass it without unquoting anything <pkill9>in that paste, the 'selection' is the expression returned <str1ngs>quote like this. (let ((welcome "Hello GNU!")) (eval `(display ,welcome) (interaction-environment))) <pkill9>why does it need to be unquoted? <pkill9>in my example, 'shell-command' doesn't need to be unquoted <pkill9>though i guess it's calling that directly? <str1ngs>pkill9: where is shell-command defined? <str1ngs>pkill9: which variable does it say is not defined? <pkill9>command-prefix and package-specification <str1ngs>right so you want to use `(display-menu.. rest .... ,command-prefix ... rest) does this make sense? <str1ngs>display-menu is called when selection is bound is that okay? if so you might need to move ` <str1ngs>also the same with package-specification. kassuming this are <pkill9>i get what to do to make it work, and why it works, i just don't get why it doesn't work when I don't unquote it <pkill9>i'll just unquote for now, i don't need to get hung up on this <str1ngs>basically the quotes everything except for things prefix with , those will be evaluated. <pkill9>i understand quasiquotes, i just don't get why eval doesn't see that variable <str1ngs>you sure it's not the call to display-menu causing this? <pkill9>interestingly, i don't need to unquote the call to the function within a nested expression <pkill9>display-menu is just returning the symbols <str1ngs>then probably `(("Build and run package" the ,command-prefix should fix this as far as I can see <pkill9>to give you an example of an evaluation that works in that paste: (shell-command ,command-prefix ,%web-browser (package-home-page (specification->package ,package-specification))) <pkill9>notice package-home-page and specification->package don't need to be unquoted <str1ngs>those are procedures they are evaluated by eval. <pkill9>so eval creates a kind of sub-environment? <pkill9>idk, i thought function and variables were the same in lisp/scheme <str1ngs>functions are variables if you use them like so. see a REPL if you type version vs (version) one is evaluated the other is a value. <str1ngs>because here you pass the data as an expression the procedures are evaluated but (interaction-environment) is outside the scope of your let. so you need to evaluate the variables with , <daviid>str1ngs: notye that scm->gi-strings returns a pointer to a NULL terminated array of pointers to strings ... but scm->gi-n-string returns pointer to a non NULL terminated ... <str1ngs>daviid: that could be handy for something GLlib related. <str1ngs>I think when I hack on a grid-buffer I might need GList will let you know. <daviid>str1ngs: for non NULL terminated arrays, you'd use (scm->gi '("a" "b" ...) 'n-string) <str1ngs>daviid: right now I'm working on a bug in emacsy related to co-routines and prompts. not easy to track down the context. <daviid>str1ngs: those operations have their counter part of course, gi-scm ... 'strings|n-string|pointers|n-pointer <str1ngs>okay will keep these in mind. though I can't think of anything that might need this off hand. <daviid>yes, co-routines and prompts ... hard to write, hard to debug .. are you using fiber, or guile-async ? <daviid>guile-a-sync2 and guile-a-sync3 work with g-golf now <str1ngs>not right now it uses emacsy uses (emacsy coroutine) <daviid>guile-a-sync* (for guile 2.0, 2.2 and 3.0) <str1ngs>I though you mentioned something before. later when I have a better grasp of emacsy I might port (emacsy coroutine) <daviid>those have been proted to g-golf a while ago <str1ngs>does guile-a-sync have and glib code? <daviid>and tested for weeks, non memleak, no bug, till now :) ***catonano_ is now known as catonano
<str1ngs>hmmm :( that wont' work for emacsy it's program agnostic. maybe fiber then. <str1ngs>for emacsy that's okay it's kinda agnostice think pure scheme. <daviid>... "(a-sync g-golf) - provides some convenience await procedures for the glib main loop using g-golf" ... <str1ngs>first I need to understand emacy's problems to correct them lol <daviid>and it provides those for guile-gi as well, fwiw <str1ngs>this is one issue is with coroutines and propmpts. <daviid>sure, was just pointing - so it 'rings a bell' if you later need it ... <str1ngs>oh I appreciate it's informative. I've been meaning to ask which async library was glib friendly . maybe I can leverage it in nomad. emacsy is something different it needs to not be coupled with GLib if possible. <str1ngs>some examples use SDL, you get the idea. <daviid>i think guile-a-sync is the only GLib friendly, afaict at least <str1ngs>that's good to know. I might still be able to use it at some point. <str1ngs>it's a fine line of how much GLib and Gtk I actually use. if anything I can think I make more things generic. which would help later with more back ends like ncurses <str1ngs>if things ever progress that far. I'm fine with Gtk and GLib for now. <daviid>sure - worth noting the author is a very very experienced C and scheme hacker as well <str1ngs>this was snarfed from guile-2d which davexunit wrote. <daviid>maybe, just curious - we should all snarf anyway, instead of rewriting the wheel i mean .. <daviid>whenever possible, this is all free s/w ... <str1ngs>aye we need more modules like guile-lib :) <daviid>it's ok ... which became sly - i see guile-a-sync2 doc says co-routines are like ecmascript ones ... not my domain though ... <daviid>str1ngs: yes we should work on guile-lib, i've always wanted to libify guix, the part of guix we all need all the time ... but always got stuck with a pile of things way above my head :) <str1ngs>let me look at guile-a-sync2 but if it uses GLib it won't be a good fit for emacsy. I would like to maybe just fix some bugs for emacsy for now. then think more on it. <daviid>str1ngs: it has co-routines without GLib <daviid>"... It is similar to ECMAScript generators and python generators." <daviid>the make-proc-iterator proc of course <str1ngs>I guess the reason this works well with GLib is it uses one event loop <str1ngs>but as long as you don't *have* to have Glib for that event loop then should work with emacsy <str1ngs>well it will stay within the design of emacsy <daviid>and you don't want to rewrite all this <str1ngs>The a-sync procedure can be used with any event loop, including the glib main loop provided by g-golf and guile-gi <str1ngs>right that's was my intention. I was thinking of adding in emacsy to replace (eamcsy couroutine) <daviid>chris, the author, has writtten and tested his lib for almost a decade, and still uses it dauily, i think so - he contributed to g-golf ... definitely a win approach if you need coroutines i would say <str1ngs>it won't be for sometime. I need a better handle on the problem space. but this is good research <str1ngs>I agree thanks for pointing this out. <daviid>sure, np! keep it in mind and possible read his code ... should help <str1ngs>it's a bit of a challenge because I'm semi maintaining emacsy. I think I'm the only one using it. plus trying to get nomad to be more usable. <daviid>ok, back to my own hack lipe of things :) <daviid>that file is in guile-gnome to by the way <str1ngs>I don't think so it has a (guix glob) module <daviid>in grip, i made it so i can include it ... <str1ngs>you know probably GLib has globber already <daviid>right, agreed (to avoid glib for those tasks ..) <pkill9>what could be causing a (let) to show a bunch of 'unbound variable' warnings where you are setting the variables? <daviid>pkill9: use prob need to use let* - see the doc for diff between let and let* ... <daviid>please paste a snipset we can reproduce ... <pkill9>i've probably made a typo somewhere <daviid>pkill9: this is not a so calle snipset <pkill9>it's under the write-cache function <pkill9>it gives a bunch of warnings: ;;; /home/itsme/.local/bin/build-and-run-package-guile:267:75: warning: possibly unbound variable `desktop-file-contents' <pkill9>;;; /home/itsme/.local/bin/build-and-run-package-guile:271:58: warning: possibly unbound variable `desktop-file-contents' <pkill9>;;; /home/itsme/.local/bin/build-and-run-package-guile:272:102: warning: possibly unbound variable `desktop-file-contents' <pkill9>;;; /home/itsme/.local/bin/build-and-run-package-guile:274:58: warning: possibly unbound variable `run-in-terminal?' <pkill9>;;; /home/itsme/.local/bin/build-and-run-package-guile:275:62: warning: possibly unbound variable `exec' <pkill9>;;; /home/itsme/.local/bin/build-and-run-package-guile:274:58: warning: possibly unbound variable `exec' <pkill9>;;; /home/itsme/.local/bin/build-and-run-package-guile:278:20: warning: possibly unbound variable `current-guix' <pkill9>;;; /home/itsme/.local/bin/build-and-run-package-guile:278:20: warning: possibly unbound variable `desktop-files-modification-times' <pkill9>;;; /home/itsme/.local/bin/build-and-run-package-guile:278:20: warning: possibly unbound variable `desktop-files-menu-entries' <pkill9>;;; /home/itsme/.local/bin/build-and-run-package-guile:265:36: warning: possibly wrong number of arguments to `map' <pkill9>oh, it might be desktop-files-menu-entries, which is missing an arugmetn for map <chrislck>don't you need a let* in the line after "desktop-files-menu-entries"? <str1ngs>umm should docstrings have periods at the end? <str1ngs>daviid I added a small feature to nomad you were interested in sometime ago. Now when you hover on a link it is displayed in the echo area of the minibuffer. <daviid>str1ngs: nice - not using nomad, but i beleive users will like it! <daviid>the important thing is you now have the 'machinery', i remember you said it was not that easy ... <str1ngs>it's been there for some time. I was just not aware of the signal. 'mouse-target-changed <daviid>str1ngs: cool - I see you define show-all, grab-focus, get-text ....? aren't these 'built-in'? <str1ngs>daviid: they are now. not when I added them :) <str1ngs>I have not ported (nomad gtk widget) to short names quite yet. <pkill9>bindings for sway i nguile would be sweete <str1ngs>pkill9: I'm writing a compositor in guile will be called nomad-shell. not sway but will be simular. ***terpri_ is now known as terpri
<pkill9>one reason to have it for sway though is just that it's a more mature project and has a lot of contributors <jackhill>ooh, I would be interested in either/both of those projects.