On 19.06.2011 23:57, Jacob Carlborg wrote:
> On 2011-06-19 20:41, Nick Sabalausky wrote:
>> "Jacob Carlborg"<doob@me.com>  wrote in message
>> news:itko61$1qdm$1@digitalmars.com...
>>> On 2011-06-18 21:35, Nick Sabalausky wrote:
>>>>
>>>> I'd probably consider something more like:
>>>>
>>>> orb.ver = "1.0.0";
>>>> orb.author = "Jacob Carlborg";
>>>> orb.type = Type.library;
>>>> orb.imports = ["a.d", "b.di"]; // an array of import files
>>>
>>> That would be doable in Ruby as well. I though it would be better to not
>>> have to write "orb." in front of every method. Note the following syntax
>>> is not possible in Ruby:
>>>
>>> ver = "1.0.0"
>>> author = "Jacob Carlborg"
>>> type = Type.library
>>> imports = ["a.d", "b.di"]
>>>
>>> The above syntax is what I would prefer but it doesn't work in Ruby, would
>>> create local variables and not call instance methods. Because of that I
>>> chose the syntax I chose, the least verbose syntax I could think of.
>>>
>>
>> That syntax should be doable in D.
>>
>>
>>>>> DSSS forced an INI-similar syntax on people.
>>>>>
>>>>
>>>> INI-syntax is trivial. Especially compared to Ruby (or D for that matter,
>>>> to
>>>> be perfectly fair).
>>>
>>> I was thinking that the Ruby syntax was as easy and trivial as the
>>> INI-syntax if you just use the basic, like I have in the examples. No need
>>> to use if-statements, loops or classes. That's just for packages that need
>>> to do very special things.
>>>
>>
>> But then the people who do such fancy things have to do it in Ruby instead
>> of D.
>>
>>> To take the DSSS syntax again as an example:
>>>
>>> # legal syntax
>>> version (Windows) {
>>> }
>>>
>>> # illegal syntax
>>> version (Windows)
>>> {
>>> )
>>>
>>> I assume this is because the lexer/parser is very simple. You don't have
>>> this problem if you use a complete language for the config/spec files.
>>>
>>
>> Right. And D is a complete language.
>>
>>>>
>>>> 1. The amount of extra stuff is fairly minimal. *Especially* in the
>>>> majority
>>>> of cases where the user uses the standard name ("orbconf.d" or whatever
>>>> you
>>>> want to call it).
>>>
>>> OK, I guess you can get away without the IO, but you still need the extra
>>> processes.
>>>
>>
>> That should be pretty quick.
>
> Ok, for now I will continue with Ruby and see how it goes. One thing I do think looks really ugly in D are delegates. For the Dake config file, I'm thinking that it would allow several targets and tasks (like rake), which would looks something like this (in Ruby):
>
> target "name" do |t|
>     t.flags = "-L-lz"
> end
>
> In D this would look something like this:
>
> target("name", (Target t) {
>     t.flags = "-L-lz"
> });
>
> Or with operator overload abuse:
>
> target("name") in (Target t) {
>     t.flags = "-L-lz"
> };
>
> I would so love if this syntax (that's been suggested before) was supported:
>
> target("name", Target t) {
>     t.flags = "-L-lz"
> }

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.
>
> If anyone have better ideas for how this can be done I'm listening.
>
> One other thing, syntax below can be thought of like a compile time eval:
>
> void main ()
> {
>     mixin(import("file.d"));
> }
>
> Does anyone have an idea if it would be possible to do the corresponding to instance eval that is available in some scripting languages?
>


-- 
Dmitry Olshansky

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?

-- 
/Jacob Carlborg

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

-- 
Dmitry Olshansky

On 2011-06-20 10:59, Dmitry Olshansky wrote:
> 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...

I had no idea that you could do that. It seems somewhat complicated and like a hack. Also note that Orbit is currently written in D1, which doesn't have __traits.

-- 
/Jacob Carlborg

On 20.06.2011 15:35, Jacob Carlborg wrote:
> On 2011-06-20 10:59, Dmitry Olshansky wrote:
>> 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...
>
> I had no idea that you could do that. It seems somewhat complicated and like a hack. Also note that Orbit is currently written in D1, which doesn't have __traits.
>

Well, everything about compile-time introspection could be labeled like a hack. In fact I just seen the aforementioned "hack" on a much grander scale being used in upcoming std module, see std.benchmarking:
https://github.com/D-Programming-Language/phobos/pull/85/files#L1R577
And personally hacks should  look ugly or they are just features or at best shortcuts ;)

