|
| From: | Elias Mårtenson |
| Subject: | [Bug-apl] Fwd: Re: 2 questions wrt editing my programs |
| Date: | Wed, 23 Apr 2014 01:13:46 +0800 |
I accidentally sent this to Jürgen only. Here it is for the rest of the list.
Regards,
Elias
I must say that that sounds a bit more work than I have. In an attempt to blow my own horn, let me try to explain how Emacs does it.
I start GNU APL inside Emacs, which opens the interpreter inside a buffer (a buffer is simply the editor content, but it can also be more like a terminal. It's text, basically). You can switch between buffers, show several buffers at the same time, and buffers don't even need to be displayed, and you can easily switch between them by pressing C-x b (that's control-x followed by b).
In the APL interaction buffer you can use GNU APL just like you do in a terminal with a few exceptions: First of all, you have access to the APL input methods, allowing you to easily type APL symbols. Secondly, if you press TAB you will get auto-expansion of symbols. There are also some other features (like a spreadsheet editor for matrixes).
Now, if you open another buffer with a plain APL file and enter a function definition, you can simply move the cursor to any line in the function and press C-c C-c. This will send the function definition to the running APL session (it will be running in the buffer even though it might not be visible). If an error occurred while sending the function definition, it will be marked in the buffer. If all works well the function will flash briefly to show what was sent (I point that out for no other reason than that I find it cool :-) ).
Now, another neat feature is that you can in any APL buffer (either the one where the interpreter is running or any text file with APL code) place the cursor on a symbol and press M-. (that's meta-period, where meta is usually the Alt key on a PC). This displays the file that contains the definition of the function and places the cursor on the first line of said function. This is a very efficient way to navigate to the location of a function definition.
There are also other features such as integrated documentation, allowing you to display docs for any APL symbol (this information is displayed in separate buffers).
Another feature is the "trace" feature that opens a separate buffer displaying the content of a variable. Whenever the variable changes the buffer is updated in realtime. This is the same feature that was used in the game of life demo that Dyalog showed in a Youtube video.
This message is getting long, and I'm typing this on my phone. Perhaps I should make a Youtube video showing off these features.
Regards,
Elias
Hi Peter,
the built-in ∇-editor should almost work like "Editor 1" described in the IBM language reference
manual for APL2, chapter 9. When you are scripting GNU APL then you can define functions in your
script like this:
)ERASE AVERAGE
∇Z←AVERAGE B
Z←(+/B)÷⍴B
∇
Having that said, this is how I work:
I use multiple xterm windows (for easy cut-and-paste of APL code).
In the 1. window I edit an APL script using vi (!).
In a second window I start that script when I have edited a function to see if it works.
Since I am an APL newbie, I have a 3rd window with GNU APL running interactively to try out
small things. In this window I sometimes edit small functions with the ∇-editor.
Regarding other ways of importing functions, you could write a small function using FILE_IO that
reads an entire text file (containing one function) and ⎕FX it. There are lots of other possibilities,
e.g.having a makefile instead of window 2 and use ":make from within vi. That saves one window.
The method above works best for me, though.
/// Jürgen
On 04/22/2014 12:33 AM, Peter Teeson wrote:
(1) Where is docn for the built in function editor when running in terminal mode?
(I have the IBM manuals - should I be looking there? Also I am not familiar with emacs or vi)
(I'm only familiar with the IPSA one)
(2) Can I use an external text editor and interface with quad FX?
Because I now want to get on with my original intent which is to solve a problem using APL
rather than C/C++ since APL is much better suited for that purpose - lots of arrays involved.
TIA
respect….
Peter
| [Prev in Thread] | Current Thread | [Next in Thread] |