11 a.m.
"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 = 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?
12:28 p.m.
New subject: Perl embedding: trial balloon
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)srce.hr> writes:
Hrvoje> To rephrase: the C code I've written today is not
Hrvoje> guaranteed to be safe, and neither will John's code he
Hrvoje> writes tomorrow be guaranteed to be safe. But if he
Hrvoje> writes it well, the resulting Perl-Emacs combinations
Hrvoje> (what a horror) *will* be safe, and that's what counts.
And I wrote:
> I don't think the analogy [of Windows to Perl] 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.
Hrvoje> So what's your point?
If code written to the standards you describe is John's target, then
(modulo esthetic considerations) giving this group of users what they
want is a good thing.
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.
I know John's already done a _lot_ of work; it's possible that he's
very close already, and it's just a matter of porting the current
Perlmacs and doing some fine-tuning. 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.
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"). That is
all I have to go on, so I know this may be an inaccurate
characterization of what he really thinks. But that's my impression.
John?
--
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."
3:53 p.m.
New subject: Perl embedding: trial balloon
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> wrote:
>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes:
Hrvoje> To rephrase: the C code I've written today is not
Hrvoje> guaranteed to be safe, and neither will John's code he
Hrvoje> writes tomorrow be guaranteed to be safe. But if he
Hrvoje> writes it well, the resulting Perl-Emacs combinations
Hrvoje> (what a horror) *will* be safe, and that's what counts.
[cut]
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"). That is
all I have to go on, so I know this may be an inaccurate
characterization of what he really thinks. But that's my impression.
John?
It is (or mostly was) a big task. I have trouble explaining to people
that yes, I have been working on it for several months, and no, it
doesn't do simple things like autoload Perl files yet, because my work
so far has been mostly on the core cross-language support.
My standards are the following: if anyone can crash a Perl-enabled
XEmacs using documented interfaces, then I can crash either a
Perl-disabled one or Perl using a similar trick.
I invite you to help me try to get Perlmacs to dump core... it feels
like I'm not making progress any more, it's been so long. :-)
9295
days inactive
9295
days old
2 comments
3 participants
participants (3)
-
Hrvoje Niksic -
John Tobey -
Stephen J. Turnbull