- Boost - lists.preview.boost.org

Re: Three questions about the new license
by David Abrahams 17 Feb '04

17 Feb '04

"Diane Cabell" <dcabell(a)law.harvard.edu> writes: > "David Abrahams" <dave(a)boost-consulting.com> wrote: >> >> Diane, I want to clarify something you may have missed: the point in >> question does not concern the Boost license itself, but the way in >> which our source files declare the license to be applicable to them. >> They do not contain a copy of the license, but instead make reference >> to it in a comment, typically: >> >> // Copyright David Abrahams 2004. Use, modification and distribution is >> // subject to the Boost Software License, Version 1.0. (See accompanying >> // file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) > > No, I didn't understand that. > > You could just say > // Copyright David Abrahams 2004 and made available subject to the terms of > Boost Software License, > // Version 1.0. (See accompanying > // file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) > Thanks, that seems less prone to misinterpretation to me also. Would // Copyright David Abrahams 2004. Distributed under the Boost // Software License, Version 1.0. (See accompanying file // LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) do just as well? It's just just a little less wordy -- "made available subject ot the terms of" sticks in my craw a bit. > (....) >> > David Abrahams wrote: >> > >>(....) >> >> Ugh I don't think we ever considered that "display" would be >> interpreted other than to mean "display publicly". Does that mean >> that in the license: >> >> Permission is hereby granted, free of charge, to any person or >> organization obtaining a copy of the software and accompanying >> documentation covered by this license (the "Software") to use, >> reproduce, display, distribute, execute, and transmit the >> Software, and to prepare derivative works of the Software, and to >> permit third-parties to whom the Software is furnished to do so, >> all subject to the following: >> >> "display" ought to be "display publicly"? > > Yes. But again, private display doesn't require permission, so a > court would likely interpret this to language to mean "public > display." If it went to court, you'd get to testify as to that > intention. So IIUC, changing the license wording isn't critical. We should probably wait 'till a critical issue comes up before making any non-critical changes. >> This is what makes me think you might have missed the fact that "use, >> modification and distribution" isn't in the license itself. The >> suggestion is that "use, modification and distribution" be removed >> from source files to avoid having to repeat all the rights named in >> the license. > > Yes, I did miss that. I think it will be solved by deleting reference to > any specific rights in the comment. Great. >> >> (....) >> >> Sorry, I think I was just bringing up a linguistic technicality. >> >> These are all copyrightable files. The question is whether a *thing* >> >> can be subject to a license, or only actions that might be performed >> >> on that thing. That's why I suggested "licensed under ... " instead >> >> of "subject to ... ". >> > >> > Copyright licenses copying; patents protect operations. Since patent >> > rights were only recently recognized for pure software, the line is >> > not really clear in a lot of cases. Interpretation of the licenses >> > isn't just limited to the linuisitics, however, but looks at the >> > purpose the agreement is trying to accomplish, what people in the >> > trade normally intend to happen in such situations, etc. >> >> I'm not sure how to apply that information to our situation. My >> remark about "subject to" was akin to saying "I think you're using a >> noun as a verb; here's a way to phrase it that avoids grammatical >> problems." > > Then I still don't understand your query. The file is a thing and you are > licensing rights to use the thing. The rights are verbs, permitting people > (or machines) to perform certain activities using the thing. Both of them > are subject to the license. I think we're OK. Maybe Devin has another > perspective. > dc Great, thanks for all your help. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Serialization16 - xml_oarchive std::string representation
by Jeff Flinn 17 Feb '04

17 Feb '04

Robert, Knowing next to nothing about xml, I'm surprised by xml archive file that I've generated which expresses std::string as in the following example: <item> <count>3</count> <item>65</item> <item>108</item> <item>108</item> </item> which corresponds to std::string("All") Is this intended? Is this representation configurable? The demo_file.xml does not use this representation, rather it generates strings in the form: <street1>24th Street</street1> Needless to say the former representation is not very space efficient. For a text archive of 1.2MB I get an xml archive 21.5MB. I am unable to compile(VC7.1) the demo_xml_save project with the following error: Compiling... demo_xml_save.cpp c:\boost\boost_1_31_0\libs\serialization\example\demo_xml_save.cpp(20) : fatal error C1055: compiler limit : out of keys Thanks, Jeff

