Den 04-09-2011 00:47, David Nadlinger skrev:
On 9/3/11 10:19 PM, jdrewsen wrote:
The (un)escape methods are located in the Protocol template and is used
for escaping strings for all of the protocols supported by libcurl. That
should be in the documentation of course.
Yes, sure – but do they ad
Den 03-09-2011 22:19, Jonathan M Davis skrev:
On Saturday, September 03, 2011 22:13:44 jdrewsen wrote:
Den 01-09-2011 18:52, Timon Gehr skrev:
On 09/01/2011 06:39 PM, jdrewsen wrote:
Den 01-09-2011 05:19, David Nadlinger skrev:
On 8/25/11 12:05 PM, Jonas Drewsen wrote:
Actually would adding
On 9/3/11 10:19 PM, jdrewsen wrote:
The (un)escape methods are located in the Protocol template and is used
for escaping strings for all of the protocols supported by libcurl. That
should be in the documentation of course.
Yes, sure – but do they add any value over the functions from std.uri?
On Saturday, September 03, 2011 22:13:44 jdrewsen wrote:
> Den 01-09-2011 18:52, Timon Gehr skrev:
> > On 09/01/2011 06:39 PM, jdrewsen wrote:
> >> Den 01-09-2011 05:19, David Nadlinger skrev:
> >>> On 8/25/11 12:05 PM, Jonas Drewsen wrote:
> Actually would adding opCast!string() and opCast!(u
Den 01-09-2011 19:23, David Nadlinger skrev:
On 9/1/11 6:42 PM, jdrewsen wrote:
Den 31-08-2011 01:28, Sean Kelly skrev:
On Aug 17, 2011, at 6:19 PM, Jesse Phillips wrote:
Doe libcurl provide any facility for URL encoding/decoding? Or perhaps
there should be an accompanying submission for doing
Den 01-09-2011 18:52, Timon Gehr skrev:
On 09/01/2011 06:39 PM, jdrewsen wrote:
Den 01-09-2011 05:19, David Nadlinger skrev:
On 8/25/11 12:05 PM, Jonas Drewsen wrote:
Actually would adding opCast!string() and opCast!(ubyte[])() to
AsyncResult and Result allow for this?:
string content = Http.
Am 01.09.2011, 16:56 Uhr, schrieb Andrei Alexandrescu
:
The phenomena involved are rather complex. Probably the only way to move
this forward is a comprehensive benchmark involving various I/O
scenarios (combinations of HTTP, FTP, NAS mount, magnetic disk, SSD, USB
stick).
Andrei
I sp
On 9/1/11 6:42 PM, jdrewsen wrote:
Den 31-08-2011 01:28, Sean Kelly skrev:
On Aug 17, 2011, at 6:19 PM, Jesse Phillips wrote:
Doe libcurl provide any facility for URL encoding/decoding? Or perhaps
there should be an accompanying submission for doing so? Any
nontrivial request will need properly
On 09/01/2011 06:39 PM, jdrewsen wrote:
Den 01-09-2011 05:19, David Nadlinger skrev:
On 8/25/11 12:05 PM, Jonas Drewsen wrote:
Actually would adding opCast!string() and opCast!(ubyte[])() to
AsyncResult and Result allow for this?:
string content = Http.get("http://mysite.com/form.cgi";);
or
ub
Den 31-08-2011 01:28, Sean Kelly skrev:
On Aug 17, 2011, at 6:19 PM, Jesse Phillips wrote:
On Thu, 18 Aug 2011 01:12:20 +0200, David Nadlinger wrote:
Now that Lars Kyllingstad's new and improved std.path has passed the
vote – congratulations, Lars! –, and Jose Armando Garcia, the author of
t
Den 01-09-2011 05:19, David Nadlinger skrev:
On 8/25/11 12:05 PM, Jonas Drewsen wrote:
Actually would adding opCast!string() and opCast!(ubyte[])() to
AsyncResult and Result allow for this?:
string content = Http.get("http://mysite.com/form.cgi";);
or
ubyte[] content = Http.get("http://mysite.c
On 08/31/2011 04:44 PM, Marco Leise wrote:
Am 31.08.2011, 21:52 Uhr, schrieb Andrei Alexandrescu
:
On 08/31/2011 02:15 PM, Marco Leise wrote:
[snip]
If I understand the above correctly, the same amount of seeking goes
around in both cases. The only difference is that requests come at a
faster
The trick is sending from a fast local source to a slow remote destination
without blocking when the write buffer fills anyway, IMO. The rest of this is
mostly an issue of academic interest.
Sent from my iPhone
On Aug 31, 2011, at 6:32 PM, Josh Simmons wrote:
> On Thu, Sep 1, 2011 at 10:00 A
Josh Simmons wrote:
>
>Not sure why we're evaluating disk access performance patterns when
>dealing with network throughput which is only copying the data from
>userspace to a kernel buffer provided you're using a proper async
>socket access pattern.
The discussion drifted away from the original t
Marco Leise wrote:
>Am 31.08.2011, 22:53 Uhr, schrieb Johannes Pfau :
>
>> Andrei Alexandrescu wrote:
>>>
>>> This will happen all the more if you have multiple threads.
>>>
>>> You clearly have a good expertise on OS, I/O, and related matters,
>>> and I am honoured by your presence and by the valu
On 8/25/11 12:05 PM, Jonas Drewsen wrote:
Actually would adding opCast!string() and opCast!(ubyte[])() to
AsyncResult and Result allow for this?:
string content = Http.get("http://mysite.com/form.cgi";);
or
ubyte[] content = Http.get("http://mysite.com/form.cgi";);
It wouldn't, opCast is only
On Thu, Sep 1, 2011 at 10:00 AM, Marco Leise wrote:
> I cannot verify your numbers at all. I drop the caches before every run and
> make two runs with --async first and --sync second and two runs the other
> way round. On a 1GB file the async version adds an average of 0.22%. With a
> larger buffe
Am 31.08.2011, 22:53 Uhr, schrieb Johannes Pfau :
Andrei Alexandrescu wrote:
This will happen all the more if you have multiple threads.
You clearly have a good expertise on OS, I/O, and related matters, and
I am honoured by your presence and by the value you're adding to this
group. However,
On 8/18/11 3:19 AM, Jesse Phillips wrote:
My first thought here is that I don't like the idea of including
something that is already being considered for deprecation. If it isn't
good enough lets hold off putting it in.
As Johannes already mentioned, only removing the default progress
callback
On 8/31/11 4:05 PM, dsimcha wrote:
void copy(in char[] source, in char[] dest) {
// Pray that all the d'tor bugs in DMD are fixed so these files
// get closed automatically.
auto destHandle = File(dest, "wb");
foreach(chunk; File(source).byChunkAsync(chunkSize)) {
de
On 8/31/11 4:24 PM, Sean Kelly wrote:
On Aug 31, 2011, at 1:53 PM, Johannes Pfau wrote:
Andrei Alexandrescu wrote:
This will happen all the more if you have multiple threads.
You clearly have a good expertise on OS, I/O, and related matters, and
I am honoured by your presence and by the valu
Am 31.08.2011, 21:52 Uhr, schrieb Andrei Alexandrescu
:
On 08/31/2011 02:15 PM, Marco Leise wrote:
[snip]
If I understand the above correctly, the same amount of seeking goes
around in both cases. The only difference is that requests come at a
faster pace, as they should.
Andrei
That's not
On Aug 31, 2011, at 1:53 PM, Johannes Pfau wrote:
> Andrei Alexandrescu wrote:
>>
>> This will happen all the more if you have multiple threads.
>>
>> You clearly have a good expertise on OS, I/O, and related matters, and
>> I am honoured by your presence and by the value you're adding to this
== Quote from Johannes Pfau (s...@example.com)'s article
> Andrei Alexandrescu wrote:
> >
> >This will happen all the more if you have multiple threads.
> >
> >You clearly have a good expertise on OS, I/O, and related matters, and
> >I am honoured by your presence and by the value you're adding to
Andrei Alexandrescu wrote:
>
>This will happen all the more if you have multiple threads.
>
>You clearly have a good expertise on OS, I/O, and related matters, and
>I am honoured by your presence and by the value you're adding to this
>group. However, in this particular argument you're only firing
Andrei Alexandrescu wrote:
> On 08/31/2011 02:15 PM, Marco Leise wrote:
> [snip]
>>> If I understand the above correctly, the same amount of seeking goes
>>> around in both cases. The only difference is that requests come at a
>>> faster pace, as they should.
>>>
>>> Andrei
>>
>> That's not what I
Am 31.08.2011, 21:12 Uhr, schrieb Andrew Wiley :
Yes, but the disk should be able to do out-of-order execution of read and
write requests (which SCSI was designed to allow), which should make this
never be an issue. My understanding is that most SCSI implementations
(and
it's in just about ev
On 08/31/2011 02:15 PM, Marco Leise wrote:
[snip]
If I understand the above correctly, the same amount of seeking goes
around in both cases. The only difference is that requests come at a
faster pace, as they should.
Andrei
That's not what I wanted to say. Let me put it like this: If you read
Am 31.08.2011, 20:08 Uhr, schrieb Andrei Alexandrescu
:
On 8/31/11 11:39 AM, Marco Leise wrote:
Am 31.08.2011, 00:07 Uhr, schrieb Andrei Alexandrescu
:
On 8/30/11 3:34 PM, Marco Leise wrote:
Am 30.08.2011, 20:48 Uhr, schrieb Andrei Alexandrescu
:
On 8/30/11 1:10 PM, Jonathan M Davis wrot
On Wed, Aug 31, 2011 at 11:39 AM, Marco Leise wrote:
> Am 31.08.2011, 00:07 Uhr, schrieb Andrei Alexandrescu <
> seewebsiteforem...@erdani.org**>:
>
>
> On 8/30/11 3:34 PM, Marco Leise wrote:
>>
>>> Am 30.08.2011, 20:48 Uhr, schrieb Andrei Alexandrescu
>>> :
>>>
>>> On 8/30/11 1:10 PM, Jonathan
On 8/31/11 11:39 AM, Marco Leise wrote:
Am 31.08.2011, 00:07 Uhr, schrieb Andrei Alexandrescu
:
On 8/30/11 3:34 PM, Marco Leise wrote:
Am 30.08.2011, 20:48 Uhr, schrieb Andrei Alexandrescu
:
On 8/30/11 1:10 PM, Jonathan M Davis wrote:
std.file.copy is synchronous. Would the suggestion then
Am 31.08.2011, 00:07 Uhr, schrieb Andrei Alexandrescu
:
On 8/30/11 3:34 PM, Marco Leise wrote:
Am 30.08.2011, 20:48 Uhr, schrieb Andrei Alexandrescu
:
On 8/30/11 1:10 PM, Jonathan M Davis wrote:
std.file.copy is synchronous. Would the suggestion then be to change
it to be
asynchronous or t
Am 31.08.2011, 00:11 Uhr, schrieb Andrei Alexandrescu
:
On 8/30/11 4:11 PM, Marco Leise wrote:
Am 30.08.2011, 21:56 Uhr, schrieb Walter Bright
:
On 8/30/2011 11:59 AM, Andrei Alexandrescu wrote:
Now, if write is buffered and the buffers are flushed asynchronously,
calls to
write() would be
You're right of course. I even do this pretty regularly. Dunno what I was
thinking.
Sent from my iPhone
On Aug 31, 2011, at 12:48 AM, Jonas Drewsen wrote:
> On 31/08/11 01.17, Sean Kelly wrote:
>> On Aug 30, 2011, at 4:14 PM, Sean Kelly wrote:
>>>
>>> HTTP really isn't the ideal protocol for
On 31/08/11 01.17, Sean Kelly wrote:
On Aug 30, 2011, at 4:14 PM, Sean Kelly wrote:
HTTP really isn't the ideal protocol for this sort of thing. By default, the
entire file would be in the message body, which isn't really asynchronous.
Chunking is an alternative, but there's no way to do th
On Aug 30, 2011, at 4:35 PM, Adam D. Ruppe wrote:
>> Or perhaps there should be an accompanying submission for doing so?
>
> Phobos does have std.uri.
And here is where I show how much web programming I've been doing in D.
On 8/30/11 6:35 PM, Adam D. Ruppe wrote:
Or perhaps there should be an accompanying submission for doing so?
Phobos does have std.uri.
I'm still longing for that cgi library of yours...
Andrei
On 8/30/11 6:17 PM, Sean Kelly wrote:
On Aug 30, 2011, at 4:14 PM, Sean Kelly wrote:
HTTP really isn't the ideal protocol for this sort of thing. By default, the
entire file would be in the message body, which isn't really asynchronous.
Chunking is an alternative, but there's no way to do t
> Or perhaps there should be an accompanying submission for doing so?
Phobos does have std.uri.
On Aug 17, 2011, at 6:19 PM, Jesse Phillips wrote:
> On Thu, 18 Aug 2011 01:12:20 +0200, David Nadlinger wrote:
>
>> Now that Lars Kyllingstad's new and improved std.path has passed the
>> vote – congratulations, Lars! –, and Jose Armando Garcia, the author of
>> the proposed logging module, is
On Aug 30, 2011, at 4:14 PM, Sean Kelly wrote:
>
> HTTP really isn't the ideal protocol for this sort of thing. By default, the
> entire file would be in the message body, which isn't really asynchronous.
> Chunking is an alternative, but there's no way to do this from the
> client-side, it's
On Aug 30, 2011, at 10:38 AM, Andrei Alexandrescu wrote:
>
> This is an equation very easy to derive from first principles but many people
> are very incredulous about it. Consequently, many classic file copying
> programs (including cp; I don't know about wget or curl) use the inefficient
> me
On Aug 30, 2011, at 11:59 AM, Andrei Alexandrescu wrote:
> On 8/30/11 1:21 PM, jdrewsen wrote:
>>
>>
>> I guess that e.g. incoming network buffers in the OS often makes the
>> shown copy routine faster than you would think i most cases. These
>> buffers stores the incoming network data asynchron
On 8/30/11 4:11 PM, Marco Leise wrote:
Am 30.08.2011, 21:56 Uhr, schrieb Walter Bright
:
On 8/30/2011 11:59 AM, Andrei Alexandrescu wrote:
Unless the OS issues speculative reads (which I don't think it does
for either
files or sockets), any time spent in write() is a net loss for
reading speed
On 8/30/11 3:34 PM, Marco Leise wrote:
Am 30.08.2011, 20:48 Uhr, schrieb Andrei Alexandrescu
:
On 8/30/11 1:10 PM, Jonathan M Davis wrote:
std.file.copy is synchronous. Would the suggestion then be to change
it to be
asynchronous or to create a second function (e.g. copyAsync) which
does an
as
On 8/30/11 2:35 PM, dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
On 8/30/11 1:10 PM, Jonathan M Davis wrote:
std.file.copy is synchronous. Would the suggestion then be to change it to be
asynchronous or to create a second function (e.g. copyAsync) w
Am 30.08.2011, 21:56 Uhr, schrieb Walter Bright
:
On 8/30/2011 11:59 AM, Andrei Alexandrescu wrote:
Unless the OS issues speculative reads (which I don't think it does for
either
files or sockets), any time spent in write() is a net loss for reading
speed.
Now *that* was speculative, if
Andrei Alexandrescu wrote:
>On 8/30/11 1:21 PM, jdrewsen wrote:
>> Den 30-08-2011 19:38, Andrei Alexandrescu skrev:
>>> On 8/30/11 12:22 PM, jdrewsen wrote:
Walter suggested that I should write an article about using the
wrapper. I've now taken the first steps on writing such an
arti
Am 30.08.2011, 20:48 Uhr, schrieb Andrei Alexandrescu
:
On 8/30/11 1:10 PM, Jonathan M Davis wrote:
std.file.copy is synchronous. Would the suggestion then be to change it
to be
asynchronous or to create a second function (e.g. copyAsync) which does
an
asynchrous copy?
I think std.file.
On 8/30/2011 11:59 AM, Andrei Alexandrescu wrote:
Unless the OS issues speculative reads (which I don't think it does for either
files or sockets), any time spent in write() is a net loss for reading speed.
Now, if write is buffered and the buffers are flushed asynchronously, calls to
write() wou
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> On 8/30/11 1:10 PM, Jonathan M Davis wrote:
> > std.file.copy is synchronous. Would the suggestion then be to change it to
> > be
> > asynchronous or to create a second function (e.g. copyAsync) which does an
> > asynchr
On Tuesday, August 30, 2011 13:48:10 Andrei Alexandrescu wrote:
> On 8/30/11 1:10 PM, Jonathan M Davis wrote:
> > std.file.copy is synchronous. Would the suggestion then be to change it
> > to be asynchronous or to create a second function (e.g. copyAsync)
> > which does an asynchrous copy?
>
> I
On 8/30/11 1:21 PM, jdrewsen wrote:
Den 30-08-2011 19:38, Andrei Alexandrescu skrev:
On 8/30/11 12:22 PM, jdrewsen wrote:
Walter suggested that I should write an article about using the wrapper.
I've now taken the first steps on writing such an article. I will have
to get the library API rock s
On 8/30/11 1:10 PM, Jonathan M Davis wrote:
std.file.copy is synchronous. Would the suggestion then be to change it to be
asynchronous or to create a second function (e.g. copyAsync) which does an
asynchrous copy?
I think std.file.copy should do whatever the heck is best to copy a
file. As suc
== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
> std.file.copy is synchronous. Would the suggestion then be to change it to be
> asynchronous or to create a second function (e.g. copyAsync) which does an
> asynchrous copy?
> - Jonathan M Davis
Probably just make it asynchronous bec
Den 30-08-2011 19:38, Andrei Alexandrescu skrev:
On 8/30/11 12:22 PM, jdrewsen wrote:
Walter suggested that I should write an article about using the wrapper.
I've now taken the first steps on writing such an article. I will have
to get the library API rock stable before I can finish it though.
On Tuesday, August 30, 2011 10:57 dsimcha wrote:
> == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
>
> > It is a continuous source of surprise to me that even seasoned
> > programmers don't realize that this is an inefficient copy routine:
> > while (read(source, buffer))
> >
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
> It is a continuous source of surprise to me that even seasoned
> programmers don't realize that this is an inefficient copy routine:
> while (read(source, buffer))
>write(target, buffer);
> If the methods are synchronous and
On 8/30/11 12:22 PM, jdrewsen wrote:
Walter suggested that I should write an article about using the wrapper.
I've now taken the first steps on writing such an article. I will have
to get the library API rock stable before I can finish it though.
I have a suggestion for you - write and test an
Den 29-08-2011 23:08, Andrei Alexandrescu skrev:
On 8/29/11 3:46 PM, jdrewsen wrote:
[snip]
I looked around and it seems getopt is a moderately commonly asked
feature for libcurl. However, since it hasn't been implemented for
years, you probably made the right call to not provide shadow members
On 8/29/11 3:46 PM, jdrewsen wrote:
[sni]
Thanks for taking my comments in stride.
* verbose, dataTimeout etc. don't have corresponding properties for
reading.
I general all the settings are simply set directly in libcurl itself.
Libcurl only has a function for setting options and not one for
Den 29-08-2011 20:55, Andrei Alexandrescu skrev:
On 8/17/11 6:12 PM, David Nadlinger wrote:
Now that Lars Kyllingstad's new and improved std.path has passed the
vote – congratulations, Lars! –, and Jose Armando Garcia, the author of
the proposed logging module, is currently not available, the et
On 8/17/11 6:12 PM, David Nadlinger wrote:
Now that Lars Kyllingstad's new and improved std.path has passed the
vote – congratulations, Lars! –, and Jose Armando Garcia, the author of
the proposed logging module, is currently not available, the etc.curl
module by Jonas Drewsen is at the front of
Den 25-08-2011 18:49, Walter Bright skrev:
quote only what is necessary
Will do
On 8/25/2011 3:07 AM, Jonas Drewsen wrote:
Thank you. Will chew through it slowly.
This is a meta comment for everyone - when replying to a long post, please quote
only what is necessary. It makes navigating these threads easier.
Jonas Drewsen wrote:
>On 24/08/11 14.58, Johannes Pfau wrote:
>> David Nadlinger wrote:
>>> Now that Lars Kyllingstad's new and improved std.path has passed the
>>> vote – congratulations, Lars! –, and Jose Armando Garcia, the
>>> author of the proposed logging module, is currently not available,
Jonas Drewsen wrote:
>On 24/08/11 16.34, Johannes Pfau wrote:
>> Damn, I forgot the most important part:
>>
>> etc.curl currently uses none of D's "advanced" function attributes.
>> This means that etc.curl can't be used in safeD for example. IMHO
>> that's a big problem: New phobos code should be
On 24/08/11 18.35, Walter Bright wrote:
On 8/24/2011 2:18 AM, Johannes Pfau wrote:
Walter Bright wrote:
On 8/17/2011 4:12 PM, David Nadlinger wrote:
the etc.curl module by Jonas Drewsen is at the front of the review
queue.
Thanks for doing this. I preface my remarks with saying I have never
On 24/08/11 14.58, Johannes Pfau wrote:
David Nadlinger wrote:
Now that Lars Kyllingstad's new and improved std.path has passed the
vote – congratulations, Lars! –, and Jose Armando Garcia, the author
of the proposed logging module, is currently not available, the
etc.curl module by Jonas Drews
On 24/08/11 16.34, Johannes Pfau wrote:
Damn, I forgot the most important part:
etc.curl currently uses none of D's "advanced" function attributes.
This means that etc.curl can't be used in safeD for example. IMHO
that's a big problem: New phobos code should be usable in safeD it's
bad enough th
On 24/08/11 19.33, Andrei Alexandrescu wrote:
On 8/24/11 9:35 AM, Walter Bright wrote:
On 8/24/2011 2:18 AM, Johannes Pfau wrote:
Walter Bright wrote:
On 8/17/2011 4:12 PM, David Nadlinger wrote:
the etc.curl module by Jonas Drewsen is at the front of the review
queue.
Thanks for doing this
On 2011-08-24 18:35, Walter Bright wrote:
On 8/24/2011 2:18 AM, Johannes Pfau wrote:
Not sure, if this still works though. Twitter is switching from HTTP
basic authentication to OAuth. Also, this code is not tested ;-)
I'm glad to see this can be done. A complete example in the
documentation
Den 22-08-2011 17:20, Jonathan M Davis skrev:
On Monday, August 22, 2011 15:23:54 simendsjo wrote:
On 22.08.2011 08:25, Jonathan M Davis wrote:
On Monday, August 22, 2011 08:09:54 Jonas Drewsen wrote:
On 21/08/11 23.44, Jesse Phillips wrote:
On Sat, 20 Aug 2011 23:57:54 +, Jesse Phillips
On 8/24/2011 10:33 AM, Andrei Alexandrescu wrote:
Probably this simple level of abstraction should be provided by the library
(with the added advantage that client code will automatically work with new
protocols as the library includes them).
Yes to both.
On 8/24/11 9:35 AM, Walter Bright wrote:
On 8/24/2011 2:18 AM, Johannes Pfau wrote:
Walter Bright wrote:
On 8/17/2011 4:12 PM, David Nadlinger wrote:
the etc.curl module by Jonas Drewsen is at the front of the review
queue.
Thanks for doing this. I preface my remarks with saying I have never
Walter Bright wrote:
>On 8/24/2011 2:18 AM, Johannes Pfau wrote:
>> Walter Bright wrote:
>>> On 8/17/2011 4:12 PM, David Nadlinger wrote:
the etc.curl module by Jonas Drewsen is at the front of the review
queue.
>>>
>>> Thanks for doing this. I preface my remarks with saying I have never
On 8/24/2011 2:18 AM, Johannes Pfau wrote:
Walter Bright wrote:
On 8/17/2011 4:12 PM, David Nadlinger wrote:
the etc.curl module by Jonas Drewsen is at the front of the review
queue.
Thanks for doing this. I preface my remarks with saying I have never
done http: programming and know little ab
Damn, I forgot the most important part:
etc.curl currently uses none of D's "advanced" function attributes.
This means that etc.curl can't be used in safeD for example. IMHO
that's a big problem: New phobos code should be usable in safeD it's
bad enough that lots of old code isn't.
So:
@safe or @
David Nadlinger wrote:
>Now that Lars Kyllingstad's new and improved std.path has passed the
>vote – congratulations, Lars! –, and Jose Armando Garcia, the author
>of the proposed logging module, is currently not available, the
>etc.curl module by Jonas Drewsen is at the front of the review queue
Walter Bright wrote:
>On 8/17/2011 4:12 PM, David Nadlinger wrote:
>> the etc.curl module by Jonas Drewsen is at the front of the review
>> queue.
>
>Thanks for doing this. I preface my remarks with saying I have never
>done http: programming and know little about it.
>
>1. The first, most obvious
On 2011-08-23 23:33, Walter Bright wrote:
On 8/17/2011 4:12 PM, David Nadlinger wrote:
the etc.curl module by Jonas Drewsen is at the front of the review queue.
Thanks for doing this. I preface my remarks with saying I have never
done http: programming and know little about it.
1. The first,
On Tue, Aug 23, 2011 at 4:33 PM, Walter Bright
wrote:
>
> 5. I'd like an NNTP interface so I can get and post newsgroup messages from
> D, though I suspect that is beyond the scope of etc.curl.
>
libcurl doesn't have NNTP support (yet). If someone can write it and
contribute to libcurl, that woul
On 8/23/2011 2:33 PM, Walter Bright wrote:
1. The first, most obvious thing I'd like to do is present a URL and get a
string back that is the contents of that web page:
string contents = getURL("http://www.digitalmars.com";);
and contents[] should be the web page; what I'd see if I opened it in
On 8/23/2011 4:38 PM, Jonathan M Davis wrote:
I understand if examples have to have a shorter line limit due to how they're
presented, but the shorter the limit, the more restrictive and annoying it
gets.
I know, but having it wrap is worse (or worst of all, have the right edge just
chopped of
On Tuesday, August 23, 2011 15:17 Walter Bright wrote:
> On 8/23/2011 3:09 PM, Jonathan M Davis wrote:
> > 40 characters is disgustingly narrow. We may need to cut examples to that
> > sort of length for the sake of e-books, but I'm willing to bet that
> > something like 3/4 of the examples would h
On 8/23/2011 3:09 PM, Jonathan M Davis wrote:
40 characters is disgustingly narrow. We may need to cut examples to that sort
of length for the sake of e-books, but I'm willing to bet that something like
3/4 of the examples would have to be wrapped because of that. It's a serious
downgrade for any
On Tuesday, August 23, 2011 14:35 Walter Bright wrote:
> On 8/21/2011 2:56 PM, Jonathan M Davis wrote:
> > 80 characters should be enough. Most of the documentation in Phobos
> > restricts itself to 80 characters, including the examples.
>
> 80 characters is way too long for magazine/book examples
On 8/21/2011 2:56 PM, Jonathan M Davis wrote:
80 characters should be enough. Most of the documentation in Phobos restricts
itself to 80 characters, including the examples.
80 characters is way too long for magazine/book examples, and will cause
problems when converting the Phobos docs to an e
On 8/17/2011 4:12 PM, David Nadlinger wrote:
the etc.curl module by Jonas Drewsen is at the front of the review queue.
Thanks for doing this. I preface my remarks with saying I have never done http:
programming and know little about it.
1. The first, most obvious thing I'd like to do is pres
On Monday, August 22, 2011 15:23:54 simendsjo wrote:
> On 22.08.2011 08:25, Jonathan M Davis wrote:
> > On Monday, August 22, 2011 08:09:54 Jonas Drewsen wrote:
> >> On 21/08/11 23.44, Jesse Phillips wrote:
> >>> On Sat, 20 Aug 2011 23:57:54 +, Jesse Phillips wrote:
> On Thu, 18 Aug 2011 0
On 22.08.2011 08:25, Jonathan M Davis wrote:
On Monday, August 22, 2011 08:09:54 Jonas Drewsen wrote:
On 21/08/11 23.44, Jesse Phillips wrote:
On Sat, 20 Aug 2011 23:57:54 +, Jesse Phillips wrote:
On Thu, 18 Aug 2011 01:12:20 +0200, David Nadlinger wrote:
At this point, I would like to in
On Monday, August 22, 2011 08:09:54 Jonas Drewsen wrote:
> On 21/08/11 23.44, Jesse Phillips wrote:
> > On Sat, 20 Aug 2011 23:57:54 +, Jesse Phillips wrote:
> >> On Thu, 18 Aug 2011 01:12:20 +0200, David Nadlinger wrote:
> >>> At this point, I would like to invite everyone to spend some time
>
On 21/08/11 23.44, Jesse Phillips wrote:
On Sat, 20 Aug 2011 23:57:54 +, Jesse Phillips wrote:
On Thu, 18 Aug 2011 01:12:20 +0200, David Nadlinger wrote:
At this point, I would like to invite everyone to spend some time
testing the module and reading its documentation and code. It is
esse
On Sunday, August 21, 2011 21:44:33 Jesse Phillips wrote:
> On Sat, 20 Aug 2011 23:57:54 +, Jesse Phillips wrote:
> > On Thu, 18 Aug 2011 01:12:20 +0200, David Nadlinger wrote:
> >> At this point, I would like to invite everyone to spend some time
> >> testing the module and reading its documen
On Sat, 20 Aug 2011 23:57:54 +, Jesse Phillips wrote:
> On Thu, 18 Aug 2011 01:12:20 +0200, David Nadlinger wrote:
>
>> At this point, I would like to invite everyone to spend some time
>> testing the module and reading its documentation and code. It is
>> essential for a working open source
On Thu, 18 Aug 2011 01:12:20 +0200, David Nadlinger wrote:
> At this point, I would like to invite everyone to spend some time
> testing the module and reading its documentation and code. It is
> essential for a working open source code review process that many people
> participate in it, and rega
On 2011-08-18 01:12, David Nadlinger wrote:
Known issues:
* DDoc is not generated where the mixins ByLineAsync, ByLineSync,
ByChunkAsync and ByLineSync are used. This seems to be a limitation of
ddoc - suggestions on how to circumvent this appreciated.
Not sure if it's the same issue but I thin
Jesse Phillips wrote:
>On Thu, 18 Aug 2011 01:12:20 +0200, David Nadlinger wrote:
>
>> Now that Lars Kyllingstad's new and improved std.path has passed the
>> vote – congratulations, Lars! –, and Jose Armando Garcia, the
>> author of the proposed logging module, is currently not available,
>> the
On Thu, 18 Aug 2011 01:12:20 +0200, David Nadlinger wrote:
> Now that Lars Kyllingstad's new and improved std.path has passed the
> vote – congratulations, Lars! –, and Jose Armando Garcia, the author of
> the proposed logging module, is currently not available, the etc.curl
> module by Jonas Dre
Now that Lars Kyllingstad's new and improved std.path has passed the
vote – congratulations, Lars! –, and Jose Armando Garcia, the author of
the proposed logging module, is currently not available, the etc.curl
module by Jonas Drewsen is at the front of the review queue. I have
volunteered to
100 matches
Mail list logo
