IRC channel logs

<daviid>the tarball is 3 or even 4 y old, and source were patched to produce guile-clutter 1.10, then guile-gnome has been patched to deal with that cairo, which unfortunately has never been released

<mark_weaver>paroneayea: guile-gnome doesn't use the dynamic FFI because it long predates the FFI

<mark_weaver>if we doing it again today, we would use the FFI.

<paroneayea>mark_weaver: got it

<daviid>so you have guile-cairo 1.9.x, guile-gnome and guile-clutter need 1.10, which 'does not exists yet' as a release, but the source tree ...

<paroneayea>ACTION wonders, maybe this is too many yaks deep to shave tonight :)

<daviid>paroneayea: if it helps, I could produce a non official guile-cairo tarball and uploaded somwhere

<daviid>yes for tonight it will be difficult for me too. but you can start to work on g-wrap in parallel

<daviid>g-wrap just depend on guile

<daviid>]and its tarball is uptodate http://www.nongnu.org/g-wrap/

<daviid>I'll try to produce a non official guile-cairo-1.10.0-dev.tar.gz if helps, but it's just checking the source, bumping the number and make dist really

<daviid>paroneayea: it is really nice that you are working on this, I'm sorry about this little difficulty wrt guile-cairo, here https://www.gnu.org/software/guile-gnome/download.html you see I wrote this comment about it "Note that at the time we write, Guile-Cairo 1.10 has not been released yet, it will hopefully soon be the case. In the mean time, the required bleeding edge Guile-Cairo stable version must be obtained from the source, see

<daviid>here."

<paroneayea>daviid: I have experience building from git

<paroneayea>in guix

<paroneayea>so the other reason I was thinking of doing this

<paroneayea>was gecause I need to get my password manager (assword) working in guix

<daviid>paroneayea: it is written in guile-gnome?

<daviid>I'm lost :)

<paroneayea>sorry I stepped afk

<paroneayea>no it's in python

<paroneayea>but I was having trouble getting some of the deps working

<paroneayea>dependencies

<daviid>paroneayea: the configure.ac of the source tree [guile-cairo] still says 1.9.91, for info, which is why I also left, till now, both checks [guile-gnome and guile-clutter] 'accepting' >= 1.9.91, but using it would raise errors, unless the installed/packaged version comes from the source tree

<paroneayea>so I thought "maybe I should just add the feature I need from assword to davexuni` 's haunt package", but that would require adding a little gtk popup and the ability to type in to whatever window the password via xdo

<paroneayea>but I think that it looks like this will be a similar situation re: getting deps working for that feature, plus it'll mean adding a new feature :)

<paroneayea>so I think I'll just get assword packaged for now

<paroneayea>once I have assword installed

<paroneayea>I can start using guixsd regularly

<paroneayea>instead of using debian so much

<davexunit>paroneayea: ;)

<davexunit>yeah just package assword.

<davexunit>shroud can be improved at a later date, perhaps never. ;)

<paroneayea>its future is shrouded in mystery! ;)

<daviid>ok, but it would really be nice if a guix guy packages guile-gnome and guile-clutter [which is more complicated by the way, becaue it depends on specific [old] cogl and clutter versions]

<mark_weaver>paroneayea: I'm going to rename the linux-libre-4.2.5 variable to linux-libre-4.2, okay?

<mark_weaver>the reason is that it should always refer to the latest 4.2.x. Only safe bug fixes are applied to that branch, so I don't anticipate that anyone would want to refer to 4.2.5 specifically.

<mark_weaver>hmm, actually, it looks like there will never be a 4.2.6 because that branch is no longer supported. better go back to 4.1.x. instead.

<mark_weaver>paroneayea: did anyone review that patch? (the one adding linux-libre-4.2.5)

<paroneayea>mark_weaver: go for it (renaming)

<paroneayea>and yes civodul reviewed it

<paroneayea>on the bugs list

<nalaginrut>morning guilers~

<artyom-poptsov>Good morning, nalaginrut

<nalaginrut>heya

<wingo>mooo

<civodul>howdy, wingo!

<wingo>moin :)

<ArneBab>moin

<ArneBab>wingo: for speeding up the compiles: do you think forcing sequential compile of the most imported modules could help?

<nalaginrut>heya

<wingo>ArneBab: i think ordering the worklist can help, but forcing serial (not parallel) compilation doesn't help

