bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] Towards a keyed and component file system


From: Blake McBride
Subject: Re: [Bug-apl] Towards a keyed and component file system
Date: Sat, 19 Apr 2014 17:12:49 -0500

Dear Jürgen,

Thanks a lot!  I a little confused with all the ⎕CR and ⎕TF options.  Do you have a txt file that gives a brief overview?

Also, please let me know when you have it in, I'll get to work with it.

Thank so much!

Blake



On Sat, Apr 19, 2014 at 12:34 PM, Juergen Sauermann <address@hidden> wrote:
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







reply via email to

[Prev in Thread] Current Thread [Next in Thread]