Re: Perl embedding: trial balloon
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)srce.hr> writes:
Hrvoje> "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.
Hrvoje> Why? funcall may be considered "slow" in comparison to C
Hrvoje> and other lisp implementations, but it's certainly not
Hrvoje> *that* slow.
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.
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.
> "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."
Hrvoje> What you quoted might as well run like this:
Hrvoje> "This XEmacs is Windows-enabled.
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. That's not true of the Windows redisplay, except
where it calls Lisp---and we have a good understanding of that
problem, even though nobody loves GCPRO, it seems.
John> So, if I understand you, XEmacs can be linked as a library
John> and dynamically loaded? What about unexec?
> Yes to the first.
Hrvoje> Huh? Are you sure of this? Because I'm sure as hell not.
Hrvoje> I believe the "external widget" code actually fires up a
Hrvoje> copy of XEmacs and talks to it through X.
No; I think I confused it with the new DLL stuff. I retract the
statement.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for? "Free software rules."