IRC channel logs

2020-09-10.log

back to list of logs

***Aurora_iz_kosmos is now known as Aurora_v_kosmose
<str1ngs>sneek later tell daviid. Thanks to some review from the guix maintainers. The g-golf guix declaration is now at 84e894e. Also the package reflects the 0.1.0 autotools version as discussed. And thanks to rekado we might have found the major culprit for GdkPixBuf errors. I'm Happy to report g-golf is looking good in regards to nomad a guix right now.
<sneek>Okay.
<daviid>.
<sneek>Welcome back daviid, you have 2 messages!
<sneek>daviid, str1ngs says: very nice, I think I have some C code that I can switch to using g-golf directly when this is ready. also <top> is a guile primitive?
<sneek>daviid, str1ngs says: Thanks to some review from the guix maintainers. The g-golf guix declaration is now at 84e894e. Also the package reflects the 0.1.0 autotools version as discussed. And thanks to rekado we might have found the major culprit for GdkPixBuf errors. I'm Happy to report g-golf is looking good in regards to nomad a guix right now.
<daviid>str1ngs: excellent, tx to all involved in the guix/g-golf package updates - I'll let you know when I commit/push the GInterfaces patches, do you have a link of the C code you are using wrt this? curious, and maybe I could use that to write a check ...
<str1ngs>daviid: here are the C declarations http://git.savannah.nongnu.org/cgit/nomad.git/tree/typelib/util.h?h=devel . and you can find the code in util.c . Let me found one that actually uses interfaces first though. Save you having to dig around. I'll get back to you.
<str1ngs>daviid: these get imported into the Nomad typelib namspace btw. so nomad_get_version is (get-version)
<str1ngs>daviid: also some of name namiing is weird do to port from C to guile. they made more sense when the GOjecct classes were in C.
<str1ngs>s/do/due* encase you are wondering why there is nomad_app and then just nomad_
<daviid>str1ngs: i would be interested 'just' to look at an example of your interface 'usage' - that forced you to use C instead of scheme, so a simple property get/set! or method call that is/are defined by the interface
<daviid>str1ngs: but don't worry 'too much' either, I already have examples ...
<daviid>and tests
<str1ngs>daviid: I need to go over these anyways. And I'll document why I need those C bits and find out if it even applies anymore.
***catonano_ is now known as catonano
***terpri__ is now known as terpri
<str1ngs>daviid: hello, something like this might be useful in g-golf http://paste.debian.net/1163255 . Unless I missed some higher level enum procedures? Right now there seems to much boiler plate to get something that would normally take one word.
<str1ngs>WDYT?
<str1ngs>daviid: here it is in practice. (gtk-button-new-from-icon-name "gtk-go-back" (enum-ref 'gtk-icon-size 'small-toolbar))
<leoprikler>str1ngs: IIRC you should be able to pass 'small-toolbar and have g-golf work out the numeric value of that
<str1ngs>I have seen that leoprikler but only in the context of goops keyword constructors
<leoprikler>okay, but you're invoking a constructor here
<leoprikler>would it kill you to use the keyword-style ones?
<str1ngs>in the case of gtk-button-new-from-icon-name it technically a function.
<leoprikler>technically yes, but in GLib terms it is a constructor
<str1ngs>though it is used as a constructor it's not the same as a goops contructor
<leoprikler>my questions is why you use this constructor over the goops one
<str1ngs>because this is not a constructor its a helper function.
<leoprikler>okay, and what does this helper do besides constructing things?
<str1ngs>GLib constructor looks like this g_object_new(GTK_TYPE_WIDGET, "visible", TRUE, NULL). _new function are syntax sugar around that. with goops we don't nee to use new constructors functions we an use make with keywords for properties which tend to take symbol enumerators. in the case gtk-button-new-from-icon-name I'm just using it for it's sugar really.
<str1ngs>anyways putting constructors sill need the values of enums and flags for example check the value of response dialog.
<str1ngs>constructors aside*
<leoprikler>true, though in this case you could probably convert the value to a symbol and then use pcase
<leoprikler>*case
<str1ngs>the value are enums so you need to know what what value GTK_RESPONSE_YES is that could change you cant expect it to be 3. in the case of g-golf you it needs to be looked up in the cache like my helper function enum-ref does. For enums that are traditionally one word it would be helpful to have a higher level way to retrieve there values. so that was my proposal to daviid.
<leoprikler>my point is if you use (enum->symbol [enum-type] [value]), you should get the symbol. So if you need to parse a Gtk response, that would be the way I'd prefer it
<leoprikler>you're correct in that symbol[s]->enum is missing and I have no idea why
<str1ngs>yeah, needs a little bit of a higher abstraction.
<str1ngs>lets see what daviid says. I's possible it's on his TODO or it just hasn't been needed yet.
<str1ngs>leoprikler: this might be useful test case. http://paste.debian.net/1163258
<str1ngs>see the constructor takes a symbol enum. but then later we need to get response tyep
<str1ngs>err type*
<leoprikler>instead of matching the response against ok, why not assoc-ref response and then compare against the ok symbol?
<str1ngs>not sure what you mean by that.
<str1ngs>enum-set is an alist the keys are symbols
<str1ngs>so the values are integers
<str1ngs>also I don't need nested let here. :P
<leoprikler>you already have a let*
<leoprikler>so you know response by then
<str1ngs>leoprikler: (run dialog) returns a signed integer. maybe that is the confusion
<str1ngs>?
<leoprikler>so?
<leoprikler>ahh, you'd need a reverse lookup
<str1ngs>probably we can do that with some tweaks to umm lets call it 'enum->value ?
<str1ngs>or 'enum->int I guess guile treats signed ints as ints.
<str1ngs>actually if we did reverse lookup then yeah it can be 'enum->symbol
<leoprikler>you already have enum->symbol
<str1ngs>in g-golf?
<leoprikler>yep
<leoprikler>at least according to the docs
<str1ngs>I think this will work.
<str1ngs>though only for response dialog. not for passing enums to say a function
<leoprikler>yeah, for that we'd need symbol->enum
<str1ngs>definitely an improvement http://paste.debian.net/1163263
<str1ngs>I need to dynamic wind this too
<str1ngs>if thunk throws an exception need to make sure (destroy dialog) is always called.
<leoprikler>you can compare symbols with eq? instead of =
<str1ngs>right, I think eq? is preferred always except for strings and integers?
<str1ngs>ie string= and =
<str1ngs>this examples gets better with case. here I'm only want 'ok so I'm explicit
<leoprikler>eq? is preferred for symbols and list pointers
<leoprikler>normally you'd use equal? if you don't care (IIRC also for strings)
<leoprikler>= is for numeric comparisons, especially with floats
<str1ngs>right that's why I had it before. thanks for catching that.
<str1ngs>yes-or-no-p is just stop gap till I can fix some coroutine issues in emasy. I'd rather use the minibuffer echo area like emacs.
<leoprikler>string= and other = functions (list=, vector=) are specialized forms of equal?, that do type-checking on top
<str1ngs>but I'll probably keep this gui yes-or-no-p for special GTK instances
<leoprikler>tbh you should probably add some more parameters to it, so that you can distinguish the cases in which you'd want to spawn a dialog from those where you'd want to use the minibuffer
<leoprikler>e.g. for M-x you likely want the minibuffer, but if you click on an icon you likely want the dialog
<str1ngs>also equal? can be specialized with goops
<leoprikler>as can be eqv? and =
<str1ngs>leoprikler: I can't parameterize this is platform code. an minibuffer yes-or-no-p is better since it does'nt require a platform.
<leoprikler>guile-gi has a = override for numeric comparisons with enums IIRC
<str1ngs>plantform meaning GTK, QT, win32
<leoprikler>you should still distinguish between maybe-platform? and never-platform?
<str1ngs>I could, but not useful since on other platforms this code would never be seen
<str1ngs>I have a higher generic abstraction. so as long as the platform has a working minibuffer. then yes-or-no-p work work via a minibuffer prompt. just like emacs.
<leoprikler>you do know that emacs uses platform-specific widgets for certain cases, yes?
<leoprikler>If dialog boxes are supported, a dialog box will be used if ‘last-nonmenu-event’ is nil, and ‘use-dialog-box’ is non-nil.
<str1ngs>of course, but for maintainability its easier to maintain a non platform specific yes-or-no-p
<str1ngs>the less GTK code I have to write the better IMHO :)
<dsmith-work>Morning Greetings, Guilers
<bonz060>Hi guys...
<bonz060>Is there a way to pipe the output of (current-error-port) t oa string.
<bonz060>?
***rekado_ is now known as rekado
<rekado>from within Guile or with a shell?
<rekado>with a shell it’s just 2>somewhere
<alextee[m]>is it possible to compile a library out of guile code?
<alextee[m]>my use case is for zrythm. i want to add the possibility of writing DSP code in guile, and then compiling it to a library and loading it into zrythm to be used in time-sensitive parts
<alextee[m]>another option is to include a faust compiler and support faust.. but guile is better !
<alextee[m]>`guild compile` hmm
<alextee[m]>can these compiled files then be loaded into C?
<RhodiumToad>they're not compiled to native code
<alextee[m]>ah that sucks. is there no way to compile code from guile to native code then?
<alextee[m]>i could expose some guile API that can be used then i could parse the guile stuff and generate corresponding C code from it and compile that maybe...
<RhodiumToad>no (though there is a jit, in guile 3)
<rekado>alextee[m]: eventually, the compiler may produce ELF files, so it would be “native” code, but this would still be stuff that’s loaded into the Guile VM.
<rekado>if time is a concern: the Guile VM is plenty fast
<alextee[m]>rekado: it doesnt have to be perfect, but will it be fast enough to be used duringaudio processing?
<alextee[m]>ok nice, looking forward to that then
<rekado>obviously it will have to be compiled (so that the Guile VM can be used directly) and not read by the Scheme interpreter (which is *much* slower)
<alextee[m]>i'll be an early adopter :-)
<rekado>so compilation helps here.
<rekado>but garbage collection and audio processing have always been at odds with one another
<alextee[m]>is there no way to specify when to garbage collect?
<rekado>it’s complicated, but I don’t know enough to guide you
<leoprikler>you can manually invoke (gc), and probably otherwise tweak some metrics, but I think that is best avoided
<rekado>you *can* influence the garbage collector (and you can write code that produces less garbage), but the farther you go with this the farther you are removed from writing Guile.
<rekado>I think you can also delay garbage collection, hopefully long enough that you can run (gc) in a less critical phase.
<rekado>personally, though, I’d probably use Faust
<alextee[m]>yeah im thinking the same thing, faust is starting to sound a lot better for this
<rekado>it’s made for writing DSP / data flow code
<rekado>you could generate faust from Guile, of course, but … why bother :)
<alextee[m]>i'll keep guile only for UI related things and actions that run in the UI thread i guess
<leoprikler>if you want to use scheme, there are also some implementations, that directly produce C/machine code
<leoprikler>Guix has recently packaged loko-scheme, so you may try that in the meantime
<alextee[m]>oh cool
<alextee[m]>but still i guess garbage collection is a thing i need to worry about
<alextee[m]>there must be no allocations or anything that might block
<alextee[m]>unless there's something specifically designed for time-sensitive-ish things
<alextee[m]>could add it as a toy anyway because it's fun. it will just probably clip at times
<rekado>alextee[m]: perhaps Guile itself could gain alternative memory management in the long run.
<alextee[m]>that would be cool
<leoprikler>hmm, theoretically you could roll your own using bytevectors
<manumanumanu>ahoy