Re: Preliminary questions for sponsoring a compiler

[Jakub Wilk]

* Paul Wise , 2016-07-30, 15:16:
I myself use Alioth, Savannah, SourceForge, GitHub and LaunchPad for 
different projects. There are no hosting facilities that I personally 
like, mostly because they are all web services.


There are many command-line tools that let you distance yourself from 
the webby nature of GitHub. This is what I use:


cligh
git-hub
github-backup
grip
https://github.com/c4milo/github-release
https://github.com/jwilk/github-editmeta

--
Jakub Wilk

Re: Fwd: Re: Preliminary questions for sponsoring a compiler

[Paul Wise]

On Tue, Jul 26, 2016 at 8:57 PM, Albert van der Horst wrote:

> Do you really demand that a Debian package can generate windows
> executables, and booting floppies in double density?

We already have tested and working GCC cross-compilers for Windows.

https://packages.debian.org/search?keywords=mingw

I don't think Debian supports floppies at this point.

> 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.
...
> 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.
...
> 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

That is a lot to digest, thanks for the comprehensive explanation.

FYI, we have nasm in Debian too:

https://packages.debian.org/nasm

If you place the source* into a public version control system and
create release tarballs from those, that satisfies Debian's
requirements.

*ci86.gnr, the *.m4 files, the *.cfg files, the make files and any
other generic source files I have forgotten.

Please also release the source code for ssort somewhere, either as
part of ciforth or if you are developing it as a separate project, in
a separate git/cvs repository. The current release tarball for ssort
only has an ELF binary, which I assume is not the source for it.

In addition, I would recommend that any Debian packaging *always*
rebuild all automatically generated files (including the .asm files),
by removing them at the beginning of the `debian/rules build` stage of
the build and relying on the upstream build system to regenerate them.
This means that the Debian build process proves that Debian (and our
users etc) has the ability to build from source.

> 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.

I myself use Alioth, Savannah, SourceForge, GitHub and LaunchPad for
different projects. There are no hosting facilities that I personally
like, mostly because they are all web services. Debian itself uses
FusionForge on alioth.d.o, but that is for Debian related projects
rather than upstream development. World-wide, GitHub is relatively new
and the most popular, but it is a proprietary, for-profit service.
Debian folks tend to use Alioth or Github.

> 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.

I certainly would not recommend dropping the history.
The options here are to host the CVS repository publicly or
to convert the CVS repository to a git repository:

https://git-scm.com/docs/git-cvsimport
https://www.kernel.org/pub/software/scm/git/docs/gitcvs-migration.html
http://cvs2svn.tigris.org/cvs2git.html
https://github.com/BartMassey/parsecvs

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Fwd: Re: Preliminary questions for sponsoring a compiler

[Albert van der Horst]

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?



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:

Re: Fwd: Re: Preliminary questions for sponsoring a compiler

[Paul Wise]

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
>
> 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

> 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.

> Let us keep in mind why we want open source. The freedom to add e.g. an
> ``unsigned less than or equal comparison'' to lina is better served by
> an assembler source. It is actually doable by a moderately skilled
> assembler programmer. ( Compare this with tinkering with GNU c by the
> way. I have once modified GNU c to change the calling convention
> for 68000 assembler code. Not for the faint of heart.)

Hmm, that sounds more complicated than what I am used to: a "source"
form of the work in the upstream tarball and files automatically
generated from that in the Debian binary package.

It sounds like you are automatically generating some assembler from
forth code and then hand-tweaking the assembler?

Could you explain the development workflow here?

> 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?

> This is partly based on experience. In the 70's Forth systems were
> generated by existing Forth systems. This didn't spread well, and only the
> high priest of Forth could generate a system. It was not  until
> the systems were translated to assembler source that were widely
> understood and could be build by widely available tools, that lead to the
> Forth boom in early personal computing.(The famous FIG-Forth)

That sounds suboptimal indeed.

> 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

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Preliminary questions for sponsoring a compiler

[Christian Seiler]

On 07/25/2016 09:28 PM, Albert van der Horst wrote:
> Christian Seiler schreef op 2016-07-25 18:14:
>> I don't quite get what you mean, I never had any problem with
>> that.
> 
> {Probably going off topic here]
> A pure assembler file means full control over section names, their
> properties (in particular, readable, writable *and* executable) and
> where they are located. My compilation feature requires a stable
> layout for the ELF header.

Ah, ok, I didn't know you'd want that much control. Personally
I tend to rely on relocations and ld resolving stuff for me,
so I don't really care about the detailed ELF file layout, even
when using assembler. But if that doesn't fit your use case,
then yeah, GNU ld is probably not what you want.

> By the way write.s gives me  `` bad register name `%rax' ''

Well, then your gcc is probably not x86_64 by default. ;-)
Since assembler is different for every processor, I just took
the most obvious architecture I know.

Regards,
Christian

Re: Preliminary questions for sponsoring a compiler

[Albert van der Horst]

Christian Seiler schreef op 2016-07-25 18:14:

On 07/25/2016 02:51 PM, Albert van der Horst wrote:

The problem is: ld is not stable w.r.t. linking pure assembler files.


How so?

$ cat write.s
.text

.global _start
.type   _start, @function

_start:
mov $1, %rax
mov %rax, %rdi
lea str, %rsi
mov strsize, %rdx
syscall
xor %rdi, %rdi
mov $60, %rax
syscall

.data
str:
.string "Hello World!\n"
strsize:
.quad   .-str
$ gcc -Wall -c -o write.o write.s && ld -o write write.o
$ ./write
Hello World!
$ strace ./write
execve("./write", ["./write"], [/* 58 vars */]) = 0
write(1, "Hello World!\n\0", 14Hello World!
)= 14
_exit(0)= ?
+++ exited with 0 +++
$ cat write-nasm.s
section .text
global  _start

_start:
mov rax, 0x1
mov rdi, rax
lea rsi, [hello]
mov rdx, length
syscall
xor edi, edi
mov rax, 60
syscall


section .data
hello   db  'Hello World!', 10, 0
length  equ $ - hello
$ nasm -f elf64 -o write-nasm.o write-nasm.s
$ ld -o write-nasm write-nasm.o
$ ./write-nasm
Hello World!
$ strace ./write-nasm
execve("./write-nasm", ["./write-nasm"], [/* 58 vars */]) = 0
write(1, "Hello World!\n\0", 14Hello World!
)= 14
_exit(0)= ?
+++ exited with 0 +++

I don't quite get what you mean, I never had any problem with
that.


{Probably going off topic here]
A pure assembler file means full control over section names, their 
properties (in particular, readable, writable *and* executable) and 
where they are located. My compilation feature requires a stable layout 
for the ELF header.
 gcc and ld are intended for c and if you try to do the things I want, 
it feels like remote controlling a robot that must drive a car.


I will not bore you with all the details. One detail, .text and .data 
have predefined properties. Now look how many options ld has. One is 
appropriate

called -nmagic . It sometimes helps to turn those properties around,
at other times it failed.

By the way write.s gives me  `` bad register name `%rax' ''



Regards,
Christian


Groetjes Albert

--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst

Re: Fwd: Re: Preliminary questions for sponsoring a compiler

[Albert van der Horst]

Albert van der Horst schreef op 2016-07-25 18:00:

 Oorspronkelijke bericht 
Onderwerp: Re: Preliminary questions for sponsoring a compiler
Datum: 2016-07-25 16:15
Afzender: Paul Wise <p...@debian.org>
Ontvanger: Albert van der Horst <alb...@spenarnc.xs4all.nl>

Not sure why you moved the discussion off-list, in Debian we prefer to
discuss things in public. Feel free to forward my reply to -mentors.


That was a mistake. Like you can see I forwarded it.



On Mon, 2016-07-25 at 15:58 +0200, Albert van der Horst wrote:


My (upstream) build system is complicated and sophisticated.
It generates booting, msdos, windows dpmi, windows 32, OSX, linux 
compilers in 16 32 and 64 bit from the same source file, together 
with 

fitting documentation and tests. Hardly something to throw over the 
> wall.


Sounds useful to publish to me.


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

