monto-editor/Lobby

Monto, a solution to the IDE portability problem

Sven Keidel

@svenkeidel

Welcome to the Monto Editor Gitter channel.

Tony Sloane

@inkytonik

Wulf Pfeiffer

@wpmp

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

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.

https://github.com/monto-editor/monto-emacs

https://github.com/monto-editor/monto-atom

@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.

Where communities thrive

People

Repo info

Activity