IRC channel logs


back to list of logs

<mark_weaver>well, okay. but how does using a mutex violate the spirit of the goal?
<madmax96>mark_weaver: Then you're not lock-free
<mark_weaver>using a mutex is less efficient, but it accomplishes the same goal
<mark_weaver>well, internally, compare-and-swap is still doing more or less the same thing as locks
<mark_weaver>compare-and-swap still needs to include the memory barriers, which are the major expense of locks
<mark_weaver>also, although it was once believed that single-word compare-and-swap was capable of implementing multi-word compare-and-swap, this turns out to be false on modern weakly-ordered memory architectures
<mark_weaver>so it's not actually a suitable primitive upon which arbitrary other things can be implemented.
<mark_weaver>(and even if it was, it would be more expensive to do it that way)
<madmax96>mark_weaver: you seem to have a lot of experience with this. Do you know how Clojure/C++/Java atomics are being implemented then?
<mark_weaver>I don't know the details off-hand, but C++ atomic operations are definitely relying on memory barriers (or equivalent).
<mark_weaver>the memory barriers themselves, as documented in C11 and the relevant C++ standards, are suitable primitives, although they are difficult to use properly.
<mark_weaver>but they can be trivially used to implement mutexes
<mark_weaver>which are somewhat easier to use
<madmax96>what I'm really after is STM on guile
<mark_weaver>yeah, STM is a good goal, although I wonder how it can be implemented efficiently.
<mark_weaver>it's a sane model, though. I wouldn't mind programming with STM.
<madmax96>I was checking out the Clojure source, and it's relying on the Java Atomic stuff. I was wondering if there is a similar was to rely on the C++ primitives that exist in Guile
<madmax96>^typo. C++ primitives that exist
<rain1>I think guile is plain C
<mark_weaver>yes, guile is plain C, and we don't want to depend on the C++ runtime.
<mark_weaver>if you want to try building STM on Guile, you'll really need to write some C code, and I would recommend adding STM variables as a separate type, which contain a single STM-protected SCM value.
<mark_weaver>so SCM is an opaque type that's the same size as a pointer.
<mark_weaver>and I think that's all you should need to know about them to implement this.
<mark_weaver>so these SCM variables would only be accessible from within 'atomic' sections, using primitive accessors that you provide.
<mark_weaver>does that make sense?
<mark_weaver>I suppose you could also implement a vector of STM variables, for efficiency purposes.
<madmax96>mark_weaver: I think so. Is it possible then to add a builtin type with C?
<mark_weaver>smobs are one method
<madmax96>found the doc, I'll start reading
<mark_weaver>s/these SCM variables would only be/these STM variables would only be/
***karswell` is now known as karswell
<madmax96>In libguile, does gscm_2_str(3) return with a string that represents a guile object, or does it only convert a guile string to a c string?
<mark_weaver>what version of guile are you using?
<mark_weaver>that sounds like something from a very old version of guile
<mark_weaver>guile-2.0.x has no such function
<Jookia>is it possible in guile to import functions that aren't explicitly exported
<davexunit>hey guilers, just wanted to let everyone know about the upcoming Lisp Game Jam.
<davexunit>participants have a week to make a game in their Lisp of choice
<mark_weaver>Jookia: you can use the '@@' syntax to access unexported variables from another module, e.g.: (@@ (ice-9 foo) varname)
<Jookia>i see, that's useful
<Jookia>davexunit: Neat! Though I don't know enough Lisp yet to do anything nice
<mark_weaver>there's also a '@' syntax that works the same way, but accesses exported variables.
<Jookia>oh, cool
<mark_weaver>you can also access modules programmatically using things like 'resolve-module' and 'module-ref'.
<mark_weaver>these are strictly more powerful, because the module name and variable name needn't be known at compile time, and you can postpone loading the module until your code runs.
<mark_weaver>we use that trick in guix in several packages
***cojy_ is now known as cojy
***mjl_ is now known as mjl
<civodul>Hello Guilers!
***unCork is now known as Cork
***amz31 is now known as amz`
<amz`>interesting read about immutability and side effects on HN:
<wingo>i think it would be more appropriate to credit patrick dubroy or recurse center for the article :)
<Jookia>Isn't FRP basically the exact thing that article fixes
<Jookia>I'd like to see an effects system in Guile
<amz`>wingo: maybe, i don't know patry dubroy
<wingo>amz` i don't either but apparently they are the author of that article
<rain1>does anyone have thoughts about this?
<wingo>ACTION has a nice port patch
<rain1>I am not sure what to say about it but the thread has continued
<wingo> 13 files changed, 995 insertions(+), 1867 deletions(-)
<wingo>all c
<wingo>rain1: for better or for worse, not a bug
<wingo>include does early binding
<wingo>use "load" if you want late binding
<rain1>alright thanks! I'll close the thread with that
<rain1>he's at NASA :O
<rain1>on the include-bug thread
<dsmith-w`>Thursday Greetings, Guilers
***dsmith-w` is now known as dsmith-work
***octo_ is now known as octophore
<rain1>these links are not working
<mejja>Hehe .. "What is it that you do not like about GOOPS? Most specifically, I dislike its middle three letters..."
<janneke>mejja: that can be fixed by a rename, right :-)
<dsmith-work>If it's OOP by any other name, does it still smell?
<janneke>dsmith-work: that depends on how you use it
<madmax296>Hi all. I've been working with the libguile SMOB stuff, and I have some preliminary stuff done. But I'm not sure I understand the usage/point of the `static scm_t_bits image_tag;` in the Smob example in the doc (
<janneke>or, if you use GOOPS in a purely functional way (no setters), does it still smell of OOP?
<madmax296>I guess my question is if the example given in the doc is thread-safe, with all the function calls with `image_tag` as a parameter.
<dsmith-work>sneek: botsnack