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 next 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: <http://developer.apple.com/documentation/developertools/conceptual/cross_development/Using/chapter_3_section_2.html#//apple_ref/doc/uid/20002000-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.
 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
next sibling 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: <http://developer.apple.com/documentation/developertools/conceptual/cross_development/Using/chapter_3_section_2.html#//apple_ref/doc/uid/200020 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 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 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().

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.


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: <http://developer.apple.com/documentation/developertools/conceptual/cross_development/Using/chapter_3_section_2.html#//apple_ref/doc/uid/20002000-1114311-BABGCAAB> 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 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
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.


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.


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.

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.

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.

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]


Congrats! =)
Feb 23 2009
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling parent 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
prev sibling next 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 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 next 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 next 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 ?

then we can play the same game all over again.

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

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.

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.

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.

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

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

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 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);

 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);

 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);

 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 ...
 }`);




mixin(`void `~name_of_fn~`(int a) { implementation_of_function(a); }`); or mixin(`alias implementation_of_function `~name_of_fn~`);

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);

 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 ...
 }`);




mixin(`void `~name_of_fn~`(int a) { implementation_of_function(a); }`); or mixin(`alias implementation_of_function `~name_of_fn~`);

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 {

}

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 ?

then we can play the same game all over again.

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

then we can play the same game all over again.

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 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
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 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
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 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
prev sibling parent 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
prev sibling next sibling parent 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
prev sibling 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=

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

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.

Would you please fix bug #2479. Haven't been able to use any release 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