www.digitalmars.com         C & C++   DMDScript  

D - Assert in stream (1154)

reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
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.
Sep 30 2002
parent reply Patrick Down <pat codemoon.com> writes:
"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.
Sep 30 2002
next sibling parent reply "Andrew Edwards" <crxace13 comcast.net> writes:
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.
|
|
Sep 30 2002
parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
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.
 |
 |
Sep 30 2002
prev sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
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.
Sep 30 2002
parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
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.
Sep 30 2002
parent "Walter" <walter digitalmars.com> writes:
"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.
Oct 02 2002