IRC channel logs


back to list of logs

<nalaginrut>morning guilers
<civodul>Hello Guilers!
<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>soon, my light strip control daemon shall exist
<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")
<unknown_lamer>ft: nope, but you can use string-contains to implement one
<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. :)
<nalaginrut>alright ;-)
<unknown_lamer>ah right, regex-split
<dsmith-work>Happy Firday, Guilers!!
<civodul>yay, happy Friday!
***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?
<dsmith-work>bhattigurjot: About ACLOCAL_PATH ?
<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>it's not too bad
<lloda>looks terrifying to me. is up to date?
<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
<bhattigurjot>dsmith-work: you mean ACLOCAL_FLAGS ?
<sneek>bhattigurjot, you have 2 messages.
<sneek>bhattigurjot, dsmith-work says: Running ldconfig allows 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>sonic boom!
*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 :)