Discussion:
[Bug-apl] 844 Build Issue
Fred Weigel
2017-01-11 18:29:05 UTC
Permalink
Juergen

I just updated from 838 to 844. I (primarily) use libapl.so.

This does not work -- libapl needs an update. But, the easiest fix
is SharedValuePointer.hh. Line 52, comment out the protected:
libapl uses decrement_owner_count() and increment_owner_count()

Fred Weigel
Juergen Sauermann
2017-01-11 18:44:52 UTC
Permalink
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hi Fred,<br>
<br>
thanks, fixed in <b>SVN 846</b>.<br>
<br>
/// Jürgen<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 01/11/2017 07:29 PM, Fred Weigel
wrote:<br>
</div>
<blockquote cite="mid:***@crisys.com"
type="cite">
<pre wrap="">Juergen

I just updated from 838 to 844. I (primarily) use libapl.so.

This does not work -- libapl needs an update. But, the easiest fix
is SharedValuePointer.hh. Line 52, comment out the protected:
libapl uses decrement_owner_count() and increment_owner_count()

Fred Weigel

</pre>
</blockquote>
<br>
</body>
</html>
Fred Weigel
2017-05-16 19:30:26 UTC
Permalink
JÃŒrgen


In 950 (and going back a few releases) Command.cc has broken )HELP.

At (around) line 150, add

if (!strcmp(command, ")HELP")) return false;

without this, things like ")HELP +" (or whatever) won't work.

Second: )HELP doesn't actually behave well with NATIVE functions.  At
(around) line 962,
try 
if (ufun) ufun->help(CERR);
instead of
Assert(ufun);

Now, it would be useful to implement a "help" option to NATIVE -- but I
haven't done that.

As a side-note, it would be useful to have a CHANGES.txt file detailing
the changes from a release
to the next.

Find attached a first cut at shared memory support (mem.cc). It allows
mmap() of a region
(get the file handle from fopen), and supports floating, integer,
character, complex vectors
of different sizes transferring from GNU APL to and from the shared
memory region. I am
working with this currently, and when I get some experience will try to
graft into some
of the primitives. But this gives an idea of what I was talking about at
the beginning of the
month.

Fred Weigel


  
Blake McBride
2017-05-16 23:51:26 UTC
Permalink
Post by Fred Weigel
...
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
Leslie S Satenstein
2017-05-17 02:33:39 UTC
Permalink
Portability in my review of the code is based on Linux/BSD/UNIX and not with other systems.
I would like to see diffs of changes. By the way, I only run svn co ...   to compile a new version.If it works out, I flip the previous version with the current and wait the next update.
  Regards
 Leslie
Leslie Satenstein
Montréal Québec, Canada



From: Blake McBride <***@gmail.com>
To: ***@crisys.com
Cc: GNU APL <bug-***@gnu.org>
Sent: Tuesday, May 16, 2017 7:51 PM
Subject: Re: [Bug-apl] 950 )HELP Issue, and mem.cc

On Tue, May 16, 2017 at 2:30 PM, Fred Weigel <***@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
Juergen Sauermann
2017-05-17 11:40:55 UTC
Permalink
Hi Leslie,

actually SVN provides more elegant solutions. I suppose by *flip* you
mean having two
checked-out versions and changing back and forth between them. The
"normal" way
of working in *svn* is to:

*svn co* only once, and to *svn up* to get the latest version or *svn up
-rXXX* to go back
to revision *XXX*. Also useful is *svn **diff -rXXX* or *svn diff
**-rXXX:YYY *to find
the differences between the current version (as per *svn up*) and
version*XXX *or
the difference between versions *XXX* and *YYY*.

