Re: [Bug-apl] location of cursor on new apl session

I remember it well, because the Emacs mode depends on it. :-) Regards, Elias On 6 February 2017 at 18:35, Juergen Sauermann < juergen.sauerm...@t-online.de> wrote: > Hi, > > this option is very old (so old that I had already forgotten it) and has > been in *info apl* for a long time. > > It

Re: [Bug-apl] using c libs in apl?

gt; up to its promises. > If it does then my vote would definitely be for *libffi*. > > Another plus for *libffi* is that it is available as debian package. > > /// Jürgen > > > On 02/08/2017 01:38 AM, Elias Mårtenson wrote: > >> This would be really neat to have, but as

Re: [Bug-apl] using c libs in apl?

The main problem with quad-TS is that it doesn't provide a way to count seconds. This is because the date portion is not constant, it's sometimes 30 and sometimes 31. The other problem is that it's local time, which means that time measurements across DST changes are not predictable. What's

Re: [Bug-apl] using c libs in apl?

This would be really neat to have, but as someone who has written a lot of FFI (foreign function interface) code in Common Lisp which has a very powerful such interface, there are a lot of nuances that needs to be covered in order to have a decent FFI. For example, what if you need to call a

[Bug-apl] Bug when using negative arguments to ]BOXING

I get a DOMAIN ERROR when trying to use the new ]BOXING feature. Here's a transcript: * ]BOXING ¯29* * ⍳10* DOMAIN ERROR+ ⍳10 ^ * )more* A ⎕CR B with invalid A < 0 Regards, Elias

Re: [Bug-apl] scripting )copy question

00:15, <enz...@gmx.com> wrote: > > did you read the post? > > i didn't ask about it in a workspace - my example was in a SCRIPT > > > On Mon, 6 Feb 2017 11:33:51 +0800 > Elias Mårtenson <loke...@gmail.com> wrote: > > > It works for me: > > &

Re: [Bug-apl] location of cursor on new apl session

I think the key thing to remember here is that the final ∇ isn't part of the program code, but rather is something analogous to an EOF marker. >From that perspective, this makes sense. Regards, Elias On 5 Feb 2017 18:44, "Juergen Sauermann" wrote: On

Re: [Bug-apl] strange behavior of --

e same with subsequent > lines but instead keeps reading from stdin of the calling process. > > /// Jürgen > > > On 02/07/2017 12:24 PM, Elias Mårtenson wrote: > >> Shouldn't you be able to simply call isatty(0) to determine this? >> >> Regards, >> Elias &g

Re: [Bug-apl] using c libs in apl?

It's actually not very complicated. And I managed to get it working with only a bit of support from Jürgen. If he doesn't have time to explain things, I'll help out too. Regards, Elias On 4 Feb 2017 11:15 PM, "Peter Teeson" wrote: > Hi Jürgen: > Other than the source

Re: [Bug-apl] scripting )copy question

It works for me: Network listener started. Connection information: mode:tcp addr:40267 * )fns* * )copy 5 SQL* DUMPED 2017-02-06 11:25:33 (GMT+8) * )fns* SQL∆Begin SQL∆Columns SQL∆Commit SQL∆Connect SQL∆Disconnect SQL∆ExecSQL∆RollbackSQL∆Select SQL∆Tables

Re: [Bug-apl] ⎕FIO[49]

Is there anything inherently wrong with having more quad-commands? What is the reason we have to do ⎕FIO[49] instead of simply ⎕ReadLines or something like that? It's like we're going out of way to make code unreadable. I know APL is all about terseness, but I think this is going too far. Am I

Re: [Bug-apl] error trap domain error

I believe you can use the techniques described under APL2, as this should be compatible with GNU APL. Regards, Elias On 27 Jan 2017 01:08, wrote: > > is there a ⎕trap or similar method to trap the domain error of the > following > > 4÷(4-4) > > all i found was

[Bug-apl] Formatting of large arrays

When printing a one-dimensional array which is wider than ⎕PW, and using a ⎕CR mode which uses box-drawing characters such as 8 or 29, the output is quite unreadable. For example, with ⎕PW←89 (standard for my Emacs session) this is what I get when printing ⍳100: * 29⎕CR ⍳100*

