Tari wrote:
TIny_Hacker wrote:
It seems that the "ExecLib " and "getDtStr(" tokens are not properly loaded when opening a program in SC3. Instead, they're loaded as "ExecLib" and "getDtStr".
Looks like this error is inherited from TokenIDE, but should be fixed now.


Thanks for the quick fix! I'm also noticing this issue with "2-Var Stats " not having the trailing space at the end.

Edit: "stdDev(" also needs a "(" at the end, and "AxesOn " needs a space.
TIny_Hacker wrote:
Thanks for the quick fix! I'm also noticing this issue with "2-Var Stats " not having the trailing space at the end.

Edit: "stdDev(" also needs a "(" at the end, and "AxesOn " needs a space.
My 83+ ROM doesn't have a space after AxesOn so I haven't changed that, but updated the other two.
Tari wrote:
TIny_Hacker wrote:
Thanks for the quick fix! I'm also noticing this issue with "2-Var Stats " not having the trailing space at the end.

Edit: "stdDev(" also needs a "(" at the end, and "AxesOn " needs a space.
My 83+ ROM doesn't have a space after AxesOn so I haven't changed that, but updated the other two.


AxesOn didn't get a space until the CSE.
kg583 wrote:
Tari wrote:
TIny_Hacker wrote:
Thanks for the quick fix! I'm also noticing this issue with "2-Var Stats " not having the trailing space at the end.

Edit: "stdDev(" also needs a "(" at the end, and "AxesOn " needs a space.
My 83+ ROM doesn't have a space after AxesOn so I haven't changed that, but updated the other two.


AxesOn didn't get a space until the CSE.
That's excitingly stupid-looking, given they didn't change any similar tokens (AxesOff). Pushing an update to the CSE tokens including that (and the other four fixed tokens) now.
Tari wrote:
kg583 wrote:
Tari wrote:
TIny_Hacker wrote:
Thanks for the quick fix! I'm also noticing this issue with "2-Var Stats " not having the trailing space at the end.

Edit: "stdDev(" also needs a "(" at the end, and "AxesOn " needs a space.
My 83+ ROM doesn't have a space after AxesOn so I haven't changed that, but updated the other two.


AxesOn didn't get a space until the CSE.
That's excitingly stupid-looking, given they didn't change any similar tokens (AxesOff). Pushing an update to the CSE tokens including that (and the other four fixed tokens) now.

The reason is that AxesOn was the only pre-existing token in that category that got a new color argument for the CSE; GridOn splintered into GridLine and GridDot, and obviously you don't need an argument to turn anything off.
Tari, could you check this file please? https://github.com/TIny-Hacker/language-ti-basic/files/14040053/TOKENS.8xp.zip


Code:
Error: Unable to load TOKENS.8xp. Are you sure it's a valid file type?
More Information: TOKENS: Detokenization process failed at ...0xef, 0x3f, ...Prevous context was: T] [CLASSIC] [n/d] [Un/d] [AUTO] [DEC] [FRAC] (backtrack was [239,63])


TI Connect CE loads this just fine.
The error message says it doesn't know what the byte sequence EF 3F is, and I agree. Looks like that file walks through tokens ordered by byte value since the last one before that is [FRAC] which is EF 3D, but TI-Toolkit/tokens agrees that EF 3F doesn't exist.
Tari wrote:
The error message says it doesn't know what the byte sequence EF 3F is, and I agree. Looks like that file walks through tokens ordered by byte value since the last one before that is [FRAC] which is EF 3D, but TI-Toolkit/tokens agrees that EF 3F doesn't exist.


Looks like TI Connect CE shows it as "STATWIZARD ON" (and then following that is "STATWIZARD OFF").

Edit:
I've added them to the tokens xml.
Tari wrote:
The error message says it doesn't know what the byte sequence EF 3F is, and I agree. Looks like that file walks through tokens ordered by byte value since the last one before that is [FRAC] which is EF 3D, but TI-Toolkit/tokens agrees that EF 3F doesn't exist.


Well, all I know is that TI Connect CE has them:

  • Mode: STATWIZARD ON" and "STATWIZARD OFF"
  • Catalog: "SEQ(n)", "SEQ(n+1)" and "SEQ(n+2)"
  • Math > Math: "piecewise(", Source Coder uses the token from v5.2.0-v5.3.0


Edit:

  • https://github.com/TI-Toolkit/tokens/blob/dcf13fdd8af3afbaadd6096fa908f39f139c5560/8X.xml#L10003C3-L10041C11
  • https://github.com/TI-Toolkit/tokens/blob/dcf13fdd8af3afbaadd6096fa908f39f139c5560/8X.xml#L10222C3-L10233C11
That was a small pile of CE-specific tokens that we didn't have, but now do.
The "Í" character cannot be exported. It is also in the "default" tab, instead of the "accented characters" tab.
Repeated error on every file i try to load:
Code:
Error: Unable to load MINECE.8xp. Are you sure it's a valid file type?
More Information: MINECE: Detokenization process failed at ...0xef, 0x7b, ...Prevous context was: (backtrack was [239,123])
PaulGamerBoy360 wrote:
Repeated error on every file i try to load:
Code:
Error: Unable to load MINECE.8xp. Are you sure it's a valid file type?
More Information: MINECE: Detokenization process failed at ...0xef, 0x7b, ...Prevous context was: (backtrack was [239,123])


SourceCode3 cannot open compiled assembly programs. You will have to grab the source code itself.
On Google Chrome on Chrome OS, trying to import a ROM into jsTIfied from SourceCoder3 results in the skin changing appropriately, but it still complains about not having a ROM loaded. I can still export the JPEG-encoded ROM "image", but it returns to the same screen as before. If I now try this on the jsTIfied page itself, it suddenly starts behaving the same way. The only quick fix is clearing cookies.
SourceCoder seems to create an array of size twice what is necessary when exporting a PNG for Casio Prizm/Nspire C. For example, when uploading a 2 by 2 PNG i get:

Code:

 const color_t sprite[8] = {
      0x0000,0x0000,
      0x0000,0x0000
   };

When all that is necessary is

Code:

 const color_t sprite[4] = {
      0x0000,0x0000,
      0x0000,0x0000
   };
pipman wrote:
SourceCoder seems to create an array of size twice what is necessary when exporting a PNG for Casio Prizm/Nspire C.
That's a silly mistake; should be corrected now.
When I create an appvar and change the language to z80 or eZ80 ASM, Sourcecoder changes the file type to a program.
That seems like sensible behavior, because it's not well-defined what it means to build code into an appvar: there is no standard execution environment or format, and I don't think SPASM even supports generating appvars.

What are you trying to do? If it makes sense it could be considered as a new feature.
Trying to compile executable appvars for a shell project that I'm working on.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3 ... 30, 31, 32
» View previous topic :: View next topic  
Page 32 of 32
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement