# User Guide Notes for @dyalogapl APL on OS X

• This is enough to leave you with a system that you can easily code in, feels familiar, and gives you pop up help for learning APL

• Page 1-2
• Version 14.1
• Revision: 20151012_141
• To whom is Javascript trademarked?!
• Page 3-4
• Page 5
• Assumption: Most reading will be done in the main documentation

This document is only part of the full documentation set for Dyalog (available to download from http://docs.dyalog.com/). In cases where the information given is different between this document and any of the others, this document should be regarded as the definitive source for Dyalog for Mac OS.

• Maybe I should have done the tutorial before reading this?!
• Feel like getting comfortable with Dyalog means getting comfortable with the tooling
• Page 6
• 14.1 is brand new for OS X and it uses the new IDE which is catching up to the Windows IDE
• Page 7
• When I start Dyalog, the APL key mapping isn’t enabled
• “Hide” and “Show” feature, neat!
• Why does (<LBR>) give an error? Is that a key code?
• Jump to section 5.1 to see how this notation is defined
• These are Keyboard Shortcuts and Command Codes
• Page 9-12
• Page 13
• Trying to edit + and failing on each of the four ways to do it
• Tried again, X←10, now all 4 options work
• <ED> means edit, bound to shift-enter
• Page 14
• Changed X to 20 and tried saving it, it doesn’t save
• Page 15
• Page 16
• Can’t get the trace window opened with control-enter on +/⍳5
• Perhaps because it is a primitive?
• Created a function to add two to the argument
∇ADDTWO X
[1]  X+2
[2]  ∇

• ADDTWO 10 results in 12
• Now I can test the debugger
• Going back to the session window lets you evaluate debugged values
• Believe this is the intent, and it does work
• Page 17
• Forward and backward debugger, nice
• Page 18
• Page 19
• control-tab Cycle between windows forward
• shift-control-tab Cycle between windows backward
• escape Exit window, save changes
• shift-escape Exit window, don’t save changes
• Easier to float windows and move them around outside of the session window
• Page 20
• Autocomplete starts with 
• Nice way to learn the commands and their bindings
• It would be nice of command code’s were listed along with their default keybinding so you can try it out right away instead of going back to the appendix
• Maybe print out the command code appendix before reading the guide!
• Page 22
• F1 is context sensitive help
• This is a biggie
• This alone is enough to start playing with stuff and learning the system
• Page 23
• How to import/export color themes?
• Can define new ones on page 31
• Backward BK* control-shift-backspace, previous line of input history
• Forward FD* control-shift-enter, next line of input history
• Page 24
• Supports debugging (different from tracing?!)
• Breakpoints can bet set in the edit window and flagged in the trace window
• )SI shows the stack
• ⎕STOP sets breakpoints
• Page 25
• Interrupts can be handled
• )off` leaves the REPL
• Page 26
• List of things that are unsupported on OS X
• Never used Dyalog before so will not miss it
• Still good to know
• Some symbol rendering is wrong
• Can’t interact with a terminal
• Page 27-30
• Page 31
• How to create a color theme
• Page 32
• How to set the titlebar text
• Page 33-38

## 3 thoughts on “User Guide Notes for @dyalogapl APL on OS X”

1. Fiona says:

Great to read some comments on the Mac OS User Guide. If there are any improvements you can suggest for this (or the Mac OS Installation Guide) please do let me know…user feedback is always welcome! Already sorted the Javascript slip (oops).

Re your comment on “Trying to edit + and failing on each of the four ways to do it” – this is because + is a primitive and primitives can’t be edited. The document is specific to using the UI rather than all-encompassing, so rules like this aren’t included (the guide would be thousands of pages otherwise). Having said that, if there’s a subset of APL guidelines that you think would be useful please tell me and I’ll see what I can do.

Fiona (Dyalog’s documentation manager)

1. Grant says:

Fiona,

Thank you so much for the delightful documentation.

Being that this is a “notebook style” blog, I had simply noted the Javascript reference as a “TODO” for myself to find out more about. If I had been concerned, I would have contacted you. What is the best way to contact you?

Gotcha about the “edit and fail” note. Thanks and that totally makes sense. The reason I kept that in there was for clarity for myself and my notes. Later in the manual it explained that you can’t edit builtins. Yikes, that is exactly what I had tried. After defining a method I tried again and all four edit approaches worked perfectly. My goal was to evaluate code and “just get
coding” and this seemed to be the fastest route.