Re: [Bug-apl] 950 )HELP Issue, and mem.cc

[Juergen Sauermann]

Hi Blake, I would agree as far as the core of GNU APL is concerned. We should try keep it to a bare minimum if possible, avoiding fancy stuff that adds no significant benefits. Looking at bug-apl, quite a few users will disagree with our position. If we keep the core language to a minimum then we need a modular extension mechanism for those that want more than the bare minimum. The default extension mechanism for GNU APL is native functions and Fred has used them. The presence of a native function does no harm for GNU APL, because if it does not work on some platform then that function is simply not working on that platform. No harm. Memory mapped files, BTW, have been in use by GNU APL before (see Archive,cc and ⎕FIO). They simplify coding a lot because you can apply string functions to the content of files without the need to buffer the file beforehand. So in my opinion mmap'ing a file  is actually a simplification. Best Regards, /// Jürgen Sauermann On 05/17/2017 01:51 AM, Blake McBride wrote: On Tue, May 16, 2017 at 2:30 PM, Fred Weigel <fwei...@crisys.com> wrote: ... Find attached a first cut at shared memory support (mem.cc). It allows mmap() ... A friendly plea to remain portable.  I've seen it time and again, a great, portable software package comes out.  And then they start tweaking it peace by peace until, for largely no reason, it becomes unportable and unmaintainable.  In 35 years, I've not needed memory mapped files (but I understand that that may be due to the kinds of problems I faced).  Still, I hope an eye is kept on simplicity and portability.  I wouldn't start adding all sorts of cute stuff. Just my two cents. Blake