I would classify that as possible, but maybe not in the way that you are envisioning.
(1) There's a header that J's array mechanism would need in front of that string (in older versions of J -- the newer versions support aliasing into arrays, but require a J array to alias -- I haven't studied enough to see if there's any way to weasel out of that issue, but if there is it would obviously have version dependencies), and (2) The details of the implementation would be version dependent and would have to be approached from the C side in any current version of J (because the relevant data structures are not exposed to the J environment). But the primitives are necessarily supported, on the C side (since J is implemented in C). I am guessing that you have some context where you have some other codebase doing memory allocation and you think it would be worthwhile manipulating that memory directly from J but also feel that the overhead of creating a fresh copy is too high? It's probably worth noting here that most J operations make copies of memory during their operation (except in carefully restricted cases). -- Raul On Tue, Dec 8, 2020 at 11:24 AM emacstheviking <[email protected]> wrote: > > Is it even possible then "introduce" a new managed (ie auto garbage > collected reference counted) string variable given some C pointer to a > string? > > > > On Tue, 8 Dec 2020 at 15:48, bill lam <[email protected]> wrote: > > > mema memf are exactly the same as malloc and free in c. > > > > memr involves memory copy, no alias. > > > > On Tue, Dec 8, 2020, 9:34 PM emacstheviking <[email protected]> wrote: > > > > > 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 > > > > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
