6:29 p.m.
Ar an triú lá déag de mí Feabhra, scríobh Raymond Toy:
On 2/13/11 5:41 AM, Aidan Kehoe wrote:
>
> Ar an triú lá déag de mà Feabhra, scrÃobh Raymond Toy:
>
> > Is it possible to build all of the packages from source using xemacs
> > 21.5-b29? I checked out all of the packages, copied
> > Local.rules.template to Local.rules and ran make. This eventually
> > causes xemacs to die when building advice.el.
>
> It should be possible, yes, that’s what the smoketest does (though its
> 21.5.29 binary is old). Can you paste the error?
>
Error attached. I'm using latest xemacs sources fresh from the hg repo
yesterday. I'm attaching the Installation file, just for the record.
Ah, thanks. I suspect 5dd1ba5e0113 has fixed this, can you try again with a
more recent build?
--
“Apart from the nine-banded armadillo, man is the only natural host of
Mycobacterium leprae, although it can be grown in the footpads of mice.”
-- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:33 p.m.
New subject: Building packages with 21.5b29?
On 2/14/11 1:29 PM, Aidan Kehoe wrote:
Ar an triú lá déag de mí Feabhra, scríobh Raymond Toy:
> On 2/13/11 5:41 AM, Aidan Kehoe wrote:
> >
> > Ar an triú lá déag de mà Feabhra, scrÃobh Raymond Toy:
> >
> > > Is it possible to build all of the packages from source using xemacs
> > > 21.5-b29? I checked out all of the packages, copied
> > > Local.rules.template to Local.rules and ran make. This eventually
> > > causes xemacs to die when building advice.el.
> >
> > It should be possible, yes, that’s what the smoketest does (though its
> > 21.5.29 binary is old). Can you paste the error?
> >
> Error attached. I'm using latest xemacs sources fresh from the hg repo
> yesterday. I'm attaching the Installation file, just for the record.
Ah, thanks. I suspect 5dd1ba5e0113 has fixed this, can you try again with a
more recent build?
I clearly don't know how to drive hg. :-( I thought I was using the
most recent version. I did an hg pull and hg update, but nothing is
added/updated.
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:15 p.m.
New subject: Building packages with 21.5b29?
Raymond Toy wrote:
On 2/14/11 1:29 PM, Aidan Kehoe wrote:
> Ah, thanks. I suspect 5dd1ba5e0113 has fixed this, can you try
again with a
> more recent build?
I clearly don't know how to drive hg. :-( I thought I was using
the
most recent version. I did an hg pull and hg update, but nothing is
added/updated.
I don't think you did anything wrong. 5dd1ba5e0113 is in
http://hg.debian.org/hg/xemacs/xemacs, but not
http://hg.debian.org/hg/xemacs/xemacs-beta. (Pushes are done to the
"xemacs" repo, then given a little soak time before being made available
from the "xemacs-beta" repo.)
$ pwd
/home/kupfer/xemacs/src/xemacs-beta
$ hg path default
http://hg.debian.org/hg/xemacs/xemacs-beta
$ hg log -r 5dd1ba5e0113
abort: unknown revision '5dd1ba5e0113'!
$ hg incoming
comparing with http://hg.debian.org/hg/xemacs/xemacs-beta
searching for changes
[...
long list of changesets that I haven't pulled yet, none of which
includes 5dd1ba5e0113
...]
$ hg incoming http://hg.debian.org/hg/xemacs/xemacs
comparing with http://hg.debian.org/hg/xemacs/xemacs
searching for changes
[...]
changeset: 5356:5dd1ba5e0113
tag: tip
user: Aidan Kehoe <kehoea(a)parhasard.net>
date: Sat Feb 12 14:07:38 2011 +0000
summary: Be better about eliminating `block's that are not `return-from'd,
bytecomp.el
$
cheers,
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:27 p.m.
New subject: Building packages with 21.5b29?
On 02/14/11 01:15 PM, Mike Kupfer wrote:
I don't think you did anything wrong. 5dd1ba5e0113 is in
http://hg.debian.org/hg/xemacs/xemacs, but not
http://hg.debian.org/hg/xemacs/xemacs-beta. (Pushes are done to the
"xemacs" repo, then given a little soak time before being made available
from the "xemacs-beta" repo.)
That sounds backwards?!? But, I suppose it's documented that way. I
haven't played around with hg myself.
Rodney
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:28 a.m.
New subject: Building packages with 21.5b29?
Rodney Sparapani writes:
On 02/14/11 01:15 PM, Mike Kupfer wrote:
>
> I don't think you did anything wrong. 5dd1ba5e0113 is in
> http://hg.debian.org/hg/xemacs/xemacs, but not
> http://hg.debian.org/hg/xemacs/xemacs-beta. (Pushes are done to the
> "xemacs" repo, then given a little soak time before being made available
> from the "xemacs-beta" repo.)
AFAIK, xemacs-beta is no longer being updated, because it turned out
that xemacs only very rarely stayed unbuildable across an xemacs-beta
update boundary. VCSes don't provide a way to say that, though.
Maybe we should rename the xemacs-beta repo (eg,
obsolete.xemacs-beta), and alias xemacs-beta to xemacs.
Mike, Vin?
That sounds backwards?!? But, I suppose it's documented that
way. I
haven't played around with hg myself.
Backwards from some points of view, yes, eg, if you think of "xemacs"
as the release branch. The view that drove this naming scheme is that
the "xemacs" repo knows everything about recent XEmacs development,
while xemacs-beta is not told about the most recent patch(es) until
they're known to at least build for somebody other than the committer.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:32 a.m.
New subject: Building packages with 21.5b29?
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Rodney Sparapani writes:
> On 02/14/11 01:15 PM, Mike Kupfer wrote:
> >
> > I don't think you did anything wrong. 5dd1ba5e0113 is in
> > http://hg.debian.org/hg/xemacs/xemacs, but not
> > http://hg.debian.org/hg/xemacs/xemacs-beta. (Pushes are done to the
> > "xemacs" repo, then given a little soak time before being made
available
> > from the "xemacs-beta" repo.)
AFAIK, xemacs-beta is no longer being updated, because it turned out
that xemacs only very rarely stayed unbuildable across an xemacs-beta
update boundary. VCSes don't provide a way to say that, though.
No, I still update it once a week, after checking that it builds. But
you're right, it's very rare that I hold up the push.
I know you've said it many times before, but do we have a release plan?
My favorite would be to merge over the GPLv3 stuff (not your favorite, I
know), clone the repo to "xemacs-stable", and start release engineering
there.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:54 a.m.
New subject: Building packages with 21.5b29?
>>>> Michael Sperber <sperber(a)deinprogramm.de>
writes:
Michael> No, I still update it once a week, after checking that it
Michael> builds.
With the buildbot now checking that xemacs builds after each push this
might not be needed?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:53 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
Michael Sperber writes:
I know you've said it many times before, but do we have a release
plan?
If anybody wants to start publishing "top ten bugs that must be fixed
for the release" or "top ten features that should be completed for the
release" lists, that would be a good start. But we don't even have
those lists yet; talking about a release plan is way premature IMHO,
especially with the only person regularly contributing patches being
Aidan, and the work he's doing is not useful in moving toward a
release IMO. (That is not to say I think Aidan "should" do something
else; just that we need more promises of manpower, and a do-able list
of tasks to apply it to, before thinking about schedules and such.)
Nor do I think it's *my* place to mandate any particular lists. Some
of the things I want to work on are definitely unnecessary; some of
the things I think *are* high priority I'm not able/willing to
volunteer to do.
My favorite would be to merge over the GPLv3 stuff (not your
favorite, I
know), clone the repo to "xemacs-stable", and start release engineering
there.
I don't see any point in merging the GPLv3 stuff and immediately
forking off a public release branch. There are too many desirable
features that are just plain unusable (Xft, nxhtml), but there's been
no discussion of what *must* be fixed and what new features we are
willing to postpone a release for. OTOH, there are many relatively
safe features (FFI from SXEmacs, my support for libcurl and neon,
Aidan's Common Lisp compatibility improvements) that I don't see much
point in freezing out at this point. Bottom line: I don't think
anybody, not you, not me, would actually do any work on a feature-
frozen branch.
As I see it the way to go is to just get the GPLv3 stuff merged as
quickly as possible and start talking about what a release would look
like immediately.
The main obstacle to the GPLv3 merge at this point is that I want to
have beta release with a decent release announcement for the work
that's been done over the last two years, but that's a major task. I
suppose we could live without it (ie, I could just pick a random
pre-merge revision that works well for me and call that the beta).
But I also want to look at the files that have been updated for GPLv3.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:46 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
On 02/15/11 08:53 AM, Stephen J. Turnbull wrote:
snip, snip
OTOH, there are many relatively
safe features (FFI from SXEmacs, my support for libcurl and neon,
Aidan's Common Lisp compatibility improvements) that I don't see much
point in freezing out at this point. Bottom line: I don't think
anybody, not you, not me, would actually do any work on a feature-
frozen branch.
I appreciate being brought into this discussion. I'm going to
be tied
up for a
few months, but, in my view, FFI is the future of XEmacs (is SXEmacs
still around?
haven't heard much from them lately). If anyone else cares, I'd like to
be able to
use FFI with R, OpenBUGS and, possibly, TeXmacs. I don't know what of
that, if
anything, is actually doable. I suppose we are talking about Linux
only, but, sadly,
we are in the process of moving to Linux anyways. Did I mention the
Packers won
the Super Bowl? :O)
--
Rodney Sparapani Center for Patient Care and Outcomes Research
Sr. Biostatistician http://www.mcw.edu/pcor
4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW)
WWLD?: What Would Lombardi Do? Milwaukee, WI, USA
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:41 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
Removing addresses of folks who are not-necessarily-fascinated by the
issue, and subscribe to the list anyway.
Rodney Sparapani writes:
I appreciate being brought into this discussion. I'm going to
be
tied up for a few months, but, in my view, FFI is the future of
XEmacs (is SXEmacs still around? haven't heard much from them
lately).
I believe so. They have their own lists and stuff, so they only show
up here when they have something important to say.
If anyone else cares, I'd like to be able to use FFI with
R, OpenBUGS and, possibly, TeXmacs.
For R, I would think it's feasible, but I'm really not sure what net
benefit that would have. On the one hand, it's true that comint
interfaces are pretty finicky. But on the other, they're a lot more
flexible than FFI would be for "on the fly" variations. Dunno about
OpenBUGS, I don't even know what it is (although I probably can
guess).
For TeXmacs, I suspect it would be quite fiddly. I guess you have in
mind something like passing a buffer to TeXmacs for display?
I suppose we are talking about Linux only,
No, we're talking about GCC on platforms which support GCC-style FFI
(I forget whether this is libffi or not). This includes at least
Linux, *BSD, and Mac OS X. ISTR you had problems with it on Solaris,
or were aware of problems on Solaris. But it's not limited to Linux,
for sure.
In theory there should be similar facilities on other platforms like
Solaris and BeOS, but somebody would have to port.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:02 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
Rodney Sparapani writes:
> I appreciate being brought into this discussion. I'm going to be
> tied up for a few months, but, in my view, FFI is the future of
> XEmacs (is SXEmacs still around? haven't heard much from them
> lately).
I believe so. They have their own lists and stuff, so they only show
up here when they have something important to say.
I thought they might speak up
and jump on this brilliant suggestion :o)
For R, I would think it's feasible, but I'm really not sure
what net
benefit that would have. On the one hand, it's true that comint
interfaces are pretty finicky. But on the other, they're a lot more
flexible than FFI would be for "on the fly" variations. Dunno about
OpenBUGS, I don't even know what it is (although I probably can
guess).
Excellent question. comint actually works pretty well as far as it goes.
But, somebody has combined R and OpenBUGS (a Bayesian statistical
package that
has an indescribable interface) into BRUGS, but only on Windows. I'd
like to
extend that to additional platforms and I see FFI as one possible solution.
We are teaching our students that using Windows is necessary :o( This is
a total reversal from when I went to school and UNIX was a necessity.
For TeXmacs, I suspect it would be quite fiddly. I guess you have
in
mind something like passing a buffer to TeXmacs for display?
Maybe I went too far
with that. I was just trying to give an
example of what might be possible with FFI.
> I suppose we are talking about Linux only,
No, we're talking about GCC on platforms which support GCC-style FFI
(I forget whether this is libffi or not). This includes at least
Linux, *BSD, and Mac OS X. ISTR you had problems with it on Solaris,
or were aware of problems on Solaris. But it's not limited to Linux,
for sure.
In theory there should be similar facilities on other platforms like
Solaris and BeOS, but somebody would have to port.
Right, I should have said GCC.
But, I also forgot to mention that the
OpenBUGS libraries are only available on Linux. I guess we could
add Mac OS X via ELF loading http://osxbook.com/software/xbinary But,
then I would want a Cocoa port and be able to designate the Meta key too
:o)
--
Rodney Sparapani Center for Patient Care and Outcomes Research
Sr. Biostatistician http://www.mcw.edu/pcor
4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW)
WWLD?: What Would Lombardi Do? Milwaukee, WI, USA
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:30 a.m.
New subject: Release plans
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
If anybody wants to start publishing "top ten bugs that must be
fixed
for the release" or "top ten features that should be completed for the
release" lists, that would be a good start. But we don't even have
those lists yet;
We haven't had them for a long time. While desirable, I don't think
this is a good strategy for moving forward - there's just nobody around
to push for that kind of plan.
The reason why I advocated branching after GPLv3 is that I expect more
aggressive development after that. (At least that development is
enabled. If it happens - who knows.) So this is a good time to branch
off for stability. One the other hand, we do want GPLv3 to enable GPLv3
packages.
I'd then suggest moving towards a model more in line what many other
projects have concluded is a good strategy for producing releases:
- branch off a "stable" branch (leaving a "development branch" and
the
"stabe branch"
- set a release *date*
- fix bugs in the stable branch, merge them over to the development
branch
- at that date, branch off the release branch, do n days of release
engineering
- release
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:40 a.m.
New subject: Release plans
Michael Sperber writes:
I'd then suggest moving towards a model more in line what many
other
projects have concluded is a good strategy for producing releases:
- branch off a "stable" branch (leaving a "development branch" and
the
"stabe branch"
- set a release *date*
- fix bugs in the stable branch, merge them over to the development
branch
- at that date, branch off the release branch, do n days of release
engineering
- release
I'm sorry, Mike, but the mere word "release" does not excite me.
"Producing releases" really sounds like pointless work to me.
I agree, we should get to work and produce some software and release
it. And some sort of cyclical process with regular releases is good
discipline for getting certain aspects of the software finished, even
polished. I'm not opposed to the one you describe. But to me
"producing releases" is not a goal in itself. The goal is delivering
software to users. To get excited about a release, and the work
entailed, I'm going to need to be excited about the software and what
it will do for the kind of user who doesn't build XEmacs from a
Mercurial repo.
I'm not excited about delivering XEmacs 21.5 to non-developer users.
Generating the excitement is what the lists are for.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:29 p.m.
New subject: Release plans
On 2/17/2011 6:40 AM, Stephen J. Turnbull wrote:
Michael Sperber writes:
> I'd then suggest moving towards a model more in line what many other
> projects have concluded is a good strategy for producing releases:
...
I'm sorry, Mike, but the mere word "release" does not excite me.
"Producing releases" really sounds like pointless work to me.
I have to agree with Stephen. The release model you've proposed works great if
you have sufficient developers which I do not believe is the case here. Instead,
I would recommend a "pick three most important items, develop, make stable and
Mark stability point in version control" approach. This approach has the lowest
overhead and minimizes time between with the stable code.
---eric
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:41 p.m.
New subject: Release plans
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Stephen> But to me "producing releases" is not a goal in itself.
IMHO we don't need a five year plan at the moment. We just need to
plan the very next steps. My logic goes like this...
The facts are that we have a repo with an almost done GPLv3 or later
that I would like to get out because I think it will be beneficial for
future development. I hope you agree here. This is more or less the
current beta but with a license change. There are no bug fixes or
enhancement there. Only the license change.
Still I think this is important enough to warrant a version number
bump. It should be easy to know that this is the version from which
XEmacs was GPLv3 or later. I suggest a version bump so it sticks
out. Maybe it should be 21.7 then for an odd number if that is needed
for a development version!?
For doing version number bumps I guess we need to do a
release. Normally a release means something new, complete, etc. This
time it does too. A new license. 21.5 will end its life with a release
note that basically states that this is the end. Whatever bugs that
are there will be fixed in the GPLv3 or later version.
All of this can probably be handled with just a tag but I think that
will not be clear enough.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:39 a.m.
New subject: Release plans
Mats -
On Thu, Feb 17, 2011 at 5:41 PM, Mats Lidell <matsl(a)xemacs.org> wrote:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
Stephen> But to me "producing releases" is not a goal in itself.
IMHO we don't need a five year plan at the moment. We just need to
plan the very next steps.
+1
My logic goes like this...
The facts are that we have a repo with an almost done GPLv3 or later
that I would like to get out because I think it will be beneficial for
future development. I hope you agree here. This is more or less the
current beta but with a license change. There are no bug fixes or
enhancement there. Only the license change.
Still I think this is important enough to warrant a version number
bump. It should be easy to know that this is the version from which
XEmacs was GPLv3 or later. I suggest a version bump so it sticks
out. Maybe it should be 21.7 then for an odd number if that is needed
for a development version!?
For doing version number bumps I guess we need to do a
release. Normally a release means something new, complete, etc. This
time it does too. A new license. 21.5 will end its life with a release
note that basically states that this is the end. Whatever bugs that
are there will be fixed in the GPLv3 or later version.
IMO you have this exactly right.
Regards,
Vin
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:46 a.m.
New subject: Release plans
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
Stephen> But to me "producing releases" is not a goal in itself.
IMHO we don't need a five year plan at the moment. We just need to
plan the very next steps. My logic goes like this...
Sure. But Mike is proposing to branch without even that.
The facts are that we have a repo with an almost done GPLv3 or later
that I would like to get out because I think it will be beneficial for
future development. I hope you agree here. This is more or less the
current beta but with a license change.
No, the current beta is 21.5.29, which is almost 2 years old, and
there are many kB of ChangeLogs since then. The GPLv3 release will be
essentially the same as the *next* beta. My current XEmacs is clearly
not as stable for me as 21.5.29 was, although that may be as much due
to my hardware and changes in Gentoo and Mac OS X as to changes in
XEmacs. (I especially experience annoyance due to the X bug I
reported. I regularly hang in poll(2) on Gentoo Linux.)
Still I think this is important enough to warrant a version number
bump.
As just another developer (ie, I'm not wearing my Release Manager hat,
so you can ignore me if you wish :-) I disagree. A version bump says
to the world, "we're done, this is what you've been waiting for!"
Nobody is waiting for a GPLv3 XEmacs except us developers, though.
What they are waiting for is an XEmacs synched to Emacs, which happens
to require GPLv3. This is not what the GPLv3 merge will provide. So
bumping the version for that alone says the wrong thing to almost
everybody.
OTOH, people who care about GPLv2 can use the last-GPLv2-XEmacs tag
which will be applied to that version. That's currently one person,
Julian Bradfield. (Vin already has everything he wants from 21.5, I
suppose.)
For doing version number bumps I guess we need to do a
release. Normally a release means something new, complete, etc. This
time it does too. A new license. 21.5 will end its life with a release
note that basically states that this is the end. Whatever bugs that
are there will be fixed in the GPLv3 or later version.
If the Review Board decides to go this way, I won't veto it. But I'll
say now and in later discussion, I think this is more fuss for the
sake of fussing.
Note that this doesn't mean that we can't decide, on the basis of some
amount of discussion, that there really isn't that much that needs to
be fixed, make a short list of what does need to be fixed, fix it, and
release a new version fairly quickly. But GPLv3 is not enough for a
version bump without making some effort to ensure the released XEmacs
is usable.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:42 a.m.
New subject: Release plans
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Stephen> A version bump says to the world, "we're done, this is what
Stephen> you've been waiting for!" Nobody is waiting for a GPLv3
Stephen> XEmacs except us developers, though.
OK. For a major version bump you are probably right that it might be
too subtle with just the license change. As a developer I can live
with a tag and minor version from which we are GPLv3. OK? Go for that!
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:12 a.m.
New subject: Release plans
> Regarding Re: Release plans; Mats Lidell <matsl(a)xemacs.org>
adds:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
Stephen> But to me "producing releases" is not a goal in
itself.
IMHO we don't need a five year plan at the moment. We
just need to plan the very next steps. My logic goes
like this...
The facts are that we have a repo with an almost done
GPLv3 or later that I would like to get out because I
think it will be beneficial for future development. I
hope you agree here. This is more or less the current
beta but with a license change. There are no bug fixes
or enhancement there. Only the license change.
So I am confused now. Do you mean the new release would be
fully GPLv3 compliant or not?
What's about 21.4 then?
I am asking this not only as a secret addict of 21.4, who I
sill am, but because of the package system.
I honestly can't wait to upgrade at least two packages.
- auctex. The 11.85 GPLv3 version has some important
bug fixes. Since I am the auctex pkg maintainer I
stick[1] to the official version but I am annoyed by its
bugs. (I hope David is not going to read this :-D)
- reftex. Here I couldn't stand the attic reftex
version of the official xemacs pkg and use a private version.
Now I admit my ignorance again in these license matters, but
it was my understanding that an upgrade of a pkg should wait
till we have sorted out the GPLv3 mess for Xemacs core and I
thought this was for 21.4 and 21.5.
But now what is the matter with older Xemacs releases: such 21.4
(and even 21.1 we you like)???
I like the idea of changing the version numbers for the
GPLv3 compliant versions.
Uwe Brauer
Footnotes:
[1] call me masochistic if you want
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:12 a.m.
New subject: Release plans
Uwe Brauer writes:
So I am confused now. Do you mean the new release would be
fully GPLv3 compliant or not?
Within a short time I will release the last beta in the 21.5 series
under GPLv2+ licensing. After that, all 21.5 and later versions will
be under GPLv3+.
What's about 21.4 then?
21.4 will remain under GPLv2+. That means you cannot *distribute*
GPLv3+ packages with it as a system.
From our point of view, the system is XEmacs 21.5 + packages. People
who wish to use 21.4 can continue to do so, with whatever packages,
including packages owned by Bill Gates himself and licensed under the
standard Microsoft EULA. They just can't redistribute that
combination without violating the GPL. (I'd worry more about
violating the MSFT EULA, myself. :-)
Now I admit my ignorance again in these license matters, but
it was my understanding that an upgrade of a pkg should wait
till we have sorted out the GPLv3 mess for Xemacs core
Yes.
and I thought this was for 21.4 and 21.5.
No. 21.5 only. If the FSF wants to bitch about 21.4, they can do so,
and we'll have to do something at that point. However, I don't think
they will as long as the mainline of XEmacs is GPLv3+, and we don't
release new versions of XEmacs 21.4, which I think is pretty likely.
21.1 is definitely unaffected because we will never release another
version of 21.1.
Julian Bradfield's friendly fork of 21.4 is not affected, of course,
because he does not distribute packages.
I like the idea of changing the version numbers for the
GPLv3 compliant versions.
I can only see bad things to come of that, unless the FSF forces us to
do it. The only people who will understand what the new version is
are the people who already understand. Everybody else will download
the latest and greatest version of XEmacs and discover that it's just
not ready for prime time. It will be years before anybody trusts an
XEmacs release to have had any quality assurance.
But maybe that's just me.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:28 a.m.
New subject: Release plans
> Regarding Re: Release plans; "Stephen J. Turnbull"
<stephen(a)xemacs.org> adds:
Uwe Brauer writes:
> So I am confused now. Do you mean the new release would be
> fully GPLv3 compliant or not?
Within a short time I will release the last beta in the 21.5 series
under GPLv2+ licensing. After that, all 21.5 and later versions will
be under GPLv3+.
> What's about 21.4 then?
21.4 will remain under GPLv2+. That means you cannot *distribute*
GPLv3+ packages with it as a system.
Well as I see it, then at least (K)ubuntu, Debian[1] which release for
the moment 21.4 as the standard Xemacs version[2], have to
change to 21.5. Do you think 21.5 is stable enough for mainstream?
BTW much more important: did the xsymbol-patch, you sent me
some time ago, enter into 21.5. It is a very important patch
:-D
Uwe
Footnotes:
[1] I don't know about other Linux distributions.
[2] I asked years ago whether Debian would consider to
release 21.5 in there unstable branch, but they refused.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:31 p.m.
New subject: Release plans
On Fri, Feb 18, 2011 at 4:28 AM, Uwe Brauer <oub(a)mat.ucm.es> wrote:
Well as I see it, then at least (K)ubuntu, Debian[1] which release
for
the moment 21.4 as the standard Xemacs version[2], have to
change to 21.5. Do you think 21.5 is stable enough for mainstream?
Fedora has been shipping 21.5 since early 2006. Ville was the Fedora
package maintainer at that time. He passed the maintainer hat to me
in summer of 2009. I've had a few bug reports, but not an unusually
large number.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:36 a.m.
New subject: Release plans
On 2/18/11 6:28 AM, Uwe Brauer wrote:
Well as I see it, then at least (K)ubuntu, Debian[1] which release for
the moment 21.4 as the standard Xemacs version[2], have to
change to 21.5. Do you think 21.5 is stable enough for mainstream?
I've been using 21.5 ever since it came out, and beta 29 ever since.
There have been a few occasional crashes, but not anymore than 21.4.
BTW much more important: did the xsymbol-patch, you sent me
some time ago, enter into 21.5. It is a very important patch
:-D
We all have our favorite fixes. :-) Mine would be a fix to comint that
fixes an issue with slime. (It's a two-line change, changing (point) to
(point-marker).)
I'd also like to see emacs autodoc included. I've been using the latest
GPL v2 version with xemacs without any changes, it's been working just
fine. (Really nice with slime.)
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:26 a.m.
New subject: Release plans
Raymond Toy writes:
We all have our favorite fixes. :-) Mine would be a fix to comint
that
fixes an issue with slime. (It's a two-line change, changing (point) to
(point-marker).)
Tracker issue, si'l vous plait. For "two-line changes" (ie, for
values of "two" up to about "10" :-), patch can be uploaded as a
.diff, or simply pasted into the comment box. For larger changes,
please upload a diff.
I'd also like to see emacs autodoc included. I've been using
the latest
GPL v2 version with xemacs without any changes, it's been working just
fine. (Really nice with slime.)
Seems to me this would be better added to the packages. Do you know
if it works OK with 21.4? If it's "core" enough, it can go into the
xemacs-base package, I think, so you don't need to offer to maintain
it. If that sounds right to you, file an issue against the
xemacs-base component in the tracker, and upload the relevant file(s)
to the issue.
Of course, you can also wait for me or Mike or somebody to get around
to it, but I'm getting old enough to have memory problems. (See, I've
already forgotten how many requests I've forgotten in the past!)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:01 p.m.
New subject: Release plans
On 2/19/11 2:26 AM, Stephen J. Turnbull wrote:
Raymond Toy writes:
> We all have our favorite fixes. :-) Mine would be a fix to comint that
> fixes an issue with slime. (It's a two-line change, changing (point) to
> (point-marker).)
Tracker issue, si'l vous plait. For "two-line changes" (ie, for
values of "two" up to about "10" :-), patch can be uploaded as a
.diff, or simply pasted into the comment box. For larger changes,
please upload a diff.
I don't think I wrote up a tracker because Aidan very quickly wrote a
patch and fix for that. I don't have a link for the message, but the
subject is "comint-replace-by-expanded-filename and Slime", Aug 23,
2010, on xemacs-beta.
> I'd also like to see emacs autodoc included. I've been using the latest
> GPL v2 version with xemacs without any changes, it's been working just
> fine. (Really nice with slime.)
Seems to me this would be better added to the packages. Do you know
if it works OK with 21.4? If it's "core" enough, it can go into the
See bug 730, which says I did test it on 21.4 and it worked ok. It's
currently in the xemacs-devel package.
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:09 p.m.
New subject: Release plans
Raymond Toy writes:
On 2/19/11 2:26 AM, Stephen J. Turnbull wrote:
> Raymond Toy writes:
> > I'd also like to see emacs autodoc included. I've
been using the latest
> > GPL v2 version with xemacs without any changes, it's been working just
> > fine. (Really nice with slime.)
>
> Seems to me this would be better added to the packages. Do you know
> if it works OK with 21.4? If it's "core" enough, it can go into the
See bug 730, which says I did test it on 21.4 and it worked ok. It's
currently in the xemacs-devel package.
I don't understand. What do you want it included in, then, if it's
already in the packages?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:57 p.m.
New subject: Release plans
On 2/19/11 10:09 AM, Stephen J. Turnbull wrote:
Raymond Toy writes:
> On 2/19/11 2:26 AM, Stephen J. Turnbull wrote:
> > Raymond Toy writes:
> > > I'd also like to see emacs autodoc included. I've been using
the latest
> > > GPL v2 version with xemacs without any changes, it's been working
just
> > > fine. (Really nice with slime.)
> >
> > Seems to me this would be better added to the packages. Do you know
> > if it works OK with 21.4? If it's "core" enough, it can go into
the
>
> See bug 730, which says I did test it on 21.4 and it worked ok. It's
> currently in the xemacs-devel package.
I don't understand. What do you want it included in, then, if it's
already in the packages?
Sorry, that's the old version of eldoc which doesn't work with slime.
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:07 a.m.
New subject: Release plans
> On Fri, 18 Feb 2011 22:36:09 -0500, Raymond Toy
<toy.raymond(a)gmail.com> wrote:
Raymond> On 2/18/11 6:28 AM, Uwe Brauer wrote:
>
> BTW much more important: did the xsymbol-patch, you
> sent me some time ago, enter into 21.5. It is a very
> important patch
> :-D
Raymond> We all have our favorite fixes. :-) Mine would
Raymond> be a fix to comint that fixes an issue with
Raymond> slime. (It's a two-line change, changing
Raymond> (point) to (point-marker).)
Well yeah, but I think it is fair to separate C fixes from
lisp fixes. Lisp fixes you can additionally load, while for C
fixes you have to recompile the whole beast.
The X-symbol fix is a C fix.
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:19 a.m.
New subject: Release plans
Uwe Brauer writes:
Well as I see it, then at least (K)ubuntu, Debian[1] which release
for
the moment 21.4 as the standard Xemacs version[2], have to
change to 21.5.
Not until there are GPLv3+ packages, of which there are none
currently.
But this is their problem, and their lawyers may advise them that 21.4
XEmacs + GPLv3+ packages is "mere aggregation" for them. I know a few
people (including me) who use Debian packages for the packages but
build 21.5 from source since Debian doesn't provide it AFAIK.
XEmacs can't make that claim, though, because we develop both and
clearly intend them as a system.
Do you think 21.5 is stable enough for mainstream?
Stable enough, probably. Sufficient quality, no. Mike has a rather
different opinion, though.
BTW much more important: did the xsymbol-patch, you sent me
some time ago, enter into 21.5. It is a very important patch
:-D
Not that I know of. Is there an issue in the tracker for it? If
there is, I'll eventually get around to checking it, and if unapplied
by then, reviewing it, if nobody else does.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:10 a.m.
New subject: Release plans
> On Sat, 19 Feb 2011 16:19:18 +0900, "Stephen J.
Turnbull" <stephen(a)xemacs.org> wrote:
Stephen> Uwe Brauer writes:
> Well as I see it, then at least (K)ubuntu, Debian[1]
> which release for the moment 21.4 as the standard
> Xemacs version[2], have to change to 21.5.
Stephen> Not until there are GPLv3+ packages, of which
Stephen> there are none currently.
Right.
Stephen> But this is their problem, and their lawyers may
Stephen> advise them that 21.4 XEmacs + GPLv3+ packages
Stephen> is "mere aggregation" for them. I know a few
Stephen> people (including me) who use Debian packages
Stephen> for the packages but build 21.5 from source
Stephen> since Debian doesn't provide it AFAIK.
Strange I did the opposite take their Xemacs core and
downloaded the latest packages since debians xemacs packages
where outdated.
> BTW much more important: did the xsymbol-patch, you
> sent me some time ago, enter into 21.5. It is a very
> important patch
> :-D
Stephen> Not that I know of. Is there an issue in the
Stephen> tracker for it? If there is, I'll eventually
Stephen> get around to checking it, and if unapplied by
Stephen> then, reviewing it, if nobody else does.
Now I did not do anything with respect to the tracker. I try
this now.
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:41 a.m.
New subject: Release plans
Uwe Brauer writes:
Stephen> But this is their problem, and their lawyers may
Stephen> advise them that 21.4 XEmacs + GPLv3+ packages
Stephen> is "mere aggregation" for them. I know a few
Stephen> people (including me) who use Debian packages
Stephen> for the packages but build 21.5 from source
Stephen> since Debian doesn't provide it AFAIK.
Strange I did the opposite take their Xemacs core and
downloaded the latest packages since debians xemacs packages
where outdated.
That works as evidence for "mere aggregation" too! :-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:50 a.m.
New subject: Release plans
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Uwe Brauer writes:
> Stephen> But this is their problem, and their lawyers may
> Stephen> advise them that 21.4 XEmacs + GPLv3+ packages
> Stephen> is "mere aggregation" for them. I know a few
> Stephen> people (including me) who use Debian packages
> Stephen> for the packages but build 21.5 from source
> Stephen> since Debian doesn't provide it AFAIK.
>
> Strange I did the opposite take their Xemacs core and
> downloaded the latest packages since debians xemacs packages
> where outdated.
That works as evidence for "mere aggregation" too! :-)
Using the same Elisp files for Emacs and XEmacs should help in that
department as well.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:24 a.m.
New subject: Release plans
> On Sat, 19 Feb 2011 16:19:18 +0900, "Stephen J.
Turnbull" <stephen(a)xemacs.org> wrote:
Stephen> Not that I know of. Is there an issue in the
Stephen> tracker for it? If there is, I'll eventually
Stephen> get around to checking it, and if unapplied by
Stephen> then, reviewing it, if nobody else does.
Ok it is issue 752
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:42 a.m.
New subject: Release plans
Uwe Brauer writes:
>> On Sat, 19 Feb 2011 16:19:18 +0900, "Stephen J.
Turnbull" <stephen(a)xemacs.org> wrote:
Stephen> Not that I know of. Is there an issue in the
Stephen> tracker for it?
Ok it is issue 752
Thanks!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:24 a.m.
New subject: Release plans
> Regarding Re: Release plans; "Stephen J. Turnbull"
<stephen(a)xemacs.org> adds:
Uwe Brauer writes:
Not until there are GPLv3+ packages, of which there are none
currently.
BTW how is the transition from GPLv2+ to GPLv3+ for the
package system supposed to work?
I suppose we need a branch at some point, since we are not
going to change the license of _all_ packages at once, and
we can't release some packages with GPLv3+ and others with
GPLv2+.
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:27 a.m.
New subject: Release plans
Uwe Brauer <oub(a)mat.ucm.es> writes:
>> Regarding Re: Release plans; "Stephen J. Turnbull"
> <stephen(a)xemacs.org> adds:
> Uwe Brauer writes:
> Not until there are GPLv3+ packages, of which there are none
> currently.
BTW how is the transition from GPLv2+ to GPLv3+ for the
package system supposed to work?
I suppose we need a branch at some point, since we are not
going to change the license of _all_ packages at once, and
we can't release some packages with GPLv3+ and others with
GPLv2+.
GPLv2+ should be unproblematic I think. GPLv2 would be troublesome.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:30 p.m.
New subject: Release plans
Uwe Brauer writes:
>> Regarding Re: Release plans; "Stephen J. Turnbull"
<stephen(a)xemacs.org> adds:
> Uwe Brauer writes:
> Not until there are GPLv3+ packages, of which there are none
> currently.
BTW how is the transition from GPLv2+ to GPLv3+ for the
package system supposed to work?
People who have packages to migrate will do so as they sync the code.
I suppose we need a branch at some point, since we are not
going to change the license of _all_ packages at once,
As a practical matter, probably not (especially not if upstream is
still active but developing under GPLv2+). But there's no reason not
to, except for the effort involved.
I guess I would like it if Norbert would roll a "last GPLv2-compatible
SUMO" that we can recommend as appropriate for 21.4 users just before
we start migrating packages to GPLv3+. But we can always just use the
latest available one.
and we can't release some packages with GPLv3+ and others with
GPLv2+.
I don't think this is really a problem. Individual components can
have more permissive licenses as long as the whole is distributable
under GPLv3+. It's not even certain that the SUMO must be distributed
under GPLv3+ just because it includes a GPLv3+ package (it might pass
as "mere aggregation").
So in fact it's not obvious to me that we *must* migrate 21.5 to
GPLv3+ before migrating packages. But it seem somewhat less likely to
annoy the FSF, and we want to do this anyway so we can sync 21.5 to
recent GNU Emacs.
The only real issue is that if we migrate something like semantic to
GPLv3+, then anything that depends on it needs to be GPLv3+
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:03 p.m.
New subject: Release plans
> Regarding Re: Release plans; "Stephen J. Turnbull"
<stephen(a)xemacs.org> adds:
Uwe Brauer writes:
> >> Regarding Re: Release plans; "Stephen J. Turnbull"
> >> <stephen(a)xemacs.org> adds:
So in fact it's not obvious to me that we *must*
migrate 21.5 to GPLv3+ before migrating packages. But
it seem somewhat less likely to annoy the FSF, and we
want to do this anyway so we can sync 21.5 to recent
GNU Emacs.
Well I trust your judgment in these matters. Whenever you
give me green light I start to upgrade auctex and reftex.
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:56 p.m.
New subject: Release plans
Michael Sperber writes:
The reason why I advocated branching after GPLv3 is that I expect
more
aggressive development after that.
BTW, it occurs to me that there's really no point in doing this until
we have a release date in mind -- hg can rewind to anywhere we want
and branch from there ex post.
In particular, I intend doing both pre- and post-GPLv3-merge betas.
The former for the sake of 21.4 and Julian, and the latter because it
will be easy to do (the tedious parts of doing a release are (1)
getting a build and (2) writing the release notes, both of which
should be trivial post-GPLv3 given a pre-GPLv3 release) and seems like
a good checkpoint. So at any later date we can choose to base stable
on GPLv3-tag, or on GPLv3 plus low- hanging-fruit syncs (which are the
ones I think are likely to get committed first, anyway. WDYT?)
So this is a good time to branch off for stability.
Do you still think that given the above discussion? Or is there
something I'm still missing?
Ciao,
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:36 p.m.
New subject: Release plans
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Michael Sperber writes:
> The reason why I advocated branching after GPLv3 is that I expect more
> aggressive development after that.
BTW, it occurs to me that there's really no point in doing this until
we have a release date in mind -- hg can rewind to anywhere we want
and branch from there ex post.
In particular, I intend doing both pre- and post-GPLv3-merge betas.
The former for the sake of 21.4 and Julian, and the latter because it
will be easy to do (the tedious parts of doing a release are (1)
getting a build and (2) writing the release notes, both of which
should be trivial post-GPLv3 given a pre-GPLv3 release) and seems like
a good checkpoint. So at any later date we can choose to base stable
on GPLv3-tag, or on GPLv3 plus low- hanging-fruit syncs (which are the
ones I think are likely to get committed first, anyway. WDYT?)
> So this is a good time to branch off for stability.
Do you still think that given the above discussion? Or is there
something I'm still missing?
It's a process question: If you branch off later, you'll have aggressive
development and bug fixes mixed, and that can't be easily separated
after the fact.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:23 a.m.
New subject: Release plans
Michael Sperber writes:
It's a process question: If you branch off later, you'll have
aggressive
development and bug fixes mixed, and that can't be easily separated
after the fact.
I don't understand. Perhaps the code committed in post-GPLv3
revisions will be hard to include for the reason you give, but you can
still conveniently work around those revisions by branching from an
earlier version at any date. It seems to me that it's a better idea
to make the decision which version to branch from *after* seeing the
later development, rather than possibly creating a dead branch early
because we later realize that "oh, we should include all this good
stuff" and go create another release branch.
There will be bug fixes mixed in with the aggressive development in
any case (unless you close the development branch). I would rather
not have to watch both branches for bug fixes and be cherrypicking
(*not* merging! only Darcs can merge individual patches, all other
VCSes lose dependency and conflict information[1]) in both directions.
Footnotes:
[1] It's possible that svnmerge.py could be adapted to Mercurial, but
according to the folks working on Python's migration to Mercurial it
hasn't been done yet. This would mitigate the problem, but add a
burden of new process.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:43 a.m.
New subject: Release plans
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Michael Sperber writes:
> It's a process question: If you branch off later, you'll have aggressive
> development and bug fixes mixed, and that can't be easily separated
> after the fact.
I don't understand. Perhaps the code committed in post-GPLv3
revisions will be hard to include for the reason you give, but you can
still conveniently work around those revisions by branching from an
earlier version at any date.
But then, if stability is your goal, you'll need to cherry-pick the bug
fixes. (And, if that hasn't been clear, that's all *I* want from a
release - a bunch of bugs fixed.)
There will be bug fixes mixed in with the aggressive development in
any case (unless you close the development branch).
Sure. But cherrypicking to the stable branch and appropriately merging
back into the development branch is pretty straightforward. It's what
other projects do. (For example, Mercurial itself.) I'd be happy to do
that, in fact.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:59 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
On 02/15/11 08:53 AM, Stephen J. Turnbull wrote:
If anybody wants to start publishing "top ten bugs that must be
fixed
for the release" or "top ten features that should be completed for the
release" lists, that would be a good start. But we don't even have
those lists yet; talking about a release plan is way premature IMHO,
especially with the only person regularly contributing patches being
Aidan, and the work he's doing is not useful in moving toward a
release IMO. (That is not to say I think Aidan "should" do something
else; just that we need more promises of manpower, and a do-able list
of tasks to apply it to, before thinking about schedules and such.)
I don't have a top ten, but I have a top 1! We are switching to RHEL
and I tried Jerry James very nice package for xemacs-beta. But, Bug 411
bit me immediately and I'm installing stable by hand instead.
Rodney
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:15 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
On Wed, Feb 23, 2011 at 11:59 AM, Rodney Sparapani <rsparapa(a)mcw.edu> wrote:
I don't have a top ten, but I have a top 1! We are switching to
RHEL
and I tried Jerry James very nice package for xemacs-beta. But, Bug 411
bit me immediately and I'm installing stable by hand instead.
Rodney
Don't give me credit! Ville did the initial work of setting up the
Fedora package, and maintained it for several years. I'm just the
current maintainer. Also, XEmacs isn't in RHEL, but it is in EPEL.
That version is maintained by Steve Traylen.
As for bug 411 ... hmmm, that custom-set-faces invocation actually
seems to work for me on Fedora 14. Can you give me the version of
RHEL and the rpm version of XEmacs that you are using?
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:39 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
On 02/23/11 01:15 PM, Jerry James wrote:
On Wed, Feb 23, 2011 at 11:59 AM, Rodney
Sparapani<rsparapa(a)mcw.edu> wrote:
> I don't have a top ten, but I have a top 1! We are switching to RHEL
> and I tried Jerry James very nice package for xemacs-beta. But, Bug 411
> bit me immediately and I'm installing stable by hand instead.
>
> Rodney
Don't give me credit! Ville did the initial work of setting up the
Fedora package, and maintained it for several years. I'm just the
current maintainer. Also, XEmacs isn't in RHEL, but it is in EPEL.
That version is maintained by Steve Traylen.
As for bug 411 ... hmmm, that custom-set-faces invocation actually
seems to work for me on Fedora 14. Can you give me the version of
RHEL and the rpm version of XEmacs that you are using?
It's
xemacs-21.5.29-12.el5.1.x86_64
<http://download.fedora.redhat.com/pub/epel/5/x86_64/xemacs-21.5.29-12.el5...
--
Rodney Sparapani Center for Patient Care and Outcomes Research
Sr. Biostatistician http://www.mcw.edu/pcor
4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW)
WWLD?: What Would Lombardi Do? Milwaukee, WI, USA
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:17 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
On 02/23/11 01:39 PM, Rodney Sparapani wrote:
It's xemacs-21.5.29-12.el5.1.x86_64
<http://download.fedora.redhat.com/pub/epel/5/x86_64/xemacs-21.5.29-12.el5...
I don't if this is part of the bug or not. But, there is also
something weird with how it interacts with .emacs If you say
that you don't want to migrate .emacs then it writes the
custom.el font settings in .emacs
--
Rodney Sparapani Center for Patient Care and Outcomes Research
Sr. Biostatistician http://www.mcw.edu/pcor
4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW)
WWLD?: What Would Lombardi Do? Milwaukee, WI, USA
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:25 a.m.
New subject: Release plans [was: Building packages with 21.5b29?]
Rodney Sparapani <rsparapa(a)mcw.edu> writes:
On 02/23/11 01:39 PM, Rodney Sparapani wrote:
>
> It's xemacs-21.5.29-12.el5.1.x86_64
>
<http://download.fedora.redhat.com/pub/epel/5/x86_64/xemacs-21.5.29-12.el5...
I don't if this is part of the bug or not. But, there is also
something weird with how it interacts with .emacs If you say
that you don't want to migrate .emacs then it writes the
custom.el font settings in .emacs
If XEmacs still has the habit of destroying your .emacs file when you
start it even once, that is not going to win it points from Emacs users
taking it for a test drive.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:26 a.m.
New subject: Release plans [was: Building packages with 21.5b29?]
David Kastrup writes:
Rodney Sparapani <rsparapa(a)mcw.edu> writes:
> On 02/23/11 01:39 PM, Rodney Sparapani wrote:
>>
>> It's xemacs-21.5.29-12.el5.1.x86_64
>>
<http://download.fedora.redhat.com/pub/epel/5/x86_64/xemacs-21.5.29-12.el5...
> I don't if this is part of the bug or not. But, there is also
> something weird with how it interacts with .emacs If you say
> that you don't want to migrate .emacs then it writes the
> custom.el font settings in .emacs
This is only if you tell custom to save customizations. Last I heard,
Emacs writes *all* customizations to .emacs, not to a special custom-
only file (but I haven't paid much attention to Emacs's customize
facilities since the bug described below was fixed). So that's what I
would *expect* to happen if I (a) tell XEmacs not to migrate and (b)
proceed to customize and save customizations.
What do you expect it to do? What do you want it to do, if that's
different from what you might expect?
If XEmacs still has the habit of destroying your .emacs file when
you
start it even once, that is not going to win it points from Emacs users
taking it for a test drive.
No, XEmacs has the habit of doing what it is told to do by the user.
A user doing a "test drive" without migrating code from .emacs to
.xemacs/init.el should not be saving customizations AFAICS. Why would
she?
There was indeed a bug where if there was GNU-Emacs-specific code that
caused an error during the migration process, then the reading of the
customizations was aborted, but XEmacs would write the incomplete
customizations out to the specified file later upon request to save.
This could happen without the migration process as well, but the
migration process made it very likely that the user would save the
broken file, overwriting the good customizations. However, that was
fixed within a few days of release, just about 10 years ago. And in
fact that whole release was withdrawn and deprecated (over the
objections of other reviewers, sad to say, but it was withdrawn and
deprecated).
And in any case it required a specific request from the user to save
customizations. This is a serious design bug in Customize as
implemented by Per (ie, that the file is completely rewritten to save
any one change). I don't know if Emacs does it differently these
days, but in 2001 it was possible to get the same behavior from Emacs.
Of course it was much less likely, because if customizations were
broken enough to interrupt the initialization process, the user would
be aware, and probably would fix the initialization process by hand
without doing custom-save-all. By contrast the migration process
would blithely ask the user if he wanted to save despite the failed
initialization. As the reporter admitted, "if I had been thinking I
would have known better than to save anything since I hadn't done
anything I wanted to save", but it's equally true that if Emacs
initialization blows up in your face, you're probably not thinking
very clearly.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:19 a.m.
New subject: Release plans [was: Building packages with 21.5b29?]
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
> Rodney Sparapani <rsparapa(a)mcw.edu> writes:
>
> > On 02/23/11 01:39 PM, Rodney Sparapani wrote:
> >>
> >> It's xemacs-21.5.29-12.el5.1.x86_64
> >>
<http://download.fedora.redhat.com/pub/epel/5/x86_64/xemacs-21.5.29-12.el5...
> > I don't if this is part of the bug or not. But, there is also
> > something weird with how it interacts with .emacs If you say
> > that you don't want to migrate .emacs then it writes the
> > custom.el font settings in .emacs
This is only if you tell custom to save customizations.
It wasn't the last time I was bitten by it (long time ago). Something
was saved without explicit request IIRC. Anyway, it seems like a good
idea to figure out what happened with Rodney's installation.
Last I heard, Emacs writes *all* customizations to .emacs, not to a
special custom- only file (but I haven't paid much attention to
Emacs's customize facilities since the bug described below was fixed).
So that's what I would *expect* to happen if I (a) tell XEmacs not to
migrate and (b) proceed to customize and save customizations.
What do you expect it to do? What do you want it to do, if that's
different from what you might expect?
Look, this is a user interface trap. You ask the user whether he should
migrate .emacs. Now we imagine an Emacs user who is just taking XEmacs
for a test ride. You ask him whether you should do an obscure operation
("migrate the .emacs file"). He is just testing and does not want
permanent changes to his Emacs configuration. He does not know what
"migration" involves and whether it might render his Emacs useless. So
to be on the safe side, he says "no" and continues.
Unfortunately, the safe side is the other one. Questions that better
match the expectations and behavior of users:
"Should I attempt read/write sharing of your .emacs (not recommended)"
No-> "Should I attempt to copy your Emacs configuration?"
Yes-> "Should I make this selection permanent?"
If you say Yes, create a .xemacs/init.el file that just loads the Emacs
custom file. So if you at one point delete your .xemacs directory, you
are back to square one, modulo any customizations that landed in .emacs
when saving from XEmacs.
> If XEmacs still has the habit of destroying your .emacs file
when you
> start it even once, that is not going to win it points from Emacs users
> taking it for a test drive.
No, XEmacs has the habit of doing what it is told to do by the user.
After asking him loaded questions.
A user doing a "test drive" without migrating code from
.emacs to
.xemacs/init.el should not be saving customizations AFAICS. Why would
she?
See above. Accident waiting to happen. And if it does happen, it is a
rather awful introduction of XEmacs. Being burnt like that, people
won't try XEmacs a second time.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:28 a.m.
New subject: Release plans [was: Building packages with 21.5b29?]
David Kastrup writes:
It wasn't the last time I was bitten by it (long time ago).
Something
was saved without explicit request IIRC.
Well, if so, that's a bug. But I've reviewed that code several times
(long ago), and don't know how that could happen. So ... without a
reproduction recipe ... I'm stuck.
Anyway, it seems like a good idea to figure out what happened with
Rodney's installation.
Yes, but given my state of knowledge, I'm going to need more
information from the people who have seen misbehavior.
Look, this is a user interface trap. You ask the user whether he
should
migrate .emacs. Now we imagine an Emacs user who is just taking XEmacs
for a test ride. You ask him whether you should do an obscure operation
("migrate the .emacs file"). He is just testing and does not want
permanent changes to his Emacs configuration. He does not know what
"migration" involves and whether it might render his Emacs useless.
Thing is, as currently structured, any attempt to save customizations
could do that, because it rewrites the whole file and doesn't keep
backups. So what it comes down to is that in the past migration had a
bad bug. Maybe it does now, too, but I don't know about it yet.
So to be on the safe side, he says "no" and continues.
Unfortunately, the safe side is the other one.
Not as far as I know. Despite this report, the jury is still out
until I know how it happened.
Questions that better match the expectations and behavior of users:
"Should I attempt read/write sharing of your .emacs (not recommended)"
No-> "Should I attempt to copy your Emacs configuration?"
Yes-> "Should I make this selection permanent?"
If you say Yes, create a .xemacs/init.el file that just loads the Emacs
custom file. So if you at one point delete your .xemacs directory, you
are back to square one, modulo any customizations that landed in .emacs
when saving from XEmacs.
Er, AFAIK that's precisely what happens if you migrate, except that no
Custom customizations will land in .emacs at all, which goes one
better, since you can't screw up Emacs with XEmacs-specific
customizations unless you write code yourself, which generally (though
not always) indicates you know enough about what you're doing to save
yourself.
> No, XEmacs has the habit of doing what it is told to do by the
user.
After asking him loaded questions.
What's loaded about the question? Really, David, a bug is a bug. If
you don't want bugs in your software to ever destroy your data, don't
turn the workstation on.
> A user doing a "test drive" without migrating code
from .emacs to
> .xemacs/init.el should not be saving customizations AFAICS. Why would
> she?
See above. Accident waiting to happen.
How? As I said, it theoretically *can* happen in normal usage,
because of the way customize behaves when saving. Isn't that an
accident waiting to happen, too? Should we disable customize and
force users to write all customizations by hand in Lisp?
And if it does happen, it is a rather awful introduction of XEmacs.
Being burnt like that, people won't try XEmacs a second time.
Well, yes, I know that. On the other hand, the judgment of the folks
who made the decision was that people who have lots of customizations
won't try XEmacs without some help in migrating their customizations.
I'm not going to second-guess them until I have reason to believe that
bad things are definitely happening.
Messing with somebody's init files is definitely a Bad Thing, and most
users would go farther, it's a VERY BAD THING. If this were happening
very often, I would think we would have heard about it. But in fact
this is the first report since Alan Mackenzie's that I can remember.
Maybe I missed yours.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:08 a.m.
New subject: Release plans [was: Building packages with 21.5b29?]
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
> It wasn't the last time I was bitten by it (long time ago). Something
> was saved without explicit request IIRC.
Well, if so, that's a bug. But I've reviewed that code several times
(long ago), and don't know how that could happen. So ... without a
reproduction recipe ... I'm stuck.
This was just anecdotal evidence of something that happened a long time
ago and that could or could not happen nowadays as far as I know.
Certainly nothing sufficient to take action on. Rodney's experience is
much more current and:
> Anyway, it seems like a good idea to figure out what happened
with
> Rodney's installation.
Yes, but given my state of knowledge, I'm going to need more
information from the people who have seen misbehavior.
Let's hope you get it.
> Look, this is a user interface trap. You ask the user whether
he should
> migrate .emacs. Now we imagine an Emacs user who is just taking XEmacs
> for a test ride. You ask him whether you should do an obscure operation
> ("migrate the .emacs file"). He is just testing and does not want
> permanent changes to his Emacs configuration. He does not know what
> "migration" involves and whether it might render his Emacs useless.
Thing is, as currently structured, any attempt to save customizations
could do that, because it rewrites the whole file and doesn't keep
backups. So what it comes down to is that in the past migration had a
bad bug. Maybe it does now, too, but I don't know about it yet.
> So to be on the safe side, he says "no" and continues.
>
> Unfortunately, the safe side is the other one.
Not as far as I know. Despite this report, the jury is still out
until I know how it happened.
"Safe" does not mean "I think we got sufficient code review to hazard a
guess that nothing bad happens when we rewrite the files created by
Emacs under normal circumstances" but rather "we don't rewrite files
created by Emacs" in my book. That's the safe option. Everything else
is optimistic (which is pretty much the same as delusionary with regard
to software development).
Using terms like like "migrate" which imply some irreversible action
(when in fact it is the manner to get _reversible_ behavior by confining
XEmacs' actions to a newly created directory rather than letting it
meddle with existing files if you don't watch your step) is letting the
user pick the wrong option for his intent.
> Questions that better match the expectations and behavior of
users:
>
> "Should I attempt read/write sharing of your .emacs (not recommended)"
> No-> "Should I attempt to copy your Emacs configuration?"
> Yes-> "Should I make this selection permanent?"
>
> If you say Yes, create a .xemacs/init.el file that just loads the Emacs
> custom file. So if you at one point delete your .xemacs directory, you
> are back to square one, modulo any customizations that landed in .emacs
> when saving from XEmacs.
Er, AFAIK that's precisely what happens if you migrate, except that no
Custom customizations will land in .emacs at all, which goes one
better, since you can't screw up Emacs with XEmacs-specific
customizations unless you write code yourself, which generally (though
not always) indicates you know enough about what you're doing to save
yourself.
I am explaining to you how to avoid letting the user pick the choice
that has prospectively unwanted consequences for him, and you keep
telling me that everything is working as intended.
The problem is that the _user_ is not working as intended.
Unfortunately, there is no bug database for users, and XEmacs depends on
the user as a critical component in order to be of any use.
So you need to include a workaround in XEmacs to deal with the flaws in
the implementation of the user as he is a required component, but you
don't have access to his source code.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:15 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
David Kastrup writes:
> Yes, but given my state of knowledge, I'm going to need
more
> information from the people who have seen misbehavior.
Let's hope you get it.
"Why, David, I didn't know you cared!"
"Safe" does not mean "I think we got sufficient code
review to hazard a
guess that nothing bad happens when we rewrite the files created by
Emacs under normal circumstances" but rather "we don't rewrite files
created by Emacs" in my book.
But XEmacs is just as much Emacs as, say, Emacs 24, and more so than
Emacs 25 is. Nor is .emacs "created" by Emacs; it's explicitly
intended to be edited by the user, and should not be present in a
brand new installation.
That's the safe option.
Which AFAIK Emacs itself doesn't respect, and never did, by design.
Using terms like like "migrate" which imply some
irreversible
action
Not at all in my dialect (migratory birds, fish, and whales, nyet?),
but I'll take yours into consideration.
I am explaining to you how to avoid letting the user pick the choice
that has prospectively unwanted consequences for him, and you keep
telling me that everything is working as intended.
No, I'm telling you I don't understand what you're trying to tell me,
because from where I sit it *looks* like things are working as
intended, and pretty much as you say. I know that I'm missing
something, while you seem to think you know what you're talking about,
so I'm going to tell you how things look to me and let you tell me
what's different for you.
The problem is that the _user_ is not working as intended.
Well, yes, but I don't know what the user is doing yet, and as far as
I can tell from what's been said so far the only thing wrong is that
the user thinks something's wrong. OK, I'm listening, but I can't
help until I can figure out what's going wrong.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:28 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
On 02/24/11 07:15 AM, Stephen J. Turnbull wrote:
But XEmacs is just as much Emacs as, say, Emacs 24, and more so than
Emacs 25 is. Nor is .emacs "created" by Emacs; it's explicitly
intended to be edited by the user, and should not be present in a
brand new installation.
Let me jump in. So, RHEL "helpfully" creates an .emacs for you
automagically?!? That caught me off guard since I had never used
Emacs on the machine which we just turned on Monday.
Well, yes, but I don't know what the user is doing yet, and as
far as
I can tell from what's been said so far the only thing wrong is that
the user thinks something's wrong. OK, I'm listening, but I can't
help until I can figure out what's going wrong.
You were right earlier. I did save the customizations just like you
do in Issue 411. But, since I didn't migrate, the customizations
went into .emacs Since I am not a heavy Emacs customize user, that
caught me off guard as well; I didn't know Emacs did that.
But, I would recommend not looking at .emacs at all and not attempt to
migrate it. That's what SXEmacs does as I understand it and I think
that's best. And, that would prevent some of these mis-conceptions.
Rodney
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:14 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
Rodney Sparapani writes:
Let me jump in. So, RHEL "helpfully" creates an .emacs for
you
automagically?!?
Hang on a sec. Are you sure there was a .emacs *before* you started
XEmacs? It's possible that there's a bug and XEmacs decides that a
non-existent file needs to be migrated or something silly like that.
It's also possible that RHEL's .emacs is a dummy file filled with
sample code that is commented out or something like that.
(Don't worry about it if you're not sure, Jerry probably knows.)
You were right earlier. I did save the customizations just like you
do in Issue 411. But, since I didn't migrate, the customizations
went into .emacs Since I am not a heavy Emacs customize user, that
caught me off guard as well; I didn't know Emacs did that.
I don't know if it does any more.
But, I would recommend not looking at .emacs at all and not attempt
to
migrate it. That's what SXEmacs does as I understand it and I think
that's best. And, that would prevent some of these mis-conceptions.
Well, OK.
This code was written in 1999 or 2000, I think, and at that time
XEmacs was much more compatible with GNU Emacs. Then it made a lot of
sense for halfway experts to try to share, and at least some sense to
try to help them out in the migration process. Now, even though
there's probably some sense to sharing for *some* people, it probably
should be 100% manual.
Mike?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:40 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
On Thu, Feb 24, 2011 at 9:14 AM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
Rodney Sparapani writes:
> Let me jump in. So, RHEL "helpfully" creates an .emacs for you
> automagically?!?
Hang on a sec. Are you sure there was a .emacs *before* you started
XEmacs? It's possible that there's a bug and XEmacs decides that a
non-existent file needs to be migrated or something silly like that.
It's also possible that RHEL's .emacs is a dummy file filled with
sample code that is commented out or something like that.
(Don't worry about it if you're not sure, Jerry probably knows.)
Yup. When a new user home dir is created, it is populated with the
dot files in /etc/skel. The .emacs in there has these contents:
;; .emacs
;;; uncomment this line to disable loading of "default.el" at startup
;; (setq inhibit-default-init t)
;; enable visual feedback on selections
;(setq transient-mark-mode t)
;; default to better frame titles
(setq frame-title-format
(concat "%b - emacs＠" (system-name)))
;; default to unified diffs
(setq diff-switches "-u")
;; always end a file with a newline
;(setq require-final-newline 'query)
I didn't realize that there is also an /etc/skel/.xemacs/init.el,
probably because I immediately overwrote it with my own init.el. It
has these contents:
;;; ~/.xemacs/init.el
;;; uncomment this line to disable loading of "default.el" at startup
;(setq inhibit-default-init t)
I wondered whether there is something in my .xemacs/{custom,init}.el
that makes the font saving and loading work. So I moved my .xemacs
directory out of the way, started XEmacs, chose a lucidatypewriter
14-point font, saved settings, restarted XEmacs, and got the
lucidatypewriter 14-point font.
Since it works for me both with no .xemacs directory at all and with
my own customizations, but doesn't work for you either way, the
difference must be in our systems. What have you got in
/usr/share/xemacs/site-packages/lisp/site-start.d?
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:24 p.m.
New subject: Release plans
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
This code was written in 1999 or 2000, I think, and at that time
XEmacs was much more compatible with GNU Emacs. Then it made a lot of
sense for halfway experts to try to share, and at least some sense to
try to help them out in the migration process. Now, even though
there's probably some sense to sharing for *some* people, it probably
should be 100% manual.
I don't know what qualifies as "fully manual". The migration assistant
does ask whether it should create an ".emacs compatibility file", and
only does that when you say yes (after having warned you about the
consequences first).
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:55 a.m.
New subject: Release plans
Michael Sperber writes:
I don't know what qualifies as "fully manual". The
migration assistant
does ask whether it should create an ".emacs compatibility file", and
only does that when you say yes (after having warned you about the
consequences first).
"Fully manual" means that XEmacs *copies* (not "moves") .emacs to
.xemacs/init.el and does nothing else. Well, perhaps adding a comment
that
;; This file is a copy of your old .emacs. If you wish to share
;; customizations between Emacs and XEmacs, you can create a separate
;; file such as .xemacs/shared.emacs and use `load' to execute it at
;; initialization time.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:39 a.m.
New subject: Release plans
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Michael Sperber writes:
> I don't know what qualifies as "fully manual". The migration
assistant
> does ask whether it should create an ".emacs compatibility file", and
> only does that when you say yes (after having warned you about the
> consequences first).
"Fully manual" means that XEmacs *copies* (not "moves") .emacs to
.xemacs/init.el and does nothing else. Well, perhaps adding a comment
that
That's what it does, essentially. It is complicated a bit by the
customization nightmare, though.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:16 a.m.
New subject: Release plans
Michael Sperber writes:
> "Fully manual" means that XEmacs *copies* (not
"moves") .emacs to
> .xemacs/init.el and does nothing else. Well, perhaps adding a comment
> that
That's what it does, essentially. It is complicated a bit by the
customization nightmare, though.
"A bit"??!!!
Look, as far as this goes at the moment, I'm basically with you; it's
not clear to me what problem really exists. But somehow people keep
finding ways to be unnerved by the process.
That's not good, and it's not something we should ignore, I think.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:14 a.m.
New subject: Release plans
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Michael Sperber writes:
> > "Fully manual" means that XEmacs *copies* (not "moves")
.emacs to
> > .xemacs/init.el and does nothing else. Well, perhaps adding a comment
> > that
>
> That's what it does, essentially. It is complicated a bit by the
> customization nightmare, though.
"A bit"??!!!
In the migration assistent, it's not all that much code. Of course,
what goes on underneath is hideous.
Look, as far as this goes at the moment, I'm basically with you;
it's
not clear to me what problem really exists. But somehow people keep
finding ways to be unnerved by the process.
That's not good, and it's not something we should ignore, I think.
Absolutely. But, as you've pointed out, reproducible recipes help.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:49 a.m.
New subject: Release plans
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Michael Sperber writes:
> I don't know what qualifies as "fully manual". The migration
assistant
> does ask whether it should create an ".emacs compatibility file", and
> only does that when you say yes (after having warned you about the
> consequences first).
"Fully manual" means that XEmacs *copies* (not "moves") .emacs to
.xemacs/init.el and does nothing else. Well, perhaps adding a comment
that
;; This file is a copy of your old .emacs. If you wish to share
;; customizations between Emacs and XEmacs, you can create a separate
;; file such as .xemacs/shared.emacs and use `load' to execute it at
;; initialization time.
It is likely a good idea to refuse even this if variables like
custom-file, user-init-file, user-emacs-directory are changed from their
default. At least if XEmacs interprets those variables.
Because otherwise loading the copied .emacs file is likely to ultimately
result in writes to original files anyway.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:05 p.m.
New subject: Release plans
David Kastrup writes:
It is likely a good idea to refuse even this if variables like
custom-file, user-init-file, user-emacs-directory are changed from their
default. At least if XEmacs interprets those variables.
Because otherwise loading the copied .emacs file is likely to ultimately
result in writes to original files anyway.
That's pure paranoia with no foundation in reality, David. Once those
variables are set (all of the logic for finding the init file is
hard-coded in the initialization), ~/.emacs is just another file to
XEmacs. There is no evidence whatsoever that (once configured) XEmacs
will make the mistake of setting user-init-file to "~/.emacs", in at
least 15 years of experience with init.el.
It's also true that the *user* may become confused *if* they try to
edit ~/.emacs in XEmacs. Again, that's perverse, not an easily-made
mistake, and XEmacs should not try to second-guess the user.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:36 p.m.
New subject: Release plans
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
> It is likely a good idea to refuse even this if variables like
> custom-file, user-init-file, user-emacs-directory are changed from their
> default. At least if XEmacs interprets those variables.
>
> Because otherwise loading the copied .emacs file is likely to ultimately
> result in writes to original files anyway.
That's pure paranoia with no foundation in reality, David.
Sigh. When the user has
(setq custom-file "~/.emacs.d/custom.el")
in his .emacs, and you copy/migrate this setting into ~/.xemacs/.emacs
(or whatever the migration is called), then XEmacs will save
customizations into ~/.emacs.d/custom.el.
Once those variables are set (all of the logic for finding the init
file is hard-coded in the initialization), ~/.emacs is just another
file to XEmacs. There is no evidence whatsoever that (once
configured) XEmacs will make the mistake of setting user-init-file to
"~/.emacs", in at least 15 years of experience with init.el.
I am not talking about what XEmacs might do of its own accord, but what
the "migrated" .emacs will make it do if you don't check that it does
not contain settings like that.
It's also true that the *user* may become confused *if* they try
to
edit ~/.emacs in XEmacs. Again, that's perverse, not an easily-made
mistake, and XEmacs should not try to second-guess the user.
Well, but it seems you could use some practice second-guessing users.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:42 a.m.
New subject: Release plans
David Kastrup writes:
Sigh. When the user has
(setq custom-file "~/.emacs.d/custom.el")
OK, you got me there. I didn't know Emacs supported that. (I also
don't know that migration doesn't check for that.)
Well, but it seems you could use some practice second-guessing users.
No. That is never a good idea.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:24 a.m.
New subject: Release plans
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
> Sigh. When the user has
>
> (setq custom-file "~/.emacs.d/custom.el")
OK, you got me there. I didn't know Emacs supported that. (I also
don't know that migration doesn't check for that.)
As long as XEmacs doesn't support it, there will be no problem.
> Well, but it seems you could use some practice second-guessing
users.
No. That is never a good idea.
Well, you are second-guessing that he is smart enough to deal with all
problems himself, no questions asked.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:29 a.m.
New subject: Release plans
David Kastrup writes:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> David Kastrup writes:
>
> > Sigh. When the user has
> >
> > (setq custom-file "~/.emacs.d/custom.el")
>
> OK, you got me there. I didn't know Emacs supported that. (I also
> don't know that migration doesn't check for that.)
As long as XEmacs doesn't support it, there will be no problem.
XEmacs has supported it for longer than I've used XEmacs
(unfortunately for those who might get caught by it).
> > Well, but it seems you could use some practice
second-guessing users.
>
> No. That is never a good idea.
Well, you are second-guessing that he is smart enough to deal with all
problems himself, no questions asked.
I apologize for my dig at Emacs, and ask that you try to be more
helpful. Specifically, in general, this is the way Emacsen do things
(assuming that users can deal with problems), except that questions of
course may be asked. As contentious as inter-developer discussions
can be, in my experience (mostly on XEmacs channels) Emacs people are
very helpful to users. So I stand by my statement that second-guessing
the user is a bad idea.
The problem here is that because (unlike pretty much everything else
in Emacs!) Customize saves destructively without an option for
backup(s), you only get one chance to get it right. That's hard!
Unless Mike pops up to say it's already handled, I'll file one bug
aginst the migration process to check that standard init files (at the
moment, .emacs and custom.el) are not overwritten ever, and another
aginst Customize to do something about backups. And make sure they
get fixed soon (before the GPLv3 release if possible).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:18 a.m.
New subject: Release plans
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
> "Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>
> > David Kastrup writes:
> >
> > > Sigh. When the user has
> > >
> > > (setq custom-file "~/.emacs.d/custom.el")
> >
> > OK, you got me there. I didn't know Emacs supported that. (I also
> > don't know that migration doesn't check for that.)
>
> As long as XEmacs doesn't support it, there will be no problem.
XEmacs has supported it for longer than I've used XEmacs
(unfortunately for those who might get caught by it).
> Well, you are second-guessing that he is smart enough to deal with
> all problems himself, no questions asked.
I apologize for my dig at Emacs, and ask that you try to be more
helpful.
I could have just quit after you calling me "just paranoid" instead of
giving an explicit example of a problematic case.
You complain about me not being helpful enough, but it is not like it is
an easy or rewarding task to get help crammed down your throat.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:14 a.m.
New subject: Release plans
David Kastrup writes:
I could have just quit after you calling me "just paranoid"
instead of
giving an explicit example of a problematic case.
I didn't say you weren't helpful, just that you could try harder than
than that last message, which was unproductive in all respects.
Eg, I don't *know* that (setq custom-file ...) *is* a problem; it
seems quite likely to me that Mike tests for that and does something
about it in the migration process. But I don't *know* that he did, so
I conceded you have a point.
The point about second-guessing is that if you get to the point where
the user says "I want to...", either he knows what he's doing (OK),
he's perverse (not much you can do about that), or you've given him
misinformation, or too little information. That last is bad, but the
asking for confirmation again is no solution; that only teaches him
that Emacs sucks. The solution is to give the right information in
the first place! Or, to fix the process so it's not so dangerous.
Or, as you've suggested before, not to do it at all.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:24 a.m.
New subject: Release plans
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
> I could have just quit after you calling me "just paranoid" instead of
> giving an explicit example of a problematic case.
I didn't say you weren't helpful, just that you could try harder than
than that last message, which was unproductive in all respects.
It brought the point across you were contesting, and so I tend to
disagree on that point. I also consider it ludicrous to get subjected
to inflated standards of helpfulness when I have nothing to gain in
return.
I am fully aware that you are also being helpful on the Emacs developer
list, and I would consider anybody silly that told you to try harder in
that manner. That you try at all is respectable.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:49 p.m.
New subject: Release plans
ClamAV 0.96
David Kastrup writes:
I am fully aware that you are also being helpful on the Emacs
developer
list, and I would consider anybody silly that told you to try harder in
that manner.
We'll have to agree to disagree on that. I know I occasionally need
to be told I'm not being helpful, it's just a shame I can't figure that
out in advance. ;-)
That you try at all is respectable.
I can agree with that.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:15 p.m.
New subject: Release plans
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
> I could have just quit after you calling me "just paranoid" instead of
> giving an explicit example of a problematic case.
I didn't say you weren't helpful, just that you could try harder than
than that last message, which was unproductive in all respects.
Eg, I don't *know* that (setq custom-file ...) *is* a problem; it
seems quite likely to me that Mike tests for that and does something
about it in the migration process. But I don't *know* that he did, so
I conceded you have a point.
Not really: It migrates the custom settings out of the file pointed to
by `custom-file' - it just uses custom's API to do that. It does not
fiddle with the setting of `custom-file' itself (which presumable also
got migrated). It does however change the value of custom-file *in the
session where the migration happened*.
So this is not entirely satisfactory: Doing the right thing would be to
detect that `custom-file' points somewhere else, and then leave the
custom settings alone. Does that sound right?
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:34 a.m.
New subject: Release plans
Michael Sperber writes:
So this is not entirely satisfactory: Doing the right thing would be
to
detect that `custom-file' points somewhere else, and then leave the
custom settings alone. Does that sound right?
I'm not sure what you mean by "leave them alone." After a (very)
small amount of thought, I think what I would recommend is
if user-wants-to-share-init:
explain why this is a bad idea
set up load .emacs in ~/.xemacs/init.el
if custom-file:
if user-wants-to-share-custom:
explain why this is a bad idea
set up load custom-file in ~/.xemacs/init.el
else if setq custom-file is found:
disable it
else:
warn user
append '(setq custom-file "~/.xemacs/custom.el") to init.el
else:
# normal XEmacs computation of custom-file is safe
pass
if user-wants-to-migrate:
copy original init file to ~/.xemacs/init.el
if custom-file:
copy custom-file to ~/.xemacs/custom.el
if setq custom-file is found:
disable it
else:
warn user
append '(setq custom-file "~/.xemacs/custom.el") to init.el
else:
# normal XEmacs computation of custom-file is safe
pass
else if user-wants-new-init-file:
touch ~/.xemacs/init.el
else if custom-file:
warn user
prompt for new setting (default to nil)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:16 a.m.
New subject: Release plans
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Michael Sperber writes:
> So this is not entirely satisfactory: Doing the right thing would be to
> detect that `custom-file' points somewhere else, and then leave the
> custom settings alone. Does that sound right?
I'm not sure what you mean by "leave them alone." After a (very)
small amount of thought, I think what I would recommend is
[...]
if setq custom-file is found:
disable it
That is precisely *not* leaving it alone. (The problem is that "finding
setq custom-file" is undecidable.)
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:57 a.m.
New subject: Release plans
Michael Sperber writes:
> if setq custom-file is found:
> disable it
That is precisely *not* leaving it alone. (The problem is that "finding
setq custom-file" is undecidable.)
So is pretty much everything else about migration, although not in the
technical sense I presume you mean -- XEmacs cannot know which forms
the user "really" wants migrated. However, this case is easy enough:
run xemacs in a separate process, load the .emacs we've found
explicitly, and find out what value custom-file has. If we can't
figure out where it was set, we can append a setq to init.el to force
an XEmacs-specific custom file. If the user is writing the custom
file from the init file, we're screwed of course, but that's perverse.
I think we can limit this paranoia to the init file and custom.el, but
on the other hand we know for sure that XEmacs will screw up those two
files (or perhaps choke on them).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:25 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
On Wed, Feb 23, 2011 at 12:39 PM, Rodney Sparapani <rsparapa(a)mcw.edu> wrote:
On 02/23/11 01:15 PM, Jerry James wrote:
> As for bug 411 ... hmmm, that custom-set-faces invocation actually
> seems to work for me on Fedora 14. Can you give me the version of
> RHEL and the rpm version of XEmacs that you are using?
It's xemacs-21.5.29-12.el5.1.x86_64
<http://download.fedora.redhat.com/pub/epel/5/x86_64/xemacs-21.5.29-12.el5...
I don't have an RHEL 5 machine, but I do have a CentOS 5.5 machine,
with exactly the same XEmacs RPM installed. I just tried the
following:
1. Start XEmacs
2. Choose Options->Font->...->Lucida.
3. Choose Options->Save Options to Custom File
4. Quit XEmacs
5. Start XEmacs
And everything's in Lucida instead of Courier. Why is it working for
me and not for you?
If you "mv .xemacs .xemacs.old" and then start XEmacs and do the font
customization and restart, does it work then? I wonder if you have
something in .xemacs/init.el or .xemacs/custom.el that is interacting
badly with your font selection.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:33 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
On 02/23/11 03:25 PM, Jerry James wrote:
If you "mv .xemacs .xemacs.old" and then start XEmacs and
do the font
customization and restart, does it work then? I wonder if you have
something in .xemacs/init.el or .xemacs/custom.el that is interacting
badly with your font selection.
This was a new machine; nothing in .xemacs (no
.xemacs even).
--
Rodney Sparapani Center for Patient Care and Outcomes Research
Sr. Biostatistician http://www.mcw.edu/pcor
4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW)
WWLD?: What Would Lombardi Do? Milwaukee, WI, USA
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:32 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
On 02/23/11 03:33 PM, Rodney Sparapani wrote:
On 02/23/11 03:25 PM, Jerry James wrote:
> If you "mv .xemacs .xemacs.old" and then start XEmacs and do the font
> customization and restart, does it work then? I wonder if you have
> something in .xemacs/init.el or .xemacs/custom.el that is interacting
> badly with your font selection.
This was a new machine; nothing in .xemacs (no .xemacs even).
By the way, while we are on the subject of init files. Should we
really be sharing init files between stable and beta? I have
never had any success with this. Maybe the default for beta
should be something like .xemacs/beta.el I know there is
probably some clever way around this like
(featurep 'xemacs-beta), but that gives me nil.
Rodney
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:38 a.m.
New subject: Release plans [was: Building packages with 21.5b29?]
Rodney Sparapani writes:
By the way, while we are on the subject of init files. Should we
really be sharing init files between stable and beta? I have
never had any success with this.
I've never heard of a problem with this before. Details?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:52 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
On 02/27/11 09:38 PM, Stephen J. Turnbull wrote:
Rodney Sparapani writes:
> By the way, while we are on the subject of init files. Should we
> really be sharing init files between stable and beta? I have
> never had any success with this.
I've never heard of a problem with this before. Details?
Well, the
lisp/package vs. package/lisp directory issue is one
thing that has bitten me before. Of course, just creating the
right links will fix that, but it took me a while to think of that.
If there are some others, having a (featurep 'xemacs-beta) might
come in handy.
--
Rodney Sparapani Center for Patient Care and Outcomes Research
Sr. Biostatistician http://www.mcw.edu/pcor
4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW)
WWLD?: What Would Lombardi Do? Milwaukee, WI, USA
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:10 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
On 2/28/11 9:52 AM, Rodney Sparapani wrote:
On 02/27/11 09:38 PM, Stephen J. Turnbull wrote:
> Rodney Sparapani writes:
>
> > By the way, while we are on the subject of init files. Should we
> > really be sharing init files between stable and beta? I have
> > never had any success with this.
>
> I've never heard of a problem with this before. Details?
Well, the lisp/package vs. package/lisp directory issue is one
thing that has bitten me before. Of course, just creating the
right links will fix that, but it took me a while to think of that.
If there are some others, having a (featurep 'xemacs-beta) might
come in handy.
Yes, that bit me too when I was testing eldoc with 21.4. I haven't used
21.4 in ages, so I think my .xemacs has slowly become 21.5 specific
unintentionally.
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:24 a.m.
New subject: Release plans [was: Building packages with 21.5b29?]
Rodney Sparapani writes:
If there are some others, having a (featurep 'xemacs-beta) might
come in handy.
Well, there is `xemacs-betaname' but I really don't see that being
useful. Specifically, these things are not going to suddenly switch
back to the old way when the beta gets promoted to stable.
What you want is a version check, such as `(emacs-version>= 21 5)'.
Note that, assuming I understand what you mean by the "package/lisp vs
lisp/package problem", neither test is going to help with that because
you have no place to put that test that will affect XEmacs's behavior
in this respect.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:35 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
ClamAV 0.96
On 03/ 1/11 05:24 AM, Stephen J. Turnbull wrote:
Well, there is `xemacs-betaname' but I really don't see that
being
useful. Specifically, these things are not going to suddenly switch
back to the old way when the beta gets promoted to stable.
What you want is a version check, such as `(emacs-version>= 21 5)'.
Note that, assuming I understand what you mean by the "package/lisp vs
lisp/package problem", neither test is going to help with that because
you have no place to put that test that will affect XEmacs's behavior
in this respect.
Hi Stephen:
Actually, it would have helped; a simple example:
(if (not (featurep 'xemacs-betaname)) (require 'ess-site))
--
Rodney Sparapani Center for Patient Care and Outcomes Research
Sr. Biostatistician http://www.mcw.edu/pcor
4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW)
WWLD?: What Would Lombardi Do? Milwaukee, WI, USA
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:02 a.m.
New subject: Release plans [was: Building packages with 21.5b29?]
Rodney Sparapani writes:
Actually, it would have helped; a simple example:
(if (not (featurep 'xemacs-betaname)) (require 'ess-site))
And when the XEmacs 21.5 code base goes stable? What then? Is that
really as good as
(if (not (emacs-version>= 21 5)) (require 'ess-site))
which right now has the same effect, but will have a different effect
when this code base becomes stable?
I also don't understand why 21.5 doesn't need ess-site, but that looks
very fishy to me. If there's 21.4-specific code in ESS, I don't think
it belongs in a site config file, but rather in an appropriately named
compatibility library.
That is, although I see how it could be used to temporarily work
around the real issue (which is hidden in ess-site somewhere), it
seems to me you're storing up trouble for the future.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:10 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
On 03/ 1/11 08:02 PM, Stephen J. Turnbull wrote:
And when the XEmacs 21.5 code base goes stable? What then? Is that
really as good as
(if (not (emacs-version>= 21 5)) (require 'ess-site))
which right now has the same effect, but will have a different effect
when this code base becomes stable?
We'll all rejoice then, will we not? :o)
I also don't understand why 21.5 doesn't need ess-site, but
that looks
very fishy to me. If there's 21.4-specific code in ESS, I don't think
it belongs in a site config file, but rather in an appropriately named
compatibility library.
That is, although I see how it could be used to temporarily work
around the real issue (which is hidden in ess-site somewhere), it
seems to me you're storing up trouble for the future.
Well no, the issue was
that the "feature" was in xemacs-beta,
not ESS. Like you say, this would have been only temporary while I
came up with a work-around for the package/lisp directory "feature".
But, as you say, there is another way which I am using now:
(if xemacs-betaname nil (require 'ess-site))
--
Rodney Sparapani Center for Patient Care and Outcomes Research
Sr. Biostatistician http://www.mcw.edu/pcor
4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW)
WWLD?: What Would Lombardi Do? Milwaukee, WI, USA
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:35 a.m.
New subject: Release plans [was: Building packages with 21.5b29?]
Rodney Sparapani writes:
> which right now has the same effect, but will have a different
effect
> when this code base becomes stable?
We'll all rejoice then, will we not? :o)
I suppose. I just hope there's nothing in ess-site that blows up with
recent XEmacsen, because this
(if xemacs-betaname nil (require 'ess-site))
will cause ess-site to be loaded at initialization time, just like in
21.4.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:06 p.m.
New subject: Release plans [was: Building packages with 21.5b29?]
On 03/ 3/11 12:35 AM, Stephen J. Turnbull wrote:
I suppose. I just hope there's nothing in ess-site that blows up
with
recent XEmacsen, because this
> (if xemacs-betaname nil (require 'ess-site))
will cause ess-site to be loaded at initialization time, just like in
21.4.
No, there is nothing in ess-site that is problematic. Like I said, it's
only Issue 411 that's keeping me from migrating to xemacs-beta.
--
Rodney Sparapani Center for Patient Care and Outcomes Research
Sr. Biostatistician http://www.mcw.edu/pcor
4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW)
WWLD?: What Would Lombardi Do? Milwaukee, WI, USA
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:50 a.m.
New subject: Release plans
>>>> Rodney Sparapani <rsparapa(a)mcw.edu> writes:
Rodney> By the way, while we are on the subject of init files. Should we
Rodney> really be sharing init files between stable and beta?
Yes. I think changing init files depending on stable or beta would
cause more problems. It would be a surprise to the unknowing user I
think.
If you do switch between stable and beta you are probably aware of
what you are doing. You would also like to have almost the same stuff
in both version so having two copies will be a maintenance burden. I
think you are better of with managing the differences with using
"emacs-version>=" within the init files instead.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:19 p.m.
New subject: Release plans
On 2/28/2011 3:50 AM, Mats Lidell wrote:
Yes. I think changing init files depending on stable or beta would
cause more problems. It would be a surprise to the unknowing user I
think.
If you do switch between stable and beta you are probably aware of
what you are doing. You would also like to have almost the same stuff
in both version so having two copies will be a maintenance burden. I
think you are better of with managing the differences with using
"emacs-version>=" within the init files instead.
Alternatively, a directory search list containing a series of directories that
are checked for INIT files could help this problem. the idea would be to put
beta specific files in a beta specific directory and they are used in preference
to the standard initialization files of the same name. yes there are a couple
of issues with initialization and building the right search list when you start
up the Beta versus the stable instances of XEmacs but that's not a tough issue.
It's only annoying.
Yours
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:21 p.m.
New subject: Building packages with 21.5b29?
On 2/14/11 1:29 PM, Aidan Kehoe wrote:
Ar an triú lá déag de mí Feabhra, scríobh Raymond Toy:
> Error attached. I'm using latest xemacs sources fresh from the hg repo
> yesterday. I'm attaching the Installation file, just for the record.
Ah, thanks. I suspect 5dd1ba5e0113 has fixed this, can you try again with a
more recent build?
Ok. I cloned xemacs yesterday (instead of xemacs-beta) and rebuilt it.
Indeed that error is gone. But now I get another error when it's
compiling semantic. Error message attached.
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:54 p.m.
New subject: Building packages with 21.5b29?
>>>> Raymond Toy <toy.raymond(a)gmail.com> writes:
Raymond> But now I get another error when it's
Raymond> compiling semantic.
I see the same error.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:30 p.m.
New subject: [COMMIT] #'byte-compile-normal-call; only examine properties of (car FORM) if a symbol
Ar an cúigiú lá déag de mí Feabhra, scríobh Raymond Toy:
On 2/14/11 1:29 PM, Aidan Kehoe wrote:
>
> Ar an triú lá déag de mí Feabhra, scríobh Raymond Toy:
> > Error attached. I'm using latest xemacs sources fresh from the hg
> > repo yesterday. I'm attaching the Installation file, just for the
> > record.
>
> Ah, thanks. I suspect 5dd1ba5e0113 has fixed this, can you try again
> with a more recent build?
Ok. I cloned xemacs yesterday (instead of xemacs-beta) and rebuilt it.
Indeed that error is gone. But now I get another error when it's
compiling semantic. Error message attached.
Perfect, thanks for the report. As far as I can see, the warnings:
While compiling se-jump in file
/Volumes/share2/src/xemacs/hg/xemacs-packages/packages/xemacs-packages/semantic/semantic-example.el:
** attempt to open-code anonymous lambda with too many arguments
** attempt to open-code anonymous lambda with too many arguments
reflect an actual problem that my recent changes made more evident. But I
don’t know enough about semantic to rush to change it, and I do know enough
about the byte compiler to rush to change *it*.
APPROVE COMMIT
NOTE: This patch has been committed.
# HG changeset patch
# User Aidan Kehoe <kehoea(a)parhasard.net>
# Date 1297880800 0
# Node ID 31475de17064148b3265c4a60d3e3d7c3849cea7
# Parent 503b9a3e5e4618f16972523c9e6d9fdacb285ba3
#'byte-compile-normal-call; only examine properties of (car FORM) if a symbol
2011-02-16 Aidan Kehoe <kehoea(a)parhasard.net>
* bytecomp.el (byte-compile-normal-call):
Check that the car of FORM is a symbol before examining its
properties; it can be a lambda form if byte-optimize.el hasn't
worked its magic and transformed such a lambda call into inline
code.
diff -r 503b9a3e5e46 -r 31475de17064 lisp/ChangeLog
--- a/lisp/ChangeLog Wed Feb 16 15:35:35 2011 +0000
+++ b/lisp/ChangeLog Wed Feb 16 18:26:40 2011 +0000
＠＠ -1,3 +1,11 ＠＠
+2011-02-16 Aidan Kehoe <kehoea(a)parhasard.net>
+
+ * bytecomp.el (byte-compile-normal-call):
+ Check that the car of FORM is a symbol before examining its
+ properties; it can be a lambda form if byte-optimize.el hasn't
+ worked its magic and transformed such a lambda call into inline
+ code.
+
2011-02-12 Aidan Kehoe <kehoea(a)parhasard.net>
* bytecomp.el:
diff -r 503b9a3e5e46 -r 31475de17064 lisp/bytecomp.el
--- a/lisp/bytecomp.el Wed Feb 16 15:35:35 2011 +0000
+++ b/lisp/bytecomp.el Wed Feb 16 18:26:40 2011 +0000
＠＠ -2888,7 +2888,7 ＠＠
(tree-equal . 3)))
(defun byte-compile-normal-call (form)
- (and (get (car form) 'byte-compile-keyword-start)
+ (and (symbolp (car form)) (get (car form) 'byte-compile-keyword-start)
(let ((plist (nthcdr (get (car form) 'byte-compile-keyword-start)
form)))
(symbol-macrolet
--
“Apart from the nine-banded armadillo, man is the only natural host of
Mycobacterium leprae, although it can be grown in the footpads of mice.”
-- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5081
days inactive
5102
days old
90 comments
12 participants
participants (12)
-
Aidan Kehoe -
David Kastrup -
Eric S. Johansson -
Jerry James -
Michael Sperber -
Mike Kupfer -
Raymond Toy -
Rodney Sparapani -
Stephen J. Turnbull -
The XEmacs Package Smoketest -
Uwe Brauer -
Vin Shelton