Update to newer upstream micropython

[The-Compiler]

Hey! First of all, thanks a lot for porting MicroPython to the NSpire, it's really useful for me!

I wanted to ask if there's a particular reason (that is, other than lack of time, which I can completely understand) this was never updated to a more up-to-date upstream micropython?

If there isn't, and you don't have the time to do this anytime soon, I might find some time in September to see if I can get it to build, and try to merge the upstream micropython master. If this works out without too much effort, should I open a PR for it? Not sure how reviewable that'd be though...

[Vogtinator]

Hey! First of all, thanks a lot for porting MicroPython to the NSpire, it's really useful for me!

I'm glad to hear that! You should thank the MP folks for their work though, porting it is a miniscule part compared to the work they did upstream :-)

I tried to update to a newer version in the next branch both here and in a local clone a while ago, but due to huge changes in the makefile and overall project structure that wasn't trivial... I did a quick port of the remnants onto upstream/master and pushed it into the next-next branch here. It builds fine but has quite some issues, for instance everything you enter causes an "uncaught NLR exception".
It would be great if you could debug that a bit, currently I don't know where to start.

Anyway, it would probably be best to clean the port up a bit and maybe, just maybe, make it clean enough to go upstream.

[The-Compiler]

I just set up the SDK and got it to build, and indeed I see the same issue.

I tried doing the same https://github.com/micropython/micropython/pull/1686/files did to show some more information, but unfortunately that just jumps into nlr_jump_fail again.

Looking at the memory with the Firebird debugger doesn't really seem helpful either, two examples:

125341F0  E0 D4 51 12 00 00 00 00-00 00 00 00 00 42 53 12   ��Q..........BS.
12534200  48 31 52 12 01 00 00 00-26 00 00 00 00 00 00 00   H1R.....&.......
12534210  00 00 00 00 00 04 01 00-00 00 00 00 B0 41 53 12   ............�AS.
12534220  00 00 00 00 01 00 00 00-00 00 00 00 00 00 00 00   ................
12534230  0A 00 00 00 0C 00 00 00-03 00 00 00 03 00 00 00   ................
12534240  50 42 53 12 00 00 00 00-00 00 00 00 00 00 00 00   PBS.............
12534250  01 00 00 00 00 00 06 0A-11 00 00 00 FF 11 5B 00   ............�.[.
12534260  02 00 00 3A 00 00 00 00-00 00 00 00 00 00 00 00   ...:............

1253EA80  68 7D 52 12 00 00 00 00-00 00 00 00 90 EA 53 12   h}R.........��S.
1253EA90  D0 D9 52 12 01 00 00 00-26 00 00 00 00 00 00 00   ��R.....&.......
1253EAA0  00 07 00 00 00 04 01 00-00 00 00 00 40 EA 53 12   ............@�S.
1253EAB0  00 00 00 00 01 00 00 00-00 00 00 00 00 00 00 00   ................
1253EAC0  0A 00 00 00 0C 00 00 00-0B 00 00 00 0B 00 00 00   ................
1253EAD0  E0 EA 53 12 00 00 00 00-00 00 00 00 00 00 00 00   ��S.............
1253EAE0  02 00 00 00 00 00 06 0A-11 00 00 00 FF 1B 81 07   ............�.�.
1253EAF0  00 81 64 01 32 11 5B 00-00 00 00 00 00 00 00 00   .�d.2.[.........

I don't seem to be able to get a backtrace (because it's something similar to setjmp/longjmp if I understand correctly?!), and I'm not sure how to debug this on a C level so I could break earlier - any pointers would be appreciated! 😉

[Vogtinator]

You can use gdb to set a breakpoint on longjmp and get a backtrace from there - make sure to enable debuginfo first.
The issue is most likely somewhere in main.c - maybe you could compare that to unix/main.c and rebase on that?

[The-Compiler]

The issue is most likely somewhere in main.c - maybe you could compare that to unix/main.c and rebase on that?

That helped, thanks! See #7.

[adriweb]

Bumpity bump :)

Also, after rebasing from upstream, you should consider adding more default modules, like random (all other micropython on graphing calcs have it, for instance)

[The-Compiler]

Since #7 was merged, this can probably be closed? Unless it's time to rebase again, seeing that #7 is about a year old.

edit: Oh, looks like it's only in the next-next branch, not nspire.

[adriweb]

Well, that updated main.c, but MP itself has changed quite a bit since the rest of the codebase was forked for/to the nspire.
Basically it would be nice to have (the core of) MP v1.9.4. If I'm not mistaken, the current Nspire version release is based on v1.3.4?

Also, for next-next, I'm not sure which version it's based off, I've seen it getting updated in 2017, but...? Well anyway, it'd still need a rebase from upstream.

[The-Compiler]

FWIW I personally likely won't continue working on this - that change was self-motivated (needing a new enough Python for an exam where the Nspire was allowed 😉), but nowadays my NSpire mostly collects dust, and most likely I won't have any exams where I need it anymore until I got my bachelor's degree next August.

[adriweb]

Right - it’d be a task for @Vogtinator then :p
Initially I wanted to create a new issue for the update to v1.9.4 but considering this one was there and still open...

[Vogtinator]

Right - it’d be a task for @Vogtinator then :p

Yup - unfortunately it would require an almost complete rewrite as micropython's architecture changed quite a bit.