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 < [email protected]> 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 < > [email protected]> 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 < >> [email protected]> 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 <[email protected]> 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 >>>> >>>> >> >> > >
