www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd 1.050 and 2.035 release

reply Walter Bright <newshound1 digitalmars.com> writes:
The main purpose of this is to correct a couple of regressions that were 
blocking QtD and Tango.

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


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

Many thanks to the numerous people who contributed to this update.
Oct 14 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 14 de octubre a las 20:46 me escribiste:

 The main purpose of this is to correct a couple of regressions that
 were blocking QtD and Tango.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.050.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.035.zip
 
 Many thanks to the numerous people who contributed to this update.


Thanks for the first releases with full svn history! 8-)

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Wake from your sleep,
the drying of your tears,
Today we escape, we escape.
Oct 14 2009
prev sibling next sibling parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Walter Bright wrote:

 The main purpose of this is to correct a couple of regressions that were 
 blocking QtD and Tango.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.050.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.035.zip
 
 Many thanks to the numerous people who contributed to this update.


Sweet, JSON output, looks like it wasn't very hard to write :)
Oct 14 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Jeremie Pelletier wrote:

 Sweet, JSON output, looks like it wasn't very hard to write :)


It was rather trivial. But it's a bit primitive right now. The problem 
is I'm not writing a consumer of this data, so I'm not sure what it 
should contain. Consider it as a trial balloon.

I'm interested in hearing from those who are making plugins to Vim, 
Emacs, source code browsers, etc., who can use this, and what more is 
needed.

I don't want to just throw in a grab-bag of cruft.
Oct 14 2009
prev sibling next sibling parent reply MIURA Masahiro <echochamber gmail.com> writes:
Walter Bright wrote:

 The main purpose of this is to correct a couple of regressions that were 
 blocking QtD and Tango.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.050.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.035.zip
 
 Many thanks to the numerous people who contributed to this update.


Thanks for the new release!  I have built QtD r304 (latest) with DMD
2.050, and a tutorial example worked successfully.

Bugzilla admin, could you add 1.050 and 2.035 to the versions dropdown list?
Oct 14 2009
parent MIURA Masahiro <echochamber gmail.com> writes:
MIURA Masahiro wrote:

 I have built QtD r304 (latest) with DMD
 2.050,


Of course that's 2.035.  I'm screwed by rapid releases :-)
(I do welcome rapid releases, though)
Oct 14 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

Using DMD 2.035 I have tried to compile:

void main() {}

Using:

dmd -X temp.d

And the compiler crashes.

Regarding the "-X" name, isn't something like "-json" better? Or better to
unify the switch for json output and normal ddoc output in some way.
Even better, DMD2 compilation switches may need a bit of global
clean-up/rationalization (and they must be chosen taking in account the needs
and constraints of the LDC compiler too, so both compilers can share all or
most the same switches, simplifying the change of compiler a bit).

Bye,
bearophile
Oct 14 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 Walter Bright:
 
 Using DMD 2.035 I have tried to compile:
 
 void main() {}
 
 Using:
 
 dmd -X temp.d
 
 And the compiler crashes.


Sorry, that happens if the source file doesn't have a module statement.
Oct 14 2009
parent reply Michael P. <baseball.mjp gmail.com> writes:
Walter Bright Wrote:


 bearophile wrote:

 Walter Bright:
 
 Using DMD 2.035 I have tried to compile:
 
 void main() {}
 
 Using:
 
 dmd -X temp.d
 
 And the compiler crashes.


 
 Sorry, that happens if the source file doesn't have a module statement.


Maybe there should be an error then?
Oct 15 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Michael P. wrote:

 Walter Bright Wrote:
 

 bearophile wrote:

 Walter Bright:

 Using DMD 2.035 I have tried to compile:

 void main() {}

 Using:

 dmd -X temp.d

 And the compiler crashes.


 Sorry, that happens if the source file doesn't have a module statement.


 
 Maybe there should be an error then?


I think he says it's a bug, he forgot a module declaration can be null. :)
Oct 15 2009
prev sibling next sibling parent reply digited <digited yandex.ru> writes:
Walter Bright Wrote:


 The main purpose of this is to correct a couple of regressions that were 
 blocking QtD and Tango.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.050.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.035.zip
 
 Many thanks to the numerous people who contributed to this update.


Thank you for this release, and thank you for small commits to SVN!

The only thing that is missing from a good release procedure is
_release_candidates_. Please, Walter, do not hurry with releases! With DMD in
SVN, it will be totally ok to do releases by one in 1-2 months, the main
problem is that the developers don't have any time to actually test the new
release. The bugs are found, but it's too late and they need to wait for new
release, with new _features_ and thus, with _sudded_ release, new bugs and
breaking changes (even in D1, yes).

You can totally eliminate this kind of problems with posting not a "Here's a
new complete release! Now you can test it, but you won't get any fixes until
next one", but a _release_candidate_, make an SVN branch for it and let
developers (of QtD, Tango and lots of other projects) to test the candidate and
report bugs to you. Be sure, after a week of testing, while you can work on
next release and new features in trunk, the release branch will really become
ready for a _stable_ release, when noone will have to complain about blocker
bugs.

Please, Walter, do not hurry with releases, make release candidates and wait
for bug reports, apply fixes to the release branch and then make a really good
release, no matter not so often!

Thank you.
Oct 15 2009
parent reply zsxxsz <zhengshuxin hexun.com> writes:
== Quote from digited (digited yandex.ru)'s article

 Walter Bright Wrote:

 The main purpose of this is to correct a couple of regressions that were
 blocking QtD and Tango.

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


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

 Many thanks to the numerous people who contributed to this update.


 Thank you for this release, and thank you for small commits to SVN!
 The only thing that is missing from a good release procedure is


_release_candidates_. Please, Walter, do not hurry with releases! With DMD in
SVN,
it will be totally ok to do releases by one in 1-2 months, the main problem is
that the developers don't have any time to actually test the new release. The
bugs
are found, but it's too late and they need to wait for new release, with new
_features_ and thus, with _sudded_ release, new bugs and breaking changes (even
in
D1, yes).

 You can totally eliminate this kind of problems with posting not a "Here's a
new


complete release! Now you can test it, but you won't get any fixes until next
one", but a _release_candidate_, make an SVN branch for it and let developers
(of
QtD, Tango and lots of other projects) to test the candidate and report bugs to
you. Be sure, after a week of testing, while you can work on next release and
new
features in trunk, the release branch will really become ready for a _stable_
release, when noone will have to complain about blocker bugs.

 Please, Walter, do not hurry with releases, make release candidates and wait
for


bug reports, apply fixes to the release branch and then make a really good
release, no matter not so often!

 Thank you.


I don't think so. If there are some important bugs fixed, the new release is
necessary without caring about the release date. With dmd.2.034, I don't event
compile druntime.
Oct 15 2009
next sibling parent reply digited <digited yandex.ru> writes:
zsxxsz Wrote:


 I don't think so. If there are some important bugs fixed, the new release is
 necessary without caring about the release date. With dmd.2.034, I don't event
 compile druntime.


So you don't mind that Tango is still uncompilable with 1.050 because of
hurrying, for third release in a row?
There must be an easy compiling of DMD from source, and you can get your own
version from SVN trunk with a fresh bugfix you need.

But a release must generally be stable and should not break the code of main D
projects (or give them time to change the projects' code and fix DMD bugs),
there's a point in nighly builds, but not weekly releases that keep breaking
the code.
Oct 15 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
digited wrote:

 So you don't mind that Tango is still uncompilable with 1.050 because of
hurrying,


I didn't know that. The bugzilla number which was posted as the reason 
it wouldn't compile was fixed.
Oct 15 2009
next sibling parent digited <digited yandex.ru> writes:
Walter Bright Wrote:


 digited wrote:

 So you don't mind that Tango is still uncompilable with 1.050 because of
hurrying,


 
 I didn't know that. The bugzilla number which was posted as the reason 
 it wouldn't compile was fixed.


I don't try to accuse you on anything, just ask to give the users some time to
test a release candidate - that will show existing blockers better than posting
& scanning bugzilla before sudden release, devs will fix their bugs and you'll
get a feedback for fixes, and there (i hope) won't be critical problems in
compiling existing projects after release.

If you are already sending rc's to Tango devs, you simply can make them public
and make an SVN branch with their code.
Oct 15 2009
prev sibling parent reply rmcguire <rjmcguire gmail.com> writes:
Walter Bright <newshound1 digitalmars.com> wrote:
 

 digited wrote:

 So you don't mind that Tango is still uncompilable with 1.050 because of 




hurrying,

 
 I didn't know that. The bugzilla number which was posted as the reason 
 it wouldn't compile was fixed.
 


Hi Walter,

could you not just put rc1, rc2, etc... at the end of the file names when you
upload to server.
This way we could tell if the release has been tested by the community, and you 
wouldn't have to change your release process much? Unless of course if it is all
automated.

-Rory
Oct 16 2009
parent Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-10-16 15:31:15 +0200, rmcguire <rjmcguire gmail.com> said:


 Walter Bright <newshound1 digitalmars.com> wrote:
 

 digited wrote:

 So you don't mind that Tango is still uncompilable with 1.050 because of




 hurrying,

 
 I didn't know that. The bugzilla number which was posted as the reason
 it wouldn't compile was fixed.
 


 
 Hi Walter,
 
 could you not just put rc1, rc2, etc... at the end of the file names when you
 upload to server.
 This way we could tell if the release has been tested by the community, and you
 wouldn't have to change your release process much? Unless of course if 
 it is all
 automated.
 
 -Rory


Well I am not sure that it is really worth making a full release 
branching, just a tag and telling people that should become a release, 
and giving binaries to test it would probably be enough normally at 
least for D 1.0 where there shouldn't be large changes.

I suppose that opening the development more brought in more peoples 
that don't write as defensively as W (or modifications of larger parts) 
and so more testing is probably good.
In this specific case we were also probably a little bit sloppy at 
reporting problems, so that the went unnoticed for a couple of releases.

I suppose that W wanted to fix regressions ASAP, which in general is 
good I think, just this time it played out a little badly.

Anyway if W is willing a more formal release procedure would be good, 
but not absolutely necessary
Oct 17 2009
prev sibling parent Unkown to Xnntp <rjmcguire gmail.com> writes:
zsxxsz <zhengshuxin hexun.com> wrote:
 

 == Quote from digited (digited yandex.ru)'s article

 Walter Bright Wrote:

 The main purpose of this is to correct a couple of regressions that were
 blocking QtD and Tango.

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


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

 Many thanks to the numerous people who contributed to this update.


 Thank you for this release, and thank you for small commits to SVN!
 The only thing that is missing from a good release procedure is


 _release_candidates_. Please, Walter, do not hurry with releases! With DMD in 


SVN,

 it will be totally ok to do releases by one in 1-2 months, the main problem is
 that the developers don't have any time to actually test the new release. The 


bugs

 are found, but it's too late and they need to wait for new release, with new
 _features_ and thus, with _sudded_ release, new bugs and breaking changes 


(even in

 D1, yes).

 You can totally eliminate this kind of problems with posting not a "Here's a 




new

 complete release! Now you can test it, but you won't get any fixes until next
 one", but a _release_candidate_, make an SVN branch for it and let developers 


(of

 QtD, Tango and lots of other projects) to test the candidate and report bugs 


to

 you. Be sure, after a week of testing, while you can work on next release and 


new

 features in trunk, the release branch will really become ready for a _stable_
 release, when noone will have to complain about blocker bugs.

 Please, Walter, do not hurry with releases, make release candidates and wait 




for

 bug reports, apply fixes to the release branch and then make a really good
 release, no matter not so often!

 Thank you.


 
 I don't think so. If there are some important bugs fixed, the new release is
 necessary without caring about the release date. With dmd.2.034, I don't event
 compile druntime.
 


This wouldn't have happened if there was release candidates.
Oct 16 2009
prev sibling next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
digited Wrote:


 Walter Bright Wrote:
 

 The main purpose of this is to correct a couple of regressions that were 
 blocking QtD and Tango.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.050.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.035.zip
 
 Many thanks to the numerous people who contributed to this update.


 
 Thank you for this release, and thank you for small commits to SVN!
 
 The only thing that is missing from a good release procedure is
_release_candidates_. Please, Walter, do not hurry with releases! With DMD in
SVN, it will be totally ok to do releases by one in 1-2 months, the main
problem is that the developers don't have any time to actually test the new
release. The bugs are found, but it's too late and they need to wait for new
release, with new _features_ and thus, with _sudded_ release, new bugs and
breaking changes (even in D1, yes).
 
 You can totally eliminate this kind of problems with posting not a "Here's a
new complete release! Now you can test it, but you won't get any fixes until
next one", but a _release_candidate_, make an SVN branch for it and let
developers (of QtD, Tango and lots of other projects) to test the candidate and
report bugs to you. Be sure, after a week of testing, while you can work on
next release and new features in trunk, the release branch will really become
ready for a _stable_ release, when noone will have to complain about blocker
bugs.
 
 Please, Walter, do not hurry with releases, make release candidates and wait
for bug reports, apply fixes to the release branch and then make a really good
release, no matter not so often!
 
 Thank you.


Yeah I totally agree here. This release was intended to fix Tango, but there
are 2 more regressions that are not fixed:

http://d.puremagic.com/issues/show_bug.cgi?id=3397
http://d.puremagic.com/issues/show_bug.cgi?id=3401
Oct 15 2009
parent Don <nospam nospam.com> writes:
Eldar Insafutdinov wrote:

 digited Wrote:
 

 Walter Bright Wrote:


 The main purpose of this is to correct a couple of regressions that were 
 blocking QtD and Tango.

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


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

 Many thanks to the numerous people who contributed to this update.


 Thank you for this release, and thank you for small commits to SVN!

 The only thing that is missing from a good release procedure is
_release_candidates_. Please, Walter, do not hurry with releases! With DMD in
SVN, it will be totally ok to do releases by one in 1-2 months, the main
problem is that the developers don't have any time to actually test the new
release. The bugs are found, but it's too late and they need to wait for new
release, with new _features_ and thus, with _sudded_ release, new bugs and
breaking changes (even in D1, yes).

 You can totally eliminate this kind of problems with posting not a "Here's a
new complete release! Now you can test it, but you won't get any fixes until
next one", but a _release_candidate_, make an SVN branch for it and let
developers (of QtD, Tango and lots of other projects) to test the candidate and
report bugs to you. Be sure, after a week of testing, while you can work on
next release and new features in trunk, the release branch will really become
ready for a _stable_ release, when noone will have to complain about blocker
bugs.

 Please, Walter, do not hurry with releases, make release candidates and wait
for bug reports, apply fixes to the release branch and then make a really good
release, no matter not so often!

 Thank you.


 
 Yeah I totally agree here. This release was intended to fix Tango, but there
are 2 more regressions that are not fixed:
 
 http://d.puremagic.com/issues/show_bug.cgi?id=3397
 http://d.puremagic.com/issues/show_bug.cgi?id=3401


PLEASE, when these things are reported, mark them as severity = 
"regression". Even reading the bug report there's no indication that 
they are regressions. Saying "it is a blocker for Tango" is NOT the same.
Oct 15 2009
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Walter Bright wrote:

 The main purpose of this is to correct a couple of regressions that were 
 blocking QtD and Tango.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.050.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.035.zip
 
 Many thanks to the numerous people who contributed to this update.


The json output looks cool. :)

But for this:

---
module main;
alias int myInt;
myInt x;
---

I get:

---
{
"name" : "main",
"kind" : "module",
"file" : "main.d",
"members" : [
{
"name" : "myInt",
"kind" : "alias",
"type" : "int",
"line" : 5}
,{
"name" : "x",
"kind" : "variable",
"type" : "int",
"line" : 7}
]
}
---

So you see, variable's type is "int", not "myInt". I knew this was going 
to happen because the way dmd is implemented and how it fogets about 
aliases of types (it just resolves them and forgets about the original 
alias name). I had some head-aches remembering those things in Descent. :-P

Think of binding libraries like OpenGL, DirectX, even the windows API 
where all functions receive and return aliases. If an IDE shows the 
resolved aliases it's no use to the user, that's what aliases are for.

Should I create an enhancement for this?
Oct 15 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Ary Borenszweig wrote:

 Should I create an enhancement for this?


Might as well.
Oct 15 2009
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Wed, 14 Oct 2009 20:46:25 -0700, Walter Bright wrote:


 The main purpose of this is to correct a couple of regressions that were
 blocking QtD and Tango.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.050.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.035.zip
 
 Many thanks to the numerous people who contributed to this update.


Hi Walter,

Thanks for the commits to svn for us to testing!
But the release came in a bit of a hurry.
I reported two more regressions, thought there weren't marked as those
because, well, I forgot to check all options.
Oct 15 2009
prev sibling next sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Walter Bright wrote:

 Bugzilla 1534: Can't mix in a case statement.


Woo hoo!
Oct 15 2009
prev sibling next sibling parent reply digited <digited yandex.ru> writes:
Walter Bright Wrote:


 The main purpose of this is to correct a couple of regressions that were 
 blocking QtD and Tango.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.050.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.035.zip
 
 Many thanks to the numerous people who contributed to this update.


Thanks again for small commits to svn!

Today i've built DMD1 on Mac 10.5 (Intel) just like this:

svn co http://svn.dsource.org/projects/dmd/branches/dmd-1.x/src dmd
cd dmd
make -f osx.mak

and it's a godsand - no more downloading 8 MB of unusable stuff (and obsolete
because some patches are already in trunk).

btw, i had to change #include "../mars/mars.h" to #include "../mars.h" in
backend/dwarf.c and backend/machobj.c to compile it.
Oct 23 2009
parent reply Michael P. <baseball.mjp gmail.com> writes:
digited Wrote:


 Walter Bright Wrote:
 

 The main purpose of this is to correct a couple of regressions that were 
 blocking QtD and Tango.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.050.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.035.zip
 
 Many thanks to the numerous people who contributed to this update.


 
 Thanks again for small commits to svn!
 
 Today i've built DMD1 on Mac 10.5 (Intel) just like this:
 
 svn co http://svn.dsource.org/projects/dmd/branches/dmd-1.x/src dmd
 cd dmd
 make -f osx.mak
 
 and it's a godsand - no more downloading 8 MB of unusable stuff (and obsolete
because some patches are already in trunk).


I'm surprised that isn't fixed yet.
http://d.puremagic.com/issues/show_bug.cgi?id=2908

 
 btw, i had to change #include "../mars/mars.h" to #include "../mars.h" in
backend/dwarf.c and backend/machobj.c to compile it.
Oct 23 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Michael P., el 23 de octubre a las 15:36 me escribiste:

 digited Wrote:
 

 Walter Bright Wrote:
 

 The main purpose of this is to correct a couple of regressions that were 
 blocking QtD and Tango.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.050.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.035.zip
 
 Many thanks to the numerous people who contributed to this update.


 
 Thanks again for small commits to svn!
 
 Today i've built DMD1 on Mac 10.5 (Intel) just like this:
 
 svn co http://svn.dsource.org/projects/dmd/branches/dmd-1.x/src dmd
 cd dmd
 make -f osx.mak
 
 and it's a godsand - no more downloading 8 MB of unusable stuff (and obsolete
because some patches are already in trunk).


 
 I'm surprised that isn't fixed yet.
 http://d.puremagic.com/issues/show_bug.cgi?id=2908


My guess is that Walter have some mars directory in his development
environment so everything works well for him.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Es mejor probar el sabor de sapo y darse cuenta que es feo,
antes que no hacerlo y creer que es una gran gomita de pera.
	-- Dr Ricardo Vaporesso, Malta 1951
Oct 23 2009
prev sibling parent reply Pablo Ripolles <in-call gmx.net> writes:
Walter Bright Wrote:


 The main purpose of this is to correct a couple of regressions that were 
 blocking QtD and Tango.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.050.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.035.zip
 
 Many thanks to the numerous people who contributed to this update.


Can we expect this to work on Mac OS X version 10.5 still?

Thanks!
Oct 26 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Pablo Ripolles wrote:

 Can we expect this to work on Mac OS X version 10.5 still?


Yes.
Oct 26 2009
parent reply Pablo Ripolles <in-call gmx.net> writes:
Walter Bright Wrote:


 Pablo Ripolles wrote:

 Can we expect this to work on Mac OS X version 10.5 still?


 
 Yes.


All right! however in MacOSX 1.5 I've observed the following which doesn't
happens in linux:

I have a module named file.d and I have a main program named main.d. The module
is being imported and it's functions used in the main program. I compile file.d
and main.d separately (no linking). For the linking I do this:

dmd file.o main.o -ofmain

No problem in link time, however in run time it prompts "Bus error". It doesn't
happen when I do:

dmd main.o file.o -ofmain

Is this expected for the OSX in general or only 10.5?
Oct 27 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Pablo Ripolles wrote:

 Is this expected for the OSX in general or only 10.5?



It's not expected and I've never seen it. Please post a reproducible 
example to bugzilla.
Oct 27 2009
parent Pablo Ripolles <in-call gmx.net> writes:
Walter Bright Wrote:


 Pablo Ripolles wrote:

 Is this expected for the OSX in general or only 10.5?


 
 
 It's not expected and I've never seen it. Please post a reproducible 
 example to bugzilla.


I'll do that.

(BTW, sorry for my orthographical mistakes, I was quite tired...)
Oct 27 2009