I doubt that any one has downloaded this in a dozen years ;-( .




The assembler files are merely intermediate files here.


Then they are not source code, not the preferred form for modification
and should not be included in the upstream VCS and tarballs.


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.





lina (for the moment) is limited to x86 architectures (32 and 64) as
well. ARM lina is under way, but the nature of lina requires
adaptation for each architecture anyway. Do you really mean there are
ways to build assembler projects that are agnostic of architecture?


I'm not sure about that, but there are certainly assemblers available
that run on multiple architectures. nasm for example.


So my conclusion is that I'll supply a public build system and keep
the remainder private.


That sounds very much not anything like open source software to me,
please put the entirety of your upstream source code
into a public project and VCS.


I should have used the word separate, not private.

Let us keep in mind why we want open source. The freedom to add e.g. an 
``unsigned less than or equal comparison'' to lina is better served by

an assembler source. It is actually doable by a moderately skilled
assembler programmer. ( Compare this with tinkering with GNU c by the
way. I have once modified GNU c to change the calling convention
for 68000 assembler code. Not for the faint of heart.)
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.

This is partly based on experience. In the 70's Forth systems were
generated by existing Forth systems. This didn't spread well, and only 
the high priest of Forth could generate a system. It was not  until

the systems were translated to assembler source that were widely
understood and could be build by widely available tools, that lead to 
the Forth boom in early personal computing.(The famous FIG-Forth)


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.



Perhaps this document will clear things up:

http://mentors.debian.net/intro-maintainers

As upstream, you may also want to take a look at this:

https://wiki.debian.org/UpstreamGuide


You will hear more after I have studied those.

--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst

Re: Preliminary questions for sponsoring a compiler

[Christian Seiler]

On 07/25/2016 02:51 PM, Albert van der Horst wrote:
> The problem is: ld is not stable w.r.t. linking pure assembler files.

How so?

$ cat write.s
.text

.global _start
.type   _start, @function

_start:
mov $1, %rax
mov %rax, %rdi
lea str, %rsi
mov strsize, %rdx
syscall
xor %rdi, %rdi
mov $60, %rax
syscall

.data
str:
.string "Hello World!\n"
strsize:
.quad   .-str
$ gcc -Wall -c -o write.o write.s && ld -o write write.o
$ ./write
Hello World!
$ strace ./write
execve("./write", ["./write"], [/* 58 vars */]) = 0
write(1, "Hello World!\n\0", 14Hello World!
)= 14
_exit(0)= ?
+++ exited with 0 +++
$ cat write-nasm.s
section .text
global  _start

_start:
mov rax, 0x1
mov rdi, rax
lea rsi, [hello]
mov rdx, length
syscall
xor edi, edi
mov rax, 60
syscall


section .data
hello   db  'Hello World!', 10, 0
length  equ $ - hello
$ nasm -f elf64 -o write-nasm.o write-nasm.s
$ ld -o write-nasm write-nasm.o
$ ./write-nasm
Hello World!
$ strace ./write-nasm
execve("./write-nasm", ["./write-nasm"], [/* 58 vars */]) = 0
write(1, "Hello World!\n\0", 14Hello World!
)= 14
_exit(0)= ?
+++ exited with 0 +++

I don't quite get what you mean, I never had any problem with
that.

Regards,
Christian

Fwd: Re: Preliminary questions for sponsoring a compiler

[Albert van der Horst]

 Oorspronkelijke bericht 
Onderwerp: Re: Preliminary questions for sponsoring a compiler
Datum: 2016-07-25 16:15
Afzender: Paul Wise <p...@debian.org>
Ontvanger: Albert van der Horst <alb...@spenarnc.xs4all.nl>

Not sure why you moved the discussion off-list, in Debian we prefer to
discuss things in public. Feel free to forward my reply to -mentors.

On Mon, 2016-07-25 at 15:58 +0200, Albert van der Horst wrote:


My (upstream) build system is complicated and sophisticated.
It generates booting, msdos, windows dpmi, windows 32, OSX, linux 
compilers in 16 32 and 64 bit from the same source file, together with 
fitting documentation and tests. Hardly something to throw over the 
> wall.


Sounds useful to publish to me.


The assembler files are merely intermediate files here.


Then they are not source code, not the preferred form for modification
and should not be included in the upstream VCS and tarballs.


lina (for the moment) is limited to x86 architectures (32 and 64) as
well. ARM lina is under way, but the nature of lina requires
adaptation for each architecture anyway. Do you really mean there are
ways to build assembler projects that are agnostic of architecture?


I'm not sure about that, but there are certainly assemblers available
that run on multiple architectures. nasm for example.


So my conclusion is that I'll supply a public build system and keep
the remainder private.


That sounds very much not anything like open source software to me,
please put the entirety of your upstream source code and build system
into a public project and VCS.


The GNU c-compiler is prebuilt, in order to compile main. Likewise I
can only build lina with lina if I supply a prebuilt lina.
So I interpret that as no, the GNU c-compiler has a monopoly to the
prebuilt case.


No, the GNU c-compiler source code tarball does not contain a pre-built
copy of itself. I guess it does require itself to build though, which
is fine but different to containing a built copy of itself.


I understand now that there must be a maintainer and a sponsor.
I would gladly be the maintainer of the package, but I thought that
makes me one of the debian developers, an elite group with
restricted membership? How do I apply? Also I'll need a lot of help.


Perhaps this document will clear things up:

http://mentors.debian.net/intro-maintainers

As upstream, you may also want to take a look at this:

https://wiki.debian.org/UpstreamGuide

--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst

signature.asc
Description: PGP signature

Fwd: Re: Preliminary questions for sponsoring a compiler

[Albert van der Horst]

I didn't mean to put this off list, my bad.

 Oorspronkelijke bericht 
Onderwerp: Re: Preliminary questions for sponsoring a compiler
Datum: 2016-07-25 15:58
Afzender: Albert van der Horst <alb...@spenarnc.xs4all.nl>
Ontvanger: Paul Wise <p...@debian.org>

Paul Wise schreef op 2016-07-25 15:12:

On Mon, Jul 25, 2016 at 8:51 PM, Albert van der Horst wrote:


Question 1: Am I obliged to supply a .s file and linking prescripts?


You need to supply the upstream source code and build system. If those
are the upstream source code and build system, then yes.


My (upstream) build system is complicated and sophisticated.
It generates booting, msdos, windows dpmi, windows 32, OSX, linux 
compilers in 16 32 and 64 bit from the same source file, together with 
fitting documentation and tests. Hardly something to throw over the 
wall.


The assembler files are merely intermediate files here. From there
it is smooth sailing, a build is a one-liner.




(Because fasm is not in main)


fasm is in main:

https://tracker.debian.org/pkg/fasm


The problem is: ld is not stable w.r.t. linking pure assembler files.


That is a shame because fasm is limited to x86 architectures. If there
are alternative tools that can be used to build lina then that would
be a good idea.


lina (for the moment) is limited to x86 architectures (32 and 64) as 
well.
ARM lina is under way, but the nature of lina requires adaptation for 
each architecture anyway.

Do you really mean there are ways to build assembler projects that are
agnostic of architecture?

So my conclusion is that I'll supply a public build system and keep the
remainder private.




I could supply an assembler file that can be build using the build-in
assembler of lina. Does that count as "not require a package outside 
of main

for compilation", the situation being about the same like the GNU
c-compiler?


That counts as suitable for main, as long as it is not pre-built.


The GNU c-compiler is prebuilt, in order to compile main. Likewise I
can only build lina with lina if I supply a prebuilt lina.
So I interpret that as no, the GNU c-compiler has a monopoly to the
prebuilt case.

Question 2: Are there  any mentors that would even consider a compiler 
that
is in competition with GCC, rather than a second generation compiler 
like

Python Perl and the rest, that depend on GCC? Irrespective of merits?
(On the upside, dear mentor, this will be some of the simplest 
packages you

will ever encounter. ).


There are people who will sponsor any package that is suitable for
Debian. Finding someone to create the package in the first place is
harder than finding a sponsor at this point in time. The package
maintainer could be you though.


I understand now that there must be a maintainer and a sponsor.
I would gladly be the maintainer of the package, but I thought that
makes me one of the debian developers, an elite group with
restricted membership? How do I apply? Also I'll need a lot of help.



Yes, I know there is an official GNU Forth compiler gforth. An 
important

difference is that a package built with lina  requires lina for
building only, not for running. An alternative build with lina for 
e.g.
``factor'' 2] is as simple as the factor build in C, one executable, 
one

man-page.


That seems like a reasonable reason to package lina.


Glad that you understand the argument, that I honestly think to be 
valid.


Groetjes Albert

--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst

Re: Preliminary questions for sponsoring a compiler

[Paul Wise]

On Mon, Jul 25, 2016 at 8:51 PM, Albert van der Horst wrote:

> Question 1: Am I obliged to supply a .s file and linking prescripts?

You need to supply the upstream source code and build system. If those
are the upstream source code and build system, then yes.

> (Because fasm is not in main)

fasm is in main:

https://tracker.debian.org/pkg/fasm

> The problem is: ld is not stable w.r.t. linking pure assembler files.

That is a shame because fasm is limited to x86 architectures. If there
are alternative tools that can be used to build lina then that would
be a good idea.

> Or is it sufficient to supply .s and let the builder figure out
> how to make an executable? 1]

Our building is automatic and based on the upstream build system.

> I could supply an assembler file that can be build using the build-in
> assembler of lina. Does that count as "not require a package outside of main
> for compilation", the situation being about the same like the GNU
> c-compiler?

That counts as suitable for main, as long as it is not pre-built.

> If I got a sponsor, I need only supply an upstream package and the sponsor
> takes care of the rest? He will prompt me for any changes to be made in
> order to comply?

The Debian package maintainer takes the upstream code and build system
and wraps it such that the standard debian/rules targets are mapped to
upstream build system targets. Who the package maintainer is depends
on who has the interest, time and skills to create the packaging. Any
package maintainer should maintain a good relationship with upstream,
passing patches and bugs etc to them.