Re: [Bug-apl] ⎕FIO[49]

orkspace. > > BTW the *FILE_IO* workspace, already contains this wrapper function *Z←L > FIO[X**]** R*, kindly provided by > Christian Robert, which calls *⎕FIO* with string *X* instead of numeric > axis argument *X*. > > Of course I forgot to add *FIO**∆**readlines* to the *FILE_

Re: [Bug-apl] ⎕FIO[49]

ng numbers > instead of names. > > So this is half a year of work on my side compared to a simple > > *)COPY 5 FILE_IO* > > where named wrapper functions for every *⎕FIO**[X]* already exist (and > you can even change the names > if you don't like them). > > /// Jürgen >

Re: [Bug-apl] defn error with ⍝

I always put the terminating ∇ on its own line. In fact, that's how I coded the Emacs mode to behave. Should I change this? On 30 January 2017 at 00:05, wrote: > > *shakes fist at ibm apl2*i guess the fns i was doing it in was before > 2014 - luckily it is the only one to

[Bug-apl] Proposal: Support alternative symbols for ⍺ and ⍵

GNU APL uses the symbols ⍺ (U+237A APL FUNCTIONAL SYMBOL ALPHA) and ⍵ (U+2375 APL FUNCTIONAL SYMBOL OMEGA) for the left and right hand arguments in a lambda function. I would like to suggest that it also accept α (U+03B1 GREEK SMALL LETTER ALPHA) and ω (U+03C9 GREEK SMALL LETTER OMEGA) as

Re: [Bug-apl] [PATCH]: allow using lambdas in ]USERCMD

I agree with you that extensions should, as far as possible, be in a loadable package. However, some features can't be built in pure APL. Either because the underlying functionality simply isn't there, or because an APL-based implementation would be too slow. Let's take a simple example: a timer

Re: [Bug-apl] Proposal: Support alternative symbols for ⍺ and ⍵

. > > /// Jürgen > > > On 02/24/2017 08:39 AM, Elias Mårtenson wrote: > > GNU APL uses the symbols ⍺ (U+237A APL FUNCTIONAL SYMBOL ALPHA) and ⍵ > (U+2375 APL FUNCTIONAL SYMBOL OMEGA) for the left and right hand arguments > in a lambda function. > > I would like to

Re: [Bug-apl] user defined commands etc.

Shouldn't it be called CONTINUE.apl? On 26 Feb 2017 00:31, "Alexey Veretennikov" wrote: > Hi, > > Doesn't seem to work: > My lib0 is > /Users/alexeyv/Sources/apl/gapl-workspaces/workspaces/CONTINUE > > CONTINUE file is removed. > The SETUP.apl is in the same

Re: [Bug-apl] Sqlite provider truncates integers in results

Thanks. I'll take a look at this today or tomorrow if no one else does it before me. Ma ☺️ On 12 Feb 2017 7:13 PM, "Kacper Gutowski" wrote: > The sqlite provider seems to silently truncate integer values in results: > > )COPY 5 SQL > DUMPED 2017-02-12 10:13:53 (GMT+1)

Re: [Bug-apl] Sqlite provider truncates integers in results