Personal things aside I still suggest you to switch it to D2. I can understand if Phobos is just not up to snuff for you yet (btw cute curl wrapper is coming in a matter of days). But other then that... just look at all these candies ( opDispatch anyone? )   :)
And even if porting is a piece of work, I suspect there a lot of people out there that would love to help this project.
(given the lofty goal that config would be written in D, and not Ruby)

-- 
Dmitry Olshansky

On 20.06.2011 16:35, Dmitry Olshansky wrote:
> On 20.06.2011 15:35, Jacob Carlborg wrote:
>> On 2011-06-20 10:59, Dmitry Olshansky wrote:
>>> 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...
>>
>> I had no idea that you could do that. It seems somewhat complicated and like a hack. Also note that Orbit is currently written in D1, which doesn't have __traits.
>>
>
> Well, everything about compile-time introspection could be labeled like a hack. In fact I just seen the aforementioned "hack" on a much grander scale being used in upcoming std module, see std.benchmarking:
> https://github.com/D-Programming-Language/phobos/pull/85/files#L1R577
> And personally hacks should  look ugly or they are just features or at best shortcuts ;)
>
> Personal things aside I still suggest you to switch it to D2. I can understand if Phobos is just not up to snuff for you yet (btw cute curl wrapper is coming in a matter of days). But other then that... just look at all these candies ( opDispatch anyone? )   :)
> And even if porting is a piece of work, I suspect there a lot of people out there that would love to help this project.
> (given the lofty goal that config would be written in D, and not Ruby)
>
Just looked through the source , it seems like you are doing a lot of work that's already been done in Phobos, so it might be worth doing a port to D2. Some simple wrappers might be needed, but ultimately:
util.traits --> std.traits
core.array --> std.array + std.algorithm
io.path --> std.file & std.path
orgb.util.OptinoParser --> std.getopt

util.singleton should probably be pulled into Phobos, but a thread safe shared version.

-- 
Dmitry Olshansky

Jacob Carlborg wrote:
> I had no idea that you could do that. It seems somewhat complicated and like a hack.

There's nothing really hacky about that - it's a defined and fairly complete part of the language.

It's simpler than it looks too... the syntax is slightly long, but conceptually, you're just looping over an array of members.

Combined with the stuff in std.traits to make it a little simpler, there's lots of nice stuff you can do in there.

On Sat, 18 Jun 2011 23:33:29 -0400, Daniel Murphy <yebblies@nospamgmail.com> wrote:

> "Jacob Carlborg" <doob@me.com> wrote in message
> news:iti35g$2r4r$2@digitalmars.com...
>>
>> That seems cool. But, you would want to write the pluing in D and that's
>> not possible yet on all platforms? Or should everything be done with
>> extern(C), does that work?
>>
>
> Yeah, it won't be possible to do it all in D until we have .so's working on
> linux etc, which I think is a while off yet.  Although this could be worked
> around by writing a small loader in c++ and using another process (written
> in D) to do the actual work.  Maybe it would be easier to build dmd as a
> shared lib (or a static lib) and just provide a different front...
>
> My point is that the compiler can quite easily be modified to allow it to
> pass pretty much anything (missing imports, pragma(lib), etc) to a build
> tool, and it should be fairly straightforward for the build tool to pass
> things back in (adding objects to the linker etc).  This could allow single
> pass full compilation even when the libraries need to be fetched off the
> internet.  It could also allow seperate compilation of several source files
> at once, without having to re-do parsing+semantic each time.  Can dmd
> currently do this?
> Most importantly it keeps knowledge about urls and downloading files outside
> the compiler, where IMO it does not belong.

Note the current proposal does exactly what you are looking for, but does it via processes and command line instead of dlls.  This opens up numerous avenues of implementation (including re-using already existing utilities), plus keeps it actually separated (i.e. a dll/so can easily corrupt the memory of the application, whereas a separate process cannot).

-Steve

On 6/20/11 6:35 AM, Jacob Carlborg wrote:
> On 2011-06-20 10:59, Dmitry Olshansky wrote:
>> 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...
>
> I had no idea that you could do that. It seems somewhat complicated and
> like a hack. Also note that Orbit is currently written in D1, which
> doesn't have __traits.

std.benchmark (https://github.com/D-Programming-Language/phobos/pull/85) does that, too. Overall I believe porting Orbit to D2 and making it use D2 instead of Ruby in configuration would increase its chances to become popular and accepted in tools/.

Andrei

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