<daviid>str1ngs: hello! and hello guilers <sneek>Welcome back daviid, you have 2 messages! <sneek>daviid, str1ngs says: it seems for language bindings the glib functions/macros g_error g_warning won't work. same with g_log. it looks like g_log_variant should probably work though. does g-golf have enough GVariant support to call 'g-log-variant? if not it's okay this mostly just a request for comment. the documentation for 'g-log-variant. can be found here <daviid>str1ngs: if you need a GError arg and return the error essage if there ws an error use with-gerror from (g-golf gi utils), examples in (g-golf typelib) and (g-golf gi repository) <daviid>there is no support (at all) for GVariant in G-Golf, and I hope I can avoid it all, but not sure yet ... outside the obligation to lead with GError arg, when that applies, as for g-irepository-require, why would you not use scheme for message otput and debugging functions? <spk121>dsmith-work: in that tree I definitely removed libltdl from dynl.c but that's just for loading extensions <spk121>daviid: there's also g_log_structured_array <daviid>spk121: indeed, but I wonder why not keeping all this in scheme 'in the first place' <str1ngs>daviid: I'm not sure how you can avoid GVariant. I though it was specifically designed to handle conversions for language bindings. <daviid>str1ngs: so far none of the examples we're working with needs GVariant, which is not a 'definitive' justficatin of course, but we have needs for GValues, since ther are the signals/callback closure required args, and GIArguments because thats what g-fuction-invoke needs, very unfortunatelly, imo everything should have been made usig GValue(s), but that wwill never happen <daviid>str1ngs: i pushed many patches so g-glf does not import info from GLib GObject anymore, unless #:force? - it's a lot cleaner and better, although I can see still a few 'corner cases', this cleaned the 'strange' duplicates warning in th hello-world and gdk-events script examples <scottviteri>Hello, is there a way to tell how much memory certain variables are taking up from the scheme shell? <daviid>str1ngs: it should not make any diff to you, but please pull/make whenever you have the opportunity, to confirm everything still ok on yourside ... tx <scottviteri>When I run my code, htop shows that memory is being eaten. This memory is freed upon restarting the shell. Looking at the ,bindings I do not see any obviously large binding. <str1ngs>daviid: I will try to pull in the next couple of days. I've been putting off pulling since I'm kinda busy working on some end user enhancements. <str1ngs>daviid re logging I'll just use (logging logger) I guess <daviid>str1ngs: I highly recommend to stick to scheme, unless forced not to, and logging is really not a "C thing" - if (logging logger) isn't good enough, we/you can certainly improve it ... <daviid>str1ngs: is this the guile-lib package? <daviid>I think I have seen other guile-scheme packages doing this, I hope if true, others will mnfest hemselves here, otherwise, ask on guile-user ... <str1ngs>daviid: the point of use glib for logging is so I don't have to mix to logggers. but it's not a big deal <daviid>why do you use glib in the fris place? can't everything be i scheme in your app? <daviid>*first (my kb s old and has many none working keys ... ***rlb` is now known as rlb
<str1ngs>because when you want to debug gtk or glib. you can use G_MESSAGES_DEBUG which effects g_log ***d4ryus2 is now known as d4ryus
<rekado>hmm, (match #(1 2 3) (#(first ___) first)) does not work even though the manual lists ___ as a valid ellipsis. <janneke>rekado: that really puzzeled me when i first started with match *janneke found match doc next to impossible to read <janneke>i should have just asked, at the time :-( <rekado>this works: (match (list 1 2 3) ((first rest ___) first)) <rekado>and this works too: (match #(1 2 3) (#(first rest ___) first)) <janneke>hmm, no something else must have puzzeled me: this works: (match '(1 2 3) ((first ___) first)) <rekado>I think that’s expected because “...” or “___” should match zero or more items…? <janneke>where "ooo" is not used at all -- ah; that defines "ooo", and .../___ are not defined (or only in text) *janneke mis-took that as a sloppy definition of ... and ___ <civodul>this doc is frustration-prone, i admit :-) <civodul>the reference is taken from Shinn's implementation <brendyyn>civodul: Hi sorry I'm back with a question :) Do you know if it's possible to get the name of an algorithm from its representation like mac-size gets the size, there is no mac-name? <civodul>janneke: that's not what i meant :-), but sure <civodul>brendyyn: i think that's currently missing, but would be worth adding <civodul>the application probably knows what algorithm it's using, though <brendyyn>civodul: Thanks. I wanted to print an error message saying the algorithm chosen didnt support something, but noticed i didn't know how to refer to it <civodul>for now you might need to carry the name next to the algorithm <janneke>civodul: sorry for trying to put words into your mouth! <manumanumanu>civodul: good news for guile though: the transducer version of (map 1+ (filter odd? lst)) runs a lot faster under guile3. It runs only about 50% faster, compared to almost twice as fast in 2.2. The difference is of course a lot larger when there are more steps, but that isn't surprising. <manumanumanu>jesus. Don't read that. I meant that the transducer version of (map 1+ (filter odd? lst)) is only about 50% faster, compared to 100% under 2.2. <manumanumanu>and the overhead of (list-transduce (tmap 1+) rcons lst) over (map 1+ lst) is a lot smaller under 3.0 as well :D <manumanumanu>I have an old thing I used to fuzz my delimited separated values library, but I am at a point where I either extend it or use something else. <brendyyn>I was puzzled for a bit about what should be inputs and keys. ***Server sets mode: +nt
***matijja``` is now known as matijja`
***matijja` is now known as matijja
***ear_the_art is now known as ear-the-art