( value_in ) {} virtual ~IntResultValue() {} virtual void update( Cell *cell, Value & cell_owner ) const; private: -int value; +APL_Integer value; }; class DoubleResultValue : public ResultValue { On 12 February 2017 at 19:18, Elias Mårtenson <loke...@gmail.com> wrote:

Re: [Bug-apl] using c libs in apl?

On 10 February 2017 at 13:30, Xiao-Yong Jin wrote: > I believe passing/returning struct is actually compiler dependent (man gcc > and /struct-return). > In C++ it's compiler-dependent, I think. The C ABI however is stable in this respect, at least on Linux. > What you

Re: [Bug-apl] using c libs in apl?

Actually I was hoping that *libffi* would solve this kind of > issues, because this sounds very much like a > standard problem? > > /// Jürgen > > > On 02/09/2017 10:05 AM, Elias Mårtenson wrote: > > I wasn't referring to the management of APL memory, but rather native &g

Re: [Bug-apl] Sqlite provider truncates integers in results

Jürgen? Could you merge the fix? Regards, Elias On 15 February 2017 at 13:30, Kacper Gutowski <mwgam...@gmail.com> wrote: > On 14 February 2017 at 14:31, Elias Mårtenson wrote: > > I've taken a look at this now, and I believe this patch should fix your > problem. Please tr

Re: [Bug-apl] Sqlite provider truncates integers in results

umbers are slightly out of sync. > > /// Jürgen > > > On 02/15/2017 07:19 AM, Elias Mårtenson wrote: > > Jürgen? Could you merge the fix? > > Regards, > Elias > > On 15 February 2017 at 13:30, Kacper Gutowski <mwgam...@gmail.com> wrote: > >> On 14 Februa

[Bug-apl] Best way to solve my daughter's maths problem

My daughter had this maths problem, and quote it from memory: Given five 4's, separated by the mathematical functions +, -, × and ÷ form the number 7. The problem also allowed her to use parentheses. I decided to write an APL expression to solve this, and this is what I came up with: *d ←

[Bug-apl] Crash with stack trace

I'm regularly getting a crash that I have not seen before. I don't know when it was introduced but it must be within the last few months. Here's the stack trace: == Assertion failed: items in Function: at in file:

Re: [Bug-apl] Crash with stack trace

se the *map<...> *stuff crashed on start-up > of apl (the *⎕SQL > *constructor is called much earlier than native functions). But maybe I > did somewthing wrong, > in paricular with the *connections*. > > /// Jürgen > > > > On 01/17/2017 05:38 PM, Elias Må

Re: [Bug-apl] Performance problems when constructing large(ish) arrays

have the same number columns as in pattern > > Dyalog and some other APLs (APLX?) have a []CSV function. The problem > gets a bit harder when you have optional quotes around strings, > embedded separators, and have to figure out yourself whether something > is numeric or char. > >

Re: [Bug-apl] Performance problems when constructing large(ish) arrays

mber:parse-number p))) (setf (row-major-aref new-array (+ n 10)) (nth 10 parts)) (setq result new-array))) On 18 January 2017 at 03:58, Elias Mårtenson <loke...@gmail.com> wrote: > You are right that doing array allocations in a

Re: [Bug-apl] Performance problems when constructing large(ish) arrays

On 18 January 2017 at 04:10, Juergen Sauermann < juergen.sauerm...@t-online.de> wrote: > What I do not like about *⎕CSV* (actually I am only guessing here because > I dont know what it reallly does, > but I assume it is specifically for comma separated lists) is that it is > supposedly only

Re: [Bug-apl] Performance problems when constructing large(ish) arrays

1 2 3) (4 5 6) (7 8 9) > Z > 1 2 3 4 5 6 7 8 9 > ⊃Z > 1 2 3 > 4 5 6 > 7 8 9 > > /// Jürgen > > > On 01/18/2017 05:52 PM, Elias Mårtenson wrote: > > Thanks, I changed my function to use the new FIO 49, and the resuolt is > much more compact: >

Re: [Bug-apl] Crash with stack trace

en, when > displaying the call stack for the assertion, > *__cxa_de**mangle**()* makes things worse. The culprit could be > *backtrace_symbols()*; the man page says that its > results shall be *free*d() but doing to segfaults from time to time. > > /// Jürgen > > > On 01/17/2

Re: [Bug-apl] libcurl and libmysql/mariadb

For the database part, all you have to do is to implement a couple of C++ interfaces, and it will be integrated into the existing SQL framework (which currently supports Postgres and SQLite). I'm typing this on my phone so I can't give you any specifics at the moment, but look at the SQLite

Re: [Bug-apl] apl computer

