The Lab and pre-lab assignment for Feb. 22nd is now available. As usual, a physical copy of your prelab assignment is due at the start of your lab. This lab is not due until March 7th. The prelab will be collected February 29th.
http://www.cs.unm.edu/~tberge01/spring.2012/cs251/labs/feb22.php
Have a great weekend!
This comment has been removed by the author.
ReplyDeleteHow are we supposed to handle the List drawables argument? I learned from looking up a compiler warning that it is a raw type, which essentially means it is not safe and the recommended solution is to use a parametrized type.
ReplyDeleteI made a RenderOval() which implements Renderable and "renders" an ellipse. I then create a List member with several instances of RenderOval()s with different coordinates, and pass the list member to the constructor of PowerDisplay from a separate main() class. I've only been able to use the raw List drawables member by setting an uninstantiated List to reference it. I can then use an enhanced for loop to iterate through the list and have each RenderOval draw itself.
The spec has no mention of a "driver class", so how can we handle whatever types are in the drawables list that you (TAs) will use to test?
This comment has been removed by the author.
ReplyDeleteSorry, the '<' and '>' got treated as an HTML tag when we transformed the write up into HTML code as it also does for this forum apparently. So for this post I will be using ^ as the open and close brackets.
ReplyDeleteThis has been fixed. The constructor should take an (int xSize, int ySize, List^Renderable^ drawables). Classes that implement interfaces can be treated as those interface types just like a class that extends another class can be treated as the super class type. This is using whats called 'Polymorphism' to your advantage. The same goes for the List interface. You don't have to really worry about what a List^Renderable^ is right now, as we will be getting into the Collections classes soon.
The way you can think about declaring a List is almost like how you can declare a Automobile from the last lab. Remember, you can declare the following:
Automobile auto = new Car(...correct params here...);
The List interface is done the same way. But the instantiable class you all should think about using is called an ArrayList. So you can create a new List by declaring:
List myList = new ArrayList^Renderable^();
Then you can add and remove from this list using the 'add(Renderable r)' and 'remove(Renderable r)' methods in the List interface.
Sorry about the confusion, we did fix lab page though so it correctly reflects the constructor.
I hope this helps.
tb
Sorry, oen more typo above. In the declaration for myList it should be List^Renderable^ myList = new ArrayList^Renderable^();
DeleteThis comment has been removed by the author.
ReplyDeleteHah, by the time I composed that last post, you reposted...
ReplyDeleteI still see a problem. Renderable() is an interface with no defined fields/methods for x and y coordinates. Seems like we need to implement a custom Renderable() with these fields/methods, but that doesn't solve the issue of handling any type of List^Renderable^ passed to the constructor. Shouldn't the spec specify a standardized way to access the x/y coordinates in order to call render() with a real xOffset and yOffset?
You are correct. I will abridge the Renderable interface within the hour. Until I update the Renderable interface you can assume I will add a 'getX()' and 'getY()' method in the interface.
DeleteThe Renderable interface has been fixed and it is in the Common folder in the repository. As soon as I get a hold of Joe, I will get the updated Javadoc up on the lab website.
ReplyDeletePowerDisplay extends JFrame, and JFrame has implicitly inherited JComponent methods int getX() and int getY(). So if PowerDisplay is not abstract, we must entirely implement Renderable, including double getX() and double getY(), which conflicts with the JComponent method signatures (by return type).
ReplyDeleteWhat should be done to get around this? Do Renderable's conflicting methods need to be renamed?
I have the same issue too. I have let Jan, our TA, know about this conflict in person earlier today.
DeleteThat's what I get for not doing the lab before hand. PowerDisplay should not implement Renderable. Only the objects you are drawing to the screen (whatever they may be) should implement Renderable. I will have this changed asap.
ReplyDeleteSorry about the confusion and thanks for bringing this up.
Regarding makefiles, I talked to Jan and he said that our makefiles are expected to work on the cs lab machines. How can we guarantee that the directory structure of where you (TAs) checkout our packages won't break the makefile? How do we deal with the different class and source paths of our files and the files in the common repo?
ReplyDeleteOn my Windows box, I defined two user environment variables with paths of the two different repo roots, I can then reference these in my makefile and get FULL path of any file inside of either, if I specify the package. This means the makefile works from ANY directory. But even if I define user environment variables on a lab machine, you (TAs) won't have them.
I thought about using svn merge to unify the paths, but then any time we compiled stuff from the common repo (or hacked around and changed stuff) then our changes would be committed back to the common repo (unless we don't have permissions, and I have not tried to commit to the common repo).
Your Makefile *must* run on the CS machines. To test if it is going to work, simply check out the repository and type 'make *command*' to see if it works.
DeleteAny variables that are local to your machine will not work on the CS machines. To get around this, you can define variables in the makefile. See the example for how to do this.
I've only had makefile success on linux when the source and class files from both repos have the same root directory.
DeleteSo should we use svn merge to unify the paths, or, every time there is a new modified revision, copy files from the common repo to the appropriate directory in our repo directory?
You can not commit to the common directory. This means everything for your assignment to work must be in your repository.
DeleteThanks, this clarifies things. I was under the impression that we would directly use the checked out common repo, rather than add needed files to our repo manually.
DeleteHas anyone else been having trouble checking out the latest revision?
ReplyDeleteEverytime I try, I get the following message:
"batch@oberon:~$ svn checkout file:///nfs/faculty/hayes/pub-svn working
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 'file:///nfs/faculty/hayes/pub-svn'
svn: Can't open file '/nfs/faculty/hayes/pub-svn/format': Permission denied"
That repo is now closed. Use the path "https://svn.cs.unm.edu/cs251s12/common". This is where all the lab and lecture demos are stored. Use the path "https://svn.cs.unm.edu/cs251s12/CSIDHERE" to access your repo.
DeleteOk, I guess I didn't catch that.
DeleteThanks, Rob.
How are we supposed to make Renderable objects if Renderable has no constructors? and since we're not implementing renderable, do we still need to use it?
ReplyDeleteIf you wish to test your PowerDisplay, you will need to write a class that implements Renderable. If done correctly, any Renderable that is implemented by anyone should work in your PowerDisplay. This means that the TAs will write a few implementations of Renderable and pass them into your PowerDisplay.
DeleteDean Dominguez:
ReplyDeleteFor width/height, is that the w/h of the displayable area not the JComponent?
Do we need to worry if your renderable objects will extend beyond the boundary of the displayable area?
The width/height is the width/height of your implementation of the PowerDisplay window.
DeleteYou don't need to worry about extending past the shown width/height.
tb
Dean Dominguez:
ReplyDeleteFor the xt credit. How will the test driver plan to send the new renderable to the PowerDisplay? You mention action listener, so what kind of event would be we listen for and what would we do after it happened, or will the driver send more data to a PowerDisplay method?
You have your button listening for an action event. When it's pressed, it would generate random coordinates inside your window, add them to your List and then have the window be redrawn.
DeleteDean Dominguez:
ReplyDeleteSo i have my program working and im trying to test it on the server. My Makefile is able to compile (make compile), its able to list (make list), edit (make edit), etc. However, it wont run.
I get this error:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
Any ideas? Anyone else having this problem?
This is the error you get when you are logged in remotely, and are running your shell in a console, rather than at the computer monitor. It won't be able to run any graphical programs, unless you have a local copy of X11 running, and connect using an appropriate "display forwarding" option. This is rather easy with a modern Mac or Linux box. Or you could (b) go work in one of the CS labs, or (c) checkout and develop your code on your local machine (my own preference).
DeleteTristan garwood:
DeleteTry ssh -X username@.....
So I developed the program on my own machine, and it ran just fine. It displayed everything and the button worked. So I committed it to the repository and then just to test it out one more time, tried running the program remotely, with X11 running. The window showed up, but there was no background color and my button didn't show up. Any idea what the problem is?
DeleteMax, I also found that your code runs ok on my mac laptop, but not so well via X display forwarding (although the button did display). I would say the main problem is that X display forwarding is incredibly inefficient, and always has been. It does work better, but still not great, over local ethernet.
DeleteThanks for testing it out for me. When it gets graded, will the TAs be using X display forwarding?
DeleteTo test our program, should we write a Driver class that implements Renderable, or should we write a main method within Renderable? Furthermore, if we were to create some test shapes that we wish to send to PowerDisplay, would these need to be coded within the Renderable class?
ReplyDeleteTo test your program you should write a small main that instantiates a new PowerDisplay object. This can be anywhere you like, but I would recommend putting it in a separate file, or in the PowerDisplay.java file.
DeleteThe only thing that should be implementing Renderable are the objects you wish to draw to the screen. While you are not actually required create any Renderable objects, I would strongly recommend making a simple one that draws a square or circle (since Graphics2D can draw this for you). To do this, you will have to create some class that implements Renderable, meaning you shouldn't be editing the Renderable interface. So to answer your last question, no they should not be within the Renderable interface
Just a reminder, the TAs and I have lots of office hours, and are happy to help you with the labs and other questions. The schedule is here:
ReplyDeletehttps://sites.google.com/site/cs251spr12/my-calendar
For instance, Joe has an office hour starting Tuesday at 3:00, and I have one starting Wednesday at 2:00.
(Note that, despite what it says, we won't be there over Spring Break.)
Hello I have been having a problem where the window pops up with the correct background color and then after about 10 sec the window loses its back ground color. Im running it off the repository and using Xming and putty. Anyone know what could be going on?
ReplyDelete