<daviid>leoprikler: very good that you added guile-gi, and the table as well - wrt 'how far g-golf is to work with guile-3.0, I don't know, but I would think not too far :) - here is what I know: <daviid>(a) we solved the re-export public iterface, thanks to both dsmith and your contribution, so that is out of the way; (b) I have identified another problem, which is that re-exporting the public interface of a module is 'static' in 3.0, dynamic in 2.2, so to speak, so adding a binding to a module, even doing so to the public interface of a module, doesn't seem to 'propagate' as it does in 2.2 - I know how to write a tiny snipset so I can <daviid>ask on guile-devel, and possibly open a bug if maintainers say so ... <daviid>but it could be that there is/are other problem(s), so telling how far I can't, but I would think not too far, let's see, no promises - but I have hope that every 'obstacle' will fall ... <leoprikler>daviid: I think I know why this is the case: The Guile 3.0 snippet only re-exports the currently bound symbols, so if you want to re-export stuff again, you'd have to listen on module changes and then re-export those too <leoprikler>There are some functions for doing that, but they don't seem too well documented. ***amiloradovsky1 is now known as amiloradovsky
<rlb>civodul: for cases where I don't care about competition/visibility, do you know if set! is promised to at least be atomic/safe wrt concurrent executions? I have some cases where I don't need the extra promises/overhead of an atomic box and wondered if I could just use set!. i.e. just need to be sure the assignment won't tear, and one of the competing set!'s will eventually win wrt visibility. <rlb>As one example, idempotent caching. <rlb>(idempotent, and deferred until requested, say for expensive (large) object hash codes) <rlb>Though I suppose you could argue that if the computation is expensive, and atomic-box-refs are cheap enough, then that example isn't a particularly compelling one. <civodul>rlb: yeah, i don't think set! is guaranteed to be atomic; and atomic box may be safer <civodul>then again, if you know set! happens at a "safe time", it's prolly good enough <rlb>I imagined as a practical matter, set! should end up always(?) being a pointer assignment, and if those are always "safe" (to the extent I described) on all the relevant architectures, then it's likely fine. <civodul>emys: so you want to replace the current-reader fluid with another fluid? <rlb>(But of course if you write a lot of code with that assumption, and then eventually we changeit, it could be *painful* to find/fix all the right places.) <RhodiumToad>though if you don't care about visibility they might be close enough <rlb>Yeah, that's what I was wondering about, i.e. (unless cached-code (set! cached-code (compute-hash obj)). Don't care when other threads can see that, as long as they do "soon". Worst case, the code will be computed more than once. <rlb>(And as long as no one can see a "torn" pointer.) <rlb>Anyway if it's not something we're really confident about, probably just avoid it, or use some alias that'd be easy to find/change later. <daviid>leoprikler: what functions/procedures 'for doing that, but they don't seem too well documented', were you thinking of/refering to?