This is a subject that has interested me a lot, and after coming to a similar conclusion as Jürgen, decided to see if it was possible to get around many of the problems by eliminating the main cause of bad parallelism: Side effects. I have been working an experimental APL interpreter (mostly

Re: [Bug-apl] compile error location of malloc.h

On 29 August 2016 at 13:58, Christian Robert <christian.rob...@polymtl.ca> wrote: > On 2016-08-29 01:21, Elias Mårtenson wrote: > >> They are, but if they are not found in the local directory, they are also >> searched for in the system directories. >> > > an

Re: [Bug-apl] compile error location of malloc.h

They are, but if they are not found in the local directory, they are also searched for in the system directories. That said, in this case using the angle brackets is the correct thing to use. On 29 August 2016 at 13:08, Christian Robert wrote: > that should read: >

Re: [Bug-apl] SVN 839 doesn't compile

I think we need a way to dynamically load SQL libraries. Otherwise we're going to either have precompiled binaries without SQL support, or the need to have multiple packages. If we support dynamically loading the SQL libraries, then the Debian package could be built with support for both

Re: [Bug-apl] Request to implement ^S and ^Q

Being someone who used this feature extensively back when I was using serial terminals, I've never had any use of that feature on modern computers. They're just too fast, and you'll have scrolled hundreds of pages before you even have time to reach for C-s. I'm curious as to what use you have for

Re: [Bug-apl] Request to add to the ⎕fio[] a 'function_common_name' as argument

Isn't this exactly what wslib5/FILE_IO.apl is? Regards, Elias On 4 January 2017 at 14:16, Christian Robert wrote: > I would love to be able to do: > > fd ←⎕fio['open'] '.bashrc' > ⎕fio['fclose'] fd > > and so on ... > > I have a Workspace named "fio" who just do

Re: [Bug-apl] ⎕SQL

I personally have nothing against adding other providers, the API to do so is very simple and I'll be happy to help anyone who wants to do it. It's just that I have neither interest nor need to do it myself, so I won't be the person doing this work. I was looking into adding Oracle support, but

Re: [Bug-apl] Request to add to the ⎕fio[] a 'function_common_name' as argument

> I don't want to have to )LOAD or )COPY a workspace to use *built-in* > native function. > > Xtian. > > On 2017-01-04 02:52, Elias Mårtenson wrote: > >> Well, FILE_IO.apl is also part of GNU APL. >> >> Regards, >> Elias >> >> On 4 January 2017 a

Re: [Bug-apl] Request to add to the ⎕fio[] a 'function_common_name' as argument

Well, FILE_IO.apl is also part of GNU APL. Regards, Elias On 4 January 2017 at 15:51, Christian Robert <christian.rob...@polymtl.ca> wrote: > Not *exactly*. Since QuadFIO is part of gnu-apl, why not improve the > QuadFIO so it is essayer to use. > > Xtian. > > On

Re: [Bug-apl] Bug: cannot erase incorrectly defined function

The function is probably still on the SI stack. Try running )SIC first. On 20 December 2016 at 16:45, Alexey Veretennikov < alexey.veretenni...@gmail.com> wrote: > Hi, > > If the function is incorrectly defined with the line-editor, it is > impossible to erase it: > > > )clear > CLEAR WS >

Re: [Bug-apl] Safe mode is not so safe

On 29 Mar 2017 22:35, wrote: Are you doing this on your own irc server or in a 'freenode' type public channel? Why not start by setting this up in a chroot 'jail' and in a vm :) I am, actually. But that is no reason to give unfettered access to even a constrained system.

Re: [Bug-apl] Safe mode is not so safe

implement the restrictions > (via ./configure, or in preferences files, or as command line option(s)). > > Best Regads, > /// Jürgen > > > On 03/29/2017 06:21 AM, Elias Mårtenson wrote: > > I'm implementing an IRC bot that can run arbitrary APL expressions. Since >

[Bug-apl] Bug in ⊤ ?

While discussing APL and J on IRC, I discovered a weird behavioural difference. Is GNU APL doing the right thing here? * 10 10 10 ⊤ 125 46 789* ┏→┓ ↓1 0 7┃ ┃2 4 8┃ ┃5 6 9┃ ┗━┛ I'd expect to get the result that I'm getting by applying ⍉ to the result, in other words, I'd expect the

[Bug-apl] Error in error message INDEX ERROR

