IRC channel logs

2024-09-03.log

back to list of logs

<gabber>is this a (known) bug? or am i doing something stupid, maybe? https://paste.debian.net/plain/1328248
<gabber>i'd expect my-list to be '(3 4)
<gabber>somehow delete1! does not like 1 as a first argument: https://paste.debian.net/plain/1328249
<morenonatural>may I suggest using `filter` or `take` as an alternative to discarding items from a list? perhaps `tfilter` or `ttake`
<old>gabber: is it not 1 the problem, but simply the first element
<old>(delete1! 1 my-list) will return (cdr my-list) without changing my-list
<old>(delete1! 2 my-list) will remove 2 from my-list by changing the cdr of the first cell, thus mutating my-list
<daviid>jfred: here is how you fix guix to run an unpatched g-golf - https://lists.gnu.org/archive/html/guile-user/2024-09/msg00001.html
<daviid>jfred: maybe you are a guile-user ml member and follow there .. let me know
<gabber>old: but that's not how i understand the documentation. i thought delete1! "deletes the first occurrence of ITEM from LST" - which does not happen in my examples. so maybe it's a documentation bug?
<gabber>morenonatural: filter and take are not really a replacement for delete
<gabber>i have the problem where i roll 6 dice and some of them make up a combination. then i want to separate the 6 dice from the combinations. i can not just filter the roll - maybe only 3 ones are part of the combo and not all 4 and i want to "set them aside"; so deleting them from one list and adding them to another was the most intuitive way to achieve it
<gabber>old: should i prepend my initial list with some element, run delete1! and then set my-list to (cdr my-list)? this feels pretty wrong
<lloda>gabber: you should use the return value from delete! and forget about the argument
<lloda>srfi-1 talks a bit about what these 'destructive' functions actually do
<ArneBab>gabber: to "set them aside" the most intuitive function may be partition (from srfi-1). (import (srfi :11 let-values) (srfi :1 lists)) (let-values (((taken set-aside) (partition even? '(1 2 3 4 5)))) (list taken set-aside))
<ArneBab>⇒ ((2 4) (1 3 5))
<old>gabber: The documentation says this about `delete!': Caveat evaluator: Like other destructive list functions, these functions cannot modify the binding of LST, and so cannot be used to delete the first element of LST destructively.
<old>If you are mutating a top-level binding, then you can do: (set! my-list (delete1! 1 my-list))
<old>note that this won't work if passing your list as a arguments to a function ..
<lloda>imo the doc IS confusing. These functions are meant to consume the argument to produce the result, not to modify the argument, bc as you say, a function cannot do that in general (on top of the other reasons given in srfi-1). But the doc somewhat presents the function as something that modifies the argument, but then it doesn't work sometimes. That's no good
<lloda>doc should straight say: don't reuse the argument.
<old>The doc does mentionned this with acons mutation I believe
<old>Like, you need to do set! + assq-set! to actually mutate a variable
<old>perhaps that ought to be explained like this for delete! and family
<cpli>i remember an old sbcl project that allows you to make use of simd; is there support for any form of inline assembly in guile?
<dthompson>no
<cpli>correction: i would even enjoy unsupported forms.
<dthompson>inline asm could come into play if guile gets native compilation someday. hoot has an inline wasm form, for example.
<cpli>how does the dlopen/foreign extension jump into loaded shared objects? if i can't do it right, i'll do it cursed.
<cpli>oh, i thought lightening was native comp
<dthompson>it is... but it's for the jit compiler
<dthompson>if it was aot compilation then inline asm could be an option. I'm curious if guile would want to expose such a thing, though. inline wasm is different in the sense that it's not specific to a single cpu architecture.
<cpli>i guess there's wasm simd at this point
<cpli>so that would "solve" my problem too
<dthompson>wasm simd is so annoying lol
<cpli>it is?
<cpli>it sounds horrendeous
<dthompson>guile doesn't do anything with simd as far as I know
<dthompson>the simd instruction set is huuuuge
<dthompson>even for wasm which only has a subset that is supported well enough across all major architectures
<Arsen> 20:52:37 <dthompson> it is... but it's for the jit compiler
<Arsen>that doesn't preclude an always-jitted fn with inline asm really.. but the whole concept seems messy
<dthompson>would be nice to have simd optimizations when necessary, though.
<dthompson>might need to pay someone good money to deal with that though ;)
<Arsen>not if one links libgccjit in ;)
<cpli>eh, i was thinking of using simd to write well-performing mesh optimization in guile, but at this point i'm thinking about maybe just using a compute shader if the mesh is large enough anyway
<dthompson>I've done plenty of graphics stuff without needing simd, so you can probably go a long way too