LoginLogin

[Translation, not bug report] Official SB known bug update

Root / SmileBASIC Bug Reports / [.]

LohadLCreated:
SquareFingers#21
Look, I completely see what you're saying and you're right, but there's a massive difference. SmileBOOM is, evidently, not great at documenting their language. We get some differences, some big and some small, between how the documentation says the language behaves and how it actually behaves. This poses just one question: which should be fixed, the implementation or the documentation? This is a question that can only be answered on a case-by-case basis. In the case of MPSEND "", I think the documentation is wrong. Now there's one major caveat about documentation errors: SmileBOOM don't bother fixing them. In fact, as lohadl translated the Japanese documentation has the same error, and I'll bet that they won't even fix those. This is THEIR problem, you can hate them for it, but let's take it as a fact that documentation errors will not be fixed in the official documentation. That leaves us just one option: maintaining our own, corrected mirror of the documentation. If we do that, we would be able to correctly document all the quirks of the language that weren't faithfully explained in the official docs, and everyone would be able to just refer to that one for everything! Regarding actual bugs in the SmileBASIC code, it's obvious that SmileBOOM is dedicated to fixing those, so we have no problems there :)
Look at the top of the page. Does it say "How to help SmileBoom with documenting their language"? Does it say "What should be fixed"? Does it say "Things SmileBoom might fix"? Does it even say "SmileBASIC 'code' bug reports"? On my screen it says "SmileBASIC bug reports". In the case of MPSEND "", the documentation is wrong in that it does not reflect the behaviour of the implementation, and the implementation is wrong in that it does not do what the documentation says. These are both valid assessments of the situation, regardless of what you think. Let's take one example which you recognise as being "unambiguously" a bug, by which I suppose you mean unambiguously a "code" bug. http://smilebasicsource.com/forum?ftid=90 Say one sentence is added to the manual: "In a DEF line, the variable names must ALL be different". Given the current situation, that is not the change I would like to see them make, and I think you agree. But if that change were made, the problem is no longer in SmileBasic: if someone encounters this and has a problem, it's because they didn't read the manual. It is an undesirable situation, but it is no longer a bug in SmileBasic, it is carelessness on the user's part. The "massive difference" of which you write is not between "bugs in the code" and "bugs in the documentation", it's between people who recognize that they're two sides of the same coin and people who don't.
You would be surprised
I had a paragraph here, but lohadl said it better.
NeatNit#22
... The "massive difference" of which you write is not between "bugs in the code" and "bugs in the documentation", it's between people who recognize that they're two sides of the same coin and people who don't.
Sure, of course I understand that it can go both ways, and indeed there might be some cases where it's not clear which way was intended: the way actually implemented, the way documented, or hell, maybe even a third way which neither one fits. A good example is the VAL() bug - when a string begins with a number but isn't entirely a number, you can either have it recognize the number and return it (ignoring the text afterwards), or instead have it always return 0. Let's say, hypothetically, that the documentation unambiguously said that a string that starts with a number will always return that number, whereas the implementation had it so that any string that isn't entirely a number returns 0. In that hypothetical case, either one of them could be fixed to match the other; The so-called "two sides of the coin". Either way is a valid way for the code to behave, with its own pros and cons. Some cases are less vague though - like the DEF A$ OUT A$ bug - it's hard to justify this limit as intentional. As an accidental quirk, maybe, but if it can be fixed in the code, it should be. I don't think anyone would argue against this - unless they were incredibly biased for whatever reason. Sure, it's possible to have the documentation match the quirk, but it wouldn't be fixing the bug, it would be just acknowledging it. The infamous "it's not a bug, it's a feature" excuse. Any person with an actual understanding of the situation would be able to see that. The MPSEND "" error is an ambiguous one from my point of view. It could be intentional, or, it could be accidental. I can't tell one way or the other... But the fact that it spits out an "illegal function call" right then and there, to me, leans towards it's intentional.
SquareFingers#23
So, you know that what you call a "code bug" can be resolved by fixing code, or it can be resolved by fixing documentation. Presumably, then, you also know that what you call a "documentation bug" can be resolved by fixing code, or it can be resolved by fixing documentation. That is not the distinction you're trying to make. The distinction you're trying to make seems to be about intent - 'which way was intended', 'intentional'. See, I happen to know that SmileBoom consists of more than one person. I know that where there is more than one person, there can be differences of opinion. Even well-meaning people working towards a common goal can have different ideas. It is entirely plausible to me that the coders had one intent in what they wanted to implement and were successful in implementing their intent, and simultaneously, the documenters had a different intent in what they wanted to write and were successful in writing their intent. But you're telling me there is ONE intent. And you know what it is. Actually, no.
12