Search found 498 matches

by stijn
Wed Oct 28, 2020 7:11 pm
Forum: Development of MicroPython
Topic: 1.13 - import libs is slower than 1.12 ?
Replies: 2
Views: 44

Re: 1.13 - import libs is slower than 1.12 ?

Which libraries, and how did you measure this exactly?
by stijn
Wed Oct 28, 2020 7:53 am
Forum: Development of MicroPython
Topic: Problem with MicroPython external C modules
Replies: 7
Views: 184

Re: Problem with MicroPython external C modules

@Jimmo do you know where the discrepancy between the .map and the .elf comes from?
by stijn
Sat Oct 24, 2020 6:57 pm
Forum: Development of MicroPython
Topic: Problem with MicroPython external C modules
Replies: 7
Views: 184

Re: Problem with MicroPython external C modules

Hmm, no idea honestly. The .map shows the module has been built succesfully - moreover, if I'm not mistaken the .map gets created by the linker, no? But I don't know why it's not in the .elf (or maybe it is, but your grep command doesn't reveal that). Don't have an STM to test so cannot help you any...
by stijn
Sat Oct 24, 2020 11:19 am
Forum: Development of MicroPython
Topic: Problem with MicroPython external C modules
Replies: 7
Views: 184

Re: Problem with MicroPython external C modules

Hard to tell without seeing all code/directory structure exactly as you have it. When building, does it show that it's compiling your code (can also test this by making a syntax error in your code, if there's no compiler error following that it doesn't get built)? One of the first lines should be .....
by stijn
Thu Oct 22, 2020 7:26 pm
Forum: Development of MicroPython
Topic: git-flow extension for developers
Replies: 8
Views: 233

Re: git-flow extension for developers

See e.g. https://githowto.com/aliases. use a command as specified there, or modify the [alias] section in your global .gitconfig file (in your home directory)
by stijn
Thu Oct 22, 2020 7:11 am
Forum: Development of MicroPython
Topic: git-flow extension for developers
Replies: 8
Views: 233

Re: git-flow extension for developers

It ideal for 'One developer' -> 'One pull request' -> 'One acceptor into master thread'. Apart from what Jimmo says note that it's also possible to have multiple developers ('acceptors') which are allowed to push to the master branch and/or do other administrative tasks. I think he was suggesting t...
by stijn
Tue Oct 20, 2020 11:46 am
Forum: Development of MicroPython
Topic: git-flow extension for developers
Replies: 8
Views: 233

Re: git-flow extension for developers

To Damien George: Is it possible to create a branch 'feature\esp32_pwm' with applied PR#3608? Then I will create a Pull Request to that branch. To add to what Jimmo says: practically the easiest to get that code (I think) is to create that branch yourself by pulling from the Github PR. Setup a git ...
by stijn
Sat Oct 10, 2020 11:57 am
Forum: Development of MicroPython
Topic: Doc change pull requests languishing
Replies: 4
Views: 261

Re: Doc change pull requests languishing

hlovatt wrote:
Fri Oct 09, 2020 10:00 pm
I'm editing directly on GitHub and it doesn't seem to have that ability.
Ah that's too bad. Might be less work to work locally from a fork then push.
by stijn
Fri Oct 09, 2020 7:40 am
Forum: Development of MicroPython
Topic: Doc change pull requests languishing
Replies: 4
Views: 261

Re: Doc change pull requests languishing

In general I think these contributions are worth it. However (left a github comment as well) none of the commit messages adhere to the coding standards, only the Pull requests titles do. So I'd suggest you change that: if it cannot be merged as-is, it's more than twice the work for the maintainer. A...
by stijn
Mon Oct 05, 2020 7:13 am
Forum: General Discussion and Questions
Topic: Embedding in a Windows GUI application
Replies: 2
Views: 140

Re: Embedding in a Windows GUI application

See mpconfigport.h and mpprint.h: most printing happens via the objects mp_plat_print, mp_sys_stdout_print, mp_stderr_print. If you change their definition you change where the output ends up. Those are meant to be used to do what you want and it's a better solution than your callback approach becau...