Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Piotr Solnica
@solnic
That is good I hope it's true. I also wonder if they will ever realize what kind of nonsense const reloading in dev mode is
Hunter Madison
@hmadison
its hilariously bad, the only languages that do it "right" (imo) are erlang and java.
Piotr Solnica
@solnic
@hmadison in my workflow this feature is completely not needed (but that’s just me, although I’m not the only one)
Chris Richards
@cmrichards
Rails 5 only reloads what has changed
Hannes Nevalainen
@kwando
dry-component :heart:
Piotr Solnica
@solnic
@kwando did you use it already?
Hannes Nevalainen
@kwando
no, but I will soon.. turns out I've been building my own version of dry-component for "my stack"
Piotr Solnica
@solnic
that’s awesome bkz that’s why I extracted it
it feels like this is going in a direction of some sort of “DIY framework”-toolkit
Hannes Nevalainen
@kwando
yeah, and I love it
finally I get the control over my code back
I'm looking at you rails
Piotr Solnica
@solnic
yes, that’s exactly the case with this whole thing :)
Andy Holland
@AMHOL
expect(Test::Container[:w00t]).to be(:awesome) :laughing:
Piotr Solnica
@solnic
Who said testing should be sad ;)
Andy Holland
@AMHOL
Indeed
Hunter Madison
@hmadison
Do you need to pass a pathanme to configure's root option for dry-component?
Hunter Madison
@hmadison
the examples seem to indicate that it should take a string, which fails for me since its trying to #join
Piotr Solnica
@solnic
@hmadison should accept both but coerce to pathname. Needs fixing
Tim Riley
@timriley
Trying to fix a bug in dry-component and the spec is intermittently failing. Something to do with the removal of constants from the Test namespace.
Actually, not exactly that, since when I disable the constant removal lines in spec_helper, it still intermittently fails...
Something to do with the run order.
Tim Riley
@timriley
Weird – it looks like @_container is being persisted between spec examples...
I remember you mentioned this before, @solnic… /me searches
Hmmm. So _container’s got a different object_id for each example. Must be something else.
Ahhh, it’s because Kernel.require for my dependency (in auto_register! is returning false for my dependency in the new spec example I’ve added.
Tim Riley
@timriley
which would suggest to me that it’s not reloading the class whose constant we’ve removed at the end of the previous example
I think the issue here is that I’ve used auto_register in my new container that I’m testing (it’s a test for auto-injecting objects from imported containers)
Tim Riley
@timriley
Here’s the problem, AFAICT:
% echo "class Foo;end" > foo.rb

% irb                          
irb(main):001:0> require "./foo"
=> true
irb(main):002:0> Foo.new
=> #<Foo:0x007f885a02ea60>
irb(main):003:0> Object.send(:remove_const, :Foo)
=> Foo
irb(main):004:0> Foo.new
NameError: uninitialized constant Foo
    from (irb):4
    from /Users/tim/.rbenv/versions/2.3.0/bin/irb:11:in `<main>'
irb(main):005:0> require "./foo"
=> false
irb(main):006:0> Foo.new
NameError: uninitialized constant Foo
    from (irb):6
    from /Users/tim/.rbenv/versions/2.3.0/bin/irb:11:in `<main>'
irb(main):007:0>
If we’ve already required a file in a ruby process, then removing the constant and re-requiring the file doesn’t redefine the constant.
I think this hasn’t come up in container_spec so far because no constant has needed to be reused like this
Tim Riley
@timriley
I’ve introduced an example that uses another fixture class with an include Import['…'] inside of it, and my change is one that sees imported containers get imported when doing that include, which means that my new fixture importable container gets imported by the existing spec with include Import[…], which causes the imported container’s constants to be removed, and then fail to be preoprly re-required/loaded for my new spec example
Ahhhh! $LOADED_FEATURES!
YESSSSSS
Tim Riley
@timriley
Thanks for helping me out, rubber duckies.
Piotr Solnica
@solnic
Yes I was aware of that issue in specs but didn't come up with a solution yet :)
Tim Riley
@timriley
np :) Tweaking LOADED_FEATURES in the same way as you did LOAD_PATHS is probably good enough for specs as they are right now, but could be refined a little later on if needed.
Piotr Solnica
@solnic
@timriley freaking global state right
Luca Guidi
@jodosha
@timriley IIRC if you do load './foo', it forces the reload, without touching $LOADED_FEATURES.
Tim Riley
@timriley
@jodosha yeah, thanks :) In my case though the production code is (rightly) using require, so I had to make that work.
Hannes Nevalainen
@kwando
anyone seeing weird behavior with call_sheet 0.4.0? Seems broken to me =S
Tim Riley
@timriley
As far as I can tell, there’s no way to use dry-data type constraints with a “filled?” validation applied?
Piotr Solnica
@solnic
@timriley wdym?
Tim Riley
@timriley
I’m currently debugging more deeply
but my initial issue was this:
It wants the constraints to be supplied as a hash, but there’s no “value” or argument for filled?
and it also crashes, whatever I put in there as a placeholder