Re: Let me introduce myself
Hi Damir, > One question - the app/ example, how does gui.l gets loaded? I can > see main.l calls app/init.l, but from there, what's the code > execution path? Well, that's easy :) Line 14 of "app/main.l" loads "app/gui.l". It needs to be loaded only once, at the server's startup. "app/init.l" is, btw, called even more seldom, on a new database to populate it with some initial data. > How can I sort of step-by-step inspect how app gets loaded? You might 'trace' functions you are interested in. If there is no special set of functions you want to trace, you can call (traceAll), for example after you got the debug prompt and before clicking on some link. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Let me introduce myself
Alexander Burger wrote: On Mon, Jul 25, 2011 at 06:40:35PM +0700, Henrik Sarvell wrote: 1.) Simply don't use the app/gui server, like I do for vizreader.com, there I use cookies (see cookie in http.l). No, don't let you be persuaded into something ;-) Well, that's easy to do while I'm fresh here :) I'll stick to the defaults and when ready start fiddling with Nginx as frontent. So far I'm very impressed. Looking at app/ examples things are starting to come together slowly. One question - the app/ example, how does gui.l gets loaded? I can see main.l calls app/init.l, but from there, what's the code execution path? How can I sort of step-by-step inspect how app gets loaded? Thanks, Damir -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Let me introduce myself
On Mon, Jul 25, 2011 at 06:40:35PM +0700, Henrik Sarvell wrote: > 1.) Simply don't use the app/gui server, like I do for vizreader.com, there > I use cookies (see cookie in http.l). No, don't let you be persuaded into something ;-) The current app/gui server is still the best if you want to do real web applications (in contrast to simple web pages), with a lot of state, context and history in each session. I still would like to see somebody writing a GUI framework with the proper DB-to-GUI linkage necessary for a convenient application design like the current PicoLisp solution, where you can encapsulate all DB-related behavior (i.e. the complete application logic) into GUI component classes. Without that, we (at 7fach GmbH) would never have been able to write applications for our customers in the required quality and time (i.e. costs). All people who wrote differently here until now never addressed the core of the problem, always only certain aspects. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Let me introduce myself
So here's my answers: 1.) Simply don't use the app/gui server, like I do for vizreader.com, there I use cookies (see cookie in http.l). 2.) Alex's #2 answer is a good one. 3.) See vizreader.com which has been running without any PL related hiccups for quite some time now and I must say the DB performance is marvelous. On Tue, Jul 19, 2011 at 2:25 PM, Alexander Burger wrote: > Hi Damir, > > welcome! :) > > In addition to what Tomas wrote: > > > > 1. App changes port number for each session > > Right, that's a central feature of the application server. The reasons > for that are > > - Each user session is handled by a separate child process, to hold the > state and history of the GUI, per-session user state, cached database > objects and transactions. > > - Each connected client must know how to access its private process. > This is done by each child allocating its own TCP port, and listening > at that port. In that way we have a clear isolation between the > processes and sessions, and it works stand-alone (without separate > instances like 'nginx' or 'httpGate') for minimal setups. > > - For a production setup, a single-port access is better of course > (mainly for security/firewall reasons). We use exclusively 'httpGate' > for that. The advantages of httpGate are that it is very simple, and - > the initial reason to write it - that it can handle SSL en/decryption. > It does a simple rewrite of the URL, basically changing url/port to > url:port. > > I'm convinced that this is the optimal way. If you'd use a cookie > solution instead, you would have to implement the identical logic twice, > once in the proxy, and once in the app (for stand-alone usage). > > > how can PicoLisp app be served to the wild of Internet, being > > accessed via port 80? > > With 'httpGate' or some other proxy like Tomas' ngix solution. You can > see usages of 'httpGate' in some examples and demo apps "in the wild", > like > > http://app.7fach.de > http://sushi.7fach.de > http://rcsim.7fach.de > http://home.picolisp.com > http://wiki.picolisp.com > > > > 2. Backup > > With mysql (or any other) I do mysqdump and I'm done. Zipped .sql > > files are rsynced to remote locations for greater security. > > > > How is backing up PicoLisp databases done in production? > > We are using three methods: > > 1. Once per night a cron job runs. > > 12 1 * * * ./pil lib/http.l -'client "localhost" 16000 (pack > "messe/back.l?*PW=" (pw))' -bye > > The "messe/back.l" does the following: It connects to the server, > forks a child process which then: > > - Stops possibly remaining sessions: > > (tell 'bye 2) > > - Locks the database > > (when (lock) > (quit "Can't lock DB" @) ) > > - Does some integrity check > > (for (F . @) *Dbs > (when (dbck F) >(quit "DB Check" (cons F @)) ) ) > > - Creates backups > > (call "sh" "-c" "tar cfz messe$(date +%a).tgz db/messe/ blob/messe/") > > - and does a DB garbage collection > > (when (dbgc) > (println 'dbgc @) ) > > Normally, the "back.l" scripts also do lots of other things, like > sending mails and cleaning up other stuff. > > Another cronjob then saves the created *.tgz backups to some other > medium. > > > 2. In most production apps, we do a "permanent" backup, i.e. a mirroring > of the database to some other, remote server. This can be done the > following way: > > - The application's database is opened in journal mode > > (pool "db/messe/" > *Dbs > (setq *Jnl (and (info "key/messe") "fifo/messe")) ) > > This causes all changes to the db being written to a file > "fifo/messe". > > - a separate 'ssl' process is started > > bin/ssl 443 '40003/!replica' key/messe fifo/messe > blob/messe/ 20 > > This process checks "fifo/messe" every 20 seconds, and sends it > (using atomic transactions) to the remote machine. > > - On the remote machine, a 'replica' process is runnning > > bin/replica 40003 key/messe "" rpl/db/messe/ rpl/blob/messe/ 4 1 1 1 1 > 2 3 4 4 4 4 5 5 5 6 3 4 4 4 3 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 0 6 > 4 & > > which then maintains an exact copy of the original database. We > have a single server mirroring all customer's databases, and which > in turn is also backed up regularly. > > 'ssl' and 'replica' are part of the distribution. > > > 3. Then, of course, there is the "normal" backup, saving the whole > working directory (most importantly the database and blobs). > > > > > and 3. Is it ready for production use? > > Are there any production grade apps running PicoLisp? What are > > common setups and known issues beginner should expect? > > We (at "software-lab" and "7fach GmbH") use it exclusively since the > mid-1990s. It was a constant evolution, always implementing only what > was absolutely necessary for the practical problems at hand. > > There are more details involved than what I described ab
Re: Let me introduce myself
Hi Damir, welcome! :) In addition to what Tomas wrote: > 1. App changes port number for each session Right, that's a central feature of the application server. The reasons for that are - Each user session is handled by a separate child process, to hold the state and history of the GUI, per-session user state, cached database objects and transactions. - Each connected client must know how to access its private process. This is done by each child allocating its own TCP port, and listening at that port. In that way we have a clear isolation between the processes and sessions, and it works stand-alone (without separate instances like 'nginx' or 'httpGate') for minimal setups. - For a production setup, a single-port access is better of course (mainly for security/firewall reasons). We use exclusively 'httpGate' for that. The advantages of httpGate are that it is very simple, and - the initial reason to write it - that it can handle SSL en/decryption. It does a simple rewrite of the URL, basically changing url/port to url:port. I'm convinced that this is the optimal way. If you'd use a cookie solution instead, you would have to implement the identical logic twice, once in the proxy, and once in the app (for stand-alone usage). > how can PicoLisp app be served to the wild of Internet, being > accessed via port 80? With 'httpGate' or some other proxy like Tomas' ngix solution. You can see usages of 'httpGate' in some examples and demo apps "in the wild", like http://app.7fach.de http://sushi.7fach.de http://rcsim.7fach.de http://home.picolisp.com http://wiki.picolisp.com > 2. Backup > With mysql (or any other) I do mysqdump and I'm done. Zipped .sql > files are rsynced to remote locations for greater security. > > How is backing up PicoLisp databases done in production? We are using three methods: 1. Once per night a cron job runs. 12 1 * * * ./pil lib/http.l -'client "localhost" 16000 (pack "messe/back.l?*PW=" (pw))' -bye The "messe/back.l" does the following: It connects to the server, forks a child process which then: - Stops possibly remaining sessions: (tell 'bye 2) - Locks the database (when (lock) (quit "Can't lock DB" @) ) - Does some integrity check (for (F . @) *Dbs (when (dbck F) (quit "DB Check" (cons F @)) ) ) - Creates backups (call "sh" "-c" "tar cfz messe$(date +%a).tgz db/messe/ blob/messe/") - and does a DB garbage collection (when (dbgc) (println 'dbgc @) ) Normally, the "back.l" scripts also do lots of other things, like sending mails and cleaning up other stuff. Another cronjob then saves the created *.tgz backups to some other medium. 2. In most production apps, we do a "permanent" backup, i.e. a mirroring of the database to some other, remote server. This can be done the following way: - The application's database is opened in journal mode (pool "db/messe/" *Dbs (setq *Jnl (and (info "key/messe") "fifo/messe")) ) This causes all changes to the db being written to a file "fifo/messe". - a separate 'ssl' process is started bin/ssl 443 '40003/!replica' key/messe fifo/messe blob/messe/ 20 This process checks "fifo/messe" every 20 seconds, and sends it (using atomic transactions) to the remote machine. - On the remote machine, a 'replica' process is runnning bin/replica 40003 key/messe "" rpl/db/messe/ rpl/blob/messe/ 4 1 1 1 1 2 3 4 4 4 4 5 5 5 6 3 4 4 4 3 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 0 6 4 & which then maintains an exact copy of the original database. We have a single server mirroring all customer's databases, and which in turn is also backed up regularly. 'ssl' and 'replica' are part of the distribution. 3. Then, of course, there is the "normal" backup, saving the whole working directory (most importantly the database and blobs). > and 3. Is it ready for production use? > Are there any production grade apps running PicoLisp? What are > common setups and known issues beginner should expect? We (at "software-lab" and "7fach GmbH") use it exclusively since the mid-1990s. It was a constant evolution, always implementing only what was absolutely necessary for the practical problems at hand. There are more details involved than what I described above, but I hope it helps a little. Please ask any time! Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Let me introduce myself
Hi Damir, > Don't mind unconventional at all. From what I've read so far, looks > like things are being done at rapid pace. I like that. :) Great! PicoLisp is briliant in many ways;-) Welcome and have fun! Cheers, Tomas -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Let me introduce myself
Tomas Hlavaty wrote: I would say you should expect to have lots of questions about how things work in picolisp as quite a few things are rather unconventional. One issue you already hit upon is that the default picolisp app url convention will quite likely not suit you;-) Don't mind unconventional at all. From what I've read so far, looks like things are being done at rapid pace. I like that. :) And thanks for production app examples! Damir -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Let me introduce myself
Hi Damir, > 1. App changes port number for each session > I use Nginx to proxy request to one or more Thin's (rails app serves) > running on high localhost ports (3000, 3001, 3002, ...) > > Can something similar be achieved with PicoLisp? Or, even better, how > can PicoLisp app be served to the wild of Internet, being accessed via > port 80? I have picolisp behind nginx too, see http://logand.com/blog/picolisp-behind-nginx-proxy.html It is not complete description but gives you an idea of the nginx side. The lisp side changes are described at http://logand.com/picoWiki/rewriteUrl Alex (the author of picolisp) uses httpGate which is in the picolisp tarball. It's basically very simple proxy fitted to his needs. > 2. Backup With mysql (or any other) I do mysqdump and I'm done. Zipped > .sql files are rsynced to remote locations for greater security. > > How is backing up PicoLisp databases done in production? There have been threads on this mailing list about it in the past. > and 3. Is it ready for production use? Are there any production grade > apps running PicoLisp? What are common setups and known issues > beginner should expect? Yes there are a few. Alex has a few complex, Henrik has one I know of and I have some, e.g. http://logand.com/sw/ondoc/index.html I would say you should expect to have lots of questions about how things work in picolisp as quite a few things are rather unconventional. One issue you already hit upon is that the default picolisp app url convention will quite likely not suit you;-) Cheers, Tomas -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Let me introduce myself
Hi. I'm Damir and for the last three days I've clicked & read through what I think are all links available at picolisp.com site. :) Found it entirely by accident (via HN Ticker post) and been thoroughly amazed of what it can do. Even played the rc3D flight game for a while... The biggest pull-down-my-socks was when I read about integrated DB and it's connection to GUI. It blew my mind - let me explain. I do Rails for living plus a bit of BSD & Linux server admin from time to time and if you know even a little bit about Rails, you'll understand my point of view w/o problem. It's the 95% of what you *don't* need to to with PicoLisp that's so great-sounding - ORM and glue in between. Rails is great. I love it. What bothers me is RAM usage and amount of coding I have to do to connect scaffolded model to view. For long I've been searching for alternatives with little to no solutions. There's Smalltalk with Seaside[0], Aida[1] and Iliad[2], all great for web dev, order of magnitute better then Rails, but like I said before I really don't like having 100's megs of RAM used just to serve web pages. Also, running GUI Smalltalk on server is a bit... well, a drawback, if you will. VNC isn't best suited for real debugging where seconds matter. Until I found PicoLisp and it's app example. I dug into docs and while I'm still mostly lost, I managed to get all examples up&running and had great time playing with REPL attached to web app. OK, let me get to my point... Looking from Rails corner, these are things I miss (or don't know how to get them running the way I'm used to): 1. App changes port number for each session I use Nginx to proxy request to one or more Thin's (rails app serves) running on high localhost ports (3000, 3001, 3002, ...) Can something similar be achieved with PicoLisp? Or, even better, how can PicoLisp app be served to the wild of Internet, being accessed via port 80? 2. Backup With mysql (or any other) I do mysqdump and I'm done. Zipped .sql files are rsynced to remote locations for greater security. How is backing up PicoLisp databases done in production? and 3. Is it ready for production use? Are there any production grade apps running PicoLisp? What are common setups and known issues beginner should expect? I am sorry if this message reads messed up, it's written in one shot with lot's of questions in my mind - thinking of ways I can use it for my web apps. Thank you, Damir -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
