[Bug-apl] Extension proposal: ⍵⍵ to access outer lambda

[Elias Mårtenson]

It would be nice to be able to access the values of ⍵ and ⍺ (and I suppose
χ) from the outer lambda from a nested lambda.

I.e, I'd like to following to return the value 1100:

*  { ⍵ + {⍵×⍵⍵} 10 } 100*

In other words, the ⍵⍵ in the inner lambda would refer to the value 100
(i.e. the value of ⍵ in the outer lambda).

Would this be easy to implement?

Regards,
Elias

Re: [Bug-apl] Execution properties - "cannot be suspended" bit

[Juergen Sauermann]

Hi David,

thanks, I have changed the code so that all user-defined functions with
the cannot be suspended" attribute at the top of the )SI stack are pop'ed
before a new immediate execution context is pushed onto )SI. SVN 369.

I hope this is what the standard wants - the information about these
cases is rather thin in both the ISO standard and in the APL2 manual.

I am not always following APL2 when it comes to hiding details of 
errors, locked

functions and similar because some of that does IMHO not make much sense in
open-source programs.

/// Jürgen


On 07/08/2014 05:18 AM, David B. Lamkins wrote:

The ISO spec for the component file interface says: "The functions
described here must be written so that they do not suspend. Any errors
encountered or detected must be passed to the context from which the
function was invoked."

I believe that means that the function's "cannot be suspended" attribute
must be set.

I've arranged for each function in the component file API to have the
"cannot be suspended" bit set using
   0 1 0 0⎕fx ⎕cr 'function name'

Errors in the functions so attributed still display the line number at
which the error occurred. According to pg. 295 of the ISO spec, I should
see only the function name on the state indicator.

Re: [Bug-apl] Execution properties - "cannot be suspended" bit

[Elias Mårtenson]

I can't say it makes much sense in non-opensource programs either. My guess
is that these things are more of a relic of a time when people were
experimenting with such things. There is a reason no other languages do
this.

However, I do see a different use for "non-suspendible functions". I see it
as functions that are guaranteed atomic. I.e. functions that modify global
state and may actually corrupt that state if they are suspended. Thus, you
should not be able to interrupt them, and in a multithreaded context you'd
imagine that it had a big global mutex protecting it.

Regards,
Elias


On 9 July 2014 21:11, Juergen Sauermann 
wrote:

> Hi David,
>
> thanks, I have changed the code so that all user-defined functions with
> the cannot be suspended" attribute at the top of the )SI stack are pop'ed
> before a new immediate execution context is pushed onto )SI. SVN 369.
>
> I hope this is what the standard wants - the information about these
> cases is rather thin in both the ISO standard and in the APL2 manual.
>
> I am not always following APL2 when it comes to hiding details of errors,
> locked
> functions and similar because some of that does IMHO not make much sense in
> open-source programs.
>
> /// Jürgen
>
>
>
> On 07/08/2014 05:18 AM, David B. Lamkins wrote:
>
>> The ISO spec for the component file interface says: "The functions
>> described here must be written so that they do not suspend. Any errors
>> encountered or detected must be passed to the context from which the
>> function was invoked."
>>
>> I believe that means that the function's "cannot be suspended" attribute
>> must be set.
>>
>> I've arranged for each function in the component file API to have the
>> "cannot be suspended" bit set using
>>0 1 0 0⎕fx ⎕cr 'function name'
>>
>> Errors in the functions so attributed still display the line number at
>> which the error occurred. According to pg. 295 of the ISO spec, I should
>> see only the function name on the state indicator.
>>
>>
>>
>>
>
>

Re: [Bug-apl] Extension proposal: ⍵⍵ to access outer lambda

[Juergen Sauermann]

Hi Elias,

that would be very easy to implement:

*  { ⍵ + { ⍵ × OUTER_OMEGA } 10 ⊣ OUTER_OMEGA←⍵ } 100
1100
*
/// Jürgen


On 07/09/2014 10:53 AM, Elias Mårtenson wrote:
It would be nice to be able to access the values of ⍵ and ⍺ (and I 
suppose χ) from the outer lambda from a nested lambda.


I.e, I'd like to following to return the value 1100:

*  { ⍵ + {⍵×⍵⍵} 10 } 100*

In other words, the ⍵⍵ in the inner lambda would refer to the value 
100 (i.e. the value of ⍵ in the outer lambda).


Would this be easy to implement?

Regards,
Elias

Re: [Bug-apl] Execution properties - "cannot be suspended" bit

[David Lamkins]

Thank you. Confirmed working.

With this change, I believe that the component function library conforms to
the ISO spec.

https://github.com/TieDyedDevil/iso-apl-cf



On Wed, Jul 9, 2014 at 6:11 AM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:

> Hi David,
>
> thanks, I have changed the code so that all user-defined functions with
> the cannot be suspended" attribute at the top of the )SI stack are pop'ed
> before a new immediate execution context is pushed onto )SI. SVN 369.
>
> I hope this is what the standard wants - the information about these
> cases is rather thin in both the ISO standard and in the APL2 manual.
>
> I am not always following APL2 when it comes to hiding details of errors,
> locked
> functions and similar because some of that does IMHO not make much sense in
> open-source programs.
>
> /// Jürgen
>
>
>
> On 07/08/2014 05:18 AM, David B. Lamkins wrote:
>
>> The ISO spec for the component file interface says: "The functions
>> described here must be written so that they do not suspend. Any errors
>> encountered or detected must be passed to the context from which the
>> function was invoked."
>>
>> I believe that means that the function's "cannot be suspended" attribute
>> must be set.
>>
>> I've arranged for each function in the component file API to have the
>> "cannot be suspended" bit set using
>>0 1 0 0⎕fx ⎕cr 'function name'
>>
>> Errors in the functions so attributed still display the line number at
>> which the error occurred. According to pg. 295 of the ISO spec, I should
>> see only the function name on the state indicator.
>>
>>
>>
>>
>


-- 
"The secret to creativity is knowing how to hide your sources."
   Albert Einstein


http://soundcloud.com/davidlamkins
http://reverbnation.com/lamkins
http://reverbnation.com/lcw
http://lamkins-guitar.com/
http://lamkins.net/
http://successful-lisp.com/

Re: [Bug-apl] Execution properties - "cannot be suspended" bit

[David Lamkins]

Regarding locked functions: I believe these came about at a time when
vendors sold not only computer time, but also software services. No doubt
this was used to hide details of a "proprietary" function from paying
customers...


On Wed, Jul 9, 2014 at 7:06 AM, Elias Mårtenson  wrote:

> I can't say it makes much sense in non-opensource programs either. My
> guess is that these things are more of a relic of a time when people were
> experimenting with such things. There is a reason no other languages do
> this.
>
> However, I do see a different use for "non-suspendible functions". I see
> it as functions that are guaranteed atomic. I.e. functions that modify
> global state and may actually corrupt that state if they are suspended.
> Thus, you should not be able to interrupt them, and in a multithreaded
> context you'd imagine that it had a big global mutex protecting it.
>
> Regards,
> Elias
>
>
> On 9 July 2014 21:11, Juergen Sauermann 
> wrote:
>
>> Hi David,
>>
>> thanks, I have changed the code so that all user-defined functions with
>> the cannot be suspended" attribute at the top of the )SI stack are pop'ed
>> before a new immediate execution context is pushed onto )SI. SVN 369.
>>
>> I hope this is what the standard wants - the information about these
>> cases is rather thin in both the ISO standard and in the APL2 manual.
>>
>> I am not always following APL2 when it comes to hiding details of errors,
>> locked
>> functions and similar because some of that does IMHO not make much sense
>> in
>> open-source programs.
>>
>> /// Jürgen
>>
>>
>>
>> On 07/08/2014 05:18 AM, David B. Lamkins wrote:
>>
>>> The ISO spec for the component file interface says: "The functions
>>> described here must be written so that they do not suspend. Any errors
>>> encountered or detected must be passed to the context from which the
>>> function was invoked."
>>>
>>> I believe that means that the function's "cannot be suspended" attribute
>>> must be set.
>>>
>>> I've arranged for each function in the component file API to have the
>>> "cannot be suspended" bit set using
>>>0 1 0 0⎕fx ⎕cr 'function name'
>>>
>>> Errors in the functions so attributed still display the line number at
>>> which the error occurred. According to pg. 295 of the ISO spec, I should
>>> see only the function name on the state indicator.
>>>
>>>
>>>
>>>
>>
>>
>


