We can use python.el

We can use python.el

[Richard Stallman]

Our lawyer says we can use python.el, including the more recent changes.
There's no need to remove anything.

This applies also to anything that you wrote, Dave.

Re: We can use python.el

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> Our lawyer says we can use python.el, including the more recent changes.
> There's no need to remove anything.
>
> This applies also to anything that you wrote, Dave.

Shall we roll the release tarball then?

The remaining items in FOR-RELEASE can surely wait for Emacs 22.2.

Re: We can use python.el

[Juanma Barranquero]

On 5/12/07, Chong Yidong <cyd@stupidchicken.com> wrote:

> Shall we roll the release tarball then?
>
> The remaining items in FOR-RELEASE can surely wait for Emacs 22.2.

Are you going to install a fix for the redisplay bug with cancel.pbm?

             Juanma

Re: We can use python.el

[Chong Yidong]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 5/12/07, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> Shall we roll the release tarball then?
>>
>> The remaining items in FOR-RELEASE can surely wait for Emacs 22.2.
>
> Are you going to install a fix for the redisplay bug with cancel.pbm?

It's not a redisplay bug.

Is there a compelling reason for fixing this on the branch?  From what
I understand, there is some problem with the image that causes the bug
in the first place.

Re: We can use python.el

[Juanma Barranquero]

On 5/13/07, Chong Yidong <cyd@stupidchicken.com> wrote:

> It's not a redisplay bug.

When you see pixels left over the screen, it is a "redisplay bug" even
if internally it is something else :)

> Is there a compelling reason for fixing this on the branch?  From what
> I understand, there is some problem with the image that causes the bug
> in the first place.

Apparently the image is fine. Even if it wasn't, it is an image
included with Emacs, so at the very least it should be fixed. But I
don't think it is the image.

             Juanma

Re: We can use python.el

[Chong Yidong]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 5/13/07, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> It's not a redisplay bug.
>
> When you see pixels left over the screen, it is a "redisplay bug" even
> if internally it is something else :)
>
>> Is there a compelling reason for fixing this on the branch?  From what
>> I understand, there is some problem with the image that causes the bug
>> in the first place.
>
> Apparently the image is fine. Even if it wasn't, it is an image
> included with Emacs, so at the very least it should be fixed. But I
> don't think it is the image.

True enough.

I've checked in a fix into both trunk and branch.

Re: We can use python.el

[Glenn Morris]

Chong Yidong wrote:

> I've checked in a fix into both trunk and branch.

Shouldn't PBM_MONO benefit from the same kind of check?
Ie, move the check to just after init_color_table, before the if
block.

Re: We can use python.el

[Richard Stallman]

    Shouldn't PBM_MONO benefit from the same kind of check?
    Ie, move the check to just after init_color_table, before the if
    block.

Is there a bug in the case of PBM_MONO?  If so, I guess we should
fix it too.  But we could also leave it alone, to be conservative.

Re: We can use python.el

[Jason Rumney]

Richard Stallman wrote:
>     Shouldn't PBM_MONO benefit from the same kind of check?
>     Ie, move the check to just after init_color_table, before the if
>     block.
>
> Is there a bug in the case of PBM_MONO?  If so, I guess we should
> fix it too.  But we could also leave it alone, to be conservative.
>   

I think the same bug (a malformed pbm file causing Emacs to crash) that 
led to the original change could also affect monochrome images.
Depending on the parsing code, it could also affect ASCII formatted pnm 
files, but the fix for that is not as obvious as checking the length 
before parsing.

Re: We can use python.el

[Chong Yidong]

Jason Rumney <jasonr@gnu.org> writes:

> Richard Stallman wrote:
>>     Shouldn't PBM_MONO benefit from the same kind of check?
>>     Ie, move the check to just after init_color_table, before the if
>>     block.
>>
>> Is there a bug in the case of PBM_MONO?  If so, I guess we should
>> fix it too.  But we could also leave it alone, to be conservative.
>>   
>
> I think the same bug (a malformed pbm file causing Emacs to crash)
> that led to the original change could also affect monochrome images.
> Depending on the parsing code, it could also affect ASCII formatted
> pnm files, but the fix for that is not as obvious as checking the
> length before parsing.

