On Thu, 03 Sep 2009 19:45:44 -0400, Robert Jacques <sandford@jhu.edu> wrote:

> Thanks for yet another great release, but.. has anyone else gotten DFL to compile? (The latest svn of DFL worked fine in 2.031)
>
> I've been trying to get it up and running but I've been seeing really weird errors. It appears in several cases that various import statements are not being imported. For example:
>
>      import dfl.menu;
>      import dfl.form;
>
> Seems to import the menu classes, but not the form classes. And
>
>      import dfl.form;
>      import dfl.menu;
>
> does the opposite.
>
> I tried tracing the issue down (from control.d -> menu.d -> application.d -> form.d, testing using dfl.internal.winapi) and it looked like I found a single line of code in form.d
>
> version(NO_MDI) {} else {
> // commented out source
> }
>
> in which a public import dfl.internal.winapi worked above and didn't work below. But, when I tried to make a simple test case, everything worked. And then when I came back to full source, that test worked too, as did form (But that was only because I had publicly imported it from application.d & application from menu.d)

With some more hacking, I've gotten it to compile. It appears to be something to do in how cyclic (+ private duplicates?) imports are handled. I made everything public and then commented out some of the redundant imports. The strange thing is that I didn't have to remove all cycles or all redundant imports to get it compiling. I did get a less hacked up version running (package imports + removed redundancies), but I had to turn off drag and drop support in order to get it to compile and swapping around certain import statements still causes errors.

On 9/4/09 01:45, Robert Jacques wrote:
> Thanks for yet another great release, but.. has anyone else gotten DFL
> to compile? (The latest svn of DFL worked fine in 2.031)
>
> I've been trying to get it up and running but I've been seeing really
> weird errors. It appears in several cases that various import statements
> are not being imported. For example:
>
> import dfl.menu;
> import dfl.form;
>
> Seems to import the menu classes, but not the form classes. And
>
> import dfl.form;
> import dfl.menu;
>
> does the opposite.
>
> I tried tracing the issue down (from control.d -> menu.d ->
> application.d -> form.d, testing using dfl.internal.winapi) and it
> looked like I found a single line of code in form.d
>
> version(NO_MDI) {} else {
> // commented out source
> }
>
> in which a public import dfl.internal.winapi worked above and didn't
> work below. But, when I tried to make a simple test case, everything
> worked. And then when I came back to full source, that test worked too,
> as did form (But that was only because I had publicly imported it from
> application.d & application from menu.d)

I have similar problems with one of my projects. Seems like many import statements stop working.

/Jacob Carlborg

Don:

>CTFE is almost completely isolated from the rest of the compiler: it can't break anything that's  not CTFE.<

It's like having a compiler plus a D1 interpreter. In theory this duplication looks silly, in practice it seems handy.


>It is likely, for example, that unions will need to be disallowed in CTFE,<

Can you tell me why?


>but there's absolutely no reason why 'new' expressions should be disallowed.<

There's a compiler for a small language (designed for embedded CPUs) that allows to allocate objects at compile time (it also compacts their fields in smart ways, grouping fields of similar type from more than one object in a transversal way into arrays of single fields, and compacting pointers reducing their size, to save memory and speed up programs a little), and then at runtime the memory can't be allocated dynamically. D can do something similar, allocating such compile-time objects. It may save running time. I'd like to know what people think about this.

Bye,
bearophile

bearophile wrote:
> Don:
> 
>> CTFE is almost completely isolated from the rest of the compiler: it can't break anything that's  not CTFE.<
> 
> It's like having a compiler plus a D1 interpreter. In theory this duplication looks silly, in practice it seems handy.

Interestingly, by *requiring* the compiler to provide an interpreter, the language can make optimisation guarantees about constant folding, _independent of the backend_.

>> It is likely, for example, that unions will need to be disallowed in CTFE,<
> 
> Can you tell me why?

Suppose you have:

align(2):
struct S
{
  char d;
  int a;
  char [2] b;
}

union U {
  byte[5] a;
  double x;
  S c;
}

and you write to u.c.d, and u.a[3] what value is x? It's disgusting. Depends on the endianness of the target system, for example.

>> but there's absolutely no reason why 'new' expressions should be disallowed.<
I mean things like:
int [] a = new int[n];
which is trivial -- about 5 lines of code.

Oh. And the D1 spec doesn't disallow inline asm in CTFE.
But CTFE asm is Not Going To Happen. <g>

Don wrote:
> Oh. And the D1 spec doesn't disallow inline asm in CTFE.
> But CTFE asm is Not Going To Happen. <g>

