Re: [9front] move zlib source from ghostscript to ape/lib/z and update to latest zlib

Re: [9front] move zlib source from ghostscript to ape/lib/z and update to latest zlib

[kokamoto]

I like the (1) way.
To follow every updated external library is worse.
This kind of topics should be discussed for individual cases, I think.

Kenji

> in general part of the beauty in plan9 is that some geniuses found
> abstractions that are so much better, that reimplementing the
> functionality the plan9 way is simpler than porting a library even
> once, which saves us 1) the work of porting it even once 2)
> maintaining a mirror image of some external bikeshedding process.
> 
> it's kind of rare that 2) or 1) alone is less work than reimplementing
> everything on plan9.
> 
> doing both 1) and 2) seem completely hopeless for most modern libraries.

Re: [9front] move zlib source from ghostscript to ape/lib/z and update to latest zlib

[ori]

> Hey Cinap, I didn't mean harm with the patches, it was my bad to
> include contrib(I had a local zlib copy lingering for weeks with those
> contrib dirs, didn't notice I still had Pascal), I think with this one
> it can be made clear what changed and what didn't.

Thanks for updating!

This patch looks easier to review, but there seems to be some binary
junk at the end of it. Can you try resending?

> This patchset doesn't move out stuff from gs for now. Most of the diff
> is on the INDEX and the Changelog files alongside the new ones. (gzio
> became 4 different files, there's a new tests dir for the tests, some
> bugfixes and a new test.)

Out of curiosity, have you tried running the tests? Might be a good
sanity check.

> Take note: I've changed the mkfile cflags on this one, they seem to be
> fine, but its up to you guys to consider it uneeded or not, I guess
> this is not final.
> 
> as for using APE or not, I'd love to see some separation/at least get
> rid of gs for page eventually, but thats a distant future.
> 
> Em qui., 5 de mar. de 2020 às 16:18, <cinap_lenrek@felloff.net> escreveu:
>>
>> what i'd like to see is an actual diff of what changed in zlib. i cannot
>> belief there are too many changes. zlib is very old library. i'm very
>> curious why we need a specific version of zlib and what features did
>> they add.
>>
>> once we have a overview what we'r getting into, then we can move it out
>> of ghostscript.
>>
>> --
>> cinap

Re: [9front] move zlib source from ghostscript to ape/lib/z and update to latest zlib

[Lucas Francesco]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

Hey Cinap, I didn't mean harm with the patches, it was my bad to
include contrib(I had a local zlib copy lingering for weeks with those
contrib dirs, didn't notice I still had Pascal), I think with this one
it can be made clear what changed and what didn't.

This patchset doesn't move out stuff from gs for now. Most of the diff
is on the INDEX and the Changelog files alongside the new ones. (gzio
became 4 different files, there's a new tests dir for the tests, some
bugfixes and a new test.)

Take note: I've changed the mkfile cflags on this one, they seem to be
fine, but its up to you guys to consider it uneeded or not, I guess
this is not final.

as for using APE or not, I'd love to see some separation/at least get
rid of gs for page eventually, but thats a distant future.

Em qui., 5 de mar. de 2020 às 16:18, <cinap_lenrek@felloff.net> escreveu:
>
> what i'd like to see is an actual diff of what changed in zlib. i cannot
> belief there are too many changes. zlib is very old library. i'm very
> curious why we need a specific version of zlib and what features did
> they add.
>
> once we have a overview what we'r getting into, then we can move it out
> of ghostscript.
>
> --
> cinap

[-- Attachment #2: zlibpatch.patch --]
[-- Type: application/octet-stream, Size: 675664 bytes --]

Re: [9front] move zlib source from ghostscript to ape/lib/z and update to latest zlib

[cinap_lenrek]

what i'd like to see is an actual diff of what changed in zlib. i cannot
belief there are too many changes. zlib is very old library. i'm very
curious why we need a specific version of zlib and what features did
they add.

once we have a overview what we'r getting into, then we can move it out
of ghostscript.

--
cinap

Re: [9front] move zlib source from ghostscript to ape/lib/z and update to latest zlib

[ori]

> in general part of the beauty in plan9 is that some geniuses found
> abstractions that are so much better, that reimplementing the
> functionality the plan9 way is simpler than porting a library even
> once, which saves us 1) the work of porting it even once 2)
> maintaining a mirror image of some external bikeshedding process.

Yes. Often, it is easier to rewrite than to port. But not always.

If we do port, I'm suggesting that we think about how to maintain it.

Re: [9front] move zlib source from ghostscript to ape/lib/z and update to latest zlib

[ori]

> but i think many libraries are
> moving too fast nowadays to track even one of them.

Perhaps those are the libraries that we should avoid porting in the first place.

Re: [9front] move zlib source from ghostscript to ape/lib/z and update to latest zlib

[hiro]

in general part of the beauty in plan9 is that some geniuses found
abstractions that are so much better, that reimplementing the
functionality the plan9 way is simpler than porting a library even
once, which saves us 1) the work of porting it even once 2)
maintaining a mirror image of some external bikeshedding process.