When displaying an index error, the error message doesn't take ⎕IO into account. To reproduce: * x ← ⍳10* * x[0]* INDEX ERROR+ x[0] ^^ * )more* ⎕IO=1 offending index=-1 max index=10 The offending index should be 0 here. Regards, Elias

[Bug-apl] Safe mode is not so safe

I'm implementing an IRC bot that can run arbitrary APL expressions. Since this bot can run code submitted by anyone, I need to ensure that the code can't affect the system where the APL expressions are executed. This is the purpose of the --safe flag, but I have noted that several destructive

Re: [Bug-apl] Is the index generator function definition allowed to work on vectors of any length?

It's an extension. Since it's undefined by both APL2 as well as ISO 13751, it's a compatible extension, and a quite useful one at that. For example, creating a multiplication table is: ×/¨⍳10 10, which also extends naturally to more dimensions, unlike the alternative which uses ∘.×. There was a

[Bug-apl] Free APL reference documentation, any takers?

The Emacs mode for GNU APL contains a (small) reference manual. Really nothing more than a short paragraph on most system functions, enough for the integrated documentation features to work. It's been pointed out to me that it would be nice if the documentation was more complete, particularly with

Re: [Bug-apl] Free APL reference documentation, any takers?

gt; > On 04/11/2017 04:34 PM, Alexey Veretennikov wrote: > > Hi, > > Indeed I was also thinking on creating such a documentation even in terms of > notes for myself. I > don't always use Emacs for GNU APL (I run it on a device where I'm not able > to compil

Re: [Bug-apl] )HELP ...

On 18 April 2017 at 23:57, David B. Lamkins wrote: > > Is "all the leading comment lines until the first non-comment line" that > complex? I'm just trying to be precise about what's a "header comment" and > what's not. > This special comment describes what the function does,

Re: [Bug-apl] scalar/array

In GNU APL, try this instead : "a"[1] The reason this seems inconsistent is because single quote is used to define a string, i.e. an array of characters. Except the case where there is only a single character, in which case it represents a scalar character. GNU APL allows you to use double

Re: [Bug-apl] scalar/array

On 4 March 2017 at 05:57, wrote: what is the reason? do you know their reasoning > > cause 1 is 1 element and 1 2 3 is 3 elements so ⍴ 1 2 3 is 3 > and ⍴ 1 should have been 1 But that's wrong. 1 is not a one-element array. 1 is just a number. 1 2 is a two-element

Re: [Bug-apl] Bogus compiler warnings

On 9 March 2017 at 18:29, Alexey Veretennikov wrote: > Hi, > > I'm trying to compile GNU APL with GCC 3.4.6 armv5. There are couple of > bogus compiler warnings, mainly about variable might be uninitialized. > Sometimes the situations are like this: > > SomeObject

[Bug-apl] West way to remove substrings?

In a discussion on the #lisp IRC channel recently, someone wanted to remove a certain substring from a larger string. In Lisp, the solution is to simply use cl-ppcre and remove by regex. But, I started thinking about how to do this in APL, and this is what I came up with: RemoveSubstrings

Re: [Bug-apl] Compile bug in apl-1.6 under MAC OS 10.9.5

This has already been fixed a few months ago. For this, and many other fixes, you should use the latest version from svn instead of the releases. That said, might be time for a new release. Jürgen? Regards, Elias On 14 Mar 2017 11:53 PM, "Jean-Jacques Girardot" <

Re: [Bug-apl] )HELP ...

personal taste. Regards, Elias On 18 April 2017 at 10:49, Elias Mårtenson <loke...@gmail.com> wrote: > Hello David, > > Having a standardised format is what makes this so useful. The whole point > of this is to make sure that everybody uses the same convention so > third-part

Re: [Bug-apl] )HELP ...

Hello David, Having a standardised format is what makes this so useful. The whole point of this is to make sure that everybody uses the same convention so third-party tools can integrate with the system. If everybody “adopts the convention they prefer”, as you suggest, such a system would not be

Re: [Bug-apl] )HELP ...

I'm not sure that's even a different point of view. What you listed is common sense and I hope everybody who is developing code for more than one person abides by it. It also doesn't conflict with the idea of docstrings. What the double lamp signifies is the difference between documentation

