IRC channel logs

2016-01-15.log

back to list of logs

***karswell` is now known as karswell
<davexunit>weee, I think I've unblocked myself wrt my syntax highlighter
<davexunit>data structure problem. seems to be solved with the use of a persistent queue
<amz3`>héllloooo :)
<civodul>hey hey!
<zxq9>Do we have any graphics bindings to guile2? (anything documented: gtk, wx, opengl, whatever) ?
<janneke>we have guile-gnome -- https://www.gnu.org/software/guile-gnome/
<civodul>and https://www.gnu.org/software/guile-opengl/
<civodul>also https://www.gnu.org/software/guile-sdl/
<peterbrett_work>Unfortunately the last time I tried, I couldn't even get guile-gnome to compile on Fedora 23
<peterbrett_work>It would be really nice to be able to use it
<civodul>heh
<civodul>daviid made a new release recently, IIRC
<peterbrett_work>wingo: reading back through the guile-devel archives, I'm a bit worried about your plan to remove smobs. I have a tonne of code in gEDA that relies heavily on smobs and there just isn't the developer resources available to replace it.
<wingo>peterbrett_work: np, i don't think they're going anywhere any time soon. to an extent it would be possible to implement the smob "api" on top of a different data structure.
<peterbrett_work>wingo: That's a big relief, thanks!
<wingo>but it's not in any near-term plan and we would talk with you before hand
<wingo>thanks for letting me know though, sometimes i live in my own world :)
<wingo>it's a nice world but a bit insular ;)
<peterbrett_work>It would be nice for $future_release to see if there are any quality-of-life improvements that could be made for people using Guile as an extension language — I feel that in the last ~3 years the focus has been more on standalone Guile programs
<wingo>what kinds of things would you like to see?
<peterbrett_work>One of the things that's kind of difficult at the moment is, "Go call this function implemented in Scheme, and give me some useful, easy-to-deal-with-from-C information if it fails"
<peterbrett_work>I have some **horrendous** code in gEDA for trying to do that
<wingo>yeah
<wingo>some wrapper for call-with-error-handling from C or so
<peterbrett_work>Most of this stuff https://github.com/peter-b/geda-gaf/blob/master/libgeda/src/g_basic.c
<peterbrett_work>And it's pretty fragile too
<peterbrett_work>Yes please :D :D
<wingo>ooh yeah all that stuff is pretty nasty :)
<peterbrett_work>Another thing that would be neat would be to be able to choose at run-time whether Guile uses threads or not
<wingo>would be nice if our exceptions were more structured, grumble
<peterbrett_work>For a lot of apps, multi-threaded extensions are pretty hairy
<wingo>peterbrett_work: is it the GC part of threads that's a problem or the signal handling?
<wingo>or do you want to prevent users from using threads
<wingo>like, is there any use of threads that's ok in some way?
<peterbrett_work>wingo: If you expose structures from your application as SCM values
<peterbrett_work>wingo: Especially UI related stuff
<peterbrett_work>Well — if smobs could be locked to the thread they're created on (so any access to them on other threads causes an error) then that would be neat
<peterbrett_work>Otherwise all extension writers who need to expose their values to Guile need to do $something (probably ugly) to avoid badness
<peterbrett_work>Unless *all* their data structures are already set up to be fully threadsafe (and let's be honest, mine aren't)
<peterbrett_work>I'm pretty certain my current gEDA stuff is broken in the presence of a finalizer thread
<wingo>for finalization, there is a solution described in the manual
<peterbrett_work>Take the notional scm_call_safely() libguile function for ex.
<wingo>ACTION looks
<wingo> http://www.gnu.org/software/guile/docs/master/guile.html/Foreign-Object-Memory-Management.html#Foreign-Object-Memory-Management
<wingo> http://www.gnu.org/software/guile/docs/master/guile.html/Foreign-Objects.html#Foreign-Objects
<peterbrett_work>I didn't spot that *goes to look*
<peterbrett_work>I think that for "super easy" extension writing you want to call scm_call_safely() and know that when it returns, nothing more gets done
<wingo>scm_set_automatic_finalization_enabled (0); then call scm_run_finalizers() periodically
<peterbrett_work>wingo: I notice that the smob API isn't even documented any more in 2.1+
<wingo>ah no? i think it's somewhere
<wingo> http://www.gnu.org/software/guile/docs/master/guile.html/Smobs.html#Smobs
<peterbrett_work>I think scm_manually_run_finalizers() is going to be a massive pain to schedule in a useful way. I might just insert a BIG_SCHEME_LOCK into all of the code that uses Guile
<peterbrett_work>Thanks
<peterbrett_work>For some reason my scanning the index didn't show up that page, derp
<wingo>peterbrett_work: it's not that bad. you can call it in your run loop, if you have one, or you can call it at the end of scm_call_safely or whatever.
<wingo>in gdb we call it whenever we leave guile mode
<wingo>we could of course arrange to automatically call it there, if you have automatic finalization disabled
<peterbrett_work>That sounds like it would be quite a good move, actually
<davexunit>ACTION revisits his "lexer combinator" library for the purposes of syntax highlighting
<davexunit>I definitely have some sort of data structure problem
<davexunit>I define a lexer to be a procedure of 2 arguments: a lexeme accumulator and a "cursor" of unprocessed text.
<davexunit>the return value should be the complete sequence of lexemes.
<davexunit>I tried using a persistent queue for this purpose. successful lexers would enqueue tokens, and failing lexers would return #f
<davexunit>but then I found myself wanting combinators that did things like take the most recent lexeme and transform it in some way.
<davexunit>so I guess a stack sounds better. the stack can be reversed as a final step to get the correct lexeme sequence.
<davexunit>weee using a stack seems to work well.
<daviid>wingo: hello! I'm trying to implement the multi-layout clutter example in scheme, which teaches, in C, how to proplerly subclass a <clutter-layout-manager>...
<daviid>wingo: In C, they do weird things :) The user must affect its subclass, MultiLayoutClass in this case, the folowing fields: manager_class->get_preferred_width, height and manager_class->allocate with the respective method he defined repectively
<daviid>wingo: I was hoping in scheme just have to define a method for these 3, like (define-method (get-preferred-width (self <clus-mlayout>) ...) but these are not triggered when using (layout-changed my-layout) .. I wonder what is the proper way here, do you have an idea?
<daviid>wingo: also, I think our get-preferred-width get-preferred-height, which are auto wrapped are not properley wrapped [they are out parameters, null alloed ...]
<daviid>wingo: but write now I'd be happy they would be trigerred, even raising an error
<zacts>davexunit: mark_weaver: https://vimeo.com/151465912
<zacts>^ a new talk by Gerald Sussman
<davexunit>zacts: watched it yesterday.
<davexunit>but I admit that I watched it at work on a computer that has flash (bleh). does that video work without the use of proprietary software?
<davexunit>vimeo always gives me trouble
<davexunit>ah, well you can download an mp4 to use with a free video player, at least.
<mark_weaver>zacts, davexunit: I literally just finished watching it about 10 seconds ago :)
<mark_weaver>unfortunately, youtube-dl (a version from less than a week ago) was unable to download it, so I had to use their javascript to download it.
<davexunit>aww I thought youtube-dl would surely work on vimeo. bummer.
<daviid>wingo: here a code snipset for you to play with and help me, hopefully! http://paste.lisp.org/display/305159 at the end, commented, I also wrote the code to run it ... drop the snipset in your path, ,use (mlayout) ...
<zacts>heh
<zacts>cool
<daviid>wingo: ebassi asks: can you override virtual functions in a GObject class vtable in guile [he ment guile-gnome/clutter of course]?
<bambams>zacts: \\o/
<bambams>ACTION is attempting the https://www.gnu.org/software/guile/docs/guile-tut/tutorial.html, but gnuplot is not cooperating. :\\
<davexunit>wingo: here's a query. there's a piece of software called Battlecode that's written in Java. it's a real-time strategy game where the player's, rather than using a controller, create programs of their own in Java to play the game. player's battle to see who has the better bot.
<davexunit>one of the key features to make this work is that the game can limit how many JVM ops a bot can run per "turn"
<davexunit>would it be possible to do something like this with the Guile VM?
<davexunit>limiting instructions is how the game enforces fair play.
<civodul>funny game
<davexunit>I'd love to be able to write AI battling games in Guile
<davexunit>I guess we'd need some mechanism to apply a thunk and capture a partial continuation after so many VM instructions.
<davexunit>that probably all goes out the window when Guile becomes a native code compiler
<davexunit>maybe there's a higher-level way to implement fairness
<daviid>wingo: wrt to my earlier clutter related quiz, I have a better picture now, my quiz still holds, but maybe you'll understand better,let me explai, it's going to be short :)
<daviid>wingo: so, the snipset is still good http://paste.lisp.org/+6JGN and I just created a b actor slightly bigger then a, (add-child a b) and got this warning:
<daviid>(guile:27969): Clutter-WARNING **: Layout managers of type ClusMlayout do not implement the ClutterLayoutManager::allocate method
<daviid>wingo: the warning is expected, since I did not affected/override the virtual function, but that [and others] allocate clutter [default] virtual function lands in guile as a generic function right? and I added a method so it should be called ? Any idea ... thanks