Vogtinator
Update to newer upstream micropython
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...
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.
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! :wink:
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 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.
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)
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.
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.
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 :wink:), 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.
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...
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.