Re: )LIBS n *

Hi Jürgen, looks good. Thank you. Best Regards Hans-Peter Am 03.07.25 um 14:42 schrieb Dr. Jürgen Sauermann: Hi Hans-Peter, thanks, fixed in *SVN 1879*. Best Regards, Jürgen On 7/2/25 16:17, Hans-Peter Sorge wrote: Hi Jürgen, thank you for the extension and the work you put into it. It s

Re: )LIBS n *

Hi Hans-Peter, thanks, fixed in *SVN 1879*. Best Regards, Jürgen On 7/2/25 16:17, Hans-Peter Sorge wrote: Hi Jürgen, thank you for the extension and the work you put into it. It simplifies the code and makes it much more readable . Only one tiny bit pops up: *)LIBS 10 ?* Invalid library ref

Re: )LIBS n *

Hi Jürgen, thank you for the extension and the work you put into it. It simplifies the code and makes it much more readable . Only one tiny bit pops up: *)LIBS 10 ?* Invalid library reference 10'///<<< there is one single quote/// It probably has no real life effect. Best Regards Hans-Peter

Re: )LIBS n *

Hi Hans-Peter, I have added a query syntax to the *)LIBS *command: *  )LIBS 0 ? library reference 0 stands for directory /home/eedjsa/apl-1.9/src/workspaces     That directory exists.   )LIBS 2 ? library reference 2 stands for directory /home/eedjsa/apl-1.9/src/wslib2     That directory

Re: )LIBS n *

Hi Jürgen, correct. However as there is no simple command that returns the name of the actually set LIB name im parsing the return from  ⍎')LIBS' for a proper Lib name. It just makes handling LIB-changes programmatically inconvenient. As ]LIB and ]LIBS return the same content, letting ]LIBS n

Re: )LIBS n *

Hi Hans-Peter, *)LIBS* (i.e. without arguments) displays the directories for all library reference numbers *)LIBS root *(i.e. with one argument) sets the root directory for all library references. This root directory may then contain the sub directories *workspaces*, *wslib1*, *wslib2*, ...

Re: Try GNU APL version 0.6

Hi Blake, I'm doing nothing special regarding keymapping -- no HTML and no javascript of my doing. I do add in the "APL language bar" like this: https://abrudz.github.io/lb/lb.js"; thanks="Adam Brudzewsky"> but for me this imported code results in a *union* of keyboard mapping and UI click

Re: Try GNU APL version 0.6

Neat. And thanks! Can this be made to use an APL keyboard? --blake On Mon, Jun 2, 2025 at 12:47 PM Roy Tobin wrote: > Hi, > For fun, I coded a browser (Web) interface for GNU APL. > > https://roytobin.github.io/trygnuapl/ > > The service, by intention, imposes minimal restrictions/li

Re: Stack Trace on OP (⊂1 1)+¨0/1

Hi Jürgen, a big thank you. Works like a charm. Best Regards, Hans-Peter Am 22.05.25 um 15:59 schrieb Dr. Jürgen Sauermann: Hi Hans-Peter, thanks, fixed in *SVN 1873*. Best Regards, Juergen On 5/21/25 23:37, Hans-Peter Sorge wrote: Hi Jürgen, the stack trace is gone. however: /⍝ The s

Re: Stack Trace on OP (⊂1 1)+¨0/1

Hi Hans-Peter, thanks, fixed in *SVN 1873*. Best Regards, Juergen On 5/21/25 23:37, Hans-Peter Sorge wrote: Hi Jürgen, the stack trace is gone. however: /⍝ The scan each on an empty vector returns a DOMAIN ERROR. / *+/¨0⍴0* DOMAIN ERROR  +/¨0⍴0  ^ ^ /⍝ This makes the following expr

Re: Stack Trace on OP (⊂1 1)+¨0/1

