Re: Beyond PowerStatus: Concurrency options

2015-03-20 Thread Bob Sneidar
I say yes. At the very least, progress indicators really REALLY need concurrency, if for nothing else than the animation. Plus, concurrency can be used to *queue* complex time consuming operations with databases and such. Data grids for example could queue up “pages” of data in the background wi

Re: Beyond PowerStatus: Concurrency options

2015-03-09 Thread Dr. Hawkins
On Mon, Mar 9, 2015 at 11:32 AM, Pierre Sahores wrote: > I see… > > —> Scala > —> PHP > —> Java > > I would choose Scala if i had to solve this my self. Have an eye on it : > it’s a powerful functional programming language witch compile to the JVM > and is able to handle connections to PostgreSQL

Re: Beyond PowerStatus: Concurrency options

2015-03-09 Thread Pierre Sahores
> Le 9 mars 2015 à 18:44, Dr. Hawkins a écrit : > > On Sun, Mar 8, 2015 at 9:27 PM, Pierre Sahores > wrote: > >> Why not clients to an LC server gateway in SSL mode and LC to PostgreSQL >> in localhost mode ? >> >> > From the past few days of discussions, it does not appear that livecode can

Re: Beyond PowerStatus: Concurrency options

2015-03-09 Thread Dr. Hawkins
On Sun, Mar 8, 2015 at 9:27 PM, Pierre Sahores wrote: > Why not clients to an LC server gateway in SSL mode and LC to PostgreSQL > in localhost mode ? > > >From the past few days of discussions, it does not appear that livecode can enforce only encrypted connections--once the socket is open, it w

Re: Beyond PowerStatus: Concurrency options

2015-03-08 Thread Pierre Sahores
Why not clients to an LC server gateway in SSL mode and LC to PostgreSQL in localhost mode ? > Le 9 mars 2015 à 02:53, Dr. Hawkins a écrit : > > Heck, I'd settle > for ssl or postgres being done correctly :) -- Pierre Sahores mobile : 06 03 95 77 70 www.sahores-conseil.com __

Re: Beyond PowerStatus: Concurrency options

2015-03-08 Thread stephen barncard
On Sun, Mar 8, 2015 at 6:53 PM, Dr. Hawkins wrote: > Not that promising--remember when intel's virtual cores (or whatever > they're called) came out? We all got excited about what sounded like a > great idea, but it never met it promise. > Only recently for us Pro Tools users. -- Stephen Barnc

Re: Beyond PowerStatus: Concurrency options

2015-03-08 Thread Dr. Hawkins
On Sun, Mar 8, 2015 at 1:17 PM, Pierre Sahores wrote: > 1.- home made : i7 8 logical cores under windows : > Not that promising--remember when intel's virtual cores (or whatever they're called) came out? We all got excited about what sounded like a great idea, but it never met it promise. The

Re: Beyond PowerStatus: Concurrency options

2015-03-08 Thread Pierre Sahores
Well done Mike ! Two other possible ways in mind : 1.- home made : i7 8 logical cores under windows : -> 1 core runs an LC controller app in client mode and dispatch tasks to : -> 7 cores running an LC functional server accepting sockets connections on port xxx 2.- Runrev’s doable : implementat

Re: Beyond PowerStatus: Concurrency options

2015-03-07 Thread Richard Gaskin
Nicely done, Mike. Using Apache for this is a good solution - it's already set up to herd workers in a way with CGI, and it handles the forking so we don't have to. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web _

Re: Beyond PowerStatus: Concurrency options

2015-03-07 Thread Mike Bonner
The last thing I did this way was more like a seti online type of work load. My web server is on the same machine as my LC in this case, so I had lc create individual data files for the web server to go through, used the load command to tell the web server which file it was, and turned it loose wit

Re: Beyond PowerStatus: Concurrency options

2015-03-07 Thread Richard Gaskin
Mike Bonner wrote: > One very simple concurrency thing I would like to see is an optional > "to thread with message" type of syntax. This would be similar to > the way sockets are handled, if something apears in the socket, a > message is dispatched. For things like long list processing, where

Re: Beyond PowerStatus: Concurrency options

2015-03-07 Thread Mike Bonner
One very simple concurrency thing I would like to see is an optional "to thread with message" type of syntax. This would be similar to the way sockets are handled, if something apears in the socket, a message is dispatched. For things like long list processing, where the app doesn't need to wait