|
Archives
D Programming
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.ide
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
D.gnu
D
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
electronics
|
digitalmars.D.announce - Just one more thing...
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.
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
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.
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)
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?
"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.
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/
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().
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?
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.
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.
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.
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?
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
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.
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
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.
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
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>.
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
So, does the latest dmd1 work?
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
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/
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
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/
Ok, try downloading dmd1 again.
== 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
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.
Anders Bergh wrote:
If you upload some 10.4 binaries I can try it on my machine.
Already done. Just redownload it.
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
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
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
== 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
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)
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
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!
Walter Bright wrote:
Anders Bergh wrote:
Just downloaded it and I can confirm that it does run on 10.4:
[evidence]
Congrats! =)
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
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
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
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
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?
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.
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!
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 ?
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.
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>.
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
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.
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.
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.
"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.
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.
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.
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/
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.
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.
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
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!
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
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.
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...
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
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
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
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
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")() {}
"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.
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.
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
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.
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.
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
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!
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
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!
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.
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
On Thu, Feb 26, 2009 at 8:39 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
Can you upgrade to 10.5 ?
That costs money.
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.
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 ?
Extrawurst wrote:
Very nice, but what happened to version 2.024 ?
test version
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 ;-)
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? <_<
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!
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);
}
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
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.
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
"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.
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!
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
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?
Hello Dejan,
Well done!
When can we expect 64bit version of DMD?
OSX is still 32bit x86 so don't get your hopes up.
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.
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.
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.
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
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* :)
|
|
C & C++
DMDScript
=?UTF-8?B?QW5kZXJzIEYgQmrDtsKacmtsdW5k?= <afb algonet.se> 