Re: [Bug-apl] Rational Numbers

I haven't looked at this yet, but is this purely a display feature, or is it a full implementation of rational numbers? In other words, is the result of 1÷3 exact? And if so, how do I convert a rational number into a floating-point number? Regards, Elias On 21 July 2017 at 00:05, Juergen

Re: [Bug-apl] Rational Numbers

There is an error in the rational code: In Archive.cc, line 218, the snprintf format is wrong. %lld is used, while the types of the arguments are actually "long". Thus, "%lld÷%lld" should be "%ld÷%ld" instead. On 21 July 2017 at 12:06, Elias Mårtenson <loke.

[Bug-apl] Floating-point random number function

I had a need to have a function that does the same as monadic ?, but with the difference that the resulting numbers not be integers, but floating point. Now, here's my attempt at creating such a function, I'd like to know if this is the best way to achieve what I need: ∇ r←*hrRand* V ;res ⍝⍝

Re: [Bug-apl] Floating-point random number function

The purpose of it is to preserve the structure of the argument, while setting all values to MAXINT. Is there a better way to achieve this? Regards, Elias On 30 June 2017 at 12:21, Christian Robert <christian.rob...@polymtl.ca> wrote: > On 2017-06-30 00:19, Elias Mårtenson wrote: &g

[Bug-apl] Implementing Dyalog Key function

How about implementing the key function, ⌸? It's described in this article on the Dyalog site: https://www.dyalog.com/blog/2015/04/exploring-key/ Jürgen, are you in favour of this function? Regards, Elias

Re: [Bug-apl] Implementing Dyalog Key function

age. And I > have seen too many > software projects that failed due to being overly ambitious. I simply do > not want to share their fate. > > Regarding emacs, I can't help to note that I am not using it, because it > is, for my taste, too complex. > I rather prefer something sim

Re: [Bug-apl] Implementing Dyalog Key function

t; 1. don't clone arrays unnecessarily > > 2. improve support for parallel processing > > With these, GNU APL would be much more efficient. I think moving the > focus to CPU and memory efficiency is much more important than adding > extensions of any sort. > > --blake >

Re: [Bug-apl] Implementing Dyalog Key function

APL - > to take advantage of parallel processing. > > Just one opinion. > > Blake > > > On Tue, Jul 4, 2017 at 11:01 AM, Elias Mårtenson <loke...@gmail.com> > wrote: > >> Hello Blake, >> >> I agree those are important points too. Some time

Re: [Bug-apl] Implementing Dyalog Key function

terms what the function is actually doing. That > makes it > a good candidate for a never used function if it should ever be > implemented. > > Best Regards, > Jürgen Sauermann > > > > > On 07/02/2017 06:24 PM, Elias Mårtenson wrote: > > How about

Re: [Bug-apl] Implementing Dyalog Key function

; its own symbol, but if we would do so (which is technically possible due > to Unicode) then we would have turned > GNU APL into an unreadable mess. > > Best Regards, > Jürgen Sauermann > > > > > On 07/03/2017 05:50 AM, Elias Mårtenson wrote: > > The key function is b

Re: [Bug-apl] Implementing Dyalog Key function

ency). I remember another post about > unnecessary bloat because of the unnecessary copying. This was causing his > machine to page unnecessarily. The unnecessary coping is major in terms of > performance and memory efficiency. This is big. > > 4. APL was developed with the promise o

[Bug-apl] Help with APL expression

I have a list of strings, and a corresponding set of categorisations: * strings ← 'foo' 'bar' 'abc' 'def' 'ghi' 'jkl'* * categories ← 1 1 0 2 1 0* I now need to group these strings according to category. In other words, when applying operation X, I need the following output: *

[Bug-apl] Right-arrow, correct behaviour?

I have defined a function as such: ∇ Z ← foo X →(X=0)/zero Z ← 'not zero' → zero: Z ← 'zero' ∇ When calling this function with a non-zero argument, I expect the return value to be 'not zero'. Instead it simply exits the function. Is this correct behaviour? Regards, Elias

Re: [Bug-apl] Right-arrow, correct behaviour?

