Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Nov 17 21:02
    flash-gordon commented #374
  • Nov 17 21:01

    flash-gordon on master

    Update custom_ci.yml Merge pull request #374 from sk… (compare)

  • Nov 17 21:01
    flash-gordon closed #374
  • Nov 17 20:59
    skryukov opened #374
  • Nov 17 16:42

    flash-gordon on use-immutable-equalizer

    (compare)

  • Nov 17 16:42

    flash-gordon on master

    Use immutable equalizer for all… Merge pull request #373 from dr… (compare)

  • Nov 17 16:42
    flash-gordon closed #373
  • Nov 17 16:38
    flash-gordon opened #373
  • Nov 17 16:38

    flash-gordon on use-immutable-equalizer

    Use immutable equalizer for all… (compare)

  • Nov 17 16:34

    flash-gordon on no-rewrap-for-structs

    (compare)

  • Nov 17 16:34

    flash-gordon on master

    Don't build constructors when c… Merge pull request #371 from dr… (compare)

  • Nov 17 16:34
    flash-gordon closed #371
  • Nov 16 11:28
    marekciupak starred dry-rb/dry-monads
  • Nov 16 07:48
    luizfonseca starred dry-rb/dry-view
  • Nov 15 18:52
    waiting-for-dev commented #114
  • Nov 15 16:06
    businessBoris starred dry-rb/dry-system
  • Nov 15 15:16
    businessBoris starred dry-rb/dry-monads
  • Nov 15 08:22
    gruz0 starred dry-rb/dry-types
  • Nov 14 12:03
    pedrofurtado starred dry-rb/dry-matcher
  • Nov 14 08:21

    flash-gordon on master

    Fixing codeblock in maybe.html.… Remove duplicated dot from exam… Merge pull request #372 from Zi… (compare)

Nikita Shilnikov
@flash-gordon
you also may want to use Optional, not Maybe, depending on your requirements
that is Types::Optional::Coercible::Int
this way values won't be wrapped with a monad
Robin Bühler
@openscript
@flash-gordon Thank you for your response. Optional suits my requirements very well. :-)
New page on the website is up.
Piotr Solnica
@solnic
:tada:
Piotr Solnica
@solnic
@blelump sorry mate, been busy with other stuff, I’ll deal with that namespace nonsense now ;)
Piotr Solnica
@solnic

I think the problem occurs because in my setup run_tasks_blocks fires before instance

@blelump so, why does it happen?

I think this should be reported as a bug in rails
since run_tasks_blocks has a nasty side-effect they should make sure all railtie instances are created first
Michał Pietrus
@blelump
@solnic , Hi, re this rake issue, well it's diffcult to say what exactly causes the underlying problem, because now it works for me, even without changing anything :smile:
Piotr Solnica
@solnic
@blelump I pushed 0.0.2 with your fix nevertheless
Michał Pietrus
@blelump
sure, thanks !
Piotr Solnica
@solnic
want a commit bit there in case of other emergencies? :)
I’m NOT using this yet so it’s gonna be low on my list until I start using it
I mostly built it as an excercise to see if it can work with Rails Just Like That™
(and it did)
Michał Pietrus
@blelump
yep , I am sure you're not :smile: and I am not sure whether I need it either
I've experimented with dry-component earlier before it became dry-system and it worked fine within Rails ecosystem
and now just switched to dry-system
Piotr Solnica
@solnic
you don’t need it, nobody needs it, but you may want to benefit from it that’s all :)
if you like DI, if you don’t like spring, if slow boot time bothers you, if you like well organized code etc…then you will benefit from it :)
Michał Pietrus
@blelump
@solnic , I'm not sure I follow you, but I meant the dry-system-rails lib. If you inject IoC into an existing app, you may want to not load everything by default and hence the dry-s-rails is not needed. That's what I'm doing now – in particular to check whether there're benefits of this approach . Speaking about benefits :smile: , have you applied the component approach in a bigger app? I'd like to ask about the concept of splitting app into smaller components or what could be a component. I know icelab::berg implements two components and there're probably various ways of doing it , but just wanted to ask about your point of view :-)
RKushnir
@RKushnir
in dry-v, if I just declare an attribute as required(required(:name)), it seems to have no effect until I chain some rules on it(required(:name).filled), is it right?
Piotr Solnica
@solnic
@RKushnir right, that’s sth to improve
RKushnir
@RKushnir
@solnic thanks, not that I need it now, just verifying my understanding
Piotr Solnica
@solnic
@RKushnir if you enable explicit type-specs then it’ll coerce based on required(:foo, :str)
so ie { “foo” => “haha” } would be processed into { foo: “haha” }
RKushnir
@RKushnir
I see. But there’s no way to specify “key is required with any value”
Piotr Solnica
@solnic
@fran-worley hey…so I made most specs pass with way less objects allocations, for invalid-input cases prev perf was restored, this is good news, but there are bad news too - this approach makes it impossible to skip results for successful rules, since we curry prior applying, so it’s a chicken-egg situation - we need result in order to know if we want to generate more result data, but now we already generate more result data before getting the result. haha such situation
@RKushnir nope, why would you need that?
@fran-worley when working on this I had this feeling that this could be much better structured, so I’ll continue experimenting, I feel like something is clearly missing at the moment
RKushnir
@RKushnir
@solnic I was thinking about a case where I want a caller to always explicitly provide a value, even if it’s an empty string, for example. But as I said, that’s just speculations, never mind
Piotr Solnica
@solnic
@RKushnir I’m trying to understand if there are legitimate cases where “any type” makes sense
@fran-worley anyhow, my plan is to pretty much rewrite dry-logic lol, I’m pretty sure current class structure is a blocker for what we want to achieve. Good news is, as long as it produces expected ast dry-v will continue to work
Fran Worley
@fran-worley
@solnic Makes sense. Do we have any independent users of dry-logic yet? I've not yet finished our implementation with it so go nuts :) If you want help and explain where you need it I'm happy to assist. At the same time I don't want to hold you back if you know where you want to go with it!
Piotr Solnica
@solnic
@fran-worley I don’t think that anybody is using it directly, and even if it’s the case, it is beta, so things can change :P
anyhow, I’ve got a rough idea how to make it work, ie rule/predicate should behave exactly the same wrt #call and #curry there should be no diff and it should be done in a single place
furthermore, we need two different execution strategies, one that generates full result data by currying all args + calling, and the other that simply calls and returns true or false for each rule
Fran Worley
@fran-worley
Oh I know we can change things, I just figured if we know that someone is actively using it we should probably warn them that it's going to change alot.
Just incase you are wondering why I don't actually curry the predicate function, rather I keep track of the args that was because if you curry a function it is no longer able to determine arity and parameter names which are key to getting arg names into the ast
Piotr Solnica
@solnic
@fran-worley thanks, you left a comment explaining it :)
Fran Worley
@fran-worley
I know, I wasn't sure if it was still there been so long now!
Piotr Solnica
@solnic
it’s there
fwiw I think we can remove Predicate class
and just have rules
the hierarchy is a bit awkward right now
Pau Ramon Revilla
@masylum
hi there!
I was trying to use dry-validation in a rails project and I'm stumbling upon this error:
Dry::Container::Error:
There is already an item registered with the key "type?"