IRC channel logs


back to list of logs

<please_help>If there's a struct { union { void* some_struct } bool bool }, then (make-c-struct (list '* uint8 uint8) (list (get-pointer) 0 0)) should make a compatible struct, right?
<nalaginrut>morning guilers~
<davexunit>hey nalaginrut
<mark_weaver>please_help: yes
***michel_mno_afk is now known as michel_mno
<amz3>héllo :)
<davexunit>does anyone know how to trace down procedures that guile doesn't give source locations for?
<davexunit>I'm looking at a statprof output where the procedure I spent the most time in percentage-wise is #<procedure 28a5100 (_ _ _ _)>
<davexunit>I have no idea how to find this
<nalaginrut>davexunit: captured as continuation?
<davexunit>I have no idea
<davexunit>I'm hunting some performance issues with Sly. statprof has been great so far, sans this issue.
<davexunit>I found a few places to optimize.
<nalaginrut>well, consider there's coroutine in sly, maybe it cause some difficult?
<nalaginrut>I couldn't think a method for that at present
<davexunit>I suspect this is in the rendering code.
<davexunit>it's where all the bottlenecks are currently
<davexunit>I doubt it's a coroutine. I don't use them for much, but they are used in the background to implement the FRP system.
***DerGuteM1 is now known as DerGuteMoritz
<lloda`>pk is what I do in these cases :-/
<lloda`>or format
<nalaginrut>davexunit: out of topic, do you think it's slow in your scheduler? and is it possible to schedule 10000+ objects in sly?
<kristofer>good morning
<davexunit>sneek: later tell nalaginrut the scheduler surely can be optimized to allocate less, but I don't think it's the culprit. also, the scheduler isn't used on a per game object basis. 10,000 is a big number, if all of those objects changed every frame then Sly couldn't keep up.
<please_help>so if I want an array of structs of { union {...} bool bool } I have to go with bytevectors and manual packing?
<davexunit>maybe with better persistent data structures I could handle updating more objects per frame, but persistence is a strong requirement in Sly, and I'm comfortable with not being able to handle massive amounts of moving objects in order to keep it.
<davexunit>please_help: yes
<davexunit>I'd like to see an agreed upon interface for packed structs make into core guile
<taylanub>please_help: you might want to look into
<davexunit>I've seen several special-purpose implementations in other people's code at this point.
<davexunit>guix, guile-opengl, etc.
<taylanub>BTW I'm waiting for someone to tell me "that README's intro is absolutely unreadable" so I can sit down and rewrite it :)
<please_help>meanwhile, anything particularly wrong with (list->typed-array 'u64 1 `(,(tensor-ptr idx-tensor0) ,(+ (ash 0 16) (ash (tensor-ptr idx-tensor1) -16)) ,(+ 0 (ash (- (tensor-ptr idx-tensor1) (ash (ash (tensor-ptr idx-tensor1) -16) 16)) 16))) assuming (tensor-ptr) gives the pointer address that's a union member?
<taylanub>that seems highly unreadable to me. maybe let-bind several of the values first?
<taylanub>also there's a procedure called 'u64vector' in SRFI-4 with which you can construct those vectors: (u64vector first-u64 second-u64 ...)
<taylanub>(hm, actually not sure if this is the same type of "typed array" as in SRFI-4)
<davexunit>I moved away from using the array interface for performance reasons
<taylanub>yes, seems to be the same.
<davexunit>moved to regular bytevectors instead
<taylanub>anyone who uses bytevectors a lot, can you tell me whether it's more often for you to work with bytestructures with a fixed layout, or some "protocol" in which e.g. initial bytes determine the length of an upcoming field, etc.? the latter *might* be supported by my bytestructures code, but it's limited by the fact that bytevectors themselves are fixed-length, so recently I thought of allowing
<taylanub>binary ports as the "backing store" behind a bytestructure in addition to bytevectors
<please_help>I'm trying to pack a void* address (64-bit) followed by 2 bools (8 bits each) twice, so I do [pointer0] [bool0 bool1 [last 48 bits of pointer1]] [first 16 bits of pointer1 [bool2 bool 3]]
<please_help>somehow doesn't work and I think it's because of my packing, but not sure.
<taylanub>some advertisement:
<please_help>taylanub: it looks like guile doesn't like .sld files: ;;; WARNING: compilation of ./bytestructures/r6/standard.scm failed:
<please_help>;;; ERROR: no code for module (bytestructures r7 standard)
<please_help>also the directory name is unfortunate given the package is referred to as "bytestructures" and not "scheme-bytestructures" internally.
<taylanub>a git-repository directory's name can be changed without problems. and I totally forgot I don't have any compatibility shims for Guile here :( I wrote this a long time ago where R7RS support was already "nearing completion" but then it stalled unfortunately.
<taylanub>if you want to use it, I can make a Guile-specific version
<taylanub>it should be sufficient to create files like base.scm, simple.scm, etc. in the guile directory, which include the .body.scm files from ../r7
<taylanub>(I could put all the .body files into a directory of their own, too)
<taylanub>please_help: I'll port it in any case. I should be done in a couple hours if nothing gets in my way, you can use it then if you want.
<dsmith-work>Morning Greetings, Guilers
<taylanub>*sigh* R6RS has no include, and no cond-expand so that I could import some Guile module that has include. supposedly one can implement it with syntax-case, but I fear it's nontrivial to get relative paths right. I like many aspects of the R6RS, but the library system is a botch. :(
<taylanub>and when I unconditionally import (guile) and use include, it still errors because "a relative path is only allowed if the include appears in a file" :\\ I think I'll just drop R6RS support.
<davexunit>so, I'm working on particle simulations with Sly again, and I'm looking for hacks to make a purely functional model allocate less memory.
<davexunit>I thought of something that might be worth looking into, but might also be too "clever" a.k.a. nonsensical
<davexunit>rather than allocating tons of record type instances, use a packed vector with a max number of particles.
<davexunit>making a new one is allocating from the pool and returning the index
<davexunit>then of course something needs to GC the dead ones, but it's a simulation I have tight control over and can easily determine the live vs dead particles.
<davexunit>single threaded application, so no worries about mutexes and things for accessing and modifying the pool.
<please_help>So actually that was wrong! The correct way to pad when a union is present is to the largest size of the elements in the unions.
<davexunit>oh it was a union! I somehow missed that detail
<please_help>As for an array of structs containing unions, there seems to be some sort of alignment spec on AMD64, and elements in the array seem to align to the closest multiple of 64
<please_help>not sure if I'm getting that right and if it's arch dependent, can someone confirm?
<davexunit>I can't confirm. maybe someone else can.
<davexunit>sounds plausible, though.
<please_help>Eitherway, thanks for the help so far. Didn't get to try bytestructures though, too bad.
<davexunit>we really need something in guile core for this stuff. I hope someone with both the time and know-how is reading this right now ;)
<please_help>like taylanub ;)
<davexunit>a define-record-type style syntax for foreign structs would be so awesome.
<taylanub>please_help: I'm almost done. :)
<taylanub>please_help: sorry for advertising when it wasn't even in a working state
<taylanub>the test suite is about to pass again but I'm facing an incredibly weird bug now:
<taylanub>I tested the guile modules many times before and never faced such a thing. using the stable 2.0.11 release too.
<taylanub>amazing .. I changed the (0 1 2) to (0 1 2 3), and now it prints (0 0 0 3) O_o
<please_help>taylanub: #bla(things...) syntax doesn't actually create a new array. If something is writing to an array created in this way and you have another variable bound to the same symbol, both will be overwritten.
<please_help>also, why not use srfi-64?
<please_help>also, I say "will" but it's actually "might".
<taylanub>please_help: thanks, that pushed me in the right direction. instead of copying the given bytevector into a freshly created one, I was copying a freshly created one into the given bytevector, and Guile doesn't prohibit writing to bytevector literals yet!
<taylanub>*sigh* R6RS and R7RS disagree on the argument order of bytevector-copy! >_<
<taylanub>(equal? #u8(0 42) #vu8(0 42)) => #f oh dear
<taylanub>can't believe there were this many unsolved issues in this library, I remember having tested it to death a while back, but I guess I made some innocent-looking changes since then which broke a lot of stuff after all
<taylanub>I blame the RnRS :P
<taylanub>please_help: oh and to answer your question: I didn't know much about SRFI-64 back then. will certainly make a better test suite some time.
<taylanub>please_help: I pushed my changes, please notify me re. any issues, questions, etc. :)
<please_help>will do
<please_help>;;; compiling ./bytestructures/bytevectors.scm
<please_help>;;; <unknown-location>: warning: possibly wrong number of arguments to `bytevector-copy!'
<please_help>also ;;; ERROR: In procedure open-file: No such file or directory: "./bytestructures/guile/./bytestructures/body/base.scm"
<taylanub>the former is a harmless Guile bug; it thinks an R6RS library clause is a function call
<taylanub>hmm, did you add the parent directory to GUILE_LOAD_PATH?
***michel_mno is now known as michel_mno_afk
<please_help>I added the directory containing bytestructures to the load-path, otherwise modules typically don't load without installing onsite.
<taylanub>please_help: what guile version are you using?
<taylanub>ACTION goes AFK for ~30 minutes
<please_help>I'm on 2.0.11
<taylanub>me too :\\
<taylanub>in my case, it prints an absolute path when it says ;;; compiling ...
<taylanub>please_help: how exactly are you trying to import it? in my case, I just start guile with a GUILE_LOAD_PATH that includes ~/src/scheme under which the repo resides, then ",use (bytestructures guile)"
<please_help>I use (use-modules (bytestructures guile))
<taylanub>that works for me as well
<taylanub>please_help: does your load-path perhaps have "."? (although that should be fine too I imagine)
<please_help>I use guile -L . so yes, my loadpath has .
<taylanub>please_help: I can reproduce with -L, and I'm guessing this might be a bug in Guile
<taylanub>I'll send a bug report
<davexunit>interesting work from jcowan on #scheme:
<davexunit>"ephemerons" are a data type that can be used to construct things like weak key hash tables
<taylanub>they're from MIT/GNU Scheme AFAIK
<taylanub>well, I know them from there, at least
<daviid>would you name grip tools/toolbox for clutter grip-clutter or clutter-grip ?
<daviid>davexunit: ok, tx
<davexunit>er, wait
<davexunit>whatever is the "dominant" tool
<davexunit>is the grip integreation to clutter
<davexunit>or clutter integration to grip
<daviid>davexunit: grip clutter is on top of clutter, providing classes, methods and functions to help potential users to build app using guile-clutter + grip-clutter or clutter-grip
<taylanub>I finally reworked the readme:
<davexunit>I'm still confused, sorry. just name it what you think it should be named. you know better than us. :)
<daviid>bah, I don't know :)
<davexunit>ACTION wonders how Guile's use of the Boehm GC stacks up with Ruby's new GC
<daviid>from english point of view, a clutter grip of really important procedures sounds better. but from file system point of view, I'd have all grip toolboxes grouped if named grip, grip-clutter [like grip-1.0.pc, grip-clutter-1.0.pc ...] hence my hesitation
<davexunit>I just upgraded a web application from ruby 1.9.3 to 2.2.3 and saw a *huge* improvement
<daviid>sorry with these ot quizz, but i'd rather have these names proper from the beginning
<davexunit>~45ms in GC per request vs 3ms now
<daviid>rotty1: I have a g-wrap/ 'mecanic' related quizz/problem, hope you can help me :)
<daviid>running over clutter 1.12.2, it should parse /1.12/include/clutter-1.0/clutter/clutter-color.h which defines
<daviid>typedef struct _ClutterParamSpecColor ClutterParamSpecColor;
<daviid>but that does not land in our clutter-types.defs, I wonder why?
***cluck` is now known as cluck