This week, I focused with the structuring of my previous coding. As being told by my supervisor, the way I programmed was not well planned yet. The main problem that causes these, is the bad habit of hard coding. I tend to hard-coded many things that I am uncertain with. And I found that, this habit actually lead to more work to do, as I need to clean up the code again and solve some other problems that came out with, and it costs much time to figure out how to solve the problem and to maintain my previous codes.
The WFileResource
The WFileResource functionality is similar to the WResource, but it can be used to access files. I uses WFileResource as a tool to access the approot of the Witty Application, as the approot cannot be accessed by the browser or the front end. The WFileResource is convenient as it can be used to access any files from the backend of the server. The file can be retrieved simply by sending a GET request to the server. Besides, in the WFileResource source code file, I call the function Wt::WFileResource::setFileName(fileName) to response the file back to the request.
The File Transfer Between Servers
One of my task this week is to transfer a file from one server to another. It would sounds a little difficult at first as the files are stored in the approot of the server, which is not publicly accessible by other users or servers. The usage of WFileResource could solve this problem, as it allows the access to the approot from the server itself. Thus, I setup a WFileResource in the host witty application. Then, by using a WClient, I send a GET request to the WFileResource of host witty application to retrieve the file.
A similar problem I faced when I need to retrieve a file from the approot of the server in the JavaScript (browser side), as the JavaScript tends to load files or directory from the docroot of Witty application. Similarly, putting a GET request to the WFileResource from the JavaScript side could retrieve the file from the approot.
The Standalone Simulator UI Interface
After finish the communication of the host witty application and the simulator, I worked on the standalone simulator that facing the similar problem. However, the simulator need to have its own UI for now as the user would need to upload their ELF file for simulation. The uploaded ELF file should be stored in the approot as well, not publicly accessible by anyone else. As the first approach, I looked over the Witty API for uploading file functions. I found that the Witty API actually limits the uploaded file size to 128kB in the default config.xml. This is a common problem I found as uploading a file larger than 128kB, will eventually emits the signal of fileTooLarge() . Since the ELF file size can be increased up to few MB in size depends on how long the program that being written could be, the possible solution that I found is to change the config.xml contents, <max-request-size>128</max-request-size> to my desire uploading size. I found Witty API to be useful on this as the files that had been uploaded can be easily located using the function spoolFileName() .
After solving the Witty uploading issue, I will need to specify the total line number of the C program as it is not included in the ELF file. Looking through the GDB tools again, I found that the GDB tools does not have any function that provide the total line number of the source code. Instead of implementing one more uploading widget for the source code file, I replaced it with an editor box, for the user to input the total line number of the source code. Then, I implemented some witty widgets for the simulation functions, such as stepIn or restart buttons. Also, I included the JavaScript console functions for each one of them, so that the user could have two alternative of using the buttons or typing in the browser console. It is really exciting when my colleague Zheng Yi, first to try out the Standalone Simulator for his testing on the ELF file he made. Fortunately, it worked fine after fixing some bugs on the simulator.
0 Comments