Re: [Bug-apl] is there a )copy ⎕fns like ⎕e x is )erase

[enztec]

On Sat, 26 Apr 2014 14:52:49 +0200
Kacper Gutowski <address@hidden> 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
>