Discussion:
ANN: Seed7 Release 2011-11-11
(too old to reply)
Rugxulo
2011-11-12 05:08:31 UTC
Permalink
Hi,
I have released a new version of Seed7: seed7_05_20111111.tgz
Remember me? :-) Yeah, about a year ago I hacked Seed7 to (barely)
work with DJGPP, at least the interpreter.

Long story short: I'm no comp. sci. major, I don't really know what
I'm doing, just too bored and curious for my own good ... too busy
with other crud, procrastinate too much, did spent a bit of time
learning bits of other languages (but, for no apparent reason, not
Seed7 ... yet, sorry!!), had some computer woes, some personal crud,
etc. I still browsed here (comp.lang.misc) occasionally and usually
downloaded the latest Seed7 sources but never did anything (though I
did notice you added a DJGPP makefile a few months back).

The Salmon guy was bragging about how portable his language was. Well,
long story short, it didn't work for me. I honestly didn't even want
to bother him with my opinions as I didn't think he cared. (Silly me
for including DOS under the portable spectrum, heheh.) And then I
figured I might as well give yours a go again (even if I failed), esp.
since I'd had partial success before.

The big problem with ANSI C (from my very weak perspective) is that,
while clearly being a huge success and accomplishing a lot, people
just "think" everything is portable when it's not. Basically you can't
assume anything. And the big problems in my book are always build-
related moreso than anything else. I hate complicated *nix makefiles
(usually relying on dozens of POSIX tools) or anything that relies on
a specific file system. That was also an issue here. I don't honestly
expect anyone to cater to "obsolete" file systems or OSes (like DOS),
but ... it would still be nice to not so heavily rely on
Super_long_filenames_that_conflict_in_first_eight_chars.TXT. More
importantly is weird things like makefiles, e.g. ones that have lines
greater than 1024 chars (eek). That is *very* rare in my experience,
though I've noticed GNU Emacs, Salmon, and now Seed7 doing it. Believe
it or not, my favorite text editor (TDE) seems to munge lines longer
than that, which is a curious error when you don't know what or how or
why. Ugh. (So I temporarily used VILE, works great!)

Basically my XP machine is half-dead, so I can't use that (though I
could use aunts' one night if really needed). I ended up running under
native FreeDOS w/ DOSLFN loaded. Not ideal as some things don't work
as well, if at all, but here it basically worked (surprisingly) ...
after a few minor tweaks. Yeah, I really should've tried this earlier,
but you never asked / nagged / emailed, so I didn't.

It mostly (but not fully) seems to work. I can't remember why DJGPP
will sometimes say "No swap space!" That's kinda weird, normally it's
obvious, but here it wasn't. (Yeah, I know, strerror() is the likely
culprit, but I didn't look any closer than that.)

Anyways, I hope this isn't too too long a reply, but here's the diff
for the Makefile (mandatory!) and (partially successful) output of "/
prg/hi chk_all":


--- mk_djgpp.mak 2011-10-11 01:38:30.000000000 -0500
+++ mk_djgpp.new 2011-11-11 22:38:28.000000000 -0600
@@ -6,7 +6,7 @@

# CFLAGS = -O2 -fomit-frame-pointer -funroll-loops -Wall
# CFLAGS = -O2 -fomit-frame-pointer -Wall -Wstrict-prototypes -
Winline -Wconversion -Wshadow -Wpointer-arith
-CFLAGS = -O2 -g -Wall -Wstrict-prototypes -Winline -Wconversion -
Wshadow -Wpointer-arith
+CFLAGS = -O2 -s -Wall -Wstrict-prototypes -Winline -Wconversion -
Wshadow -Wpointer-arith
# CFLAGS = -O2 -g -pg -Wall -Wstrict-prototypes -Winline -Wconversion
-Wshadow -Wpointer-arith
# CFLAGS = -O2 -Wall -Wstrict-prototypes -Winline -Wconversion -
Wshadow -Wpointer-arith
# CFLAGS = -O2 -pg -Wall -Wstrict-prototypes -Winline -Wconversion -
Wshadow -Wpointer-arith
@@ -28,7 +28,7 @@
ALL_S7_LIBS = ..\bin\$(COMPILER_LIB) ..\bin\$(COMP_DATA_LIB) ..\bin\$
(DRAW_LIB) ..\bin\$(CONSOLE_LIB) ..\bin\$(SEED7_LIB)
# CC = g++
CC = gcc
-GET_CC_VERSION_INFO = $(CC) --version >
+GET_CC_VERSION_INFO = $(CC) --version

BIGINT_LIB_DEFINE = USE_BIG_RTL_LIBRARY
BIGINT_LIB = big_rtl
@@ -104,8 +104,8 @@
version.h:
echo #define ANSI_C > version.h
echo #define USE_DIRENT >> version.h
- echo #define PATH_DELIMITER 92 /* backslash (ASCII) */ >> version.h
- echo #define SEARCH_PATH_DELIMITER ';' >> version.h
+ echo #define PATH_DELIMITER 92 >> version.h
+ echo #define SEARCH_PATH_DELIMITER \';\' >> version.h
echo #define MAP_ABSOLUTE_PATH_TO_DRIVE_LETTERS >> version.h
echo #define CATCH_SIGNALS >> version.h
echo #define AWAIT_WITH_SELECT >> version.h
@@ -119,10 +119,11 @@
echo #define $(BIGINT_LIB_DEFINE) >> version.h
echo #define likely(x) __builtin_expect((x),1) >> version.h
echo #define unlikely(x) __builtin_expect((x),0) >> version.h
- $(GET_CC_VERSION_INFO) cc_vers.txt
- echo #include "direct.h" > chkccomp.h
+# $(GET_CC_VERSION_INFO) >cc_vers.txt
+ echo gcc.exe (GCC) 4.6.2 > cc_vers.txt
+ echo #include \"direct.h\" > chkccomp.h
echo #define mkdir(path,mode) mkdir(path) >> chkccomp.h
- echo #define LIST_DIRECTORY_CONTENTS "dir" >> chkccomp.h
+ echo #define LIST_DIRECTORY_CONTENTS \"dir\" >> chkccomp.h
echo #define long_long_EXISTS >> chkccomp.h
echo #define long_long_SUFFIX_LL >> chkccomp.h
$(CC) chkccomp.c -lm -o chkccomp
@@ -130,23 +131,23 @@
del chkccomp.h
del chkccomp.exe
del cc_vers.txt
- echo #define OBJECT_FILE_EXTENSION ".o" >> version.h
- echo #define LIBRARY_FILE_EXTENSION ".a" >> version.h
- echo #define EXECUTABLE_FILE_EXTENSION ".exe" >> version.h
- echo #define C_COMPILER "$(CC)" >> version.h
- echo #define GET_CC_VERSION_INFO "$(GET_CC_VERSION_INFO)" >>
version.h
- echo #define CC_OPT_DEBUG_INFO "-g" >> version.h
- echo #define CC_OPT_NO_WARNINGS "-w" >> version.h
- echo #define LINKER_OPT_OUTPUT_FILE "-o " >> version.h
- echo #define LINKER_FLAGS "$(LDFLAGS)" >> version.h
- echo #define SYSTEM_LIBS "$(SYSTEM_LIBS)" >> version.h
- echo #define SYSTEM_CONSOLE_LIBS "$(SYSTEM_CONSOLE_LIBS)" >>
version.h
- echo #define SYSTEM_DRAW_LIBS "$(SYSTEM_DRAW_LIBS)" >> version.h
- echo #define SEED7_LIB "$(SEED7_LIB)" >> version.h
- echo #define CONSOLE_LIB "$(CONSOLE_LIB)" >> version.h
- echo #define DRAW_LIB "$(DRAW_LIB)" >> version.h
- echo #define COMP_DATA_LIB "$(COMP_DATA_LIB)" >> version.h
- echo #define COMPILER_LIB "$(COMPILER_LIB)" >> version.h
+ echo #define OBJECT_FILE_EXTENSION \".o\" >> version.h
+ echo #define LIBRARY_FILE_EXTENSION \".a\" >> version.h
+ echo #define EXECUTABLE_FILE_EXTENSION \".exe\" >> version.h
+ echo #define C_COMPILER \"$(CC)\" >> version.h
+ echo #define GET_CC_VERSION_INFO \"echo gcc.exe (GCC) 4.6.2 \" >>
version.h
+ echo #define CC_OPT_DEBUG_INFO \"-g\" >> version.h
+ echo #define CC_OPT_NO_WARNINGS \"-w\" >> version.h
+ echo #define LINKER_OPT_OUTPUT_FILE \"-o \" >> version.h
+ echo #define LINKER_FLAGS \"$(LDFLAGS)\" >> version.h
+ echo #define SYSTEM_LIBS \"$(SYSTEM_LIBS)\" >> version.h
+ echo #define SYSTEM_CONSOLE_LIBS \"$(SYSTEM_CONSOLE_LIBS)\" >>
version.h
+ echo #define SYSTEM_DRAW_LIBS \"$(SYSTEM_DRAW_LIBS)\" >> version.h
+ echo #define SEED7_LIB \"$(SEED7_LIB)\" >> version.h
+ echo #define CONSOLE_LIB \"$(CONSOLE_LIB)\" >> version.h
+ echo #define DRAW_LIB \"$(DRAW_LIB)\" >> version.h
+ echo #define COMP_DATA_LIB \"$(COMP_DATA_LIB)\" >> version.h
+ echo #define COMPILER_LIB \"$(COMPILER_LIB)\" >> version.h
echo #define STACK_SIZE_DEFINITION unsigned _stklen = 4194304 >>
version.h
$(CC) -o setpaths setpaths.c
.\setpaths.exe >> version.h



HI INTERPRETER Version 4.5.8856 Copyright (c) 1990-2011 Thomas Mertes
compiling the compiler - okay
chkint - okay
chkflt
*** The interpreted chkflt does not work okay:

Comparison of float values works correct.
Compare of float values works correct.
Decimal conversion of float works correct.
Conversion from integer to float works correct.
Truncation of float works correct.
Addition works correct for selected values.
A ** B works correct for selected values.
A ** B with integer B works correct for selected values.
Infinity works correct for selected values.
***** NaN is not returned as error value for math functions
***** NaN does not work correct
Negative zero does work correct.


*** The compiled chkflt does not work okay:

Comparison of float values works correct.
Compare of float values works correct.
Decimal conversion of float works correct.
Conversion from integer to float works correct.
Truncation of float works correct.
Addition works correct for selected values.
A ** B works correct for selected values.
A ** B with integer B works correct for selected values.
Infinity works correct for selected values.
***** NaN is not returned as error value for math functions
***** NaN does not work correct
Negative zero does work correct.

chkstr - okay
chkprc - okay
chkbig
*** The interpreted compiler was not able to compile chkbig

*** The compiled compiler was not able to compile chkbig
chkbool - okay
chkset
*** The interpreted compiler was not able to compile chkset

*** The compiled compiler was not able to compile chkset
chkexc
*** The interpreted chkexc does not work okay:

Integer exceptions work correct.
BigInteger exceptions work correct.
Floating point exceptions work correct.
String exceptions work correct.
Array exceptions work correct.
***** gets from write only file succeeded
***** gets from write only file succeeded
***** getln from write only file succeeded
***** getwd from write only file succeeded
***** gets from UTF-8 write only file succeeded
***** gets from UTF-8 write only file succeeded
***** getln from UTF-8 write only file succeeded
***** getwd from UTF-8 write only file succeeded
***** length for pipe succeeded
***** bigLength for pipe succeeded
***** seek for pipe succeeded
***** seek for pipe succeeded
***** tell for pipe succeeded
***** bigTell for pipe succeeded
***** length for pipe succeeded
***** bigLength for pipe succeeded
***** seek for pipe succeeded
***** seek for pipe succeeded
***** tell for pipe succeeded
***** bigTell for pipe succeeded
***** File exceptions do not work correct

seek(STD_IN, 0) raises RANGE_ERROR
gets(STD_IN, -1) raises RANGE_ERROR
test_func(1 div 0) raises NUMERIC_ERROR
1 div 0 = 0 and TRUE raises NUMERIC_ERROR
1 div 0 = 0 and FALSE raises NUMERIC_ERROR
TRUE and 1 div 0 = 0 raises NUMERIC_ERROR
1 div 0 = 0 or TRUE raises NUMERIC_ERROR
1 div 0 = 0 or FALSE raises NUMERIC_ERROR
FALSE or 1 div 0 = 0 raises NUMERIC_ERROR
if 1 div 0 raises NUMERIC_ERROR
1 div 0 in if then raises NUMERIC_ERROR
1 div 0 in if else raises NUMERIC_ERROR
while 1 div 0 raises NUMERIC_ERROR
1 div 0 in while raises NUMERIC_ERROR
repeat until 1 div 0 raises NUMERIC_ERROR
1 div 0 in repeat raises NUMERIC_ERROR


*** The compiled chkexc does not work okay:

Integer exceptions work correct.
BigInteger exceptions work correct.
Floating point exceptions work correct.
String exceptions work correct.
Array exceptions work correct.
***** gets from write only file succeeded
***** gets from write only file succeeded
***** getln from write only file succeeded
***** getwd from write only file succeeded
***** gets from UTF-8 write only file succeeded
***** gets from UTF-8 write only file succeeded
***** getln from UTF-8 write only file succeeded
***** getwd from UTF-8 write only file succeeded
***** length for pipe succeeded
***** bigLength for pipe succeeded
***** seek for pipe succeeded
***** seek for pipe succeeded
***** tell for pipe succeeded
***** bigTell for pipe succeeded
***** length for pipe succeeded
***** bigLength for pipe succeeded
***** seek for pipe succeeded
***** seek for pipe succeeded
***** tell for pipe succeeded
***** bigTell for pipe succeeded
***** File exceptions do not work correct

seek(STD_IN, 0) raises RANGE_ERROR
gets(STD_IN, -1) raises RANGE_ERROR
test_func(1 div 0) raises NUMERIC_ERROR
1 div 0 = 0 and TRUE raises NUMERIC_ERROR
1 div 0 = 0 and FALSE raises NUMERIC_ERROR
TRUE and 1 div 0 = 0 raises NUMERIC_ERROR
1 div 0 = 0 or TRUE raises NUMERIC_ERROR
1 div 0 = 0 or FALSE raises NUMERIC_ERROR
FALSE or 1 div 0 = 0 raises NUMERIC_ERROR
if 1 div 0 raises NUMERIC_ERROR
1 div 0 in if then raises NUMERIC_ERROR
1 div 0 in if else raises NUMERIC_ERROR
while 1 div 0 raises NUMERIC_ERROR
1 div 0 in while raises NUMERIC_ERROR
repeat until 1 div 0 raises NUMERIC_ERROR
1 div 0 in repeat raises NUMERIC_ERROR


EDIT: I think?? "hi.exe" (interpreter) was successful with running
chkbig, chkset (but fails for the compiler??).


Directory of G:\DJGPP\MANIFEST

GCC462B MFT 3,265 10-29-11 10:34a gcc462b.mft
BNU2211B MFT 1,830 08-05-11 10:37p bnu2211b.mft
DJDEV204 MFT 3,484 11-30-03 7:41p djdev204.mft
BSH205~1 MFT 449 09-22-09 10:48p bsh205bbr3.mft
MAK381B MFT 196 11-24-07 7:43a mak381b.mft
SED421B MFT 175 11-22-09 7:20a sed421b.mft
FIL41B MFT 1,367 12-15-03 10:03p fil41b.mft
TXT20B MFT 932 12-15-03 10:05p txt20b.mft
SHL2011B MFT 1,405 12-15-03 10:05p shl2011b.mft
FND423~1 MFT 560 06-27-08 4:33p fnd4233br4.mft
PDCUR34A MFT 352 10-08-08 10:19p pdcur34a.mft

(Hope this helps, sorry if not or too long!)
Rugxulo
2011-11-13 19:40:48 UTC
Permalink
Hi again,
Post by Rugxulo
It mostly (but not fully) seems to work. I can't remember why DJGPP
will sometimes say "No swap space!" That's kinda weird, normally it's
obvious, but here it wasn't. (Yeah, I know, strerror() is the likely
culprit, but I didn't look any closer than that.)
No idea about this. I half expected CWS or DJ to answer, but it's not
important I guess, just weird. (Apparently the testsuite output didn't
capture it like I thought, oops.)
Post by Rugxulo
--- mk_djgpp.mak        2011-10-11 01:38:30.000000000 -0500
+++ mk_djgpp.new        2011-11-11 22:38:28.000000000 -0600
-GET_CC_VERSION_INFO = $(CC) --version >
+GET_CC_VERSION_INFO = $(CC) --version
-       $(GET_CC_VERSION_INFO) cc_vers.txt
+#      $(GET_CC_VERSION_INFO) >cc_vers.txt
+       echo gcc.exe (GCC) 4.6.2 > cc_vers.txt
-       echo #define GET_CC_VERSION_INFO "$(GET_CC_VERSION_INFO)" >>
version.h
+       echo #define GET_CC_VERSION_INFO \"echo gcc.exe (GCC) 4.6.2 \" >>
version.h
Okay, all that was a kludge due to "Ambiguous redirect" error from
Bash. Later I tried again without Bash, but Make still had errors
(using COMMAND.COM) without the extra \" escapes. DJECHO.EXE wasn't a
better idea since it chomped ' and " quotes anyways. So extra escapes
indeed probably have to be added.

But I did forget about REDIR.EXE (included in always-required
DJDEV*.ZIP), so a better solution would be this (tested successfully)
without needing any '>' at all (though I personally wonder how
important this really is or if anything really depends on it being
accurate):

GET_CC_VERSION_INFO = redir $(CC) --version -o
Charles Sandmann
2011-11-17 22:44:19 UTC
Permalink
Post by Rugxulo
It mostly (but not fully) seems to work. I can't remember why DJGPP
will sometimes say "No swap space!"
That message is from CWSDPMI. It shouldn't appear, but adding
more memory or disk space should make it go away.
Rugxulo
2011-11-18 06:10:54 UTC
Permalink
Hi,
Post by Rugxulo
It mostly (but not fully) seems to work. I can't remember why DJGPP
will sometimes say "No swap space!"
That message is from CWSDPMI.  It shouldn't appear, but adding
more memory or disk space should make it go away.
I don't know what Seed7 was trying to do exactly, but I'm 99% sure it
wasn't lack of RAM (as I had oodles). Now, disk space, maybe, because
I was (at the time) running all atop a 100 MB RAM disk, including the
(temporary) DJGPP install. But who knows, maybe he was intentionally
trying to malloc a lot of space. (Well, I haven't messed with it
again, and he never commented back, so I haven't worried too much
about it.)
Rugxulo
2011-11-21 14:15:59 UTC
Permalink
Hi again,
Post by Rugxulo
Post by Rugxulo
It mostly (but not fully) seems to work. I can't remember why DJGPP
will sometimes say "No swap space!"
That message is from CWSDPMI.  It shouldn't appear, but adding
more memory or disk space should make it go away.
I don't know what Seed7 was trying to do exactly, but I'm 99% sure it
wasn't lack of RAM (as I had oodles). Now, disk space, maybe, because
I was (at the time) running all atop a [EDIT:] 150 MB RAM disk, including the
(temporary) DJGPP install. But who knows, maybe he was intentionally
trying to malloc a lot of space. (Well, I haven't messed with it
again, and he never commented back, so I haven't worried too much
about it.)
Okay, I tried again. Still put a temporary install in moderate RAM
disk, but this time I compiled from atop a big hard drive, so it
should have had plenty of space. However, I still get the error. This
is with r7, of course. I even tried "cwsdpmi -p -s-" in case for some
odd reason that would help. It didn't. My only other attempt was to
load "hdpmi32 -r", and then it worked fine (go figure). I don't know
and didn't check what "chkbig" or "chkset" are doing, but those two
tests are still failing (only) with CWSDPMI.

P.S. Here's an ugly sed script to more easily modify the pre-included
(broken?) DJGPP makefile to work properly. (Still ain't heard anything
from tm, oh well.)

#n
s/\/\*.*\*\///
s/\"/\\"/g
s/\x27/\\&/g
/>$/{
s/>//
s/=/= redir -o cc_vers.txt/
}
w makefile.dj
# use "HDPMI32 -r" for "hi chk_all" else chkbig and chkset will fail