1 0

mistake in filesystem documentation
by Janusz Piwowarski 17 Feb '04

17 Feb '04

Hello In operations.hpp documentation there is boost::maxint_t file_size() instead of boost::intmax_t . Regards, Janusz

2 1

having a variable act as a function call
by Noel Yap 17 Feb '04

17 Feb '04

I'd like to have a variable act as a function call. For example: Foo& getFoo(); foo; // really calls getFoo Is there a boost way to do this? Thanks, Noel -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

3 3

RE: [boost] Re: Future of threads (III)
by Hurd, Matthew 17 Feb '04

17 Feb '04

> On Behalf Of Matthew Vogt > Allowing the use of asynchronous I/O seems to break the abstraction, which > leaves me wondering why the object should be active? (This is in the > context > of *local* objects, BTW - if the object is remote there is very little > difference between a client/server solution and one using active objects, > is > there?) > > Apologies in advance if I'm not getting something obvious... > > Matt > I think you're confusing the reference to asynch i/o I made, or I'm confused. Recent form would suggest the latter ;-) I was suggesting that a future value is a bit like asynch i/o. I meant that in the sense that with asynch i/o you request something get on with your life and react to it later. A future works like this too, but a little more indirectly, your future is your handler mechanism. You call your function/method which returns a future, say boost::future< double >. When you go to use your future if the value is not yet available then it blocks waiting until it is. If it is available then you use it. This would fit with an active object pattern where the method call returns a result quite nicely, especially if futures where compatible with triggering results on to the queues of other active objects. Though I think the asynch design approach is superior in performance, the semantics of a synchronous approach are often clearer as it looks like a traditional serial program. This would lead to a cute pattern that I haven't seen or thought of before where you get a future value from an active object, but call a method on another active object with that future value ad infinitum and the results just percolate through. :-) Sounds neat but a little impractical I think. The traditional call a method on the Active object and have the results percolate through the pre-allocated workflow of queues and active objects makes a lot more sense. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

RE: [boost] Re: Re: Future of threads (III)
by Hurd, Matthew 17 Feb '04

17 Feb '04

> On Behalf Of scott > Subject: RE: [boost] Re: Re: Future of threads (III) > Do you guys have any thoughts on how to "get work into" the > class (now that it is truly a running thread)? Cos this is > the essence of what an AO is. I think :-) > > Cheers, > Scott > AO's should either have a queue for work or hook into a queue. They are a bit like a worker pool with one worker ;-) Another idiom is a future value, where you ask for a value and don't block until you "read" the value. ACE also has an implementation of this. You can think of it as a bit like overlapped I/O. I also advocate a different architectural neutral style where you can have things at look like function calls that can be: 1. a function call 2. a call to queue work pool or active object 3. an IPC mechanism for same machine transfer, e.g. shared memory 4. a network mechanism, TCP, UDP, TIB or something, for If it can be enabled by a policy driven approach then you can change the architecture of your application by simply changing policies. I think David Abraham's named parameters could help greatly with this approach, along with the serialization lib for marshalling support. This should provide a solid basis for this. I've also thought that perhaps boost::signals might be the correct approach to take for this but I'm unsure. To support this approach you also need mutex aspects that are also policy driven. I am preparing to submit such locking that builds on the existing mutexes and locks. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

4 5

FW: [boost] Re: Re: Future of threads (III)
by scott 17 Feb '04

17 Feb '04

