- Boost - lists.boost.org

Re: [boost] [ublas] Patch for GCC 3.4
by Giovanni Bajo 04 May '04

04 May '04

[copied to the Boost mailing list] Michael Stevens wrote: > I noticed you posting a month ago and I was hoping Joerg Walter would > answer your query. I have been helping Joerg maintain uBLAS since the > end of last year. Sadly Joerg has been of the ublas-dev list for > quite some time now and I have been unable to contact him. In the > meantime I am keeping up the maintenance of the separate ublas-dev > CVS. > However I do not have Boost CVS commit access so I am unable to > propagate these changes. The ublas-dev CVS has a couple of rather > recent changes which need further testing before reaching Boost. > However the GCC 3.4 problem I think is important enough that it > should be fixed now. > I therefore want to ask you the favour of committing the attached > patch. This fixes all the missing typename's which occur in several > files. It also adds test7 to the regression tests. This shows up a > bug in VC7.1 which I am hoping Microsoft will address. OK, I'm committing this patch to the CVS trunk on your behalf. > If this goes well I would also like to ask you to add a set for > Jamfiles for BBv2 that are now a part of ublas-dev. Would that be OK? I do not have problems in doing this, but if you are maintaining uBLAS, I think it is worth you to do this *officially*, and get CVS write access. Asking on the Boost list would be a way to accomplish this. Giovanni Bajo

1 0

RE: [boost] Re: Using Serialization for binary marshalling
by Brian Braatz 03 May '04

03 May '04

"""""""""" > Now, as you rightly point out, CDR does provide for efficient binary > representation of C++ primitive types. I can see that some people > might prefer to use CDR as an on-wire format for communication between > equivalent systems, so this certainly is a candidate for complete C++ coverage. > > This is complicated, however. If you were to allow full C++ > serialization into a CDR archive, the result would be portable but not > conformant to any standard or protocol, since it relied on the > serialization library's object serialization method. Only another > user of the serialization library could recover the serialized data. Unless I'm mistaken you will have achieved a cross-platform (eg: big-endian, little-endian compatible) efficient binary format for the case where you do indeed have mirror serialization code on both sides. To me that's a huge win. I can write to binary files or across a socket to any platform and as long as I deserialize using the same code it should work. I don't believe the other binary (maybe the text) archives can claim that. I think there is one more restriction on the C++ code, however. Types would have to be coded with 'portable' types (eg: boost::uint_16, boost::uint_32, etc). But anyone doing cross-platform development already does that, right ;-) """"""""""'' Question- I was just looking for clarification. Does the boost serialization library allow me to have objects on different platforms stream to each other? To put it another way is the guess here correct? " Unless I'm mistaken you will have achieved a cross-platform (eg: big-endian, little-endian compatible) efficient binary format for the case where you do indeed have mirror serialization code on both sides. To me that's a huge win." Thanks

1 0

regex patches available
by John Maddock 03 May '04

03 May '04

All users of Boost.Regex-1.31.1 should be aware that there are now a set of patches available for this release - see https://sourceforge.net/project/showfiles.php?group_id=7586 for downloads. Issues fixed include: POSIX style regular expressions not behaving correctly with regex_grep. Non-greedy repeats not backtracking correctly in some cases. Backreferences cause some repeat operators to behave incorrectly. Some wide character expressions weren't getting correctly optimised, leading to thrown exceptions in trivial cases. Misc. compiler compatibility fixes. Regards, John Maddock.

2 1

bdb and mpi selectors for the graph library
by pdoucyml＠free.fr 03 May '04

03 May '04

Hi all, as part of a project dealing with (very) big graphs, I am currently writing two containers. The first one is aimed at situations when you have huge graphs and want to distribute them among different computers. It uses MPI to communicate between computers. The second is aimed at situations when you can't distribute your graph (e.g. you're partitionning it before distributing it), or speed isn't an issue. It uses a berkeley DB database to store the graph. Is this code of interest for boost, would you consider reviewing it once it's tested and stable ? Pierre DOUCY -- Written slowly for people who can't read fast.

2 1

Linux regression tests screwed up?
by Gennaro Prota 03 May '04

03 May '04

