On 21.06.2011 13:07, Jacob Carlborg wrote:
> On 2011-06-21 00:30, Dmitry Olshansky wrote:
>> On 21.06.2011 1:36, Jacob Carlborg wrote:
>>> On 2011-06-20 22:45, Dmitry Olshansky wrote:
>>>> On 20.06.2011 23:39, Nick Sabalausky wrote:
>>>>> "Dmitry Olshansky"<dmitry.olsh@gmail.com> wrote in message
>>>>> news:itn2el$2t2v$1@digitalmars.com...
>>>>>> On 20.06.2011 12:25, Jacob Carlborg wrote:
>>>>>>> On 2011-06-19 22:28, Dmitry Olshansky wrote:
>>>>>>>
>>>>>>>> Why having name as run-time parameter? I'd expect more like (given
>>>>>>>> there
>>>>>>>> is Target struct or class):
>>>>>>>> //somewhere at top
>>>>>>>> Target cool_lib, ...;
>>>>>>>>
>>>>>>>> then:
>>>>>>>> with(cool_lib) {
>>>>>>>> flags = "-L-lz";
>>>>>>>> }
>>>>>>>>
>>>>>>>> I'd even expect special types like Executable, Library and so on.
>>>>>>> The user shouldn't have to create the necessary object. If it
>>>>>>> does, how
>>>>>>> would the tool get it then?
>>>>>>>
>>>>>> If we settle on effectively evaluating orbspec like this:
>>>>>> //first module
>>>>>> module orb_orange;
>>>>>> mixin(import ("orange.orbspec"));
>>>>>> //
>>>>>>
>>>>>> // builder entry point
>>>>>> void main()
>>>>>> {
>>>>>> foreach(member; __traits(allMembers, orb_orange))
>>>>>> {
>>>>>> static if(typeof(member) == Target){
>>>>>> //do necessary actions, sort out priority and construct a
>>>>>> worklist
>>>>>> }
>>>>>> else //static if (...) //...could be others I mentioned
>>>>>> {
>>>>>> }
>>>>>> }
>>>>>> //all the work goes there
>>>>>> }
>>>>>>
>>>>>> Should be straightforward? Alternatively with local imports we can
>>>>>> pack it
>>>>>> in a struct instead of separate module, though errors in script
>>>>>> would be
>>>>>> harder to report (but at least static constructors would be
>>>>>> controlled!).
>>>>>> More adequatly would be, of course, to pump it to dmd from stdin...
>>>>>>
>>>>> Target would be part of Orb. Why not just make Target's ctor register
>>>>> itself
>>>>> with the rest of Orb?
>>>>>
>>>>>
>>>> Nice thinking, but default constructors for structs?
>>>> Of course, it could be a class... Then probably there could be usefull
>>>> derived things like these Executable, Library, etc.
>>>
>>> I really don't like that the users needs to create the targets. The
>>> good thing about Ruby is that the user can just call a function and
>>> pass a block to the function. Then the tool can evaluate the block in
>>> the context of an instance. The user would never have to care about
>>> instances.
>>>
>> I'm not getting what's wrong with it. Your magical block is still
>> getting some _name_ as string right? I suspect it's even an advantage if
>> you can't type pass arbitrary strings to a block only proper instances,
>> e.g. it's harder to mistype a name due to a type checking.
>
> This is starting to get confusing. You're supposed to be passing an arbitrary strings to the function and then _receive_ an instance to the block.
>
>> What's so good about having to type all these name over and over again
>> without keeping track of how many you inadvertently referenced?
>
> You shouldn't have to repeat the name.
>
>> Taking your example, what if I typed name2 instead of name here, what
>> would be the tool actions:
>> target "name" do |t|
>> t.flags = "-L-lz"
>> end
>
> "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
>
So it's a way to _create_ instances. I suspected there could be need to add some extra options to existing. Imagine creating special version of package, IMO it's better when all this extra is packaged at one place not in every block.

BTW this doesn't look any better then possible D version:

spec = Gem::Specification.new do |s|
  s.name = 'example'
  s.version = '1.0'
  s.summary = 'Example gem specification'
  ...
end

In any case there is now instance named spec, right? So user still have to manage some variables...


