At times, yes. The particular case I am in, I am actually editing the .apl file directly because I have a lot of global search/replace operations. I am migrating some code from one WS to another. )COPY messed me up bad yesterday. I ended up throwing away my work and going to a backup. I am really looking forward to the two )COPY problems being resolved.
Thanks. Blake On Thu, May 29, 2014 at 8:28 AM, Elias Mårtenson <loke...@gmail.com> wrote: > Wouldn't it make more sense to edit your code in files, and load it when > needed? I.e. to keep the canonical version in the file instead of the > workspace. > > The fact that you are protected from interpreter crashes should be reason > enough I think. > > Regards, > Elias > On 29 May 2014 21:12, "Blake McBride" <blake1...@gmail.com> wrote: > >> Sorry about that. I oversimplified an actual case I had. I'll re-raise >> the issue if and when I hit it again. (I don't remember where that was.) >> >> On another note, the two )COPY issues have become a bit of a stumbling >> block for me. I actually lost work yesterday because of them. (I am >> finishing up an APL editor written in APL. I would typically load the WS I >> want to edit, copy the editor WS, edit the WS, and then ⎕EX the editor. >> This doesn't work without a functioning )COPY. Thanks!) >> >> Thanks. >> >> Blake >> >> >> >> On Thu, May 29, 2014 at 6:49 AM, Juergen Sauermann < >> juergen.sauerm...@t-online.de> wrote: >> >>> Hi Blake, >>> >>> according to IBM [] binds stronger than vector notation (APL2 language >>> reference, page 34). >>> IBM APL2 also gives RANK ERROR in the examples below. Eg. 1 2 3[2] is >>> evaluateded as 1 2 ( 3[2] ). >>> >>> /// Jürgen >>> >>> >>> >>> On 05/28/2014 06:41 PM, Blake McBride wrote: >>> >>> )CLEAR >>> CLEAR WS >>> 1 2 3[2] >>> RANK ERROR >>> 1 2 3[2] >>> ^^ >>> 1 2 3[2 2] >>> RANK ERROR >>> 1 2 3[2 2] >>> ^^ >>> x←1 2 3 >>> x[2 2] >>> 2 2 >>> >>> >>> Of course, they should all work as if they were assigned to a variable >>> first. >>> >>> Blake >>> >>> >>> >>