P.P.S. Happy (early) Thanksgiving! CWS, obviously (?) feel free to
ignore this in favor of more important things, though indeed I find it
curious.
Charles Sandmann
2011-11-22 01:19:42 UTC
Permalink
Post by Rugxulo
Okay, I tried again. Still put a temporary install in moderate RAM
disk, but this time I compiled from atop a big hard drive, so it
should have had plenty of space. However, I still get the error. This
is with r7, of course. I even tried "cwsdpmi -p -s-" in case for some
odd reason that would help. ... I don't know
and didn't check what "chkbig" or "chkset" are doing, but those two
tests are still failing (only) with CWSDPMI.
Would be interesting to know if this is new (r7) breakage or something
that was in r5.
Post by Rugxulo
P.P.S. Happy (early) Thanksgiving! CWS, obviously (?) feel free to
ignore this in favor of more important things, though indeed I find it
curious.
Would be worth seeing if I can reproduce; if so maybe I'll try to fix it.
Rugxulo
2011-11-23 21:42:48 UTC
Permalink
Hi,
Post by Charles Sandmann
Post by Rugxulo
Okay, I tried again. Still put a temporary install in moderate RAM
disk, but this time I compiled from atop a big hard drive, so it
should have had plenty of space. However, I still get the error. This
is with r7, of course. I even tried "cwsdpmi -p -s-" in case for some
odd reason that would help. ... I don't know
and didn't check what "chkbig" or "chkset" are doing, but those two
tests are still failing (only) with CWSDPMI.
Would be interesting to know if this is new (r7) breakage or something
that was in r5.
I don't know. I've tried a bunch of setup changes locally here today,
but I couldn't consistently get any better results. So I don't think
r5 is any better here. It could indeed be some rare bug or regression,
but I doubt it. r7 indeed seems pretty stable.
Post by Charles Sandmann
Post by Rugxulo
P.P.S. Happy (early) Thanksgiving! CWS, obviously (?) feel free to
ignore this in favor of more important things, though indeed I find it
curious.
Would be worth seeing if I can reproduce; if so maybe I'll try to fix it.
I'm not sure if my machine is too quirky or not. I mean, 6 GB of RAM,
only 4 GB recognized at most (e.g. r7) with others recognizing
different amounts (1.8 GB for r5, 2.6 GB for HDPMI32), oddly enough.
Also not sure exactly why it even says "No swap space!" at all or what
that means exactly. All the things I tried didn't help clarify. I
should probably check r7's sources, but that sounds very
intimidating ....

Feel free to try it, but I don't think you should stress too much over
it. It's heavily confusing (for me, at least).
tm
2011-11-28 22:34:09 UTC
Permalink
Post by Rugxulo
Hi,
Post by Rugxulo
It mostly (but not fully) seems to work. I can't remember why DJGPP
will sometimes say "No swap space!"
That message is from CWSDPMI.  It shouldn't appear, but adding
more memory or disk space should make it go away.
I don't know what Seed7 was trying to do exactly, but I'm 99% sure it
wasn't lack of RAM (as I had oodles). Now, disk space, maybe, because
I was (at the time) running all atop a 100 MB RAM disk, including the
(temporary) DJGPP install. But who knows, maybe he was intentionally
trying to malloc a lot of space.
A test which intentionally used malloc, to get huge
amounts of memory (to provoke a MEMORY_ERROR exception),
was removed from chkexc.sd7 in version 2011-10-03. It
caused swapping and other problems with 64-bit MacOS.


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
tm
2011-11-28 22:23:45 UTC
Permalink
Post by Rugxulo
Hi,
I have released a new version of Seed7: seed7_05_20111111.tgz
Remember me? :-) Yeah, about a year ago I hacked Seed7 to (barely)
work with DJGPP, at least the interpreter.
I can remember your work. Thanks again.
BTW: Sorry for my delayed answer, I was off-net.
Post by Rugxulo
... I still browsed here (comp.lang.misc) occasionally and usually
downloaded the latest Seed7 sources but never did anything (though I
did notice you added a DJGPP makefile a few months back).
... Basically my XP machine is half-dead, so I can't use that (though I
could use aunts' one night if really needed). I ended up running under
native FreeDOS w/ DOSLFN loaded. Not ideal as some things don't work
as well, if at all, but here it basically worked (surprisingly) ...
after a few minor tweaks. Yeah, I really should've tried this earlier,
but you never asked / nagged / emailed, so I didn't.
It mostly (but not fully) seems to work. I can't remember why DJGPP
will sometimes say "No swap space!" That's kinda weird, normally it's
obvious, but here it wasn't. (Yeah, I know, strerror() is the likely
culprit, but I didn't look any closer than that.)
Anyways, I hope this isn't too too long a reply, but here's the diff
for the Makefile (mandatory!) and (partially successful) output of "/
I installed DJGPP under Windows XP, to test it.
I use the original make.exe from DJGPP/bin to execute mk_djgpp.mak
(with C:\DJGPP\bin\make -f mk_djgpp.mak). When I use your patch I
get error messages. The replacement of " with \" does not work with
my DJGPP. Maybe this is because XP uses cmd.exe to execute makefile
commands. AFAIK DOS uses command.com for this purpose. When I do:

echo #asdf "jkl"

in a command window (under XP) it writes:

#asdf "jkl"

Likewise the command:

echo #asdf "jkl" > version.h

in a command window writes:

#asdf "jkl"

to the file "version.h".
Maybe there is an alternate way to write ' and " with echo under
DOS. Preferably this way works under DOS and Windows.

About your other changes to "mk_djgpp.mak":
- Is the option -g not supported by your DJGPP gcc?
My DJGPP gcc supports it.
- Why do you use the option -s (Remove all symbol table and
relocation information from the executable)?
- Does the comment /* backslash (ASCII) */ make problems?
I added this comment to show the meaning of the value 92.
- As I already mentioned \' and \" do cause problems under XP.

GET_CC_VERSION_INFO can be used to determine the version of the
actual C compiler. This is done the following way:
A file name should be concatenated to GET_CC_VERSION_INFO and the
whole string should be executed by the shell. E.g.:

cmd_sh(GET_CC_VERSION_INFO & "a_file");

This shell command should write a line with the version info of the
C compiler to the given file. This version information can be read
from the file afterwards. It is important that the actual C compiler
is used to write the version information. This way a program can
determime the version of the actual C compiler (Instead of the C
compiler used to compile Seed7). The version of the C compiler,
which compiled Seed7, is defined with the preprocessor macro
C_COMPILER_VERSION. So a program can recognice that the C compiler
changed after Seed7 was compiled. Currently this mechanism is not
used, but it will probably be used in the near future.
Post by Rugxulo
HI INTERPRETER Version 4.5.8856 Copyright (c) 1990-2011 Thomas Mertes
compiling the compiler - okay
chkint - okay
chkflt
Comparison of float values works correct.
Compare of float values works correct.
Decimal conversion of float works correct.
Conversion from integer to float works correct.
Truncation of float works correct.
Addition works correct for selected values.
A ** B works correct for selected values.
A ** B with integer B works correct for selected values.
Infinity works correct for selected values.
***** NaN is not returned as error value for math functions
Some floating point functions should (according to IEEE 754), return
NaN. Seed7 relies on the features of the C library. This error shows
up, when the C floating point library does not work according to
IEEE 754 rules.
Post by Rugxulo
***** NaN does not work correct
Negative zero does work correct.
chkstr - okay
chkprc - okay
chkbig
*** The interpreted compiler was not able to compile chkbig
*** The compiled compiler was not able to compile chkbig
Probably this was caused by the "No swap space!" error you
mentioned. To prove this you can call

hi comp chkbig

manually. The file tmp_chkbig.cerrs or tmp_chkbig.lerrs may
contain helpful information. Please tell me, when the Seed7
compiler (comp.sd7) itself crashes.
Post by Rugxulo
chkbool - okay
chkset
*** The interpreted compiler was not able to compile chkset
*** The compiled compiler was not able to compile chkset
See my comment regarding compilation of chkbig above.
Post by Rugxulo
chkexc
Integer exceptions work correct.
BigInteger exceptions work correct.
Floating point exceptions work correct.
String exceptions work correct.
Array exceptions work correct.
***** gets from write only file succeeded
***** gets from write only file succeeded
***** getln from write only file succeeded
***** getwd from write only file succeeded
***** gets from UTF-8 write only file succeeded
***** gets from UTF-8 write only file succeeded
***** getln from UTF-8 write only file succeeded
***** getwd from UTF-8 write only file succeeded
***** length for pipe succeeded
***** bigLength for pipe succeeded
***** seek for pipe succeeded
***** seek for pipe succeeded
***** tell for pipe succeeded
***** bigTell for pipe succeeded
***** length for pipe succeeded
***** bigLength for pipe succeeded
***** seek for pipe succeeded
***** seek for pipe succeeded
***** tell for pipe succeeded
***** bigTell for pipe succeeded
This errors are caused by weaknesses in the underlying C library,
respectively in DOS.
Post by Rugxulo
***** File exceptions do not work correct
I have to investigate this message.
Post by Rugxulo
EDIT: I think?? "hi.exe" (interpreter) was successful with running
chkbig, chkset (but fails for the compiler??).
Yes, see my comment regarding chkbig above.

I really want to improve "mk_djgpp.mak", such that it works for you.
But I think it should also work for DJGPP under Windows (that way I
can test it also). Please help me, to reach that goal.


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Rugxulo
2011-11-28 23:30:17 UTC
Permalink
Hi,
Post by tm
I have released a new version of Seed7: seed7_05_20111111.tgz
BTW: Sorry for my delayed answer, I was off-net.
That's fine, I guessed as much. Hope you have been enjoying the
holiday season.
Post by tm
I installed DJGPP under Windows XP, to test it.
I use the original make.exe from DJGPP/bin to execute mk_djgpp.mak
(with C:\DJGPP\bin\make -f mk_djgpp.mak). When I use your patch I
get error messages.
Sadly, my XP machine died, so I can't (easily) test XP, so for now I'm
only testing native FreeDOS. Traditionally, MS-DOS and clones have
wimpy shells that don't support quoting in a consistent matter. Worse
is lack of "2>" stderr redirection, which is why DJGPP comes with
REDIR.EXE (though it has some oddball errors in some cases here). CMD,
Bash, and 4DOS all support stderr redirection natively, but most
people don't consistently use those, so it's hard to standardize on a
solution, which is why I recommend sticking to REDIR, DJECHO, etc.
(which all come with stock DJGPP by default) if at all possible.

I haven't checked too closely, but are *.cerrs files disabled for
DJGPP (or don't work) due to the above?
Post by tm
- Is the option -g not supported by your DJGPP gcc?
  My DJGPP gcc supports it.
- Why do you use the option -s (Remove all symbol table and
  relocation information from the executable)?
Ignore that, it was just a whim, not important here. It doesn't matter
for runtime memory anyways (IIRC).
Post by tm
- Does the comment /* backslash (ASCII) */ make problems?
  I added this comment to show the meaning of the value 92.
It was being expanded into file names under Bash. I don't know why I
even used Bash, I guess I just expected it to behave better since your
development seems fairly POSIX / *nix heavy. I don't honestly think I
need Bash, though, and I've not used it in recent attempts here.
Post by tm
- As I already mentioned  \' and \" do cause problems under XP.
I don't know, it's easy to get confused, esp. because Make, Bash, and
COMMAND.COM are all fighting over who controls stdout.
Post by tm
GET_CC_VERSION_INFO can be used to determine the version of the
actual C compiler.
Don't know, it's confusing, I'd have to test some more. It was just
giving me "ambiguous redirect" error under Bash, but it may not be a
huge problem otherwise.

To capture (almost) all output messages, I just now did this (under
DOSEMU):

redir -eo hi chk_all | tee blah.txt
Post by tm
HI INTERPRETER Version 4.5.8856  Copyright (c) 1990-2011 Thomas Mertes
compiling the compiler - okay
chkint - okay
chkflt
Some floating point functions should (according to IEEE 754), return
NaN. Seed7 relies on the features of the C library. This error shows
up, when the C floating point library does not work according to
IEEE 754 rules.
Right, probably just a silly bug in DJGPP, probably not hugely
important here.
Post by tm
 ***** NaN does not work correct
Negative zero does work correct.
chkstr - okay
chkprc - okay
chkbig
 *** The interpreted compiler was not able to compile chkbig
 *** The compiled compiler was not able to compile chkbig
Probably this was caused by the "No swap space!" error you
mentioned. To prove this you can call
  hi comp chkbig
manually. The file tmp_chkbig.cerrs or tmp_chkbig.lerrs may
contain helpful information. Please tell me, when the Seed7
compiler (comp.sd7) itself crashes.
The compiler never crashed, or at least not in my book on how you'd
say "crash". It just uses a fair chunk of RAM, apparently, which is
causing (on my weird PC) some oddball errors from CWSDPMI r7 (DPMI
host). Old CWSDPMI r5 and HDPMI32 have different or no (!) errors,
respectively, in the same instance. Update: I also just now finally
tested again in DOSEMU, and there chkbig and chkset compile fine. N.B.
Under pure DOS, the interpreter seems to handle these tests fine, e.g.
"hi chkbig" or "hi chkset" with r7, but the "compiled compiler" (?) is
the one that confuses CWSDPMI r7 ("No swap space!", see its dalloc.c).
Charles seems vaguely interested, but I'd be surprised if he could
find time (and I have no idea). It may just be something dumb and/or
with silly workaround like limiting (!) total free RAM (as most other
DPMI hosts don't nearly recognize 4 GB like r7 claims to.)

P.S. I had to "dpmi -m 0x7f000" under DOSEMU else DJGPP would run out
of memory. (Sadly, 4.6.2 is a bloated pig and needs a lot, esp. with -
O2. But I'm not sure -O1 would help in this case, a few random tests a
week or so back may have actually performed worse or hung. Ugh, so
confusing.)
Post by tm
chkbool - okay
chkset
 *** The interpreted compiler was not able to compile chkset
 *** The compiled compiler was not able to compile chkset
See my comment regarding compilation of chkbig above.
It's something to do with available memory. Though indeed I have the
space, it's not being allocated properly. I honestly don't think GCC +
Seed7 is using that much overall, and esp. since it succeeded under
DOSEMU with same toolset with only 500 MB RAM free, it must be just a
random allocation issue. I'm only running XMGR (XMSv3) and CWDPMI r7,
nothing else, no EMM386 (though I am also running UIDE cache driver,
which I doubt conflicts here).
Post by tm
chkexc
 ***** gets from write only file succeeded
 ***** gets from write only file succeeded
 ***** getln from write only file succeeded
 ***** getwd from write only file succeeded
 ***** gets from UTF-8 write only file succeeded
 ***** gets from UTF-8 write only file succeeded
 ***** getln from UTF-8 write only file succeeded
 ***** getwd from UTF-8 write only file succeeded
DOS doesn't have write-only files. ;-)
Post by tm
 ***** length for pipe succeeded
 ***** bigLength for pipe succeeded
 ***** seek for pipe succeeded
 ***** seek for pipe succeeded
 ***** tell for pipe succeeded
 ***** bigTell for pipe succeeded
 ***** length for pipe succeeded
 ***** bigLength for pipe succeeded
 ***** seek for pipe succeeded
 ***** seek for pipe succeeded
 ***** tell for pipe succeeded
 ***** bigTell for pipe succeeded
This errors are caused by weaknesses in the underlying C library,
respectively in DOS.
Right. DJGPP does have popen(), but I can't remember how well it works
(or if buggy). It's definitely a kludgy slow workaround here (for
DOS), sadly, but hey, it almost works sometimes. ;-)
Post by tm
I really want to improve "mk_djgpp.mak", such that it works for you.
But I think it should also work for DJGPP under Windows (that way I
can test it also). Please help me, to reach that goal.
My aunts' live nearby and still have an XP computer, so I can
presumably test there. It's not hard, obviously, just confusing (silly
redirection and quoting quirks). It could be a Make issue as I think
DJGPP always tried to hide from / workaround COMMAND.COM whenever
possible.
Rugxulo
2011-11-29 07:56:46 UTC
Permalink
Hi,
Post by Rugxulo
Post by tm
I installed DJGPP under Windows XP, to test it.
I use the original make.exe from DJGPP/bin to execute mk_djgpp.mak
(with C:\DJGPP\bin\make -f mk_djgpp.mak). When I use your patch I
get error messages.
And yet your makefile doesn't work for me (aunts' WinXP cpu). It still
seems to need backslash escapes for both single and double quotes as
well as editing to avoid "Ambiguous redirect error" for
GET_CC_VERSION.

Also, it's kinda weird. It uses about 350-420 MB of RAM for "hi
chk_all" due to GCC 4.6.2 being used (by the compiled compiler?). Also
trying to trim that via using -O1 didn't work too well (GCC
regression???), seemed to freeze the compiler at one point. But with -
O2 the tests do pass (compiled compiler), so I guess it really is a
rare CWSDPMI r7 quirk (under native FreeDOS on my own machine).
Presumably due to page tables being in low RAM with nowhere to swap
(or at least r7 refuses to swap here despite ample FAT32 space).

Actually, I tried GCC 4.1.2 (in FreeDOS) but got other weird errors
(division by zero), for some reason. Fun fun fun (confusing).
Post by Rugxulo
Post by tm
- Does the comment /* backslash (ASCII) */ make problems?
  I added this comment to show the meaning of the value 92.
It was being expanded into file names under Bash.
And yet it still seems to do it when not using Bash. I don't know why.
Perhaps your Make is old 3.79.1? I'm using /beta/mak381b.zip here.
Also I think you must have Fil41b, Txt20b, Shl2011b (aka, CoreUtils)
installed else it has some other error in the "make depend" stage,
didn't check too closely.
Post by Rugxulo
Post by tm
- As I already mentioned  \' and \" do cause problems under XP.
I don't know, it's easy to get confused, esp. because Make, Bash, and
COMMAND.COM are all fighting over who controls stdout.
I honestly can't remember when / if COMMAND.COM is called for DOS
programs when on XP.
Post by Rugxulo
To capture (almost) all output messages, I just now did this (under
redir -eo hi chk_all | tee blah.txt
So slow as it has to wait for finished output, ugh. I really wish
there was an easy way to enable compilation messages. Just sitting
there "in the dark" isn't very enlightening. (Besides, it scrolls past
the screen too fast, and "No swap space!" isn't redirectable anyways.)
Post by Rugxulo
Post by tm
Probably this was caused by the "No swap space!" error you
mentioned. To prove this you can call
  hi comp chkbig
manually. The file tmp_chkbig.cerrs or tmp_chkbig.lerrs may
contain helpful information. Please tell me, when the Seed7
compiler (comp.sd7) itself crashes.
I'm not sure *.cerrs is being created. You may still have blindly
assumed "2>" works everywhere. But let me reiterate that "hi chkbig"
and "hi chkset" both work fine. Honestly, all this fuss may be (only)
over the compiled compiler, which I don't really "need", do I? An
interpreter is good enough. ;-)
Post by Rugxulo
Post by tm
I really want to improve "mk_djgpp.mak", such that it works for you.
But I think it should also work for DJGPP under Windows (that way I
can test it also). Please help me, to reach that goal.
Well, in theory, you could install FreeDOS 1.1 test #3 (from iBiblio)
in VirtualBox. However, I definitely am not expecting or even
requesting that. I know that's probably tedious.

P.S. Does your makefile depend on both "seed7/bin/hi" and "seed7/bin/
hi.exe" existing? They're the same exact file but wasting space with
duplication. Feel free to directly "-o hi.exe" (instead of "-o hi") to
avoid that.
tm
2011-11-29 23:28:13 UTC
Permalink
Post by Rugxulo
Hi,
Post by Rugxulo
Post by tm
I installed DJGPP under Windows XP, to test it.
I use the original make.exe from DJGPP/bin to execute mk_djgpp.mak
(with C:\DJGPP\bin\make -f mk_djgpp.mak). When I use your patch I
get error messages.
And yet your makefile doesn't work for me (aunts' WinXP cpu). It still
seems to need backslash escapes for both single and double quotes as
well as editing to avoid "Ambiguous redirect error" for
GET_CC_VERSION.
I have no idea how to the fix the "Ambiguous redirect error". The
purpose of the preprocessor macro C_COMPILER_VERSION is explained
in a previous message.

Escaping quotes is also done in other makefiles. In this makefiles
the argument to echo is a quoted string. Inspired by this I created
the following makefile:

------------- begin mk_djgpp.mak ---------------
# Makefile for gmake and gcc from MinGW. Commands executed by: cmd.exe
# To compile use a windows console and call:
# make -f mk_djgpp.mak depend
# make -f mk_djgpp.mak
# If your version of gmake does not support dos commands use MSYS with
mk_msys.mak or mk_nmake.mak.

# CFLAGS = -O2 -fomit-frame-pointer -funroll-loops -Wall
# CFLAGS = -O2 -fomit-frame-pointer -Wall -Wstrict-prototypes -Winline
-Wconversion -Wshadow -Wpointer-arith
CFLAGS = -O2 -g -Wall -Wstrict-prototypes -Winline -Wconversion -
Wshadow -Wpointer-arith
# CFLAGS = -O2 -g -pg -Wall -Wstrict-prototypes -Winline -Wconversion -
Wshadow -Wpointer-arith
# CFLAGS = -O2 -Wall -Wstrict-prototypes -Winline -Wconversion -
Wshadow -Wpointer-arith
# CFLAGS = -O2 -pg -Wall -Wstrict-prototypes -Winline -Wconversion -
Wshadow -Wpointer-arith
# CFLAGS = -O2 -funroll-loops -Wall -pg
# Since there is no linker option to determine the stack size
# it is determined with STACK_SIZE_DEFINITION (see below).
LDFLAGS =
# LDFLAGS = -pg
# LDFLAGS = -pg -lc_p
SYSTEM_LIBS = -lm
# SYSTEM_LIBS = -lm -lgmp
SYSTEM_CONSOLE_LIBS =
SYSTEM_DRAW_LIBS =
SEED7_LIB = seed7_05.a
CONSOLE_LIB = s7_con.a
DRAW_LIB = s7_draw.a
COMP_DATA_LIB = s7_data.a
COMPILER_LIB = s7_comp.a
ALL_S7_LIBS = ..\bin\$(COMPILER_LIB) ..\bin\$(COMP_DATA_LIB) ..\bin\$
(DRAW_LIB) ..\bin\$(CONSOLE_LIB) ..\bin\$(SEED7_LIB)
# CC = g++
CC = gcc
GET_CC_VERSION_INFO = $(CC) --version >