Best Regards,
Jürgen Sauemann
Post by Leslie S Satenstein
Portability in my review of the code is based on Linux/BSD/UNIX and not with other systems.
I would like to see diffs of changes. By the way, I only run svn co
... to compile a new version.
If it works out, I flip the previous version with the current and wait
the next update.
Regards
*
Leslie
*
*Leslie Satenstein*
*Montréal Québec, Canada*
**
------------------------------------------------------------------------
*Sent:* Tuesday, May 16, 2017 7:51 PM
*Subject:* Re: [Bug-apl] 950 )HELP Issue, and mem.cc
...
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
Juergen Sauermann
2017-05-17 14:53:10 UTC
Permalink
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hi Blake,<br>
<br>
I would agree as far as the core of GNU APL is concerned. We
should try keep it to a bare minimum if<br>
possible, avoiding fancy stuff that adds no significant benefits.<br>
<br>
Looking at bug-apl, quite a few users will disagree with our
position.<br>
<br>
If we keep the core language to a minimum then we need a modular
extension mechanism for those<br>
that want more than the bare minimum. The default extension
mechanism for GNU APL is native functions<br>
and Fred has used them. The presence of a native function does no
harm for GNU APL, because if it<br>
does not work on some platform then that function is simply not
working on that platform. No harm.<br>
<br>
Memory mapped files, BTW, have been in use by GNU APL before (see
<b>Archive,cc</b> and <b>⎕FIO</b>).<br>
They simplify coding a lot because you can apply string functions
to the content of files without the<br>
need to buffer the file beforehand. So in my opinion mmap'ing a
file  is actually a simplification.<br>
<br>
Best Regards,<br>
/// Jürgen Sauermann<br>
<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 05/17/2017 01:51 AM, Blake McBride
wrote:<br>
</div>
<blockquote
cite="mid:CABwHSOta43bELPwMJRDKJSDJG43PT8HQ79pFncyh+***@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Tue, May 16, 2017 at 2:30 PM, Fred
Weigel <span dir="ltr">&lt;<a moz-do-not-send="true"
href="mailto:***@crisys.com" target="_blank">***@crisys.com</a>&gt;</span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>...</div>
<div><br>
</div>
<div>Find attached a first cut at shared memory support
(mem.cc). It allows mmap() ...</div>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Just my two cents.</div>
<div><br>
</div>
<div>Blake</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>
Juergen Sauermann
2017-05-17 11:27:43 UTC
Permalink
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hi Fred,<br>
<br>
tahnks, I fixed the )HELP issues, <b>S</b><b>V</b><b>N 951</b>.<br>
<br>
Not sure what you mean by releases. If it is major releases like
1.6, 1.7... then<br>
the corresponding release announcement normally tells what the
major improvements<br>
are. The next finer granularity is SVN commits, and for them I
consider the SVN commit<br>
text to be more useful than a separate CHANGES.txt file. You can
use the <b>svn log<br>
</b>command, either for individual files or for directories to
retrieve these messages.<br>
<br>
I will be AFK for almost two weeks from now and will have a closer
look at mem.cc<br>
when I am back. Please remind me if I should forget that.<br>
<br>
Best Regards,<br>
Jürgen<br>
<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 05/16/2017 09:30 PM, Fred Weigel
wrote:<br>
</div>
<blockquote cite="mid:***@crisys.com"
type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<div>J<span style="font-family: Helvetica, Arial, sans-serif;">ürgen</span></div>
<div><span style="font-family: Helvetica, Arial, sans-serif;"><br>
</span></div>
<div><span style="font-family: Helvetica, Arial, sans-serif;">In
950 (and going back a few releases) Command.cc has broken
)HELP.</span></div>
<div><br>
</div>
<div>At (around) line 150, add</div>
<div><br>
</div>
<div>if (!strcmp(command, ")HELP")) return false;</div>
<div><br>
</div>
<div>without this, things like ")HELP +" (or whatever) won't work.</div>
<div><br>
</div>
<div>Second: )HELP doesn't actually behave well with NATIVE
functions. At (around) line 962,</div> <div>try </div> <div> if (ufun) ufun-&gt;help(CERR);</div>
<div>instead of</div>
<div> Assert(ufun);</div>
<div><br>
</div>
<div>Now, it would be useful to implement a "help" option to
NATIVE -- but I haven't done that.</div>
<div><br>
</div>
<div>As a side-note, it would be useful to have a CHANGES.txt file
detailing the changes from a release</div>
<div>to the next.</div>
<div><br>
</div>
<div>Find attached a first cut at shared memory support (mem.cc).
It allows mmap() of a region</div>
<div>(get the file handle from fopen), and supports floating,
integer, character, complex vectors</div>
<div>of different sizes transferring from GNU APL to and from the
shared memory region. I am</div>
<div>working with this currently, and when I get some experience
will try to graft into some</div>
<div>of the primitives. But this gives an idea of what I was
talking about at the beginning of the</div>
<div>month.</div>
<div><br>
</div>
<div>Fred Weigel</div>
<div><br>
</div>
<div><br>
</div>
<div> </div>
</blockquote>
<br>
</body>
</html>
Fred Weigel
2017-06-08 07:24:03 UTC
Permalink
Juergen

I noticed in 956, that there is a defect in Command.cc. At line 170:

if (args_ucs[1] == '.' && args_ucs[2] == '.') many = true;

has two defects: First is that it may read off the end of the prototype
string.
Second is that it doesn't work as intended. I propose:

if ((a > 1) && (args_ucs[a - 1] == '.') && (args_ucs[a - 2] == '.'))
many = true;

That works (try the command )HOST ls -l for a quick test case).

Fred Weigel
Juergen Sauermann
2017-06-08 17:38:33 UTC
Permalink
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hi Fred,<br>
<br>
thanks, fixed in <b>SVN 957</b>.<br>
<br>
/// Jürgen<br>
<br>
</font><br>
<br>
<div class="moz-cite-prefix">On 06/08/2017 09:24 AM, Fred Weigel
wrote:<br>
</div>
<blockquote cite="mid:***@crisys.com"
type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<div>Juergen</div>
<div><br>
</div>
<div>I noticed in 956, that there is a defect in Command.cc. At
line 170:</div>
<div><br>
</div>
<div>if (args_ucs[1] == '.' &amp;&amp; args_ucs[2] == '.') many =
true;</div>
<div><br>
</div>
<div>has two defects: First is that it may read off the end of the
prototype string.</div> <div>Second is that it doesn't work as intended. I propose:</div> <div><br> </div> <div>if ((a &gt; 1) &amp;&amp; (args_ucs[a - 1] == '.') &amp;&amp;
(args_ucs[a - 2] == '.')) many = true;</div>
<div><br>
</div>
<div>That works (try the command )HOST ls -l for a quick test
case).<br>
<br>
</div>
<div>Fred Weigel</div>
<div><br>
</div>
<div> </div>
</blockquote>
<br>
</body>
</html>
e***@gmx.com
2017-06-08 17:54:47 UTC
Permalink
my )host ls -l (pre fix) seems to work what is it not doing that it should be doing?


On Thu, 8 Jun 2017 19:38:33 +0200
Post by Juergen Sauermann
Hi Fred,
thanks, fixed in SVN 957.
/// Jürgen
Juergen
if (args_ucs[1] == '.' && args_ucs[2] == '.') many = true;
has two defects: First is that it may read off the end of the prototype string.
if ((a > 1) && (args_ucs[a - 1] == '.') && (args_ucs[a - 2] == '.')) many = true;
That works (try the command )HOST ls -l for a quick test case).
Fred Weigel
Juergen Sauermann
2017-06-08 18:54:40 UTC
Permalink
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hi,<br>
<br>
it also worked on my machine, but it was a fault indeed and
therefore I fixed it.<br>
<br>
/// Jürgen<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 06/08/2017 07:54 PM, <a class="moz-txt-link-abbreviated" href="mailto:***@gmx.com">***@gmx.com</a>
wrote:<br>
</div>
<blockquote cite="mid:***@gmx.com"
type="cite">
<pre wrap="">my )host ls -l (pre fix) seems to work what is it not doing that it should be doing?


On Thu, 8 Jun 2017 19:38:33 +0200
Juergen Sauermann <a class="moz-txt-link-rfc2396E" href="mailto:***@t-online.de">&lt;***@t-online.de&gt;</a> wrote:

</pre>
<blockquote type="cite">
<pre wrap="">Hi Fred,

thanks, fixed in SVN 957.

/// Jürgen



On 06/08/2017 09:24 AM, Fred Weigel wrote:
Juergen

I noticed in 956, that there is a defect in Command.cc. At line 170:

if (args_ucs[1] == '.' &amp;&amp; args_ucs[2] == '.') many = true;

has two defects: First is that it may read off the end of the prototype string.
Second is that it doesn't work as intended. I propose:

if ((a &gt; 1) &amp;&amp; (args_ucs[a - 1] == '.') &amp;&amp; (args_ucs[a - 2] == '.')) many = true;

That works (try the command )HOST ls -l for a quick test case).

Fred Weigel


</pre>
</blockquote>
<pre wrap="">

</pre>
</blockquote>
<br>
</body>
</html>

Continue reading on narkive:
Loading...