On 2011-06-21 23: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.

Again, I'm NOT saying I don't want standard library like Java/C#.

-- 
/Jacob Carlborg

On 2011-06-22 06:13, Nick Sabalausky wrote:
> "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.

Too bad you feel that about Ruby, I think it's a great language. Maybe you don't have a choice of using Rake or not but the reason I see why anyone would choose Rake is because the rakefiles are in Ruby.

-- 
/Jacob Carlborg

On 2011-06-21 07:17, Andrei Alexandrescu wrote:
> On 6/21/11 9:14 AM, Lars T. Kyllingstad wrote:
> > On Tue, 21 Jun 2011 08:21:57 -0500, Andrei Alexandrescu wrote:
> >> On 6/21/11 1:58 AM, Lars T. Kyllingstad wrote:
> >>> On Mon, 20 Jun 2011 17:32:32 -0500, Andrei Alexandrescu wrote:
> >>>> On 6/20/11 4:28 PM, Jacob Carlborg wrote:
> >>>>> 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.
> >>> 
> >>> I think we should.  Also, now that TempAlloc isn't up for review anymore, and both std.log and std.path have to be postponed a few weeks, the queue is open. :)
> >>> 
> >>> -Lars
> >> 
> >> Perfect. Anyone would want to be the review manager? Lars? :o)
> > 
> > I would, but in two weeks I am going away on vacation, and that will be in the middle of the review process.  Any other volunteers?
> > 
> > -Lars
> 
> BTW if libcurl is ready for review that should be the more urgent item.

It looks like libcurl needs more bake time first, so if we're going to review std.benchmark, it can go first. Since, no one else has stepped forward to do it, I can be the review manager. Given the relative simplicity of std.benchmark and the fact that something like half of it was in std.datetime to begin with, do you think that reviewing until July 1st (a little over a week) would be enough before voting on it, or do you think that it should go longer? We can always extend the time if it turns out that it needs a longer period than that, but if you think that it's likely to need more review and update, then we might as well select a longer time to begin with.

- Jonathan M Davis