bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] Shared memory removed


From: David B. Lamkins
Subject: Re: [Bug-apl] Shared memory removed
Date: Sat, 28 Jun 2014 10:40:29 -0700

That'd be great. Thanks.

On Sun, 2014-06-29 at 01:32 +0800, Elias Mårtenson wrote:
> Perhaps a prefix command. It already allows you to prefix with a plain
> C-u to specify apl binary. It could also ask for extra arguments. 
> 
> Regards, 
> Elias 
> 
> On 29 Jun 2014 01:31, "David B. Lamkins" <address@hidden> wrote:
>         Something like that would be helpful, yes.
>         
>         What did you have in mind? A variant of the gnu-apl function
>         that
>         prompts for options?
>         
>         On Sun, 2014-06-29 at 01:18 +0800, Elias Mårtenson wrote:
>         > Should I add an extra feature to allow you to configure
>         extra options
>         > for a given session?
>         >
>         >
>         > Regards,
>         > Elias
>         >
>         >
>         > On 29 June 2014 01:14, David B. Lamkins <address@hidden>
>         wrote:
>         >         On Sat, 2014-06-28 at 14:13 +0200, Juergen Sauermann
>         wrote:
>         >         I also doubt that anybody is using shared variables
>         at all
>         >         because I
>         >         haven't received any trouble reports on them.
>         >         >
>         >         > /// Jürgen
>         >         >
>         >
>         >
>         >         That's true in my case.
>         >
>         >         Earlier this week I did make a first attempt to
>         understand how
>         >         SVs work.
>         >
>         >         In the short term I'll need to construct a workflow
>         that lets
>         >         me do more
>         >         than trivial experiments with SVs. I rely on Elias'
>         >         gnu-apl-mode for APL
>         >         input. To work with SVs I'll need to patch
>         gnu-apl-mode to
>         >         provide for
>         >         additional command-line options (so I can pass --SV
>         --id # to
>         >         GNU APL).
>         >         Or something... It seems inelegant to have to
>         customize each
>         >         running
>         >         instance of Emacs to set up an id.
>         >
>         >         At this point, I don't have any definite plans for
>         SVs beyond
>         >         experimentation to help me understand the strengths
>         and
>         >         weaknesses of
>         >         the approach.
>         >
>         >
>         >
>         >
>         >
>         >
>         
>         





reply via email to

[Prev in Thread] Current Thread [Next in Thread]