it's kind of rare that 2) or 1) alone is less work than reimplementing
everything on plan9.

doing both 1) and 2) seem completely hopeless for most modern libraries.

Re: [9front] move zlib source from ghostscript to ape/lib/z and update to latest zlib

[hiro]

> I think it's worth trying to change that situation, so we actually
> maintain the things we decide are worth porting.

at what cost though? i would propose creating infrastructure and
processes that make it *easier* to do, but i think many libraries are
moving too fast nowadays to track even one of them.

Re: [9front] move zlib source from ghostscript to ape/lib/z and update to latest zlib

[hiro]

> On one hand, yes -- unifdef will let you do that.  On the other hand,
> unless we make a considered choice to fork fully and actually
> *maintain*

it sounds like this is automatable, you could have a script run
checkout, pull, then unifdef and commit the diff from a 9front branch
to this with a slight addendum to the original commit message noting
this is done automatically. repeat with every new changeset as it
comes in.

downsides are sending patches back upstream, but i doubt there will be
much of those.

there might be more clever ways to do this, but this seems trivial and
sustainable to me.

Re: [9front] move zlib source from ghostscript to ape/lib/z and update to latest zlib

[kokamoto]

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

Yeah! I got compiled 3.5MB of duktape.c (100,000 lines) successfully.
The binary size is 5,315,508 bytes., which is not so big!

Kenji

Re: [9front] move zlib source from ghostscript to ape/lib/z and update to latest zlib

[ori]

> there was a program in comp.sources.unix (or maybe misc) called unifdef which would apply selective conditionals and oreserved comments. it is so old it is orobably pre andi and may not know about c++ style comments, but maybe it would help. 
> 
> itwould allow you tokeep only the os support you need - and make the code mire readable perhaps.
> 

On one hand, yes -- unifdef will let you do that.  On the other hand,
unless we make a considered choice to fork fully and actually
*maintain* a forked version of the initial code, I think it's better
to keep the sources of ported code as close to upstream as possible,
so that it's easy to import new versions and update it -- and submit
portabillity fixes to the maintainers, so we don't have to move them
along manually to new versions.

In general, plan 9 ports have the problem of being off-brand tarballs
that, to a good approximation, never get updated.

I think it's worth trying to change that situation, so we actually
maintain the things we decide are worth porting.

Re: [9front] move zlib source from ghostscript to ape/lib/z and update to latest zlib

[Steve Simon]

there was a program in comp.sources.unix (or maybe misc) called unifdef which would apply selective conditionals and oreserved comments. it is so old it is orobably pre andi and may not know about c++ style comments, but maybe it would help. 

itwould allow you tokeep only the os support you need - and make the code mire readable perhaps.

-Steve


> On 2 Mar 2020, at 11:09 pm, kokamoto@hera.eonet.ne.jp wrote:
> 
> 
>> 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

Re: [9front] move zlib source from ghostscript to ape/lib/z and update to latest zlib

[kokamoto]

> 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

Re: [9front] move zlib source from ghostscript to ape/lib/z and update to latest zlib

[ori]

> this diff is 2MB of text! that is just insane. how are we going
> to maintain this? i cannot review 2MB of code.
> 
> all the files of zlib in ghostscript is only 525k and arround
> 13kloc... why is there a z/contrib? why are we importing pascal
> and ada files?
> 

We should get rid of all the contrib/ dir -- it's not being built, and nothing in it is
needed. What's left is still 13k loc.

Re: [9front] move zlib source from ghostscript to ape/lib/z and update to latest zlib

[cinap_lenrek]

this diff is 2MB of text! that is just insane. how are we going
to maintain this? i cannot review 2MB of code.

all the files of zlib in ghostscript is only 525k and arround
13kloc... why is there a z/contrib? why are we importing pascal
and ada files?

how did this got so bad?

--
cinap