<davexunit>wee, I am able to link against libvulkan using the FFI <davexunit>now, to actually learn how to use this thing... <davexunit>there's a (mostly) machine readable XML spec from which bindings can be generated. <davexunit>I'm considering taking a page out of guile-xcb's book and write a vulkan language that knows how to read that xml spec and compile it. <kristofer>(build-tree word-list) appears to be building the list I want. it's really slow though <amz3>kristofer: you are building a tree with words, is that correct that you try to implement autocompletion? <kristofer>(build-tree word-list) is outrageously slow. the string=? appears to be the most expensive part of the loop. any tips to improve it? <amz`>kristofer: you memoize alphabetize for instance <amz`>actually it's the only improvement i see <amz`>tho, I don't know any memo procedure that is available in Guile <kristofer>amz`: I'm having a difficult time conceptualizing how to memoize alphabetize in a pure functional way. <mark_weaver>kristofer: I would convert the list of words into a list of (word,sorted-word) pairs, sort those pairs by their cdrs (second halves), and then each bucket will be together and you can accumulate them together. <sneek>mark_weaver, you have 1 message. <sneek>mark_weaver, NiAsterisk says: thanks for the tip to look into python-2, kyotocabinet did build without errors now <mark_weaver>right now your code requires O(n^2) time, but this would make it O(n log n), and with the expensive 'alphabetize' being done once per word instead of O(n^2) times. <mark_weaver>kristofer: memoization requires the use of mutable state, however, it can be applied to pure functions without changing their behavior, and so the resulting code can still be analyzed as if it were purely functional. in fact, haskell does a great deal of memoization at a very deep level. <mark_weaver>even just memoization would have helped a lot here, but it still would have been O(n^2) ***petercom1and is now known as petercommand
<davexunit>the vulkan xml spec contains not only xml, but little bits of C that need to be parsed. frustrating. <wingo>i've long thought we need a little c parser <davexunit>it would really help in various cases like this. <davexunit>not the first time I've wished for a c parser. <wingo>is your need for code or for type definitions? <davexunit>I've wanted to parse header files to help automatically generate FFI bindings. <wingo>still, hard to map api to abi sometimes <wingo>because of typedefs, you have to correctly parse a lot of headers to get valid typedefs <davexunit>the most sore spot for me with FFI stuff is defining foreign structs. <davexunit>the list of types to pointer thing doesn't really cut it sometimes. <wingo>if it doesn't use many primitive types then you can write a bespoke parser for vulkan's struct typedefs <wingo>won't have to handle the preprocessor, etc <davexunit>preprocessor stuff isn't a worry, the xml spec does a decent job saying what the structs contain <davexunit>but... how do you write constructors and selectors for the struct and its members? <davexunit>need something that can construct a wrapped bytevector type that knows the byte offsets of all the members <wingo>yep, you need to make some tools :) <wingo>we probably need a sub-bytevector feature too <wingo>for the time being a sub-bytevector thing could work acceptably <mark_weaver>I thought I remembered someone posting a C parser to guile-user <wingo>and, compared to accessors that assume a struct is embedded at some offset in some other bytevector, <davexunit>I think the scariest part of this for me is how to pack the bytevector properly <wingo>which is a common thing to get wrong when dealing with arrays of structs <mark_weaver>I haven't looked closely though, so I don't know whether it would be suitable for us. <davexunit>I tried to find out how guile does correct padding and all that for make-c-struct but I had trouble understanding what was going on. <wingo>the idea is simple iirc: each type has a sizeof and an alignof. <wingo>the alignof a struct is the gcd of the alignof of its elements. <wingo>the offset of the first element of the struct is 0. it continues for sizeof bytes. then the offset of the next element is rounded up by its alignof. and so on. <wingo>well in practice all alignments are power of 2's so it's really the max alignof. <wingo>gcd so that if the struct itself is aligned, and the element of a struct is aligned relative to the struct itself, then the element of the struct will be aligned absolutely <davexunit>okay, so I can use guile's alignof procedure on the primitive types <wingo>and on lists of types as well i think <davexunit>though so far I don't think I'd use that for my particular thing. <wingo>if the struct is packed, then no alignof padding is inserted. <davexunit>how does that work when sending a pointer off to a C function? <davexunit>when I write C, I've never thought about whether a struct was packed or not. <wingo>whether a struct is packed or not is an attribute of the type <wingo>i.e. __attribute__((packed)) <wingo>so it is part of the type, and so code that uses that type knows where to get the members. <davexunit>now I'm unsure how to query if a type is packed or not. <wingo>it's not packed unless it specifies __attribute__((packed)) at the end <davexunit>I guess I can assume that these vulkan structs are unpacked. I haven't seen anything stating otherwise. <wingo>whether or not there are alignment holes is also a function of how the struct is built <wingo>i.e. struct { double x; float y; } // packed on i686 b/c alignof(double) is 4, 4-byte padding on end on x86-64 b/c alignof(double) is 8 <wingo>struct { float y; double x; } // likewise, but on x86-64 there's a 4-byte hole between y and x <wingo>iirc anyway, i could be getting this wrong <wingo>you can :) it's very uniform based on sizeof and alignof. <wingo>sizeof and alignof give you all the info you need. <wingo>ACTION wonders how long a readline.scm would be <Jookia>wingo: Reimplementing GNU Readline? Blasphemy <mark_weaver><wingo> the alignof a struct is the gcd of the alignof of its elements. <wingo>mark_weaver: you are right, sorry! <mark_weaver>they are two sides of the same coin, easy to get them mixed up <wingo>yay, the build is up to guile <nalaginrut>I'm going to write a better FFI parser with nyacc, there's already a c99 parser in it, but I'm still waiting for the patch of errno to be pushed <daviid>davexunit: I think guile-opengl also use xml spec to generate its binding <davexunit>because guile-xcb actually uses the XML as source code for the 'xml-xcb' language that compiles to Scheme code. <daviid>I wish i had more time, i'd like to learn this too, so I could start to work on gir ... but that's not going to be tomorrow <nalaginrut>wingo: are we going to use gcc-xml for AOT? or will implement all stuff from scratch? <wingo>nalaginrut: i do not know. initially we do it ourselves. then we see if we can integrate with gcc or llvm or whatever, and if it makes sense. <wingo>but that integration project is hard and i prefer to leave it to someone else ;) <wingo>if we do integrate with gcc or something, we would need a stable backend language through which to do it, like ghc's c-- or llvm's bitcode, but we would need guile-specific facilities like the ability to expand the stack, to residualize side tables for gc and arity info, etc <nalaginrut>wingo: frankly, I prefer we do it ourselves. Of course, I know it's challenging to compile Scheme to efficient native code due to its natural features... <nalaginrut>wingo: I'm glad you looks so confident for it ;-) <nalaginrut>I even don't install it, alright, some packages need it <amz3>since there is gcc, what is llvm useful for anyway? ***micro` is now known as Guest91588
<amz3>my last comment was not very useful sorry <amz3>I'm wondering whether it will be better if I use a 'call-with-proc' kind of procedure instead of the macro <amz3>the proc looks horrible actually <amz3>hmm... call-with-proc is an apply ***Korhonen is now known as Reginald-Wolfgan
<xyh>hey where is the guile-joy <davexunit>gah, map-union in (sxml xpath) is not written in an iterative way. <xyh>I remember we have someone port joy to guile here <xyh>anyone knows where can I find the code ? <davexunit>xyh: the guile-user mailing list archives should have it <davexunit>ACTION monkey patches (sxml xpath) in his project weeeeeee <xyh>what nick does Eric Bavier use ? <xyh>I am also a fan of joy