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

6. The negative sign is uncolored (<-it's a bug?)

That's referring to the editor's syntax highlighter. If you type something like "PRINT -1" into the editor, the - isn't colored the same as the 1.

Thank you for the reply. I personally don't think it's a "bug" but more like an aesthetic issue since I don't discriminate between the minus sign and the negative sign, but this isn't about me. Fine :p Pres. Kobayashi gave me an update on the VAL("12 giraffes") issue: It'll be fixed in the next version and such leading-number strings will return 0.

Ah, so they're finally gonna color the - sign when used in number literals? Nice.

Thank you for the reply. I personally don't think it's a "bug" but more like an aesthetic issue since I don't discriminate between the minus sign and the negative sign, but this isn't about me. Fine :p

I agree that this is not a bug, and furthermore, I anticipate that their 'fix' may introduce another aesthetic issue which is even worse.

Pres. Kobayashi gave me an update on the VAL("12 giraffes") issue: It'll be fixed in the next version and such leading-number strings will return 0.

That's disappointing, I was rooting for the leading number to be interpreted. Still, as Square said, it's better than the current situation :)

So I tried to read through all the other bug reports on this forum to see if there's anything interesting, but all this "it's not a bug but just a translation error/ hole/ hack/ lack of explanation" talk confused me as I'm not versed in the coding jargon at all. As a result I think I'll report nothing at this moment.

There are two that I think are unambiguously bugs: http://smilebasicsource.com/forum?ftid=90 and http://smilebasicsource.com/forum?ftid=96 Edit: nearly forgot this one: http://smilebasicsource.com/forum?ftid=171 Regarding the translation errors / ambiguous documentation, I think it's not worth the bother to get them to fix it. Instead we should set up a community-maintained documentation, similar to the Garry's Mod Wiki. Edit: Some notes. I once sent SmileBOOM an email listing many translation errors, typos and mistakes in the official instructions list. That was kind of a long time ago. It has not been acknowledged. This is why I don't think they'll bother improving the docs, even if we tell them exactly what to change it to. This is the email I sent:

Thank you for you time to send your report/inquirey. The following content was sent to SmileBoom. ──────────────────────────────────── Category : Reporting a mistranslation in SmileBASIC Public Key / Product Version : none Your report/question: Hi, I've been using the reference online ( http://smilebasic.com/en/reference/ ) and noticed the following mistranslations: 1. The navigation bar, with all the links to the #anchors, says "sprties" instead of "sprites". 2. in COPY (1), the description for Copy Source Offset says "First element to be overwritten", using the word "overwritten" instead of "copied" 3. TABSTEP, SYSBEEP and other writeable variables should have their defaults listed. 4. Under CONSTANTS: '--- ATTR #TROT0 '&H00 needs a linebreak, and needs to say TEXT ATTR: '--- TEXT ATTR #TROT0 '&H00 5. The Bit section has Japanese text. If I find any more errors, I'll be sure to let you know. P.S. is there any release date estimate for SmileBASIC in the UK? ──────────────────────────────────── If you have received this message in error, please contact us at info@smileboom.com.

Most notably, the header for the bitwise operations section is written entirely in Japanaese. The other ones are relatively minor. lohadl, unrealatedly I must ask - is the MPSEND command documented well in Japanese? Square said it best in this thread:

- A large number of MPSEND calls in a short period will result in an error * Communication buffer overflow

Yes, about as useless a piece of documentation as it is possible to write. What is a large number? What is a short period? "There is an error. It will occur sometimes. It might not."

If the Japanese instruction is more clear on this, please tell us. :)

As to what are 'unambiguously bugs': http://smilebasicsource.com/forum?ftid=16 How to crash SB http://smilebasicsource.com/forum?ftid=63 VERY bizarre behavior regarding filename DIALOG caption string and % symbol These threads show ways that crash SmileBasic. That should just never happen. If there is just one more bug besides those in NeatNit's post that I'd like to see fixed, it's: http://smilebasicsource.com/forum?ftid=84 MPSEND "" gives error

If there is just one more bug besides those in NeatNit's post that I'd like to see fixed, it's: http://smilebasicsource.com/forum?ftid=84 MPSEND "" gives error

To be fair, I don't think that one is a bug. Simply, you can't send an empty packet. Might be a documentation hole but as we've discussed, that doesn't make it a bug. Do the Japanese docs mention anything about this?

