IRC channel logs


back to list of logs

<RhodiumToad>manumanumanu: for the record, I'm Andrew Gierth
<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.
<daviid>please do
<str1ngs>daviid: almost done.
<str1ngs>daviid: it has alot of arguements. laid it was easier to compare against the documentation.
<str1ngs>laid it out*
<daviid>str1ngs: yes, much better tx
<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?
<str1ngs>well allow-none
<guix-vits>Hi there.
<str1ngs>hello guix-vits
<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>it's ok
<str1ngs>daviid: here's a screenshot of a <terminal> buffer in nomad. :)
<daviid>str1ngs: cool, very nice
<daviid>str1ngs: why d you stay on e928900 commit? I thought the duplicate warning accessor was present in all recent versions?
<str1ngs>daviid: also ibuffer
<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>during compile time I get.
<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 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>err frame.scm
<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
<daviid>few minutes
<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>*for each
<daviid>and/or (gi-find-by-property-name namespace "state")
<str1ngs>okay one sec
<daviid>take your time
<daviid>is that Gtk then?
<daviid>can you call g-base-info-get-name on that ponter?
<daviid>i get it her it's ok
<str1ngs>okay one sec.
<daviid>could you try !type
<str1ngs>though !state is okay now, show we not check with "type"?
<daviid>it's not as ok as you think
<str1ngs>with type I get ((#<pointer 0x16fa370>) () () (#<pointer 0x175f4a0>) () ())
<str1ngs>same mapping
<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
<str1ngs>from Gdk
<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>$9 = "Window"
<str1ngs>so Gdk and Gtk both have type properties I guess.
<daviid>yes tx
<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 ... ?
<str1ngs>daviid: let me check
<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>and (g-golf)
<daviid>unless it's a utils module that does not use goops nor g-golf of coure ...
<str1ngs>this is the module that does all of the gi-imports
<str1ngs>do I need to merge in modules that use (oop goops) and (g-golf) ?
<daviid>but the other modules
<daviid>Nomad ...
<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?
<str1ngs>yes of course
<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
<daviid>just like (nomad gtk gi)
<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
<daviid>but does it solve the problem?
<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>use gnome paste
<str1ngs>try this
<str1ngs>I can paste to gnome if it helps
<daviid>no it's ok
<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>sorry I meant does *not* help
<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>it shoudln't
<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>the only weird depend might be lcov
<str1ngs>actually not true you'll need emacsy
<str1ngs> use the wip branch of emacsy
<daviid>let's try omething lese first
<daviid>can you star a fresh repl, then
<daviid>,use (g-golf)
<daviid>(gi-import-by-name "Gdk" "Device")
<daviid>(gi-import-by-name "Gtk" "Window")
<daviid>an paste here what you see
<str1ngs>$1 done $2 done $3 #<<extended-generic-with-setter> !type (5)>
<daviid>5? i only have 3 here
<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>I get 2
<str1ngs>one sec
<daviid>that's not normal
<str1ngs>Method #<<method> (<gdk-event>) 7fabd5cddc40> Method #<<accessor-method> (<gdk-device>) 7fabd6d5b5a0>
<str1ngs>daviid: hmm
<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
<daviid>,use (nomad gtk frame)
<daviid>,m (nomad gtk frame)
<daviid>tell me what yu see
<str1ngs>$1 = #<<extended-generic-with-setter> !type (5)>
<daviid>(describe $1)
<daviid>but did you comment the line 29?
<daviid>commenting #:use-module (g-golf gdk events)
<daviid>then start afresh erpl ...
<str1ngs>it's commented out
<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>which is really strnage
<daviid>right that is the problem
<str1ngs>could it a compilation issue?
<daviid>very much doubt it
<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)
<brendyyn>thought it was interesting
<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>but I think this might be wrong
<str1ngs>html frames rekado ?
<rekado>no, stack frames
<str1ngs>okay that makes more sense.
<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>brendyyn: I wrote some experimental GI bindings to QT. so you can in theory use g-golf or guile-gi . see
<str1ngs>daviid: okay one sec.
<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
<daviid>need to rest, bb tomorowo
<str1ngs>daviid: I can make a reduced module.
<brendyyn>str1ngs, amazing.
<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 ...
<daviid>we'll see
<str1ngs>brendyyn: also it works with sbcl python javascript. anything that has GI bindings.
<str1ngs>daviid: ummm I think I fixed it :)
<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
<str1ngs>daviid: I found the culprit. see thanks for the help. this was my first really annoying bug on my part. apologize I could not find it myself.
<dsmith-work>UGT Greetings, Guilers
<civodul>wingo: are ports thread-safe?
<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
<civodul>ok, that's the answer i expected
***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.
<spk121>I wonder if it still works.
<str1ngs>spk121: yeah, looking at this example it's not pretty
<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
<spk121>str1ngs: interesting
***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 ?
<dsmith-work>Was that to be passed to ./configure ?