Menu
▾
▴
cpp-netlib-devel — Developers Mailing List
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(52) |
Jun
(30) |
Jul
(17) |
Aug
(9) |
Sep
(4) |
Oct
(7) |
Nov
(11) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(1) |
Mar
(37) |
Apr
(28) |
May
(15) |
Jun
(28) |
Jul
(7) |
Aug
(125) |
Sep
(116) |
Oct
(85) |
Nov
(14) |
Dec
(6) |
| 2009 |
Jan
(11) |
Feb
(4) |
Mar
(5) |
Apr
|
May
(9) |
Jun
(5) |
Jul
(4) |
Aug
(40) |
Sep
(1) |
Oct
(19) |
Nov
(43) |
Dec
(45) |
| 2010 |
Jan
(76) |
Feb
(95) |
Mar
(3) |
Apr
(23) |
May
(39) |
Jun
(54) |
Jul
(6) |
Aug
(13) |
Sep
(12) |
Oct
(59) |
Nov
(53) |
Dec
(43) |
| 2011 |
Jan
(43) |
Feb
(44) |
Mar
(25) |
Apr
(23) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(1) |
Nov
(2) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
|
From: Jeroen H. <vex...@gm...> - 2010-01-20 21:50:17
|
Hi, On Wed, Jan 20, 2010 at 22:37, Dean Michael Berris <mik...@gm...> wrote: > On Thu, Jan 21, 2010 at 5:17 AM, Glyn Matthews <gly...@gm...> wrote: >> >> 2010/1/20 Dean Michael Berris <mik...@gm...> >>> >>> On Thu, Jan 21, 2010 at 5:01 AM, Glyn Matthews <gly...@gm...> >>> wrote: >>> > >>> > 2010/1/20 Nelson, Erik - 2 <eri...@ba...> >>> >> >>> >> After I fix that, the next error I get is: >>> >> 1>c:\work\boost\boost/network/uri/http/detail/parse_specific.hpp(74) : >>> >> error C2065: 'not' : undeclared identifier >>> >> >>> >> Adding #include <ciso646> to parse_specific.hpp gets it on the road, >>> >> but >>> >> then I come to something I don't see any obvious answer to: >>> >> >>> >>> It seems that you're using the version in the 'master' branch. Can you >>> try the latest from 0.5-devel? >>> >>> Anyway the "real" fix would be to change 'not' into !. >> >> Just a point about the use of `not` and `or` that have made their way into >> the code, but I had no idea that these were keywords in C++. In fact, IMO >> they're much clearer than writing `!` or `||` etc. but I've never seen >> this. Can anyone explain why they exist but are never used? >> > > I think it's because vendors aren't quick to support them natively in > the compiler. GCC takes this in stride just fine as does other vendors > (Intel's compiler is another one I know that works pretty well). I > would quote the appropriate parts of the C++ standard if I had a copy > (which I promise I should buy someday soon) but anyway it's something > really annoying to me for non-conformant compilers like MSVC. > > I also like them better but unfortunately to support more compilers > we're going to have to stick with !, ||, && et al. > > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > Just found http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B#C.2B.2B_operator_synonyms which is the best explanation I've found so far and quotes the relevant parts in the cite-note I believe. As a side-note, I too prefer `and` over `&&`, though for portability I think we should stick to the latter. Jeroen |
|
From: Glyn M. <gly...@gm...> - 2010-01-20 21:46:18
|
Hi Dean, 2010/1/20 Dean Michael Berris <mik...@gm...> > Hi Glyn! > > On Thu, Jan 21, 2010 at 5:07 AM, Glyn Matthews <gly...@gm...> > wrote: > > Hi Guys, > > > > > > I have made some structural changes to the quickbook sources in my own > fork, > > and I have been able to publish the results on github: > > > > http://glynos.github.com/cpp-netlib/ > > > > This is so cool! I should learn to do this one of these days. :D > Very easy to do, the instructions can be found if you go to a page that doesn't exist, like: http://cpp-netlib.github.com/ > > > The content hasn't changed so much but if Dean and Jeroen are updating > the > > docs, I'd appreciate it if you'd use these changes in my fork (branch > > 0.5-devel). > > > > Definitely. Send me a pull request so I can merge your work into my > branch. I'll take on some housekeeping with the HTTP client example > changes -- we broke backward compatibility in 0.5-devel -- and general > documentation for the HTTP Server documentation. > > > Comments in general about the content are also welcome. > > > > There are some typographical errors that I see, I'll file issues on > your fork's tracker so that we can track those there too. > Yeah, i'm sure there are loads it's always easy to miss them. > > One quick thing is that the marker image doesn't show -- you may have > forgotten to put them images into the appropriate directory. ;) > > The links to the marker images are on boost.org, which don't seem to exist. I don't know how to fix this. > Thanks again for the great effort on the documentation -- I shall > reply in kind soon enough once my consulting work winds down a little. > > OK, thanks. G |
|
From: Dean M. B. <mik...@gm...> - 2010-01-20 21:38:07
|
On Thu, Jan 21, 2010 at 5:17 AM, Glyn Matthews <gly...@gm...> wrote: > > 2010/1/20 Dean Michael Berris <mik...@gm...> >> >> On Thu, Jan 21, 2010 at 5:01 AM, Glyn Matthews <gly...@gm...> >> wrote: >> > >> > 2010/1/20 Nelson, Erik - 2 <eri...@ba...> >> >> >> >> After I fix that, the next error I get is: >> >> 1>c:\work\boost\boost/network/uri/http/detail/parse_specific.hpp(74) : >> >> error C2065: 'not' : undeclared identifier >> >> >> >> Adding #include <ciso646> to parse_specific.hpp gets it on the road, >> >> but >> >> then I come to something I don't see any obvious answer to: >> >> >> >> It seems that you're using the version in the 'master' branch. Can you >> try the latest from 0.5-devel? >> >> Anyway the "real" fix would be to change 'not' into !. > > Just a point about the use of `not` and `or` that have made their way into > the code, but I had no idea that these were keywords in C++. In fact, IMO > they're much clearer than writing `!` or `||` etc. but I've never seen > this. Can anyone explain why they exist but are never used? > I think it's because vendors aren't quick to support them natively in the compiler. GCC takes this in stride just fine as does other vendors (Intel's compiler is another one I know that works pretty well). I would quote the appropriate parts of the C++ standard if I had a copy (which I promise I should buy someday soon) but anyway it's something really annoying to me for non-conformant compilers like MSVC. I also like them better but unfortunately to support more compilers we're going to have to stick with !, ||, && et al. -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-01-20 21:34:04
|
Hi, On Wed, Jan 20, 2010 at 22:07, Glyn Matthews <gly...@gm...> wrote: > Hi Guys, > > > I have made some structural changes to the quickbook sources in my own fork, > and I have been able to publish the results on github: > > http://glynos.github.com/cpp-netlib/ > > The content hasn't changed so much but if Dean and Jeroen are updating the > docs, I'd appreciate it if you'd use these changes in my fork (branch > 0.5-devel). > Gladly, though I have no idea how to pull them into my current fork. > Comments in general about the content are also welcome. > > Glyn > Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-01-20 21:27:24
|
Hi Glyn! On Thu, Jan 21, 2010 at 5:07 AM, Glyn Matthews <gly...@gm...> wrote: > Hi Guys, > > > I have made some structural changes to the quickbook sources in my own fork, > and I have been able to publish the results on github: > > http://glynos.github.com/cpp-netlib/ > This is so cool! I should learn to do this one of these days. :D > The content hasn't changed so much but if Dean and Jeroen are updating the > docs, I'd appreciate it if you'd use these changes in my fork (branch > 0.5-devel). > Definitely. Send me a pull request so I can merge your work into my branch. I'll take on some housekeeping with the HTTP client example changes -- we broke backward compatibility in 0.5-devel -- and general documentation for the HTTP Server documentation. > Comments in general about the content are also welcome. > There are some typographical errors that I see, I'll file issues on your fork's tracker so that we can track those there too. One quick thing is that the marker image doesn't show -- you may have forgotten to put them images into the appropriate directory. ;) Thanks again for the great effort on the documentation -- I shall reply in kind soon enough once my consulting work winds down a little. -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Glyn M. <gly...@gm...> - 2010-01-20 21:17:11
|
Hi, 2010/1/20 Dean Michael Berris <mik...@gm...> > On Thu, Jan 21, 2010 at 5:01 AM, Glyn Matthews <gly...@gm...> > wrote: > > > > 2010/1/20 Nelson, Erik - 2 <eri...@ba...> > >> > >> After I fix that, the next error I get is: > >> 1>c:\work\boost\boost/network/uri/http/detail/parse_specific.hpp(74) : > >> error C2065: 'not' : undeclared identifier > >> > >> Adding #include <ciso646> to parse_specific.hpp gets it on the road, but > >> then I come to something I don't see any obvious answer to: > >> > > It seems that you're using the version in the 'master' branch. Can you > try the latest from 0.5-devel? > > Anyway the "real" fix would be to change 'not' into !. > Just a point about the use of `not` and `or` that have made their way into the code, but I had no idea that these were keywords in C++. In fact, IMO they're much clearer than writing `!` or `||` etc. but I've never seen this. Can anyone explain why they exist but are never used? Thanks, G |
|
From: Dean M. B. <mik...@gm...> - 2010-01-20 21:10:33
|
On Thu, Jan 21, 2010 at 5:01 AM, Glyn Matthews <gly...@gm...> wrote:
>
> 2010/1/20 Nelson, Erik - 2 <eri...@ba...>
>>
>> After I fix that, the next error I get is:
>> 1>c:\work\boost\boost/network/uri/http/detail/parse_specific.hpp(74) :
>> error C2065: 'not' : undeclared identifier
>>
>> Adding #include <ciso646> to parse_specific.hpp gets it on the road, but
>> then I come to something I don't see any obvious answer to:
>>
It seems that you're using the version in the 'master' branch. Can you
try the latest from 0.5-devel?
Anyway the "real" fix would be to change 'not' into !.
>> 1>c:\work\boost\boost/network/uri/http/uri.hpp(36) : error C2597:
>> illegal reference to non-static member
>> 'boost::network::uri::basic_uri<boost::network::tags::http_default_8bit_
>> tcp_resolve>::string_type'
>>
>> It's complaining about this code
>>
>> uint32_t port() const {
>> return parts_.port ? *(parts_.port) :
>> (boost::iequals(parts_.scheme, string_type("https"))
>> ? 443u : 80u);
>> }
>>
>>
>> Am I doing something wrong? Or is this known to be broken right now?
>> I'm using a copy of Dean's code that I pulled down today. Any guidance
>> would be appreciated.
>>
>
> You're not doing anything wrong if all you're doing is trying to build a
> test... we're still short of being release ready but this code hasn't
> changed since 0.4 so I can't explain this error. Dean?
>
Right now I don't have a means of testing on the Windows platform so I
can't diagnose easily.
This looks like a missing typedef in the definition of the basic_uri template.
You can add 'typedef typename string<Tag>::type string_type' at the
start of the basic_uri template. Let me know if that helps.
--
Dean Michael Berris
cplusplus-soup.com | twitter.com/deanberris
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
|
|
From: Glyn M. <gly...@gm...> - 2010-01-20 21:07:58
|
Hi Guys, I have made some structural changes to the quickbook sources in my own fork, and I have been able to publish the results on github: http://glynos.github.com/cpp-netlib/ The content hasn't changed so much but if Dean and Jeroen are updating the docs, I'd appreciate it if you'd use these changes in my fork (branch 0.5-devel). Comments in general about the content are also welcome. Glyn |
|
From: Jeroen H. <vex...@gm...> - 2010-01-20 21:07:38
|
Hi Erik,
On Wed, Jan 20, 2010 at 21:43, Nelson, Erik - 2
<eri...@ba...> wrote:
> Hi there,
>
> I'm playing with the hello_world.cpp (current one in
> mikhailberis-cpp-netlib git) and have a couple of questions. Here's the
> start of my compiler output
>
> 1>http_server.cpp
> 1>Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. For
> example:
> 1>- add -D_WIN32_WINNT=0x0501 to the compiler command line; or
> 1>- add _WIN32_WINNT=0x0501 to your project's Preprocessor Definitions.
> 1>Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target).
> 1>c:\work\boost\boost/network/protocol/http/traits/impl/request_methods.
> ipp(37) : error C2059: syntax error : 'constant'
>
>
> Comments/Questions:
> 1) I know that _WIN32_WINNT is #defined in the jamfile, but I'm curious
> if anyone knows why this warning comes up with cpp-netlib... We use
> boost extensively but have never needed to #define this
> 2) the error comes from
> request_methods.ipp, on line
> static char const * const DELETE = "DELETE";
> Winnt.h #defines DELETE. If I change the offending line in
> request_methods.ipp to 'DELETE_', that seems to fix it
>
> After I fix that, the next error I get is:
> 1>c:\work\boost\boost/network/uri/http/detail/parse_specific.hpp(74) :
> error C2065: 'not' : undeclared identifier
>
> Adding #include <ciso646> to parse_specific.hpp gets it on the road, but
> then I come to something I don't see any obvious answer to:
>
> 1>c:\work\boost\boost/network/uri/http/uri.hpp(36) : error C2597:
> illegal reference to non-static member
> 'boost::network::uri::basic_uri<boost::network::tags::http_default_8bit_
> tcp_resolve>::string_type'
>
> It's complaining about this code
>
> uint32_t port() const {
> return parts_.port ? *(parts_.port) :
> (boost::iequals(parts_.scheme, string_type("https"))
> ? 443u : 80u);
> }
>
>
> Am I doing something wrong? Or is this known to be broken right now?
> I'm using a copy of Dean's code that I pulled down today. Any guidance
> would be appreciated.
>
> Thanks
>
> Erik
>
I've written a patch which might fix the two URI related errors,
though I currently have no way of testing them as I have no Windows
install around, please give them a shot and let me know.
Yours,
Jeroen Habraken
|
|
From: Glyn M. <gly...@gm...> - 2010-01-20 21:01:31
|
Hi Erik,
2010/1/20 Nelson, Erik - 2 <eri...@ba...>
> Hi there,
>
> I'm playing with the hello_world.cpp (current one in
> mikhailberis-cpp-netlib git) and have a couple of questions. Here's the
> start of my compiler output
>
> 1>http_server.cpp
> 1>Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. For
> example:
> 1>- add -D_WIN32_WINNT=0x0501 to the compiler command line; or
> 1>- add _WIN32_WINNT=0x0501 to your project's Preprocessor Definitions.
> 1>Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target).
> 1>c:\work\boost\boost/network/protocol/http/traits/impl/request_methods.
> ipp(37) : error C2059: syntax error : 'constant'
>
>
> Comments/Questions:
> 1) I know that _WIN32_WINNT is #defined in the jamfile, but I'm curious
> if anyone knows why this warning comes up with cpp-netlib... We use
> boost extensively but have never needed to #define this
>
This comes from boost asio (boost/asio/detail/socket_types.hpp), there must
be something in your configuration - the order in which you include
windows.h, perhaps.
> 2) the error comes from
> request_methods.ipp, on line
> static char const * const DELETE = "DELETE";
> Winnt.h #defines DELETE. If I change the offending line in
> request_methods.ipp to 'DELETE_', that seems to fix it
>
Can you submit a patch?
>
> After I fix that, the next error I get is:
> 1>c:\work\boost\boost/network/uri/http/detail/parse_specific.hpp(74) :
> error C2065: 'not' : undeclared identifier
>
> Adding #include <ciso646> to parse_specific.hpp gets it on the road, but
> then I come to something I don't see any obvious answer to:
>
> 1>c:\work\boost\boost/network/uri/http/uri.hpp(36) : error C2597:
> illegal reference to non-static member
> 'boost::network::uri::basic_uri<boost::network::tags::http_default_8bit_
> tcp_resolve>::string_type'
>
> It's complaining about this code
>
> uint32_t port() const {
> return parts_.port ? *(parts_.port) :
> (boost::iequals(parts_.scheme, string_type("https"))
> ? 443u : 80u);
> }
>
>
> Am I doing something wrong? Or is this known to be broken right now?
> I'm using a copy of Dean's code that I pulled down today. Any guidance
> would be appreciated.
>
>
You're not doing anything wrong if all you're doing is trying to build a
test... we're still short of being release ready but this code hasn't
changed since 0.4 so I can't explain this error. Dean?
G
|
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-01-20 20:43:59
|
Hi there,
I'm playing with the hello_world.cpp (current one in
mikhailberis-cpp-netlib git) and have a couple of questions. Here's the
start of my compiler output
1>http_server.cpp
1>Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. For
example:
1>- add -D_WIN32_WINNT=0x0501 to the compiler command line; or
1>- add _WIN32_WINNT=0x0501 to your project's Preprocessor Definitions.
1>Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target).
1>c:\work\boost\boost/network/protocol/http/traits/impl/request_methods.
ipp(37) : error C2059: syntax error : 'constant'
Comments/Questions:
1) I know that _WIN32_WINNT is #defined in the jamfile, but I'm curious
if anyone knows why this warning comes up with cpp-netlib... We use
boost extensively but have never needed to #define this
2) the error comes from
request_methods.ipp, on line
static char const * const DELETE = "DELETE";
Winnt.h #defines DELETE. If I change the offending line in
request_methods.ipp to 'DELETE_', that seems to fix it
After I fix that, the next error I get is:
1>c:\work\boost\boost/network/uri/http/detail/parse_specific.hpp(74) :
error C2065: 'not' : undeclared identifier
Adding #include <ciso646> to parse_specific.hpp gets it on the road, but
then I come to something I don't see any obvious answer to:
1>c:\work\boost\boost/network/uri/http/uri.hpp(36) : error C2597:
illegal reference to non-static member
'boost::network::uri::basic_uri<boost::network::tags::http_default_8bit_
tcp_resolve>::string_type'
It's complaining about this code
uint32_t port() const {
return parts_.port ? *(parts_.port) :
(boost::iequals(parts_.scheme, string_type("https"))
? 443u : 80u);
}
Am I doing something wrong? Or is this known to be broken right now?
I'm using a copy of Dean's code that I pulled down today. Any guidance
would be appreciated.
Thanks
Erik
|
|
From: Dean M. B. <mik...@gm...> - 2010-01-20 08:56:00
|
On Wed, Jan 20, 2010 at 4:35 AM, Jeroen Habraken <vex...@gm...> wrote: > > FYI, committed HTTP support. > Cool! > All the initial tests now run, and only the one testing whether > "http://www-.boost.org/" is invalid fails. It turns out the hostname > is valid according to the URI specification, but it's considered > invalid by DNS. Thus when using another name lookup provider such as > the hosts file -/etc/hosts on linux-, it is valid, but I'll have to > double check this. > Oh, if it's valid according to the URI specification then we should be fine. We can change the docs and the tests to say that we're accepting these types of URI's but that the DNS system may not be happy with "malformed" FQDN's. Thanks Jeroen! Hopefully I'll get a pull request to merge soon. -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-01-19 20:36:14
|
On Tue, Jan 19, 2010 at 16:38, Dean Michael Berris <mik...@gm...> wrote: > On Tue, Jan 19, 2010 at 11:29 PM, Jeroen Habraken <vex...@gm...> wrote: >> >> On Tue, Jan 19, 2010 at 15:51, Dean Michael Berris >> <mik...@gm...> wrote: >>> >>> When do you expect this to be available? I'm curious to see how that's >>> going to shape up granted that there's no more way to customize the >>> parsing of the specific parts. >> >> I've nearly got this working, so either today or tomorrow I hope. >> > > Cool. :) > >>>> - The parser doesn't have support for IP's yet, thus >>>> scheme://localhost/ works, scheme://127.0.0.1/ doesn't, whilst both >>>> are valid >>> >>> These were valid before IIRC and there must be tests to show that they >>> are supported. >> >> They are indeed valid, but I've not written the parser rules for them. >> I shall add a couple of tests reflecting this. >> > > That would be great. :) > >>> >>> I would better prefer that there be tests written first before any >>> work is done so that I can look at the tests and see whether the >>> feature to be added makes sense. The way I do it is I force test >>> failures first before I go write functionality. >>> >>> Please look up Test Driven Development and see if you can follow that >>> process instead. For one thing I will not commit a merge if tests are >>> failing. >> >> Yes, and I'm aware of TDD, but unfamiliar with Boost.Test. There are a >> couple of tests I've written outside the framework which need to be >> merged, for this I'll have to look into Boost.Test though (not that >> that's a bad thing). >> > > Oh Boost.Test is sooooo easy compared to xUnit testing that it's even > a joke I even invested the time to learn the xUnit tests. Anyway I'm > looking forward to the tests. :) > >>> >>> Alright, but I see that 'rest()' was removed too. The value of getting >>> the raw scheme-specific part of a URI is something I personally >>> require and prefer be still there. >> >> The newer RFC (http://www.ietf.org/rfc/rfc3986.txt) which deprecates >> RFC1738 has no notion of a scheme-specfic-part, which makes this >> rather hard. Could you please explain why you need it? >> > > For logging purposes, it's more efficient to just get the stuff after > the ":". I guess it would be better if I log the raw string instead. > > Since we're moving to the newer RFC then that should be alright. ;) > >>> This is the main reason why I put that protocol()/scheme() and rest() >>> functions in the basic_uri type. The raw() accessor should also be >>> there so that a URI's raw string representation can be retrieved even >>> after the parts have been parsed already. >> >> I don't believe it was there initially, but it's trivial to add and makes sense. >> > > Yes indeed. I've been meaning to do this but I haven't gotten around > to doing it. :) > >>> Thanks for putting in the work and I hope this helps! >>> >> >> I know this is a rather large overhaul which influences the whole >> library, please bear with me and thank you for the response. >> > > No worries, as long as it's not broken then it's something that's > worth the investment, it's definitely welcome. :) > > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > FYI, committed HTTP support. All the initial tests now run, and only the one testing whether "http://www-.boost.org/" is invalid fails. It turns out the hostname is valid according to the URI specification, but it's considered invalid by DNS. Thus when using another name lookup provider such as the hosts file -/etc/hosts on linux-, it is valid, but I'll have to double check this. Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-01-19 15:39:13
|
On Tue, Jan 19, 2010 at 11:29 PM, Jeroen Habraken <vex...@gm...> wrote: > > On Tue, Jan 19, 2010 at 15:51, Dean Michael Berris > <mik...@gm...> wrote: >> >> When do you expect this to be available? I'm curious to see how that's >> going to shape up granted that there's no more way to customize the >> parsing of the specific parts. > > I've nearly got this working, so either today or tomorrow I hope. > Cool. :) >>> - The parser doesn't have support for IP's yet, thus >>> scheme://localhost/ works, scheme://127.0.0.1/ doesn't, whilst both >>> are valid >> >> These were valid before IIRC and there must be tests to show that they >> are supported. > > They are indeed valid, but I've not written the parser rules for them. > I shall add a couple of tests reflecting this. > That would be great. :) >> >> I would better prefer that there be tests written first before any >> work is done so that I can look at the tests and see whether the >> feature to be added makes sense. The way I do it is I force test >> failures first before I go write functionality. >> >> Please look up Test Driven Development and see if you can follow that >> process instead. For one thing I will not commit a merge if tests are >> failing. > > Yes, and I'm aware of TDD, but unfamiliar with Boost.Test. There are a > couple of tests I've written outside the framework which need to be > merged, for this I'll have to look into Boost.Test though (not that > that's a bad thing). > Oh Boost.Test is sooooo easy compared to xUnit testing that it's even a joke I even invested the time to learn the xUnit tests. Anyway I'm looking forward to the tests. :) >> >> Alright, but I see that 'rest()' was removed too. The value of getting >> the raw scheme-specific part of a URI is something I personally >> require and prefer be still there. > > The newer RFC (http://www.ietf.org/rfc/rfc3986.txt) which deprecates > RFC1738 has no notion of a scheme-specfic-part, which makes this > rather hard. Could you please explain why you need it? > For logging purposes, it's more efficient to just get the stuff after the ":". I guess it would be better if I log the raw string instead. Since we're moving to the newer RFC then that should be alright. ;) >> This is the main reason why I put that protocol()/scheme() and rest() >> functions in the basic_uri type. The raw() accessor should also be >> there so that a URI's raw string representation can be retrieved even >> after the parts have been parsed already. > > I don't believe it was there initially, but it's trivial to add and makes sense. > Yes indeed. I've been meaning to do this but I haven't gotten around to doing it. :) >> Thanks for putting in the work and I hope this helps! >> > > I know this is a rather large overhaul which influences the whole > library, please bear with me and thank you for the response. > No worries, as long as it's not broken then it's something that's worth the investment, it's definitely welcome. :) -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-01-19 15:30:17
|
Hi, A few quick responses, On Tue, Jan 19, 2010 at 15:51, Dean Michael Berris <mik...@gm...> wrote: > Hi Jeroen, > > On Tue, Jan 19, 2010 at 1:08 AM, Jeroen Habraken <vex...@gm...> wrote: >> >> I just pushed a major rewrite of the URI parser to my github fork, and >> there are a couple of things to take into consideration for the >> moment. Also, Dean, could you please verify I pushed it to the right >> branch and everything this time. >> > > I see it in your 0.5-devel branch. Hopefully that'd be easier to merge > into my 0.5-devel branch but I have a few concerns. > >> Here's a quick list, in no specific order: >> - HTTP support is broken at the moment, which breaks a lot of other >> code, this should be fixed soon and is a priority. > > When do you expect this to be available? I'm curious to see how that's > going to shape up granted that there's no more way to customize the > parsing of the specific parts. I've nearly got this working, so either today or tomorrow I hope. >> - The parser doesn't have support for IP's yet, thus >> scheme://localhost/ works, scheme://127.0.0.1/ doesn't, whilst both >> are valid > > These were valid before IIRC and there must be tests to show that they > are supported. They are indeed valid, but I've not written the parser rules for them. I shall add a couple of tests reflecting this. >> - A lot more tests need to be added > > I would better prefer that there be tests written first before any > work is done so that I can look at the tests and see whether the > feature to be added makes sense. The way I do it is I force test > failures first before I go write functionality. > > Please look up Test Driven Development and see if you can follow that > process instead. For one thing I will not commit a merge if tests are > failing. Yes, and I'm aware of TDD, but unfamiliar with Boost.Test. There are a couple of tests I've written outside the framework which need to be merged, for this I'll have to look into Boost.Test though (not that that's a bad thing). >> - There's been an API change, protocol() has been renamed to scheme() >> as it's what the name the RFC uses, and according to Wikipedia scheme >> and protocol are two different things > > Alright, but I see that 'rest()' was removed too. The value of getting > the raw scheme-specific part of a URI is something I personally > require and prefer be still there. The newer RFC (http://www.ietf.org/rfc/rfc3986.txt) which deprecates RFC1738 has no notion of a scheme-specfic-part, which makes this rather hard. Could you please explain why you need it? > This is the main reason why I put that protocol()/scheme() and rest() > functions in the basic_uri type. The raw() accessor should also be > there so that a URI's raw string representation can be retrieved even > after the parts have been parsed already. I don't believe it was there initially, but it's trivial to add and makes sense. >> - Documentation needs to be updated, and an the example should be >> expanded to show the use of scheme() for example > > Yes, if you can do that too before I merge your work that would be > most appreciated too. Sure. >> - Another API change is coming up, which will expose the optional >> parameters as boost::optionals, instead of returning an empty default >> value >> > > Please update the tests and documentation to show that things have changed. Of course. > Thanks for putting in the work and I hope this helps! > > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > I know this is a rather large overhaul which influences the whole library, please bear with me and thank you for the response. Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-01-19 14:52:19
|
Hi Jeroen, On Tue, Jan 19, 2010 at 1:08 AM, Jeroen Habraken <vex...@gm...> wrote: > > I just pushed a major rewrite of the URI parser to my github fork, and > there are a couple of things to take into consideration for the > moment. Also, Dean, could you please verify I pushed it to the right > branch and everything this time. > I see it in your 0.5-devel branch. Hopefully that'd be easier to merge into my 0.5-devel branch but I have a few concerns. > Here's a quick list, in no specific order: > - HTTP support is broken at the moment, which breaks a lot of other > code, this should be fixed soon and is a priority. When do you expect this to be available? I'm curious to see how that's going to shape up granted that there's no more way to customize the parsing of the specific parts. > - The parser doesn't have support for IP's yet, thus > scheme://localhost/ works, scheme://127.0.0.1/ doesn't, whilst both > are valid These were valid before IIRC and there must be tests to show that they are supported. > - A lot more tests need to be added I would better prefer that there be tests written first before any work is done so that I can look at the tests and see whether the feature to be added makes sense. The way I do it is I force test failures first before I go write functionality. Please look up Test Driven Development and see if you can follow that process instead. For one thing I will not commit a merge if tests are failing. > - There's been an API change, protocol() has been renamed to scheme() > as it's what the name the RFC uses, and according to Wikipedia scheme > and protocol are two different things Alright, but I see that 'rest()' was removed too. The value of getting the raw scheme-specific part of a URI is something I personally require and prefer be still there. This is the main reason why I put that protocol()/scheme() and rest() functions in the basic_uri type. The raw() accessor should also be there so that a URI's raw string representation can be retrieved even after the parts have been parsed already. > - Documentation needs to be updated, and an the example should be > expanded to show the use of scheme() for example Yes, if you can do that too before I merge your work that would be most appreciated too. > - Another API change is coming up, which will expose the optional > parameters as boost::optionals, instead of returning an empty default > value > Please update the tests and documentation to show that things have changed. Thanks for putting in the work and I hope this helps! -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-01-18 17:08:31
|
Hi everyone, I just pushed a major rewrite of the URI parser to my github fork, and there are a couple of things to take into consideration for the moment. Also, Dean, could you please verify I pushed it to the right branch and everything this time. Here's a quick list, in no specific order: - HTTP support is broken at the moment, which breaks a lot of other code, this should be fixed soon and is a priority. - The parser doesn't have support for IP's yet, thus scheme://localhost/ works, scheme://127.0.0.1/ doesn't, whilst both are valid - A lot more tests need to be added - There's been an API change, protocol() has been renamed to scheme() as it's what the name the RFC uses, and according to Wikipedia scheme and protocol are two different things - Documentation needs to be updated, and an the example should be expanded to show the use of scheme() for example - Another API change is coming up, which will expose the optional parameters as boost::optionals, instead of returning an empty default value Jeroen Habraken |
|
From: Dean M. B. <mik...@gm...> - 2010-01-12 17:53:03
|
On Wed, Jan 13, 2010 at 12:32 AM, Nelson, Erik - 2 <eri...@ba...> wrote: > Dean Michael Berris wrote: >> >> Thanks for the interest and I hope this helps! > > Thanks much to both you and Glyn... This is one project that I've been > watching for a while and hope it can get into boost. > You're welcome! :) -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-01-12 16:33:04
|
Dean Michael Berris wrote: > You may not have to wait that long though, you can check out the > 0.5-devel branch, and take a look at the example that's included in > the test directory of an HTTP server that responds "Hello, World!" to > any query sent it: > > > http://github.com/mikhailberis/cpp-netlib/blob/0.5-devel/libs/network/te st/hello_world.cpp > > Thanks for the interest and I hope this helps! Thanks much to both you and Glyn... This is one project that I've been watching for a while and hope it can get into boost. |
|
From: Dean M. B. <mik...@gm...> - 2010-01-12 16:14:12
|
Hi Erik, On Tue, Jan 12, 2010 at 5:18 PM, Glyn Matthews <gly...@gm...> wrote: > Hi Erik, > > 2010/1/11 Nelson, Erik - 2 <eri...@ba...> >> >> I'm interested in checking out cpp-netlib, similar to what Matt Trentini >> mentioned in May 2009. I've seen the mention recently of a HTTP server >> example but I haven't been able to locate the example that Dean has >> mentioned he's working on (derived from asio example 3 if I remember >> correctly). Can I talk you into putting something out there or pointing >> me in the right direction if I'm missing it? >> > > You don't need to talk us into this ;) In the next few weeks we intend to > have an HTTP server example and this is scheduled to be included in the 0.5 > release. Contributions are, of course, welcome. > You may not have to wait that long though, you can check out the 0.5-devel branch, and take a look at the example that's included in the test directory of an HTTP server that responds "Hello, World!" to any query sent it: http://github.com/mikhailberis/cpp-netlib/blob/0.5-devel/libs/network/test/hello_world.cpp Thanks for the interest and I hope this helps! -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Glyn M. <gly...@gm...> - 2010-01-12 09:18:28
|
Hi Erik, 2010/1/11 Nelson, Erik - 2 <eri...@ba...> > I'm interested in checking out cpp-netlib, similar to what Matt Trentini > mentioned in May 2009. I've seen the mention recently of a HTTP server > example but I haven't been able to locate the example that Dean has > mentioned he's working on (derived from asio example 3 if I remember > correctly). Can I talk you into putting something out there or pointing > me in the right direction if I'm missing it? > > You don't need to talk us into this ;) In the next few weeks we intend to have an HTTP server example and this is scheduled to be included in the 0.5 release. Contributions are, of course, welcome. Regards, Glyn |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-01-11 18:48:36
|
I'm interested in checking out cpp-netlib, similar to what Matt Trentini mentioned in May 2009. I've seen the mention recently of a HTTP server example but I haven't been able to locate the example that Dean has mentioned he's working on (derived from asio example 3 if I remember correctly). Can I talk you into putting something out there or pointing me in the right direction if I'm missing it? Thanks Erik |
|
From: Dean M. B. <mik...@gm...> - 2010-01-10 20:34:23
|
On Mon, Jan 11, 2010 at 3:14 AM, Jeroen Habraken <vex...@gm...> wrote: > On Sun, Jan 10, 2010 at 20:02, Dean Michael Berris >> >> I'll look at addressing the HTTP 1.1 test issues if I can. The build >> time and resource requirements are really a little disturbing to me, >> but then I think that is the nature of the beast that is C++ and C++ >> template metaprogramming. Currently it's not high up on my list >> because I'm concentrating on implementing functionality first rather >> than optimizing the build/test times -- but maybe it has come to the >> point where the limits of GCC is being hit by just the sheer amount of >> code we include when boost/network.hpp is included. > > The main reason of starting this discussion was that I was seeing the > same thing happening to my new URI code as it progressed, with the > beautiful but humongous beast that Spirit is. > Yes, I'm working on something locally that attempts to address this. I've broken up the includes of the Spirit sources and the build times are significantly lower. I'll see if I can reduce this much farther locally first before pushing to github. (BTW, am working on 0.5-devel, just a heads up.) More from me later. :) -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-01-10 19:14:41
|
On Sun, Jan 10, 2010 at 20:02, Dean Michael Berris <mik...@gm...> wrote: > On Mon, Jan 11, 2010 at 2:44 AM, Jeroen Habraken <vex...@gm...> wrote: >> On Sun, Jan 10, 2010 at 19:29, Dean Michael Berris >> <mik...@gm...> wrote: >>> >>> Thanks, I'm applying and pushing the code as soon as the tests all pass. >> >> A checkout of the master seems to pass all tests here on my machine, >> Linux x86 with GCC 4.4.2. >> > > I meant after I applied the patch. :) It's in branch 0.5-devel now. > >>> That reminds me, we should be testing this code especially because we ship it. >> >> Very much so, though I'm noticing that compiling the tests is quite >> resource intensive. I've had GCC eat up more than half of my gigabyte >> of RAM, with the HTTP 1.1 tests taken more than a couple of minutes. >> > > Yes, I see the same thing. > > I'll look at addressing the HTTP 1.1 test issues if I can. The build > time and resource requirements are really a little disturbing to me, > but then I think that is the nature of the beast that is C++ and C++ > template metaprogramming. Currently it's not high up on my list > because I'm concentrating on implementing functionality first rather > than optimizing the build/test times -- but maybe it has come to the > point where the limits of GCC is being hit by just the sheer amount of > code we include when boost/network.hpp is included. The main reason of starting this discussion was that I was seeing the same thing happening to my new URI code as it progressed, with the beautiful but humongous beast that Spirit is. > It may be time for me to modularize the includes and hopefully I get > some motivation to do that *soon*. ;) > > I'll add issues to the implementation -- if you have any issues and > feel like logging them in please feel free to do so (and this applies > to everyone too: http://github.com/mikhailberis/cpp-netlib/issues). > > Have a good one and I hope this helps! You too, and thanks again! > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-01-10 19:02:56
|
On Mon, Jan 11, 2010 at 2:44 AM, Jeroen Habraken <vex...@gm...> wrote: > On Sun, Jan 10, 2010 at 19:29, Dean Michael Berris > <mik...@gm...> wrote: >> >> Thanks, I'm applying and pushing the code as soon as the tests all pass. > > A checkout of the master seems to pass all tests here on my machine, > Linux x86 with GCC 4.4.2. > I meant after I applied the patch. :) It's in branch 0.5-devel now. >> That reminds me, we should be testing this code especially because we ship it. > > Very much so, though I'm noticing that compiling the tests is quite > resource intensive. I've had GCC eat up more than half of my gigabyte > of RAM, with the HTTP 1.1 tests taken more than a couple of minutes. > Yes, I see the same thing. I'll look at addressing the HTTP 1.1 test issues if I can. The build time and resource requirements are really a little disturbing to me, but then I think that is the nature of the beast that is C++ and C++ template metaprogramming. Currently it's not high up on my list because I'm concentrating on implementing functionality first rather than optimizing the build/test times -- but maybe it has come to the point where the limits of GCC is being hit by just the sheer amount of code we include when boost/network.hpp is included. It may be time for me to modularize the includes and hopefully I get some motivation to do that *soon*. ;) I'll add issues to the implementation -- if you have any issues and feel like logging them in please feel free to do so (and this applies to everyone too: http://github.com/mikhailberis/cpp-netlib/issues). Have a good one and I hope this helps! -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
7 messages has been excluded from this view by a project administrator.
