On Sat, 26 Apr 2014 14:52:49 +0200 Kacper Gutowski <mwgam...@gmail.com> wrote:
> On 2014-04-26 12:08:14, Juergen Sauermann wrote: > > I could make the ∇-editor aware that a )COPY is in progress and that > > functions shall be deleted automatically by the ∇-editor. > > I like a lot that there is now a command that sources another file > raw, much like "." in shell or "#include" in cpp. It's all that is > needed to make more complex programs/libraries in forms of > UNIX-ish-style scripts without relying on (hardly readable) workspace > files. > > With this mindset I find any changes to behaviour highly unexpected > and I would probably report them as a bugs (unless properly documented > as an actual features, of course). It might not be a problem in case > of ∇, but for updating already defined function it's an overkill as it > can be easily done explicitly by programmer like that: > > ∇mean[0] > R←mean B > R←(+/B)÷⍴B > ∇ > > This can be )COPY-ied many times without any problems as it enters the > editor with a name only and then explicitly rewrites header line at [0]. this is good for fns that you don't want to overwrite if you have multiple fns in one text file but it still appends to existing fns but i am starting to like this appending to give me a second chance of coding it - sorta like a vimdiff > As for implementing )EDIT-like routine, in other systems it launches > editor with a function body only, not ∇-editor commands. > So I think it might be a good idea to dump function's ⎕CR to a > temporary file and then launch external editor on it. When done > editing, read it back, split by lines, and simply pass it to ⎕FX. > Maybe also ⎕EX FN when ⎕FX returns success with a different name, > and)COPY/)DUMP to destination file as appropriate. > > The only drawback is that vi line numbers have 1-origin and this > can't be changed to zero. And I'm not yet sure how to efficiently > slurp UTF-8 file as characters. If I'm not mistaken, there isn't > anything in lib_file_io to help and it might require parsing UTF-8 > in APL at the moment. > Alternatively, one could automatically wrap modified function from > file with #!apl and ∇name[0] … ∇ header and then )COPY it in, but > that would be ugly. using just the ⎕ex and then a )copy (or a new ⎕cp that is just )copy that can be used in a fns) is what i am using > > > On 2014-04-26 03:08:59, enztec wrote: > > fp←'r' FILE_IO[24] 'vi workspaces/',fn,' < `tty` > `tty`' > > I guess, YMMV on other systems, but in my environment (linux) it > suffices to do '> /dev/tty', there is no point in running additional > command just to get current tty, and input redirection is superfluous > when doing popen 'r'. fp←'r' FILE_IO[24] 'vi workspaces/',fn,' > /dev/tty' works thanks this was my first time using popen and knowing a little bash is a dangerous thing btw if you can take a look at the FILE_IO code in http://lists.gnu.org/archive/html/bug-apl/2014-04/msg00269.html and give me an idea why the difference between c popen and apl popen - null vs no '10' at end of data still returned - i'd appreciate it enztec > > > -k >
