Way to make SharedArray over fixed length Strings?

question

#1

if you do SharedArray{AbstractString}(10, 1)

you get the following error:

ERROR: ArgumentError: type of SharedArray elements must be bits types, got AbstractString

Is there a package for making fixed length strings to allow their use in SharedArrays?

Thanks!


edit: is there a way to make it work with LegacyStrings.jl?


#2

What about an SVector{N, Char} from StaticArrays.jl?

julia> using StaticArrays

julia> isbits(SVector{10, Char})
true

#3

How do you treat that as a string though?

And is there a way to do build in rpad()'ing?


#4
julia> s = SVector{4,Char}(b"abcd")
4-element SVector{4,Char}:
 'a'
 'b'
 'c'
 'd'

julia> convert(String, s)
"abcd"

As for padding, just fill the remaining characters with spaces?


#5

Might be nice to have a package implementing a fixed-length SString{n,T} <: AbstractString type on top of SVector{n,T} (supporting both T = Char for UTF-32 and T = UInt8 for ASCII). If you don’t need to support strings containing NUL, then you could also use NUL-padding to give a string of length ≤ n with fixed-length storage.


#6

Can you guys take a look at this package I wrote up?

It’s probably more of a proof of concept than an efficient design at this point.

// I basically just started with @stevengj’s LatexStrings.jl and worked my way backward


#7

There is also: https://github.com/JuliaComputing/FixedSizeStrings.jl


#8

Well damn… Can anyone discuss the pros & cons of the two implementations?

I’m cool with letting the package I wrote die, I just want to know it’s for the right reasons.


#9

Well, yours doesn’t really seem to be optimized for performance since you don’t properly propagate the fixed size.
Also, this is a pretty crazy use of parse and eval:

You do realize, that you can just do SVector{length(string), UInt8}(Vector{UInt8}(string)) ? :slight_smile:

In general, I always found it useful to have a fixed size string, that looks more like this:

struct FString{N}
length::Int 
data::NTuple{N, UInt8}
end

So that one can have a Vector{FString{32}} with variable sized strings - which seems to be a shortcoming of FixedSizeStrings.

I made a prototype for such a type for my GPU blog post: fixed_strings.jl

All packages don’t support UTF8, so a package that would offer that would be nice.

In general, I recommend to just extend the existing package with more functionality - especially when both packages are still that small!


#10

I wholeheartedly agree with this. There was just no way to find your code?

It seems like you only came forward because of Cunningham’s Law:

“The best way to get the right answer on the Internet is not to ask a question, it’s to post the wrong answer.”


What do you think the best route is moving forward?

I just don’t really like writing pointless code and wasting time.

// and from ANN: HigherPrecision and Pruning and quality control for the package ecosystem, it seems like this kind of thing is happening all the time to Julians :frowning:


#11

There was just no way to find your code?

Sorry :wink:
I meant extending FixedSizeStrings, which isn’t my package. I should probably contribute my code to that package as well :slight_smile:


#12

you could figure out whats missing for your use case in FixedSizeStrings and make a PR - feel free to ping me for guidance :slight_smile: i should also figure out what i could add…


#13

Is there a definitive solution to having SharedArray’s over fixed length strings?

Ran into a use case for symbols recently too