IRC channel logs
2023-01-27.log
back to list of logs
<mwette>I guess you could wrap an exception handled in a dynamic-wind, right? <apteryx>shouldn't (list->s32vector (list #x0FFFFFFFE)) return #s32(-2147483648) ? <apteryx>how can I convert 4 bytes into a signed integer? <mfiano>First you have to know the endianness <some02>make sure you don't hold the computer upside down, or you'll read the bytes the wrong order <dthompson>apteryx: bytevector-s32-ref or bytevector-s32-native-ref <old>apteryx: Use bytevector->sint-list <old>(bytevector->sint-list #u8(255 255 255 255 7 7 7 7) (endianness little) 4) => (-1 117901063) <mfiano>Very nice, thank you (even though I'm not the asker). <old>Now the tricky part if getting the bytevector from the number <mwette>(unpack "i" #u8( #xff #xff #xff #xfe)) => -16777217 <old>Oh well that way simpler <mwette>(pack "i" -123) => #vu8(133 255 255 255) <mfiano>mwette: No worries, but I just noticed a problem :) <apteryx>this works to translate a 4 bytes network byte ordered value into a (list of) signed integer: (bytevector->sint-list #vu8(0 0 #x8c #x41) (endianness big) 4) <mfiano>mwette: Did you know that you are using Tab characters for indentation and you editor is not converting them to spaces? It makes it very hard to read on GitHub. https://github.com/mwette/guile-contrib/blob/main/struct.scm#L132 -- Notice how the `case` clauses are not indented correctly. It took me like 30 seconds to even spot the `case` operator...I was trying to parse it as `let` bindings :D <old>Eh you might want to add `car' in there <mfiano>I find it odd that there isn't a `uint->byte`, but I am quite new to Scheme. Is it because there is no first-class byte type? <old>what would uint->byte should do? <old>(define (uint->byte X) (logand x #xf)) ? <mfiano>err, I'm sorry. I mean uint->bytevector, with same signature, to prevent consing the 1-element list every invocation. <old>would have to read r6rs to know why <old>I mean, uint->bytevector is a specialization of the more generic uint-list->bytevector <old>There could be a simple syntax available <old>From what I can see, the list variant does a single allocation of the bytevector at the expanse of iterating twice over the list <mfiano>Yeah it just seems like this could hurt in a tight loop if the compiler didn't constant fold it away, when it is a useless container (the list) in the single-element case. <old>It will definintely impact a tigh loop <old>Having to do (length (list X)) every time <old>just that is at least a possible cache misses <mfiano>Right. Is this worth raising on the ML do you think? <old>I'm not sure. Since this is a r6rs modules, I don't think we're suppose to add thing in that is not the the standard <mfiano>Thanks. I have an unrelated question about Scheme that your code made me remember to ask about. <mfiano>Well I guess not. I don't really have a question anymore. Ignore me and thanks again :) <mfiano>Does Guile allow programs to (potentially) use all available system memory, or is there some parameter to tweak the size or something? <old>hmm IIRC you will get some problem with the GC <mfiano>When? Why? and which question was this addressing? :) <old>if Guile allows to use all avaiable memory <old>Allocation are made by the GC, and I think there's some limit I'm not sure <mfiano>Ok, my question is more like: In a lot of CL implementations, you can invoke the binary with an upper bound on the heap size. Is this possible? <old>Well you can your answer with: <old>(iota 100000000000000000000000000000000000) <old>Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS <mfiano>Ah ok, thanks. I was looking in the wrong places (not for env vars) <old>but you won't find this in Guile source <old>and they are not environemtn variable .. <old>but these are "heap segments" <mfiano>Interesting. I didn't know bdw hard codes heap size!? <old>for really controlling the heap, I guess cgroup can be used on Linux or rlimit <old>I was kind of disapointed by that. Some application do require lots of allocations <old>it should let the system decice on when too much memory is being used <mfiano>Indeed. What is the hard coded value (if you happen to know off hand) ? <mfiano>I guess I'm not sure if MAXINCR is sector size or what. I will dig later. <old>MAX_HEAP_SECTS is either 812920, 7680, 384, 128, 1024, 512 <old>all depending on the configuration at compile time <old>MAXHINCR is etiehr 2048 or 4096 <old>maybe this limit will be removed with the wipet GC from wingo idk <mfiano>whippet, and I can't wait to hear more about it soon :D <old>Yes I hope we get something to feed on during the FOSDEM <old>Also, there's patches for allocating big data with mmap. That could reduce memory usage for large application that process huge amount of data <old>not sure if it land in 3.0.9 <mfiano>Good to know. I mean, I don't do a whole lot of it, but there are times I have to process gigantic 4096x4096 or larger 32bit RGBA data, which requires 2 to 3 copies in memory. <old>mmap is your friend then <old>you can overcommit virtual memory with it (allocate more virtual then there's actual RAM) <mfiano>I am not a C person, so I will bug someone about that when the time comes :) <old>You only pay for physical memory when you do the first write access to a page <old>Say your gigantic 4096x4096 use 1000 virtual pages. You pay zero in term of physical memory. Then you read a single byte of a page, so you pay only 4096 bytes (a page) <old>Which can be also very nice for allocating huge matrix where most of the stuffs in it are zeroes anyway <old>s/first write access/first write access of a anonymous mapping or read/write for mmaped file <mfiano>I think that is nice, and it is what SBCL does (allows overcommitting), but like I said, I know nothing about manual memory management or the languages that use them, like C for whatever implementation of libc. <old>Never late to learn :p <mfiano>Never too early to learn to love lisp <old>ACTION see that guile 3.0.9 is now on Guix