just download the mmport.app.zip .
its not as nice as i wanted but here it is.
1 Like
Why are you committing zip files to git?
This is quite the bad practice and doesnāt help others contribute.
Also you should add a license file to the repository so itās clear under what terms this can be used.
1 Like
im sorry iāll try to upload the folder
ok can you check now ? sorry again, i hope its better now.
This is really interesting, because thereās a lot of boring boiler-plate work in porting. This would help, and then the developer could just focus on the harder modules to port.
I didnāt run any of the code or app yet, but I poked around and it looks like these are the sources that are actually doing the work:
Is that right?
If this is really just a collection of python scripts with a macOS app wrapper, then Iād suggest making the mmport/ folder the top-level of your github repo. So itās what people see when they go to your repo.
Then delete the macOS .app and any .zip files from the repo and put them into the Releases tab (not in the github repo).
Developers are suspicious when they see executable files/apps or binaries in a github repo, because we all know that running programs off the internet that read and write files on your computer can cause problems. So the best thing you can do is just put the source code files and READMEs into the repo, and nothing else. Developers can clone your repo, inspect the code, and run it. That will make your project more transparent and allow others to contribute if they see any improvements in the code and want to add features or update it. There are a lot of other reasons to keep binary files (apps, zips) out of the repo (diffs, merging, versioningā¦), but thatās a whole other topic.
For the macOS app and any zip files, delete them from your repo, and make a new āReleaseā (it will go here: Releases Ā· semierendonmez-commits/mmport Ā· GitHub). Put the compiled macOS app and other files there in the release. Non-developers who donāt want to run python scripts can still download your app and run it, but you would direct them to the Releases page.
Hope that helps, itās a common point of confusion if youāre new to hosting repos on Github.
Another thing ā SDK v2.3 was just released, and so these features are now supported:
| Finding | Result | Why |
|---|---|---|
stream |
excluded | libstdc++ stream support isnāt built |
| exception | excluded | -fno-exceptions |
3 Likes
yeah iām kinda very new to hosting repos sorry. can you check again if its allright now? yeah i did this with claude last night and they released the new firmware today. iāll take a look.
Yeah, more like that! Itās looking like a nice python tool now.
1 Like
what a cool idea and project - great stuff !
Im amazed that this was able to do so many of the plugins you validated, thats a fantastic result!
Iād , as a dev, echo danns comments,
Iād never run a binary, esp. as its python, so I could directly run from a repo.
(also windows/linux users could, potentially, use this from a repo)
there are two other things, that would make me cautious
a) installing other software
you get the user to use homebrew, so I dont see a need for it to install arm compiler, just get user to do this. I donāt want a 3rd party app installing things for me 
b) its not in englishā¦ prompts or code comments.
English is not better, but (unfortunately?) it is the defacto/common denominator in programming circles - so would help give it wider appeal.
personally, something like this Id want to be able to inspect code to learn more.
(personally, Im fine with python , so I dont need the comments, but its useful to know authors intent, as well as what the code says ;))
I think it would also be useful to have a document that covers exactly HOW its doing the ātranslation/portā
its great to have it do the āfirst passā,
but like any tool itāll have limitations, then the user/dev will have to take over (in many/most cases)
this is much easier if you know how its done the translation, and what its done and not done.
also non-devs might use something like claude to continue,
if you have a document which describes what itās done/why, they can point claude at that for an initial context .
(you mention that you used claude for this, it can very easily create this document)
this is another reason for users/devs to use your repo, rather than a binary.
the dev/claude can look at your python code to understand the transformation
again, great job, there is a lot of boilerplate code so having something generate that is a nice timesaver.
btw: its a very different project / different goals,
but my RNBO project, see topic here has some similarities, e.g. being ānon developerā focused, and being templated based code generator.
you might finding it interesting, and also the issues some users had.
(iāll admit windows gave me the most issues, surprise, surprise 
)
1 Like