BIGINT_LIB_DEFINE = USE_BIG_RTL_LIBRARY
BIGINT_LIB = big_rtl
# BIGINT_LIB_DEFINE = USE_BIG_GMP_LIBRARY
# BIGINT_LIB = big_gmp

MOBJ1 = hi.o
POBJ1 = runerr.o option.o primitiv.o
LOBJ1 = actlib.o arrlib.o biglib.o blnlib.o bstlib.o chrlib.o cmdlib.o
conlib.o dcllib.o drwlib.o
LOBJ2 = enulib.o fillib.o fltlib.o hshlib.o intlib.o itflib.o kbdlib.o
lstlib.o prclib.o prglib.o
LOBJ3 = reflib.o rfllib.o sctlib.o setlib.o soclib.o strlib.o timlib.o
typlib.o ut8lib.o
EOBJ1 = exec.o doany.o objutl.o
AOBJ1 = act_comp.o prg_comp.o analyze.o syntax.o token.o parser.o
name.o type.o
AOBJ2 = expr.o atom.o object.o scanner.o literal.o numlit.o findid.o
AOBJ3 = error.o infile.o symbol.o info.o stat.o fatal.o match.o
GOBJ1 = syvarutl.o traceutl.o actutl.o executl.o blockutl.o
GOBJ2 = entutl.o identutl.o chclsutl.o sigutl.o
ROBJ1 = arr_rtl.o bln_rtl.o bst_rtl.o chr_rtl.o cmd_rtl.o con_rtl.o
dir_rtl.o drw_rtl.o fil_rtl.o
ROBJ2 = flt_rtl.o hsh_rtl.o int_rtl.o set_rtl.o soc_dos.o str_rtl.o
tim_rtl.o ut8_rtl.o
ROBJ3 = heaputl.o striutl.o
DOBJ1 = $(BIGINT_LIB).o cmd_unx.o fil_dos.o tim_dos.o
OBJ = $(MOBJ1)
SEED7_LIB_OBJ = $(ROBJ1) $(ROBJ2) $(ROBJ3) $(DOBJ1)
DRAW_LIB_OBJ = gkb_rtl.o drw_dos.o
CONSOLE_LIB_OBJ = kbd_rtl.o con_wat.o
COMP_DATA_LIB_OBJ = typ_data.o rfl_data.o ref_data.o listutl.o
flistutl.o typeutl.o datautl.o
COMPILER_LIB_OBJ = $(POBJ1) $(LOBJ1) $(LOBJ2) $(LOBJ3) $(EOBJ1) $
(AOBJ1) $(AOBJ2) $(AOBJ3) $(GOBJ1) $(GOBJ2)

MSRC1 = hi.c
PSRC1 = runerr.c option.c primitiv.c
LSRC1 = actlib.c arrlib.c biglib.c blnlib.c bstlib.c chrlib.c cmdlib.c
conlib.c dcllib.c drwlib.c
LSRC2 = enulib.c fillib.c fltlib.c hshlib.c intlib.c itflib.c kbdlib.c
lstlib.c prclib.c prglib.c
LSRC3 = reflib.c rfllib.c sctlib.c setlib.c soclib.c strlib.c timlib.c
typlib.c ut8lib.c
ESRC1 = exec.c doany.c objutl.c
ASRC1 = act_comp.c prg_comp.c analyze.c syntax.c token.c parser.c
name.c type.c
ASRC2 = expr.c atom.c object.c scanner.c literal.c numlit.c findid.c
ASRC3 = error.c infile.c symbol.c info.c stat.c fatal.c match.c
GSRC1 = syvarutl.c traceutl.c actutl.c executl.c blockutl.c
GSRC2 = entutl.c identutl.c chclsutl.c sigutl.c
RSRC1 = arr_rtl.c bln_rtl.c bst_rtl.c chr_rtl.c cmd_rtl.c con_rtl.c
dir_rtl.c drw_rtl.c fil_rtl.c
RSRC2 = flt_rtl.c hsh_rtl.c int_rtl.c set_rtl.c soc_dos.c str_rtl.c
tim_rtl.c ut8_rtl.c
RSRC3 = heaputl.c striutl.c
DSRC1 = $(BIGINT_LIB).c cmd_unx.c fil_dos.c tim_dos.c
SRC = $(MSRC1)
SEED7_LIB_SRC = $(RSRC1) $(RSRC2) $(RSRC3) $(DSRC1)
DRAW_LIB_SRC = gkb_rtl.c drw_dos.c
CONSOLE_LIB_SRC = kbd_rtl.c con_wat.c
COMP_DATA_LIB_SRC = typ_data.c rfl_data.c ref_data.c listutl.c
flistutl.c typeutl.c datautl.c
COMPILER_LIB_SRC = $(PSRC1) $(LSRC1) $(LSRC2) $(LSRC3) $(ESRC1) $
(ASRC1) $(ASRC2) $(ASRC3) $(GSRC1) $(GSRC2)

hi: ..\bin\hi.exe ..\prg\hi.exe
..\bin\hi level

..\bin\hi.exe: $(OBJ) $(ALL_S7_LIBS)
$(CC) $(LDFLAGS) $(OBJ) $(ALL_S7_LIBS) $(SYSTEM_DRAW_LIBS) $
(SYSTEM_CONSOLE_LIBS) $(SYSTEM_LIBS) -o ..\bin\hi.exe

..\prg\hi.exe: ..\bin\hi.exe
copy ..\bin\hi.exe ..\prg

clear: clean

clean:
del version.h
del *.o
del ..\bin\*.a
del depend

dep: depend

strip:
strip ..\bin\hi.exe

version.h:
echo "#define ANSI_C" > version.h
echo "#define USE_DIRENT" >> version.h
echo "#define PATH_DELIMITER '\\\\'" >> version.h
echo "#define SEARCH_PATH_DELIMITER ';'" >> version.h
echo "#define MAP_ABSOLUTE_PATH_TO_DRIVE_LETTERS" >> version.h
echo "#define CATCH_SIGNALS" >> version.h
echo "#define AWAIT_WITH_SELECT" >> version.h
echo "#define OS_STRI_USES_CODEPAGE" >> version.h
echo "#define os_lstat stat" >> version.h
echo "#define os_fseek fseek" >> version.h
echo "#define os_ftell ftell" >> version.h
echo "#define OS_FSEEK_OFFSET_BITS 32" >> version.h
echo "#define os_off_t off_t" >> version.h
echo "#define os_putenv putenv" >> version.h
echo "#define $(BIGINT_LIB_DEFINE)" >> version.h
echo "#define likely(x) __builtin_expect((x),1)" >> version.h
echo "#define unlikely(x) __builtin_expect((x),0)" >> version.h
$(GET_CC_VERSION_INFO) cc_vers.txt
echo "#include \"direct.h\"" > chkccomp.h
echo "#define mkdir(path,mode) mkdir(path)" >> chkccomp.h
echo "#define LIST_DIRECTORY_CONTENTS \"dir\"" >> chkccomp.h
echo "#define long_long_EXISTS" >> chkccomp.h
echo "#define long_long_SUFFIX_LL" >> chkccomp.h
$(CC) chkccomp.c -lm -o chkccomp.exe
.\chkccomp.exe >> version.h
del chkccomp.h
del chkccomp.exe
del cc_vers.txt
echo "#define OBJECT_FILE_EXTENSION \".o\"" >> version.h
echo "#define LIBRARY_FILE_EXTENSION \".a\"" >> version.h
echo "#define EXECUTABLE_FILE_EXTENSION \".exe\"" >> version.h
echo "#define C_COMPILER \"$(CC)\"" >> version.h
echo "#define GET_CC_VERSION_INFO \"$(GET_CC_VERSION_INFO)\"" >>
version.h
echo "#define CC_OPT_DEBUG_INFO \"-g\"" >> version.h
echo "#define CC_OPT_NO_WARNINGS \"-w\"" >> version.h
echo "#define LINKER_OPT_OUTPUT_FILE \"-o \"" >> version.h
echo "#define LINKER_FLAGS \"$(LDFLAGS)\"" >> version.h
echo "#define SYSTEM_LIBS \"$(SYSTEM_LIBS)\"" >> version.h
echo "#define SYSTEM_CONSOLE_LIBS \"$(SYSTEM_CONSOLE_LIBS)\"" >>
version.h
echo "#define SYSTEM_DRAW_LIBS \"$(SYSTEM_DRAW_LIBS)\"" >> version.h
echo "#define SEED7_LIB \"$(SEED7_LIB)\"" >> version.h
echo "#define CONSOLE_LIB \"$(CONSOLE_LIB)\"" >> version.h
echo "#define DRAW_LIB \"$(DRAW_LIB)\"" >> version.h
echo "#define COMP_DATA_LIB \"$(COMP_DATA_LIB)\"" >> version.h
echo "#define COMPILER_LIB \"$(COMPILER_LIB)\"" >> version.h
echo "#define STACK_SIZE_DEFINITION unsigned _stklen = 4194304" >>
version.h
$(CC) setpaths.c -o setpaths.exe
.\setpaths.exe >> version.h
del setpaths.exe

depend: version.h
echo Working without C header dependency checks.

level.h:
..\bin\hi level

..\bin\$(SEED7_LIB): $(SEED7_LIB_OBJ)
ar r ..\bin\$(SEED7_LIB) $(SEED7_LIB_OBJ)

..\bin\$(CONSOLE_LIB): $(CONSOLE_LIB_OBJ)
ar r ..\bin\$(CONSOLE_LIB) $(CONSOLE_LIB_OBJ)

..\bin\$(DRAW_LIB): $(DRAW_LIB_OBJ)
ar r ..\bin\$(DRAW_LIB) $(DRAW_LIB_OBJ)

..\bin\$(COMP_DATA_LIB): $(COMP_DATA_LIB_OBJ)
ar r ..\bin\$(COMP_DATA_LIB) $(COMP_DATA_LIB_OBJ)

..\bin\$(COMPILER_LIB): $(COMPILER_LIB_OBJ)
ar r ..\bin\$(COMPILER_LIB) $(COMPILER_LIB_OBJ)

wc: $(SRC)
echo SRC:
wc $(SRC)
echo SEED7_LIB_SRC:
wc $(SEED7_LIB_SRC)
echo CONSOLE_LIB_SRC:
wc $(CONSOLE_LIB_SRC)
echo DRAW_LIB_SRC:
wc $(DRAW_LIB_SRC)
echo COMP_DATA_LIB_SRC:
wc $(COMP_DATA_LIB_SRC)
echo COMPILER_LIB_SRC:
wc $(COMPILER_LIB_SRC)

lint: $(SRC)
lint -p $(SRC) $(SYSTEM_DRAW_LIBS) $(SYSTEM_CONSOLE_LIBS) $
(SYSTEM_LIBS)

lint2: $(SRC)
lint -Zn2048 $(SRC) $(SYSTEM_DRAW_LIBS) $(SYSTEM_CONSOLE_LIBS) $
(SYSTEM_LIBS)
------------- end mk_djgpp.mak ---------------

