Re: [Tinycc-devel] What is your general workflow in answering to mailing list thread?

2020-12-25 Thread Michael Matz

Hello,

On Sat, 26 Dec 2020, Michael Matz wrote:


c) no top-posting [1], no full-quoting if answering to only some parts,


And obviously I could use an email client that asked me that, if I had 
used something like "[1]" to reference a foot note, and then not 
actually put in a foot note in the mail text, this was not just forgotten 
:)


So, maybe a next rule would be: e) read your text before sending :)

That foot note was supposed to be this:

[1]
This is why top posting is so bad (in top posting order):

 A: Because it messes up the order in which people normally read text.
 Q: Why is top-posting such a bad thing?
 A: Top-posting.
 Q: What is the most annoying thing in e-mail?


Ciao,
Michael.

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


Re: [Tinycc-devel] What is your general workflow in answering to mailing list thread?

2020-12-25 Thread Michael Matz

Hello,

On Fri, 25 Dec 2020, Vaidas BoQsc wrote:


What is the proper way to quote and reply in a Mailing List? Thanks.
I just noticed that instead of replying, I created a new thread.


Thank you for asking.  Generally the usual netiquette rules should be 
obeyed, but we don't need to be too obsessive about them as the size of 
this list is small.  Googling for mailing list netiquette will give you 
various answers, from relaxed to much too strict, but commonalities would 
be:


a) No HTML-only mails (of possible without HTML content, but multi-part
   with non-html is okayish)
b) readable with mono-space font
c) no top-posting [1], no full-quoting if answering to only some parts,
   quote with '> ' prefixed lines
d) 72 characters line width


As an average, I use in-browser Google Mail.
Do I need a Mail Client to have a better experience with Mailing Lists?  


Ugh, let's hope this doesn't transform into a flame-war of 
best-email-clients ;)


gmail is probably the best in-browser client, but still fairly bad as far 
as mail clients go; I'm not sure how much of the badness can be configured 
away.  I'm not a GUI user myself, so can't really suggest anything from 
own experience, but reasonable mails seem to be produced by Thunderbird 
users.  If the settings allow to send text-only mails and a mono-space 
font and do quoting in classic '> bla' style it's going to be fine.



Do you happen to do any manual message formatting work while replying?


(FWIW, I'm using alpine, and the only formatting I regularly use is to 
justify whole text paragraphs to the text width that they don't look too 
jiggly)



Ciao,
Michael.___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


Re: [Tinycc-devel] tinycc manpage

2020-12-25 Thread Michael Matz

Hello,

On Fri, 25 Dec 2020, Sudipto Mallick wrote:


When I compiled a recent version of tinycc from mob, I looked at the
source of the manpage. I don't like it.


In which sense?  tcc.1 is a generated file, it's not supposed to be 
edited.  The source is tcc-doc.texi, i.e. texinfo, via texi2pod and 
pod2man.  So, are you sure you're barking at the right tree?


I learnt about the mdoc(7) format for writing man pages and thought to 
use that format for the tcc man page. The rewrite is attached.


While -mdoc certainly is nicer than -man it's both trumped (IMHO) by 
perlpod and texinfo, in writability.



What do you think about this mdoc formatted manual page?


I think it's nicer than the current generated tcc.1 file, and I think it's 
somewhat more purist to directly write mdoc files for a project like TCC, 
instead of generating them.  But I also think that something like this 
needs to be easy to write/edit, and in this case I'd argue that texinfo is 
just fine.


This is not yet complete (see TODOs). Please give suggestion to complete 
it.



Ciao,
Michael.

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


Re: [Tinycc-devel] What is your general workflow in answering to mailing list thread?

2020-12-25 Thread Anton Shepelev
Vaidas BoQsc:

> What is the proper way to quote and reply in a Mailing
> List?

See Netiquette for the basic guidelines:

   https://tools.ietf.org/html/rfc1855

