Mail Archives: djgpp/2010/10/15/07:00:23
On 14 Okt., 00:28, Rugxulo <rugx DOT DOT DOT AT gmail DOT com> wrote:
> Hi, apologies in advance for copying/pasting various snippets from the
> above thread, but I figured it was easier than replying separately to
> each.
>
> N.B. I must be extremely curious, ambitious, and dumb to even try
> this. Oh well. Mainly I'm just impressed with your tenacity with
> always updating Seed7. (There isn't much other traffic in this
> newsgroup.) Plus I know you said you once had a DOS port, plus you
> like Pascal and want to eventually port Pascal_S, which sounds good to
> me too. ;-)
It is a port of the P4 Pascal compiler not Pascal_S. The port of the
P4 is actually finished. The Seed7 version of the P4 can compile
itself and the Seed7 version of the I4 can execute the P-code
produced by the P4. All this things work, but the do not work with
the officially released Seed7. I need to do some things with the
64-bit support... When this things are done I will release the
Seed7 version of the P4. Don't hold your breath. It will take some
time, since there are other things at the priority list such as
font support.
> On Oct 12, 8:48 am, tm <thomas DOT mer DOT DOT DOT AT gmx DOT at> wrote:
>
> > I am thinking about ways to improve the build and config process.
> > Please provide me information to reach this goal.
>
> Long story short: Your interpreter / compiler is GPL / LGPL, and it
> supports GCC on Linux and Windows, which is all good ... but you know
> DJGPP exists too, right?? It's too good to ignore, IMHO. (Sigh, silly
> AMD64 hates DOS, oh well, at least DOSBox / DOSEMU / BOCHS etc. work,
> albeit slowly.) FreeDOS exists too, and yes, people run still it
> natively. :-)
>
> N.B. I'm really very very weak in C and have literally no knowledge of
> POSIX at all. Plus I'm no comp.sci. major, just a lame hobbyist
> uneducated hacker. But still I try ....
>
> BartC> I've just spent an hour and a half struggling with getting
> BartC> this going, but no luck.
>
> I spent about that today too, using DJGPP 2.04 (symlinks ftw!), GCC
> 4.4.4, BinUtils 2.19, Blairs Ncurses 5.7 (?), Bash 2.05b, etc.
>
> BartC> Surely it should be possible for someone to try this out
> BartC> without first becoming an expert on C systems and Make
> BartC> programs? Apart from being obliged to have some rather
> BartC> specific C compilers on hand.
>
> C and Make are common with *nix, and since Linux is all the rage,
> that's usually what you have to deal with, even on Windows (MSYS,
> MinGW, Cygwin, DJGPP).
>
> tm> Sure, please help me to find a solution.
>
> Not sure this is much help, but hey, it's way better than nothing!
Much more than that. You did good work. I will try to improve the
next release so that fewer changes for DJGPP are necessary (see
below).
> BartC> The solution is very simple: just make available some sort
> BartC> of binary installation to help people get started. Even if
> BartC> programs can't be compiled for maximum speed, they can at
> BartC> least try out the language. Myself, I was mainly interested
> BartC> in how fast Seed 7 was. I found the interpreter quite slow ...
>
> Erm, the interpreter is probably the best way to "try" the language.
> Heck, some languages don't even have compilers! I'm not picking on
> you, just saying, if you want something to test, an interpreter is it.
> But if you want something fast-running, a compiler is the only option.
>
> (And yes, other languages, e.g. Rexx via Regina or ooRexx, both
> provide tons of premade binaries on their sites. It's much more
> convenient, IMHO. Apparently tm has tons of old srcs on SourceForge
> anyways, so he could easily remove some of those obsoleted and put up
> some binaries. It can't be that big a space waste.)
It is not a problem of space (see below). It can be a problem of
effort, since every release already takes several hours of work.
> tm> A binary installation needs to check for an existing C compiler
> tm> and make utility. if there are none it must install them. There
> tm> are all sorts of potential problems. I always hoped that someone
> tm> else does this work.
>
> The interpreter doesn't need a C compiler, nor Make. IMHO, that would
> be enough to provide.
You are right, the interpreter does not need this things. The
interpreter can definitely be provided as executable.
The Seed7 compiler is something else. The Seed7 compiler needs to be
configured to fit to a certain C compiler and to the corresponding
runtime library. To keep things simple I decided to do this
configuration when the interpreter is compiled.
In summary: When you compile the interpreter the Seed7 compiler is
configured also.
In other words: The interpreter executable contains the
configuration information used by the Seed7 compiler.
This configuration is done when you do
make depend
So when you compile the interpreter without make utility this
configuration (used by the Seed7 compiler) might be wrong. The
configuration can be wrong also when you use a binary released
interpreter.
Strange things can happen when the Seed7 compiler is configured
wrong. E.g.: It tries to call the wrong C compiler or it does
produce C code which fails with this C compiler.
The configuration of the Seed7 compiler needs to be moved out of
the makefile(s). When the Seed7 compiler has its own configuration
process an executable of the interpreter can be released without
potential problems.
> Of course, I would personally link statically if
> at all possible, but I realize that's not probably going to happen.
This is going to happen when I find a way to configure the Seed7
compiler independent of the interpreter. I tried to replace the
makefile based configuration with a Seed7 one. For the interpreter
this leads to a chicken and egg problem, but the configuration of
the Seed7 compiler could be done this way.
> BartC> Well, I have now a file called HI.EXE. Just including that
> BartC> would have been a big help! (Of course this is specific to
> BartC> Windows, and increases the download size, but this is what
> BartC> many language downloads offer.)
>
> It's not that big, honestly, but you need the lib/*.s7i files too. UPX
> if you really want. ;-)
>
> tm> Just adding HI.EXE to the release would result in the same
> tm> problems that you have with comp.sd7. When comp.sd7 has no
> tm> information about the C compiler, the C compiler options, the C
> tm> bugs, the C runtime functions and the workarounds needed for
> tm> them it cannot do its work.
>
> TinyC/TCC works on Windows and is an extremely small download. You
> could always bundle that.
From time to time I think over bundling Seed7 with a C compiler.
But this would IMHO lose more than it wins. Currently C is used
as platform. When a C compiler is bundled the processor is the
platform. And I dont want to maintain a C compiler on several
processors and operating systems.
> I also made a one-floppy DJGPP install (GCC
> 2.95.3) with Make, but that's probably too old. But hey, if you can
> get it working, that should be easy to bundle too. Those are much more
> "minimal" than MinGW or Cygwin. But it depends on how much POSIX you
> need / expect / want (2008? mmap?).
mmap is used optionally and fork is not used, but some other POSIX
stuff is used. Since you made the one-floppy DJGPP install you have
probably much more knowledge about it. When you send me results
(like you did with the DJGPP port) I can do improvements for the
next release to make it easier.
> tm> And there is also the Danger that someone infects this executable
> tm> with a virus.
>
> You can always provide md5 or sha-1 or whatever checksums to compare
> against. There are even some .EXEs that provide their own built-in CRC
> checking to avoid viruses. Honestly, I don't think that's worth
> worrying about, just saying ....
>
> === ANNOUNCE ===
>
> Okay, so here's the real reason I'm replying. It's not much, but it
> seems to (mostly) work. I did hack up the latest Seed7 to (barely)
> compile HI.EXE interpreter. The examples that don't need weird stuff
> (windows.s7i) work, e.g. wiz. So at least some basic functionality is
> there for people to play with. Not sure you will appreciate this, but
> hey I tried.
Great work. I appreciate it.
> It's sloppy but it works. (Note that I didn't bother
> testing the compiler,
Thats also a matter of configuration (see above).
> the interpreter was more than sufficient. I was
> almost not even sure it would ever build. I think there could be
> slightly better organization, better modularization. Not saying
> AutoConf would help, but I guess you know DJGPP lacks a few things,
> e.g. UTF-8, mmap, 64-bit sized files, etc). I used a (modified) Linux
> makefile, not sure if that was best or not (MinGW probably isn't any
> easier).
Is it okay to add your makefile to the next release as mk_djgpp.mak?
When I have not time to try it I can add it to the release and
mention it as experimental makefile.
> Here's my (srcs + .o files + .EXE) built with DJGPP:
>
> http://drop.io/bsbuwco
> http://rapidshare.com/files/424908618/seed7-djgpp.7z
>
> (if neither of those two work for you, email me)
The first one worked. Maybe not everybody knows the .7z format (I
know it, but on my Linux system it was necessary to install 7Zip).
I did a diff to see your changes.
You obvously did symlinks for some *.s7i files from the seed7/prg
directory to the seed7/lib directory. This links are not necessary
when the file version.h contains
#define SEED7_LIBRARY "<< insert absolute path of seed7/lib >>"
My version.h file contains (under Linux) the line:
#define SEED7_LIBRARY "/home/tm/seed7_5/lib"
This way the interpreter will find the *.s7i include files in the
seed7/lib directory. The makefile contains commands to do this
configuration [long line broken into three lines]:
cd ../lib;
echo "#define SEED7_LIBRARY" \"`pwd`\" >> ../src/version.h;
cd ../src
The command pwd is executed and the result (the absolute path of the
seed7/lib directory) is inserted.
Since pwd does not work under Windows the makefile mk_mingw.mak
uses the program setpaths.c to set up this and other paths.
In the file fil_rtl.c (function offsetSeek) you renamed the
parameter offset to ofset. Is offset predefined? To avoid future
problems with this parameter the next release will rename it to
anOffset.
In the files kbd_inf.c, kbd_poll.c, scr_inf.c and trm_inf.c you
changed the line
#include "ncurses/term.h"
to
#include "term.h"
This is the job of INCL_NCURSES_TERM so the line
#undef INCL_NCURSES_TERM
should be enough and the changes in the 4 files are unnecessary.
The next release will add an empty function for drwGenPointList to
the file drw_dos.c . This way your change in drw_drv.h should not
be necessary.
Many thanks for your effort.
Please keep up with your work.
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.
- Raw text -