Hi, I was looking at the Linux regression logs at http://boost.sourceforge.net/regression-logs/cs-Linux.html and I see that each test file is listed twice, with different results (Warn/Pass, or Warn/Fail etc.). It seems that at least in some cases old files are being picked up from the repository; for instance the tests for "dynamic_bitset - dyn_bitset_unit_tests1 - intel-8.0-linux" give a warning on the return type of const char * const test_file_name() which I have already changed to "const char *" nine days ago. A similar thing can be said for some gcc errors: http://boost.sourceforge.net/regression-logs/cs-Linux-links.html#dynamic_bi… Maybe I got something wrong in the Jamfiles? -- Genny. __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover

1 0

[Boost-bugs] [ boost-Bugs-946917 ] Minor coding issue
by SourceForge.net 03 May '04

03 May '04

Bugs item #946917, was opened at 2004-05-03 14:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=946917&group_i… Category: date_time Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pieter (morban) Assigned to: Jeff Garland (az_sw_dude) Summary: Minor coding issue Initial Comment: The functions: gregorian_calendar_base<ymd_type_,date_int_type_>::fr om_day_number(date_int_type dayNumber) and: gregorian_calendar_base<ymd_type_,date_int_type_>::fr om_julian_day_number(date_int_type dayNumber) in "gregorian_calander.ipp" share the same code, except for the static_cast to year_type (which is static_cast<unsigned short> in the first and static_cast<year_type> in the second of these functions. It seems that the one of these functions is redundant (and that the first one has a wrong type cast)... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=946917&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

ssh and repository
by Victor A. Wagner Jr. 03 May '04

03 May '04

Ok, it's broken yet again <sigh> and as Jonathan Wakely <cow(a)compsoc.man.ac.uk> says (I don't know where he's finding that info, I've been ALL OVER sourceforge.net) the root name is in EVERY directory...it's not a "just change my command line" Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

6 7

Hotfix or full 1.31.1 release? [mainly regex]
by John Maddock 03 May '04

03 May '04

Folks, I'm starting to accumulate a number of regex fixes/patches now, that could usefully be released as either a hotfix for 1.31.0, or combined with other 1.31.0 fixes to make a full 1.31.1 release. So which should it be - this is mainly going to be determined by whether the regression testers are prepared to switch their testing back to the release branch I guess. John.

3 3

Re: Re: [BGL] forced client complexity
by Provisional Dissonance 02 May '04

02 May '04

>Yea, but first the original poster should indicate if this is what he's >looking for -- I never needed this myself. What I was looking for, really, was dialog on existing design strategies. It sounds like your issues with property maps mirror my confusion with the library design, though. While I can fully appreciate the desire to write generic code, it feels like BGL has pushed the complexity of creating and enforcing coupling between the generic graph/node/visitor/algorithm/etc onto the client. At a basic conceptual level, I think of a graph as a data structure composed of nodes and edges. If I'm modeling a family tree, I expect the nodes to be objects of some family-member class. C++ exposes many robust and elegant methods for modeling the family-member - why should I, as a client, have to use property-maps at all? If the node's "index" is related to the object, why would it not be a natural member of the node-type's class? If, instead, it is a synthesized construct for communication between a graph and the algorithm operating over it, why should the client be responsible for its maintenance instead of the framework? What are the advantages of this approach? What are the disadvantages of simplifying things for the client? This is the type of design issue that I intended to question with my initial post. -prs __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

6 16

bind question/request
by Max Khesin 02 May '04

02 May '04

I am refactoring code that looks something like this: if (op == LN::FILTER_IN || op == LN::FILTER_NOT_IN) { where += handle_set_operation(column, type, format, op, expr_set); } else if (op == LN::FILTER_RANGE) { where += handle_range_operation(column, type, format, op, expr_set); } else if (op == LN::FILTER_NULL || op == LN::FILTER_NOT_NULL) { where += handle_null_operation(column, op); } ... This would obviously be handled better with a map of some sort (has to map int to function). The problem here is that some functions have more arguments than others, precluding the possibility of uniform type for the function value of the map. I cannot just go and change the function sig to include dummy values ('cause it's a dumb idea). This situation made me think of boost.function/boost.bind, which allows to effectively shorten the function parameter list by binding some of the args. so given int f(int a, int b) { return a + b; } bind(f, _1, 5)(x); is equivalent to f(x, 5); and by extension bind(f, _1, _2, _0)(x, y, z) would be equivalent to f(x, y) thoughts? thanks. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

5 4