IRC channel logs


back to list of logs

<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
<emys>mwette, I typed up my findings here with regards to the module problem
<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.)
<rlb>"change it"
<RhodiumToad>pointer assignments aren't really safe
<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.
<ArneBab>wingo: do you have an updated version of your “improve compiler”-thread?
<daviid>leoprikler: what functions/procedures 'for doing that, but they don't seem too well documented', were you thinking of/refering to?