Closed natefaubion closed 7 years ago
One problem is that the "manager" also needs a port. On Unix we could get around this by using domain sockets but of course that won't work on windows, so maybe the better idea is to write the manager-port into a file $XDG_CONFIG_HOME/.psc-ide
.
Maybe the simplest thing would be to support something like psc-ide-server --auto
, which essentially does a grep/sed
on the output of ps
for currently running instances, returning a port (spawning a new instance as needed). With --auto
, the -p
would just be incremented as needed.
Couldn't multiple projects be supported with a custom build command?
Parsing ps
output seems like overkill honestly. If we really need multiple processes active, we could save the ports in a file.
Couldn't multiple projects be supported with a custom build command?
I mean, yeah, we can put it on the user to configure everything for every project and make sure nothing overlaps (you can only have multiple projects for those that have configured the option, and none of the configured ports can overlap) And we can also put it on various tools to do the management, which can lead to duplicate instances trying to build at the same time (if you use multiple tools that call psc-ide-server
). Personally, I'd love to be able to cd
into any project in vim and have it just work, though.
I mention ps
only because you always get an up-to-date list of instances, and it doesn't require you to keep (potentially stale) data in magic files.
I would say that's a job for an editor plugin. Vim could start psc-ide-server
on its own random port at startup.
One case where sharing instances across tools would be great is syncing (saving in vim could update a repl). Rather than having two instances rebuilding the same project.
Another potential case is having multiple editor sessions. This is more common with terminal vim, but I know some people jump from editor to editor.
Then again multiple instances of ´psc-ide-server` aren't that heavy right now. 10mb without any modules and 130mb with all the modules of slamdata loaded. Tested on my macbook. Maybe I shouldn't have settled for the fixed default 4242, but for a random highport negotiated at startup.
An easy solution for starters would be to do something like tern
does and put a file .psc-ide-port
in the toplevel folder of a project that psc-ide runs in. Re the repl case... let's build the repl that gets updated before worrying about its edgecases.
Re the repl case... let's build the repl that gets updated before worrying about its edgecases.
That's totally fair. That's also why this is in roadmap
and not the main repo :D Gotta dream a little.
Not that I haven't ;)
Right now my plugin code initially tries connecting to the configured port (default 4242), checks if the server is running it has the correct project directory, and uses it if so.
My tentative plan for multiple projects/windows/servers was to start at a configured port and walk up ports in a range until it either finds a suitable server or free port.
I definitely am getting to the point where this is really annoying, I typically have 2-3 projects open at once, with the failure of this is now more obvious.
Why not open on a random port and put the port in a dotfile in the project directory?
How do you select random port? Do I keep rolling a rng until I find a free port? Not sure I see what the dotfile gives, it's determining the port to use that's the interesting part.
The file was just in case other clients wanted to connect.
I would expect most ports to be free, but if you get unlucky, you'd just keep trying random ports.
Any updates on this? Is this covered by .psc-ide-port
files?
So Atom, Code, and pscid handle this via purescript-psc-ide, opening on a random port (and as you say persisting this in .psc-ide-port
files to allow this to be shared). I'm not sure outside of this.
The emacs plugin doesn't respect that file since it's easy to do this with .dir-locals.el
. Kind of a directory local configuration file for emacs which we use to declare paths for purescript source files on a per-project basis aswell.
Should be ok to implement the same thing as Atom and Code in psc-ide-vim.
Talked briefly with @kRITZCREEK on IRC about this. Currently, I don't think any of the editor plugins support multiple projects with
psc-ide-server
. It's kind of a pain because it requires maintaining a pool of ports and doing the bookkeeping for the processes. It would be nice ifpsc-ide-server
could server as a master process for on-demand project checking, maintaining the child processes as needed (keyed by project root).It's potentially something that one could just run on startup, and then all plugins would end up sharing the same instances. This could definitely live in another project, but then becomes yet another tool to install.