Isnt a set containment problem a really simple problem to solve with a database, eg an inner join and a count?
For something that is in memory and throw-away, why go through a DB?
Helix: Rust and Ruby, Without the Glue
11–20 of 69 posts
Re: Helix: Rust and Ruby, Without the Glue
#12[deleted]
Re: Helix: Rust and Ruby, Without the Glue
#13But the Rust version of the blank check doesn't handle any encoding but UTF-8. Helix could wrap up a char iterator for it I suppose, one that calls rb_enc_codepoint_len? And isn't there some common C lib that exposes Unicode functions like is_whitespace? Granted, using a cargo crate is easier than finding and adding a .h, and far easier than getting and linking another lib.
The Rust version works on strings not on bytes. Strings don't have encodings.
huh? strings have encodings. rust strings are bytes encoded in utf-8.
Re: Helix: Rust and Ruby, Without the Glue
#14But the Rust version of the blank check doesn't handle any encoding but UTF-8. Helix could wrap up a char iterator for it I suppose, one that calls rb_enc_codepoint_len? And isn't there some common C lib that exposes Unicode functions like is_whitespace? Granted, using a cargo crate is easier than finding and adding a .h, and far easier than getting and linking another lib.
The Rust version works on strings not on bytes. Strings don't have encodings.
What do you mean? All Rust strings are UTF-8 encoded, and all Ruby strings have an associated encoding.
Re: Helix: Rust and Ruby, Without the Glue
#15I would be interested to see how Ruby's Set class performs in the Zesty example. If that is actually a bottleneck in the application, I would rather reach for something that is in the Standard Library instead of going fully native.
Ruby’s set class is implemented in Ruby wrapping a Hash (`{ key => true }`), not in C (or Java or…). It’s fairly good when you’re testing for containment, but the implementation is probably going to be as bad or worse for the #fully_contains behaviour…except the requirement that Zesty’s arrays be sorted. Conceptually, a Set will do much better even with this sort of optimization.
Interesting side-note: Rust's `HashSet` is actually implemented by wrapping a `HashMap`. But because `()` is zero-sized (unlike a boolean), Rust can optimise a ton of stuff out.
Re: Helix: Rust and Ruby, Without the Glue
#16But the Rust version of the blank check doesn't handle any encoding but UTF-8. Helix could wrap up a char iterator for it I suppose, one that calls rb_enc_codepoint_len? And isn't there some common C lib that exposes Unicode functions like is_whitespace? Granted, using a cargo crate is easier than finding and adding a .h, and far easier than getting and linking another lib.
The Rust version works on strings not on bytes. Strings don't have encodings.
Right, so how do you get from Ruby strings (various encodings) to a Rust string? The sample code just calls std::str::from_utf8_unchecked(s) which is obviously not dealing with Ruby encodings.
Re: Helix: Rust and Ruby, Without the Glue
#17But the Rust version of the blank check doesn't handle any encoding but UTF-8. Helix could wrap up a char iterator for it I suppose, one that calls rb_enc_codepoint_len? And isn't there some common C lib that exposes Unicode functions like is_whitespace? Granted, using a cargo crate is easier than finding and adding a .h, and far easier than getting and linking another lib.
The Rust version does a type coercion from Ruby VALUE to Rust String. The type coercions are defined generically using Rust traits (see the Helix README) so once somebody defines RubyString -> String once everyone benefits.
In this case, the coercion needs to ask Ruby for the encoding tag and ask Ruby to validate the encoding (which is does often enough that it's often cached) but after that we can safely coerce directly into a UTF8 string.
If we wanted to support other encodings, we could fall back to using Ruby's transcoding support (string.encode("UTF8")) and again, once someone does the work once it'll work for all helix users.
Re: Helix: Rust and Ruby, Without the Glue
#18Earlier quoted context omitted.
The Rust version works on strings not on bytes. Strings don't have encodings.
huh? strings have encodings. rust strings are bytes encoded in utf-8. https://doc.rust-lang.org/book/strings.html
In Rust a string is a sequence of unicode scalar values. I personally find it unfortunate that they dictate the storage of it at the API level, but that is a necessary evil for presenting a consistent ABI with foreign code.
I did not know that strings in Ruby have encodings. Is there a reason for that? I personally don't like mixing characters and opaque byte sequences as they are very different.
Re: Helix: Rust and Ruby, Without the Glue
#19Hmm. Kind of makes you wonder why you're using Ruby at all, which is slow as hell. It appears that once they port all Rails libraries to Rust, it may not take that much effort to create Rust on Rails and get rid of Ruby.
Re: Helix: Rust and Ruby, Without the Glue
#20Earlier quoted context omitted.
The Rust version works on strings not on bytes. Strings don't have encodings.
Right, so how do you get from Ruby strings (various encodings) to a Rust string? The sample code just calls std::str::from_utf8_unchecked(s) which is obviously not dealing with Ruby encodings.
Yeah, that's a clear bug. I was not aware that Ruby strings had encodings.