Thanks, I've tried this and I'm having some problems. I'm probably not
doing things right.
I'm doing something similar to:
string filename = "/tmp/xyz";
int fd = open( filename.c_str(), O_RDONLY );
Workspace::load_DUMP( COUT, UTF8_string( filename ), handle, false );
The load seems to succeed, b
On Tue, Aug 05, 2014 at 05:20:29PM EDT, Blake McBride wrote:
> Attempting to fix apl.xmodmap, I discovered that the mapping for
> χ seems to be correct, it just doesn't work for some reason. Strange
> that just those new characters give me a problem. I don't get it.
> Does anyone else?
I assume
Take a look at Quad_FX.cc.
On Wed, 2014-08-06 at 10:36 +0800, Elias Mårtenson wrote:
> Interesting. It seems that the tag gets set to ⎕FX when the function
> is defined that way. I would have expected the tag to be blank.
>
>
> Of course I can fix this on my end, but I'd like to know if this is
Interesting. It seems that the tag gets set to ⎕FX when the function is
defined that way. I would have expected the tag to be blank.
Of course I can fix this on my end, but I'd like to know if this is
expected behaviour. Jürgen, do you have any input?
Regards,
Elias
On 6 August 2014 10:28, Davi
This one probably doesn't affect many people.
If you define a function using ⎕FX without using the GNU APL extension
to store location metadata, a M-. on that function's name will complain:
if: Unexpected tag format: "⎕FX"
It might be nice if this said something like:
"This function was defined
I *was* gonna ask what took you so long... ;)
On Wed, 2014-08-06 at 10:16 +0800, Elias Mårtenson wrote:
> Thanks. Glad to have an issue reported to confirmed in about 5
> minutes. :-)
>
>
> Regards,
> Elias
>
>
> On 6 August 2014 10:14, David B. Lamkins wrote:
> Thank you.
>
Thanks. Glad to have an issue reported to confirmed in about 5 minutes. :-)
Regards,
Elias
On 6 August 2014 10:14, David B. Lamkins wrote:
> Thank you.
>
> Confirmed working.
>
> On Wed, 2014-08-06 at 10:11 +0800, Elias Mårtenson wrote:
> > Thanks. A fix has been comitted.
> >
> >
> > Regards,
Thank you.
Confirmed working.
On Wed, 2014-08-06 at 10:11 +0800, Elias Mårtenson wrote:
> Thanks. A fix has been comitted.
>
>
> Regards,
> Elias
>
>
> On 6 August 2014 10:09, David B. Lamkins wrote:
> Elias,
>
> This just started happening when using M-. :
>
Thanks. A fix has been comitted.
Regards,
Elias
On 6 August 2014 10:09, David B. Lamkins wrote:
> Elias,
>
> This just started happening when using M-. :
>
> let: Symbol's value as variable is void: find-tag-marker-ring
>
> Result of (emacs-version) :
>
> "GNU Emacs 24.3.1 (x86_64-redhat-linux
Elias,
This just started happening when using M-. :
let: Symbol's value as variable is void: find-tag-marker-ring
Result of (emacs-version) :
"GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.10.9)
of 2014-05-20 on buildvm-07.phx2.fedoraproject.org"
Gentle people,
Please find attached binom.apl.tgz. It contains the source for BINOM,
a defined function does what the primitive dyadic ! function does but
produces exact results over a larger range.
BINOM produces 1) the same results as ! over the range where !
produces exact int
I would like to make a change to the Emacs communication protocol before
release, so if you could hold back for a day or so and then merge the
latest version of the native module that would be great.
Regards,
Elias
On 6 Aug 2014 00:44, "Juergen Sauermann"
wrote:
> Hi Blake, all,
>
> thanks. I a
Hello Juergen,
Thanks for the tweak to the decode function. Preliminary testing
indicates that 63 bits of a 64-bit integer are usable. For example
128 128 128 128 128 128 128 128 128 ⊤ ⎕ ← 128 ⊥ 127 127 127 127 127 127
127 127 127
yields
9223372036954775807 ⍝ NOTE this is greater than
In apl.html, section 5.2, about SQL interface: "nad" should be "and".
Attempting to fix apl.xmodmap, I discovered that the mapping for χ seems to
be correct, it just doesn't work for some reason. Strange that just those
new characters give me a problem. I don't get it. Does anyone else?
Thanks.
Blake
On Tue, Aug 5, 2014 at 3:34 PM, Blake McBride wrote:
> Gre
Greetings,
Looking at SVN 420, I question the following keyboard issues:
1. with respect to support-files/Dyalog-keyboard
apl.xmodmap is missing mapping for the following characters:
χ
⍹
⍶
⍷
⍨
¥
⍸
⍣
⌷
⍥
¢
£
⍙
there may be others.
Please tell me if you would like me to fix this.
2. The file
Checked out , built and tested on both OS X 10.8.5 and 10.9.4 with no errors or
warnings (except that I do not have Postgres on 10.9.4).
On 2014-08-05, at 3:16 PM, David Lamkins wrote:
> Tested on one of my Fedora 20 systems, both by an update to my existing work
> dir and a fresh SVN checkout
Tested on one of my Fedora 20 systems, both by an update to my existing
work dir and a fresh SVN checkout. The build and install finished properly
in both cases. No surprises. :)
--
"The secret to creativity is knowing how to hide your sources."
Albert Einstein
http://soundcloud.com/davidlam
Hi Blake, all,
thanks. I am almost ready with the *GNU APL 1.4* release.
I have updated the latest *SVN 420 *to be a *pre-1.4 release*.
Please have a look if it builds and installs on your platforms.
*SVN 420 *is not yet the official *1.4* GNU package, so build errors can
still be fixed
befor
Hi Elias,
I guess something like that exists already. Have look at
how *)LOAD***works for .*apl *files. There is a stack of file descriptors
for the files read by *Input* and you can push an open file descriptor
onto it. The
only thing that doesn't work is to stop in the middle of a file (unless
Hi,
this is how I read the ISO standard. If a statement that is valid per
ISO returns
a wrong result then I consider that a fault that should be (and was) fixed.
If that conflicts with an intended use of a non-standard extension like
the ⍣ operator then I
would rate that as simply bad luck (
Greetings,
Just a thought - it seems that Juergen is trying to create a new release of
GNU APL. I think this is very important given the vast and critical
improvements since the last release. i.e. people who just download the
last release rather than build from SVN are trying something that has
Hello Jürgen,
What I mean by the somewhat mysterious subject is that I have had a request
to implement (or rather, improve) a feature in the Emacs Mode that allows a
user to evaluate all or part of a file.
Specifically, what is needed is a way for me to take a set of source lines
(usually a porti
Great. Thanks!
On Tue, Aug 5, 2014 at 9:23 AM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:
> Hi Blake,
>
> I have copied your apl.wasd.kbd to the Dyalog keyboard folder, SVN 418.
> The file is now called apl.kbd everywhere and the folder tells which
> keyboard is meant.
>
>
> /// J
Are you sure we want to fix that though? Things like the power operator
(once we have it) will not work right (since it's seems to be often used to
execute a niladic function a certain number of times.
The SQL∆WithTransaction will have the same problem.
The workaround seems to be a bit ugly, like
Hi Blake,
I have copied your apl.wasd.kbd to the Dyalog keyboard folder, SVN 418.
The file is now called apl.kbd everywhere and the folder tells which
keyboard is meant.
/// Jürgen
On 08/01/2014 05:57 PM, Blake McBride wrote:
GNU APL comes with a file named apl.xkb under the support-files
Hi David,
thanks, fixed in SVN 417. Unfortunately, as a consequence, it is no
longer possible to pass a niladic function to an operator.
/// Jürgen
On 08/05/2014 09:39 AM, David B. Lamkins wrote:
Maybe I've misunderstood some APL2 corner case, but the behavior of the
attached program seems wr
Hi,
I have changed the decode function to stay longer in the integer domain,
SVN 416,
Not sure what is wrong with 2⋆63 - looks OK to me.
Note also that the largest integer in GNU APL (see ⎕SYL[20;]) is
920
and not 9223372036854775808 (and therefore 2⋆63 is outside that range)
Hi Peter,
ah, your talking of the installation directory. There was a fault in
Makefile.am
that installed that file in some doc directory. Fixed in SVN 416.
/// Jürgen
On 08/05/2014 01:52 PM, Peter Teeson wrote:
First I deleted the previous folder (directory) and then did a brand new svn co
I believe I know what's going on.
OSX is case insignificant, but case-preserving. This means that the files
foo and FOO are actually the same file. This is usually not a problem, but
it's completely opposite to how Unix is supposed to work, and is caused by
backward compatibility with OS9.
I thin
First I deleted the previous folder (directory) and then did a brand new svn co
of the trunk followed by the usual ./configure and make.
There is a script.apl file in /workspaces but not a SCRIPT.apl one.
Even my backup does not have one.
Other than documentation it appears in the /workspaces Ma
Hi Peter,
I guess you accidentally deleted the file or did the 'svn update' from
the src subdir?
/// Jürgen
On 08/04/2014 09:51 PM, Peter Teeson wrote:
I did a brand new SVN co and then did ./configure and got this warning
file://localhost/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn
Yes. It seems the APL2 example code is not very good. If an error occurs,
you really don't want to just continue running. :-)
Regards,
Elias
On 5 August 2014 18:23, Juergen Sauermann
wrote:
> Hi Elias,
>
> it was available ,but behaves differently. ⎕ES stops execution
> while the ERR function
The issue here seems to be that since test is a nihilic function returning
0, the following call:
test/0
Is equivalent to the following:
{0⊣⍵}/0
which returns a single 0, since the /-reduction on a scalar is the value
itself.
However, the following:
(test)/0
is equivalent t
Hi Elias,
it was available ,but behaves differently. ⎕ES stops execution
while the ERR function only displays an error if it occurs.
/// Jürgen
On 08/05/2014 06:42 AM, Elias Mårtenson wrote:
Thank you. I see now how it works. Personally, I'd use Quad-ES to set
an error state instead. Was Qua
Maybe I've misunderstood some APL2 corner case, but the behavior of the
attached program seems wrong.
⍝!
∇z←false
z←0
∇
∇test1
→(false)/0
'foo'
→false/0
'bar'
∇
test1
∇test2
'check1' (0≡false)
'check2' (0≡(false))
'case 1' (0/0)
'case 2' (false/0)
'case 3' ((false)/0)
∇
te
36 matches
Mail list logo