> As an average, I use in-browser Google Mail.

That is not a decent e-mail client, it is terrible.

> Do I need a Mail Client to have a better experience with
> Mailing Lists?

I should say yes. A decent, well-configured mail client is a
game changer. For basic requirements for a mail client, see:

   https://jdebp.eu/Proposals/gnksoa-mua.html

> Do you happen to do any manual message formatting work
> while replying?

I format all my message with the GNU Troff text-proessing
facility, but a good e-mail client will do it for you, so do
not worry :-)


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


Re: [Tinycc-devel] tinycc manpage

2020-12-25 Thread Anton Shepelev
Sudipto Mallick:

> When I compiled a recent version of tinycc from mob, I
> looked at the source of the manpage. I don't like it.

What did not you like?

> I learnt about the mdoc(7) format for writing man pages
> and thought to use that format for the tcc man page. The
> rewrite is attached.

The processed result is attached. While processing, GNU
Troff reported the following warnings:

   mdoc warning: A .Bl directive has no matching .El (#287)
   mdoc warning: Empty input line #376
   mdoc warning: Empty input line #387
   mdoc warning: Empty input line #392
   mdoc warning: Empty input line #394
   mdoc warning: Empty input line #409

> What do you think about this mdoc formatted manual page?

I disike lines longer than 78 characters and lack of
vertical spacing between logical sections. You can do them
like this:

   end of previous secgtion
   .
   .Sh SYNOPSIS
   .
   text text text.

> Please give suggestion to complete it.

I personally prefer the original -man package to -mdoc...
TCC(1)BSD General Commands Manual   TCC(1)

NAME
 tcc -- Tiny C Compiler

SYNOPSIS
 tcc [options] [infile1 infile2 ...] [-run infile args ...]

DESCRIPTION
 Tiny C Compiler is a lightweight and fast C compiler.  Unlike other C
 compilers, it can run programs directly from memory without generating
 executable files, almost like scripting languages!  tcc runs on Linux,
 Windows, macOS, FreeBSD, NetBSD and OpenBSD operating systems.  tcc can
 compile C code for i386, x86_64, arm, arm64 and riscv64 architectures.

OPTIONS
   General options
 -c  Generate an object file.

 -o outfile
 Put object file, executable, or dll into output file outfile.

 -run source [args ...]
 Compile file source and run it with the command line arguments
 args.  In order to be able to give more than one argument to a
 script, several tcc options can be given after the -run option,
 separated by spaces:
   tcc "-run -L/usr/X11R6/lib -lX11" ex4.c
 In a script, it gives the following header:
   #!/usr/local/bin/tcc -run -L/usr/X11R6/lib -lX11

 -v  Display TCC version.

 -vv Show included files. As sole argument, print search dirs.  -vvv
 shows too.

 -bench  Display compilation statistics.

   Preprocessor options
 -Idir   Specify an additional include path. Include paths are searched in
 the order they are specified.

 System include paths are always searched after. The default sys-
 tem include paths are: /usr/local/include, /usr/include and
 PREFIX/lib/tcc/include.  (PREFIX is usually /usr or /usr/local).

 -Dsym[=val]
 Define preprocessor symbol `sym' to `val'.  If `val' is not pre-
 sent, its value is `1'.  Function-like macros can also be
 defined: `-DF(a)=a+1'

 -Usym   Undefine preprocessor symbol `sym'.

 -E  Preprocess only, to stdout or file (with -o).

   Compilation flags
 Note: each of the following options has a negative form beginning with
 -fno-.

 -funsigned-char
 Let the char type be unsigned.

 -fsigned-char
 Let the char type be signed.

 -fno-common
 Do not generate common symbols for uninitialized data.

 -fleading-underscore
 Add a leading underscore at the beginning of each C symbol.

 -fms-extensions
 Allow a MS C compiler extensions to the language. Currently this
 assumes a nested named structure declaration without an identi-
 fier behaves like an unnamed one.

 -fdollars-in-identifiers
 Allow dollar signs in identifiers.

   Warning options
 -w  Disable all warnings.
 Note: each of the following warning options has a negative form beginning
 with -Wno-.

 -Wimplicit-function-declaration
 Warn about implicit function declaration.

 -Wunsupported
 Warn about unsupported GCC features that are ignored by TCC.

 -Wwrite-strings
 Make string constants be of type const char * instead of char *.

 -Werror
 Abort compilation if warnings are issued.

 -Wall   Activate all warnings, except -Werror, -Wunusupported and
 -Wwrite-strings.

   Linker options
 -Ldir   Specify an additional static library path for the -l option.  The
 default library paths are /usr/local/lib, /usr/lib and /lib.

 -lname  Link your program with dynamic library libname.so or static
 library libname.a.  The library is searched in the paths speci-
 fied by the -L option and LIBRARY_PATH variable.

 -Bdir   Set the path where the tcc internal libraries (and include files)
 can be found (default is PREFIX/lib/tcc).

 -shared
 Generate a shared 

[Tinycc-devel] tinycc manpage

2020-12-25 Thread Sudipto Mallick
When I compiled a recent version of tinycc from mob, I looked at the
source of the manpage. I don't like it. I learnt about the mdoc(7)
format for writing man pages and thought to use that format for the
tcc man page. The rewrite is attached.

What do you think about this mdoc formatted manual page?

This is not yet complete (see TODOs). Please give suggestion to complete it.


tcc.1
Description: Binary data
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


[Tinycc-devel] What is your general workflow in answering to mailing list thread?

2020-12-25 Thread Vaidas BoQsc
What is the proper way to quote and reply in a Mailing List? Thanks.
I just noticed that instead of replying, I created a new thread.

As an average, I use in-browser Google Mail.
Do I need a Mail Client to have a better experience with Mailing Lists?

Do you happen to do any manual message formatting work while replying?
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


Re: [Tinycc-devel] Almost added a feature, but I broke things

2020-12-25 Thread NA via Tinycc-devel
Thank you Kyryl for the amalgama code and the notes, really good stuff! 
I'll have fun playing with this over the holidays


On 24/12/2020 18:21, Kyryl Melekhin wrote:

https://raw.githubusercontent.com/kyx0r/klec/master/utils/tinycc.c

on x86_64 linux compile like so gcc tinycc.c -ldl -lpthread
then you can use it like so:

if the project already has something resembling a unity build:
a.out -E file1.c > file2.c

if the project does incremental build:
use cat on every C file in correct order ignore the headers.
cat *.c > file1.c
a.out -E file1.c > file2.c


To better understand how it works I recommend to try it on tcc
code base first. Tcc code actually is layed out in an easy format
despite make forcing the incremental build.
a.out -E tcc.c > tinycc.c
This current version the result should amount to approx 87K loc

Some comments:
1. If the headers in C source are not guarded properly
it will not work, but so will your project not compile also. So
this does not happen. Header exclusion works the same way a compiler
would exclude it.
2. Problem of amalgamation is not as trivial as you think it might be,
because of the nature of how C works your header might be guarded but
you can also have code outside of that guard, in any case my program will
exclude the code properly. Especially that #endif is used to terminate any kind
of preprocessing expression.
3. By default headers with <> (system headers) are not amalgamated.
You can enable that, just read the source code in tcc_preprocess.
This program is powered by strategically placing printfs inside tcc
and some compiler logic changes of the default option -E, so don't try
to use this tcc for anything except what is meant to be.
4. While in most cases the resulting file will compile, some projects might be
weird and still require some manual tweaks and edits. Also you might need
to spend some time to clean the code from extra newlines that might get
created.
5. You can also configure it in source code to instead of processing everything
actually do the preprocess and exclude all the unnecessary junk, so for example
with that tcc source for x64 linux will be about ~35K instead of 87K.

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel