Hi Blake,
you can set the path in the preferences files:
READLINE_HISTORY_PATH = /home/...
/// Jürgen
On 07/01/2014 11:14 PM, Blake McBride wrote:
GNU APL creates a .apl.history in whatever directory APL is started up
in. This is unlike all other system I've seen, and a problem when you
do
Hi,
I have added monadic ⊣ and ⊢ see SVN 355.
Instead of making them identical I though it might be better to do
different things. What I came up with is this:
⊢ B returns (a copy of) B as a normal APL value.
⊣ B also returns a copy of B, but as a committed APL value.
Thus ⊣ can be used (inste
Hi,
I agree with Elias that 16807 is a pretty arbitrary and useless value, but
for the sake of IBM APL2 compatibility I have changed GNU APL to use it
as well. SVN 355.
Note that localizing ⎕RLis currently not fully correct, but this ts on
my TODO list
/// Jürgen
On 07/02/2014 05:19 AM, B
Hi,
I have changed the code so that ⎕PW is not copied when no objects are
specified
in the )COPY command, SVN
As much as I like IBM APL2 compatibility there is a limit to it when it
begins
to make no sense anymore.
For example if I would say:
* )COPY some_WS A B ⎕PW*
then IBM APL2 wo
Agreed. Thanks!
On Wed, Jul 2, 2014 at 8:51 AM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:
> Hi,
>
> I have changed the code so that ⎕PW is not copied when no objects are
> specified
> in the )COPY command, SVN
>
> As much as I like IBM APL2 compatibility there is a limit to it
Hi Elias,
latest SVN? I fixed another issue in SVN 354 or so which caused execve()
so fail.
The *apl -l 37* and *APserver -v* outputs would help.
/// Jürgen
On 07/02/2014 06:03 AM, Elias Mårtenson wrote:
It still doesn't work for me. Same error.
Regards,
Elias
On 1 July 2014 20:29, Juerg
Thanks!
On Wed, Jul 2, 2014 at 7:45 AM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:
> Hi,
>
> I agree with Elias that 16807 is a pretty arbitrary and useless value, but
> for the sake of IBM APL2 compatibility I have changed GNU APL to use it as
> well. SVN 355.
>
> Note that loca
Dear Juergen,
Thanks. I can do that, but every other Linux program I have ever used,
although it may allow me to specify a config file location as you do, the
default is always in the home directory.
Thanks.
Blake
On Wed, Jul 2, 2014 at 6:24 AM, Juergen Sauermann <
juergen.sauerm...@t-online
Hi Blake,
yes. The problem with that is that it requires the presence of a home
directory.
There are use cases like scripting where the interpreter cannot figure
where the
home directory is located and my strategy is to depend on as few environment
variables (like $HOME or $PWD) as possible.
Hi,
I have changed the rank operator with axis, i.e. ?[X].
The old implementation tried to improve on the somewhat broken
syntax specified in the ISO standard:
* A ?[y] B ??A ? y B*
* ?[y] B ??? y B*
The new implementation follows NARS which uses *?[X] *instead of *?*
when co
On 2014-07-02 14:36:37, Juergen Sauermann wrote:
> I have added monadic ⊣ and ⊢ see SVN 355.
>
> Instead of making them identical I though it might be better to do
> different things. What I came up with is this:
>
> ⊢ B returns (a copy of) B as a normal APL value.
> ⊣ B also returns a copy of B,
Makes sense. The standard specification is so weird that it must be
considered broken.
Frankly, I'd love to hear the discussions that preceeded its inclusion in
the standard. :-)
Regards,
Elias
On 2 July 2014 23:19, Juergen Sauermann
wrote:
> Hi,
>
> I have changed the rank operator with axi
Dear Juergen,
If you have trouble reliably finding the home directory, how do you find
the preferences file?
I would say to find the .apl.history file in the same way and place you
find the .gnu-apl directory. That would be consistent.
The problem I am having is that since I use GNU APL from th
I have to agree with Blake here. Ideally there should be a call to
getenv("HOME") and if that returns non-NULL, then use the .apl_history in
$HOME/.apl/apl_history or something like that.
If it returns NULL, well, then fall back to current directory I suppose.
I could make the Emacs mode use the
I found this for Unix/Linux systems:
#include #include #include
struct passwd *pw = getpwuid(getuid());
const char *homedir = pw->pw_dir;
On Wed, Jul 2, 2014 at 10:44 AM, Elias Mårtenson wrote:
> I have to agree with Blake here. Ideally there should be a call to
> getenv("HOME") and if tha
Neat, although I believe directly looking at the PATH variable is more
portable. It works on all Unices as well as Windows.
Regards,
Elias
On 2 July 2014 23:54, Blake McBride wrote:
> I found this for Unix/Linux systems:
>
>
> #include #include #include
> struct passwd *pw = getpwuid(getuid()
What was recommended is to use PATH variable (as you suggest) and then fall
back to the code I gave.
On Wed, Jul 2, 2014 at 11:00 AM, Elias Mårtenson wrote:
> Neat, although I believe directly looking at the PATH variable is more
> portable. It works on all Unices as well as Windows.
>
> Regard
Arguably, I can't think of a single situation where PATH isn't set while
getpwuid would work. I could be wrong though.
Regards,
Elias
On 3 July 2014 00:13, Blake McBride wrote:
> What was recommended is to use PATH variable (as you suggest) and then
> fall back to the code I gave.
>
>
> On Wed
Hi Blake,
I don't have to. If I don't find $HOME then the preferences file in
$HOME is not read and
the /etc/gnu-apl.d/preferences file is read. If that file would use
$HOME then its purpose
of having a fallback in case $HOME is not working would be undermined.
/// Jürgen
On 07/02/2014 05:4
A note from
http://stackoverflow.com/questions/2552416/how-can-i-find-the-users-home-dir-in-a-cross-platform-manner-using-c
Important remark: *many people are assuming that HOME environment variable
is always available on Unix but this is not true*, one good example would
be OS X.
On OS X when yo
Are you sure of that? I'm 99% sure that PATH is always set on OSX.
Regards,
Elias
On 3 July 2014 00:31, Blake McBride wrote:
> A note from
> http://stackoverflow.com/questions/2552416/how-can-i-find-the-users-home-dir-in-a-cross-platform-manner-using-c
>
> Important remark: *many people are as
Dear Juergen,
If $HOME is there, why don't you default to $HOME/.apl.history rather than
just .apl.history? That would portably-enough solve the problem of not
getting .apl.history files all over the place. Just use whatever algorithm
you are using for the .gnu-apl directory.
Thanks.
Blake
I have a current Mac OS/X system with a default configuration. $HOME is
set.
On Wed, Jul 2, 2014 at 11:34 AM, Elias Mårtenson wrote:
> Are you sure of that? I'm 99% sure that PATH is always set on OSX.
>
> Regards,
> Elias
>
>
> On 3 July 2014 00:31, Blake McBride wrote:
>
>> A note from
>> h
Thanks for understanding what I was saying even though I apparently have a
serious issue telling PATH and HOME apart. Whenever I say PATH, read HOME.
Regards,
Elias
On 3 July 2014 00:40, Blake McBride wrote:
> I have a current Mac OS/X system with a default configuration. $HOME is
> set.
>
>
Nice! Thank you.
On Wed, 2014-07-02 at 14:36 +0200, Juergen Sauermann wrote:
> Hi,
>
> I have added monadic ⊣ and ⊢ see SVN 355.
>
> Instead of making them identical I though it might be better to do
> different things. What I came up with is this:
>
> ⊢ B returns (a copy of) B as a normal APL
While I agree that $HOME/.apl-history is more generally useful, I can
also make a case for having the history file's location be relative to
the working directory:
Assume that you're a consultant or contractor working on APL projects
for a number of clients. You cd to the directory for a client's
I have a better idea what's going on now.
What happens is that it tries to launch
*/home/emartenson/src/apl/dist/bin/APnnn/APs/APserver*, which doesn't exist.
The actual file is */home/emartenson/src/apl/dist/bin/APserver*.
The problem seems to stem from a logic error in LibPaths::compute_bin_pa
27 matches
Mail list logo
