|
From: | Blake McBride |
Subject: | Re: [Bug-apl] Towards a keyed and component file system |
Date: | Sat, 19 Apr 2014 17:12:49 -0500 |
Hi Blake,
I'll add an inverse for 5⎕CR / 6⎕CR. That should be pretty efficient for
byte strings used by 12 ⎕CR without needing ⍎ (which involves the
tokenizer).
/// Jürgen
On 04/19/2014 05:57 PM, Blake McBride wrote:
That't probably what I'll do. Thanks!
Blake
On Sat, Apr 19, 2014 at 10:40 AM, Juergen Sauermann <address@hidden> wrote:
Hi,
the problem is that there are so many different ways to solve this, each with its own
characteristics in performance and memory/disk space. We cannot implement them all.
There are many mappings from binary to ASCII such as base64 encoding (RFC 4648)
that can be efficiently implemented in APL.
/// Jürgen
On 04/19/2014 05:22 PM, Blake McBride wrote:
That may work, but I am always leery of SQL with anything but straight, printable ASCII. Plus, this has got to be a lot more CPU cycles. If you can't implement the conversion between printable ASCII and APL arrays, I can probably write some APL code that can translate between the strings you do create (with arbitrary character sequences) and a (longer) string with just printable ASCII (and no spaces). It would be unquestionably portable, but would be slower.
Thanks.
Blake
On Sat, Apr 19, 2014 at 10:07 AM, Juergen Sauermann <address@hidden> wrote:
Hi,
I guess 10 ⎕CR is better suitable for that because it uses a portable subset of Unicode for APL values.
I believe performance issues are a question of the past, so a little overhead is worth to be paid for
simplicity. 10⎕CR output can be decoded with ⍎¨ for example:
⎕←X←'Hello' 1 (2 3)
Hello 1 2 3
⎕←Y←10 ⎕CR 'X'
X←3⍴0 X[0+⍳3]←'∘',1, 0 ((⎕IO+0)⊃X)←5⍴'Hello' ((⎕IO+2)⊃X)←2⍴2,3
)ERASE X
0⍴ ⍎¨Y
X
Hello 1 2 3
/// Jürgen
On 04/19/2014 04:43 PM, Elias Mårtenson wrote:
You are right. The SQL implementation uses C strings behind the scenes for both SQLite and Postgres.
I'll be happy to implement BLOB support if you can suggest a good syntax for it from APL.
Regards,Elias
On 19 April 2014 22:34, Blake McBride <address@hidden> wrote:
Looks good. I am a little concerned that the vector produced by 3 ⎕TF may have trouble going to and from an SQL VARCHAR using the existing (and fantastic!) library. I am not sure, but there may be a problem with C null characters ('\0') or other non-printable characters. Some feedback on this would be very helpful.
Thanks!
Blake
[Prev in Thread] | Current Thread | [Next in Thread] |