Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Jeff Dickey
@jdickey
Coming soon: IBM RPG :older_man:
not to take away from the awesomeness; anything that lets devs use their favourite/existing-products' languages in new ways is almost by definition a Good Thing
Christian Georgii
@cgeorgii

Hi, I've been thinking about opening a pull request for dry-struct to make it quack a bit more like a hash in order to enable validating it with dry-validation. Nowadays an attempt to call a schema with a struct object throws an error. I don't understand if this is a conscious design decision because it seems like a useful use case.

What I want to enable is this:

schema = Dry::Validation.Schema { required(:age).filled(gteq?: 18) }

User.new(age: 17)

schema.(user)
#<Dry::Validation::Result output=#<User age=17> errors={:age=>["must be greater than or equal to 18"]}>
Nikita Shilnikov
@flash-gordon
you're supposed to create structs from valid data hence it doesn't make sense to pass structs to dry-v
Christian Georgii
@cgeorgii
Ok, thanks for the quick answer

Another question, then

BMI = Dry::Types['strict.int'].constrained(gteq: 18, lteq: 42).constructor { |x| x.round }

BMI[17.5]
#=> 18

BMI.valid?(17.5)
#=> false

Does this behavior make sense or is it a bug?

Nikita Shilnikov
@flash-gordon
not something I would expect tbh
mb there are reasons for that, requires checking out the code
Christian Georgii
@cgeorgii
Ok, I will take a look
Nikita Shilnikov
@flash-gordon
@solnic https://github.com/dry-rb/dry-types/blob/287e732d12a96ab9f54955754f10d4afa5e5abf8/lib/dry/types/constructor.rb#L82 here the constructor types doesn't apply fn to value. Doesn't it seem wrong?
@cgeorgii ^
Piotr Solnica
@solnic
@flash-gordon it does
Nikita Shilnikov
@flash-gordon
@cgeorgii pls file an issue, I'll take care of it tomorrow
Christian Georgii
@cgeorgii
Alright, but let me know if you want me to take a stab at it ;)
Nikita Shilnikov
@flash-gordon
permission granted ;)
Christian Georgii
@cgeorgii
Cool, I will let you know
Christian Georgii
@cgeorgii
@flash-gordon Just opened a PR for this here: dry-rb/dry-types#277 :fireworks:
Let me know if you have any thoughts or questions.
Nikita Shilnikov
@flash-gordon
:+1: will check it out
Jules Ivanic
@guizmaii

Hi everyone,

First, I want to thanks all of the people working on this project ! It’s an awesome project ! :clap:

Second, is there any .sequence method proposed in dry-rb ?

sequence signature is: F[G[A]] -> G[F[A]]
Nikita Shilnikov
@flash-gordon
@guizmaii called w/o a block traverse acts as sequence https://github.com/dry-rb/dry-monads/blob/master/lib/dry/monads/list.rb#L263-L286
Jules Ivanic
@guizmaii
ok thanks :)
Jules Ivanic
@guizmaii
does it work on Ruby Array ?
Nikita Shilnikov
@flash-gordon
nope, we don't monkey patch core classes, it's against our philosophy :)
Jules Ivanic
@guizmaii
+1
awesome philosophy !
Jules Ivanic
@guizmaii
Do you thinks that this make sense: atomic_rows = Concurrent::AtomicReference.new(Dry::Monads::List.[]) ?
I need to update this list but my computation is parrallel
I’m very new to concurrency in Ruby :/

hum maybe this is better:

future_rows = Dry::Monads::List.[]
requests.find_in_baches { |data|
  future_rows += Task[:io] { compute_rows(data) } 
}

future_rows.traverse { |rows|
  …
}

WDYT ?

Nikita Shilnikov
@flash-gordon
future_rows = Concurrent::Array.new
requests.find_in_baches { |data|
  future_rows << Task[:io] { compute_rows(data) } 
}

Dry::Monads::List.coerce(future_rows.to_a).traverse { |rows|
  …
}
@guizmaii I think this one will work better
as in Monads::List isn't meant to be mutable
and, actually, you can use future_rows = []
since it's mutated from the same thread
Jules Ivanic
@guizmaii
Hum you’re right ! Thanks :)
is it coslty to coerce ?
if the array contains a lot of elements (< 100.000)
Nikita Shilnikov
@flash-gordon
not really
O(n) max
you can do List.new, it's O(1)
I bet traversing will be way more expensive tbh, it's not omptimized for long lists
otoh, it can be not that bad
Nikita Shilnikov
@flash-gordon
btw, if you use find_in_batches then future_rows.size will be equal total_rows / batch_size
which is better
I think you should give it a chance and see if something can be improved later
Jules Ivanic
@guizmaii
ok thanks for your precise answers ! :)
Jules Ivanic
@guizmaii
This message was deleted
Thanks for your help @flash-gordon ! 🙂
Nikita Shilnikov
@flash-gordon
sure, np