On Thursday 12 September 2002 11:31 pm, Lars Gullik Bjønnes
wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | ...and a clean interface to boot.
> |
> | So Lars might say where's the socketstream, but this has
> | been a real struggle and I'm now officially happy.
>
> Ok then... sit on this u
Angus Leeming <[EMAIL PROTECTED]> writes:
| ...and a clean interface to boot.
|
| So Lars might say where's the socketstream, but this has been a
| real struggle and I'm now officially happy.
Ok then... sit on this until 1.4.0cvs begins and then we'll take the
serious look at it.
--
pipes used for communication between programs.
* Rewritten (simplified?) by Angus Leeming for use with pipestream.
*/
#ifndef PIPECOMM_H
#define PIPECOMM_H
#ifdef __GNUG__
#pragma interface
#endif
#include "fdmonitor.h"
#include // for ios_base::openmode
class PipeComm {
public:
///
e
On Thu, Nov 08, 2001 at 12:50:53PM +0100, Jean-Marc Lasgouttes wrote:
> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> Works well with compaq cxx 6.2 in strict_ansi mode. If I switch to
> 'super fussy' mode, I get:
>
> cxx: Info: pipestream.C, line 158: conversion to integral typ
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Works well with compaq cxx 6.2 in strict_ansi mode. If I switch to
'super fussy' mode, I get:
cxx: Info: pipestream.C, line 158: conversion to integral type of smaller
size could lose data
int_type rval = ::read(sock_,
On Wed, Nov 07, 2001 at 10:30:31AM +0100, Lars Gullik Bjønnes wrote:
> How hard would it be to have
>
> pipestream(char const * const cmd);
>
> as the signature, and split it into arguments inside the create
> method?
Not really hard, but we can't use arguments
On Tue, Nov 06, 2001 at 09:22:58PM +0100, Lars Gullik Bjønnes wrote:
> | class pipestream : public std::iostream {
> | public:
> | /// constructor taking the external command as argument
> | explicit pipestream(char const * const cmd[]);
> | /// constructor taking the e
class pipestream : public std::iostream {
public:
/// constructor taking the external command as argument
explicit pipestream(char const * const cmd[]);
/// constructor taking the external command as argument
explicit pipestream(char const * const cmd
On Tue, Nov 06, 2001 at 06:16:20PM +0100, Andre Poenitz wrote:
> The problem is probably to find the right executable...
man execvp - we should reasonably expect the prog to be on the path.
I don't see why we need /bin/sh, and it's definitely a bad idea ...
john
--
"The Internet is a shallow
; | if (::socketpair(AF_UNIX, SOCK_STREAM, 0, sockets) == -1) {
> | error("pipestream: socketpair");
> | return 0;
> | }
> |
> | pid_t pid = vfork();
>
> Why vfork?
I don't know. Do you (or somebody else) mind fixing the rema
On Tue, Nov 06, 2001 at 05:06:44PM +, John Levon wrote:
> > Actually I like this variant using unix sockets a lot better...
> > pipes are unidir so you need two...
> >
> > With unix sockets you only need one.
>
> so why does it use socketpair ?
Did I mention that I've never seen sockets bef
On Tue, Nov 06, 2001 at 06:02:33PM +0100, Lars Gullik Bjønnes wrote:
> Actually I like this variant using unix sockets a lot better...
> pipes are unidir so you need two...
>
> With unix sockets you only need one.
so why does it use socketpair ?
john
--
"The Internet is a shallow and unrelia
On Tue, Nov 06, 2001 at 04:03:34PM +, John Levon wrote:
> On Tue, Nov 06, 2001 at 11:50:57AM +0100, Andre Poenitz wrote:
>
> > PS: Btw, I am now using yesterday's pipestream in my own (2.95 based)
> > project and it is really cute... I got rid of most of the "
On Tue, Nov 06, 2001 at 11:50:57AM +0100, Andre Poenitz wrote:
> PS: Btw, I am now using yesterday's pipestream in my own (2.95 based)
> project and it is really cute... I got rid of most of the "system
> interface" stuff ;-)
why is it using sockets instead of child-par
So it looks like we have a working pipestream for 2.95 and 3.0.
What about the more exotic ones?
Andre'
--
André Pönitz .. [EMAIL PROTECTED]
/* This file is part of
* ==
*
* LyX
On Tue, Nov 06, 2001 at 04:21:40PM +0100, Andre Poenitz wrote:
> On Tue, Nov 06, 2001 at 02:07:36PM +, Jose Abilio Oliveira Matos wrote:
> > pipestream.C: In constructor pipestream::pipestream(const char*)':
> > pipestream.C:263: class pipestream' does not
On Tue, Nov 06, 2001 at 02:07:36PM +, Jose Abilio Oliveira Matos wrote:
> pipestream.C: In constructor pipestream::pipestream(const char*)':
> pipestream.C:263: class pipestream' does not have any field named ios'
> pipestream.C:264: no matching function for call to
ovalis:~]$g++ -c pipestream.C
[14:03][jamatos@novalis:~]$g++3 -c pipestream.C
pipestream.C: In constructor pipestream::pipestream(const char*)':
pipestream.C:263: class pipestream' does not have any field named ios'
pipestream.C:264: no matching function for call to
std::basic_iostr
essor
*
* Copyright 2001 The LyX Team.
*
* == */
#ifndef PIPESTREAM_H
#define PIPESTREAM_H
#include
class pipestream : public std::iostream {
public:
/// constructor taking the external command as argument
exp
On Mon, Nov 05, 2001 at 07:57:47PM +0100, Lars Gullik Bjønnes wrote:
> | So either we provide two pipestream implementations (one for "old g++"
> | and one for "Standard C++") or we have to leave it. Forcing efverybody to
> | upgrade is certainly not an opt
supposed
> to live.
Ok, I fear it is not easily fixable at all. It's old g++ stuff all over
the place and the differences to g++3.0/Standard C++ are pretty large.
So either we provide two pipestream implementations (one for "old g++"
and one for "Standard C++") or we hav
21 matches
Mail list logo
