www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Just one more thing...

reply Walter Bright <newshound1 digitalmars.com> writes:
Now includes Mac OSX version!

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.040.zip


http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.025.zip

Expect bugs. Thread local storage isn't working on OSX, neither are 
sockets and memory mapped files (for unknown reasons).

Thanks to Sean Kelly for a lot of help on the runtime library with this.
Feb 14 2009
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:


 Now includes Mac OSX version!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.040.zip
 


...

 Expect bugs. Thread local storage isn't working on OSX, neither are 
 sockets and memory mapped files (for unknown reasons).
 
 Thanks to Sean Kelly for a lot of help on the runtime library with this.


I gather this only works with Mac OS X 10.5 "Leopard" ?

$ dmd/osx/bin/dmd hello.d
Bus error

Could it be rebuilt with the MacOSX10.4u.sdk, perhaps ?

--anders
Feb 14 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Anders F Björklund wrote:

 Walter Bright wrote:
 

 Now includes Mac OSX version!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.040.zip


 ...

 Expect bugs. Thread local storage isn't working on OSX, neither are 
 sockets and memory mapped files (for unknown reasons).

 Thanks to Sean Kelly for a lot of help on the runtime library with this.


 
 I gather this only works with Mac OS X 10.5 "Leopard" ?
 
 $ dmd/osx/bin/dmd hello.d
 Bus error
 
 Could it be rebuilt with the MacOSX10.4u.sdk, perhaps ?


It works with whatever came with the Mac mini install disk <g>. I have 
no idea about other setups.
Feb 14 2009
parent =?UTF-8?B?QW5kZXJzIEYgQmrDtsKacmtsdW5k?= <afb algonet.se> writes:
Walter Bright wrote:


 I gather this only works with Mac OS X 10.5 "Leopard" ?

 $ dmd/osx/bin/dmd hello.d
 Bus error

 Could it be rebuilt with the MacOSX10.4u.sdk, perhaps ?


 
 It works with whatever came with the Mac mini install disk <g>. I have 
 no idea about other setups.


It works on Mac OS X 10.5 (confirmed with "hello.d"):
$ dmd/osx/bin/dmd dmd/samples/d/hello.d

However, "dmd" is not executable (chmod +x dmd) and
"dmd.conf" is missing (copy from "linux" directory) ?

--anders

PS. I made an installer for it with PackageMaker.app,
similar to the ones for Windows and Linux made earlier.
http://www.algonet.se/~afb/d/dmd-setup.html (DMD 1.00)
http://www.algonet.se/~afb/d/rpm-setup.html (DMD 1.00)
Feb 15 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Anders F Björklund wrote:

 I gather this only works with Mac OS X 10.5 "Leopard" ?
 
 $ dmd/osx/bin/dmd hello.d
 Bus error
 
 Could it be rebuilt with the MacOSX10.4u.sdk, perhaps ?


Is 10.5 really binary incompatible with 10.4 ? And not even a nice 
message when it isn't?
Feb 14 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:gn7cvo$tot$3 digitalmars.com...

 Anders F Björklund wrote:

 I gather this only works with Mac OS X 10.5 "Leopard" ?

 $ dmd/osx/bin/dmd hello.d
 Bus error

 Could it be rebuilt with the MacOSX10.4u.sdk, perhaps ?


 Is 10.5 really binary incompatible with 10.4 ? And not even a nice message 
 when it isn't?


Every time Apple puts out a new OSX version, they pretty much stop caring 
about the previous one (at least when compared to the Win and Lin worlds). 
Unless things have changed far more than I'm aware of since I was using OSX, 
backwords-compatibility problems are just sort of the nature of the Mac 
world.
Feb 14 2009
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-02-14 16:27:22 -0500, Walter Bright <newshound1 digitalmars.com> said:


 Anders F Björklund wrote:

 I gather this only works with Mac OS X 10.5 "Leopard" ?
 
 $ dmd/osx/bin/dmd hello.d
 Bus error
 
 Could it be rebuilt with the MacOSX10.4u.sdk, perhaps ?


 
 Is 10.5 really binary incompatible with 10.4 ?


It is compatible, unless you're using a new API or new linker features 
which weren't available in 10.4.

Development on Mac OS X works by choosing a target SDK and a deployment 
target version. Unless you want to use new APIs from 10.5, you should 
use the MacOSX10.4u.sdk SDK. Here's some documentation about how to do 
that:



If 

you use the 10.5 SDK, or no SDK at all, then the new APIs from 10.5 are 
available and if your software links to some of that it won't be 
possible to run it on 10.4. You can set the (minimum) deployment target 
to 10.4 if you want: this will cause functions from 10.5 to be 
weak-linked, and then you can check at runtime if they're available and 
not use them if they're not. But if you don't need anything specific to 
10.5, you should just use the 10.4 SDK and then you'll be pretty sure 
it runs correctly there.



 And not even a nice message when it isn't?


Unfortunately no, not automatically.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Feb 14 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michel Fortin wrote:

 Is 10.5 really binary incompatible with 10.4 ?


 
 It is compatible, unless you're using a new API or new linker features 
 which weren't available in 10.4.
 
 Development on Mac OS X works by choosing a target SDK and a deployment 
 target version. Unless you want to use new APIs from 10.5, you should 
 use the MacOSX10.4u.sdk SDK. Here's some documentation about how to do 
 that:
 

0-1114311-BABGCAAB> 
 
 
 If
 you use the 10.5 SDK, or no SDK at all, then the new APIs from 10.5 are 
 available and if your software links to some of that it won't be 
 possible to run it on 10.4. You can set the (minimum) deployment target 
 to 10.4 if you want: this will cause functions from 10.5 to be 
 weak-linked, and then you can check at runtime if they're available and 
 not use them if they're not. But if you don't need anything specific to 
 10.5, you should just use the 10.4 SDK and then you'll be pretty sure it 
 runs correctly there.


It's hard to see what that might be. dmd uses nothing but the generic 
linker commands, in fact, it uses gcc to do the link. It also doesn't 
use any but the basic api functions like read() and write().
Feb 14 2009
next sibling parent reply Anders Bergh <anders1 gmail.com> writes:
On Sun, Feb 15, 2009 at 05:06, Walter Bright <newshound1 digitalmars.com> wrote:

 It's hard to see what that might be. dmd uses nothing but the generic linker
 commands, in fact, it uses gcc to do the link. It also doesn't use any but
 the basic api functions like read() and write().


When you link you have to have an environment variable set,
MACOSX_DEPLOYMENT_TARGET=10.4. There's probably some other things that
need to be done, if you use Xcode to build it'll do it for you easily.

-- 
Anders Bergh
Feb 14 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Anders Bergh wrote:

 On Sun, Feb 15, 2009 at 05:06, Walter Bright <newshound1 digitalmars.com>
wrote:

 It's hard to see what that might be. dmd uses nothing but the generic linker
 commands, in fact, it uses gcc to do the link. It also doesn't use any but
 the basic api functions like read() and write().


 
 When you link you have to have an environment variable set,
 MACOSX_DEPLOYMENT_TARGET=10.4. There's probably some other things that
 need to be done, if you use Xcode to build it'll do it for you easily.
 


I don't use XCODE, just an ordinary makefile. What else needs to be done?
Feb 14 2009
parent reply Anders Bergh <anders1 gmail.com> writes:
On Sun, Feb 15, 2009 at 06:04, Walter Bright <newshound1 digitalmars.com> wrote:

 Anders Bergh wrote:

 On Sun, Feb 15, 2009 at 05:06, Walter Bright <newshound1 digitalmars.com>
 wrote:

 It's hard to see what that might be. dmd uses nothing but the generic
 linker
 commands, in fact, it uses gcc to do the link. It also doesn't use any
 but
 the basic api functions like read() and write().


 When you link you have to have an environment variable set,
 MACOSX_DEPLOYMENT_TARGET=10.4. There's probably some other things that
 need to be done, if you use Xcode to build it'll do it for you easily.


 I don't use XCODE, just an ordinary makefile. What else needs to be done?


A few Google searches gives me this:

http://paulbeachsblog.blogspot.com/2007/12/i-have-read-in-number-of-places-that-i.html
(suggests -mmacosx-version-min=10.4)

Also, -isysroot /Developer/SDKs/MacOSX10.4u.sdk
-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk

I don't use 10.4 so I have no way of testing it.

-- 
Anders Bergh
Feb 14 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Anders Bergh wrote:

 On Sun, Feb 15, 2009 at 06:04, Walter Bright <newshound1 digitalmars.com>
wrote:

 Anders Bergh wrote:

 On Sun, Feb 15, 2009 at 05:06, Walter Bright <newshound1 digitalmars.com>
 wrote:

 It's hard to see what that might be. dmd uses nothing but the generic
 linker
 commands, in fact, it uses gcc to do the link. It also doesn't use any
 but
 the basic api functions like read() and write().


 When you link you have to have an environment variable set,
 MACOSX_DEPLOYMENT_TARGET=10.4. There's probably some other things that
 need to be done, if you use Xcode to build it'll do it for you easily.


 I don't use XCODE, just an ordinary makefile. What else needs to be done?


 
 A few Google searches gives me this:
 
 http://paulbeachsblog.blogspot.com/2007/12/i-have-read-in-number-of-places-that-i.html
 (suggests -mmacosx-version-min=10.4)


 From the article: "Any attempt to compile Firebird on MacOS 10.5 and 
run it on MacOS 10.4 will create bus errors."

I suppose that explains the bus error. But I love this: "The Firebird 
build environment now uses both - just to make 100% certain". Blech. 
Anyone know for sure? I hate randomly trying things.
Feb 14 2009
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Walter Bright wrote:

 I suppose that explains the bus error. But I love this: "The Firebird 
 build environment now uses both - just to make 100% certain". Blech. 
 Anyone know for sure? I hate randomly trying things.


Set both of them... They're for the same thing, but as with all
deprecation processes it's not 100% sure everything is migrated.

MACOSX_DEPLOYMENT_TARGET=10.4
CFLAGS+=-isysroot /Developer/SDKs/MacOSX10.4u.sdk

Specifically, you want gcc and linker to use the same settings.
(especially to pick the correct OS version of the crt1 library)

But according to the documentation, this "should" work instead:
-mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk

--anders

PS.
I *think* it's fixed in Xcode 3.1.2, but I wouldn't bet on it...
If you're using Xcode 3.0 (from DVD), you should probably upgrade.
Feb 14 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Anders F Björklund wrote:

 Walter Bright wrote:

 I suppose that explains the bus error. But I love this: "The Firebird 
 build environment now uses both - just to make 100% certain". Blech. 
 Anyone know for sure? I hate randomly trying things.


 
 Set both of them... They're for the same thing, but as with all
 deprecation processes it's not 100% sure everything is migrated.
 
 MACOSX_DEPLOYMENT_TARGET=10.4
 CFLAGS+=-isysroot /Developer/SDKs/MacOSX10.4u.sdk
 
 Specifically, you want gcc and linker to use the same settings.
 (especially to pick the correct OS version of the crt1 library)
 
 But according to the documentation, this "should" work instead:
 -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
 
 --anders
 
 PS.
 I *think* it's fixed in Xcode 3.1.2, but I wouldn't bet on it...
 If you're using Xcode 3.0 (from DVD), you should probably upgrade.


Hmm. I tried compiling programs by just adding -mmacosx-version-min=10.4 
  and the compiled executable is a different size, and still runs.
Feb 15 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Anders F Björklund wrote:

 -mmacosx-version-min=10.4


I recompiled with that switch, and uploaded a new dmd.1.040.zip. Can you 
give it a try, please?
Feb 15 2009
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Walter Bright wrote:

 Anders F Björklund wrote:

 -mmacosx-version-min=10.4


 
 I recompiled with that switch, and uploaded a new dmd.1.040.zip. Can you 
 give it a try, please?


You did add *both* the switches, right ? One for MDT, one for SDK.
(MDT is for choosing functions, SDK chooses headers and libraries)

-mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk

It still fails on Mac OS X 10.4, maybe it still used native SDK ?
(if it matters, it gets a null dereference in _malloc_initialize)

--anders
Feb 15 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Anders F Björklund wrote:

 Walter Bright wrote:

 Anders F Björklund wrote:

 -mmacosx-version-min=10.4


 I recompiled with that switch, and uploaded a new dmd.1.040.zip. Can 
 you give it a try, please?


 
 You did add *both* the switches, right ? One for MDT, one for SDK.
 (MDT is for choosing functions, SDK chooses headers and libraries)
 
 -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
 
 It still fails on Mac OS X 10.4, maybe it still used native SDK ?
 (if it matters, it gets a null dereference in _malloc_initialize)


Ok, I tried it with both switches now. Please give it a try.
Feb 15 2009
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Walter Bright wrote:


 It still fails on Mac OS X 10.4, maybe it still used native SDK ?
 (if it matters, it gets a null dereference in _malloc_initialize)


 
 Ok, I tried it with both switches now. Please give it a try.


No luck, same problem. Might want to add "requires Mac OS X 10.5"
or something for now ? Upgraded wxD CVS to support DMD on Mac too.

--anders
Feb 15 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Anders F Björklund wrote:

 Walter Bright wrote:
 

 It still fails on Mac OS X 10.4, maybe it still used native SDK ?
 (if it matters, it gets a null dereference in _malloc_initialize)


 Ok, I tried it with both switches now. Please give it a try.


 
 No luck, same problem. Might want to add "requires Mac OS X 10.5"
 or something for now ? Upgraded wxD CVS to support DMD on Mac too.


Yeah, that looks like the best strategy for the moment. It seems odd 
that there is such confusion about something that should be documented 
and straightforward.
Feb 15 2009
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Walter Bright wrote:


 No luck, same problem. Might want to add "requires Mac OS X 10.5"
 or something for now ? Upgraded wxD CVS to support DMD on Mac too.


 
 Yeah, that looks like the best strategy for the moment. It seems odd 
 that there is such confusion about something that should be documented 
 and straightforward.


Must have been unlucky, or doing things "outside the dotted lines",
or both... Because usually it does just work with the MDT and SDK.

I think cross-compilation is rather transparent on Mac OS X, on the
other platforms it usually involves a full chroot or virtual machine ?

--anders
Feb 15 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Anders F Björklund wrote:

 Walter Bright wrote:
 

 No luck, same problem. Might want to add "requires Mac OS X 10.5"
 or something for now ? Upgraded wxD CVS to support DMD on Mac too.


 Yeah, that looks like the best strategy for the moment. It seems odd 
 that there is such confusion about something that should be documented 
 and straightforward.


 
 Must have been unlucky, or doing things "outside the dotted lines",
 or both... Because usually it does just work with the MDT and SDK.


I don't know how my new Mac mini, with an utterly default install, could 
possibly be outside the dotted lines. "man gcc" lists about a thousand 
switches, none of which are -mmacosx-version-min=10.4



 I think cross-compilation is rather transparent on Mac OS X, on the
 other platforms it usually involves a full chroot or virtual machine ?


On Windows I can still compile for DOS <g>.
Feb 15 2009
next sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Walter Bright wrote:


 Must have been unlucky, or doing things "outside the dotted lines",
 or both... Because usually it does just work with the MDT and SDK.


 
 I don't know how my new Mac mini, with an utterly default install, could 
 possibly be outside the dotted lines. "man gcc" lists about a thousand 
 switches, none of which are -mmacosx-version-min=10.4


Me neither, seems to work for me.


 I think cross-compilation is rather transparent on Mac OS X, on the
 other platforms it usually involves a full chroot or virtual machine ?


 
 On Windows I can still compile for DOS <g>.


Is that a bug or a feature ? :-)

--anders
Feb 15 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
So, does the latest dmd1 work?
Feb 16 2009
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:

 Anders F Björklund wrote:

 Walter Bright wrote:


 No luck, same problem. Might want to add "requires Mac OS X 10.5"
 or something for now ? Upgraded wxD CVS to support DMD on Mac too.


 Yeah, that looks like the best strategy for the moment. It seems odd 
 that there is such confusion about something that should be 
 documented and straightforward.


 Must have been unlucky, or doing things "outside the dotted lines",
 or both... Because usually it does just work with the MDT and SDK.


 
 I don't know how my new Mac mini, with an utterly default install, could 
 possibly be outside the dotted lines. "man gcc" lists about a thousand 
 switches, none of which are -mmacosx-version-min=10.4


I ran across some documentation that says this flag wasn't added to the 
man page because it was expected to change at some point.


Sean
Feb 16 2009
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-02-15 04:30:28 -0500, Anders F Björklund <afb algonet.se> said:


 Walter Bright wrote:

 Anders F Björklund wrote:

 -mmacosx-version-min=10.4


 
 I recompiled with that switch, and uploaded a new dmd.1.040.zip. Can 
 you give it a try, please?


 
 You did add *both* the switches, right ? One for MDT, one for SDK.
 (MDT is for choosing functions, SDK chooses headers and libraries)
 
 -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
 
 It still fails on Mac OS X 10.4, maybe it still used native SDK ?


If you specify a SDK for the compiler, you should also tell the linker 
to use the SDK.

	-syslibroot /Developer/SDKs/MacOSX10.4u.sdk

Or if you're passing the linker's argument through GCC instead of 
calling the linker directly:

	-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk

That's all explained in the document I linked to yesterday.



 (if it matters, it gets a null dereference in _malloc_initialize)


I made a diff of malloc.c (which contains _malloc_initialize) between 
10.4 and 10.5, and it looks like the rewrote half of that file, so 
there may be some differences.

But even then, if Walter is using the 10.5 SDK and isn't using anything 
specific to 10.5, I don't see where the problem could be comming from; 
especially after setting -mmacosx-version-min=10.4. When using the 10.5 
SDK, -mmacosx-version-min=10.4 will only make 10.5-only APIs 
weak-linked. When using the 10.4 SDK, it shoudn't do anything special, 
as 10.5's APIs are just not available.

I'd suggest to Walter to try adding the SDK flags to the linker. If 
that doesn't work, I'd suggest someone with 10.4 on an Intel Mac look 
for the crash report that should be in 
~/Library/Logs/CrashReporter/dmd_<date>.crash and send it to Walter, or 
post it somewhere for everyone to analyse.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Feb 15 2009
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Michel Fortin wrote:


 It still fails on Mac OS X 10.4, maybe it still used native SDK ?


 
 If you specify a SDK for the compiler, you should also tell the linker 
 to use the SDK.
 
     -syslibroot /Developer/SDKs/MacOSX10.4u.sdk
 
 Or if you're passing the linker's argument through GCC instead of 
 calling the linker directly:
 
     -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk
 
 That's all explained in the document I linked to yesterday.


