Port of ulisp-lispbox text editor for the M5 Cardputer

#1

Hey I ported the text editor @Ginkgo wrote for his lispbox project to the M5 Cardputer. The screen is tiny so I made a bunch of accommodations to make it more useable, but it works quite well with the keyboard. Try it out and let me know if works for you!

Port of ulisp-lispbox text editor for the LilyGo T-Deck
#2

Adopted your less mem-eating split-string-to-list function for the Lisp Box, thx!

#3

Thanks, I feel like breaking up strings in ulisp is tricky with only search and subseq, and I’ve had to write such functions before. If one only uses those two it requires a lot of string copying. On the other hand the search functions I write tend to require a lot of iteration over the same parts of the string. Ideally I would want to get a pointer to a location in a string (perhaps similar to rusts slices?) but I can’t imagine what that would look like in lisp. Or maybe there’s techniques that I’m missing. Either way strings in ulisp don’t exactly work like lists from what I understand so I feel like we as a community should think about how to approach them with performance in mind.

#4

As far as I can see, strings in uLisp seem to be organized efficiently - but the memory killer in my approach was recursion, I believe. Great you changed it into an iteration!

#5

To give a detailed explanation: it’s the combination of recursion and the fact that subseq makes copies of the string. If you did recursion on a regular list it should be fine because cdr would give you a “pointer” to the rest of the list whereas your use of subseq makes a whole new string every time you pass the rest of the string to the function. I believe where the recursion made it worse is that the intermediate strings couldn’t be garbage collected until the recursive function calls returned. If you set an external variable with the new intermediate string every recursive function call then that would drop the earlier string and let it be garbage collected, which should solve the memory problem afaik. If I thought of that initially I might have written it that way. What I did write doesn’t create intermediate strings though so it should be more performant overall.

For the record I think about these sorts of issues too much and it gets in the way of writing actual software so I think its better to just get it done and optimize it later, as the famous quote suggests.

#6

Thanks for sharing your insights! I’m not yet that much familiar with the internal workings of uLisp and tend to be a bit ignorant about this stuff until I run into problems… so I guess we’ve met right in the middle here, which is probably how Open Source should work. :)