No you cannot use Lex or Yacc. It must all be implemented in Squeak. Use parsing stuff in Squeak or write you own. |
Try sending the message explore to an instance of any object and see what comes up. Now are you getting a better picture of what we want? Eric Anderson |
As to the BitBlt error, you might want to make sure you are not sending a point that is a fractions. For example myForm displayAt: myVar where myVar = (5/3)@3. Basically you are telling Squeak that it need to display at a fraction of a pixel instead of as an Integer. Try converting or rounding your numbers before you display. Eric Anderson |
Nah, no $'s in this stuff. Mark Guzdial |
Character cr asString should do what you want. Mark Guzdial |
Brian McNamara is working on a grammar to provide you. Any time now... Mark Guzdial |
Greek ::= \alpha | \beta | ... \omega SpecialPunct ::= \{ | \} | \\ | \# | \$ | \% | \& | \~ | \_ | \^ Text ::= Char | Char Text Char ::= Greek | SpecialPunct | any normal character Exp ::= Term Op Exp | Term Term ::= Super | Sub | Foo Foo ::= Fraction | { Exp } | Text Fraction ::= \frac{Exp}{Exp} Super ::= Foo^{Exp} Sub ::= Foo_{Exp} Op ::= + | - | * | / |
\alpha + \gamma 4 + 3 - (5 * \Delta) \beta^{2} \beta^{2}+4 \beta^{2+4} \frac{\epsilon^{(x+2)}+\delta_{(\omega-2)}}{\Gamma^\Gamma_\Gamma} x^{(\frac{2}{n})} x+1^{(\frac{2}{n})} (x+1)^{(\frac{2}{n})} | ![]() |
The directives have to do with how data gets shuttled through the parser. Check the parser lecture notes – I don't remember the exact message names now, but I know that I figured them out for that lecture. Mark Guzdial |
Just use ObjectExplorer! There seems to be lots of confusion on this point, so let me explain our rationale. The "explore" message is meant to be CYA for YOU!. We're concerned that some of you may get parsing right (or nearly right), but won't be able to display the equation. By having an "explore" option, we can see the results of the parse and potentially give partial credit for that EVEN IF the graphical display bombs. Does that make sense? Mark Guzdial |
This is not an official answer cause I am not a TA or anything, but I think that the point of the project is to recognize LaTeX commands and if you change the commands then they are no longer in LaTeX and that would defeat the whole purpose... I dunno, this is just to give you an opinion so you do not go and spend half of the night working on it this way and then find out tomorrow afternoon that it was all worthless... |
Agreed – you MUST parse LaTeX. Mark Guzdial |
Absolutely not okay. You can't force whitespace. See the examples above – these will probably be the test cases that the TA's use! Mark Guzdial |
Is '\' included as part of your tokenizer? Mark Guzdial |
Try delimiting the \ character in quotes. or, if you're making it a terminal, try [\\]. Hope this helps. Rich Glazerman |
try '\alpha' Rich Glazerman |
Greek ::= \alpha |
\beta |
...
\omega
SpecialPunct ::= \{ | \} |
\\ | \# |
\$ | \% |
\& | \~ |
\_ | \^
Text ::= Char |
Char Text
Char ::= Greek | SpecialPunct | any normal character
Exp ::= Term RestExp
RestExp ::= Op Exp | <nothing>
Term ::= Foo RestTerm
RestTerm ::= ^{Exp} RestTerm |
_{Exp} RestTerm |
<nothing>
Foo ::= Fraction |
{ Exp } |
Text
Fraction ::= \frac{Exp}{Exp}
Op ::= + | - | | / | <nothing>
–Brian
I am pretty sure that the "nothing" alternative doesn't change the LL(1) property of the grammar. I intended it to be just a convenient way to "paste" two expressions together (like "3\frac{1}{2}") without an operator. –Brian |
Okay, I figured it out. When TGen makes transformations for you, it doesn't necessarily carry the translation message selectors with it so you need to actually implement the translations that it makes in your own grammar. Therefore, any grammar with transformations is likely not to work since it won't have the correct method calls. |
Here's a good solution...pass back some symbol that you can recognize. If you get that symbol in later place, just ignore the symbol and return something else depending on the situation. For instance, for a string to be concatenated, if you get the symbol as the current string, just return the character that would be concatenated. Else, concatenate the character to the string and return the whole thing. I haven't had any problems since, but of course, different situations will have to be handled in different ways. Adam Blaiss |
Greek ::= \alpha |
\beta |
...
\omega
SpecialPunct ::= \{ | \} |
\\ | \# |
\$ | \% |
\& | \~ |
\_ | \^
Text ::= Char |
Char Text
Char ::= SpecialPunct | any normal character
Exp ::= Term RestExp
RestExp ::= Op Exp | <nothing>
Term ::= Foo RestTerm
RestTerm ::= ^{Exp} RestTerm |
_{Exp} RestTerm |
<nothing>
Foo ::= Fraction |
{ Exp } |
Greek |
Text
Fraction ::= \frac{Exp}{Exp}
Op ::= + | - | | / | <nothing>
Well, I'm not exactly sure but did you slam Brian's entire grammar into TGen and just try to get it work? Of course, I'm sure you changed the stuff that would make it interface with TGen, but I had problems just taking the entire grammar and just converting it to work. I would try starting with basic terminal types and keep compiling and building a grammar step by step. This worked quite well for me. This may not be what you want to hear, but it's a viable alternative if you're still having problems approaching the deadline. Adam Blaiss |
This isn't official, but I'm guessing that if the parser works, it shouldn't make a difference since the classes generated won't really tell what kind of parser they are. Also, all of the methods are called from "right to left" (really bottom to top) no matter what so even my LL1 parser currently has the same problem as yours. Adam Blaiss |
When you install the parser and scanner, go to the instance methods in the parser and change the value of treeBuilderClass from ^AbstractSyntaxTreeBuilder to whatever class you want the methods to be called from. This is how I did it and it worked fine. Also, I was never able to actually find this "builder" option. :-) Adam Blaiss |
If you look up a little, Brian said he talked to Mark and found out that this was not necessary and gave a grammar for it. However, it still works if you want to leave it like that, it just does that unnecesary bit. Adam Blaiss |
Well, I'm not sure, but did you accept both the terminals and nonterminals in the upper and lower left corners before trying to install the parser? Red button (I think) click in the boxes and choose accept. After doing them both, it should tell you that the grammar has been produced and what type it is (LL(1),SLR(1), etc.) Then you can actually install it. Hope this helps. Adam Blaiss |
Well, what you really need to do is make way to return the actual MathEquation objects and that is what you would want to explore. This needs to be dealt with in the MathEquation classes so you may need to go back and edit your code from Milestone #1. Make a special method explore: where they actually just return the objects and not forms to display. However, I'm still a little confused on exactly what to explore since Mark stated that exploring could be used to determine if you parsed correctly but didn't display correctly, but if you are able to build the MathEquation string to display, then evidently it'll display correctly. Therefore, exploring and displaying would essentially show the same thing, whether you did it all correct or wrong, which I don't believe was his intention. Adam Blaiss |
If you've changed your design from Milestone #2.5, include your old design, which is just Milestone #2.5, and the new design, which would be the CRC and UML analysis of the program you wrote. If the design hasn't changed at all since Milestone #2.5, then just include the old design, which is just Milestone #2.5. They just want to see how your design has changed as you began to actually program and work through the parsing. Adam Blaiss |