IRC channel logs


back to list of logs

***sneek_ is now known as sneek
<civodul>Hello Guilers!
<wingo>moin :)
<taylanub>おはようございます! Gotta love Emacs input methods
<civodul>wingo: speaking of Emacs, any news from bipt? :-)
<wingo>no news, but i have been absent
<dsmith-work>Is bipt doing another GSoC?
<dsmith-work>Morning Greetings, Guilers
<davexunit>I haven't seen anything saying that he has.
<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>cluck: awesome!
<cluck>relevant link:
<davexunit>thank you
<davexunit>I regret not participating in gsoc while I was in school.
<ArneBab>possibly guile 2.0.11 breaks my build of gtk-gnutella - was (if … (define …)) allowed in 1.8?
<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
<taylanub>oh, I misread that as (if (define) ...)
<ijp>in 1.8, the return value of a define is unspecified
<ArneBab>more exactly this:
<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?
<ijp>if you like
<ArneBab>I forwarded this to ram
<ArneBab>ijp: how about (define x "") (if foo (set! x "bar") (set! x "baz"))?
<ArneBab>bad because it uses mutation?
<ijp>I would prefer to put the if in the define, but this is also fine
<ArneBab>thanks again!
<dsmith-work>(re guile emacs)
<daviid>hello guilers
<davexunit>hey daviid
<wingo>heya daviid, davexunit :)
<davexunit>hey wingo. how goes the hack?
<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>daviid: yeah, perhaps.
<davexunit>interested in taking that on? :)
<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.
<davexunit>I need to learn to use guild still...
<davexunit>does that make me bad? :P
<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
<taylanub>sneek: guilemacs
<sneek>Last time I checked guilemacs is;a=summary
<davexunit>cool. :)
<taylanub>mgsk: ^
<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
<davexunit>what is the size of a gunichar?
<davexunit>16 bits?
<daviid>unsigned-int32, gunichar2 is unsigned-int16
<davexunit>(define gunichar uint32)
<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
<davexunit>oh okay. didn't realize the complexity.
<taylanub>mgsk: yup,
<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
<mgsk>I guess we'll find out
<daviid>davexunit: for info [in case you are intrested you could think of using guile-cairo too, maybe. currently guile-cairo binds the cairo 1.10.2 API]
<daviid>and ... :)
<davexunit>daviid: thanks
***cluck` is now known as cluck