Hi Alain,
Thanks for doing this. I already fixed other obsoleted calls in the past and
would thus suggest to apply this patch
Matthias
On Oct 7, 2014, at 00:58, Alain Miniussi alain.miniu...@oca.eu wrote:
Hi
We have a few places where we are using 1.1 stuuf that have been obsoleted
Hi,
In orders to use MPI in a multi-threaded environment, even when only one thread
uses MPI, you need to request the necessary level of thread support in the
environment constructor. Then you'd an check whether your MPI implementation
supports multi threading. Note that using MPI the way you
On Feb 13, 2014, at 17:44, MM finjulh...@gmail.com wrote:
On 13 February 2014 15:33, Matthias Troyer tro...@phys.ethz.ch wrote:
Hi,
In orders to use MPI in a multi-threaded environment, even when only one
thread uses MPI, you need to request the necessary level of thread support
On 14 Oct 2013, at 10:53, MM finjulh...@gmail.com wrote:
Hello
In a problem of getting the maximum of a multi-variable function, I would use
mpi::reduce and provide it with a function object that compares the
evaluations of this function.
Each process evaluates a part of the space, ie a
.
On Mon, 2012-12-31 at 23:05 +0100, Matthias Troyer wrote:
On Dec 4, 2012, at 10:53 AM, Alain O Miniussi alain.miniu...@oca.eu wrote:
On Thu, 2012-11-29 at 12:55 -0500, Jeremiah Willcock wrote:
On Thu, 29 Nov 2012, Matthias Troyer wrote:
On Nov 29, 2012, at 5:23 PM, Jeremiah Willcock
On Dec 4, 2012, at 10:53 AM, Alain O Miniussi alain.miniu...@oca.eu wrote:
On Thu, 2012-11-29 at 12:55 -0500, Jeremiah Willcock wrote:
On Thu, 29 Nov 2012, Matthias Troyer wrote:
On Nov 29, 2012, at 5:23 PM, Jeremiah Willcock jewil...@osl.iu.edu wrote:
Another issue with MPI versions
Dear Robert,
I'm also impressed by how much effort you have invested and am working
myself through the documentation now. I will have a number of questions
regarding your resolution of some of my concerns from the last review,
and wonder whether I should send you the list in private or openly
On Friday, August 8, 2003, at 12:21 PM, David Abrahams wrote:
Matthias Troyer [EMAIL PROTECTED] writes:
Dear Boosters,
Since some of the applications and libraries we plan on releasing soon
rely on Boost features and bugfixes that are in the CVS but not in
Boost 1.30.[012] I wonder what
Dear Boosters,
Since some of the applications and libraries we plan on releasing soon
rely on Boost features and bugfixes that are in the CVS but not in
Boost 1.30.[012] I wonder what the plans are for the Boost 1.31.0
release? Since we would prefer to base our released software on a Boost
Dear Boosters,
We have found several problems with Boost when porting our codes to IBM
Power4 systems and to several Linux variants:
The first two patches (patch1, patch2) that are attached define some
missing static const data members that were declared in the Boost
random library but not
On Tuesday, July 29, 2003, at 07:13 PM, David Abrahams wrote:
Matthias Troyer [EMAIL PROTECTED] writes:
Finally in the new version of graph_properties.hpp there is an #ifdef
that spans three lines (line 165). Could some please make this into a
one-line #ifdef. (patch4 is a crude version, what
Dear Boosters, dear Jens,
After some debugging I realized another bug in the new version of the
Boost random number library. uniform_real has the following operator():
result_type operator()(Engine eng) { return eng() * (_max - _min) +
_min; }
This does not work if the underlying engine
Dear Jens, dear Boosters,
Some of the new distributions in the Boost random library no longer
work with floating point based generators. Could Jens or somebody fix
that? I myself am reluctant to provide a fix.
Here is a test program that fails to compile now:
#include boost/random.hpp
int
Dear Boosters,
In trying to port my codes and boost to an IBM Regatta (Power-4)
massively parallel machine, I encountered compilation problems like the
following that I cannot solve when compiling with IBM's xlC C++
compiler. Can anyone provide some insight or should I forget about the
IBM
On Tuesday, July 15, 2003, at 07:31 AM, David Abrahams wrote:
Matthias Troyer [EMAIL PROTECTED] writes:
Sorry, Here is an example that shows the problem in a simple case:
#include boost/graph/adjacency_list.hpp
#include iostream
int main()
{
boost::adjacency_listboost::vecS,boost::vecS,boost
Dear Boosters,
Since the update of the iterator adaptor library broke boost
multi_array (or at least my CVS version of it), I tried to fix it and
came up with the patch below which makes my codes compile again. Since
I do not have documentation of the new version of the iterator adaptors
Hi,
I now get the following compile-time error on MacOS X using g++ v. 3.1:
/Users/troyer/src/boost/boost/iterator/iterator_adaptor.hpp:282:
`sizeof'
applied to incomplete type `boost::STATIC_ASSERTION_FAILUREfalse'
Can anybody help?
Matthias
On Monday, July 14, 2003, at 11:04 PM, David Abrahams wrote:
Matthias Troyer [EMAIL PROTECTED] writes:
I do not have documentation of the new version of the iterator
adaptors (either my CVS checkout is messed up or maybe it is not in
the CVS yet)
http://tinyurl.com/gv90
http://tinyurl.com/gv91
I
On Monday, July 14, 2003, at 11:04 PM, David Abrahams wrote:
Matthias Troyer [EMAIL PROTECTED] writes:
I now get the following compile-time error on MacOS X using g++ v.
3.1:
/Users/troyer/src/boost/boost/iterator/iterator_adaptor.hpp:282:
sizeof'
applied to incomplete type
`boost
On Wednesday, May 28, 2003, at 01:08 PM, John Maddock wrote:
The undefind reference comes from posix_api.o . I guess that
s_match_vtable is not used in that file.
You bet it is, you would get the unresolved external if it wasn't
being used
:-)
On MacOS X using g++ version 3.3 in addition to the
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 class, telling which char type to
Dear Boosters,
After a cvs update I am having probles compiling cregex.cpp on an Intel
Linux platform with the KC compiler. The problem seems to be an
ambiguity in a call to destroy(..). While this is probably a bug in the
KCC compiler, I would appreciate a workaround (e.g. changing the name
Dear Boosters,
Mario Rueti, a student in my group, needed and wrote the following
function objects which seem to be missing in the standard library (only
arithmetic and logical operations seem to be defined as function
objects). Since these might be of more general interest we wonder if
they
On Friday, March 21, 2003, at 09:05 PM, David Abrahams wrote:
Matthias Troyer [EMAIL PROTECTED] writes:
When trying to compile the filesystem library with KAI C++ we
encounter a problem in
boost/type_traits/is_base_and_derived.hpp
Uh, wait...
It seems that the workaround is needed also for KCC
Can you elaborate as to what the difference between Box-Muller and the implemented method is? As far as I understand Box-Muller it is just the implemented algorithm.
On Wednesday, February 12, 2003, at 09:30 AM, Lapshin, Kirill wrote:
Hello all,
We've noticed that normal_distribution using
On Wednesday, February 5, 2003, at 12:55 AM, Beman Dawes wrote:
At 05:06 PM 2/4/2003, Matthias Troyer wrote:
I have run the regression tests on a Cray SV1 system using the Cray
C++
3.6 compiler and posted the results on
http://www.comp-phys.org/boost/cs-sn9626.html
Why don't you consider
On Wednesday, February 5, 2003, at 02:56 PM, Jeff Garland wrote:
The lack of support of standard library functions associated with
long long is a problem on other platforms and other functions (eg:
std::abs). This has been a headache for me using the int64_t in
date-time.
So I presume that the
On Wednesday, February 5, 2003, at 11:42 AM, Samuel Krempp wrote:
Le mer 05/02/2003 à 10:27, Matthias Troyer a écrit :
It seems that on all Crays the macros CRAY and cray are defined. If
one
wants to be machine specific, we got this information recently:
On Wednesday, January 22, 2003
On Wednesday, February 5, 2003, at 04:24 PM, Dave Abrahams wrote:
On Wednesday, February 05, 2003 10:11 AM [GMT+1=CET],
Matthias Troyer [EMAIL PROTECTED] wrote:
I am looking into it but already have a conjecture. When using signed
64 bit integers the Cray compiler (with optimization turned
On Wednesday, February 5, 2003, at 08:22 PM, Dave Abrahams wrote:
On Wednesday, February 05, 2003 2:04 PM [GMT+1=CET],
Matthias Troyer [EMAIL PROTECTED] wrote:
Actually there were two problems. One was the one you mentioned above.
The other was that we needed either a masking to 32 bits
Hi Dan,
Thanks for your input regarding the Cray X1. My efforts to port my
codes to Cray vector machines are aimed at using an X1 in the future,
and I use our SV1 machines at this time mainly to sort out problems,
to vectorize my codes and for first tests.
On Wednesday, February 5, 2003, at
On Wednesday, February 5, 2003, at 04:52 PM, Toon Knapen wrote:
On Wednesday 05 February 2003 10:27, Matthias Troyer wrote:
After we get the regrssion tests to work, there will be a special
challenge for ublas or MTL-3: Calling the BLAS routine where
appropriate will be essential in getting any
Yes, Emily Winch was working on this, and I thought she was going to
submit to boost. The following URL has a paper she wrote about this.
http://www.oonumerics.org/tmpw01/schedule.html
I can't access that file. Is there a server problem or has it moved?
On Sunday, February 2, 2003, at 05:36 PM, Beman Dawes wrote:
At 05:37 PM 2/1/2003, Matthias Troyer wrote:
On Saturday, February 1, 2003, at 10:49 PM, Beman Dawes wrote:
At 12:39 PM 2/1/2003, Matthias Troyer wrote:
cat regress.log | $process_jam_log
---
cat regress.log
On Monday, February 3, 2003, at 06:20 PM, Emily Winch wrote:
On Mon, 2003-02-03 at 08:02, Matthias Troyer wrote:
Yes, Emily Winch was working on this, and I thought she was going
to
submit to boost. The following URL has a paper she wrote about
this.
http://www.oonumerics.org/tmpw01
On Monday, February 3, 2003, at 04:37 PM, Beman Dawes wrote:
At 03:10 AM 2/3/2003, Matthias Troyer wrote:
prompt$
../tools/regression/build/bin/process_jam_log/cray/release/
process_jam_log
Usage: bjam [bjam-args] | process_jam_log [locate-root]
locate-root is the same as the bjam
Dear Boosters,
Since we got to work jam on the Cray, found an optimizer bug when
compiling regex with -O3 that we will report to Cray and got regex to
compile at -O2, I am now running the regression tests.
While they are running I want to ask a question about building and post
a
On Saturday, February 1, 2003, at 10:49 PM, Beman Dawes wrote:
At 12:39 PM 2/1/2003, Matthias Troyer wrote:
cat regress.log | $process_jam_log
---
cat regress.log | $process_jam_log $boost_root
...
Finally, I wonder why I need the sixth change. How does this work on
other platforms
Hi Dan,
I don't think this will be needed since on the X1 USHRT_MAX should be
0x, and thus the default version will work. Note that the patch for
the SV1 and other Crays that I submitted checks for USHRT_MAX being
0x and thus does not apply on the X1 anyways.
On another note, I
Hi,
I have now run the regression tests on a Cray SV1 but it seems there is
still a problem in the postprocessing stage. I get output like:
generating html tables:
Using /u/ph/troyer/boost/status/bin/bind_test.test to determine
compilers
Missing jam_log.xml in target
Matthias Troyer [EMAIL PROTECTED] writes
I tried to run the boost regression test but the first
problem I encountered is that jam does not seem to work
on a Cray machine:
athos: sh ./build.sh cc
...
./bootstrap.cc/jam0 -f build.jam --toolset=cc --toolset-root=
./build.sh[3]: 48150 Floating
Thank you very much!
Now the Cray people just need to find the jam problem, and I will be
able to test more.
On Wednesday, January 22, 2003, at 01:13 PM, John Maddock wrote:
While I am still working on these three issues, I could solve the
problem with cstdint.hpp. and have attached a context
Dear Boost Jamers,
Our local Cray adminstrators (Bruno Loepfe from ETH and Olivier Byrde
from Cray) found a bug in the boost jam sources. it is in the file
hash.c:
char *b = (*data)-key;
int keyval;
.
keyval = *b;
while( *b )
keyval =
On Saturday, January 18, 2003, at 12:55 PM, John Maddock wrote:
If you can test and supply patches they would be much appreciated,
come to
that, I don't suppose you would like to volunteer to regularly run the
regression tests on that platform would you (no problem if you can't
though)?
On Monday, January 20, 2003, at 04:51 PM, David Abrahams wrote:
One other thing worth checking if you can't get a stack trace easily:
./bootstrap.cc/jam0 -d12
You may get enough useful output for us to track down the problem.
Here is is. I will send a stack trace as soon as I can get it. I
This did not help but I'm getting closer. I don't have a full trace
back but the debugger tells me that it happens in line 99 of file
hash.c:
char *b = (*data)-key;
Since the problem vanishes when I turn off optimization (-O0), I'm not
sure whether it is a compiler or jam bug. I will forward
I still have three problems with Cray C++ v. 3.6, but got some parts to
compile. They are:
i) a problem with template instantiation - here it seems that the
compiler might not be correctly installed on our system and I will talk
to the Cray engineers.
ii) static assertions do not work
iii) in
Dear Boosters,
All of our codes are now built on top of boost. Since we might use Cray
vector computers more in the future (finally they provides a
standard-conforming C++ standard library in release 3.6) we started
porting our codes to the Cray. I did not run the full test suite, but
just
On Saturday, January 18, 2003, at 07:36 PM, Daniel Yerushalmi wrote:
SNIP
I'll try to do it at least once to see which parts of boost we can use,
and see how much CPU time this gobbles up. If it is not too much, I
will talk to our sysadmins if they would allow me to do it about once a
month. I
On Saturday, January 18, 2003, at 10:33 PM, David Abrahams wrote:
ii) the fast vector units do not help anything for compiling the code.
Just one question: why the heck don't they make a cross-compiler which
runs on a machine better-suited to compilation?
They have that, but it costs extra
A couple more questions.
I'm afraid I don't have the time or expertise to create a full C++
compiler (tho it would be interesting to try using Spirit). If I were
to
base a reflection framework on PDT, its parser and toolset comes as
binaries for the following platforms:
alpha
apple
hp9000s700
On Wednesday, December 18, 2002, at 05:03 PM, Robert Ramey wrote:
From: Matthias Troyer [EMAIL PROTECTED]
templateclass Archive
void save(Archive ar, T t)
{
ar member1;
...
}
Here we have a problem as far as I can see: if the class is
polymorphic, how can I serialize the derived class
Dear Robert,
thanks for your comments to my posting
On Tuesday, December 17, 2002, at 06:58 PM, Robert Ramey wrote:
From: Matthias Troyer [EMAIL PROTECTED]
5) Versioning: [snip]
overhead for version number is 1 or 2 bytes per class definition.
tracking the classes so far serialized
Beman Dawes wrote:
A large number of changes to the Filesystem Library have been committed
to the CVS main trunk.
Hi Beman,
In a couple of hours I changed all our codes that depend on
boost::filesystem. Although I did not perform a through review, I had
no problem using the library. I found
Dear Serialization-Boosters,
In the past weeks I have been to busy at work to contribute much to the
serialization debate, but I managed to find some time now. It seems to
me that the discussion is drifting too far into semantic debates and I
would like to refocus by proposing to split the
On Monday, December 16, 2002, at 06:41 PM, Beman Dawes wrote:
At 12:12 PM 12/16/2002, Glen Knowles wrote:
I think what he might be asking for is something like:
make /my/full/path relative to /my/base/dir produces ../../full/path
Ah... Thanks...
The practical problem is determining if two
On Friday, November 29, 2002, at 06:32 PM, Robert Ramey wrote:
Two suggestions *I think* have been made.
1) that the serialisation library recommends to users who want
portable
archives, should use the boost::int*_t types instead of short, int,
etc.
This would only be applicable to binary
On Wednesday, November 27, 2002, at 06:05 PM, Kevin Lynch wrote:
Michael Walter wrote:
If a library user wants his archives to be portable he has to use
int8_t, int16_t, etc..
I don't remember seeing this pointed out, so forgive me if I just
missed it or am just stating the obvious, but:
* A serialization of bool is missing - easy to fix
I don't understand what you mean. basic_[i|o]archive contain:
Sorry, I missed that because it is separate from the other virtual
functions and not implemented in the b[io]archive class on which I
based my XDR implementation.
* The code
On Tuesday, November 26, 2002, at 03:01 AM, Robert Ramey wrote:
Date: Mon, 25 Nov 2002 10:41:17 +0100
From: Matthias Troyer [EMAIL PROTECTED]
I guess this should be changed to:
#ifdef BOOST_HAS_MS_INT64
virtual basic_iarchive operator(int64_t _Val) = 0;
virtual basic_iarchive operator
On Friday, November 22, 2002, at 03:33 PM, Wesley W. Terpstra wrote:
* Some approaches, including XML, allow a practically unlimited
number of
different ways to represent the same data. The user rather than the
serialization library should choose the particular design.
XSLT will allow this. As
I have started using the boost filesystem library in our application
codes and encountered a problem that could be solved by adding either
of the three functions
bool is_relative() const;
bool is_absolute() const;
void make_absolute();
to the path class.
Let me motivate this by an example: if
After spending more time with the serialization library, implementing
an archive
for the XDR format and considering how I could read my old archive
files using this
library instead of my own one, I can now give a more detailed review of
the
serialization library. I will keep those parts that
On Sunday, November 24, 2002, at 06:40 PM, Robert Ramey wrote:
5.5 Superfast I/O
There have been requests to add more primitive virtual functions to
basic_[i|o]archive in order to permit increased efficiency.
Specifically,
the idea is to add for each primitive type a virtual function to
On Wednesday, November 20, 2002, at 01:42 PM, Gennadiy Rozental wrote:
[Issue 3] Library seems to hardcode important part of functionality
that
users may want to overwrite. Here I refer in most part to
archive/object
preamble.
Major [Issue 3]: Submitted library is somewhat limited in a
On Tuesday, November 19, 2002, at 06:22 AM, David Bergman wrote:
Hi,
This is a comment from the Java corner of the world: I have, as many
other developers using Java, implemented serialization of objects onto
XML. It is not that hard, although there might not exist (can anyone
verify this?) a
On Tuesday, November 19, 2002, at 04:32 AM, Robert Ramey wrote:
Date: Mon, 18 Nov 2002 08:19:28 +0100
From: Matthias Troyer
overriding the very general template definiations above for this
special case would result in
templateclass T
inline boost::basic_iarchive operator(boost
On Sunday, November 17, 2002, at 07:22 AM, Robert Ramey wrote:
From: Matthias Troyer [EMAIL PROTECTED]
Imagine I use a platform where long is
64-bit, write it to the archive and then read it again on a platform
where long is 32-bit. This will cause major problems.
Suppose you have a number
On Sunday, November 17, 2002, at 10:49 PM, Dave Harris wrote:
In-Reply-To: [EMAIL PROTECTED]
On Sun, 17 Nov 2002 10:19:23 +0100 Matthias Troyer
([EMAIL PROTECTED]) wrote:
It can cause troubles, since for my portable codes I use int64_t or
int32_t to be portable. In order for the library
On Monday, November 18, 2002, at 05:54 AM, Robert Ramey wrote:
From: Jeff Garland [EMAIL PROTECTED]
If there are technical reasons why the library cannot be extended to
do this than I would definitely vote to reject. It sounds like that's
what you and Robert are saying, but I don't
70 matches
Mail list logo
