I've no idea how many people use aplwrap, but just in case it's greater
than zero...
The code has rotted a bit since I last tinkered with it--a couple of
GTK+ functions have been deprecated and the calling convention of a
couple others changed slightly. I've patched all that; if you try it,
I tagged and pushed APLwrap 2.2 today. This is the same code that has
been on the repository since October 19th. I've only bumped the version
number and added a summary of changes (attached).
Changes from APLwrap version 2.1 to 2.2
---
- Improve reliability of
APLwrap has undergone a lot of changes and fixes since its 2.1 release
(see attached). I'd like to tag and commit a 2.2 release in the near
future.
If you're an APLwrap user, I'd appreciate it if you'd pull the latest
version from GitHub, give it a good workout, and report any lingering
bugs.
Tha
Well, whatever you did, the latest release seems to have solved the
problem. Thanks!
On Thu, Oct 9, 2014 at 6:04 PM, David Lamkins wrote:
> I'm unable to reproduce this. I'll keep an eye open for its appearance on
> my machines.
>
> On Thu, Oct 9, 2014 at 1:18 PM, Blake McBride wrote:
>
>> Cre
Looks great. Thanks!
On Sat, Oct 11, 2014 at 9:51 PM, David B. Lamkins
wrote:
> The "build.h" issue is corrected in commit 0b576f6.
>
>
>
The "build.h" issue is corrected in commit 0b576f6.
...
gcc -DHAVE_CONFIG_H -I. -I..
-DMANUALS_PATH=\"/usr/local/share/doc/aplwrap\" -std=c99 -Wall -Werror
-pthread -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0
-I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0
-I/usr/include/gio-unix-2.0/ -I/usr/include/cairo
-I/usr/include/gdk-pixbuf-2.0 -I
I'm unable to reproduce this. I'll keep an eye open for its appearance on
my machines.
On Thu, Oct 9, 2014 at 1:18 PM, Blake McBride wrote:
> Create a new object that looks like this:
>
> abc
>
> def
>
>
> Note the blank line between 'abc' and 'def'. Now save it. Then open the
> object - the e
Create a new object that looks like this:
abc
def
Note the blank line between 'abc' and 'def'. Now save it. Then open the
object - the error occurs.
Thanks.
Blake
On Thu, Oct 9, 2014 at 3:13 PM, David Lamkins wrote:
> I don't see it. Please provide the sequence of steps you followed.
>
I don't see it. Please provide the sequence of steps you followed.
Now getting this error when editing a file with blank lines:
(aplwrap:12159): Gtk-CRITICAL **: gtk_text_buffer_emit_insert: assertion
'g_utf8_validate (text, len, NULL)' failed
Thanks.
Blake
On Thu, Oct 9, 2014 at 12:31 PM, David B. Lamkins
wrote:
> Thank you. Fixed and pushed.
>
> On Wed, 2
Thank you. Fixed and pushed.
On Wed, 2014-10-08 at 14:30 -0500, Blake McBride wrote:
> If you edit a function with blank lines, you get the following error
> on the console for each blank line that exists:
>
>
> (aplwrap:30307): Gtk-CRITICAL **: gtk_text_buffer_emit_insert:
> assertion 'g_utf8_v
If you edit a function with blank lines, you get the following error on the
*console* for each blank line that exists:
(aplwrap:30307): Gtk-CRITICAL **: gtk_text_buffer_emit_insert: assertion
'g_utf8_validate (text, len, NULL)' failed
Thanks.
Blake
Looks good, thanks!
On Mon, Oct 6, 2014 at 12:50 PM, David B. Lamkins
wrote:
> Changed and pushed.
>
> Blake, don't commit any syntax errors in origin-0 until you get the
> libemacs update. ;)
>
>
> On Tue, 2014-10-07 at 01:18 +0800, Elias Mårtenson wrote:
> > I try not to make incompatible chan
Changed and pushed.
Blake, don't commit any syntax errors in origin-0 until you get the
libemacs update. ;)
On Tue, 2014-10-07 at 01:18 +0800, Elias Mårtenson wrote:
> I try not to make incompatible changes. I would love to completely
> redesign it at some point but for now you can consider that
I try not to make incompatible changes. I would love to completely redesign
it at some point but for now you can consider that part stable. If I need
to redesign that part I'll probably simply implement a new command.
Regards,
Elias
On 7 Oct 2014 01:11, "David B. Lamkins" wrote:
> Did I? I guess
Did I? I guess it's a matter of interpretation. Emacs uses origin-1 for
line numbers, while APL uses origin-0.
Clearly it makes sense to maintain the Emacs sense of line numbers.
It's still proper to commit the fix (with the +1) since otherwise
gnu-apl-mode will be wrong in the case where APL run
Well, it should. :-)
It returns the error message and line number in separate fields. The Emacs
mode uses it to highlight the line that has the error.
Regards,
Elias
On 7 October 2014 01:02, David B. Lamkins wrote:
> APLwrap doesn't actually interpret the wire protocol beyond looking for
> 'er
APLwrap doesn't actually interpret the wire protocol beyond looking for
'error' in the first line. Additional lines, up to but not including the
terminating sentinel, are simply collected and displayed.
On Mon, 2014-10-06 at 11:32 +0800, Elias Mårtenson wrote:
> That's a display issue. ☺ I'm sure
That's a display issue. ☺ I'm sure aplwrap can provide an option to display
it in that way for people who prefer that (most people probably don't care
since one never actually interacts with jump indexes very often directly)
What David's patch does is to harmonise the underlying wire protocol. It
Conceptually different but significantly confusing if they are not
displayed as the same number.
On Sun, Oct 5, 2014 at 10:18 PM, Elias Mårtenson wrote:
> Thanks. I'll integrate it once I get home. Although you missed a +1 there.
> The error is reported as a line number, not an APL jump index, w
Thanks. I'll integrate it once I get home. Although you missed a +1 there.
The error is reported as a line number, not an APL jump index, which is
conceptually different thing.
Regards,
Elias
On 6 Oct 2014 01:05, "David B. Lamkins" wrote:
> Thanks, Blake. This is best fixed in libemacs.
>
> Elia
Thanks, Blake. This is best fixed in libemacs.
Elias: The attached patch makes a failed function definition report an
origin-independent line number.
On Sun, 2014-10-05 at 07:29 -0500, Blake McBride wrote:
> Looks good, but one very small problem - when it reports the line
> number with the error
Looks good, but one very small problem - when it reports the line number
with the error, it is off by one. In other words, line references in the
editor (and in APL) start at 0, but when it reports the error it reports
the line number as if they start at 1.
Thanks.
Blake
On Sat, Oct 4, 2014 at
Fixed and pushed.
On Sat, 2014-10-04 at 08:08 -0500, Blake McBride wrote:
> This is still a problem. It can create a real loss of work.
>
>
> Thanks.
>
>
> Blake
>
>
>
> On Fri, Sep 12, 2014 at 6:18 PM, Chris Moller
> wrote:
> Actually, saving shouldn't close the window in any eve
This is still a problem. It can create a real loss of work.
Thanks.
Blake
On Fri, Sep 12, 2014 at 6:18 PM, Chris Moller wrote:
> Actually, saving shouldn't close the window in any event. I'll poke at
> it. Right now, I'm looking at the open-function problem.
>
>
>
> On 09/12/14 18:46, Bla
Thank you very much! Looks great!
On Fri, Oct 3, 2014 at 4:18 PM, David Lamkins wrote:
> OK, I see. That's not quite the full fix, though. If you go to the last
> line and start typing, the line count doesn't change.
>
> Fixed and pushed.
>
>
> On Fri, Oct 3, 2014 at 1:37 PM, Blake McBride w
I pushed an APLwrap update with file Open, Save and Save As functionality.
--
"The secret to creativity is knowing how to hide your sources."
Albert Einstein
http://soundcloud.com/davidlamkins
http://reverbnation.com/lamkins
http://reverbnation.com/lcw
http://lamkins-guitar.com/
http://lamki
OK, I see. That's not quite the full fix, though. If you go to the last
line and start typing, the line count doesn't change.
Fixed and pushed.
On Fri, Oct 3, 2014 at 1:37 PM, Blake McBride wrote:
> Dear David,
>
> The problem is this: you open up a function with two lines (the header and
> on
Dear David,
The problem is this: you open up a function with two lines (the header and
one line) but the counter at the bottom says 3. The first thing you think
is; what does that number represent? It is confusing.
If you edit a function with 200 lines (God help us), it would be nice to
know it
I know. I thought about that.
I'm not convinced that adjusting the line count is the right answer. We
actually do have N lines numbered 0 to N-1.
I suppose we could display the largest line number rather than the number
of lines. Then you'd have to remember to add 1 to get the line count...
May
Dear David,
Thanks a lot! Looks a lot better. I did find one small issue with it
though.
It displays the total number of lines. Nice. Problem is, it is one
greater than the number of lines. I suppose there is a way of looking at
it such that it is correct, but that logic only worked when the
Fixed and pushed.
This is still an issue. It is actually a lot worse now too. For example,
if I just arrow up and down, the window thinks the file is modified.
When arrowing up and down the line numbers sometimes go in the wrong
direction and then jump to some other number.
Thanks.
Blake
On Sun, Sep 21, 2014
For the APLwrap users: a big batch of patches was pushed to GitHub last
night. See src/ChangeLog for a complete list.
--
"The secret to creativity is knowing how to hide your sources."
Albert Einstein
http://soundcloud.com/davidlamkins
http://reverbnation.com/lamkins
http://reverbnation.com/
;> -- Original message--
>>
>> *From: *David Lamkins
>>
>> *Date: *Mon, 2014/09/22 09:41
>>
>> *To: *bug-apl@gnu.org;
>>
>> *Cc: *Blake McBride;Chris Moller;
>>
>> *Subject:*Re: [Bug-apl] aplwrap: another problem with quad-qu
@gnu.org;
>
> *Cc: *Blake McBride;Chris Moller;
>
> *Subject:*Re: [Bug-apl] aplwrap: another problem with quad-quote
>
>
> I see it. Thanks. I'll look into this tonight.
>
>
>
>> GNU APL (without aplwrap):
>>
>> x←⍞,0⍴⍞←0⍴' '
>>
Cc: *Blake McBride;Chris Moller;
>
> *Subject:*Re: [Bug-apl] aplwrap: another problem with quad-quote
>
>
> I see it. Thanks. I'll look into this tonight.
>
>
>
>> GNU APL (without aplwrap):
>>
>> x←⍞,0⍴⍞←0⍴' '
>> abc
>>
Fixed. I forwarded the patch to Chris. -- Original message-- From: David LamkinsDate: Mon, 2014/09/22 09:41To: bug-apl@gnu.org;Cc: Blake McBride;Chris Moller;Subject:Re: [Bug-apl] aplwrap: another problem with quad-quote I see it. Thanks. I'll look into this tonight.GNU APL (wi
I see it. Thanks. I'll look into this tonight.
> GNU APL (without aplwrap):
>
> x←⍞,0⍴⍞←0⍴' '
> abc
> x
> abc
> ⍴x
> 3
>
>
> APL WRAP:
>
> x←⍞,0⍴⍞←0⍴' '
> abc
> [APLWRAP does something really strange here like repeating a prior line???]
> ⍴x
> 0
>
> Something really
GNU APL (without aplwrap):
x←⍞,0⍴⍞←0⍴' '
abc
x
abc
⍴x
3
APL WRAP:
x←⍞,0⍴⍞←0⍴' '
abc
[APLWRAP does something really strange here like repeating a prior line???]
⍴x
0
Something really wrong.
Thanks.
Blake
No problem. I like aplwrap and I appreciate the work you and David have
done!
Thanks.
Blake
On Sun, Sep 21, 2014 at 3:41 PM, Chris Moller wrote:
> Sorry--I spent most of last week putting out fires in Toronto. I'll try
> to get caught up on aplwrap stuff over the next couple of days.
>
> c
Greetings,
When you go into aplwrap File / New or File / Open the line counter starts
at line 1. This is a problem because the branches will be off by one. The
header line should be line 0. Then the branches will match the line
numbers. (Yes, I know branching to line numbers is bad form, but i
Sorry--I spent most of last week putting out fires in Toronto. I'll try
to get caught up on aplwrap stuff over the next couple of days.
cm
On 09/21/14 16:32, Blake McBride wrote:
Greetings,
I like the ability to not see the pstsat line. However I fond the
following problem.
Click File / Se
Greetings,
I like the ability to not see the pstsat line. However I fond the
following problem.
Click File / Settings / Open pstat window.
The pstat window displays. The "Close" button on the pstat window does not
work until you click "OK" on the "Settings" popup.
Thanks.
Blake
On Fri, Sep
Sorry, thought I responded to this. The problem is still there.
Thanks.
Blake
On Fri, Sep 12, 2014 at 6:35 PM, Chris Moller wrote:
> I just pushed a patch I think might fix this. Let me know how it goes..
>
> cm
>
>
>
> On 09/12/14 17:24, Blake McBride wrote:
>
> When you bring up File / O
I like it. From an implementation viewpoint, that seems cleaner than
what I was trying to do with the command-line option.
Thanks. :)
On Fri, 2014-09-12 at 22:44 -0400, Chris Moller wrote:
> File>>Settings now has a toggle to turn the status line on and off.
> I'll add the info pop-up tomorrow an
File>>Settings now has a toggle to turn the status line on and off.
I'll add the info pop-up tomorrow and, if I'm feeling enthusiastic, I'll
stick in a ~/.aplwrap to retain the states.
On 09/12/14 21:09, David Lamkins wrote:
Thanks, Chris. Much appreciated.
On Sep 12, 2014 6:07 PM, "Chris Mol
Thanks, Chris. Much appreciated.
On Sep 12, 2014 6:07 PM, "Chris Moller" wrote:
> It's easy enough to put the same thing in an info dialogue under Help.
> I'll stuff that in tonight or tomorrow but keep the status line switchable.
>
>
> On 09/12/14 20:30, David B. Lamkins wrote:
>
> I find the A
It's easy enough to put the same thing in an info dialogue under Help.
I'll stuff that in tonight or tomorrow but keep the status line switchable.
On 09/12/14 20:30, David B. Lamkins wrote:
I find the APL process stats to be useful in gauging performance issues
related to time, I/O and memory (
I find the APL process stats to be useful in gauging performance issues
related to time, I/O and memory (see APL_STATUS_LINE.md for a key to the
fields).
I can see your point, though: the status line does look "busy" and it
eats up a line or two of vertical space.
Putting this display in its own
I just pushed a patch I think might fix this. Let me know how it goes..
cm
On 09/12/14 17:24, Blake McBride wrote:
When you bring up File / Open, aplwrap displays a list of functions.
The first one appears auto-selected, but if you click OK you find it
wasn't. If you click on it first and
Actually, saving shouldn't close the window in any event. I'll poke at
it. Right now, I'm looking at the open-function problem.
On 09/12/14 18:46, Blake McBride wrote:
Greetings,
Let's say you create a large APL function using File / New. If just
one line has an open quote that isn't closed
Greetings,
Let's say you create a large APL function using File / New. If just one
line has an open quote that isn't closed, you lose all of your work. I
think aplwrap should test the result of ⎕FX before it exits. If ⎕FX fails,
display the line number with the error and remain in the editor so
The bottom of my aplwrap screen displays:
#0 ∆e: 1.18 ∆u: 0.00 ∆s: 0.00 ∆v: 52,043,776 ∆r: 3,239,936 ∆f: 983 ∆F: 0
∆b: 0.00 ∆rc: 37,908 ∆wc: 134 ∆rb: 0 ∆wb: 0 ∆ic: 29 ∆oc: 12 ∆cw: 0
This is getting kind of crazy. My suggestion is this - get rid of that
display entirely. Add a Help / Info menu
When you bring up File / Open, aplwrap displays a list of functions. The
first one appears auto-selected, but if you click OK you find it wasn't.
If you click on it first and then click okay, it works. The point is it
appears selected but it isn't. When you do actually select it, there is no
vi
Cool. Thanks for the report.
I rarely invoke aplwrap from a shell window (I usually use GNOME's
Alt-F2 launcher), so I tend to miss chatter sent to the terminal.
On Fri, 2014-09-12 at 15:18 -0500, Blake McBride wrote:
> Works for me now without errors. Thanks to all!!
>
> On Fri, Sep 12, 2014
I suspect it might have something to do with timing.
The window's "destroy" signal invokes aplwrap_quit(), which then
terminates the APL process.
The termination of the APL process invokes (due to the
g_child_watch_add() call) apl_exit(), which then tries to terminate the
APL process.
I suspect
Works for me now without errors. Thanks to all!!
On Fri, Sep 12, 2014 at 2:30 PM, Chris Moller wrote:
> I just applied and pushed David's patch, the question remaining why it
> showed up only in some environments and not others.
>
>
> On 09/12/14 15:04, David B. Lamkins wrote:
>
> I believe I'
My supposition about the lock key(s) turned out to be correct. I was
able to reproduce Blake's issue by engaging Caps Lock.
Chris, I'll send you a patch.
On Fri, 2014-09-12 at 10:00 -0700, David B. Lamkins wrote:
> I just did a pull and recompile. The copy/paste works as expected.
>
>
>
> Hmmm
I just applied and pushed David's patch, the question remaining why it
showed up only in some environments and not others.
On 09/12/14 15:04, David B. Lamkins wrote:
I believe I've found the cause of this problem.
There's something special (I don't know what) about the exit behavior of
GTK+ in
Thanks a lot, David!!
Blake
On Fri, Sep 12, 2014 at 2:04 PM, David B. Lamkins
wrote:
> I believe I've found the cause of this problem.
>
> There's something special (I don't know what) about the exit behavior of
> GTK+ in the case that there's something on the application's clipboard.
> With no
I believe I've found the cause of this problem.
There's something special (I don't know what) about the exit behavior of
GTK+ in the case that there's something on the application's clipboard.
With nothing on the clipboard, application exit was fine. With something
on the clipboard, aplwrap's apl
Good idea. I'll give that a try tonight.
On Fri, 2014-09-12 at 12:55 -0400, Chris Moller wrote:
> Can you run it under valgrind? That should find memory problems.
>
>
> On 09/12/14 12:51, David B. Lamkins wrote:
>
> > FWIW: commenting out the gtk_text_view_scroll_to_mark() call in
> > scroll_t
I just did a pull and recompile. The copy/paste works as expected.
Hmmm... thinking... looking at the code...
I'll bet you have a lock key (shift lock? num lock?) engaged.
I'll have to go through and mask those out. Sorry...
Might not get to this until tonight...
On Fri, 2014-09-12 at 12:5
Can you run it under valgrind? That should find memory problems.
On 09/12/14 12:51, David B. Lamkins wrote:
FWIW: commenting out the gtk_text_view_scroll_to_mark() call in
scroll_to_cursor() does not affect the crash that I'm seeing (which is
different in its details from the crash that Blake
It all works fine here:
Fedora release 20 (Heisenbug)
kernel 3.14.5-200.fc20.x86_64 #1 SMP GNU/Linux
gtk3-3.10.9-1.fc20.x86_64
On 09/12/14 12:43, Blake McBride wrote:
Dear David,
I am using the latest git on aplwrap but the backspace on paste still
doesn't work for me.
Glad to hear someo
FWIW: commenting out the gtk_text_view_scroll_to_mark() call in
scroll_to_cursor() does not affect the crash that I'm seeing (which is
different in its details from the crash that Blake reported). I still
get a memory corruption report, though...
On Fri, 2014-09-12 at 09:46 -0700, David B. Lamkins
I reached similar conclusions. It seems that copy/paste tickles this
bug.
Copy, then paste, then evaluate, then click the close box: this is
enough to give me GTK+ errors and even stack dumps.
These are probably the important clues:
GLib-GObject-WARNING **: invalid unclassed pointer in cast to
'
Dear David,
I am using the latest git on aplwrap but the backspace on paste still
doesn't work for me.
Glad to hear someone else is getting the crash error.
Thanks.
Blake
On Fri, Sep 12, 2014 at 11:38 AM, David B. Lamkins
wrote:
> To be clear: this patch is for the copy/paste behavior.
>
> T
To be clear: this patch is for the copy/paste behavior.
There's still the crash on exit; I'll write about that in the other
thread.
On Fri, 2014-09-12 at 12:27 -0400, Chris Moller wrote:
> I just applied that patch and pushed it to github. Blake, can you try
> it and see if you still get errors?
The backspaces I use don't work, but attempting it causes the problem. I
am at git commit 5352f834aba8f8620dcbb4ab1aab3bb64aede4a4
Do you get the error there?
Thanks.
Blake
On Fri, Sep 12, 2014 at 11:24 AM, Chris Moller
wrote:
> No, I don't get get a failure, but as you pointed out in an e
I just applied that patch and pushed it to github. Blake, can you try
it and see if you still get errors?
Thx
On 09/12/14 12:20, David B. Lamkins wrote:
I sent Chris a patch for this issue.
On Fri, 2014-09-12 at 07:51 -0700, David B. Lamkins wrote:
I noticed that last night.
The GTK+ fram
No, I don't get get a failure, but as you pointed out in an earlier
post, the copied 'abc' is uneditable--and I just saw that David has
fixed that. I'll have that patch up in a couple of minutes.
Chris
On 09/12/14 11:47, Blake McBride wrote:
Here are the steps that reproduce the problem:
1.
I sent Chris a patch for this issue.
On Fri, 2014-09-12 at 07:51 -0700, David B. Lamkins wrote:
> I noticed that last night.
>
> The GTK+ framework preserves text attributes during copy and paste.
> Since the transcript text is not editable, neither is a pasted copy of
> some selection of that te
Interestingly, the error shows on the console, and the aplwrap window
disappears BUT the aplwrap process is still running.
On Fri, Sep 12, 2014 at 10:47 AM, Blake McBride wrote:
> Here are the steps that reproduce the problem:
>
> 1. Execute aplwrap
>
> 2. Type the following:
>
>
Here are the steps that reproduce the problem:
1. Execute aplwrap
2. Type the following:
∇test
[1] abc
[2]
3. Highlight and COPY (^C) the 'abc'
4. Click on the end of the [2] line
5. PASTE (^V) the 'abc' (has no quotes)
6. Hit the backspace key 3 times
7. Hit the X in t
I noticed that last night.
The GTK+ framework preserves text attributes during copy and paste.
Since the transcript text is not editable, neither is a pasted copy of
some selection of that text.
I'll see whether I can figure out how to override that behavior.
Meanwhile, you can use aplwrap's "co
I am using vanilla LinuxMint 16. GTK comes with it. Upgrading to test is
sort of a big job that messes up auto-update. Let me see if I can get an
exact sequence to duplicate the problem instead. Is that okay?
On Fri, Sep 12, 2014 at 8:49 AM, Chris Moller wrote:
> Can you try putting in a ne
Can you try putting in a newer version? 3.8.7 is from November of last
year. They've done a lot of bug-fixing since then and it would be good
to know if the bug is on my end or in GTK.
On 09/12/14 09:40, Blake McBride wrote:
Looks like I am running 3.8.7
On Fri, Sep 12, 2014 at 8:25 AM,
Looks like I am running 3.8.7
On Fri, Sep 12, 2014 at 8:25 AM, Chris Moller wrote:
> What version of GTK are you using? I'm running 3.10.9 though in
> configure.ac I'm only checking for versions >= 3.0.12. There may be some
> incompatibility.
>
>
>
> On 09/12/14 08:39, Blake McBride wrote:
>
What version of GTK are you using? I'm running 3.10.9 though in
configure.ac I'm only checking for versions >= 3.0.12. There may be
some incompatibility.
On 09/12/14 08:39, Blake McBride wrote:
Greetings,
I was in the middle of editing a function using the regular
del-editor, I copied and
Greetings,
I was in the middle of editing a function using the regular del-editor, I
copied and pasted a line, I then exited aplwrap by clicking on the x in the
upper left hand corner of the screen without closing the function I was
editing. Aplwrap gave me:
(aplwrap:29325): Gtk-CRITICAL **: gtk
Greetings,
If I type a line, before I hit enter I can backspace or arrow around the
line to edit it. This is very convenient when you type in a long line and
realize you made a typo somewhere in the middle. You are able to correct
the problem without retyping the rest of the line.
Unfortunately
* Added a status line to aplwrap (by David Lamkins).
* Added capabilities to aplwrap and aplplot to allow plots to be
embedded in the aplwrap transcript.
Hi,
I changed GNU APL to use libncurses for figuring Input and
output ESC sequences if configured to do so.
This should make GNU APL terminal independent as proposed by
David.
The input (keyboard → APL) and output (APL → screen) can be
co
I wrote an ANSI terminal emulator decades ago. It's not a small task.
Even if you take a small subset of the control codes, there are still
some tricky architectural issues to consider w.r.t. how a screen-based
console would function within the transcript-based model presented by
aplwrap.
If you'
There was some discussion about setting the TERM environment variable,
which David Lamkins did for aplwrap, setting it to "dumb"--i.e., aplwrap
doesn't understand terminal controls. Nothing says it can't be made to
do so, but I've no idea at the moment the scope of work involved.
FWIW, though, I
This was fixed before but doesn't work anymore. I use it a lot, and having
it work just like GNU APL without APLWRAP is very useful to me.
Thanks.
Blake
On Mon, Aug 18, 2014 at 10:23 AM, Blake McBride wrote:
> Greetings,
>
> Some of my error handling code uses the bell (⎕AV[⎕IO+7]), and my
Can't believe I forgot to update. Thanks.
On Mon, Sep 8, 2014 at 12:38 AM, David B. Lamkins
wrote:
> aplwrap 2.0:
>
> x←⍞,0⍴⍞←'abcde'
> abcdefghij
> x
> fghij
> ⍴x
> 10
>
>
> On Sun, 2014-09-07 at 22:00 -0500, Blake McBride wrote:
> > GNU APL & IBM APL:
> >
> >
> >
aplwrap 2.0:
x←⍞,0⍴⍞←'abcde'
abcdefghij
x
fghij
⍴x
10
On Sun, 2014-09-07 at 22:00 -0500, Blake McBride wrote:
> GNU APL & IBM APL:
>
>
> x←⍞,0⍴⍞←'abcde'
> abcdefghij
> x
> fghij
> ⍴x
> 10
>
>
>
>
>
>
> APLWRAP:
>
>
> x←⍞,0⍴⍞←'abcde'
>
GNU APL & IBM APL:
x←⍞,0⍴⍞←'abcde'
abcdefghij
x
fghij
⍴x
10
APLWRAP:
x←⍞,0⍴⍞←'abcde'
abcdefghij
x
fghij
⍴x
5
Thanks.
Blake
Great. I'm glad to see it works for you. :-)
On 7 September 2014 23:15, Chris Moller wrote:
> Yes, I'm using your socket interface, but I'm not using all the
> commands. Right now, I'm just using "variables" to extract the list of
> functions (and, eventually, both fcns and vars), "fn" to extr
Yes, I'm using your socket interface, but I'm not using all the
commands. Right now, I'm just using "variables" to extract the list of
functions (and, eventually, both fcns and vars), "fn" to extract the
functions (and, eventually, "getvar") and "def."
Chris
On 09/07/14 10:59, Elias Mårtenson w
Cool! Are you using the Emacs mode protocol?
If so, are you using all the commands? I just want to know in case I would
like to make changes. :-)
Regards,
Elias
On 7 September 2014 22:46, Chris Moller wrote:
> I just pushed aplwrap 2.0, which incorporates a lot of work by David
> Lamkins and
I just pushed aplwrap 2.0, which incorporates a lot of work by David
Lamkins and adds an editor.
Summary of changes since v 1.0:
*
Correct display of APL output.
*
--LX command-line argument to pass expression or command to APL.
*
--rows-var command-line argument lets APL k
[image: Inline images 1]I use FreeFont in my Emacs windows, and this is
what it looks like there. I don't see any problems with it.
Regards,
Elias
On 19 August 2014 02:27, David B. Lamkins wrote:
> The GNU FreeFont (which includes FreeMono) project page is here:
>
> https://www.gnu.org/softwar
The GNU FreeFont (which includes FreeMono) project page is here:
https://www.gnu.org/software/freefont/
There's a link for problem reports.
Very good point. TERM=dumb is probably a good choice.
Perhaps an error in the font design that has never been noticed and
corrected... (Who would someone even report a problem like this to?)
On Mon, Aug 18, 2014 at 12:36 PM, David B. Lamkins
wrote:
> The slant isn't pronounced, but I can definitely see what Blake is
> seeing. (See the attached cl
1 - 100 of 111 matches
Mail list logo
