doc: Read&Decode Stream code example is broken

[stubb0rnCoder]

Describe the bug
Using current main (2460e89) the example for streaming read&decode here is not compiling.

Macros
The ACCEL_IODEV_PTR and ACCEL_DEFINE_IODEV macros are missing a ... argument or otherwise the compiler will complain about them taking only one but getting two arguments from LISTIFY().

decoder
The statement decoder->get_frame_count(buf, {SENSOR_CHAN_ACCEL_XYZ, 0}, &frame_count); throws an error expected expression before '{' token on the second argument.
Adding a (struct sensor_chan_spec) before the {...} fixes that.

print statements
Some of the printk statements use dev->name where (as I understand it) a sensor->name is needed.

data retrieval
The final print statement extracts/formats the acceleration data for the print statement which throws a pointer vs. member error:

note: in expansion of macro 'PRIsensor_three_axis_data
_arg'
  107 |              PRIsensor_three_axis_data_arg(accel_data, 0));
...
zephyr/include/zephyr/drivers/sensor_data_types.h:72:51: error: '(struct sensor_three_axis_data *)&a
ccel_data' is a pointer; did you mean to use '->'?
   72 |         (data_).header.base_timestamp_ns + (data_).readings[(readings_offset_)].timestamp_delta,   \

To Reproduce
Insert the snippet into a minimal application.

I used the xg24_dk2601b board which needs adjustment of the board overlay to have two IMUs defined but I don't see the reported issues being board related.

Environment (please complete the following information):

• OS: MacOS
• Toolchain Zephyr SDK v0.17.0
• Commit SHA 2460e89

[teburd]

@kartben this is why I wanted to make these samples that get built, can we please add doc snippet samples in some manner that doesn't require the full work of making them samples in some manner? These snippets are meant to be inline in the docs not necessarily stand-alone things in this case

[kartben]

[...] can we please add doc snippet samples in some manner that doesn't require the full work of making them samples in some manner [...]

at the risk of sound like I am "mirroring" what you just said, why not actually do the "full work" (btw if by "full" you're implying/feel there's some kind of overhead to it, please let me know) of turning this into a proper sample, if the point is to have this code actually be runnable / used as a .... sample?

[teburd]

[...] can we please add doc snippet samples in some manner that doesn't require the full work of making them samples in some manner [...]

at the risk of sound like I am "mirroring" what you just said, why not actually do the "full work" (btw if by "full" you're implying/feel there's some kind of overhead to it, please let me know) of turning this into a proper sample, if the point is to have this code actually be runnable / used as a .... sample?

It's not meant to be a generic stand alone sample with independent rst docs. It makes no sense to document a sample that is meant to be a snippet in other documentation to me.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[teburd]

@kartben any thoughts? I don't think these code snippets warrant setting up a complete documented sample, would setting up a small docs/code_snippets type directory where these things can live and be built in CI to ensure they build work for you?