<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. <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. <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>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) <lloda>you can do that with match-lambda iiu what you mean <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> ,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? <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>(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 <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. <daviid>i know that thanks, but this is not related to the problem <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>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 <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>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>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 <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>to test, i'll use a thread and no quit ... in the future <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. <daviid>str1ngs: yes they are, should have thought about this but ... tired I guess <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>it raises an exception because gtk-main-quit returned value is void, and a delete-event callback must return one value, a boolean ... <str1ngs>though personally 'destroy is probably a better for gtk_main_quit <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 <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 <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