Gzip and News_Comment
Dave Freeman
should be useful. One will enable use of the gzip archiver for your news
feed. Actually, it could also be used for just about any archiver I guess.
At this stage, it is only for incoming news files. Out going news is still
in compress format.
The other file is useful for those of us who like looking at the news files
in a directory util. It adds the contents of a line of each news article
header to the comment line. It will add a line based on a command line
search criteria - it could add the Newsgroups: line, or Subject: or Keyword:
or any other line that exists in the header.
Anyway, hope you get some use out of them. If you have any problems or bug
reports please mail them to me.
--
| Dave Freeman | FIDONet: 3:640/535 |
| The Ice Cave | AmigaNet: 41:400/533, /535 |
| Cairns, Qld | Usenet: dfre...@icecave.apana.org.au |
| Australia | BBS Phone: +61-70-31-4186, -4020 |
Michael B. Smith
> I have just posted a couple of new files to alt.sys.amiga.uucp.patches which
> should be useful. One will enable use of the gzip archiver for your news
> feed. Actually, it could also be used for just about any archiver I guess.
> At this stage, it is only for incoming news files. Out going news is still
> in compress format.
FYI, I've got a RNEWS in test that supports alternate archiving formats.
Primarily for gzip (via funbatch/zunbatch).
--
// Michael B. Smith
\X/ m...@adastra.cvl.va.us -or- uunet.uu.net!virginia.edu!adastra!mbs
Russell Donaldson
[ ------ stuff deleted ------------- ]
: FYI, I've got a RNEWS in test that supports alternate archiving formats.
: Primarily for gzip (via funbatch/zunbatch).
: --
: // Michael B. Smith
: \X/ m...@adastra.cvl.va.us -or- uunet.uu.net!virginia.edu!adastra!mbs
Is there any reason why Amiga GZip could not be posted to a.s.a.patches;
if it to be used as a defacto standard for this form of archiving ?
--
+ Russell A Donaldson - Wanganui New Zealand Ph +64-6-344-2275 +
+ russ...@radical.amigans.gen.nz | Life is too short to drink bad wine +
Dave Freeman
>FYI, I've got a RNEWS in test that supports alternate archiving formats.
>Primarily for gzip (via funbatch/zunbatch).
Oh, goodie. I looked at having my scripts running in place of RNews instead
of before uuxqt but it basically came down to the need for AREXX to run
scripts as 'rx gzip.rexx' so there was no simple way to have it run as rnews
in the correct place. I decided instead to pre-process the news files and
unarchive them before anything else touched them. Then when uuxqt called
rnews it would find the news files in ascii format and could work with them
just fine.
I look forward to seeing your efforts released. It looks like you have
probably got a more efficient method going.
Dave Freeman
>FYI, I've got a RNEWS in test that supports alternate archiving formats.
>Primarily for gzip (via funbatch/zunbatch).
Oh, goodie. I looked at having my scripts running in place of RNews instead
of before uuxqt but it basically came down to the need for AREXX to run
scripts as 'rx gzip.rexx' so there was no simple way to have it run as rnews
in the correct place. I decided instead to pre-process the news files and
unarchive them before anything else touched them. Then when uuxqt called
rnews it would find the news files in ascii format and could work with them
just fine.
I look forward to seeing your efforts released. It looks like you have
probably got a more efficient method going.
Michael Smith
> Is there any reason why Amiga GZip could not be posted to a.s.a.patches;
> if it to be used as a defacto standard for this form of archiving ?
Reason? Other than the fact that its quite large for a non-UUCP-related
posting? Probably not. IMO, alt.binaries.amiga/alt.sources.amiga would be
more appropriate. Someone should also do an archive of gzip 1.2.3 instead
of the current 1.1.1. I've got mine done with GCC, but so many people
prefer the SAS/C version (so they don't have to run ixemul.library) that
I won't post it.
I expect that the "compress" program will continue to be the standard for
quite some time, although some forward looking sites, and sites where
dial-up costs are quite high are looking at gzip very hard -- especially
European folks (and maybe *.nz, I don't know) where even local calls cost
money for each minute.
--
// Michael B. Smith
Jim Pritchett
> prefer the SAS/C version (so they don't have to run ixemul.library) that
Why do people dislike running with ixemul.library?
Jim Pritchett
UUCP: rwsys.lonestar.org!caleb!jdp
or utacfd.uta.edu!rwsys!caleb!jdp
Michael Smith
>In article <CA3y7...@murdoch.acc.Virginia.EDU>, Michael Smith writes:
>
>> prefer the SAS/C version (so they don't have to run ixemul.library) that
>
>Why do people dislike running with ixemul.library?
The most common complaint I'm aware of is from folks that have only one or
two ixemul programs. It takes up about 140K while idle.
Many folks also believe that it is better to modify the program to use native
Amiga routines/calls/etc. than to emulate the Unix stuff.
IMO, my time is better spent otherwise and I really like ixemul.
Russell McOrmond
: In article <CA3y7...@murdoch.acc.Virginia.EDU>, Michael Smith writes:
:
: > prefer the SAS/C version (so they don't have to run ixemul.library) that
:
: Why do people dislike running with ixemul.library?
Size is my reason. Unless I am running a very HUGE number of utilities that
use it, it's just not worth it.
If it were broken down into a number of smaller libraries where one only
had loaded the functions that they needed, it would be OK.
: UUCP: rwsys.lonestar.org!caleb!jdp
: or utacfd.uta.edu!rwsys!caleb!jdp
---
Russell McOrmond, Ottawa Ontario, Canada | Opinions expressed
Freenet: aa...@freenet.carleton.ca (Faster) | in this message are
Home: r...@Atronx.OCUnix.On.Ca | my own and I
FidoNet 1:163/109 Current WPL | represent nobody
WPL Help 1:1/139 keeper of sources. | else.
Jim Zepeda
I can not speak for everyone but in my case it has to do with customer
satisfaction. When I send a program to someone that needs it in a
hurry the last thing that I need is for them to learn that they need
to install a library.
The other problem is portability. I prefer to keep my code to the
POSIX (IEEE 1003.1) and XPG 4 guidelines. The ixemul.library includes
some BSD functions that I want to avoid since they are beyond the
standard. (This is not to say that they are wrong I just will not use
them untill they are in the standard.)
I have considered getting the source to the ixemul.library and
building a non-shared version of the library. That will solve the
first problem but I would have to look at the copyright to see if
that would generate any other problems.
-Jim-
===================================================================
Jim Zepeda ; VMMAIL: AUSTIN(RJZEPEDA)
IBM Advanced Workstations and Systems ; email: r...@austin.ibm.com
I do not speak for my employer. It can speak for itself.
--
Jim Zepeda ; VMMAIL: AUSTIN(RJZEPEDA)
IBM Advanced Workstations and Systems ; email: r...@austin.ibm.com
I do not speak for my employer. It can speak for itself.
Michael Smith
In article <CAu2G...@austin.ibm.com> r...@austin.ibm.com writes:
>The other problem is portability. I prefer to keep my code to the
>POSIX (IEEE 1003.1) and XPG 4 guidelines. The ixemul.library includes
>some BSD functions that I want to avoid since they are beyond the
>standard. (This is not to say that they are wrong I just will not use
>them untill they are in the standard.)
As far as this is concerned, so do the SAS/C and DICE compiler libraries.
You can stick to POSIX and XPG wherever you wish, but I am not aware of any
of the compilers that don't have extensions, in one direction or another.
>I have considered getting the source to the ixemul.library and
>building a non-shared version of the library. That will solve the
>first problem but I would have to look at the copyright to see if
>that would generate any other problems.
This would be a non-trivial task, as this stdio implementation (based
on the NetBSD stdio) presumes a shared library with global data, as
do many of the tasking functions (vfork(), signal(), etc.).
I'd love to have such a thing, though. Go for it. :)
As far as the copyright is concerned, its released under a combined
GPL and "Regents of the University of California" (or some such) copyright.
You would pretty much have to release it GPL if you were to re-release it.
--
// Michael B. Smith
Tapio Heiskanen
# In article <CA3y7...@murdoch.acc.Virginia.EDU>, Michael Smith writes:
# > prefer the SAS/C version (so they don't have to run ixemul.library) that
# Why do people dislike running with ixemul.library?
It's huge and slow. And I do have 8 meg of memory, but it's still huge.
And for some reason it's been purged after the last one to use it terminates.
Shouldn't it stay until someone says 'flush'.
--
Tapio (hessu) Heiskanen _|_ Location: 60 08 58 N / 24 52 53 E
Sarkiniementie 11 B 18 \ / Internet: he...@diode.fipnet.fi
FIN-00210 HELSINKI _Y_ (Diana) Fax: +358 0 6822206
FINLAND | Telephone: +358 0 678284
-- "Tea, Earl Grey, hot!" - Jean-Luc Picard
Anthony Horan
> > prefer the SAS/C version (so they don't have to run ixemul.library) that
>
> Why do people dislike running with ixemul.library?
Because after the program using it has finished, it stays in memory, using up
valuable space for nothing. It also increases the initial loading time of the
program. It's a big library, 148K big in fact.
-----------------------------------------------------------------------------
Anthony Horan, Melbourne Australia - ant...@xymox.apana.org.au
"I kind of feel like I'm Metallica..."
- Tori Amos on the perils of long tours, November 1992
-----------------------------------------------------------------------------