IRC channel logs


back to list of logs

<daviid>mark_weaver: the download button, then the devel release.. I got this error
<daviid>The site at “” seems to be unavailable. The precise error was: URL cannot be shown [using epiphany]
<mark_weaver>hmm, works for me
<mark_weaver>well, works for me with GNU IceCat. it doesn't work in Epiphany for me either.
<mark_weaver>I guess maybe epiphany doesn't support ftp
<mark_weaver>anyway, I have to go afk for a bit!
<daviid>mark_weaver: ok tx
<mark_weaver>daviid: are you using epiphany from Guix or on another system?
<daviid>mark_weaver: debian
<mark_weaver>okay, thanks
<daviid>i guess it does not support ftp as you said
<daviid>wingo: if you prefer I can send a bug report with this:, let me know
<daviid>wingo: did you find any time to look at the guile-gnome segfault problem:
***karswell` is now known as karswell
<dsmith-work>sneek: seen rotty?
<sneek>rotty was here Oct 21 at 07:17 am UTC, saying: daviid: should not run configure, that was a mistake.
<dsmith-work>daviid: There ya go ^^
<daviid>dsmith-work: thanks!
<daviid>I wish rotty would be here more often, and hope he's fine
<davexunit>ACTION needs to learn the finer points of reading guile 2.2 disassemblies
<davexunit>I have a 550 line long disassembly that I'm groveling to find low-hanging fruit for optimization
<kristofer>any guidance for generating audio with guile?
<amz`>héllo :)
<daviid>hello guilers!
<davexunit>wingo: I'm staring at a statprof report of one my applications, and the second most time consuming procedure is named "anon #x7f2cfac2ca8c". is there any way for me to find out *where* this mammoth lives, or am I up a creek?
<wingo>davexunit: it's possible but if statprof doesn't tell you a source line, it can't find it, i think
<wingo>(use-modules (system vm debug))
<davexunit>wingo: just importing the module is enough to enable the extra debugging facilities?
<wingo>(define pdi (find-program-debug-info #x7f2cfac2ca8c)
<wingo>then use program-debug-info accessors on that pdi
<wingo>you can try (find-source-for-addr ...) as well
<wingo>might not work tho
<davexunit>wingo: I'll give that a shot, thanks.
<wingo>davexunit: other possibility, use ,statprof foo #:display tree
<wingo>it can at least tell you how it got to that procedure
<davexunit>on a related note, is there a way to determine the *slowest* procedure? for all I know, this procedure is fast but just called a ton of times.
<davexunit>wingo: thanks! that will be a big help, I think.
<wingo>good luck :)
<davexunit>the procedure that is taking up the most time is one that I can't find ways to optimize further. I'm calling it ~42000 times per second.
<wingo>how many callers does it have?
<davexunit>in this particular program: 1.
<davexunit>the procedure in question is a public procedure in a module.
<davexunit>full context: it's a sprite batch renderer, and I'm currently rendering ~700 dynamic sprites at 60FPS
<davexunit>so it might just be that this is as fast it gets for now.
<wingo>you could use define-inlinable on the procedure
<davexunit>perhaps this anon procedure will have some low hanging fruit.
<wingo>see what that gives you
<davexunit>wingo: yeah, I'll give that a try.
<davexunit>I was reading the disassembly trying to find things that looked fixable.
<wingo>yay :)
<wingo>that's what i do too sometimes
<davexunit>adding a sprite to the batch involves 20 f32vector-set! calls and 6 u32vector-set! calls
<davexunit>6 u32s for indices, 12 f32s for vertices, and 8 f32s for texture coordinates.
<wingo>at least you're getting some unboxing, i guess
<davexunit>doesn't seem to be. I see scm->u64 and scm->f32 instructions.
<davexunit>which I imagine is because I am not copying from one bytevector to another
<davexunit>I have a rectangle record type that the vertices are pulled from
<wingo>one possibility (dunno if good idea or not) would be to have the record hold a bytevector
<wingo>and store the packed data in the bytevector
<wingo>we really need compiler support for unboxed fields tho :P
<davexunit>I thought of this, but the issue is that these rectangles are dynamic.
<davexunit>so they change every frame as the objects that represent these sprites move around.
<davexunit>and I've chosen to *not* use mutable state for the simulation.
<davexunit>maybe creating a bunch of packed bytevectors would still be a win.
<davexunit>I haven't tried.
<wingo>ACTION dunno
<davexunit>I have a larger issue of fighting GC pressure
<wingo>it would probably mean that you need less allocation when creating these bytevectors, and you would have faster uses of the coordinates because monomorphism
<davexunit>if I were writing this particular simulation in an imperative manner, I would just pre-allocate a big bytevector to use as an object pool.
<davexunit>wingo: it's worth exploring. the same might apply for my vector types, but I worry about losing exactness by forcing everything to be floats.
<wingo>do you ever use rationals?
<wingo>that would be a significant source of slowness
<davexunit>yeah sometimes
<davexunit>well I guess I could force everything to be f32s.
<davexunit>that could solve arithmetic slowness, but the GC pressure will remain.
<wingo>or f64, for your game objects
<wingo>the gc pressure would be different tho
<wingo>because you would have fewer objects and fewer edges for gc to trace
<davexunit>wingo: is it safe to try to shove f64s into an f32 bytevector later?
<davexunit>for rendering, I use f32s.
<wingo>davexunit: perfectly safe
<wingo>i mean
<dsmith-work>Happy Friday, Guilers!!
<wingo>to the extent that floating-point is safe at all :)
<davexunit>wingo: would you wrap the bytevectors in a record type?
<davexunit>wingo: :)
<davexunit>I like having my rect?, vector2?, vector3?, etc. predicates.
<wingo>davexunit: if you want type-safety, yeah.
<davexunit>it's another allocatin
<wingo>i think the right sol'n is compiler support for unboxed fields
<davexunit>struct + bytevector
<wingo>yeah, but that's just like struct + heap float
<wingo>so you can't lose
<davexunit>if that's a future possibility, then I will implement using a wrapped struct
<wingo>yeah compiler support for unboxed fields will be a thing eventually
<wingo>at least for u64/s64/f64 values
<davexunit>as you probably know, I'm perfectly willing to accept current slowness when there's hope on the horizon for optimization later.
<davexunit>wingo: so assuming this optimization existed, would I still want to pack things into a bytevector?
<davexunit>seems like I wouldn't.
<wingo>davexunit: no.
<davexunit>I'll be a good boy and try to make sure that the bytevector doesn't get exposed publicly in my APIs then.
<wingo>the bytevector thing is just a way to get closer to the performance of this optimization
<davexunit>so when unboxed fields rolls around, I can just change the implementation without breaking interfaces.
<wingo>the inner morality of programs
<davexunit>do you think it's crazy to want a custom allocator to avoid GC pressure?
<daviid>wingo: hello! compiling guile-gnome against 2.1.2 (the release tarball, for info I couldn't compile guile latest master) gives me 2 probs
<davexunit>you could consider my program to be a particle simulation, and a typical technique for making it fast is to use a pre-allocated object pool in contiguous memory.
<wingo>davexunit: dunno :) i still think you want generational gc :)
<davexunit>the trick for me is that I must retain the purely functional semantics.
<davexunit>wingo: perhaps! I ask because I'm not sure what I actually want.
<davexunit>I just know I want faster.
<daviid>the first is g-wrap related: ;;; compiling /opt2/share/guile/site/g-wrap/util.scm g-wrap/util.scm:86:11: warning: possibly unbound variable `gw-handle-condition'
<davexunit>wingo: is generational GC even a realistic possibility for Guile?
<daviid>wingo: there is a circular deps between gwrap.scm and utils/g-wrap.scm the latest doing: #:autoload (g-wrap) (gw-handle-condition)
<davexunit>wingo: anyway, I think I've used up all my wingo coins for one day. thank you very much for all of the helpful advice.
<wingo>daviid: is a warning, a problem?
<daviid>not really but I wanted to get rid of it, why not
<wingo>davexunit: generational gc is a possibility yes
<daviid>the second is a bug
<daviid>gnome/gw/support/glob.scm:117:15: gnome/gw/support/glob.scm:117:15: Value out of range 0 to 18446744073709551615: -1
<daviid>this glob.scm is written in 1998 by Radey Shouman... I can dig but I think you will find out so much quicker then I ...
<daviid>wingo: here is a more complete report:
<wingo>looks like a miscompilation
<daviid>wohh, is it bad doctor? :)
<daviid>by the way, g-wrap raises a bunch of guile reated deprecated msgs, I'll see what I can do
<daviid>then we really should compile and install compiled modules for guile-cairo, g-wrap and guile-gnome [guile-clutter], quite a work but worth it
<rain1>is the guile-cairo thing still an issue?
<rain1>where the release was too old
<wingo>i get the same bug with (define (qux str k) (let lp ((kk (string-length str))) (and (>= kk k) (lp (1- kk))))
<wingo>if you run it with (qux "foo" 0) you get this error
<daviid>wingo: yes
<daviid>rain1: it is if you use the tarball, you have to clone guile-cairo for now
<rain1>why don't i modify the guix package to point of the latest commit?
<davexunit>hmm the 'statprof' procedure doesn't support the #:display argument
<davexunit>running this code from the REPL is inconvenient because it's an event loop
<davexunit>wingo: counting calling with statprof doesn't seem to be working with 2.1.2, not sure yet if this is also the case in 2.0.x
<daviid>wingo: ping me when you'll have fixed the above, I'll jump on something else for now
<davexunit>or, at least, the printed output doesn't show the calls, despite there being a column for the calls.
<davexunit>call counts, that is.
<daviid>wingo: if you could look at bug#20093, and fix it, that would be awesome
<wingo>any analysis of variance implementations in guile?
<wingo>ACTION tries to avoid r
***Fuuzetsu is now known as Guest12807
***sbp_ is now known as sbp
***ft_ is now known as ft
<rain1> this is a nice piece of code
<rain1> I found this too
<rain1>what about having a graph library for guile?
<amz3>thx, rain1 it's a library i've written
<amz3>everything is possible
<amz3>rain1: why are you interested in graph?
<rain1>I'm writing some more graph routines
<rain1>it seems a shame if all the work is not kept together, then people will rewrite it
<amz3>what is your goal?
<rain1>right now its just a test program to color graphs
<amz3>ah ok
<rain1>I have another program that uses graphs I might port at some time
<amz3>I used a graphdb to create a social network, I really like graph/graphdb
<amz3>a social network webapp
<mark_weaver>from my perspective, the problem with adding a standard graph library is that I don't know of a single best representation for graphs, especially if one wishes to avoid mutation.
<rain1>that's true, I'm using assoc lists, amz3s code uses a mutable hash table -- and there are lots more advanced structures
<rain1>maybe it could be one library with several submodules
<amz3>yes, there is many representation of graphs
<davexunit>yeah, something for which there's a plethora of possible implementations is probably not the best thing to include in the core
***mario-go` is now known as mario-goulart
***heroux_ is now known as heroux