9front - general discussion about 9front
 help / color / mirror / Atom feed
From: kokamoto@hera.eonet.ne.jp
To: 9front@9front.org
Subject: Re: [9front] move zlib source from ghostscript to ape/lib/z and update to latest zlib
Date: Tue, 3 Mar 2020 08:08:35 +0900	[thread overview]
Message-ID: <E01F5F723D5C50F18B3E4C65F59712E0@hera.eonet.ne.jp> (raw)
In-Reply-To: 66DB1A7C7255F30439FF262EDF2F601B@felloff.net


> how did this got so bad?

I don't check that lib, however, I can image why?

I'm facing same problem now, duktape.c which is more than 3.5MB (about 100,000 lines).
This netsurf project aims to cover as many OSs and CPUs as possible, which leads
to many many #define lines, and #if define() lines...

On the other hand, Plan9 doesn't consider so, only support itself.
Then, mkfile or compilers are very simple and quick.
However, if we take this approarch, we must write our applications by ourselves.
The 2nd edition of Plan9 got this approach, and had many simple applications,
which was more than 20 years ago...

We can have two lines of way now...
I think porting applications are neccessary now, because it's only application and
it's ok if it works.   However, for libraries, we should kepp the concept of Plan9.
So, we should keep the difference between ports and contrib?

How do you think?

Kenji



             reply	other threads:[~2020-03-02 23:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-02 23:08 kokamoto [this message]
2020-03-03  0:49 ` Steve Simon
2020-03-03  1:01   ` ori
2020-03-03 10:06     ` hiro
2020-03-03 10:08     ` hiro
2020-03-03 10:12       ` hiro
2020-03-03 14:01         ` ori
2020-03-03 13:58       ` ori
  -- strict thread matches above, loose matches on Subject: below --
2020-03-03 11:05 kokamoto
2020-03-03  6:36 kokamoto
2020-03-02  5:15 Lucas Francesco
2020-03-02  8:33 ` [9front] " cinap_lenrek
2020-03-02 14:41   ` ori
2020-03-05 19:17     ` cinap_lenrek
2020-03-08 23:44       ` Lucas Francesco
2020-03-16  3:28         ` ori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E01F5F723D5C50F18B3E4C65F59712E0@hera.eonet.ne.jp \
    --to=kokamoto@hera.eonet.ne.jp \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).