The only difference to the last version are the rules to produce
"version.h" with echo commands.

Please try this makefile (be careful the usenet system (google
groups) might add line breaks), and tell me what is still missing.
Post by Rugxulo
And yet it still seems to do it when not using Bash. I don't know why.
Perhaps your Make is old 3.79.1?
Yes, my DJGPP make has version 3.79.1
Post by Rugxulo
I'm using /beta/mak381b.zip here.
Also I think you must have Fil41b, Txt20b, Shl2011b (aka, CoreUtils)
installed else it has some other error in the "make depend" stage,
didn't check too closely.
Since I installed DJGPP long ago I cannot remember which packages
I installed. I certainly did not install all packages of DJGPP. When
I was able to compile Seed7 I stopped installing DJGPP packages.
Post by Rugxulo
Post by Rugxulo
redir -eo hi chk_all | tee blah.txt
As explained elsewhere you can start every chkxxx.sd7 program
separately. Separate compilation of every chkxxx.sd7 programs is
also possible.
Post by Rugxulo
I'm not sure *.cerrs is being created.
You are right, no *.cerrs or *.lerrs are created.
Post by Rugxulo
You may still have blindly
assumed "2>" works everywhere.
No, acually the preprocessor macro REDIRECT_C_ERRORS is
used to redirect to *.cerrs. Since the macro is not
defined in mk_djgpp.mak, no *.cerrs or *.lerrs is
produced.
Post by Rugxulo
But let me reiterate that "hi chkbig"
and "hi chkset" both work fine. Honestly, all this fuss may be (only)
over the compiled compiler, which I don't really "need", do I? An
interpreter is good enough. ;-)
It would still be interesting to find out why compilation of
chkbig.sd7 and chkset.sd7 fails. I want to be sure that the Seed7
compiler is not the cause of the error.
Post by Rugxulo
P.S. Does your makefile depend on both "seed7/bin/hi" and "seed7/bin/
hi.exe" existing? They're the same exact file but wasting space with
duplication. Feel free to directly "-o hi.exe" (instead of "-o hi") to
avoid that.
Thank you, I was not aware of that.


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Rugxulo
2011-11-30 01:04:06 UTC
Permalink
Hi,
Post by tm
I have no idea how to the fix the "Ambiguous redirect error". The
purpose of the preprocessor macro C_COMPILER_VERSION is explained
in a previous message.
GET_CC_VERSION_INFO = redir -o cc_vers.txt $(CC) --version
Post by tm
Escaping quotes is also done in other makefiles. In this makefiles
the argument to echo is a quoted string. Inspired by this I created
------------- begin mk_djgpp.mak ---------------
(snip)
------------- end mk_djgpp.mak ---------------
I guess I should give this a try and report back?

But yes, the problem is that *nix and DOS behave differently:

echo hello "silly" world > blah.txt

DOS: hello "silly" world
Linux: hello silly world
Post by tm
The only difference to the last version are the rules to produce
"version.h" with echo commands.
Please try this makefile (be careful the usenet system (google
groups) might add line breaks), and tell me what is still missing.
Okay. You could also email me if that's easier. Though I think (?) I
can handle it for now. ;-)
Post by tm
Post by Rugxulo
And yet it still seems to do it when not using Bash. I don't know why.
Perhaps your Make is old 3.79.1?
Yes, my DJGPP make has version 3.79.1
Some minor things changed between that one (old, stable) and (new,
modern) 3.81. That's why I mentioned it, I suspected it might be the
culprit. It might be easier to just have a .sh script (or even .BAT)
with simple compilation commands. Make is often overused and brittle,
kinda frustrating (IMO).

