Jacob Carlborg wrote:
> First, I need curl, or similar.

If you like, you're free to use the http implementation from my build2.d <http://arsdnet.net/dcode/build2.d> - look for HTTP Implementation near the bottom.

The (commented out) Network Wrapper get() function a little above
shows how to use it for basic stuff.


Doesn't have https support or anything else fancy like that, but it works.

On 2011-06-21 16:02, Andrei Alexandrescu wrote:
> On 6/21/11 4:18 AM, Jacob Carlborg wrote:
>> On 2011-06-21 00:32, Andrei Alexandrescu wrote:
>>> On 6/20/11 4:28 PM, Jacob Carlborg wrote:
>>>> See my reply to Dmitry.
>>>
>>> I see this as a dogfood issue. If there are things that should be in
>>> Phobos and aren't, it would gain everybody to add them to Phobos.
>>
>> All of these are not missing. For some of the things I just like doing
>> it differently then how Phobos does it.
>
> I understand.
>
>>> Anyhow, it all depends on what you want to do with the tool. If it's
>>> written in D1, we won't be able to put it on the github
>>> D-programming-language/tools (which doesn't mean it won't become
>>> widespread).
>>
>> So now suddenly D1 is banned? Seems like you are trying to destroy all
>> traces of D1. I think it would be better for all if you instead
>> encourage people to use D of any version and not use D2.
>
> No need to politicize this - as I said, it's a matter of dogfood, as
> well as one of focusing our efforts. You seem to not like the way D and
> its standard library work, which is entirely fine, except when it comes
> about adding an official tool.

I do like D1 and in general D2. What I'm having most problem with is Phobos and that D2 sometimes (too often for me) doesn't work.

If we talk about making it an official tool I can understand that you want it to be written in D2 and Phobos.

On the other hand I think that the D community should encourage all developers using D, regardless of which version or standard library they use. The community is too small for anything else.

>>>> BTW has std.benchmark gone through the regular review process?
>>>
>>> I was sure someone will ask that at some point :o). The planned change
>>> was to add a couple of functions, but then it got separated into its own
>>> module. If several people think it's worth putting std.benchmark through
>>> the review queue, let's do so. I'm sure the quality of the module will
>>> be gained.
>>>
>>>
>>> Andrei
>>
>> Why would std.benchmark be an exception? Shouldn't all new modules and
>> big refactoring of existing ones go through the review process?
>
> Again, the matter has been incidental - the module has grown from the
> desire to reduce std.datetime. The new code only adds a couple of
> functions. Going through the review process will definitely be helpful.
>
>> If none
>> one thinks it's worth putting std.benchmark through the review process
>> then it seems to me that people isn't thinking it worth adding to Phobos.
>
> I wrote these functions for two reasons. One, I want to add a collection
> of benchmarks to Phobos itself so we can keep tabs on performance.
> Second, few people know how to write a benchmark and these functions
> help to some extent, so the functions may be of interest beyond Phobos.
>
> My perception is that there is an underlying matter making you look for
> every opportunity to pick a fight. Your posts as of late have been
> increasingly abrupt. Only in the post I'm replying to you have attempted
> to ascribe political motives to me, to frame me as one who thinks is
> above the rules, and to question the worthiness of my work. Instead of
> doing all that, it may be more productive to focus on the core matter
> and figuring out a way to resolve it.
>
>
> Thanks,
>
> Andrei

I'm sorry if my posts are abrupt. I'm not very good at writing in the first place and my native language not being English doesn't help. Sometimes I just want to answer something to just basically indicate that I've read the reply, that may look abrupt, I don't know.

I just want to say one more thing (hoping you don't think I'm too offensive) and that is that you sometimes seem to want to pretend that there is no D1 and never has been.

Maybe I was a bit too harsh saying that std.benchmark maybe wasn't worth adding. On the other hand isn't this what the review process is about (or maybe this is before the review process)? We can't include EVERYTHING in Phobos or it will become like the Java/C# standard library, I assume we don't want that. I just saw a new module with almost 1k lines of code and some additional changes as well and was wondering why this haven't gone through the review process.

In the end I'm just trying to defend my code and ideas. Should I've not answered the feedback I got on my ideas?

Anyway, I have no problem dropping this discussion and focusing on the core matter and figuring out a way to resolve it.

-- 
/Jacob Carlborg

On 2011-06-21 10:17, Jacob Carlborg wrote:
> Maybe I was a bit too harsh saying that std.benchmark maybe wasn't worth adding. On the other hand isn't this what the review process is about (or maybe this is before the review process)? We can't include EVERYTHING in Phobos or it will become like the Java/C# standard library, I assume we don't want that.

