IRC channel logs
2023-03-04.log
back to list of logs
<daviid>lloda: here is the definition of the function we use that returns the pointer i am passing to the cairo-pointer->context newly added proc .. <daviid>lloda: and that is what BrokenClutch uses to call the cairo using the ffi, so it is likely a 'correct' pointer (?) <daviid>BrokenClutch: can you confirm the above sentence is accurate? can you paste a sample of your g-golf cairo example? <daviid>lloda: is there a way to get the cairo_t* 'manually', once we called (cairo-create (cairo-image-surface-create 'argb32 140 100)), so we could try to call cairo-pointer->context with that pointer and check it works ? <BrokenClutch>daviid: what paste site you use? I can show the code, it's pretty small and simple <daviid>select the language 'scheme' for better rendering .. <BrokenClutch>daviid: and to answer the question, yes, I'm using the returned pointer from append_cairo <BrokenClutch>daviid: forgot to mark your name when I sent the link above <daviid>BrokenClutch: no need, we usually paste anonymously, and that would be your name actually ... <BrokenClutch>daviid: I was saying on IRC, like, when I've sent the link <BrokenClutch>Not even saw the author option in the paste site, hahahaha <daviid>BrokenClutch: ok great - this is just to confirm for lloda (and myself) that the cairo context pointer is valid, and probably the bug is in the cairo-pointer->context def, but i need the help of lloda to solve it ... <dsmith>daviid: Just started a fresh build from main. <daviid>dsmith: same here, i posted a long explanation that for some reason, my previous build failed , but i re-compiled and built gule-cairo as well ... <dsmith>That's ./configure --prefix=/opt-9 <daviid>dsmith: yes, we are trying to slove a segfault in guile-cairo now <daviid>dsmith: as you are a good C programmer, if you have an idea <daviid>dsmith: now, to debug, i 'd like to access the pointer in the guile-cairo context smob <daviid>after (cairo-create (cairo-image-surface-create 'argb32 140 100)) => $5 = #<cairo-context 7faf46da8e20> how to i get the cairo context pointer, so i can call the newlly added proc cairo-pointer->context and help lloda to get it 'right' <dsmith>Dunno about good. Old. war torn. battle weary. <daviid>BrokenClutch: in g-golf, each example (small of course, is a script, fwiw, here is the 'Simple Paintable' template that once guile-cairo works, and completed, will land in the distributed examples - https://paste.centos.org/view/4bdfa8d0 <daviid>BrokenClutch: then, as you can see in this short example, you should not import the all gtk space, rather selectively what you need ... which should boost the launching of the example by a substantial factor <BrokenClutch>daviid: I was importing everything just to snoop it around on the geiser REPL <BrokenClutch>but I didn't know that I could have the width and height as arguments of the snapshot vfunc <daviid>BrokenClutch: but i subclass GObject, you subclaeed gtk-widget, caution ... <daviid>their respective snapshot virtual function aren't the same <daviid>BrokenClutch: your code is perfectly valid to ... but i am more concerned you learn the goops / guile module / generics extremely difficult to understand for a new goops comers ... and the script and any other g-golf exmple, put in exec the recommendation of the g-golf manual ... you will have been warned :):) <BrokenClutch>daviid: I'm going to, thanks for the help, I'm new to guile and I'm loving it <daviid>BrokenClutch: if that new, then you are talented :) congrat <BrokenClutch>daviid: I have some experience with lisp, but I use haskell mainly for doing some dumb projects <BrokenClutch>and yes, I'm using this opportunity to say something about haskell, is something that we all do, we must spread the word <daviid>lloda: could t be that cairo_reference sems to be called tice ? it is called by scm_take_cairo (?) <daviid>lloda: how about "return scm_take_cairo ((cairo_t *) scm_pointer_address (scr));" ? <daviid>hum, i just tired, that segfault as well <dsmith>Ok. So need to enable core dumps. (Always forget how). some rlimit? <dsmith>That lets the app dump a core file. Then you can use that with gdb to see where the segfault happened. <dsmith>(most segfaults I've seen in C/Scheme is letting a SCM be NULL) <daviid>a line which i changed to try return scm_take_cairo ((cairo_t *) scm_pointer_address (scr)); - that segfault as well <dsmith>So is the argument a SCM or a pointer? <daviid>line 72 defines the cairo context pointer, line 79, i cll the 'make me a guile-cairo cotext opaque type please', and it segfault <daviid>in guile-cairo.c, i see lines 66 - 70, it just passed the cr, maybe i can try that <daviid>return scm_take_cairo ((cairo_t *)scr); <daviid>oh well, it ne3eds a billion years C expert for one line of code <daviid>this segfault as well return scm_from_cairo ((cairo_t *)scr); <daviid>this segfault as well return scm_from_cairo ((cairo_t *) scm_pointer_address (scr)); <daviid>today's one billion dllars quiz: how can you make a guile-cairo context recevingin a cairo context <daviid>i am next to blind here though, so if someone who knows C and libguile, can tell us how to ... (1) making a guile-cairo context when receiving a caro context pointer; (2) extract the cairo context pointer from guile-cairo context; then we can use (2) to write and debug (1) ... <mwette>in C, scm_from_cairo, scm_to_cairo <daviid>mwette: everything i tried segfault <daviid>mwette: meanwhile, did you answer my quiz, where is the cod to use th generate cairo.scm ? and what would be the option to schemefy names ? <daviid>and a renamer is even commented ... great, i'll try asai can - tx <dsmith>daviid: What's your example test that segfaults? Can you do it with just guile and guile-cairo? OR do I need more stuff? <dsmith>(let ((ctx (cairo-create (cairo-image-surface-create 'argb32 140 100)))) <dsmith> (eq? ctx (cairo-pointer->context (context->cairo-pointer ctx)))) <daviid>that i don't know, not sure - the problem is not that eq? it is that both proc segfault <daviid>context->cairo-pointer ctx segfault <daviid>sorry the other way around cairo-pointer->context, all i tried including the one prposed by lloda segfault - then i couldn't even come with something compilable for context->cairo-pointer <daviid>dsmith: but i beleive reconstructing would never be eq?, because they are smobs, new smobs ... <daviid>all we need is to be able to call, from scheme, scm_from_cairo (cairo_t *ctx), and so far all ateempt segfault <dsmith>scheme@(guile-user)> (cairo-create (cairo-image-surface-create 'argb32 140 100)) <dsmith>$1 = #<cairo-context 7f88502c1560> <dsmith>scheme@(guile-user)> (context->cairo-pointer $1) <dsmith>scheme@(guile-user)> (cairo-pointer->context 2) <dsmith>ice-9/boot-9.scm:1685:16: In procedure raise-exception: <dsmith>In procedure pointer-address: Wrong type argument in position 1 (expecting POINTER_P): 2 <daviid>dsmith: at least no more segfault <daviid>(cairo-pointer->context $2) <$2, not 2 ? <dsmith>My $ is sticky. Poured a coffee on it a while back. <daviid>yes! cn you paste your changes or the entire file, as you wish <dsmith>Not sure if a finalizer is needed.. (the NULL in scm_from_pointer) <daviid>i'll let you juge that :) - let me try here and use it with g-golf - <dsmith>return scm_from_cairo ((cairo_t *) scm_to_pointer (scr)); <dsmith>return scm_from_pointer (scm_to_cairo (scr), NULL); <dsmith>"from cairo to pointer", and "from pointer to cairo" <daviid>dsmith: it works, but i need to complete a few cairo calls to actually see something - many thenks, just a few minutes i shall proove it effectively works <dsmith>I added those just after scm_release_cairo. Seemed a good place <daviid>hum, what is this expression in scheme cairo_set_dash (cr, (double[1]) { RADIUS * G_PI / 3 }, 1, 0.0); - the (double[1]) { RADIUS * G_PI / 3 } i mean [i have radisu and pi values 'in hand'] <daviid>it's documented here, but i still do not know what to pass ? <dsmith>An array of doubles. Actually a pointer to the first item in the array. <dsmith>But I'm thinking C. That doesn't look like C. Or Scheme. <haugh>Do we have any former/current Clojure users in here? I'm curious if/how Guile's approach to hash tables (immutability is not thread safe) changes one's approach to data processing, especially if you're used to taking this for granted. The data processing I've seen and imitated so far is mostly pattern based (matching sexps) or record based (depends on syntax for terseness). These are strong statements I'm making and I would love to be corrected on any <haugh>misunderstanding; I'm just not extremely encouraged by the documentation on hash tables and vhashes. <sneek>rlb was last seen in #guile one month and 10 days ago, saying: . <haugh>oh no he was eaten by the JVM D: <dsmith>Well, he's working on lokke, a clojure front end to guile.. <daviid>dsmith: (cairo-set-dash cr `#(,(/ (* radius %pi))) 1 0.0) => wrong number of arg - i wonder if guile-cairo has an old cairo-set-dash <daviid>this cairo_set_dash (cr, (double[1]) { RADIUS * G_PI / 3 }, 1, 0.0); written by the gnome team works perfectly - <dsmith>The (double[1]) is a cast I guess. <daviid>dsmith: this is not the problem the C call has 4 args <dsmith>Ahh. So Guile knows the len of the vector. <daviid>ok, but, unfortunately, it doesn draw anything :( <dsmith>IN the c code, ndashes is from scm_vector_length (sdashes) <dsmith>Do you need the /3 ? (cairo-set-dash cr `#(,(/ (* radius %pi) 3)) 0.0) <dsmith>Could it be drawing the other things (dashes?) in the same color? <dsmith>Does the C example work correctly? <daviid>dsmith: sorry, complete machine crash here :( <daviid>i added the 3 - (cairo-set-dash cr `#(,(/ (* radius %pi) 3)) 0.0) - but it still doesn 'draw' on the gtk4 widget <daviid>ok, i am going to rest, thanks all, dsmith lloda mwette and BrokenClutch tomorrow i'll try a few other things .. not sure what's going on, but i don't see why it does not work, or sjhall i say why it would not work ... <cow_2001>i feel like i should really really learn proper C <cow_2001>there are some C programming tracks on coursera by irl universities <chrislck>you only learn C properly when you encounter segfaults <cow_2001>BAH & HUMBUG! (define fifo-read (open-file "my-fifo-file" "r")) blocks :( <cow_2001>i want to use it to communicate between two different processes <cow_2001>but i cannot do that when opening it blocks <cow_2001>oh. you need to write into it before it is released <cow_2001>okay, now that i want to write into it, i can't, because it blocks ~;~ <cow_2001>oh, ah, so turning off fifo buffering works <cow_2001>but now i am stuck with a popen port not wanting to be written to until i quit the repl <cow_2001>(define e (open-pipe* "espeak-ng" "--stdin")) (put-string "moo\n" e) <cow_2001>oh right! it's the weird (in a good way) text game. i played it until it told me it's still under development. <cow_2001>okay, i can only get (put-string pipe-port "moo\n") to work after (close-port pipe-port) <mwette>maybe it's buffered, try setvbuf <mwette>sneek: later tell dsmith, I got the demo to work in my wayland (guile) code <sneek>Welcome back dsmith, you have 1 message! <sneek>dsmith, mwette says: I got the demo to work in my wayland (guile) code <dsmith>mwette: Any changes that would explain why it's not working under X? <dsmith>LIke a refresh/flsh or something? <mwette>I'm not sure the dashes are there <dsmith>The "dashes" are the black sections I think. <mwette>now i have it -- let me push the new image <mwette>it works but not showing up on github <mwette>The C code version does not work? <daviid>mwette: fyi, the png you posted requires login <daviid>*visualizing the png you posted requires login ... <mwette>anything like paste.*.net for sharing pics? <mwette>^uses my ffi/cairo implementation <daviid>mwette: thanks - i just ask for help on #introspecton, if anyone has an dea of some magic needed ... - but i will try ffi/cairo later today <daviid>mwette: i unfortunately do not have a working guile-clutter working, otherwise i'd use it and demonstrate gule-cairo works fine - it however probably require some 'magic i am so far unaware of <mwette>Is it that guile-cairo does not expose the pointers and that is what you need? <daviid>mwette: i don't understand your sentence 'guile-cairo does not expose the pointers ...' <mwette>where does `append-cairo' come from? <daviid>that pointer is what the user who succeded yesterday with a few manual ffi cairo bindings ... <mwette>Ah, ok. And can you call something simple like (cairo-get-reference-count on cr) to return a sensible result? <daviid>mwette: no, i just call guile-cairo as i ever did (never ever did i have to call cairo-get-reference-count, but maybe that is the guile-clutter magic 'hidden' ...? <daviid>let me paste the patch for guile-cairo <mwette>the call to get-reference-count would validate that "cr" is valid <daviid>those are the proc i use in g-golf and used to trace the guile-cairo context effectively use the cairo context given by the gtk4 call to append-cairo ... <daviid>does that call should be just after making the gule-cvairo context? before all the draw cals? <mwette>There is no "C pointer" type per-se in GUile. What predicate call on ctx returns #t? (pointer? ctx) (number? ctx) ... <daviid>cairo-get-reference-count is unbound in guile-cairo <daviid>mwette: the guile scheme printer writes it as a pointer ... <mwette>you need to be careful about calling scm_to/from_pointer <daviid>ok, please check the guile-cairo patch, only two lines to check <daviid>all i can tell you is that append-cairo returns a pointer one can use with a cairo ffi call <mwette>OK. I was suggesting you call (cairo-get-reference-count cr) early in your nuclear-snapshot routine just to see if "cr" is valid. That call should return 1 nominally. <daviid>problem is there is no cairo-get-reference-count in gule-cairo <mwette>Ah. And there doens't seem to be a cairo? or cairo-t? predicate that I can see. <daviid>i can't find any reference occurrence in the proc index <daviid>but mwette if it wasn't a valid cairo context pointer, all cairo calls would fail, and prob segfault <daviid>which is what happened 100x while trying to get this patch for the two proc i pasted ... cairo-pointer->context and context->cairo-pointer - these two procs sefault gule till dsmith kindely find a good patch ... <mwette>I would hope so. Just trying to break down to something simple. Can you draw a simple line? <daviid>mwette: i can try, can you suggest the code, i am a very 'not knowledgeable' cairo user (i used to kjnow a bit, i forogt, will get it back ...) <daviid>what i think is all drawing occurs, but somehow the surface isn't 'aware' and refreshed <daviid>anothyer thing i thought is it draws, but in the 'back' of the background yellow squarre <daviid>be right back, 5min afk ... thanks very much for your help <mwette>maybe cairo-fill-preserve to replace cairo-fill <daviid>mwette: no change, still no drawing <mwette>and what are foreground and background rgba? <daviid>just like the C code, the background is the yellow, the foregrond is back <daviid>rotation is 0.0 [not really used, it is for the next incantation, an animated nucear icon ...] <mwette>did you try commenting out the background (li. 82-84)? <mwette>and make foreground blue or something <daviid>idid think about tat and di not try :) - now why? ow to solve it <mwette>maybe forground/background appends are in bad order or something <daviid>lt me indeed append the background first 