[boost] Re: Inter-FSM protocol discussion
Hi Scott, point well taken. I think we're talking at different levels in the great abstraction foodchain. When you speak of protocols, you're talking about a specification (like one published by the ITU) that you need to implement. If I understand you correctly, you're saying that in practice you don't actually implement the entire specification for all targets under all circumstances. So in code you might have alternate implementations of FSM's that each more-or-less implement parts of the specification, and by extension their event signaling semantics may differ? What I'm talking about is a mechanism for formally describing the event/signaling interaction semantics between specific sets of FSM's - a specific object-level protocol if you will. By my way of thinking then, for you to go off and use this to implement, for example, an ITU telco protocol for different targets (you cite the example of four different ITU protocol implementations on four different hardware platforms) would require alternate FSM implementations (and by extension alternate inter-FSM object-level event signaling protocols) be defined for each target platform. Worst case the implementations are completely orthogonal in which case this idea would only help you on a per-target basis and that's really the limit of the scope of what I'm talking about. The whole business of doing high-level concept checking on mappings between sets of objects is something I'm struggling with in another context right now so it's useful to try to explain this stuff. Does this make more sense now knowing that I'm talking at the level of abstraction of specific FSM's and specific event/signaling protocols and not the more general full-blown ITU style protocol? Sorry for the overloading, but I can't think of a better way to describe it. - Chris "Scott Woods" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > "A category is given by two pieces of data: a class of objects and, for > any > > two objects X and Y, a set of morphisms from X to Y." > > > > What I was trying to suggest is that the objects in the category are > FSM's, > > and the set of morphisms defined for any two FSM's X and Y is a concept > that > > needs to be checked. Speaking as a layman, and not a discrete math > theorist, > > at first glimpse it would seem reasonable to think that the various > flavors > > of morphism might provide us with a nomenclature for describing the set(s) > > of inter-FSM event exchanges that a protocol could legally define without > > violating the semantics of any of the FSM objects in the category. > > > > Hi Chris, > Interesting. With a minimal understanding of discrete math theory (read > zip) am concerned that I am about to say something stupid but did have 2 > to offer anyway. > > 1) With low uptake of FSM approach to coding - adding grouping and > *morphing? > Think I can see the same light and with a childhood fear of the dark would > probably stumble in the same direction. The end of the tunnel could be a > lonely > place though;-) > 2) Having worked on multiple implementations of several protocols one > (painfully) > delayed revelation went something like this. If you are required to > implement Q.931 > on 4 hardware devices from 4 different vendors then you will produce 4 > distinct > implementations. Targeting a set of common semantics is somewhat "flawed". > In > FSM terms an implementation of a protocol may have some transitions missing. > In practice there are specifics about a device or even the implementation by > the > telco (yep, implementations of ITU standards on PSTNs vary) that mean a full > implementation is impossible. Have you ever dealt with minutely varying > behaviours > of mail servers (all fully POP3 or IMAP4 conformant)? Anyhow my point is; > with > your goal of defining permissible semantics, will there be the latitude to > cope with > previously described circumstances? > > SW > > > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: another program option feature request
Pavol Droba wrote:
> On Mon, Jun 09, 2003 at 09:08:37AM +0400, Vladimir Prus wrote:
>> Hi Pavol,
>>
>> > I have a request regarding config file support in the program option
>> > library. Currently when the parser encounters an unknown option in the
>> > config file, parsing is stopped with an exception.
>> > Together with fixed option definition, this feature disables a
>> > possibility to have an arbitrary options in the config file, whose
>> > exact format is not know prior to parsing.
>> >
>> > An example:
>> >
>> > I'd like to have something like this in the config file
>> >
>> >
>> >
>> > [module]
>> >
>> > file-count = 3
>> >
>> > file-name1 = 001.aaa
>> > file-name2 = 002.aaa
>> > file-name3 = 003.aaa
>> >
>> >
>> >
>> >
>> > where the number of file-name* lines is not know before parsing, and it
>> > is up to user to specify as many as she wants, or the format and number
>> > of options is dependant on some other option ( i.e. file-count )
>> >
>> > I think, that it would be nice to be able to force the parser to accept
>> > also the options not described in the option_descriptions and have a
>> > way to work with them.
>>
>> In fact, there's a (undocumented) feature which applies to your case:
>>
>> desc.add_options()
>> ("file-name*", )
>>
>> After this, every option starting with "file-name" will be accepted. Is
>> this appropriate for your use case?
>>
>> - Volodya
>
> Well, it looks fine, but still, there can be other cases which could not
> be coverd by a simple wildcard like this.
>
> I think, it would still be benefitial if there would be possibility to
> parse options which have not been described.
Thinking a bit more, I note that cmdline class has a feature to allow
unregistered option, while config_file does not. For uniformity alone,
it will be good to add such feature to config_file. Noted, thanks!
- Volodya
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: another program option feature request
On Mon, Jun 09, 2003 at 09:08:37AM +0400, Vladimir Prus wrote:
> Hi Pavol,
>
> > I have a request regarding config file support in the program option
> > library. Currently when the parser encounters an unknown option in the
> > config file, parsing is stopped with an exception.
> > Together with fixed option definition, this feature disables a possibility
> > to have an arbitrary options in the config file, whose exact format is
> > not know prior to parsing.
> >
> > An example:
> >
> > I'd like to have something like this in the config file
> >
> >
> >
> > [module]
> >
> > file-count = 3
> >
> > file-name1 = 001.aaa
> > file-name2 = 002.aaa
> > file-name3 = 003.aaa
> >
> >
> >
> >
> > where the number of file-name* lines is not know before parsing, and it is
> > up to user to specify as many as she wants, or the format and number of
> > options is dependant on some other option ( i.e. file-count )
> >
> > I think, that it would be nice to be able to force the parser to accept
> > also the options not described in the option_descriptions and have a way
> > to work with them.
>
> In fact, there's a (undocumented) feature which applies to your case:
>
> desc.add_options()
> ("file-name*", )
>
> After this, every option starting with "file-name" will be accepted. Is this
> appropriate for your use case?
>
> - Volodya
Well, it looks fine, but still, there can be other cases which could not be coverd by
a simple wildcard like this.
I think, it would still be benefitial if there would be possibility to parse options
which have
not been described.
Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Question about lexical_stream::operator<< and >>
This question may sound silly for you boost veterans, but here it is
nonetheless. As a general matter, I am interested in boost from a consumer
rather than contributor standpoint (at least for now) so my questions will
be very practical in nature.
I #included and in my
code, and they indirectly #include . Here is the warning I
get from the compiler (I am using MS Visual C++ 6):
*
d:\documents and
settings\administrator\desktop\dev\boost_1_30_0\boost\lexical_cast.hpp(147)
: warning C4800: 'void *' : forcing value to bool 'true' or 'false'
(performance warning)
d:\documents and
settings\administrator\desktop\dev\boost_1_30_0\boost\lexical_cast.hpp(146)
: while compiling class-template member function 'bool __thiscall
boost::detail::lexical_stream,class std::allocator > >::operator <<(const class
std::basic_string,class
std::allocator > &)'
and others like this
*
And here is the line that causes this warning. First off, it's not clear why
the return should be a bool, and if that was indeed the author's intention,
the conversion between the ( stream << input ) which normally should return
a stream&, and bool, does not seem to make sense (for one thing the return
will never be false).
**
bool operator<<(const Source &input)
{
return stream << input;
}
**
Could somebody clarify this.
Best regards,
Adrian Michel
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] compiler status page proposition
Hi, It may be convinient fr backward references to have an anchors in compiler status page marking beggining of each library. What you think? Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Command Line & Config review results
Petr Ko?m?d wrote: > On Thursday 05 of June 2003 15:38, Vladimir Prus wrote: >> Aleksey Gurtovoy wrote: >> > I think the general conclusion was that one should be able to use both >> > 'char' and 'wchar_t' versions of the library facilities in the same >> > program. >> Ehm... in fact I gleaned quite the opposite conclusion, and can't >> understand the need to use both in the same program. Anyway, I'm planning >> to use preprocessor-based solution, so can support this use case, too. > > A mix of unicode & non-unicode config files & ASCII command line together > is a legitimate need today. Which does not mean you have to use two versions of each library. Qt manages to get alone nicely with a single QString class. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: another program option feature request
Hi Pavol,
> I have a request regarding config file support in the program option
> library. Currently when the parser encounters an unknown option in the
> config file, parsing is stopped with an exception.
> Together with fixed option definition, this feature disables a possibility
> to have an arbitrary options in the config file, whose exact format is
> not know prior to parsing.
>
> An example:
>
> I'd like to have something like this in the config file
>
>
>
> [module]
>
> file-count = 3
>
> file-name1 = 001.aaa
> file-name2 = 002.aaa
> file-name3 = 003.aaa
>
>
>
>
> where the number of file-name* lines is not know before parsing, and it is
> up to user to specify as many as she wants, or the format and number of
> options is dependant on some other option ( i.e. file-count )
>
> I think, that it would be nice to be able to force the parser to accept
> also the options not described in the option_descriptions and have a way
> to work with them.
In fact, there's a (undocumented) feature which applies to your case:
desc.add_options()
("file-name*", )
After this, every option starting with "file-name" will be accepted. Is this
appropriate for your use case?
- Volodya
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Inter-FSM protocol discussion
> "A category is given by two pieces of data: a class of objects and, for any > two objects X and Y, a set of morphisms from X to Y." > > What I was trying to suggest is that the objects in the category are FSM's, > and the set of morphisms defined for any two FSM's X and Y is a concept that > needs to be checked. Speaking as a layman, and not a discrete math theorist, > at first glimpse it would seem reasonable to think that the various flavors > of morphism might provide us with a nomenclature for describing the set(s) > of inter-FSM event exchanges that a protocol could legally define without > violating the semantics of any of the FSM objects in the category. > Hi Chris, Interesting. With a minimal understanding of discrete math theory (read zip) am concerned that I am about to say something stupid but did have 2 to offer anyway. 1) With low uptake of FSM approach to coding - adding grouping and *morphing? Think I can see the same light and with a childhood fear of the dark would probably stumble in the same direction. The end of the tunnel could be a lonely place though;-) 2) Having worked on multiple implementations of several protocols one (painfully) delayed revelation went something like this. If you are required to implement Q.931 on 4 hardware devices from 4 different vendors then you will produce 4 distinct implementations. Targeting a set of common semantics is somewhat "flawed". In FSM terms an implementation of a protocol may have some transitions missing. In practice there are specifics about a device or even the implementation by the telco (yep, implementations of ITU standards on PSTNs vary) that mean a full implementation is impossible. Have you ever dealt with minutely varying behaviours of mail servers (all fully POP3 or IMAP4 conformant)? Anyhow my point is; with your goal of defining permissible semantics, will there be the latitude to cope with previously described circumstances? SW ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Some questions on the FSM submission
Hi Jeff, > for a telecom product. It was great if what you were doing fit well into SDL, > but plugging in say an std::list was a nightmare -- basically undoable (C > wrappers and such). He hated every minute. Me too :-))) > 4) I think you are right that your submission can cover most of the > ground of both. That said, I for one, think that coverage of UML is > the more important of the two. A few developers I've met actually > understand something about UML state diagrams. Barely any have > any idea about SDL and I've worked on various telecom projects > for at least 8 years... Agreed. Andreas has it covered. Perceived competition between UML and SDL is a bit of a fizzer in that they have the same roots and huge overlap in goals? Didnt see it like this myself until recent catch-up. UML wins on familiarity and comfort? Your point about "few developers" is spot-on. Consistent with a recent CUJ article that tried to sell the value of state-machines. Used the example of a VB implementation of calc.exe to highlight the fact that we (developers at large) tend to avoid proper handling of async events. Its everywhere (GUIs, devices, networks...) and yet a low percentage of software solutions are formalized with the likes of UML. Maybe boost::fsm is going to be sexy enough to lure a few more developers? PS: 8 years of telecoms without SDL? Almost jealous ;-) > > > Jeff > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: Interest in library generating streambufs from objects
Thanks for your interest. I have posted the library at http://groups.yahoo.com/group/boost/files/streambuf_lib/. The implementation needs to be streamlined, but it works, and the main ideas are clear enough. Robert Ramey wrote: > I think it would be more interesting if the following were considered > > a) composability - suppose I have an encryption facility and a > compression facility. I would like to be able to make a > streambuf the compresses thhen encryrpts or vice versa. ... > c) this suggests to me: > i) a implemention set of composable iterator adaptors. > ii) a streambuf that can filter input/output through an itererator adaptor. This > MIGHT be implemented as a codecvt facet that takes an interator adaptor > as an argument. ... > To summarize, I would like see the concept of "adaptable sequence" factored > out of streambuf and a streambuf built that can use any "adaptable sequence". This is good idea! I had thought about composing streambufs to create new streambufs, and indeed this seems fairly straightforward using my approach (perhaps the most difficult part is selecting suitable names for the composition operations -- how about 'operator+' ?) However, reworking the project in terms of iterator adaptors is a completely different story (I think.) Very interesting! Could you give a more detailed example? Jeff Garland wrote: >1) I'd be interested in how this fits with the Boost Socket initiative >http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket >2) I've written something similar for zip files, but looks like you may have >a more general solution -- a toolkit for creating new streambuf types. If >this is the case, it would be very handy. I'll have to look more closely at Boost Sockets (I've only read the requirements.) Also I will look at your compressed streams tonight. Thanks, Jonathan Turkanis ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Some questions on the FSM submission
Hi Andreas, > I don't know what part in the UML specs you're referring to (I don't really > know UML apart from class diagrams and state charts). A quick search did not > reveal much apart from protocol state machines which AFAICT don't have > anything to do with FSM interaction. Confusion is (again ;-) my fault. I will try to do better this time round. I was back-predaling on the different capabilities of SDL and UML with respect to their potential to deal with the issue of "free-protocols" (in the manner of free- functions). After reading; http://www.rational.com/media/uml/resources/documentation/umlrt.pdf I felt it was unreasonable to make the broad statements I had made previously about UML's (or SDL's) inability to treat protocols as substantive. While the document above is not part of the UML specification it is obviously quality work that applies UML to the modeling of protocols. It isnt a built-in facility of UML and their model for protocols (and capsules and ports and connectors) was not what I had envisaged. But it seemed to be a successful modeling and I had to concede; why should a "niche" concept such as "protocols" foul the "global namespace" of a generic modeling language? > SDL defines channels, gates and connections which sort of define a protocol. > To me, these primitives are only necessary to *document* which FSM is > talking to which other FSM. There's little semantics behind them. Maybe I'm > seeing this too easy but I think in C++ all you need for inter-FSM > communication is: Yes. Agree with significance/usefulness of channels, gates and connections. And this is part of why I consider SDL (& UML) "weak" in their "out-of-the-box" abilities to specify FSM interaction (i.e. protocols). > 1. Events that can carry parameters > 2. A call-back mechanism a la boost::function, so that an FSM that is > answering a request does not have to know who it is answering to. > [snip] > > boost::intrusive_ptr< Request > pRequest = new Request(); > // set params > A & machine = context< A >(); > pRequest->callback = boost::bind( &A::queue_event, machine, _1 ); > > B::instance().queue_event( pRequest ); > > > So, IMO there's no need for boost::fsm to provide communication protocol > primitives, because their functionality is pretty orthogonal to what my > library does. Users would want to use what they're accustomed to. Most would > presumably use boost::function. > Yes. Think with 1, 2 and putting distance between boost::fsm and comms you have nailed something for me. Maybe there will eventually be a boost::signaling (damn thats somewhat overused) or boost::eventing (sounds like a horse race) that will complement your current targets? Of course, this does not directly meet the requirements I have (so badly) articulated but it does not preclude related work in the future (I'm thinking decades). I suspect that some of my inability to define a "protocol" (a collection of events) is related to different apparent areas of work; i.e. real-time events vs distributed message processing, e.g. FTP or IMAP4. A significant difference is that the former is less likely to involve well-defined sets of messages that will be re-used from one project to the next (or even surfacing in several parts of a single project). I feel responsible for something of a detour into the subject of SDL and the comparison of UML with SDL. I hope that this detour has uncovered something of use for you (certainly has for me) but really exactly where these languages are going and their relative advantages are secondary to getting your library accepted ;-) Thanks, Scott ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Math Constants Formal Review
At 01:57 PM 6/8/2003, Gennaro Prota wrote: >On Sun, 8 Jun 2003 15:56:53 +0100, "Paul A Bristow" ><[EMAIL PROTECTED]> wrote: > >>If someone would like to do this, I'd be grateful. >> >>(Memories of how to use commandlines and CVS have decayed). > >IIUC, the boost sandbox is, so to speak, a more precious resource than >the Yahoo files section. So, unless there's a need to "develop there" >(for instance because many people should simultaneously work at the >files, or because it's appropriate to have a record of all the changes >and who made them) the Yahoo section or any private web spaces should >be preferred. It seems a waste to use a cvs repository just to provide >a place to get things from. But, maybe, the policy is different and I >don't know. It would be nice to have a confirmation. I'm sure Beman or >Dave can give it. > What Daryle is talking about is not the sandbox CVS itself, but boost-sandbox project web space that you get from SourceForge, separate from the CVS. We use that space on the main boost SourceForge project for publishing daily regression tests, for example. Yes, it would definitely be a good idea. It means that those wishing to grab code for a review do not have to deal with yahoogroups. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Command Line & Config review results
At 10:48 AM 6/4/2003, Vladimir Prus wrote: >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... but let it >be. I assume I've not asked to implement any specific approach, and can >decide myself? I've just about finished an extensive analysis of the issues involved when wchar_t and other non-char types are used in filenames. Many of these issues, including the key interoperability requirements, will apply to command line arguments or any other communication where the character type, size, or encoding differs between internal use in a user program and external use by the operating system. It would be unwise and chaotic for the Boost filesystem and command line libraries to have different external to internal conversion behaviors. Also, those issues are fairly orthogonal to the other big picture aspects of a command line library design. All that argues for not trying to add wchar_t support to the command line library right away. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Command Line & Config review results
At 09:12 AM 6/5/2003, Aleksey Gurtovoy wrote: >Vladimir Prus wrote: >> > There've been a fair amount of suggested changes, many of which are >> > documented on Wiki [1], and since the author himself keeps track of >> > the issues, I won't reiterate them here - except for stressing the >> > need for >> > >> > a) extensively reworked and extended documentation, and >> >> Completely agree. >> >> > 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 be happy to help you out. There may be a confusion here. Lots of people have experience with wchar_t and other non-char types in applications where the internal and external character set, type, size, and encoding are all the same. But I think command line arguments have to interoperate with the operating system. That means the internal and external character set, type, size, or encoding may be different. While some people have experience with character set conversions on specific operating systems, finding people who have solutions which work portably across multiple operating systems is much harder. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Managing boost dependencies
"Edward Diener" <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> "Edward Diener" <[EMAIL PROTECTED]> writes: >> >>> David Abrahams wrote: "Edward Diener" <[EMAIL PROTECTED]> writes: >>> I will look at the WinCVS site to see if there are NGs or mailing >>> lists that might help me out. >> >> Suit yourself; I'm trying to suggest that you not waste your time, at >> least as first, and instead dig into http://cvsbook.red-bean.com/ > > Thanks for the link. > > Do realize that people are different and that my programming preference is > almost always to use a GUI interface over command lines as long as the GUI > interface lets me do what I want to accomplish. I do realize that. I have the same preference, but I found WinCVS to be somewhat opaque and mysterious until I learned the command-line stuff. > Of course I write actual code in a fancy editor just like everyone > else . I will dig into the .pdf version of the link first, > although my initial reaction to CVS was not joyful, but I am sure it > can not be that arcane to use. Maybe it is, but I think it's better than trying to learn CVS the other way. Once you understand CVS itself, there are any number of front-ends (WinCVS, emacs vc and pcl-cvs modes, something that integrates with the windows file browser - I forget the name) that you can use and will make total sense. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Managing boost dependencies
David Abrahams wrote: > "Edward Diener" <[EMAIL PROTECTED]> writes: > >> David Abrahams wrote: >>> "Edward Diener" <[EMAIL PROTECTED]> writes: >> I will look at the WinCVS site to see if there are NGs or mailing >> lists that might help me out. > > Suit yourself; I'm trying to suggest that you not waste your time, at > least as first, and instead dig into http://cvsbook.red-bean.com/ Thanks for the link. Do realize that people are different and that my programming preference is almost always to use a GUI interface over command lines as long as the GUI interface lets me do what I want to accomplish. Of course I write actual code in a fancy editor just like everyone else . I will dig into the .pdf version of the link first, although my initial reaction to CVS was not joyful, but I am sure it can not be that arcane to use. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Managing boost dependencies
"Edward Diener" <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> "Edward Diener" <[EMAIL PROTECTED]> writes: >> >>> How does one get the latest Boost CVS source ? I have WinCVS but >>> have never been able to figure out how to use it to get CVS source >>> on the Internet anywhere. Would anyone like to run me through it ? I >>> know it has something to do with server access but I am dumbfounded >>> by the WinCVS doc, >> >> The easiest and most reliable way to use CVS to get the Boost CVS >> sources is to use the cvs command-line tool (a cvs.exe is part of your >> WinCVS installation) and to simply follow verbatim the instructions >> for anonymous CVS access at: >> >>http://sourceforge.net/cvs/?group_id=7586 >> >> Using "boost" for the modulename. It's only two lines you need to >> type. > > OK, thanks ! Those two lines should get me started. > >> >> I know WinCVS is supposed to make things easier, but for many jobs it >> really doesn't - you have to figure out how the instructions everyone >> else uses can be translated into equivalent checkboxes and menu items >> in WinCVS, and eventually you need to understand how the command-line >> works because the abstraction layer provided by WinCVS always "leaks" >> the underlying implementation details. > > I will use the command lines above but I am still thinking that there must > be a way to do things via WinCVS which allows me to access Boost CVS from > within WinCVS's GUI environment. Oh, there certainly is; I used to use it. I'm just telling you that in the end you will work harder, possibly much harder, to become effective with CVS if you try to do that. That's in part because WinCVS tries to hide CVS's model of operation a bit, even though it's just a CVS wrapper. If you learn the command-lines first, though, you'll immediately understand what all of the WinCVS operations do since the abstraction layer provided by WinCVS is actually fairly thin. > I will look at the WinCVS site to see if there are NGs or mailing > lists that might help me out. Suit yourself; I'm trying to suggest that you not waste your time, at least as first, and instead dig into http://cvsbook.red-bean.com/ -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: RE: Math Constants Formal Review - is extensible.
On Sun, 08 Jun 2003 16:56:53 +0200, Paul A Bristow wrote:
> You can seen an example of extending to a 'new' constant 'gamma' in the
> examples testFunctionConstants/gamma_function_constants.hpp.
Either I don't understand the example or we are talking past each other. I
don't meant to extend the framework with new constants, but with
definitions of existing constants for new types. Maybe the attached
example of a small experiment of mine clarifies what I was thinking about.
Look at the "Roguewave"-extension for pi. If I imagine to use
"boost/math_constants.hpp" in the company I work, it would be encapsulated
into another header "base/math_constants.h" and it would provide all
constants for Roguewawve's decimal type, too. I already used the
lambda-library and tought it about the decimal type, which worked very
smooth and I was really happy to see that the library designers didn't
limited it to build-in types. A key-feature for me!
> defining the constant as a 40 decimal digit string.
Roguewave's types can be used with precisions up to 1024 bits - probably
more. I don't think that a one-size-fits-all approach can work in the area
of numeric computations.
> If Boosters agree that this scheme is an acceptable way to go, the the
> example and guidance could be made more helpful to provide the
> encouragement you rightly say is needed.
>
> But first the overall strategy needs agreement.
Indeed. So if I still missed that the constants can be provided by the
user for their types, please let me know. Otherwise, we should find a
consensus whether such a feature is needed. I personally think it is, but
if the majority thinks it's not that important... :)
Note that the attached file is not meant to offend you in any way. It way
just a toy example and maybe you can take some ideas out of it. It's not
meant to replace your code as I think you have put a lot of ideas in it
and provide features I don't even know of :)
Regards, Daniel
---
#include
using namespace std;
namespace math
{
// Generic base class for all constants
template< typename T, template< class > class F > struct constant
{
// A cast-to-anything-operator :)
template< typename U > operator U() const { return F< U >()(); }
#define ADD_OPERATOR( OP ) \
template< typename U > friend U operator OP( const T& lhs, const U& rhs ) \
{ U nrv( static_cast< U >( lhs ) ); nrv OP##= rhs; return nrv; } \
template< typename U > friend U operator OP( const U& lhs, const T& rhs ) \
{ U nrv( lhs ); nrv OP##= static_cast< U >( rhs ); return nrv; }
ADD_OPERATOR( + );
ADD_OPERATOR( - );
ADD_OPERATOR( * );
ADD_OPERATOR( / );
#undef ADD_OPERATOR
};
// Here's the definition for pi for all types (can be extended by UDTs):
template< typename T > struct pi_value;
template<> struct pi_value< float > { float operator()() const { return 3.14; } };
template<> struct pi_value< double > { double operator()() const { return 3.1416;
} };
template<> struct pi_value< long double > { long double operator()() const {
return 3.1415927; } };
/*
// For expensive constructions, maybe this is an option:
template<> struct pi_value< RWDecimal< RWMP3Int > > {
const RWDecimal< RWMP3Int >& operator()() const {
static const RWDecimal< RWMP3Int > value( "3.1415926535897932384626433832"
);
return value;
}
};
*/
// Here's the single line to create a useful interface
struct pi_t : constant< pi_t, pi_value > {} pi;
// Another one:
template< typename T > struct pi2_value;
template<> struct pi2_value< float > { float operator()() const { return 9.87; } };
template<> struct pi2_value< double > { double operator()() const { return 9.8696;
} };
template<> struct pi2_value< long double > { long double operator()() const {
return 9.8696044; } };
struct pi2_t : constant< pi2_t, pi2_value > {} pi2;
// And their relationship:
pi2_t operator*( const pi_t&, const pi_t& ) { return pi2_t(); }
// Some obvious (?) constants:
#define CONSTANT_VALUE( name, value ) \
template< typename T > struct name##_value { T operator()() const { return value;
} }; \
struct name##_t : constant< name##_t, name##_value > {} name;
CONSTANT_VALUE( minus_one, -1 );
CONSTANT_VALUE( zero, 0 );
CONSTANT_VALUE( one, 1 );
CONSTANT_VALUE( two, 2 );
CONSTANT_VALUE( three, 3 );
CONSTANT_VALUE( ten, 10 );
#undef CONSTANT_VALUE
minus_one_t operator-( const one_t& ) { return minus_one_t(); }
one_t operator-( const minus_one_t& ) { return one_t(); }
zero_t operator-( const zero_t& ) { return zero_t(); }
// Another one:
template< typename T > struct half_pi_value;
template<> struct half_pi_value< float > { float operator()() const { return 1.57;
} };
template<> struct half_pi_value< double > { double operator()() const { return
1.5708; } };
template<>
RE: [boost] patch for date_time library
Synge - I have applied a fix that is equivalent to your patch. Let me know if it works. Sorry to be so slow on this... Jeff > -Original Message- > [mailto:[EMAIL PROTECTED] Behalf Of Synge Todo > Sent: Thursday, May 29, 2003 10:15 PM > Subject: [boost] patch for date_time library > > > Dear Boosters, > > SGI MIPSpro C++ can not compile programs, which use date_time library. > The compiler complains as follows: > > cc-3354 CC: ERROR File = > /home/i004/i00400/src/boost/boost/date_time/time_system_split.hpp, Line = 35 > A non-integral operation is not allowed in a nontype template argument. > > typedef date_time::wrapping_int config::tick_per_second > wrap_int_type; > > I attached a simple workaround to solve this problem. Could someone > apply this patch? Thank you in advance. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: no semaphores in boost::thread
well, unless (likely given this biz) the words have changed meaning again, "naked semaphore" was described by Dijkstra way back when (1964??) a "mutex" was a variant of a semaphore which restricted signalling (V()) to the task/process/thread/whatever that had successfully waited (P()) on it. often a mutex would allow the _same_ task/process/thread... to wait (P()) multiple times on the same mutex withOUT deadlock, but would have to signal (V()) the correct number of times before the mutex would be released. Now if the definitions have changed, I apologize for the mis-understanding. If you have some OTHER definition that discriminates between semaphore and mutex, I'd be happy to hear it. If not, why do we have two words for the same thing? btw, note that IF my definition is correct, then at a minimum a mutex must do more work than a semaphore (since it must establish "ownership" of the mutex). At Thursday 2003-06-05 09:48, you wrote: "Victor A. Wagner, Jr." wrote: > > I'm baffled that they want to penalize (time and space) those for whom a > naked semaphore works. Show me please an example illustrating "naked semaphore" in work. >It's blatantly clear to anyone who's had to write a > mutex that it's additional code on TOP of a semaphore. Optimization strategies aside for a moment (they are different for mutexes and semaphores) a binary semaphore can be used as "normal" POSIX mutex. ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/SRC-020.pdf " Mutexes and semaphores A mutex is represented by a pair (Lock-bit, Queue). The Lock-bit is 1 if a thread is in a critical section protected by the mutex, and is 0 otherwise. In terms of the formal specification, the Lock-bit is 0 iff the mutex is NIL. The Queue contains the threads that are blocked in Acquire (awaiting its WHEN condition). The user code for Acquire and Release is designed for fast execution of a LOCK clause when there is no contention for its mutex. In this case an Acquire-Release pair executes a total of 5 instructions, taking 10 microseconds on a MicroVAX II. This code is compiled entirely in-line. Acquire consists of two sequential actions: test-and-set the Lock-bit (implemented atomically in the hardware); call a Nub subroutine if the bit was already set. The user code for Release is two sequential actions: clear the Lock-bit; call a Nub subroutine if the Queue is not empty. The Nub subroutine for Acquire (after acquiring the spin-lock) first adds the calling thread to the Queue. Then it tests the Lock-bit again. If it is still 1, this thread is de-scheduled and the general scheduling algorithm is invoked to determine what to do with this processor. On the other hand, if the Lock-bit is now 0, the thread is removed from the Queue, the spin-lock is released, and the entire Acquire operation (beginning at the test-and-set) is retried. The Nub subroutine for Release (after acquiring the spin-lock) checks to see if there are any threads in the Queue. If there are, it takes one, adds it to the ready pool, and invokes the general scheduling algorithm, which will assign the thread to a suitable processor if one is available. The implementation of semaphores is the same as mutexes: P is the same as Acquire and V is the same as Release. " regards, alexander. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law" ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] random lib: Quasi-random generators
Hi, Have anyone involved in the random lib and its standardization considered a couple of quasi-random generators? I have recently heard of the fancy named quasi stuff which simply means that the numbers fill the range more uniformly than normal pseudo-random sequences. These sequences are important for Quasi Monte Carlo integration and for applications that need to destribute N samples uniformly in some way without knowing N in advance. regards Thorsten source: "Numerical recipes in C++, second edition, p. 313ff" ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost]Interest in library generating streambufs from objects
This a very ripe subject My interest stems from my efforts regarding a serialization library. I have had occasion to consider alternatives in this light. I have looked at Jeffs compression streambuf. I think its interesting, useful and nicely done. Given this, maybe you should set your sights even higher. I think it would be more interesting if the following were considered a) composability - suppose I have an encryption facility and a compression facility. I would like to be able to make a streambuf the compresses thhen encryrpts or vice versa. b) suppose I add other facilities such as escaping/unescaping ascii characters, convert to/from wide characters, etc. I should be able to compose these in an arbitray way. c) this suggests to me: i) a implemention set of composable iterator adaptors. ii) a streambuf that can filter input/output through an itererator adaptor. This MIGHT be implemented as a codecvt facet that takes an interator adaptor as an argument. d) This would have the advantage that the conversion facilities would be useful way beyond streambuf e) currently, the new iterator adaptor package doesn't include an example that is suitable for use as a basis for such "conversion" or transformational adaptors. But its not hard to make one. To summarize, I would like see the concept of "adaptable sequence" factored out of streambuf and a streambuf built that can use any "adaptable sequence". Robert Ramey Jeff Garland wrote >Jonathon T. wrote: >> I have several class templates for producing standard streambufs based on >> classes with read, write and seek functions (or a suitable subset thereof.) >> I have used them successfully to access tcp connections, cryptographic >> routines, OLE compound documents, zip files, etc. >> There are templates istreambuf and ostreambuf which perform either input or >> output exclusively, a template double_streambuf which behaves like an >> istreambuf glued to an ostreambuf, and a template bidirectional_streambuf >> which performs input and output using a single shared buffer with a single >> repositionable file pointer. >> In addition, template parameters can be used to specify code conversion and >> to turn off buffering, and a contained error object can be used to customize >> exception throwing. >> I there is any interest, I will post them at the vault. >Jonathan -- >I have an interest in this (sorry for the slow response) for a couple reasons. >1) I'd be interested in how this fits with the Boost Socket initiative >http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket >2) I've written something similar for zip files, but looks like you may have >a more general solution -- a toolkit for creating new streambuf types. If >this is the case, it would be very handy. >Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] WinCVS note
I also had problems getting WinCVS to work to taste. I was frustrating as I didn't need to go into the whole facility - I just wanted a sync'ed local copy. I bought a book on CVS but it started to consume a lot of time to use I finally got WinCVS to create a new local copy by using the command line functionality ( login, etc) included in WinCVS. From then on the sync stuff (update) worked fine (though I had to search around for an option in the update). I suspect that WinCVS is a little bit behind the complete CVS syntax. I suppose there might be a lesson here but I've move on. Robert Ramey >"Edward Diener" <[EMAIL PROTECTED]> writes: >> How does one get the latest Boost CVS source ? I have WinCVS but have never >> been able to figure out how to use it to get CVS source on the Internet >> anywhere. Would anyone like to run me through it ? I know it has something >> to do with server access but I am dumbfounded by the WinCVS doc, >The easiest and most reliable way to use CVS to get the Boost CVS >sources is to use the cvs command-line tool (a cvs.exe is part of your >WinCVS installation) and to simply follow verbatim the instructions >for anonymous CVS access at: > http://sourceforge.net/cvs/?group_id=7586 >Using "boost" for the modulename. It's only two lines you need to >type. >I know WinCVS is supposed to make things easier, but for many jobs it >really doesn't - you have to figure out how the instructions everyone >else uses can be translated into equivalent checkboxes and menu items >in WinCVS, and eventually you need to understand how the command-line >works because the abstraction layer provided by WinCVS always "leaks" >the underlying implementation details. >Dave Abrahams ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Math Constants Formal Review
On Sun, 8 Jun 2003 15:56:53 +0100, "Paul A Bristow" <[EMAIL PROTECTED]> wrote: >If someone would like to do this, I'd be grateful. > >(Memories of how to use commandlines and CVS have decayed). IIUC, the boost sandbox is, so to speak, a more precious resource than the Yahoo files section. So, unless there's a need to "develop there" (for instance because many people should simultaneously work at the files, or because it's appropriate to have a record of all the changes and who made them) the Yahoo section or any private web spaces should be preferred. It seems a waste to use a cvs repository just to provide a place to get things from. But, maybe, the policy is different and I don't know. It would be nice to have a confirmation. I'm sure Beman or Dave can give it. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Managing boost dependencies
David Abrahams wrote: > "Edward Diener" <[EMAIL PROTECTED]> writes: > >> How does one get the latest Boost CVS source ? I have WinCVS but >> have never been able to figure out how to use it to get CVS source >> on the Internet anywhere. Would anyone like to run me through it ? I >> know it has something to do with server access but I am dumbfounded >> by the WinCVS doc, > > The easiest and most reliable way to use CVS to get the Boost CVS > sources is to use the cvs command-line tool (a cvs.exe is part of your > WinCVS installation) and to simply follow verbatim the instructions > for anonymous CVS access at: > >http://sourceforge.net/cvs/?group_id=7586 > > Using "boost" for the modulename. It's only two lines you need to > type. OK, thanks ! Those two lines should get me started. > > I know WinCVS is supposed to make things easier, but for many jobs it > really doesn't - you have to figure out how the instructions everyone > else uses can be translated into equivalent checkboxes and menu items > in WinCVS, and eventually you need to understand how the command-line > works because the abstraction layer provided by WinCVS always "leaks" > the underlying implementation details. I will use the command lines above but I am still thinking that there must be a way to do things via WinCVS which allows me to access Boost CVS from within WinCVS's GUI environment. I will look at the WinCVS site to see if there are NGs or mailing lists that might help me out. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost header and library dependency tables
"John Maddock" <[EMAIL PROTECTED]> writes: > A while ago Beman produced header dependency tables, unfortunately these > began to get rather complicated and so were dropped, I've placed some > alternative tables here: > > Boost header dependencies: > http://www.regex.fsnet.co.uk/header_dependencies.html > Boost library dependencies: > http://www.regex.fsnet.co.uk/library_dependencies.html > > Whether these are actually any better than what we had before is > questionable, but the information might prove useful to some. > > BTW these tables are produced using bcp in list mode (see separate thread). What I really want to see for something called "library dependencies" is the list of other libraries (not headers) that a library depends on. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Managing boost dependencies
"John Maddock" <[EMAIL PROTECTED]> writes: > Folks, > > I've put together a small tool for managing boost dependencies called bcp > (for boost copy). > > The bcp utility is a tool for extracting subsets of Boost, it's useful for > Boost authors who want to distribute their library separately from Boost, > and for Boost users who want to distribute a subset of Boost with their > application. > > ~ > > As usual comments etc are most welcome, All I can say is that this is totally awesome, and thank you. > also should a utility/tool such as this go through the review > process I don't think it needs to. We review libraries, but traditionally tools are just checked in if they seem useful or are known to be needed. This one is. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: Math Constants Formal Review - recap & summary
A Mini-recapitulation of the _long_ saga so far:
Briefly I propose many different representations for constants,
because after much discussion and experimentation, no
universally-acceptable format and no disadvantage-free format has
been found.
1 We agree on the need for accurate mathematical constants
- pi, e, sqrt(2) for a start, but many others are 'essential' to
some people.
2 Physical constants are a separate matter for their accuracy is not
constant.
3 Some constants cannot be calculated accurately by current
compilers because they use 'built-in' hardware floating-point, and
this is unlikely to change. Only constants calculated with a higher
precision software system, like NTL,
will ensure that the constant is stored
as accurately as the floating-point hardware will allow.
4 40 decimal digits are sufficient for all practical purposes
(except intervals see below), and compilers are (or really should
be) capable of reading decimal digits into their various internal
formats (float, double, long double).
5 A C++ naming scheme for math constants has been devised which is
at least acceptable (if inevitably a compromise).
6 Control of precision is essential, but there is opposition to a
C-style solution using three names for each constant, for example:
float pi_F, double pi_D, long double pi_L. Nor, in Boost
discussions, did use of namespaces to separate different precisions
seem acceptable.
7 There are dozens of constants that some users rate 'essential'.
Splitting into several #include files still risks violating the
"don't pay for what you don't use" principle.
8 Only MACROS provide a simple way of avoiding some cost for
constants you don't use. (but Boosters expressed strong opposition
to MACROs because they pollute the global namespace, even if #undefs
are provided).
9 Users extremely strongly prefer to write "float area = pi * r * r;"
10 There is evidence that some compilers can generate better code
from functions like "double pi() { return 3.1459;}"
but that this implies writing pi() instead of plain "long double pi". So
the ()s remain a major issue.
Michael Kenniston had a previous interesting suggestion
but which did not seem entirely satisfactory.
He has now produced another which is attached.
Briefly, this allows 'novice' users to write "pi" but
get the effect of "pi()" without too many precision surprises. Yet
it still allows the 'expert' to write "pi()" and control precision
explicitly. But there remain some disadvantages - see FAQ.
11 Finally the acceptance of the Interval Library into Boost means
there is a real need for intervals containing constants - upper and
lower limits. Examples have been calculated as 'exact representations'
and
discussed before. This increases the number of constants potentially
required to achieve the required accuracy (for example, 2_pi
interval IS needed).
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Frey
| Sent: 07 June 2003 00:20
| To: [EMAIL PROTECTED]
| Subject: [boost] RE: Math Constants Formal Review
|
|
| I currently vote neither yes nor no. I just need to get a
| better understanding of what is intended to be included into
| boost from the files provided.
|
| On Fri, 06 Jun 2003 19:21:08 +0200, Paul A Bristow wrote:
|
| > but I hope the review can concentrate on what emerged
| previously as
| > the _really_ tricky issue of how to _present_ the values in C++,
|
| I looked at the files and I think that they need some clean
| ups. Also, I don't really see the concept behind it. How are
| the values presented and how does your way compare to other
| options? (Well, I basically can fiure out the first part,
| but without the second, I can't really understand it). Maybe
| you can provide some links to the key messages of the
| discussion that lead to it or give us a short summary.
|
| Another point I am missing is a way to extend the constants
| for user-defined types. Something like numeric_limits<>
| comes to mind. I think that this is a must-have feature as
| people that write applications that need lots of these
| constants are likely also using types with higher precision
| that the standard types provided by the language. Without a
| way to teach the constants-framework the new types, they
| will create wrappers and thus they won't use the intended
| boost-/standard-way to access the variables.
|
| Regards, Daniel
|
| ___
| Unsubscribe & other changes:
| http://lists.boost.org/mailman/listinfo.cgi/b| oost
|
|
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review
If someone would like to do this, I'd be grateful. (Memories of how to use commandlines and CVS have decayed). Paul Paul A Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Daryle Walker | Sent: 06 June 2003 23:47 | To: Boost | Subject: [boost] Re: Math Constants Formal Review | | | On Friday, June 6, 2003, at 6:45 AM, Jaap Suter wrote: | | > Today is the start of the formal review of the Math | Constants library | > by Paul Bristow. The review will run until Sunday June | 15th. I will | > be serving as review manager. | > | [SNIP] | > You can find the latest documentation, including a bigger | FAQ section, | > at: | > | > http://groups.yahoo.com/group/boost/files/MathConstants/ | > Math_Constants_doc_3.zip | > | > Some examples are available at: | > | > http://groups.yahoo.com/group/boost/files/MathConstants/ | > Math_Constants3.zip | [TRUNCATE] | | In the previous review, copies of the code and documentation of the | Command & Config Option library were copied to the web space | SourceForge reserved for the Boost-Sandbox. Maybe we could | do the same | for this review (and all later ones). | | Daryle | | ___ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/b| oost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review
| Genny wrote | Paul> What I would like to get is agreement on the presentation | of constants. | | You mean macros vs. constant variables vs. inline functions? | This is another thing I didn't understand by looking at the | documentation: the FAQ section seems sometimes to imply you | have already done a choice in this regard; In the previous review, Boosters suggested strongly different views on different ways of presenting constants. As I have tried to explain, there are pros and cons and valid reasons for wanting all of these. for instance: | | Q. Why not use floating-point hardware constants? | A. Because only a few are available, they are often not the right | size, are not available on all processors, and most important | are sometimes not accurate enough. | | but then, in another point: | | Q. Why are functions like double pi() which return constants | provided? | A. It provides a framework whereby users can plug in special | implementation and hardware-specific versions. Indeed - so the _user_ needs to be able to make the choice, and this implies that a single representation of constants won't do. | "Because some compilers may be able to produce smaller | and/or faster code.(For example, note that MSVC 7 Standard | edition only inlines "__inline", so this will produce slower | and longer code)." | | Maybe you meant: "because some compilers generate better | code with a manifest constant and others better code with a | function"? You could also say that - I'm open to suggestions. Paul ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: Math Constants Formal Review - is extensible.
You can seen an example of extending to a 'new' constant 'gamma' in the examples testFunctionConstants/gamma_function_constants.hpp. The example by Michael Kenniston also show how complex items could also be added (but not normally to avoid every program dragging in ). Macros could also facilitate the process of course, and it could start with a macro defining the constant as a 40 decimal digit string. If Boosters agree that this scheme is an acceptable way to go, the the example and guidance could be made more helpful to provide the encouragement you rightly say is needed. But first the overall strategy needs agreement. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria LA8 8AB UK | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Frey | Sent: 07 June 2003 00:20 | To: [EMAIL PROTECTED] | Subject: [boost] RE: Math Constants Formal Review | | Another point I am missing is a way to extend the constants | for user-defined types. Something like numeric_limits<> | comes to mind. I think that this is a must-have feature as | people that write applications that need lots of these | constants are likely also using types with higher precision | that the standard types provided by the language. Without a | way to teach the constants-framework the new types, they | will create wrappers and thus they won't use the intended | boost-/standard-way to access the variables. | | Regards, Daniel | | ___ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/b| oost | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Interest in library generating streambufs from objectswith socket-like interfaces?
Jonathon T. wrote: > I have several class templates for producing standard streambufs based on > classes with read, write and seek functions (or a suitable subset thereof.) > I have used them successfully to access tcp connections, cryptographic > routines, OLE compound documents, zip files, etc. > There are templates istreambuf and ostreambuf which perform either input or > output exclusively, a template double_streambuf which behaves like an > istreambuf glued to an ostreambuf, and a template bidirectional_streambuf > which performs input and output using a single shared buffer with a single > repositionable file pointer. > In addition, template parameters can be used to specify code conversion and > to turn off buffering, and a contained error object can be used to customize > exception throwing. > I there is any interest, I will post them at the vault. Jonathan -- I have an interest in this (sorry for the slow response) for a couple reasons. 1) I'd be interested in how this fits with the Boost Socket initiative http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket 2) I've written something similar for zip files, but looks like you may have a more general solution -- a toolkit for creating new streambuf types. If this is the case, it would be very handy. Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Managing boost dependencies
John M. wrote: > The bcp utility is a tool for extracting subsets of Boost, it's > useful for Boost authors who want to distribute their library > separately from Boost, > and for Boost users who want to distribute a subset of Boost with > their application. John - Many thx for doing this, I'm sure it will come in handy. I've tried this out for date_time and noticed a couple things: 1) date_time includes tokenizer.hpp which includes token_iterator.hpp which includes token_functions.hpp. Unfortunately, token_functions.hpp is not copied so my compile failed. 2) When I copied the 'build' library the boost-build.jam file and Jamrules files in boost root directory were not copied so bjam commands complained. Seems like these last 2 can't be determined because there isn't any direct include... Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Inter-FSM protocol discussion
Hi Andreas, I've taken the liberty of starting a new thread to talk about these inter-FSM protocol issues as they don't related directly to your current FSM lib submission. For the benefit of people cruising the archives at a later date, this conversation derives from this exchange: http://news.gmane.org/onethread.php?group=gmane.comp.lib.boost.devel&root=%3Cbbjf53%24448%241%40main.gmane.org%3E --- After posting http://article.gmane.org/gmane.comp.lib.boost.devel/20971 (suggests that inter-FSM protocols need some sort of semantic concept checking that depends on metadata that characterizes the FSM's between which the protocol is being established), it occurred to me that all but the simplest protocols themselves depend on a FSM mechanism... So let me take another shot at it: Related to concept checking (references: Category theory [1], and Morphisms [2]): "A category is given by two pieces of data: a class of objects and, for any two objects X and Y, a set of morphisms from X to Y." What I was trying to suggest is that the objects in the category are FSM's, and the set of morphisms defined for any two FSM's X and Y is a concept that needs to be checked. Speaking as a layman, and not a discrete math theorist, at first glimpse it would seem reasonable to think that the various flavors of morphism might provide us with a nomenclature for describing the set(s) of inter-FSM event exchanges that a protocol could legally define without violating the semantics of any of the FSM objects in the category. After thinking about it a little more and realizing that all but the simplest protocols are themselves based on some sort of FSM mechanism, maybe what we need is boost::fsm + boost::morphism to deal formally with protocols at a high-level. Totally shooting from the hip, we might for example consider codifying a concept hierarchy for the various flavors of morphisms (see p.151 of the BGL book or http://www.boost.org/libs/graph/doc/graph_concepts.html for an inspirational example). Climbing further out on the limb, such a library might leverage boost::property_map to aggregate the FSM's in a category (value_type == event source/sink metadata), and the actual morphism concept would be defined as a set of references into the property_map that performs concept check via boost::concept_check, and perhaps (wild speculation alert) generation of the code to actually implement the morphism mapping (i.e. wiring FSM event sources/sinks) via boost::mpl? This would provide compile-time concept checking and theoretically make it possible to design protocols at a very high-level of abstraction and leave the messy wiring to the C++ compiler (starts to blur the line between functional and imperative which is a good thing). I'm certain I've overlooked some important considerations. Viscerally, it feels like the right light to stumble towards though. Comments? - Chris Category theory entry on Wikipedia [1] http://www.wikipedia.org/wiki/Category_theory Morphism entry on Wikipedia [2] http://www.wikipedia.org/wiki/Morphism > > Ok, I see that concept checking could be helpful... > > > I've been staring at the Wikipedia sections on Morphisms [1] and Group > > Theory [2] looking for a suitable nomenclature for describing these > > protocol concepts. Basically my idea is that the actual protocol > > would formally specify what flavor of *morphism it's attempting to > > establish and use information from FSM's in the group to determine if > > such a mapping is possible (the concept check) and if so, affect the > > mapping generically somehow (i.e. the protocol itself doesn't > > get involved with event types and data semantics directly). Unclear > > to me if this is done at compile time, runtime, or both... > > > > What do you guys think of these ideas? > > Errr, while I got what a group is I don't really get what a *morphism is. > The description is too formal for me and the examples don't help either. > Moreover, I also fail to see the connection between groups and FSMs. Have I > been drinking too much lately ;o)? > > Regards, > > Andreas > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Managing boost dependencies
"Edward Diener" <[EMAIL PROTECTED]> writes: > How does one get the latest Boost CVS source ? I have WinCVS but have never > been able to figure out how to use it to get CVS source on the Internet > anywhere. Would anyone like to run me through it ? I know it has something > to do with server access but I am dumbfounded by the WinCVS doc, The easiest and most reliable way to use CVS to get the Boost CVS sources is to use the cvs command-line tool (a cvs.exe is part of your WinCVS installation) and to simply follow verbatim the instructions for anonymous CVS access at: http://sourceforge.net/cvs/?group_id=7586 Using "boost" for the modulename. It's only two lines you need to type. I know WinCVS is supposed to make things easier, but for many jobs it really doesn't - you have to figure out how the instructions everyone else uses can be translated into equivalent checkboxes and menu items in WinCVS, and eventually you need to understand how the command-line works because the abstraction layer provided by WinCVS always "leaks" the underlying implementation details. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Imminent Code Breakage
Roland Richter <[EMAIL PROTECTED]> writes: >> If you manually specialize boost::detail::iterator_traits it should work. >> > > The problem is the reference type. Yes, it works if you manually pass > all (or some) of the types; then again, this would require to include > thse types into the definition of reverse_iterator etc. No, AFAICT it doesn't require that. Did you read my suggestion above? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: alternative configuration technique
"John Maddock" <[EMAIL PROTECTED]> writes: >> I found that boost has very powerful configuration system >> (boost/config.hpp and around...) >> but why use macros? >> there is another solution described here, let discuss it... >> may be there are some troubles, invisible for me, that prevent from using >> this technique >> in libraries like boost? > > I think that there are two problems: > > 1) Your scheme requires that all possible implementations can be parsed by > the compiler - that won't be true for macros describing defects. > 2) Your scheme can't cope with optional features (long long or > ). > > Oh, and macros are probably simpler, if ugly. Yeah, the effort it would take to implement and maintain a one-line workaround in a 20-line function for different compilers would go through the roof. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: no semaphores in boost::thread
William E. Kempf wrote: I haven't seen your code to say for sure, but from the limited description I believe there's a very high probability that this is the case. Hm... I'm ready to accept the argument that having two separate synchronization primitives to do logically one task can be error-prone in non-trivial schemes. However, from what I understand, Stefan uses his semas in roughly this way: // get single element from queue 1a. semaphore_acquire 2a. mutex_lock 3a. get_elem_from_queue (some equivalent of front+pop_front) 4a. mutex_unlock // put single element into queue 1b. mutex_lock 2b. put_elem_to_queue (some equivalent of push_back) 3b. mutex_unlock 4b. semaphore_release I understand that there is a period of time when the program is running (and therefore is subject to preemption) between 1a and 2a, and that similar period of time happens between 3b and 4b. But I do not see the problem -- in typical usage these two pseudocode sequences are *the only* places in the application where the queue is accessed. That means that the only effect of race condition (resulting from preemption between 1a and 2a or between 3b and 4b) is that at some times the queue will actually have more elements than the sema's counter value. It is *not* a danger in the sense that there is no possibility to pop from the empty queue (once you get green light in 1a, you are sure that 3a will succeed, you just do not care how many elements there are, there is at least one for sure). I think that the argument about race conditions is valid when there are other places in code where the queue is accessed in some way and I understand that two separate synchronization objects make it more probable to write flawed code. However, in this simple example, either: - the race condition does not matter, or - I miss something obvious On the other hand (and being frank, it has to be stated loudly), the above pseudocode does not show that semas should be preferred over condvars... I write it for the sake of argument and better understanding of the rationale. -- Maciej Sobczak http://www.maciejsobczak.com/ Distributed programming lib for C, C++, Python & Tcl: http://www.maciejsobczak.com/prog/yami/ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost header and library dependency tables
On Sun, 8 Jun 2003, John Maddock wrote: [snip] > > Finally, what are "library dependencies"? Sorry if it's a dumb question. > > But by looking at the results, I don't get the meaning of it. > > It's everything that's needed by the complete library - by it's test and > example programs etc as well as the headers - for most libraries this means > that the Boost.test source will be listed as a dependency for example. Yes, it's what I thought at first. But the results are strange: I'm really surprised the MultiArray library relies on the Interval library headers. Regards, Guillaume ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] alternative configuration technique
> I found that boost has very powerful configuration system > (boost/config.hpp and around...) > but why use macros? > there is another solution described here, let discuss it... > may be there are some troubles, invisible for me, that prevent from using > this technique > in libraries like boost? I think that there are two problems: 1) Your scheme requires that all possible implementations can be parsed by the compiler - that won't be true for macros describing defects. 2) Your scheme can't cope with optional features (long long or ). Oh, and macros are probably simpler, if ugly. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost header and library dependency tables
> I think it's a good idea. But I have a few comments. > > First, it only handles headers that are directly under 'boost/'. However > some people have tried not to pollute the root directory and have put > their libraries in sub-directories. For example, the Graph library, uBlas, > the Interval library, the mathematical libraries, and so on. And your > script is unfortunately forgetting them. I know, I just wasn't sure which needed including. > Second, the links at the top of the pages don't work with all browsers > since the anchors are defined in a non-standard way. It shouldn't be name=#boostaligned_storagehpp> but (no > sharp sign). With some quotes, it would be even better, but it's another > problem. OK, that's an error in the shell script I used, easy enough to hack around > Finally, what are "library dependencies"? Sorry if it's a dumb question. > But by looking at the results, I don't get the meaning of it. It's everything that's needed by the complete library - by it's test and example programs etc as well as the headers - for most libraries this means that the Boost.test source will be listed as a dependency for example. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
