Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    x4lldux
    @x4lldux
    so I think instumenter needs to recognize both, :gen_server and GenServer
    Klaus Alfert
    @alfert
    I am also pretty sure that we need a more low-level reporting facility in addition to the reports to understand how the messages are sent and received during the implementation of the calls. It would be quite complicated to find errors only on the command level, that is at least my current assumption. We could find all the information by interception the message flow, should be technically easy.

    so I think instumenter needs to recognize both, :gen_server and GenServer

    Yes, either that or instrumenting calls to :gen and instrument :elixir as well as stdllib. That sounds silly. I would go for instrumenting calls to Elixir's standard functionalities such as GenServer, GenEvent, Task and so on.

    x4lldux
    @x4lldux

    How about using a numeric index before each command, something like A.001 , A.002, ... B.001, B.002,

    printer already supports this with cmd_args: false option. but what I was thinking, was instead of pretty boxes like I showed earlier, something like this:

    
    Sequential commands:
       var1 = DSL.cache(4, "")
            # -> true
    
    
    Process 1 (5, 5):
    #! var2 = DSL.cache(1, "𐀀")
            # -> true
    #! var3 = DSL.cache(10, "")
            # -> true
    #! var4 = DSL.cache(0, "")
            # -> true
    #! var5 = DSL.cache(-1, "Ϊŕ")
            # -> :error
    #! var6 = DSL.cache(-1, "𐀄݅醧")
            # -> true
    
    
    Process 2 (6, 6):
    #! var7 = DSL.flush()
            # -> true
    #! var8 = DSL.cache(6, "")
            # -> true
    #! var9 = DSL.cache(2, "")
            # -> true
    #! var10 = DSL.cache(3, "ҡ")
            # -> true
    #! var11 = DSL.cache(9, "")
            # -> true
    #! var12 = DSL.find(8)
            # -> {:error, :not_found}
    Klaus Alfert
    @alfert
    Yes, that looks awesome!
    x4lldux
    @x4lldux
    so user can see all the args, and the order of command, and instead of a graph with justthe commands, has a list with commands and args

    Yes, either that or instrumenting calls to :gen and instrument :elixir as well as stdllib.

    That sounds slooooow.

    I'd instrument Gen* family, :gen_* family and Tasks by default. but also give a quick way to instrument other modules instead of full apps
    Klaus Alfert
    @alfert
    The only thing I miss for now is the correlation between commands of the processes. We cannot see this in the reports - and it might be meaningless since we do not know how long each command run. So there is indication that e.g. var8 is always set after var2 because Process 2 could be faster than Process 1.
    x4lldux
    @x4lldux
    and supervisors ofc!
    Klaus Alfert
    @alfert

    'd instrument Gen family, :gen_ family and Tasks by default. but also give a quick way to instrument other modules instead of full apps

    We need something different: the current application under test needs to instrumented such that calls to Gen*, Task, SuperVisor, :ets, :dets and some replaced by their instrumented variants (I would like to add support for send() and receive..do..end as well).

    The basic idea is to instrument the application under test only. In special cases, it might be helpful to instrument other applications or modules as well, but this really depends on the situation.
    Instrumenting modules can always be done by calling instrument_module(), which is the working horse of instrument_app().
    x4lldux
    @x4lldux
    yes yes, I only meant that with respect to earlier arguments about :gen vs Gen and instrumenting entire :elixir and stdlib. I fully agree with Ets, Dets, :io, File, send/receive all need to be instrumented also
    *calls to those things
    Klaus Alfert
    @alfert
    yep. exactly.
    So, I would go for experimental instrumentation as part of the next release, and then we follow with better support for concurrency in the later release(s).
    x4lldux
    @x4lldux

    So there is indication that e.g. var8 is always set after var2 because Process 2 could be faster than Process 1.

    this isn't clearly present even in this version:

    Sequential step: 
    var1 = DSL.cache(10, 1)
    var2 = DSL.cache(8, -2)
    
    Parallel step: 
      +------------P0-------------+      +-----------P1-----------+    
      | var3 = DSL.cache(-18, -2) |      | var5 = DSL.cache(8, 3) |    
      | var4 = DSL.find(-2)       |      | var6 = DSL.cache(0, 0) |    
      +---------------------------+      | var7 = DSL.flush()     |    
                                         +------------------------+
    all of P1 commands can be started and finished when P0 executes DSL.cache from var3... so there's no good way to visualize this
    Klaus Alfert
    @alfert
    Yes, I recognised it during the writing. And that is something we need to document, otherwise people will be very irritated.
    x4lldux
    @x4lldux
    yup
    ok. it's night-night for me. see ya
    Klaus Alfert
    @alfert
    me too! Good night!
    Klaus Alfert
    @alfert
    Folks, do we need more for PR #157 ? Otherwise I would merge. My next plans are provide a buggy concurrent algorithm or to analyse the Registry. In addition to that I would like to start a better reporting facility for parallel processes by evaluating traces.
    Magnus
    @evnu
    I think merging is fine, that should be a good starting ground for new tests.
    Alas, I am a bit swamped with work right now, so I can't review a lot currently :-/
    Magnus
    @evnu
    alfert/propcheck#165 I really like that idea! :)
    Klaus Alfert
    @alfert
    yes, it is a good idea and the implementation thought also about problems of shadowing variables and stuff like that. That shows some seniority with compiling / interpreting computer languages.
    Magnus
    @evnu
    Should the new libgraph dep be runtime: false? It might only be needed during compilation. Can't check right now, only on mobile.
    Klaus Alfert
    @alfert
    Hmm, it is only required during the test phase, i.e. it will not be part of our client's dependencies. Runtime false would mean what exactly?
    Marking a dependency runtime: false will not start it as part of the application supervision tree when your main application is started.
    Probably doesn't make a difference, I guess libgraph does not have a supervisor tree
    Klaus Alfert
    @alfert
    No, it doesn't have a supervisor tree, so it is not important.
    Klaus Alfert
    @alfert
    @evnu , @x4lldux I do a nasty git operation, due to the unlucky merge operation of Alex for his let-chaining branch. I create a new branch, cherry-picked all commits and publish the old master as the new and create a new PR. Keep your fingers crossed and please don't do anything with the repo.
    Magnus
    @evnu
    :+1:
    sometimes you gotta do what you gotta do
    Klaus Alfert
    @alfert
    sometimes you gotta do what you gotta do
    And it worked out well.
    Magnus
    @evnu
    Maybe someone here has a little bit of input for this: I sometimes find a failing counter example on CI; I can then download the counter examples and fix the problem. It happens that I realize only after that I should add a specific regression test with the example I just fixed, but the list of counter examples is already clear. So, to get the example again, I download the file from CI again and make the test fail, to copy the example from the output. I think it would be nice to allow listing the counter examples on the command line instead. For example, mix propcheck.list_counter_examples What do you think?
    Klaus Alfert
    @alfert
    Did you tried mix propcheck.inspect?
    Perhaps a better would be helpful
    Magnus
    @evnu
    Ah, I didn't know/remember that option. Will check it out next week.
    Magnus
    @evnu
    @alfert thanks, propcheck.inspect looks good!
    Magnus
    @evnu
    It seems that proper's development has slowed down a bit again. A new release of propcheck would be nice, though.
    Klaus Alfert
    @alfert
    @evnu Good point, semester holidays are over, obviously. I was absorbed with job related stuff in the last weeks. I will try to create a release this week, after that I am on vacation myself. It would be a point release, without too much new/fancy stuff, since the parallelism stuff is still in its early phases - unless you can convince me otherwise ...
    Klaus Alfert
    @alfert
    PropCheck 1.2.1 is out
    Magnus
    @evnu
    hey, I am offline a lot right now as well (holiday season). Thanks for the release!
    Magnus
    @evnu
    @alfert As Elixir v1.5 is no longer supported, maybe :poison should no longer be a direct dependency of PropCheck. From git blame, it was introduced as a direct dependency to work around a travis issue for Elixir v1.5? (1e41ce4b)
    Magnus
    @evnu
    @alfert would be nice to have a release soonish to get rid of the __STACKTRACE__ warnigns