IRC channel logs

2024-03-04.log

back to list of logs

<old>For example this: https://paste.sr.ht/~old/615eb18693dfa3fa4989232544de7dc69a70bc24
<mwette>oh. Maybe bytevector-copy!
<old>the bytevector-slice are bottleneck here
<old>mwette: that copy the bytes, I only want to shift the view of the bytes!
<mwette>Without allocating anything. Not sure how that is doable. The pointer trick at least should only allocate a couple bytevector headers: no contents.
<old>if only allocating a single slice
<old>then mutating it
<old>that's how I think
<flatwhatson>gotta pass around offsets instead of taking slices
<old>sure, but then it require specialized code for primitives that could just work with
<old>without offset
<old>it is just simpler to assume offset = 0 everywhere and shift the bytes pointer in the slice at the top instead
<ft>Aww. I thought -slice gave me a lightweight view into a bigger bytevector, too. Oh well.
<flatwhatson>it does! it's just not free to create them
<ft>Maybe I misunderstood. Allocating memory for the required meta data is unavoidable, of course. Sounded to be it did copy the data for slice into a fresh bytevector, though. That would have been surprising to me.
<flatwhatson>right, in old's example he wants to allocate a slice per element, so the next elements are always at offset 0/1
<flatwhatson>this would be fine *if* you could mutate the book-keeping record
<flatwhatson>re-using the existing allocation instead of creating garbage for every element
<ft>Ah I see. Like sliding the slice across the original buffer.
<ft>Maybe I should just look at his code example. :)
<old>flatwhatson: exactly
<flatwhatson>i like this approach for parsing, usually create some kind of "cursor" record with a few peek/read primitives which update the offset implicitly
<old>So bytvector-slice! or bytevector-slice-shift! has its usefulness :-)
<old>hmm bytevector-slice keep the immutability of its parent, which prevent mutation I guess
<old>ah no that's related to the bytes not the contianer
<mwette>old: did you look at arrays?
<old>mwette: why would I?
<old>I know that there's some kind of operation on them. But bytevector are prefered in my case. I want to be able to bytevector->pointer to pass the underlying byte to C
<ArneBab>Last weekend I finished the changes for SRFI-234 (topological sorting) and there’s now a last draft. It would be great if you could take a look! https://srfi.schemers.org/srfi-234/srfi-234.html — for discussing: https://srfi-email.schemers.org/srfi-234/msg/24424728/
<lloda>guile arrays wouldn't help in the problem above bc there is no function to set the array base
<lloda>array-slice-for-each which is written in C works by setting the base, but then it copies the descriptors when calling to Scheme so that the mutation isn't seen there, which is probably a bad choice
<lloda>most of the time the Scheme code doesn't care, and when it does, i don't think it's unreasonable to make it responsible for copying the descriptor
<lloda>ofc right now there's no function to copy an array descriptor, since they are immutable :p
<lloda>tbh this looks like something the compiler could optimize. (let ((slice (advance-slice slice))) ...) could construct the new slice in the place of the old like rvo in c++
<lloda>ACTION not a compiler writer and i'm sure this is hard to do
<lloda>> (time-nanosecond (let* ((a (current-time)) (b (sleep 1)) (c (current-time))) (time-difference c a)))
<lloda>= 1049000
<lloda>it looks like time-nanosecond doesn't count nanoseconds but time-resolution steps
<lloda>nvm i'm dumb :-/
<graywolf>Is it a good practice to use ->bool in predicate procedures?
<lloda>predicates return #f or not #f and are usually marked ?
<lloda>if your function specifically returns #f or #t and nothing else it might be ok to name them ->bool idk
<graywolf>I mean should I write (define (x? y) (string-match ".." y)) or (define (x? y) (->bool (string-match ".." y)))
<graywolf>->bool is built in, I just wonder whether it is a good practice to use it
<graywolf>Or what the use case for it is
<lloda>i've never used it
<lloda>i think it's very unusual for functions to require #f/#t. It's always #f/not #f in scheme
<graywolf>Cool, thank you :)
<lloda>👍
<graywolf>I have a string binding to a variable (define foo "arstarst"), how can I use it in a pattern matching? (foo) binds identifier foo, but I would like to match ("arstarst"), but keep the string in a variable.
<graywolf>I guess I could use (? (cut string-equal? foo <>)) but I wonder if there is less verbose reprezentaion
<chrislck>sneek: botsnack
<sneek>:)
<mwette>graywolf: (match "arstartst" ((? (lambda (f) (equal? f foo))) #t) (x #f))
<mwette>graywolf: or you could use (define-syntax foo (identifier-syntax "abc"))
<mwette>then (match "abc" (foo #t) (_ #f)) => #t
<lloda>i think the idea is that foo could be anything at runtime
<lloda>i think you p much have to use ? the way match is designed
<sneek>chrislck: Greetings :)
<old>graywolf: I think ->bool is equivalent to (lambda (x) (if x #t #f))
<old>I typically do something like: (define (x? y) (and (string-match ".." y) #t))
<old>but ->bool would be good for that
<graywolf>Actually no, the foo is just a (really) long string that I want to keep separate for readability, but it is a constant. The define syntax looks interesting, thank you.
<graywolf>old: I am mainly not sure whether it is preferred to actually to the conversion to #t/#f or just leave it as it is
<graywolf>actually do the*
<old>graywolf: if it ends with ?, it ought to return either #t or #f IMO
<old>the important thing is that the caller should not expect someting useful from the function other than branching with its value
<graywolf>efraim: Quick question regarding your review for #69526: Does your request "inserted and sorted alphabetically" mean that even the commits adding the rust-hickory-* should be sorted by alphabet?
<graywolf>uff, wrong channel
<mwette>graywolf: the identifier-syntax one does not work (as written, at least)
<mwette>(match "axc" (foo #t) (_ #f)) => #t
<dsmith>sneek, botsnack
<sneek>:)
<dsmith>!uptime
<sneek>I've been a process for 7 days
<sneek>This system has been up 48 weeks, 1 day, 23 hours, 26 minutes
<old>almost a year for sneek!
<dsmith>No. Only 7 days.
<old>ahh the system is up for a year
<dsmith>The beaglebone has been up almost a year
<old>sneek must be restart often?
<dsmith>Was restartig a lot a few years ago. Fixed some bugs in nick procesing and has been good since then.
<dsmith>Last time I started it by hand was around last september.
<dsmith>It's been running fine since then until a week ago.
<dsmith>(In Sept I added the speak-like-ap-pirate hack)
<old>what happen a week ago?
<dsmith>No idea. Was as surprise to see that.
<dsmith>Feb 25 19:14:29 EST some deprecated feature was used. 30 seconds later systemd restarted it.
<old>hm
<old>would be interesting to see the logs of IRC chats where sneek is during that time frame
<old>to see if it is possible to reproduce this deprecated stuff
<old>Funny to see sneek was killed -- and reborn -- at my birthday
<dsmith>The logs at http://logs.guix.gnu.org/{guile,guix}/ do not have parts and joins
<old>maybe too much botsnack
<dsmith>heh
<old>If anyone is interested, I made a little wrapper around the porkbun API for Dynamic DNS