@Viv, I can successfully connect to the visualizer tool using my gmail credentials. I am now trying to connect the visualizer to a local network running on my machine. There seems to be two options to connect the visualizer to the network:
Provide a session information file to the visualizer;
Provide the visualizer session ID to the local network.
To enable VLOG messages, do make sure you build the local_network_controller target with VLOGGING=ON (you pass that when you run CMake such as cmake .. -DVLOGGING=ON)
now when you build local_network_controller, VLOG messages would be enabled.
Next up when you run local_network_controller it will ask you if you want to enter a session_id to thereby report to the Visualiser. At this point, just give it the session_id you have from the website for your created session and you should see it linked fine (If you do not see the tool ask you to enter a session_id, then most likely VLOGGING is not enabled).
Just out of curiosity, where did you find
if it’s mentioned somewhere as an option, I’ll go remove it unless you meant the “Import Session” feature. That does not tie into the local_network_controller.
Once you have an active session, you can choose to “Export” that session from the main page. That will give you a csv file with all the VLOG messages that the server received for the corresponding session. That’s meant to be used to say paste into an email or chat convo to explain a problem.
Import is pretty much the reverse, it takes the full csv(not a small portion) file that you got from Export and populates a new session with the info. So for example if someone ran a network behind a firewall/chose not to report to the visualiser website but instead have the server run locally in a LAN, they could export their session and pass it to someone to import onto the visualiser tool. With the Timeline, Dev’s should then be able to go back and see exactly what happened and analyse the problem a bit better hopefully.
So the network link with the visualiser is unidirectional right? The logging information is only sent from vaults to the visualiser and it only acts as a graphical representation of the logging information, not as a control panel.
Which branch and commits are you using? I tried ‘next’ from the MaidSafe super-project and its corresponding versions of submodules (obtained when doing ‘git submodule update --init --recursive’) to no avail. The logging code to communicate with the visualiser appeared in a more recent commit.
When using the latest revision of each submodule ‘next’ branch, which contains the visualiser code, I get a compile error because ‘ms_add_default_tests’ does not seem to be defined…
Yes only vaults communicate with the Visualiser tool and not the other way around. Visualiser apart from the optional hostname a vault can choose to send does not retain any info abt a vault’s machine nor try to keep connections open.
It’s been a couple days since I’ve run the local_network_controller. I normally just use latest next on Super-Project and all submodules with a git alias:
# .gitconfig file
[alias]
pu = "!f() { branch=$1; if [[ -z $branch ]]; then branch=next; fi && echo Updating Super project on \\'$branch\\' && git checkout $branch && git pull && git submodule foreach 'git checkout '$branch' & git pull'; }; f"
^^ with that either git pu by default gets me next on Super-project and all submodules. or you can specify a branch to instead pull that such as git pu master
Dashboard does not report of any build issues currently.
which platform are you trying this on? To confirm I just tried building local_network_controller on Win8.1 and seems to build fine on latest next Super-Project & submodules
I am on OS X 10.8.5. I used the ‘unix_installers’ branch and ended up with a working configuration. I could successfully run the network and connect it to the visualiser.
At this point, I believe it would be better to focus my efforts on getting the static monolithic library working and wrappers for JavaScript. Let me know what I can help on.
If you have fpm (ruby gem) and check out next on the superproject then test the OSX installer with the code already in place (And commented for OSX) then it would be a huge help. We have an outstanding task and this was halted last week due to other priorities. It may just work as is, but great to test it (need to compile in Release mode to get installers - target is maidsafe-dev).
If you jump on Jira and perhaps @Viv could get some tasks allocated to help though. Thanks Eric, a huge help for sure (we do not let such things go unnoticed either)