X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: tm Newsgroups: comp.lang.misc,comp.os.msdos.djgpp Subject: Re: ANN: Seed7 Release 2011-11-11 Date: Thu, 1 Dec 2011 04:46:50 -0800 (PST) Organization: http://groups.google.com Lines: 159 Message-ID: <6d7b148e-61e1-4c8f-b77a-0833fe15a6d1@cu3g2000vbb.googlegroups.com> References: <7037d719-14a3-4e62-8ebc-0fdbdbdf1db1 AT r9g2000vbw DOT googlegroups DOT com> <839be453-9721-41d5-9955-14d39a35d31a AT q9g2000yqe DOT googlegroups DOT com> <5f4874db-f024-4c50-9555-5af08e030b50 AT t16g2000vba DOT googlegroups DOT com> NNTP-Posting-Host: 62.134.46.4 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1322743705 20773 127.0.0.1 (1 Dec 2011 12:48:25 GMT) X-Complaints-To: groups-abuse AT google DOT com NNTP-Posting-Date: Thu, 1 Dec 2011 12:48:25 +0000 (UTC) Complaints-To: groups-abuse AT google DOT com Injection-Info: cu3g2000vbb.googlegroups.com; posting-host=62.134.46.4; posting-account=269_QwoAAADSifhJt6OVa6bEjZR2ZMUB User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: HUALESRCNK X-HTTP-UserAgent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0,gzip(gfe) Bytes: 8480 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On 1 Dez., 02:14, Rugxulo wrote: > On Nov 30, 5:01 pm, tm wrote: > > 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. > > > > 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 --------------- > > > > (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"? > > 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. > > 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 \" . > > 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. > > > > > > 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. > 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"? > > > > > 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.