[Solved] User defined data types broken 1.19.1-443

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
Post Reply
hippy
Posts: 130
Joined: Sat Feb 20, 2021 2:46 pm
Location: UK

[Solved] User defined data types broken 1.19.1-443

Post by hippy » Sat Sep 24, 2022 8:52 am

Some time ago I created a user defined data type, along with unary and binary operators for it, which I recall was based on online documentation and examples, eg https://micropython-usermod.readthedocs ... ds_10.html

What I have basically boils down to this -

Code: Select all

const mp_obj_type_t monotonic_time_type = {
    { &mp_type_type },
    .name = MP_QSTR_monotonic_time,
    .print = monotonic_time_print,
    .make_new = monotonic_time_make_new,
    .unary_op = monotonic_time_unary_op,
    .binary_op = monotonic_time_binary_op,
    .locals_dict = (mp_obj_dict_t *)&monotonic_time_locals_dict,
};
That's now stopped compiling which I guess is due to a refactoring in recent days; I am using 1.19.1-443, Raspberry Pi 'RP2' port.

Is there any documentation or guidance on how I need to refactor my own code to get it to compile and make it work as it used to ?
Last edited by hippy on Sat Oct 01, 2022 3:05 pm, edited 1 time in total.

User avatar
jimmo
Posts: 2754
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: User defined data types broken 1.19.1-443

Post by jimmo » Fri Sep 30, 2022 7:48 am

hippy wrote:
Sat Sep 24, 2022 8:52 am
Is there any documentation or guidance on how I need to refactor my own code to get it to compile and make it work as it used to ?
Sorry for some reason I didn't see this in the "new posts" list (one of my main frustrations with this forum!).

Yes, see https://github.com/micropython/micropyt ... leshooting

(This is the page you get if you follow the link that is now presented after a compile error)

hippy
Posts: 130
Joined: Sat Feb 20, 2021 2:46 pm
Location: UK

Re: User defined data types broken 1.19.1-443

Post by hippy » Fri Sep 30, 2022 5:19 pm

Many thanks for the link and no need to apologise for having not seen the post sooner.

Might as well start with good news - Worked for me; now compiling again without error. Just had to change the definition in the OP.

I hadn't known about that linked page, nor the Wiki to be honest. I guess I need to get myself more familiar with it and pay more attention to PR's etc.

There's a minor typo in the linked page; it uses the new format for 'local_dict' in the 'if it was' example, rather than old format. What it currently gives -

Code: Select all

    locals_dict, &mp_obj_array_locals_dict,
};
Should be -

Code: Select all

    .locals_dict = (mp_obj_dict_t *) &mp_obj_array_locals_dict,
};
Looks to me like there might be a missing STATIC in front of MP_DEFINE_CONST_OBJ_TYPE example -

Code: Select all

then you can add STATIC in front of the MP_DEFINE_CONST_OBJ_TYPE.

