Since apparently Emacs has no real support for multiuser
editing (although I have now learned about two partial
work-arounds, Ebby, and Shemacs; I haven't tried either),
I am wondering whether there is any support for multiple
users interacting with *any* lisp interpreter simultaneously,
sharing state and all that.
··············@gmail.com" <·············@gmail.com> wrote in
····························@h76g2000cwa.googlegroups.com:
>
> Since apparently Emacs has no real support for multiuser
> editing (although I have now learned about two partial
> work-arounds, Ebby, and Shemacs; I haven't tried either),
> I am wondering whether there is any support for multiple
> users interacting with *any* lisp interpreter simultaneously,
> sharing state and all that.
>
You may look here:
http://www.cons.org/cmucl/doc/lispserver.html
On 6 Jun 2006 14:19:29 -0700, ··············@gmail.com"
<·············@gmail.com> wrote:
>
>Since apparently Emacs has no real support for multiuser
>editing (although I have now learned about two partial
>work-arounds, Ebby, and Shemacs; I haven't tried either),
>I am wondering whether there is any support for multiple
>users interacting with *any* lisp interpreter simultaneously,
>sharing state and all that.
The BioBike system, www.biobike.org, supports multiple users
interacting with the same running Lisp (Allegro), sharing state
and all that.
On Tue, 06 Jun 2006 23:19:29 +0200, ·············@gmail.com
<·············@gmail.com> wrote:
>
> Since apparently Emacs has no real support for multiuser
> editing (although I have now learned about two partial
> work-arounds, Ebby, and Shemacs; I haven't tried either),
> I am wondering whether there is any support for multiple
> users interacting with *any* lisp interpreter simultaneously,
> sharing state and all that.
>
Not in the ANSI Common Lisp standard.
Each vendor add's their own thread management.
Of the major implementations I think only CLisp lacks thread's.
You would have to write your own server.
This is not as difficult as it sounds.
For each request fire up a new thread.
I must admit I have only done this with a application server
for Othello using LispWorks.
I used a web interface. Java applet draws the board.
XML-RPC for sending board updates and getting computer/user
move back. Apache server sends message over to Lisp app
over a socket using FastCGI. (Many prefer mod_lisp/mod_lisp2.)
In general each new thread get's a new Lisp Listener.
Since global variables are special and created by the listener
they are not shared. (That's only a half truth.)
For shared data you need semaphores/monitors.
Again implementation dependent.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
··············@gmail.com" <·············@gmail.com> writes:
> Since apparently Emacs has no real support for multiuser
> editing
What more do you want than make-frame-on-display?
> (although I have now learned about two partial
> work-arounds, Ebby, and Shemacs; I haven't tried either),
> I am wondering whether there is any support for multiple
> users interacting with *any* lisp interpreter simultaneously,
> sharing state and all that.
--
__Pascal Bourguignon__ http://www.informatimago.com/
IMPORTANT NOTICE TO PURCHASERS: The entire physical universe,
including this product, may one day collapse back into an
infinitesimally small space. Should another universe subsequently
re-emerge, the existence of this product in that universe cannot be
guaranteed.
> > Since apparently Emacs has no real support for multiuser
> > editing
>
> What more do you want than make-frame-on-display?
I want both shared state and uniquely identified users. If
after doing make-frame-on-display I could uniquely identify
edits/actions coming from different displays, then this would work.
But I strongly suspect that this isn't possible.
··············@gmail.com" <·············@gmail.com> writes:
>> > Since apparently Emacs has no real support for multiuser
>> > editing
>>
>> What more do you want than make-frame-on-display?
>
> I want both shared state and uniquely identified users. If
> after doing make-frame-on-display I could uniquely identify
> edits/actions coming from different displays, then this would work.
This is not built-in.
> But I strongly suspect that this isn't possible.
On the contrary! This is emacs!
Check frame-local variables. You can identify the user corresponding
to each frame, and then on, you can track the edits coming from the
different frames. For example you could put in a different face the
text inserted from different frames.
But then, of course, there are complete solutions:
http://en.wikipedia.org/wiki/Collaborative_real-time_editor
--
__Pascal Bourguignon__ http://www.informatimago.com/
THIS IS A 100% MATTER PRODUCT: In the unlikely event that this
merchandise should contact antimatter in any form, a catastrophic
explosion will result.
> > I want both shared state and uniquely identified users. If
> > after doing make-frame-on-display I could uniquely identify
> > edits/actions coming from different displays, then this would work.
> Check frame-local variables. You can identify the user corresponding
> to each frame, and then on, you can track the edits coming from the
> different frames. For example you could put in a different face the
> text inserted from different frames.
This is a sensible suggestion, thank you.
But -- one related challenge is to do the same thing with code that
is evalled! This sounds challenging. Seems to bring up the issue
of concurrency (a topic I sadly know very little about).
One of the features I'm planning to build into the system I'm working
on
is some extension of plists, which could for example be used to keep
track
of who has been authoring/editing which Lisp forms. I haven't finished
the design for this feature, however. (And it isn't quite clear to me
yet
whether others have already addressed this matter.)
··············@gmail.com" <·············@gmail.com> writes:
> One of the features I'm planning to build into the system I'm
> working on is some extension of plists, which could for example be
> used to keep track of who has been authoring/editing which Lisp
> forms. I haven't finished the design for this feature, however.
> (And it isn't quite clear to me yet whether others have already
> addressed this matter.)
Have a look at: http://paste.lisp.org/display/20035 (ibcl.lisp)
You could easily add a *current-user* to the definitions collected in
a multi-threaded environment...
--
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.
Pascal Bourguignon wrote:
> ··············@gmail.com" <·············@gmail.com> writes:
> > One of the features I'm planning to build into the system I'm
> > working on is some extension of plists, which could for example be
> > used to keep track of who has been authoring/editing which Lisp
> > forms. I haven't finished the design for this feature, however.
> > (And it isn't quite clear to me yet whether others have already
> > addressed this matter.)
>
> Have a look at: http://paste.lisp.org/display/20035 (ibcl.lisp)
> You could easily add a *current-user* to the definitions collected in
> a multi-threaded environment...
Geh, looks to require significant thinking on my part.
Could you post somewhere a representative usage of
the tools in that package?
··············@gmail.com" <·············@gmail.com> writes:
> Pascal Bourguignon wrote:
>> ··············@gmail.com" <·············@gmail.com> writes:
>> > One of the features I'm planning to build into the system I'm
>> > working on is some extension of plists, which could for example be
>> > used to keep track of who has been authoring/editing which Lisp
>> > forms. I haven't finished the design for this feature, however.
>> > (And it isn't quite clear to me yet whether others have already
>> > addressed this matter.)
>>
>> Have a look at: http://paste.lisp.org/display/20035 (ibcl.lisp)
>> You could easily add a *current-user* to the definitions collected in
>> a multi-threaded environment...
>
> Geh, looks to require significant thinking on my part.
> Could you post somewhere a representative usage of
> the tools in that package?
Here:
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/d77afe3ef9680d88/ae3e871c9bf9a165?lnk=st&q=ibcl+group%3Acomp.lang.lisp+author%3APascal+author%3ABourguignon&rnum=1&hl=en#ae3e871c9bf9a165
--
__Pascal Bourguignon__ http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.
Pascal Bourguignon wrote:
> ··············@gmail.com" <·············@gmail.com> writes:
...
> > I want both shared state and uniquely identified users. If
> > after doing make-frame-on-display I could uniquely identify
> > edits/actions coming from different displays, then this would work.
...
> On the contrary! This is emacs!
>
> Check frame-local variables. You can identify the user corresponding
> to each frame, and then on, you can track the edits coming from the
> different frames. For example you could put in a different face the
> text inserted from different frames.
Wouldn't multiple users all want their own favorite Emacs keybindings?
And custom elisp functions?
That is far beyond frame-local variables; really, you would want
frame-local keymaps and function bindings.
··············@hotmail.com wrote:
> Pascal Bourguignon wrote:
> > Check frame-local variables. You can identify the user corresponding
> > to each frame, and then on, you can track the edits coming from the
> > different frames. For example you could put in a different face the
> > text inserted from different frames.
>
> Wouldn't multiple users all want their own favorite Emacs keybindings?
> And custom elisp functions?
>
> That is far beyond frame-local variables; really, you would want
> frame-local keymaps and function bindings.
Good point. Everyone will want their own working environment or
frontend.
What is required to be shared is the backend. Now, it may be that the
various
frontends will have some representation in the backend, but basically I
see
that as icing on the cake.
By the way, I guess I might as well post some info about why I
care about this (in case anyone else happens to care about that).
This is all part of a project I'm working on at http://hdm.nongnu.org,
and, specifically, it is related to the "Arxana" subproject.
(Look in ./scholium-system/ subdirectory after CVS checkout.)
Basically an updated version of Ted Nelson's "Xanadu" project,
but as free software and with an eye towards AI applications.
(Oh, also I wanted to change my nickname.)
>>>>> "holtzermann" == ·············@gmail com <·············@gmail.com> writes:
holtzermann> ··············@hotmail.com wrote:
>> Pascal Bourguignon wrote:
>> > Check frame-local variables. You can identify the user corresponding
>> > to each frame, and then on, you can track the edits coming from the
>> > different frames. For example you could put in a different face the
>> > text inserted from different frames.
>>
>> Wouldn't multiple users all want their own favorite Emacs keybindings?
>> And custom elisp functions?
>>
>> That is far beyond frame-local variables; really, you would want
>> frame-local keymaps and function bindings.
holtzermann> Good point. Everyone will want their own working
holtzermann> environment or frontend. What is required to be shared
holtzermann> is the backend. Now, it may be that the various
holtzermann> frontends will have some representation in the backend,
holtzermann> but basically I see that as icing on the cake.
Then how about having each user run their own instance of emacs with
something like slime connecting to the same lisp process (presumably
interacting with a separate thread)?
The slime backend could be extended to track users and stuff and the
slime frontend (eval-defun, compile-form etc) could be extended to
recoqnize for instance defuns and set the necessary plists on the
symbols.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)