***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>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: 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 ... <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>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>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. <leoprikler>true, though in this case you could probably convert the value to a symbol and then use pcase <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>see the constructor takes a symbol enum. but then later we need to get response tyep <leoprikler>instead of matching the response against ok, why not assoc-ref response and then compare against the ok symbol? <str1ngs>enum-set is an alist the keys are symbols <str1ngs>also I don't need nested let here. :P <str1ngs>leoprikler: (run dialog) returns a signed integer. maybe that is the confusion <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 <str1ngs>though only for response dialog. not for passing enums to say a function <str1ngs>if thunk throws an exception need to make sure (destroy dialog) is always called. <str1ngs>right, I think eq? is preferred always except for strings and integers? <str1ngs>this examples gets better with case. here I'm only want 'ok so I'm explicit <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 <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 <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 :) <bonz060>Is there a way to pipe the output of (current-error-port) t oa string. ***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]>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... <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? <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) <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]>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. <leoprikler>hmm, theoretically you could roll your own using bytevectors