On 11/02/2010 12:31 PM, LyX Ticket Tracker wrote:
Comment(by sanda):
>But you will still have a latent bug here.
so this 'fix' is still not fixing the root cause, right?
Right.
Petr Šimon wrote:
> Hello,
> I have a question about citation-insert, which I use from a Firefox
> extension Lyz, a plugin for Zotero.
> When I set the citation format to (Author, year) (using natbib and
> plainnat) and send citation-insert to lyxserver the citation is inserted as
(I am not on the mailing list, please CC)
Hello,
I have a question about citation-insert, which I use from a Firefox
extension Lyz, a plugin for Zotero.
When I set the citation format to (Author, year) (using natbib and
plainnat) and send citation-insert to lyxserver the citation is inserted as
>> The problem wasn't completely solved yet, but I didn't had time to
>> investigate more. It also still crashed in release mode when closing
>> the pipes. Besides, it takes me sometimes 8 tries before I could
>> succesfully connect.
>
>Note that this patch is slightly different from the one I
allow GUI operations outside the main
> thread.
> >
> >Modified:
> > lyx-devel/trunk/development/lyxserver/server_monitor.cpp
> > lyx-devel/trunk/development/lyxserver/server_monitor.h
> >
>
> The problem wasn't completely solved yet, but I didn'
>Author: forenr
>Date: Sun Sep 13 17:07:28 2009
>New Revision: 31386
>URL: http://www.lyx.org/trac/changeset/31386
>
>Log:
>Take into account that Qt doesn't allow GUI operations outside the main
thread.
>
>Modified:
> lyx-devel/trunk/development/lyxserver/se
On Sat, Sep 12, 2009 at 11:30:23PM +0200, Enrico Forestieri wrote:
> On Sat, Sep 12, 2009 at 09:57:24PM +0200, Andre Poenitz wrote:
>
> > On Sat, Sep 12, 2009 at 06:33:17PM +0200, Vincent van Ravesteijn wrote:
> > > But, it doesn't run ok. It's not allowed to access the GUI from within a
> > > d
On Sun, Sep 13, 2009 at 12:53:54AM +0200, Vincent van Ravesteijn wrote:
> It's slightly better in release mode. Now it only crashes when closing
> the pipes, or quitting the monitor.
Is it any better with the attached patch (even in debug mode)?
--
Enrico
Index: developmen
Enrico Forestieri schreef:
On Sat, Sep 12, 2009 at 09:57:24PM +0200, Andre Poenitz wrote:
On Sat, Sep 12, 2009 at 06:33:17PM +0200, Vincent van Ravesteijn wrote:
But, it doesn't run ok. It's not allowed to access the GUI from within a
different thread.
Funny, worked on Linux.
On Sat, Sep 12, 2009 at 09:57:24PM +0200, Andre Poenitz wrote:
> On Sat, Sep 12, 2009 at 06:33:17PM +0200, Vincent van Ravesteijn wrote:
> > But, it doesn't run ok. It's not allowed to access the GUI from within a
> > different thread.
>
> Funny, worked on Linux. But you are right of course.
I
lyx-devel/trunk/development/lyxserver/server_monitor.cpp
>
> Modified: lyx-devel/trunk/development/lyxserver/server_monitor.cpp
> ==
> --- lyx-devel/trunk/development/lyxserver/server_monitor.cpp Sat Sep 12
On Sat, Sep 12, 2009 at 06:33:17PM +0200, Vincent van Ravesteijn wrote:
> But, it doesn't run ok. It's not allowed to access the GUI from within a
> different thread.
Funny, worked on Linux. But you are right of course.
> That means that Qt asserts for every call to a member
> function of inf
On Sat, Sep 12, 2009 at 06:33:17PM +0200, Vincent van Ravesteijn wrote:
> for...@lyx.org schreef:
> > Author: forenr
> > Date: Sat Sep 12 02:15:00 2009
> > New Revision: 31372
> > URL: http://www.lyx.org/trac/changeset/31372
> >
> > Log:
> > Add a Qt version of the LyX server monitor program.
> >
for...@lyx.org schreef:
Author: forenr
Date: Sat Sep 12 02:15:00 2009
New Revision: 31372
URL: http://www.lyx.org/trac/changeset/31372
Log:
Add a Qt version of the LyX server monitor program.
I tried to account for msvc based on the MS docs, but I cannot test it.
Apologies if it does not compile
On Sat, Sep 12, 2009 at 11:42:42AM +0200, Andre Poenitz wrote:
> Looks like server_monitor.c can go now?
Or moved to the attic?
--
Enrico
svc based on the MS docs, but I cannot test it.
> Apologies if it does not compile out of the box. It works with mingw.
>
> Added:
>lyx-devel/trunk/development/lyxserver/server_monitor.cpp (contents,
> props changed)
>lyx-devel/trunk/development/lyxserver/serv
Konrad Hofbauer wrote:
> Pavel Sanda wrote:
> > fyi i have found now that lyxclient is able to detect non-working pipe,
>> so the bibdesk script could use lyxclient to pass the commands or its
>> detection mechanism.
>
> Thanks - and wht does lyxclient do if it finds a broken pipe?
ends up with
Pavel Sanda wrote:
> fyi i have found now that lyxclient is able to detect non-working pipe,
so the bibdesk script could use lyxclient to pass the commands or
its detection mechanism.
Thanks - and wht does lyxclient do if it finds a broken pipe?
If there exists already code that detects a non
Jean-Marc Lasgouttes wrote:
> Konrad Hofbauer <[EMAIL PROTECTED]> writes:
>
> > The previous email maybe was too wordy, let me summarize:
> >
> > IMHO not starting the LyXServer when there are existing .lyxpipe files
> > is a bad choice, because afte
Konrad Hofbauer wrote:
> Jean-Marc Lasgouttes wrote:
>> LyXPipes should be removed on a crash, IMO.
>
> I have not quite figured out yet when this remnant lyxpipes occur. I will
> keep an eye on it.
if you are on 1.6 find some current crash in bugzilla and try out ;)
you can fill some bugzilla re
Jean-Marc Lasgouttes wrote:
LyXPipes should be removed on a crash, IMO.
I have not quite figured out yet when this remnant lyxpipes occur. I
will keep an eye on it.
If I kill LyX with e.g. "kill -QUIT" then they are not removed. But this
is not the same as a crash, I know ...
/Konrad
Thanks for your answers!
Pavel Sanda wrote:
1) Blindly recreate the Lyx-Pipe
if you are used to launch many instance simultaneously you will never know
who owns pipe.
I conclude from this that some people do frequently run multiple
instances at a time. Then this is not an option.
2) Ask t
Konrad Hofbauer <[EMAIL PROTECTED]> writes:
> The previous email maybe was too wordy, let me summarize:
>
> IMHO not starting the LyXServer when there are existing .lyxpipe files
> is a bad choice, because after a crash _once_, it leaves the user
> _forever_ with a no
Konrad Hofbauer wrote:
> The previous email maybe was too wordy, let me summarize:
>
> IMHO not starting the LyXServer when there are existing .lyxpipe files is a
> bad choice, because after a crash _once_, it leaves the user _forever_ with
> a non-funtional LyXServer.
>
>
The previous email maybe was too wordy, let me summarize:
IMHO not starting the LyXServer when there are existing .lyxpipe files
is a bad choice, because after a crash _once_, it leaves the user
_forever_ with a non-funtional LyXServer.
LyX could instead:
1) Blindly recreate the Lyx-Pipe
/
which I run into from time to time, that causes BibDesk to hang, and
which I am trying to hunt down.
That Bibdesk hangs is the script's fault, but the underlying reason is
that the LyXServer is not running. Bibdesk runs a shell script with
#!/bin/sh
echo LYXCMD:BibDesk:citation-insert
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | - lyxserver->emergencyCleanup();
| > | + theApp->server().emergencyCleanup();
| > I must admit that I really dislike the "
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> even "theLyX" had been better.
Abdelrazak> That does not sound right to my hears... Would you prefer
Abdelrazak> LyXApp?
You mean lyxApp, I guess :)
JMarc
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| - lyxserver->emergencyCleanup();
| + theApp->server().emergencyCleanup();
I must admit that I really dislike the "theApp" name.
To me it conveys absolutely no information.
For me
h"
| #include "frontends/lyx_gui.h"
| #include "frontends/LyXView.h"
|
| @@ -89,8 +89,6 @@
| #endif
|
|
| -extern LyXServer * lyxserver;
| -
| // This is the global bufferlist object
| BufferList bufferlist;
|
| @@ -661,8 +659,7 @@
| // a crash
|
| bufferli
Abdelrazak Younes wrote:
Index: lyxserver.C
===
Hum... please disregard the changes in this file which are obviously not
needed.
Abdel.
--- lyxserver.C (revision 15112)
+++ lyxserver.C (working copy)
@@ -39,13 +39,15 @@
#i
lyx::from_utf8(command));
Index: frontends/Application.C
===
--- frontends/Application.C (revision 15114)
+++ frontends/Application.C (working copy)
@@ -25,11 +25,6 @@
using lyx::support::package;
-// FIXME: replace all
Hello,
As the subject says and as agreed in my latest patch. Will commit soon.
Abdel.
On Tuesday 01 February 2005 15:10, G. Milde wrote:
>
> These are the first to spring into my mind. There are more to expect. But
> also, they (and the existing ones) must be documented in order to be
> usable.
>
> My goal is to get for lyx a broad base of user-provided extensions in the
> way we th
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "G" == G Milde <[EMAIL PROTECTED]> writes:
>
| G> The keybinding is not really needed. If the code becomes more clear
| G> and concise by removing, please do so.
>
| It does not really change the code. It is just a matter of design of
| the l
> "G" == G Milde <[EMAIL PROTECTED]> writes:
G> The keybinding is not really needed. If the code becomes more clear
G> and concise by removing, please do so.
It does not really change the code. It is just a matter of design of
the lyxsever protocol.
G> I thought to keep it for backwards comp
On 2.02.05, Jean-Marc Lasgouttes wrote:
> >>>>> "G" == G Milde <[EMAIL PROTECTED]> writes:
>
> G> Feature Request ===
>
> G> Could the lfun "server-notify" take an data argument, that is
> G> passed on to the lyx
>>>>> "G" == G Milde <[EMAIL PROTECTED]> writes:
G> Feature Request ===
G> Could the lfun "server-notify" take an data argument, that is
G> passed on to the lyxserver?
Sure. And what about getting rid of the key binding too? Is it really
useful to the client?
JMarc
ice to have a python package for LyX support. This
could comprise
Functions and classes for lyx2lyx and tex2lyx -> lyxfiles.py
Lyxserver communication -> lyxclient.py
A python wrapper for lfuns -> lyxfuns.py
(using lyxclient.py for no
On 1.02.05, Jean-Marc Lasgouttes wrote:
>
> G> Dear developers, trying to use the lyxserver for a kind of
> G> scripting support, I came accross some troublespots.
>
> I did not have time to look seriously at all the report, but I believe
> that many of them can be tr
>>>>> "G" == G Milde <[EMAIL PROTECTED]> writes:
G> Dear developers, trying to use the lyxserver for a kind of
G> scripting support, I came accross some troublespots.
Hello Günter,
I did not have time to look seriously at all the report, but I believe
tha
On Wed, Jan 26, 2005 at 04:47:52PM +0100, G. Milde wrote:
> Dear developers,
>
> trying to use the lyxserver for a kind of scripting support, I came accross
> some troublespots.
Could you put that on bugzilla, too? Please.
Andre'
On Fri, Jan 28, 2005 at 09:01:04AM +, Angus Leeming wrote:
> > Super-glad to see Asger back into the fold. He can be a less hated me!!
> He's just got a thicker skin ;-) How the hell are you anyway?
Fine, insanity at work has mitigated into mere eccentricity. I might
even build a recent lyx s
John Levon wrote:
> Super-glad to see Asger back into the fold. He can be a less hated me!!
He's just got a thicker skin ;-) How the hell are you anyway?
--
Angus
On Thu, Jan 27, 2005 at 07:03:11PM +, Jose' Matos wrote:
> PS: In another movement (no pun John ;-) to help python scripting for lyx
Is this a test on whether I'm still listening? :)
Super-glad to see Asger back into the fold. He can be a less hated me!!
john
he lyx server via
the
python module. This is something that I wanted to do for quite some
time. :-)
> Generally, the lyxserver seems to be an a sad state mainly because noone
> seems to use it seriously. (Some of my ideas and complaints are to be
> found in examples/lyxtest.py.) If ther
Dear developers,
trying to use the lyxserver for a kind of scripting support, I came accross
some troublespots.
Sending a non existing LFUN will show Unknown Function in the status bar,
but the server returns "INFO:cname:fun" while it should IMHO return an
"ERROR:cname:fun:functio
On 19.01.05, Angus Leeming wrote:
> G. Milde wrote:
> > Dear LyXers,
> >
> > IMHO, LyX clearly lacks a decent support for a scripting language. As
> > this topic is not new but discussion about which language to choose is
> > endless, I tried to set up a s
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| | The changes I did with lyxsocket, can very well be used by the
| | lyxserver as well.
| | This patch does that.
| | So far only compiled on xforms, will test qt as well before
| | committing... I might skip on gtk.
Ok, this variant compiles
On Wed, Jul 21, 2004 at 10:58:27PM +0200, Lars Gullik Bj?nnes wrote:
> the pipe fd is registered with the qt event loop with the
> QSocketNotifier.
I thought your patch deleted all of that. OK
john
John Levon <[EMAIL PROTECTED]> writes:
| On Wed, Jul 21, 2004 at 10:02:44PM +0200, Lars Gullik Bj?nnes wrote:
>
>> | So far only compiled on xforms, will test qt as well before
>> | committing... I might skip on gtk.
>>
>> Updated a bit.
>
| Now that Qt has no notion of these pipes, how will we b
On Wed, Jul 21, 2004 at 10:02:44PM +0200, Lars Gullik Bj?nnes wrote:
> | So far only compiled on xforms, will test qt as well before
> | committing... I might skip on gtk.
>
> Updated a bit.
Now that Qt has no notion of these pipes, how will we break out of the
Qt event loop when an fd becomes r
Lars Gullik Bjønnes wrote:
> The changes I did with lyxsocket, can very well be used by the
> lyxserver as well.
>
> This patch does that.
>
> So far only compiled on xforms, will test qt as well before
> committing... I might skip on gtk.
Please don't. If you start a
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| The changes I did with lyxsocket, can very well be used by the
| lyxserver as well.
>
| This patch does that.
>
| So far only compiled on xforms, will test qt as well before
| committing... I might skip on gtk.
Updated a bit.
? Config
? c
The changes I did with lyxsocket, can very well be used by the
lyxserver as well.
This patch does that.
So far only compiled on xforms, will test qt as well before
committing... I might skip on gtk.
Please have a look.
diffstat lyxserver-1.diff
frontends/gtk/lyx_gui.C| 29
On Mon, 13 Oct 2003, Angus Leeming wrote:
> I am going to commit this patch as-is unless someone speaks up soon.
Thank you for the work on my patch, Angus. Attached is a patch for
support/Changelog registering socktools.{C,h}.
I'm going to post the manpage of lyxclient soon.
Regards,
João Lui
On Mon, 13 Oct 2003, Jean-Marc Lasgouttes wrote:
> > "Joao" == Joao Luis Meloni Assirati <[EMAIL PROTECTED]> writes:
>
> Joao> For me it is no problem, but I remember people saying that /home
> Joao> is not a good place to put fifos and sockets because it can be
> Joao> an afs or other restri
On Mon, 13 Oct 2003, Joao Luis Meloni Assirati wrote:
> Or simply
>
> ./lyxclient 'LYXCMD:file-open /home/angus/docs/transform_v2.lyx'
>
> if you have only one lyx runing, as the client will search for a running
> lyx.
Ooops... I mean
./lyxclient -c 'file-open /home/angus/docs/transform_v2.lyx
On Mon, 13 Oct 2003, Lars Gullik Bjønnes wrote:
> | It relies only in permission bits. That is, it tries all lyx_tmpdir...,
> | and stays with the first it can connect. Of course it cannot connet to a
> | socket that is under a closed directory. The socket itself is created
> | closed for other
Joao Luis Meloni Assirati <[EMAIL PROTECTED]> writes:
| On Mon, 13 Oct 2003, Lars Gullik Bjønnes wrote:
>
>> Is the check clever enough? What about multiuser boxes?
>
| It relies only in permission bits. That is, it tries all lyx_tmpdir...,
| and stays with the first it can connect. Of course it c
On Mon, 13 Oct 2003, Lars Gullik Bjønnes wrote:
> Is the check clever enough? What about multiuser boxes?
It relies only in permission bits. That is, it tries all lyx_tmpdir...,
and stays with the first it can connect. Of course it cannot connet to a
socket that is under a closed directory. The
Joao Luis Meloni Assirati <[EMAIL PROTECTED]> writes:
| On Mon, 13 Oct 2003, Angus Leeming wrote:
>
>> Pass commands to lyx:
>> ./lyxclient -a /tmp/lyx_tmpdir222460OMx2d/lyxsocket -c
>> 'LYXCMD:file-open /home/angus/docs/transform_v2.lyx'
>
| Or simply
>
| ./lyxclient 'LYXCMD:file-open /home/angus
> "Joao" == Joao Luis Meloni Assirati <[EMAIL PROTECTED]> writes:
Joao> For me it is no problem, but I remember people saying that /home
Joao> is not a good place to put fifos and sockets because it can be
Joao> an afs or other restrictive filesystem mount. So, looking at all
Joao> other progr
On Mon, 13 Oct 2003, Angus Leeming wrote:
> Pass commands to lyx:
> ./lyxclient -a /tmp/lyx_tmpdir222460OMx2d/lyxsocket -c
> 'LYXCMD:file-open /home/angus/docs/transform_v2.lyx'
Or simply
./lyxclient 'LYXCMD:file-open /home/angus/docs/transform_v2.lyx'
if you have only one lyx runing, as the
Hello,
It is good to hear about my patch...
On Mon, 13 Oct 2003, Lars Gullik Bjønnes wrote:
> | Run lyx-xforms (the patch will be in cvs in 5 mins). You'll find a
> | special file, eg /tmp/lyx_tmpdir222460OMx2d/lyxsocket
>
> Is this a good place to put the file?
> It should be placed in .lyx an
> of getting inverse dvi search working, for witch I will send a
>>> patch in my next e-mail.
>>
> | Dear Joao, I attach the patch that I am going to apply to the cvs
> | tree. It seems to work beautifully.
>>
> | I have added placeholder functions to the Qt and Gtk ve
ll send a patch
>> in my next e-mail.
>
| Dear Joao, I attach the patch that I am going to apply to the cvs
| tree. It seems to work beautifully.
>
| I have added placeholder functions to the Qt and Gtk versions of
| lyx_gui.C. The lyxserver does not work for these frontends, but at
|
e patch that I am going to apply to the cvs
tree. It seems to work beautifully.
I have added placeholder functions to the Qt and Gtk versions of
lyx_gui.C. The lyxserver does not work for these frontends, but at
least they compile.
Dear all, to try this out, compile development/lyxsocket
On Mon, Oct 13, 2003 at 11:53:40AM +0200, Andre' Poenitz wrote:
> I was about asking
'about to ask' I suppose...
Andre'
On Mon, Oct 13, 2003 at 10:26:46AM +, Angus Leeming wrote:
> Joao Luis Meloni Assirati wrote:
> > On Wed, 8 Oct 2003, Angus Leeming wrote:
> >
> >> Of course, there are lots of small coding points,
> >
> > It is not a surprise :). If there is a chance of my patch being
> > accepted, I would b
Lars Gullik Bjønnes wrote:
> | Joao Luis Meloni Assirati wrote:
>>> On Wed, 8 Oct 2003, Angus Leeming wrote:
>>>
Of course, there are lots of small coding points,
>>>
>>> It is not a surprise :). If there is a chance of my patch being
>>> accepted, I would be glad to correct them. Note also
Angus Leeming <[EMAIL PROTECTED]> writes:
| Joao Luis Meloni Assirati wrote:
>> On Wed, 8 Oct 2003, Angus Leeming wrote:
>>
>>> Of course, there are lots of small coding points,
>>
>> It is not a surprise :). If there is a chance of my patch being
>> accepted, I would be glad to correct them. No
Joao Luis Meloni Assirati wrote:
> On Wed, 8 Oct 2003, Angus Leeming wrote:
>
>> Of course, there are lots of small coding points,
>
> It is not a surprise :). If there is a chance of my patch being
> accepted, I would be glad to correct them. Note also that
> lyxclient.C is still sort of prelimi
On Wed, 8 Oct 2003, Angus Leeming wrote:
> Of course, there are lots of small coding points,
It is not a surprise :). If there is a chance of my patch being accepted,
I would be glad to correct them. Note also that lyxclient.C is still sort
of preliminary. My concern was mainly the patch.
> So
Joao Luis Meloni Assirati wrote:
> If this patch gets accepted, I will provide Changelog entries and
> also write the lyxclient manpage.
Joao, I like this a great deal. The design appears to mirror that of
LyXServer very closely which IMO is a good thing as it builds on our
existing kno
socket in the connected state and two
functions readln() and writeln() for line buffered IO.
LyXServerSocket - this class has a socket in the listening state. Each
time a new connection arrives, it allocates a new LyXDataSocket.
These are intended to substitute the lyxserver based on pipes, but
Angus Leeming <[EMAIL PROTECTED]> writes:
| On Wednesday 11 September 2002 5:01 pm, Lars Gullik Bjønnes
| wrote:
| > I am sure that this patch is ok... but it very hard to see
| > what the actuall changes are.
|
| Granted. Attached is the new read_ready function.
|
| It removes the lyxerr call
// to tell the outside world if there's anything
// in the read buffer.
break;
}
}
if (!read_buffer_.empty()) {
read_buffer_ = rtrim(read_buffer_, "\n");
lyxerr[Debug::LYXSERVER]
<< "LyXComm: Received from fd "
<< infd << '\n'
<< '\"' << read_buffer_ << '\"' << endl;
clientcb(client, read_buffer_);
}
errno = 0;
}
Angus Leeming <[EMAIL PROTECTED]> writes:
| Attached is a patch to LyXComm:read_ready that enables the
| LyXServer to work coherently with Tru64 unix. It's little more
| than a clean-up of the existing code and does not change the
| resulting string passed to the LyXServer /at al
Attached is a patch to LyXComm:read_ready that enables the
LyXServer to work coherently with Tru64 unix. It's little more
than a clean-up of the existing code and does not change the
resulting string passed to the LyXServer /at all/.
It transpires that the root of the problems lies in
On Monday 02 September 2002 3:28 pm, John Levon wrote:
> On Mon, Sep 02, 2002 at 02:55:59PM +0100, Angus Leeming wrote:
> > if (rerrno == EAGAIN) {
> > - errno = 0;
> > - return;
> > - }
> > - if (rerrno != 0)
On Mon, Sep 02, 2002 at 02:55:59PM +0100, Angus Leeming wrote:
> if (rerrno == EAGAIN) {
> - errno = 0;
> - return;
> - }
> - if (rerrno != 0) {
> + break;
> +
> + } else if
Small steps towards a pipestream...
The current implementation of the LyXServer doesn't work well under Tru64
unix. The pipes are opened and closed continually because
LyXComm::read_ready() is called from the GUI callback routine on every cycle
until the pipe first receives some input
On Monday 19 August 2002 3:45 pm, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | On Monday 19 August 2002 3:31 pm, Lars Gullik Bjønnes wrote:
> >> Remember that a socket could be stale...
> |
> | Surely the LyXServer's d-tor should delete it?
>
> In an ideal world yes..
Angus Leeming <[EMAIL PROTECTED]> writes:
| On Monday 19 August 2002 3:31 pm, Lars Gullik Bjønnes wrote:
>> Remember that a socket could be stale...
>
| Surely the LyXServer's d-tor should delete it?
In an ideal world yes but perhaps we crashed before that could
happen.
--
Lgb
On Monday 19 August 2002 3:31 pm, Lars Gullik Bjønnes wrote:
> Remember that a socket could be stale...
Surely the LyXServer's d-tor should delete it?
Angus
Angus Leeming <[EMAIL PROTECTED]> writes:
| On Monday 19 August 2002 2:30 pm, Lars Gullik Bjønnes wrote:
>> | Anyway, I'm perfectly happy to use named sockets rather than pipes, but
>> | AFAICS there is still a problem. If I'm an external program, how do I
>> | find out the /name/ of this named s
On Monday 19 August 2002 2:30 pm, Lars Gullik Bjønnes wrote:
> | Anyway, I'm perfectly happy to use named sockets rather than pipes, but
> | AFAICS there is still a problem. If I'm an external program, how do I
> | find out the /name/ of this named socket if LyX is going to have many of
> | them.
.lyx/server-socket.4634
.lyx/server-socket.PID
Every instance of LyX will only have _one_ socket.
| If the answer is obvious, /please/ tell me. I'm not proud...
>
>> | However, I take your point if you're saying that (were we to use
>> | sockets) the client would not have to
emulation...
AF_UNIX (AF_LOCAL) is just a dummy in winsock2.
However, cygwin brings the usual unix socket stuff.
> | Actually, lyxserver has never worked on
> | windows since there's no mkfifo in cygwin.
>
> ... but I do not know about named pipes.
Win32->definitely no; Cygwin->no; other posix over win32 layers->yes
Ruurd
out this info I can't even start.
If the answer is obvious, /please/ tell me. I'm not proud...
> | However, I take your point if you're saying that (were we to use
> | sockets) the client would not have to parse this message to
> | ascertain whether it was the intended
| That's not strictly true. The LyXServer can have many clients so long as they
| supply it with different clientnames. It then communicates with them by
| outputting
| LYXSRV:::
| to lyxpipe.out.
Try this:
cd /tmp
mkfifo fifo
cat fifo &
cat fifo &
echo "hello the
On Monday 19 August 2002 1:10 pm, Lars Gullik Bjønnes wrote:
> The really great benefit of named sockets/local sockets is that they
> allow multiple clients. With named pipes you can only have one client
> at a time.
That's not strictly true. The LyXServer can have many clients s
On Monday 19 August 2002 1:10 pm, Lars Gullik Bjønnes wrote:
> so you have not played with network programming?
No I'm a fluid dynamics engineer who has been picking up the language of the
computer scientist by playing with LyX.
Angus
t we should ditch pipes as well and move on to
>> > > local sockets.
>> >
>> > What about OS/2 and Windows? Do they have local sockets?
>>
>> No local sockets on Windows... Actually, lyxserver has never worked on
>> windows since there's no m
gt; local sockets.
>>
>> What about OS/2 and Windows? Do they have local sockets?
>>
| No local sockets on Windows...
I think they have local sockets on Windows...
(at least Java on Windows has LocalSocket)
| Actually, lyxserver has never worked on
| windows since there's no mkfifo in cygwin.
... but I do not know about named pipes.
--
Lgb
al sockets.
> >
> > What about OS/2 and Windows? Do they have local sockets?
>
> No local sockets on Windows... Actually, lyxserver has never worked on
> windows since there's no mkfifo in cygwin.
André's pipestream class that he posted this morning uses
ckets?
>
No local sockets on Windows... Actually, lyxserver has never worked on
windows since there's no mkfifo in cygwin.
AFAIK no one has even mailed me or Claus with questions concerning the use
of lyxserver. The windows users are probably not that demanding.
(inherantly;-) )
Ruurd
Lars Gullik Bjønnes wrote:
> >> >> I have a small socket lib that I use from time to time...
> >> >> (It works for named sockets/unix sockets/local sockets as well.)
> >> |
> >> | Isn't this just what lyxserver needs? It just sends and receives da
I use from time to time...
>> >> (It works for named sockets/unix sockets/local sockets as well.)
>> |
>> | Isn't this just what lyxserver needs? It just sends and receives dats to
>> | and from FIFO files.
>>
>> But it does not support pipes.
>
| I take
1 - 100 of 205 matches
Mail list logo
