From: Cecil Westerhof <Cecil@decebal.nl>
To: help-gnu-emacs@gnu.org
Subject: Re: Changing the Emacs engine to Guile
Date: Tue, 22 Jun 2010 12:05:49 +0200 [thread overview]
Message-ID: <87d3vjz8jm.fsf@linux-lqcw.site> (raw)
In-Reply-To: 87tyovtqc3.fsf@kuiper.lan.informatimago.com
Op dinsdag 22 jun 2010 10:38 CEST schreef Pascal J. Bourguignon:
> The above while found-match loop does not modify this-line.
> The result is to find the last match on the line.
I just hacked it fast to try it out. I only checked the standard case
where I changed the spaces at the beginning of the line with non break
spaces. I just tried something else and found this behaviour. As they
say: haste makes waste. There is also another bug, with certain input I
can get a value out of range. Next time I should verify my code and not
publish it immediately. :-{
> Also, (I'm not sure about it I would have to check string-replace, but
> my guess is that) the substituted text is (substring substitute-str
> start-match end-match), which will be different in the case of emacs
> code below.
I did a diff of the files generated by Guile and Emacs Lisp (when using
single byte characters) and they where the same. This was the case where
only the spaces at the beginning of the line where replaced.
I need to make a more robust version and make some test cases and test
again.
> this (while (re-search-forward ...)) loop modifies the line for each
> occurence of the regexp, replacing it with (substring substitute-str 0
> match-length), which is a different replacement string in general.
Why? I would think the replacement string is the same. (When using
single byte characters.)
> I don't know about the other implementations, but with clisp you could
> also try to use the -C option to have your script compiled before
> running it. On big files it might be worthwhile to spend some time
> compiling the script.
In my script I have:
exec clisp -C "$0" "$@"
That is not correct?
> But my point here is that in emacs, most code is compiled or byte
> compiled, therefore you should compare the speed of the code generated
> by sbcl vs. guile. Benchmarking is hard.
As I understood it Guile compiles before executing. That is not correct?
Well, if the big time difference is nothing to worry about, I'll keep
still. ;-}
For the moment being I still prefer Emacs Lisp for scripting above
Guile. ;-]
--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
next prev parent reply other threads:[~2010-06-22 10:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87fx0g2yu6.fsf@linux-lqcw.site>
[not found] ` <87iq5cmjgp.fsf@fh-trier.de>
2010-06-21 16:40 ` Changing the Emacs engine to Guile Andreas Politz
[not found] ` <87y6e81d6f.fsf@linux-lqcw.site>
2010-06-21 21:04 ` Pascal J. Bourguignon
[not found] ` <878w671qvm.fsf@linux-lqcw.site>
2010-06-22 8:38 ` Pascal J. Bourguignon
2010-06-22 10:05 ` Cecil Westerhof [this message]
2010-06-22 17:28 ` Pascal J. Bourguignon
2010-06-22 20:40 ` Cecil Westerhof
2010-06-21 19:22 ` Cecil Westerhof
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d3vjz8jm.fsf@linux-lqcw.site \
--to=cecil@decebal.nl \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).