headers
Fren Zeee | 1 Jun 2012 01:35
Picon

Re: emacs lisp in javascript?

On Tue, May 1, 2012 at 10:42 AM, Thorsten Jolitz <tjolitz <at> googlemail.com> wrote:
> Thomas Lord <lord <at> emf.net> writes:
>
>> Is it viable to implement GNU Emacs Lisp in
>> Javascript?   Has anyone explored the question
>> and gotten anywhere?
>
> The other way around:
>  Ejacs is a JavaScript interpreter for Emacs, written entirely in Emacs
>   Lisp.
> http://steve-yegge.blogspot.de/2008/11/ejacs-javascript-interpreter-for-emacs.html

Is there any advantage to implementing javascript interpreter in a
language like emacs lisp which is dynamic binding versus clisp or
scheme which is static binding ?

Franz
Permalink | Reply | 1 comment |
headers
Richard Stallman | 1 Jun 2012 04:25
Picon
Picon

Feature suggestion

The output of C-u C-x =
should show some key sequences that would insert this character.

--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call
Permalink | Reply | 11 comments |
headers
Miles Bader | 1 Jun 2012 04:46
Picon
Gravatar

Re: Feature suggestion

Richard Stallman <rms <at> gnu.org> writes:
> The output of C-u C-x =
> should show some key sequences that would insert this character.

It already does, if the currently enabled input method can input it.

The functionality isn't really complete though, and could be improved.
For instance, it only works for some input methods -- e.g. "tex", but
not "korean-hangul".  Also it would nice if it would show other input
methods when the current input method doesn't handle a character.

-miles

--

-- 
Guilt, n. The condition of one who is known to have committed an indiscretion,
as distinguished from the state of him who has covered his tracks.
Permalink | Reply | 0 comments |
headers
Dmitry Antipov | 1 Jun 2012 05:46
Picon
Favicon

Re: Proposal: 'struct window' cleanup

On 05/23/2012 06:23 PM, Stefan Monnier wrote:

> The rest of the patch looks ready for installation.  IOW, please install
> it, and thank you,

It should be installed as 108441.

Dmitry
Permalink | Reply | 1 comment |
headers
Thorsten Jolitz | 1 Jun 2012 06:05

Re: emacs lisp in javascript?

Fren Zeee <frenzeee <at> gmail.com> writes:

> On Tue, May 1, 2012 at 10:42 AM, Thorsten Jolitz
> <tjolitz <at> googlemail.com> wrote:
>> Thomas Lord <lord <at> emf.net> writes:
>>
>>> Is it viable to implement GNU Emacs Lisp in
>>> Javascript?   Has anyone explored the question
>>> and gotten anywhere?
>>
>> The other way around:
>>  Ejacs is a JavaScript interpreter for Emacs, written entirely in Emacs
>>   Lisp.
>> http://steve-yegge.blogspot.de/2008/11/ejacs-javascript-interpreter-for-emacs.html
>
> Is there any advantage to implementing javascript interpreter in a
> language like emacs lisp which is dynamic binding versus clisp or
> scheme which is static binding ?

