<daviid>mark_weaver: the download button, then the devel release.. I got this error <daviid>The site at “ftp://alpha.gnu.org/gnu/guile/” seems to be unavailable. The precise error was: URL cannot be shown [using epiphany] <mark_weaver>well, works for me with GNU IceCat. it doesn't work in Epiphany for me either. <mark_weaver>daviid: are you using epiphany from Guix or on another system? <daviid>i guess it does not support ftp as you said ***karswell` is now known as karswell
<sneek>rotty was here Oct 21 at 07:17 am UTC, saying: daviid: autogen.sh should not run configure, that was a mistake. <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? <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>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. <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>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. <davexunit>I was reading the disassembly trying to find things that looked fixable. <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 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>that would be a significant source of slowness <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? <wingo>to the extent that floating-point is safe at all :) <davexunit>wingo: would you wrap the bytevectors in a record type? <davexunit>I like having my rect?, vector2?, vector3?, etc. predicates. <wingo>davexunit: if you want type-safety, yeah. <wingo>i think the right sol'n is compiler support for unboxed fields <wingo>yeah, but that's just like struct + heap float <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>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. <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>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>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>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. <daviid>wingo: if you could look at bug#20093, and fix it, that would be awesome <wingo>any analysis of variance implementations in guile? ***Fuuzetsu is now known as Guest12807
***sbp_ is now known as sbp
***ft_ is now known as ft
<rain1>what about having a graph library for guile? <amz3>thx, rain1 it's a library i've written <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 <rain1>right now its just a test program to color graphs <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 <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