Re: Issue with wait
Hi Henrik, > "In fact, it has. 'wait' always first checks for pending events before > it goes to sleep." > > Why does it do that? This is exactly the purpose of 'wait': Wait for events. The milliseconds are just a timeout value. > If I had access to a wait that simply stops > execution and nothing else everything would be good, I tried to create > one of my own but it uses too much CPU in the loop. Well, that's easy: (call 'sleep 2) Also (at least on Linux) this works: (call 'sleep "0.1") > "If there are data available on that socket already, that task will be > executed." > > It is listening (subscribing) for data so there is no data available > to begin with. But there must be something, otherwise it would not wake up. Try to (trace '...) or '$ strace ...' it. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Subscribe
Hello Brett Stahlman :-) You are now subscribed -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Subscribe
Hello Brett Stahlman :-) You are now subscribed -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Issue with wait
Hi Alex, thanks for that clarification. "In fact, it has. 'wait' always first checks for pending events before it goes to sleep." Why does it do that? If I had access to a wait that simply stops execution and nothing else everything would be good, I tried to create one of my own but it uses too much CPU in the loop. "If there are data available on that socket already, that task will be executed." It is listening (subscribing) for data so there is no data available to begin with. "where I don't know what '*RedisOnSubRes' contains" It contains: (println (last *RedisSubRes)) I would be fine if I didn't need a loop at the end that needs to wait a certain amount of time, the loop is needed to ping the client to check that it is alive (it will respond with pong if it is): https://bitbucket.org/hsarvell/pl-web/src/default/pl-web.l?at=default&fileviewer=file-view-default (line 368). On Sun, Jan 3, 2016 at 9:45 AM, Alexander Burger wrote: > Hi Henrik, > > On Sat, Jan 02, 2016 at 10:34:25PM +0100, Henrik Sarvell wrote: >> I've recently implemented pub / sub ( http://redis.io/topics/pubsub ) >> in my redis class ( >> https://bitbucket.org/hsarvell/ext/src/default/redis.l?fileviewer=file-view-default >> ). > > Cool! > > >> (subscribe> R "foo") >> #(wait 1) >> (println "finished") >> >> with ./pil subscribe.l in /opt/picolisp you will see "finished". >> >> If you uncomment the wait line you will not see "finished", the script >> stops on (wait 1) and I have no idea why. >> >> Since I don't pass in a second argument I would assume that wait has >> nothing to do with the *Run global in this case and that execution >> will simply pause for one millisecond and then continue but this does >> not happen. > > In fact, it has. 'wait' always first checks for pending events before it > goes to sleep. In 'subscribe>' you start a task on the socket. If there > are data available on that socket already, that task will be executed. I > can't reproduce your setup, but the task calls > >(run *RedisOnSubRes) > > where I don't know what '*RedisOnSubRes' contains, but I recommend you > trace that one to see where it hangs. > > >> So execution continues as soon as we get something back on the socket >> we have established. > > Yes, exactly. > > >> I don't get why wait literally needs something coming into (in ... ) >> in order to allow continued execution in this case. > > If nothing would be coming in, 'wait' would indeed sleep just for > a millisecond and then return. So it must be the scenario described > above. > > ♪♫ Alex > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Questions about EmuLisp
Hi Christophe, > These are primarily questions for Alex, but I'm interested > in the answers of other people too. I'm afraid that I don't have useful answers, but I try ... > 1) What do you think of EmuLisp? I like the fact that it is written in JS, but I don't know its limitations. > 2) Would you promote it? > 3) Would you use it on the futur website for the demo REPL? Personally I prefer server-side application code, as it gives more power to the application, and also makes development a lot easier. So it is not an option for me at the moment. On the client I prefer hand-crafted JS, which doesn't need to be touched during application development. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Issue with wait
Hi Henrik, On Sat, Jan 02, 2016 at 10:34:25PM +0100, Henrik Sarvell wrote: > I've recently implemented pub / sub ( http://redis.io/topics/pubsub ) > in my redis class ( > https://bitbucket.org/hsarvell/ext/src/default/redis.l?fileviewer=file-view-default > ). Cool! > (subscribe> R "foo") > #(wait 1) > (println "finished") > > with ./pil subscribe.l in /opt/picolisp you will see "finished". > > If you uncomment the wait line you will not see "finished", the script > stops on (wait 1) and I have no idea why. > > Since I don't pass in a second argument I would assume that wait has > nothing to do with the *Run global in this case and that execution > will simply pause for one millisecond and then continue but this does > not happen. In fact, it has. 'wait' always first checks for pending events before it goes to sleep. In 'subscribe>' you start a task on the socket. If there are data available on that socket already, that task will be executed. I can't reproduce your setup, but the task calls (run *RedisOnSubRes) where I don't know what '*RedisOnSubRes' contains, but I recommend you trace that one to see where it hangs. > So execution continues as soon as we get something back on the socket > we have established. Yes, exactly. > I don't get why wait literally needs something coming into (in ... ) > in order to allow continued execution in this case. If nothing would be coming in, 'wait' would indeed sleep just for a millisecond and then return. So it must be the scenario described above. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