forwarding to boost on the assumption that it was your intention. apologies if i got that wrong. -----Original Message----- From: scott [mailto:scottw@qbik.com] Sent: Tuesday, February 17, 2004 4:42 PM To: 'Jody Hagins' Subject: RE: [boost] Re: Re: Future of threads (III) > -----Original Message----- > From: Jody Hagins [mailto:jody-boost-011304@atdesk.com] > > > The "typical" (i.e., most commonly implemented) method is to use a > thread-safe message queue, coupled with a condition variable. While > there are messages to be processed, the "active object" pulls > them from > the messages queue, and responds appropriately (the AO > specific logic). > When there are no messages available, the AO sits on the condition > variable, awaiting an indication of the arrival of a new > message. I am > sure you understand this, but I could not figure out any other > interpretation of your question... I was responding to your mentioning of the "future" mechanism. Its a perfectly valid mechanism but I was trying to build a case for an implementation of boost::active_object that would never use it. > > I suggest that notions of "function call" should be exorcised from > > discussions that are targeting active objects. That type of thinking > > is perfectly valid in some other thread (oops) but can scuttle work > > targeting active objects; the behaviour (i.e. the code) is > inherently > > in the object. > > > > a client can only submit "worker orders" or "Method Requests" or > > jobs or messages or signals. > > > > I hope there is enough there to make a case :-) > > > I think what you are saying is right in line with traditional methods > for implementing an AO, but I thought we were trying to find alternate > methods, unless I mistakenly misinterpreted the preceeding > communications. > Well, I've learnt to not take anything I send too seriously. These days I am happy if I get the spelling right. I can imagine that there are many approaches to application of the ActiveObject pattern. What I am trying to do so badly is steer discussions away from certain directions. Technically they may be completely justifiable. Strangely I have seen well intentioned implementations of AOs go down some of these paths and the result is not what anyone wants. And nobody really knows where it wandered off target. Personally I believe that what people (developers) _really_ want is the ability to conveniently right a bunch of code fragments that are executed in response to some event (e.g. reception of a message). The collecton of fragments is "the active object". We want the environment to take care of all the nasties such as multi-threading, temporary storage of messages (queueing), routing of message to code fragment and calling of code (passing parameters from message). I think the most insidious error in previous developments has been the assumption of an equivalence between the message sent and a specific function call. Once this assumption is tossed out, implementation becomes more sane and the result is what was targeted. Or closer anyhow :-) The collection of code fragments is the active object. The collection of messages exchanged is a protocol. Until these concepts are to the fore (rather than synchronous, procedural type concepts) then any implementation of boost::active_object will tread the path that others have. actually i have no doubt it would result in something amazing; just not what i was hoping for in an active object :-) > Drinking is not a spectator sport. Cin cin, Scott

2 1

FC++ Lambda
by Darren Cook 17 Feb '04

17 Feb '04

Hi, I've read the lambda sections of the FC++ docs, and the paper on the subject, and am a bit confused how to use it. Could you show the FC++ equivalents of these BLL examples: 1. (from the paper) int a[]={5,3,8,4}; std::for_each(a,a+4,std::cout<<_1<<"\n"); 2. int a[]={5,3,8,4}; std::for_each(a,a+4,std::cout<<constant("v=")<<_1<<"\n"); 3. (a vector of MyClass pointers) std::for_each( tests.begin(), tests.end(), bind(&MyClass::save,_1,f) ); 4. std::for_each( tests.begin(), tests.end(), bind(delete_ptr(), _1) ); 5. (in a spirit parser) Node= +( (+range_p('A','Z'))[bind(&MyClass::on_name, this, _1,_2)] >> +( ch_p('[') >> (*(anychar_p-']'))[bind(&MyClass::on_value, this, _1,_2)] >> ch_p(']') ) ); Darren *: For each I'm doing something like: #include <boost/lambda/lambda.hpp> #include <boost/lambda/bind.hpp> #include <boost/lambda/construct.hpp> using namespace boost::lambda;

2 3

Boost on tandem
by Hurd, Matthew 17 Feb '04

17 Feb '04

Any experience out there with this? Regards, Matt Hurd IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

[Boost-bugs] [ boost-Bugs-898333 ] Boost.Build fails with Dev-Cpp
by SourceForge.net 16 Feb '04

16 Feb '04

Bugs item #898333, was opened at 2004-02-16 14:05 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=898333&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Boost.Build fails with Dev-Cpp Initial Comment: Boost.Build fails to build correctly with a bare install of the Dev-Cpp environment (http://www.bloodshed.net/devcpp.html) which is an IDE with a mingw gcc backend. There are two aspects to the problem: 1. Supplying MINGW_INCLUDE_DIRECTORY to bjam does not yield the necessary -isystem directives to the gcc invocations. 2. [More general] The environment-derived path to the archiver executable may contain spaces, but is not escaped when the archiver is invoked. Matt Vogt (mvogt(a)juptech.com) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=898333&group_i… ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0