> 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
>
>> Create new target and set it's flags? I can't see a reasonable error
>> checking to disambiguate it at all.
>> More then that now I'm not sure what it was supposed to do in the first
>> place - update flags of existing Target instance with name "name" ?
>> Right now I think it could be much better to initialize them in the
>> first place.
>>
>> IMHO every time I create a build script I usually care about number of
>> targets and their names.
>>
>> P.S. Also about D as config language : take into account version
>> statements, here they make a lot of sense.
>
> Yes, version statements will be available as well.
>


-- 
Dmitry Olshansky

On 2011-06-21 12:04, Dmitry Olshansky wrote:
> On 21.06.2011 13:07, Jacob Carlborg wrote:
>> "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
>>
> So it's a way to _create_ instances. I suspected there could be need to
> add some extra options to existing. Imagine creating special version of
> package, IMO it's better when all this extra is packaged at one place
> not in every block.
>
> BTW this doesn't look any better then possible D version:
>
> spec = Gem::Specification.new do |s|
> s.name = 'example'
> s.version = '1.0'
> s.summary = 'Example gem specification'
> ...
> end
>
> In any case there is now instance named spec, right? So user still have
> to manage some variables...

No, no, no. Have you read my previous messages and the wiki? That above syntax is used by Rubygems, Rake uses a similar and Orbit and Dake will also use a similar syntax but will still be slightly different. The concepts are the same, with calling a method and passing along a block.

The syntax used by Orbit doesn't actually need blocks at all because you can only have one package in one orbspec. The syntax will look like this:

name "example"
version "1.0"
summary "Example gem specification"

Dake will have blocks in the syntax for its config files, this is because multiple targets and tasks are supported within the same file. The syntax will look like this:

target "<name>" do
    flags "-L-l"
    product "foobar"
    type :executable
end

