***Server sets mode: +nt
***catonano_ is now known as catonano
***apteryx_ is now known as apteryx
<lloda> why does bytevector-copy! take start & len args but bytevector-fill! doesn't :-( <lloda>are these standard or is it something we can fix? <lloda>(bytevector-fill! bytevector fill start k) <wingo>lloda: it can certainly be extended. fwiw i have had "subbytevectors" on my list for a long time also <wingo>we have all the machinery, just need to add the constructor <lloda>I only think it's necessary as a low level mechanism <lloda>because it ends in a memset, etc <lloda>I think if you need 'view' objects, arrays is what should be used <lloda>also bytevector-/vector- have very different interfaces, even though vectors and bytevectors are more or less the same thing, even the implementation <lloda>I don't know if some merging could be done there <lloda>so imo bytevector/vector-copy/fill should offer start/length and even stride, like s/d/c/zcopy in BLAS, but I don't like the idea of a subbytevector object tbh <lloda>there are already too many of these things :-/ <wingo>well my issue is that sometimes you have a big piece of memory and you want to give it to a subroutine <wingo>right now you have to pass the whole thing, or use arrays which are somewhat less efficient than straight-up bytevectors <wingo>if i could pass a subbytevector then i get bounds-checking in the subroutine <wingo>s/give it to/give a piece of it to/ <lloda>you think it's too much of a burden to pass start/len explicitly in those cases? <lloda>ideally arrays wouldn't be less efficient <lloda>I'm concerned that introducing this middle layer will make arrays even less efficient <lloda>because of the redundant ranges <lloda>also would all the operations that now take bytevectors, be able to handle subbytevectors? <wingo>yes i think passing start/len is too much of a burden because it's not reliable. <wingo>fwiw subbytevectors don't add any conceptual complexity <wingo>the compiler already assumes that any bytevector can alias any other bytevector <wingo>and bytevectors already have a "parent" field if their memory is "owned" by some other object <wingo>so a subbytevector is just a bytevector that has another as a parent, and which aliases a part of its memory <wingo>it's not a new type of object <lloda>ok that sounds a lot better than what I thought <lloda>handling aliasing will be up to the user? <lloda>like it is for arrays now I guess <wingo>you mean managing the fact that one bytevector can mutate another? yes that's right <wingo>note that it is possible to flag some bytevectors as immutable but given that they can alias mutable memory it doesn't give you much <lloda>shouldn't the flag be only on the memory and not on the bytevector then <lloda>'memory' as w/e object that is <lloda>also (sub)bytevectors will still be contiguous memory I assume <weinholt>if you have shared subbytevectors then -ref/-set! can't assume alignment <wingo>weinholt: that's already the case fwiw in guile, because you can make a bytevector out of a foreign pointer <wingo>i think we will just emit unaligned load/set ops and pretend it's the cpu's job :) <wingo>lloda: memory isn't an object; it has no flags that we can easily access <wingo>sometimes you can rely on os-level protections but guile doesn't do that right now as you'd need to catch sigsegv in weird places <lloda>ok I was thinking you'd get some kind of metadata on the allocated pieces or something <wingo>some of the memory is static in the .go files <wingo>or from const static C memory, etc <lloda>I see. Not a big problem I don't think <lloda>bytevector-copy! is massively faster than some of the other copy!s in Guile so I think those should be rebased as far as possible <lloda>it's a special case, but a very common one <wingo>it's faster than vector-copy! ? <lloda>they don't work on the same types so I dunno <lloda>I was thinking about array-copy! which is super slow <lloda>I know vector-copy in core uses memmove or memcpy same as the unrollable case of array-copy! #t <lloda>but array-copy! has to handle all the type conversions so it just does the dumb loop when the types are srfi4 <lloda>bytevector-copy! on s64 x 50000 and vector-copy! x 50000 are about the same <lloda>array-copy! is about the same with vectors (special case of #t -> #t copy) but it's horrible with 's64 as expected <lloda>so the question is, if you have subbytevectors, will you also have subvectors, and will it be the same re: not a new type, etc. <wingo>lloda: i don't think we will have subvectors. <wingo>reason being, vectors deal in gc-managed memory and don't have this behavior of needing to be able to adopt memory from elsewhere <wingo>i can see a consistency argument but the mechanics are too different <wingo>civodul: fixed that closed-stdin bug and cutting a 2.9.7 <wingo>i probably won't get to do any guile things over the next 3 weeks fwiw <civodul>ah ha! so that's when i should start playing with it :-) <wingo>oh yay distcheck worked the first time :) <zig>roelj: As you might have figured, I cycled back to my rdf work. I read the documentation of sparqling-genomics. It is interesting. Like you told me previously, I need to support sparql 1.1 to be able to interop with your project. *wingo finished release, just waiting on mailman to post the release announcement <roelj>zig: Well, if your store can do RDF then I want to look at it already. Maybe I can help implementing SPARQL 1.1 stuff! <zig>I am not sure how to tell the thing I am thinking about. <spk121>looks like I didn't make the cut for minlang room in FOSDEM, but, the schedule looks fun <jcowan>roelj: Yes, and it generalized from triples to arbitrary tuples, so you can handle common RDF extensions like provenance. ***apteryx_ is now known as apteryx
***ng0_ is now known as ng0
<civodul>unscientific benchmark: "time guix build guile3.0-minikanren --check --no-grafts -v1" <zig>on my side, query times were good with babelia. I did not compare with guile 2.2 tho. I might have time to do that during the holydays maybe. <jcowan>I'm testing Guile 2.9.7 on Cygwin now <zig>I also benchmark nomunofu against blazegraph (jvm) <jcowan>I had to build libunistring, which Cygwin doesn't package, and ./configure is dog-slow on Cygwin; the Guile one is especially large and it's still running. <jcowan>Pig fucker crashed with "libunistring not compiled with iconv support". I do wish Guile would check dependencies *first*. <davexunit>guile checks tons of stuff during configure. sounds like a simple omission. <jcowan>I'm assuming that libunistring couldn't find Cygwin's iconv, so I'm rebuilding it <jcowan>But the ordering consideration has been the case since at least 2.0, when I spent most of a day configuring, aborting, installing a dependency, rinse repeat. <jcowan>At least now I know what the dependencies are up front, and hopefully it won't have to recompile *everything*, as Guile 2.0 did. <jcowan>Okay, it's libiconv-devel that I needed to install (Cygwin uses Fedora package names, unsurprisingly) <jcowan>and also libffi-devel, configuring for the 3rd time <daviid>wingo: congrat for the release! i hope the next one includes lloda's wip-truncate-exception 2 patches - if you're going to be a bit 'away from guile' for 3 weeks, please don't forget to look at it ... tx!