Why not? Granted, we want quality code, and we only have so many people working on Phobos and only so many people to help vet code, but assuming that it can be written at the appropriate level of quality and that the functionality is generally useful, I don't see why we wouldn't want a large standard library like Java and C# have. Given our level of manpower, I don't expect that we'll ever have a standard library that large, but I don't see why having a large standard library would be a bad thing as long as it's of high quality and its functionality is generally useful.

- Jonathan M Davis

On 2011-06-21 19:36, Jonathan M Davis wrote:
> On 2011-06-21 10:17, Jacob Carlborg wrote:
>> Maybe I was a bit too harsh saying that std.benchmark maybe wasn't worth
>> adding. On the other hand isn't this what the review process is about
>> (or maybe this is before the review process)? We can't include
>> EVERYTHING in Phobos or it will become like the Java/C# standard
>> library, I assume we don't want that.
>
> Why not? Granted, we want quality code, and we only have so many people
> working on Phobos and only so many people to help vet code, but assuming that
> it can be written at the appropriate level of quality and that the
> functionality is generally useful, I don't see why we wouldn't want a large
> standard library like Java and C# have. Given our level of manpower, I don't
> expect that we'll ever have a standard library that large, but I don't see why
> having a large standard library would be a bad thing as long as it's of high
> quality and its functionality is generally useful.
>
> - Jonathan M Davis

I just got that impression. That we want a relative small standard library and have other libraries available as well.

-- 
/Jacob Carlborg

On Tue, Jun 21, 2011 at 1:01 PM, Jacob Carlborg <doob@me.com> wrote:

> On 2011-06-21 19:36, Jonathan M Davis wrote:
>
>> On 2011-06-21 10:17, Jacob Carlborg wrote:
>>
>>> Maybe I was a bit too harsh saying that std.benchmark maybe wasn't worth adding. On the other hand isn't this what the review process is about (or maybe this is before the review process)? We can't include EVERYTHING in Phobos or it will become like the Java/C# standard library, I assume we don't want that.
>>>
>>
>> Why not? Granted, we want quality code, and we only have so many people
>> working on Phobos and only so many people to help vet code, but assuming
>> that
>> it can be written at the appropriate level of quality and that the
>> functionality is generally useful, I don't see why we wouldn't want a
>> large
>> standard library like Java and C# have. Given our level of manpower, I
>> don't
>> expect that we'll ever have a standard library that large, but I don't see
>> why
>> having a large standard library would be a bad thing as long as it's of
>> high
>> quality and its functionality is generally useful.
>>
>> - Jonathan M Davis
>>
>
> I just got that impression. That we want a relative small standard library and have other libraries available as well.
>
> --
> /Jacob Carlborg
>

What's wrong with having a standard library like C#'s?  It's one of the greatest advantages of .NET programming.

On 2011-06-21 11:01, Jacob Carlborg wrote:
> On 2011-06-21 19:36, Jonathan M Davis wrote:
> > On 2011-06-21 10:17, Jacob Carlborg wrote:
> >> Maybe I was a bit too harsh saying that std.benchmark maybe wasn't worth adding. On the other hand isn't this what the review process is about (or maybe this is before the review process)? We can't include EVERYTHING in Phobos or it will become like the Java/C# standard library, I assume we don't want that.
> > 
> > Why not? Granted, we want quality code, and we only have so many people working on Phobos and only so many people to help vet code, but assuming that it can be written at the appropriate level of quality and that the functionality is generally useful, I don't see why we wouldn't want a large standard library like Java and C# have. Given our level of manpower, I don't expect that we'll ever have a standard library that large, but I don't see why having a large standard library would be a bad thing as long as it's of high quality and its functionality is generally useful.
> > 
> > - Jonathan M Davis
> 
> I just got that impression. That we want a relative small standard library and have other libraries available as well.

I don't know how everyone else feels about it, but I see no problem with having a large standard library as long as it's of high quality and its functionality is generally useful. Java and C#'s standard libraries are generally considered a valuable asset. One of the major advantages of Python which frequently gets touted is its large standard library. I definitely see a large standard library as advantageous. The trick is being able to develop it, having it of high quality, and actually have everything in it be generally useful. We don't have a lot of people working on Phobos, so naturally, it's going to be smaller. If quality is a major focus, then the size is going to tend to be smaller as well. And if we try and avoid functionality which is overly-specific and not generally useful, then that's going to make the library smaller as well.

