Re: Trouble with a sample
Hi Beneroth, Sorry just to reply now, it was a hectic weeks for me.. but thanks for this explanation! I am also trying to learn PicoLisp as much as possible from these threads. I want to promote PicoLisp as much as I can, I am working on something right now and hopefully I can provide a positive feedback soon, cheers! BR,Geo On Wednesday, 4 September 2019, 12:42:06 am GMT+9, wrote: Hi Geo psh (located in the bin/ dir within picolisp/ dir) is "picolisp shell" (or process shell?), is a tool to get a REPL to a running picolisp app process. The implementation is a bit tricky, basically it does a HTTP request to the running app server (to initiate a session process), and then that process gets told to bind to a tty, so you get a REPL to the running application - a child process, same as normal application user sessions, not the master process. So with psh you can work on the live application, like just another user. Very useful for debugging or live patching. If it is really a productive system, you should be careful with database transactions, as the database is write-locked for all users until the transaction started with (dbSync) is finished with (commit 'upd) or canceled with (rollback). Better use the auto-transaction methods (the ones with the ! in the name) like (put!>). Best regards, beneroth On 03.09.19 16:30, George Orais wrote: Hi CK, Im also currently learning PicoLisp web dev and this thread is indeed informative. For your question I think Alex mentioned about psh? Im not so sure but I think I read somewhere about psh and its usage and this might be the answer. BR, geo
Re: Trouble with a sample
Hi beneroth, On Tue, Sep 03, 2019 at 05:35:02PM +0200, andr...@itship.ch wrote: > psh (located in the bin/ dir within picolisp/ > dir) is "picolisp shell" (or process shell?), > is a tool to get a REPL to a running picolisp > app process. > The implementation is a bit tricky, basically > it does a HTTP request to the running app > server (to initiate a session process), > and then that process gets told to bind to a > tty, so you get a REPL to the running > application - a child process, same as normal > application user sessions, not the master > process. > > So with psh you can work on the live application, like just another user. Correct. Let me note that in addition to what you described, i.e. starting a *new* session in a running server with $ bin/psh 8080 or $ bin/psh you can now also connect directly to an already *running* GUI session with $ bin/psh 52545 12899978148913174~ where "52545" is the port and "12899978148913174~" the session ID of that process. They are known because the (app) function prints them to stderr (to terminal during development and log file in production) in the form 19505 = 52545 12899978148913174~ where "19505" is the PID. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Trouble with a sample
Hi Kashyap 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. Yeah, using (load) is the right way. (load) is extremely fast. Greetings, beneroth -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Trouble with a sample
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 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
> 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
>>
>
Re: Trouble with a sample
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 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
>
Re: Trouble with a sample
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
Re: Trouble with a sample
I'm curious about this: > 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? 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? -grant shoshin -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Trouble with a sample
Hi Grant, > https://gist.github.com/gcentauri/cf28da3988ae2d53937ca69c79d3b1de > This moves the call to `pool` into the `main` initialization function, and > assumes we're just going to use a guestbook by the name "Fancy Guestbook". > This name is stored in a global *Gbk variable to use within our form, instead > of storing the DB object itself in a global. Great! This should have solved the discussed problems :) Thanks for sharing! ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Trouble with a sample
Hi CK, I played around with the example for a bit and think maybe with Alex's advice have gotten something working as you were expecting: https://gist.github.com/gcentauri/cf28da3988ae2d53937ca69c79d3b1de This moves the call to `pool` into the `main` initialization function, and assumes we're just going to use a guestbook by the name "Fancy Guestbook". This name is stored in a global *Gbk variable to use within our form, instead of storing the DB object itself in a global. I replaced the references to the *Gbk global db object with `(db 'nm '+Gbk "Fancy Guestbook")` to request that particular object within the form. The next step would be to replace the globals for holding the input data ( *MsgHdr ) with references to the gui components themselves. I tried doing that but kept getting something wrong when trying to reference the gui values themselves. Hope this helps! I'm still trying to learn myself, so this was eye opening for me as well. I feel like my bias from "traditional" web apps keeps me from fully understanding the PicoLisp way, and trying to bend it into a form I understand more intuitively. This guestbook example is very similar to what i've been trying to figure out. Regards, Grant Shoshin Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, August 30, 2019 11:10 AM, C K Kashyap wrote: > Thanks Alex .. yup, I've seen the demo app - I think that's the one you > showed in the one and only tutorial youtube video on PicoLisp :) > I think I'll try to familiarize with the Pilog queries a bit and then jump on > to my todo app. I did have a look at the wiki too - as a matter of fact, I > found someone who built his homepage using the wiki. > Regards, > Kashyap > > On Fri, Aug 30, 2019 at 7:47 AM Alexander Burger wrote: > >> On Fri, Aug 30, 2019 at 07:30:33AM -0700, C K Kashyap wrote: >>> Oh okay ... that makes sense I was planning to look at guest.l as a >>> sample to get started with app but I guess I will stick to the sample here >>> - https://picolisp.com/wiki/?mindbgui >> >> Yes, this is pretty minimalistic. If you dare to look at something bigger and >> more complex, you probably saw >> the "app" demo in the distribution, and the >> source of the picolisp wiki at https://software-lab.de/wiki.tgz >> >>> I'll have to lear Pilog also before that I think :) >> >> One step after the other :) >> >> ☺/ A!ex >> >> -- >> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Trouble with a sample
On Fri, Aug 30, 2019 at 07:30:33AM -0700, C K Kashyap wrote: > Oh okay ... that makes sense I was planning to look at guest.l as a > sample to get started with app but I guess I will stick to the sample here > - https://picolisp.com/wiki/?mindbgui Yes, this is pretty minimalistic. If you dare to look at something bigger and more complex, you probably saw the "app" demo in the distribution, and the source of the picolisp wiki at https://software-lab.de/wiki.tgz > I'll have to lear Pilog also before that I think :) One step after the other :) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Trouble with a sample
Oh okay ... that makes sense I was planning to look at guest.l as a sample to get started with app but I guess I will stick to the sample here - https://picolisp.com/wiki/?mindbgui I'll have to lear Pilog also before that I think :) My goal is to build a todo app - perhaps try write a GUI for https://picolisp.com/wiki/?taskDB Regards, Kashyap On Fri, Aug 30, 2019 at 7:23 AM Alexander Burger wrote: > On Fri, Aug 30, 2019 at 06:31:27AM -0700, C K Kashyap wrote: > > Could you also comment on the problem with step 8 please - I believe, its > > independent of the setup issue. > > > > 8. I open another browser tab and hit localhost:3000 and find that the > > record that I had entered does not show up - I believe it should have > > showed up. > > Hmm, OK, did not check this one. > > In fact, the whole issue with the global *Gbk is broken :( > > As we saw, it is created on top level in the program file, i.e. in the > parent > process. So child processes do inherit it, but changes are not > synchronized to > the parent, only to other siblings (as the reference of 'tell' states, > "Send ... > to all family members (i.e. all children of the current process, and all > other > children of the parent process"). So when a new session starts, it still > inherits the *old* state. > > In general it is not recommended to keep DB objects in globals, as they > cannot > be garbage collected. > > ☺/ A!ex > > > > > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Trouble with a sample
On Fri, Aug 30, 2019 at 06:31:27AM -0700, C K Kashyap wrote: > Could you also comment on the problem with step 8 please - I believe, its > independent of the setup issue. > > 8. I open another browser tab and hit localhost:3000 and find that the > record that I had entered does not show up - I believe it should have > showed up. Hmm, OK, did not check this one. In fact, the whole issue with the global *Gbk is broken :( As we saw, it is created on top level in the program file, i.e. in the parent process. So child processes do inherit it, but changes are not synchronized to the parent, only to other siblings (as the reference of 'tell' states, "Send ... to all family members (i.e. all children of the current process, and all other children of the parent process"). So when a new session starts, it still inherits the *old* state. In general it is not recommended to keep DB objects in globals, as they cannot be garbage collected. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Trouble with a sample
Thanks Alex, Could you also comment on the problem with step 8 please - I believe, its independent of the setup issue. 8. I open another browser tab and hit localhost:3000 and find that the record that I had entered does not show up - I believe it should have showed up. Regards, Kashyap On Fri, Aug 30, 2019 at 6:18 AM Alexander Burger wrote: > Hi Kashyap, > > > 1. Run the sample (attached) as follows - > > pil guest.l + > > : (setup) (go) (wait) > > 2. I hit localhost:3000 (since I have httpGate 3000 8080 running > > 3. I enter the details in the form and hit send followed by confirmation > > 4. I notice that I get -- addM -- Bad message > > I see. The problem is the *Gbk global. It is NIL if the file is loaded > the first time and 'setup' has not been called yet. > > "guest.l" first does > >(pool "gb.db") > >(setq >*Gbk (car (collect 'nm '+Gbk)) # decide which guestbook we'll serve > ) > > but the DB is still empty. > > It works if you do > >$ pil guest.l -setup -bye # Create the DB >$ pil guest.l -go + > or $ pil guest.l -go -wait > > > I would not do the 'pool' and the initialization of *Gbk on top of the > file, but > in a separate 'main' function (or here in 'go'): > >(de go () > (pool "gb.db") > (unless (seq *DB) > (new! '(+Gbk) 'nm "Your guestbook name here") ) > (setq *Gbk (car (collect 'nm '+Gbk) ) ) # decide which guestbook > we'll serve > (server 8080 "!work") ) > > Note that 'collect' is not wise here, as it collects the *whole* DB into a > list > just to get the first element :) > > > BTW, there is another minor glitch: The > >(commit 'upd) > > at the end of 'addM>' is superfluous, as both 'new!' and 'put!>' already > did an > implied commit. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Trouble with a sample
Hi Kashyap, > 1. Run the sample (attached) as follows - > pil guest.l + > : (setup) (go) (wait) > 2. I hit localhost:3000 (since I have httpGate 3000 8080 running > 3. I enter the details in the form and hit send followed by confirmation > 4. I notice that I get -- addM -- Bad message I see. The problem is the *Gbk global. It is NIL if the file is loaded the first time and 'setup' has not been called yet. "guest.l" first does (pool "gb.db") (setq *Gbk (car (collect 'nm '+Gbk)) # decide which guestbook we'll serve ) but the DB is still empty. It works if you do $ pil guest.l -setup -bye # Create the DB $ pil guest.l -go + or $ pil guest.l -go -wait I would not do the 'pool' and the initialization of *Gbk on top of the file, but in a separate 'main' function (or here in 'go'): (de go () (pool "gb.db") (unless (seq *DB) (new! '(+Gbk) 'nm "Your guestbook name here") ) (setq *Gbk (car (collect 'nm '+Gbk) ) ) # decide which guestbook we'll serve (server 8080 "!work") ) Note that 'collect' is not wise here, as it collects the *whole* DB into a list just to get the first element :) BTW, there is another minor glitch: The (commit 'upd) at the end of 'addM>' is superfluous, as both 'new!' and 'put!>' already did an implied commit. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Trouble with a sample
Oops, please allow me to clarify. 1. Run the sample (attached) as follows - pil guest.l + : (setup) (go) (wait) 2. I hit localhost:3000 (since I have httpGate 3000 8080 running 3. I enter the details in the form and hit send followed by confirmation 4. I notice that I get -- addM -- Bad message 5. I quit pil and start it again and run (go) (wait) [ I dont need to run setup again since it ran last time and did create the DB] 6. I hit localhost:3000 and fill in the details and hit send followed by confirmation 7. I notice that that page is updated at the bottom with the record that I just entered 8. I open another browser tab and hit localhost:3000 and find that the record that I had entered does not show up - I believe it should have showed up. 9. I restart pil 10. Open a new tab and hit localhost:3000 -> the new record shows up I tried this both on WSL on windows and using docker on Mac and my pil version is 19.8.25 - Am I missing something. Regards, Kashyap On Fri, Aug 30, 2019 at 3:49 AM Alexander Burger wrote: > On Thu, Aug 29, 2019 at 07:33:16AM -0700, C K Kashyap wrote: > > I am still at a loss about the gustbook sample :( - pretty please take a > > look. > > Hmm, yes, but what exactly is the problem? > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > guest.l Description: Binary data
Re: Trouble with a sample
On Thu, Aug 29, 2019 at 07:33:16AM -0700, C K Kashyap wrote: > I am still at a loss about the gustbook sample :( - pretty please take a > look. Hmm, yes, but what exactly is the problem? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Trouble with a sample
Thanks Alex,
I am still at a loss about the gustbook sample :( - pretty please take a
look.
Regards,
Kashyap
On Wed, Aug 28, 2019 at 10:24 PM Alexander Burger
wrote:
> Hi Kashyap,
>
> > 1. Open pil + from terminal 1 and run (pool "test.db")
> > 2. Open pil + from terminal 2 and run (pool "test.db")
>
> Ah, no, this wont't work. Two separate processes don't know of each other
> and
> can't synchronize.
>
> Normally, browser sessions connect to one port (e.g. 80 or 8080) where the
> parent process listens, and get their own session (child process of the
> parent).
>
> Alternatively (without a browser, just REPL) you can use bin/psh
> to create a terminal session or connect to a running session
> by passing the port and session ID.
>
>
> > 3. Run (put '{1} 'X 10) followed by (commit) in terminal 1
> > 4. Run (get '{1} 'X) from terminal 2 -> we get 10 as expected
> > 5. Run (put '{1} 'Y 20) followed by (commit) in terminal 1
> > 6. Run (get '{1} 'Y) from terminal 2 -> this returns NIL
>
> This is fatal, and creates havoc in the DB. Ends up wit a corrupted DB in
> the
> worst case.
>
>
> > I suppose the two processes in the above sequence are not a family so the
> > scenario is not identical and perhaps the above is expected.
>
> Yes, exactly! Only a "family" of processes guarantees consistent concurrent
> modifications.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
Re: Trouble with a sample
Hi Kashyap,
> 1. Open pil + from terminal 1 and run (pool "test.db")
> 2. Open pil + from terminal 2 and run (pool "test.db")
Ah, no, this wont't work. Two separate processes don't know of each other and
can't synchronize.
Normally, browser sessions connect to one port (e.g. 80 or 8080) where the
parent process listens, and get their own session (child process of the parent).
Alternatively (without a browser, just REPL) you can use bin/psh
to create a terminal session or connect to a running session
by passing the port and session ID.
> 3. Run (put '{1} 'X 10) followed by (commit) in terminal 1
> 4. Run (get '{1} 'X) from terminal 2 -> we get 10 as expected
> 5. Run (put '{1} 'Y 20) followed by (commit) in terminal 1
> 6. Run (get '{1} 'Y) from terminal 2 -> this returns NIL
This is fatal, and creates havoc in the DB. Ends up wit a corrupted DB in the
worst case.
> I suppose the two processes in the above sequence are not a family so the
> scenario is not identical and perhaps the above is expected.
Yes, exactly! Only a "family" of processes guarantees consistent concurrent
modifications.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Trouble with a sample
Perhaps this helps - If I do the following
1. Open pil + from terminal 1 and run (pool "test.db")
2. Open pil + from terminal 2 and run (pool "test.db")
3. Run (put '{1} 'X 10) followed by (commit) in terminal 1
4. Run (get '{1} 'X) from terminal 2 -> we get 10 as expected
5. Run (put '{1} 'Y 20) followed by (commit) in terminal 1
6. Run (get '{1} 'Y) from terminal 2 -> this returns NIL
I suppose the two processes in the above sequence are not a family so the
scenario is not identical and perhaps the above is expected. I thought of
sharing just in case.
Regards,
Kashyap
On Wed, Aug 28, 2019 at 4:16 PM C K Kashyap wrote:
> Hi Alex,
> I double checked and reloading the browser does not seem to help :(
> Regards,
> Kashyap
>
> On Wed, Aug 28, 2019 at 10:02 AM Alexander Burger
> wrote:
>
>> Hi Kashyap,
>>
>> > I was trying out the guestbook example here -
>> > https://dev.to/cess11/lets-build-a-picolisp-guestbook-mkl I noticed
>> that
>> > the changes to the DB only get affected across sessions only after
>> restart
>> > the service. I mean, I add some data in a browser session and it shows
>> up
>> > at the bottom as expected, however, they disappear if I revisit the site
>> > from another tab.
>>
>> I have not tried or deeply studied the code, but it looks good at a first
>> glance.
>>
>> 'commit' should not be the culprit, as the program uses 'new!' and
>> 'put!>',
>> which commit automatically.
>>
>> Perhaps this is only a browser refresh problem? Browser tabs are not
>> automatically updated (contrary to pil's gui tabs) when revisited.
>>
>> What if you simply press the reload button in the browser's navigation
>> bar?
>>
>> ☺/ A!ex
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>
Re: Trouble with a sample
Hi Alex, I double checked and reloading the browser does not seem to help :( Regards, Kashyap On Wed, Aug 28, 2019 at 10:02 AM Alexander Burger wrote: > Hi Kashyap, > > > I was trying out the guestbook example here - > > https://dev.to/cess11/lets-build-a-picolisp-guestbook-mkl I noticed that > > the changes to the DB only get affected across sessions only after > restart > > the service. I mean, I add some data in a browser session and it shows up > > at the bottom as expected, however, they disappear if I revisit the site > > from another tab. > > I have not tried or deeply studied the code, but it looks good at a first > glance. > > 'commit' should not be the culprit, as the program uses 'new!' and 'put!>', > which commit automatically. > > Perhaps this is only a browser refresh problem? Browser tabs are not > automatically updated (contrary to pil's gui tabs) when revisited. > > What if you simply press the reload button in the browser's navigation bar? > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Trouble with a sample
Hi Kashyap, > I was trying out the guestbook example here - > https://dev.to/cess11/lets-build-a-picolisp-guestbook-mkl I noticed that > the changes to the DB only get affected across sessions only after restart > the service. I mean, I add some data in a browser session and it shows up > at the bottom as expected, however, they disappear if I revisit the site > from another tab. I have not tried or deeply studied the code, but it looks good at a first glance. 'commit' should not be the culprit, as the program uses 'new!' and 'put!>', which commit automatically. Perhaps this is only a browser refresh problem? Browser tabs are not automatically updated (contrary to pil's gui tabs) when revisited. What if you simply press the reload button in the browser's navigation bar? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Trouble with a sample
Thank you Pontus for the sample :) I did some digging around and looks like if I call pool right before calling collect, it seems to work. I think there may be something incorrect about the way "commit" is used in the code. Regards, Kashyap On Wed, Aug 28, 2019 at 7:17 AM Pontus Näslund wrote: > Hi, > > it's my code so I should know but I haven't run this since I wrote it > > I'm on vacation so I can't easily test it but it sounds like either > 'collect or persistence is failing, have you tried exploring your DB from > REPL? > > Best regards, > > On Wed, 28 Aug 2019, 14:32 C K Kashyap, wrote: > >> Hi, >> I was trying out the guestbook example here - >> https://dev.to/cess11/lets-build-a-picolisp-guestbook-mkl I noticed that >> the changes to the DB only get affected across sessions only after restart >> the service. I mean, I add some data in a browser session and it shows up >> at the bottom as expected, however, they disappear if I revisit the site >> from another tab. >> I would really appreciate it if someone could point out what's going on. >> Regards, >> Kashyap >> >
Re: Trouble with a sample
Hi, it's my code so I should know but I haven't run this since I wrote it. I'm on vacation so I can't easily test it but it sounds like either 'collect or persistence is failing, have you tried exploring your DB from REPL? Best regards, On Wed, 28 Aug 2019, 14:32 C K Kashyap, wrote: > Hi, > I was trying out the guestbook example here - > https://dev.to/cess11/lets-build-a-picolisp-guestbook-mkl I noticed that > the changes to the DB only get affected across sessions only after restart > the service. I mean, I add some data in a browser session and it shows up > at the bottom as expected, however, they disappear if I revisit the site > from another tab. > I would really appreciate it if someone could point out what's going on. > Regards, > Kashyap >
