Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 21 13:13

    solnic on v0.14.0

    (compare)

  • Jan 21 13:10

    dry-bot on master

    [devtools] sync configs (compare)

  • Jan 21 13:09

    solnic on master

    Bump dry-system to 0.14.0 (compare)

  • Jan 21 13:08

    solnic on master

    Update changelog.yml (compare)

  • Jan 21 10:31

    solnic on docsite-0.15

    (compare)

  • Jan 21 10:31

    solnic on docsite-1.0

    (compare)

  • Jan 21 10:17
    Travis dry-rb/dry-view (master) errored (706)
  • Jan 21 10:14
    jchapron starred dry-rb/dry-types
  • Jan 21 10:13

    dry-bot on master

    [devtools] sync configs (compare)

  • Jan 21 10:13

    dry-bot on master

    [devtools] sync configs (compare)

  • Jan 21 10:13

    dry-bot on master

    [devtools] sync configs (compare)

  • Jan 21 10:13

    dry-bot on master

    [devtools] sync configs (compare)

  • Jan 21 10:13

    dry-bot on master

    [devtools] sync configs (compare)

  • Jan 21 10:13

    dry-bot on master

    [devtools] sync configs (compare)

  • Jan 21 10:13

    dry-bot on master

    [devtools] sync configs (compare)

  • Jan 21 10:13

    dry-bot on master

    [devtools] sync configs (compare)

  • Jan 21 10:13

    dry-bot on master

    [devtools] sync configs (compare)

  • Jan 20 21:48
    Travis dry-rb/dry-view (master) errored (705)
  • Jan 20 21:44

    dry-bot on master

    [devtools] sync configs (compare)

  • Jan 20 21:44

    dry-bot on master

    [devtools] sync configs (compare)

