On Monday 21 December 2009 10:53:15 Denis Arnaud wrote:
2009/12/21 Vladimir Prus vladi...@codesourcery.com
IIUC, mpi.so is a Python extension? If so, soname makes little sense for
it.
Python extensions on my system appear to have or not have soname at random.
Yes, mpi.so is a Python
Sean Chittenden wrote:
For sure it is. Debian is my primary platform and I'd like this to
be seamless. I've pondered support for multiple simultaneous
installations, possibly with a layout like this:
Because of the trickery of the loader using unresolved symlinks (for
non-statically
Denis Arnaud wrote:
2009/10/28 troy d. straszheim t...@resophonic.com
Would it be possible to have the option, with CMake build, to use a
more conventional soname, so that Linux distribution packagers
(Debianers and RPM-based packagers such as me, for instance) be
happy (i.e.,
Brad King wrote:
David Abrahams wrote:
I just realized we need a feature (surprise!)
When I'm working on a Boost library, I need to be able to fire off all
the tests of libraries that depend on the one I'm changing, to make sure
I'm not breaking anything in the library collection before I
Tan, Tom (Shanghai) wrote:
This is a re-post from the boost-users list, Thanks to Troy d.
straszheim who reminded me there that there's a dedicated list here.
I used CMake to build boost 1.39 and found at least two problems:
On Monday 11 May 2009 19:40:35 Doug Gregor wrote:
On Mon, May 11, 2009 at 6:55 AM, Vladimir Prus
vladi...@codesourcery.com wrote:
On Monday 11 May 2009 01:24:08 Beman Dawes wrote:
I'm going to experiment with pre-built binary installers, with an eye
to supplying them for the 1.40.0
On Tuesday 12 May 2009 20:50:19 Doug Gregor wrote:
On Mon, May 11, 2009 at 9:27 AM, Vladimir Prus
vladi...@codesourcery.com wrote:
On Monday 11 May 2009 19:40:35 Doug Gregor wrote:
On Mon, May 11, 2009 at 6:55 AM, Vladimir Prus
vladi...@codesourcery.com wrote:
On Monday 11 May 2009 01
On Monday 11 May 2009 01:24:08 Beman Dawes wrote:
I'm going to experiment with pre-built binary installers, with an eye
to supplying them for the 1.40.0 release.
For what platforms?
- Volodya
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
Michael Jackson wrote:
On Nov 12, 2008, at 11:39 AM, David Abrahams wrote:
on Wed Nov 12 2008, Michael Jackson mike.jackson-AT-bluequartz.net
wrote:
Came across an interesting situation while doing some testing on the
CMake build system. I configured my build tree to be SHARED+MULTI-
Janusz Piwowarski wrote:
Hi,
As in subject: first line, first character.
Fixed, thanks!
- Volodya
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Vladimir,
The patch you recently checked in:
revision 1.36
date: 2003/08/28 11:48:59; author: vladimir_prus; state: Exp; lines: +53
-18
Implement depth_first_visit variant which allows to stop the search at
certain vertices.
breaks depth_first_search by aborting before it
Hi Janusz,
Janusz Piwowarski wrote:
I found remove_vertex member for vector_as_graph isn't implemented.
It's my proposal:
Thanks!
templateclass EdgeList, class Allocator
void
remove_vertex(typename EdgeList::value_type u,
std::vectorEdgeList, Allocator g)
{
Hi Janusz,
Janusz Piwowarski wrote:
Hi all
gcc 3.2 generates warnings about implicit typename in line 313 in file
adjacency_list_io.hpp. I think either there should be EdgePrinterG,E
call or class G should be renamed to Graph, as is in the rest of
templates in this file.
Thanks for
Hi Neal,
Neal D. Becker wrote:
I'm lost with trying to use the (unreleased) program_options lib.
I have no problem to use with just command line, but I'd like to have both
command line and config file.
Here's what I tried:
try {
options_description desc(Allowed options);
Hi Paul,
Paul Hamilton wrote:
Is there a URL available for samples we could look at? Talking about
an XML
user interface description isn't something I can do in the abstract.
No URL yet. I'll setup a SourceForge project for it and post the
whitepaper. It's really not in a state where it
David Abrahams wrote:
The documentation for create_directories makes no sense. It says
only:
void create_directories( const path ph );
Precondition: ph.empty() ||
forall p: p == ph || is_parent(p, ph): is_directory(p) || !exists( p )
Postcondition: exists(ph)
David Abrahams wrote:
David Abrahams [EMAIL PROTECTED] writes:
Jeremy Siek [EMAIL PROTECTED] writes:
I seem to remember the named parameters mechanism being fragile
under VC6.
After a painstaking binary search in recent CVS states for the ICE, I
narrowed it down to:
snip
Worked
Reid Sweatman wrote:
Another option might be: create_directory_and_parents
That name is longer than create_directories although it better
describes the function.
I like create_directory_path
That one's good, and captures the essential distinction well. Other
possibles:
FYI,
I've just comitted a patch which adds the concept of 'null vertex' to BGL. If
'G' is a graph type, then
graph_traitsG::null_vertex()
will return vertex_descriptor which does not refer to any vertex. Of course,
that value is never returned by add_vertex.
I found this concept usefull
::native)
but this does not look like a solution... The real solution, IMO, would be
to make leaf() return path instance, but I don't know the rationale for
making it return string, so maybe this idea is not good. Beman, could you
comment?
And answering to Vladimir Prus on the bug report: I would
I'm pleased to announce that the next milestone release of Boost.Build V2 is
available at
http://prdownloads.sourceforge.net/boost/boost-build-2.0-m6.tar.bz2
http://prdownloads.sourceforge.net/boost/boost-build-2.0-m6.zip
See also
http://boost.sourceforge.net/boost-build2/
for
From: Alisdair Meredith [EMAIL PROTECTED]
Only *critical* fixes to the 1.30.0 release.
What about updated compiler configs? For instance, Borland released a
compiler update pretty much the same week that Boost 1.30 went out, so
several version checks fail. Any other compilers release a
Hi Csaba,
Iteration macros did not work without some 'using' directives because it
uses functions from boots but actually without the boost:: qualifier.
E.g. BGL_FORALL_VERTICES(v,g,graph_t) did not compile unless you have using
namespace boost or using namespace boost::vertices before the
Vladimir Prus wrote:
When trying to used current Boost.Test CVS HEAD state as shared libraries,
I get errors from linker:
Oops! Seems like I did not picked up changes to Jamfile. Sorry for the noise.
- Volodya
___
Unsubscribe other changes: http
When trying to used current Boost.Test CVS HEAD state as shared libraries, I
get errors from linker:
../../../libs/test/build/bin/libboost_unit_test_framework.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/libboost_unit_test_framework.so:
undefined reference to
I'm pleased to announce that the next milestone release of Boost.Build V2 is
available at
http://prdownloads.sourceforge.net/boost/boost-build-2.0-m5.tar.bz2
http://prdownloads.sourceforge.net/boost/boost-build-2.0-m5.zip
See also
http://boost.sourceforge.net/boost-build2/
for
Toon Knapen wrote:
The boost-sandbox is showing some strange behaviour.
When checking out the boost-sandbox/numeric/bindings/traits/type.h using
the :ext: server I get version 1.3 (on the HEAD), with :pserver: it's
only 1.2. The WebCVS also only shows up to version 1.2.
That's the same as
Hi Bruce,
Vladimir Prus wrote:
There's another question: why store u at all. I'm
guessing source(*ei, g) might be more efficient?
That's a good thought, but there might be a problem
trying to dereference a past-the-end iterator. I
mentioned before that ei_end could always be generated
Hi Pavol,
Pavol Droba wrote:
I'm already aware of string_algo and using it a bit. I wasn't aware it
has tokenizer component, though.
It was added only a few days ago along with some other improvements and
more stuff is comming in the near future.
Ah... the problem is that those new
Hi Bruce,
Bruce Barr wrote:
I'm glad Vladimir got me to take another look at this.
I'm submitting a new patch to replace the one
submitted on May 30.
And I'm glad you're willing to polish your patch!
There are other differences between the recursive and
nonrecursive versions that, in my
I've run into a problem using sandbox::boost/sequence_algo/algorithm.hpp.
The header uses boost::find, but that function can't really be used,
because:
1. (minor) it depends on new iterator adaptors, while I'm using sandbox with
boost CVS.
2. It's not possible to use boost::find, since, as
Hi Beman,
Beman Dawes wrote:
how can I get rid of a read only file? At present it seems to be
impossible?
Yes, at the moment it is impossible with the filesystem library.
[Warning: half-baked ideas follows. I don't even know if it is spelled
writeable or writable.]
If we can figure
Douglas Gregor wrote:
Creating new visitors in the BGL can be a pain, because it may require a
lot of extra typing for simple cases. I'd like to add the ability to attach
function objects to visitor events like this:
dfs_visitor()
.do_on_back_edge(var(has_cycle) = true)
I have a few comments regarding the tokenizer library.
1. The documentation says that char_delimiters_separator is default parameter
to 'tokenizer' template, and at the same time says that
'char_delimiters_separator' is deprecated. I think that's confusing and
default parameter should be
John Maddock wrote:
Another note is on usability. Say I create directory po and find that
some
files are missing. I tweak bcp source and try again. But attempt to
override
files fail. I remove po directory. But then bcp says the destination
does
not exist. It's a bit inconvenient ---
Pavol Droba wrote:
Hi,
I have no comment about the tokenize library, but if your are interested
in the stuff like that, you can have a look into the sandbox.
string_algo library already contains this functionality
( along with other interesting features ) and it is implemented in more
Bruce Barr wrote:
Here's a patch to depth_first_search.hpp in BGL in version 1.30.0 of boost
that implements nonrecursive depth first search. This reduces or
eliminates the problem of stack overflow that occurs with DFS in large
graphs. There also may be a performance gain in some cases.
I have just tried the tool. On the whole, it's very usefull. Thanks to John!
However, it seems to be confused by the preprocessor library. Since the
includes sometime have the form:
#include BOOST_PP_ITERATE()
the 'bcp' tool does not find them. For example,
It appears that the error reporting is a little bit less helpfull when 'char'
type is compared. I've just run the following program:
#define BOOST_INCLUDE_MAIN
#include boost/test/test_tools.hpp
using namespace boost;
int test_main(int, char*[])
{
char m1[] = {'a', 'b',
Aleksey Gurtovoy wrote:
... as per http://article.gmane.org/gmane.comp.lib.boost.devel/20648 are
available from here:
* user summary page -
http://boost.sourceforge.net/regression-logs/user_summary_page.html
* developer summary page -
I've put together a plan of post-review developement of the program_options
library --- see attachemnt. I believe it includes all issues raised. If
anybody mage a suggestion which got lost, or has any opinion on the document,
I'd be interested to know.
Thanks in advance,
Volodya
Program
Neal D. Becker wrote:
On Tuesday 17 June 2003 10:49 am, Vladimir Prus wrote:
I've put together a plan of post-review developement of the
program_options library --- see attachemnt. I believe it includes all
issues raised. If anybody mage a suggestion which got lost, or has any
opinion
Daryle Walker wrote:
In CVS, I added an example file to the CRC library. I changed the
documentation to point to the example file.
Daryle,
I see this code in the example:
do
{
ifs.read( buffer, buffer_size );
len = ifs.gcount();
John Maddock wrote:
The following two files:
boost/graph/transitive_closure.hpp
boost/graph/vector_as_graph.hpp
Use a licence that is different from any other file in boost (the closest
approximation appears to be that used by the lambda and function
libraries). Is it possible to avoid
Aleksey Gurtovoy wrote:
b) resolving the 'wchar_t' support issue before the library makes
into official Boost distribution.
I'm actually not that happy about solving general issue alone...
You don't have to. I am sure a lot of people on this list have dealt
with the issue and would
Neal,
Neal D. Becker wrote:
Does/will program options support this style:
-w1=10 -w2=20
w1 and w2 are options (with args) that act just the same as long options,
but use a single '-' instead of the usual '--'.
this style is supported already. The 'cmdline::allow_long_disguise' style
Neal D. Becker wrote:
Currently (last I tested) program options when used with variable map will
set bool options to false even though they were not specified on the
command
line. What I'd prefer is that all options be left alone unless they are
set
on the command line. I've been bitten
Neal,
Yes, that's true. All bool options implicitly have default value of
false. In fact, I think this is quite reasonable. Unless some switch is
on, it's off. This saves the user the need to check if option is present.
Could you describe how this behaviour has bitten you? There's probably a
Neal D. Becker wrote:
On Friday 06 June 2003 10:39 am, Vladimir Prus wrote:
Neal,
[...]
I can appreciate the usefulness of the current behavior, and I also
know that there is a workaround (.default_value(true)), but this only
works if you notice the unexpected behaviour!
The only
Aleksey Gurtovoy wrote:
The Command Line Config library by Vladimir Prus has been accepted
into Boost, pending the incorporation of suggestions brought up in
the review.
These are good news!
I would like to thank all the reviewers. Being the library submitter is quite
different from
William E. Kempf wrote:
there is no such thing as the 'Gnu licence'. There is the 'GNU General
Public License' (aka GPL) and the 'GNU Lesser General Public License'
(LGPL). libxml2 uses neither, and its license is fully compatible with
boost's license requirements.
Maybe, but it fails the
William E. Kempf wrote:
I tend to disagree here. Writing XML library is not easy, and libraries
like expat and libxml2 are already here, working and debugged. The
effort to write a new library from scratch would be quite serious, and
will result in anything tangible only after a lot of time.
Hi Misha,
Misha Bergal wrote:
I have 2 use cases for program options library. I would say that they are
fairly advanced but nevertheless typical ones:
Due to severe time constraints I am going to describe just the first use
case, which I think will highlight significant number of
Hi Beman,
Beman Dawes wrote:
This review is based purely on reading the documentation. The code was not
inspected and no tests were run. I also skim read some of the other review
comments.
In general, I like the library and think that it should be accepted by
Boost.
Thanks!
But there
Hi Pavol
Pavol Droba wrote:
Hi,
I have probably encountered a bug in the library. I'm not able to put
a bool option in the config file. Regardles how I specify the option
there, parsing always fails with the exception:
config file options should have required parameter
That's really a
I think that it would be handy to introduce null vertex value into BGL. For
example, I'm computing some 'alternative vertices' in some function. If no
such vertex exists, I'd like to record this fact, so that when the function
is called again on the same vertex, I don't have to do anything.
Aleksey Chernoraenko wrote:
I wrote a C++ wrapper library around libxml2 (http://xmlsoft.org/),
and would like to submit it to boost. It currently provides a DOM-like
and a SAX-like interface, is parametrized for the (possibly unicode
enabled) string type, and has already proven its value for
Hi Daryle,
Daryle Walker wrote:
[I wrote this half-asleep a few days ago. You could add things like
signals/slots, better list management, etc. Take this suggestion as a
very general guideline, not as actual code to use.]
I haven't looked at the command-line/config library under review
Hi Misha,
Misha Bergal wrote:
Alas, this comment seems non-constructive for me. I don't think that
the question is what kind of design should be promoted. What are the
problems with the current design? Can you list some interesting things
that
would be possible if config_file were an
Hi Misha,
Misha Bergal wrote:
You've missed the word directly. You can't have all possible styles
work out of the box, because the number of possible styles is infitite.
The problem with approach taken by the library is that to support the new
style the user is advised to write a custom
Hi Misha,
Misha Bergal wrote:
Vladimir Prus [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I think it's better to wait for Unicode users to formulate what's needed.
It
seems, for example, that the last approach would work better for me on
Linux.
Visual C++
int
wmain( int
David Abrahams wrote:
parameterstd::string( output )
place_to( output_file_name )
default_value( /tmp/abc )
description( output file name )
While I don't find the interface proposed by Vladimir to be offensive,
when you get a pile of function arguments of the same
Hi Misha,
Misha Bergal wrote:
Vladimir Prus [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I think the point is that you hardly want both ascii and unicode in
single program. In that case two versions of shared library can be built:
for ascii and unicode, and you will link
Gennadiy Rozental wrote:
I think the names arguments and options are as good as anything else.
It may be so. But I do not understand how the library use these terms.
Vladimir wrote:
option is (name,value) pair
argument is an command line element which is not option.
These definitions
Gennadiy Rozental wrote:
And one important point: there are only three unnamed parameters. There's
a
bunch of other things that can be configured, and they all use *named*
interface:
desc.add_options()
(output, file, output file name).default_value(/tmp/abc)
;
The
Gennadiy Rozental wrote:
Consider command line
my_prog --output=/tmp/log input.cpp
Here is the option with name output and value /tmp/log. There's also
argument input.cpp.
1. Why you named namespace progrma_options it in fact you supply both.
Because options are of a bit more
Rozental, Gennadiy wrote:
1. You store something inside class cmdline
Actually, only arguments, for the benefit of folks which might use 'cmdline'
standalone. Options are not stored there.
2. You store strings in options_and_arguments
3. You store typed values in variables_map
In my
Hi Pavol,
Pavol Droba wrote:
I have been reading the discussiong here about adding the support for
unicode.
Maybe there is a solution which would allow to have templated versions of
relevant classes AND static library in one box.
If we decide that specialization for char and wchar_t
Tanton Gibbs wrote:
I realize that header file is easy. But that approach will bit sooner or
later. It probably would be possible to supply alternative header-only
option, but that would be a lot of work. Need to find more opinions here.
BTW, if you have problems with shared libraries on
Matthias Troyer wrote:
On Tuesday, May 27, 2003, at 05:44 PM, John Torjo wrote:
- does not work for wchar_t. While this might seem silly, it's not,
since
VC allows for a TCHAR* command line string.
I have to consider this. An obvious approach would be to add template
parameter to every
Chuck Messenger wrote:
Vladimir Prus wrote:
Chuck Messenger wrote:
Vladimir Prus wrote:
Yep. This question was raised already. I think that making templates out
of all classes is *a* solution, but I'm not sure it's *the* solution.
The problem is that extensive template usage would prevent
Hi Tanton,
Tanton Gibbs wrote:
Since there have been a few emails bouncing around, I'd like to chime in
with my opinions on a few matters.
1. Static vs Shared
I would much prefer header files only instead of a shared library. Having
to deal with shared libraries are a pain on many
Pavol Droba wrote:
The only problem with current 'validator' is that it should validate
*string* and return the value. So, the example given by Tanton:
_1 = 1 _1 = 9)
would not really work --- the validator function is given a string. It's
probably possible to use 'notify' callback
Chuck Messenger wrote:
As for me, I'm a bit unsure about introducing new syntax. In this case,
I'm not sure overloading of is 100% intuitive --- one can assume that
value of magic is read from param result, for example.
OK, then how about this:
magic =
Anthony Williams wrote:
Vladimir Prus [EMAIL PROTECTED] writes:
Anthony Williams wrote:
Vladimir Prus [EMAIL PROTECTED] writes:
Shame about the NT symlinks not supported yet errors...
Hmm... I hope someone more knowledgeble about NT will implement them
someday. I even don't
Hi Gennadiy,
Gennadiy Rozental wrote:
This is not a review of the supplied library. I am not gonna discuss
docs
even though they are scarce. I almost don't mention implementation/code/
testing. I just want to express my opinion on design of the library.
Thanks for taking the time to
Pavol Droba wrote:
Ok, I think, I see now, where the point is.
The framework is separated into two layers.
L1: option level ( string and boost::any oriented, defined by
option_description ) L2: typed-paramter level ( represented by
po::parameter function )
L2 should work above the L1
Hi Neal,
Neal D. Becker wrote:
Why not a generic default validator?
Good question! I think that I planned to define specialization for common
types, like int and float in library sources, so that client code does
not have to instantinate them. As it is now, there are only specialized
version,
Chuck Messenger wrote:
* Library-managed default values
I think it good idea. Need to flesh some details a bit.
See
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Library-Mana
ged_Default_Values_-_Program_Options_Suggestion
Replace default_value() with optional 3rd arg
Gennaro Prota wrote:
I drop an idea: suppose that when there's a new
commit the CVS informs, via e-mail, the penultimate people that had
done a commit. This way I (the generic developer) can do the
following: before doing any commit check out the whole repository (in
order to have the newest
Gennaro Prota wrote:
I think this is a bit more complicated that it should be. Why don't just
create boost-wide commit emails mailing list?
Off-hand _this one_ seems more complicated, because it involves more
people than necessary and forces to keep the diffs (though just for,
say, a couple
Kevlin Henney wrote:
In article [EMAIL PROTECTED], Vladimir Prus
[EMAIL PROTECTED] writes
The principle of least astonishment can be applied in a different way. We
all know that lexical cast uses streams, and
stringstream ss( 1 );
int i;
ss i;
cout i \n;
certainly
I have quite a bunch of tests which use test execution monitor and look like
this
int test_main(int ac, char* av[])
{
test_a();
test_b();
}
and so on. There's another method, in which there's init_unit_test_suite
method, which returns a property initialized test_suite
James Curran wrote:
Vladimir Prus wrote:
The intent is to get/change the part of leaf name after the first
dot.
um.. After the FIRST dot or the LAST dot.
In Win32, james.m.curran.txt the extention is txt, not
m.curran.txt
Certainly the last. My existing code uses the last dot
Jason House wrote:
James Curran wrote:
Vladimir Prus wrote:
The intent is to get/change the part of leaf name after the first
dot.
um.. After the FIRST dot or the LAST dot.
In Win32, james.m.curran.txt the extention is txt, not
m.curran.txt
Note too that on Windows
David Abrahams wrote:
I've a very basic question for now: how to I convert *rst files in
documentation to something nice-looking, like hmtl?
ReStructuredText:
http://docutils.sourceforge.net/README.html#quick-start
Use the html.py script in the tools/ directory
Thanks, it worked. I've
Douglas Gregor wrote:
On Thursday 17 April 2003 03:50 am, Vladimir Prus wrote:
IOW, now specifying behaviour for event requires creating a new class,
with event_filter typedef and operator(). You propose to pass lambda,
immediately on dfs_visitor creation. I think this is indeed convenient
I've just tried to use the above test tool, and see the following:
svertka.driver.cpp(127): error in test_svertka: test {result.begin(),
result.end()} == {result2, ...} failed [-431600044 != -78651042]
I think this message misses one thing: the position where mismatch occured. If
Gennadiy Rozental wrote:
svertka.driver.cpp(127): error in test_svertka: test
{result.begin(), result.end()} == {result2, ...} failed [-431600044 !=
-78651042]
I think this message misses one thing: the position where mismatch
occured. If
differing values are printed, it's
Hi Maxim,
And here are the Intel VTune results (see the sources for details):
CreationAssignment
struct13383 27358
boost::any3846331870
TailoredAny
I have a simple class, which three interesting
methods:
- current
- advance
- eof
I had a custom wrapper which converts any class which such methods (and some
typedefs) and now I want to use iterator adaptors library. What is the best
approach? I can roll a new policy class, of course.
But I
David Abrahams wrote:
But I think the above set of operation is quite handy when one wants to
create a new input iterator. The wrapped class is also close to
Generator, with added 'eof' method. So, I wonder, if I should strive to
make something reusable, which can be added to the library?
Hi Doug,
Will I be able to write:
anyfast_allocator a;
values[10] = a;
?
IOW, I don't think your proposal provides any means to convert between
'any' with different allocators. And I'm not sure you can easily achieve
that
Sure you can. You just store a copy of the allocator
Hi Maxim,
I think it would be great to make boost::any's memory allocation
strategy for value holder customizable. It would allow to use not only
global new operator, but any other special fast allocators like, for
example, Loki::SmallObject.
The changes are minor and would not break
Hello,
I'm just using BOOST_CHECK_THROW tool. It works ok, but in addition to
exception type I'd like to test the value of 'what()', just to be sure. Is
there any way. Would it be possible to add another tool, which checks both
type and 'what()' content?
TIA,
Volodya
P.S. I also think there
Terje Slettebø wrote:
/home/boost/boost-regress/boost/boost/lexical_cast.hpp:173: syntax error
before `;'
Looking at the CVS, it appears the reason for this is that
config/compiler/gcc.hpp no longer defines BOOST_NO_STRINGSTREAM, even
though it should, at least for 2.95.x and below, as is
Gennaro Prota wrote:
Ok. I've forwarded this to Kevlin.
Maybe there's more than one problem here. I see that Vladimir talks
about warnings while Jeff about errors. Also maybe it helps to see the
exact condition to define BOOST_NO_STRINGSTREAM in
config/stdlib/sgi.hpp, with the comment
posted mailed
Dieter Vrancken wrote:
Ok. I'll try it again :) (sorry for the delayed reply, had some
difficulties with my newsreader)
I'm afraid the information you given is not enough, especially for
folks without access to that specific compiler. It's much better to
post (1) complete
Dieter Vrancken wrote:
Ok. I'll try it again :) (sorry for the delayed reply, had some
difficulties with my newsreader)
I'm afraid the information you given is not enough, especially for
folks without access to that specific compiler. It's much better to
post (1) complete and simple
David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
Doesn't seem to be in the archives. It's from Neal D. Becker 10 Mar
2003. Here is the entire message:
I really appreciate the boost rpms that have been made available. I
hope we
can improve one thing in the upcoming
1 - 100 of 189 matches
Mail list logo
