IRC channel logs


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>ah, nevermind
<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
<dthompson>ohhhh I misunderstood your question
<dthompson>you aren't starting with the raw bytes
<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>(use-module (struct))
<mwette>(unpack "i" #u8( #xff #xff #xff #xfe)) => -16777217
<old>Oh well that way simpler
<mwette>(pack "i" -123) => #vu8(133 255 255 255)
<mwette>but less efficient
<mwette>struct.scm is in
<mfiano>Oh it's not builtin :)
<mwette>sorry -
<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. -- 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>would not hurt
<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?
<mfiano>(for Guile, that is)
<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
<old>here's a quick one:
<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>go ahead :-)
<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 ..
<mfiano>Usual :)
<old>C define hard coded
<mfiano>Oh I see
<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>right whippet sorry
<old>Yes I hope we get something to feed on during the FOSDEM
<mfiano>it is going to be a good week
<old>I hope so!
<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>and so on
<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