Yes Henry I know about those.
I have a reasonable understanding of it but I lack the flying time in
general solving real issues with J.
I spent 45 minutes last night just absorbing the page on ranks, array,
k-cells and frames....it makes sense when you read it!
I am never going to get a job working with J unless I start my own start-up
I guess.
Thanks.
Sean
On Tue, 8 Dec 2020 at 19:36, Henry Rich <henryhr...@gmail.com> wrote:
> Do you know about NuVoc and the ancillary pages pointed to below the
> primitive table? There is a lot written about rank.
>
> Henry Rich
>
> On 12/8/2020 2:27 PM, emacstheviking wrote:
> > Hauke,
> > PERFECT!
> >
> > ,.psz &.> pqfname@(res&;)"0 i.ncols
> > ┌───────────────────┐
> > │id │
> > ├───────────────────┤
> > │invoice_id │
> > ├───────────────────┤
> > │created │
> > ├───────────────────┤
> > │status │
> > ├───────────────────┤
> > │ce_survey_id │
> > ├───────────────────┤
> > │organisation_id │
> > ├───────────────────┤
> > │payment_provider_id│
> > └───────────────────┘
> >
> > I just have to go through it step at a time until I fully understand the
> > magic! I have a vague understanding of rank and shape and that you can
> use
> > "0 "1 etc which affects the frame/k-cell metrics but could you explain
> what
> > it is doing here please?
> >
> > Thanks
> > Sean
> >
> >
> > On Tue, 8 Dec 2020 at 17:15, Hauke Rehr <hauke.r...@uni-jena.de> wrote:
> >
> >> Did I miss something or didn’t anyone answer the looping question yet?
> >>
> >> Without knowing much about what the names involved are doing,
> >> I think it ought to be
> >> pqfname@(res&;)"0 i. ncols
> >> which will have the shape
> >> (shape of i. ncols)×(shape of whatever pqfname res;0 returns)
> >>
> >> Am 08.12.20 um 14:34 schrieb emacstheviking:
> >>> Apologies for the length of this email but my brain has thrown one
> >> again...
> >>> I am currently working on a wrapper for Postgres using libpq-fe. It's
> >>> working but in need of some higher level functions to make result sets
> >>> easier to work with and feel more J-like.
> >>>
> >>> Once the query is executed, all results have been stored in RAM by the
> >>> library (not my first choice!) and then a value is obtained like so
> >>>
> >>> pqgetvalue result_set;row;col
> >>>
> >>> I've seen the source code for the library and the above translate
> >> directly
> >>> into an array read;
> >>>
> >>> char * PQgetvalue(const PGresult *res, int tup_num, int field_num)
> >>> {
> >>> if (!check_tuple_field_number(res, tup_num, field_num))
> >>> return NULL;
> >>> return res->tuples[tup_num][field_num].value;
> >>> }
> >>>
> >>>
> >>> *# mema and management.*
> >>>
> >>> My plan was to write a 'pgquery' verb that takes the connection handle
> >> and
> >>> a SQL query (details to be settled) and then creates and executes the
> >> query
> >>> and returns back a table of boxed strings. My first question then is
> how
> >> is
> >>> the memory managed? I know from the documentation that memf is the
> >> natural
> >>> (obverse?) way to release memory but I wanted to know what happens if I
> >>> allocate a string with mema then return it and assign it into a boxed
> >>> structure. I have an ffi helper I wrote, I call it psz:
> >>>
> >>> psz=: 3 : 'memr (>y),0,_1'
> >>>
> >>> If I assign the return value to a variable:
> >>>
> >>> name =. psz a-mem-address-of-a-C-String
> >>>
> >>> is the pointer aliased or can I now memf the original address and still
> >>> have a viable copy of the string later. I ask this because, for the
> >>> lifetime of the result set object, the internally allocated memory is
> >>> always around until a pqclear is executed. In this particular case I am
> >>> hopefully correct in thinking that my returned box list of strings is
> >>> stable up until that time.
> >>>
> >>> (In --this case-- I don't need to release anything as the library does
> it
> >>> but I wanted a general asnwer about what memr actually does)
> >>>
> >>> I am more interested in the general case of using 'memr' though; does
> it
> >>> allocate a copy or, as I suspect, is it merely re-typing the memory
> >> address
> >>> as a string, in the same manner that 'ic' can be used to process
> integers
> >>> and floats. Some insights would be appreciated.
> >>>
> >>>
> >>> *# looping*
> >>>
> >>> This brings me to how best to extract the data from the internal result
> >>> set? My basic flow so far is this:
> >>>
> >>> conn=. pqconnectdb<'dbname=foo'
> >>> res=.pqexec conn;'select * from some_table'
> >>> nrows=. pqtuples res
> >>> ncols=. pqfields res
> >>>
> >>> So I might have 7 rows and 12 columns per row. Obtaining the name of
> the
> >>> columns is done using the pqfname call. I've been playing around and
> the
> >>> basic loop I have is awful!
> >>>
> >>> pgtest =: 3 : 0
> >>> nrows=. pqntuples y
> >>> ncols=. pqnfields y
> >>> NB. get the column names as the first row
> >>> for_j. i. ncols do.
> >>> c =. pqfname y;j
> >>> smoutput psz c
> >>> end.
> >>> ''
> >>> )
> >>>
> >>> I know I can do this 'looplessly' but have so far failed. It's going to
> >> be
> >>> a combination of bonding and maybe a hook or something but as I say,
> >> total
> >>> quagmire at the moment! The thing I require to be looped is this:
> >>>
> >>> pqfname res;col. NB. where col is i. ncols
> >>>
> >>> My thought process was along the lines of, produce an array of res;i
> >> pairs
> >>> but that feels ugly, then I thought about and played with trying to
> just
> >>> pass the i. ncols list into a bonded call to ; but somehow got stuck...
> >>>
> >>> So..I am after some nice solutions to how best to iterate ncols to
> obtain
> >>> the initial row of column names and then extract each row of data from
> >> the
> >>> result set...I know this can be done very succinctly, I continue to
> work
> >> on
> >>> it...
> >>>
> >>> Loving the challenge of thinking so differently!
> >>>
> >>> Thanks all,
> >>> Sean
> >>> ----------------------------------------------------------------------
> >>> For information about J forums see http://www.jsoftware.com/forums.htm
> >>>
> >> --
> >> ----------------------
> >> mail written using NEO
> >> neo-layout.org
> >>
> >> ----------------------------------------------------------------------
> >> For information about J forums see http://www.jsoftware.com/forums.htm
> >>
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
>
>
> --
> This email has been checked for viruses by AVG.
> https://www.avg.com
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
