We are still working on fixing the code bugs, improving the application usability, and optimizing the code. There are a lot of small changes and enhancement that I’ve been working on, here, however I will detail the most important ones, that someone might actually find useful. So, let’s jump right into it.
Logging
Wt has a server log, and can be written to using the function Wt::log(). This can provide information about what’s going on and what the server is doing, check for errors, and it can even be used for debugging purposes. It is specially helpful if the server crashed to figure out what part of the code caused this problem. For it to actually be useful, logging should happen on every function call, and return.
On the server part of my code (the schematic editor back-end), there are many functions that will open a file and send it to the editor (for loading a previous project), save the current JointJS graph (for saving the user project), compare the schematic editor with the list of objects the user has defined and create a JSON file containing the differences (to update the schematic editor), and finally, read the current schematics and generate a UCF file. Now on every function call, I will log a simple message indicating that the function is called, and when finished, I check the return value of the function to see if an error has occurred or not, then log the results. After that we were asked to provide logging for the application front end as well. This includes all the JavaScript functions. The technical part is not a problem. I used a JSignal that I can trigger from the JavaScript code, that will call a C++ Wt::log() function. I added logging to the JavaScript functions that loads a file from the server, update the editor, and sends the schematic file to the server.
The log looks something like this:
[2015-Jul-26 14:13:32.246747] 28592 [/s3.wt 06dpCYFODGhXRbgT] [info] "Updating the schematic editor"
[2015-Jul-26 14:13:32.246814] 28592 [/s3.wt 06dpCYFODGhXRbgT] [info] "Schematic editor has been saved successfully"
[2015-Jul-26 14:13:32.246848] 28592 [/s3.wt 06dpCYFODGhXRbgT] [info] "/lib/Components/T3/Uart.js has loaded successfully"
127.0.0.1 - - [2015-Jul-26 14:13:32.246994] "POST /s3.wt?wtd=06dpCYFODGhXRbgT HTTP/1.1" 200 50
[2015-Jul-26 14:13:32.247021] 28592 - [info] "WebRequest: took 0.403ms"
127.0.0.1 - - [2015-Jul-26 14:13:32.255173] "GET /lib/Components/T3/Gpio.js?_=1437891203754 HTTP/1.1" 200 2036
[2015-Jul-26 14:13:32.302750] 28592 [/s3.wt 06dpCYFODGhXRbgT] [info] "/lib/Components/T3/Mspi.js has loaded successfully"
[2015-Jul-26 14:13:32.302811] 28592 [/s3.wt 06dpCYFODGhXRbgT] [info] "/lib/Components/T3/Gpio.js has loaded successfully"
Limiting connections to one wire per pin
We are using the schematic editor to actually generate a UCF file to configure the FPGA. And in this UCF file, each FPGA pin (and hence each digital pin on the board) can have only one connection. To do that, I had to modify the connection validation function (again!) to not allow connections when a pin is already connected. I also modified the function validateMagnet so that when the user click on a pin that is already connected, it will not create a wire. I provided the details and the code in my answer here.
So far so good, and everything works fines. But again, I have my worries.
I talked previously about the custom XML attribute “mode” that we added to JointJS ports (the board and modules pins) and that its main reason is to validate connections. When I was first assigned the task, the goal was to validate connections for the digital modes (input, output, and inout), but since the FPGA pins don’t have a fixed mode, I had to write a function that will change the board pin mode when connected, i.e. to be input when connected to an output pin. Hence, if the user wanted to connected this pin to an output pin after the first connection has been made, he wouldn’t be able to. See the problem? Now that every pin can have one, and only one connection, there is no point to check for the “mode” as the first connection is always allowed, and the second connection is always disallowed, regardless of the modes of the pins! So checking for digital modes is not necessary, and thus, changing the FPGA pins mode when connected is also not necessary as well!
The attribute “mode”, though not useful now for digital pins, it is still used to validate connections for analog, and power pins.
Removing variable names hard-coding
One last enhancement (bug) I worked on was to generate the JavaScript variable names dynamically. The only variable that I need to be global is the graph (the one containing the JoinJS paper and everything on it), as it is accessed from the C++ code and the JavaScript functions. Hence, I am making it global by attaching it to JS window object. However, instead of using a fixed property name, such as window.graph I was asked to use something dynamic, such as the editor ID. So, if widgetID is the string containing the editor widget ID, the graph now is actually a property of
window[widgetID]
Well, I am using this global variable to store one more thing, which is the wtLog() function that I use to trigger the JSignal (as I defined it in the C++ code). However, it is not necessary to be that way, as I can define in the JavaScript code and user JavaScript Wt.emit function instead of C++ createCall function.
The list of modifications and enhancements still contains many issues. So next week I will still be working on similar modifications. Till next time.
0 Comments