"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
> This depends on whether the Perl code is able to act directly on
> large pieces of the buffer for things like regexp matching and
> substitution. If Perl regexps in Mule are implemented by pulling
> characters out of the buffer one at a time, it's going to be
> incredibly slow.
I don't know if our regexp matcher is much smarter than that. It
might be.
Here we are talking about something like:
perl_char =…
[View More] mule_to_ucs (BUF_FETCH_CHAR (buf, pos));
...where mule_to_ucs() is a table-driven function. There is also the
possibility to make the matcher smarter so that it pre-fetches a part
of the buffer, and converts it. And so on.
I think it would be OK to ignore the Mule efficiency issues at the
very beginning, and worry about them later, when the rest of the
infrastructure is in place.
> So presumably what John has in mind is using XEmacs's low-level C
> code to access buffers, Lisp strings, and so on. But if that's "all
> Perl support going through funcall," I don't see what safety that is
> supposed to guarantee.
XEmacs is not about "safety", at least not in the C++ sense of the
word. The safety XEmacs is about is the run-time safety of Lisp,
which relies on correctly implemented internals. If John writes
correct code, it will work. If not, not. As always.
To rephrase: the C code I've written today is not guaranteed to be
safe, and neither will John's code he writes tomorrow be guaranteed to
be safe. But if he writes it well, the resulting Perl-Emacs
combinations (what a horror) *will* be safe, and that's what counts.
> I don't think the analogy is correct. Windows-enabled XEmacs can't
> get at Lisp structures except through the same Lisp engine.
> Evidently the Perl engine is going to be able to get at a lot of
> Lisp data, maybe all of it.
So what's your point?
[View Less]
* 1999-04-17 Hrvoje Niksic <hniksic(a)srce.hr> list.xemacs
* Message-Id: <87lnfr10gj.fsf(a)pc-hrvoje.srce.hr>
|
| John Tobey <jtobey(a)channel1.com> writes:
|
| > I would like you folks' comments on the possibility of porting
| > Perlmacs (an embedding of Perl in GNU Emacs) to XEmacs.
|
| I have mixed feelings about this. On the one hand, adding the feature
| for the users who want it has always been a policy in XEmacs, as
| opposed to FSF Emacs.
|
| But on the …
[View More]other hand, I don't really see a use for Perlmacs in the
| XEmacs core. XEmacs is based on Lisp, and it won't go away. Teaching
| people to utilize the Lisp interpreter they have is a worthy goal
| which I feel is threatened by allowing Perl to be used instead.
|
| Perl is popular. Perl is hype. People who have never heard of Emacs
| Lisp but know Perl, will want to use the new capabilities, and then
| we'll be stuck with supporting Perl. I don't like that prospect.
|
| I'll quit rambling and continue with the technical part.
As a both Lisp and Perl programmer, I would cheerish the choice of
extension language, whether it were even python. I don't like the FSF's
attitude to stick lisp or guile on everyone's throat just because they
believe lisp is "academic" and better crafted.
We only need to take a look at the number of people that are supporting
Perl modules compared with the number of people supporting Emacs lisp
modules (and programs) and it's easy to calculate ratio of 50:1. Check
traffic in perl groups vs. Emacs.
If we had Perl as extension language, a vast number of potential
programmers might step in.
jari
[View Less]
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
> FWIW, my impression was that the point is to duplicate many of the
> editing features and data structure manipulations (currently bound
> to Lisp) in Perl. What with different GC strategies and general
> philosophy (Lisp usually works on copies; Perl does in place
> transformations, etc) data safety strikes me as involving lots of
> details which could be different from function to function in the
> Perl …
[View More]embedding.
I have my ideas about these things, but I think I'll rather wait to
hear John's response, since it sounds like he put quite a bit thought
and effort into it.
To avoid confusion, I'll reiterate: I do NOT want to see Perl become
just another means of extending XEmacs. If Perl support is ever
included to XEmacs distribution, I it support should be as separate a
package as possible, so that bug reports and feature requests can go
directly to the maintainer of that lump of code, and that it can be
removed with little or no effort if the said maintainer loses his
willingness to maintain it.
[View Less]
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
> I am under the impression that to write this stuff to such standards
> is going to be within an order of magnitude of reimplementing the
> Lisp engine in Common Lisp or Scheme. Not as big, but big.
>
> Do you disagree about the scale of the task? I suspect John does.
How have you come to that impression (yes, I disagree about the
scale)? I mean, it's a lot of work, and I don't like the outcome, but
it …
[View More]doesn't look even nearly *that* hard.
> But if not, the Perlmacs patch could end up getting backed out, as
> ImageMagick did, if his goals aren't congruent with the mainline.
> He'd be asked to do most of the work, since most (I think it is safe
> to say) current developers are unsympathetic to the project. It
> would be unfair if it basically came down to John being asked to
> clean up lots of devilish details and obscure crashes, and that
> wasn't what he had in mind.
It's not only up to me, but John sounds like he knows what he's
talking about. If he has good code to show up with, I don't see a
*practical* reason not to include it (I do have philosophical
objections, but then again, people had philosophical objections
against the Windows port...)
> My impression is that John is looking for maximum Perl capability
> for the implementation effort (quite rightly by itself, of course),
> is willing to trade off rare crashes for immediate power (his
> reaction was "it works well for me"), and doesn't think that the
> implicit `(require 'perl-stuff)' scenario is show-stoppingly
> important (his initial reaction was "it's the Lisp programmer's
> problem").
Uhm, I guess we got different impressions... I don't know, really.
[View Less]
>>>>> "Per" == Per Abrahamsen <abraham(a)dina.kvl.dk> writes:
Per> John Tobey <jtobey(a)channel1.com> writes:
>> Sure, I suppose you could implement a major mode as a separate Perl
>> process, but who really wants to invent protocols for such things?
>> Not to mention ways to serialize and deserialize interesting data
>> structures.
Per> It would be _way_ simpler, incomparable more robust, incredible more
Per> maintainable, and …
[View More]infinitely more useful[1] to have Perl as a
Per> subprocess. And both Perl and Emacs Lisp are really good at
Per> serializing data structures.
Per> However, I have to admit that Emacs as a loadable Perl module, or Perl
Per> as a loadable Emacs module, has a much higher hack-value. Kids today
Per> don't appreciate the power of the Unix pipe any more.
Per> The third option, creating a single Perl+Emacs executable, is simply
Per> to ugly to consider.
CORBA? (I can hear Hrvoje moan. Hi Hrvoje ...)
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla
[View Less]
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
> >>>>> "John" == John Tobey <jtobey(a)channel1.com> writes:
>
> John> I personally will be happy if all Perl support goes through
> John> funcall.
>
> This would be rather slow for typical Perl-ish direct buffer
> manipulations, I should think.
Why? funcall may be considered "slow" in comparison to C and other
lisp implementations, but it's certainly not *that* slow.
…
[View More]> John> Maybe things like car and cdr can avoid it for
> John> speed, but that will happen in a Perl module (Emacs::Lisp)
> John> and will not touch the xemacs binary.
>
> ??? Why would Perl code go ripping into list structure? It was in a
> different context, but you did write "I want Perl to chew on the text
> in my buffer".
I believe he wants Perl to be able to access anything Emacs Lisp is
normally able to access. Buffer text is only one obvious example.
> "This XEmacs is Perlmacs-enabled. That means that nothing can be
> relied upon to behave like it used to (although as far as we know it
> does, we cannot _prove_ that it will continue to do so), and you could
> experience severe data loss unless you carefully check all possible
> Lisp/Perl interactions in all packages that you may explicitly or
> implicitly load."
I dislike the possibility of Perl support for other reasons, but I
must say that it wouldn't make things that bad. What you quoted might
as well run like this:
"This XEmacs is Windows-enabled. That means that nothing can be
relied upon to behave like it used to (although as far as we know
it does, we cannot _prove_ that it will continue to do so), and
you could experience severe data loss unless you carefully check
all possible Windows interactions in all packages that you may
explicitly or implicitly load."
Such a saying cannot be proven nor disproven, and can apply to just
about anything.
> to the splash screen. That's what Kyle was saying, although much more
> politely.
>
> John> So, if I understand you, XEmacs can be linked as a library
> John> and dynamically loaded? What about unexec?
>
> Yes to the first.
Huh? Are you sure of this? Because I'm sure as hell not. I believe
the "external widget" code actually fires up a copy of XEmacs and
talks to it through X. Talking to John about external widget is
side-tracking, because that's not what he's interested in.
[View Less]
>>>>> "dv" == Didier Verna <verna(a)inf.enst.fr> writes:
dv> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
Hrvoje> (literally). I don't know why it's still labeled beta. Steve, bug or
Hrvoje> feature?
>>
>> Bug, I'd say.
>>
>> >> - AFAIK, there has been no official 21.0 announcement
>>
Hrvoje> It was on xemacs-announce.
>>
>> There has been no announcement on comp.emacs.…
[View More]xemacs, and the web page
>> still says 20.4.
>>
>> All the discussion about binary kits and the 21.0 release has raised
>> far more questions than provided answers. What *is* the release
>> strategy for the future? What status will 21.0 have? How will we
>> deal with binary kits. I'm sure you guys thought up something in
>> Japan, but it sure hasn't hit xemacs-beta yet.
dv> The japan release was supposed to be 21.0.
More questions. What's a "japan release"? What does this whole
sentence mean? It would be great if someone who was there could type
up some rough minutes of what happened there.
dv> For some reason, it was still labeled "beta". So I suggested to
dv> Steve that we should wait for the first patchlevel[1] release
What's a "patchlevel release"? Are we talking about 21.1.x? Is this
related to the 19.15 patchlevels in process?
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla
[View Less]
Didier Verna <verna(a)inf.enst.fr> writes:
> The japan release was supposed to be 21.0. For some reason, it was
> still labeled "beta". So I suggested to Steve that we should wait for the
> first patchlevel[1] release before posting on usenet. That's what we'll do I
> think. Steve has come back from Japan now, so I guess we won't have to wait
> for long before regular releases happen again.
>
>
> Footnotes:
> [1] which was supposed to be less than …
[View More]two weeks after the 21.0 one
That would be nice _if_ we had our fixes merged into 21.2 immediately so
they would get some testing before being put into 21.1. Something like
the customize specifier stuff is a bug fix and I want that in before
21.2. However it does need some testing.
Jan
P.S. What ever it is decided about the binary kits it needs to be in
_very very very_ big letters on the website and in the announcement.
[View Less]
