I'd like to make a concerted effort to get Mango fully operational on Darwin, because some issues have surfaced there. Those who can help out (Anders! nudge, nudge :-) or are just interested, are invited to http://dsource.org/forums/viewtopic.php?t=546

Thanks!

Kris wrote:

> I'd like to make a concerted effort to get Mango fully operational on Darwin,
> because some issues have surfaced there. Those who can help out (Anders!

I resent the darwin patch, to the email specified.

Think the code is alright, just the compiler left?

--anders

In article <ct8rjm$2hos$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

>I resent the darwin patch, to the email specified.
>
>Think the code is alright, just the compiler left?

Cheers! I'll get your patches into SVN, tonight.

I did notice from the patch file that you had to add a couple of imports ... this would seem to indicate there's a difference (in dmd) between compiling everything at once and doing it piecemeal (aka the traditional 'make' approach).


Is that correct?

Kris wrote:

> I did notice from the patch file that you had to add a couple of imports ...
> this would seem to indicate there's a difference (in dmd) between compiling
> everything at once and doing it piecemeal (aka the traditional 'make' approach).

It still breaks, even if just doing one big "dmd" (really: gdc)
command to compile and link unittest.d and all sources at once,
instead of making the library object files into libmango.a first.

The only import that I added was to mango/log/Hierarchy.d :

> @@ -39,6 +39,7 @@
>  module mango.log.Hierarchy;
>   private import mango.log.Appender;
> +private import mango.log.Logger;
>   /*******************************************************************************
>  

The others imports were just adding "std.c.darwin.darwin"

--anders

Kris wrote:
> In article <ct8rjm$2hos$1@digitaldaemon.com>,
> =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
> 
> 
>>I resent the darwin patch, to the email specified.
>>
>>Think the code is alright, just the compiler left?
> 
> 
> Cheers! I'll get your patches into SVN, tonight. 
> 
> I did notice from the patch file that you had to add a couple of imports ...
> this would seem to indicate there's a difference (in dmd) between compiling
> everything at once and doing it piecemeal (aka the traditional 'make' approach).
> 
> 
> Is that correct?
> 
> 

At least there was earlier. Back in the days of many forward reference problems, some could be fixed by doing the all-at-once approach and rearranging the order until it worked. Then again, this approach often left out the file name when errors occurred, forcing you back to the one-file-at-the-time approach. If differences in the two methods still occur, it suggests that the import handling is lacking, possibly missing imports (probably public imports) or importing to much (probably private imports). It certainly was the case back then, documented by several minimal bug report snippets.

Lars Ivar Igesund

On Wed, 26 Jan 2005 22:42:39 +0100, Lars Ivar Igesund wrote:

> Kris wrote:
>> In article <ct8rjm$2hos$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>> 
>> 
>>>I resent the darwin patch, to the email specified.
>>>
>>>Think the code is alright, just the compiler left?
>> 
>> 
>> Cheers! I'll get your patches into SVN, tonight.
>> 
>> I did notice from the patch file that you had to add a couple of imports ... this would seem to indicate there's a difference (in dmd) between compiling everything at once and doing it piecemeal (aka the traditional 'make' approach).
>> 
>> 
>> Is that correct?
>> 
>> 
> 
> At least there was earlier. Back in the days of many forward reference problems, some could be fixed by doing the all-at-once approach and rearranging the order until it worked. Then again, this approach often left out the file name when errors occurred, forcing you back to the one-file-at-the-time approach. If differences in the two methods still occur, it suggests that the import handling is lacking, possibly missing imports (probably public imports) or importing to much (probably private imports). It certainly was the case back then, documented by several minimal bug report snippets.
> 
> Lars Ivar Igesund

Oh, how I remember those days!  :-(

Heaps of frustration.

I guess things are not quite so bad now, but I'm sure
there are still a few import issues hanging around.

- John R.

In article <ct90n4$2nrs$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Kris wrote:
>
>> I did notice from the patch file that you had to add a couple of imports ... this would seem to indicate there's a difference (in dmd) between compiling everything at once and doing it piecemeal (aka the traditional 'make' approach).
>
>It still breaks, even if just doing one big "dmd" (really: gdc) command to compile and link unittest.d and all sources at once, instead of making the library object files into libmango.a first.
>
>The only import that I added was to mango/log/Hierarchy.d :
>
>> @@ -39,6 +39,7 @@
>>  module mango.log.Hierarchy;
>> 
>>  private import mango.log.Appender;
>> +private import mango.log.Logger;

That indicates a compiler bug: the import of log.Appender has a public import of log.Logger, so it is unnecessary to import the latter a second time.

Can you confirm that this is still the case for GDC?

- Kris

Kris wrote:

>>The only import that I added was to mango/log/Hierarchy.d :
>>
>>>@@ -39,6 +39,7 @@
>>> module mango.log.Hierarchy;
>>> 
>>> private import mango.log.Appender;
>>>+private import mango.log.Logger;
> 
> That indicates a compiler bug: the import of log.Appender has a public import of
> log.Logger, so it is unnecessary to import the latter a second time.
> 
> Can you confirm that this is still the case for GDC?

Here's what I get with Mango 1.1 and GDC 0.10 on Mac OS X:

> mango/log/Hierarchy.d:63: identifier 'Logger' is not defined
> mango/log/Hierarchy.d:63: Logger is used as a type
> mango/log/Hierarchy.d:63: class mango.log.Hierarchy.LoggerInstance base type must be class or interface, not void
> mango/log/Hierarchy.d:68: identifier 'Level' is not defined
> mango/log/Hierarchy.d:68: Level is used as a type
> mango/log/Hierarchy.d:68: variable mango.log.Hierarchy.LoggerInstance.level voids have no value
> mango/log/Hierarchy.d:96: identifier 'Level' is not defined
> mango/log/Hierarchy.d:96: Level is used as a type
> mango/log/Hierarchy.d:96: cannot have parameter of type void

(and there are a few repeats of those missing definitions)

--anders

In article <cta6hc$17os$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Kris wrote:
>
>>>The only import that I added was to mango/log/Hierarchy.d :
>>>
>>>>@@ -39,6 +39,7 @@
>>>> module mango.log.Hierarchy;
>>>> 
>>>> private import mango.log.Appender;
>>>>+private import mango.log.Logger;
>> 
>> That indicates a compiler bug: the import of log.Appender has a public import of log.Logger, so it is unnecessary to import the latter a second time.
>> 
>> Can you confirm that this is still the case for GDC?
>
>Here's what I get with Mango 1.1 and GDC 0.10 on Mac OS X:
>
>> mango/log/Hierarchy.d:63: identifier 'Logger' is not defined
>> mango/log/Hierarchy.d:63: Logger is used as a type
>> mango/log/Hierarchy.d:63: class mango.log.Hierarchy.LoggerInstance base type must be class or interface, not void
>> mango/log/Hierarchy.d:68: identifier 'Level' is not defined
>> mango/log/Hierarchy.d:68: Level is used as a type
>> mango/log/Hierarchy.d:68: variable mango.log.Hierarchy.LoggerInstance.level voids have no value
>> mango/log/Hierarchy.d:96: identifier 'Level' is not defined
>> mango/log/Hierarchy.d:96: Level is used as a type
>> mango/log/Hierarchy.d:96: cannot have parameter of type void
>
>(and there are a few repeats of those missing definitions)
>
>--anders

This appears to be a bug in the way GDC handles public imports from subordinates. What's interesting is that it apparently happens only in this particular case (the approach is prevalent throughout Mango).