Hi Jürgen, the stack trace is gone. however: /⍝ The scan each on an empty vector returns a DOMAIN ERROR. / *+/¨0⍴0* DOMAIN ERROR  +/¨0⍴0  ^ ^ /⍝ This makes the following expressions inconsistent:/ *+/¨(1 2) (3 4)* 3 7 *+/¨0 1/ (1 2) (3 4)* 7 /⍝ Result should be empty./ *+/¨0 0/ (1 2) (3

Re: Stack Trace on OP (⊂1 1)+¨0/1

Hi Hans-Peter, thanks, fixed in *SVN 1872*. Best Regards, Jürgen On 5/20/25 11:39, Hans-Peter Sorge wrote: Hi, various operators (+,-,⌊,) stack trace  on *(⊂1 1)+¨0/1 * (it's ¨ (each) again) /⍝ Expected/ *   ⍴(⊂1 1)+0/1* 0 *+(⊂1 1)+0/1* /⍝ Left operator stack traces (as does power too

Re: Floating Point exception on cygwin64

Hello, I finally got around to investigating this issue a little further. The floating point exception appears to be a result of ⎕PW being set to 0 at startup. Applying the following changes allow GNU APL to start up, where one may confirm that ⎕PW is 0, and evaluate expressions properly again, bu

Re: tools/APL_keyboard_show doesn't restore terminal settings

Hi Mike, thanks, fixed in *SVN 1870*. Best regards, Jürgen On 4/30/25 17:50, M.Hall wrote: On macos 15.4.1, with gnu_apl Version / SVN:  1.9 / SVN: 1868M In the 'tools' subdirectory, run "./APL_keyboard_show", and press control-C to exit. The  terminal settings are not restored (because the

Re: iota core dump

Hi, *SVN 1865* is ok too. Best Regards Hans-Peter Am 26.04.25 um 17:02 schrieb Dr. Jürgen Sauermann: Hi, maybe fixed in *SVN 1865*. Somewhat weird that some system show the fault and some (including mine) do not. Best Regards, Jürgen On 4/26/25 05:25, Christian Robert wrote: Quite strange

Re: iota core dump

Jürgen, try this sample program on your system: $ cat x.cc #include #include int main() {    // Create a vector of integers    std::vector vec;    // Add elements to the vector    for (int i=0 ; i<10 ; ++i)    {  vec.push_back(i);    }    // Access and print vector elements    for (size

Re: iota core dump

Hi, maybe fixed in *SVN 1865*. Somewhat weird that some system show the fault and some (including mine) do not. Best Regards, Jürgen On 4/26/25 05:25, Christian Robert wrote: Quite strange... mine is aborting [xtian@vbox:/home/xtian] $ gdb apl GNU gdb (Fedora Linux) 16.2-3.fc42 Copyright (C

Re: iota core dump

Hi Christian, pls note - you are on *Welcome to GNU APL version 1.9 / SVN: 1864M* I did a *svn  co https://svn.savannah.gnu.org/svn/apl/trunk -r 1863 *... *Welcome to GNU APL version 1.9 / SVN: 1863M *... * 1864M *still has the bug in my environment too. Best Regards Hans-Pe

Re: iota core dump

Quite strange... mine is aborting [xtian@vbox:/home/xtian] $ gdb apl GNU gdb (Fedora Linux) 16.2-3.fc42 Copyright (C) 2024 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute

Re: iota core dump

Hi Jürgen I reverted /usr/include/c++/15/bits/stl_vector.h and checked out SVN 1863. It does not show the bug. Best Regards Hans-Peter Am 25.04.25 um 14:19 schrieb Dr. Jürgen Sauermann: Hi Hans-Peter, difficult to reproduce since the Assertion below does not occur on my machine. However,

Re: iota core dump

Hi Hans-Peter, difficult to reproduce since the Assertion below does not occur on my machine. However, I fixed something that may or may not solve the issue. *SVN 1863*. Please let me know if it helped. Best Regards, Jürgen On 4/23/25 15:23, Hans-Peter Sorge wrote: Hi, this is with most r

Re: iota core dump

Hi Christian, thank you for your information. Correct - this is Fedora 42. One of those silent improvements one can run into after the release but not read about before the release. In this special case it looks like the immediate output fails: x←'0123456789abcde'⍳ '345'  x 4 5 6  '

Re: iota core dump

Hi Hans-Peter,  you are probably on the brand new Fedora 42 ? if so, Jürgen is actually working on this problem. may take some time because it affect std::vector<> class and there are a lot of them in gnu apl. On fedora 42, the new library check for *all* out of bound access and there are s

Re: Stack Trace when )SAVEing.

Hi Jürgen, I have tested renaming a function based on most recent SVN co. No more stack traces. Thank You and Best Regards Hans-Peter Am 20.04.25 um 18:43 schrieb Dr. Jürgen Sauermann: Hi Hans-Peter, it looks like the problem has disappeared in the latest GNU APL version: *    )LOA

Re: Stack Trace when )SAVEing.

Hi Hans-Peter, it looks like the problem has disappeared in the latest GNU APL version: *    )LOAD MT631_DDD.apl DUMPED 2025-04-20  18:25:18 (GMT+2)   )SAVE 2025-04-20  18:41:34 (GMT+2)  MT631_DDD * Could you please check if the problem persists after a clean build, i.e. * make clean

Re: Problems with APL keyboard layout on macOS Sequoia

Mike, I have a custom APL keyboard input bundle made with Ukelele that I've been using with Sequoia and Sonoma. I built this one because I found the Dyalog layout doesn't have the complete GNU APL characters and I'd like the line drawing characters on my numeric keypad. It's installed like your

Re: Selective Assignment incorrect under certain circumstances

Hi Jürgen, it does precisely, what it was designed for. It is amazing how this genius selective assignment is chewing away even rather elaborate expressions. Special thanks for this fix. Thoughts, trans scripted into APL, work out of the box.-) Best Regards, Hans-Peter Am 30.03.25 um 16:4

Re: Selective Assignment incorrect under certain circumstances

Hi Hans-Peter, thanks, hopefully fixed in *SVN 1860*. Not sure, though, if I have understood all issues reported. Best Reards, Jürgen On 3/16/25 20:49, Hans-Peter Sorge wrote: Hi, for the following nested vector the Selective Assigments do not work properly: / ⍝ Matrix A is being repeated

Re: )LOAD WS bu no )COPY WS VAR

Hi Hans-Peter, works just fine on my machine: *   )CLEAR CLEAR WS   )COPY /tmp/BUGGY_CLOSE.xml NOTE: this workspaces was )SAVEd with syntax version 1.7.1 but is now )LOADed with a newer version 1.9.1. That should be OK, but new features introduced by the newer version will not be support

Re: Diamonds are ...

Hi Hans-Peter, this looks like a misunderstanding of how )COPY of )DUMPed files works. In the classical )SAVE/)COPY case the )COPY is atomic. In the )DUMP/)COPY case the )COPY is not atomic. In that case the )LOAD only starts the copy but does not finalize it. In fact the )COPY proceeds immedia

Re: Stacktrace )SAVEd Workspace

Hi Hans-Peter, the problem seems to be in the ravel of the value. Removing only the symbol (= APL variable) would leave the problem with the ravel in the .xml file. The proper way to fix the .xml is roughly: 1. remove the offending ... tag. 2. remove all references to the vid (value ID) of

Re: GNU APL Community Page Submissions

Hi ona... I have added the links, please check them: https://www.gnu.org/software/apl/Community.html It would also help if you could provide a shorter name for yourself. Best Regards, Jürgen On 2/26/25 02:28, ona-li-toki-e-jan-Epiphany-tawa-mi--- via Bugs and suggestions for GNU APL wrote:

Re: )LOAD WS bu no )COPY WS VAR

Hi Jürgen, it was mtx .. not xml. *)copy BUGGY_1853* *mtx** *The )copy  of the variable still fails with 1853M. However, it can be fixed by )LOADing  / )COPYing the WS and )SAVEing it.. *)load BUGGY_CLOSE.xml* NOTE: this workspaces was )SAVEd with syntax version 1.7.1 but is now )LOADed wi

Re: During )dump / )copy, )dump / )load cycle the variable content gets lost and oone more stack trace.

i Hans-Peter, thanks, fixed in *SVN 1843*. Best Regards, Jürgen I have made a major re-disign of 10 ⎕CR B, hope it does not brake other On 2/16/25 12:35, Hans-Peter Sorge wrote: Hi, $ apl -q /⍝ create, rather simple, content/ * BUG←⊂⊂¨(1 2 0)⍴¨'X' */⍝ dump content/***  )du

Re: During )dump / )copy, )dump / )load cycle the variable content gets lost and oone more stack trace.

i Hans-Peter, thanks, fixed in *SVN 1843*. Best Regards, Jürgen I have made a major re-disign of 10 ⎕CR B, hope it does not brake other On 2/16/25 12:35, Hans-Peter Sorge wrote: Hi, $ apl -q /⍝ create, rather simple, content/ * BUG←⊂⊂¨(1 2 0)⍴¨'X' */⍝ dump content/***  )du

Re: Stacktrace )SAVEd Workspace

Hi Jürgen, a huge  thank you. My bigger WS causing some long load times with )DUMP / )LOAD and stack traces with )SAVE / )LOAD can now be LOADed w/o problems. Then )SAVE / )LOAD  is OK too. Best Regards Hans-Peter Am 07.03.25 um 16:20 schrieb Dr. Jürgen Sauermann: Hi Hans-Peter, I believe th

Re: Stacktrace )SAVEd Workspace

',WSNAME,'.xml'* and *⍎')DUMP ',WSNAME,'.apl'* directly one after an other. That happens several times (a day...). Then )LOAD *WSNAME.xml* stack traces. The steps )LOAD *WSNAME.apl*, )SAVE *WSNAME.xml *and )LOAD *WSNAME.xml *does not stack trace. I have no c

Re: Stacktrace )SAVEd Workspace

Hi Hans-Peter, I believe that I have found the problem. Supposedly fixed in *SVN 1851.* Unfortunately it does not fix the problem in existing workspaces, you have to )SAVE them again. Sometimes )COPY might work to recover precious variables. The error occurs if a (nested) ravel with, say, *vid=x

Re: Stacktrace )SAVEd Workspace

Hi Jürgen, the previous log was w/o *]LOG 39. * There is no apparent reason  to fail at vid 274. Just an excerpt from the xml: and the log: Value 0x3211b2b0 SET complete (0x400) at Value.cc:2231 now = 0x400 (changed)    read_Ravel() vid=270, XML line 4823 - YES (2 items) Value 0x3

Re: Diamonds are ...

Hi Jürgen, again, thank you for all the detailed information. It might even fit into a "README-99-cases-you-could-ever-think-about" The ⍎')command' is a real time saver. If not implemented it would be first in a wish list. The begin ⋄ command ⋄ timer was just an idea to get a quick "precise

Re: A Question about zero rank disclose and a SYSTEM LIMIT in context.

Hi Jürgen, thank you for all the details. I was wondering too how to build sensible and readable code at depth beyond  let's say 6..7..8 or even more. But the  ⍎ ,nn⍴ ⊂ 'SimpleExpresssion' is just too tempting. I  have  a power meter installed from which I get the meter readings via tty. A

Re: A Question about zero rank disclose and a SYSTEM LIMIT in context.

Hi Hans-Peter, I have increased the system limit for operators per statement (!) from 16 to 32. This system limit is required for performance reasons since it avoids memory allocations and de-allocations for derived functions. I would assume that a single APL statement with more than 32 operat

Re: During )dump / )copy, )dump / )load cycle the variable content gets lost and oone more stack trace.

use )SAVE / )LOAD now? Best Regards Hans-Peter Am 26.02.25 um 15:48 schrieb Dr. Jürgen Sauermann: Hi Hans-Peter, thanks, fixed in *SVN 1843*. Best Regards, Jürgen I have made a major re-disign of 10 ⎕CR B, hope it does not brake other On 2/16/25 12:35, Hans-Peter Sorge wrote: Hi, $ apl

Re: During )dump / )copy, )dump / )load cycle the variable content gets lost and oone more stack trace.

ussed a problem with )SAVE when you suggested to use )DUMP. Having used )DUMP since then I was fine. Question: Is it 'save' to use )SAVE / )LOAD now? Best Regards Hans-Peter Am 26.02.25 um 15:48 schrieb Dr. Jürgen Sauermann: Hi Hans-Peter, thanks, fixed in *SVN 1843*. Best Rega

Re: A Question about zero rank disclose and a SYSTEM LIMIT in context.

Hi Jürgen, thank you. I hope I do not keep you to busy... Best Regards Hans-Peter Am 02.03.25 um 17:52 schrieb Dr. Jürgen Sauermann: Hi again, Hans-Peter, good news. I found and fixed the fault: *   E←⊂¨2 2⍴0/¨⊂,¨2 2 ⍴ 0⍴0   E≡⊃¨⊂¨E 1    E≡⊂¨⊃¨E 1 * *SVN 1847*. Best Regards,

Re: A Question about zero rank disclose and a SYSTEM LIMIT in context.

Hi again, Hans-Peter, good news. I found and fixed the fault: *   E←⊂¨2 2⍴0/¨⊂,¨2 2 ⍴ 0⍴0   E≡⊃¨⊂¨E 1    E≡⊂¨⊃¨E 1 * *SVN 1847*. Best Regards, Jürgen On 3/1/25 16:35, Dr. Jürgen Sauermann wrote: Hi Hans-Peter, I cannot quite answer your question, but maybe we can find the pro

Re: Stacktrace )SAVEd Workspace

SNAME.apl*, )SAVE *WSNAME.xml *and )LOAD *WSNAME.xml *does not stack trace. I have no clue as to when the open WS I am working on gets into a condition that does not corectly )SAVE the WS from there on. I'll  re)LOAD the )SAVEd WS immediately after a )SAVE was done to get closer to the bu

Re: A Question about zero rank disclose and a SYSTEM LIMIT in context.

Hi Jürgen, * 3 ⎕CR  ⍎∊17⍴⊂'(1↑¨''a'')'* SYSTEM LIMIT (fun_oper)   (1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')(1↑¨'a')    ^ ^ * 3 ⎕CR  ⍎∊16⍴⊂'(1↑¨''a'')'** *┏━━━┓ ┏━━━┓ ┏━━━┓ ┏━━━┓ ┏━━━┓ ┏━━━┓

Re: Missing gap line in output of multi dimentional array

Hi Jürgen, not that I read the reference  manual  for that particular definition. Thank you for pointing me to it. Conclusion: works as designed. For my idea actually a  "*N   ⎕CR  VAR*"  creating output without box chars would do it. Best Regards Hans-Peter Am 28.02.25 um 17:17 schrieb Dr

Re: (lack of) Monadic ≠ in GNU APL ('Nubsieve' / 'Unique Mask')

Added in *SVN 1846*. Best Regards, Jürgen On 2/22/25 03:50, Russtopia wrote: Through random wanderings watching videos on APL and J, I encountered a short segment on J's definition of the 'nub sieve' function (~:) https://aplwiki.com/wiki/Nub_Sieve In J (and, according to the "APL wiki" wh

Re: A Question about zero rank disclose and a SYSTEM LIMIT in context.

Hi Hans-Peter, I cannot quite answer your question, but maybe we can find the problem together. My analysis so far is this: I started with storing the common part of your c, d, and e in variable *E*. With that your examples become: *   E←⊂¨2 2⍴0/¨⊂,¨2 2 ⍴ 0⍴0   c←    E   d←  ⊃¨E    ⍝

Re: During )dump / )copy, )dump / )load cycle the variable content gets lost and oone more stack trace.

use )SAVE / )LOAD now? Best Regards Hans-Peter Am 26.02.25 um 15:48 schrieb Dr. Jürgen Sauermann: Hi Hans-Peter, thanks, fixed in *SVN 1843*. Best Regards, Jürgen I have made a major re-disign of 10 ⎕CR B, hope it does not brake other On 2/16/25 12:35, Hans-Peter Sorge wrote: Hi, $ apl

Re: Missing gap line in output of multi dimentional array

Hi Hans-Peter, I am not sure if your observation below is an error. The relevant rule in the IBM APL2 language reference manual is this (Figure 22 on page 138): /* For Z←R, where R is a nested array:: ...  Z has LN intermediate blank lines between vertically adjacent items C and D, where: LN←0

Re: During )dump / )copy, )dump / )load cycle the variable content gets lost and oone more stack trace.

in *SVN 1843*. Best Regards, Jürgen I have made a major re-disign of 10 ⎕CR B, hope it does not brake other On 2/16/25 12:35, Hans-Peter Sorge wrote: Hi, $ apl -q /⍝ create, rather simple, content/ * BUG←⊂⊂¨(1 2 0)⍴¨'X' */⍝ dump content/***  )dump buggy *2025-02-16  12:13:47

Re: (lack of) Monadic ≠ in GNU APL ('Nubsieve' / 'Unique Mask')

Hi Russ, I will look into this. One observation so far is that your *Q←{ ((⍵⍳⍵)=⍳⍴⍵)/⍵ }* seems to return the unique elements rather than a boolean vector: *   Q←{ ((⍵⍳⍵)=⍳⍴⍵)/⍵ }   ⎕CR 'Q' λ←λ1 ⍵ λ← ((⍵⍳⍵)=⍳⍴⍵)/⍵   Q 'Hello, World' Helo, Wrd   ∪'Hello, World' Helo, Wrd* Look

Re: During )dump / )copy, )dump / )load cycle the variable content gets lost and oone more stack trace.

#x27;save' to use )SAVE / )LOAD now? Best Regards Hans-Peter Am 26.02.25 um 15:48 schrieb Dr. Jürgen Sauermann: Hi Hans-Peter, thanks, fixed in *SVN 1843*. Best Regards, Jürgen I have made a major re-disign of 10 ⎕CR B, hope it does not brake other On 2/16/25 12:35, Hans-Peter Sorge wro

Re: Stack trace when Tilde

Hello Jürgen, thanks a lot. Best Regards Hans-Peter Am 26.02.25 um 18:42 schrieb Dr. Jürgen Sauermann: Hi Hans-Peter, thanks, fixed in *SVN 1844*. Best Regards, Jürgen On 2/18/25 21:14, Hans-Peter Sorge wrote: *)clear* CLEAR WS * (⊂¨(1 0 1 0 0 1)   (1 1 1)) ⊂¨ ⊂¨(1 0 1 0 0 1) (1 1 1) * R

Re: During )dump / )copy, )dump / )load cycle the variable content gets lost and oone more stack trace.

AD now? Best Regards Hans-Peter Am 26.02.25 um 15:48 schrieb Dr. Jürgen Sauermann: Hi Hans-Peter, thanks, fixed in *SVN 1843*. Best Regards, Jürgen I have made a major re-disign of 10 ⎕CR B, hope it does not brake other On 2/16/25 12:35, Hans-Peter Sorge wrote: Hi, $ apl -q /⍝ create, rather

Re: Stack trace when Tilde

Hi Hans-Peter, thanks, fixed in *SVN 1844*. Best Regards, Jürgen On 2/18/25 21:14, Hans-Peter Sorge wrote: *)clear* CLEAR WS * (⊂¨(1 0 1 0 0 1)   (1 1 1)) ⊂¨ ⊂¨(1 0 1 0 0 1) (1 1 1) * RANK ERROR  (⊂¨(1 0 1 0 0 1) (1 1 1))⊂¨⊂¨(1 0 1 0 0 1) (1 1 1)  ^  ^ */⍝ just

Re: During )dump / )copy, )dump / )load cycle the variable content gets lost and oone more stack trace.

Hi Hans-Peter, thanks, fixed in *SVN 1843*. Best Regards, Jürgen I have made a major re-disign of 10 ⎕CR B, hope it does not brake other On 2/16/25 12:35, Hans-Peter Sorge wrote: Hi, $ apl -q /⍝ create, rather simple, content/ * BUG←⊂⊂¨(1 2 0)⍴¨'X' */⍝ dump content/***

Re: GNU APL Community Page Submissions

Hi,  thanks for sharing your workspaces. I am somewhat busy right now, so please remind me if I haven't updated the community page within 3 weeks. I am also wondering if we should have abstraction workspaces for ⎕FIO any longer. The one shipped with GNU APL is for backward compatibility only,

Re: GNU APL Community Page Submissions

Whoops, messed up the fio.apl link. This the correct one https://paltepuk.xyz/cgit/fio.apl.git/about/ Sent with [Proton Mail](https://proton.me/mail/home) secure email. On Wednesday, February 26th, 2025 at 01:24, ona li toki e jan Epiphany tawa mi wrote: > Hello, I have two GNU APL projects of

Re: Floating Point exception on cygwin64

Hi, I guess that running GNU APL in gdb might find the place where this occurs. Also: apl -l 37 to see how far the start-up comes. Unlike other logging levels -l 37 should work even if dynamic logging is  not configured. Best Regards, Jürgen On 2/23/25 19:00, Russtopia wrote: Hi all, has a

Re: Floating Point exception on cygwin64

On my system at least, the issue appears first in r1807. $ svn log -l 2 r1807 | j_sauermann | 2024-12-28 09:21:16 -0800 (Sat, 28 Dec 2024) | 1 line use TIOCGWINSZ if available

Re: Stack trace in fairly simple expression.

Hi Jürgen, thank you - and take your time. The next one is on it's way. Best Regards Hans--Peter Am 18.02.25 um 18:17 schrieb Dr. Jürgen Sauermann: Hi Hans-Peter, thanks, fixed in *SVN 1842*. BTW: I am also working on your other issues, but it may take a little time. Best Regards, Jürge

Re: Stack trace in fairly simple expression.

Hi Hans-Peter, thanks, fixed in *SVN 1842*. BTW: I am also working on your other issues, but it may take a little time. Best Regards, Jürgem On 2/18/25 17:01, Hans-Peter Sorge wrote: Hi, in SVN: 1833:1841M there is a stack trace for *x←, ⊂1 1 0 0 1 1**    y←,⊂'asdfgh'    

Re: Stop Vector Stack trace

Hi Hans-Peter, interesting side effect since I did not change anything in that area. Best Regards, Jürgen On 2/16/25 11:32, Hans-Peter Sorge wrote: Hi Jürgen, in SVN: 1833:1838M fixed too. Thank you and Best Regards Hans-Peter Am 14.02.25 um 17:20 schrieb Hans-Peter Sorge: Hi, $ apl -q

Re: Stop Vector Stack trace

Hi Jürgen, in SVN: 1833:1838M fixed too. Thank you and Best Regards Hans-Peter Am 14.02.25 um 17:20 schrieb Hans-Peter Sorge: Hi, $ apl -q set the stop vector for long running / large data volume functions when a particular situation is met. Here grossly simplified ... ∇x [1] ⍎1/'S∆

Re: Stack trace QuadCR space

Hi Jürgen, thank you. Fixed with SVN 1838. for *info apl : *Chapter 1 [ENTER] is OK Menu and Chapter 2 .. 7  [ENTER] no reaction. for ⎕MX there is no help. I agree, that in the context  with  ⎕FIO, ⎕CR, ⎕MX, ⎕FFT, ⎕RVAL and others my proposal would not be helpful. I there a way to redirect an

Re: Stack trace QuadCR space

Hi Hans-Peter, I believe that I have fixed the first Assertion below (even if I could not reproduce it on my box). *SVN 1838*. Many built-in functions return *0 0⍴0* because that is (the only ?) APL value that does not emit a \n when being printed (in many cases unintentionally). Also, several

Re: Syntax error on function )COPY'd from another workspace

I might have a clue as to what's going on with the optimization. This is beginning to look like it's related to the FT_DIRECT_BRANCHES (unconditional branches) optimization. More digging with the debugger, except now with Hans-Peter's sample function: [0] WWW [1] ws←3↓1⊃⍎')WSID' [2] → x

Re: Syntax error on function )COPY'd from another workspace

Hi Hans-Peter, As far as I am aware, the problems were unrelated to )DUMP, )SAVE, )LOAD, )COPY. In other words, the combination used is irrelevant. I could be wrong. Thanks! Blake On Wed, Feb 12, 2025 at 2:04 PM Hans-Peter Sorge < hanspeterso...@netscape.net> wrote: > Hi Blake, > > ist that

Re: Syntax error on function )COPY'd from another workspace

Hi Blake, ist that for )SAVEd workspaces? I use )DUMP / )LOAD instead of )SAVE / )LOAD. )SAVE stores the WS in xml format. Q: Shouldn't  )LOAD create identical binary WS-images from a xml (saved) and an apl (dumped) stored workspaces? How to get a binary image from an actual running WS to co

Re: Syntax error on function )COPY'd from another workspace

Just FYI. The problems I was noticing were unrelated to )COPY I saw the same problems with )LOAD --blake On Wed, Feb 12, 2025 at 1:05 PM Hans-Peter Sorge < hanspeterso...@netscape.net> wrote: > Hi Jürgen, > > thank you. > The fix came just in time as I have to )COPY quite often right now :-) >

Re: Syntax error on function )COPY'd from another workspace

gt;> Thanks! >>>> >>>> Blake >>>> >>>> >>>> On Sun, Feb 9, 2025 at 10:07 AM Blake McBride >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> I have been watching this thread. My imp

Re: Syntax error on function )COPY'd from another workspace

that I know have thrown the syntax error in the past by simply opening and immediately closing the funcion (no other changes) with the ∇ editor. Things work fine after that. II )SAVE th

Re: Syntax error on function )COPY'd from another workspace

LOAD the original workspace and "fix up" problematic functions that I know have thrown the syntax error in the past by simply opening and immediately closing the funcion (no other changes) with the ∇

Re: Syntax error on function )COPY'd from another workspace

9:08 AM Dr. Jürgen Sauermann < >>>> mail@jürgen-sauermann.de> wrote: >>>> >>>>> Hi Paul, >>>>> >>>>> maybe Blake has an idea. For me it is very difficult to fix >>>>> workspaces that were contributed by other

Re: Syntax error on function )COPY'd from another workspace

thrown the syntax error in the past by simply opening and immediately closing the funcion (no other changes) with the ∇ editor. Things work fine after that. II )SAVE the workspace, and then )LOAD the saved

Re: Syntax error on function )COPY'd from another workspace

thrown the syntax error in the past by simply opening and immediately closing the funcion (no other changes) with the ∇ editor. Things work fine after that. II )SAVE the workspace, and then )LOAD the saved

Re: Syntax error on function )COPY'd from another workspace

08 AM Dr. Jürgen Sauermann >>>> mailto:mail@j%C3%BCrgen-sauermann.de>> wrote: >>>>> Hi Paul, >>>>> >>>>> maybe Blake has an idea. For me it is very difficult to fix >>>>> workspaces that were contributed by other users. F

Re: Syntax error on function )COPY'd from another workspace

> Jürgen >>>> >>>> >>>> On 2/8/25 19:48, Paul Rockwell wrote: >>>> >>>> Unfortunately, I haven't been able to get this reproduced with anything >>>> simpler. I can reliably reproduce this using Blake's APL Editor fo

Re: Syntax error on function )COPY'd from another workspace

this reproduced with anything >>> simpler. I can reliably reproduce this using Blake's APL Editor found >>> here: https://github.com/blakemcbride/APLEditor >>> >>> I don't believe it to be an error in the functions themselves. I can >>> )LOAD

Re: Syntax error on function )COPY'd from another workspace

unctions themselves. I can >> )LOAD the original workspace and "fix up" problematic functions that I know >> have thrown the syntax error in the past by simply opening and immediately >> closing the funcion (no other changes) with the ∇ editor. Things work fine >>

Re: Syntax error on function )COPY'd from another workspace

the original workspace and "fix up" problematic functions that I know have > thrown the syntax error in the past by simply opening and immediately > closing the funcion (no other changes) with the ∇ editor. Things work fine > after that. > > II )SAVE the workspace, and then

Re: Syntax error on function )COPY'd from another workspace

nctions that I know have thrown the syntax error in the past by simply opening and immediately closing the funcion (no other changes) with the ∇ editor. Things work fine after that. II )SAVE the workspace, and then )LOAD the saved copy, and the error re-appears. I've validated the variab

Re: Syntax error on function )COPY'd from another workspace

l workspace and "fix up" problematic functions that I know have thrown the syntax error in the past by simply opening and immediately closing the funcion (no other changes) with the ∇ editor. Things work fine after that. II )SAVE the workspace, and then )LOAD the saved copy, and the

Re: Syntax error on function )COPY'd from another workspace

Hi Paul, that very much looks like an error in the Editor workspace, doesn't it? Can you reproduce the fault in plain APL? Best Regards, Jürgen On 2/6/25 19:14, Paul Rockwell wrote: I've been seeing syntax errors being thrown on functions copied from another workspace. I've imported Blake McB

Re: automatic )more and old-style multi line strings

Hi Roy, thanks, fixed in *SVN 1830*. As to a list of open issues: I am following a strategy of fixing all issues immediately and therefore there is no such list. Best Regards, Jürgen On 2/6/25 01:13, Roy Tobin wrote: Hi, Small polish needed. Seems that when automatic )more is on, a faulty/m

Re: Build errors of libapl on macos, Intel and ARM

Hi Mike, thanks, fixed in *SVN 1829*. Best Regards, Jürgen On 2/6/25 04:43, M.Hall wrote: Build errors of libapl on macos, Intel and ARM $ ./configure --with-libapl ... $ make ... /bin/sh ../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I..    -Wall  -I sql -I /Volumes/ARCHIV

Re: Workspace XML file double quote problem

Hi Mike, I have fixed the double quote. *SVN 1828*. The NULs at the end of the document are on purpose. They guarantee that the document is 0-terminated after being *mmap*()'ed so that C string functions will not segfault when reaching the end of the *mmap()*'ed file.. The alternative would h

Re: Are lambdas different as the body of a direct function v. a ]usercmd?

Hi Roy, thanks, fixed in *SVN 1827*. Best Regards, Jürgen On 2/4/25 00:49, Roy Tobin wrote: (small bug with workaround, but not patch, follows) Hi, For a User-defined command defined with a lambda, I expect the omega is "the command entered by the user is passed to APL_fun as an APL string (

Re: Workspace XML file double quote problem

Never mind. It does break other things. I should leave the programming to the professionals. Sorry. On Sun, Feb 2, 2025 at 8:27 PM M.Hall wrote: > Found it. > Looks like XML_Saving_Archive::emit_token_val() line 769 of src/Archive.cc > was adding its own close quote. > > $ diff -u src/Archive.cc

Re: Workspace XML file double quote problem

Found it. Looks like XML_Saving_Archive::emit_token_val() line 769 of src/Archive.cc was adding its own close quote. $ diff -u src/Archive.cc-ORIG src/Archive.cc --- src/Archive.cc-ORIG 2025-02-02 15:07:35.0 -0600 +++ src/Archive.cc 2025-02-02 15:07:24.0 -0600 @@ -766,7 +766,7 @@

Re: Del Editor Confusion

Looks great on macos x86_64 and arm64e. Thank you! On Fri, Jan 31, 2025 at 8:04 AM Dr. Jürgen Sauermann < mail@jürgen-sauermann.de> wrote: > Gentlemen, > > thanks, fixed in *SVN 1825*. > > Best Regards, > Jürgen > > > On 1/27/25 03:33, Paul Rockwell wrote: > > I'm seeing the same thing on SVN 182

Re: Del Editor Confusion

Gentlemen, thanks, fixed in *SVN 1825*. Best Regards, Jürgen On 1/27/25 03:33, Paul Rockwell wrote: I'm seeing the same thing on SVN 1822 on Fedora 41 x86_64 and SVN 1823 on macOS 15.2 Apple Silicon (arm64). - Paul Rockwell On Jan 26, 2025, at 7:36 PM, M.Hall wrote: I have some misunder

Re: (low) cut-n-paste error in sample code for Quad FX interface

Hi Roy, thanks, fixed in *SVN 1824*. Best Regards, Jürgen On 1/28/25 07:27, Roy Tobin wrote: Possible cut-n-paste error on line 363 of src/native/template.hh? I presume the instrumenting literal should indicate that eval_fill_AB() was called.  I'm just going by inspection -- this observation

Re: Del Editor Confusion

I'm seeing the same thing on SVN 1822 on Fedora 41 x86_64 and SVN 1823 on macOS 15.2 Apple Silicon (arm64). - Paul Rockwell > On Jan 26, 2025, at 7:36 PM, M.Hall wrote: > > I have some misunderstandings with the del editor. (this is long, sorry) > > $ apl > > ⍝ define a function > ∇

Re: Build fails against recent Clang/LLVM

Hi Alexey, thanks fixed in SVN *1823*. Best Regards, Jürgen On 1/22/25 20:01, Alexey Dokuchaev wrote: As of libc++19[1], std::char_traits<> is now only provided for char, char8_t, char16_t, char32_t, and wchar_t, and any instantiation for other types will fail. This breaks GNU APL on the Fre

Re: libgsl awkwardness

Hi Henrik, I believe the proper way to handle this is to use the VERSION argument in the *ax_path_lib_gsl.m4* script. Unfortunately your modified m4 script seems not to handle versions, and the original script https://www.gnu.org/software/autoconf-archive/ax_path_lib_gsl.html gives me a *4

  1   2   3   4   5   6   7   8   9   10   >