ANNOUNCE: release 3 of the DJGPP port of GNU grep 2.5.3 uploaded.
Juan Manuel Guerrero
DJGPP specific changes.
=======================
Adapting the code provided by the port of grep 2.5.1 it has been possible
to reimplement colorization support for this port too. If grep is called
with the command line option --color and the output is directed to the
screen then the default colors will be used to mark matches, filenames and
line numbers. If the output does not go to the screen then colorization is
automaticaly suppressed. Read the docs to learn how to control the color
using the environment variable GREP_COLORS. No other changes have been done.
As usual all changes are documented in the djgpp/diffs file.
Please read the docs to become familiar with this binary.
The binaries, docs and surces can be downloaded from ftp.delorie.com and
mirrors as(timestamp 2008-01-20):
grep 2.5.3 binaries, info and man format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/grep253b.zip
grep 2.5.3 dvi, html, pdf and ps format documentation:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/grep253d.zip
grep 2.5.3 source:
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/grep253s.zip
For the convenience of the WinXP users the binaries has been produced
a second time using the djdev204 beta library. This package is available
at ftp.delorie.com and mirrors as (timestamp 2008-01-20):
grep 2.5.3 binary, info and man format documentation:
ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/grep253b.zip
Send grep specific bug reports to <bug-...@gnu.org>.
Send suggestions and bug reports concerning the DJGPP port to
comp.os.msdos.djgpp or <dj...@delorie.com>.
Enjoy.
Guerrero, Juan Manuel <juan.g...@gmx.de>
CBFalconer
>
... snip ...
>
> The binaries, docs and surces can be downloaded from
> ftp.delorie.com and mirrors as(timestamp 2008-01-20):
>
> grep 2.5.3 binaries, info and man format documentation:
> ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/grep253b.zip
I already downloaded, and am running, grep 2.5.3 for djgpp. I
downloaded it sometime last August. So either you have made a
mistake, or you should have modified the name for a later port.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
Juan Manuel Guerrero
> Juan Manuel Guerrero wrote:
> >
> ... snip ...
> >
> > The binaries, docs and surces can be downloaded from
> > ftp.delorie.com and mirrors as(timestamp 2008-01-20):
> >
> > grep 2.5.3 binaries, info and man format documentation:
> > ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/grep253b.zip
>
> I already downloaded, and am running, grep 2.5.3 for djgpp. I
> downloaded it sometime last August. So either you have made a
> mistake, or you should have modified the name for a later port.
Sorry, but I do not understand this. There have been 3 releases or
updates of the port of grep 2.5.3. These were necessary to fix bugs
and pending issues. AFAIK it was always the rule to follow that
the new update or release replaces the old one; there is absolutly
no reason to keep a broken or unfinished version of the port.
Because the new release replaces the old one there is also
no reason to give the new release a different name than the
old one. This is the politics that has been followed all the years.
E.G. look at fileutils (fil41*.zip) it is release 7 as can be seen
by inspection of the dsm file, and it has still the same zip
file name than the first release. I only make a new release
of a port if there is a serious reason to do it; in that case
the old one is replaced and the new release
is announced allowing the user to update if he want.
I never silently replace an old release with a new one.
The current naming scheme is that it must fulfill the
8.3 DOS filename restriction so usualy there is no space
left for some release info. Any necessary release info is
given in the announcement and in the dsm file.
If you prefer a different naming convention it will be ok
with me but in that case discuss it DJ and not with me.
If he changes the rules I will follow the new ones.
Regards,
Juan M. Guerrero
Luis Gouveia
BIOSCOM command in DJGPP include file BIOS.H doesn't allow
me to make a serial communication at a baudrate superior
to 9600. Is there any command that allow's it under DJGPP?
I need at least 57600.
XP's hyperterminal does 921600!!
Thanks a lot,
Luís Gouveia
DJ Delorie
> BIOSCOM command in DJGPP include file BIOS.H doesn't allow me to
> make a serial communication at a baudrate superior to 9600. Is there
> any command that allow's it under DJGPP? I need at least 57600.
To get higher speeds, you need hardware-specific code.
Luis Gouveia
DJ Delorie <d...@delorie.com> escreveu:
Huumm... Hyperterminal is no hardware-specific and does it
very well at 57600!
Thanks again,
Luís Gouveia
Gerrit van Niekerk
> > To get higher speeds, you need hardware-specific code.
> Huumm... Hyperterminal is no hardware-specific and does it
> very well at 57600!
lucky to receive reliably even at 9600 baud. For higher speeds you need to use interrupts and need
an ISR, perhaps even a dual Protected Mode/Real Mode one.
Hyperterminal uses the Windows kernel-mode driver, so there is no comparison.
Gerrit van Niekerk
> > > To get higher speeds, you need hardware-specific code.
> > Huumm... Hyperterminal is no hardware-specific and does it
> > very well at 57600!
> BIOSCOM as the name says, uses the BIOS functions which are simple polling functions. You will be
> lucky to receive reliably even at 9600 baud. For higher speeds you need to use interrupts and need
> an ISR, perhaps even a dual Protected Mode/Real Mode one.
For an example, download the GDB source code and look at gdb/ser-go32.c
--
Gerrit van Niekerk
GP van Niekerk Ondernemings BK
Roosstraat 211, Meyerspark, 0184, South Africa
Tel: +27(12)8036501 Fax SA: 0866 413 555
Cell: +27(73)6891370
Fax Int'l: +1(206)2034139
Email: gerr...@gpvno.co.za
Web: http://www.gpvno.co.za
Luis Gouveia
Thanks Gerrit!
Luís Gouveia
Em Mon, 21 Jan 2008 20:56:26 +0200
"Gerrit van Niekerk" <gerr...@gpvno.co.za> escreveu:
CBFalconer
> CBFalconer schrieb:
>> Juan Manuel Guerrero wrote:
>>
>> ... snip ...
>>
>>> The binaries, docs and surces can be downloaded from
>>> ftp.delorie.com and mirrors as(timestamp 2008-01-20):
>>>
>>> grep 2.5.3 binaries, info and man format documentation:
>>> ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/grep253b.zip
>>
>> I already downloaded, and am running, grep 2.5.3 for djgpp. I
>> downloaded it sometime last August. So either you have made a
>> mistake, or you should have modified the name for a later port.
>
> Sorry, but I do not understand this. There have been 3 releases or
> updates of the port of grep 2.5.3. These were necessary to fix bugs
> and pending issues. AFAIK it was always the rule to follow that
> the new update or release replaces the old one; there is absolutly
> no reason to keep a broken or unfinished version of the port.
Yes there is - it allows the user to keep track of which version he
is running. For example, look at: fileutils-4.1r7
which has been repaired several times.
Juan Manuel Guerrero
> Juan Manuel Guerrero wrote:
> > Sorry, but I do not understand this. There have been 3 releases or
> > updates of the port of grep 2.5.3. These were necessary to fix bugs
> > and pending issues. AFAIK it was always the rule to follow that
> > the new update or release replaces the old one; there is absolutly
> > no reason to keep a broken or unfinished version of the port.
>
> Yes there is - it allows the user to keep track of which version he
> is running. For example, look at: fileutils-4.1r7
> which has been repaired several times.
I am afraid that we are talking about different things.
1) I was talking all the time about the name of the zip file
and this must match the well known 8.3 filename restrictions.
In this particular case we are talking about grep253[bds].zip.
I will not change this name to something like this: grep253r3[bds].zip
to signal that it is the 3rd release. If I really decide to make a
new
release there is a good reason for this (fixing a bug) and the old
zip file will be replaced by the new zip file with identical name.
This is the way it has been handled all the years and I will not
change this.
2) Something completely different is the name that
appears in the weekly Mini-FAQ. I have no objections
in substituting the string "grep-2.5.3" with "grep-2.5.3r3".
That is ok but please note that I have no access to the
template of that file so I have to ask DJ to change it every time
I upload something to his ftp server. I will talk to DJ to see
how this issue can be solved. I hope I have really understood
what you want this time.
Regards,
Juan M. Guerrero
DJ Delorie
> That is ok but please note that I have no access to the template of
> that file so I have to ask DJ to change it every time I upload
> something to his ftp server. I will talk to DJ to see how this
> issue can be solved.
I can give you a CVS account, the file is in there.
As for the naming conventions... you've been doing a lot of work on
ports, I think you've earned the right to decide how it's done.
CBFalconer
I'm not worrying about goodness or badness. To me, the point is
that his uploads are destroying previous work. They also prevent
tracking the changes made. We all know that bad ports are possible
and do occur, and thus need correction. But just reloading the
same file name doesn't allow the user to detect it, except possibly
by detailed examination of the exact file dates.
Juan Manuel Guerrero
> DJ Delorie wrote:
[snip]
> > As for the naming conventions... you've been doing a lot of work
> > on ports, I think you've earned the right to decide how it's done.
>
> I'm not worrying about goodness or badness. To me, the point is
> that his uploads are destroying previous work. They also prevent
> tracking the changes made. We all know that bad ports are possible
> and do occur, and thus need correction. But just reloading the
> same file name doesn't allow the user to detect it, except possibly
> by detailed examination of the exact file dates.
I am aware of this. That is the reason why I always mention the
timestamp of the uploaded zip file in the announcement. Most
of the mayor DJGPP mirrors update in 24h so that the announcement
together with the timestamp, the dsm file and the diffs file
should be information enough for the user to know that something
has changed and what has changed.
Most of the zip files are ports. In most of the cases there will be
only
one release, in the worst one or two more to fix something so I
insist that there is no reason to keep previous releases. The ports
of grep and splint are very good examples that broken old releases
must be replaced and retired. All new releases of ports I have
produced are bug fixes and not extensions of the functionality
provided by the ported program so there is no reason to keep
the previuos release available to the user.
Neitherless, if DJ do not object I would suggest to change the
actual naming convention and adopt one similar to the one
that uses cygwin. This is something like this:
foobar123-1[bsd].zip
or
foobar20080123-1[bsd].zip
The first means th package name followed by the version
number followed by release number (1 in this case). We also
keep the b,d and s letters to code the type of package content.
The second version is for CVS checkouts or something similar
where the checkout timestamp is used as version number.
Suggestions, objections, comments are welcome.
I still insist that broken old releases must be retired. I do not
want to have to answer user questions like "which one
of the releases is the better one?" or "what shall I download?".
Regards,
Juan M. Guerrero
DJ Delorie
> Neitherless, if DJ do not object I would suggest to change the
> actual naming convention and adopt one similar to the one
I think the days of requiring an 8.3 clean path from the ftp site to
the user's machine have past, even if the machine itself is 8.3. They
can rename it (or expect it to be cleanly renamed) as needed, and most
systems aren't 8.3 any more.
I'd still *prefer* 8.3 so let's not go renaming everything ;-)
Manuel Collado
> [snip]
> Neitherless, if DJ do not object I would suggest to change the
> actual naming convention and adopt one similar to the one
> that uses cygwin. This is something like this:
> foobar123-1[bsd].zip
> or
> foobar20080123-1[bsd].zip
> The first means th package name followed by the version
> number followed by release number (1 in this case). We also
> keep the b,d and s letters to code the type of package content.
> The second version is for CVS checkouts or something similar
> where the checkout timestamp is used as version number.
> Suggestions, objections, comments are welcome.
Just another possibility:
- Use the current naming convention for the first release of each port.
- Insert a 'rx' release designator before the [bsd] suffix for second
and subsequent releases: xxx123b.zip -> xxx123r2b.zip -> xxx123r3b.zip
> I still insist that broken old releases must be retired.
Agreed.
> I do not want to have to answer user questions like "which one of the
> releases is the better one?" or "what shall I download?".
Using the same name for really different releases is even worse. A lot
of users asking for help will insist in that their DJGPP environments
are up-to-date when in fact the aren't
Regards.
--
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado
Juan Manuel Guerrero
> Juan Manuel Guerrero escribi�:
> > [snip]
> > Neitherless, if DJ do not object I would suggest to change the
> > actual naming convention and adopt one similar to the one
> > that uses cygwin. This is something like this:
> > foobar123-1[bsd].zip
> > or
> > foobar20080123-1[bsd].zip
> > The first means th package name followed by the version
> > number followed by release number (1 in this case). We also
> > keep the b,d and s letters to code the type of package content.
> > The second version is for CVS checkouts or something similar
> > where the checkout timestamp is used as version number.
> > Suggestions, objections, comments are welcome.
>
> Just another possibility:
>
> - Use the current naming convention for the first release of each port.
> - Insert a 'rx' release designator before the [bsd] suffix for second
> and subsequent releases: xxx123b.zip -> xxx123r2b.zip -> xxx123r3b.zip
It seems a good idea to me.
If possible, the primary goal should be to retain the used
naming scheme. The vast mayority of the ports will have
only one release and in that case there is no reason to
add something to the package name. If a bug fix release
is needed a release identifier could be add.
> > I do not want to have to answer user questions like "which one of the
> > releases is the better one?" or "what shall I download?".
>
> Using the same name for really different releases is even worse. A lot
> of users asking for help will insist in that their DJGPP environments
> are up-to-date when in fact the aren't
Agreed.
Regards,
Juan M. Guerrero
Juan Manuel Guerrero
It was not my intention to suggest to rename all the zip
files stored on the ftp server. What ever it will be decided
will only be applied to future zip files.
Regards,
Juan M. Guerrero