<str1ngs>daviid: I can get around the flag by use void's 'none since it's 0 . it's not ideal. can you confirm that type-desc does not support callback yet? ***catonano_ is now known as catonano
<daviid>str1ngs: manually patching here and there is very 'brave' of you, but I hope I can find a real solution to what appears to be a GI problem <daviid>this said, type-desc is the name of a slot, and local vr where that applies, which is used to store further description for arguments and retured values that are taged as 'interface <daviid>flags are working, but they depend on a proper registered name,which apars not to be the case for "GLib" "SpawnFlags", for some reasons yet to identify, propb with the help of the #introspection folks ... <str1ngs>daviid: I ended up calling this function from my typelib, I could not get around the Throw to key `match-error' with args `("match" "no matching pattern" callback) child-setup-data argument throws in though this argument should really take #f anyway. as far as I can tell it's not matching callback for type-desc 'callback in prepare-gi-args-in. <str1ngs>daviid: I'll remind you about this when you are not as busy. I was trying to avoid add C depends is all. <daviid>str1ngs: i thought you were talking about 'flag (interface type), within the context of a call to vte-terminal-spawn-async - but indeed there is no callback type-tag implementation yet <daviid>now, if you have an example of this code you refer to that raises the callback related error, i'll add it to the tofo list ... <daviid>str1ngs: also, do y have a snipset callng this vte-termnal-... that i can use to debug ? <str1ngs>daviid: I'll put quick example together. mainly it's just importing (gi-import "Vte") creating the control with (make <vte-terminal>) add it to a container then call vte-terminal-spawn-async. on debian you'll probably need to install gir1.2-vte-2.91 as well. or what ever version it has. <str1ngs>daviid: it has alot of arguements. laid it was easier to compare against the documentation. <str1ngs>argument 3 which is working_directory. should take #f but it's a minor issue. I think my argv is right but not 100% sure. <str1ngs>atleast it works in C with "/bin/bash" <str1ngs>daviid spawnflags is working with '(default) like it should with async. as far as I can tell anyways. <daviid>but any other value fails then? let me try ... <str1ngs>daviid: as far as I can see child-setup fails when trying to match callback <str1ngs>it should take #f since it's nullable IIRC? <daviid>str1ngs: i know why it refuses #f for the working_directory arg, and I'm gona fix this first :) <daviid>because it's easier to fix :) - mean while I think ... to the other problems ... <str1ngs>daviid: no worries, it's not a rush. I'm just calling this from my typelib meantime. I was just trying to avoid the C dependencies. also (getcwd) is not to bad to use but it should take #f as well. <daviid>str1ngs: I pushed a fix for that specific bug (the one reveled by the working_directory argument ...) <str1ngs>daviid: okay, I cant test that for awhile since. I'm still on hash 9e890031a1664608d0422b18867d75719deab864. due to the !type issue. <daviid>str1ngs: why d you stay on e928900 commit? I thought the duplicate warning accessor was present in all recent versions? <str1ngs>daviid: if I move to the new gdk event useing !type throw an error. don't recall <str1ngs>don't you recall. talking about !type? <daviid>yeah, this change introduced that !type accessor duplicate warning, but other version still had and have a !state accessor duplicate warning right? the same example you're using ... ? <str1ngs>daviid: when I consolidated all of my imports to (nomad gtk gi) !state was fixed but not !type <daviid>ok, anyway, it is a serious bug, that i'd like to fix ... but i need to understand what causes it :) hence this proc i was talking about, i'm writing it now, to find, if any, GObject subclass that have a 'name' property ... <str1ngs>daviid: one sec I forget to stash my gdk event port. should be easy to change though <str1ngs>WARNING: (g-golf): `!type' imported from both (g-golf gdk events) and (g-golf hl-api gobject) <str1ngs>WARNING: (g-golf): `!window' imported from both (g-golf gdk events) and (g-golf hl-api gobject) <daviid>right, these bugs are all related ... <daviid>but i need a snispet, hence this proc i'm writing to help us find a 'symptom' gobject calss <daviid>these are warnings, but ultimately wouls crash your app ... <str1ngs>okay, I mean the other thing is I can push the port and you cant pull nomad from git? <str1ngs>just my configure.ac is not ideal right now. to many depends <daviid>str1ngs: i'd rather narrow down as much as possible <daviid>we should be able to reproduce with just a few lines of code <str1ngs>I can probably narrow it down in frame. but if I use a single trivial file it won't replicated. because it seems to be a module merge issue. <str1ngs>what I mean I can create a trivial example that fails in the effected file. I think that's the best I can do. <daviid>str1ngs: wait till i have that proc i'm talking about <str1ngs>okay lets do that. the proc would be useful for introspection anyways. <str1ngs>meantime I'm using an older hash so I can do continue hacking on nomad. <daviid>str1ngs: ok, I pushed, i'd like you to pull/make, then try (gi-find-by-property-name namespace "type") for all namespaces that nomad imports <daviid>and/or (gi-find-by-property-name namespace "state") <daviid>can you call g-base-info-get-name on that ponter? <str1ngs>though !state is okay now, show we not check with "type"? <str1ngs>with type I get ((#<pointer 0x16fa370>) () () (#<pointer 0x175f4a0>) () ()) <daviid>right, i need to think how tosolve this <daviid>but it is a g-golf bug as i thougth <str1ngs>(g-base-info-get-name (car (car $3))) is Device <daviid>by the way it seems state is guile core prog, that escaped my 'eyes' to <daviid>ah no, my mistake, it's a clutter 'thing' <daviid>anyway, I think i know what's wrong <str1ngs>*scheme@(guile-user)> (g-base-info-get-name (car (gi-find-by-property-name "Gtk" "type"))) <str1ngs>so Gdk and Gtk both have type properties I guess. <daviid>but the bug s exactly what i thought, now need to fix :) <daviid>str1ngs: actually, i can't reroduce the problem you face in noamd, are you sure all your modules both #:use-module g-golf and #:duplicate ... ? <daviid>i mean (oop goops) and #:duplicates (merge-generics replace warn-override-core warn last) <str1ngs> #:duplicates (merge-generics replace warn-override-core warn last) should work right? <daviid>maybe soe of your modules do not need g-golf, but if they do, then you must have (oop goops) and <daviid>str1ngs: but the module must import (oop goop) <daviid>unless it's a utils module that does not use goops nor g-golf of coure ... <str1ngs>do I need to merge in modules that use (oop goops) and (g-golf) ? <str1ngs>I don't understand do I need to merge in the other modules as well? <daviid>in those namond modules, do you use goops, and /or g-golf? <daviid>str1ngs: what i'm trying to say, what i suspect, maybe, is that y hve a module somewhere, that do use goops and/or g-golf, and does not have the proper module #:duplicate (merge-generics ...) , maybe, i'd like to be sure <str1ngs>daviid: I see some that do not. let see if I have some orphaned g-golf uses <str1ngs>daviid do i *need* to merge when using g-golf in a module.. yes or no? <daviid>str1ngs: yes, _and_ it must import (oop goops) as well <str1ngs>okay I have some orphaned g-golf uses I think let me clean these modules up <daviid>str1ngs: even in a repl you'd have to do that <str1ngs>dunno have not had a problem with this until now. <str1ngs>the (oop goops) requirement is kind strange to <str1ngs>daviid I've updated all my modules any module that uses g-golf now used oop goops and merges <str1ngs>still throw an error when I use !type <str1ngs>daviid: if do #:use-module (g-golf gdk events) it's fixed <daviid>can i see the module code, a link <str1ngs>(g-golf gdk events) get re-exported so it's some merge issue <str1ngs>I can do a paste I have in tree changes <daviid>he module you just added the #:use-module (g-golf gdk events) <str1ngs>and now I cant paste to debian. do not spam ffs <daviid>if you comment line 29, move line 31 above the duplicates, does it solve the problem? <str1ngs>does help. I don't think define-module is order dependant? <str1ngs>you know i love generic methods. but merging is a PITA! :P <daviid>when you say does help, does it solve? <daviid>it doesn't make sense ou need to import (g-golf gdk events), if you import (g-golf) <daviid>whch re-export the publc nterface of all its modules ... <str1ngs>daviid: right I checked g-golf.scm encase it was not being exported <str1ngs>(gi-import-by-name "Gdk" "Event" #:with-methods? #f) should not effect anything in g-golf.scm? <daviid>i think i need to clone nomad, where is it hsted? <str1ngs>daviid: one sec let me commit my stash <daviid>not sure i have the dependencies here though .. <str1ngs>actually not true you'll need emacsy <daviid>(gi-import-by-name "Gdk" "Device") <daviid>(gi-import-by-name "Gtk" "Window") <str1ngs>$1 done $2 done $3 #<<extended-generic-with-setter> !type (5)> <str1ngs>one sec should be $3 = #<<extended-generic-with-setter> !type (2)> <str1ngs>I had some extra helper stuff in ~/.guile <daviid>it should be #<<extended-generic-with-setter> !type (3)> <daviid>try (describe $3) - if $3 is the extended-generic... <str1ngs>Method #<<method> (<gdk-event>) 7fabd5cddc40> Method #<<accessor-method> (<gdk-device>) 7fabd6d5b5a0> <str1ngs>daviid: hmmm could it be because I'm use <gtk-application-window> as a super class? <daviid>but in this fresh repl, you didn't <daviid>anyway, can ou try a fresh repl, then <str1ngs>$1 = #<<extended-generic-with-setter> !type (5)> <daviid>but did you comment the line 29? <daviid>commenting #:use-module (g-golf gdk events) <daviid>ok i need to think and rest as well <str1ngs>okay, thanks for the help. now I have an idea whats going on I can see if my modules causing the problem <str1ngs>and I have a hacky fix for now so that alright too. <str1ngs>daviid: FYI when i call (describe !type) in key-press-event there is no Method #<<method> (<gdk-event>) 7fabd5cddc40> like the REPL. <daviid>but you can see for yourself that even commenting the import it is there ... <str1ngs>has to be an issue with my modules I think at this point. <str1ngs>don't worry to much on this I think I can debug this more. <daviid>and (describe event) in that signalcallback gives a <gdk-event> instance? <daviid>and (describe !state) in that same key-press-event does show <gdk-event> in its methods right? <daviid>still commenting the (g-golf gdk events) ... <brendyyn>"KDE/Qt bindings could be generated from the C bindings, or using GOOPS 10 (which would require someone to rewrite parts of GOOPS in C)." - Mentioned in Why use Scheme (2002) <rekado>for a web application I’d like to add a debug mode to connect to a REPL and inspect the frames. <rekado>so I wrapped the server in a catch and thought about starting a REPL server in the handler <rekado>should I instead spawn a repl server first and run the web server in that thread? <daviid>str1ngs: can you confirm that (describe !state in that same key press envent signalcallbck does show the <gdk-event> in its methods/accessors? <str1ngs>daviid: Methods defined for !state Method #<<method> (<gdk-event>) 7f9109b7f5c0> <daviid>how can that be, and not for !type? is a mistery ... <daviid>that is with the import line commented right? <daviid>difficult to debug 'on the phone ' :):) <daviid>str1ngs: i think it shuld be possiblet write a sall module that just use gtk gdk, define a class of ours and a key-press event callback <str1ngs>daviid: I can make a reduced module. <rekado>I guess I can use (system repl error-handling) instead <daviid>str1ngs: if yu can, just that, then we'll see <daviid>copy the hello-world, add gdk, define a frame class and try ... <str1ngs>brendyyn: also it works with sbcl python javascript. anything that has GI bindings. <brendyyn>str1ngs, i will have to research this, i really dont know anything about GI <str1ngs>daviid: I think loading ~/.nomad is causing the problem <civodul>i realize since 2.2 i never know the definite answer <civodul>i thought the answer was "yes" but i don't see any locking in there <wingo>civodul: they should never crash or write OOB if that is the question ***jackhill_ is now known as jackhill
<spk121>I asked this a couple of months ago, but, drawing a plot. (in this case memory vs time) Any new and exciting chart libraries out there? <spk121>I guess wingo 's guile-charting is still out there somewhere <jcowan>How about old, boring, and reliable chart libraries <jcowan>(not that I know of any; I would always defer charting to LibreOffice or such) <spk121>jcowan: in my silly guile+gtk debugger project, I wanted to plot out the memory currently allocated. When I need to make regular charts, I'm usually a gnuplot fan. <luni>i have a question about OOP. Now i have defined a slot like this: (dice #:init-value (list (make <Die>) (make <Die>)) #:accessor dice-list) . How could be possible use instead of init-value a function that accepts a variable number of objects (<Die>))? <str1ngs>spk121: maybe render with gnuplot then display in gtk as a pixbuf? <spk121>str1ngs: sure. Would work great. It is just that is cheating according to my own self-imposed rules. But if I was going to go that route, I think I still have a guile script that calls that ancient GNU Plotutils program. <str1ngs>spk121: you could make a typelib that uses C++ binding. and only expose a C interface. that's what I used for QT <str1ngs>basically it would be a gnuplot GI binding. you'd only have to stub out the functions you need. <str1ngs>but then you are still use C it's just reusable from scheme. <spk121>luni: it is a little odd to have an initializer that takes an argument. The short answer is that you probably shouldn't. <luni>ok... thank you. i was thinking to use something like #:init-form that accepts a procedure but with no arguments. I need to pass the number of dice... or maybe have to think better about the utility of the Dice class used only to make a list of dice used by a roll generic method. I could create the list directly inside the generic method maybe <luni>because of if i have a Die class i don't need the Dice class to define a group of dice <spk121>luni: you could make a macro that makes a family of classes. Or you could have your initializer depend on a global. But, of course, in GOOPS you can do anything if you try hard enough. I'm just big on keeping things boring ***jonsger1 is now known as jonsger
<dsmith-work>What was it again to get 3.0.x working on arm 32bit? Something about disabling jit ? 
