From 67f188865c286f2fd55ad89f05e5c8f92f51bca1 Mon Sep 17 00:00:00 2001 From: afishberg Date: Sun, 3 Apr 2016 23:59:39 -0700 Subject: [PATCH 1/5] Update Entry 1 -- April 3.md --- Entry 1 -- April 3.md | 82 +++++++++++++++++++++++++++++++++++-------- 1 file changed, 68 insertions(+), 14 deletions(-) diff --git a/Entry 1 -- April 3.md b/Entry 1 -- April 3.md index 67f8f0a..d784e30 100755 --- a/Entry 1 -- April 3.md +++ b/Entry 1 -- April 3.md @@ -2,22 +2,67 @@ ## Last week's critique -**TODO:** Fill in this part with a summary and reflection on the critque you -received for last week's work. Answer questions such as: How, specifically, did -the feedback help improve the project? Did the feedback point out or offer -something you hadn't considered? Did it help you make a design decision? Was it -helpful in addressing the most pressing issues in your project? How will you -incorporate the feedback into your work? Will you change something about the -design, implementation, or evaluation as a result? +First of all, I'm happy Joshua seems excited about my idea. I enjoy strategy games so much that I sometimes worry this idea +might not be interesting to the average gamer/coder. It also seems, like me, he has not seen or heard of anything else quite +like this -- wahoo for potentially novel ideas! + +In reference to the potential pitfalls and rabbit holes for the project, I agree. This is a huge project that will never be +"complete" by the end of the semester. My goal is to have a fully functioning language where I can easily extend new API +behavior in the future. For instance, even if I choose to add a new type of laser in the future that has function calls +like `chargeLaser()` and `dischargeLaser()`, this should (from an implementation perspective) be just adding a new data type +to the abstract syntax tree that then gets interpreted when encountered. The actual aspects of the language should be +relatively consistent (i.e. math, control flow, etc.) since all ship functionality is essentially just a function calls that +generates a piece of the AST. + +While I agree I could potentially spend a lot of time on graphics, GUI, and networking, this is an advantage of using Scala +and Java. I have a lot of Processing experience and the bare bones visualization I'm imagining right now should not take +too much effort to create. In other words, all the GUI is essentially doing is recieving messages from the server which it +simply renders. Although may be to naive of a design for an industry level game (since malicious gamers can potentially start +sending fake or falsified packets), I am choosing to not address this concern for the time being. Additionally, I have a friend +designing many of the sprites for me so I will not need to spend time drawing pictures (since my pixel artwork stinks and +image design isn't part of my language design). Finally, since Java and Scala both execute on the JVM, I have already managed +to get a simple Java and Scala project to share serialized classes back and forth through a localhost connection on port 2016. +This means I have already overcome the biggest potential networking concern. + +Although I have done a lot of parallelization code in Java previously, I have not done anything like this in Scala (even +though it seems to mostly use the Java standard library). Additionally, most of my threading experience has been simply +scaling up parallel tasks, not doing things like game loops which require time sensitive synchronization. Any feedback +my critiquer can provide about my parallelization choices will be gladly welcome! + +Finally, I am happy to report I have already began addressing the last point by beginning my design work! Below I will share +some of the bare bones API functions I am envisioning as well as a sample program I wrote. Any feedback on these is very +important! + +###### How, specifically, did the feedback help improve the project? +Since this was the first critique, there wasn't much feedback to provide thus far. The most useful part of this feedback +was to confirm my idea was solid and there were no major oversights in the inital planning. I imagine feedback will +become more useful in the coming weeks. + +###### Did the feedback point out or offer something you hadn't considered? Did it help you make a design decision? +Again, since this was the first critique, there wasn't much feedback to provide thus far. Thus no new design decisions +were made from it. Rather, it helped me reaffirm my current trajectory is solid. + + +###### Was it helpful in addressing the most pressing issues in your project? +Again, since this was the first critique, there wasn't much feedback to provide thus far. There were not any pressing issues +I was stuck with (yet). + + +###### How will you incorporate the feedback into your work? Will you change something about the design, implementation, +or evaluation as a result? +This was mostly discussed above. Since Joshua seemed to approve of my current trajectory, I will stay the current course I +am planning. + ## Description -**TODO:** Fill in this part with information about your work this week: -important design decisions, changes to previous decisions, open questions, -exciting milestones, preliminary results, etc. Feel free to include images -(e.g., a sketch of the design or a screenshot of a running program), links to -code, and any other resources that you think will help clearly convey your -design process. +Since I did a wide range of tasks and research this week, I will provide a description in bullet point form. + + * I decided to split my original repo into two repos. The server is now stored [here](https://github.com/afishberg/binary-star-alpha-server) and the client is now stored [here](https://github.com/afishberg/binary-star-alpha-client). This seemed like the sensible thing to do since they are different programs that need to be compiled and run seperately. Furthermore, they aren't even written in the same language. + * I was originally concerned with how to build my programs after downloading the repos. Although the Scala code is mostly just standard library code, the client needs the Processing JAR file. Although I had never started a Gradle project myself (i.e. I have built someone elses Gradle projects before and worked with Android), this week I spent a lot of time familiarizing myself with Gradle project design. Gradle projects are awesome since you can supply dependencies to be fetch from online Maven repos at compile time (i.e. Processing JAR). Additionally, I can push something called the Gradle Wrapper (gradlew) to my repo so people can build my code natively without needing to install Gradle. + * I set up my IDEs. Building using Gradle means overriding certain aspects IDEs like Eclipse use by default. After struggling to get my Gradle build files to work in Eclipse and ScalaIDE (although they can work), I decided to try IntelliJ. Although I had never used IntelliJ prior, I need to say I am very impressed with its feel and production environment. I am normally a hardcore Eclipse user, but I may actually perfer IntelliJ in the future (we'll see how this project goes). + * I designed a sample program and though about some basic API calls. + * I began researching parser options in Scala (I might need to write one from scratch for all the functionality I need... but I would obviously perfer not to...) ## Questions @@ -25,10 +70,19 @@ design process. you need to make, what implementation issue are you trying to solve, or how are you evaluating your design and implementation?** +I need to begin designing the AST for the language and writing the initial steps of the parser. To do this, I finish my research +on Scala parser options and begin implementing the basic data types. + **What questions do you have for your critique partners? How can they best help you?** + * What do you think of my sample program? How could I improve the language? + * How should I name globals? Do we like the required `g_`? + * Should I call API functions from a `class` like structure with a `.` operator? Or should I leave it as is? How do I handle function name collisions then? Should this just be an error? + * Since the message classes sent between the server and client need to be both in the server and client project, how should I include them in both repos? Right now I am just copy/pasting the classes between the two repos. This seems dirty. + * How should I commit asset (i.e. pictures/sounds/etc)? Should these go in the repo? + **How much time did you spend on the project this week? If you're working in a team, how did you share the labor?** - +I spend about 11 hours working this week. A lot of this was messing with Gradle builds and IDE as well as research. From 00562da7d3a94075cb468ba30df569d98679c848 Mon Sep 17 00:00:00 2001 From: afishberg Date: Sun, 10 Apr 2016 11:58:11 -0700 Subject: [PATCH 2/5] Update Entry 2 -- April 10.md --- Entry 2 -- April 10.md | 283 +++++++++++++++++++++++++++++++++++++++-- 1 file changed, 269 insertions(+), 14 deletions(-) diff --git a/Entry 2 -- April 10.md b/Entry 2 -- April 10.md index c3ed055..9b317ca 100755 --- a/Entry 2 -- April 10.md +++ b/Entry 2 -- April 10.md @@ -2,22 +2,250 @@ ## Last week's critique -**TODO:** Fill in this part with a summary and reflection on the critque you -received for last week's work. Answer questions such as: How, specifically, did -the feedback help improve the project? Did the feedback point out or offer -something you hadn't considered? Did it help you make a design decision? Was it -helpful in addressing the most pressing issues in your project? How will you -incorporate the feedback into your work? Will you change something about the -design, implementation, or evaluation as a result? +Overall, Josh doesn't seem to have any major objections to the current state or direction of my +project. It seems his biggest fear at the moment is getting all the individual parts working +together (which is a very realistic fear to have). That being said, I am confident I will be +able to complete what needs to be done. In many ways, I believe the most challenging part of this +entire project is getting the parser to work. Although I am still yet to get it completely working, +I have made great progress on this during the last week and plan to have it complete by next week. +I have also completed the AST baring one issue (that I will address later). + +###### How, specifically, did the feedback help improve the project? +Josh did a good job of addressing my questions from last week. + +I am happy he seems to think my scheme for declaring and naming globals is good. Although I might +reconsider my approach later (I think I might prefer the declaration go in the global scope and +then be initialized within `void init()`) his confirmation of my current plan makes me happy enough +to just make this decision for now and move on. + +I also agree that just committing my assets to the repo in an `/asset/` folder will be best for now. +Although I might not want to push a huge amount of images and sounds to my GitHub repo later, I doubt +the assets will be too overwhelming before the end of this project. + +There are a few answers I'm not sure if I entirely agree with, however. + +After considering it, one suggestion, replacing the word `void` with a clearer word, I think defeats +target goal of this language in some ways. While I agree `void` isn't the clearest word to describe +a return type, I think the teaching philosophy of this game currently relies heavily on a teaching +methodology sometimes called the *Heuristic Method*. As I've always understood it (and as it seems +to be described in this +[link](http://www.studylecturenotes.com/curriculum-instructions/heuristic-method-of-teaching-meaning-advantages-disadvantages)), +the *Heuristic Method* revolves heavily on discovery and developing personal problem solving skills +with lots of individual feedback. By this thought, my goal isn't to "dumb down" the language, but to +simply present it in such a way that promotes exploration and good feedback. While I agree substituting +the word `void` isn't the worst offense of "dumbing down" the language, `void` is a very widely used +return type in programming world (i.e. C, C++, C#, Java, Scala, Javascript, etc all have the word in +some capacity). Thus I think this a good word to expose the users to. That being said, I am considering +changing the name of the `double` type (since I don't support `float`) for this type of reasoning. I +will explore this more later. + +Additionally, while I agree the `.` operator is useful, I'm still not certain if I want to be using it +to call functions on the ship. Although subtle, `get_vel_max()` verses `ship.get_vel_max()` implies object +oriented programming, something I've otherwise mostly been able to avoid. I do agree the `.` operator +will be useful for access structs, however, if they make it into the language. + +###### Did the feedback point out or offer something you hadn't considered? Did it help you make a design decision? +Josh is correct in saying I am eventually going to have to make a choice between adding advance features and advance +error checking. While I plan to have both in some degree, I could spend months on either of these tasks independently. +Thus, he is correct in pointing out this upcoming decision. + +For the time being, I am planning on implementing enough features that my updated prototype sample program can be +run. Additionally, I wish to minimially support all the listed ship API function calls I provided in this document. +I would also like to add type checking for evaluation. + +After this, if I have more time, I will make a decision to either add more implmementation or more error checking. +That being said, adding more implementation would probably be easier since it doesn't involve touching the parser +as much (or possibly at all). + +###### Was it helpful in addressing the most pressing issues in your project? +Josh did provide a useful suggestion for resolving how to parse good error messages. Rather than looking for a +parser with better error handling, I could just anticipate the most common errors and parse for them. While this +might seem like a big task, it is already something I was planning on doing in many ways since I intend to record +voice lines for a multitute for errors (you need to anticipate the errors if you want to record voice lines for them!) + +###### How will you incorporate the feedback into your work? +The most immediate change I am incorrperating was something we discussed in person in class. Rather than referring +to ship API funcitons in camelcase, I am instead using underscores. Although C authors have been known to use both +of these conventions, I think `_` is more widely used (or at least looks more C-like to us). + +###### Will you change something about the design, implementation, or evaluation as a result? +I did! I am now using names like `get_vel_max()` instead of `getVelMax()` for ship level API calls. Additionally, +I will probably parse for specific errors as part of my error checking. Finally, although I am differing the +decision, I will have to decide whether to prioritize more error checking or features at some point. + + ## Description -**TODO:** Fill in this part with information about your work this week: -important design decisions, changes to previous decisions, open questions, -exciting milestones, preliminary results, etc. Feel free to include images -(e.g., a sketch of the design or a screenshot of a running program), links to -code, and any other resources that you think will help clearly convey your -design process. +###### Important Design Decisions + * Design the AST + * Start designing the parser + * Begin forumlating the interpreter and how it will interact with the AST + * Although I can attempt to walk through these decisions with words, I believe the supplied code below will do a better job. + +###### Changes to Previous Decisions + * Changes API functions to use `_` instead of camel case (i.e. `void getVelMax()` is now `void get_vel_max()`) + * No other major changes were made to last week's decisions. Most changes will like start happening when I begin integrating the individual parts + +###### Open Questions + * I have many open questions at the moment. See the questions section at the bottom for more details. + +###### Exciting Milestones + * Completed the AST (barring one open question)! + +###### Preliminary Results + * AST compiles fine + * Since the Parser is not yet complete and the interpreter hasn't been started, I haven't been able to gather any actual results yet (next week) + +#### Updated Prototype Program +Below is an updated version of the program I formulated last week. The main changes here are bug fixes and updating the naming +convention of the ship API functions. I used this program as a skeleton when designing the AST. Anything I express here needs +to be representable by the AST. I still need to figure out how to support casting so `get_hull() / get_hull_max()` doens't use +integer division. + + void init() { + int g_flee = 0; + set_vel(get_vel_max()); + } + + void main() { + double percent = get_hull() / get_hull_max(); + if (percent > .2) { + aggressive(); + } else { + flee() + } + } + + void aggressive() { + if (radar(0) > 0 && can_fire()) { + fire(); + } + } + + void flee() { + int i = 0; + for (i = -15; i <= 15; i++) { + if (radar(i) > 0) { + g_flee = i; + break; + } + } + if (g_flee != 0) { + int turn; + if (g_flee > get_rot_max()) { + set_rot(get_rot_max()); + g_flee -= get_rot_max(); + } else if (g_flee < -get_rot_max()) { + set_rot(-get_rot_max()); + g_flee += get_rot_max(); + } else { + set_rot(g_flee); + g_flee = 0; + } + } + +#### Prototype Ship API Calls +Below is the initial ship API functions I plan to support. In the future, different ships will have different components +(i.e. different weapons, engines, etc.) which will change which subset of these functions a ship has access to. This "hardware" +is designed to be as simple as possible. + +In the future I would like to make more complex weapons, movement, etc. For instance, a weapon with ammo and different +firing patters would be interesting. Additionally, having engines work based of acceleration, instead of velocity, make +control much harder (and thus interesting). + +##### Weapons -- Basic Blaster + * `void fire()`: If the basic blaster can fire, it fires. If it cannot fire, it throws an error. + * `bool can_fire()`: Returns `true` if the basic blaster can fire and `false` otherwise. + +##### Engine -- Movement + * `void set_vel(int v)`: Sets the ship's velocity magnitute to the provided number. If the number is greater than the maximum velocity it throws an error. + * `int get_vel()`: Returns the ship's current velocity magnitute. + * `int get_vel_max()`: Returns the maximum ship velocity magnitute. + * `void set_rot(int r)`: Sets the ship's rotation velocity in degrees/update. In otherwords, `r = 0` means directly forward, `r < 0` means some degrees off in the clockwise direction, and `r > 0` means some degrees off in the counter-clockwise direction. + * `int get_rot()`: Returns the ship's current rotation velocity. + * `int max_rot()`: Returns the maximum ship rotation velocity. + +##### Hull -- Health + * `int get_hull()`: Returns the ship's current health. + * `int get_hull_max()`: Returns the ship's maximum health. + +##### Sensor -- Detection + * `int radar(int angle)`: Looks in the provided relative direction. If there is an object that is within the radar's maximum range, it will return the distance. Otherwise it will return `-1`. + * `int radar_range_max()`: Returns the maximum range the radar can detect objects. + +##### Communication Link -- Debugging + * `void alert(String msg)`: Displays a string message above the ship in game. Useful for debugging. + +#### Prototype AST +Although it is a lot of code, I think discussing the curerent state of the AST is very important for my prototype. +Especially since I am not sure how to parse Call (i.e. it is both an expression and statement). + +For the prototype demo, it might be interesting to try to build the AST for the sample program (especially the `void flee()` +function). + + case class FuncDecl(rtnTy: Type, name: String, param: List[VarDecl], body: Block) + + case class Type() // TODO add ArrayTy + case class IntTy() extends Type + case class DoubleTy() extends Type + case class BoolTy() extends Type + case class CharTy() extends Type + case class VoidTy() extends Type + + case class VarDecl(ty: Type, name: String) + + case class Expr() + case class Literal() extends Expr // TODO add ArrayLit + case class IntLit(i: Int) extends Literal + case class DoubleLit(d: Double) extends Literal + case class BoolLit(b: Boolean) extends Literal + case class CharLit(ch: Char) extends Literal + case class Var(name: String) extends Expr + + // uniop + case class NegateOp(expr: Expr) extends Expr + case class NotOp(expr: Expr) extends Expr + + // binop + case class AddOp(left: Expr, right: Expr) extends Expr + case class SubOp(left: Expr, right: Expr) extends Expr + case class MultOp(left: Expr, right: Expr) extends Expr + case class DivOp(left: Expr, right: Expr) extends Expr + case class ModOp(left: Expr, right: Expr) extends Expr + case class AndOp(left: Expr, right: Expr) extends Expr + case class OrOp(left: Expr, right: Expr) extends Expr + case class LtOp(left: Expr, right: Expr) extends Expr + case class GtOp(left: Expr, right: Expr) extends Expr + case class LeqOp(left: Expr, right: Expr) extends Expr + case class GeqOp(left: Expr, right: Expr) extends Expr + case class EqOp(left: Expr, right: Expr) extends Expr + case class NeqOp(left: Expr, right: Expr) extends Expr + + case class SubscriptOp(left: Expr, right: Expr) extends Expr + + case class Statement() + case class Block(body: List[Statement]) extends Statement + case class IfThenElse(cond: Expr, bodyTrue: Block, bodyFalse: Block) extends Statement + case class Call(name: String, args: List[Expr]) extends Statement + case class For(init: Statement, cond: Expr, inc: Statement) extends Statement + case class While(cond: Expr) extends Statement + case class Break() extends Statement + + // side effect op + case class Assign(name: String, expr: Expr) extends Statement + case class DeclAssign(decl: VarDecl, expr: Expr) extends Statement + case class AddAssign(name: String, expr: Expr) extends Statement + case class SubAssign(name: String, expr: Expr) extends Statement + case class MultAssign(name: String, expr: Expr) extends Statement + case class DivAssign(name: String, expr: Expr) extends Statement + case class ModAssign(name: String, expr: Expr) extends Statement + case class PreIncOp(expr: Expr) extends Statement + case class PreDecOp(expr: Expr) extends Statement + case class PostIncOp(expr: Expr) extends Statement + case class PostDecOp(expr: Expr) extends Statement + + ## Questions @@ -25,10 +253,37 @@ design process. you need to make, what implementation issue are you trying to solve, or how are you evaluating your design and implementation?** +Before next week I really need to completely finish the parser and AST for +basic programs (without error checking). I really want to be able to generate +AST from simple correct programs. + +This means I am going to need to figure out how to represent function calls. +I ran into a little problem I haven't been able to address yet when I realized +function calls can behave as both statements and expressions. + +Additionally I still need to figure out how I want to handle casting. + **What questions do you have for your critique partners? How can they best help you?** + * Statement are usually considered to have side effects while Expressions do not. That being said, this seems to only be a formal definition. For instance, things like `break` are merely control flow and thus has no side effects (although one could make the argument by breaking a loop out of scope it is a side effect?), but as far as the parser is concerned, `break` is definently a statement. This is especially an issue for `Call(name: String, args: List[Expr])`. A `Call` can definetly be a statement but can also be evaluated in an expression. This problem seems to be rooted in addressing order of operations in expressions, something I have done mathematically in the parser but have not done for all operators (since some, like `+=`, have side effects and others, like arithmetic `+`, do not. How should I handle and parse `Call` in the AST? + * Should there be function collisions with ship API calls? Or should I call all ship API functions with either `ship.` or some prefix like I'm using for global variables (i.e. `g_`)? + * After basic features are supported, should I prioritize more error checking or more interpreter features? + * Should ship API functions get their own AST components since they directly cause game behavior and are predefined? + * If ship API calls should get their own AST components, should the parser parse them out directly or should I preform a transformation on `Call` items during type checking to convert them into the appropriate AST items. + * How should I support casting? I am uncertain at the moment of how to support the C parenthesis method (i.e. `(int) 3.5`). Would it be better to support it with a few predefined functions like `int2double`, `double2int`, `int2char`, etc.? Does the latter betray my teaching methodology? + * Should I support treu `int` operations or should I wrap them in a BigInteger type? If I do this, I can prevent overflow errors. + * Should I support true `double` operations or should I wrap them in a BigDecimal type? If I do this, I can keep a fixed decimal point percision (i.e. 6 decimal place values) and avoid weird rounding issues. + * Since I am not supporting `float` type, does calling the decimal type `double` make sense? Should I just call my `double` `float` or should I call it `decimal`? + * Should I bother supporting arrays? For the time being, I think this is a huge layer of unneeded complexity. + * If I choose to support Arrays, it seems obvious `String` will be some kind of wrapper around `Array[CharTy]`. That being said, if I choose not to bother with arrays, how much should I handle `String`? I am considering supporting them only as constants so you can developers can create useful error messages for themselves but not allowing much (any?) String manipulation. + * How much do I deal with order of operations? That seems to be the root of my `Call()` statement problem. + * Should I support `assert(bool b)`? I think this is extremely useful for users. + **How much time did you spend on the project this week? If you're working in a team, how did you share the labor?** - +I spent a solid 8.5 hours working on this project outside of class this week. I would have +liked to spend enough time so I could have ensured the AST and parser were complete this week, +but clinic prevented me from doing extra this week (Phase III presentation and a draft of +our final report is due next week!) From 31df7508ca84dcc88701a96be62493f6d6a05609 Mon Sep 17 00:00:00 2001 From: afishberg Date: Sun, 10 Apr 2016 12:04:32 -0700 Subject: [PATCH 3/5] Update Entry 2 -- April 10.md --- Entry 2 -- April 10.md | 1 + 1 file changed, 1 insertion(+) diff --git a/Entry 2 -- April 10.md b/Entry 2 -- April 10.md index 9b317ca..fd70206 100755 --- a/Entry 2 -- April 10.md +++ b/Entry 2 -- April 10.md @@ -81,6 +81,7 @@ decision, I will have to decide whether to prioritize more error checking or fea * Design the AST * Start designing the parser * Begin forumlating the interpreter and how it will interact with the AST + * Looked at Prof Ben's Garden Project a bit after the fact (didn't want to take the fun out of thinking through the design challenges). This project can bee seen [here](https://github.com/hmc-cs111-fall2015/garden). * Although I can attempt to walk through these decisions with words, I believe the supplied code below will do a better job. ###### Changes to Previous Decisions From 9569c55879ce10137c56ed3bd9ee01631a0d40bc Mon Sep 17 00:00:00 2001 From: afishberg Date: Sun, 17 Apr 2016 23:59:39 -0700 Subject: [PATCH 4/5] Update Entry 3 -- April 17.md --- Entry 3 -- April 17.md | 89 +++++++++++++++++++++++++++++++++++------- 1 file changed, 75 insertions(+), 14 deletions(-) diff --git a/Entry 3 -- April 17.md b/Entry 3 -- April 17.md index bafd527..d9f7d97 100755 --- a/Entry 3 -- April 17.md +++ b/Entry 3 -- April 17.md @@ -2,33 +2,94 @@ ## Last week's critique -**TODO:** Fill in this part with a summary and reflection on the critque you -received for last week's work. Answer questions such as: How, specifically, did -the feedback help improve the project? Did the feedback point out or offer -something you hadn't considered? Did it help you make a design decision? Was it -helpful in addressing the most pressing issues in your project? How will you -incorporate the feedback into your work? Will you change something about the -design, implementation, or evaluation as a result? +Joshua did a lot this week to answer my questions the best he could. Below you will see a subsection for each question he addressed +and my comments on his thoughts. + +###### Statements, expressions, and function calls +Interestingly enough, after thinking on it much this week, I think I will just make a container data type called Eval which simply +takes a call statement. This container would then call its corresponding function and, ultimately, replace itself in the Expr with +the return value. Additionally, interestingly enough, this also will help with type checking (if I get to that). For instance, +there could never be a void function in an Eval. + +###### Function collisions +After dwelling on it, I agree that the `ship.` syntax is overkill. Additionally, I agree supporting overloading is more than +I probably want to deal with for now (although it might be interesting in the future)? That being said, true C doesn't support +this feature, so I don't really think I should bother. I am still not sure if I should add the prefix though (i.e. +`s_get_hull()` or `get_hull()`). I guess this would be a good question to bring up in class on Monday? + +###### Error checking vs. interpreter features +I think this should become an important discussion to have in class on Monday. While I agree quality error checking is +very important for the long term goals of this project, in the scope of the next few weeks, I need to really consider what +error checking aspects I want to support. A big one on my mind right now is type checking. + +###### AST components for ship functions +I don't think I will bother to make custom AST components for the ship. The more I think about it, this just seems like it will +actually add more complexity to my interpreter than ease my work. Rather, I when interpreting a call function, I will first check +if the function name is included in a ship function name list, if it isn't I'll check for user defined functions. + +###### Casting -- Big types -- Double / float / decimal /etc. +I am addressing all these comments at once. I think I am just going to support a traditional `int` and `double` for now. I could +always change this later. This is just the easiest to implement for now. + +###### Arrays +I don't think I'm going to bother with arrays anymore. Too much of a headache for the scope of this projec.t + +###### Order of operations +I think I may have gotten this all sorted out in my parsing! It might be difficult to add new operators in the future, but +for now I think this is good. + +###### Assert +I think I am going to add `assert()`. It will just freeze the ship (not the whole game) and help the user debug. It actually +seems simple enough to implement too (the ship halting will be the same reaction to an error being caught). ## Description -**TODO:** Fill in this part with information about your work this week: -important design decisions, changes to previous decisions, open questions, -exciting milestones, preliminary results, etc. Feel free to include images -(e.g., a sketch of the design or a screenshot of a running program), links to -code, and any other resources that you think will help clearly convey your -design process. +This week I was super overwhelmend with clinic deadlines to want to tackle any of the more challenging parts of this project. +That being said, this didn't keep me from making progress this week. Thus, rather than working on the server for my project as +originally intended (i.e. the parser and interpreter), I chose to instead make progress on some of the more leisurely parts of +the software. Thus, this week, rather than directly addressing my dilemmas with my parser, interpreter, and language design +I chose to focused on thinking about how to address these problems while I coded some of the more trivial GUI components in +the client. + +In addition to making progress on the GUI itself, I also began looking for sprites to use. Although I do have a friend +designing custom original sprites for me, it is seeming that they will not be done in time for this project. Thus, I have +located an alternative source of temporary sprites I can use for this project for free. This webpage, which can be found +[here](http://millionthvector.blogspot.com/p/free-sprites.html), provides users with high quality spaceship sprites +under the Creative Commons Attribution 4.0 International License. This means all I need to do for the time being is +credit the author for the sprites (thanks MillionthVector)! Ultimately, however, it is still my intention to replace these +sprites entirely with my own. + +As for the parser and interpreter I plan to get them working completely this week (for real this time). To do this, I have +decided to add an extra type to Expr, an Eval which takes a Call type and executes it within the context of an Expr. This +way I keep the Call Statement and the Call Expr using similar data types but I can clearly extract and use a return value +when a function call is made in an Expr. As for the remaining progress I made on design with regard to the parser and interpreter, +this is addressed in the section above. ## Questions **What is the most pressing issue for your project? What design decision do you need to make, what implementation issue are you trying to solve, or how are you evaluating your design and implementation?** +Interestingly enough, the most pressing issue for my project right now is time. Although I knew this week was going to be a struggle, +I was hoping to have completed what I considered to be the most challenging part of this project. That being said, I still believe +I am on track and will manage to get everything completed on time. **What questions do you have for your critique partners? How can they best help you?** +To be honest, since I didn't really make any progress on the most challenging parts of this project this week, I don't really have +many new questions at the moment. That being said, something I need to consider moving forward is the best way to test the game. + +Therefore, how do you think I should test the game? Do you think I should just make a bunch of ship scripts that I run to +test for errors? Should I organize my critique group to play the current build of the game next week? Is there a testing framework +I should be using? I'm not entirely sure if using ScalaTest is really the best use of my time. Rather, might I be better off writing +scripts that I convert to AST and print to console so I can check the output by hand? + +I firmly believe testing is a very important part of any code project, that being said, since so much of this game is how the user +interacts with it, I am not certain of how to best "automate" tests. **How much time did you spend on the project this week? If you're working in a team, how did you share the labor?** - +This week, I spent the minimum 8hrs on this project thanks to clinic. That being said, since the most challenging deadlines have +now passed, I plan to spend a rediculuous amount of time on this project this upcoming week. I currently feel I am a little behind +at the moment. From fd44261be0661396ed270cb0482591720010a556 Mon Sep 17 00:00:00 2001 From: afishberg Date: Sun, 24 Apr 2016 23:57:12 -0700 Subject: [PATCH 5/5] Update Entry 4 -- April 24.md --- Entry 4 -- April 24.md | 195 ++++++++++++++++++++++++++++++++++++----- 1 file changed, 175 insertions(+), 20 deletions(-) diff --git a/Entry 4 -- April 24.md b/Entry 4 -- April 24.md index 72425b0..fc7016f 100755 --- a/Entry 4 -- April 24.md +++ b/Entry 4 -- April 24.md @@ -1,34 +1,189 @@ # Design notebook for week ending April 24, 2016 ## Last week's critique +After reading through the critique, I feel I have addressed most of the issues (since there wasn't many at this phase of +the project). That being said, as I'm winding down the project, I am sad to realize a lot of the feature I was hoping I'd get +to I simply won't have time for. That being said, I am really proud of what I accomplished since it is far from a simple task. -**TODO:** Fill in this part with a summary and reflection on the critque you -received for last week's work. Answer questions such as: How, specifically, did -the feedback help improve the project? Did the feedback point out or offer -something you hadn't considered? Did it help you make a design decision? Was it -helpful in addressing the most pressing issues in your project? How will you -incorporate the feedback into your work? Will you change something about the -design, implementation, or evaluation as a result? +#### Simplifying Function Calls +Although I am not sure I would call the Eval container a _simplification_ of the grammar, I feel confident this was the +correct way to address the issue at hand. This way I can still rely on the parsing for Statement Function Calls while +still being able to evaluate them within the context of a Expr. + +A big hold up I have come to realize is it is impossible to really keep Statements and Expr completely separate for C-style +language (in the Programming Languages definition). Functions in a technical definition should not cause side effects, but +that is clearly not the case for C-style languages. + +#### Bulid Environment +Although I'm pretty sure it all works now, I actually caught a pretty big problem with this this week. Interestingly enough +although IntelliJ can import and run Gradle projects and project structures, after you start making changes inside IntelliJ, +the changes are only reflected in the IntelliJ project (as far as I've discovered... I wouldn't be surprised if there is a +way to make IntelliJ generate Gradle build files though). Because of this, even though the code would build and run in +IntelliJ, the code would not actually run with `./gradlew run` as it should. I fixed this by adding +`compile 'org.scala-lang:scala-parser-combinators:2.11.0-M4'` to the build file. This fetchs important things like PackratParser +from the online Maven repo. (To be honest, I'm surprised this isn't included in the Scala core library...) + +#### Testing +Although still not as rigorous as I was hoping, I began writing simple scripts that I could run through my parser to help +me debug various parser problems. The most important of these is actually the third program called `prog3.bs`. This is the +sample program I wrote for my prototype and is the most complicated test at the moment. + +For the time being, I just pushed them in a root server directory. Although I know this is horrible style, this was the +easiest directory to place the files in for now. When the program runs, this is the directory that is used +as the working directory. This means I can avoid having to place absolute paths in the code in favor of just file names. +Although I plan to address this before Friday (I plan to make a dedicated and documented sample script folder). ## Description -**TODO:** Fill in this part with information about your work this week: -important design decisions, changes to previous decisions, open questions, -exciting milestones, preliminary results, etc. Feel free to include images -(e.g., a sketch of the design or a screenshot of a running program), links to -code, and any other resources that you think will help clearly convey your -design process. +#### Finalizing Parser +I got the biggest achievement of this entire project working this week - the parser. Although I definently want to do more +with it, espeically in the realm of error and type checking, it is in a great place. As it stands now, I can put in a full +"complex program" and parse it correctly. Although I will refrain from linking `prog3.bs` here (since I imagine the +filename/location will change in the near future), the types of programs it can handle is almost identical to C barring +the preprocessor, arrays, structs, and pointers (which although is a lot, isn't necessary for my purposes). Take a look in +the repo for sample programs for a better understanding of what it can parse successfully. + +In order to get a lot of this stuff working, I needed to make my parser a lot more complex. What used to be a single funciton +`pStatement` is now 6 different functions: `pStatement`, `pStatementBlock`, `pStatementSemicolon`, `pStatementControlFlow`, +`pStatementDecl`, and `pStatementAssign`. Although I am quite happy with the current break down of these individual parsers, +I am not very confident in my naming convention. As it stands, I feel these names imply they each parse ONLY the specific type of +statement in the name, when in reality they call each other in order (i.e. `pStatement` => `pStatementBlock` => `pStatementSemicolon` +=> `pStatementControlFlow` => `pStatementDecl` => `pStatementAssign`). I'm not really sure how to address this. + +I am also happy to report I even managed to implemented a few extra operators I was originally teeter tottering on implementing +(i.e. `++`, `--`, `&&`, and `||`). That being said, these expressions do not necessarily interact correctly with each other +at the moment. As seen [here](http://en.cppreference.com/w/c/language/operator_precedence), C operator precedence is well +define such that things like `||` should be evaluated after `&&`. Thus, since I implemented all the boolean operators at one +level in the parser, they just parse out in order from left to right. Although at this point I know exactly how to fix this, +I decided to leave it be in favor of a few other tasks. + +Note: Something huge that tripped me up this week is the difference between `()` and `{}` for function declrations in Scala! +Specifically, I was getting confused when the functions wouldn't allow me to put the `|` operator on the next line. + +For instance, the following compiles correctly: + + def pType: PackratParser[Type] = ( + "int" ^^^ IntTy() + | "double" ^^^ DoubleTy() + | "bool" ^^^ BoolTy() + | "char" ^^^ CharTy() + | "void" ^^^ VoidTy() + ) + +But this (I only switched the `()` with `{}`) does not compile correctly: + + def pType: PackratParser[Type] = { + "int" ^^^ IntTy() + | "double" ^^^ DoubleTy() + | "bool" ^^^ BoolTy() + | "char" ^^^ CharTy() + | "void" ^^^ VoidTy() + } + +But then this (I put the `|` at the end of the previous line instead of the beginning of the next) compiles correctly: + + def pType: PackratParser[Type] = { + "int" ^^^ IntTy() | + "double" ^^^ DoubleTy() | + "bool" ^^^ BoolTy() | + "char" ^^^ CharTy() | + "void" ^^^ VoidTy() + ) + +When considering what is actually happening, this actually makes a lot of sense. When using `{}`, this implies to Scala the +code block is "more than one line". Thus, if you don't end the line with a binary operator, it can't determine if the line +is supposed to end or not. Python does something similar where you can't start a line with a `+` unless you ended the previous +line with a `\` (telling Python to continue to the next line) but you can end a line with a `+` and it will continue the expression +onto the next line without the `\`. + +When you use `()`, however, this implies the entire block (if you can even call it that) is just one statement. This means you +can start the line with a binary operator since Scala knows the whole thing is a single expression. + +I also notice while I was programming I started using the `return` statement again, something you don't often need in Scala +(since it implicitly returns the last value in a function). There is probably quite a bit I could do to make my code more +Scala-like in style. I am jumping a lot between thinking about C and Scala (due to the nature of the project) keep catching +myself reverting to non-Scala styles. Also, I just am not always certain of the most Scala-like way to express something. +I would benefit greatly from a code review from a more experience Scala programmer like Prof Ben. + +#### Building Game Logic +Although I started a majority of this work last week, I ended up revamping portions of it as I began working on the interpreter +and network communication. As I continue to mull over future features I wish to implement (i.e. multiple weapons, armor types, etc.) +I believe the complex granularity I chose to work with makes a lot of sense. That being said, I'm still certain this current +formation isn't final. You can check out the majority of the current implementation by checking out `Behaviors.scala` and `Draw.scala`. + +As of now, the traits I have are: + + * `Acceleration`: A trait that inherits from `Velocity`. Possessing this trait means movement depends on velocity and acceleration. + * `Allegiance`: A trait that inherits from `Solid`. Possessing this trait means the object has an alliance with other units. This means its collision behavior only affects enemies. This is useful for controlling friendly fire. + * `Corporeal`: A trait that most things inherits from (last week this behavior was a part of `Drawable`, now `Drawable` possesses this trait). Possessing this trait means the object has a position and direction in the "world." I'm not sure how I feel about the name. + * `Expiration`: A trait that inherits from `Mortal`. Possessing this trait means the object will die after a certain duration regardless of the circumstances. + * `Explosive`: A trait that inherits from `Expiration` and `Solid`. Possessing this trait means the object will die upon collision with something and inflict damage. + * `FFExplosive`: A trait that inherits from `Explosive` and `Allegiance`. Possessing this trait means the object will only explode and damage enemy units. The FF stands for Friendly Fire. + * `Health`: A trait that inherits from `Mortal`. Possessing this trait means the object has health and will die when it reaches or goes below 0. + * `Mortal`: A trait that means the object can die. This can be useful for differentiating between background indestructable objects and player objects. + * `Movable`: A trait that means the object has an `updatePos()` function. This means the object can move between game loops. + * `Solid`: A trait that inherits from `Corporeal`. Possessing this trait means the object can collide with other `Solid` objects. + * `Velocity`: A trait that inherits from `Movable`. Possessing this trait means movement depends on velocity. + * `Drawable`: Not a trait, but an important Abstract Class. Anything that inherits from this can be drawn on the client side display. Drawable uses the `Corporeal` trait since a drawn object needs a location on the map. + +#### Network Logic +I decided to simplify my client for the time being by making it only a viewer. This means the server does not need to deal with +receiving any of the information from the client. Thus, the client basically just draws on screen the information sent to it by +the server from the `Drawer` and `DrawQueue`. To do this, I strip down every `enabled()` object that inherits from the `Drawable` +abstract class into a `DrawOrder` and send serialize it over the socket. I should really consider changing my network connections +to UDP (to prevent lag over a bad connection), but I don't want to deal with missing packets. Regardless, advancements over the +networking is a much lower priority now. + +#### Building Interpreter +One of the biggest things I have not fully got working this week is the interpreter. Specifically, I am unsure of how to overcome +a typing problem in Scala although I am certain it has to do with Scala Reflection. I will outline this more in the question section. ## Questions -**What is the most pressing issue for your project? What design decision do -you need to make, what implementation issue are you trying to solve, or how -are you evaluating your design and implementation?** +#### What is the most pressing issue for your project? What design decision do you need to make, what implementation issue are you trying to solve, or how are you evaluating your design and implementation? + +Although it is clear I will not get everything I hoped to get done, done, I would like to get the interpreter working a bit more +than it currently is. Although at the moment I am fine with dealing with types within my code, I am at a loss of how to convert +one of my types elegantly to one of Scala's types for implementation. Furthermore, when building my function `Map` environment, since +my various functions have different parameters and return types, I can't simply make a `Map[String, () => Unit]`. + +One solution I've considered is making a psudo-stack system where arguments are sent and values are returned in shared global +variables. That being said, there is still some typing problems one runs into down this path too. Specifically, if I have a +function that simply does pattern matching and returns the Scala equivilent to my type, this means the Scala function must +return something of type `Any` or `AnyValCompanion`. + +I've been spoiled a bit from Python which can just arbitrarily return any type as it sees fit. I know this is a problem Scala +can address and I know the solution lies in Scala Reflection somewhere, but I'm having trouble figuring it out. + +#### What questions do you have for your critique partners? How can they best help you? + +###### What's a good place to stop? +At this point, I will obviously not get everything I'd like to get done, done. The real question is where should I stop? +Especially after this last week, I've certainly put much more time than I was required to into this project. I'm just curious +where I should call it quits. + +As it stands, a lot of individual parts work but the whole system cannot run as a whole. Should I focus on getting the whole +thing running in some limited capacity? Or should I focus on having a runnable demo for each of the individual parts? + +###### Naming Subparsers +What do you think of my subparser names? They got a lot more haphazard as I began making some big changes to the parsing levels +of my program. I'm not really sure what a good convention is. Any ideas? + +###### Trait Inheritance +Although it is probably hard to comment on whether my trait inheritance makes sense without knowing where I am planning to go +with this project beyond the scope of this class, I do know going "inheritance crazy" (i.e. making way too many +classes/traits/interfaces) is a problem programmers need to watch out for. Do you think this granularity makes sense? + +###### Scala Reflection +Although I have some experience working with Java Reflection, Scala Reflection seems quite a bit different. I've also never +really tried to do anything this complicated with runtime typing in a strongly type language (i.e. Python's indifference makes +this stuff much easier). I looked at some tutorials, but I'm not even certain of the "name" of what I'm trying to do is. Any +ideas of how to figure this out? I'm planning on chatting with Prof Ben. -**What questions do you have for your critique partners? How can they best help -you?** +#### How much time did you spend on the project this week? +I spent a ton of time working on this project this week. Since I didn't have an Algorithms Homework (since we had a midterm this +week) I managed to spend over 20+ hours on this project. A lot of this was spent coding, debugging, and planning out inheritance/parser levels. -**How much time did you spend on the project this week? If you're working in a -team, how did you share the labor?** +I also spent 3 hours planning, getting pictures, and practicing my presentation. (Some of the pictures took a while to make...)