(joking) Maybe DJ can borrow some time on the GCC Power7 Compile Farm,
heheheh. "make djworld" every day at 12:01am. ;-)
Post by tm
Post by Rugxulo
I'm using /beta/mak381b.zip here.
Also I think you must have Fil41b, Txt20b, Shl2011b (aka, CoreUtils)
installed else it has some other error in the "make depend" stage,
didn't check too closely.
Since I installed DJGPP long ago I cannot remember which packages
I installed.
ls /dev/env/DJDIR/manifest/*.mft
dir c:\djgpp\manifest\*.mft /w
Post by tm
I certainly did not install all packages of DJGPP.
No, definitely not, it would be too many. For whatever reason, I end
up installing / upgrading / reinstalling it a lot (and/or keep
separate versions). It's those dumb POSIX requirements to have so many
bazillion tools that complicates everything.
Post by tm
When
I was able to compile Seed7 I stopped installing DJGPP packages.
Perfectly reasonable, just hard to reproduce without much of a
clue. ;-)
Post by tm
Post by Rugxulo
Post by Rugxulo
redir -eo hi chk_all | tee blah.txt
As explained elsewhere you can start every chkxxx.sd7 program
separately. Separate compilation of every chkxxx.sd7 programs is
also possible.
Yes, I know, but "hi chk_all" is the official way, no?
Post by tm
Post by Rugxulo
I'm not sure *.cerrs is being created.
You are right, no *.cerrs or *.lerrs are created.
Post by Rugxulo
You may still have blindly
assumed "2>" works everywhere.
No, acually the preprocessor macro REDIRECT_C_ERRORS is
used to redirect to *.cerrs. Since the macro is not
defined in mk_djgpp.mak, no *.cerrs or *.lerrs is
produced.
Well, since we have some weird errors somewhere, it might be a good
idea to temporarily enable logging of them. ;-) But I was
(sometimes) getting weird errors from REDIR (or Seed7 ?? or CWSDPMI
r7 ??) here. But typically you type "redir -eo gcc buggy_file.c >
bugs.txt" or similar.
Post by tm
Post by Rugxulo
But let me reiterate that "hi chkbig"
and "hi chkset" both work fine. Honestly, all this fuss may be (only)
over the compiled compiler, which I don't really "need", do I? An
interpreter is good enough.   ;-)
It would still be interesting to find out why compilation of
chkbig.sd7 and chkset.sd7 fails. I want to be sure that the Seed7
compiler is not the cause of the error.
Honestly, surprisingly, I don't think it is. But there are a lot of
little pieces and weird issues with various environmental things. So
it's hard to isolate (and confusing, at least to me).
Post by tm
Post by Rugxulo
P.S. Does your makefile depend on both "seed7/bin/hi" and "seed7/bin/
hi.exe" existing? They're the same exact file but wasting space with
duplication. Feel free to directly "-o hi.exe" (instead of "-o hi") to
avoid that.
Thank you, I was not aware of that.
Not a big deal, just a small oversight. I'm not really complaining
since it was so minor (and some makefiles indeed rely on "prog" to
exist, not a lot of $(EXE) usage these days, all the world's a
POSIX !).
tm
2011-11-30 23:01:29 UTC
Permalink
Post by Rugxulo
Hi,
Post by tm
I have no idea how to the fix the "Ambiguous redirect error". The
purpose of the preprocessor macro C_COMPILER_VERSION is explained
in a previous message.
GET_CC_VERSION_INFO = redir -o cc_vers.txt $(CC) --version
When I use redir under XP it just writes

The Vdm Redirector is already loaded

and it does not redirect anything. I really have doubts to use
redir, as it seems to fail under Windows. Do you use an original
DOS redir or one from a DOS clone?
Post by Rugxulo
Post by tm
Escaping quotes is also done in other makefiles. In this makefiles
the argument to echo is a quoted string. Inspired by this I created
------------- begin mk_djgpp.mak ---------------
(snip)
------------- end mk_djgpp.mak ---------------
I guess I should give this a try and report back?
Yes, please.
Post by Rugxulo
echo hello "silly" world > blah.txt
DOS: hello "silly" world
Linux: hello silly world
An echo command in a makefile might work differently from an echo
command in a console window. It seems that on your computer echo
commands in a makefile work like Linux echo commands. I tried to
take that into account. The new "mk_djgpp.mak" from the last post
contains commands like

echo "#define OBJECT_FILE_EXTENSION \".o\"" >> version.h
echo "#define SEARCH_PATH_DELIMITER ';'" >> version.h
echo "#define PATH_DELIMITER '\\\\'" >> version.h

which should write

#define OBJECT_FILE_EXTENSION ".o"
#define SEARCH_PATH_DELIMITER ';'
#define PATH_DELIMITER '\\'

to the file "version.h". I would like to know, if my approach is
working as expected. Please do a test. My newest attempt to solve
the redirect problem is based on the "mk_djgpp.mak" file from
the last post. It removes the line

$(GET_CC_VERSION_INFO) cc_vers.txt

and adds the line marked with +

echo "#include \"direct.h\"" > chkccomp.h
+ echo "#define WRITE_CC_VERSION_INFO system(\"$(GET_CC_VERSION_INFO)
cc_vers.txt\");" >> chkccomp.h
echo "#define mkdir(path,mode) mkdir(path)" >> chkccomp.h
echo "#define LIST_DIRECTORY_CONTENTS \"dir\"" >> chkccomp.h

This way the check for the C compiler version is done inside the
program chkccomp.c with a system() call. But there is still
the command

echo "#define GET_CC_VERSION_INFO \"$(GET_CC_VERSION_INFO)\"" >>
version.h

in "mk_djgpp.mak". Hopefully it does not create problems. Currently
I plan to release two versions of "mk_djgpp.mak". One which works
for you (commands are executed by bash), which will probably keep
the name "mk_djgpp.mak" and one which works for me (commands are
executed by cmd.exe/command.com), which would get a new name like
"mk_djgp2.mak". The "mk_djgp2.mak" makefile will hopefully help
people, who did not install the DJGPP bash package.
Post by Rugxulo
Post by tm
The only difference to the last version are the rules to produce
"version.h" with echo commands.
Please try this makefile (be careful the usenet system (google
groups) might add line breaks), and tell me what is still missing.
Okay. You could also email me if that's easier. Though I think (?) I
can handle it for now. ;-)
Thank you in advance, for your effort.
Post by Rugxulo
Post by tm
Post by Rugxulo
And yet it still seems to do it when not using Bash. I don't know why.
Perhaps your Make is old 3.79.1?
Yes, my DJGPP make has version 3.79.1
Some minor things changed between that one (old, stable) and (new,
modern) 3.81. That's why I mentioned it, I suspected it might be the
culprit. It might be easier to just have a .sh script (or even .BAT)
with simple compilation commands. Make is often overused and brittle,
kinda frustrating (IMO).
The advantage of make comes into effect, when a few source files are
changed, and make only compiles the changed files.
Post by Rugxulo
Post by tm
Post by Rugxulo
Post by Rugxulo
redir -eo hi chk_all | tee blah.txt
As explained elsewhere you can start every chkxxx.sd7 program
separately. Separate compilation of every chkxxx.sd7 programs is
also possible.
Yes, I know, but "hi chk_all" is the official way, no?
Yes, but when "hi chk_all" shows errors it can be helpful to start
and compile chkxxx.sd7 programs separately.
Post by Rugxulo
Post by tm
Post by Rugxulo
I'm not sure *.cerrs is being created.
You are right, no *.cerrs or *.lerrs are created.
Post by Rugxulo
You may still have blindly
assumed "2>" works everywhere.
No, acually the preprocessor macro REDIRECT_C_ERRORS is
used to redirect to *.cerrs. Since the macro is not
defined in mk_djgpp.mak, no *.cerrs or *.lerrs is
produced.
Well, since we have some weird errors somewhere, it might be a good
idea to temporarily enable logging of them. ;-)
Without redirecting to *.cerrs the errors should be visible on the
console.
Post by Rugxulo
Post by tm
Post by Rugxulo
But let me reiterate that "hi chkbig"
and "hi chkset" both work fine. Honestly, all this fuss may be (only)
over the compiled compiler, which I don't really "need", do I? An
interpreter is good enough. ;-)
It would still be interesting to find out why compilation of
chkbig.sd7 and chkset.sd7 fails. I want to be sure that the Seed7
compiler is not the cause of the error.
Honestly, surprisingly, I don't think it is. But there are a lot of
little pieces and weird issues with various environmental things. So
it's hard to isolate (and confusing, at least to me).
Ok, so I assume for now that the errors are not caused by the Seed7
compiler.


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Rugxulo
2011-12-01 01:14:54 UTC
Permalink
Hi,
Post by tm
Post by Rugxulo
Post by tm
I have no idea how to the fix the "Ambiguous redirect error". The
purpose of the preprocessor macro C_COMPILER_VERSION is explained
in a previous message.
GET_CC_VERSION_INFO = redir -o cc_vers.txt $(CC) --version
When I use redir under XP it just writes
  The Vdm Redirector is already loaded
and it does not redirect anything. I really have doubts to use
redir, as it seems to fail under Windows. Do you use an original
DOS redir or one from a DOS clone?
Oops, this is a minor configuration error that I'd hoped wouldn't bite
you. Long story short, you should put DJGPP\BIN first in your PATH
(plus it's faster that way). I've thought before that "next" DJGPP (I
can dream, can't I?) would fix some of the Windows issues by renaming
or symlinking some things, e.g. djredir, djpatc, djupdat, etc.

Long story short: Windows has its own (unrelated) REDIR.EXE in the
path, but DJGPP's version (in your /bin/ directory) is what you want.
Heck, perhaps we could rename DJGPP's to REDIR.COM. It should still
work the same (famous last words).
Post by tm
Post by Rugxulo
Post by tm
Escaping quotes is also done in other makefiles. In this makefiles
the argument to echo is a quoted string. Inspired by this I created
------------- begin mk_djgpp.mak ---------------
(snip)
------------- end mk_djgpp.mak ---------------
I guess I should give this a try and report back?
Yes, please.
IIRC, it didn't quite work, but I think it was minor stuff. I'll have
to try again (sadly, I know that's not a great answer).

Honestly, the whole '\\\\' part was giving a (harmless??) warning, so
I'm not entirely sure how to fix that. Perhaps '\\\\\' [sic, five!],
but maybe not. Eli Z., are you reading this? (he's the expert!) ;-)
Post by tm
The new "mk_djgpp.mak" from the last post
contains commands like
        echo "#define OBJECT_FILE_EXTENSION \".o\"" >> version.h
        echo "#define SEARCH_PATH_DELIMITER ';'" >> version.h
        echo "#define PATH_DELIMITER '\\\\'" >> version.h
which should write
  #define OBJECT_FILE_EXTENSION ".o"
  #define SEARCH_PATH_DELIMITER ';'
  #define PATH_DELIMITER '\\'
to the file "version.h". I would like to know, if my approach is
working as expected. Please do a test.
See above (but I also intend to test, yet again).
Post by tm
My newest attempt to solve
the redirect problem is based on the "mk_djgpp.mak" file from
the last post. It removes the line
        $(GET_CC_VERSION_INFO) cc_vers.txt
and adds the line marked with +
        echo "#include \"direct.h\"" > chkccomp.h
+       echo "#define WRITE_CC_VERSION_INFO system(\"$(GET_CC_VERSION_INFO)
cc_vers.txt\");" >> chkccomp.h
        echo "#define mkdir(path,mode) mkdir(path)" >> chkccomp.h
        echo "#define LIST_DIRECTORY_CONTENTS \"dir\"" >> chkccomp.h
This way the check for the C compiler version is done inside the
program chkccomp.c with a system() call. But there is still
the command
        echo "#define GET_CC_VERSION_INFO \"$(GET_CC_VERSION_INFO)\"" >>
version.h
(confusing without testing it)
Post by tm
in "mk_djgpp.mak". Hopefully it does not create problems. Currently
I plan to release two versions of "mk_djgpp.mak". One which works
for you (commands are executed by bash), which will probably keep
the name "mk_djgpp.mak" and one which works for me (commands are
executed by cmd.exe/command.com), which would get a new name like
"mk_djgp2.mak". The "mk_djgp2.mak" makefile will hopefully help
people, who did not install the DJGPP bash package.
I have no intention of requiring Bash. I'd rather do without,
honestly. Don't feel obligated to support that. It'd be best if it
didn't need it and "just worked" in CMD or COMMAND.COM.
Post by tm
Post by Rugxulo
Post by tm
Post by Rugxulo
And yet it still seems to do it when not using Bash. I don't know why.
Perhaps your Make is old 3.79.1?
Yes, my DJGPP make has version 3.79.1
Some minor things changed between that one (old, stable) and (new,
modern) 3.81. That's why I mentioned it, I suspected it might be the
culprit. It might be easier to just have a .sh script (or even .BAT)
with simple compilation commands. Make is often overused and brittle,
kinda frustrating (IMO).
The advantage of make comes into effect, when a few source files are
changed, and make only compiles the changed files.
Right, but when everything *requires* make and is so brittle and
easily broken, it's just frustrating. Worse when lots of POSIX or
Linux-specific stuff is used. Heck, I was trying something else
earlier today and got weird errors. It's just frustrating, that's all.
(And Make 3.82 has been out for a few months [though not for DJGPP]
but has some weird bug or two. Strange how hard it is to stabilize.)

It's fun when it works, painful when it doesn't.
Post by tm
Post by Rugxulo
Post by tm
Post by Rugxulo
Post by Rugxulo
redir -eo hi chk_all | tee blah.txt
As explained elsewhere you can start every chkxxx.sd7 program
separately. Separate compilation of every chkxxx.sd7 programs is
also possible.
Yes, I know, but "hi chk_all" is the official way, no?
Yes, but when "hi chk_all" shows errors it can be helpful to start
and compile chkxxx.sd7 programs separately.
Yes. But I would prefer output written to file if it's bigger than two
screens or so. Then it'd be easy to compare with md5sum or diff or
whatever.
Post by tm
Post by Rugxulo
Post by tm
Post by Rugxulo
I'm not sure *.cerrs is being created.
You are right, no *.cerrs or *.lerrs are created.
Post by Rugxulo
You may still have blindly
assumed "2>" works everywhere.
No, acually the preprocessor macro REDIRECT_C_ERRORS is
used to redirect to *.cerrs. Since the macro is not
defined in mk_djgpp.mak, no *.cerrs or *.lerrs is
produced.
Well, since we have some weird errors somewhere, it might be a good
idea to temporarily enable logging of them.   ;-)
Without redirecting to *.cerrs the errors should be visible on the
console.
But the console doesn't pause when full, sadly. Perhaps you should
pipe it to "more" or "less" or whatever. But nah, I still say an
output file would be better (IMHO).
Post by tm
Post by Rugxulo
Post by tm
Post by Rugxulo
But let me reiterate that "hi chkbig"
and "hi chkset" both work fine. Honestly, all this fuss may be (only)
over the compiled compiler, which I don't really "need", do I? An
interpreter is good enough.   ;-)
It would still be interesting to find out why compilation of
chkbig.sd7 and chkset.sd7 fails. I want to be sure that the Seed7
compiler is not the cause of the error.
Honestly, surprisingly, I don't think it is. But there are a lot of
little pieces and weird issues with various environmental things. So
it's hard to isolate (and confusing, at least to me).
Ok, so I assume for now that the errors are not caused by the Seed7
compiler.
Too few maintainers, not enough testers, too difficult to fix / patch
things unless you know ten bazillion POSIX-y things. No, I don't think
this is Seed7's fault, but there are obvious more than a few things
stacked against us for building some such things, sadly. It takes hard
work to fix. I just wish I wasn't so useless ....
tm
2011-12-01 12:46:50 UTC
Permalink
Post by Rugxulo
Post by tm
When I use redir under XP it just writes
The Vdm Redirector is already loaded
and it does not redirect anything. I really have doubts to use
redir, as it seems to fail under Windows. Do you use an original
DOS redir or one from a DOS clone?
Oops, this is a minor configuration error that I'd hoped wouldn't bite
you. Long story short, you should put DJGPP\BIN first in your PATH
(plus it's faster that way). I've thought before that "next" DJGPP (I
can dream, can't I?) would fix some of the Windows issues by renaming
or symlinking some things, e.g. djredir, djpatc, djupdat, etc.
Long story short: Windows has its own (unrelated) REDIR.EXE in the
path, but DJGPP's version (in your /bin/ directory) is what you want.
Heck, perhaps we could rename DJGPP's to REDIR.COM. It should still
work the same (famous last words).
AFAICS only one redirection (the one to get the C compiler version)
has problems. Other redirections (e.g.: echo into "version.h") don't
have problems. Since I plan to determine the C compiler version in
"chkccomp.c" (instead of in the makefile) this could work without
REDIR.COM.
Post by Rugxulo
Post by tm
Post by Rugxulo
Post by tm
Escaping quotes is also done in other makefiles. In this makefiles
the argument to echo is a quoted string. Inspired by this I created
------------- begin mk_djgpp.mak ---------------
(snip)
------------- end mk_djgpp.mak ---------------
I guess I should give this a try and report back?
Yes, please.
IIRC, it didn't quite work, but I think it was minor stuff. I'll have
to try again (sadly, I know that's not a great answer).
Honestly, the whole '\\\\' part was giving a (harmless??) warning, so
I'm not entirely sure how to fix that. Perhaps '\\\\\' [sic, five!],
but maybe not. Eli Z., are you reading this? (he's the expert!) ;-)
Ok, I will use

echo "#define PATH_DELIMITER 92 /* backslash (ASCII) */" >> version.h

instead. Hopefully the quotes around the string beware us from
problems with the C comment. Does the echo command above (issued
from a makefile) write

#define PATH_DELIMITER 92 /* backslash (ASCII) */