On 28 June 2017 at 18:22, Kacper Gutowski <mwgam...@gmail.com> wrote: > On Wed, Jun 28, 2017 at 06:02:03PM +0800, Elias Mårtenson wrote: > > I have defined a function as such: > > > > ∇ Z ← foo X > > →(X=0)/zero > > Z ← 'not zero' > > → > >

[Bug-apl] Runaway power operator can't be stopped

If I write an expression using the power operator that never finishes, for example: * 10+⍣=1* Then this will run forever, and Control-C can't be used to kill it. The only way out is to kill the entire APL session. Regards, Elias

Re: [Bug-apl] Assertion failed

Can you tell me exactly what you are doing in order to reproduce the problem? Regards, Elias On 31 Jul 2017 04:51, "Juergen Sauermann" wrote: > Hi Ala'a, > > maybe this is something for Elias to look into. Seems like some > Simple_string is corrupted. > > ///

Re: [Bug-apl] Assertion failed

gt; "PrintOperator.hh*") understands > UCF and UCS strings directly. > > /// Jürgen > > > On 07/31/2017 02:31 AM, Elias Mårtenson wrote: > > Can you tell me exactly what you are doing in order to reproduce the > problem? > > Regards, > Elias > > >

Re: [Bug-apl] Assertion failed

correct, except that an *UCS8_string* is not a string, despite of its > name. > *UCS8_string*s have no terminating 0 byte; the 0-byte is only appended if > the *UCS8_string* is converted to a C string with function *c_str()*. > > /// Jürgen > > > On 08/08/2017 09:28 AM, Elias Mårt

[Bug-apl] About fractional notation

Currently, the division symbol is used to represent fractional numbers. I would like to suggest the use of FRACTION SLASH (U+2044) instead. I think that would look better, and more intuitive. Note that this symbol is different from a regular slash, /, in several ways. First and foremost, it has a

Re: [Bug-apl] Modulo or residue function is not generating consistent complete residue systems for some arguments

Wolfram Alpha tells me it should be 5J3: https://www.wolframalpha.com/input/?i=(5%2B3i)+mod+(14%2B5i) Regards, Elias On 20 June 2017 at 16:02, Jay Foad wrote: > With the demo version of APL2 I get: > > 5J3 ∣ 14J5 > ¯4J1 > 5J3 | 1J4 > ¯4J1 > 5J3 | ¯4J1 >

Re: [Bug-apl] Modulo or residue function is not generating consistent complete residue systems for some arguments

"⍵ mod ⍺" or "⍵ rem ⍺" or > "⍵ % ⍺" in most other systems. > > On 20 June 2017 at 09:11, Elias Mårtenson <loke...@gmail.com> wrote: > >> Wolfram Alpha tells me it should be 5J3: >> >> https://www.wolframalpha.com/input/?i=(5%2B3i)+mod+(14%2B5i)

[Bug-apl] Problems with ]BOXING in the latest svn version

This is what happened when I tried to enable -29: * ]BOXING ¯29* *args: '[' at Command.cc:180 *args: '[' at Command.cc:180 *args: '[' at Command.cc:180 *args: '[' at Command.cc:180 *args: '[' at Command.cc:180 *args:

[Bug-apl] Grouping function

I'm sure there was a function that could do this, but for the life of me can't figure out which one it was. Assuming I have an array of values, I want to split them into groups of N numbers, which are overlapping. I.e. if the group size is 3 and the array contains the values 1 2 3 4 5 6, I want

Re: [Bug-apl] Grouping function

Thank you. That's what I needed. On 17 June 2017 at 18:25, Kacper Gutowski <mwgam...@gmail.com> wrote: > On Sat, Jun 17, 2017 at 06:17:24PM +0800, Elias Mårtenson wrote: > > I'm sure there was a function that could do this, but for the life of me > > can't

Re: [Bug-apl] Regex support

gt; strings. > > Best Regards, > /// Jürgen > > > On 09/21/2017 12:09 PM, Elias Mårtenson wrote: > > I've implemented the bare minimal needed to get regexes working through > a ⎕RE function. I've attached the diff. > > I really need Jürgen to take a look at this

