Big strings

[dbenoy]

I have created a 24-bit color library in MUF and I'm running up against the string size limit a lot.

24-bit ANSI codes are quite lengthy (This is what white looks like: "\[[48;2;255;255;255m"), and if they are applied frequently within one string (say to display some ANSI art like some kind of map for navigating the MUCK, or to display a long list of colored items somebody left lying in a room, etc.) even fairly normal use cases can potentially use up the buffer.

Ideally the string buffers would be dynamically sized, but perhaps that'd be a tall order.

For my own MUCKs I may just go in and boost the buffer size for now, but I thought I'd bring it up.

[wyld-sw]

I'd certainly be in favor of making a simple string_buffer struct for our use. It would certainly be an undertaking to switch to it, but may be worthwhile - as a potential move to C++ is probably a version or two in the future.

Thoughts?

[tanabi]

@dbenoy you probably know this, but that BUFFER_SIZE variable is used literally everywhere so expect a potential memory jump. I'd be curious how much of a jump; of course fuzzball comes from an era where memory was at a premium, so TBH you probably won't even "really notice" it. But if you're running it on sparce hardware (like a Pi or a cheap VM) it could potentially hurt.

@wyld-sw I think there's already a string struct somewhere? Not 100% sure but I'm pretty sure I saw it. I would say 99% of the MUCK relies on that BUFFER_LEN define, though, no joke. Converting to use a string_buffer in any meaningful way will be a huge undertaking, as basically everything that handles a string in the MUCK allocates a stack variable with size BUFFER_LEN and relies on strings being no larger than that.

So while we could, for instance, make the output buffer more dynamic, all the things that feed into the output buffer will still be restricted to BUFFER_LEN unless we go through and convert them to be dynamic as well ... and then we start hittng into weird cases where strings can be infinitely long in these limited cases, but get cut off at BUFFER_LEN in these other cases, and it just gets kinda crazy.

Personally, I think we should hold off until we're in C++ land, because the conversion will be a lot easier and more natural then. We would be touching a -lot- of code in order to make this work otherwise.

[dbenoy]

I can't disagree with any of this.

I just gotta deal with the fact that sometimes lines will get long and things will crash and try to write my code so that if it's going to crash, it doesn't do it at an inopportune moment, like after giving a player some sort of benefit but before taking payment, or after executing some task but before/during delivering a message telling wizards that somebody is doing something strange.

[wyld-sw]

Agreed, @tanabi. I don't think shared_string currently has the API to nicely add and remove, but I certainly understand that there's bigger fish to fry at the moment.

[tanabi]

This may be a good reason to bump up the C++ conversion to a higher priority. We can even consider things like doing a gradual conversion ... once we build the core bits in C++, a lot of stuff (like MUF prim code, etc.) can remain in C for awhile.

[dbenoy]

This pretty much sums up my feelings about object oriented programming: https://www.youtube.com/watch?v=QM1iUe6IofM

I'm no fan of C++.

But I also don't think it would hurt this particular project to switch over to it. C++ is decent stuff, so long as nobody goes nuts and starts encapsulating everything into objects in the bad ways described in that video.

But if that were the case, there would never be a need to have a 'conversion' at all, perse. Could just start compiling in C++, and then just start to use C++ strings and arrays and such whenever it's more convenient to do so, but keep the procedural-oriented design of everything in tact forever.

[tanabi]

One must always do what makes sense :)

We actually have a number of cases where inheritence would make a lot of sense. For instance, we have like, what, 3 different implementations of B-Trees? Each one ~slightly~ different in structure but with 85% code overlap?

Our options there are to either make one B-Tree to rule them all, which means we're wasting memory because there are some subtle but valid variations between the 3 ... or we use inheritence and then we can share the common code but allow the data structures to vary a bit.

Making objects in the MUCK actual objects, so that we can have methods on them to do common things like figure out flags, figure out if object X can link to object Y, etc, all make sense.

But we don't have to eliminate procedural things "just 'cause". The core of the software will likely always retain its current structure, just objects make sense in certain places.

[dbenoy]

Excellent, I think you get the gist of what I'm saying then :) Never would we want to make a main loop class, or command handler class, or something like that.

In which case it doesn't seem like much hassle at all to C++-ify it, and just start gradually taking these little constellations of self-contained data like you describe and turning them into objects as needed.

[dbenoy]

Although personally I'm a lot more reluctant to objectify things. I wouldn't make 'can X link to Y' part of the object's methods. Only anything relating directly to its data.

You can just as easily make a can_link_to(object1, object2) procedure.

But... I've laid my anti-OOP bias out for you, so this is yours to take with a grain of salt :)

[wyld-sw]

I think we’re all on the same page. Using objects “because OOP!” does no one any favors. I think we’d start with simple data structures that increase maintainability for sure.