I thought GCC 4.0.1 and later did that for you automatically ?
i.e. passed -syslibroot to the linker when using -isysroot

--anders
Feb 15 2009
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-02-15 08:42:53 -0500, Anders F Björklund <afb algonet.se> said:


 I thought GCC 4.0.1 and later did that for you automatically ?
 i.e. passed -syslibroot to the linker when using -isysroot
 
 --anders


Hum, indeed, I think you're right. Seems like this Apple documentation 
is outdated: 


Sorry 

for the confusion.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Feb 15 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Ok, try downloading dmd1 again.
Feb 15 2009
prev sibling parent reply Greg Parker <gparker apple.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article

 Michel Fortin wrote:

 Is 10.5 really binary incompatible with 10.4 ?


 It is compatible, unless you're using a new API or new linker features
 which weren't available in 10.4.

 Development on Mac OS X works by choosing a target SDK and a deployment
 target version. Unless you want to use new APIs from 10.5, you should
 use the MacOSX10.4u.sdk SDK.


 It's hard to see what that might be. dmd uses nothing but the generic
 linker commands, in fact, it uses gcc to do the link. It also doesn't
 use any but the basic api functions like read() and write().


You'll be affected pretty much no matter what you use. Changes between OS
versions have included:
* the libc and dynamic linker bootstrap process. Basically, crt.o changed, and
you can't compile with the
new crt.o and run on an old OS.
* UNIX compliance. Some functions changed for UNIX compliance, so now libc
includes _read and
_read$UNIX2003 for example. If you build with UNIX compliance on (which is the
default), then you'll
magically link to the _read$UNIX2003 symbol, which doesn't exist on older OS
versions.

You can get backwards compatibility, but you have to ask for it with the SDK
and min-version settings.


--
Greg Parker     gparker apple.com     Runtime Wrangler
Feb 22 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Greg Parker wrote:

 You'll be affected pretty much no matter what you use. Changes
 between OS versions have included: * the libc and dynamic linker
 bootstrap process. Basically, crt.o changed, and you can't compile
 with the new crt.o and run on an old OS. * UNIX compliance. Some
 functions changed for UNIX compliance, so now libc includes _read and
  _read$UNIX2003 for example. If you build with UNIX compliance on
 (which is the default), then you'll magically link to the
 _read$UNIX2003 symbol, which doesn't exist on older OS versions.
 
 You can get backwards compatibility, but you have to ask for it with
 the SDK and min-version settings.


Thanks, I think I've got the makefile set up for that now, though I 
don't have an old mac to test it on.
Feb 22 2009
parent reply Anders Bergh <anders1 gmail.com> writes:
On Sun, Feb 22, 2009 at 21:55, Walter Bright <newshound1 digitalmars.com> wrote:

 Greg Parker wrote:

 You'll be affected pretty much no matter what you use. Changes
 between OS versions have included: * the libc and dynamic linker
 bootstrap process. Basically, crt.o changed, and you can't compile
 with the new crt.o and run on an old OS. * UNIX compliance. Some
 functions changed for UNIX compliance, so now libc includes _read and
  _read$UNIX2003 for example. If you build with UNIX compliance on
 (which is the default), then you'll magically link to the
 _read$UNIX2003 symbol, which doesn't exist on older OS versions.

 You can get backwards compatibility, but you have to ask for it with
 the SDK and min-version settings.


 Thanks, I think I've got the makefile set up for that now, though I don't
 have an old mac to test it on.


If you upload some 10.4 binaries I can try it on my machine.

-- 
Anders Bergh
Feb 23 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Anders Bergh wrote:

 If you upload some 10.4 binaries I can try it on my machine.


Already done. Just redownload it.
Feb 23 2009
parent reply Anders Bergh <anders1 gmail.com> writes:
On Mon, Feb 23, 2009 at 12:19, Walter Bright <newshound1 digitalmars.com> wrote:

 Anders Bergh wrote:

 If you upload some 10.4 binaries I can try it on my machine.


 Already done. Just redownload it.


Just downloaded it and I can confirm that it does run on 10.4:

$ ./dmd
Digital Mars D Compiler v1.040
Copyright (c) 1999-2009 by Digital Mars written by Walter Bright
Documentation: http://www.digitalmars.com/d/1.0/index.html

-- 
Anders Bergh
Feb 23 2009
next sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Anders Bergh wrote:


 If you upload some 10.4 binaries I can try it on my machine.


 Already done. Just redownload it.


 
 Just downloaded it and I can confirm that it does run on 10.4:
 
 $ ./dmd
 Digital Mars D Compiler v1.040
 Copyright (c) 1999-2009 by Digital Mars written by Walter Bright
 Documentation: http://www.digitalmars.com/d/1.0/index.html


I also got further with this one, than with the previous two:

$ dmd/osx/bin/dmd dmd/samples/d/hello.d
/usr/bin/ld: Undefined symbols:
_pthread_mutexattr_destroy$UNIX2003
collect2: ld returned 1 exit status
--- errorlevel 1

Apparently it's still using some Leopard symbols for pthread.

Could also be that dmd is now alright, but libphobos.a isn't.
But as long as those two (MDT+SDK) are applied, it should be.

--anders
Feb 23 2009
parent reply Sean Kelly <sean invisibleduck.org> writes:
Anders F Björklund wrote:

 Anders Bergh wrote:
 

 If you upload some 10.4 binaries I can try it on my machine.


 Already done. Just redownload it.


 Just downloaded it and I can confirm that it does run on 10.4:

 $ ./dmd
 Digital Mars D Compiler v1.040
 Copyright (c) 1999-2009 by Digital Mars written by Walter Bright
 Documentation: http://www.digitalmars.com/d/1.0/index.html


 
 I also got further with this one, than with the previous two:
 
 $ dmd/osx/bin/dmd dmd/samples/d/hello.d
 /usr/bin/ld: Undefined symbols:
 _pthread_mutexattr_destroy$UNIX2003
 collect2: ld returned 1 exit status
 --- errorlevel 1
 
 Apparently it's still using some Leopard symbols for pthread.
 
 Could also be that dmd is now alright, but libphobos.a isn't.
 But as long as those two (MDT+SDK) are applied, it should be.


Darnit... using 10.4 pthreads might be difficult.  Posix support was a 
tad weak on OSX until 10.5.  We'd have to version the library code on OS 
version, which would be a tad weird since Apple doesn't really support 
old versions of its OS anyway.



Sean
Feb 23 2009
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Sean Kelly wrote:


 Apparently it's still using some Leopard symbols for pthread.

 Could also be that dmd is now alright, but libphobos.a isn't.
 But as long as those two (MDT+SDK) are applied, it should be.


 
 Darnit... using 10.4 pthreads might be difficult.  Posix support was a 
 tad weak on OSX until 10.5.  We'd have to version the library code on OS 
 version, which would be a tad weird since Apple doesn't really support 
 old versions of its OS anyway.


The pthread symbol is there, just not in the UNIX2003 variant.

So at this point it's just a linker issue, even if more behind.

--anders
Feb 23 2009
parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Anders F Björklund (afb algonet.se)'s article

 Sean Kelly wrote:

 Apparently it's still using some Leopard symbols for pthread.

 Could also be that dmd is now alright, but libphobos.a isn't.
 But as long as those two (MDT+SDK) are applied, it should be.


 Darnit... using 10.4 pthreads might be difficult.  Posix support was a
 tad weak on OSX until 10.5.  We'd have to version the library code on OS
 version, which would be a tad weird since Apple doesn't really support
 old versions of its OS anyway.


 The pthread symbol is there, just not in the UNIX2003 variant.
 So at this point it's just a linker issue, even if more behind.


Phew!  Better that than disabling features.


Sean
Feb 23 2009
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Sean Kelly wrote:


 Could also be that dmd is now alright, but libphobos.a isn't.
 But as long as those two (MDT+SDK) are applied, it should be.


 Darnit... using 10.4 pthreads might be difficult.  Posix support was a
 tad weak on OSX until 10.5.  We'd have to version the library code on OS
 version, which would be a tad weird since Apple doesn't really support
 old versions of its OS anyway.


 The pthread symbol is there, just not in the UNIX2003 variant.
 So at this point it's just a linker issue, even if more behind.


 
 Phew!  Better that than disabling features.


Rebuilding Phobos with MDT+SDK* makes it work on Mac OS X 10.4.

At least for DMD 1.04x and the basic things, which puts it on
par with the other compilers (GDC and LDC) and is OK with me...

Haven't done D2 for any of them yet, so that might be trickier.

--anders

* http://www.algonet.se/~afb/d/dmd-osx.diff (copied from dmd)
Mar 05 2009
parent John Stoneham <captnjameskirk yahoo.com> writes:
Anders F Björklund Wrote:

 Rebuilding Phobos with MDT+SDK* makes it work on Mac OS X 10.4.
 
 At least for DMD 1.04x and the basic things, which puts it on
 par with the other compilers (GDC and LDC) and is OK with me...
 
 Haven't done D2 for any of them yet, so that might be trickier.
 
 --anders
 
 * http://www.algonet.se/~afb/d/dmd-osx.diff (copied from dmd)


I just wanted to report that, since the DMD compiler itself does run on Tiger,
I decided to try to use it with the latest Tango SVN, and it works great.  So
far I've used DMD+Tango to build 2 fairly large projects on Tiger: wxD and gtkD
Mar 07 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Anders Bergh wrote:

 Just downloaded it and I can confirm that it does run on 10.4:
 
 $ ./dmd
 Digital Mars D Compiler v1.040
 Copyright (c) 1999-2009 by Digital Mars written by Walter Bright
 Documentation: http://www.digitalmars.com/d/1.0/index.html