Re: [Bug-apl] Regex support

On 21 September 2017 at 04:30, wrote: anyone who loves grep and hates perl (and i hope java too) can't > be all bad > > using apl like syntax is goodaaa' ⎕REX['s'] 'bbb' what would > monadic ⎕REX['s'] 'bbb' return? I don't think there is any reasonably monadic

Re: [Bug-apl] Regex support

I did not know this. I took a look at Dyalog's API and it's not possible to implement it fully, as it relies on their object oriented features. However, the basic functionality wouldn't be hard to replicate, if that is something that is desired. Jürgen, what is your opinion on this? On 22

Re: [Bug-apl] Regex support

ll. That, in conjuction with APL arrays, > would ultimately be a killer feature (I am not aware of such a feature > in other languages). > > Best, > > Giuseppe Cocomazzi > http://sbudella.altervista.org > > > On Wed, Sep 20, 2017 at 5:59 AM, Elias Mårtenson <loke...@gmai

[Bug-apl] Regex support

On several occasions, I have felt that built-in regex support in GNU APL would be very helpful. Implementing it should be rather simple, but I'd like to discuss how such an API should look in order for it to be as useful as possible. I was thinking of the following form: regex ⎕Regex

Re: [Bug-apl] Regex support

I've implemented the bare minimal needed to get regexes working through a ⎕RE function. I've attached the diff. I really need Jürgen to take a look at this, since my code that constructs the return value cannot possibly be correct. There must be a better way to handle this which does not involve

[Bug-apl] Regexp prototype

Here's the diffs for the current version of regexp support. It's probably stable enough to use for real so that we can get some feedback on it. Do you want to merge this? Regards, Elias Index: configure.ac === --- configure.ac

Re: [Bug-apl] Regex support

meant for dyadic ⊂. > > /// Jürgen > > > On 10/02/2017 10:47 AM, Elias Mårtenson wrote: > > In playing around with this, I realise that the "B" mode is quite useful. > So much so, in fact, that I'm wondering if it's warranted to have a > dedicated quad-function for

Re: [Bug-apl] Regexp prototype

t; maybe you want to write a brief description of *⎕RE* for *doc/apl.texi* ? > And should we maybe call it *⎕REX*? > > Best Regards, > Jürgen > > > On 10/04/2017 12:30 PM, Elias Mårtenson wrote: > > Thanks. > > The version I sent to you still uses "B" as the c

Re: [Bug-apl] Regexp prototype

s, I will do so. May take a few days though. > > Best Regards, > /// Jürgen > > > On 10/04/2017 07:43 AM, Elias Mårtenson wrote: > > Here's the diffs for the current version of regexp support. It's probably > stable enough to use for real so that we can get some feedba

Re: [Bug-apl] Suggestion for Quad-RE

On 12 October 2017 at 20:55, Juergen Sauermann < juergen.sauerm...@t-online.de> wrote: > Hi Elias, > > see below. > > /// Jürgen > > > On 10/12/2017 09:13 AM, Elias Mårtenson wrote: > > On 11 October 2017 at 21:15, Juergen Sauermann < > juergen.sauerm...@

Re: [Bug-apl] Assertion failed

k: > > > > Depth: 0 > > Exec: 0xbaf770 > > Safe exec: 0 > > Pmode: ◊ x.y > > PC: 0 (5) 'y > > Stat: x.y > > err_code: 0x30001 > > thrown at: Symbol.cc:683 > > e_msg_1:'VALUE ERROR' > > e_msg_2:'

Re: [Bug-apl] Regex support

is already occupied in GNU APL (inherited from IBM APL2), > so some other name(s) are needed. > > Before implementing too much in advance, it would be good to present the > intended syntax and semantics on bug-apl and solicit opinions. > > /// Jürgen > > > On 09/22/2017 04

Re: [Bug-apl] Regex support

t; The Macro definitions are contained in Macro.def > > Please note that in GNU APL functions cannot return functions, which may > or may not be a problem > in your case, depending on whether the function argument(s) of the > ⎕-operator is/are primitive or not. > In standard A

<    1   2   3   4   5   6   7   >