Hello Chris,
I've been following the discussions about the GTK wrapper, and while I'm
not using it myself (since I work on the Emacs integration) I realise that
there are plenty of (potential) overlaps between our projects.
In particular, I want to let you know about the Emacs mode backchannel
pr
That's all correct, I believe.
--LX runs a command or expression. To be fair, an expression isn't useful.
However, you can write --LX ')copy myws' or --LX ')load myws' to start up
APL with a particular workspace. That's useful.
If you load a workspace as above, and that workspace ends contains a
I'm not sure I get it...
aplwrap -- --LX "9-8"
opens a window containing the result and
?ARG
yields
apl --noColor --rawCIN -w 500 --silent --LX 8-9
aplwrap -- -f plotsincos
runs the script. Is there something I'm missing?
On 08/13/14 18:16, David Lamkins wrote:
Sor
IMO either Copy or Break should be moved to a menu option.
On Wed, Aug 13, 2014 at 6:21 PM, David Lamkins wrote:
> Control-C is bound to GTK's copy. That's going to interfere with the key's
> role as the APL attention signal.
>
>
1. Space issue while defining functions:
GNU APL
∇test
[1] 1
[2] 2
[3] 3
[4] ∇
APLWRAP:
∇test
[1] 1
[2] 2
[3] 3
[4] ∇
2. Space issue with quad-quote:
GNU APL:
∇test;x
[1] x←⍞
[2] x
[3] →1
[4] ∇
test
abc
abc
def
def
ghi
ghi
jkl
jkl
mno
mno
APLWRAP with same
Control-C is bound to GTK's copy. That's going to interfere with the key's
role as the APL attention signal.
)CLEAR
CLEAR WS
∇test;x
[1] x←3
[2] →1
[3] ∇
test
^CATTENTION
test[1] x←3
^
)CLEAR
CLEAR WS
∇test;x
[1] x←⍞
[2] →1
[3] ∇
test
abc
def
^C
^C
^C
^C
^C
^C
^C
^C
^C
Dear Chris,
Thanks. That looks a lot better. A couple of things I did notice, however.
1. I noticed that the way your program maps is affected by my kxb
settings. Didn't expect that. I completely rebooted my machine to
eliminate any mapping issues.
2. Keymap errors:
Format ⍕ is mapped to
Sorry... I didn't explain the command-line stuff completely and forgot a
part.
Here's a patch (attached).
On Wed, Aug 13, 2014 at 2:22 PM, Chris Moller wrote:
>
>- Added the command-line stuff.
>- Fixed the assign arrow and branch arrow transposition.
>
> Both pushed to github.
> I'll
In case you missed my recent note, this problem isn't with quad-PW after
all.
More details in my other post.
On Wed, Aug 13, 2014 at 2:22 PM, Chris Moller wrote:
>
>- Added the command-line stuff.
>- Fixed the assign arrow and branch arrow transposition.
>
> Both pushed to github.
> I
Hmm. It has something to do with your UTF-8 validation in apl_read().
My guess is that read() returns in the middle of a multibyte UTF-8
character, causing the validation to fail.
I don't think this is strictly related to the size of the buffer; I tried
changing BUFFER_SIZE to 6256 with no improv
The ]keyb command shows the "canonical" key layout for GNU APL.
It is/was based on the Dyalog layout. But there are a few differences and
omissions in the current DyalogAlt.keylayout for Mac.
Starting with the actual Dyalog layout I have added the mappings to the Unicode
glyphs mentioned in Blak
* Added the command-line stuff.
* Fixed the assign arrow and branch arrow transposition.
Both pushed to github.
I'll look at the quad-PW stuff
On 08/13/14 16:36, David Lamkins wrote:
Here's a feature request:
- Provide a means to pass command-line arguments to APL.
At the very least, I'd l
Oops. Not related at all to quad-PW; sorry...
The extra blanks move around each time I invoke ]KEYB, whether or not
quad-PW has changed.
On Wed, Aug 13, 2014 at 1:52 PM, David Lamkins wrote:
> The ]KEYB breakage seems dependent on quad-PW, somehow. Try different
> values for quad-PW and you'll
Hello Chris,
Please consider 1) filtering out whether the 'NumLock' is active or not
when you test the key event state is 0 and keyval is GDK_KEY_Return and
2) adding support for a keyval of GDK_KEY_KP_Enter in the same test.
Then using the numeric keypad with aplwrap would be a lot more p
On 2014-08-13 19:42:25, Juergen Sauermann wrote:
> I believe the VALENCE ERROR comes because = is dyadic and
> the lambda is monadic?
>
> In GNU APL (and in the ISO standard) there is no monadic =, is it?
> Maybe in Dyalog APL there is?
No, it was supposed to be dyadic. I'm not sure how GNU APL
The ]KEYB breakage seems dependent on quad-PW, somehow. Try different
values for quad-PW and you'll see the extra blanks move around in the ]KEYB
display.
(Also, note that the location of the assign arrow and branch arrow are
transposed in the keymap.)
From: Chris Moller
> To: Blake McBride
>
Here's a feature request:
- Provide a means to pass command-line arguments to APL.
At the very least, I'd like to be able to do something like:
$ aplwrap -s 16 -- --my-option 1234
where everything from -- onward would be tacked onto the end of aplwrap's
apl_argv[].
That way, everything after t
Hi Kacper,
I believe the VALENCE ERROR comes because = is dyadic and
the lambda is monadic?
In GNU APL (and in the ISO standard) there is no monadic =, is it?
Maybe in Dyalog APL there is?
/// Jürgen
On 08/13/2014 06:40 PM, Kacper Gutowski wrote:
That's interesting thing to see in GNU APL.
N
I've just pushed a new version to github.
* Switched to the FreeMono font rather than the SimPL font. ]keyb
still doesn't look right, but I think it's the box characters
screwing up and not the normal characters. Mono is now the default;
use the -v option if you want variable width.
*
That's interesting thing to see in GNU APL.
Negative exponents are obviously tricky to do, but what about using
boolean functions? It's a quite convenient way to succinctly express
iteration. But right now GNU APL gives somewhat unexpected results:
({2+⍵÷2}⍣≡) 9
9
({2+⍵÷2}⍣=) 9
VALEN
A couple more minor concerns:
1. The output pane resizes horizontally to the enclosing window size, but
not vertically.
2. Last night's scroll-to-end fix is working for me. Now it'd be nice to
have the output pane also scroll to the left when waiting for input.
I agree about the inverse functions. That rabbit hole is dark and deep.
However, power is quite useful even without it. :-)
That said, would it make sense to add a )MORE message when the inverse
function can't be computed? For example, when you try to apply the power
operator on a negative argumen
Hi Blake,
thanks. Negative powers build on the concept of an "inverse function".
In GNU APL some of the primitives have inverse functions (+/- ×/÷, ⋆/⍟
and ○).
But these inverse functions have rather strange effects, for example:
2 (+ ⍣ 40) 5
85
2 (- ⍣ ¯40) 5
85
2 (+ ⍣ ¯40
24 matches
Mail list logo