<wingo>anyway for the bootstrap case i think the fix we discussed a few days ago will work fine

<wingo>and it will make these considerations moot

<ArneBab>including the *.go files?

<wingo>yes

<ArneBab>and for developers the problem only arises once (first build)

<ArneBab>the only part where it could hurt is automatic testing

<wingo>bloggies: https://wingolog.org/archives/2016/01/19/unboxing-in-guile

<davexunit>yay!

<davexunit>wingo: unrelated, but I got the networking guy I work with pretty excited about the snabb switch via your blog post about pflua

<wingo>neat :)

<wingo>snabb is fun

<davexunit>wingo: also you are on lwn front page today http://lwn.net/Articles/672404/

<wingo>woo

<davexunit>I've been thinking about how to rewrite my 4x4 matrix manipulation code to take advantage of the unboxing optimizations

<davexunit>the new blog post touched on something I was thinking about regarding using a packed bytevector of f32s or a vector of floats

<davexunit>right now I use packed bytevectors and have GSL do the (currently expensive) multiplication

<davexunit>using packed bytevectors has the very nice advantage that I can store the matrix in the exact format that OpenGL wants

<davexunit>so I can pass a matrix off to a shader without having to allocate each frame

<wingo>yep

<davexunit>with the disadvantage that everything is f32s. no exact number matrix ops.

<wingo>is exactness important to you?

<wingo>usually you're dealing with inexact reals, no?

<davexunit>depends on the layer of the application. when rendering, exactness is not important.

<davexunit>if I were to use matrices in the higher level purely functional part, it would be nice to use exact math where possible.

<davexunit>but exactness is still thrown out the window once you introduce any trigonometry

<davexunit>which is often. so I should probably just not worry about it.

<davexunit>but I still mourn the lack of precision in the situations where I could have had beautiful exact numbers

<wingo>yeah i get that too at times. for me though, f64 values are pretty good, and if you need different kinds of values you can parameterize your data structures in some way

<wingo>so starting from concrete precisions isn't all bad

<daviid>hello guilers!

<davexunit>wingo: maybe I should go from f32s to f64s, as well.

<wingo>davexunit: the down-side would be that the gpu probably doesn't do doubles. you can of course copy from one to the other, that doesn't box

<davexunit>wingo: I believe the GPU does doubles.

<davexunit> https://www.opengl.org/wiki/Data_Type_%28GLSL%29#Scalars

<wingo>they can specify whatever they want :) whether your gpu does it and does it well is a different question

<davexunit>sure :)

<peterbrett_work>wingo: I enjoyed your blog post — thank you

<davexunit>I should ask my fellow OpenGL programmers what they use and for what reasons

<wingo>tx for kind words :)

<peterbrett_work>wingo: I work on a GPL compiler/VM at $dayjob (https://github.com/livecode/livecode) and your blog has informed a lot of the way I think about language implementations

<peterbrett_work>wingo: No, thank *you*

<wingo>neat!

<davexunit>wingo: another common GL thing for me to do is destructure a <vector{2,3,4}> record type (my data types for vector math) and use glUniform{2,3,4}f to pass them to a shader. I don't actually know how much boxing kills me there, but I imagine it hurts.

<davexunit>retrieve fields from struct, convert values to floats, pass to glUniform*f

<davexunit>is there a chance that the unboxing optimizations take care of the allocation for that float?

<davexunit>(glUniform2f location (vx v) (vy v)) where v could be like (vector2 1 2)

<davexunit>and 'location' doesn't matter right now.

<wingo>davexunit: currently there's no support for unboxed struct fields. you have to use a bytevector somehow for unboxed data at rest.

<davexunit>wingo: I'm not worried about the vectors themselves, but the transition between being in a vector and being sent to the OpenGL library as a float.

<ArneBab>generators just got finalized — should come in handy to save memory: http://srfi.schemers.org/srfi-121/srfi-121.html

<ArneBab>wingo: could the compiler give warnings when it detects heavy boxed use of unboxed values?

<ArneBab>(optimization information is something I envie my matlab using collegues for)

<wingo>evening

<wingo>ArneBab: it could i guess, i don't know much about that tho :)

<ArneBab>a challenge with that could be to keep it synchronized with the actual performance of the compiler

<wingo>yeah i wouldn't want to do that right now

<wingo>it might as well just say "warning: the compiler is a work in progress" ;)

<ArneBab>☺

IRC channel logs

2016-01-19.log