MP_DEFINE_CONST_OBJ_TYPE(
Also I didn't see any link given with the error when I compiled ...

Code: Select all

[ 50%] Building C object CMakeFiles/picopython.dir/own/modtime_monotonic.c.obj
/home/pi/pico/micropython/ports/picopython/own/modtime_monotonic.c:206:6: error: 'mp_obj_type_t {aka const struct _mp_obj_type_t}' has no member named 'print'
     .print = monotonic_time_print,
      ^~~~~
/home/pi/pico/micropython/ports/picopython/own/modtime_monotonic.c:206:14: error: initialization makes integer from pointer without a cast [-Werror=int-conversion]
     .print = monotonic_time_print,
              ^~~~~~~~~~~~~~~~~~~~
...
...
/home/pi/pico/micropython/ports/picopython/own/modtime_monotonic.c:210:20: error: initialization makes integer from pointer without a cast [-Werror=int-conversion]
     .locals_dict = (mp_obj_dict_t *)&monotonic_time_locals_dict,
                    ^
/home/pi/pico/micropython/ports/picopython/own/modtime_monotonic.c:210:20: note: (near initialization for 'monotonic_time_type.slot_index_binary_op')
/home/pi/pico/micropython/ports/picopython/own/modtime_monotonic.c:210:20: error: initializer element is not computable at load time
/home/pi/pico/micropython/ports/picopython/own/modtime_monotonic.c:210:20: note: (near initialization for 'monotonic_time_type.slot_index_binary_op')
cc1: all warnings being treated as errors
make[2]: *** [CMakeFiles/picopython.dir/build.make:3204: CMakeFiles/picopython.dir/own/modtime_monotonic.c.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:1628: CMakeFiles/picopython.dir/all] Error 2
make: *** [Makefile:84: all] Error 2
And similar for the rest - But might be something in my CMakeLists.txt, GCC version, etc.

User avatar
jimmo
Posts: 2754
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: User defined data types broken 1.19.1-443

Post by jimmo » Sat Oct 01, 2022 12:12 am

hippy wrote:
Fri Sep 30, 2022 5:19 pm
There's a minor typo in the linked page; it uses the new format for 'local_dict' in the 'if it was' example, rather than old format. What it currently gives -
Thanks, I've made the two fixes.
hippy wrote:
Fri Sep 30, 2022 5:19 pm
Also I didn't see any link given with the error when I compiled ...
For me on rp2, if I introduce a compile error, this is what I get (which was the intention of the change... we did it just before introducing this change to object type definitions for exactly your scenario -- we don't expect everyone to be following the PRs in that much detail).

Code: Select all

[  5%] Building C object CMakeFiles/firmware.dir/main.c.obj
/home/jimmo/src/github.com/micropython/micropython4/ports/rp2/main.c:29:1: error: expected identifier or '(' before '/' token
   29 | /
      | ^
make[3]: *** [CMakeFiles/firmware.dir/build.make:3055: CMakeFiles/firmware.dir/main.c.obj] Error 1
make[2]: *** [CMakeFiles/Makefile2:1385: CMakeFiles/firmware.dir/all] Error 2
make[1]: *** [Makefile:91: all] Error 2
See https://github.com/micropython/micropython/wiki/Build-Troubleshooting
make: *** [Makefile:33: all] Error 1

hippy
Posts: 130
Joined: Sat Feb 20, 2021 2:46 pm
Location: UK

Re: User defined data types broken 1.19.1-443

Post by hippy » Sat Oct 01, 2022 12:52 pm

Interesting. This is what I get doing a stock RP2 build with the same error introduced -

Code: Select all

[  6%] Building C object CMakeFiles/firmware.dir/main.c.obj
/home/pi/pico/micropython/ports/rp2/main.c:29:1: error: expected identifier or  (' before '/' token
 /
 ^
make[2]: *** [CMakeFiles/firmware.dir/build.make:2840: CMakeFiles/firmware.dir/main.c.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:1622: CMakeFiles/firmware.dir/all] Error 2
make: *** [Makefile:84: all] Error 2
pi@Pi3B:~/pico/micropython/ports/rp2/build $
I am convinced that (and all the rest) is original as per the 'git clone/ git pull' version, v1.19.1-461. Your error report is slightly different to mine ...

Code: Select all

   29 | /
      | ^
I don't have the line number nor the vertical bars. And the number, numbering and line numbers referenced, in the "make[N]: ***" reports appear to be very different.

I'm guessing it's something different in our build environments. I am building on a Pi 3B (non-plus), 32-bit Raspberry Pi OS Buster, GCC 7.3.1, cmake 3.16.3, make 4.2.1

Removed Pi forum thread link after I had deleted that
Last edited by hippy on Sat Oct 01, 2022 2:48 pm, edited 1 time in total.

User avatar
jimmo
Posts: 2754
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: User defined data types broken 1.19.1-443

Post by jimmo » Sat Oct 01, 2022 1:04 pm

hippy wrote:
Sat Oct 01, 2022 12:52 pm
I am convinced that (and all the rest) is original as per the 'git clone/ git pull' version, v1.19.1-461.
This message is triggered by
https://github.com/micropython/micropyt ... kefile#L33

So if your Makefile is indeed identical then that means that make (from cmake's generated makefile) isn't returning non-zero ??
hippy wrote:
Sat Oct 01, 2022 12:52 pm
I don't have the line number nor the vertical bars.
That's probably your (quite old!! ~2018) version of gcc, there's been lots of improvement to error messages since then.

hippy
Posts: 130
Joined: Sat Feb 20, 2021 2:46 pm
Location: UK

Re: User defined data types broken 1.19.1-443

Post by hippy » Sat Oct 01, 2022 2:46 pm

jimmo wrote:
Sat Oct 01, 2022 1:04 pm
This message is triggered by
https://github.com/micropython/micropyt ... kefile#L33

So if your Makefile is indeed identical then that means that make (from cmake's generated makefile) isn't returning non-zero ??
It seems to have been another case which proves that posting about something will almost instantly have your subconscious set you on the path to revealing the answer one's been seeking.

Your pointing to that file coincided with my discovering the same and and identifying where the issue lies.

It appears it is a difference in building. This produces the link to the web page -

Code: Select all

cd rp2
make
The Raspberry Pi recommended way of building for the RP2 doesn't -

Code: Select all

cd rp2
cd build
cmake ..
make
So that seems to be where the divergence lies.

I will acknowledge the latest 'raspberry-pi-pico-python-sdk.pdf' indicates the first way for building, but I am convinced it used to indicate the second way. The second way is what's recommended for RP2 development, what I and I expect many, perhaps most, RP2 users are using, should IMO be using.

I am not going to complain about wrapping a 'cmake' build system within a 'make' build system because I can see the rationale for doing that.

It seems to me though, given MicroPython has migrated to a 'cmake' build system, that any 'web link' generation on errors must be added to 'CMakeLists.txt' or some '.cmake' or similar file, so it's provided for those using the 'cmake' build system plus those using the 'make' build wrapper around it. The 'Makefile' wrapper should be just that, a wrapper, nothing more.

jimmo wrote:
Sat Oct 01, 2022 1:04 pm
That's probably your (quite old!! ~2018) version of gcc, there's been lots of improvement to error messages since then.
Probably - That's the version which 'sudo apt install' gets and avoids a lot of 'you're not using a supported compiler' when issues arise on the Pi forums.

Post Reply