IRC channel logs


back to list of logs

<paroneayea>daviid: ping
<daviid>paroneayea: pong
<paroneayea>daviid: thinking about packaging guile-gnome for guix
<paroneayea>daviid: g-wrap is interesting. Why is it used over the ffi?
<daviid>paroneayea: you'll need to package guile-cairo and g-wrap first
<paroneayea>daviid: guile-cairo is packaged!
<daviid>oh cool!
<daviid>paroneayea: which guile-cairo?
<daviid>which version?
<paroneayea>so, how many yaks to shave tonight is the question :)
<paroneayea>is this the same one?
<daviid>paroneayea: the problem is if you packaged from the tarball, it is not good enough for guile-gnome
<daviid>you need the guile-cairo from the source
<paroneayea>daviid: hmmmm
<paroneayea>why? :)
<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
<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 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
<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
<daviid>paroneayea: the 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
<civodul>howdy, wingo!
<wingo>moin :)
<ArneBab>wingo: for speeding up the compiles: do you think forcing sequential compile of the most imported modules could help?
<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?
<ArneBab>and for developers the problem only arises once (first build)
<ArneBab>the only part where it could hurt is automatic testing
<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
<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
<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.
<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 ( and your blog has informed a lot of the way I think about language implementations
<peterbrett_work>wingo: No, thank *you*
<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:
<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>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" ;)