-- 
"The secret to creativity is knowing how to hide your sources."
   Albert Einstein


http://soundcloud.com/davidlamkins
http://reverbnation.com/lamkins
http://reverbnation.com/lcw
http://lamkins-guitar.com/
http://lamkins.net/
http://successful-lisp.com/

Re: [Bug-apl] Defined operator won't accept right constant function

[David B. Lamkins]

Hmm? It's in *gnu-apl-keymap* on my systems...

On Wed, 2014-07-09 at 10:30 +0800, Elias Mårtenson wrote:
> Wow. This is the first I heard of χ. Shouldn't it be mapped to the
> keyboard somewhere?

[Bug-apl] Filter fns with ⍙ (delta-underbar) in the name by default?

[Elias Mårtenson]

How about having the )FNS, )OPS and )VARS commands filter out names that
contain a ⍙ symbol by default? Since the idea is that those are internal
names it would make sense to hide them (unless some other flag is given).

Opinions?

Regards,
Elias

Re: [Bug-apl] Request: lib_file_io additions

[Elias Mårtenson]

Yes, fair enough. It's the end result I'm after. :-)

Regards,
Elias


On 8 July 2014 11:56, David B. Lamkins  wrote:

> It looks like glob() subsumes the function of readdir(). There are some
> nasty details with allocated results, too...
>
> You could, however, combine fnmatch() with readdir().
>
> http://linux.die.net/man/3/fnmatch
>
> On Tue, 2014-07-08 at 11:44 +0800, Elias Mårtenson wrote:
> > How about adding support for a dyadic form where the left-side
> > argument is a glob pattern to be used when matching the file names?
> >
> >
> > http://linux.die.net/man/3/glob
> >
> >
> >
> > Regards,
> > Elias
> >
> >
> > On 8 July 2014 00:52, David Lamkins  wrote:
> > Thanks, Jüergen. I'll change my code tonight to use the new
> > calls.
> >
> >
> > I like your solution to readdir() access. I fell asleep last
> > night pondering how best to do that.
> >
> >
> > On Mon, Jul 7, 2014 at 9:44 AM, Juergen Sauermann
> >  wrote:
> > Hi David,
> >
> > I have added rename (FILE_IO[27]), SVN 364.
> >
> > I didn't do readdir() because that would need you to
> > opendir(),
> > loop around readdir() and closedir().
> >
> > Instead FILE_IO[28] returns the entire directory as a
> > matrix in one go.
> >
> > Every row is a dirent struct but with a different
> > order:
> >
> > filename
> > d_ino;   /* inode number */
> > d_off;   /* not an offset; see NOTES */
> > d_reclen;/* length of this record */
> > d_type;  /* type of file; not supported
> >
> > The reason for the different order is that not all
> > fields are present in every file system,
> > so I thought I should put all non-optional fields
> > before the optional field, making the columns
> > of the result more portable.
> >
> >
> > /// Jürgen
> >
> >
> >
> >
> >
> > On 07/07/2014 09:31 AM, David B. Lamkins wrote:
> >
> > > There are two functions that I'd like to access via
> lib_file_io:
> > > readdir() and rename().
> > >
> > > I'm currently implementing these via popen() through
> lib_file_io, but
> > > that seems inelegant...
> > >
> > > I have immediate application for these calls in the
> component file
> > > library.
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> > --
> > "Far out in the uncharted backwaters of the unfashionable end
> > of the Western Spiral arm of the Galaxy lies a small
> > unregarded yellow sun. Orbiting this at a distance of roughly
> > ninety-eight million miles is an utterly insignificant little
> > blue-green planet whose ape-descended life forms are so
> > amazingly primitive that they still think programming in Java
> > is a pretty neat idea."
> >
> >  -- With apologies to Douglas Adams, who I like to think would
> > have appreciated this.
> >
> >
> > http://soundcloud.com/davidlamkins
> > http://reverbnation.com/lamkins
> > http://reverbnation.com/lcw
> > http://lamkins-guitar.com/
> > http://lamkins.net/
> > http://successful-lisp.com/
> >
> >
>
>
>

Re: [Bug-apl] Extension proposal: ⍵⍵ to access outer lambda

[Juergen Sauermann]

Hi,

actually - no. I called it OUTER_OMEGA to make clear what it does.
Maybe you like

*  { ⍵ + {⍵×WW} 10 ⊣ WW←⍵ } 100
1100
*
imore?


On 07/09/2014 04:08 PM, Elias Mårtenson wrote:

I know, but it's much more ugly than my proposal, don't you think?

Regards,
Elias


On 9 July 2014 22:06, Juergen Sauermann > wrote:


Hi Elias,

that would be very easy to implement:

*  { ⍵ + { ⍵ × OUTER_OMEGA } 10 ⊣ OUTER_OMEGA←⍵ } 100
1100
*
/// Jürgen



On 07/09/2014 10:53 AM, Elias Mårtenson wrote:

It would be nice to be able to access the values of ⍵ and ⍺ (and
I suppose χ) from the outer lambda from a nested lambda.

I.e, I'd like to following to return the value 1100:

*{ ⍵ + {⍵×⍵⍵} 10 } 100*

In other words, the ⍵⍵ in the inner lambda would refer to the
value 100 (i.e. the value of ⍵ in the outer lambda).

Would this be easy to implement?

Regards,
Elias

Re: [Bug-apl] Question about behavior of ⍋

[Jay Foad]

Dyalog (same behaviour as NARS, I think):

  ⍋'AAA' 'Y' 'BBB' 'CC'
DOMAIN ERROR

  Z←'AA' 'XX' 'AAA' 'XXX'
  ⍋⎕UCS¨Z
DOMAIN ERROR

  ⎕ML←2
  ⍋⊃Z
1 3 2 4

Jay.

On 9 July 2014 03:59, Elias Mårtenson  wrote:
> I was looking specifically at the results of grade on a two-dimensional
> array. I missed the fact that both APL2 and NARS fails on arrays of depth 2.
>
> What does Dyalog and APLX do in these cases?
>
> Regards,
> Elias
>
>
> On 9 July 2014 10:52, Blake McBride  wrote:
>>
>> No, same results as IBM APL 2.
>>
>>
>>
>> On Tue, Jul 8, 2014 at 9:42 PM, Elias Mårtenson  wrote:
>>>
>>> So NARS is giving the same results as GNU APL then?
>>>
>>>
>>> On 8 July 2014 22:50, Blake McBride  wrote:

 Interestingly, in NARS200 I get all of the same results as in IBM APL 2
 except the following:

   ⍋⊃z
 1 3 2 4





 On Tue, Jul 8, 2014 at 9:41 AM, Blake McBride 
 wrote:
>
> For what it is worth, IBM APL 2 gives:
>
>   ⍋'AAA' 'Y' 'BBB' 'CC'
> DOMAIN ERROR
>   ⍋'AAA' 'Y' 'BBB' 'CC'
>   ∧
>
>   Z←'AA' 'XX' 'AAA' 'XXX'
>   ⎕UCS¨Z
> 65 65  88 88  65 65 65  88 88 88
>   ⍋⎕UCS¨Z
> DOMAIN ERROR
>   ⍋⎕UCS¨Z
>   ∧
>
>   ⊃Z
> AA
> XX
> AAA
> 
>   ⍋⊃Z
> DOMAIN ERROR
>   ⍋⊃Z
>   ∧
>
>
> I have no real preference regarding this.  I am just providing this for
> informational purposes.  Please feel free with other tests you would like 
> me
> to perform.
>
> Thanks.
>
> Blake
>
>
>
>
> On Tue, Jul 8, 2014 at 5:45 AM, Juergen Sauermann
>  wrote:
>>
>> Hi Elias,
>>
>> nice trick!
>>
>> /// Jürgen
>>
>>
>>
>> On 07/08/2014 08:58 AM, Elias Mårtenson wrote:
>>
>> By the way, I found a workaround to the string ordering. The
>> workaround requires memory on the order of ↑(⍴V)×⌈/⍴¨V for a vector V. 
>> This
>> should be enough justification for the proposed extension.
>>
>> Here's what I do: instead of doing the following:
>>
>>   z[⍋z←'foo' 'bar' 'test' 'aa']
>> ┌→──┐
>> │┌→──┐ ┌→──┐ ┌→───┐ ┌→─┐│
>> ││bar│ │foo│ │test│ │aa││
>> │└───┘ └───┘ └┘ └──┘│
>> └∊──┘
>>
>> I do this:
>>
>>   z[⍋⊃z←'foo' 'bar' 'test' 'aa']
>> ┌→──┐
>> │┌→─┐ ┌→──┐ ┌→──┐ ┌→───┐│
>> ││aa│ │bar│ │foo│ │test││
>> │└──┘ └───┘ └───┘ └┘│
>> └∊──┘
>>
>> Regards,
>> Elias
>>
>>
>>
>>>
>>
>>
>

>>>
>>
>

Re: [Bug-apl] Extension proposal: ⍵⍵ to access outer lambda

[Kacper Gutowski]

On 2014-07-09 16:14:32, Juergen Sauermann wrote:
> Hi,
> 
> actually - no. I called it OUTER_OMEGA to make clear what it does.
> Maybe you like
> 
>   { ⍵ + {⍵×WW} 10 ⊣ WW←⍵ } 100
> 1100
> 
> imore?

I think the main problem isn't the length of variable's name but the
fact that regular variable is neither lexically scoped nor localized.

Using ⍵⍵ might be confusing for Dyalog users where ⍺⍺ and ⍵⍵ are used
as functional arguments of dfn operators.  But since GNU APL uses ⍶
and ⍹ for those and it doesn't localize variables in dfns, using
repeated ⍺/⍵ for nested arguments doesn't sound that bad.


-k

Re: [Bug-apl] Defined operator won't accept right constant function

[David B. Lamkins]

That's only because I wondered what χ is used for right after the layout
change. ;)

On Wed, 2014-07-09 at 10:57 +0800, Elias Mårtenson wrote:
> Yes, you're right. :-)  You know my code better than myself.
> 
> 
> Regards,
> Elias
> 
> 
> On 9 July 2014 10:50, David B. Lamkins  wrote:
> Hmm? It's in *gnu-apl-keymap* on my systems...
> 
> On Wed, 2014-07-09 at 10:30 +0800, Elias Mårtenson wrote:
> > Wow. This is the first I heard of χ. Shouldn't it be mapped
> to the
> > keyboard somewhere?
> 
> 
> 
> 
> 
> 

[Bug-apl] ISO Component File API preview

[David Lamkins]

I haven't yet written test scripts, but I've informally tested all of the
functions and am reasonably confident that the component file API is
complete and correct.

If you'd like to try out the API while I'm working on scripted test cases,
the repo is:

https://github.com/TieDyedDevil/iso-apl-cf

You'll find documentation is in the comments and in Annex A of the ISO
13751 standard.

The standard "specifies a minimal set of functions which a conforming
implementation must provide"; I've implemented all of these. I've also
added several useful functions not mentioned in the standard, including
component inquiry, component drop, and transaction support.

Note that the code is not packaged for my package manager; I assume that
the component file implementation would become an L3 library in the event
it's adopted for inclusion in GNU APL.

Júergen, I've specified the GPLv3 license since that's what GNU APL uses.
If there's a more appropriate choice of license for this library, please
let me know.

-- 
"The secret to creativity is knowing how to hide your sources."
   Albert Einstein


http://soundcloud.com/davidlamkins
http://reverbnation.com/lamkins
http://reverbnation.com/lcw
http://lamkins-guitar.com/
http://lamkins.net/
http://successful-lisp.com/

Re: [Bug-apl] Filter fns with ⍙ (delta-underbar) in the name by default?

[David B. Lamkins]

Personally, I'm not a fan of having tools codify what's essential a
stylistic convention. 

Looking at it another way: This is something I call the "principle of
least surprise... An experienced APL programmer shouldn't have to be
told that )FNS, )OPS and )VARS all have a hidden feature that must be
explicitly disabled to obtain the expected (and standard) behavior.

That said: This is something that's easy to do in APL without changing
the underlying platform.  Here are a couple of functions that you could
use as a starting point:

∇z←⍙class ni ⍙set
  ⍝ Return a character array of every workspace name which includes
  ⍝ all characters in ⍙set. The empty set matches everything. The
  ⍝ optional ⍙class argument selects results by name class; the
  ⍝ default is 2 3 4 (variables, functions and operators).
  ⍎(0=⎕nc '⍙class')/'⍙class←2 3 4'
  z←⊃{ (∧/⊃(⊂,⍙set)∊¨⍵)/⍵ }{ (∧\' '≠⍵)/⍵ }¨⊂[(1+⎕io)]⎕nl ⍙class
∇

∇z←⍙class ne ⍙set
  ⍝ Return a character array of every workspace name which excludes
  ⍝ any character in ⍙set. The empty set excludes nothing. The
  ⍝ optional ⍙class argument selects results by name class; the
  ⍝ default is 2 3 4 (variables, functions and operators).
  ⍎(0=⎕nc '⍙class')/'⍙class←2 3 4'
  z←⊃{ (~∨/⊃(⊂,⍙set)∊¨⍵)/⍵ }{ (∧\' '≠⍵)/⍵ }¨⊂[(1+⎕io)]⎕nl ⍙class
∇
 

If you want to list all names not containing ⍙, do this:

  ne '⍙'

To get just the variables:

  2 ne '⍙'

Or just the functions:

  3 ne '⍙'

Or just the operators:

  4 ne '⍙'

The ni function is complementary.

Add a ]usercmd definition or three to customize this to your taste...

On Wed, 2014-07-09 at 23:12 +0800, Elias Mårtenson wrote:
> How about having the )FNS, )OPS and )VARS commands filter out names
> that contain a ⍙ symbol by default? Since the idea is that those are
> internal names it would make sense to hide them (unless some other
> flag is given).
> 
> 
> Opinions?
> 
> 
> Regards,
> Elias

Re: [Bug-apl] ISO Component File API preview

[Elias Mårtenson]

I was looking at your code, and I noticed that it's SQLite-specific.
WOuldn't it make sense to make it SQL-implementation-agnostic?

Based on what I can see, the only SQLite-specific SQL you have in there is
"replace into" which I had never heard about before.

Regards,
Elias


On 9 July 2014 01:22, David Lamkins  wrote:

> I haven't yet written test scripts, but I've informally tested all of the
> functions and am reasonably confident that the component file API is
> complete and correct.
>
> If you'd like to try out the API while I'm working on scripted test cases,
> the repo is:
>
> https://github.com/TieDyedDevil/iso-apl-cf
>
> You'll find documentation is in the comments and in Annex A of the ISO
> 13751 standard.
>
> The standard "specifies a minimal set of functions which a conforming
> implementation must provide"; I've implemented all of these. I've also
> added several useful functions not mentioned in the standard, including
> component inquiry, component drop, and transaction support.
>
> Note that the code is not packaged for my package manager; I assume that
> the component file implementation would become an L3 library in the event
> it's adopted for inclusion in GNU APL.
>
> Júergen, I've specified the GPLv3 license since that's what GNU APL uses.
> If there's a more appropriate choice of license for this library, please
> let me know.
>
> --
> "The secret to creativity is knowing how to hide your sources."
>Albert Einstein
>
>
> http://soundcloud.com/davidlamkins
> http://reverbnation.com/lamkins
> http://reverbnation.com/lcw
> http://lamkins-guitar.com/
> http://lamkins.net/
> http://successful-lisp.com/
>

Re: [Bug-apl] Defined operator won't accept right constant function

[Elias Mårtenson]

Yes, you're right. :-)  You know my code better than myself.

Regards,
Elias


On 9 July 2014 10:50, David B. Lamkins  wrote:

> Hmm? It's in *gnu-apl-keymap* on my systems...
>
> On Wed, 2014-07-09 at 10:30 +0800, Elias Mårtenson wrote:
> > Wow. This is the first I heard of χ. Shouldn't it be mapped to the
> > keyboard somewhere?
>
>
>
>

Re: [Bug-apl] ISO Component File API preview

[David B. Lamkins]

I'm certainly willing to consider alternatives. IIUC, lib_sql also
supports PostgreSQL. Anything else?

How do I tell lib_sql to use a PostgreSQL server?

The argument in favor of SQLite, of course, is that it's serverless. No
additional setup (beyond the installation of the library) required.

Would there be any additional benefits or concerns when connecting to a
PostgreSQL server? 

As you've no doubt noticed, there's nothing in the code (or in the
standard API) to acknowledge or support the notion of multiple users.
Again: point in favor of SQLite...


On Thu, 2014-07-10 at 10:25 +0800, Elias Mårtenson wrote:
> I was looking at your code, and I noticed that it's SQLite-specific.
> WOuldn't it make sense to make it SQL-implementation-agnostic?
> 
> 
> Based on what I can see, the only SQLite-specific SQL you have in
> there is "replace into" which I had never heard about before.
> 
> 
> Regards,
> Elias
> 
> 
> On 9 July 2014 01:22, David Lamkins  wrote:
> I haven't yet written test scripts, but I've informally tested
> all of the functions and am reasonably confident that the
> component file API is complete and correct.
> 
> 
> If you'd like to try out the API while I'm working on scripted
> test cases, the repo is:
> 
> https://github.com/TieDyedDevil/iso-apl-cf
> 
> 
> You'll find documentation is in the comments and in Annex A of
> the ISO 13751 standard.
> 
> 
> The standard "specifies a minimal set of functions which a
> conforming implementation must provide"; I've implemented all
> of these. I've also added several useful functions not
> mentioned in the standard, including component inquiry,
> component drop, and transaction support.
> 
> 
> 
> Note that the code is not packaged for my package manager; I
> assume that the component file implementation would become an
> L3 library in the event it's adopted for inclusion in GNU APL.
> 
> 
> Júergen, I've specified the GPLv3 license since that's what
> GNU APL uses. If there's a more appropriate choice of license
> for this library, please let me know.
> 
> -- 
> "The secret to creativity is knowing how to hide your
> sources."
>Albert Einstein
> 
> 
> http://soundcloud.com/davidlamkins
> http://reverbnation.com/lamkins
> http://reverbnation.com/lcw
> http://lamkins-guitar.com/
> http://lamkins.net/
> http://successful-lisp.com/
> 
> 

Re: [Bug-apl] ISO Component File API preview

[Elias Mårtenson]

To connect to a Postgres database, simply use "postgresql" as the left-side
argument to SQL∆Connect. The right-hand argument should be a connect string
as described here:
http://www.postgresql.org/docs/9.3/static/libpq-connect.html#LIBPQ-CONNSTRING

Regards,
Elias


On 10 July 2014 10:44, David B. Lamkins  wrote:

> I'm certainly willing to consider alternatives. IIUC, lib_sql also
> supports PostgreSQL. Anything else?
>
> How do I tell lib_sql to use a PostgreSQL server?
>
> The argument in favor of SQLite, of course, is that it's serverless. No
> additional setup (beyond the installation of the library) required.
>
> Would there be any additional benefits or concerns when connecting to a
> PostgreSQL server?
>
> As you've no doubt noticed, there's nothing in the code (or in the
> standard API) to acknowledge or support the notion of multiple users.
> Again: point in favor of SQLite...
>
>
> On Thu, 2014-07-10 at 10:25 +0800, Elias Mårtenson wrote:
> > I was looking at your code, and I noticed that it's SQLite-specific.
> > WOuldn't it make sense to make it SQL-implementation-agnostic?
> >
> >
> > Based on what I can see, the only SQLite-specific SQL you have in
> > there is "replace into" which I had never heard about before.
> >
> >
> > Regards,
> > Elias
> >
> >
> > On 9 July 2014 01:22, David Lamkins  wrote:
> > I haven't yet written test scripts, but I've informally tested
> > all of the functions and am reasonably confident that the
> > component file API is complete and correct.
> >
> >
> > If you'd like to try out the API while I'm working on scripted
> > test cases, the repo is:
> >
> > https://github.com/TieDyedDevil/iso-apl-cf
> >
> >
> > You'll find documentation is in the comments and in Annex A of
> > the ISO 13751 standard.
> >
> >
> > The standard "specifies a minimal set of functions which a
> > conforming implementation must provide"; I've implemented all
> > of these. I've also added several useful functions not
> > mentioned in the standard, including component inquiry,
> > component drop, and transaction support.
> >
> >
> >
> > Note that the code is not packaged for my package manager; I
> > assume that the component file implementation would become an
> > L3 library in the event it's adopted for inclusion in GNU APL.
> >
> >
> > Júergen, I've specified the GPLv3 license since that's what
> > GNU APL uses. If there's a more appropriate choice of license
> > for this library, please let me know.
> >
> > --
> > "The secret to creativity is knowing how to hide your
> > sources."
> >Albert Einstein
> >
> >
> > http://soundcloud.com/davidlamkins
> > http://reverbnation.com/lamkins
> > http://reverbnation.com/lcw
> > http://lamkins-guitar.com/
> > http://lamkins.net/
> > http://successful-lisp.com/
> >
> >
>
>
>

Re: [Bug-apl] Request: lib_file_io additions

[Juergen Sauermann]

Hi,

I think we have to draw the border between FILE_IO and convenience 
functions somewhere.

Otherwise we would end up with the entire libc accessible via FILE_IO.

And, remember, we have this nice language called APL to do such things.

/// Jürgen


On 07/08/2014 05:56 AM, David B. Lamkins wrote:

It looks like glob() subsumes the function of readdir(). There are some
nasty details with allocated results, too...

You could, however, combine fnmatch() with readdir().

http://linux.die.net/man/3/fnmatch

On Tue, 2014-07-08 at 11:44 +0800, Elias Mårtenson wrote:

How about adding support for a dyadic form where the left-side
argument is a glob pattern to be used when matching the file names?


http://linux.die.net/man/3/glob



Regards,
Elias

Re: [Bug-apl] Can't break out of the middle on a display operation

[Blake McBride]

I wouldn't do that!


On Tue, Jul 8, 2014 at 10:01 PM, Elias Mårtenson  wrote:

> I suggested some time ago that very large data sets shouldn't be displayed
> at all, since they are not only slow, they are also largely useless in an
> interactive session.
>
> It was decided that this approach would not be taken, but I don't remember
> the justification for it.
>
> Regards,
> Elias
>
>
> On 9 July 2014 10:58, Blake McBride  wrote:
>
>> I think the layout function need two modifications:
>>
>> 1.  enable ^C
>>
>> 2.  at least for large data, output as you go rather than format the
>> whole thing and then output the whole thing
>>
>> --blake
>>
>>
>>
>> On Tue, Jul 8, 2014 at 9:27 PM, Elias Mårtenson 
>> wrote:
>>
>>> There is already the SIGINT signal which is processed by GNU APL to
>>> interrupt a function execution. However, this interruptability is not
>>> extended to the layout function.
>>>
>>>
>>> On 9 July 2014 09:09, Peter Teeson  wrote:
>>>
 In Sharp APL (IPSA) we had a "panic int" which interrupted whatever was
 being computed after a predetermined time.
 It was inherent to the interpreter because we ran a timesharing system.
 I don't recall the exact details but it went something like this;

 1) Workspace gets swapped in for execution and is given a quantum of
 CPU time
 2) At the end of that quantum a second but quite small (relative to the
 normal ) additional amount of CPU was allocated
  to see if that would allow an interrupt at a "suitable" point in the
 function/operation that was going on.
 3) If that extra time was not sufficient the workspace was arbitrarily
 interrupted and AFAICR the user got )CLEAR WS.

 That's probably not exactly correct (I never read the actual assembly
 code for that part of the interpreter).
 But the idea worked for us.

 On a single user system there is no real need for a specific quantum;
 the OS takes care of  scheduling.
 But perhaps a "panic int" concept in some form or other might be useful?
 Perhaps allowing the user to decide if they want to continue?
 Perhaps with a default value? Perhaps assignable by the user?

 respect…

 Peter

 On 2014-07-08, at 1:50 PM, Blake McBride  wrote:

 > If I do:
 >
 >   z←⍳100
 >
 > the operation is very fast.  But if I do:
 >
 >   ⍳100
 >
 > it is very slow, presumably because it is formatting the whole thing
 for display.  No problem.
 >
 > The problem is that during its effort to format for display, I cannot
 use ^C.  ^C appears to work fine in normal situations - but not during the
 format for display time.  During format-for-display time ^C is ignored.
 >
 > This caused me a problem when I accidentally mis-typed something.
  The mis-type caused something very large to be displayed.  In fact, it was
 so large that my machine started paging.  I was unable to use ^C to stop
 it.  After waiting an hour, I had to kill the process and loose my work.
 >
 > Thanks.
 >
 > Blake
 >



>>>
>>
>

Re: [Bug-apl] Filter fns with ⍙ (delta-underbar) in the name by default?

[Blake McBride]

I really don't like that.  Using delta-underscore to signify internal names
is just a personal convention.  I wouldn't want to have personal
conventions become language standards.

Thanks.

Blake



On Wed, Jul 9, 2014 at 10:12 AM, Elias Mårtenson  wrote:

> How about having the )FNS, )OPS and )VARS commands filter out names that
> contain a ⍙ symbol by default? Since the idea is that those are internal
> names it would make sense to hide them (unless some other flag is given).
>
> Opinions?
>
> Regards,
> Elias
>

Re: [Bug-apl] ISO Component File API preview

[Blake McBride]

Greetings,

PostgreSQL is very important to, at least, me.  I do a lot of production
work in PostgreSQL.  I like SQLite too, but I would only use it when the
data didn't relate to anything but APL.  Here is what I propose.  Since
your component file system rides on top of SQL, and the standard doesn't
know or care about anything below the APL level, we should add a function
that allows the user to specify the database information (dbname, user,
password, etc.).  That call would be made as sort of a setup step.  Once
that setup step is specified, all of the standard API should work as
described.

This will give us a totally standard API.  If someone wants to switch to
GNU APL, all they have to do is add one function to specify the database.
 Not too much to ask.

We kind of have to do this.  Even with SQLite, you still have to specify
the database name (I presume one database contains many component files).

Thanks.

Blake



On Wed, Jul 9, 2014 at 9:44 PM, David B. Lamkins  wrote:

> I'm certainly willing to consider alternatives. IIUC, lib_sql also
> supports PostgreSQL. Anything else?
>
> How do I tell lib_sql to use a PostgreSQL server?
>
> The argument in favor of SQLite, of course, is that it's serverless. No
> additional setup (beyond the installation of the library) required.
>
> Would there be any additional benefits or concerns when connecting to a
> PostgreSQL server?
>
> As you've no doubt noticed, there's nothing in the code (or in the
> standard API) to acknowledge or support the notion of multiple users.
> Again: point in favor of SQLite...
>
>
> On Thu, 2014-07-10 at 10:25 +0800, Elias Mårtenson wrote:
> > I was looking at your code, and I noticed that it's SQLite-specific.
> > WOuldn't it make sense to make it SQL-implementation-agnostic?
> >
> >
> > Based on what I can see, the only SQLite-specific SQL you have in
> > there is "replace into" which I had never heard about before.
> >
> >
> > Regards,
> > Elias
> >
> >
> > On 9 July 2014 01:22, David Lamkins  wrote:
> > I haven't yet written test scripts, but I've informally tested
> > all of the functions and am reasonably confident that the
> > component file API is complete and correct.
> >
> >
> > If you'd like to try out the API while I'm working on scripted
> > test cases, the repo is:
> >
> > https://github.com/TieDyedDevil/iso-apl-cf
> >
> >
> > You'll find documentation is in the comments and in Annex A of
> > the ISO 13751 standard.
> >
> >
> > The standard "specifies a minimal set of functions which a
> > conforming implementation must provide"; I've implemented all
> > of these. I've also added several useful functions not
> > mentioned in the standard, including component inquiry,
> > component drop, and transaction support.
> >
> >
> >
> > Note that the code is not packaged for my package manager; I
> > assume that the component file implementation would become an
> > L3 library in the event it's adopted for inclusion in GNU APL.
> >
> >
> > Júergen, I've specified the GPLv3 license since that's what
> > GNU APL uses. If there's a more appropriate choice of license
> > for this library, please let me know.
> >
> > --
> > "The secret to creativity is knowing how to hide your
> > sources."
> >Albert Einstein
> >
> >
> > http://soundcloud.com/davidlamkins
> > http://reverbnation.com/lamkins
> > http://reverbnation.com/lcw
> > http://lamkins-guitar.com/
> > http://lamkins.net/
> > http://successful-lisp.com/
> >
> >
>
>
>
>

Re: [Bug-apl] ISO Component File API preview

[Elias Mårtenson]

Yes, that's how I work too. My home server contains a Postgres instance
that I use for pretty much everything. It's quite convenient.

Regards,
Elias


On 10 July 2014 12:53, Blake McBride  wrote:

> Greetings,
>
> PostgreSQL is very important to, at least, me.  I do a lot of production
> work in PostgreSQL.  I like SQLite too, but I would only use it when the
> data didn't relate to anything but APL.  Here is what I propose.  Since
> your component file system rides on top of SQL, and the standard doesn't
> know or care about anything below the APL level, we should add a function
> that allows the user to specify the database information (dbname, user,
> password, etc.).  That call would be made as sort of a setup step.  Once
> that setup step is specified, all of the standard API should work as
> described.
>
> This will give us a totally standard API.  If someone wants to switch to
> GNU APL, all they have to do is add one function to specify the database.
>  Not too much to ask.
>
> We kind of have to do this.  Even with SQLite, you still have to specify
> the database name (I presume one database contains many component files).
>
> Thanks.
>
> Blake
>
>
>
> On Wed, Jul 9, 2014 at 9:44 PM, David B. Lamkins 
> wrote:
>
>> I'm certainly willing to consider alternatives. IIUC, lib_sql also
>> supports PostgreSQL. Anything else?
>>
>> How do I tell lib_sql to use a PostgreSQL server?
>>
>> The argument in favor of SQLite, of course, is that it's serverless. No
>> additional setup (beyond the installation of the library) required.
>>
>> Would there be any additional benefits or concerns when connecting to a
>> PostgreSQL server?
>>
>> As you've no doubt noticed, there's nothing in the code (or in the
>> standard API) to acknowledge or support the notion of multiple users.
>> Again: point in favor of SQLite...
>>
>>
>> On Thu, 2014-07-10 at 10:25 +0800, Elias Mårtenson wrote:
>> > I was looking at your code, and I noticed that it's SQLite-specific.
>> > WOuldn't it make sense to make it SQL-implementation-agnostic?
>> >
>> >
>> > Based on what I can see, the only SQLite-specific SQL you have in
>> > there is "replace into" which I had never heard about before.
>> >
>> >
>> > Regards,
>> > Elias
>> >
>> >
>> > On 9 July 2014 01:22, David Lamkins  wrote:
>> > I haven't yet written test scripts, but I've informally tested
>> > all of the functions and am reasonably confident that the
>> > component file API is complete and correct.
>> >
>> >
>> > If you'd like to try out the API while I'm working on scripted
>> > test cases, the repo is:
>> >
>> > https://github.com/TieDyedDevil/iso-apl-cf
>> >
>> >
>> > You'll find documentation is in the comments and in Annex A of
>> > the ISO 13751 standard.
>> >
>> >
>> > The standard "specifies a minimal set of functions which a
>> > conforming implementation must provide"; I've implemented all
>> > of these. I've also added several useful functions not
>> > mentioned in the standard, including component inquiry,
>> > component drop, and transaction support.
>> >
>> >
>> >
>> > Note that the code is not packaged for my package manager; I
>> > assume that the component file implementation would become an
>> > L3 library in the event it's adopted for inclusion in GNU APL.
>> >
>> >
>> > Júergen, I've specified the GPLv3 license since that's what
>> > GNU APL uses. If there's a more appropriate choice of license
>> > for this library, please let me know.
>> >
>> > --
>> > "The secret to creativity is knowing how to hide your
>> > sources."
>> >Albert Einstein
>> >
>> >
>> > http://soundcloud.com/davidlamkins
>> > http://reverbnation.com/lamkins
>> > http://reverbnation.com/lcw
>> > http://lamkins-guitar.com/
>> > http://lamkins.net/
>> > http://successful-lisp.com/
>> >
>> >
>>
>>
>>
>>
>

Re: [Bug-apl] Extension proposal: ⍵⍵ to access outer lambda

[Elias Mårtenson]

I know, and that what I ended up doing. No having to do that at all is,
however, nicer of course.

But, I agree it's not a *necessary* feature.

Regards,
Elias


On 9 July 2014 22:14, Juergen Sauermann 
wrote:

>  Hi,
>
> actually - no. I called it OUTER_OMEGA to make clear what it does.
> Maybe you like
>
>
>
> *  { ⍵ + {⍵×WW} 10 ⊣ WW←⍵ } 100 1100 *
> imore?
>
>
>
> On 07/09/2014 04:08 PM, Elias Mårtenson wrote:
>
> I know, but it's much more ugly than my proposal, don't you think?
>
>  Regards,
> Elias
>
>
> On 9 July 2014 22:06, Juergen Sauermann 
> wrote:
>
>>  Hi Elias,
>>
>> that would be very easy to implement:
>>
>>
>>
>> *  { ⍵ + { ⍵ × OUTER_OMEGA } 10 ⊣ OUTER_OMEGA←⍵ } 100 1100 *
>> /// Jürgen
>>
>>
>>
>> On 07/09/2014 10:53 AM, Elias Mårtenson wrote:
>>
>> It would be nice to be able to access the values of ⍵ and ⍺ (and I
>> suppose χ) from the outer lambda from a nested lambda.
>>
>>  I.e, I'd like to following to return the value 1100:
>>
>>  *  { ⍵ + {⍵×⍵⍵} 10 } 100*
>>
>>  In other words, the ⍵⍵ in the inner lambda would refer to the value 100
>> (i.e. the value of ⍵ in the outer lambda).
>>
>>  Would this be easy to implement?
>>
>>  Regards,
>> Elias
>>
>>
>>
>
>

Re: [Bug-apl] ISO Component File API preview

[David B. Lamkins]

Well, it seems simple enough, but I have zero experience with PostgreSQL
and it's going to take me a while to ramp up...

Therefore: Please apply the attached experimental patch and see whether
you can get something working.

Here's the gist of the change as implemented in this patch:

CF_OPEN takes either a file name (no path separator; .cf extension) or a
PostgreSQL URI. In the former case, you get a SQLite database file with
the given name. In the latter case, lib_sql passes the URI through to
the PostgreSQL server.

Once you have a database handle (and - in the case of the PostgreSQL
connection, I'd guess - a properly configured database) then everything
else should work exactly the same. (Or maybe not... While proofreading
this message, I realized that I depend upon SQLite's implict oid
support; this may not be the same on PostgreSQL. But that's a small
matter of either making a table definition that'll work in both cases,
or creating a separate case for each SQL variant.)

Elias, INSERT INTO should be valid in both SQLite and PostgreSQL. At
least, that's what my quick search of the documentation suggests.

Of course, the ISO component file APIs that are tied to *files* won't do
anything useful for a PostgreSQL connection. This includes CF_ERASE,
CF_RENAME and CF_CREATE; the first two for the obvious reasons and the
last because (for now, until I figure out or someone tells me otherwise)
I'm assuming that the PostgreSQL database passed to CF_OPEN will have
been created by a database administrator. If we can prove basic
operation, I'll take care of making the the file APIs do something
reasonable (probably just signal a domain error) when passed a
PostgreSQL URI.

The alternate (non-URI) form of PostgreSQL connection string is not
presently recognized. It may be tricky to distinguish between a
poorly-formed file name and a properly-formed non-URI connection string.

Guys: I'm willing to pursue this, but don't yet have the PostgreSQL
knowledge to enable me to proceed. If you want to provide patches,
that'd be great. If you're willing to talk me through setting up
PostgreSQL (It's installed; I just haven't figured out how to create
roles and databases yet...) that'd be even better.

I'll mention in passing that this seems like a bit of an abuse of the
component *file* concept since there's no readily-accessible (to the
application programmer, anyhow) file in the case of the PostgreSQL
database. 

On the other hand, the ability to host a component file abstraction on a
database server seems like an interesting and possibly useful
"conforming extension". I imagine that this could be a relatively easy
way to implement multiuser access, as well. (I'm assuming that
PostgreSQL handles multiple clients and can do The Right Thing w.r.t.
locking.) 

Let's see where this goes. I'm looking forward to your feedback and
help...


On Thu, 2014-07-10 at 12:56 +0800, Elias Mårtenson wrote:
> Yes, that's how I work too. My home server contains a Postgres
> instance that I use for pretty much everything. It's quite convenient.
> 
> 
> Regards,
> Elias
> 
> 
> On 10 July 2014 12:53, Blake McBride  wrote:
> Greetings,
> 
> 
> PostgreSQL is very important to, at least, me.  I do a lot of
> production work in PostgreSQL.  I like SQLite too, but I would
> only use it when the data didn't relate to anything but APL.
>  Here is what I propose.  Since your component file system
> rides on top of SQL, and the standard doesn't know or care
> about anything below the APL level, we should add a function
> that allows the user to specify the database information
> (dbname, user, password, etc.).  That call would be made as
> sort of a setup step.  Once that setup step is specified, all
> of the standard API should work as described.
> 
> 
> This will give us a totally standard API.  If someone wants to
> switch to GNU APL, all they have to do is add one function to
> specify the database.  Not too much to ask.
> 
> 
> We kind of have to do this.  Even with SQLite, you still have
> to specify the database name (I presume one database contains
> many component files).
> 
> 
> Thanks.
> 
> 
> Blake
> 
> 
> 
> 
> On Wed, Jul 9, 2014 at 9:44 PM, David B. Lamkins
>  wrote:
> I'm certainly willing to consider alternatives. IIUC,
> lib_sql also
> supports PostgreSQL. Anything else?
> 
> How do I tell lib_sql to use a PostgreSQL server?
> 
> The argument in favor of SQLite, of course, is that
> it's serverless. No
> additional setup (beyond the installation of the
> library) required.
> 
>   

Re: [Bug-apl] ISO Component File API preview

[Elias Mårtenson]

Thank you for looking into this.

Since the SQL API is database-agnostic, it would make sense to make your
library the same. Instead of trying to make sense of the file
specification, why don't you just pass it along to the SQL API? In other
words, just pass the database type (currently only "sqlite" or
"postgresql", but who knows what other databases we might want to support
in the future?) and the connect parameters to the SQL library without
looking at them?

Or, even easier, you might not want to call SQL∆Connect at all, and simply
accept an already-opened database handle?

As for the "files" concept, wouldn't it make more sense to allow multiple
files in a single database. The files index would then be stored in a
separate table, which would be linked to a column in the datastore. Listing
the files would then be a simple SELECT from the file-list-table.

Regards,
Elias


On 10 July 2014 13:30, David B. Lamkins  wrote:

> Well, it seems simple enough, but I have zero experience with PostgreSQL
> and it's going to take me a while to ramp up...
>
> Therefore: Please apply the attached experimental patch and see whether
> you can get something working.
>
> Here's the gist of the change as implemented in this patch:
>
> CF_OPEN takes either a file name (no path separator; .cf extension) or a
> PostgreSQL URI. In the former case, you get a SQLite database file with
> the given name. In the latter case, lib_sql passes the URI through to
> the PostgreSQL server.
>
> Once you have a database handle (and - in the case of the PostgreSQL
> connection, I'd guess - a properly configured database) then everything
> else should work exactly the same. (Or maybe not... While proofreading
> this message, I realized that I depend upon SQLite's implict oid
> support; this may not be the same on PostgreSQL. But that's a small
> matter of either making a table definition that'll work in both cases,
> or creating a separate case for each SQL variant.)
>
> Elias, INSERT INTO should be valid in both SQLite and PostgreSQL. At
> least, that's what my quick search of the documentation suggests.
>
> Of course, the ISO component file APIs that are tied to *files* won't do
> anything useful for a PostgreSQL connection. This includes CF_ERASE,
> CF_RENAME and CF_CREATE; the first two for the obvious reasons and the
> last because (for now, until I figure out or someone tells me otherwise)
> I'm assuming that the PostgreSQL database passed to CF_OPEN will have
> been created by a database administrator. If we can prove basic
> operation, I'll take care of making the the file APIs do something
> reasonable (probably just signal a domain error) when passed a
> PostgreSQL URI.
>
> The alternate (non-URI) form of PostgreSQL connection string is not
> presently recognized. It may be tricky to distinguish between a
> poorly-formed file name and a properly-formed non-URI connection string.
>
> Guys: I'm willing to pursue this, but don't yet have the PostgreSQL
> knowledge to enable me to proceed. If you want to provide patches,
> that'd be great. If you're willing to talk me through setting up
> PostgreSQL (It's installed; I just haven't figured out how to create
> roles and databases yet...) that'd be even better.
>
> I'll mention in passing that this seems like a bit of an abuse of the
> component *file* concept since there's no readily-accessible (to the
> application programmer, anyhow) file in the case of the PostgreSQL
> database.
>
> On the other hand, the ability to host a component file abstraction on a
> database server seems like an interesting and possibly useful
> "conforming extension". I imagine that this could be a relatively easy
> way to implement multiuser access, as well. (I'm assuming that
> PostgreSQL handles multiple clients and can do The Right Thing w.r.t.
> locking.)
>
> Let's see where this goes. I'm looking forward to your feedback and
> help...
>
>
> On Thu, 2014-07-10 at 12:56 +0800, Elias Mårtenson wrote:
> > Yes, that's how I work too. My home server contains a Postgres
> > instance that I use for pretty much everything. It's quite convenient.
> >
> >
> > Regards,
> > Elias
> >
> >
> > On 10 July 2014 12:53, Blake McBride  wrote:
> > Greetings,
> >
> >
> > PostgreSQL is very important to, at least, me.  I do a lot of
> > production work in PostgreSQL.  I like SQLite too, but I would
> > only use it when the data didn't relate to anything but APL.
> >  Here is what I propose.  Since your component file system
> > rides on top of SQL, and the standard doesn't know or care
> > about anything below the APL level, we should add a function
> > that allows the user to specify the database information
> > (dbname, user, password, etc.).  That call would be made as
> > sort of a setup step.  Once that setup step is specified, all
> > of the standard API should work as described.
> >
> >
> > This will give us a totally standa

Re: [Bug-apl] ISO Component File API preview

[Elias Mårtenson]

Oh, and one more thing:

There is unfortunately no standard for getting the id of autoincrement
columns. For maximum flexibility, I'd suggest the standard approach of
having a separate table holding the "next" ID. Such table is usually
designed as a two-column "next_id" table, where one column holds the object
type (or table name) and the other column holds the next id.

Regards,
Elias


On 10 July 2014 13:38, Elias Mårtenson  wrote:

> Thank you for looking into this.
>
> Since the SQL API is database-agnostic, it would make sense to make your
> library the same. Instead of trying to make sense of the file
> specification, why don't you just pass it along to the SQL API? In other
> words, just pass the database type (currently only "sqlite" or
> "postgresql", but who knows what other databases we might want to support
> in the future?) and the connect parameters to the SQL library without
> looking at them?
>
> Or, even easier, you might not want to call SQL∆Connect at all, and simply
> accept an already-opened database handle?
>
> As for the "files" concept, wouldn't it make more sense to allow multiple
> files in a single database. The files index would then be stored in a
> separate table, which would be linked to a column in the datastore. Listing
> the files would then be a simple SELECT from the file-list-table.
>
> Regards,
> Elias
>
>
> On 10 July 2014 13:30, David B. Lamkins  wrote:
>
>> Well, it seems simple enough, but I have zero experience with PostgreSQL
>> and it's going to take me a while to ramp up...
>>
>> Therefore: Please apply the attached experimental patch and see whether
>> you can get something working.
>>
>> Here's the gist of the change as implemented in this patch:
>>
>> CF_OPEN takes either a file name (no path separator; .cf extension) or a
>> PostgreSQL URI. In the former case, you get a SQLite database file with
>> the given name. In the latter case, lib_sql passes the URI through to
>> the PostgreSQL server.
>>
>> Once you have a database handle (and - in the case of the PostgreSQL
>> connection, I'd guess - a properly configured database) then everything
>> else should work exactly the same. (Or maybe not... While proofreading
>> this message, I realized that I depend upon SQLite's implict oid
>> support; this may not be the same on PostgreSQL. But that's a small
>> matter of either making a table definition that'll work in both cases,
>> or creating a separate case for each SQL variant.)
>>
>> Elias, INSERT INTO should be valid in both SQLite and PostgreSQL. At
>> least, that's what my quick search of the documentation suggests.
>>
>> Of course, the ISO component file APIs that are tied to *files* won't do
>> anything useful for a PostgreSQL connection. This includes CF_ERASE,
>> CF_RENAME and CF_CREATE; the first two for the obvious reasons and the
>> last because (for now, until I figure out or someone tells me otherwise)
>> I'm assuming that the PostgreSQL database passed to CF_OPEN will have
>> been created by a database administrator. If we can prove basic
>> operation, I'll take care of making the the file APIs do something
>> reasonable (probably just signal a domain error) when passed a
>> PostgreSQL URI.
>>
>> The alternate (non-URI) form of PostgreSQL connection string is not
>> presently recognized. It may be tricky to distinguish between a
>> poorly-formed file name and a properly-formed non-URI connection string.
>>
>> Guys: I'm willing to pursue this, but don't yet have the PostgreSQL
>> knowledge to enable me to proceed. If you want to provide patches,
>> that'd be great. If you're willing to talk me through setting up
>> PostgreSQL (It's installed; I just haven't figured out how to create
>> roles and databases yet...) that'd be even better.
>>
>> I'll mention in passing that this seems like a bit of an abuse of the
>> component *file* concept since there's no readily-accessible (to the
>> application programmer, anyhow) file in the case of the PostgreSQL
>> database.
>>
>> On the other hand, the ability to host a component file abstraction on a
>> database server seems like an interesting and possibly useful
>> "conforming extension". I imagine that this could be a relatively easy
>> way to implement multiuser access, as well. (I'm assuming that
>> PostgreSQL handles multiple clients and can do The Right Thing w.r.t.
>> locking.)
>>
>> Let's see where this goes. I'm looking forward to your feedback and
>> help...
>>
>>
>> On Thu, 2014-07-10 at 12:56 +0800, Elias Mårtenson wrote:
>> > Yes, that's how I work too. My home server contains a Postgres
>> > instance that I use for pretty much everything. It's quite convenient.
>> >
>> >
>> > Regards,
>> > Elias
>> >
>> >
>> > On 10 July 2014 12:53, Blake McBride  wrote:
>> > Greetings,
>> >
>> >
>> > PostgreSQL is very important to, at least, me.  I do a lot of
>> > production work in PostgreSQL.  I like SQLite too, but I would
>> > only use it when the data didn't relate to anyt

Re: [Bug-apl] Can't break out of the middle on a display operation

[Juergen Sauermann]

Hi,

not so. I implemented ⎕SYL[⎕IO+26;] for that case. Just try:

*  ⎕SYL[⎕IO+26]←2000
  ⍳100
  ...*

/// Jürgen


On 07/09/2014 05:11 AM, Elias Mårtenson wrote:
Yeah, and neither would Jürgen. Seems like I was in the minority on 
that one. :-)


Regards,
Elias


On 9 July 2014 11:10, Blake McBride > wrote:


I wouldn't do that!



On Tue, Jul 8, 2014 at 10:01 PM, Elias Mårtenson
mailto:loke...@gmail.com>> wrote:

I suggested some time ago that very large data sets shouldn't
be displayed at all, since they are not only slow, they are
also largely useless in an interactive session.

It was decided that this approach would not be taken, but I
don't remember the justification for it.

Regards,
Elias


On 9 July 2014 10:58, Blake McBride mailto:blake1...@gmail.com>> wrote:

I think the layout function need two modifications:

1.  enable ^C

2.  at least for large data, output as you go rather than
format the whole thing and then output the whole thing

--blake



On Tue, Jul 8, 2014 at 9:27 PM, Elias Mårtenson
mailto:loke...@gmail.com>> wrote:

There is already the SIGINT signal which is processed
by GNU APL to interrupt a function execution. However,
this interruptability is not extended to the layout
function.


On 9 July 2014 09:09, Peter Teeson
mailto:peter.tee...@icloud.com>> wrote:

In Sharp APL (IPSA) we had a "panic int" which
interrupted whatever was being computed after a
predetermined time.
It was inherent to the interpreter because we ran
a timesharing system.
I don't recall the exact details but it went
something like this;

1) Workspace gets swapped in for execution and is
given a quantum of CPU time
2) At the end of that quantum a second but quite
small (relative to the normal ) additional amount
of CPU was allocated
 to see if that would allow an interrupt at a
"suitable" point in the function/operation that
was going on.
3) If that extra time was not sufficient the
workspace was arbitrarily interrupted and AFAICR
the user got )CLEAR WS.

That's probably not exactly correct (I never read
the actual assembly code for that part of the
interpreter).
But the idea worked for us.

On a single user system there is no real need for
a specific quantum; the OS takes care of  scheduling.
But perhaps a "panic int" concept in some form or
other might be useful?
Perhaps allowing the user to decide if they want
to continue?
Perhaps with a default value? Perhaps assignable
by the user?

respect…

Peter

On 2014-07-08, at 1:50 PM, Blake McBride
mailto:blake1...@gmail.com>>
wrote:

> If I do:
>
> z←⍳100
>
> the operation is very fast.  But if I do:
>
> ⍳100
>
> it is very slow, presumably because it is
formatting the whole thing for display.  No problem.
>
> The problem is that during its effort to format
for display, I cannot use ^C.  ^C appears to work
fine in normal situations - but not during the
format for display time.  During
format-for-display time ^C is ignored.
>
> This caused me a problem when I accidentally
mis-typed something.  The mis-type caused
something very large to be displayed.  In fact, it
was so large that my machine started paging.  I
was unable to use ^C to stop it.  After waiting an
hour, I had to kill the process and loose my work.
>
> Thanks.
>
> Blake
>

Re: [Bug-apl] ISO Component File API preview

[David Lamkins]

That has always been part of the design. See the "max. component #" table.
On Jul 9, 2014 10:40 PM, "Elias Mårtenson"  wrote:

> Oh, and one more thing:
>
> There is unfortunately no standard for getting the id of autoincrement
> columns. For maximum flexibility, I'd suggest the standard approach of
> having a separate table holding the "next" ID. Such table is usually
> designed as a two-column "next_id" table, where one column holds the object
> type (or table name) and the other column holds the next id.
>
> Regards,
> Elias
>
>
> On 10 July 2014 13:38, Elias Mårtenson  wrote:
>
>> Thank you for looking into this.
>>
>> Since the SQL API is database-agnostic, it would make sense to make your
>> library the same. Instead of trying to make sense of the file
>> specification, why don't you just pass it along to the SQL API? In other
>> words, just pass the database type (currently only "sqlite" or
>> "postgresql", but who knows what other databases we might want to support
>> in the future?) and the connect parameters to the SQL library without
>> looking at them?
>>
>> Or, even easier, you might not want to call SQL∆Connect at all, and
>> simply accept an already-opened database handle?
>>
>> As for the "files" concept, wouldn't it make more sense to allow multiple
>> files in a single database. The files index would then be stored in a
>> separate table, which would be linked to a column in the datastore. Listing
>> the files would then be a simple SELECT from the file-list-table.
>>
>> Regards,
>> Elias
>>
>>
>> On 10 July 2014 13:30, David B. Lamkins  wrote:
>>
>>> Well, it seems simple enough, but I have zero experience with PostgreSQL
>>> and it's going to take me a while to ramp up...
>>>
>>> Therefore: Please apply the attached experimental patch and see whether
>>> you can get something working.
>>>
>>> Here's the gist of the change as implemented in this patch:
>>>
>>> CF_OPEN takes either a file name (no path separator; .cf extension) or a
>>> PostgreSQL URI. In the former case, you get a SQLite database file with
>>> the given name. In the latter case, lib_sql passes the URI through to
>>> the PostgreSQL server.
>>>
>>> Once you have a database handle (and - in the case of the PostgreSQL
>>> connection, I'd guess - a properly configured database) then everything
>>> else should work exactly the same. (Or maybe not... While proofreading
>>> this message, I realized that I depend upon SQLite's implict oid
>>> support; this may not be the same on PostgreSQL. But that's a small
>>> matter of either making a table definition that'll work in both cases,
>>> or creating a separate case for each SQL variant.)
>>>
>>> Elias, INSERT INTO should be valid in both SQLite and PostgreSQL. At
>>> least, that's what my quick search of the documentation suggests.
>>>
>>> Of course, the ISO component file APIs that are tied to *files* won't do
>>> anything useful for a PostgreSQL connection. This includes CF_ERASE,
>>> CF_RENAME and CF_CREATE; the first two for the obvious reasons and the
>>> last because (for now, until I figure out or someone tells me otherwise)
>>> I'm assuming that the PostgreSQL database passed to CF_OPEN will have
>>> been created by a database administrator. If we can prove basic
>>> operation, I'll take care of making the the file APIs do something
>>> reasonable (probably just signal a domain error) when passed a
>>> PostgreSQL URI.
>>>
>>> The alternate (non-URI) form of PostgreSQL connection string is not
>>> presently recognized. It may be tricky to distinguish between a
>>> poorly-formed file name and a properly-formed non-URI connection string.
>>>
>>> Guys: I'm willing to pursue this, but don't yet have the PostgreSQL
>>> knowledge to enable me to proceed. If you want to provide patches,
>>> that'd be great. If you're willing to talk me through setting up
>>> PostgreSQL (It's installed; I just haven't figured out how to create
>>> roles and databases yet...) that'd be even better.
>>>
>>> I'll mention in passing that this seems like a bit of an abuse of the
>>> component *file* concept since there's no readily-accessible (to the
>>> application programmer, anyhow) file in the case of the PostgreSQL
>>> database.
>>>
>>> On the other hand, the ability to host a component file abstraction on a
>>> database server seems like an interesting and possibly useful
>>> "conforming extension". I imagine that this could be a relatively easy
>>> way to implement multiuser access, as well. (I'm assuming that
>>> PostgreSQL handles multiple clients and can do The Right Thing w.r.t.
>>> locking.)
>>>
>>> Let's see where this goes. I'm looking forward to your feedback and
>>> help...
>>>
>>>
>>> On Thu, 2014-07-10 at 12:56 +0800, Elias Mårtenson wrote:
>>> > Yes, that's how I work too. My home server contains a Postgres
>>> > instance that I use for pretty much everything. It's quite convenient.
>>> >
>>> >
>>> > Regards,
>>> > Elias
>>> >
>>> >
>>> > On 10 July 2014 12:53, Blake McBride  wrote:
>