Hi Alex, While on this subject - is there any advice on speeding up the dev loop for app development? Right now, I kill pil and restart pil each time I make a change to the app. I suppose I could have my logic written in a separate .l file and have it be loaded in the main server file. Regards, Kashyap
On Mon, Sep 2, 2019 at 7:10 AM C K Kashyap <ckkash...@gmail.com> wrote: > For some reason, I cannot see Grant's messages in the thread in gmail. I > was able to read the message by visiting mail-archive. > > Thanks Grant for your updated sample ... I am in the process of GUIfying > the todo sample https://picolisp.com/wiki/?taskDB > > Regards, > Kashyap > > On Mon, Sep 2, 2019 at 2:14 AM Alexander Burger <a...@software-lab.de> > wrote: > >> Hi Grant, >> >> > > In general it is not recommended to keep DB objects in globals, as >> they cannot >> > > be garbage collected. >> > > >> > > ☺/ A!ex >> >> > In the `family.l` example it seems to store the "current person" object >> in the >> > `val` of *DB. Is this just for convenience for the sample? Or is this >> > different since the global symbol isn't a reference to the object >> itself? >> >> This is ok. With "globals" I meant global internal symbols. '*DB' holds an >> *external* symbol, i.e. '{1}', which is the root object of the database. >> >> So what "family.l" does with >> >> (set *DB (request '(+Man) ... >> >> is create a new '+Man' object and store it in '{1}' in the database. >> >> The global '*DB' is not changed here (and in fact never should be; it >> should >> always point to '{1}') and is known by the system - most notably by the >> garbage >> collector. >> >> >> > I assume the correct pattern for an action form is to use some global >> to hold >> > a reference to some indexable ID for the DB object we are interested in? >> >> This is possible, but typically nothing is kept globally, and the user is >> presented a search dialog ('choPerson' in "family.l"). >> >> Note that in fact the GUI *does* use a global '*ID' but this gets a new >> value >> with each form and thus does not inhibit the previous values to become >> garbage. >> >> Also, search dialogs typically keep searched values in globals ('*PrsNm', >> '*PrsJob', '*PrsDat1' etc.) to allow the user to search for similar >> things in >> the same context, but these values are strings, numbers, dates etc. and >> not DB >> objects. >> >> ☺/ A!ex >> >> -- >> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >> >
