[e-lang] Good news for E REPLs!

[Kevin Reid]

I have just made a working, responsive web-page REPL for E, run off the same backend as my rewrite of eel. Said rewrite also now has a working IRC component, and a tested ability to kill hung vats.

The HTTP server end is simply a Java servlet plugged into Jetty in the same way as the Caja test suite does, plus some glue to allow writing a servlet from E.

(It does not support asynchronous output from the server, unfortunately, so no eventual printing or multi-user visibility. I need to research libraries for implementing “comet” features; but in the worst case I can imagine just doing some long-polling using my existing architecture.)

Besides polish and robustness, all we need to do to deploy this is to choose a server to run it on, and drop it behind an Apache reverse-proxy so it can be virtual hosted.

Source code coming soon after some cleanup.

[Kevin Reid]

Post by Kevin Reid
I have just made a working, responsive web-page REPL for E, run off the same backend as my rewrite of eel. Said rewrite also now has a working IRC component, and a tested ability to kill hung vats.

[...]

Post by Kevin Reid
Source code coming soon after some cleanup.

https://github.com/kpreid/e-murepl/

Source code is up. The IRC component is not yet included; it only does the web interface. Note that this requires the latest development version of E to support the process-isolated-vat subsystem.

I'm just now experimenting with using GitHub for repository hosting. Since Git is a DVCS, I'm not _relying_ on GitHub's continued existence for my project; in fact, I have my own second public copy at <git://switchb.org/e-murepl> (not an automatic mirror). (One thing I've been thinking about but haven't worked out is a tool to nag me about all local work not yet committed (SVN) or committed and pushed (Git) -- perhaps it could also do local<->remote<->remote mirroring.)

[James Graves]

I've started using github as well.

Since you can easily set up multiple remotes, you can just set your
switchb.org instance to automatically fetch all branches from github.

You could also automatically push selected branches to github
automatically. That can be as simple as a one-line crontab:

cd my_local_repo; git push origin master

Or whatever you've named the github remote instead of 'origin'.

I doubt you'd want to push local topic branches, unless you don't mind
seeing your work in progress. You probably wouldn't want people to fork
from those either. Sometimes my stuff is messy, and I'll rebase a set of
patches before anyone else gets a look at them. It can make the history
easier to follow.

James Graves

Post by Kevin Reid

Post by Kevin Reid
I have just made a working, responsive web-page REPL for E, run off the

same backend as my rewrite of eel. Said rewrite also now has a working IRC
component, and a tested ability to kill hung vats.

Post by Kevin Reid
[...]

Post by Kevin Reid
Source code coming soon after some cleanup.

https://github.com/kpreid/e-murepl/
Source code is up. The IRC component is not yet included; it only does the

web interface. Note that this requires the latest development version of E
to support the process-isolated-vat subsystem.

Post by Kevin Reid
I'm just now experimenting with using GitHub for repository hosting. Since

Git is a DVCS, I'm not _relying_ on GitHub's continued existence for my
project; in fact, I have my own second public copy at <git://
switchb.org/e-murepl> (not an automatic mirror). (One thing I've been
thinking about but haven't worked out is a tool to nag me about all local
work not yet committed (SVN) or committed and pushed (Git) -- perhaps it
could also do local<->remote<->remote mirroring.)

Post by Kevin Reid
--
Kevin Reid <http://switchb.org/kpreid/>
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

[James Graves]

My previous email was written with the assumption that you are using git
locally, and are also using git-svn (which works quite well). It is well
worth the effort to switch over completely to a git workflow. Also, github
is quite handy for discussing and reworking patches.

James Graves