www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Mango on Mac (Darwin)

reply Kris <Kris_member pathlink.com> writes:
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!
Jan 26 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jan 26 2005
parent reply Kris <Kris_member pathlink.com> writes:
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?
Jan 26 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jan 26 2005
parent reply Kris <Kris_member pathlink.com> writes:
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
Jan 26 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jan 26 2005
parent Kris <Kris_member pathlink.com> writes:
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).
Jan 27 2005
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
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
Jan 26 2005
parent John Reimer <brk_6502 yahoo.com> writes:
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.
Jan 26 2005