GitHub nore...@github.com i.e. Yang Tse wrote:
93 *.c source files renamed to use our standard naming scheme.
..
A lib/curl_amigaos.c
A lib/curl_asyn_ares.c
A lib/curl_asyn_thread.c
A lib/curl_axtls.c
A lib/curl_base64.c
A lib/curl_bundles.c
Okay, but now we can say
On Thu, 3 Jan 2013, venkataragavan vijayakumar wrote:
I am currently using libcurl for my HTTP client purpose. Now i have
requirement that , i need to develop a HTTP server. Can libcurl will parse
the HTTP request comes from other client? Please do the needful.
No. libcurl offers no
On Thu, 3 Jan 2013, JALINDAR wrote:
Please don't top-post!
I still find the same for polarssl on web page:
http://curl.haxx.se/docs/install.html
Yes, as that's the correct instruction! I use only that when I build my
libcurl against PolarSSL and it works just fine for me. (At least the
On Thu, 3 Jan 2013, Jens Staal wrote:
I just wanted to report that the latest curl pretty much built out of the
box on Plan9/APE (ANSI-POSIX-ENVIRONMENT).
Ah, lovely. Thanks for keeping up your tests and reporting back. I truly want
curl and libcurl to work on current platforms, including
Hi Daniel, Gisle, and all,
The renaming of lib/*.h which already were not named curl_*.h to
curl_*.h, and renaming lib/*.c which already were not named curl_*.c
has at least the following intended benefits over the non-renamed
sources:
Relative to the header files...
1) We are able to guarantee
torsdagen den 3 januari 2013 11.50.02 skrev Daniel Stenberg:
On Thu, 3 Jan 2013, Jens Staal wrote:
I just wanted to report that the latest curl pretty much built out of the
box on Plan9/APE (ANSI-POSIX-ENVIRONMENT).
Ah, lovely. Thanks for keeping up your tests and reporting back. I truly
On Thu, 3 Jan 2013, Yang Tse wrote:
1) We are able to guarantee to a higher degree that the headers being
included are actually libcurl ones.
I'm not a fan of fixing *potential* problems. We've managed fine for 14 years
with this naming, I don't see anything new on the horizon that suddenly
On Thu, Jan 3, 2013 at 12:35 PM, Daniel Stenberg dan...@haxx.se wrote:
Further downsides with the renames:
* Patches for older curl versions now suddenly don't apply anymore and will
give us (and others) much more work to apply. This will not only affect a
couple of patches that I have
On Thu, 3 Jan 2013, Jens Staal wrote:
fixing the configure is pretty easy with sed after all :) (and could
probably be delegated to a build instructions file, or possibly a script
that first trims configure and then runs it)
Right, I understand you now and I'm sure it will make sense to have
I originally sent this on 25-Dec - now that folks seem to be back from
their holiday, thought I should re-send.
I hope someone can apply it to your source repository - I don't have (or
want) access - hopefully this is a one-time contribution.
Happy New Year!
(The 25-Dec version is identical
On Thursday, January 03, 2013 12:35:54 Daniel Stenberg wrote:
Further downsides with the renames:
* Patches for older curl versions now suddenly don't apply anymore and will
give us (and others) much more work to apply. This will not only affect a
couple of patches that I have pending in
Yang Tse yangs...@gmail.com wrote:
2) When debugging libcurl or apps that use it with debuggers that are
capable of showing the name of the source file it is much easier to
know if one is stepping in libcurl's code or elsewhere.
I think that's a good argument for renaming.
From your
Replying to all in last msg in thread I've read in order to keep a
linear thread, even at the expense of making this msg longer...
@Daniel...
On Thu, Jan 3, 2013, Daniel Stenberg wrote:
On Thu, 3 Jan 2013, Yang
On Thursday 03 January 2013 18:04:53 Yang Tse wrote:
3) On core dumps, and fatal happenings which trace the source file
name of where the problem has been triggered, it becomes much easier
for not expert souls to figure out if it is a libcurl problem or not.
I would be surprised if this
On Thu, 3 Jan 2013, Yang Tse wrote:
The splitting of a single header or two surely can't motivate the renaming
of 190 *other* files?
True, the splitting doesn't actually motivate the renaming. It would only
justify the modification of the 190 *other* files.
Yes indeed, but that change
Hi Jiri,
thank you for the responses -- unfortunately I had to take care of
more stuff than expected before my annual leave at the end of
the year, so I was not able to prepare anything meaningful in the
previous weeks. However now I'm back at work and I want to
resolve this the first thing
2013/1/3 Marc Hoersken i...@marc-hoersken.de:
I haven't tested this myself, but from my experience with previous
renames, GitHub and all the other tools in the git ecosystem will show
you the history till the last rename, but won't automatically follow
the history before that point.
I have to
2013/1/3 Marc Hoersken i...@marc-hoersken.de:
2013/1/3 Marc Hoersken i...@marc-hoersken.de:
I haven't tested this myself, but from my experience with previous
renames, GitHub and all the other tools in the git ecosystem will show
you the history till the last rename, but won't automatically
On Thu, Jan 03, 2013 at 10:10:31PM +0100, Marc Hoersken wrote:
2013/1/3 Marc Hoersken i...@marc-hoersken.de:
2013/1/3 Marc Hoersken i...@marc-hoersken.de:
I haven't tested this myself, but from my experience with previous
renames, GitHub and all the other tools in the git ecosystem will
Hi all
I count it as such. Let us give ourselves 24, 48 hours to let other
express themselves, if they desire so.
I must admit I'm not all for it but saying that I'm not dead set against it
either - given the choice I personally wouldn't do it.
However, I am all for consistency. So if we do
On Thursday, January 03, 2013 21:05:20 Marc Hoersken wrote:
I think it's too late to fix the history without actually rewriting
it. Even reverting or manually undoing the rename, which would
basically result in the same changeset with regards to git, would
still result in a hole or jump in the
2013/1/3 Kamil Dudka kdu...@redhat.com:
I haven't tested this myself, but from my experience with previous
renames, GitHub and all the other tools in the git ecosystem will show
you the history till the last rename, but won't automatically follow
the history before that point.
I am not sure
Hi Steve,
I can volunteer to test and finalize your tests if you want
That would be great - Are you able to verify the patch I posted doesn't break
anything first of all?
Sure - thanks for the details you sent off the list, will try them and report.
I know these things are always subjective
On Tue, 25 Dec 2012, tlhackque wrote:
I have updated mk-ca-bundle.pl to implement the following :
Patch follows.
Sorry, but your mail client completely messed up the whitespaces of that patch
which made it impossible to apply in my end. Can you please make another
attempt at sending it
Hi,
Is there a CURLOPT equivalent of setting -U to :? This is so I can use
the Windows credentials when authenticating to an NTLM proxy - i.e.
smartcard auth.
Thanks,
Adam
---
List admin:
25 matches
Mail list logo