I checked in a fix into the trunk (I haven't been able to test this,
because I don't know how to create a malformed pbm, but redisplay of
valid pbms seems to work.)

Re: We can use python.el

[Glenn Morris]

Chong Yidong wrote:

> I checked in a fix into the trunk (I haven't been able to test this,
> because I don't know how to create a malformed pbm, but redisplay of
> valid pbms seems to work.)

Isn't it just a case of editing an existing pbm file (eg
etc/images/zoom-out.pbm) so that the width and height values on the
second line of the file header are bigger than they should be? I tried
this and where before Emacs displayed a garbled image (no crash), now
it gives a message and a blank image. So your change looks good to me.

Re: We can use python.el

[Henrik Enberg]

> From: Glenn Morris <rgm@gnu.org>
> Date: Mon, 14 May 2007 13:45:09 -0400
>
> Chong Yidong wrote:
> 
> > I checked in a fix into the trunk (I haven't been able to test this,
> > because I don't know how to create a malformed pbm, but redisplay of
> > valid pbms seems to work.)
> 
> Isn't it just a case of editing an existing pbm file (eg
> etc/images/zoom-out.pbm) so that the width and height values on the
> second line of the file header are bigger than they should be? I tried
> this and where before Emacs displayed a garbled image (no crash), now
> it gives a message and a blank image. So your change looks good to me.

Sure, but at least one of the files that's been discussed
(etc/image/cancel.pbm) isn't actually a PBM file.  It advertise itself
as a PGM file.

$ file etc/images/cancel.pbm 
etc/images/cancel.pbm: Netpbm PGM "rawbits" image data

Re: We can use python.el

[Richard Stallman]

People seemed to complain that your fix caused a disastrous problem.
What is the state of that?  Is the original bug fixed now?
Is the subsequent bug fixed now?

Re: We can use python.el

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> People seemed to complain that your fix caused a disastrous problem.
> What is the state of that?  Is the original bug fixed now?
> Is the subsequent bug fixed now?

I'm still looking at it.

I suggest not delaying the release for this.  According to the Xlib
references, XPending is not supposed to be able to signal an X
protocol error.  So this may be due to a misbehaving X server.

I will check a fix into the trunk once I work out the details.

Re: We can use python.el

[Richard Stallman]

    > People seemed to complain that your fix caused a disastrous problem.
    > What is the state of that?  Is the original bug fixed now?
    > Is the subsequent bug fixed now?

    I'm still looking at it.

What is the current state of the code in EMACS_22_BASE?  Is the fix in or out?

Re: We can use python.el

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     > People seemed to complain that your fix caused a disastrous problem.
>     > What is the state of that?  Is the original bug fixed now?
>     > Is the subsequent bug fixed now?
>
>     I'm still looking at it.
>
> What is the current state of the code in EMACS_22_BASE?  Is the fix in or out?

The fix is out.

Re: We can use python.el

[Jan Djärv]

Chong Yidong skrev:
> Richard Stallman <rms@gnu.org> writes:
> 
>> People seemed to complain that your fix caused a disastrous problem.
>> What is the state of that?  Is the original bug fixed now?
>> Is the subsequent bug fixed now?
> 
> I'm still looking at it.
> 
> I suggest not delaying the release for this.  According to the Xlib
> references, XPending is not supposed to be able to signal an X
> protocol error.  So this may be due to a misbehaving X server.

Since X requests and responses happens asynchronously, the backtrace does not 
show where the error happened unless you run with (x-synchronize t).  The 
error is detected by XPending because it is there the answer is received, but 
it happend much earlier, when Emacs sent to bad request to the server.

	Jan D.

Re: We can use python.el

[Jason Rumney]

Chong Yidong wrote:
> It's not a redisplay bug.
>
> Is there a compelling reason for fixing this on the branch?  From what
> I understand, there is some problem with the image that causes the bug
> in the first place.
>   

There is no problem with the image, it is a valid grayscale PGM. The 
problem is that it is being rejected as invalid by your bugfix, as it 
does not have enough bytes to be a valid color PPM image.

Re: We can use python.el

