Thank you, Fred. Done as suggested.
The corrected and polished version of the utility is now on Github:
https://github.com/TieDyedDevil/apl-nlf
On Fri, 2014-07-11 at 22:56 -0500, Frederick H. Pitts wrote:
> Hello David,
>
> Thanks for the utility.
>
> May I suggest a minor tweak?
Hello David,
Thanks for the utility.
May I suggest a minor tweak?
' e: show names having any character not in set'
should read
' e: show names having only characters not in set'
The former implies
]nlf e ⍙
would list, for instance, ⍙class, because c,
Well... I'm done. Clearly we can't agree agree on either the concept of a
file or how a spec should be interpreted.
On Fri, Jul 11, 2014 at 2:08 PM, Blake McBride wrote:
> Although my implementation may not meet what you perceive to comply with
> their unwritten (hidden) intent, my implementati
Although my implementation may not meet what you perceive to comply with
their unwritten (hidden) intent, my implementation would meet their written
spec.
On Fri, Jul 11, 2014 at 3:36 PM, David Lamkins wrote:
> WIth all due respect, Blake, I understand and appreciate the differences
> between f
WIth all due respect, Blake, I understand and appreciate the differences
between filesystems and databases.
I've already said my piece regarding some of the benefits of using files
rather than a database; I won't reiterate.
To be clear: I have no objection to your creating this code. I object to
David - SQL offers many features that are very, very important in the real
world. Creating file systems on top of SQL that are compliant to start off
with, but have the potential to be augmented for real-world situations is
extremely valuable. For example, the way you implemented component files
That's what I thought you had planned to do.
My objection stands. A table in a database is not a file.
On Fri, Jul 11, 2014 at 11:56 AM, Blake McBride wrote:
> There would be an association between the name passed to CF_OPEN and an
> SQL table with that same name.
>
>
> On Fri, Jul 11, 2014 at
There would be an association between the name passed to CF_OPEN or
CF_CREATE and an SQL table with that same name.
On Fri, Jul 11, 2014 at 1:54 PM, David Lamkins wrote:
> If I understand your proposal (and I may not), my objection is that you
> don't intend to associate the name passed to CF_O
If I understand your proposal (and I may not), my objection is that you
don't intend to associate the name passed to CF_OPEN or CF_CREATE to a
like-named file in the host filesystem.
On Jul 11, 2014 11:40 AM, "Blake McBride" wrote:
> I don't understand. What I am proposing to create is something
I don't understand. What I am proposing to create is something that
conforms with the APL Annex standard. It will be implemented on top of
Elias' SQL interface. It will be implemented in a way that is also
cooperative with the design and intend of SQL (since that is what it rides
on). What part
Here's a more developed version of the utility functions I posted a few
days ago. I've added a ]usercmd wrapper.
⍝!
∇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
On Fri, Jul 11, 2014 at 9:58 AM, Blake McBride wrote:
> Does that sound agreeable to everyone?
>
>
>
Not at all. What you're proposing to create is not a component file
implementation.
--
"The secret to creativity is knowing how to hide your sources."
Albert Einstein
http://soundcloud.com/
On Fri, Jul 11, 2014 at 11:19 AM, David Lamkins wrote:
> On Fri, Jul 11, 2014 at 7:18 AM, Elias Mårtenson
> wrote:
>
>> On 11 July 2014 22:15, Blake McBride wrote:
>>
>>
>>> 2. I'm not sure if I fully understand the conclusion of David's last
>>> longish email. It sounded like he is abandonin
On Fri, Jul 11, 2014 at 7:18 AM, Elias Mårtenson wrote:
> On 11 July 2014 22:15, Blake McBride wrote:
>
>
>> 2. I'm not sure if I fully understand the conclusion of David's last
>> longish email. It sounded like he is abandoning the old code and moving
>> towards a GDBM solution. That sounds
On 11 July 2014 22:15, Blake McBride wrote:
1. It seems that GDBM is really a file manager and not a database. What I
> mean by that is that there is a one-to-one relationship between a Unix file
> and a GDBM file. You can't store multiple "files" in one Unix file like
> SQLite. If this is tr
Greetings,
A few things:
1. It seems that GDBM is really a file manager and not a database. What I
mean by that is that there is a one-to-one relationship between a Unix file
and a GDBM file. You can't store multiple "files" in one Unix file like
SQLite. If this is true, it is perfect in term
16 matches
Mail list logo
