On Thu, 2014-05-15 at 12:55 +0800, Elias Mårtenson wrote:
> As for the edit buffer, you can always kill the frame and opening it
> again. That's always completely safe, as it never performs any
> destructive operation until you press C-c C-c.
>
Cool.
> You can also undo as far back as you want.
Thanks. I'll take a look at your patch later.
As for the edit buffer, you can always kill the frame and opening it again.
That's always completely safe, as it never performs any destructive
operation until you press C-c C-c.
You can also undo as far back as you want. I suppose I could add a rever
Bif_OPER1_EACH.cc lines 359-362.
Oops. Right patch; wrong attribution. This applies to
> 1. Allow an escape to IBM-style function listing and editing.
On Wed, 2014-05-14 at 15:04 -0700, David B. Lamkins wrote:
> The following patch works. If there's an opening del and a left bracket
> somewhere on the line, let GNU APL handle t
On Wed, 2014-05-14 at 11:43 -0700, David B. Lamkins wrote:
> 2. (This is unrelated to 1.) When editing a function in a gnu-apl-mode
> buffer, provide a way to revert the definition without closing the edit
> buffer.
The following patch works. If there's an opening del and a left bracket
somewhere
That fixed it for me. Thanks!
On Wed, May 14, 2014 at 1:14 PM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:
> Hi Jay,
>
> thanks, fixed in SVN 267.
>
> /// Jürgen
>
>
>
> On 05/14/2014 05:44 PM, Jay Foad wrote:
>
>> That's because of a bug in GNU APL:
>>
>>x←(1 2)(3 4)
>>
I have two feature requests for gnu-apl-mode:
1. Allow an escape to IBM-style function listing and editing. IOW, if
you see something like ∇fname[⎕]∇ (in the general case: ∇fname[),
then let GNU APL handle the request directly. (At present, attempting
this in gnu-apl-mode yields `Error when parsin
Hi Jay,
thanks, fixed in SVN 267.
/// Jürgen
On 05/14/2014 05:44 PM, Jay Foad wrote:
That's because of a bug in GNU APL:
x←(1 2)(3 4)
(a b)←x
a≡1 2
0
:-(
Jay.
On 14 May 2014 15:24, Blake McBride wrote:
Your unbox doesn't work. The following does:
(s r)←⊃x ⋄ z←(⊃s)
Perfect! Thanks!!
On Wed, May 14, 2014 at 11:01 AM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:
> Hi Blake,
>
> thanks, fixed in SVN 266.
>
> /// Jürgen
>
>
>
> On 05/14/2014 04:04 PM, Blake McBride wrote:
>
>> Dear Juergen,
>>
>> Thanks! Two small adjustments, if you care to, an
I think Elias is correct.
>From the IBM manual, pg. 110 (check the source; I think I've transcribed
accurately, but make no guarantee):
-- begin
Empty Argument: If R is empty, the function LO is not applied. Instead,
a related function called the fill function of LO is applied with
argument ↑R (t
You are talking about . (U+22C4 DIAMOND OPERATOR). It's an alternative
symbol to the one normally used in both GNU APL internally as as well the
Emacs mode: ◊ (U+25CA LOZENGE).
I suggest you change your mapping to output the latter instead of the
former. The former usually renders terribly in most
I tested this, and I'm wondering if the return value should really be 0?
Wouldn't it make more sense to return ⍬?
Regards,
Elias
On 15 May 2014 00:02, Juergen Sauermann wrote:
> Hi David,
>
> thanks, fixed in SVN 266.
>
> /// Jürgen
>
>
>
> On 05/14/2014 01:56 AM, David B. Lamkins wrote:
>
>> S
Hi David,
thanks, fixed in SVN 266.
/// Jürgen
On 05/14/2014 01:56 AM, David B. Lamkins wrote:
SVN Revision: 264
{⍵}¨''
SEGMENTATION FAULT
-- Stack trace at main.cc:122
-
That's because of a bug in GNU APL:
x←(1 2)(3 4)
(a b)←x
a≡1 2
0
:-(
Jay.
On 14 May 2014 15:24, Blake McBride wrote:
> Your unbox doesn't work. The following does:
>
> (s r)←⊃x ⋄ z←(⊃s)⍴⊃r
>
>
> On Wed, May 14, 2014 at 3:43 AM, Jay Foad wrote:
>>
>> On 13 May 2014 15:00, Bl
Thanks!
On Wed, May 14, 2014 at 10:31 AM, Elias Mårtenson wrote:
> I've fixed the problem. For Postgres, I wasn't checking for the case when
> there was 0 rows returned.
>
> Regards,
> Elias
>
>
> On 12 May 2014 05:07, Blake McBride wrote:
>
>> It appears to only happen in PostgreSQL. Also, w
I've fixed the problem. For Postgres, I wasn't checking for the case when
there was 0 rows returned.
Regards,
Elias
On 12 May 2014 05:07, Blake McBride wrote:
> It appears to only happen in PostgreSQL. Also, when I tried it with a
> non-empty file in PostgreSQL, it worked. Thanks.
>
>
>
I just noticed some really strange behavior in emacs mode. I mapped my
Unicomp keyboard and the diamond character works and displays perfectly
when not in emacs mode. But when I use it in emacs mode I experience the
following behavior:
When I type:
3 ⋄ 4
in emacs mode, I see something like:
3
Your unbox doesn't work. The following does:
(s r)←⊃x ⋄ z←(⊃s)⍴⊃r
On Wed, May 14, 2014 at 3:43 AM, Jay Foad wrote:
> On 13 May 2014 15:00, Blake McBride wrote:
> > Here are the functions, examples to follow:
> >
> > ∇box[⎕]∇
> > [0] z←box x
> > [1] z←⊂(⊂⍴x),⊂,x
> >
> > ∇unbox[⎕]∇
Thanks!
On Wed, May 14, 2014 at 3:43 AM, Jay Foad wrote:
> On 13 May 2014 15:00, Blake McBride wrote:
> > Here are the functions, examples to follow:
> >
> > ∇box[⎕]∇
> > [0] z←box x
> > [1] z←⊂(⊂⍴x),⊂,x
> >
> > ∇unbox[⎕]∇
> > [0] z←unbox x
> > [1] z←(⊃x[⎕IO])⍴⊃(x←⊃x)[⎕IO+1]
>
> FY
Dear Juergen,
Thanks! Two small adjustments, if you care to, and it will be perfect.
1. There should be 4 spaces before the closing ∇ (it really looks strange
flushed left)
2. There should be a line with 4 spaces and a ∇ before line 0
Thanks for making the changes!
Blake
On Wed, May 14
Hi Blake,
thanks, fixed in SVN 265.
/// Jürgen
On 05/13/2014 05:07 PM, Blake McBride wrote:
In GNU APL, when you list a function via:
∇fun[⎕]∇
the format of the returned output has several problems
(inconsistencies with respect to the IBM documentation). Some of the
differences are small
On 13 May 2014 15:00, Blake McBride wrote:
> Here are the functions, examples to follow:
>
> ∇box[⎕]∇
> [0] z←box x
> [1] z←⊂(⊂⍴x),⊂,x
>
> ∇unbox[⎕]∇
> [0] z←unbox x
> [1] z←(⊃x[⎕IO])⍴⊃(x←⊃x)[⎕IO+1]
FYI you can write your box as: z←⊂(⍴x)(,x)
and unbox as: (s r)←⊃x ⋄ z←s⍴r
Jay.
To reproduce, load a native function:
* 'libemacs' ⎕FX 'EE'*
Then type *]OWNERS* and the interpreter will crash with the following dump:
Value #0: Flags = COMPLETE, ⍴⊏21⊐ ≡1:
SystemVariable.cc:671
Owners of 0x1dfdaf0:
=
23 matches
Mail list logo