In this case, <name> would refer to a single D file or a directory with multiple D files. If you want to have settings for multiple targets then you just put that code outside any of the blocks, at the global scope (or pass a block to a method name "global", haven't decided yet).

And similar for tasks:

task "foo" do
    # do something
end

A task is just some code you can run from the command line via the tool:

dake foo

As you can see, no variables and no instances for the user to keep track of. Seems that I actually do need to write down a complete specification for these config/spec files.

-- 
/Jacob Carlborg

On 21.06.2011 15:53, Jacob Carlborg wrote:
> On 2011-06-21 12:04, Dmitry Olshansky wrote:
>> On 21.06.2011 13:07, Jacob Carlborg wrote:
>>> "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
>>>
>> So it's a way to _create_ instances. I suspected there could be need to
>> add some extra options to existing. Imagine creating special version of
>> package, IMO it's better when all this extra is packaged at one place
>> not in every block.
>>
>> BTW this doesn't look any better then possible D version:
>>
>> spec = Gem::Specification.new do |s|
>> s.name = 'example'
>> s.version = '1.0'
>> s.summary = 'Example gem specification'
>> ...
>> end
>>
>> In any case there is now instance named spec, right? So user still have
>> to manage some variables...
>
> No, no, no. Have you read my previous messages and the wiki? That above syntax is used by Rubygems, Rake uses a similar and Orbit and Dake will also use a similar syntax but will still be slightly different. The concepts are the same, with calling a method and passing along a block.
>
> The syntax used by Orbit doesn't actually need blocks at all because you can only have one package in one orbspec. The syntax will look like this:
>
> name "example"
> version "1.0"
> summary "Example gem specification"

Very sensible, no arguments.

>
> Dake will have blocks in the syntax for its config files, this is because multiple targets and tasks are supported within the same file. The syntax will look like this:
>
> target "<name>" do
>     flags "-L-l"
>     product "foobar"
>     type :executable
> end
>

Yes, this is the one I'm not entirely happy with, admittedly because it's a ruby script (and it's respective magic).
 I just hope you can embed Ruby interpreter inside dake so that user need not to care about having proper ruby installation (and it's correct version too).

> In this case, <name> would refer to a single D file or a directory with multiple D files. If you want to have settings for multiple targets then you just put that code outside any of the blocks, at the global scope (or pass a block to a method name "global", haven't decided yet).

Good so far.

>
> And similar for tasks:
>
> task "foo" do
>     # do something
> end
>
> A task is just some code you can run from the command line via the tool:
>
> dake foo
>
> As you can see, no variables and no instances for the user to keep track of. Seems that I actually do need to write down a complete specification for these config/spec files.
>

I'm still looking for a clean version statements... but I'll just have to wait till you have the full spec I guess.

-- 
Dmitry Olshansky

On 2011-06-21 14:12, Dmitry Olshansky wrote:
> On 21.06.2011 15:53, Jacob Carlborg wrote:
>> On 2011-06-21 12:04, Dmitry Olshansky wrote:
>>> On 21.06.2011 13:07, Jacob Carlborg wrote:
>>>> "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
>>>>
>>> So it's a way to _create_ instances. I suspected there could be need to
>>> add some extra options to existing. Imagine creating special version of
>>> package, IMO it's better when all this extra is packaged at one place
>>> not in every block.
>>>
>>> BTW this doesn't look any better then possible D version:
>>>
>>> spec = Gem::Specification.new do |s|
>>> s.name = 'example'
>>> s.version = '1.0'
>>> s.summary = 'Example gem specification'
>>> ...
>>> end
>>>
>>> In any case there is now instance named spec, right? So user still have
>>> to manage some variables...
>>
>> No, no, no. Have you read my previous messages and the wiki? That
>> above syntax is used by Rubygems, Rake uses a similar and Orbit and
>> Dake will also use a similar syntax but will still be slightly
>> different. The concepts are the same, with calling a method and
>> passing along a block.
>>
>> The syntax used by Orbit doesn't actually need blocks at all because
>> you can only have one package in one orbspec. The syntax will look
>> like this:
>>
>> name "example"
>> version "1.0"
>> summary "Example gem specification"
>
> Very sensible, no arguments.
>
>>
>> Dake will have blocks in the syntax for its config files, this is
>> because multiple targets and tasks are supported within the same file.
>> The syntax will look like this:
>>
>> target "<name>" do
>> flags "-L-l"
>> product "foobar"
>> type :executable
>> end
>>
>
> Yes, this is the one I'm not entirely happy with, admittedly because
> it's a ruby script (and it's respective magic).
> I just hope you can embed Ruby interpreter inside dake so that user need
> not to care about having proper ruby installation (and it's correct
> version too).

Of course, Ruby will be embedded. I already have this working in Orbit. I'm very careful when choosing the dependencies my application/tools depends on. Another reason I'm not happy about switching to D2, then it would depend on libcurl.

>> In this case, <name> would refer to a single D file or a directory
>> with multiple D files. If you want to have settings for multiple
>> targets then you just put that code outside any of the blocks, at the
>> global scope (or pass a block to a method name "global", haven't
>> decided yet).
>
> Good so far.
>
>>
>> And similar for tasks:
>>
>> task "foo" do
>> # do something
>> end
>>
>> A task is just some code you can run from the command line via the tool:
>>
>> dake foo
>>
>> As you can see, no variables and no instances for the user to keep
>> track of. Seems that I actually do need to write down a complete
>> specification for these config/spec files.
>>
>
> I'm still looking for a clean version statements... but I'll just have
> to wait till you have the full spec I guess.

if version.linux || version.osx
    #
end

This allows to use versions just as bool values.

-- 
/Jacob Carlborg

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)

Andrei

On Jun 21, 11 21:03, Jacob Carlborg wrote:
> On 2011-06-21 14:12, Dmitry Olshansky wrote:
[snip]
>
> Of course, Ruby will be embedded. I already have this working in Orbit.
> I'm very careful when choosing the dependencies my application/tools
> depends on. Another reason I'm not happy about switching to D2, then it
> would depend on libcurl.
>

It doesn't. You need libcurl only if you need to use the etc.c.curl interface.

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.

>>> 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

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

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.

Andrei

On 2011-06-21 15:26, KennyTM~ wrote:
> On Jun 21, 11 21:03, Jacob Carlborg wrote:
>> On 2011-06-21 14:12, Dmitry Olshansky wrote:
> [snip]
>>
>> Of course, Ruby will be embedded. I already have this working in Orbit.
>> I'm very careful when choosing the dependencies my application/tools
>> depends on. Another reason I'm not happy about switching to D2, then it
>> would depend on libcurl.
>>
>
> It doesn't. You need libcurl only if you need to use the etc.c.curl
> interface.

First, I need curl, or similar. Second, as I've said in a previous post I don't want to and will not use a low level socket.

-- 
/Jacob Carlborg