If there is just one more bug besides those in NeatNit's post that I'd like to see fixed, it's: http://smilebasicsource.com/forum?ftid=84 MPSEND "" gives error

To be fair, I don't think that one is a bug. Simply, you can't send an empty packet.

To be accurate, regardless of what you think, the documentation describes the argument to MPSEND as "Character string of up to 256 bytes", and character string of 0 bytes matches that description.

Might be a documentation hole but as we've discussed, that doesn't make it a bug.

As we have discussed, it is common for experienced programmers to describe flaws in documentation as 'bugs'.

Oh...oh my gosh, my head. OK, translations first. 1. The MPSEND English translation is faithful to the Japanese text. I translated it without referring to the English site for fun and this is what I got: MPSEND: Sends data to all participants in a wireless communication session - The data transmitted will definitely be sent but delays happen - If you call many MPSEND instructions within a short time, the following error will occur: (*C.B.O.) - Communication will be cut off upon entering sleep mode Up to 256 bytes of character strings will be sent. 2. >Untranslated header (ビット演算: 数値に対してビット単位で演算を行う機能) Bitwise operations: Functions that perform operations on a numerical value at the bit level. 3. I'm just speculating so don't quote me, but from his past tweets I learned the following things: a. Kobayashi lets his English-speaker team handle SmileBASIC business (I deliberately make the distinction between our English SmileBASIC and their Japanese Petitcom 3), as he admitted he's not well-versed in English comprehension. b. He does not disclose anything about his English team, so by extension I have no idea who to contact or who actually WILL read your emails. I've long given up on correcting the English site -- I could just give you my translation here! c. Their plan was, and probably still is, to see how SmileBASIC in NA is doing before making an announcement on an EU release. Note that they plan to translate all major European languages (French, German etc) so that certainly is another factor that might drag down your release. Plus they have the Ogiri contest in January to worry about, so I imagine everything else (like the EU release) will have to take a backseat. *I am not their spokesperson, just making my conjecture.* === Time-wasting Drivel Alert =========== I have a confession to make. I'm a licensed translator and my expertise is in creative arts, NOT technical stuff. That's why I'm comfortable with translating manga, anime, and fanmade games like Plane2Solid. But the moment I read a programming discussion, my brain completely overheats and shuts down, even if I know the presenter tries their best to use simple English. I read all three of the threads you posted. My brain goes: "Oh my god, what are you tech savvy people talking about? It's all greek to me. OK, so calc84 and pirate seemed to think that the DIM thing is a design, but SquareFingers reckoned it's a bug albeit a minor one. But what do I think? I don't know. The VAL one was easy to reproduce and comprehend. I can see myself using that command someday. But will I ever use CLEAR and DIM together? There's a workaround for DEF OUT. What EXACTLY is MPSEND for? I can never test it out since I only have one 3DS. If I don't know myself, how can I possibly tell Kobayashi in my own words? I can't just translate what I think you guys are saying and show him your screenshots. The fact that I'm just parroting will show. Yes I know you guys are using simple English, but call me stupid, I just don't understand." I still don't know if those three were design quirks (like having to use EXEC instead of just USE) or unintentional bugs. Half of my brain just refuses to process further, and the other half probably doesn't care or know what to think. I can try sharing these with my Japanese Petitcom friends and see if they can explain to ME in other terms, or tell me why they matter like if they'll mess up their JRPGs. But before I do, I can't help as of now, sorry.

Squarefingers is fastidious about his programming; I think he's looking for a manual where every detail of the implementation is made known in a semantically correct way, with absolutely no assumptions. For instance, MPSEND says you can send messages up to 256 bytes, which would of course include 0 bytes. MPSEND doesn't work with a size of 0, which is an assumption you could probably make or discover on your own, but Squarefingers would like it to be documented. This is NOT to say Squarefingers is doing something wrong or that he is incorrect; Squarefingers, please don't take this the wrong way. I'm not trying to make this negative; worrying about the details is usually a good thing in programming. I'm trying to describe the numerous bug reports in a manner that is easier to understand from a non-programming view.

