Description of the limitation and why it is relevant to address
Developing with Viktor without a pydev debugger can be really a challange. It cost a lot of time to fix bugs without this functionality. It should be a must.
I think this is relevant for the VIKTOR platform because fixing issues shouldn’t be done using print statements just to be able to read your data.
Hi enrique, thanks for adding this feature request.
Can imagine that having a debugger can be very handy for a lot of developers. Adding this capability is non-trivial, which i why it’s currently not supported.
I’m very interested to hear from more developers on the type of debugger they want to use.
Hi Matthijs, we are using the in-built Pydev debugger of PyCharm itself when debuging local code (vikor-free). Perhaps you can explain what other options could be possible when using Viktor now and in the near-by future.
First of all, thanks for being active in the community. We appreciate it, so please keep sharing your thoughts!
I understand why this feature will be valuable. In fact, we have had this in our issue board for some time. We give it a vote on your behalf, so it gets higher on the priority list. I cannot say when we will have the time to address this issue; we have so many nice features in the backlog, which also require our dedication.
Did you know there is an autoreload option? This means apps are updated automatically in your developer’s environment after you change the code. This helps increase development/debugging speed.
Autoreload is turned on by default since CLI v0.10.0. In older CLI versions, you need to use the flag -- autoreload
Hi Anande, We’ve been using --autoreload for a while already, we love it! It was a major step for speeding up our development process. A debugger (any kind ) would be the next step in making VIktor so much easier and enjoyably to work with. It would also same us a lot of time (and development budget). I hope you guys get to address this issue soon, it’s number 1 on our Viktor wishlist
Hi Enrique! Nice to hear you are enjoying the autoreload. I believe @matthijs will also be happy to read this; he created this feature himself!
I want to give you some insight into the roadmap of this ‘branch’ of development. Internally we call it Developers Happiness. First, we worked on the autoreload, as you already know. The next priority was to give developers de possibility of deploying their apps, and we have already made some nice steps in this direction. Currently, we are working on improving the experience for starting developers; this includes improving the documentation, creating sample codes/apps and making Docker and optional (but recommended) installation requirements. We expect to be ready with this somewhere in December/ January.
Maybe after this process, we can look into the debugger. We cannot promise anything for now, but your post at least started the discussion internally again.
Yeah, is not a problem to wait.
In the meantime what is the best way to debug or have an idea of which data are passed?
For example, I am using LinearPattern; I would like to retrieve the first and last instance, I assume I can do it using Children (which is not specified in the documentation) I will take it is the correct property, but because is a TransformableObject it will be great having some way to interrogate the data and visualize it.
I am currently using GeometryAndDataView to visualize some results, but most of the time objects are not serializable, for example (Object of type Point is not JSON serializable).
