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
<juergen.sauerm...@t-online.de <mailto:juergen.sauerm...@t-online.de>>
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
<juergen.sauerm...@t-online.de
<mailto:juergen.sauerm...@t-online.de>> 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 <blake1...@gmail.com
<mailto:blake1...@gmail.com>> 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
