[AlexanderWells-diamond]

Allow creation records like:

t1 = builder.WaveformOut(
    "TEST1",  initial_value=["ZERO", "ONE", "MANY"]
)
t2 = builder.WaveformOut(
    "TEST2",  initial_value=[b"ZERO", b"ONE", b"MANY"]
)

Where each element of the array is treated as an EPICS string

Values returned will always be Python string lists:

> t1.get()
["ZERO", "ONE", "MANY"]
> t2.get()
["ZERO", "ONE", "MANY"]

(valid) Unicode characters may also be passed in, and will be returned as-is. Note that it is not always obvious how many Unicode characters can be safely entered into EPICS's 40 character string limits.

[codecov]

Codecov Report

Merging #102 (65f8bd8) into master (565bca1) will increase coverage by 0.19%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #102      +/-   ##
==========================================
+ Coverage   87.15%   87.34%   +0.19%     
==========================================
  Files          14       14              
  Lines         981      996      +15     
==========================================
+ Hits          855      870      +15     
  Misses        126      126              

Impacted Files	Coverage Δ
softioc/builder.py	97.64% <100.00%> (+0.02%)	⬆️
softioc/device.py	95.81% <100.00%> (+0.21%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[github-actions]

Unit Test Results

     15 files  ±    0       15 suites  ±0   27m 47s ⏱️ -21s
   271 tests +  22     255 ✔️ +  12    16 💤 +  10  0 ❌ ±0 
4 065 runs  +330  3 475 ✔️ +180  590 💤 +150  0 ❌ ±0 

Results for commit 65f8bd8. ± Comparison against base commit 565bca1.

♻️ This comment has been updated with latest results.

[AlexanderWells-diamond]

The current state of the branch is that you can create a WaveformIn/Out with an initial_value of an array of (byte) strings, but you cannot set that value at a later time. This is because if there is no dtype, numpy defaults to float64, and trying to coerce an array of byte strings to float64 is simply nonsense.

If you specify an FTVL or dtype of the relevant type during record creation, the record does behave as expected.

I'm unsure if we can support arrays of strings quite as freely as we could in version 3.2.1 - I don't see a neat way around the implicit numpy conversion.

[Araneidae]

Think there are a few minor things to tidy up, but looks good.

[Araneidae]

Don't really think this note captures the essence of this new feature. In particular, the internal encoding is almost completely hidden from users, and it's a bit of a misconception to say that "EPICS has no Unicode support".

We should reference the fact that waveforms of strings are treated as Python Unicode strings throughout and are managed as Python arrays unlike all other waveforms.

[AlexanderWells-diamond]

Rewritten in 5b59ed7 - how does that sound?

[Araneidae]

ok