Quote from Steve Yegge:
,----------------------------------------------------------------------
| I had big plans for Ejacs. I was going to make it a full-featured,
| high-performance JavaScript interpreter, with all the Emacs internals
| surfaced as JavaScript native host objects, so you could write Emacs
| customizations using object-oriented programming. 
`----------------------------------------------------------------------

From reading the cited blog, I would guess that this was more a
personnal project from somebody who loves Emacs and Javascript and
started a project that made him learn much more about both.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dmitry Antipov | 1 Jun 2012 07:15
Picon
Favicon

Re: Proposal: block-based vector allocator

On 05/31/2012 07:43 PM, Paul Eggert wrote:

> Have you done some performance analysis on typical 64- and 32-bit hosts?

Sure.

> Has this been published somewhere?  Should be in the ChangeLog entry or whatnot.

I'll post it here, just after making them readable and comparable.

>> +    /* On a 32-bit system, rounding up vector size (in bytes) up
>> +       to mult-of-8 helps to maintain mult-of-8 alignment.  */
>> +    roundup_size = 8
>
> This alignment is needed only if USE_LSB_TAG, right?  If so, the
> roundup should occur only on such hosts.

It looks like you miss the core idea behind this code.

The rounding is not just to force alignment. For the block-allocated vectors,
this code rounds each possible vector size (in bytes) up to nearest
mult-of-roundup_size bytes, and then uses (size / roundup_size) as an index
into vector_free_lists. I believe this is the most natural way for both 32
and 64-bit systems with USE_LSB_TAG since it guarantees expected alignment
by design. On non-USE_LSB_TAG system, roundup_size is orthogonal to pointer
values (roundup_size can't be less than sizeof (Lisp_Object), of course).
For example, 32-bit system (non-wide-int, i.e. sizeof (Lisp_Object) == 4)
without USE_LSB_TAG is expected to work with roundup_size = 4, but I can't
test this and have no ideas why it's worth trying at all.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Paul Eggert | 1 Jun 2012 07:44
Favicon

Re: Proposal: block-based vector allocator

On 05/31/2012 10:15 PM, Dmitry Antipov wrote:
> On non-USE_LSB_TAG system, roundup_size is orthogonal to pointer
> values (roundup_size can't be less than sizeof (Lisp_Object), of course).

Ah, OK, then we can make roundup_size be the equivalent of
COMMON_MULTIPLE (sizeof (Lisp_Object), defined USE_LSB_TAG ? 8 : 1).

> For example, 32-bit system (non-wide-int, i.e. sizeof (Lisp_Object) == 4)
> without USE_LSB_TAG is expected to work with roundup_size = 4, but I can't
> test this and have no ideas why it's worth trying at all.

It would waste less memory due to internal fragmentation, which
would be a win.  I don't see the downside -- perhaps you could
explain?
Permalink | Reply | 6 comments |
headers
Eli Zaretskii | 1 Jun 2012 08:07
Picon

Re: Feature suggestion

> Date: Thu, 31 May 2012 22:25:29 -0400
> From: Richard Stallman <rms <at> gnu.org>
> 
> The output of C-u C-x =
> should show some key sequences that would insert this character.

Type "C-x 8 RET" followed by the hexadecimal code of the character
(shown by "C-u C-x ="), and Bob's your uncle.

Would mentioning that in the text do the job?
Permalink | Reply | 9 comments |
headers
Dmitry Antipov | 1 Jun 2012 09:34
Picon
Favicon

Re: Proposal: block-based vector allocator

On 06/01/2012 01:16 AM, Stefan Monnier wrote:

>> -  return (p == m->start&&  m->type == MEM_TYPE_VECTORLIKE);
>> +  if (m->type == MEM_TYPE_VECTORLIKE)
>> +    {
>> +      if (m->end - m->start == VECTOR_BLOCK_BYTES)
>
> Please just use a new MEM_TYPE, so we don't need to worry about the
> possibility of having a non-vector-block which just happens to have the
> same size as a vector-block.

I don't understand this. Any block-allocated vector P0 has the size less than
or equal to VECTOR_BLOCK_BYTES. So, mem_find (P0) will always return mem_node
M0 where M0->end - M0->start == VECTOR_BLOCK_BYTES (IOW, such a mem_node always
corresponds to a vector block). If P1's size is greater than VECTOR_BLOCK_BYTES,
including the case when it's equal to sizeof (vector_block), mem_find (P1) will
always return it's own corresponding node M1 where P1 is equal to M1->start and
M1->end - M1->start is never equal to VECTOR_BLOCK_BYTES.

Dmitry
Permalink | Reply | 16 comments |
headers
Andreas Schwab | 1 Jun 2012 10:45

Re: Feature suggestion

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Thu, 31 May 2012 22:25:29 -0400
>> From: Richard Stallman <rms <at> gnu.org>
>> 
>> The output of C-u C-x =
>> should show some key sequences that would insert this character.
>
> Type "C-x 8 RET" followed by the hexadecimal code of the character
> (shown by "C-u C-x ="), and Bob's your uncle.

Or when using the ucs input method: uNNNN (that works only for BMP
characters).

Andreas.

--

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Permalink | Reply | 0 comments |

Gmane