cpp-netlib-devel

[cpp-netlib-devel] Branching to Implement HTTP 1.0

[Dean M. B. <mik...@gm...>]

Hi Guys,

I know, it's been a while. However now I just got myself a spanking
new machine on which I can do the development of the network library
on -- without having to interfere with the work I do. This gives me a
reason to 1) go home earlier and 2) develop the network library more.

Now that I'm pretty much setting up the dispatcher library I've been
working on for review in the near future (am waiting for a
considerably important enhancement to Boost.Function to get that
going, while it's not there yet I'm setting my eyes on low hanging
fruit) I'm looking forward to getting some things done quickly as far
as the network library is concerned.

I certainly hope interest hasn't waned yet. I know mine hasn't, and I
just hope we can get at least 1.0 released before the end of the year.

As for the subject, I'm not an SVN expert -- do you guys know how to
branch, switch to the branch, continue developing code there (possibly
broken stuff), and then later merge back the changes to trunk? And
what do you suggest for the branching convention, so that those who
are interested in branching off and working on stuff will be able to
do so without having to deal with too many issues later?

I hope to be able to check in the (crude) HTTP 1.0 client
implementation in a while. I'll send another email when I'm done. For
the meantime, I'm going to be checking code into the trunk, of course
still making sure that the tests aren't broken.

Have a great day everyone (evening from here), and I certainly hope to
hear from you soon!

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mik...@gm...]
[+63 928 7291459]
[+1 408 4049523]

Re: [cpp-netlib-devel] Branching to Implement HTTP 1.0

[Glyn M. <gly...@gm...>]

Hi Dean,

On 08/10/2007, Dean Michael Berris <mik...@gm...> wrote:

I certainly hope interest hasn't waned yet. I know mine hasn't, and I
just hope we can get at least 1.0 released before the end of the year.
Interest hasn't waned ;)  I'm glad to see something happening.

As for the subject, I'm not an SVN expert -- do you guys know how to
> branch, switch to the branch, continue developing code there (possibly
> broken stuff), and then later merge back the changes to trunk? And
> what do you suggest for the branching convention, so that those who
> are interested in branching off and working on stuff will be able to
> do so without having to deal with too many issues later?


For such a small group as ourselves, I'm comfortable with the standard SVN
convention for branches, with (as far as is possible) branches representing
distinct tasks:

|- cpp-netlib
  |- trunk
  |- branches
    |- http
    |- dns
    |- other_clever_stuff
  |- tags

I think the naming of the branches should represent the tasks rather than
the identity of the person working on it.  As for integration, maybe this
responsibility could be given to one individual who people would notify when
their branch is stable.  They would identify any problems and use the SF
tracker to update the relevant people of breakages.  I don't think this will
be a huge amount of work.


> I hope to be able to check in the (crude) HTTP 1.0 client
> implementation in a while. I'll send another email when I'm done. For
> the meantime, I'm going to be checking code into the trunk, of course
> still making sure that the tests aren't broken.


That's OK for now, since there's really only your own branch being worked
on.

Have a great day everyone (evening from here), and I certainly hope to
> hear from you soon!


Good to hear from you too.  I'll take a look at the code later and I'll give
you more feedback.

G

Re: [cpp-netlib-devel] Branching to Implement HTTP 1.0

[Dean M. B. <mik...@gm...>]

Hey Glyn!

On 10/8/07, Glyn Matthews <gly...@gm...> wrote:
> Hi Dean,
>
> On 08/10/2007, Dean Michael Berris <mik...@gm...> wrote:
>
> I certainly hope interest hasn't waned yet. I know mine hasn't, and I
> just hope we can get at least 1.0 released before the end of the year.
>
> Interest hasn't waned ;)  I'm glad to see something happening.

Now I'm glad we're getting somewhere. ;)

Let me get it out of the way first, you may now update to revision 23
-- this has been built against the latest Boost trunk. Please let me
know if you encounter problems though, I'm developing on Windows using
MSVC 8.0 Express Edition. I currently do not have access to a Linux
machine, so whoever can run and patch for GCC on that platform would
be very welcome. :)

> > As for the subject, I'm not an SVN expert -- do you guys know how to
> > branch, switch to the branch, continue developing code there (possibly
> > broken stuff), and then later merge back the changes to trunk? And
> > what do you suggest for the branching convention, so that those who
> > are interested in branching off and working on stuff will be able to
> > do so without having to deal with too many issues later?
>
> For such a small group as ourselves, I'm comfortable with the standard SVN
> convention for branches, with (as far as is possible) branches representing
> distinct tasks:
>
> |- cpp-netlib
>   |- trunk
>   |- branches
>     |- http
>     |- dns
>     |- other_clever_stuff
>   |- tags
>
> I think the naming of the branches should represent the tasks rather than
> the identity of the person working on it.  As for integration, maybe this
> responsibility could be given to one individual who people would notify when
> their branch is stable.  They would identify any problems and use the SF
> tracker to update the relevant people of breakages.  I don't think this will
> be a huge amount of work.
>

