» Goto page Previous  1, 2, 3, 4, 5, 6 ... 29, 30, 31  Next
» View previous topic :: View next topic  
KermMartian wrote:
Deep Thought wrote:
Here's a bug that I found in the previous versions of SC but didn't report: SourceCoder doesn't recognize the hidden tokens like ◄ and ►. TI-Connect doesn't either, but it'd still be very useful (for example when fixing games glitched by TIC).
I believe this might be properly fixed now; have you tried to verify it in the current version by any chance?


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

Code:
:Text(Ans,6L1(O)-4,"

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

Code:
:Text(Ans,6L1(O)-2,"

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.

Quote:
:Text(Ans,6L1(O)-4,"◄
:Text(Ans,6L1(O)-1,"[
:Else
:Text(Ans,6L1(O)-4,"]
:Text(Ans,6L1(O)-2,"►
Generated by SourceCoder, 2005-2010 Cemetech
I am not sure if this is a bug but it seems like it could cause major issues for Axe programmers who use SC:

calc84maniac wrote:

LordConiupiter wrote:

something strange going on here. It's not really a bug I thing, thoug it's some kinda error.
In one program I save 2 pics to an AppVar, and in another one I try to use them as Pics, which isn't really working for me.
here is my source:

--snip--


Code:
:Copy(Pic0,{L6},756)
:Copy(Pic1,{L3},756)

should be

Code:
:Copy(Pic0,L6,756)
:Copy(Pic1,L3,756)

since you don't want to read the memory and pass that value as an argument to Copy().


Here is the reply from Lord:

LordConiupiter wrote:

yes, I know that, and that's exactly what I did, but this is the way cemetech converts it, to show that it's a single token.
@calcdude: it looks more like it with your code, but the whole image is shown with the upper part down, and the lower part up.
In my case it is a mans head and upper body, so his head is shown at the bottom of the screen, and his body at the top.


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. Smile

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:
:{3,2,1→{L3}
:{5,4,2→{L6}


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

calc84maniac wrote:

KermMartian wrote:

LordConiupiter wrote:

yes, it allways does.
You mean if you type {L3} into the editor and then export as .8xp, it's {L3} on the calculator, not L3? That's not right....

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:
:{3,2,1→{L3}
:{5,4,2→{L6}


No, the problem is that L3 shows up as {L3} in Sourcecoder, which is a valid (and completely different) Axe statement.
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 L3 and {{L3}} is the symbol for {L3}. Unless you're saying you want a symbol for literal { L 3 }, not the L3 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.
niemo wrote:
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:
{e}^(X

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. Smile
There is a problem with parsing DS<(

When saving as 8xp, SourceCoder saves this as 4 individual tokens (D, S, < and ()
DJ Omnimaga wrote:
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
hdafedex wrote:
: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.
hdafedex wrote:
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. Smile
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.
nemo wrote:
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 Razz
builderboy2005 wrote:
Should the plethora of optimization bugs be mentioned? Or is the optimization being hid in a corner for now Razz
We're hiding it under a sheet for now and not mentioning it. Laughing 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 Smile I think ill check them out
  
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, 4, 5, 6 ... 29, 30, 31  Next
» View previous topic :: View next topic  
Page 5 of 31
» 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