Woo-hoo!
Feb 23 2009
parent 0ffh <frank youknow.what.todo.interNETz> writes:
Walter Bright wrote:

 Anders Bergh wrote:

 Just downloaded it and I can confirm that it does run on 10.4:
 [evidence]


 Woo-hoo!


Congrats! =)
Feb 23 2009
prev sibling parent reply John Stoneham <captnjameskirk yahoo.com> writes:
Walter Bright Wrote:


 Anders F Björklund wrote:

 I gather this only works with Mac OS X 10.5 "Leopard" ?
 
 $ dmd/osx/bin/dmd hello.d
 Bus error
 
 Could it be rebuilt with the MacOSX10.4u.sdk, perhaps ?


 
 Is 10.5 really binary incompatible with 10.4 ? And not even a nice 
 message when it isn't?


This is exactly the problem. I can confirm that it does not work on 10.4.11.
However, it is EXTREMELY easy to get dmd to work on Tiger AND Leopard, but
Walter will have to rebuild it linking to /Developer/SDKs/MacOSX10.4u.sdk (just
a simple command-line switch when building it). This has to be done when
building libphobos too, or we'll get an "Undefined Symbol" error when trying to
build our own programs against it. Doing this will make it run on Tiger and
Leopard, without having to have two builds for each system.

Walter, could you please do this for the 2.026 build, so we Tiger users can
have D too?
Feb 26 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
John Stoneham wrote:

 Walter, could you please do this for the 2.026 build, so we Tiger users can
have D too?


It's already done for the compiler (just redownload it), and Sean is 
working on the library. It isn't as simple as you describe, because 10.4 
has a weaker implementation of pthreads.
Feb 26 2009
parent reply John Stoneham <captnjameskirk yahoo.com> writes:
Walter Bright Wrote:


 John Stoneham wrote:

 Walter, could you please do this for the 2.026 build, so we Tiger users can
have D too?


 
 It's already done for the compiler (just redownload it), and Sean is 
 working on the library. It isn't as simple as you describe, because 10.4 
 has a weaker implementation of pthreads.


I didn't realize the pthread issue would rear it's ugly head just by linking
the 10,4u SDK. :) I did download it again as you suggested, and yes the
compiler itself now runs without throwing any errors, but as you point out the
library isn't compiled for 10.4 yet so I do get the "undefined symbol" error
during the linking of a simple hello.d (specifically, it's
_pthread_mutexattr_destroy$UNIX2003).

