Is anyone having issues with freezing python source files?

[kdschlosser]

I am trying to freeze a python source file and I am getting this error.

mpy-cross: ../py/emitnative.c:2584: emit_native_build_slice: Assertion `vtype_start == VTYPE_PYOBJ' failed.

I have tracked it down to me using the viper code emitter. Issues with this were supposed to have been fixed some 5 years ago but I think there is an issue that came up. This is using the latest release of MicroPython.

I want to make sure it is not something in my setup before opening a bug report for it.

I am compiling for ESP32-S3

[bixb922]

I am freezing Micropython with viper code on a ESP32-S3 with 1.22 and have seen no problem

[jimmo]

@kdschlosser Are you able to narrow it down to a particular line or lines? (i.e. it's got to be something in your @viper function that is creating a slice).

[kdschlosser]

This is the code.

    @micropython.viper
    def _set_memory_location(self, x1: int, y1: int, x2: int, y2: int) -> int:
        # Column addresses
        param_buf = ptr8(self._param_buf)

        param_buf[0] = (x1 >> 8) & 0xFF
        param_buf[1] = x1 & 0xFF
        param_buf[2] = (x2 >> 8) & 0xFF
        param_buf[3] = x2 & 0xFF

        self._data_bus.tx_param(_CASET, self._param_mv[:4])

        # Page addresses
        param_buf[0] = (y1 >> 8) & 0xFF
        param_buf[1] = y1 & 0xFF
        param_buf[2] = (y2 >> 8) & 0xFF
        param_buf[3] = y2 & 0xFF

        self._data_bus.tx_param(_RASET, self._param_mv[:4])

self._param_mv is a memoryview to self._param_buf. I am aware that slicing is not allowed for pointers which is what param_buf is but there is no mention of it not being allowed at all for anything inside of a viper wrapped function.

The docs say that these are the limitations

    Context managers are not supported (the with statement).
    Generators are not supported.
    If raise is used an argument must be supplied.
    Default argument values are not permitted.
    Floating point may be used but is not optimised.

And then it goes on to describe using the ptr* functions.

Viper provides pointer types to assist the optimiser. These comprise

    ptr Pointer to an object.
    ptr8 Points to a byte.
    ptr16 Points to a 16 bit half-word.
    ptr32 Points to a 32 bit machine word.

The concept of a pointer may be unfamiliar to Python programmers. It has similarities to a Python [memoryview](https://docs.micropython.org/en/latest/library/builtins.html#memoryview) object in that it provides direct access to data stored in memory. Items are accessed using subscript notation, but slices are not supported

That's where it states you cannot slice a pointer. self._param_mv while the underlying code is a pointer the high level code make it a python object and not a pointer.

BTW there are a ton of typos for the word optimized. in the docs it is spelled "optimised"
https://docs.micropython.org/en/latest/reference/speed_python.html

[kdschlosser]

and that's all fine and dandy but for some reason I believe the documentation is written in American English and not in British English, so the spelling would be incorrect if that is the case.

[kdschlosser]

OH and if you look at that exact same page you linked to.

In the United States, there is a preference for "optimized" over "optimised" (98 to 2).
In the United Kingdom, there is a 51 to 49 preference for "optimised" over "optimized".
In India, there is a preference for "optimized" over "optimised" (78 to 22).
In the Philippines, there is a preference for "optimized" over "optimised" (96 to 4).
In Canada, there is a preference for "optimized" over "optimised" (95 to 5).
In Australia, there is a 52 to 48 preference for "optimised" over "optimized".
In Liberia, there is not enough data to determine a preference between "optimized" and "optimised".
In Ireland, there is a preference for "optimized" over "optimised" (60 to 40).
In New Zealand, there is a preference for "optimized" over "optimised" (55 to 45).
In Jamaica, there is a preference for "optimized" over "optimised" (100 to 0).
In Trinidad & Tobago, there is a preference for "optimized" over "optimised" (100 to 0).

The UK and Australia are the only 2 places where optimised is preferred over optimized. The vastly larger portion of English speaking folks in this world use optimized.

[davefes]

I think most of it is written in Australian English. I am surprised that there is a preference for "optimized" in New Zealand, as when I moved from Canada (95% optimized) I had to change my ways! In more ways than one.

[kdschlosser]

It can go either way. I didn't realize that the author was from Australia.

English is a twisted language with far too many rules.

[jimmo]

Yes there is a large contingent of MicroPython contributors from Australia and the UK (currently the entire core team is Australian). You'll see a lot of Australian English (essentially UK English) in MicroPython's comments and documentation.

That linked page surprises me -- In Australia, there is a 52 to 48 preference for "optimised" over "optimized" -- this does not match my experience. Similarly https://sapling.ai/usage/color-vs-colour

[kdschlosser]

If I am not able to slice the memory view object then that defeats the entire purpose of using it.

I am not sure why self._param_mv is not considered as a VTYPE_PYOBJ because self._param_mv is a memoryview object which is a python object.

[kdschlosser]

so it appears there is an issue with slicing in general, doesn't matter if it's a string or a memory view object. It's the integers that are being passed as the slice that is the problem. They are not VTYPE_PYOBJ, VTYPE_INT or VTYPE_UINT. I am not exactly what they are being passed as.

[jimmo]

that's because only 1 argument gets passed is start is specified and if stop is specified then 2 arguments would get passed and the second one being the stop would be an int and with step specified that argument would need to be an int.

I think possibly there's a misunderstanding here about the VTYPE_* types.

The bytecode and native emitters only work with VTYPE_PYOBJ. The viper emitter is "cleverer" in that it knows that some things are actually int or uint etc. And that's what's tripping it up here, because this ultimately has to call mp_obj_new_slice which takes three mp_obj_t. (And FWIW, slice arguments do not have to be integers).

But the viper compiler has helpfully decided that these three things are not python objects. Look at elsewhere in emitnative.c that uses MP_F_CONVERT_OBJ_TO_NATIVE.

[jimmo]

someone doesn't pass a float or some other object that isn't an int or None

That's not quite what's going on here. Those protections happen at runtime when the slice is evaluated.

[kdschlosser]

OK so I did the search like you have suggested. One is done for a return value and the other is used in the emit_native_start_pass function which I am assuming is a for loop possibly? So I am not 100% sure of the use of MP_F_CONVERT_OBJ_TO_NATIVE in that case. But there are no uses of MP_F_CONVERT_OBJ_TO_NATIVE on function arguments.

[kdschlosser]

by looking at the emit_native_load_subscr it appears like it is being done correctly in the slice function.

[kdschlosser]

The reason why I need to use slicing is due to the type of code that is being run. This is for LCD display drivers, specifically a framework. So a driver if needed could change the size of that buffer to be larger for use elsewhere in the driver if needed. This is why the slice would specifically need to take place inside the viper code. The user could reset the memoryview object to point to the new larger buffer object and it wouldn't disrupt the operation of the function at all. If I sliced the memoryview ahead of time and set it as an instance variable it is another thing that would have to get reset if the buffer size is changed.