[bercedev]

Fixes #1600.

went with what you found in the comment: shrink used dflt-len unqualified, and a defndynamic resolves from the root, so it never saw the dynamic one in the Map module. it's Map.dflt-len now, same as the other funs use Map.min-load.

added two tests to test/dynamic_map.carp: shrinking a fresh map leaves it at 16 buckets, and shrinking a 64 bucket map gives 32. on master that file now stops with Can't find symbol 'dflt-len' at core/Map.carp:711:25, with the fix all 37 tests in it pass.

i ran the other test/*.carp files too, same results as master apart from the new tests (init_global, managed, memory and unsafe don't pass in my container on master either, so i left those alone).

[hellerve]

Hi Berce, and thanks for contributing. Just one question: what was the role of AI assistance in this patch? We’re not against AI-assisted development, but we ask that people are transparent about it. Also, especially on issues marked "beginner", we’re mostly interested in people who want to start engaging with the project rather than drive-by contributions.

[bercedev]

hi, honest answer: the code was written by claude code, and i tested it locally before opening the PR (built carp with gcc and ran the test suite, including the new tests). totally get the point about beginner issues, if you'd rather keep those for people starting out with the project i'm fine closing this one

[hellerve]

thanks for your candor! was this meant more of a drive-by, or did you want to enter the community? if it’s the former no hard feelings at all, but i think we should close this.

[bercedev]

not meant as a drive-by, i'd like to stick around and keep contributing, mostly fixes through PRs like this one. if that works for you i'm happy to keep this and #1608 open and work through any review

[hellerve]

works for me! feel free to join the discord, too, since that’s where the chatter happens :)

[hellerve]

I think this is correct, but it doesn’t fix #1600 completely (the remove and put bugs are unfixed).

[bercedev]

good catch, pushed fixes for both: put now grows past max-load, and remove drops the key from its own bucket first and then shrinks one step when the load is below min-load and the map is bigger than dflt-len (same as the static shrink!). while in there i found the old remove also rebuilt the bucket list with reduce/cons, which reversed it, so after a remove other keys could end up in the wrong buckets. added tests for the three cases, they fail on master. all of test/*.carp passes locally (77).

[hellerve]

The doc says a missing key returns the map unchanged, but we now check the siz and shrink first.

[bercedev]

right, fixed in cf5338c: remove now returns the map as is when the key isn't there, so the doc holds again. added a test for that (a sparse 64-slot map keeps its size when you remove a missing key). full run_carp_tests.sh passes.

[hellerve]

(> (length removed) Map.dflt-len) is already in shrink. calling shrink on thefirst condition is enough.

[bercedev]

right, dropped it. remove doesn't recurse anymore, so shrink returning the map unchanged at the default size is enough. tests still pass (test/*.carp 77, error tests 50).