We have been pushing for both high quality and general usefulness in what is added to Phobos, so it hasn't exactly been growing by leaps and bounds, and with the limited resources that we have, it takes time to improve and enlarge it even if we want to be large. So, Phobos is naturally smaller than many standard libraries (particularly those backed by large companies) and will continue to be so. But I think that having a large, high quality, generally useful standard library is very much what we should be striving for, even if for now that's pretty much restricted to high quality and generally useful.

Now, maybe there are other folks on the Phobos dev team or on the newsgroup which want Phobos to be small, but I really think that experience has shown that large standard libraries are generally an asset to a language. The trick is ensuring that the functionality that they have is of high quality and appropriately general for a standard library.

- Jonathan M Davis

On Tue, 21 Jun 2011 21:01:07 +0300, Jacob Carlborg <doob@me.com> wrote:

> On 2011-06-21 19:36, Jonathan M Davis wrote:
>> On 2011-06-21 10:17, Jacob Carlborg wrote:
>>> Maybe I was a bit too harsh saying that std.benchmark maybe wasn't worth
>>> adding. On the other hand isn't this what the review process is about
>>> (or maybe this is before the review process)? We can't include
>>> EVERYTHING in Phobos or it will become like the Java/C# standard
>>> library, I assume we don't want that.
>>
>> Why not? Granted, we want quality code, and we only have so many people
>> working on Phobos and only so many people to help vet code, but assuming that
>> it can be written at the appropriate level of quality and that the
>> functionality is generally useful, I don't see why we wouldn't want a large
>> standard library like Java and C# have. Given our level of manpower, I don't
>> expect that we'll ever have a standard library that large, but I don't see why
>> having a large standard library would be a bad thing as long as it's of high
>> quality and its functionality is generally useful.
>>
>> - Jonathan M Davis
>
> I just got that impression. That we want a relative small standard library and have other libraries available as well.
>