[Richard Stallman]

    > Are you going to install a fix for the redisplay bug with cancel.pbm?

    It's not a redisplay bug.

It is a bug.  If you think it is not a redisplay bug, what sort
of bug would you call it?

    Is there a compelling reason for fixing this on the branch?  From what
    I understand, there is some problem with the image that causes the bug
    in the first place.

The image is in the Emacs distribution, right?
If the right fix is to fix the image, that is fine with me,
as long as we fix it.

pretest 22.0.100 (was: We can use python.el)

[Reiner Steib]

On Sat, May 12 2007, Chong Yidong wrote:

> Richard Stallman <rms@gnu.org> writes:
>
>> Our lawyer says we can use python.el, including the more recent changes.
>> There's no need to remove anything.
>>
>> This applies also to anything that you wrote, Dave.
>
> Shall we roll the release tarball then?

The were some C and lisp changes compared to 22.0.99, so I'd suggest
to roll another pretest (22.0.100) first, ASAP.  (Beside changing
version numbers, this could be identical to Emacs 22.1 if all goes
well.)

> The remaining items in FOR-RELEASE can surely wait for Emacs 22.2.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: pretest 22.0.100

[Chong Yidong]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> On Sat, May 12 2007, Chong Yidong wrote:
>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>> Our lawyer says we can use python.el, including the more recent changes.
>>> There's no need to remove anything.
>>>
>>> This applies also to anything that you wrote, Dave.
>>
>> Shall we roll the release tarball then?
>
> The were some C and lisp changes compared to 22.0.99, so I'd suggest
> to roll another pretest (22.0.100) first, ASAP.  (Beside changing
> version numbers, this could be identical to Emacs 22.1 if all goes
> well.)

Since we are using Richard's release style, there will *never* be a
point where there aren't C and lisp changes compared to the previous
pretest.

The C changes to date, at least, are minor enough that we can be sure
they won't cause problems (someone can double-check this manually
too).

Re: pretest 22.0.100

[Stefan Monnier]

