You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Plan9port's sam doesn't have this limit, and since sam was intended to easily modify many files, I think this sam should remove it, too.
Sam's lack of internal limits and sizes is a virtue. Because it avoids all fixed-size tables and data structures, sam is able to make global changes to files that some of our other tools cannot even read.
—Rob Pike, The Text Editor sam
A quick ag for this constant reveals it's used to initialize static sized arrays in a few places:
~/src/sam master
❯ ag MAXFILES
samterm/menu.c
8:uint8_t *name[MAXFILES]; /* first byte is ' ' or '\'': modified state */
9:Text *text[MAXFILES]; /* pointer to Text associated with file */
10:uint16_t tag[MAXFILES]; /* text[i].tag, even if text[i] not defined */
233: if(nname == MAXFILES)
samterm/samterm.h
5:#define MAXFILES 256
The stupid solution would be to just increase this to some other limit (512 or 1024 to stick with nice round numbers), but that runs into two problems imho:
How much memory does that use? It may be non-negligible. It's all well and good for me with my if-you-have-to-ask-you-can't-afford-it workstation with HOW MUCH!?!?!?!gb of RAM to go around allocating fucktonnes of memory, but until fairly recently I was editing on an X200 with only a few gigs; and being as we support 32-bit systems, maybe we shouldn't go crazy with memory usage.
It's just kicking the can down the road. Someone will eventually hit that limit and re-open the issue.
I suspect a "stretchy" buffer would be the correct choice here (that is, a crude implementation of an arraylist, where we realloc the memory when we're in danger of running out). That would require a significant refactor.
PRs are open!
The text was updated successfully, but these errors were encountered:
255 is an awful lot, but if you're using sam as your primary editor and are lazy about cleaning up files it is possible to hit it.
deadpixi#110
A quick
ag
for this constant reveals it's used to initialize static sized arrays in a few places:The stupid solution would be to just increase this to some other limit (512 or 1024 to stick with nice round numbers), but that runs into two problems imho:
HOW MUCH!?!?!?!
gb of RAM to go around allocating fucktonnes of memory, but until fairly recently I was editing on an X200 with only a few gigs; and being as we support 32-bit systems, maybe we shouldn't go crazy with memory usage.I suspect a "stretchy" buffer would be the correct choice here (that is, a crude implementation of an arraylist, where we realloc the memory when we're in danger of running out). That would require a significant refactor.
PRs are open!
The text was updated successfully, but these errors were encountered: