D compiler version ALHPA 0.43 running on Win2K

the following very simple code ....
import stream;
int main( char[][] args )
{
 Stream output;
 output = stdout;
 return 0;
}

if compiled and run it gives the following error:
Error: Assertion Failure stream(1154)

(which is in the unittest section of stream.d)
I believe the problem is that under windows stream.writeLine appends \r\n
not just \n
I have tried dmd -release atest.d but still get the same error
I though unittests where only compiled in is you used -unittest

is there a known workaround, or a way to turn off unittests ?

Mike.

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in news:anah4a$278d$1 @digitaldaemon.com:

> 
> is there a known workaround, or a way to turn off unittests ?
> 
> Mike.

phobos.lib is still compiled with unittests.  You can rebuild phobos and just fix the assert.  This has been the workaround in the past.

In order to fix this problem, find and replace all 18s with 17s within the unitest portion of the stream.d file.  It does not work because the assertion is incorrect.

Andrew

"Patrick Down" <pat@codemoon.com> wrote in message
news:Xns9299B57E4C654patcodemooncom@63.105.9.61...
| "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in news:anah4a$278d$1
| @digitaldaemon.com:
|
| >
| > is there a known workaround, or a way to turn off unittests ?
| >
| > Mike.
|
| phobos.lib is still compiled with unittests.  You can rebuild
| phobos and just fix the assert.  This has been the
| workaround in the past.
|
|

Seems to me D (or at least the linker)  requires a "multilib" like interface
like gcc (which I know little about)

The last thing I want to have to do is rebuild the phobos lib everytime I
change the version of my source
for a release I want to be linked against the release phobos lib, and for
debug against the debug lib.
and especially if its every going to run on achitecture like the ARM7TDMI
where you have 2 instruction sets (Arm and Thumb) and objects can be in
either with or without "interworking".

it might be a better solution to have the "version" information need to be
in the object files
so the code
int myFuncA( int a ) { .... }
version (WHATEVER) {
    int myFuncB( int a ) { .... }
    alias myFuncB myFunc;
} else {
    int myFunc( int a ) { .... }
}

can be build with or without 'version' : WHATEVER and is then marked that it
HAS to be linked with or without that 'version'.
or build as multiversion, in which case the object file contains all
possible variants and the linker can sort out the actual code to link.
I guess you would have to specify the range of variants you wanted build
so you could build with X86 WIN32, then all variants of ANSI, UNICODE,
release, debug, unittest
but NO UNIX or other vairants (or build UNIX release, debug, unittest) etc
and so on.

without this the version statments and built in versions (-debug,-release,-unittest) create the same grief as you can create in C files with #defines in C files being set before including headers and other fun with shared sources.


"Patrick Down" <pat@codemoon.com> wrote in message news:Xns9299B57E4C654patcodemooncom@63.105.9.61...
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in news:anah4a$278d$1 @digitaldaemon.com:
>
> >
> > is there a known workaround, or a way to turn off unittests ?
> >
> > Mike.
>
> phobos.lib is still compiled with unittests.  You can rebuild phobos and just fix the assert.  This has been the workaround in the past.
>
>

Walter,

can you fix the makefile so rebuilding phobos can be done with a simple
"make"
your make file seems to think the dmd exe is the src dir not bin but assumes
the other tools are on the path (why not assume dmd is also on the path).

Mike.

"Andrew Edwards" <crxace13@comcast.net> wrote in message news:anapnr$2f8i$1@digitaldaemon.com...
> In order to fix this problem, find and replace all 18s with 17s within the unitest portion of the stream.d file.  It does not work because the assertion is incorrect.
>
> Andrew
>
> "Patrick Down" <pat@codemoon.com> wrote in message
> news:Xns9299B57E4C654patcodemooncom@63.105.9.61...
> | "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in news:anah4a$278d$1
> | @digitaldaemon.com:
> |
> | >
> | > is there a known workaround, or a way to turn off unittests ?
> | >
> | > Mike.
> |
> | phobos.lib is still compiled with unittests.  You can rebuild
> | phobos and just fix the assert.  This has been the
> | workaround in the past.
> |
> |
>

Even better, have the compiler only generate object code for modules on an as-needed basis.  Just because I change a file doesn't mean it will even recompile unless I build a program that needs it.  So long as the linker knows to call the D compiler on source that's newer, source files can be recompiled on demand.  The .obj refers to the source and if source is present and newer than the .obj, to recompile it and use the resulting .obj instead.  Requires more communication between the linker and compiler but that's what you expect for a modern language.  Integrate the linker with make.  So there's smooth integration between the source itself and its files and .obj files and .exe files.

I suppose the linker could cache different versions (just need to use hash on .obj filenames, or could build it direct into the .obj format) easily enough.  Which is what you suggest.

Multiversion could be useful if you want to distribute a D library of some kind.  Or a flag to link that says build all these variants.

It seems crucial to avoid rebuilds that the compiler command line "version" defines be stored in the .obj file so you can avoid recompiling just to make sure it's right.  Which is what C and C++ have a problem with.  A fundamental problem, due to their dependence on header files and textual includes.  The only reason that crap is still around is because you can't remove it from the language, as so much stuff is dependent on it.  It breaks backward compatibility to go to .obj-only includes (with potential for source recompilation, if source is present).  D has no such problem.

Being link-wise compatible with C is important I think.  So long as D provides for an interface by which other compilers can interface.  It's got to grow beyond just being externally compatible with C at some point.  Will the current design handle this gracefully?

Sean

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:anaq32$2foo$1@digitaldaemon.com...
> Seems to me D (or at least the linker)  requires a "multilib" like
interface
> like gcc (which I know little about)
>
> The last thing I want to have to do is rebuild the phobos lib everytime I
> change the version of my source
> for a release I want to be linked against the release phobos lib, and for
> debug against the debug lib.
> and especially if its every going to run on achitecture like the ARM7TDMI
> where you have 2 instruction sets (Arm and Thumb) and objects can be in
> either with or without "interworking".
>
> it might be a better solution to have the "version" information need to be
> in the object files
> so the code
> int myFuncA( int a ) { .... }
> version (WHATEVER) {
>     int myFuncB( int a ) { .... }
>     alias myFuncB myFunc;
> } else {
>     int myFunc( int a ) { .... }
> }
>
> can be build with or without 'version' : WHATEVER and is then marked that
it
> HAS to be linked with or without that 'version'.
> or build as multiversion, in which case the object file contains all
> possible variants and the linker can sort out the actual code to link.
> I guess you would have to specify the range of variants you wanted build
> so you could build with X86 WIN32, then all variants of ANSI, UNICODE,
> release, debug, unittest
> but NO UNIX or other vairants (or build UNIX release, debug, unittest) etc
> and so on.
>
> without this the version statments and built in versions (-debug,-release,-unittest) create the same grief as you can create in C files with #defines in C files being set before including headers and
other
> fun with shared sources.
>
>
> "Patrick Down" <pat@codemoon.com> wrote in message news:Xns9299B57E4C654patcodemooncom@63.105.9.61...
> > "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in news:anah4a$278d$1 @digitaldaemon.com:
> >
> > >
> > > is there a known workaround, or a way to turn off unittests ?
> > >
> > > Mike.
> >
> > phobos.lib is still compiled with unittests.  You can rebuild phobos and just fix the assert.  This has been the workaround in the past.
> >
> >
>
>

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:anbcfa$1cl$1@digitaldaemon.com...
> Even better, have the compiler only generate object code for modules on an as-needed basis.  Just because I change a file doesn't mean it will even recompile unless I build a program that needs it.  So long as the linker knows to call the D compiler on source that's newer, source files can be recompiled on demand.  The .obj refers to the source and if source is present and newer than the .obj, to recompile it and use the resulting
.obj
> instead.  Requires more communication between the linker and compiler but that's what you expect for a modern language.  Integrate the linker with make.  So there's smooth integration between the source itself and its
files
> and .obj files and .exe files.
>
> I suppose the linker could cache different versions (just need to use hash on .obj filenames, or could build it direct into the .obj format) easily enough.  Which is what you suggest.
>
> Multiversion could be useful if you want to distribute a D library of some kind.  Or a flag to link that says build all these variants.
>
> It seems crucial to avoid rebuilds that the compiler command line
"version"
> defines be stored in the .obj file so you can avoid recompiling just to
make
> sure it's right.  Which is what C and C++ have a problem with.  A fundamental problem, due to their dependence on header files and textual includes.  The only reason that crap is still around is because you can't remove it from the language, as so much stuff is dependent on it.  It
breaks
> backward compatibility to go to .obj-only includes (with potential for source recompilation, if source is present).  D has no such problem.
>
> Being link-wise compatible with C is important I think.  So long as D provides for an interface by which other compilers can interface.  It's
got
> to grow beyond just being externally compatible with C at some point.
Will
> the current design handle this gracefully?

Yes. Your implementation ideas are great, and future D implementations could well do this. The current one is constrained a bit by manpower (!) where I don't have the time to write a new make/linker/compiler management system. I think also that people will at least initially be more comfortable adopting D if it has the familiar make/compile/link method of building programs, despite their limitations.