X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Rugxulo Newsgroups: comp.lang.misc,comp.os.msdos.djgpp Subject: Re: ANN: Seed7 Release 2011-11-11 Date: Mon, 28 Nov 2011 15:30:17 -0800 (PST) Organization: http://groups.google.com Lines: 178 Message-ID: References: <7037d719-14a3-4e62-8ebc-0fdbdbdf1db1 AT r9g2000vbw DOT googlegroups DOT com> NNTP-Posting-Host: 65.13.115.246 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1322523434 24843 127.0.0.1 (28 Nov 2011 23:37:14 GMT) X-Complaints-To: groups-abuse AT google DOT com NNTP-Posting-Date: Mon, 28 Nov 2011 23:37:14 +0000 (UTC) Complaints-To: groups-abuse AT google DOT com Injection-Info: h3g2000yqa.googlegroups.com; posting-host=65.13.115.246; posting-account=p5rsXQoAAAB8KPnVlgg9E_vlm2dvVhfO User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: HNKRAUELSC X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.630.0 Safari/534.16,gzip(gfe) Bytes: 8886 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id pASNj2o7028754 Reply-To: djgpp AT delorie DOT com Hi, On Nov 28, 4:23 pm, tm wrote: > On Nov 12, 6:08 am, Rugxulo wrote: > > > On Nov 11, 4:20 pm, tm wrote: > > > > 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. > 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? > 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)? Ignore that, it was just a whim, not important here. It doesn't matter for runtime memory anyways (IIRC). > - 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. > - 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. > 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 > > 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: > > 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. > >  ***** 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.) > > 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). > > chkexc > >  *** The interpreted chkexc does not work okay: > > >  ***** 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. ;-) > >  ***** 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. ;-) > 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.