Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 13 15:58
    rokhimin starred dry-rb/dry-matcher
  • Dec 13 08:53
    flash-gordon labeled #376
  • Dec 13 08:44
    solnic commented #376
  • Dec 12 21:34
    flash-gordon commented #376
  • Dec 12 21:34
    flash-gordon labeled #376
  • Dec 12 21:34
    flash-gordon opened #376
  • Dec 12 19:32
    RyanLafferty starred dry-rb/dry-types
  • Dec 12 05:53
    technofreak starred dry-rb/dry-monads
  • Dec 12 00:14
    thekuwayama starred dry-rb/dry-monads
  • Dec 11 09:29
    blasterun starred dry-rb/dry-monads
  • Dec 11 08:34
    flash-gordon closed #115
  • Dec 11 08:34
    flash-gordon commented #115
  • Dec 11 08:31

    flash-gordon on v1.3.3

    (compare)

  • Dec 11 08:30

    flash-gordon on master

    Bump version to 1.3.3 (compare)

  • Dec 11 08:30

    flash-gordon on master

    Update CHANGELOG (compare)

  • Dec 10 23:46
    johnmaxwell commented #116
  • Dec 10 21:54

    flash-gordon on master

    Halt with mutable backtrace Ex… Merge pull request #116 from jo… (compare)

  • Dec 10 21:54
    flash-gordon closed #116
  • Dec 10 21:54
    flash-gordon commented #116
  • Dec 10 21:49
    johnmaxwell commented #116
Piotr Solnica
@solnic
and there are opportunities for more optimization there
John Backus
@backus
Cool
I also imagine that, for dry-v and dry-t, the more that can be expressed using dry logic the better (barring big perf hits)
Piotr Solnica
@solnic
yeah I mean that was my intention when I extracted dry-logic (it was part of dry-validation originally)
John Backus
@backus
Right
Piotr Solnica
@solnic

ok folks I’m done with logic/validation stuff…I’d appreciate if you could add this:

gem 'dry-validation', github: 'dry-rb/dry-validation', branch: 'master'
gem 'dry-types', github: 'dry-rb/dry-types', branch: 'master'
gem 'dry-struct', github: 'dry-rb/dry-struct', branch: 'master'
gem ‘dry-logic’, github: 'dry-rb/dry-logic', branch: 'master'

to your Gemfile and run your tests…

Nikita Shilnikov
@flash-gordon
@solnic dry-rb/dry-validation#238 <- I'll update this today
Piotr Solnica
@solnic
@flash-gordon cool, you could collaborate with @cored as he’s working on optional dry-struct support which has the identical problem as it needs feature detection too
@fran-worley hey! could you tell me if latest stuff from master works fine with Reform and friends?
Rafael George
@cored
@flash-gordon hey
@solnic according to that issue the dependency then should be remove from the Gemfile? I mean by optional you mean that the user will install the dependency by itself ?
s/itself/himself
Nikita Shilnikov
@flash-gordon
@cored hey, that's what @solnic told me: https://github.com/dry-rb/dry-validation/pull/238#issuecomment-244924977 :) I'm just gonna do a monkey-patch with opt-in to_either method
so this case is trivial ^
Rafael George
@cored
so you will try to require at the same method level ?
Nikita Shilnikov
@flash-gordon
@cored require 'dry/monads/either'; require dry-v/either-ext at the end of result.rb I think, with LoadError being caught
Rafael George
@cored
I see
Nikita Shilnikov
@flash-gordon
@cored dry-struct part can be done with a runtime check like defined? ::Dry::Struct && input < ::Dry::Struct
Rafael George
@cored
I see
so since some specs have a definition for an struct, I guess the check also will be there
Piotr Solnica
@solnic
meh, seems like OR-handling still needs some work
Fran Worley
@fran-worley
@solnic I'll check today and get back to you. We will hold off our next release until dry-validation 0.10.0 is out as I want to use some of the goodies you've added :)
Piotr Solnica
@solnic
@fran-worley this has to wait until next week, I thought I’d make it before end of this week but I failed
Fran Worley
@fran-worley
Oh no worries, @apotonick is busy at the moment so we won't be releasing any earlier. When we do release it will be a big dry-v plug as the update is essentially improving Reforms integration with dry
Piotr Solnica
@solnic
that’s great, I’ll try to help
Fran Worley
@fran-worley
Definitely more trailblazer people are switching over especially as @apotonick has set it up so you can gradually transition an app from AM-V to dry.
Russell Edens
@rx
@solnic, @backus backing up to your conversation earlier today ... In working on dry-rb/dry-validation#67 I wanted to provide a consistent api for discovering fields in a dry-v and a dry-s. Having both libraries use a more consistent schema interface would make this much cleaner. As it is right now I have to make dry-l look more like dry-v at the rule-ast level.
I'll be pushing some code to look at later today/tonight.
^^ unfortunate typo - should be: As it is right now I have to make dry-s look more like dry-v at the rule-ast level.
Piotr Solnica
@solnic
@rx did you use dry-logic from master? it changed quite a bit
Russell Edens
@rx
@solnic I have been following the changes. I'm re-working the work I did against master now.
Piotr Solnica
@solnic
@rx I’m not entirely sure if it’s the best direction but we’ll see. rules are not for defining data structures, they are generic. We can easily add generating some meta-data in dry-v schemas though, or try to use generated dry-t’s schemas (that do define the structures). I think I mentioned that in the related issue :)
Russell Edens
@rx
@solnic yes I started down that route but it started feeling like I was pushing the metadata requirements into both dry-v and dry-s, when the rules_ast already had everything that is needed (and more). This lead me to treating the metadata api more like an extension, like you mentioned earlier in the issue :smile: I translated dry-s rules-ast to dry-v rules-ast temporarily to allow me to start using the extension with dry-s. The next step is resolving the non-symmetrical dry-s and dry-v schemas, that would allow me to throw away my temporary dry-s(ast)->dry-v(ast) translation. This approach allowed me to build a more complete set of metadata for both dry-v and dry-s with minimal dependencies and saving anyone else from groking the underlying rules_ast. :smile: If the underlying rules_ast is likely to change more than the dry-s and dry-v object model then I did indeed take a wrong turn.
Russell Edens
@rx
@solnic I just happened to embark on this approach, then I saw you refactored the dry-l ast. :worried:
Piotr Solnica
@solnic
sorry about that, it’s been planned for months, I actually didn’t know you started working on this
fwiw the ast approach is going to be the most powerful, so assuming it’s easy to translate it to what we need, this will be the best approach :)
Russell Edens
@rx
No problem. it should be very easy to re-map. I'll provide a heads up next time. I was just trying to stay out of the way. It looked like you got some really good stuff done.
Right now I'm putting this into its own repo as a WIP for you to look at.
Piotr Solnica
@solnic
yes these are major improvements bringing us much closer to 1.0.0’s
Russell Edens
@rx
:clap:
Piotr Solnica
@solnic
I still need to improve OR-message handling though (it’s a tricky beast…)
Russell Edens
@rx
yes it would be by definition!
btw - I had trouble finding a dry-v rules_ast set and not examples. Do you have one? And do you want me to open an issue or PR against the website documentation?
Piotr Solnica
@solnic
@rx are you asking about examples of DSL usage in dry-v?
Russell Edens
@rx
@solnic yes.
I built my specs using the documentation on the website.
Piotr Solnica
@solnic
I barely covered 50% of the functionality in the docs :)
(not sure why I’m smiling lol)
required(:admin) { true? | true?.not } == required(:admin) { true? | false? }
we could probably add support for not(true?) though