Skip to content

Conversation

@ArcaneNibble
Copy link
Collaborator

I expect that this might be somewhat controversial to have in final shipping firmware, but this was very useful for debugging I was doing.

… the brick

This was being used to test watchdog and exception handler implementation.
@ArcaneNibble
Copy link
Collaborator Author

I do think that having "reboot" and "power off" in shipping firmware would be useful, but it would have to be clearly documented that they indeed do what they say (and thus terminates user programs unexpectedly without saving data).

@coveralls
Copy link

Coverage Status

coverage: 57.178% (-0.06%) from 57.239%
when pulling 1676ba7 on ArcaneNibble:experimental-crash
into 4484552 on pybricks:master.

@BertLindeman
Copy link
Contributor

We do have hub.system.shutdown()

@ArcaneNibble
Copy link
Collaborator Author

Oh so we do. It looks like that performs a clean shutdown? It might be useful to add a clean reboot function.

These test functions here perform unclean shutdowns, which is why I've put them in experimental


return mp_const_none;
}
static MP_DEFINE_CONST_FUN_OBJ_KW(experimental_crash_obj, 0, experimental_crash);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would make more sense to use MP_DEFINE_CONST_FUN_OBJ_0 here.

@dlech
Copy link
Member

dlech commented Jul 17, 2025

We use to have hub.system.reset() but it got removed in a2e3bd7. As it says in the commit message, we can reset via Bluetooth (or soon USB), so that seemed good enough since most users won't every need this.

@ArcaneNibble
Copy link
Collaborator Author

Fair enough. Thoughts on keeping crash in experimental? Or is that a bit too tempting for the wrong reasons?

@dlech
Copy link
Member

dlech commented Jul 18, 2025

Not sure it would be useful in the long term, but we've used experimental before for some things that were helpful while developing a certain feature only to eventually remove them again.

So if it is helpful to keep these around while bringing up EV3, I'm OK with it, but they will probably get removed again when we are done.

@laurensvalk is kind of the gate keeper on MicroPython API stuff, so best to see what he has to say.

@laurensvalk
Copy link
Member

laurensvalk commented Jul 18, 2025

this was very useful for debugging I was doing.

Instead of having them as permanently enabled but hidden features, would it be useful to have a few functions like these in a module that you can enable in config as needed? Something like #if PYBRICKS_PY_EXPERIMENTAL_EV3_HACKS for now.

I'd like to have it disabled in the build by default once we get closer to the release, since we've often found that people come to rely on experimental features and temporary hacks become permanent. Since it is early days, it can be enabled by default for now, just like we have sensor port 1 currently disabled by default for now.

If we have more than a few and across platforms, maybe it could go in a dedicated module _hacks that we enable with a build flag so you don't have to modify the config or accidentally commit it.

@ArcaneNibble
Copy link
Collaborator Author

people come to rely on experimental features

Now that you mention it, I can definitely see crash being way too tempting (for reasons that I can't fully imagine, but it'd definitely not be things you'd want to encourage).

@laurensvalk
Copy link
Member

from universe import destroy

destroy(password="So Long, and Thanks for All the Fish!")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants