Re: Still some issues/warnings..

Brings back unfond memories of decades ago of the significance of invisible leading tabs in Makefiles... On 10/20/22 08:06, Dr. Jürgen Sauermann wrote: Hi again, I may have found the problem. I am so much used to nicely looking indentation that my brain keeps refusing to remember the counter-

Re: Unexpectedly offline

A lousy way to start a year.  Gute Besserung,Jürgen. --cm On 1/22/23 08:07, Dr. Jürgen Sauermann wrote: Gentlemen, I am sorry for not responding earlier to any emails to bug-apl@gnu.org. I was unexpectedly taken offline after new year and I am now online again, although only for a short perio

Re: libapl stdout

For what it's worth, in an ongoing project in use: #include #include #include #include #include "aplexec.h" LIBAPL_error AplExec::aplExec (apl_op_e apl_op, QString &cmd,   QString &outString, QString &errString) {  LIBAPL_error execerr = LAE_NO_ERRO

Re: libapl stdout

make install.) On 1/27/23 16:28, enz...@gmx.com wrote: Chris i don't have qt installed nor do i have your #include "aplexec.h" On Fri, 27 Jan 2023 11:23:08 -0500 Chris Moller wrote: For what it's worth, in an ongoing project in use: #include #include #

Re: libapl stdout

tring (res); ./libaplc.c:44:errString = QString (errbuffer.str ().c_str ()); On Fri, 27 Jan 2023 17:18:01 -0500 Chris Moller wrote: Qt isn't necessary--that's just the environment I'm working in.  From my example, get rid of the #include line. Here's aplexec.h: #ifndef

Re: libapl stdout

t std::string is close.  See: https://cplusplus.com/reference/string/string/ On 1/27/23 19:47, enz...@gmx.com wrote: sorry that means nothing to me as to what to replace the qstring below with On Fri, 27 Jan 2023 19:38:51 -0500 Chris Moller wrote: QString is mmore or less equivalent to

libapl.cc bug

Hi, Jürgen, Xtian Robert just sent me a libedif bug, but building libapl.so so I could fix that bug I found a few libapl bugs of the form: libapl.cc: In function ‘void disable_safe_mode()’: libapl.cc:985:4: error: ‘uprefs’ was not declared in this scope  985 |    uprefs.safe_mode = f

Re: SVN 1704 completely broke libedif

Hi, Xtian, Just pushed a fix for edif if you want to give it a try.  Works for me on SVN 1706 and yesterday's SVN 1708. --cm On 6/5/23 03:33, Christian Robert wrote: SVN 1704 completely broke libedif Juergen made UCS_string (const char *)  a private member of the class so a lot of compile e

Re: SVN 1704 completely broke libedif

the "make" worked fine thereafter Xtian. On 2023-06-06 11:31, Chris Moller wrote: Hi, Xtian, Just pushed a fix for edif if you want to give it a try.  Works for me on SVN 1706 and yesterday's SVN 1708. --cm On 6/5/23 03:33, Christian Robert wrote: SVN 1704 completely br

Re: SVN 1704 completely broke libedif

t in the header file, but I have seen quite a few incorrect usages of it (read: with UTF8-encoded strings) which then caused other, difficult to find, errors later on. Best Regards, Jürgen On 6/6/23 17:31, Chris Moller wrote: Hi, Xtian, Just pushed a fix for edif if you want to give it a try.

Re: SVN 1704 completely broke libedif

e automatic use of 2. by the compiler. It is also easier to use with *grep* in order to spot the (still possible) incorrect usage of 5. Hope this helps, Jürgen On 6/6/23 22:13, Chris Moller wrote: Yeah, I saw your comment in one of the .hh files.  What I did was wrap all the edif ASCII st

Re: apl won't start

Is the battery dead? :-) On 8/10/23 09:55, Bill Daly wrote: Log of session attached w OpenPGP_0xDA6C0193083E.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature

Re: output formatting

Try adding the option "--PW 1000" (or any large number less than 1).  That will set the print width to huge. The tr utility with the -s option can compress repeated spaces into a single space. sed '$d' will kill the last line. So something like apl --PW 500 --eval "2 70⍴⍳140" | tr -s

General chatter.

First, due to my old ISP having apparently gone out of business while keeping my mollerware.com domain locked, my old mol...@mollerware.com address is at least temporarily dead.  I'm mol...@nc.rr.com for the moment. Second, is there a Windows version of APL that runs without using Cygwin?  My

Re: General chatter.

ommercial APL vendors offer Windows based APL imterpreters which are free of charge for private use but not free because they come with limitations as to their use. Best Regards, Jürgen On 3/29/24 18:47, Chris Moller wrote: First, due to my old ISP having apparently gone out of business while

Re: General chatter.

com/dyalog/current-platforms.htm On Fri, Mar 29, 2024 at 12:47 PM Chris Moller wrote: First, due to my old ISP having apparently gone out of business while keeping my mollerware.com <http://mollerware.com> domain locked, my old mol...@mollerware.com address is at least temporaril

[Bug-apl] Command-line bug, apl-1.3

apl.texi and the files derived from it refer to a command line option "[no]COLOR," but in main.cc the options are "Color" and "noColor." apl --noColor works apl --noCOLOR yields "unknown option '--noCOLOR'"

[Bug-apl] A GTK wrapper for GNU APL

into the utility. If you're interested, all the links are in the last entry in the Community page at http://www.gnu.org/software/apl/Community.html For more information, there are INSTALL and README files in the package. Any bugs or feature requests, let me know. Chris Moller

Re: [Bug-apl] A GTK wrapper for GNU APL

The --with-apl-source-dir= thing is left over from an old version and I forget to take it out of the INSTALL file. Now it asks apl itself where the source is. If it's important, I can stick the option back in, but, mostly, it should do things automagically. You can set the font size with the

Re: [Bug-apl] A GTK wrapper for GNU APL

Monospace added; use option -m On 08/12/14 18:47, David Lamkins wrote: Nice start! Thanks for doing this. :) --with-apl-source-dir= is not recognized by configure, but APL_SOURCES= ./configure seems to work. A few obvious things for the wish list: 1. a monospaced font 2. ability to adjust

Re: [Bug-apl] A GTK wrapper for GNU APL

ch my actual keyboard (which was designed to match the GNU APL standard.) Thanks. Blake On Tue, Aug 12, 2014 at 1:43 PM, Chris Moller <mailto:mol...@mollerware.com>> wrote: I've written a GTK+-based wrapper for APL and Jürgen suggested I tell people about it...

Re: [Bug-apl] A GTK wrapper for GNU APL

On 13 August 2014 13:27, David Lamkins <mailto:da...@lamkins.net>> wrote: On Tue, Aug 12, 2014 at 5:59 PM, Chris Moller mailto:mol...@mollerware.com>> wrote: The --with-apl-source-dir= thing is left over from an old version and I forget to take it out of the

Re: [Bug-apl] A GTK wrapper for GNU APL

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. *

Re: [Bug-apl] A GTK wrapper for GNU APL

* 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

Re: [Bug-apl] A GTK wrapper for GNU APL

David Lamkins wrote: 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 <mailto:mol...@mollerware.com>> wrote: * Added the command-line stuff. * Fixed the assi

Re: [Bug-apl] A GTK wrapper for GNU APL

ique VI Vck WPrintWS2 ∆ ∆DTDT2∆LLP∆LP ∆LPH ∆RD ∆SS Look at the ∆DT2 at the bottom of each. Look at the subsequent alignment on that line. Remember this is the same workspace. Thanks. Blake On Wed, Aug 13, 2014

Re: [Bug-apl] GNU APL GTK wrapper

I'll take a look at that. Is your protocol documented somewhere? Or is it implicit in gnu-apl-mode/native? cm On 08/13/14 23:28, Elias Mårtenson wrote: 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 integ

Re: [Bug-apl] A GTK wrapper for GNU APL

A few more patches pushed, including mapping the keyboard interrupt to the ctrl-break key. cm On 08/13/14 19:24, Blake McBride wrote: 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

Re: [Bug-apl] GNU APL GTK wrapper

iables Trace updates to a variable List all system commands List all quad-variables Show the si-stack Clear the si-stack Get the tag for a function (the tag contains the source file and line where it was defined) If you need other commands, it's trivial to add. Regards, Elias On 15 Aug 2014 04

[Bug-apl] Possible bugs in ]keyb output

ealing with these differences in ]keyb output. Chris Moller

Re: [Bug-apl] A GTK wrapper for GNU APL

DK_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 pleasant. As it is right now, aplwrap doesn't send text to GnuAPL on return key presses when the 'NumLock' is active. Thanks, Fred Retired Chemic

Re: [Bug-apl] A GTK wrapper for GNU APL

Applied, committed, and pushed to github. Chris Retired Computer Engineer On 08/16/14 17:51, Frederick H. Pitts wrote: Chris, I'm using if ( /* Filter out NumLock status from event state */ ( key_event->state & ~ GDK_MOD2_MASK ) == 0 && ( key_event->k

Re: [Bug-apl] Requesting a couple of minor keyboard tweaks.

On 08/16/14 22:09, David B. Lamkins wrote: There are two small tweaks that I'd like to see w.r.t. key mapping and binding: 1. GNOME binds alt-` to rotate through an applications windows, making this keystroke unavailable for ◊ in aplwrap. Through trial and error I discovered that I can use ctrl

Re: [Bug-apl] Requesting a couple of minor keyboard tweaks.

een pushed. On 08/17/14 00:30, David B. Lamkins wrote: On Sat, 2014-08-16 at 22:45 -0400, Chris Moller wrote: On 08/16/14 22:09, David B. Lamkins wrote: There are two small tweaks that I'd like to see w.r.t. key mapping and binding: 1. GNOME binds alt-` to rotate through an applications

Re: [Bug-apl] aplwrap: what's with the s?

I'm not seeing it: 'S' and 's' both look normal to me. As part of installing aplwrap, I put a copy of Freemono.ttf in $INSTALLDIR/share/fonts and run fc-cache. If you don't already have Freemono.ttf, this makes it available, but if you already have a copy, whatever you already had may take pr

Re: [Bug-apl] Possible bugs in ]keyb output

r APL interpreters and also understood by GNU APL (and mapped to chars in ?AV). /// Jürgen On 08/16/2014 09:26 PM, Chris Moller wrote: For a few days, David Lamkins and I have been kicking around a problem in the ]keyb output. Turns out the least tractable of these seems to be the result of two diff

Re: [Bug-apl] Patch: cout buffer control

This may be a result of buffer sizes. I don't know enough about C++ to know how to do it, but maybe if you reduce the buffer size, it will reduce the latency. On 08/22/14 11:08, David Lamkins wrote: I agree: cout << endl should flush the buffer. It does when stdout is a tty. For some reason, t

Re: [Bug-apl] GNU APL GTK wrapper

Hi, Elias, I have indeed started adding a few APL-interaction features to aplwrap, one of the first of which uses your "variables" command, which leads me to a request: a variation in VariablesCommand.cc of "cls = ALL" that tags the entries in the returned list with their name classes. That mak

Re: [Bug-apl] GNU APL GTK wrapper

ith a small change. The format is now NAME (space) NC Regards, Elias On 28 August 2014 22:57, Chris Moller mailto:mol...@mollerware.com>> wrote: Hi, Elias, I have indeed started adding a few APL-interaction features to aplwrap, one of the first of which uses your "va

[Bug-apl] aplwrap 2.0

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

Re: [Bug-apl] aplwrap 2.0

t;def." Chris On 09/07/14 10:59, Elias Mårtenson wrote: 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 mailto:mol...@mollerware.com>&

[Bug-apl] While I'm at it...

...a bit more spam. If anyone's interested, I've got another APL-related work-in-progress: aplplot. It provides a way of plotting APL vectors and arrays. At the moment it handles: * multiple-curve linear and log XY plots, * polar plots, * complex-vector plots in 3-space * various kinds o

Re: [Bug-apl] aplwrap: bell & ANSI controls

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

Re: [Bug-apl] Error building latest aplwrap

Cool of your compiler to catch that. Fixed and the fix pushed. cm On 09/10/14 21:21, Blake McBride wrote: Compiled on a 64 bit Linux box. ... gcc -DHAVE_CONFIG_H -I. -I..-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/in

[Bug-apl] aplwrap 2.1

* 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.

Re: [Bug-apl] aplwrap assertion failures

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

Re: [Bug-apl] aplwrap assertion failures

25 AM, Chris Moller <mailto:mol...@mollerware.com>> wrote: What version of GTK are you using? I'm running 3.10.9 though in configure.ac <http://configure.ac> I'm only checking for versions >= 3.0.12. There may be some incompatibility. On 09

Re: [Bug-apl] aplwrap assertion failures

r corner to force aplwrap to exit. This causes the error. Does this give you errors too? Thanks. Blake On Fri, Sep 12, 2014 at 9:05 AM, Chris Moller mailto:mol...@mollerware.com>> wrote: On 09/12/14 09:58, Blake McBride wrote: I am using vanilla LinuxMint 16. GTK comes with it. U

Re: [Bug-apl] aplwrap needs to be able to edit paste lines

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

Re: [Bug-apl] aplwrap needs to be able to edit paste lines

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? > > Thx > > > On 09/12/14 12:20, David B. Lamkins wrote:

Re: [Bug-apl] aplwrap assertion failures

an exact sequence to > duplicate the problem instead. Is that okay? Sure. And I might have a spare machine I can install 3.8.7 on just to see what happens. > > On Fri, Sep 12, 2014 at 8:49 AM, Chris Moller > wrote:

Re: [Bug-apl] aplwrap assertion failures

certainly responsible for the heap corruption I saw. Also, it looked as if the GtkTextBuffer and associated objects got torn down while APL was still alive; this was responsible for a lot of GTK+ assertion failures in my tests. Both of these issues are fixed. I'll send Chris the patch. On Fri,

Re: [Bug-apl] aplwrap - editing functions with errors

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

Re: [Bug-apl] aplwrap - File / Open auto-select issue

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

Re: [Bug-apl] aplwrap - bottom display

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 (

Re: [Bug-apl] aplwrap - bottom display

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,

Re: [Bug-apl] aplwrap - bottom display

e: 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.

Re: [Bug-apl] About aplwrap

Hi, y'all, I just stuck this patch in. It works fine for me, but, Christian, if you could try it in your environment, I'd appreciate it. Chris (also, BTW, "Christian" who happens to have a son named Robert Christian Moller) On 03/29/16 18:42, Christian Robert wrote: Hi Chris, I found

[Bug-apl] aplwrap

./autogen.sh should fix it, and I'll try to schedule myself an upgrade sometime soon. Happy hacking, Chris Moller

[Bug-apl] Possible bug in APL

(libapl.cc:435) ==14122==    by 0x4048F9: main (gapl.c:685) The line in LibPaths.cc is: unused = realpath(APL_lib_root, APL_lib_root); which could obviously cause a collision. I don't know if this is a real problem or not, but I thought I ought to  mention it to someone. Chris Moller

Re: [Bug-apl] Possible bug in APL

essage suggests that this bug causes no harm (a memory area is copied to itself, which is an overlap but one that causes no harm). It also looks to me as if you are using an older GNU APL version because I cannot find the line in Libpath.cc that you quote below in the current GNU APL code. Th

Re: [Bug-apl] Possible bug in APL

I got that non-working version of apl-1.7.tar.gz from ftp.gnu.org/pub/gnu/apl, dated 17 March 2017, so I guess it's a bit out-of-date. I just now got a chance to pull down the savannah svn version, which ./configures fine, but there a few compile errors with g++ (GCC) 8.1.1 20180502 (Red Hat

[Bug-apl] Yet another editor thingy.

After battling for decades with the ancient nabla editor, I finally did something I should have done years ago and write a simple native function that let's you use emacs or vi from inside an APL session.  It's not even close to Elias Mårtenson's cool emacs APL mode--it's just a quick thing to

Re: [Bug-apl] Yet another editor thingy.

working on that now. --Chris /// Jürgen On 07/15/2018 10:47 PM, Chris Moller wrote: After battling for decades with the ancient nabla editor, I finally did something I should have done years ago and write a simple native function that let's you use emacs or vi from inside an APL sess

[Bug-apl] Another trivial g++ 8.1.1 incompatibility

This is the same as the last batch--don't know how I  missed it the first time: Index: Svar_DB.cc === --- Svar_DB.cc  (revision 1055) +++ Svar_DB.cc  (working copy) @@ -316,7 +316,8 @@    

Re: [Bug-apl] Yet another editor thingy.

reak anything, at least under Fedora 28 Linux, kernel 4.16.13. --Chris On 20/07/18 15:33, Chris Moller wrote: Hi, Jürgen, On 18/07/18 05:36, Juergen Sauermann wrote: Hi Chris, thank you for contributing this. I have added a link on our community page http://www.gnu.org/software/apl/Communit

Re: [Bug-apl] Yet another editor thingy.

r system call that failed because of EINTR. Here, we should call fgetc again. Best, Xiao-Yong On Jul 29, 2018, at 4:10 PM, Chris Moller wrote: Hi, Jürgen, So far as I can tell, after all the testing I can throw at it, my editor interface function is ready for the world. Unfortunately, it ne

Re: [Bug-apl] Yet another editor thingy.

f (b0 == EOF)    { +   if (errno == EINTR) { + clearerr (stdin); + CIN.unsetf( std::ios_base::unitbuf ); + goto again; +   }     if (got_WINCH)    { got_WINCH = false; On 29/07/18 22:00, Chris Moller

Re: [Bug-apl] Yet another editor thingy.

e the workspace.  So while, as far as edif is concerned you can have multiple simultaneous sessions aimed at the same lib0 workspace, you probably shouldn't do it. Also, I've no idea if Windows or any Linux distribu

Re: [Bug-apl] Yet another editor thingy.

/18 07:12, Hans-Peter Sorge wrote: Hello Chris, thank you for this master piece. The line editing in GNU APL is a bit cumbersome. But the apl session gets blocked during editing (edif2). Currently I have no clue, how to analyze it. Thank you again. Hans-Peter Am 30.07.2018 um 20:52 schri

Re: [Bug-apl] Yet another editor thingy.

. 2. Wouldn't it be cleaner if you save the state of CIN and CERR when you enter your editor and restore it when leaving it? Right now the state of CIN and CERR seems to change after hitting ^C for the first time. /// Jürgen On 08/02/2018 03:14 PM, Chris Moller wrote: I thought I'd fixe

Re: [Bug-apl] Yet another editor thingy.

y, but I'm still hacking at it. It doesn't appear to be directly related to the EINTR patch in LineInput::get_uni(), though at least stdin has to be cleared when errno == EINTR. -- Chris On 02/08/18 13:12, Chris Moller wrote: I agree with you.  I'm not all that pleased with it

Re: [Bug-apl] Yet another editor thingy.

;t caused any signal problems with those fgetc()s, but it's not impossible.  It might be worthwhile putting in some code to catch EOF/EINTR conditions on them too. --Chris On 03/08/18 16:34, Chris Moller wrote: Hi, Jürgen, Just to keep you updated, what seems to be happening is that after

Re: [Bug-apl] Yet another editor thingy.

Hans-Peter, If you want to try it again, I'm pretty sure I've fixed that bug in edif2--I just committed the update to https://github.com/ChrisMoller/edif --Chris On 02/08/18 07:12, Hans-Peter Sorge wrote: Hello Chris, thank you for this master piece. The line editing in GNU APL is a bit

Re: [Bug-apl] Yet another editor thingy.

OS/2?  Now /that/ was a lot of years ago... :-) On 07/08/18 16:22, Hans-Peter Sorge wrote: Hello Chris, thank you (Really  a  lot:-). Works like a charm. Feels like OS/2-times :_)) Greetings Hans-Peter Am 07.08.2018 um 19:09 schrieb Chris Moller: Hans-Peter, If you want to try it

Re: [Bug-apl] Yet another editor thingy.

ly? Best Regards, /// Jürgen On 08/07/2018 07:09 PM, Chris Moller wrote: Hans-Peter, If you want to try it again, I'm pretty sure I've fixed that bug in edif2--I just committed the update to https://github.com/ChrisMoller/edif --Chris On 02/08/18 07:12, Hans-Peter Sorge wrote:

Re: [Bug-apl] ⎕GTK

Excellent! On 10/08/18 13:32, Juergen Sauermann wrote: Hi, I have added a new system function *⎕GTK *to GNU APL. *⎕GTK* is based on libgtk+ version 3 and provides a simple (and therefore somewhat restricted) way of creating and  managing GUIs from an APL program. Think of it as a replacement

Re: [Bug-apl] Yet another editor thingy.

ly? Best Regards, /// Jürgen On 08/07/2018 07:09 PM, Chris Moller wrote: Hans-Peter, If you want to try it again, I'm pretty sure I've fixed that bug in edif2--I just committed the update to https://github.com/ChrisMoller/edif --Chris On 02/08/18 07:12, Hans-Peter Sorge

Re: [Bug-apl] Yet another editor thingy.

t I should check for EINTR .in that one as well. Best Regards, /// Jürgen On 08/10/2018 03:35 PM, Chris Moller wrote: I'm not sure how much the reversion would revert.  If it was the patch I sent you on 2 August: Inde

[Bug-apl] edif update

I just committed a minor patch to edif, fixing a relatively low probability bug involving a possible message queue name collision if you have two or more APL sessions open simultaneously. https://github.com/ChrisMoller/edif --cm

Re: [Bug-apl] edif update / ⎕IO is 0

I  wasn't closely following the first series of posts about this bug but, for what it's worth, I can reproduce it regardless of whether edif or edif2 has been ⎕fx-ed.  Neither edif nor edif2 do anything with ⎕io. [0] ~tinkering/apl-natives/vis/src >apl -L startup -q $@   ⎕io 1   edif2

Re: [Bug-apl] edif update / ⎕IO is 0

#x27;qio_test' 1 1 Greetings Hans-Peter Am 14.08.2018 um 18:17 schrieb Chris Moller: I just committed a minor patch to edif, fixing a relatively low probability bug involving a possible message queue name collision if you have two or more APL sessions open simultaneously. https://github.com/ChrisMoller/edif --cm

Re: [Bug-apl] edif update / ⎕IO is 0

l session again. edif: latest git. apl:  1069M Best Regards, Hans-Peter Am 16.08.2018 um 21:31 schrieb Chris Moller: Not that I expected otherwise, but edif and edif2 still work as expected. cm On 16/08/18 15:14, Juergen Sauermann wrote: Hi Hans-Peter, thanks, hopefully fixed in *S

Re: [Bug-apl] edif update / ⎕IO is 0

- There is on other quirk too:   'libedif.so' ⎕fx 'edif2' edif2   'libedif.so' ⎕fx 'edif2' edif2   )off double free or corruption (fasttop) Abgebrochen (Speicherabzug geschrieben) [segmentation fault] Best rega

Re: [Bug-apl] edif update / ⎕IO is 0

e - There is on other quirk too:   'libedif.so' ⎕fx 'edif2' edif2   'libedif.so' ⎕fx 'edif2' edif2   )off double free or corruption (fasttop) Abgebrochen (Speicherabzug geschrieben) [segmentation fault] Best regards, Hans

Re: [Bug-apl] edif update / ⎕IO is 0

econds But now, on a naked WS, the corruption is gone sofar I could not repeat a subsequent corruption until after a reboot! [joy@joyw520 ~]$ apl   'libedif.so' ⎕fx 'edif2' edif2   'libedif.so' ⎕fx 'edif2' edif2   )off Goodbye. Sessi

Re: [Bug-apl] edif update / ⎕IO is 0

oot! [joy@joyw520 ~]$ apl   'libedif.so' ⎕fx 'edif2' edif2       'libedif.so' ⎕fx 'edif2' edif2   )off Goodbye. Session duration: 6.48602 seconds Best regards, Hans-Peter Am 20.08.2018 um 05:26 schrieb Chris Moller: Hi, Hans-Peter, That qui

Re: [Bug-apl] edif update / ⎕IO is 0

f2' instead of 'libedif2.so' ⎕fx 'edif2' -- However, the latest version still segfaults on 'libedif2.so' ⎕fx 'edif2' 'libedif2.so' ⎕fx 'edif2' )off and 'libedif.so' ⎕fx 'edif2' 'libedif.so' ⎕fx 'edif2

Re: [Bug-apl] edif update / ⎕IO is 0

Hi, Hans-Peter, Something occurred to me last night... When edif2 starts, it fork()s but instead of exec()ing it just goes into an inotify() read loop,  That leaves two APL processes running and when they're killed they both call the edif2 close_fun().  Among other things, close_fun() frees v

Re: [Bug-apl] edif update / ⎕IO is 0

Yeah, I've noticed that APL gets unhappy when stdout/stderr interferes with its pty.  I tried to pull down a trial version of slickedit just to see what was going on, but stopped when it asked me for a credit card on which to charge 300USD, so I'm only guessing that the output you're seeing is

Trivial feature request

-LX "((4 5 6)+(7 8 9))÷2" Without the patch, apl just goes into accepting-input mode; with it, apl can be used, for example, to evaluate expressions in scripts: VAL=`apl --OFF -s --LX "((4 5 6)+(7 8 9))÷2"` Thanks, Chris Moller

Re: Trivial feature request

point on the condition.) Thanks. Blake On Wed, Jan 1, 2020 at 8:33 PM Chris Moller <mailto:mol...@mollerware.com>> wrote: Hi, Jürgen, A really minor request: Index: src/main.cc === ---

Re: Trivial feature request

ed etc. To get the quotes into apl they need to be escaped according to the shell's rules. *SVN 1215*. Best regards, Jürgen On 1/2/20 3:33 AM, Chris Moller wrote: Hi, Jürgen, A really minor request: Index: src/main.cc ===

Re: Trivial feature request

Excellent! Thanks, Chris On 05/01/2020 11:35, Dr. Jürgen Sauermann wrote: Hi Chris, yes, fixed in *SVN 1220*. Best Regards, Jürgen On 1/5/20 4:09 PM, Chris Moller wrote: Would it be worthwhile having --eval imply --noColor?  The most common use of --eval, I suspect, will just want the

Probably minor bug

Shape.hh: In member function 'Shape Shape::insert_axis(Axis, ShapeItem) const': Shape.hh:69:46: error: ''target_mem_ref' not supported by dump_expr' may be used uninitialized in this function [-Werror=maybe-uninitialized]    69 |  loop(r, MAX_RANK)   rho[r] = other.rho[r];   |  

Re: Probably minor bug

o fix this, but I am afraid that this may take some time. My bug report was merged into a meta-bug which is open since 2005: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Best Regards, Jürgen On 6/27/20 5:01 PM, Chris Moller wrote: Shape.hh: In member function 'Shape Shape::i

aplwrap

s now, in case you want your screen(s) to be more attention-getting. Anyway:  https://github.com/ChrisMoller/aplwrap Chris Moller

Re: aplwrap

ake 1.15.1 installed (what comes with this version of the OS). Thanks! Blake McBride On Sun, Jun 28, 2020 at 10:03 AM Chris Moller <mailto:mol...@mollerware.com>> wrote: I haven't any if idea if anyone is still using the aplwrap thing David Lamkins and I hacked togethe

Re: aplwrap

target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/blake/Backup/aplwrap.git' Makefile:333: recipe for target 'all' failed make: *** [all] Error 2 On Sun, Jun 28, 2020 at 1:20 PM Chris Moller <mailto:mol...@mollerware.

Re: aplwrap

PS:  You have to rerun ./autogen.sh after patching configure.ac On 2020-06-28 14:53, Chris Moller wrote: aplwrap needs to have the GNU APL source around to get stuff out of Avec.hh.  Normally, it gets the location of that directory by running apl --show_src_dir and if that doesn't wor

  1   2   >