I'm really looking forward to using D on OS X. As Tank said in the Matirx, it's
a very exiting time!
Feb 26 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
John Stoneham wrote:

 I didn't realize the pthread issue would rear it's ugly head just by
 linking the 10,4u SDK. :) I did download it again as you suggested,
 and yes the compiler itself now runs without throwing any errors, but
 as you point out the library isn't compiled for 10.4 yet so I do get
 the "undefined symbol" error during the linking of a simple hello.d
 (specifically, it's _pthread_mutexattr_destroy$UNIX2003).
 
 I'm really looking forward to using D on OS X. As Tank said in the
 Matirx, it's a very exiting time!



Can you upgrade to 10.5 ?
Feb 26 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Thu, Feb 26, 2009 at 8:39 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 Can you upgrade to 10.5 ?


That costs money.
Feb 26 2009
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Jarrett Billingsley wrote:

 On Thu, Feb 26, 2009 at 8:39 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Can you upgrade to 10.5 ?


 
 That costs money.


Welcome to Apple.
Feb 26 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:

 On Thu, Feb 26, 2009 at 8:39 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Can you upgrade to 10.5 ?


 
 That costs money.


If you want free try linux <g>.
Feb 26 2009
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:


 Can you upgrade to 10.5 ?


It's only a few months left to "Snow Leopard",
then we can play the same game all over again.

--anders
Feb 27 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Anders F Björklund wrote:

 Walter Bright wrote:
 

 Can you upgrade to 10.5 ?


 
 It's only a few months left to "Snow Leopard",
 then we can play the same game all over again.


Yeah, but 10.5 has working posix threads. It's doubtful whether 10.4 is 
worth the effort.
Feb 27 2009
next sibling parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-02-27 09:38:02 +0100, Walter Bright <newshound1 digitalmars.com> said:


 Anders F Björklund wrote:

 Walter Bright wrote:
 

 Can you upgrade to 10.5 ?


 
 It's only a few months left to "Snow Leopard",
 then we can play the same game all over again.


 
 Yeah, but 10.5 has working posix threads. It's doubtful whether 10.4 is 
 worth the effort.


the worst offender (semaphores) are broken also on 10.5, I had to 
implement them on the top of mach semaphores in tango.
Feb 27 2009
parent Sean Kelly <sean invisibleduck.org> writes:
Fawzi Mohamed wrote:

 On 2009-02-27 09:38:02 +0100, Walter Bright <newshound1 digitalmars.com> 
 said:
 

 Anders F Björklund wrote:

 Walter Bright wrote:


 Can you upgrade to 10.5 ?


 It's only a few months left to "Snow Leopard",
 then we can play the same game all over again.


 Yeah, but 10.5 has working posix threads. It's doubtful whether 10.4 
 is worth the effort.


 
 the worst offender (semaphores) are broken also on 10.5, I had to 
 implement them on the top of mach semaphores in tango.


This isn't likely to change any time soon.  There is the old sys/sem.h 
or whatever (from the XOpen spec), but the interface just stinks.
Feb 27 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:go88pa$1guq$1 digitalmars.com...

 Anders F Björklund wrote:

 Walter Bright wrote:


 Can you upgrade to 10.5 ?


 It's only a few months left to "Snow Leopard",
 then we can play the same game all over again.


 Yeah, but 10.5 has working posix threads. It's doubtful whether 10.4 is 
 worth the effort.


Ordinarily, I detest the idea of pulling support for anything as recent as 
just a few years old. But Apple themselves has a habit of ignoring users of 
anything except the latest version, so I would think that mac users would be 
accustomed to the old routine of their OS becoming a deadend the moment a 
new version comes out. So, in this case, I would think that there may 
actually be justification in sticking with 10.5+, if you were to so choose.

But, to be fair, I did stop being a mac user a long time ago (10.2, tabby, 
or ocelot, or kitty-cat, or whatever the hell arbitrary feline name that 
was), so my opinion on this matter probably doesn't count for much. Feel 
free to take it or ignore it as you will.
Feb 27 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:

 Ordinarily, I detest the idea of pulling support for anything as recent as 
 just a few years old. But Apple themselves has a habit of ignoring users of 
 anything except the latest version, so I would think that mac users would be 
 accustomed to the old routine of their OS becoming a deadend the moment a 
 new version comes out. So, in this case, I would think that there may 
 actually be justification in sticking with 10.5+, if you were to so choose.


It's really a matter of the number of users who are not upgrading vs the 
effort involved in supporting them.

With Windows its very easy to support 15 years worth of Windows 
operating systems, so there's no reason not to. But there seems to be a 
different tradeoff at work for the Mac.
Feb 27 2009
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
Nick Sabalausky wrote:

 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:go88pa$1guq$1 digitalmars.com...

 Anders F Björklund wrote:

 Walter Bright wrote:


 Can you upgrade to 10.5 ?


 It's only a few months left to "Snow Leopard",
 then we can play the same game all over again.


 Yeah, but 10.5 has working posix threads. It's doubtful whether 10.4 is 
 worth the effort.


 
 Ordinarily, I detest the idea of pulling support for anything as recent as 
 just a few years old. But Apple themselves has a habit of ignoring users of 
 anything except the latest version, so I would think that mac users would be 
 accustomed to the old routine of their OS becoming a deadend the moment a 
 new version comes out. So, in this case, I would think that there may 
 actually be justification in sticking with 10.5+, if you were to so choose.


I would not completely agree with you on this. When you install the 
developer tools on osx 10.5 it installs SDKs for 10.5 and 10.4 as 
default, but you can also choose to install support for older versions. 
I'm not sure if it's only for 10.3 or also for 10.2.

Then what about Carbon, Classic (don't know if this is still available) 
and Rosetta, environments and libraries to support older applications.
Feb 27 2009
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-02-27 16:37:13 -0500, Jacob Carlborg <doob me.com> said:


 Nick Sabalausky wrote:

 Ordinarily, I detest the idea of pulling support for anything as recent 
 as just a few years old. But Apple themselves has a habit of ignoring 
 users of anything except the latest version, so I would think that mac 
 users would be accustomed to the old routine of their OS becoming a 
 deadend the moment a new version comes out. So, in this case, I would 
 think that there may actually be justification in sticking with 10.5+, 
 if you were to so choose.


 
 I would not completely agree with you on this. When you install the 
 developer tools on osx 10.5 it installs SDKs for 10.5 and 10.4 as 
 default, but you can also choose to install support for older versions. 
 I'm not sure if it's only for 10.3 or also for 10.2.


On Mac OS X 10.5, you can compile for 10.3 using Xcode 3, and 10.2 
using Xcode 2.5 (Xcode 2.5 for Leopard is a free download). Of course, 
10.2 and 10.3 being PowerPC-only, there's no point trying to compile 
DMD for them.



 Then what about Carbon, Classic (don't know if this is still available) 
 and Rosetta, environments and libraries to support older applications.


Classic is no longer supported on Leopard, and was never supported on 
Intel Macs.

Apple keeps old application running on newer versions of the operating 
system -- I can run apps I made for 10.0 on Leopard -- but their 
developer tools are limited to a few operating systems back.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Feb 27 2009
parent reply Brad Roberts <braddr puremagic.com> writes:
Michel Fortin wrote:

 On 2009-02-27 16:37:13 -0500, Jacob Carlborg <doob me.com> said:
 

 Nick Sabalausky wrote:

 Ordinarily, I detest the idea of pulling support for anything as
 recent as just a few years old. But Apple themselves has a habit of
 ignoring users of anything except the latest version, so I would
 think that mac users would be accustomed to the old routine of their
 OS becoming a deadend the moment a new version comes out. So, in this
 case, I would think that there may actually be justification in
 sticking with 10.5+, if you were to so choose.


 I would not completely agree with you on this. When you install the
 developer tools on osx 10.5 it installs SDKs for 10.5 and 10.4 as
 default, but you can also choose to install support for older
 versions. I'm not sure if it's only for 10.3 or also for 10.2.


 
 On Mac OS X 10.5, you can compile for 10.3 using Xcode 3, and 10.2 using
 Xcode 2.5 (Xcode 2.5 for Leopard is a free download). Of course, 10.2
 and 10.3 being PowerPC-only, there's no point trying to compile DMD for
 them.


You can do that if and only if you don't require newer apis.  If you've
been reading this thread, you know that the runtime uses the posix
thread apis and those are supported less and less well as you go back in
time.  The ability to support the old versions isn't some magic wand
that conjures up new features into those old releases.

Later,
Brad
Feb 27 2009
next sibling parent Jacob Carlborg <doob me.com> writes:
Brad Roberts wrote:

 Michel Fortin wrote:

 On 2009-02-27 16:37:13 -0500, Jacob Carlborg <doob me.com> said:


 Nick Sabalausky wrote:

 Ordinarily, I detest the idea of pulling support for anything as
 recent as just a few years old. But Apple themselves has a habit of
 ignoring users of anything except the latest version, so I would
 think that mac users would be accustomed to the old routine of their
 OS becoming a deadend the moment a new version comes out. So, in this
 case, I would think that there may actually be justification in
 sticking with 10.5+, if you were to so choose.


 I would not completely agree with you on this. When you install the
 developer tools on osx 10.5 it installs SDKs for 10.5 and 10.4 as
 default, but you can also choose to install support for older
 versions. I'm not sure if it's only for 10.3 or also for 10.2.


 On Mac OS X 10.5, you can compile for 10.3 using Xcode 3, and 10.2 using
 Xcode 2.5 (Xcode 2.5 for Leopard is a free download). Of course, 10.2
 and 10.3 being PowerPC-only, there's no point trying to compile DMD for
 them.


 
 You can do that if and only if you don't require newer apis.  If you've
 been reading this thread, you know that the runtime uses the posix
 thread apis and those are supported less and less well as you go back in
 time.  The ability to support the old versions isn't some magic wand
 that conjures up new features into those old releases.
 
 Later,
 Brad
 


I was just trying to say that in some cases they do support older 
systems. I can agree with you that they could support older systems 
better by updating apis and similar. But somewhere you have to draw a 
line, if every new api and feature should be available in an older 
system then what's the point with a new system.
Feb 28 2009
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Brad Roberts wrote:

 Michel Fortin wrote:

 On 2009-02-27 16:37:13 -0500, Jacob Carlborg <doob me.com> said:


 Nick Sabalausky wrote:

 Ordinarily, I detest the idea of pulling support for anything as
 recent as just a few years old. But Apple themselves has a habit of
 ignoring users of anything except the latest version, so I would
 think that mac users would be accustomed to the old routine of their
 OS becoming a deadend the moment a new version comes out. So, in this
 case, I would think that there may actually be justification in
 sticking with 10.5+, if you were to so choose.


 I would not completely agree with you on this. When you install the
 developer tools on osx 10.5 it installs SDKs for 10.5 and 10.4 as
 default, but you can also choose to install support for older
 versions. I'm not sure if it's only for 10.3 or also for 10.2.


 On Mac OS X 10.5, you can compile for 10.3 using Xcode 3, and 10.2 using
 Xcode 2.5 (Xcode 2.5 for Leopard is a free download). Of course, 10.2
 and 10.3 being PowerPC-only, there's no point trying to compile DMD for
 them.


 
 You can do that if and only if you don't require newer apis.  If you've
 been reading this thread, you know that the runtime uses the posix
 thread apis and those are supported less and less well as you go back in
 time.  The ability to support the old versions isn't some magic wand
 that conjures up new features into those old releases.


One somewhat weird issue that we may have to face at some point is that 
Posix functions whose behavior was changed have had the symbol for the 
new function changed to _blah$UNIX2003, with the old function left in 
place.  Since D can't declare symbols like this, we may end up having to 
add shims in C or post-process object files if it turns out that the old 
implementation of a function isn't sufficient.  I'd love to hear of a 
better solution here.
Feb 28 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Sean Kelly wrote:

 One somewhat weird issue that we may have to face at some point is that


 Posix functions whose behavior was changed have had the symbol for the
 new function changed to _blah$UNIX2003, with the old function left in
 place.  Since D can't declare symbols like this, we may end up having to
 add shims in C or post-process object files if it turns out that the old
 implementation of a function isn't sufficient.  I'd love to hear of a
 better solution here.


extern(C) void __identifier("blah$UNIX2003")(int);

A beneficial side-effect is that I can finally get rid of all those
mixins that are just doing this:

mixin(`void `~name_of_fn~`(int a)
{
    // ... rest of function ...
}`);

:D

  -- Daniel
Feb 28 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Feb 28, 2009 at 10:52 PM, Daniel Keep
<daniel.keep.lists gmail.com> wrote:

 extern(C) void __identifier("blah$UNIX2003")(int);

 A beneficial side-effect is that I can finally get rid of all those
 mixins that are just doing this:

 mixin(`void `~name_of_fn~`(int a)
 {
 =A0 =A0// ... rest of function ...
 }`);


Yes, please, Jesus I'd love that.
Feb 28 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:

 On Sat, Feb 28, 2009 at 10:52 PM, Daniel Keep
 <daniel.keep.lists gmail.com> wrote:

 extern(C) void __identifier("blah$UNIX2003")(int);

 A beneficial side-effect is that I can finally get rid of all those
 mixins that are just doing this:

 mixin(`void `~name_of_fn~`(int a)
 {
    // ... rest of function ...
 }`);


 
 Yes, please, Jesus I'd love that.


Put it as an enhancement request on bugzilla!
Feb 28 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter Bright wrote:

 Jarrett Billingsley wrote:

 On Sat, Feb 28, 2009 at 10:52 PM, Daniel Keep
 <daniel.keep.lists gmail.com> wrote:

 extern(C) void __identifier("blah$UNIX2003")(int);

 A beneficial side-effect is that I can finally get rid of all those
 mixins that are just doing this:

 mixin(`void `~name_of_fn~`(int a)
 {
    // ... rest of function ...
 }`);


 Yes, please, Jesus I'd love that.


 
 Put it as an enhancement request on bugzilla!


Your wish is my I'll probably do it if it benefits me too in some way.

http://d.puremagic.com/issues/show_bug.cgi?id=2698

:P

  -- Daniel
Feb 28 2009
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Daniel Keep wrote:

 
 Sean Kelly wrote:

 One somewhat weird issue that we may have to face at some point is that


 Posix functions whose behavior was changed have had the symbol for the
 new function changed to _blah$UNIX2003, with the old function left in
 place.  Since D can't declare symbols like this, we may end up having to
 add shims in C or post-process object files if it turns out that the old
 implementation of a function isn't sufficient.  I'd love to hear of a
 better solution here.


 
 extern(C) void __identifier("blah$UNIX2003")(int);


That would be awesome.


 A beneficial side-effect is that I can finally get rid of all those
 mixins that are just doing this:
 
 mixin(`void `~name_of_fn~`(int a)
 {
     // ... rest of function ...
 }`);


I had absolutely no idea that this could be used to generate symbol 
names that are illegal in D.
Mar 01 2009
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Sean Kelly wrote:

 Daniel Keep wrote:

 extern(C) void __identifier("blah$UNIX2003")(int);


 
 That would be awesome.
 

 A beneficial side-effect is that I can finally get rid of all those
 mixins that are just doing this:

 mixin(`void `~name_of_fn~`(int a)
 {
     // ... rest of function ...
 }`);


 
 I had absolutely no idea that this could be used to generate symbol 
 names that are illegal in D.


I don't think he's generating illegal symbol names. He's just sick of 
having to specify the whole function in a string when all he wants to 
change from instantiation to instantiation is the name...
Mar 01 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Frits van Bommel wrote:

 Sean Kelly wrote:

 Daniel Keep wrote:

 extern(C) void __identifier("blah$UNIX2003")(int);


 That would be awesome.


 A beneficial side-effect is that I can finally get rid of all those
 mixins that are just doing this:

 mixin(`void `~name_of_fn~`(int a)
 {
     // ... rest of function ...
 }`);


 I had absolutely no idea that this could be used to generate symbol
 names that are illegal in D.


 
 I don't think he's generating illegal symbol names. He's just sick of
 having to specify the whole function in a string when all he wants to
 change from instantiation to instantiation is the name...


/cookie fvbommel

  -- Daniel
Mar 01 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, Mar 2, 2009 at 11:55 AM, Daniel Keep
<daniel.keep.lists gmail.com> wrote:

 Frits van Bommel wrote:

 Sean Kelly wrote:

 Daniel Keep wrote:

 extern(C) void __identifier("blah$UNIX2003")(int);


 That would be awesome.


 A beneficial side-effect is that I can finally get rid of all those
 mixins that are just doing this:

 mixin(`void `~name_of_fn~`(int a)
 {
 =A0 =A0 // ... rest of function ...
 }`);








I'm sure you've thought of this, so why can you not do
   mixin(`void `~name_of_fn~`(int a) { implementation_of_function(a); }`);
or
   mixin(`alias implementation_of_function `~name_of_fn~`);
?

--bb
Mar 02 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Bill Baxter wrote:

 On Mon, Mar 2, 2009 at 11:55 AM, Daniel Keep
 <daniel.keep.lists gmail.com> wrote:

 Frits van Bommel wrote:

 Sean Kelly wrote:

 Daniel Keep wrote:

 extern(C) void __identifier("blah$UNIX2003")(int);


 That would be awesome.


 A beneficial side-effect is that I can finally get rid of all those
 mixins that are just doing this:

 mixin(`void `~name_of_fn~`(int a)
 {
     // ... rest of function ...
 }`);








 
 I'm sure you've thought of this, so why can you not do
    mixin(`void `~name_of_fn~`(int a) { implementation_of_function(a); }`);
 or
    mixin(`alias implementation_of_function `~name_of_fn~`);


Simple enough to break:

mixin(Property("foo", int));
mixin(Property("bar", float));

You can't use alias.  You have to have some way of generating unique
symbol names in a context you don't have any control over.  There are
also little issues with this like how the name of the function, when
debugging, won't be what you expect it to be.

No, you can't use templates because you can't mixin functions with
non-public protection with templates.

  -- Daniel
Mar 03 2009
parent reply Max Samukha <samukha voliacable.com.removethis> writes:
On Tue, 03 Mar 2009 20:05:28 +1100, Daniel Keep
<daniel.keep.lists gmail.com> wrote:


Bill Baxter wrote:

 On Mon, Mar 2, 2009 at 11:55 AM, Daniel Keep
 <daniel.keep.lists gmail.com> wrote:

 Frits van Bommel wrote:

 Sean Kelly wrote:

 Daniel Keep wrote:

 extern(C) void __identifier("blah$UNIX2003")(int);


 That would be awesome.


 A beneficial side-effect is that I can finally get rid of all those
 mixins that are just doing this:

 mixin(`void `~name_of_fn~`(int a)
 {
     // ... rest of function ...
 }`);








 
 I'm sure you've thought of this, so why can you not do
    mixin(`void `~name_of_fn~`(int a) { implementation_of_function(a); }`);
 or
    mixin(`alias implementation_of_function `~name_of_fn~`);


Simple enough to break:

mixin(Property("foo", int));
mixin(Property("bar", float));

You can't use alias.  You have to have some way of generating unique
symbol names in a context you don't have any control over. 


As of 1.039, it seems to be possible to generate unique symbols in a
reasonable way (not well tested):

template UniqueAlias(string member, string idName, int id = 0)
{
    static if (is(typeof(mixin("this." ~ idName ~ ToString!(id)))))
        mixin UniqueAlias!(member, idName, id + 1);
    else
        mixin("alias " ~ member ~ " " ~ idName ~ ToString!(id) ~ ";");
}

unittest
{
    class A
    {
        int x;
    }
    
    class B : A
    {
        int y;
        void foo() {}
            
        template Bar() {}

        mixin UniqueAlias!("x", "m");
        mixin UniqueAlias!("y", "m");
        mixin UniqueAlias!("x", "m");
        mixin UniqueAlias!("foo", "m");
        mixin UniqueAlias!("Bar", "m");
    }

    auto s = new B;
    s.m0 = 1;
    s.m1 = 2;
    assert(s.x == 1);
    assert(s.y == 2);
    assert(s.m2 == 1);
    s.m3();   
    alias B.m4!() bar;
}


There are also little issues with this like how the name of the function, when
debugging, won't be what you expect it to be.

No, you can't use templates because you can't mixin functions with
non-public protection with templates.

  -- Daniel
Mar 03 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Max Samukha wrote:

 On Tue, 03 Mar 2009 20:05:28 +1100, Daniel Keep
 <daniel.keep.lists gmail.com> wrote:
 

 Bill Baxter wrote:

 On Mon, Mar 2, 2009 at 11:55 AM, Daniel Keep
 <daniel.keep.lists gmail.com> wrote:

 Frits van Bommel wrote:

 Sean Kelly wrote:

 Daniel Keep wrote:

 extern(C) void __identifier("blah$UNIX2003")(int);


 That would be awesome.


 A beneficial side-effect is that I can finally get rid of all those
 mixins that are just doing this:

 mixin(`void `~name_of_fn~`(int a)
 {
     // ... rest of function ...
 }`);








 I'm sure you've thought of this, so why can you not do
    mixin(`void `~name_of_fn~`(int a) { implementation_of_function(a); }`);
 or
    mixin(`alias implementation_of_function `~name_of_fn~`);


 Simple enough to break:

 mixin(Property("foo", int));
 mixin(Property("bar", float));

 You can't use alias.  You have to have some way of generating unique
 symbol names in a context you don't have any control over. 


 
 As of 1.039, it seems to be possible to generate unique symbols in a
 reasonable way (not well tested):
 
 template UniqueAlias(string member, string idName, int id = 0)
 {
     static if (is(typeof(mixin("this." ~ idName ~ ToString!(id)))))
         mixin UniqueAlias!(member, idName, id + 1);
     else
         mixin("alias " ~ member ~ " " ~ idName ~ ToString!(id) ~ ";");
 }
 
 unittest
 {
     class A
     {
         int x;
     }
     
     class B : A
     {
         int y;
         void foo() {}
             
         template Bar() {}
 
         mixin UniqueAlias!("x", "m");
         mixin UniqueAlias!("y", "m");
         mixin UniqueAlias!("x", "m");
         mixin UniqueAlias!("foo", "m");
         mixin UniqueAlias!("Bar", "m");
     }
 
     auto s = new B;
     s.m0 = 1;
     s.m1 = 2;
     assert(s.x == 1);
     assert(s.y == 2);
     assert(s.m2 == 1);
     s.m3();   
     alias B.m4!() bar;
 }
 

 There are also little issues with this like how the name of the function, when
 debugging, won't be what you expect it to be.

 No, you can't use templates because you can't mixin functions with
 non-public protection with templates.

  -- Daniel




Yes, this is definitely an improvement...

char[] Foo(char[] name)
{
    const char[] uid = createUniqueAlias(name);

    return
        `private void `~uid~`() { blah; }`
      ~ `private alias `~uid~` `~name~`;`;
}

class Bar
{
    mixin(Foo("baz"));
}

Wait, no; that won't work.  createUniqueAlias won't have access to the
enclosing scope.  I'll have to do this:

char[] Foo(char[] name)
{
    return `
        mixin CreateUniqueAlias!("uid");

        mixin("private void "~uid~"() { blah; }");

        mixin("private alias "~uid~" `~name`;");
    `;
}

class Bar
{
    mixin(Foo("baz"));
}

Now I get TWO string-escaped mixins AND a meaninglessly named function
mixed into my instantiating code's scope!  Plus, since I need to refer
to the unique name, I have to store it somewhere... and now THAT can
collide with other symbols!

I'm not saying it's not a neat trick; I've used the exact same thing a
few times.  But it's not a solution to *this* problem.

  -- Daniel
Mar 03 2009
parent Max Samukha <samukha voliacable.com.removethis> writes:
On Tue, 03 Mar 2009 21:34:51 +1100, Daniel Keep
<daniel.keep.lists gmail.com> wrote:


Max Samukha wrote:

 On Tue, 03 Mar 2009 20:05:28 +1100, Daniel Keep
 <daniel.keep.lists gmail.com> wrote:
 

 Bill Baxter wrote:

 On Mon, Mar 2, 2009 at 11:55 AM, Daniel Keep
 <daniel.keep.lists gmail.com> wrote:

 Frits van Bommel wrote:

 Sean Kelly wrote:

 Daniel Keep wrote:

 extern(C) void __identifier("blah$UNIX2003")(int);


 That would be awesome.


 A beneficial side-effect is that I can finally get rid of all those
 mixins that are just doing this:

 mixin(`void `~name_of_fn~`(int a)
 {
     // ... rest of function ...
 }`);








 I'm sure you've thought of this, so why can you not do
    mixin(`void `~name_of_fn~`(int a) { implementation_of_function(a); }`);
 or
    mixin(`alias implementation_of_function `~name_of_fn~`);


 Simple enough to break:

 mixin(Property("foo", int));
 mixin(Property("bar", float));

 You can't use alias.  You have to have some way of generating unique
 symbol names in a context you don't have any control over. 


 
 As of 1.039, it seems to be possible to generate unique symbols in a
 reasonable way (not well tested):
 
 template UniqueAlias(string member, string idName, int id = 0)
 {
     static if (is(typeof(mixin("this." ~ idName ~ ToString!(id)))))
         mixin UniqueAlias!(member, idName, id + 1);
     else
         mixin("alias " ~ member ~ " " ~ idName ~ ToString!(id) ~ ";");
 }
 
 unittest
 {
     class A
     {
         int x;
     }
     
     class B : A
     {
         int y;
         void foo() {}
             
         template Bar() {}
 
         mixin UniqueAlias!("x", "m");
         mixin UniqueAlias!("y", "m");
         mixin UniqueAlias!("x", "m");
         mixin UniqueAlias!("foo", "m");
         mixin UniqueAlias!("Bar", "m");
     }
 
     auto s = new B;
     s.m0 = 1;
     s.m1 = 2;
     assert(s.x == 1);
     assert(s.y == 2);
     assert(s.m2 == 1);
     s.m3();   
     alias B.m4!() bar;
 }
 

 There are also little issues with this like how the name of the function, when
 debugging, won't be what you expect it to be.

 No, you can't use templates because you can't mixin functions with
 non-public protection with templates.

  -- Daniel




Yes, this is definitely an improvement...

char[] Foo(char[] name)
{
    const char[] uid = createUniqueAlias(name);

    return
        `private void `~uid~`() { blah; }`
      ~ `private alias `~uid~` `~name~`;`;
}

class Bar
{


    mixin(Foo("baz"));

}

Wait, no; that won't work. 


Yes, the mixin that checks for uniqueness needs to have access to the
scope where it is instantiated. So it has to be mixed in directly or
as part of another template mixin


 createUniqueAlias won't have access to the
enclosing scope.  I'll have to do this:

char[] Foo(char[] name)
{
    return `
        mixin CreateUniqueAlias!("uid");

        mixin("private void "~uid~"() { blah; }");

        mixin("private alias "~uid~" `~name`;");
    `;
}

class Bar
{
    mixin(Foo("baz"));
}

Now I get TWO string-escaped mixins AND a meaninglessly named function
mixed into my instantiating code's scope!  Plus, since I need to refer
to the unique name, I have to store it somewhere... and now THAT can
collide with other symbols!

I'm not saying it's not a neat trick; I've used the exact same thing a
few times.  But it's not a solution to *this* problem.

  -- Daniel


I didn't say it's a solution to this problem. I was saying it is
possible to generate unique symbol names. Your problem could be solved
like this:

template Property(string name, T)
{
    private T _prop;
    private T prop()
    {
       return _prop;
    }
    private T prop(T v)
    {
       _prop = v;
        return v;
    }

    mixin ("alias prop " ~ name ~ ";");
}

class A
{
    mixin Property!("foo", int);
}

class B : A
{
    mixin Property!("bar", float);
    mixin Property!("baz", int);
}

void main()
{
    auto b = new B;
    b.foo = 1;
    b.bar = 2.0;
    b.baz = 3;

    assert (b.foo == 1);
    assert (b.bar == 2.0);
    assert (b.baz == 3);
}

But such properties cannot implement interfaces. The spec says nothing
about whether aliases should be able to implement interface functions,
so I'm not sure if it's a compiler bug.

Ok, I'm all for the ident() thing. Or probably 'mixin' can be reused?
What ambiguities may arise?

void mixin("foo")() {}
Mar 03 2009
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:go9me9$kg9$1 digitalmars.com...

 Nick Sabalausky wrote:

 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:go88pa$1guq$1 digitalmars.com...

 Anders F Björklund wrote:

 Walter Bright wrote:


 Can you upgrade to 10.5 ?


 It's only a few months left to "Snow Leopard",
 then we can play the same game all over again.


 Yeah, but 10.5 has working posix threads. It's doubtful whether 10.4 is 
 worth the effort.


 Ordinarily, I detest the idea of pulling support for anything as recent 
 as just a few years old. But Apple themselves has a habit of ignoring 
 users of anything except the latest version, so I would think that mac 
 users would be accustomed to the old routine of their OS becoming a 
 deadend the moment a new version comes out. So, in this case, I would 
 think that there may actually be justification in sticking with 10.5+, if 
 you were to so choose.


 I would not completely agree with you on this. When you install the 
 developer tools on osx 10.5 it installs SDKs for 10.5 and 10.4 as default, 
 but you can also choose to install support for older versions. I'm not 
 sure if it's only for 10.3 or also for 10.2.

 Then what about Carbon, Classic (don't know if this is still available) 
 and Rosetta, environments and libraries to support older applications.


I was referring more to Apple's own software (which tends to be fairly 
important when using a mac). For instance I remember not being able to use 
XCode (instead of Project Builder) because I was on 10.2, and not being able 
to use certain parts of the "iLife" suite (or newer versions of them) 
because my OS was merely one point release behind (ie, only about 1.5 years 
old, at the time). But I dunno, maybe things have been changing since then.
Feb 27 2009
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Nick Sabalausky wrote:

 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:go88pa$1guq$1 digitalmars.com...

 Anders F Björklund wrote:

 Walter Bright wrote:


 Can you upgrade to 10.5 ?


 It's only a few months left to "Snow Leopard",
 then we can play the same game all over again.


 Yeah, but 10.5 has working posix threads. It's doubtful whether 10.4 is 
 worth the effort.


 
 Ordinarily, I detest the idea of pulling support for anything as recent as 
 just a few years old. But Apple themselves has a habit of ignoring users of 
 anything except the latest version, so I would think that mac users would be 
 accustomed to the old routine of their OS becoming a deadend the moment a 
 new version comes out. So, in this case, I would think that there may 
 actually be justification in sticking with 10.5+, if you were to so choose.


It turns out that Apple doesn't allow OSX prior to 10.5 to be run in a 
VM, so I can't even generate a test environment for 10.4 unless I track 
down a spare computer for it.  10.4 may have to remain an unsupported 
platform simply by necessity.
Feb 28 2009
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Anders F Björklund wrote:

 Walter Bright wrote:
 

 Can you upgrade to 10.5 ?


 
 It's only a few months left to "Snow Leopard",
 then we can play the same game all over again.


And at that point Apple will drop support for 10.4.
Feb 27 2009
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Stoneham wrote:


 I'm really looking forward to using D on OS X.
 As Tank said in the Matirx, it's a very exiting time!


There seems to be typos there, I think you mean "DMD" :-)

DMD is now the third D compiler to make it to Mac OS X,
after GDC and LDC before it (based on same front-end).
Anyway, it's just minor symbol issues left - "hello.d"
even limps along if you stub the missing symbol for it.

But the wxD samples built successfully* with all three...

--anders

* on Mac OS X 10.5, that was
Feb 26 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Anders F Björklund wrote:

 DMD is now the third D compiler to make it to Mac OS X,
 after GDC and LDC before it (based on same front-end).


D2 needed to get there, too.


 But the wxD samples built successfully* with all three...


Great!
Feb 27 2009
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:

 DMD is now the third D compiler to make it to Mac OS X,
 after GDC and LDC before it (based on same front-end).


 
 D2 needed to get there, too.


I get them confused all the time, with D meaning DMD or D2.

--anders
Feb 27 2009
prev sibling parent Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-02-27 09:43:12 +0100, Walter Bright <newshound1 digitalmars.com> said:


 Anders F Björklund wrote:

 DMD is now the third D compiler to make it to Mac OS X,
 after GDC and LDC before it (based on same front-end).


 
 D2 needed to get there, too.


Yes, I am very happy about this, now I might start playing with D 2.0 
(in the spare time).


 But the wxD samples built successfully* with all three...


 
 Great!
Feb 27 2009
prev sibling parent reply John Stoneham <captnjameskirk yahoo.com> writes:
Anders F Björklund Wrote:

 DMD is now the third D compiler to make it to Mac OS X,
 after GDC and LDC before it (based on same front-end).


Development on GDC appears to have stopped in 2007. LDC certainly has some life
in it and looks promising. I will definitely have to check it out.

However, even if LDC becomes stable on all platforms, it's still not the
official reference implementation. That would be DMD. I think it's very
important for the official DMD compiler to support the 3 major platforms, and
I'm very excited (caught the typo that time :) that OS X has been included.
Feb 27 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Feb 27, 2009 at 11:20 AM, John Stoneham
<captnjameskirk yahoo.com> wrote:

 Anders F Bj=F6rklund Wrote:

 DMD is now the third D compiler to make it to Mac OS X,
 after GDC and LDC before it (based on same front-end).


 Development on GDC appears to have stopped in 2007. LDC certainly has som=


e life in it and looks promising. I will definitely have to check it out.

 However, even if LDC becomes stable on all platforms, it's still not the =


official reference implementation. That would be DMD. I think it's very imp=
ortant for the official DMD compiler to support the 3 major platforms, and =
I'm very excited (caught the typo that time :) that OS X has been included.


LDC is based on DMD.  They share the same frontend.



 Feb 27 2009



prev sibling next sibling parent reply Extrawurst <spam extrawurst.org>  writes:


Walter Bright wrote:

 Now includes Mac OSX version!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.040.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.025.zip
 
 Expect bugs. Thread local storage isn't working on OSX, neither are 
 sockets and memory mapped files (for unknown reasons).
 
 Thanks to Sean Kelly for a lot of help on the runtime library with this.


Very nice, but what happened to version 2.024 ?



 Feb 14 2009



 next sibling parent  Walter Bright <newshound1 digitalmars.com>  writes:


Extrawurst wrote:

 Very nice, but what happened to version 2.024 ?


test version



 Feb 14 2009



prev sibling  parent  Chris R Miller <lordsauronthegreat gmail.com>  writes:


Extrawurst wrote:

 Walter Bright wrote:

 Now includes Mac OSX version!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.040.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.025.zip

 Expect bugs. Thread local storage isn't working on OSX, neither are
 sockets and memory mapped files (for unknown reasons).

 Thanks to Sean Kelly for a lot of help on the runtime library with this.


 Very nice, but what happened to version 2.024 ?


Market inflation ;-)



 Feb 14 2009



prev sibling next sibling parent  Jarrett Billingsley <jarrett.billingsley gmail.com>  writes:


On Sat, Feb 14, 2009 at 3:11 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 Now includes Mac OSX version!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.040.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.025.zip

 Expect bugs. Thread local storage isn't working on OSX, neither are sockets
 and memory mapped files (for unknown reasons).

 Thanks to Sean Kelly for a lot of help on the runtime library with this.


Where'd 2.024 go?  <_<



 Feb 14 2009



prev sibling next sibling parent  grauzone <none example.net>  writes:


This is what D actually needs: improving the tool-chain, fixing bugs, 
supporting additional architectures...

Sure, the language itself and the standard library still need a lot of work.

But D would already be quite usable, if only the compiler wouldn't choke 
up on circular module dependencies all the time, or if OPTLINK.EXE 
wouldn't keep crashing for no reasons, and all that. I understand that 
fixing bugs isn't all that simple or even gratifying, but having a 
stable and robust tool-chain is the most important things of all.

(Note: this is IMO one of the reasons, why C is still used, even for new 
projects.)

So I'm really happy to see that you take the time to address tool-chain 
issues. Good going!



 Feb 14 2009



prev sibling next sibling parent  dickl <dick221z yahoo.com>  writes:


Walter Bright wrote:

 Now includes Mac OSX version!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.040.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.025.zip
 
 Expect bugs. Thread local storage isn't working on OSX, neither are 
 sockets and memory mapped files (for unknown reasons).
 
 Thanks to Sean Kelly for a lot of help on the runtime library with this.




since 2.021.

The problem is the variable arguments as used in sformat (where there is 
an addition argument to the vararg list)

import std.stdio;
import std.string;

void main()
{
     char [32]msg;

     sformat(msg,"%s","Hello");
     writefln(msg);
}



 Feb 14 2009



prev sibling next sibling parent  Jacob Carlborg <doob me.com>  writes:


Walter Bright wrote:

 Now includes Mac OSX version!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.040.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.025.zip
 
 Expect bugs. Thread local storage isn't working on OSX, neither are 
 sockets and memory mapped files (for unknown reasons).
 
 Thanks to Sean Kelly for a lot of help on the runtime library with this.


That is terrific news



 Feb 15 2009



prev sibling next sibling parent reply Jacob Carlborg <doob me.com>  writes:


Walter Bright wrote:

 Now includes Mac OSX version!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.040.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.025.zip
 
 Expect bugs. Thread local storage isn't working on OSX, neither are 
 sockets and memory mapped files (for unknown reasons).
 
 Thanks to Sean Kelly for a lot of help on the runtime library with this.


For those how don't know what thread local storage is used for, is this 
both D1 and D2 and what features can I expect not working because of 
thread local storage.



 Feb 15 2009



  parent  Sean Kelly <sean invisibleduck.org>  writes:


Jacob Carlborg wrote:

 Walter Bright wrote:

 Now includes Mac OSX version!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.040.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.025.zip

 Expect bugs. Thread local storage isn't working on OSX, neither are 
 sockets and memory mapped files (for unknown reasons).

 Thanks to Sean Kelly for a lot of help on the runtime library with this.


 
 For those how don't know what thread local storage is used for, is this 
 both D1 and D2 and what features can I expect not working because of 
 thread local storage.


TLS is only in D2, and I don't think any library code uses it. 
Basically, you can't declare "__thread" variables on OSX.  You *can* use 
the TLS in core.thread though (the ThreadLocal class, or 
Thread.get/setLocal).


Sean



 Feb 15 2009



prev sibling next sibling parent reply "Lionello Lunesu" <lionello lunesu.remove.com>  writes:


"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:gn78ho$hmp$1 digitalmars.com...

 Now includes Mac OSX version!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.040.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.025.zip

 Expect bugs. Thread local storage isn't working on OSX, neither are 
 sockets and memory mapped files (for unknown reasons).

 Thanks to Sean Kelly for a lot of help on the runtime library with this.


dmd.2.025.zip has a file called "lib" (no extension) in the dmd folder. 
Sounds like a copy something \dmd\lib ? Its size is similar to gcstub.obj, 
is that it?

L. 



 Feb 15 2009



  parent  Walter Bright <newshound1 digitalmars.com>  writes:


Lionello Lunesu wrote:

 dmd.2.025.zip has a file called "lib" (no extension) in the dmd folder. 
 Sounds like a copy something \dmd\lib ? Its size is similar to 
 gcstub.obj, is that it?


eh, just delete it!



 Feb 15 2009



prev sibling next sibling parent  Steve Schveighoffer <schveiguy yahoo.com>  writes:


On Sat, 14 Feb 2009 12:11:38 -0800, Walter Bright wrote:


 Now includes Mac OSX version!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.040.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.025.zip
 
 Expect bugs. Thread local storage isn't working on OSX, neither are
 sockets and memory mapped files (for unknown reasons).
 
 Thanks to Sean Kelly for a lot of help on the runtime library with this.


WRT the new layout of lib/bin.  I know that you specify how to fix the 
permissions of the executables on the linux download page, but is it 
possible to get the files as a tarball so they do not have to be set?  Or 
to set the permissions in the zipfile (not sure about that one).  It 
seems weird that a distribution for linux has to have its permissions set 
manually.  I know it's been this way forever, but it does get annoying to 
have to twiddle with an installation every time I install it.  It 
probably isn't too much to host 2 different archives of the same file, 
one in tgz format and one in zip.

BTW, the new layout is good for cygwin users, because previous to this on 
windows, I had to remove the linux executables.  Cygwin would try to 
execute those first before finding the .exe versions.

-Steve



 Feb 15 2009



prev sibling next sibling parent reply Dejan Lekic <dejan.lekic tiscali.co.uk>  writes:


Walter Bright wrote:

 Now includes Mac OSX version!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.040.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.025.zip
 
 Expect bugs. Thread local storage isn't working on OSX, neither are 
 sockets and memory mapped files (for unknown reasons).
 
 Thanks to Sean Kelly for a lot of help on the runtime library with this.


Well done!
When can we expect 64bit version of DMD?



 Feb 15 2009



 next sibling parent  BCS <none anon.com>  writes:


Hello Dejan,


 Well done!
 When can we expect 64bit version of DMD?


OSX is still 32bit x86 so don't get your hopes up.



 Feb 15 2009



prev sibling  parent  Walter Bright <newshound1 digitalmars.com>  writes:


Dejan Lekic wrote:

 When can we expect 64bit version of DMD?


Nobody's ever satisfied <g>.

It has to be done sooner or later. Probably sooner.



 Feb 15 2009



prev sibling next sibling parent reply "Danny Wilson" <bluezenix gmail.com>  writes:


I tried using DMD OSX with DSSS yesterday. For some reason it whines when  
using -version=Posix
   "Error: version identifier 'Posix' is reserved and cannot be set".

Is that a bug or a feature :-)?


Op Sat, 14 Feb 2009 21:11:38 +0100 schreef Walter Bright  
<newshound1 digitalmars.com>:


 Now includes Mac OSX version!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.040.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.025.zip

 Expect bugs. Thread local storage isn't working on OSX, neither are  
 sockets and memory mapped files (for unknown reasons).

 Thanks to Sean Kelly for a lot of help on the runtime library with this.





 Feb 16 2009



 next sibling parent  Walter Bright <newshound1 digitalmars.com>  writes:


Danny Wilson wrote:

 I tried using DMD OSX with DSSS yesterday. For some reason it whines 
 when using -version=Posix
   "Error: version identifier 'Posix' is reserved and cannot be set".
 
 Is that a bug or a feature :-)?


It's a feature. Posix is predefined for OSX and linux targets.



 Feb 16 2009



prev sibling  parent  =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Danny Wilson wrote:

 I tried using DMD OSX with DSSS yesterday. For some reason it whines 
 when using -version=Posix
   "Error: version identifier 'Posix' is reserved and cannot be set".
 
 Is that a bug or a feature :-)?


LDC does the same...

For GDC, the predefined version identifier is 'Unix':
http://www.digitalmars.com/d/archives/D/gnu/1208.html

--anders



 Feb 16 2009



prev sibling  parent  Moritz Warning <moritzwarning web.de>  writes:


On Sat, 14 Feb 2009 12:11:38 -0800, Walter Bright wrote:


 Now includes Mac OSX version!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.040.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.025.zip
 
 Expect bugs. Thread local storage isn't working on OSX, neither are
 sockets and memory mapped files (for unknown reasons).
 
 Thanks to Sean Kelly for a lot of help on the runtime library with this.


Great to see a osx dmd! Thanks!

But! The new folder structure (./<OS>/bin/) is very unfortunate.

Installer scripts need to be rewritten and tutorials changed
all over the net.

Can't we have three release files, for windows, linux and osx?
It's the way every other program I've seen in my life does it.
This way the directory structure would be preserved.
The download volume would be reduced (linux user don't have to download 
the windows stuff etc.).
The users don't get confused by looking for the OS specific download.
The linux package can be a tar.gz file with executable bit set already.

*PLEASE* :)



 Feb 17 2009