I completely agree with this. Next time I'm up to something, I'll
branch according to what that something is as well. :)

> > I hope to be able to check in the (crude) HTTP 1.0 client
> > implementation in a while. I'll send another email when I'm done. For
> > the meantime, I'm going to be checking code into the trunk, of course
> > still making sure that the tests aren't broken.
>
> That's OK for now, since there's really only your own branch being worked
> on.
> > Have a great day everyone (evening from here), and I certainly hope to
> > hear from you soon!
>
> Good to hear from you too.  I'll take a look at the code later and I'll give
> you more feedback.

Please do! They're available now from the trunk.

Have a great day everyone, and have fun!

(Note, please help me complete the unit test for HTTP 1.0 -- the
parser is implemented with Boost.Spirit, and if anybody's got time to
make that implementation a bit more sane than it currently is, help is
definitely most wanted. The parsing happens at construction of the
http::request object. I'm also already using Fusion which may up the
compile time if you're going to be using the simple HTTP client.)

Hope to commit more tomorrow. At the moment, I'm going to get some
much needed sleep. :)

Have a great day guys, and have fun with this! :)

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mik...@gm...]
[+63 928 7291459]
[+1 408 4049523]

Re: [cpp-netlib-devel] Branching to Implement HTTP 1.0

[<rhy...@gm...>]

Hi,

Always glad to see progress :-) I've checked the code under a Debian 
Linux box with Boost trunk, and it fails to compile, since pthread is 
required by Boost.System. It is fairly easy to cope with. Add this line 
to the trunk/libs/network/test/Jamfile.v2 file in the project requirements:

    <toolset>gcc:<source>pthread

Then the code compiles. But, I got linking errors, and I've got no idea 
how to settle them:

