<sneek>daviid, str1ngs says: seems I can avoid No applicable method for #<<accessor> !state (2)> in call (!state #<<gdk-event> 7f6f67e1bd40>) if I don't compile the module I'm using !state in. does that give any indicator as to why it cant' find the method to you? <daviid>str1ngs: no, it doesn't help me to find the cause - what I would need is an exampleI can use that reproduces the problem .., what I suspect is you import 'somehow/somewhere' a GObject subclass tht has a property named state, and the g-golf fails to detect it alredy has a generic function .. but it would be really nice to have a snipset that I culd use to analyse, reproduce and solve the problem ... <daviid>*fails to detect that there a !state generic function <daviid>but even that i just said i have some doubt, because the warning you pasted here says the !state generic function has 2 methods ... <daviid>str1ngs: these are among the most complicated bugs to analyse and solve, each really needs an example we can use to reproduce ... <alextee[m]>i have a window like this while the program is running (obviously needs a revamp but it works) <RhodiumToad>manumanumanu: I asked because he credited you as the finder in the code comments <str1ngs>daviid: all I have is WARNING: (g-golf): `!type' imported from both (g-golf gdk events) and (g-golf hl-api gobject) <daviid>str1ngs: I need to reproduce the problem here, can't you produce a snipset that reproduces the proble? <str1ngs>daviid: as for repeating this. it's not so easy. since it only happens when using multiple modules. I've moved all of my imports into one modules and that does not help. this is the extent of my imports. <str1ngs>daviid: no I can't reproduce it. the closes I have gotten to bisecting this is to not compile (nomad gtk gi) and to sue !type somewhere in the module. <daviid>if you call this odule not (omad gtk gi), but (bluefox), then write soething in it that use either !type (or !state ?), then import it in a repl, so it is compiled, then 'do something, does that reproduces the probke? <str1ngs>again your trivial use case works. but my use case it not trivial have more then one moving part and use case. <str1ngs>why don't we start with this waring. <str1ngs>WARNING: (g-golf): `!type' imported from both (g-golf gdk events) and (g-golf hl-api gobject) <str1ngs>how do avoid this warning since !type is the problem anyways <str1ngs>looks to me (g-golf gdk events) and (g-golf hl-api gobject) both have !type yes? <daviid>i did explain above what i suspect may be (but i am not sure either) the cause of the roblem <str1ngs>g-golf/gdk/events.scm:(define-method (!type (self <gdk-event>)) <daviid>str1ngs: i'm working on the gdk display bug you and your user posted, and it's a complicated bug to solve to ... but thinking ... can you change the definition of your modules so that all (a) :#use-module (oop goops), then (b) also have a #:duplicate ... (grab an example in any of the g-golf modules ...) - then try again <daviid>this example you pasted mixes a way to work we use for scrits and a way to work that we use to define modules, that complicates things, debugging wise, as well <daviid>hum, maybe we can't avoid that actually ... another thng <str1ngs>daviid normally I use #:use-module. I'll change it back if you can verify my merge is correct <daviid>could you write a procedure, say gi-irepository-find-by-property-name namespace name, that returns a list (possibly empty) that list the pointers to the GObjectInfo that have a property named 'name' ... <str1ngs>daviid: I'll see about not sure what you are ask <str1ngs>err see about gi-irepository-find-by-property-name <daviid>I first wish to identify which namespace (not the nomad ones) imports a GObject subclass <daviid>str1ngs: ok, i'll do that , but not exacly now <daviid>fighting another ghost ... need to eat something as well ... <str1ngs>daviid: sorry I mean I'll write. gi-irepository-find-by-property-name <str1ngs>daviid: (gi-import "GIRepository") should work right? <str1ngs>or should I use g-golf primitives for this? <daviid>i shouldn't have asked, i'll write it, don't worry ***rekado_ is now known as rekado
<rekado>alextee[m]: amazing progress! This really makes me want to try zrythm! ***apteryx_ is now known as apteryx
<brendyyn>Hmm I'm a little puzzled. I'm writing a module that provides some procedures, but they based on another set of procedures which can all have variants (they come as a set). im trying to find a way so that i can import this module with the particular variant without needed to write a duplicate module for each one. <brendyyn>maybe i need to create some define-variant macro <civodul>did we lose old release tarballs of guile-lib? <rekado>brendyyn: I’m not sure I understand. You can import modules with a prefix so that there are no conflicts. <rekado>brendyyn: would it make sense to provide a procedure that takes the variant and spits out a parameterized procedure using that specific variant? <rekado>this way the dependency is made explicit <brendyyn>well there isn't just one but a whole set of procedures, so its a little confusing <rekado>brendyyn: can you provide an example perhaps? <brendyyn>rekado, I'm implementing SPAKE2 from python-spake2. you define a spake session with a group, which defines the set of math functions used <brendyyn>you could for example choose sha256 instead of sha512 or something like that <brendyyn>in python its all done with classes but thats different from scheme <rotty>weinholt: uh, the net really never forgets :-) <RhodiumToad>well you can do it in classes with scheme if you like <brendyyn>i dont even know what scheme classes are <rekado>brendyyn: classes with Scheme: see GOOPS <rekado>brendyyn: but you don’t really need GOOPS for this <rekado>brendyyn: you can have a configuration object that contains all of the procedures you need <rekado>instead of calling the procedures directly you first look them up in the configuration object <rekado>you know, like function pointers in C. <rekado>e.g. (define config-A `((algorithm . ,sha256) (name . "A"))) (define (magic config) ((assoc-ref config 'algorithm) "whatever")) <rekado>you could then have different configurations and have “magic” do the right thing dependent on what configuration it is given. <rekado>you don’t have to use alists for this, of course. You can use records. <brendyyn>so ive got this for example (define Y* (ed25519:add-elements Y (ed25519:scalar-multiple N password))) <brendyyn>thats hard coded with the config from ed25519. but im trying to swap them for generic `add-elements' etc. how do they magically follow a config that is set after they re defined <rekado>Y* would need to accept a config as its argument <brendyyn>since with lexical scoping everything saves the closure that existed at the time, as i learnt in sicp <rekado>(this pattern is also known as the Reader monad, by the way. It really just means that all your procedures accept a read-only argument of configurations.) <rekado>(define (Y* config) ((config-add-elements config) Y ((config-scalar-multiple config) N password))) <rekado>where “config-add-elements” is an accessor for the record value “config” that returns a procedure. <rekado>(define ed25519-config (make-config #:add-elements ed25519:add-elements #:scalar-multiple ed25519:scalar-multiple …)) <rekado>i.e. you create a config value “ed25519-config”, a record with a bunch of fields for the different procedures. <brendyyn>yep i can do that, but then its not just Y*, but X* and various others. how can i have it so the config is set once, and not manually for every single function, since it would be wrong to missmatch anything <brendyyn>sicp taught me to be scared of mutation and global stuff :p im still need to learn more useful tools <rekado>it’s neither mutation (the values are read-only) nor is it global <rekado>(this is scoped with parameterize) <brendyyn>so it makes becomes some big (let .... ) thing? <rekado>but if you want to do without parameters you can go all in and define a monad… <rekado>it lets all calls to the parameter name return the parameterized value. <rekado>within the scope of the parameterize expression <brendyyn>oh great. so i can make the session with this kind of thing <brendyyn>a spake sessions starts by generating a random number and then computing all these other session specific values <spk121>wingo: so moving guile-cairo to foreign objects was painless but it makes two api changes: can't define an equals operator the same way as a SMOB, and the default printer changes, but, otherwise should be quite similar <wingo>spk121: you can define-method (equal? (x <a>) (y <a>)) i think <dsmith-work>alextee[m]: The doc snarfer for C that guile uses internally to create the help files is not installed. <dsmith-work>alextee[m]: The scheme doc snarf is not for C files. <alextee[m]>dsmith-work: i figured.. it says it accepts a C language which was a bit misleading <alextee[m]>it has a dependency on the compiled guile sources (which are not installed!) which is not very nice <alextee[m]>where GUILE_SNARF_DOCS_BIN is "<guile source distribution>/libguile/guile-snarf-docs" <alextee[m]>dsmith-work: shouldn't the C snarfer be installed along with the rest of the guile tools? how is one supposed to extend their C programs properly without a tool to generate documentation for it? <dsmith-work>alextee[m]: Well.. I suspect there is not much motivation. The end goal is to make the ffi really great and just use that instead of hand-coding C modules. <dsmith-work>alextee[m]: Another thing to consider is that auto-generated docs are usually rather poor. Better to write a real manual. <dsmith-work>alextee[m]: I'd really like to see the C doc snarfer installed! <alextee[m]>dsmith-work: well, as a user you'd at least want to know what functions are available to use! that's my main motivation for needing the snarfed docs <alextee[m]>not sure how the ffi would work but sounds pretty cool if you don't need to write wrappers of your C stuff ***b4284[m]1 is now known as b4284
<dsmith-work>alextee[m]: I'm a *huge* fan of automation, but most doxygen generated (for example) library docs are near useless. Mostly just showing the argument names, which I can just see for myself by reading the headers. <dsmith-work>alextee[m]: So while I really like having an automated tool, I've not seen much good use of it. ***wxie1 is now known as wxie
<alextee[m]>well, some projects do it right. doxygen-like gtk-doc docs for example are amazing documentation <dsmith-work>alextee[m]: Yes, there some very excellent generated docs. <alextee[m]>that with the dev-help program is my go-to for pango/cairo/gtk documentation, and it's pretty much just from comments on the sources ***xkapastel is now known as Guest45017
***xkapastel_ is now known as xkapastel
***slyfox_ is now known as slyfox
<alextee[m]> doing `guile -s @SOME_ABSOLUTE_PATH@/myscript.scm` results in a double'd path and guile fails to run the script, but doing `cd @SOME_ABSOLUTE_PATH@ && guile -s myscript.scm` works fine <alextee[m]>doubled up path and error message: In procedure stat: No such file or directory: "/home/alex/git/zrythm/build/C:/msys64/home/alex/git/zrythm/build/meson-post-install.scm" <alextee[m]>but i have checked and @SOME_ABSOLUTE_PATH@ is "C:/msys64/home/alex/git/zrythm/build" <alextee[m]>maybe i should report this or is this a known thing/im doing something wrong? <str1ngs>alextee[m]: if you if use guile -s from a mingw terminal? <alextee[m]>when you use the C:/.... format, it prepends the current path <alextee[m]>when you use the unix format /.... it works fine <alextee[m]>can replicate this easily with just `guile -s C:/..../some-script.scm` <alextee[m]>i guess it sees that there's no starting "/" so it thinks it's a relative path <alextee[m]>meson seems to pass paths in the C:/.... format and i replace those paths in my files before building so... that's a problem with guile <dsmith-work>Currnetly attempting to cross-build with musl as C lib... <daviid>str1ngs: that function is deprecated, but it seems vte-terminal-spawn-async, the recommended one instead, gets its flags definition correct <daviid>but you still shold try to use vte-terminal-spawn-async <daviid>not sure why so many type have void as their name in so many namespaces, need to ask #introspection about this, ... <daviid>str1ngs: i can't look into this till i solved the other 2 problems i'm working on <str1ngs>daviid ahh I'll try with vte-terminal-spawn-async this API has changed a few times. <manumanumanu>RhodiumToad: oh. The mail I sent to him mentions you by your irc handle, as in "RhodiumToad over in #guile found this bug...". If you want to I can point it out to him