<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? ***michel_mno_afk is now known as michel_mno
<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'm hunting some performance issues with Sly. statprof has been great so far, sans this issue. <nalaginrut>well, consider there's coroutine in sly, maybe it cause some difficult? <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 :-/ <nalaginrut>davexunit: out of topic, do you think it's slow in your scheduler? and is it possible to schedule 10000+ objects in sly? <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>I'd like to see an agreed upon interface for packed structs make into core guile <davexunit>I've seen several special-purpose implementations in other people's code at this point. <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>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. <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. <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? <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 ;) <davexunit>a define-record-type style syntax for foreign structs would be so awesome. <taylanub>please_help: sorry for advertising when it wasn't even in a working state <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. <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>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>;;; <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>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)" <taylanub>please_help: does your load-path perhaps have "."? (although that should be fine too I imagine) <taylanub>please_help: I can reproduce with -L, and I'm guessing this might be a bug in Guile <davexunit>"ephemerons" are a data type that can be used to construct things like weak key hash tables <daviid>would you name grip tools/toolbox for clutter grip-clutter or clutter-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 <davexunit>I'm still confused, sorry. just name it what you think it should be named. you know better than us. :) <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 <daviid>rotty1: I have a g-wrap/h2def.py 'mecanic' related quizz/problem, hope you can help me :) <daviid>running h2def.py 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