...failed gcc.link 
libs/network/test/bin/gcc-4.1.3/debug/link-static/message_transform_test...
...skipped 
<plibs/network/test/bin/gcc-4.1.3/debug/link-static>message_transform_test.passed 
for lack of 
<plibs/network/test/bin/gcc-4.1.3/debug/link-static>message_transform_test...
gcc.compile.c++ 
libs/network/test/bin/gcc-4.1.3/debug/link-static/http_1_0_test.o
gcc.link libs/network/test/bin/gcc-4.1.3/debug/link-static/http_1_0_test
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-write.o): 
In function `__write_nocancel':
(.text+0x26): undefined reference to `__syscall_error'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-write.o): 
In function `__write_nocancel':
(.text+0x56): undefined reference to `__syscall_error'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-close.o): 
In function `__close_nocancel':
(.text+0x20): undefined reference to `__syscall_error'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-close.o): 
In function `__close_nocancel':
(.text+0x4b): undefined reference to `__syscall_error'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-connect.o): 
In function `__connect':
(.text+0x23): undefined reference to `__syscall_error'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-connect.o):(.text+0x52): 
more undefined references to `__syscall_error' follow
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(sigaction.o): 
In function `__libc_sigaction':
/build/buildd/glibc-2.6.1/build-tree/glibc-2.6.1/nptl/../sysdeps/unix/sysv/linux/i386/sigaction.c:83: 
undefined reference to `_dl_sysinfo_dso'
/build/buildd/glibc-2.6.1/build-tree/glibc-2.6.1/nptl/../sysdeps/unix/sysv/linux/i386/sigaction.c:83: 
undefined reference to `_dl_sysinfo_dso'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(init.o): 
In function `__pthread_initialize_minimal_internal':
/build/buildd/glibc-2.6.1/build-tree/glibc-2.6.1/nptl/init.c:264: 
undefined reference to `__libc_setup_tls'
/build/buildd/glibc-2.6.1/build-tree/glibc-2.6.1/nptl/init.c:387: 
undefined reference to `_dl_init_static_tls'
/build/buildd/glibc-2.6.1/build-tree/glibc-2.6.1/nptl/init.c:389: 
undefined reference to `_dl_wait_lookup_done'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(pthread_create.o): 
In function `allocate_stack':
/build/buildd/glibc-2.6.1/build-tree/glibc-2.6.1/nptl/allocatestack.c:411: 
undefined reference to `_dl_stack_flags'
/build/buildd/glibc-2.6.1/build-tree/glibc-2.6.1/nptl/allocatestack.c:547: 
undefined reference to `_dl_stack_flags'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-read.o): 
In function `__read_nocancel':
(.text+0x26): undefined reference to `__syscall_error'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-read.o): 
In function `__read_nocancel':
(.text+0x56): undefined reference to `__syscall_error'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-open.o): 
In function `__open_nocancel':
(.text+0x26): undefined reference to `__syscall_error'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-open.o): 
In function `__open_nocancel':
(.text+0x56): undefined reference to `__syscall_error'



Dean Michael Berris wrote:
> Hi Guys,
>
> I know, it's been a while. However now I just got myself a spanking
> new machine on which I can do the development of the network library
> on -- without having to interfere with the work I do. This gives me a
> reason to 1) go home earlier and 2) develop the network library more.
>
> Now that I'm pretty much setting up the dispatcher library I've been
> working on for review in the near future (am waiting for a
> considerably important enhancement to Boost.Function to get that
> going, while it's not there yet I'm setting my eyes on low hanging
> fruit) I'm looking forward to getting some things done quickly as far
> as the network library is concerned.
>
> I certainly hope interest hasn't waned yet. I know mine hasn't, and I
> just hope we can get at least 1.0 released before the end of the year.
>
> As for the subject, I'm not an SVN expert -- do you guys know how to
> branch, switch to the branch, continue developing code there (possibly
> broken stuff), and then later merge back the changes to trunk? And
> what do you suggest for the branching convention, so that those who
> are interested in branching off and working on stuff will be able to
> do so without having to deal with too many issues later?
>
> I hope to be able to check in the (crude) HTTP 1.0 client
> implementation in a while. I'll send another email when I'm done. For
> the meantime, I'm going to be checking code into the trunk, of course
> still making sure that the tests aren't broken.
>
> Have a great day everyone (evening from here), and I certainly hope to
> hear from you soon!
>
>   

Re: [cpp-netlib-devel] Branching to Implement HTTP 1.0

[Dean M. B. <mik...@gm...>]

T24gMTAvMTAvMDcsIOi/nuWfjiA8cmh5dGhtLm1haWxAZ21haWwuY29tPiB3cm90ZToKPiBIaSwK
Pgo+IEFsd2F5cyBnbGFkIHRvIHNlZSBwcm9ncmVzcyA6LSkgSSd2ZSBjaGVja2VkIHRoZSBjb2Rl
IHVuZGVyIGEgRGViaWFuCj4gTGludXggYm94IHdpdGggQm9vc3QgdHJ1bmssIGFuZCBpdCBmYWls
cyB0byBjb21waWxlLCBzaW5jZSBwdGhyZWFkIGlzCj4gcmVxdWlyZWQgYnkgQm9vc3QuU3lzdGVt
LiBJdCBpcyBmYWlybHkgZWFzeSB0byBjb3BlIHdpdGguIEFkZCB0aGlzIGxpbmUKPiB0byB0aGUg
dHJ1bmsvbGlicy9uZXR3b3JrL3Rlc3QvSmFtZmlsZS52MiBmaWxlIGluIHRoZSBwcm9qZWN0IHJl
cXVpcmVtZW50czoKPgo+ICAgICA8dG9vbHNldD5nY2M6PHNvdXJjZT5wdGhyZWFkCj4KPiBUaGVu
IHRoZSBjb2RlIGNvbXBpbGVzLiBCdXQsIEkgZ290IGxpbmtpbmcgZXJyb3JzLCBhbmQgSSd2ZSBn
b3Qgbm8gaWRlYQo+IGhvdyB0byBzZXR0bGUgdGhlbToKPgoKSG93IGFib3V0IGFkZGluZyA8dG9v
bHNldD5nY2M6PGxpbmtmbGFncz4tbHB0aHJlYWQgaW4gdGhlIHJlcXVpcmVtZW50cwpvZiB0aGUg
dGVzdHMgSmFtZmlsZSBhcyB3ZWxsPyBUaGlzIHNob3VsZCBmaXggaXQsIHRob3VnaCBJJ20gbm90
CmVudGlyZWx5IHN1cmUgLS0gY291bGRuJ3QgdGVzdCBpdCBhdCB0aGUgbW9tZW50LgoKUGxlYXNl
IGxldCBtZSBrbm93IHdoYXQgeW91IHNlZSwgYW5kIHRoYW5rcyBmb3IgdGhlIHRpcCEgOikKCi0t
IApEZWFuIE1pY2hhZWwgQy4gQmVycmlzClNvZnR3YXJlIEVuZ2luZWVyLCBGcmllbmRzdGVyLCBJ
bmMuCltodHRwOi8vY3BsdXNwbHVzLXNvdXAuYmxvZ3Nwb3QuY29tL10KW21pa2hhaWxiZXJpc0Bn
bWFpbC5jb21dClsrNjMgOTI4IDcyOTE0NTldClsrMSA0MDggNDA0OTUyM10K

Re: [cpp-netlib-devel] Branching to Implement HTTP 1.0

[<rhy...@gm...>]

Dean Michael Berris wrote:
> On 10/10/07, 连城 <rhy...@gm...> wrote:
>   
>> Hi,
>>
>> Always glad to see progress :-) I've checked the code under a Debian
>> Linux box with Boost trunk, and it fails to compile, since pthread is
>> required by Boost.System. It is fairly easy to cope with. Add this line
>> to the trunk/libs/network/test/Jamfile.v2 file in the project requirements:
>>
>>     <toolset>gcc:<source>pthread
>>
>> Then the code compiles. But, I got linking errors, and I've got no idea
>> how to settle them:
>>
>>     
>
> How about adding <toolset>gcc:<linkflags>-lpthread in the requirements
>   
I forgot to mention that another line is also added:

    lib pthread ;

I tried the linkflags setting, and it works. All tests passed. I'll 
check it in soon :-)
> of the tests Jamfile as well? This should fix it, though I'm not
> entirely sure -- couldn't test it at the moment.
>
> Please let me know what you see, and thanks for the tip! :)
>
>   

Re: [cpp-netlib-devel] Branching to Implement HTTP 1.0

[Dean M. B. <mik...@gm...>]

T24gMTAvMTAvMDcsIOi/nuWfjiA8cmh5dGhtLm1haWxAZ21haWwuY29tPiB3cm90ZToKPiBEZWFu
IE1pY2hhZWwgQmVycmlzIHdyb3RlOgo+ID4gT24gMTAvMTAvMDcsIOi/nuWfjiA8cmh5dGhtLm1h
aWxAZ21haWwuY29tPiB3cm90ZToKPiA+Cj4gPj4gSGksCj4gPj4KPiA+PiBBbHdheXMgZ2xhZCB0
byBzZWUgcHJvZ3Jlc3MgOi0pIEkndmUgY2hlY2tlZCB0aGUgY29kZSB1bmRlciBhIERlYmlhbgo+
ID4+IExpbnV4IGJveCB3aXRoIEJvb3N0IHRydW5rLCBhbmQgaXQgZmFpbHMgdG8gY29tcGlsZSwg
c2luY2UgcHRocmVhZCBpcwo+ID4+IHJlcXVpcmVkIGJ5IEJvb3N0LlN5c3RlbS4gSXQgaXMgZmFp
cmx5IGVhc3kgdG8gY29wZSB3aXRoLiBBZGQgdGhpcyBsaW5lCj4gPj4gdG8gdGhlIHRydW5rL2xp
YnMvbmV0d29yay90ZXN0L0phbWZpbGUudjIgZmlsZSBpbiB0aGUgcHJvamVjdCByZXF1aXJlbWVu
dHM6Cj4gPj4KPiA+PiAgICAgPHRvb2xzZXQ+Z2NjOjxzb3VyY2U+cHRocmVhZAo+ID4+Cj4gPj4g
VGhlbiB0aGUgY29kZSBjb21waWxlcy4gQnV0LCBJIGdvdCBsaW5raW5nIGVycm9ycywgYW5kIEkn
dmUgZ290IG5vIGlkZWEKPiA+PiBob3cgdG8gc2V0dGxlIHRoZW06Cj4gPj4KPiA+Pgo+ID4KPiA+
IEhvdyBhYm91dCBhZGRpbmcgPHRvb2xzZXQ+Z2NjOjxsaW5rZmxhZ3M+LWxwdGhyZWFkIGluIHRo
ZSByZXF1aXJlbWVudHMKPiA+Cj4gSSBmb3Jnb3QgdG8gbWVudGlvbiB0aGF0IGFub3RoZXIgbGlu
ZSBpcyBhbHNvIGFkZGVkOgo+Cj4gICAgbGliIHB0aHJlYWQgOwo+Cj4gSSB0cmllZCB0aGUgbGlu
a2ZsYWdzIHNldHRpbmcsIGFuZCBpdCB3b3Jrcy4gQWxsIHRlc3RzIHBhc3NlZC4gSSdsbAo+IGNo
ZWNrIGl0IGluIHNvb24gOi0pCgpTd2VldCEgVGhhbmtzIQoKLS0gCkRlYW4gTWljaGFlbCBDLiBC
ZXJyaXMKU29mdHdhcmUgRW5naW5lZXIsIEZyaWVuZHN0ZXIsIEluYy4KW2h0dHA6Ly9jcGx1c3Bs
dXMtc291cC5ibG9nc3BvdC5jb20vXQpbbWlraGFpbGJlcmlzQGdtYWlsLmNvbV0KWys2MyA5Mjgg
NzI5MTQ1OV0KWysxIDQwOCA0MDQ5NTIzXQo=