Michał Pietrus
@blelump
@solnic , it seems before I'll get into container reloading, there's an issue with constants reloading that are loaded into container as well. During dev mode, once I make any change in any file, it ends up with superclass mismatch for class ... and so far the only solution I have is to remove_const, but that's a pain
Andy Holland
@AMHOL
Guess that's for inheriting from things like ROM::Relation[:users] etc?
Was thinking recently since we don't mutate, might be a good idea to cache those
Although I guess removing the constant makes sense when reloading
Piotr Solnica
@solnic
it’s because it removed the constant but the container had a reference to the prev one BECAUSE CODE RELOADING IN RUBY IS NOT WORKING
Andy Holland
@AMHOL
Still a problem with nested classes tho
Ahh OK
Piotr Solnica
@solnic
irb(main):001:0> Foo = "HAHA"
=> "HAHA"
irb(main):002:0> Bar = Foo
=> "HAHA"
irb(main):003:0> Object.send(:remove_const, :Foo)
=> "HAHA"
irb(main):004:0> Foo
NameError: uninitialized constant Foo
    from (irb):4
    from /Users/solnic/.rubies/ruby-2.3.1/bin/irb:11:in `<main>'
irb(main):005:0> Bar
=> “HAHA"
that’s probably one of the many cases where things can go wrong
Michał Pietrus
@blelump
@solnic , uhm, thanks for explanation
Piotr Solnica
@solnic
we’ve been talking about a stable way of reloading via container
I think it should be doable with no surprises
since the only thing we need to be concerned with is stuff inside the container, rather than THE WHOLE runtime env
Piotr Solnica
@solnic
@blelump re your question from earlier today, I used similar approach last year in a biggerish rails app, started with dry-container, then auto_inject was born from it, then I built rodakase, then dry-component was born from it, then we built a couple of dry-web (post-rodakase) apps with Tim at IceLab, they are a couple times bigger than Berg, all use multi-system setups. 95% of the features we have in dry-system/container/auto_inject are a result of discovering specific needs when working on these apps. Overall we’ve been super happy with how it works; however, we are hitting some challenges, ie in dev mode shotgun is too slow and makes clicking through the website too slow, we’ll be addressing this shortly (that’s related to code reloading, although I don’t know what strategy we will use eventually)
Daniel Vandersluis
@dvandersluis

I'm probably missing something obvious, but i'm getting behaviour that seems wrong to me. Consider the following

configure do
  def valid_email?(value)
    true
  end
end

required(:email).filled(:valid_email?)

When I pass in a blank string for email, I always get BOTH error messages (:email=>["must be filled", "Email is invalid"]). If blank I just want the "must be filled" error.

required(:email) { filled? & valid_email? } gives me the same
Also as you can see, the valid_email? predicate always returns true and yet still adds an error
Piotr Solnica
@solnic
@dvandersluis that’s a hint, not an error, we’re gonna make that configurable (opt-in/out) and you can override it’s message via en.errors.valid_email?.(hint|failure)
so ie you can put under hint sth like make sure it’s a valid email
and for failure “this does not look like a valid email”
Daniel Vandersluis
@dvandersluis
ah okay that makes sense
so as of 0.9.5 there's nothing I can configure right?
Piotr Solnica
@solnic
@dvandersluis you can do schema.(input).message_set.dump to skip hints
it’s gonna return a hash with failures exclusively
default behavior of #messages is to include them
btw more insights about hints/failures here dry-rb/dry-validation#225
Daniel Vandersluis
@dvandersluis
ok I'll check that out.
I'm using dry-v via reform so I'm not sure how I would go about calling the message set, but I'll see what I can figure out
Piotr Solnica
@solnic
@fran-worley ^^^ ??? (again :D)
Daniel Vandersluis
@dvandersluis
:)
Fran Worley
@fran-worley
@blelump good thanks. Just doing the docs for Formular which should help you and is pretty much the last thing before release!
@solnic I was just wondering how your going to merge them. Though the more I think about it the more it makes sense. Funny how long it takes to see something clearly!
Michał Pietrus
@blelump
@fran-worley :fireworks: :sparkles:
Piotr Solnica
@solnic
@fran-worley the class hierarchy is a bit borked, ie Predicate is not the most low-level primitive “rule” type, as it has an identifier, which is a very specific concept in dry-logic - a named rule, so ie Rule::Key is a named rule and…Predicate is a named rule too
so basically we can’t treat predicate objects as some low-level rules
furthermore, the issue with 2 types of return values is troublesome, this must behave in a consistent manner since a rule have a predicate, and that predicate can be another rule OR a predicate itself, this made things more complex than it should be
so essentially we need a single rule concept, with various specialisations, and predicates should be just…methods returning true/false (so ie anonymous blocks or methods from modules/classes/objects that we detach via Method objects)
this should simplify the whole thing, as we’re gonna deal with just one concept - rule
and I’d like to try to keep the idea of “an applied rule” where all args are filled, we’ll see how it goes
the requirement is that rule instantiation must not be too expensive
Piotr Solnica
@solnic
@flash-gordon I was typing a response to that new dry-types issue and SUDDENLY your reply appeared, I freaked out, I freaked out badly :laughing:
Nikita Shilnikov
@flash-gordon
@solnic ah, just the only question I know the answer to :laughing:
Fran Worley
@fran-worley
@solnic makes sense it always seemed kinda irritating that really simple rules with essentially just one predicate had to get wrapped in a rule object. Do you mind if I capture your thoughts above and add them as a comment on the dry-logic PR ?
Michał Pietrus
@blelump
@solnic , thanks for detailed explanation ! Re the container issue, it seems _container comes from dry::container, however when finalize! is performed, it also freezes the system::container itself. I am out of ideas for today , see you tomorrow :-)
Piotr Solnica
@solnic
@blelump oh we just would not finalize! in dev mode, that’s all
Michał Pietrus
@blelump

hi @solnic, I am definietly not a reload–constant guru, but here's what I've found.

Having container without finalization indeed helps and this seems to be the best fit for the dev mode unless you want to explicitly desire some dependency, which hasn't been registered. Only dependencies that are auto–injected are getting registered by default. So if I expect a constant that is on container load path, but didn't get registrered into container, I may call AppContainer.auto_registrar.finalize!. This performs auto registration of all components I've specified in config.auto_register. So far so good, I have everything. Now I change something and it enters:

ActionDispatch::Reloader.to_prepare do
  Object.__send__(:remove_const, :Import)
  AppContainer.instance_variable_set('@_container', ::Concurrent::Hash.new)
  Import = AppContainer.injector
  AppContainer.auto_registrar.finalize!
end

It's not good approach since there're still references to the "old" constants and app crashes after refreshing it.

Besides the above issue, auto_registrar internally calls require_component of the container. The interesting part is Kernel.require which returns false for any n–th load (n > 1) so block doesn't get executed and the container is actually empty, however I am not sure that's the appropriate usage (calling auto_registrar.finalize!).

Igor
@svilenkov
When using dry-initializer how can you add some code to the initialize() method without affecting gems behavior?
Piotr Solnica
@solnic
@blelump I think you should talk to @timriley as I’m almost sure he’d be interested in seeing how hot-reloading of a container could be implemented properly. I won’t have time for this during this week. Way too much mojowork + dry-logic/validation. Sorry ¯_(⊙ʖ⊙)
for rails we probably need to integrate with their AS::Dependencies so it knows about constants loaded by the system
Andrew Kozin
@nepalez
@keeperhood you can just reload the initializer
class MyClass
  extend Dry::Initializer::Mixin

  param :foo

  private

  def initialize(foo, bar)
    @bar = bar
    super(foo)
  end
end