<rlb>sneek: later tell civodul I'm leaning toward just suppressing this test on i386 for now. Please let me know if you happen to think that's not OK for the shorter term: https://debbugs.gnu.org/43262 <rlb>(For the debs I mean.) ***catonano_ is now known as catonano
<daviid>str1ngs: users are expected to retreive <gi-enum> instances they are interested in, just as you are doing in your last paste - and then use the interface provided (use enum->value, enum->symbol ... see the doc for a complete list) <str1ngs>ahh probably can just use enum->value here <str1ngs>either way it's quite the boiler plate to use a enum. hence my suggestion. for enum-ref <daviid>str1ngs: in that last past, i would first retreive the gi-enum and use or to raise an error if it's not find - ... (let* ((gi-enum (or (gi-cache-ref 'enum 'gtk-response-type) (error "Missing import: " "Gtk" "ResponseType") or something like that <daviid>then as leoprikler sugge3sted, i would use case, not (when (= response 'ok) <str1ngs>right I had thought to handle exceptions <str1ngs>no here I do not need case. it's not the case example it is either 'ok or it should not do anything at all. <str1ngs>either way he main point is symbols scales better with symbols and I agree. <str1ngs>another use case for enum-ref btw (gtk-button-new-from-icon-name id (enum-ref 'gtk-icon-size 'small-toolbar)) <str1ngs>much easier then having to get the enum from the cache then looking up the value. <daviid>str1ngs: it definitely won't happen in g-golf, enum-ref I mean, as imo, it would be an api design mistake, but if you do that in nomad, i would use another name and probably use a macro (so users don't have to quote), a good name would make it clear that this api has nothing to do with the <enum>, <gi-enum> api ... <dsmith>rlb: About that 386 test failure. I'm curious how the expected and actual values differ. <dsmith>rlb: And I wonder if the jit compiler is involved. <daviid>wrt 'no here i do not need case', then you should use eq?, not = <str1ngs>daviid: I don't only use g-golf with nomad. so if I have to make a module to get an enum. I would imagine that others would suffer from this unneeded boiler plate as well. that's my feed back. <rlb>dsmith: yeah, haven't really investigated so far, but I also wondered if it could be x87 (80-bit) related somehow. <rlb>(perhaps triggered by compiler changes) <dsmith>rlb: Ya, newer compilers sometimes interpret specs differently. If the code is expecting/relying on the old behavior... <daviid>str1ngs: do you remember which of your examples uses an interface as one of its signal argument? <str1ngs>not off hand, I'd really need to go through this C code one by one. <str1ngs>in C it's hard to distinguish an interface since they all appear like classes. it's more relevant to GI <daviid>str1ngs: no worry, i'll find it here, it is a scheme example iirc, i think it was a file signal argument or something like that <str1ngs>daviid: maybe nomad_app_set_style. GtkCssProvider is an interface. <daviid>ok, but i was thinking about a scheme example i used already, i think it was a gio based example, for which one of the signal has an interface as one of its args - but no worries, tx <str1ngs>that's the only one that stands out. <str1ngs>I will take notes of something that does not work and why in the future. at-least anything I work around. <leoprikler>would (enum->value (gi-cache-ref 'enum <enum>) <symbol>) not be correct here? <leoprikler>btw. daviid in case enum->value doesn't take lists, you should maybe consider that as syntactic sugar for the flags case ***apteryx is now known as Guest38011
***apteryx_ is now known as apteryx
<daviid>leoprikler: yes to the first question, using appropriate values for <enum> and <symbol> - to the second, you prob know, but use gi-gflags->integer and gi-integer->gflags - i'll keep things 'as is' for now <leoprikler>is there a reason you use enum and gi-gflags like this? (i.e. why not enum->value and flags->integer)? <daviid>leoprikler: no, maybe i should change that <leoprikler>seepel: you mean the "->"? It might be bound to something in one of the modules it uses <seepel>In particular there is a let form that begins (let '(return) (list tag) ...), at the repl anything similar that I try results in a bad syntax error. <leoprikler>(define-syntax-rule (-> (type arg ...)) `(type ,arg ...)) <leoprikler>-> strips away the type, so the result looks more like (let return (tag) ...) <leoprikler>btw. tag gets expanded, so I'm not sure what this ends up as either <seepel>Oh really? I would expect the syntax rule to expand to `(let (return) ...), though maybe that does explain a little bit. I think my brain silently removed the quasiquote by thinking in terms of common lisp. So maybe the syntax-rule actually returns a list that is interpereted later? <leoprikler>it does compile to tree-il, which is a little different than guile <leoprikler>tbf I'm not sure how ,'(return) would be handled <seepel>Well, I think you've confirmed my suspicion that something else is going on here. I was mostly worried that some module was importing some kind of enhanced let that I was unaware of. <seepel>Thanks for taking a look with me! <leoprikler>so yeah, return is the name, tag is the gensym, make-prompt-tag is the value and the prompt stuff is the expression <seepel>Ahhh, I understand now. It could equally by (let (list 'return) (list tag) ...). Thanks so much, that would've taken me ages :) <seepel>Ah yeah, this makes so much sense -> returns the external representation of tree-il ***dddddd_ is now known as dddddd
***deesix_ is now known as deesix