Re: [boost] install boost_1_34_1 on fedora (keren hochman)

From: ÐË ·ë (fxhnkf_at_[hidden])
Date: 2008-09-02 05:14:15

Dear keren hochman:
        i think you might make the wrong command path.If you take care you may notice the path of bjam in your make error is "./tools/jam/src//bjam", see too slash before bjam.
        Hava a nice day:)
  

boost-request_at_[hidden] дµÀ£º
  Send Boost mailing list submissions to
boost_at_[hidden]

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.boost.org/mailman/listinfo.cgi/boost
or, via email, send a message with subject or body 'help' to
boost-request_at_[hidden]

You can reach the person managing the list at
boost-owner_at_[hidden]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Boost digest..."

The boost archives may be found at: http://lists.boost.org/MailArchives/boost/

Today's Topics:

1. install boost_1_34_1 on fedora (keren hochman)
2. Re: [log] filtering performance (Andrey Semashev)
3. Re: [interprocess][process] Synchronizing libraries and
efforts (+ bugs) (Ion Gazta?aga)
4. Re: [interprocess][process] Synchronizing libraries and
efforts (+ bugs) (Ion Gazta?aga)

----------------------------------------------------------------------

Message: 1
Date: Mon, 1 Sep 2008 18:10:21 +0300
From: "keren hochman" 
Subject: [boost] install boost_1_34_1 on fedora
To: boost_at_[hidden]
Message-ID:
<290181000809010810t4752a609s536c965814f9f504_at_[hidden]>
Content-Type: text/plain; charset=ISO-8859-1

Im trying to install boost_1_34_1 on fedora (reference to
http://www.boost.org/doc/libs/1_36_0...-boost-library
)
But after make install i receive the following error message:

bin/sh: ./tools/jam/src//bjam: No such file or directory
Not all Boost libraries built properly.

Could anyone advise me ?

------------------------------

Message: 2
Date: Mon, 01 Sep 2008 19:25:25 +0400
From: Andrey Semashev 
Subject: Re: [boost] [log] filtering performance
To: boost_at_[hidden]
Message-ID: <48BC0965.5040904_at_[hidden]>
Content-Type: text/plain; charset=ISO-8859-1

Igor Nazarenko wrote:
> It seems that the library does quite a bit of work before filtering
> away a record, unless the logging is turned off entirely. There's at
> least two mutex locks, some memory allocation, etc. Callgrind claims
> ~2500 instructions when the record is thrown away by the global
> severity filter. Shortened callgrind output is in-line below; full
> output and the test program attached. Compiled by gcc 4.2.3 using
> boost.build variant=release threading=multi.

Although I didn't extensively profile the code, I believe that is quite
possible.

------------------------------

Message: 3
Date: Mon, 01 Sep 2008 17:44:56 +0200
From: Ion Gazta?aga 
Subject: Re: [boost] [interprocess][process] Synchronizing libraries
and efforts (+ bugs)
To: boost_at_[hidden]
Message-ID: <48BC0DF8.10804_at_[hidden]>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed

Boris wrote:
>> -> Using named pipes has been problematic because it returns errors 
>> when launching multiple processes aggressively: Error 231 - All Pipes 
>> are Busy. This does not happen with anonymous pipes and I think it has 
>> some relationship with the guid code. By the way, I think a uuid 
>> library is too much to create a unique identifier to be shared with 
>> the child a simple atomic count would to the job in my opinion. That 
>> would reduce Boost.Process dependencies.
> 
> An atomic count might not be sufficient as it would be unique only per 
> process. As I used Boost.Uuid only for convenience though I'll replace 
> it with an atomic count plus a random number to drop the dependency.

The PID of the parent plus an atomic count wouldn't be enough?

>> -> systembuf::close() should call sync() to push the last charaters 
>> into the pipe, othewise, characters are lost if the user does not 
>> flush the stream.
> 
> Changed (in postream::close()).

I think we must change this in systembuf, because a user might use the 
streambuf directly and it would be surprised to see that unlike 
std::filebuf, already written characters are missed.

Regards,

Ion

------------------------------

Message: 4
Date: Mon, 01 Sep 2008 17:52:52 +0200
From: Ion Gazta?aga 
Subject: Re: [boost] [interprocess][process] Synchronizing libraries
and efforts (+ bugs)
To: boost_at_[hidden]
Message-ID: <48BC0FD4.8010200_at_[hidden]>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed

Boris wrote:
> On Sun, 31 Aug 2008 23:20:10 +0200, Ion Gazta?aga 
> wrote:
> 
>> [...]I understand async I/O should be tied with ASIO. I think 
>> Boost.Iostreams
> 
> To give you an idea how asynchronous I/O with Boost.Process and 
> Boost.Asio currently looks like:
> 
> boost::process::child child; // somehow launched
> #if defined(_WIN32)
> boost::asio::windows::stream_handle out(io_service, 
> child.get_stdin().handle().release());
> boost::asio::windows::stream_handle in(io_service, 
> child.get_stdout().handle().release());
> #else
> boost::asio::posix::stream_descriptor out(io_service, 
> child.get_stdin().handle().release());
> boost::asio::posix::stream_descriptor in(io_service, 
> child.get_stdout().handle().release());
> #endif
> in.async_read_some(...);

I don't know ASIO but it's a shame that it does not offer a portable 
interface for async I/O.

>> [...]I can wait ;-) Since you are working hard on the library, I think 
>> it's better to wait until you consider the library mature enough. Feel 
>> free to contact me if you have any question.
> 
> OK, I'll tell you once I'm done (as I said I expect until mid 
> September). The code is nearly done. But with all the changes which I 
> had to merge I definitely need to update the documentation and samples.

Ok.

> By the way, I would be very interested in a communication channel 
> between a parent and a child process based on Boost.Interprocess. I need 
> asynchronous I/O though. Before I picked up Boost.Process I had created 
> a Boost.Asio extension boost::asio::shared_memory which can be used like 
> boost::asio::socket. The only (but big :) problem I haven't solved yet 
> is how to handle more than one communication channel. As read/write 
> operations in Boost.Interprocess need to be synchronized the calls might 
> block. A parent process with many children will then have to use at 
> least one thread per child. What would be required is a demultiplexer 
> which would work like select() for file descriptors. Then I think 
> asynchronous I/O could be done with Boost.Interprocess. The question is 
> though what would that demultiplexer look like? You are not working on 
> supporting asynchronous I/O in Boost.Interprocess? ;)

I don't have much idea about async I/O but we can try to write something 
once we know what we need. I might be completly wrong but 
boost::interprocess::shared_memory_object is based on a file descriptor 
(shm_open in unix and a plan file on windows) so we can just obtain the 
handle and see if select() and WaitForMultipleObject() work on them. 
After all, write() should work on UNIX with a shared memory object 
descritor.

Regards,

Ion

------------------------------

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

End of Boost Digest, Vol 2293, Issue 3
**************************************

       
---------------------------------
 ÑÅ»¢ÓÊÏ䣬ÄúµÄÖÕÉúÓÊÏ䣡