IRC channel logs


back to list of logs

<davexunit>has anyone here used guile-cairo?
<davexunit>it doesn't seem to have been updated in awhile.
<mark_weaver>I've used it to generate images.
<mark_weaver>it worked just fine for me.
<davexunit>I'm going to try to use it to render fonts for me.
<davexunit>and turn cairo surfaces into opengl textures.
<mark_weaver>admittedly, this was back in Dec 2008.
<davexunit>I'll see how it goes ;)
<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>madsy: change "#:export-list" to "#:export"
<mark_weaver>where did you get #:export-list from, anyway?
<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>(you don't need it because of the macro)
<mark_weaver>madsy: also, you could rewrite (cdr (assq enum *gl-enums*)) to (assq-ref *gl-enums* enum)
<madsy>mark_weaver: thanks
<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.
<mark_weaver>so maybe not a good change after all.
<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.
<madsy>mark_weaver: yep
<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>so it will be done at runtime.
<mark_weaver>madsy: try this:
<mark_weaver>you can always see what a macro expands into using ,expand at the REPL.
<mark_weaver>,optimize is also useful
<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()
<mark_weaver>heh :)
<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>industria is in guildhall, fwiw.
<nisstyre>mark_weaver: that's another library?
<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>guildhall is sort of a CPAN for Guile
<nisstyre>oh okay
<nisstyre>I'm a Racketeer
<nisstyre>only using Guile because of weechat
<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>mark_weaver: okay that makes sense
<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.
<nisstyre>mark_weaver: yeah
<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>mark_weaver: Oh, right.
<madsy>Nice. Got OpenGL sync objects generated too.
<madsy>Down to 30 functions missing
<madsy> /home/madsy/Projects2/SchemingDemo/build/gl-procs.texi:2705: ` 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>sort doesn't work on hash tables.
<mark_weaver>if you replace 'tab' with (hash-map->list cons tab), that might work. untested.
<zRecursive>mark_weaver: it works, thanks
<zRecursive>After sorting, how can i get its first n items ?
<mark_weaver>use 'take' from srfi-1
<mark_weaver>warning: it will report an error if there are less than 10 items.
<zRecursive>not best solution
<mark_weaver>you probably have to write your own loop, then.
<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) ?
<zRecursive>odd take limitation
<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>IMO, anyway.
<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.
<dje42>Ah, righto.
<mark_weaver>see signal_delivery_thread in scmsigs.c, and how it uses 'scm_without_guile'.
<dje42>This is 2.0.9 fwiw.
<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>very interesting.
<mark_weaver>dje42: can you show me the code of that thread?
<dje42>Sec ...
<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>that doesn't answer my question.
<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.
<mark_weaver>most guile procedures assume it.
<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>okay, thanks!
<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>*nod* thanks
<mark_weaver>looks reasonable to me.
<mark_weaver>hmm, I have a theory.
<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>it might be SIGPWR actually.
<mark_weaver>and since you're blocking it, you have to leave guile mode. yeah, I think that might be it.
<mark_weaver>yeah, I suspect it's something like that.
<mark_weaver>yes, that's it
<mark_weaver>dje42: so don't worry about debugging further. leaving guile mode is the right thing to do here.
<dje42>K, thx.
<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?
<foeniks>I am using srfi 64 for testing
<ft>I don't know what you're after, but there's (system vm coverage).
<civodul>Hello Guilers!
<civodul>happy birthday, Guile 2.0!
*wingo just finished the assembler, finally
<wingo>%^&*( x86 machine code :P
<civodul>heh :-)
<taylanub>Where's sneek ? :\\
<madsy>wingo: Coding an assembler or using assembly?
<wingo>coding an assembler
<davexunit>good morning guilers.
<davexunit>and happy potluck day!
*civodul is done :-)
<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>civodul: wow that's neat.
<davexunit>I *really* need to take the time to learn gdb proper.
<davexunit>it's still intimidating to me.
<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
<civodul>would be very cool!
***Guest90249 is now known as Fuuzetsu
<davexunit>potluck dish sent.
<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 :-)
<civodul>thanks davexunit
<civodul>that's really cool
<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.
<mark_weaver>sounds great!
<madsy>mark_weaver: ping
<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 :)
<mark_weaver>I'm overwhelmed with other things right now.
*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.
<davexunit>yes, that is the goal.
<davexunit>I'll keep experimenting.
<mark_weaver>so I think you need to preserve the existing list of signals to notify when this signal value changes.
<mark_weaver>okay, good luck!
<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!