into the file "version.h"?
Post by Rugxulo
Post by tm
This way the check for the C compiler version is done inside the
program chkccomp.c with a system() call. But there is still
the command
echo "#define GET_CC_VERSION_INFO \"$(GET_CC_VERSION_INFO)\"" >>
version.h
(confusing without testing it)
Maybe I should just send my current version of "mk_djgpp.mak" by
mail.
Post by Rugxulo
Post by tm
in "mk_djgpp.mak". Hopefully it does not create problems. Currently
I plan to release two versions of "mk_djgpp.mak". One which works
for you (commands are executed by bash), which will probably keep
the name "mk_djgpp.mak" and one which works for me (commands are
executed by cmd.exe/command.com), which would get a new name like
"mk_djgp2.mak". The "mk_djgp2.mak" makefile will hopefully help
people, who did not install the DJGPP bash package.
I have no intention of requiring Bash. I'd rather do without,
honestly. Don't feel obligated to support that. It'd be best if it
didn't need it and "just worked" in CMD or COMMAND.COM.
So your DJGPP installation does not include bash. I thought that
your make utility executes commands in the makefile with bash. At
least executing echo from a makefile seems to remove quotes ("),
unless they are escaped with \" .
Post by Rugxulo
Post by tm
The advantage of make comes into effect, when a few source files are
changed, and make only compiles the changed files.
Right, but when everything *requires* make and is so brittle and
easily broken, it's just frustrating. Worse when lots of POSIX or
Linux-specific stuff is used. Heck, I was trying something else
earlier today and got weird errors. It's just frustrating, that's all.
(And Make 3.82 has been out for a few months [though not for DJGPP]
but has some weird bug or two. Strange how hard it is to stabilize.)
It's fun when it works, painful when it doesn't.
Hopefully we soon come to the fun part with Seed7 compilation.
Post by Rugxulo
Post by tm
Post by Rugxulo
Post by tm
Post by Rugxulo
Post by Rugxulo
redir -eo hi chk_all | tee blah.txt
As explained elsewhere you can start every chkxxx.sd7 program
separately. Separate compilation of every chkxxx.sd7 programs is
also possible.
Yes, I know, but "hi chk_all" is the official way, no?
Yes, but when "hi chk_all" shows errors it can be helpful to start
and compile chkxxx.sd7 programs separately.
Yes. But I would prefer output written to file if it's bigger than two
screens or so. Then it'd be easy to compare with md5sum or diff or
whatever.
I see.
Post by Rugxulo
But the console doesn't pause when full, sadly. Perhaps you should
pipe it to "more" or "less" or whatever. But nah, I still say an
output file would be better (IMHO).
In the first post you were able to send the whole output of
"chk_all.sd7". Are you referring to the output of "hi comp chkbig"
and "hi comp chkset"?
Post by Rugxulo
Post by tm
Post by Rugxulo
Post by tm
Post by Rugxulo
But let me reiterate that "hi chkbig"
and "hi chkset" both work fine. Honestly, all this fuss may be (only)
over the compiled compiler, which I don't really "need", do I? An
interpreter is good enough. ;-)
It would still be interesting to find out why compilation of
chkbig.sd7 and chkset.sd7 fails. I want to be sure that the Seed7
compiler is not the cause of the error.
Honestly, surprisingly, I don't think it is. But there are a lot of
little pieces and weird issues with various environmental things. So
it's hard to isolate (and confusing, at least to me).
Ok, so I assume for now that the errors are not caused by the Seed7
compiler.
Too few maintainers, not enough testers, too difficult to fix / patch
things unless you know ten bazillion POSIX-y things. No, I don't think
this is Seed7's fault, but there are obvious more than a few things
stacked against us for building some such things, sadly. It takes hard
work to fix. I just wish I wasn't so useless ....
I am sure that it is not useless.


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Rugxulo
2011-12-01 21:01:29 UTC
Permalink
Hi,
Post by tm
AFAICS only one redirection (the one to get the C compiler version)
has problems. Other redirections (e.g.: echo into "version.h") don't
have problems. Since I plan to determine the C compiler version in
"chkccomp.c" (instead of in the makefile) this could work without
REDIR.COM.
That's fine. Just keep in mind that (DJGPP's) REDIR.EXE is good for
redirecting stderr (a la "2>") and also timing execution ("-t") since
most DOS shells "traditionally" didn't support such features.
Post by tm
Post by Rugxulo
Honestly, the whole '\\\\' part was giving a (harmless??) warning, so
I'm not entirely sure how to fix that. Perhaps '\\\\\' [sic, five!],
but maybe not. Eli Z., are you reading this? (he's the expert!)    ;-)
Ok, I will use
        echo "#define PATH_DELIMITER 92 /* backslash (ASCII) */" >> version.h
instead. Hopefully the quotes around the string beware us from
problems with the C comment. Does the echo command above (issued
from a makefile) write
  #define PATH_DELIMITER 92 /* backslash (ASCII) */
into the file "version.h"?
Tested that briefly here (Make 3.81) under DOSEMU, seems to work fine.
Post by tm
Post by Rugxulo
Post by tm
This way the check for the C compiler version is done inside the
program chkccomp.c with a system() call. But there is still
the command
        echo "#define GET_CC_VERSION_INFO \"$(GET_CC_VERSION_INFO)\"" >>
version.h
(confusing without testing it)
Maybe I should just send my current version of "mk_djgpp.mak" by
mail.
Probably, heh, sorry for any inconvenience, it's just a lot of
patching can be confusing.
Post by tm
Post by Rugxulo
Post by tm
in "mk_djgpp.mak". Hopefully it does not create problems. Currently
I plan to release two versions of "mk_djgpp.mak". One which works
for you (commands are executed by bash), which will probably keep
the name "mk_djgpp.mak" and one which works for me (commands are
executed by cmd.exe/command.com), which would get a new name like
"mk_djgp2.mak". The "mk_djgp2.mak" makefile will hopefully help
people, who did not install the DJGPP bash package.
I have no intention of requiring Bash. I'd rather do without,
honestly. Don't feel obligated to support that. It'd be best if it
didn't need it and "just worked" in CMD or COMMAND.COM.
So your DJGPP installation does not include bash. I thought that
your make utility executes commands in the makefile with bash. At
least executing echo from a makefile seems to remove quotes ("),
unless they are escaped with \" .
Bash is a POSIX shell. DOS is not POSIX. Make also doesn't
(necessarily) require Bash at all. DJGPP's libc, Make, and Bash all
have various workarounds (kludges?) to avoid certain limitations or
enable POSIX-specific features that otherwise wouldn't work.

I'm just saying, I don't use Bash when I don't need it. Sure, for ./
configure it's needed, but that's not a DOS feature, that's GNU's
doing (and it's a horrible kludge, barely works!). I don't need a Bash
shell to run DOS or DJGPP. GCC in DOS only truly needs (as minimum)
libc (djdev204.zip), as + ld (bnu2211b.zip), and gcc (gcc462b.zip).

Make did indeed (IIRC) remove quotes when running under DOS, with or
without Bash! I'm not sure I remember anymore, it may have changed
between 3.79.1 and 3.81. Something like SHELL=/dev/env/DJDIR/bin/
bash.exe isn't set by default anymore or some such, dunno. It's very
confusing, and we have no dedicated Bash, or maybe even Make,
maintainer for DJGPP. Eli Z. might? know or care, but he's probably
ultra busy like the others, I presume.

Long story short: it might honestly just be easier for you (and me?)
to stabilize on one single version of GCC, BinUtils, DJDEV, Make,
(plus CoreUtils of course), etc. Mixing and matching isn't working too
well.
Post by tm
Post by Rugxulo
But the console doesn't pause when full, sadly. Perhaps you should
pipe it to "more" or "less" or whatever. But nah, I still say an
output file would be better (IMHO).
In the first post you were able to send the whole output of
"chk_all.sd7". Are you referring to the output of "hi comp chkbig"
and "hi comp chkset"?
If it's pointed to stdout, simple redirection works fine (though, due
to limitations, piping doesn't show any results until *everything*
finishes). Redirecting from stderr is a bit tricker depending on which
tools you use. FreeDOS does have a device driver that lets you ">more
$" without any intermediate files, so maybe I should've used that. But
you can't scroll back up or anything (like Linux, FreeBSD), so hence I
almost prefer a static output file.

I mean, there are tools to extend text resolution to pretty big in
pure DOS (80x50, 132x60, and several variations, etc.), but I'm fairly
certain Seed7 errors would exceed it no matter what (unless something
is patched, heh, and I don't claim to know anything about IEEE
floating point, and surely I don't think most DOSes will ever support
write-only files).
Martin Strömberg
2011-12-02 19:03:33 UTC
Permalink
[A lot about problem with differences between command.com, cmd.exe and
WINDOZE versions.]

How about putting SHELL=/bin/sh in the makefile(s) and require bash to
be installed and just forget about the WINDOZE weirdness?

(If youÃ're project is *DOZE only perhaps you don't want this. But if
you're also aiming at some other POSIXly platform this should be the
way to go.)
--
MartinS
Rugxulo
2011-12-02 21:25:13 UTC
Permalink
Hi,
Post by Martin Strömberg
[A lot about problem with differences between command.com, cmd.exe and
WINDOZE versions.]
How about putting SHELL=/bin/sh in the makefile(s) and require bash to
be installed and just forget about the WINDOZE weirdness?
Because Bash by itself isn't ever enough, it snowballs from there to
include a bunch of POSIX tools and weird ./configure + m4 + awk + sed
+ make + whatever that is always cryptic and doesn't work well with
DJGPP anymore.

But Bash isn't really needed here. Luckily the necessary stuff is
pretty tame (DOSLFN, basic GCC, Make, some CoreUtils).
Post by Martin Strömberg
(If you 're project is *DOZE only perhaps you don't want this. But if
you're also aiming at some other POSIXly platform this should be the
way to go.)
He seems to mostly target and test on Windows and Linux. And he does
have POSIX bindings for file access. But he's also trying to target
other (non-tier 1) platforms too (thankfully), at least superficially,
e.g. Mac OS X, *BSD.
tm
2011-12-05 14:35:54 UTC
Permalink
Post by Martin Strömberg
[A lot about problem with differences between command.com, cmd.exe and
WINDOZE versions.]
How about putting SHELL=/bin/sh in the makefile(s) and require bash to
be installed and just forget about the WINDOZE weirdness?
I neither want to convert Windows people to Unix (bash,
etc.), nor want to convert Unix people to Windows (Win32,
.NET, etc.).

The Seed7 package provides several makefiles, which are
tailored to different operating systems and C compilers.
Supported OS are Linux, BSDs, Unix, Mac OSX, Windows and
DOS. Details can be found in seed7/src/read_me.txt .

Essentially only two tools are necessary.
1. A C compiler
2. A make utility

For a source code release this barrier is IMHO very
low. On many "development computers" both tools are
probably already installed. When it is required to
install other things, before the actual install can
start, many people will just give up.


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Loading...