Thanks a lot!
On Sun, Apr 20, 2014 at 9:22 AM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:
> Hi Blake,
>
> I have added a few more ⎕CR variants, see SVN 218.
> I added a chapter to apl.info describing them.
>
> You may like 14 ⎕CR and its inverse ¯14 ⎕CR:
>
>
>
>
>
>
>
>
> *
Hi Blake,
I have added a few more ⎕CR variants, see SVN 218.
I added a chapter to apl.info describing them.
You may like 14 ⎕CR and its inverse ¯14 ⎕CR:
* 14 ⎕CR 'Hello' 1 (2 3)
202000830701000320004000600020200020
00050401000548656c6
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 <
juergen.sa
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:
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 c
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)
I wouldn't use spaces or tabs either - very important if the database pads
the strings! Along similar lines, it would be nice if the quad function
that converts it back to an array ignores trailing spaces.
On Sat, Apr 19, 2014 at 9:55 AM, Blake McBride wrote:
> Blob support, in general, would
Blob support, in general, would be good, but I don't think it is a good
solution to this problem. I am thinking of converting all arrays to these
strings. I don't think databases are especially efficient if everything is
a blob. They handle strings much more efficiently. I think the best
soluti
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 wrote:
> Looks good. I am a little concerned tha
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
wo
Hi Blake,
I have added 11⎕CR for APL → CDR and 12⎕CR for CDR → APL conversions,
see SVN 217.
For example:
* 12 ⎕CR CDR←11 ⎕CR 'Hello' 1 (2 3)**
** Hello 1 2 3 **
** ⍴CDR**
**128*
/// Jürgen
On 04/19/2014 12:16 PM, Blake McBride wrote:
Greetings,
Now that the wonderful SQL int
Dear Jürgen,
Thank you for your response. Implementing 11⎕CR and 12⎕CR would be very
helpful.
I still need an answer to question 3 if you can.
Thanks!
Blake
On Sat, Apr 19, 2014 at 8:05 AM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:
> Hi Blake,
>
> 3 ⎕TF produces a byte vect
Hi Blake,
3 ⎕TF produces a byte vector in the CDR (common data representation)
format defined by IBM.
It was a by-product of the CDR format which is used internally in GNU
APL for communication
with shared variables and other running GNU APL workspaces. Right now
there is no inverse
function
Greetings,
Now that the wonderful SQL interface is working for me, I believe I can
create a component and keyed file system in straight APL easily. I just
need to understand ⎕TF a bit better.
1. 3 ⎕TF seems to produce a string vector representation of an arbitrary
nested array without retaining
14 matches
Mail list logo
