dry-rb/chat

WE MOVED TO ZULIP => https://dry-rb.zulipchat.com <=

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

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

Jules Ivanic

@guizmaii

result: https://twitter.com/guizmaii/status/1070020900752384001

Thanks for your help @flash-gordon ! 🙂

Nikita Shilnikov

@flash-gordon

sure, np

Where communities thrive

People

Repo info

Activity