***sneek_ is now known as sneek
<taylanub>おはようございます！ Gotta love Emacs input methods <civodul>wingo: speaking of Emacs, any news from bipt? :-) <wingo>no news, but i have been absent <cluck>dsmith-work: according to melange it would seem so <cluck>Guile-Emacs - Robin Templeton - Organization: GNU Project - Assigned mentors: Andy Wingo - Short description: Complete the integration of Guile and Emacs. <davexunit>I regret not participating in gsoc while I was in school. <taylanub>I think I've heard of that issue before (`define' returning something useful in 1.8 or so) <ArneBab>that seems to be in files generated by autogen <ijp>you can define in an if in 1.8 <ijp>in 1.8, the return value of a define is unspecified <taylanub>I was dreaming then. (nightmares, to be exact) <ijp>this change was covered in NEWS <ijp>(2.0) ** Guile is now more strict about prohibiting definitions in expression contexts. <ArneBab>awww, wait, the license header for the other files states that *they* are autogenerated - not the template itself. <ijp>there are two easy ways to fix it <ijp>(if foo (define x bar) (define x baz)) -> (define x (if foo bar baz)) <ijp>or (define x bar) -> (module-define! (current-module) 'x bar) <ArneBab>may I just quote you for #gtk-gnutella? <ArneBab>ijp: how about (define x "") (if foo (set! x "bar") (set! x "baz"))? <ijp>I would prefer to put the if in the define, but this is also fine <daviid>wingo: davexunit woh, party time :) <daviid>so much to do! lot's of fun hacking but time is running, as ever... :) <davexunit>daviid: I hear ya, things are always so busy <mgsk>So this GSoC guile emacs business... is that code in a public-facing repo? <daviid>davexunit: in wrappers/utils you (re)define define-enumeration, but is it not in guile? (rnrs enums (6)) <davexunit>daviid: oh, I haven't checked. I took the macro from guile-opengl, actually. but I should remove it because I can just import it from guile-opengl. <daviid>davexunit: i also thought that freeimage could become guile-freeimage ... with time :) <davexunit>I wasn't interested in wrapping the full API. <davexunit>on my "high priority" list is guile-sdl2. I want to wrap up a 0.2 release of guile-2d (under a new name), apply to be a GNU project, and then write an SDL2 binding. <daviid>then also thought it would be nice to have a guile-colour 'package' because I am rewritting guile-clutter examples [in a much better way then I did in the past] and of course also have a colour.scm file very similr to yours... <davexunit>it might be worth it to make a library just for dealing with colors. <davexunit>for me, the problem right now is that the more guile dependencies a project has, the harder it is for users to install. <daviid>davexunit: right now I concentrate on guile-gnome and guile-clutter, and it takes all my free time [almost :)] <lloda>is there something like string-split that doesn't discard the separators? <daviid>davexunit: I think we should join our efforts, whenever possible, then resolve install 'problems' latter, using guild <davexunit>because those libraries are rarely in the package manager, and the guildhall isn't widely used. <daviid>davexunit: so do i, i just do the basic, but the question is not to rewriter everytime in our corner... oh well you know of course <davexunit>daviid: guile-gnome and guile-clutter are important projects. <davexunit>perhaps guile-wm could take advantage of guile-clutter to make a pretty window manager <daviid>davexunit: yes they are very important, imo. i really hope to get better and faster with time, then get guile-clutter up to the latest... <daviid>I'm slow now, learning by doing... but I feel better every day of course <davexunit>maybe we should organize a way for guilers to peer-review each other's code easily? <davexunit>a lot of us maintain projects that no one else really looks at besides ourselves, most of the time. <daviid>i need help with wrapping double* [for guile-clutter], gunichar* and gunichar2* [guile-gnome], i just could not find out how to do it properly so far. i'll send a [1 more] patch for guile-gnome devel branch in a short and request help with these two <taylanub>davexunit: something improving on the method of sending patches to the ML? <daviid>davexunit: I send message to guile-devel and ask for review, as you know: it is the best way in my opinion, just have to wait people get interested or find some time... <davexunit>taylanub: I think that works well for certain things, but I guess I'm thinking of something more broad. <davexunit>like periodically perusing someone's codebase and giving general feedback about what you feel code be improved. <daviid>the problem for me is there are very few guilers aware of g-wrap, guile-cairo, guile-gnome and guile-clutter <daviid>anyway, let's work :) but keeping the guile-colour lib i mind, as I'll push guile-clutter examples i'll let you know... [I use goops though] <davexunit>daviid: I wasn't aware of those until recently :) <mgsk>taylanub: that hasn't been touched since 2013. I thought it was accepted into this years summer of code? <davexunit>daviid: goops is okay, but for a small color helper library, I would prefer to avoid it. <daviid>davexunit: [re-reading your phrase about new guile-2d and sdl2...] I also develop/maintain Kisê and also would like it to become a GNU project. for that it's lacking a couple of things still: using autotools is the main one <davexunit>daviid: do you have a link to kise's homepage or repository viewer? <daviid>davexunit: goops is unavoidable, it is at the kernel of guile-cairo, guile-gnome and guile-clutter bindings, very fortunately imo! <davexunit>daviid: I think it's fine for those things, but for certain data types it's unnecessary. <daviid>i understand what you mean, but someone using guile-clutter should manipulate colurs just he/she does for <clutter-actor> and sol forth... changing programming paradigm just for colours may not be the best idea i think <daviid>but anyway, let's see in the future <davexunit>we all have different needs and preferences. <daviid>right now I need someone to tell me how to wrap gunichar*, anyone :) ? <davexunit>the gift/curse of scheme is that we can have them all. <davexunit>daviid: that can probably be represented using the existing primitive C types in (system foreign) <daviid>davexunit: yes. and maybe we can even provide guile-colour with the choice of the 2 paradigm: struct or goops <daviid>unsigned-int32, gunichar2 is unsigned-int16 <daviid>davexunit: oh, far more complicatd then that, it's using g-wrap... fyi, here is the unpatched version [misssing gunichar2] but you can see no specific special wrapper for gunichar* where it needs one. g-wrap only has mchars, pointer to char, as you can see it works for gchar*, but when I add-type-rule! for gunichar* as for gchar*, obviously the compiler sends casting pinter warnings... and I'ld like no warningsa at all <daviid>save your time for now, but thanks for the intention! I'll send a patch and email to guile-devel soon with a proper explanation... for someone familiar with g-wrap it should only take a couple of minute to answer <taylanub>mgsk: but I haven't heard anything from bipt yet, and no new commits as you mentioned although half of the "coding period" is done :\\ <mgsk>Unless bipt just hasn't committed his/her work ***cluck` is now known as cluck