Scholastic is a better word :) I know exactly what you're saying. Being the scholastic translator, can I ask something stupid though? Does SB even know a 0-byte string is a "string", or will it just consider it "emptiness" and not a string at all? (Apparently it's acting so.) If I make a game that says "Enter your name, up to 7 characters", I don't really expect you to type nothing -- to me you didn't enter a name. Is a 0-byte string really a string in SB language? Here's another thought I'd like to share: The fact that he's willing to reply means something to me. While I agree a scholastic programmer may regard doc flaws as 'bugs', if I were to parrot that to him, *I* would likely to be regarded as "nit-picking". If God forbid he gets annoyed and stops replying to me, I lose a valuable access. Therefore I should and will only report bugs that truly matters to us laypeople -- the VAL inconsistency was the best example. The crash-your-SB-challenge seems interesting and I might report that, but maybe we're just abusing its memory.

Yes, 0 byte strings are still technically strings. The type is probably saved with the variable, so although the variable is "empty", it's still marked as a string.

I'm happy to be called a pedant. I know my style of writing, and the style of documentation I'd like to read, isn't everybody's cup of tea. But even if the destination I have in mind isn't the best possible for everyone, I think the system would be improved if it were pulled in that direction. lohadl: no oath or bond is laid on you to translate further than you will. You will find opinions and information here, not all of it is for you, and that's fine. Not all of it is for me either (I have not once used a sprite, for instance). Do what you feel is best, within your zone of comfort. And, a string variable that contains no value is demonstrably different from a string variable that contains an empty string.

CLEAR
OK
?VAR("A$")
Undefined variable
OK
A$=""
OK
?VAR("A$")

OK

EDIT: I'm also fine with 'fastidious'. It's accurate enough, and after all, accuracy is a big part of what I'm after. :)

Thank you randomouscrap and SquareFingers. I really hate to disappoint people, so if it's within my capacity I will help out. Gee, if only I were more experienced to be able to fully comprehend and appreciate all these bugs. But that will take at least another year.

One more thing. I have never used Twitter, and I do not anticipate I will ever use Twitter. So this is from an outsider's perspective, but I have a strong feeling that Twitter is really not an appropriate venue for bug reports. On the page http://smilebasic.com/en/contact/ there is an option "Reporting a problem in SmileBasic" (and I believe there is an equivalent on the Japanese website). There is a thread in Miiverse, in the official English SmileBasic thread, specifically for reporting bugs. Where there are official channels for these things, which can be sensitive matters politically, it is best to use them. I appreciate what you've done, and I am speaking from ignorance, so... do with this what you will.

don't quote me

I'll do what I want!!! >:(

If there is just one more bug besides those in NeatNit's post that I'd like to see fixed, it's: http://smilebasicsource.com/forum?ftid=84 MPSEND "" gives error

To be fair, I don't think that one is a bug. Simply, you can't send an empty packet.

To be accurate, regardless of what you think, the documentation describes the argument to MPSEND as "Character string of up to 256 bytes", and character string of 0 bytes matches that description.

Might be a documentation hole but as we've discussed, that doesn't make it a bug.

As we have discussed, it is common for experienced programmers to describe flaws in documentation as 'bugs'.

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 :)

Thank you for the reply. I personally don't think it's a "bug" but more like an aesthetic issue since I don't discriminate between the minus sign and the negative sign, but this isn't about me. Fine :p

I agree that this is not a bug, and furthermore, I anticipate that their 'fix' may introduce another aesthetic issue which is even worse.

I can't imagine there being any issue as long as they keep it so the - sign is highlighted only when it's next to a numeric literal. Coloring it anywhere else would be wrong because math operators aren't colored.

I have a strong feeling that Twitter is really not an appropriate venue for bug reports.

You would be surprised. It seems like what is reported on Twitter is more likely to actually get fixed/implemented, possibly because Kobayashi himself actually sees all of the reports. From what I can tell, most all the bugs listed on the Japanese site are ones that are reported to him through Twitter. I would agree it is a poor choice for nitpicky bugs, but otherwise it's guaranteed that it will actually be seen, and (assuming you address him in Japanese) you get a response much faster than the other routes.

It's like the chain of command. Twitter bypasses the "lower-ranked" website contact, email, Miiverse and the info goes straight to the "highest-up". This is by definition inappropriate and unconventional, but what Lumage said was also all true -- VAL gets noticed in just 2 days but NeatNit's email probably takes forever. This is why I'm careful not to abuse this express route with bugs I don't really know. You two are both correct though :)

I'll do what I want!!! >:(

No. Wear this cap and go sit in that corner. >:p