There are perhaps not as many log messages as could be. I tend to add and remove them as needed.
If you understand the concept you COULD try to fork the widget for debugging purposes. You could even attempt debugging the current version if your browser supports. I am constantly amazed and impressed with Chrome, where I am able to set breakpoints and inspect data just like any other software I might work on…
Kevin and I are progressing in parallel spaces at the moment, although I am starting some pre-alpha level integrations with a version of his code.
What would be useful, to me at least, would be a version of the CP/serialport workspace that has the tinyG widget included. That would have some additional scrreen space for the all important debugging screens.
I assume I could fork tinyG workspace and back out he other widgets, and also assume there is a much better way. (always seems to be).
Any thoughts?
Carl, the better way would be to create the widget you’re after and pull in the necessary widgets in the cprequire_test() method at the top of all the JSFiddle’s. That test method runs code that only gets run in the test environment. That’s the area where we all load the widgets that our widget depends on. Then, when the widget is pulled into production, you know how it’s going to interact with everything. The cprequire_test() method gets removed when the code is loaded via chilipeppr.load(), i.e. when the main workspace loads it.
Carl, there’s an example of that at the top of my widget. Since you’re cloning and adding to my work, you could just add to that part also.
Please comment on my interpretation of your recommendation:
- Assume I am going to implement something by adding it to Kevin’s configtinyg widget
- For now we assume Kevin’s code is stable and fixed, my question is not about revision control (kevin’s future revisions).
- So my strategy will be to clone Kevin’s codebase, then modify it and test it. The modified configtinyg will be launched in CP the same way, thru Kevin’s button in the TinyG widget.
- My fist step is to clone Kevin’s code. Fork is not implemented in his widget, so I navigate to http://fiddle.jshell.net/khauser/vc1vd3n5 and open it, displaying in jsFiddle. . There I select Fork on the Blue header line and a fork of Kevin’s code is now placed in my jsFiddle account, it happens to be here -> http://jsfiddle.net/cmcgrath5035/f7kk0che/.
- I make my revisions and test them in their own test space.
- Now I want to test that the TinyG fiddle will properly open and close my modified version of configtinyG. To do that, I fork the TinyG widget, then fork again in the jsFiddle IDE so that I have an editable copy in my workspace. That is actually here -> http://jsfiddle.net/cmcgrath5035/u44mk50n/.
- In my forked TinyG fiddle, I edit line 206 in the cpdefine method to point to my version of the code, and test that it inits and runs properly from the TinyG widget
- When ready, I tell John to come and get it.
Am I close?
I’ll modify Step 4. in prior message, the Fork from Kevins widget (upper right cornet carot) is now functional. So rather than forking from http://fiddle.jshell.net/khauser/vc1vd3n5 I fork from within the open widget. That appears to be the same as navigating directly to http://jsfiddle.net/khauser/vc1vd3n5/ from a newly opened tab in Chrome.