IRC channel logs


back to list of logs

<rlb>wingo: right -- I suspect it is, since that patch was directly on 2.2.6, but I'll double-check.
<daviid>str1ngs: I am sorry gdk-event are taking more time the what I initially announced here - it's actually a bit more complex then I initially thought, then I also had (and still have) to dedicate some timeon another task ... but I am working on it ...
<str1ngs>sneek: later tell daviid. no rush I'm still working on this guix gobject issues. which effects guile-gi as well.
<sneek>Got it.
<str1ngs>sneek: later tell nly there are some examples here I have ones for scheme, lisp, python and javascript. though I'm sure you are only interested in the guile one
<sneek>Got it.
<str1ngs>sneek: later tell nly. for a speech interface I would prefer some thing that is either a C library or GTK related. vs QT
<str1ngs>sneek: later tell daviid also I have a work around for the key press event issue. I just pass the goops class to a typlib function and setup the signal there. so the end result is the same.
<sneek>Will do.
<rlb>Is there any way to use string->keyword and keyword->string without changing the reader globally -- i.e. I want to use those functions without breaking compilation of something like (use-modules (guile web)) which has a #:prefix foo: in it. If not, I wonder if we might want to provide alternate access to those two functions.
<rlb>You can demonstrate the problem by creating a module containing (define-module (foo) #:use-module ((srfi srfi-4) #:prefix bar:)) and make sure it's not in your ~/.cache, then from a repl, (use-modules (srfi srfi-88)) followed by (use-mouldes (foo)).
<rlb>Here, with 2.2.6 compiling/loading foo crashes because it reads bar: as a keyword.
<rlb>(same thing happens with (web client) -- what I meant to say above, rather than (guile web))
<rlb>Oh, well, I guess I can just side-step it for now -- didn't realize those two functions were just trivial indirections...
<rgherdt>Hi! I'm trying to run the tortoise example on guile-2.2 and gnuplot 5.2 and somehow when I run scm_shell and try out tortoise-move etc. nothing is drawn. Did someone experience the same problem? Here the code:
<rgherdt>If I call tortoise_move direct out of C it works
<rgherdt>I solved the problem. The issue was fprintf was outputting commas instead of dots for floating points, changing the locale fixed it
***ng0_ is now known as ng0
<chrislck>I have a (for-each) vs (ice-9 match) query... not sure how to express myself.
<chrislck>Having discovered the magic of (ice-9 match), is it possible to translate its conciseness into for-each?
<chrislck>e.g. consider a regular alist (define greeks '((a alpha) (b beta) ...etc...)) is it possible via macro to create an uber-for-each?
<chrislck>(for-each! (lambda ((letter greek)) (format #t "~a->~a in greek" letter greek) greeks)
<chrislck>... I suppose there's no harm trying
<lloda>you can do that with match-lambda iiu what you mean
<lloda>I use it all the time
<chrislck>ooh fancy
<chrislck>how clever they are
<chrislck>(for-each (match-lambda ((letter greek)) ...) greeks); much conciseness
<chrislck>does it makes it possible to write a whole scheme prog without any car? >:)
<daviid>str1ngs: I pushed a few patches, wip, so that g-value-get-boxed 'blindingly' return its (pointer) value when the boxed type is union, so we can start to play with gdk-events, but i have a strainge results when asking for the event type
<sneek>daviid, you have 2 messages.
<sneek>daviid, str1ngs says: no rush I'm still working on this guix gobject issues. which effects guile-gi as well.
<sneek>daviid, str1ngs says: also I have a work around for the key press event issue. I just pass the goops class to a typlib function and setup the signal there. so the end result is the same.
<daviid>str1ngs: if you could pull and make ... then try this example - - but in a repl, like this
<daviid> ,use (g-golf), then (load "hello-world.scm"), then (main '()) and then hit a key of the keyboard and hit the top-level right button of the window bar, the cross, so the delete-event is triggered
<daviid>then in the repl: (gdk-event-get-event-type %delete-event) and/or (gdk-event-get-event-type %key-press-event)
<daviid>big surprise, here it returns 469802720 for the former, instead of 0 )(zero)
<daviid>actually, to trace the problem, I added a call to display the result of the call to gdk_event_get_event_type, then it displays 469802720, and gdk-event-get-event-type returns #f, since there is no such gdkevent type ...
<daviid>at this point, I don't know what I could do to try to figure out what the problem is, anyone has an idea?
<str1ngs>I can test this now
<daviid>technically, I didn't even have to bind gdk-event-get-event-type, because g-golf provides scheme support to C union types, in (g-golf support union), c-union-ref and c-union-set!, but that returns exactly the same value (which is why I did bind gdk_event_get_event_type, thinking there might be a bug in my c-union-ref, but both return the same value
<daviid>(c-union-ref %delete-event 96 int) -| 469802080
<daviid>96 is the size of the union
<daviid>(describe (gi-cache-ref 'boxed 'gdk-event)) to see the complete def
<str1ngs>(describe (gi-cache-ref 'boxed 'gdk-event)) works for me
<str1ngs>the lamba signature for key-press-event looks more inline is the C closure which is a nice change
<daviid>str1ngs: yes, expected, what does not work is what i talked about above
<daviid>str1ngs: things will change still, but i first have to solve the bug
<daviid>of this low level first attempt ... gdk-event-get-event-type returns 'fancy' values
<str1ngs>I'm still groking the issue you having give me sec
<str1ngs>you are*
<daviid>so does return strange values - (c-union-ref %delete-event 96 int) and (c-union-ref %key-press-event 96 int)
<daviid>I asked on #introspection if anyone has a idea of what could be the cause, but nobody could thnk of something
<daviid>str1ngs: what is the include i would need to add to libg-golf.c to have access to GdkEvent nd friends ...?
<daviid>or maybe the #include glib-object.h is enough
<str1ngs>daviid: important note the continuation for the key-press-event is not doing what you think it is doing.
<str1ngs>TRUE to stop other handlers from being invoked for the event. FALSE to propagate the event further.
<str1ngs>taken from
<daviid>i know that thanks, but this is not related to the problem
<str1ngs>nvm I read this wront
<str1ngs>wrong it is do *not* sorry
<daviid>both need to return #f, which is what the example shoews, but again, this is not the problem
<str1ngs>I read the comment wrong your understanding is correct
<daviid>let's concentrate on the bug
<daviid>str1ngs: do you know the include i need to add to libg-golf? it complains nknown type name ‘GdkEvent’
<str1ngs>another thing since you are have an event that main quits when the windows is destroyed you don't need to all it after destroy the window on button click
<str1ngs>to call main quit I meant
<daviid>please let focus on the bug
<str1ngs>I will find GdkEvent
<str1ngs>#include <gdk/gdk.h>
<daviid>libg-golf.c:35:10: fatal error: gdk/gdk.h: No such file or director
<daviid>or maybe i'm missing some -dev debian packages
<str1ngs>need pkg-config --cflags gtk+-3.0
<str1ngs>and libgtk-3-dev
<str1ngs>daviid: making progess here give me a sec
<daviid>str1ngs: i wrte a C func, and it gves wrong vlaue as well
<daviid>i think the pointer is invalid, but why don't know yet
<str1ngs>daviid: please try with does delete-event give you the right value?
<str1ngs>no need to use a repl
<daviid>yes it does
<str1ngs>I think the use of set! is problematic it's best to stay within the signals. but you would understand the underlying guile aspect.
<str1ngs>think if the event is unreffed after the signal is run
<str1ngs>un-referenced I meant
<daviid>str1ngs: the only explanation would be that the events are becoming invalid after gtk-main-quit - the set! was purely to test/try ...
<str1ngs>yes gtk-main-quit will not even return from the signal. and it does clean up. I have structured where gtk-main-quit should be called
<daviid>did ask on #instrospection
<daviid>but it make sense
<str1ngs>I hoped this helped?
<daviid>ok, tx for the help
<daviid>to test, i'll use a thread and no quit ... in the future
<daviid>*a separate thread
<str1ngs>right I was going to mention that for repl use
<str1ngs>daviid: I'm pretty confident the event is un referenced after the closure is called.
<str1ngs>if you add this signal snippet you can see what I mean.
<daviid>str1ngs: yes they are, should have thought about this but ... tired I guess
<str1ngs>no worries
<daviid>note that your commet related to 'no need to #f in the delete-event callback' is 'inaccurate, here is what happens: the window is destroyed, the gtk main loop quits, but the scheme glosure-marshaller still runs, and it expects a boolean
<daviid>when you comment this last value, you may try, it raises an exception
<daviid>which is expected
<daviid>it raises an exception because gtk-main-quit returned value is void, and a delete-event callback must return one value, a boolean ...
<str1ngs>good to know thanks.
<str1ngs>though personally 'destroy is probably a better for gtk_main_quit
<str1ngs>a better signal*
<str1ngs>'delete-event is mainly if you want to protect the window from being closed.
<str1ngs>or more accurately protect it from being destroyed
<daviid>not sure, but these small example are so that i can test ... i know quite a lot of uers click on the delete (top roght button on the wndow bar) to delete the window, precisely
<daviid>but everyone will be able to do what ever he/she thinks best
<str1ngs>that's understandable. but that also destroys the window so 'destroy is always called on destruction
<daviid>my task is to provide signal and gdk-event processing fnctionality ..
<str1ngs>with 'delete-event you can by pass destruction
<str1ngs>say hide the window instead.
<daviid>yes, if that is what you want, like you personally
<daviid>for that users would clck the _ instead
<str1ngs>right, but with this example both click button and delete window achieve program quit. simply by the window being destroyed.
<daviid>str1ngs: it is merely a test code, it does not reflect real app
<daviid>str1ngs: in real app though, you'll almost alwys will find both a quit menu entry or button and the delet-event
<str1ngs>that's understandable
<daviid>but let's not argue, i have other things to do, really, do as you wish in your app, of course
<str1ngs>the gdkevent is looking much better even up to this point. thanks for the work davvid
<daviid>str1ngs: tx, it's going to be much better still, basically, like guile-gnome, i want to 'copy' the guile-gnome interface, but I still have quite a few difficult little thing to do to get there ...
<str1ngs>makes sense, that's one aspect I like about g-golf. considering I'm used to the C interfaces myself