<davexunit>it doesn't seem to have been updated in awhile. <davexunit>I'm going to try to use it to render fonts for me. <davexunit>and turn cairo surfaces into opengl textures. <madsy>Hm.. how do I use #:export-list in define-module? It complains that the symbols don't exist <madsy>Which isn't that weird as I have to define them after the define-module clause. Right? <madsy>ijp: The doc snarfing uses texinfo to generate the documentation strings <ijp>madsy: I was trying to draw a distinction between docstirngs and manual entries <ijp>they are often different <mark_weaver>also, fwiw, you don't have to export *gl-enums* unless you want users to be able to access it directly. <mark_weaver>madsy: also, you could rewrite (cdr (assq enum *gl-enums*)) to (assq-ref *gl-enums* enum) <mark_weaver>well, I should note a difference between those: (cdr (assq enum *gl-enums*)) will raise an exception if it's not in the alist. 'assq-ref' will instead return #f. <davexunit>madsy: I'm just realizing that you were the one that initially told me about using pango + cairo for font rendering on reddit. <mark_weaver>(or (assq-ref *gl-enums* enum) (error "gl-enum: not found") #f) might be best of all. <mark_weaver>the last #f is to prevent 'error' from being a tail call, for a better stack trace. <madsy>davexunit: Heh, that might be right :) <madsy>I rolled my own font rendering with libfreetype2 and harfbuzz. Afterwards I found out that pango did that already <mark_weaver>madsy: will the argument to 'gl-enum' always be a literal constant? if so, you could have the lookup done at compile-time instead of run-time. <davexunit>madsy: do you just turn cairo surfaces into gl textures? <madsy>davexunit: As I said, I don't use cairo or pango. I use libfreetype2 directly and upload the glyphs as textures <davexunit>madsy: sorry. reading comprehension failure. <madsy>I also do some neat texture packing <madsy>Required because not all glyphs are of the same size <madsy>mark_weaver: That's why I wanted to use a macro. davexunit gave me the idea <madsy>mark_weaver: Won't the macro ensure that I get constants at compile time? <mark_weaver>as you have it now, (gl-enum #:depth-buffer-bit) will expand into the code (cdr (assq num *gl-enums*)) <mark_weaver>you can always see what a macro expands into using ,expand at the REPL. <mark_weaver>you could also change those keywords into bare symbols. easier to type, and they look nicer. <mark_weaver>since it's a macro now, they don't need to be quoted. <mark_weaver>(well, it was before too, but your old macro expanded into a procedure call, thus the quote still would have been needed if it wasn't a keyword) <davexunit>madsy: the macro I suggested was for convenience, not performance <mark_weaver>the tradeoff, of course, is that these constants will be baked into the compiled .go files of anything that uses 'gl-enum', so if they ever change, things will have to be recompiled. in this case, I suspect these constants are stable, but in general it's something to keep in mind. <mark_weaver>(and guile doesn't automatically recompile things when the macros change) <madsy>mark_weaver: Thanks a bunch :) <madsy>I spent 10 minutes scratching my head, wondering why my OpenGL code didn't work. <madsy>Turns out I forgot to call glFlush() <madsy>You need to call glFlush() in order for changes to become visible on another thread <dje42>mark_weaver: Nice trick with (or ... (error ...) #f) for a better stack trace. Any possibility of being able to flag functions as "do not turn into tail call" so the trick isn't needed? <mark_weaver>we have a better plan, to keep track of the last N tail calls in between any two non-tail calls, as is done in MIT Scheme. <mark_weaver>for various reasons, we can't flag procedures like that. the mapping between a variable and the procedure stored in the location bound by that variable is not known at compile time. <mark_weaver>we could make it a macro, but it's widely specified as a procedure. <nisstyre>Hey, is it best practice to extend %load-path to point at where I've downloaded a Scheme library or move the files to one of the directories listed in %load-path? <nisstyre>for reference I want to install the weinholt libraries <mark_weaver>if you take from upstream, you'll want to rename them to *.scm <nisstyre>okay, I'll see if someone has nicely packaged that <mark_weaver>as for where to put them, it's up to you I suppose. $PREFIX/share/guile/site/2.0/ is a fine place if you want them to be available site-wide, but some people prefer to add a path component in their home dir. <nisstyre>looks like there is a guildhall client for Arch <nisstyre>probably system wide since this is a laptop <madsy>mark_weaver: Hm.. some fairly new OpenGL functions have an opaque struct pointer as a handle type. Is it safe to store that as a 64-bit unsigned integer in guile? <mark_weaver>but you could use upstream also. just rename the files, that's all. <mark_weaver>madsy: you should use scm_from_pointer and scm_to_pointer for that. <nisstyre>mark_weaver: someone has packaged guildhall for the AUR (Arch User Repository) so I'll just use that since then I can have pacman handle it <madsy>Nice. Got OpenGL sync objects generated too. <madsy>Down to 30 functions missing <madsy> /home/madsy/Projects2/SchemingDemo/build/gl-procs.texi:2705: ` glget.info@documentencoding us-ascii@se...' is too long for expansion; not expanded. <madsy>Is it possible to override that texinfo limitation? <madsy>Ah. I was missing some newlines <madsy>Gah.. texinfo makes me pull my hair <zRecursive>Why (sort tab (lambda (left right) (> (cdr left) (cdr right))) ) error? tab is a hash table <mark_weaver>if you replace 'tab' with (hash-map->list cons tab), that might work. untested. <zRecursive>After sorting, how can i get its first n items ? <mark_weaver>warning: it will report an error if there are less than 10 items. <mark_weaver>or if you don't mind iterating the list twice, pass (min 10 (length lst)) as the second arg to 'take'. <zRecursive>You mean (hash-for-each (lambda (key value) (...)) tab) ? <mark_weaver>it's not a limitation. strictness is good because it detects bugs. <mark_weaver>making things guess what you meant by default leads to buggy, security-flawed software. <mark_weaver>(define (take-up-to lst n) (if (or (zero? n) (null? lst)) '() (cons (car lst) (take-up-to (cdr lst) (- n 1))))) <mark_weaver>that uses stack space proportional to N, so don't use it for huge values of N. <dje42>I have a very simple thread I'm creating with scm_spawn_thread - it just reads bytes from a pipe and queues asyncs in the main thread. However, my app is hung in GC_stop_world in sem_wait. Suggestions welcome. <dje42>Is there something threads need to maybe periodically do to not hang gc? <mark_weaver>historically, one has had to leave guile mode during the read (or other blocking operation), and that's what the signal delivery thread in guile 2 does. I didn't think that was needed anymore, but maybe I'm wrong. worth a try. <mark_weaver>see signal_delivery_thread in scmsigs.c, and how it uses 'scm_without_guile'. <mark_weaver>the problem you're seeing certainly sounds exactly like the kind of problem that scm_without_guile was meant to prevent. <dje42>Yeah. Once you said "leave guile mode" the path was clear. :-) <mark_weaver>(the paragraph above the description of 'scm_without_guile' claims that it is no longer needed since Guile 2. if that's not true, we'd like to know about it) <mark_weaver>'fport_fill_input' in fports.c does a blocking 'read' without leaving guile mode also, and that doesn't seem to cause problems, so this is surprising. <dje42>Hang is gone now that I'm using scm_without_guile to do the read. <mark_weaver>were you in guile module when you called 'scm_spawn_thread' ? <mark_weaver>(not that I'd expect otherwise, just grasping at straws here) <dje42>The function that calls scm_spawn_thread is called from within a call to scm_c_define_module. <mark_weaver>scm_c_define_module doesn't enter guile mode, rather it also assumes that you're already in guile mode before you call it. <mark_weaver>I don't really know what would happen if you did these things while not in guile mode, but I assume it could be bad. <mark_weaver>scm_spawn_thread puts the newly-created thread in guile mode, but it also assumes that when you call it, you're already in guile mode. <dje42>I'll try again, probably tomorrow, making sure that all my init'n is done in guile mode and see if that also removes the hang. <mark_weaver>'scm_with_guile' is the preferred way to enter guile mode. <mark_weaver>(the function passed to it runs in guile mode. after it returns, you're only in guile mode if you were already in guile mode before calling it) <dje42>[that's the thread procedure, after the switch to scm_without_guile] <mark_weaver>maybe the new 2.0 mechanism to allow GC to stop all threads relies on sending some signal to the threads. <mark_weaver>and since you're blocking it, you have to leave guile mode. yeah, I think that might be it. <mark_weaver>dje42: so don't worry about debugging further. leaving guile mode is the right thing to do here. <dje42>I'm making ^c support in gdb/guile part of my Guile potluck contribution. :-) <madsy>mark_weaver: Do you have an idea what subset of texinfo commands one can use in doc snarfing? I set up my source code generator to add documentation strings from .texi files generated from OpenGL's docbook source. <madsy>And it fails with a lot of errors. Like, some sections are said to be defined multiple times, etc <taylanub>Ugh, making a syntactic version of bytestructures will 1) not be able to re-use big parts of the framework, most notably all the "primitive" types like uint8 etc. need distinct syntactic versions, 2) drop the feature of "partial references"; in the procedural implementation you can reference a vector-of-structs to get a struct, in the syntactic one you'll need to reference down to a primitive value, 3) not support the "pointer" type. <taylanub>All in all, it's not a clean analogue to the C type system at all anymore. <taylanub>Well, that all goes for one implementation strategy I had in mind (and thought as the cleanest), there are alternatives with varying trade-offs ... <foeniks>is there a way to get guile report on code coverage? <ft>I don't know what you're after, but there's (system vm coverage). *wingo just finished the assembler, finally <madsy>wingo: Coding an assembler or using assembly? <madsy>Anyone knows what subset of texinfo commands I can use when doc-snarfing? <madsy>I generated texinfo from a docbook to put in snarf docstrings, but it blew up *add^_ had compeletely forgotten about the potluck.. <davexunit>I *really* need to take the time to learn gdb proper. <civodul>davexunit: yeah but dje42's Scheme API makes it really easy to use <davexunit>I wish I had my functional reactive programming module complete. that would have been my potluck dish. <davexunit>well, maybe I can share the working but not REPL-friendly version. ***Fuuzetsu is now known as Guest90249
***Guest90249 is now known as Fuuzetsu
<mark_weaver>civodul: oooh, that's a *great* potluck contribution, civodul! <mark_weaver>davexunit's FRP module is also really nice, although I was already familiar with that one :) <mark_weaver>I'm afraid I don't have anything again this year. it seems that I'm always focused on something else when the potluck comes around. <civodul>i was familiar with FRP, but everytime i see it, i find it fantastic :-) <davexunit>I hope to have it more fleshed out for the guile-2d 0.2 release. <davexunit>it will be more REPL-friendly and will have a mechanism to build a root level signal from a hook. <madsy>You have a moment to spare? I'm a bit stuck at the doc snarfing. <mark_weaver>I've seen your questions about that, and I have no answers. I expected that any texinfo command would work. also, wingo already did all this work. I'm not sure why you're doing it over again. <madsy>Because I'm not doing the same thing as wingo. <mark_weaver>I'm sorry, I don't have time to help you debug this. <madsy>That's fine. I'm just saying I'm not duplicating any work :) *davexunit think he's going to use boxing similar to SRFI 111 to solve the FRP + REPL problem. <mark_weaver>davexunit: iiuc, the problem with that is that you should preserve the list of downstream signals, i.e. the list of things that will be notified when this signal changes. <davexunit>mark_weaver: I'm trying to write things so that I hold onto the unboxed signals. <mark_weaver>I don't see how that addresses the problem I just raised. Well, I don't have time to swap this into my brain again right now, but just keep in mind what will happen when you redefine a signal in the middle of an existing DAG. <davexunit>mark_weaver: no problem. I will re-read the issue you raised and mull it over. :) <mark_weaver>I think you'll want it to refer to new upstreams (inputs that affect the newly redefined signal), but I think you'll want to keep anything downstream connected as it was before. <mark_weaver>so I think you need to preserve the existing list of signals to notify when this signal value changes. <davexunit>yeah, upstream signals preserve the list of downstream signals in a weak hash table. <davexunit>but yeah, keep your brain focused on the more important stuff! I'll figure this out sooner or later!