IRC channel logs

2020-07-29.log

back to list of logs

<pkill9>I don't suppose there is already a library out there for parsing .desktop files?
<leoprikler>There is a number of config file parsers, but I don't know whether there's a specific guile implementation
<pkill9>ok, it's not difficult ot parse them, I'm just seeing if it's already been done to save time/effort
<dsmith>They are like m$ .ini files, right?
<dsmith>Seems like it. https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s03.html
<pkill9>yea
<pkill9>just ini files
***dsmith is now known as CrabbyOldMan
<CrabbyOldMan>Never liked ini files..
***CrabbyOldMan is now known as dsmith
***Ekho- is now known as Ekho
<daviid>str1ngs: great! for the nomad patch ...
<sneek>daviid, you have 1 message!
<sneek>daviid, str1ngs says: Just a FYI I've submitted a patch to guix which updates nomad to now use feature-g-golf https://issues.guix.gnu.org/42582. And soon I'm I'll have a 0.2.0-alpha release so feature-g-golf should be completely merged at that time.
***berndj-blackout is now known as berndj
<daviid>str1ngs: i posted a <gtk-application>//run related quiz on #introspection, maybe you know the answer?
<daviid>str1ngs: i found the solution, thanks to ebassy ...
<daviid>seepel1: here is an updated (g-golf) hello-world example, which uses the 'modern' way of doing things, meaning a GtkApplication, GtkApplicationWindow and run, quit - https://paste.gnome.org/psohpas0f
***apteryx_ is now known as apteryx
<ArneBab>dsmith: do we have a good ini file parser?
<str1ngs>daviid: example looks good. Though strange to see read short named methods now :)
<daviid>str1ngs: well, i couldn't wait for short namd methods ... :)
<daviid>at last, all clean and beautiful ... :)
<ArneBab>daviid: I see the gi-imports by string for which I’d need to know beforehand what I need; are there helper-functions to give discoverability? Something like gi-import-item-Application?
<str1ngs>daviid: it is I agree. just I'm so use to C name space names :). I need to port nomad to short names still.
<str1ngs>ArneBab: you can import whole names spaces. ie (gi-import "Gtk") in the case of GTK though it's faster to selectively import.
<daviid>ArneBab: gi-import-by-name namspac name
<ArneBab>or maybe (gii-Application) → Application imported
<ArneBab>(basically: is there auto-completion?)
<daviid>no
<ArneBab>^ to not talk around the issue :)
<str1ngs>it's good to know the name spaces and classes IMHO
<daviid>ArneBab: thes ar g-base-info-names, you'll understand by playing a little, but GtkWindow -> "Gtk" "Window" ... and you can always import the name space if you don't know, or to start with ...
<daviid>ArneBab: just ask, w'll hlp you, then you'll get it ...
<ArneBab>that’s not why I’m asking. I’m asking because I’m now doing java dev at work, and I learned the value of discoverability through auto-completion.
<str1ngs>Gtk is the only namespace that practically needs to be selectively imported. most other cases you can just import the whole namespace with gi-import.
<str1ngs>there is no way to auto discovery this, there is no information until the typelib in imported.
<daviid>ArneBab: you could only autocomplete if you imported ...
<str1ngs>you can though look in /usr/share/gir-1.0/ but that's kinda out of the scope of g-golf and guile.
<ArneBab>it would have to be maintained, yes … understood, yes
<daviid>ArneBab: also, it would be imposible to dvelop anything out of any gnome namspace without reading/studying the maual anyway ...
<ArneBab>it would be nice if that could be changed :-) (at work I’m often prodding internal APIs with auto-completion, jumping to API docs to see whether I guessed right)
<str1ngs>I agrees, atleast in the context of knowing the name spaces and classes. once you have your imports though geiser does a great job of completion. atleast with my Emacs setup it does.
<ArneBab>that sounds like the best way would be "import everything at first, reduce imports later"
<daviid>ArneBab: it won't, ver, change - you can't autocomplete what's not in mem ...
<str1ngs>ArneBab: that reduction is how I handle it at times. the only case you can't do that is with Gtk it's very slow to import.
<ArneBab>str1ngs: also for development where you leave the editor open anyway?
<ArneBab>(or the geiser shell)
<ArneBab>… couldn’t that reduction be automated?
<ArneBab>daviid: I understand, yes. Otherwise guile-gi would become documentation of gtk
<ArneBab>str1ngs: (with automation I mean: show me the reduced import I would need so everything I use here keeps working)
<daviid>it would be, imo, a complete loss of develop time as well, you need to read the namespace manual to actually write ana pp anyway ... you would not autocomplete in the dark, that would be 'ridiculous'
<daviid>all this does not make any sense, sorry to say ...
<str1ngs>ArneBab: here's an example of non trivial application use case. http://git.savannah.nongnu.org/cgit/nomad.git/tree/scheme/nomad/gtk/gi.scm?h=feature-g-golf import is actually quite easy and only needs to be done once.
<ArneBab>daviid: autocompletion in the dark works pretty well in Java and Python — it changes development from the need to remember stuff exactly to fuzzy matching available options against rough memory
<str1ngs>you are comparing apples to oranges though. there is no information to complete until the typelibs are imported. even pygobject can't do that.
<str1ngs>which is python so your python example fails there too.
<ArneBab>str1ngs: Python often has full wrappers, I think exactly because of that.
<daviid>ArneBab: you don't develop a gnome app in the dark, it just doesn't make sense
<ArneBab>however just importing the whole namespace and reducing the imports later should be enough, too.
<str1ngs>right that's what I said just import the whole typelib namespace. and now you have full completion. assuming you are using geiser.
<str1ngs>or something REPL even.
<daviid>you must read the manual and other examples, it's difficult, not like a one line list-<let's complte to se how many list ops thr are ...>
<str1ngs>g-golf is 100% more introspective then C I would know :)
<daviid>ArneBab: anyway, ping us when you need help, we'll hlp you of cours ... but you will soon grab a basic knowledge if you play with a little ...
<str1ngs>daviid: what are you working now in regards to g-golf? just curious
<str1ngs>on*
<daviid>ArneBab: what i'm trying to say is this: the knowldge you need is in the gnome namespace manuals and examples 'out there', not in g-golf ...
<daviid>str1ngs: GIInterfaces and 'Using G-Golf', the user manual
<daviid>full and proper GIInterfaces implementation is very important, getting close now ...
<str1ngs>good to know, I'm going to start work on porting to short names in the next couple of days.
<daviid>str1ngs: great, it will be a good test for g-golf ...
<str1ngs>in regards to short names I've needed to do (set! %gi-method-short-names-skip '(insert reload load-uri)) for now. so no obvious bugs
<ArneBab>daviid: ok
<daviid>str1ngs: ok
<daviid>str1ngs: are these guile core syntax?
<daviid>or nomad module syntax?
<daviid>anyway, just curious, good to test the customization as well ...
<str1ngs>daviid: in the case of 'insert it's emacsy syntax and reload and load-uri are nomad/emacsy syntax. think interactive commands like emacs.
<str1ngs>I'll probably keep these nomad/emacsy syntax for ease of user use.
<str1ngs>insert inserts into text buffer like eamcs. and reload load-uri are web mode interactive commands.
<daviid>ok, in this case, if you don't set! %gi-method-short-names-skip, they would (should) become insrt_, reload_ and load-uri_
<daviid>str1ngs: but you know that already i guess ...
<daviid>all in the manual ... just in case
<str1ngs>right, seems to be okay like this for now. insert I can't get around the other possible I can rename.
<daviid>str1ngs: ok, what i'm trying to say is this - if you keep the default, the insert syntax name will be protected, and the short name method will be insert_
<daviid>any syntax name is protected
<str1ngs>ahh you are saying I can use insert_ instead now?
<daviid>yees, if tou don't set! the skip var ...the way short names are defined n
<str1ngs>that's good to know thank you. I'll just keep this %gi-method-short-names-skip in that case.
<str1ngs>btw on guix I get (process:102313): GLib-GObject-CRITICAL **: 13:01:36.689: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed . but it does not actually effect the program execution I need to look into this more. does not happen on debian systems. I think it might be related to GI on guix again.
<daviid>str1ngs: you can try, just comment your (set! .%gi-method-short-names-skip ...) from, import ouy module and try in a repl, insert, insert_, reload, reload_ ...
<str1ngs>I need to try an reduce the problem and figure out what gtk code is actually causing it.
<daviid>the postfix char is customizable as well, in could be a prefix, or even a complete renamer lambda ...
<str1ngs>I see in Nomad load_ is bound
<daviid>ok
<str1ngs>well it's a generic method.
<daviid>str1ngs: exactly, it protected load, because there is no way to transform a syntax into a method ...
<daviid>str1ngs: make sure to read this https://www.gnu.org/software/g-golf/manual/html_node/Customizing-G_002dGolf.html#Customizing-G_002dGolf, the _ Short Name Methods subsection, _ Syntax Name Protect and every variable reference entry - it is really important you understand this, and let meknw if the manual is nhot clear
<str1ngs>I did read that part of the manual but was more focused on %gi-method-short-names-skip since that all I've needed so far.
<daviid>well, skip is more for users who do not want short name methods 'at all', for either all methods, or some ... but in any case, syntax names are always protected (unless a bug or so )
<str1ngs>also I need to get a better handle on https://www.gnu.org/software/g-golf/manual/html_node/Gdk.html#Gdk . I'm not using Gdk right currently I think.
<daviid>str1ngs: there was a user here who said he preferes to protect syntax names by prefixing using @ ... so i beleive i've offered all possible ways to acheive what ever users wants
<str1ngs>for me I tend to use defaults. for Nomad it's a little tricky because it was written when only long names existed. So I rather not break thing just for the sake of short names quite yet. though defiantly any new GI code I'll be using short names. I think it's code tax in the long run..
<str1ngs>less code tax to use short names I mean.
<daviid>str1ngs: sure, just mentionening the possibilities ... so in his config, those syntax you are 'facing' would be protected, and short name methods would be @insert, @reload, @load-uri, instead of the default insert_, reload_ ...
<str1ngs>sounds good, I'll know more once I port the long names.
<daviid>ok
<daviid>str1ngs: i don't know about the guix related GLib-GObject-CRITICAL ... but it seems it can't obtain the GType of a boxed type based on its name ...
<str1ngs>I'm pretty confident it's related to the on going GI issue on guix.
<daviid>ok
<str1ngs>though it says critical, it does not effect Nomad. I will try when I have time to reduce the message and see what's exactly causing it. maybe I'll know more then.
<str1ngs>debian systems are not effected so I don't think it's an issue with g-golf right now.
<daviid>it doesn't sound like a g-golf issue indeed, but let's see ... once you succeed in getting a short snipset ...
***sputny1 is now known as sputny
<daviid>str1ngs: if it helps, g-type-name is extensively used by g-golf 'itself', defined in (g-golf gobject type-information), you may try it at the repl as well ..
<daviid>str1ngs: for example (g-type-name 56) -| "gfloat"
<daviid>or (g-type-name (!g-type <gtk-window>)) -| $18 = "GtkWindow"
<dsmith-work>Wednesday Greetings, Guilers
<mwette>o/
<peanutbutterandc>Hello guile
<a_v_p>peanutbutterandc: Hi!
<peanutbutterandc>a v p wow how do I mention you? You've got embedded spaces! Hello there! :)
<peanutbutterandc>"a v p" does this do the trick? o.O
<peanutbutterandc>nope
<dsmith-work>peanutbutterandc: a_v_p has emedded _
<peanutbutterandc>dsmith-work, How would I go about mentioning "a v p"? This seems like a fun little puzzle
<dsmith-work>peanutbutterandc: I guess I don't know what you mean by "mention"
<peanutbutterandc>dsmith-work, like this
<peanutbutterandc>sorry i'm a n00b
<dsmith-work>a_v_p: Hello
<dsmith-work>LIke that?
<peanutbutterandc>Yes, but that isn't turning my messages green on hexchat. But that's besides the point...
<peanutbutterandc>anyways....
<peanutbutterandc>Ah!
<peanutbutterandc>Silly me!
<dsmith-work>peanutbutterandc: So I don't see spaces, I see underlines...
<peanutbutterandc>It's a_v_p with embedded underscores. I'm using hexchat. And it just turns them into spaces
<peanutbutterandc>dsmith-work, lol
<dsmith-work>Oh wow
<dsmith-work>"Well that's your problem right there.."
<peanutbutterandc>Anyways, is there any chance that you might have any answer regarding this: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42574 please?
<peanutbutterandc>dsmith-work, which irc client would you recommend, BTW?
<peanutbutterandc>I'm trying to get this trace thing working properly so that I can trace the example programs in a certain book. Just so. But I'm not having much luck with it.
<dsmith-work>peanutbutterandc: Well, I've most always used erc in emacs. I messed with xchat a bit a long long time ago, but I like having the power of emacs available.
<dsmith-work>I'm using ERC with GNU Emacs 26.1 (x86_64-pc-linux-gnu, GTK+ Version 3.24.5, multi-tty) of 2019-09-22.
<peanutbutterandc>And they're such neat recursive functions. So trace-mpting.
<peanutbutterandc>(tempting)
<dsmith-work>peanutbutterandc: I've never used the tracing stuff, sorry.
<peanutbutterandc>I see.... I still have to learn emacs properly...*sigh*
<peanutbutterandc>dsmith-work, I see. It's all right.
<peanutbutterandc>a_v_p, perhaps you might have some ideas regarding the matter? https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42574
<dsmith-work>I've just recently started using paredit for lispy stuff. Avoidied it for years. It's *wonderful*.
<peanutbutterandc>dsmith-work, I've read about paredit in guix-reference-manual. It says the same thing too, basically.
<dsmith-work>peanutbutterandc: Make sure the manual and the guile are at the same version. Low level stuff (like evaluation, the vm, the jit) might have changed quite a bit between major versions.
<dsmith-work>The https://www.gnu.org/software/guile/manual/ manual is for the latest version, 3.0.4
<peanutbutterandc>dsmith-work, I just looked at the manual that I have (info) and it's basically the same...
<dsmith-work>There are links to older manuals here https://www.gnu.org/software/guile/learn/
<dsmith-work>Ok.
<peanutbutterandc>dsmith-work, Perhpas you might be able to shed some light into the matter, too, (regarding bug 42574). I am pretty sure it isn't really a bug but just me being a n00b
***evhan` is now known as evhan
<seepel1>daviid: Thanks for the example!
***terpri__ is now known as terpri