Has anyone successfully set up a dev environment complete with emulation on the Mac? Does anyone have any instructions or links perhaps that might help?
Are You volunteering…?
There’s much to do.
Development platforms are probably an area of great variance, I muck around on a couple of Raspberry Pi’s but mostly on a battered old xubuntu laptop 32 bit PC with a lousy ‘k’ key .
I tend to do what work I’ve done on zynthian using idle.
I’ve had the gui and webconf running as an entity on the PC but not got the engines chugging.
I seem to remember that the JoFe uses a linux PC
I don’t see any problems with the mac but I’d stick it in a vm . . .
If I was to suggest a preferred IDE I’d say pycharm but others will have alternatives.
The release cycle is being heavily addressed and it looks lie that has ‘traction’ . …
It’s really down to what you would lie to be involved in developing.
Obviously any help is welcome.
I do intend to volunteer if I can find things that I can do to contribute. But, I have to follow the proper steps:
PHASE 1: Set up dev environment.
PHASE 2: ?
PHASE 3: Profit
Seriously, though, I’ve heard of PyCharm and read a bit about it and that looks like it would be the one I would want to go with. Thanks for that.
I’m also confused on how to run/emulate the code on a non-Rpi machine for testing purposes. I don’t mind running Linux under a VM if necessary, but I’ve read that that isn’t necessary.
I’ve read about QEMU, but I haven’t been able to get it to work successfully. I’m completely new to Rpi development and I see conflicting and outdated information on how to set it up. My Zynthian is built on an Rpi 3 B+, so ideally, I need to be able to emulate that particular board.
Ideally, I’d also like to be able to edit/run/test code off a microSD card, which I can then pop into the Zynthian. (I have extFS for Mac to be able to read/write to them.)
Any further assistance is appreciated!
I only run the webconf on a Linux machine.
No ide but atom…
And zynthian-ui directly on the raspi with vi.
Atom is pretty great! I use that, too.
So I’ve been working with PyCharm. Bit of a learning curve, but I think I really like it! Makes it easy to integrate with GitHub, which I’m still getting used to (been a long time since I’ve used VCS). But, it also allows you to easily deplpoy the changes to the Zynthian as you work. It’s the closest that I’ve been able to come to live coding/testing.
Glad you like it. It’s VERY powerful.
Could you draw a block diagram of how you connect it?
I would like to write up a ‘standard’ development environment and such an example would help that process?
I would be happy to. I’m not sure what a block diagram would look like for this type of thing. Do you have an example you could point me to?
It may seem simplistic but it helps break down what people have configured.
How is this? Let me know if you need anything other information or would like any changes.
Thanks I’ve been looking at PyCharm working with online debugging using remote Interpreters and can confirm that running the tornado based zynthian-weboconf, works fine onto a remote Raspbeery Pi.
It builds a tmp directory under the zynthian-webconf/ directory with a unique identifier . . .
And runs quite well, allowing a full debug environment.
I have the settings and will write it up in the wiki if it’s of any use to anyone.
The mappings from the development machine to the raspberry pi is probably the main area to standardise in this environment which is the kind of thing I want to put into the flow diagrams.
Because the zynthian software exists across several different repositories i’, not sure, yet, how this could be set up in the PyCharm environment.
I’m going to try different zynthian components ( zyncoder, zynthian-webconf, etc … ) opened in different PyCharm projects.
That is exactly what I’ve been trying to accomplish. It’s slow-going because I’m new to Pi development.
What I have done (hopefully this will work for you) is this:
- Create a new, blank PyCharm project. Call it Zynthian.
- Go to VCS->Checkout from Version Control->Git.
- Use the GitHub URL for the given “repositoryname” and use the directory PyCharmProjects/Zynthian/repositoryname.
- When you Click Clone, it will ask you “Would you like to open the directory …/PyCharmProjects/Zynthian/repositoryname?” Click Yes.
- Then it will ask you “How would you like to open the project?” Select “Open in current window” and check “Add to currently opened projects”.
- When you click “Okay” it will add it as a sub-project to Zynthian. You will see it in Bold letters. If it is not bolded, something went wrong somehwere.
- Go into Settings->Version Control->Ignored Files. Make sure to add repositoryname/.idea folder to the list.
- If you go to Settings->Version Control, you should see a list of all repositories that have been added and they all should say “Git”.
So, for example, my setup (so far) looks like this (note that docs is not bold because it is not a GitHub folder):
- If you haven’t already, go to Tools->Deployment->Configuration. Set it up like this:
- You can then set up the mappings between the projects and the Zynthian directories in the same dialog:
This is what I have so far. I would LOVE to be able to debug remotely or run an emulation locally. I just haven’t been able to get any of that to work.
The trick with the remote debug is to define a remote Interpreter.
The Little cog wheel has a Show All option which is a bit non intuitive and is often used during the initial confusions.
However we want the Add Menu Option.
Which gives us
Select the ssh option . . .
and fill all that in . . .
and that. . . .
**AND THEN SET THE INTERPRETER TO python3 in the following **
Hey Presto All the code loaded on the remote pi !!
It strike me that using a Raspberry Pi as a development environment would seem to a lot less involved than using an emulation.
Oh, cool! I’ll definitely give it a try!
You are right that it would be less involved than emulation. I think with what I have done so far, I can be productive, but this is even better. This gives me pretty much what I was looking for and is easier to set up!
Ok Built a similar structure…
Unregistered VCS root detected, message
Do You get the same? I presume it’s the symbolic links in zynthian-ui to zyncoder & data.
Yes, those are the symlinks. I saw that, too. I believe that dialog should only be relevant for the interaction with GutHub and shouldn’t affect any dev or deployment activities. You should be able to ignore them and leave them as-is.
In a perfect world should we fork the zynthian repos into our own fork?
Yes. I’m new to GitHub, but from what I have read, that is how it is preferred to be done unless you are on the core development team. I have forked all Zynthian repositories to my own account. Then, I can edit/commit at will. Once you have something to contribute, then you issue a pull request, which asks the Zynthian project to incorporate changes (or even just parts of changes) into the main project.
Unfortunately this feature is only available in the professional version
Yes, It is a pain but to work in the modern environments effectively the sort of complexity offered is what is required. They do seem to relenting on their recent rather aggressive approach to pricing. It’s £150.00 for the first year and decreases after that, althou’ they have,as I say, mucked around with the pricing model before. However when all said and done the obvious alternative is Eclipse (Other suggestions appreciated, I know there are others people speak of atom but I’ve not looked because for better or worse I know most of the bits I require in pycharm) and last time I looked at that their were two python camps that didn’t seem to be getting on.
I suspect the open source model might not be able to compete with commercial products in such fast developing arenas especially when commercial users might well buy up 1,500 licenses and want very specific aspects developed.
I’m biased obviously I graduated from idle to eclipse and then pycharm and it’s my goto python environment, but it’s hard to learn every aspect of it. The debugger is very good and Microsoft have demonstrated that staying within one environment for development is a good model. The process of jumping between on screen terminals to start & restart particular components is an awful lot of wasted keypresses however mechanical it may become. I would be hard pressed to do much programming work without it.