More comments on the GUI config interface
Datseris opened this issue · comments
I am continuing here from your answer in: https://discourse.julialang.org/t/drwatson-the-perfect-sidekick-to-your-scientific-inquiries/23241/31?u=datseris to keep the discourse post from getting off-topic.
I see. But in the end in the actual code that this is actually used, you still use a Dict. So, this means that you have a GUI to make the Dict, but then in the code you will actually do all the "coding by hand" process to use the dictionary.
I think that the dict_list approach is faster, for making more than one file. With your GUI you really have to make each individual config by hand.
How does your plan here support custom user-defined data?
A final advantage of dict_list, which is completely subjective, is the following: There is no confusion: the config generation and the config reading is done with the same identical structure, which has the same identical keys. You also know the keys because the dictionary is defined in-code, in proper .jl text file. So it is human readable. I am not sure how true this is with JSON. Example: you have to run your code over cloud, and you cant use a GUI. Thankfully you have already made your config files. But you don't remember anymore what is the exact name of each key (exact with respect to capital letters and white space). How do you find out? You have to run a separate Julia process, load your dict, and display all keys.
With dict_list you just look at the complementary script file that defines the dictionary.
Correct me if I am wrong please.
All the above being said though, I believe this GUI interface can be extremely advantageous for collaborating and sharing a project with other scientists who may not know how to use Julia in detail. For this to work what is missing is some kind of GUI support for running a main.jl script: Some GUI that chooses a config file, chooses a main.jl that has some main(dict) function that only accepts the resulting dict form the config, and then runs the main with the given dict.
This could be veeeery helpful for collaborations of scientists.
The only unfortunate thing for DrWatson is that, as I said, Electron is too heavy of a dependency. If you want to contribute this functionality, we have to make an extention (as it is my sworn duty to keep DrWatson having only julia in its require, or packages that have only julia. so that it can run even on potatoes)
I am continuing here from your answer in: https://discourse.julialang.org/t/drwatson-the-perfect-sidekick-to-your-scientific-inquiries/23241/31?u=datseris to keep the discourse post from getting off-topic.
Thanks for moving the discussion. Sorry I spammed your thread on Discourse :)
I see. But in the end in the actual code that this is actually used, you still use a Dict. So, this means that you have a GUI to make the Dict, but then in the code you will actually do all the "coding by hand" process to use the dictionary.
Exactly, well at least that's my current approach.
I think that the dict_list approach is faster, for making more than one file. With your GUI you really have to make each individual config by hand.
That's also true, however it should not be difficult to allow multiplicity of files in the exact same way of dict_list
A final advantage of dict_list, which is completely subjective, is the following: There is no confusion: the config generation and the config reading is done with the same identical structure, which has the same identical keys. You also know the keys because the dictionary is defined in-code, in proper .jl text file.
JSON was the first format that came to my mind since it is (in my opinion) quite readable, but that can be easily changed.
So it is human readable. I am not sure how true this is with JSON. Example: you have to run your code over cloud, and you cant use a GUI. Thankfully you have already made your config files. But you don't remember anymore what is the exact name of each key (exact with respect to capital letters and white space). How do you find out? You have to run a separate Julia process, load your dict, and display all keys.
In JSON keys are saved as well as the values. It is kind of similar to a dict. i.e. for my examples one would get the following JSON file:
{"Bool field":true,"Int Field":4}
All the above being said though, I believe this GUI interface can be extremely advantageous for collaborating and sharing a project with other scientists who may not know how to use Julia in detail. For this to work what is missing is some kind of GUI support for running a main.jl script: Some GUI that chooses a config file, chooses a main.jl that has some main(dict) function that only accepts the resulting dict form the config, and then runs the main with the given dict.
I guess this could be implemented as well! A nice idea would be to make a full GUI package that would work as a wrapper for DrWatson (so no need for depedencies!).
One other advantage that I had in mind is that one can incorporate limits and options in a very natural way, hence making sharing even easier and safer (no risk with the user using crazy values).
Thanks a lot for all the input this definitely helps me thinking on what this package could become!
I thought about this more, and I realize that this functionality does not in fact have the same scope as dict_list.
dict_list's purpose is really to run multiple simulations with just different parameters. That's the main deal. Here, you are trying to have an interface for creating a config file. Even though there is some over lap, the actual goal is not identical.
So, in the end of the day, I shouldn't have compared much to dict_list.
A nice idea would be to make a full GUI package that would work as a wrapper for DrWatson (so no need for depedencies!).
Yes, this seems like the best approach.