I see only one perspective from which you would like to not have
standard libs as large as C# an Java provided the quality of the code is
good and that is the fact that you can't realistically hope to have the
IDEs they have which integrate facilities to access the documentation very
easily or one can just to rely on auto-completion (which also gives Java
and C# the luxury to use very very explicit and strait forward naming).
This is worthy of consideration for phobos (the fact
that it doesn't come bundled with an IDE like C#). Otherwise it is good
to have as much std as possible and useful. My only concern (excepting
bugs and holes in Phobos) is that the packages are not grouped at all
and that increases the time (at least for a noob) it take to search
through the documentation and the code. Also there is some ambiguity to
regarding the place of some functionality like std.array and std.string
(I fond myself surprised in other areas but I can't remember right now)
which I imagine it could be fixed simply by intelligently using D module
system. But maybe there are reasons for doing it this way which I don't
get.
-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On 2011-06-21 14:27, Byakkun wrote:
> On Tue, 21 Jun 2011 21:01:07 +0300, Jacob Carlborg <doob@me.com> wrote:
> > On 2011-06-21 19:36, Jonathan M Davis wrote:
> >> On 2011-06-21 10:17, Jacob Carlborg wrote:
> >>> Maybe I was a bit too harsh saying that std.benchmark maybe wasn't
> >>> worth
> >>> adding. On the other hand isn't this what the review process is about
> >>> (or maybe this is before the review process)? We can't include
> >>> EVERYTHING in Phobos or it will become like the Java/C# standard
> >>> library, I assume we don't want that.
> >> 
> >> Why not? Granted, we want quality code, and we only have so many people
> >> working on Phobos and only so many people to help vet code, but
> >> assuming that
> >> it can be written at the appropriate level of quality and that the
> >> functionality is generally useful, I don't see why we wouldn't want a
> >> large
> >> standard library like Java and C# have. Given our level of manpower, I
> >> don't
> >> expect that we'll ever have a standard library that large, but I don't
> >> see why
> >> having a large standard library would be a bad thing as long as it's of
> >> high
> >> quality and its functionality is generally useful.
> >> 
> >> - Jonathan M Davis
> > 
> > I just got that impression. That we want a relative small standard library and have other libraries available as well.
> 
> I see only one perspective from which you would like to not have
> standard libs as large as C# an Java provided the quality of the code is
> good and that is the fact that you can't realistically hope to have the
> IDEs they have which integrate facilities to access the documentation very
> easily or one can just to rely on auto-completion (which also gives Java
> and C# the luxury to use very very explicit and strait forward naming).
> This is worthy of consideration for phobos (the fact
> that it doesn't come bundled with an IDE like C#). Otherwise it is good
> to have as much std as possible and useful. My only concern (excepting
> bugs and holes in Phobos) is that the packages are not grouped at all
> and that increases the time (at least for a noob) it take to search
> through the documentation and the code. Also there is some ambiguity to
> regarding the place of some functionality like std.array and std.string
> (I fond myself surprised in other areas but I can't remember right now)
> which I imagine it could be fixed simply by intelligently using D module
> system. But maybe there are reasons for doing it this way which I don't
> get.

As far as std.array vs std.string goes, functionality which generalizes to arrays is supposed to be in std.array, whereas functionality which only makes sense for strings belongs in std.string. For instance, toUpper makes sense in std.string but not in std.array, since it only makes sense to uppercase strings, not general characters, whereas a function like replicate makes sense for arrays in general, so it's in std.array. Where it's likely to be surprising is with functions like split where you would initially think that it applies only to strings, but it has an overload which is more generally applicable, so it's in std.array. And several functions were moved to std.array from std.string a couple of releases back, so if you were used to having them in std.string, it could throw you off. There are probably a few places where functions might be better moved to another module, and there are definitely cases where it's debatable whether they belong in one module or another, but overall things are fairly well organized. In some cases, we may eventually have to move to a deeper hierarchy, but with what we have at the moment, I don't think a deeper hierarchy would help us much. It's not like Java where everything is a class and every class is in its own module. In that kind of environment, you pretty much have to have a deep hierarchy. But that's not the case with D.

- Jonathan M Davis

"Jacob Carlborg" <doob@me.com> wrote in message news:itpn8m$1c1i$1@digitalmars.com...
>
> "target" works like this:
>
> 1. You call "target" passing in the name of the target and a block
>
> 2. "target" then call the block passing in an instance of a Target class (or similar)
>
> 3. In the block you then specify all the necessary settings you need for this particular target.
>
> You should only call "target" once for each target. So, if you pass in "name2" instead of "name" you would create a new target. I haven't figured out what should happen if you call "target" twice with the same name.
>
> Also note that this would be sufficient:
>
> target "name" do
>     flags "-l-lz"
> end
>
> In that case you wouldn't even have to care about "t" or that it even exists an instance behind the since. It would just be syntax.
>
> You can have a look at how Rake and Rubgems do this:
>
> If you look at the Rake examples: http://en.wikipedia.org/wiki/Rake_%28software%29 then a target would work the same as a Rake task.
>
> Have a look at the top example of: http://rubygems.rubyforge.org/rubygems-update/Gem/Specification.html
>

FWIW, I've been using Rake heavily on a non-D project for about a year or so, and the more I use it the more I keep wishing I could just use D instead of of Ruby. That may have a lot to do with why I'm so interested in seeing Dake use D. Of course, I realize that Dake isn't Rake and isn't going to be exactly the same, but it's still Ruby instead of D and that's proven to be the #1 issue that I have with Rake.

On 2011-06-21 20:11, Jimmy Cao wrote:
> On Tue, Jun 21, 2011 at 1:01 PM, Jacob Carlborg <doob@me.com
> <mailto:doob@me.com>> wrote:
>
>     On 2011-06-21 19:36, Jonathan M Davis wrote:
>
>         On 2011-06-21 10:17, Jacob Carlborg wrote:
>
>             Maybe I was a bit too harsh saying that std.benchmark maybe
>             wasn't worth
>             adding. On the other hand isn't this what the review process
>             is about
>             (or maybe this is before the review process)? We can't include
>             EVERYTHING in Phobos or it will become like the Java/C# standard
>             library, I assume we don't want that.
>
>
>         Why not? Granted, we want quality code, and we only have so many
>         people
>         working on Phobos and only so many people to help vet code, but
>         assuming that
>         it can be written at the appropriate level of quality and that the
>         functionality is generally useful, I don't see why we wouldn't
>         want a large
>         standard library like Java and C# have. Given our level of
>         manpower, I don't
>         expect that we'll ever have a standard library that large, but I
>         don't see why
>         having a large standard library would be a bad thing as long as
>         it's of high
>         quality and its functionality is generally useful.
>
>         - Jonathan M Davis
>
>
>     I just got that impression. That we want a relative small standard
>     library and have other libraries available as well.
>
>     --
>     /Jacob Carlborg
>
>
> What's wrong with having a standard library like C#'s?  It's one of the
> greatest advantages of .NET programming.

I'm not saying it's something wrong with having a standard library as C#/Java. Again, I just got that impression. Emphasis on "impression".

-- 
/Jacob Carlborg