<anadon>I sent this to John Cowen, but maybe a few people here could also comment. I'm trying to consider a general use case of a Guile file describing a datastructure which spans something obscenely large -- say 100's on TB. So big that is actually can only exist across multiple systems each of which only have some chunks of it. Then also say that there are multiple readers/writers acting on this said file which need to be able to access inde
<anadon>xed or referenced data efficiently and not with linear parsing of the entire thing. How might I think about or solve this problem?
<anadon>My best thought is to put in some reference in the place of a subtree when it gets too big. Then when a given subsubtree becomes too large to parse or index efficiently to apply a similar reference and put that data into a new further down. Then for normal lists which become too large, have a seperate data structure to have ranges of indecies put into sub-trees for that portion of the now split list, and have that tree structure handle
<anadon>what were flat datastructures. But this has to have been solved by someone before.
<manumanumanu>anyway, I am trying something else. I think I was to blame for the documentation error. The warnings are because of xref missing a comma afterwards (which for the two places were sane, even regarding the oxford comma).
<manumanumanu>Now bootstrapping to see if I really was to blame. If so I will probably go into hiding (even though noone else seems to be hit by this)
<manumanumanu>wingo: my srfi-171 patch broke installing on os x due to my malformed documentation. I am so sorry. A patch is on it's way to the mailing list in about 1 minute.
<dsmith-work>wingo: an since intel/amd is also fine, /me thinks those segfaults must be isolated to the armv7 jit code.
<rlb>civodul: if I understand correctly, wondering about the possibility of making GUILE_SYSTEM_EXTENSIONS_PATH "official", i.e. documenting it (or doing something else), so that projects that build on guile have a supported (when it's available) way to augment the load-extension/dynamic-link path.
<rlb>Or rather, some documented way to provide a dir with your own libs that should "come first" without having to change LD_LIBRARY_PATH.
<rlb>(which affects all subprocesses as mentioned in dynl.c)
<rlb>...and better yet, some way to do that after guile starts up so that a (shell/env) wrapper isn't mandatory, e.g. (set! %system-extensions-path (cons ... %system-extensions-path)) as per %load-path.
<civodul>rlb: GUILE_SYSTEM_EXTENSIONS_PATH is really for Guile's own .so files
<civodul>so what we'd need is GUILE_EXTENSIONS_PATH
<civodul>but that'd be synonymous with LTDL_LIBRARY_PATH currently