Yes, I tried it with ztrumpet's Exodus. The line

Code:

should have had a ◄ at the end, and the line

Code:

should have had a ► at the end. (Sorry I posted your code, ztrumpet. Hope you don't mind.)

Thanks for letting me know about this, all fixed.

I am not sure if this is a bug but it seems like it could cause major issues for Axe programmers who use SC:



Here is the reply from Lord:



http://ourl.ca/4072/98320

Thanks for the report, DJ Omni, I'm looking into it now. I'll also request that Lord Computer report such things directly to me next time to save you the trouble.

EDIT: Edit: I couldn't replicate your issue. I put this source into SourceCoder, and receive the following .8xp file (attached). Also, please update me with a response in this Cemetech topic, since I don't visit here often:
http://www.cemetech.net/forum/viewtopic.php?p=100793#100793


Code:


http://www.omnimaga.org/index.php?action=dlattach;topic=1475.0;attach=1926

Quoted from Calc84maniac

We're talking about the Editor here, right? I don't see why it would be a problem that in SourceCoder, {L3} is the symbol for L₃ and {{L3}} is the symbol for {L₃}. Unless you're saying you want a symbol for literal { L 3 }, not the L₃ token?

i recently made a program that uses the e^( token on sourcecoder, and when i transferred it to my calc i got a syntax error because my program had, instead of the e^( token, had e , ^ and ( as individual characters.

Good point. I tried the proper way to type that sequence:

Code:

And I ended up with the same thing oncalc as you. I'll edit this post or repost when it's fixed.

Edit: All fixed.

There is a problem with parsing DS<(

When saving as 8xp, SourceCoder saves this as 4 individual tokens (D, S, < and ()

Thanks for the report, DJ_Omnimaga. I fixed this and tested it fixed, but I'd appreciate your confirmation of my fix.

*bump*

For Axe coders, I added the "escape" sequences \{N\}, \{F\}, and \{E\} to represent the literal on-calc strings {N}, {F}, {E}. This was previously a problem, as the editor usually converts those to (bold finance N), (fancy F), and (small *10^ E), respectively.

:gcd(Q,G→A
:lcm(Q,G→B

Parses to the following:

:Q,G→A
:Q,G→B

Problem duplicated, solution pending.

Edit: Repaired. Had to do with improper octal parsing in PHP.

Is there a way to view and compare a text file of the original parsed input file versus the parsed output? I imported a large program that is not working and I suspect that there are other commands such as this gcd and lcm that didnt parse.

In other words, if these two problems were the only ones they would show up on a text file diff. Along with the other special things like {L2} ect.

This would allow to us to find any remaining parse errors and me to find my bug.

If you could parse the .8xp, re-export it from SourceCoder, then send me the original and re-exported .8xp files, I could run a simple binary diff on the two and figure out which token(s) are not getting parsed, if any.

really small bug. in drawing menu under the Points section, pxl-Test() is spelled "Pxl-Test(" when it should be spelled "pxl-Test(" however source coder correctly parses pxl-Test( with the lower case p so no parsing issues.

Javascript updated; ctrl-f5 the editor to get a new copy with the fix. That's so weird, in the twelve years or so that I've been coding calcs, I don't think I've noticed that too consciously. Nice catch.

Should the plethora of optimization bugs be mentioned? Or is the optimization being hid in a corner for now

We're hiding it under a sheet for now and not mentioning it. I'd love it if someone could try to make them work again one day, though. Have you checked out the new image tools?

No i haven't, but they look really cool I think ill check them out