> Question 2: Are there  any mentors that would even consider a compiler that
> is in competition with GCC, rather than a second generation compiler like
> Python Perl and the rest, that depend on GCC? Irrespective of merits?
> (On the upside, dear mentor, this will be some of the simplest packages you
> will ever encounter. ).

There are people who will sponsor any package that is suitable for
Debian. Finding someone to create the package in the first place is
harder than finding a sponsor at this point in time. The package
maintainer could be you though.

> Yes, I know there is an official GNU Forth compiler gforth. An important
> difference is that a package built with lina  requires lina for
> building only, not for running. An alternative build with lina for e.g.
> ``factor'' 2] is as simple as the factor build in C, one executable, one
> man-page.

That seems like a reasonable reason to package lina.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Preliminary questions for sponsoring a compiler

[Albert van der Horst]

Dear mentors,
Since 2002 lina is a stable Forth compiler under x86 linux (And 
compatible compilers available for OSX, win32 ).
From the beginning  it has been  fully documented using texinfo, plus a 
man-page, that documents the options and a judicious excerpt.


lina page
http://home.hccnet.nl/a.w.m.van.der.horst/lina.html
Tutorial
https://forth.hcc.nl/w/Ciforth/Ciforth?setlang=en

Now I'm planning to supply some actually useful packages as .deb in 
debian made with this  compiler.
(In fact flashers for microcontrollers in behalf of i.a. 
http://home.hccnet.nl/anij/nof/noforth.html)

The first thing is probably find a mentor for lina itself.

The compiler is hardly mainstream:
1. It is written in assembler.
2. It is at the same time an interactive system, a scripter and a 
compiler.

3. It is totally self contained, doesn't link to any library.
4. It has its own library, but that is a source library.
5. It uses the library and the executable for configuration, no shell
variables. You configure it by copying bin+lib to a project directory 
and change those (and yes,they are small).


Making it is simple:
fasm lina64.fas lina64

I aspire lina to be in main of debian.

I see the guidelines:
"
For the mainsection, Debian Policy requires it
to be fully compliant with the Debian Free Software
Guidelines(DFSG(http://www.debian.org/social_contract#guidelines
) ) and
not to require a package outside of  main for compilation or execution. 
This is the desired case.

"

Not so simple is building it with gas, and ld.

Question 1: Am I obliged to supply a .s file and linking prescripts?
(Because fasm is not in main)
The problem is: ld is not stable w.r.t. linking pure assembler files.
Or is it sufficient to supply .s and let the builder figure out
how to make an executable? 1]
I could supply an assembler file that can be build using the build-in
assembler of lina. Does that count as "not require a package outside of 
main
for compilation", the situation being about the same like the GNU 
c-compiler?

OR:
If I got a sponsor, I need only supply an upstream package and the 
sponsor

takes care of the rest? He will prompt me for any changes to be made in
order to comply?

Question 2: Are there  any mentors that would even consider a compiler 
that is in competition with GCC, rather than a second generation 
compiler like Python Perl and the rest, that depend on GCC? Irrespective 
of merits?
(On the upside, dear mentor, this will be some of the simplest packages 
you will ever encounter. ).


For those who wonder:

Yes, I know there is an official GNU Forth compiler gforth. An important 
difference is that a package built with lina  requires lina for
building only, not for running. An alternative build with lina for e.g. 
``factor'' 2] is as simple as the factor build in C, one executable, one 
man-page.


lina scripts have been proposed in a webserver. A sub ms startup time
 makes some applications practical.

http://lina.minimaltype.com

Groetjes Albert

--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst

1] My actual build system is assembler-blind, and word-size agnostic
so no sweat for gas, nasm or fas formats that are actually intermediate
files.

2]

-~
$ cat factor.frt
WANT SQRT

: main 1 ARG[] EVALUATE  DUP . ": " TYPE
   DUP SQRT 1+ 2 DO
  BEGIN DUP I MOD 0= WHILE I . I / REPEAT
   LOOP . CR ;
~$ lina -c factor.frt
~$ time ./factor 111
111 : 3 37

real0m0.001s
user0m0.000s
sys 0m0.000s

-