[urbit] Hi Urbits!

[Jeremy Wall]

So I've been noodling around on improving the situation for urbit
development. I've long been of the opinion that a language that leaves the
tooling up to an IDE developer does themselves a big disservice. To that
end I'm thinking that urbit should provide "Tooling as a Service" out of
the box. Meaning that things like syntax checking, linting, formatting,
refactoring, and even autocomplete should all be available via API
endpoints for an urbit instance. Most of the pieces are there already.

To that end I'm going to see if I can get syntax checking as a service
working in urbit as a proof of concept. If anyone is interested in
following along or helping let me know.
--
Jeremy Wall
http://jeremy.marzhillstudios.com
***@marzhillstudios.com

[Galen Wolfe-Pauly]

This is awesome.

So I've been noodling around on improving the situation for urbit development. I've long been of the opinion that a language that leaves the tooling up to an IDE developer does themselves a big disservice. To that end I'm thinking that urbit should provide "Tooling as a Service" out of the box. Meaning that things like syntax checking, linting, formatting, refactoring, and even autocomplete should all be available via API endpoints for an urbit instance. Most of the pieces are there already.
To that end I'm going to see if I can get syntax checking as a service working in urbit as a proof of concept. If anyone is interested in following along or helping let me know.
--
Jeremy Wall
http://jeremy.marzhillstudios.com
--
You received this message because you are subscribed to the Google Groups "urbit" group.
For more options, visit https://groups.google.com/d/optout.

[Anton Dyudin]

Definitely interested in the concept; something I have long intended to
build was a full Hoon plugin for Light Table, which is built to have
language support negotiated over TCP with a corresponding language
"server". (Language support here mostly meaning eval, but I think some
plugins also implement contextual completion.)

It would definitely be interesting to also have e.g. "move the twig I'm
standing on to a named gate in the current core, passing in any named
variables referenced therein", but that might involve some cooperation from
the type system.

("Move this armgate to an outer/previous core dragging along anything
referenced as parameters" "move this arm to /===/lib% after encapsulating
everything as above"; "move this parameter to/from the/a |_ at the head of
the current core in all gates that use it" "remove the duplicate one,
changing all invocations to the gate/core accordingly")

Post by Jeremy Wall
So I've been noodling around on improving the situation for urbit
development. I've long been of the opinion that a language that leaves the
tooling up to an IDE developer does themselves a big disservice. To that
end I'm thinking that urbit should provide "Tooling as a Service" out of
the box. Meaning that things like syntax checking, linting, formatting,
refactoring, and even autocomplete should all be available via API
endpoints for an urbit instance. Most of the pieces are there already.
To that end I'm going to see if I can get syntax checking as a service
working in urbit as a proof of concept. If anyone is interested in
following along or helping let me know.
--
Jeremy Wall
http://jeremy.marzhillstudios.com
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
.
For more options, visit https://groups.google.com/d/optout.

[Jeremy Wall]

Post by Anton Dyudin
Definitely interested in the concept; something I have long intended to
build was a full Hoon plugin for Light Table, which is built to have
language support negotiated over TCP with a corresponding language
"server". (Language support here mostly meaning eval, but I think some
plugins also implement contextual completion.)

I think repl as a service might also be interesting.

Post by Anton Dyudin
It would definitely be interesting to also have e.g. "move the twig I'm
standing on to a named gate in the current core, passing in any named
variables referenced therein", but that might involve some cooperation from
the type system.

Any refactoring and contextual actions are going to a number of things.
Among them a way to tell the service what subject this code should assume.
(ie. is this a %gall app? %eyre?)

Post by Anton Dyudin
("Move this armgate to an outer/previous core dragging along anything
referenced as parameters" "move this arm to /===/lib% after encapsulating
everything as above"; "move this parameter to/from the/a |_ at the head of
the current core in all gates that use it" "remove the duplicate one,
changing all invocations to the gate/core accordingly")

Yeah that's all very much future work but theoretically possible.

Post by Anton Dyudin

Post by Jeremy Wall
So I've been noodling around on improving the situation for urbit
development. I've long been of the opinion that a language that leaves the
tooling up to an IDE developer does themselves a big disservice. To that
end I'm thinking that urbit should provide "Tooling as a Service" out of
the box. Meaning that things like syntax checking, linting, formatting,
refactoring, and even autocomplete should all be available via API
endpoints for an urbit instance. Most of the pieces are there already.
To that end I'm going to see if I can get syntax checking as a service
working in urbit as a proof of concept. If anyone is interested in
following along or helping let me know.
--
Jeremy Wall
http://jeremy.marzhillstudios.com
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

--
Jeremy Wall
http://jeremy.marzhillstudios.com
***@marzhillstudios.com