Re: Fwd: Re: Preliminary questions for sponsoring a compiler
Paul Wise schreef op 2016-07-26 07:15:
On Tue, Jul 26, 2016 at 3:01 AM, Albert van der Horst wrote:
It has been published, the generic system is GPL as well.
It is on the net since ages
http://home.hccnet.nl/a.w.m.van.der.horst/ciforth-5.0.tar.gz and
http://home.hccnet.nl/a.w.m.van.der.horst/cifgen.html
Wrong! Must be:
http://home.hccnet.nl/a.w.m.van.der.horst/ciforth.html
I doubt that any one has downloaded this in a dozen years ;-( .
I see.
Indeed not in VCS , but we should not be dogmatic about tarballs that
provide a source that is feasible to change, i.e. they are Open Source
in
actual practice.
There is a difference between "I can modify this" and "Open Source".
After all, it is possible to modify ELF binaries with a hex editor,
objdump or IDA Pro. It is possible to modify minified JavaScript using
a text editor. That doesn't make individual ELF files or minified
JavaScript files "source". The important thing is equality of access
to the work between upstream developers, Debian package maintainers,
Debian users, users of Debian derivatives and every other person
touching the software in some way. I have included here some links to
articles about what "source" or the "preferred form for modification"
is:
http://www.inventati.org/frx/essays/softfrdm/whatissource.html
https://b.mtjm.eu/source-code-data-fonts-free-distros.html
https://wiki.freedesktop.org/www/Games/Upstream/#source
As an experienced developer I'm familiar with this.
In the end it is about knowledge. The comments in my Forth solutions
to the projecteuler.net problems are worth more than the code itself.
If compilers cease to exist for a language x, the source code is
what left and represents the knowledge.
I hear you, but consider this.
Given the choice to compile c or patch an ELF file, I ( still ;-) )
prefer modifying the c-source.
There is a forth loosely based on ciforth : jonesforth.
Given the choice between using the generic system and using the
assembler source, Mr. Jones chose the assembler source.
I should have used the word separate, not private.
Ah, that is fine, as long as both are packaged for Debian and
appropriate build and runtime dependencies declared.
Do you really demand that a Debian package can generate windows
executables, and booting floppies in double density? And do you
demand to test that to a level approaching Debians (let alone mine)
quality standards?
<SNIP>
It sounds like you are automatically generating some assembler from
forth code and then hand-tweaking the assembler?
I don't tweak the assembler myself (maybe for a test). Others may, it is
a service saving them the considerable time to understand a complicated
system
in case they want something simple. Also (in contrast to gforth) it is
assembler all the way down, but some of it is an assembler
representation of Forth code.
Could you explain the development workflow here?
Let's start with the data. The knowledge to do 64 bits is contained in
width64.m4 , there is also width32.m4 and width16.m4. The knowledge to
do nasm files is contained in nasm.m4. Other assemblers have their
m4's.Last but not least linux.m4 versus msdos32.m4 versus osx.m4 versus
alonehd.m4 etc. So we have orthogonal sets of alternatives. Now these
are selected by configuration files, also interpreted by m4.
Configuration files also contain choices (e.g. "prepared for
multitasking") and sizes. A prelude sets defaults, changeable by the
configuration file. A postlude makes depending configurations and
detects conflicts. (Real mode -> 16 bits. Real mode and 32 bits -->
error).
A configuration item is an m4 function.
Then there is one generic file. Parts of it are protected by a m4
function
that decides whether or not it will show up in the output.
A configuration file, an assembler selection and the generic file are
passed through m4, to generate an assembler source, a test file, and the
glossary documentation.
(So all documentation is pertinent. It says "a cell size is 64 bits"
"you have 8 slots in the search order").
The glossary documentation is sorted by my sssort tool that can specify
records by regular expressions, then combined with the other information
that also passes through m4. texinfo takes it from there.
With all that in place development workflow is trivial:
I can add one test line in the generic file, change the name of command
>IN to PP, or change the section where a command belongs, increase the size allocated to stacks etc. , and go make stuff, up and including fitting documentation.
There is a document contained in ciforth-5.0.tar that discusses when
you
want to modify at the assembler level, and when at the generic level.
It is useful to provide both.
I assume you are talking about README.ciforth here?
You're awfully optimistic here. That is hardly more than a list of the
files
involved. The document is called cifgen.ps and is generated via the
makefile. It can be downloaded separately:
http://home.hccnet.nl/a.w.m.van.der.horst/cifgenps.zip
I do want to have this system on a public VCS. It is now in CVS
on my private server. Any advice of how to move with the history
intact is welcome.
I would suggest switching to the git VCS and a public Free Software
hosting service. git is much more popular than CVS these days and
existing hosting services are less likely to go down if you stop
working on this project for some reason.
https://en.wikipedia.org/wiki/Comparison_of_free_software_hosting_facilities
I'm more interested in recommendations of Debian developpers than those
of wiki. Surely you have by now an opinion what would be preferably
for Debian.
Then there is history. There are over a thousands meticulously
documented
versions of ci86.gnr and a couple of dozen tagged versions.
If I must leave that behind, some convincing need to be done.
Groetjes Albert
--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst
Reply to: