7:41 p.m.
PATCH 21.5
This is the latest iteration of the TLS patch I've been working on
(and off) for some time now. I believe this iteration is ready for
serious consideration for inclusion in XEmacs. It gives us an
Emacs-compatible open-network-stream on systems where one of NSS,
gnutls, or openssl is available. This version incoporates changes
requested by Aidan during the last go-around: it uses Boolint in the C
code instead of hanging onto references to Lisp objects, and TLS
connections now self-identify as such.
We still need an Emacs-compatible gnutls.el. That's going to be hard,
since Emacs's Lisp code is very gnutls-specific; i.e., if you build
with NSS or openssl, the matchup between gnutls.el and the underlying
code isn't great. I'm considering a couple of approaches, but don't
want to hold up this part of the work.
Also, Windows ships with DLLs that contain TLS code, so in principle
it should be possible to extend this work to the WIndows part of the
code. In practice, I'm having some really fundamental trouble with
that which I will discuss on xemacs-beta.
The patch is attached in an attempt to avoid whitespace mangling
courtesy of gmail.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches
6:29 a.m.
Jerry James writes:
PATCH 21.5
This is the latest iteration of the TLS patch
Why not a public branch? This is truly exciting stuff! (Excuse my
faux pas if you already did....) N.B. If you decide to commit now, no
point in a branch, of course. I'm just hoping we can have more
visibility for our activity going forward.
I've been working on (and off) for some time now. I believe
this
iteration is ready for serious consideration for inclusion in
XEmacs.
OK by me, since it's optional (should default to yes but build or
other problems can be handled by --with-tls=no).
I think you should try gnutls first, though, although you can document
that choice as "likely to change". Rationale: I have no objection to
preferring nss or openssl once we resolve the gnutls.el compatibilty
issue (even if we resolve it "not worth the effort"), but during the
beta we really want as much Emacs code to work out of the box as
possible.
Please do it "soon" and I can release a beta (which you may have
noticed is long overdue, fsck my employer -- not that fsck would help,
it's broken-by-design).
We still need an Emacs-compatible gnutls.el. That's going to be
hard,
since Emacs's Lisp code is very gnutls-specific;
I say, just live with it. People who want Emacs compatibility will
just have to go --with-tls=gnutls for the nonce.
This isn't a real review, so no APPROVE, but I'm sure not gonna VETO
if you self-approve.
Steve
P.S. It would be appreciated if you would remove the patch to
configure, and just leave configure.ac for review. IMO YMMV WDOT?
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches
1:19 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Jerry James writes:
> PATCH 21.5
>
> This is the latest iteration of the TLS patch
Why not a public branch? This is truly exciting stuff! (Excuse my
faux pas if you already did....) N.B. If you decide to commit now, no
point in a branch, of course. I'm just hoping we can have more
visibility for our activity going forward.
+1 I'd even say go for the trunk.
--
Regards,
Mike
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches
10:58 p.m.
>>>> Michael Sperber <sperber(a)deinprogramm.de>
writes:
+1 I'd even say go for the trunk.
Same here. +1. Try to avoid branching especially on stuff that is
configurable.
Yours
--
%% Mats
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches
2:20 a.m.
Mats Lidell writes:
>>>>> Michael Sperber <sperber(a)deinprogramm.de>
writes:
> +1 I'd even say go for the trunk.
Same here. +1. Try to avoid branching especially on stuff that is
configurable.
I did mean to go for the trunk. Sorry for the unclear expression.
What I meant is that there are levels of implementation where you
don't want testers using it, but developers might want access. Jerry
has been working on this for a while. In such cases it's useful to
push branches, and now it's fairly cheap to do that.
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches
3:16 a.m.
On Fri, Oct 3, 2014 at 11:29 PM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
Why not a public branch? This is truly exciting stuff! (Excuse my
faux pas if you already did....) N.B. If you decide to commit now, no
point in a branch, of course. I'm just hoping we can have more
visibility for our activity going forward.
The consensus seems to be to push it to the master branch, so I will
do so. I've got some other stuff coming up that would be good to push
onto a branch, though. Would you like to see my D-Bus workspace? (I
might need a little hand holding to get started with mercurial
branching. I work with git branches a lot and am very comfortable
with them, but I still haven't managed to learn much about mercurial.)
OK by me, since it's optional (should default to yes but build
or
other problems can be handled by --with-tls=no).
I think you should try gnutls first, though, although you can document
that choice as "likely to change". Rationale: I have no objection to
preferring nss or openssl once we resolve the gnutls.el compatibilty
issue (even if we resolve it "not worth the effort"), but during the
beta we really want as much Emacs code to work out of the box as
possible.
That is a good point. Okay, I have changed it to try gnutls first for
Emacs compatibility reasons.
Please do it "soon" and I can release a beta (which you may
have
noticed is long overdue, fsck my employer -- not that fsck would help,
it's broken-by-design).
I will push in a few moments, once I verify that I didn't break
anything by swapping the order of gnutls and nss checking.
I say, just live with it. People who want Emacs compatibility will
just have to go --with-tls=gnutls for the nonce.
Okay.
This isn't a real review, so no APPROVE, but I'm sure not
gonna VETO
if you self-approve.
Thanks for the "fake" review, then. :-) It was helpful.
P.S. It would be appreciated if you would remove the patch to
configure, and just leave configure.ac for review. IMO YMMV WDOT?
Oh, geez. Sorry. I didn't mean to do that. I'll try to avoid that
in the future.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches
6:43 a.m.
Jerry James writes:
I've got some other stuff coming up that would be good to push
onto
a branch, though. Would you like to see my D-Bus workspace? (I
might need a little hand holding to get started with mercurial
branching.
Sure, I'd like to see that. I can help with local branching, but I'm
not that familiar with bitbucket. Probably Mike knows that most about
that.
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches
8:20 a.m.
>>>> Jerry James <james(a)xemacs.org> writes:
I've got some other stuff coming up that would be good to push
onto
a branch, though. Would you like to see my D-Bus workspace? (I
might need a little hand holding to get started with mercurial
branching. I work with git branches a lot and am very comfortable
with them, but I still haven't managed to learn much about
mercurial.)
I suggest you make a branch by cloning to a new repository. It is
slower, need more bandwidth pulling, but is easier to understand and
harder to make mistakes.
... or if possible I suggest "feature-flag" (configure option!?) such
workplaces so they can go in the trunk directly.
Yours
--
%% Mats
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches
10:18 a.m.
Mats Lidell writes:
I suggest you make a branch by cloning to a new repository.
Definitely. Mercurial "named branches" are a poor design to start
with, and are really hard for git users to understand.
Then you have a choice. You can use "bookmarks" to identify the trunk
and the branch (this is very much like git branches, but tags will
still feel weird to a git person). Or you can keep the repos
separate.
... or if possible I suggest "feature-flag" (configure
option!?) such
workplaces so they can go in the trunk directly.
I don't think this is a good idea, since trunk is currently what beta
testers use, and what will eventually be released. The current state
of Xft is the canonical example of what happens if you merge a feature
to trunk with substantial functionality missing. Embarrassing, to say
the least.
I know Jerry will be a lot more responsible than the "here today,
gone tomorrow" crowd that did the Xft work, but still, real
programmers get busy, too.
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches
6:06 a.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
I don't think this is a good idea, since trunk is currently what
beta testers use, and what will eventually be released.
The idea with using feature-flags is that they by default are turned
off so a beta tester, and even in released code, you won't notice
unless you turn that flag on.
It is not practical to use for all things but is a technique to avoid
branching. So for developing new functionality, that is likely to be
activated in trunk in a short time period, I'd would suggest hiding it
behind a feature flag.
Just right now it can of course be problematic since we don't have any
support for feature flags but could be a fun thing to implement. ;-)
Yours
--
%% Mats
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches
8:47 a.m.
Mats Lidell writes:
The idea with using feature-flags is that they by default are
turned off so a beta tester, and even in released code, you won't
notice unless you turn that flag on.
That's the theory. Amusingly enough, in this very thread we're
observing that Jerry's changes have broken things even though they're
turned off. That happens to ordinary mortals and Ben Wing alike.
It is not practical to use for all things but is a technique to
avoid branching.
Branching was nearly impossible in RCS, not terribly useful in CVS,
only a little bit better in Subversion. But things have changed (Bzr
is dead, long live King Git!) There is no good reason to avoid all
branching any more, and skilled branchers can use branching for all
kinds of tasks that in the past we would use ifdefs or quilts or
whatever for. That's because when using git, the costs of merging to
the developer are much less, and the benefits to users much greater.
As long as the developer frequently merges from trunk to feature
branch, this strategy works very well. The only real cost is that
while on the branch the beta testers and others find it hard to
discover the feature branch. (I'm serious, that is a cost I worry
about.)
Just right now it can of course be problematic since we don't
have
any support for feature flags but could be a fun thing to
implement. ;-)
I don't understand. Do you mean like in Gentoo, USE flags and FEATURE
flags are recognized by emerge? But that's strictly a Gentoo thing,
isn't it? And most of the people I know, including some ex-Gentoo
maintainers, are moving away from Gentoo -- it's a niche platform.
For use with XEmacs itself, we have Customize and "behaviors" at
runtime, and configure options (easily captured in a shell script or
the .INC file on Windows) for build time. What more do we need?
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches
10:06 p.m.
On Wed, Oct 8, 2014 at 3:18 AM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
I know Jerry will be a lot more responsible than the "here
today,
gone tomorrow" crowd that did the Xft work, but still, real
programmers get busy, too.
You may be assuming too much. I might turn out to be one of those fly
by night programmers, who drop in on a project for a couple of decades
and then merrily go on their way.
--
Jerry James, who notes that his first XEmacs contribution was really
only a decade and a half ago
http://www.jamezone.org/
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches
12:50 a.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
That's the theory. Amusingly enough, in this very thread
we're
observing that Jerry's changes have broken things even though
they're turned off. That happens to ordinary mortals and Ben Wing
alike.
Well, you won't notice unless it breaks somethings which actually is
one of the points. You have to, and get to, fix those integration
errors upfront.
Besides beta testers should expect to get some build and runtime
errors. That is one reason they are beta testers. To help find
problems by tripping over them.
I don't understand. Do you mean like in Gentoo, USE flags and
FEATURE
flags are recognized by emerge? But that's strictly a Gentoo thing,
isn't it? And most of the people I know, including some ex-Gentoo
maintainers, are moving away from Gentoo -- it's a niche platform.
I seem to fall for these niche things since I'm both a XEmacs and
Gentoo developer ;-)
But I don't mean like in Gentoo...
For use with XEmacs itself, we have Customize and
"behaviors" at
runtime, and configure options (easily captured in a shell script or
the .INC file on Windows) for build time. What more do we need?
As you suggest it will probably suffice for us. However the feature
flag concept, as I get it, is more of having yet an interface and
mechanism for controlling a feature of the system. That mechanism is
solely a developer thing and will vary over time depending on what
features are being developed.
Yours
--
%% Mats
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches
11:57 a.m.
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
> That's the theory. Amusingly enough, in this very thread we're
> observing that Jerry's changes have broken things even though
> they're turned off. That happens to ordinary mortals and Ben Wing
> alike.
Well, you won't notice unless it breaks somethings which actually is
one of the points. You have to, and get to, fix those integration
errors upfront.
In an early stage, it may get fixed by accident as development
proceeds, and never been seen by users at all. If not, if this
development is done on a branch, you'll get a spate of this kind of
error at integration time. If you do it on the trunk with ifdefs, not
only are they spread out over time, but there are probably more of
them because ifdefs are fiddly and prone to this kind of issue.
Besides beta testers should expect to get some build and runtime
errors. That is one reason they are beta testers. To help find
problems by tripping over them.
Not really. They're suppose to find problems that come up in real use
cases that the developers hadn't thought of. If there is a way for us
to catch bugs before the beta testers get the code, we should use it,
IMHO.
But I don't mean like [USE flags] in Gentoo...
As you suggest it will probably suffice for us. However the feature
flag concept, as I get it, is more of having yet an interface and
mechanism for controlling a feature of the system. That mechanism is
solely a developer thing and will vary over time depending on what
features are being developed.
That's not very helpful; except for "solely a developer thing", it's a
description of USE flags, ifdefs, customize, behaviors, configure, ....
Steve
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches
3648
days inactive
3656
days old
13 comments
4 participants
participants (4)
-
Jerry James -
Michael Sperber -
Stephen J. Turnbull -
The XEmacs Package Smoketest