Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Sven Keidel
    @svenkeidel
    Welcome to the Monto Editor Gitter channel.
    Tony Sloane
    @inkytonik
    Hi
    Wulf Pfeiffer
    @wpmp
    Hi
    Sven Keidel
    @svenkeidel
    @StareInTheAir, when can we merge the file-dependency branch?
    This message was deleted
    Hans Becker
    @StareInTheAir
    hey
    yeah we should. I already merged every other repository to master
    Should I do it?
    Sven Keidel
    @svenkeidel
    Have you tested if all the other services still compile and work after the merge?
    Hans Becker
    @StareInTheAir
    Yes, and benchmarks of services-java don't work since the multiplexing. services-javascript and services-python also have errors. benchmarks will be the hardest to fix.
    Sven Keidel
    @svenkeidel
    Yes, this was to be expected. Long running feature branches are evil. Anyway, do you think we can share the work between each other?
    What is your estimate of how much work this is?
    My estimate would be a full day of work.
    Hans Becker
    @StareInTheAir
    Let me look at the errors
    Hans Becker
    @StareInTheAir
    ok, most of services-javascript and services-python is really easy to fix. Code Completions is not quite as easy, but should be possible too. 1/2 day for that. benchmarks needs to be merged, but it doesn't look as impossible as I thought. Max 1/2 for that too
    Sven Keidel
    @svenkeidel
    Then I would tackle the JavaScript services and the benchmarks. Can you work on the rest?
    Hans Becker
    @StareInTheAir
    Javascript and python services are very similar to fix. I suggest I do that and you do benchmarks
    Sven Keidel
    @svenkeidel
    Ok
    Hans Becker
    @StareInTheAir
    ok, it was more complicated, than planned. Originally I thought I could fake the code completions like before, but then I remembered, that they need the position in the source code to work. The source code position is now send via CommandMessages. So I transformed the javascript and python code completion into identifier finders, just like in the Java services. Because of that I now can reuse the Java code completion service 1to1 for python and javascript (with CommandMessages)
    I also had to touch a lot of code, I planned to unify sometime (Main classes, usage of centralized icons, cmdline parameters), so I also did that now
    Sven Keidel
    @svenkeidel
    Great
    I simply removed the benchmarks from the main trunk. The benchmarks live in their own branch anyway, so there is no need to keep them around in master.
    Hans Becker
    @StareInTheAir
    It seems the highlighting with tokens (for javascript and python) in the eclipse editor doesn't work any more. I didn't know, that it was based on Token and purely done in the Eclipse edtior
    Sven Keidel
    @svenkeidel
    They probably use the old format for highlighting with token categories and not the new one.
    Hans Becker
    @StareInTheAir
    Morning! I fixed up the broker a bit yesterday and merged to master. Also highlighting in the web-editor still works with python, java and javascript. So it's an eclipse-editor issue.
    Sven Keidel
    @svenkeidel
    The webeditor uses token categories to the best of my knowledge. We should change it to use the new highlighting IR as well.
    Hans Becker
    @StareInTheAir
    There is code in the eclipse editor for that too, but it crashes
    Nathan Ringo
    @remexre
    Hi, I'm the guy who's been emailing from the MELT/Silver team; I just sent an email with our in-progress draft RFC. If you have any questions, I'll be here
    Sven Keidel
    @svenkeidel
    Hi, sorry for the late response.
    I created two repositories in the monto github organization for the two new editor plugins.
    @remexre, I gave you admin rights on these repositories.
    I take a look at the new monto spec now.
    Sven Keidel
    @svenkeidel
    Sec 3.2.:
    Do the language services still send a description to the broker which products they offer?
    Differences: Stateless Services
    For some services it is infeasible to be stateless, e.g. debuggers.
    Sven Keidel
    @svenkeidel
    I would not use JSON-Schema to describe the message formats. It is too verbose in my opinion. Can we use the format I used in the SLE'16 paper?
    the “source” field of the ClientRequest is a “source” product. Please use the terminology that we used in the paper. "source" product == source
    Sven Keidel
    @svenkeidel
    3.2.3. Requesting Products:
    If the Service requires additional input Products to create the requested Product, it SHALL respond with a ServiceDependency Message and an HTTP Status of 400
    Why not send a GET request of the required products to the broker?
    Sven Keidel
    @svenkeidel
    The example work-flow I am imagining:
    IDE -- POST (Source) --> Broker
    IDE -- GET (Highlighting) --> Broker
    Broker -- GET (Highlighting) --> Highlighting Service
    Highlighting Service -- GET (AST) --> Broker
    Broker -- GET(AST) --> Parsing Service
    Parsing Service -- Response(AST) --> Broker
    Broker -- Response (AST) --> Highlighting Service
    Highlighting Service -- Response (Highlighting) --> Broker
    Broker -- Response (Highlighting) --> IDE.
    With a push-based model we would save two of the get requests.
    @remexre, let me know what you think.
    Nathan Ringo
    @remexre

    Do the language services still send a description to the broker which products they offer?

    Forgot to add that to the BrokerVersion message. Thanks!

    For some services it is infeasible to be stateless, e.g. debuggers.

    Addressed in the email, but I haven't thought of a good way (other than state tokens) to do this while still allowing multiple users per service.

    Nathan Ringo
    @remexre

    I would not use JSON-Schema to describe the message formats. It is too verbose in my opinion. Can we use the format I used in the SLE'16 paper?

    I chose JSON Schema because it's machine verifiable -- I can use the spec itself to validate network communications. (That's also why the schemas are all in their own files). If you want, I can use a more human-readable format in the actual document, though.

    Why not send a GET request of the required products to the broker?

    The broker needs a public IP in that case.

    Nathan Ringo
    @remexre

    Here's what I'm envisioning, for the first request:

    // For a file "foo"
    
    Client -> Broker            ClientRequest([Errors(foo)], [Source(foo)])
      Broker -> ErrorService    BrokerRequest([Errors(foo)], [Source(foo)])
      Broker <- ErrorService    [ Err(NeedsProducts([AST(foo)]))
                                , Info(DontNeedProducts([Source(foo)]))
                                ]
      Broker -> ASTService      BrokerRequest([AST(foo)], [Source(foo)])
      Broker <- ASTService      Ok([AST(foo)])
      Broker -> ErrorService    BrokerRequest([Errors(foo)], [AST(foo)])
      Broker <- ErrorService    Ok([Errors(foo)])
    Broker <- Client            Ok([Errors(foo)])

    The Broker could then cache the fact that for the file foo, ErrorService needs AST(foo) and not Source(foo), so further requests are:

    // For a file "foo"
    
    Client -> Broker            ClientRequest([Errors(foo)], [Source(foo)])
      Broker -> ASTService      BrokerRequest([AST(foo)], [Source(foo)])
      Broker <- ASTService      Ok([AST(foo)])
      Broker -> ErrorService    BrokerRequest([Errors(foo)], [AST(foo)])
      Broker <- ErrorService    Ok([Errors(foo)])
    Broker <- Client            Ok([Errors(foo)])
    Nathan Ringo
    @remexre

    Please use the terminology that we used in the paper. "source" product == source

    I'm was actually intentionally calling out sources as being just another product type whose name happens to be "source". I can make that more clear in the document itself, though.