> The were some C and lisp changes compared to 22.0.99, so I'd suggest
> to roll another pretest (22.0.100) first, ASAP.  (Beside changing

After 22.0.99 comes 22.0.990, not 22.0.100.


        Stefan

Re: pretest 22.0.100

[Juanma Barranquero]

On 5/14/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> After 22.0.99 comes 22.0.990, not 22.0.100.

??

             Juanma

Re: pretest 22.0.100

[Nick Roberts]

Stefan Monnier writes:
 > > The were some C and lisp changes compared to 22.0.99, so I'd suggest
 > > to roll another pretest (22.0.100) first, ASAP.  (Beside changing
 > 
 > After 22.0.99 comes 22.0.990, not 22.0.100.

Well it didn't with Emacs 21, although at some stage it might reach 22.0.990.


nickrob@kahikatea:~/emacs/src$ cvs status -v xdisp.c

   ...
   Existing Tags:
        multi-tty                       (branch: 1.1150.2)
        ...
        gerd_defvaralias                (branch: 1.632.2)
        EMACS_20_4                      (revision: 1.360)
        EMACS_PRETEST_21_0_103          (revision: 1.627)
        EMACS_PRETEST_21_0_102          (revision: 1.621)
        EMACS_PRETEST_21_0_101          (revision: 1.620)
        EMACS_PRETEST_21_0_100          (revision: 1.601)
        EMACS_PRETEST_21_0_99           (revision: 1.597)
        EMACS_PRETEST_21_0_98           (revision: 1.589)
        fx-branch                       (branch: 1.586.2)
        EMACS_PRETEST_21_0_95           (revision: 1.563)
        EMACS_PRETEST_21_0_93           (revision: 1.539)
        EMACS_PRETEST_21_0_92           (revision: 1.532)
        EMACS_PRETEST_21_0_91           (revision: 1.523)
        EMACS_PRETEST_21_0_90           (revision: 1.520)
 
-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: pretest 22.0.100

[Stefan Monnier]

>> > The were some C and lisp changes compared to 22.0.99, so I'd suggest
>> > to roll another pretest (22.0.100) first, ASAP.  (Beside changing
>> 
>> After 22.0.99 comes 22.0.990, not 22.0.100.

> Well it didn't with Emacs 21, although at some stage it might reach 22.0.990.

Yes, the same mistake was made then (but was not made for Emacs-20.1).
It's no excuse to repeat it.


        Stefan

Re: pretest 22.0.100

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> > The were some C and lisp changes compared to 22.0.99, so I'd suggest
>>> > to roll another pretest (22.0.100) first, ASAP.  (Beside changing
>>> 
>>> After 22.0.99 comes 22.0.990, not 22.0.100.
>
>> Well it didn't with Emacs 21, although at some stage it might reach 22.0.990.
>
> Yes, the same mistake was made then (but was not made for Emacs-20.1).

Which mistake are you talking about?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: pretest 22.0.100

[Jason Rumney]

Stefan Monnier wrote:
> Yes, the same mistake was made then (but was not made for Emacs-20.1).
> It's no excuse to repeat it.
>   

If it was deliberate, then it was not a mistake. And history shows that 
Emacs has always had version numbers, not version strings.

Re: pretest 22.0.100

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Stefan Monnier wrote:
>> Yes, the same mistake was made then (but was not made for Emacs-20.1).
>> It's no excuse to repeat it.
>>   
>
> If it was deliberate, then it was not a mistake. And history shows
> that Emacs has always had version numbers, not version strings.

Does not change that people looking for a tarball to download will
take a look at the bottom for the most recent one.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: pretest 22.0.100

[Jason Rumney]

David Kastrup wrote:
> Jason Rumney <jasonr@gnu.org> writes:
>
>   
>> Stefan Monnier wrote:
>>     
>>> Yes, the same mistake was made then (but was not made for Emacs-20.1).
>>> It's no excuse to repeat it.
>>>   
>>>       
>> If it was deliberate, then it was not a mistake. And history shows
>> that Emacs has always had version numbers, not version strings.
>>     
>
> Does not change that people looking for a tarball to download will
> take a look at the bottom for the most recent one

That is solved by having an emacs-pretest-latest.tar.gz symbolic link in 
the download directory and advising users to use that.

After 18.9 came 18.10, likewise with 19.9 and 19.10. There is no good 
reason to change the rules only for pretests.

Re: pretest 22.0.100

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup wrote:
>> Jason Rumney <jasonr@gnu.org> writes:
>>
>>   
>>> Stefan Monnier wrote:
>>>     
>>>> Yes, the same mistake was made then (but was not made for Emacs-20.1).
>>>> It's no excuse to repeat it.
>>>>         
>>> If it was deliberate, then it was not a mistake. And history shows
>>> that Emacs has always had version numbers, not version strings.
>>>     
>>
>> Does not change that people looking for a tarball to download will
>> take a look at the bottom for the most recent one
>
> That is solved by having an emacs-pretest-latest.tar.gz symbolic link
> in the download directory and advising users to use that.
>
> After 18.9 came 18.10, likewise with 19.9 and 19.10. There is no good
> reason to change the rules only for pretests.

Actually, my personal favorite for the next number would be 22.1.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: pretest 22.0.100

[Ralf Angeli]

* Jason Rumney (2007-05-17) writes:

> After 18.9 came 18.10, likewise with 19.9 and 19.10. There is no good 
> reason to change the rules only for pretests.

,----[ http://www.gnu.org/prep/maintain/html_node/Test-Releases.html ]
| In this method, if you are about to release version 4.6 but you want to
| do a pretest first, call it 4.5.90. If you need a second pretest, call
| it 4.5.91, and so on. If you are really unlucky and ten pretests are not
| enough, after 4.5.99 you could advance to 4.5.990 and so on. (You could
| also use 4.5.100, but 990 has the advantage of sorting in the right
| order.)
`----

-- 
Ralf

Re: pretest 22.0.100

[Ulrich Mueller]

>>>>> On Thu, 17 May 2007, Ralf Angeli wrote:

> ,----[ http://www.gnu.org/prep/maintain/html_node/Test-Releases.html ]
> | In this method, if you are about to release version 4.6 but you want to
> | do a pretest first, call it 4.5.90. If you need a second pretest, call
> | it 4.5.91, and so on. If you are really unlucky and ten pretests are not
> | enough, after 4.5.99 you could advance to 4.5.990 and so on. (You could
> | also use 4.5.100, but 990 has the advantage of sorting in the right
> | order.)
> `----

This probably predates ls -v and strverscmp(3).

Ulrich

Re: pretest 22.0.100

[Alfred M. Szmidt]

   > ,----[ http://www.gnu.org/prep/maintain/html_node/Test-Releases.html ]
   > | In this method, if you are about to release version 4.6 but you want to
   > | do a pretest first, call it 4.5.90. If you need a second pretest, call
   > | it 4.5.91, and so on. If you are really unlucky and ten pretests are not
   > | enough, after 4.5.99 you could advance to 4.5.990 and so on. (You could
   > | also use 4.5.100, but 990 has the advantage of sorting in the right
   > | order.)
   > `----

   This probably predates ls -v and strverscmp(3).

When viewing a ftp directory there is very little to decide how files
are listed.

Re: pretest 22.0.100

[Jay Belanger]

Jason Rumney <jasonr@gnu.org> writes:
...
> If it was deliberate, then it was not a mistake. And history shows that
> Emacs has always had version numbers, not version strings.

If that were the case, shouldn't 22.0.99 be followed by 22.0.991
rather than 22.0.990 or 22.0.100?

Jay

Re: pretest 22.0.100

[Stefan Monnier]

>> Yes, the same mistake was made then (but was not made for Emacs-20.1).
>> It's no excuse to repeat it.

> If it was deliberate, then it was not a mistake. And history shows that
> Emacs has always had version numbers, not version strings.

If people feel so strongly about it, go for it and use 22.0.100 or any other
number that makes you happy, really.  I just think 22.0.990 etc... is much
cleverer since it makes it both numerically and alphabetically increasing.
I never imagined people would waste time arguing against it.


        Stefan

Re: pretest 22.0.100

[Juanma Barranquero]

On 5/17/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I never imagined people would waste time arguing against it.

Or *for* it?

             Juanma

Another pretest after 22.0.99 (was: pretest 22.0.100)

[Reiner Steib]

On Thu, May 17 2007, Stefan Monnier wrote:

> If people feel so strongly about it, go for it and use 22.0.100 or any other
> number that makes you happy, really.  I just think 22.0.990 etc... is much
> cleverer since it makes it both numerically and alphabetically increasing.
> I never imagined people would waste time arguing against it.

Although I put .100 in the subject, I don't care at all if it is .100
or .990 or whatever.  I was only suggestion to do another one after
22.0.99 as there have been many C and lisp changes compared to
22.0.99, so releasing another pretest now seems appropriate, IMHO.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: We can use python.el

[Michaël Cadilhac]

[-- Attachment #1.1: Type: text/plain, Size: 1013 bytes --]

Chong Yidong <cyd@stupidchicken.com> writes:

> Shall we roll the release tarball then?

Please wait until I've committed the fr-refcard, some colleagues of mine
are still proofreading it.

I'll install it ASAP, that is to say, before Tuesday.

Speaking of which, should we keep the
\centerline{traduction fran\c{c}aise d'\'Eric Jacoboni}
               (French translation by Eric Jacoboni)
line?   I've modified almost every line of it, rewriting the file from
the German one, but I think (I don't know about copyright issues) that
there's no need to put such a line (well, it'd be certainly gratifying,
but it's not in the FOSS way of life, isn't it :-)).

Thanks!

-- 
 |   Michaël `Micha' Cadilhac       |  <ESC>ape this <COLON> thing,          |
 |   http://michael.cadilhac.name   |           <Q>uit and                   |
 |   JID/MSN:                       |    do <NOT> <RET>urn.                  |
 `----  michael.cadilhac@gmail.com  |          -- VI                    -  --'

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: We can use python.el

[Richard Stallman]

    Speaking of which, should we keep the
    \centerline{traduction fran\c{c}aise d'\'Eric Jacoboni}
		   (French translation by Eric Jacoboni)
    line?

If we have removed all his work (except something trivial),
we don't need to credit him any more in the file.