***_hanhart_ is now known as _hanhart
<davexunit>hmm, seems that I can't take advantage of unboxing when moving floats from a f64vector to a f32vector <mark_weaver>davexunit: that sounds fixable. talk to wingo about it <mark_weaver>although, out of curiosity, why not just use f32 everywhere? <davexunit>this is just a hunch. I don't have a reduced test case. <davexunit>mark_weaver: after talking to wingo, the idea was to f64s for better precision in the main application, and just lower precision to f32s for rendering. <davexunit>I could just use f32s, but it feels like a sacrifice. <davexunit>I'm giving this unboxing stuff some good exercise, I think. <davexunit>alright, so I took a look at the procedure that is taking up the second most amount of time in one of my programs according to statprof. seems that it is boxing floats before doing br-if-<. <davexunit>in this case, I'm doing inequality tests against what the compiler should be able to prove is two floats. <davexunit>I wonder if its possible to avoid the boxing here or if there's a catch that I don't know about. ***_zxq9_ is now known as zxq9
***karswell` is now known as karswell
<ozzloy>anyone in here have a 3d printer to recommend? <davexunit>ozzloy: probably not the best channel to ask. <rain1>there is #reprap on this server i think <rain1>i've got a weird crash with geiser <rain1>some reason my program makes emacs die <rain1>i wil see if i can figure out why <cojy>how do i fix this: geiser-repl--connection: No Geiser REPL for this buffer (try M-x run-geiser) <cojy>(obviously i did this and have one running) <zacts>is the core of guile implemented in C? <rekado>is there any usable library to simplify shell hacking? <rekado>I find the Guile way to connect two processes with a pipe to be very verbose <rekado>is there a more intuitive or less verbose way to do this? <davexunit>rekado: I just use the regular pipes interface and build abstractions on top as needed. <davexunit>okay, I see how to create structs with unboxed fields. <davexunit>now, how to convince the compiler to do this <davexunit>or rather, get the compiler to see that this struct has unboxed fields, so generate the appropriate boxing/unboxing instructions for ref/set <davexunit>hmm, I'm not sure where I should be checking for unboxed struct fields in the compiler <davexunit>I'm not sure I can even find the precise vtable at compile time. <davexunit>so far I read the implementation of structs and figured out how to make a vtable for unboxed unsigned ints <davexunit>and I see that I can remove some ifdefs to add support for unboxed ints and doubles <davexunit>but now, how can the compiler learn that the struct vtable has unboxed fields? <davexunit>if I can figure that out, I can probably fumble my way through adding the scm->u64 instructions and whatnot <rain1>i have a question about records/structures <rain1>for my program i wanted to be able to define a records to get new types disjoint from every other (like R7RS) -- was a bit confused about how RECORD? can be true of anything <rain1>I think that srfi-9 gives me a disjoint type though <davexunit>(record? foo) is #t for objects that are instances of record types <davexunit>srfi-9 provides the syntax for defining record types <rain1>Is there a way to get all the fields of a record as a list? I may need to define my own register-record macro <davexunit>sounds like you want to work with structs directly <rain1>may I define a struct with the srfi-9 library then take it apart using the structures stuff? <davexunit>you can use things like record-type-vtable to get the underlying vtable and make new structs with it <davexunit>but not sure how to wrap that back up as an instance of that record type <rain1>hmm i don't know what the best solution is yet.. <rain1>yeah looks like struct is the best, I can have a macro that expands into a struct definition.. oh no I can't <rain1>There's a problem: structs are defined not using s-expressions but strings like "rwrwrw" <rain1>so I can't do something like: (define-my-record name a b c) for 3 fields <davexunit>you can see the definition of define-record-type to see what it does <rekado>davexunit: re pipes: thanks for the pointer. I'd probably also abstract this away if I had to use pipes more often. <davexunit>ACTION writes to list about struct field unboxing <davexunit>learned a lot this morning, but blocked and in need of some help. <davexunit>for now I will step away from the keyboard and go have brunch <rain1>are opaque fields taken into account for EQUAL? <rain1>would anyone be able to help me with guile programming <rain1>i wanted to make a launcher which figures out what to do with a link <rain1>so I started with this but when I try it like ./launcher.scm gnu.org it errors: <rain1>Couldn't find the application directory. <davexunit>wingo: hey, wrote to the list about struct field unboxing. I'm in the "I have no idea what I'm doing but I'll poke this hornet's nest anyway" territory. <davexunit>learned some stuff, confused about some stuff. <davexunit>my biggest questions are: where is one able to inspect a struct vtable at compile time? and where is the right place for generating the boxing/unboxing code? during the tree-il->cps conversion or in the cps optimization passes. <cojy>what's the performance like on guile's delimited continuations these days? <davexunit>cojy: I don't have numbers, but I use them a lot in my game engine and they perform well. they aren't the bottleneck, anyway. :) <davexunit>it's not saying much, but I have modified struct.c such that signed integer and double fields are supported. <davexunit>rain1: resuming our conversation that started on #guix. you can perform arithmetic on character sets. <davexunit>so you could have a character set of confusable characters <rain1>yeah that would make it much nicer! <davexunit>personally, I think it would be cool if it used all the characters by default <davexunit>and had a switch that would avoid those deemed confusing. <rain1>oh right and an option, yeah that makes sense <rain1>im keen on the non confusable because I've shad stuff written down that I couldn't decode :P <davexunit>but it's all about what you have the time an energy to implement. having something basic is good for now. it can be improved later. <davexunit>they have a variety of options for stuff like that