I think that eventually we can get all of SafeD to work in CTFE, but inline asm isn't part of SafeD!

Don:

> >> but there's absolutely no reason why 'new' expressions should be disallowed.<
> I mean things like:
> int [] a = new int[n];
> which is trivial -- about 5 lines of code.

I hope to see such trivial thing in future DMDs :-)
So it may simplify the code I've shown here:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=16767

(Or I'd like to be able to return fixed-sized arrays (by value?) from functions).

Bye,
bearophile

On Fri, 04 Sep 2009 04:40:51 -0400, Robert Jacques <sandford@jhu.edu> wrote:

> On Thu, 03 Sep 2009 19:45:44 -0400, Robert Jacques <sandford@jhu.edu> wrote:
>
>> Thanks for yet another great release, but.. has anyone else gotten DFL to compile? (The latest svn of DFL worked fine in 2.031)
>>
>> I've been trying to get it up and running but I've been seeing really weird errors. It appears in several cases that various import statements are not being imported. For example:
>>
>>      import dfl.menu;
>>      import dfl.form;
>>
>> Seems to import the menu classes, but not the form classes. And
>>
>>      import dfl.form;
>>      import dfl.menu;
>>
>> does the opposite.
>>
>> I tried tracing the issue down (from control.d -> menu.d -> application.d -> form.d, testing using dfl.internal.winapi) and it looked like I found a single line of code in form.d
>>
>> version(NO_MDI) {} else {
>> // commented out source
>> }
>>
>> in which a public import dfl.internal.winapi worked above and didn't work below. But, when I tried to make a simple test case, everything worked. And then when I came back to full source, that test worked too, as did form (But that was only because I had publicly imported it from application.d & application from menu.d)
>
> With some more hacking, I've gotten it to compile. It appears to be something to do in how cyclic (+ private duplicates?) imports are handled. I made everything public and then commented out some of the redundant imports. The strange thing is that I didn't have to remove all cycles or all redundant imports to get it compiling. I did get a less hacked up version running (package imports + removed redundancies), but I had to turn off drag and drop support in order to get it to compile and swapping around certain import statements still causes errors.

Well, I got drag and drop working. More importantly, I've manage to make a small test case to put into bugzilla: http://d.puremagic.com/issues/show_bug.cgi?id=3301

On Thu, Sep 3, 2009 at 10:16, Walter Bright<newshound1@digitalmars.com> wrote:
> This will probably be the last OSX 10.5 release, the next should be 10.6.
>
> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.047.zip
>
>
> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.032.zip
>
> Many thanks to the numerous people who contributed to this update.
>

Why the last for OS X 10.5? You can compile software for 10.5 on 10.6 just like you would compile for 10.4 on 10.5. Are you planning on using some Snow Leopard-only features?

-- 
Anders Bergh

Anders Bergh wrote:
> Why the last for OS X 10.5? You can compile software for 10.5 on 10.6
> just like you would compile for 10.4 on 10.5. Are you planning on
> using some Snow Leopard-only features?

Apple apparently changed how the linker works. The 10.5 linker does not work as documented, and it took some kludging to get it to work. I doubt that changing the kludges to work with 10.6 will continue to work with 10.5.

Its great to see so many bugs being sorted out.

However, I am having all kinds of trouble with "shared", which up until now I have been able to fairly easily sidestep. Here is a cut-down example of what I am trying to do, which is to have one thread acquiring data and passing it on to another thread via a queue which uses appropriate synchronization mechanisms to make things thread-safe. The data passed through is immutable, so theoretically everything should be fine.

This kind of thing is very routine in multi-threaded programs, and should be easy to pull off. I find I have to do heaps of nasty casting to get past the compiler (the immutable assignment thing is a side issue).

Is there a neater syntax for this? How about being able to say "shared immutable class Message {...}" (or just shared or just immutable or just const), and then all instances (new, local, parameter, return) would automatically be shared and immutable?


class Message {
    int data_;
    this(int value) {
        data_ = value;
    }
    int get() immutable {
        return data_;
    }
}

// queue-like synchronized container
class Queue {
    immutable(Message) msg_;

    this() {
        msg_ = null;
    }

    synchronized void add(immutable(Message) msg) {
        Message * tmp = cast(Message *) &msg_;
        *tmp = cast(Message) msg;
    }
    synchronized immutable(Message) remove() {
        return msg_;
    }
}


int main(string args[]) {
    // pretend to be one thread queueing an object
    auto queue = cast(shared) new Queue();
    auto message = cast(immutable) cast(shared) new Message(1);
    queue.add(message);

    // pretend to be another thread taking the data and working with it
    return queue.remove.get;
}