<unknown_lamer>hrm, if I set! a binding in one thread and access it in another, is the switch atomic? <unknown_lamer>I bet there's a mutex, and locking it 500 times a second would be bad... <unknown_lamer>(trying to use an external beat detector -> accumulator -> separate thread wakes up every few seconds to diff current-beats - previous-beats to estimate the instantaneous bpm) <unknown_lamer>or, rather, approximate. I keep forgetting about accurate language. <civodul>unknown_lamer: it's not atomic, and not even thread-safe <unknown_lamer>new idea: three threads, one reading the beats and updating a counter, a second waiting on a cvar to be woken up every N ms by the first thread to update the current count, and the third thread accessing the current count using a mutex <unknown_lamer>I'm guess that acquiring and releasing a mutex hundreds of times per second is still a bad idea <unknown_lamer>or maybe my brain is stuck in the early aughts and computers are much faster now <wleslie>performance of uncontended locks on guile is something I don't know about <unknown_lamer>I guess I'll do the simplest way (lock repeatedly when updating the count) and see how that fares against the cvar coordinator <unknown_lamer>finally, something I have near release after only a few days at least! <unknown_lamer>I still need to finish up my opengl stuff from last fall, dang SML programming sucking me away from that <unknown_lamer>I am currently resisting the urge to sabatoge my own project by trying to bind aubio and jack into guile instead of using PD and feeding output from that into guile... <unknown_lamer>it looks like it may be worth my effort to buckle down and finally write a guile midi parser... always been annoying that no lisp dialect has one <unknown_lamer>and I've been knee deep in awful low level packed structure parsing for a week or two *anyway* <ft>Hm. Is there no function that splits a string at a string instead of a character? Like (split "foo->bar" "->") => ("foo" "bar") <ft>unknown_lamer: string-contains, okay. Let's look what that does. Thanks. :) <unknown_lamer>it might be possible to use the SRE library to construct a regex to that as well <ft>unknown_lamer: string-contains will do. Thanks! <nalaginrut>ft: and regex-split is cool too (regexp-split "->" "a->b") <ft>nalaginrut: Interesting thanks! But in this case, I think string-contains is more useful to me, since I only want to split at the first occurance of the separator. :) ***wpsea_ is now known as wpsea
<lloda>hello wingo, do you remember the issue with interning arrays in master? <wingo>ah yes! sorry for delaying that <wingo>i haven't started on it -- was distracted by an n^2 thing that i'm still chewing on <wingo>i'll do n^2 thing first so that the recompile will go faster ;) <dsmith-work>bhattigurjot: Heya. Did mark_weaver's suggestion work? <lloda>wingo: np, n^2 is important. i really should try harder to understand vm/assembler.scm <wingo>i'm happy to help if you're interested in diving in <wingo>lloda: it's fairly up to date, yes <wingo>some minor changes since then but i updated it a couple months ago <lloda>i'll try to read that first then <sneek>bhattigurjot, you have 2 messages. <sneek>bhattigurjot, dsmith-work says: Running ldconfig allows libguile.so to be found. Has nothing at all to do with the .m4 file. <sneek>bhattigurjot, mark_weaver says: set the ACLOCAL_PATH environment variable to $PREFIX/share/aclocal, where $PREFIX is the one used to install guile, and then rerun: autoreconf -vfi <bhattigurjot>I tried setting both, i.e ACLOCAL_PATH as well as ACLOCAL_FLAGS, but nothing. It still couldn't set GUILE_PROGS and GUILE_FLAGS <bhattigurjot>I had to manually copy the guile.m4 from the /usr/local/share/aclocal dir to my software's m4 directory ***cluck` is now known as cluck
<daviid>wingo: hello! I am trying to understand why I have some opaque warning, for example: WARNING (opaque type for proc g-utf8-to-ucs4 gunichar*), where it seems to me that you actually did the work.... gunichar is defined in glib-spec.scm as ("gunichar" unsigned-int32) [line 132]. g_utf8_to_ucs4 _is_ in overrides/glib.defs, -> _wrap_g_utf8_to_ucs4 and glib-support.c defines _wrap_g_utf8_to_ucs4 ... do you have any idea of what's going on <daviid>gunichar2 was actually missing, I added it as ("gunichar2" unsigned-int16). 1 thing maybe is that if I compare with what you did for gchar, gchar*, then I should add gunichar* to the list: should it be ("gunichar*" mchars . #f), then also adding: (add-type-rule! ws ["gunichar**", "const-gunichar**"] '(mchars caller-owned out)) <daviid>yep, that did solve it, and where it would be nice to get a confirmation, looking at all char related work you've done I'm pretty confident that it's the correct patch. *jdsdsa plays guile's theme <daviid>I guess that given the defs ("gunichar2*" mchars . #f), mchars being efined as char* in g-wrap, these warnings are expected [unavoidable?]: glib-support.h:73:8: note: expected 'const gunichar2 *' but argument is of type 'char *' <daviid> gchar* _wrap_g_utf16_to_utf8 (const gunichar2 *str, GError **error); <daviid>guile-gnome-gw-glib.c:1920:1: warning: passing argument 1 of '_wrap_g_utf16_to_utf8' from incompatible pointer type [enabled by default] <daviid> gw__result = _wrap_g_utf16_to_utf8 (gw__c_arg0, &gw__c_arg1); <daviid>I was hoping to get rid of absoltelly all warnings: I guess it is a not very C knowledgeable dream :)