Re: mySQL Host access

[Peter Haworth]

Hi Lyn,
Thanks for that info, that will certainly help me when I start looking into
LC server.  Unfortunately, I think I'm about 6 months into a 2-year
contract with my current web host so probably could not switch at this
point.


On Thu, Jan 7, 2016 at 4:17 PM Lyn Teyla  wrote:

> Peter Haworth wrote:
>
> > Is this common practice when accessing mySQL on a host server?  If so, is
> > there a better way to set about accessing a mySQL database in these
> > circumstances, perhaps using php scripts on the server instead of
> accessing
> > the db directly with the LC database functions?
>
> One of my hosting providers HostM.com has been offering a free
> LiveCode-based MariaDB/MySQL API solution. It was previously available only
> to clients who needed this setup.
>
> I told them about the widespread interest in the LiveCode community for
> such a solution, and they’ve kindly made their API demo available for free
> download by any LiveCode developer.
>
> You can download it at:
>
> https://www.hostm.com/tutorials/livecode/api-mariadb-mysql
>
> Hope this helps!
>
> Lyn
>
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: mySQL Host access

[Peter Haworth]

Hi Alex,
You're probably right on the lc server issue (and thanks for the
compliment).

I already had a library of php db access scripts on my server which I've
been using in batch cron jobson a nightly basis so the guts of what I
needed to do was already in place, whereas I have never installed LC server
or used it.  Now that it's all working I will probably try using LC
server.  My web host is Dreamhost - does anyone know if they support LC
server?

I have all this working now using php middleware.  I ended up using the LC
post command with a command code that indicates what SQL action is required
plus other parameters that contain the required data for the SQL action.

The php script return a JSON containing either the data from SELECT
statements, number of rows affected for INSERT/UPDATE/DELETE, or error
message information if there's a mySQL error.

No SQL commands are sent out, they are all constructed by the sever php
script.  I think, but would like opinions, that doing it that way means I
can embed the data in the SQL commands and not have to worry about
injection attacks since the actual SQL commands go directly from my php
script to mySQL.

Thanks for everyone's input on this.

On Thu, Jan 7, 2016 at 4:17 PM Lyn Teyla  wrote:

> Peter Haworth wrote:
>
> > Is this common practice when accessing mySQL on a host server?  If so, is
> > there a better way to set about accessing a mySQL database in these
> > circumstances, perhaps using php scripts on the server instead of
> accessing
> > the db directly with the LC database functions?
>
> One of my hosting providers HostM.com has been offering a free
> LiveCode-based MariaDB/MySQL API solution. It was previously available only
> to clients who needed this setup.
>
> I told them about the widespread interest in the LiveCode community for
> such a solution, and they’ve kindly made their API demo available for free
> download by any LiveCode developer.
>
> You can download it at:
>
> https://www.hostm.com/tutorials/livecode/api-mariadb-mysql
>
> Hope this helps!
>
> Lyn
>
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: "fork" command?

[Richard Gaskin]

Monte Goulding wrote:

>> On 8 Jan 2016, at 6:03 am, Richard Gaskin wrote:
>>
>> I think we need a new command that launches a specified process
>> but in a way that uses a call to "fork" to pass file descriptors
>> (which include sockets and other I/O info) to the child process.
>>
>> In many ways it would work very similarly to the existing "open
>> process", but allow params to give the child process access to
>> things like socket connections, pipes, files, etc. the parent
>> process has access to at the time the child process is launched.
>>
>> It would seem least intrusive on the code base to implement it as
>> a new command, perhaps called "fork".
>
>
> Hmm… I’m not convinced we need this for FastCGI. Apache mod_fcgid
> will start up processes for you and for Nginx and other servers
> that don’t do that you could use spawn-fcgi.

My understanding is that spawn-fcgi uses fork, no?


> We mainly need two things for FastCGI:
>  - an engine with the FastCGI accept loop as the main loop (LC Server
> just starts up and quits at the end of the code and standalones just
> keep looping until you quit).

I believe that has more to do with the nature of CGI than with LC per 
se.  That is, as a CGI any engine (Perl, Python, Ruby, LiveCode) will be 
born, live, and die during the request.


But with FastCGI the engine is only loaded once, and instances forked 
with requests as needed, and using fork they get the socket and other 
data needed for the child process to handle the task.


Some engines may use multithreading rather than multiprocessing, but the 
difference is less of a concern on Linux than on Windows since Linux 
spawns processes much more efficiently.


If multithreading were pursued as an alternative to multiprocessing via 
fork, I fear a threading subsystem would be much more work to implement, no?



>  - to decide on how to handle things like global variable scope etc
> because you’re going to end up with multiple requests to the same
> environment.

How is that handled in the FastCGI version of PHP?  I would imagine it 
would be no more onerous than with threading, arguably simpler since so 
much of the action takes places in a separate process.


I wouldn't expect to be able to use FastCGI without modifying some of my 
scripting habits; as with any new feature, just a few new things to 
learn and keep track of.  Indeed, I would welcome the opportunity for it 
to become possible to learn those things.



> After some thought and considering the new script only stack format
> I came to the conclusion that it would be better not to do the php
> style   - startup - the process is started do anything you can do once for
>all requests
>  - acceptRequest - a new request needs to be handled and the global
>environment variables $_SERVER etc have been updated where
>necessary (or these could be parameters I guess)
>  - shutdown - something is killing the process so do anything you
>need to do to cleanup
>
> The basic idea is you can do something like this:
>
> local sCounter = 0
> local sProcessStarted
>
> on startup
>   put the seconds into sProcessStarted
> end startup
>
> on acceptRequest
>   add 1 to sCounter
>   put “Started:” && sProcessStarted & return & “Counter:” && sCounter
> end acceptRequest
>
> If you only spawn one process then each time you hit the server the
> counter would increment.

In that outline would "acceptRequest" be a request from Apache, or are 
you proposing a system that replaces Apache to accept requests directly 
from the client?


Once we have forking we could completely replace Apache (or NGineX or 
Node.js) with a fully-functioning server for specific applications where 
the efficiencies of a purpose-built system would be helpful.


But even when running under Apache with FastCGI, fork would seem a very 
useful thing.  It's how PHP and other engines are able to scale, and 
indeed not having it prevents LC from being used in traffic-heavy scenarios.



> Of course you could have a FastCGI engine that cleared all the
> globals and stacks from memory between requests and loaded any
> script only stack file but it’s not quite as much fun, you lose
> the advantage of keeping resources in memory and as far as I can
> tell it’s a bit more work to do that ;-)

As with other persistent systems like LC on the desktop, we should 
maintain control over which data is purged and which data is shared.  We 
have globals and script-locals, depending on the context we need them, 
and in a multiprocessing environment we should have the same flexibility.


For example, one of the strong advantages of FastCGI or other persistent 
implementation is that we don't have to create and destroy database 
connections with every request.  That sort of information (along with 
config data and other such things) we'd want to remain globally 
available to child processes.  Request-specific data could be handled in 
script-locals, where they can be managed and cleared as needed 

Subject: Re: "fork" command?

[Todd Fabacher]

+1 for Me also

I would for sure would support funding for this. LiveCode in a Node.JS like
solution would be a KILLER!!! Especially if there was a direct connection
to MongoDB which we are HEAVY users of.

--Todd


> Le 7 janv. 2016 ? 20:03, Richard Gaskin  a
?crit :
>
> I'm just far enough into Robert Love's "Linux System Programming" that I
think the solution to FastCGI may be much simpler than I'd previously
thought.
>


> Forking seems so common in other tools, and not having it appears to be
the one detail standing between where we are now and having not just
FastCGI, but also being able to build truly excellent application servers
on par with Node.js and other similar systems.
>
> LiveCode is a great language, and if we had the ability to fork we should
be able to build a wide range of powerful, scalable, efficient systems,
breaking far beyond the limitations of CGI we're limited to now.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: mySQL Host access

[Lyn Teyla]

Peter Haworth wrote:

> Is this common practice when accessing mySQL on a host server?  If so, is
> there a better way to set about accessing a mySQL database in these
> circumstances, perhaps using php scripts on the server instead of accessing
> the db directly with the LC database functions?

One of my hosting providers HostM.com has been offering a free LiveCode-based 
MariaDB/MySQL API solution. It was previously available only to clients who 
needed this setup.

I told them about the widespread interest in the LiveCode community for such a 
solution, and they’ve kindly made their API demo available for free download by 
any LiveCode developer.

You can download it at:

https://www.hostm.com/tutorials/livecode/api-mariadb-mysql

Hope this helps!

Lyn



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

equivalent to DISTINCT ON (with SUM()) for in-memory SQLite

[Dr. Hawkins]

I need to sum amounts and return keys where other fields are the same on an
in-memory database.

I have my own unique key uniqDna, fields cname and cadr, and numeric field
due

I want to SUM(due) for each unique cname||cadr, and get get the
corresponding keys.

DISTINCT ON would due this, but it's not supported by SQLite.

At the moment, I'm not seeing any approach other than returning them all,
and using cname||cadr as a matrix key, and summing myself.

-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: "fork" command?

[Monte Goulding]

> My understanding is that spawn-fcgi uses fork, no?

Yes. Are you looking to implement your own process manager though?
> 
> 
> > We mainly need two things for FastCGI:
> >  - an engine with the FastCGI accept loop as the main loop (LC Server
> > just starts up and quits at the end of the code and standalones just
> > keep looping until you quit).
> 
> I believe that has more to do with the nature of CGI than with LC per se.  
> That is, as a CGI any engine (Perl, Python, Ruby, LiveCode) will be born, 
> live, and die during the request.
> 
> But with FastCGI the engine is only loaded once, and instances forked with 
> requests as needed, and using fork they get the socket and other data needed 
> for the child process to handle the task.

> Some engines may use multithreading rather than multiprocessing, but the 
> difference is less of a concern on Linux than on Windows since Linux spawns 
> processes much more efficiently.
> 
> If multithreading were pursued as an alternative to multiprocessing via fork, 
> I fear a threading subsystem would be much more work to implement, no?

spawn-fcgi and mod_fcgid do essentially what you are proposing. Spawn long 
running processes when told to and manage passing the request to them in a 
balanced way if there’s more than one process.
> 
> 
> >  - to decide on how to handle things like global variable scope etc
> > because you’re going to end up with multiple requests to the same
> > environment.
> 
> How is that handled in the FastCGI version of PHP?

PHP tears down everything although you can maintain persistent db connections. 
There’s a few different ways to do FastCGI for PHP as it has it’s own process 
manager.

>  I would imagine it would be no more onerous than with threading, arguably 
> simpler since so much of the action takes places in a separate process.

I actually haven’t mentioned threading at all...
> 
> I wouldn't expect to be able to use FastCGI without modifying some of my 
> scripting habits; as with any new feature, just a few new things to learn and 
> keep track of.  Indeed, I would welcome the opportunity for it to become 
> possible to learn those things.
> 
> In that outline would "acceptRequest" be a request from Apache, or are you 
> proposing a system that replaces Apache to accept requests directly from the 
> client?

acceptRequest would be called in response to the FastCGI main loop which 
processes a requests then waits for the next one to come in. Where it comes 
from is from anything that implements the FastCGI protocol but it is a HTTP 
request if that’s what you are asking.

> 
> Once we have forking we could completely replace Apache (or NGineX or 
> Node.js) with a fully-functioning server for specific applications where the 
> efficiencies of a purpose-built system would be helpful.

Ah, ok so you wan’t MCHTTPd with child processes and maybe FastCGI but maybe 
just some custom protocol between them?
> 
> But even when running under Apache with FastCGI, fork would seem a very 
> useful thing.  It's how PHP and other engines are able to scale, and indeed 
> not having it prevents LC from being used in traffic-heavy scenarios.

I’m not saying it’s not useful, just suggesting letting something else do the 
forking might be a good idea.

> 
> 
> > Of course you could have a FastCGI engine that cleared all the
> > globals and stacks from memory between requests and loaded any
> > script only stack file but it’s not quite as much fun, you lose
> > the advantage of keeping resources in memory and as far as I can
> > tell it’s a bit more work to do that ;-)
> 
> As with other persistent systems like LC on the desktop, we should maintain 
> control over which data is purged and which data is shared.  We have globals 
> and script-locals, depending on the context we need them, and in a 
> multiprocessing environment we should have the same flexibility.
> 
> For example, one of the strong advantages of FastCGI or other persistent 
> implementation is that we don't have to create and destroy database 
> connections with every request.  That sort of information (along with config 
> data and other such things) we'd want to remain globally available to child 
> processes.  Request-specific data could be handled in script-locals, where 
> they can be managed and cleared as needed within the worker process itself, 
> without affecting truly global data managed by the parent.

I think what I was proposing covers that.

Cheers

Monte


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML5 update: why it is slow?

[Pierre Sahores]

> Le 7 janv. 2016 à 03:56, Lyn Teyla  a écrit :
> 
> Monte Goulding wrote:
> 
>> Personally I’d rather you declare force majeure on wait for HTML5 and apply 
>> your considerable talents to implementing non-blocking versions of 
>> everything.
> 
> Agreed. Won’t the planned improvements to networking include asynchronous 
> communication in any case?
> 
> If a stop-gap solution for HTTP request support is required, what about the 
> suggestions listed at:
> 
> http://stackoverflow.com/questions/16987080/whats-the-c-side-of-an-emscripten-xmlhttprequest-call

or what’s amazingly well minded and reliable on the lua, openresty/nginx and 
gideros side…

> Lyn
> 
> 

--
Pierre Sahores
mobile : 06 03 95 77 70
www.sahores-conseil.com
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML5 update: why it is slow?

[Pierre Sahores]

> Le 7 janv. 2016 à 14:18, Peter TB Brett  a écrit :
> 
> On 07/01/2016 11:59, Pierre Sahores wrote:
>> 
>> 
>>> Le 7 janv. 2016 à 03:56, Lyn Teyla  a écrit :
>>> 
>>> Monte Goulding wrote:
>>> 
 Personally I’d rather you declare force majeure on wait for HTML5 and 
 apply your considerable talents to implementing non-blocking versions of 
 everything.
>>> 
>>> Agreed. Won’t the planned improvements to networking include asynchronous 
>>> communication in any case?
>>> 
>>> If a stop-gap solution for HTTP request support is required, what about the 
>>> suggestions listed at:
>>> 
>>> http://stackoverflow.com/questions/16987080/whats-the-c-side-of-an-emscripten-xmlhttprequest-call
> 
> Doing a synchronous XMLHttpRequest isn't a totally insane idea and might be a 
> decent temporary workaround.  Thanks Lyn -- I'll look into it.
> 
>> or what’s amazingly well minded and reliable on the lua, openresty/nginx and 
>> gideros side…
> 
> Since I'm not very well-versed in Lua programming, would you mind going into 
> more detail about how the model used there and how you envisage it working in 
> LiveCode Script?

https://openresty.org/ 

Cheers,

Pierre
> 
>Peter
> 
> 
> -- 
> Dr Peter Brett 
> LiveCode Open Source Team
> 
> LiveCode on reddit: https://reddit.com/r/livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

--
Pierre Sahores
mobile : 06 03 95 77 70
www.sahores-conseil.com
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: "fork" command?

[Todd Fabacher]

Yes, Monte is correct, we switch our servers to Node.JS simply because of
the ease of use, speed and productivity gains.

BUT...there is tremendous power is using one language as a solution. The
barrier of entry for most LiveCoders is very high to get a proper cloud
App. If like LC had a solution like Node.JS where you could just drop it on
the server. list your scripts, start up the server and BINGO one cloud
server ready to go - it would be HUGE.  FASTCGI did not offer many
advantages over Node.JS, and we are quite happy with it. but Now I need to
keep a person on staff who specialize it at the cost of over $100K.

The future of LiveCode is the cloud any way you turn, even if you do
traditional desktops. All this talk about HTML5 without a good, simple and
fast web server is just BS because it is the weak link in the chain. Any
productivity gain you might get in HTML5 or LC are going to be killed
trying to create a REST API server for your app.

I would for sure support any web server with this functionality. I also
think this would be a great opportunity to the LC community to step up and
do this on it's own as a independent project and let LC guys stay focused.
What do you think Monti and Richard?

--Todd
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC app not displaying correctly on iPhone

[Richard Miller]

Thank you, Colin.



Sent from my iPhone

> On Jan 6, 2016, at 1:05 PM, Colin Holgate  wrote:
> 
> Exact fit is rarely what you would want to do, it will distort the card area 
> to fit the screen size.
> 
> The black bars are because you didn’t include the default-5...@2x.png file.
> 
> 
>> On Jan 6, 2016, at 9:44 AM, Richard Miller  wrote:
>> 
>> I am testing a LC iPhone app on my iPad and iPhone 6S plus. I'm setting the 
>> fullscreenmode to "exactFit". The app displays perfectly on the iPad, but 
>> there is black space above and below the app on the iPhone. Nothing is cut 
>> off; it's just that the app is not filling the iPhone screen. I get the same 
>> result in the simulator, even when I set it to iPhone 6 or 5S.
>> 
>> Any suggestions? Building this with OS 10.11.2, LC 7.1, and Xcode 6.4.
>> 
>> Thanks 
>> Richard Miller
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: mySQL Host access

[Mark Wieder]

On 01/07/2016 06:05 PM, Lyn Teyla wrote:


The stacks are a free download, and from what I can tell, don’t require you to 
be a HostM.com client. You just need to be able to run LiveCode Server.


Maybe.
The url *does* throw a 404, though.

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: mySQL Host access

[Lyn Teyla]

Peter Haworth wrote:

> Thanks for that info, that will certainly help me when I start looking into
> LC server.  Unfortunately, I think I'm about 6 months into a 2-year
> contract with my current web host so probably could not switch at this
> point.

The stacks are a free download, and from what I can tell, don’t require you to 
be a HostM.com client. You just need to be able to run LiveCode Server.

Lyn



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: "fork" command?

[Monte Goulding]

> On 8 Jan 2016, at 12:42 pm, Richard Gaskin  wrote:
> 
> Monte Goulding wrote:
> 
> >> My understanding is that spawn-fcgi uses fork, no?
> >
> > Yes. Are you looking to implement your own process manager though?
> 
> What constitutes "process manager" in this context?

Something that spawns processes that handle requests.
> 
> 
> >> Once we have forking we could completely replace Apache (or NGineX
> >> or Node.js) with a fully-functioning server for specific
> >> applications where the efficiencies of a purpose-built system would
> >> be helpful.
> >
> > Ah, ok so you wan’t MCHTTPd with child processes and maybe FastCGI
> > but maybe just some custom protocol between them?
> 
> Ideally, both: FastCGI for use under Apache for building Web sites, and a 
> forkable variant of MCHTTPd for building custom application servers.

OK, well these are two quite distinct requests although you could probably 
implement the FastCGI protocol in script and then use your proposed fork 
command if you wanted to load balance over child processes. I was thinking more 
along the lines of using libfcgi directly in the engine. It’s worth noting that 
FastCGI doesn’t require fork (http://www.fastcgi.com/drupal/node/6?q=node/22#S3 
) so if you are keen to 
implement FastCGI in script you could try doing that now. If fork is 
implemented then it should be easy to add to your implementation.
> 
> 
> >> But even when running under Apache with FastCGI, fork would seem
> >> a very useful thing.  It's how PHP and other engines are able to
> >> scale, and indeed not having it prevents LC from being used in
> >> traffic-heavy scenarios.
> >
> > I’m not saying it’s not useful, just suggesting letting something
> > else do the forking might be a good idea.
> 
> I'm not particular how it's done; I'm just looking for options to make 
> scalable services with LC.  What would that "something else" be?

I thought I’d covered that. spawn-fcgi, mod_fcgid or some equivalent.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: mySQL Host access

[Peter Haworth]

OK, thanks Lyn.  I will have to check with my web host (Dreamhost) how to
set LC server up.

On Thu, Jan 7, 2016 at 6:05 PM Lyn Teyla  wrote:

> Peter Haworth wrote:
>
> > Thanks for that info, that will certainly help me when I start looking
> into
> > LC server.  Unfortunately, I think I'm about 6 months into a 2-year
> > contract with my current web host so probably could not switch at this
> > point.
>
> The stacks are a free download, and from what I can tell, don’t require
> you to be a HostM.com client. You just need to be able to run LiveCode
> Server.
>
> Lyn
>
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: mySQL Host access

[Mark Wieder]

On 01/07/2016 06:43 PM, Mark Wieder wrote:


The url *does* throw a 404, though.


...and now they fixed the link.

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: [On-Rev Tio] could someone test the index.html files in her/his account on Tio?

[Robert Mann]

CLOSURE ON THAT SUBJECT :: had to reinstall corrupted files / folders

1. Because I did not have a save copy locally (now I have!)
2. Because they only seem to have one daily backup and told me the corrupted
files had just been corrupted before backup... ?? how can they not have a
d-1 backup?? I wonder!

So DO make a backup of your on-rev accounts locally after each major
modification!!

-
Has anybody made a stack that would scan changes within site files
and make local copy of changed folders?
-




--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/On-Rev-Tio-could-someone-test-the-index-html-files-in-her-his-account-on-Tio-tp4699843p4700013.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

mySQL Host access

[Peter Haworth]

It seems that to access a mySQL database on my web host's servers from a
Livecode program, I have to configure "Allowable hosts" in the database
configuration.  That can be an ip address or a domain name such as "@.
mydomain.com"

The program in question will be used by perhaps a half dozen users, all
from their home computers and likely using different internet providers so
it appears every time I give the program to a new user, I will have to add
either their ip address (if it's fixed) or a domain as above.

Is this common practice when accessing mySQL on a host server?  If so, is
there a better way to set about accessing a mySQL database in these
circumstances, perhaps using php scripts on the server instead of accessing
the db directly with the LC database functions?

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: equivalent to DISTINCT ON (with SUM()) for in-memory SQLite

[Peter Haworth]

I think this will work

SELECT sum(due) from mytable WHERE  ORDER BY cname || caddr GROUP
BY cname || caddr

GROUP may have to come before ORDER, don't remember.



On Thu, Jan 7, 2016 at 4:32 PM Dr. Hawkins  wrote:

> I need to sum amounts and return keys where other fields are the same on an
> in-memory database.
>
> I have my own unique key uniqDna, fields cname and cadr, and numeric field
> due
>
> I want to SUM(due) for each unique cname||cadr, and get get the
> corresponding keys.
>
> DISTINCT ON would due this, but it's not supported by SQLite.
>
> At the moment, I'm not seeing any approach other than returning them all,
> and using cname||cadr as a matrix key, and summing myself.
>
> --
> Dr. Richard E. Hawkins, Esq.
> (702) 508-8462
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: [On-Rev Tio] could someone test the index.html files in her/his account on Tio?

[Richard Gaskin]

Robert Mann wrote:

> So DO make a backup of your on-rev accounts locally after each major
> modification!!

With portable HDDs selling at around US$50/GB multiple redundant backups 
are easy, esp. with:


> Has anybody made a stack that would scan changes within site files
> and make local copy of changed folders?

rsync -avz user@server:/path/to/server/folder/  local/folder/

rsync is preinstalled on OS X and Linux; Windows users can install 
Cygwin to have it (and other great bash tools).


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for Desktop, Mobile, and Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: "fork" command?

[Pierre Sahores]

> Le 7 janv. 2016 à 20:03, Richard Gaskin  a écrit :
> 
> I'm just far enough into Robert Love's "Linux System Programming" that I 
> think the solution to FastCGI may be much simpler than I'd previously thought.
> 
<—snip —>

> Forking seems so common in other tools, and not having it appears to be the 
> one detail standing between where we are now and having not just FastCGI, but 
> also being able to build truly excellent application servers on par with 
> Node.js and other similar systems.
> 
> LiveCode is a great language, and if we had the ability to fork we should be 
> able to build a wide range of powerful, scalable, efficient systems, breaking 
> far beyond the limitations of CGI we're limited to now.

+1

Livecode behind NGINX would probably run as fast as OpenResty powered app’s 
servers.

https://www.techempower.com/benchmarks/

Best,

Pierre
--
Pierre Sahores
mobile : 06 03 95 77 70
www.sahores-conseil.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: mySQL Host access

[Mike Bonner]

I wonder if Andres Dblib could be modified so that it could be used on both
ends.  On the client side, use the where, columns etc functionality to
build up an array, (dbA) encode it, and post it to a page where its
decoded, copied to the dbA variable (after you "start using.." andres
stack) and then its a single call to interact with the database. (ok so a
bit more complicated, you'd have to set the default connection, and pass in
whethere you were doing an insert, update, or whatever) but overall I think
it would be do-able. (and there is a gpl version of the library)  It would
just have to be modded to handle the arrayencode, and posting.  And
decoding on the far side.

On Thu, Jan 7, 2016 at 12:15 PM, Peter Haworth  wrote:

> Thanks Matthias, definitely seems like php on the server is the way to go.
> I guess designing the interface protocol between the LC app and the php
> scripts is my next step.
>
> Pete
> lcSQL Software 
> Home of lcStackBrowser  and
> SQLiteAdmin 
>
> On Thu, Jan 7, 2016 at 10:17 AM, Matthias Rebbe | M-R-D <
> matthias_livecode_150...@m-r-d.de> wrote:
>
> >
> >
> > > Am 07.01.2016 um 18:34 schrieb Peter Haworth :
> > >
> > > It seems that to access a mySQL database on my web host's servers from
> a
> > > Livecode program, I have to configure "Allowable hosts" in the database
> > > configuration.  That can be an ip address or a domain name such as "@.
> > > mydomain.com”
> > >
> >
> > if i remember right you could use %.%.%.% instead of the ip address to
> > allow all ip addresses to remotely connect to the MySQL DB.
> > But i wouldn´t do that. I would create a php or lc script on the server
> > which makes all the communication with the MySQL db and then let the
> > Desktop App call the php/lc file on the server. The php/lc file would
> then
> > return the needed data to the Desktop App.
> >
> > It´s much safer then to allow remote connections to the MySQL DB.
> >
> > Matthias
> >
> > > The program in question will be used by perhaps a half dozen users, all
> > > from their home computers and likely using different internet providers
> > so
> > > it appears every time I give the program to a new user, I will have to
> > add
> > > either their ip address (if it's fixed) or a domain as above.
> > >
> > > Is this common practice when accessing mySQL on a host server?  If so,
> is
> > > there a better way to set about accessing a mySQL database in these
> > > circumstances, perhaps using php scripts on the server instead of
> > accessing
> > > the db directly with the LC database functions?
> > >
> > > Pete
> > > lcSQL Software 
> > > Home of lcStackBrowser  and
> > > SQLiteAdmin 
> > > ___
> > > use-livecode mailing list
> > > use-livecode@lists.runrev.com
> > > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> >
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: "fork" command?

[Monte Goulding]

Hmm… I’m not convinced we need this for FastCGI. Apache mod_fcgid will start up 
processes for you and for Nginx and other servers that don’t do that you could 
use spawn-fcgi. I have done some thinking on FastCGI after Todd asked me to 
look into the feasibility of it and was considering funding or part funding it. 
He ended up going with another platform for server side stuff so its been put 
on the back burner.

We mainly need two things for FastCGI:
 - an engine with the FastCGI accept loop as the main loop (LC Server just 
starts up and quits at the end of the code and standalones just keep looping 
until you quit).
 - to decide on how to handle things like global variable scope etc because 
you’re going to end up with multiple requests to the same environment.

After some thought and considering the new script only stack format I came to 
the conclusion that it would be better not to do the php style  On 8 Jan 2016, at 6:03 am, Richard Gaskin  wrote:
> 
> I'm just far enough into Robert Love's "Linux System Programming" that I 
> think the solution to FastCGI may be much simpler than I'd previously thought.
> 
> I think we need a new command that launches a specified process but in a way 
> that uses a call to "fork" to pass file descriptors (which include sockets 
> and other I/O info) to the child process.
> 
> In many ways it would work very similarly to the existing "open process", but 
> allow params to give the child process access to things like socket 
> connections, pipes, files, etc. the parent process has access to at the time 
> the child process is launched.
> 
> It would seem least intrusive on the code base to implement it as a new 
> command, perhaps called "fork".
> 
> That said, I have to admit the risk of Dunning-Kruger effect here:  I'm not 
> that far into the book, and my knowledge in this area is far below my 
> aspirations.
> 
> But for those of you more familiar with Linux system programming, do I 
> misunderstand the difficulty involved?
> 
> Forking seems so common in other tools, and not having it appears to be the 
> one detail standing between where we are now and having not just FastCGI, but 
> also being able to build truly excellent application servers on par with 
> Node.js and other similar systems.
> 
> LiveCode is a great language, and if we had the ability to fork we should be 
> able to build a wide range of powerful, scalable, efficient systems, breaking 
> far beyond the limitations of CGI we're limited to now.
> 
> If all we need is a new command to wrap the Linux "fork" call, after I finish 
> Love's book I may brush up on my C skills and give it a go.
> 
> But who wants to wait for that.  Is there anyone in our community who could 
> do this now?
> 
> Do I misunderstand what's needed here?
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

"fork" command?

[Richard Gaskin]

I'm just far enough into Robert Love's "Linux System Programming" that I 
think the solution to FastCGI may be much simpler than I'd previously 
thought.


I think we need a new command that launches a specified process but in a 
way that uses a call to "fork" to pass file descriptors (which include 
sockets and other I/O info) to the child process.


In many ways it would work very similarly to the existing "open 
process", but allow params to give the child process access to things 
like socket connections, pipes, files, etc. the parent process has 
access to at the time the child process is launched.


It would seem least intrusive on the code base to implement it as a new 
command, perhaps called "fork".


That said, I have to admit the risk of Dunning-Kruger effect here:  I'm 
not that far into the book, and my knowledge in this area is far below 
my aspirations.


But for those of you more familiar with Linux system programming, do I 
misunderstand the difficulty involved?


Forking seems so common in other tools, and not having it appears to be 
the one detail standing between where we are now and having not just 
FastCGI, but also being able to build truly excellent application 
servers on par with Node.js and other similar systems.


LiveCode is a great language, and if we had the ability to fork we 
should be able to build a wide range of powerful, scalable, efficient 
systems, breaking far beyond the limitations of CGI we're limited to now.


If all we need is a new command to wrap the Linux "fork" call, after I 
finish Love's book I may brush up on my C skills and give it a go.


But who wants to wait for that.  Is there anyone in our community who 
could do this now?


Do I misunderstand what's needed here?

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: mySQL Host access

[Earthednet-wp]

Peter,
I do this on my server. I keep the php on my server. Then I only have to allow 
access from "localhost' because the php is being run on the server. The php is 
accessed with "post" command from livecode. If you need an example, I can send 
you a sample stack, with some sample php.
Bill

William Prothero
http://es.earthednet.org

> On Jan 7, 2016, at 9:34 AM, Peter Haworth  wrote:
> 
> It seems that to access a mySQL database on my web host's servers from a
> Livecode program, I have to configure "Allowable hosts" in the database
> configuration.  That can be an ip address or a domain name such as "@.
> mydomain.com"
> 
> The program in question will be used by perhaps a half dozen users, all
> from their home computers and likely using different internet providers so
> it appears every time I give the program to a new user, I will have to add
> either their ip address (if it's fixed) or a domain as above.
> 
> Is this common practice when accessing mySQL on a host server?  If so, is
> there a better way to set about accessing a mySQL database in these
> circumstances, perhaps using php scripts on the server instead of accessing
> the db directly with the LC database functions?
> 
> Pete
> lcSQL Software 
> Home of lcStackBrowser  and
> SQLiteAdmin 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: mySQL Host access

[Alex Tweedly]

Why would you consider php scripts, when it would (I assume) be much 
more familiar for you to use .lc scripts on LCServer, or CGI, scripts ?


In fact, given it's you :-), I would think you could write such LC 
access scripts in your sleep :-), probably better than most of us.


-- Alex.

On 07/01/2016 17:34, Peter Haworth wrote:

It seems that to access a mySQL database on my web host's servers from a
Livecode program, I have to configure "Allowable hosts" in the database
configuration.  That can be an ip address or a domain name such as "@.
mydomain.com"

The program in question will be used by perhaps a half dozen users, all
from their home computers and likely using different internet providers so
it appears every time I give the program to a new user, I will have to add
either their ip address (if it's fixed) or a domain as above.

Is this common practice when accessing mySQL on a host server?  If so, is
there a better way to set about accessing a mySQL database in these
circumstances, perhaps using php scripts on the server instead of accessing
the db directly with the LC database functions?

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: "fork" command?

[Bob Sneidar]

That would be a great addition, although I confess I am highly dependent on the 
"finish what you are doing and move on to the next step" model, or single 
threading as the less tech savy might call it. ;-)

Bob S


> On Jan 7, 2016, at 11:03 , Richard Gaskin  wrote:
> 
> I'm just far enough into Robert Love's "Linux System Programming" that I 
> think the solution to FastCGI may be much simpler than I'd previously thought.
> 
> I think we need a new command that launches a specified process but in a way 
> that uses a call to "fork" to pass file descriptors (which include sockets 
> and other I/O info) to the child process.
> 
> In many ways it would work very similarly to the existing "open process", but 
> allow params to give the child process access to things like socket 
> connections, pipes, files, etc. the parent process has access to at the time 
> the child process is launched.
> 
> It would seem least intrusive on the code base to implement it as a new 
> command, perhaps called "fork".
> 
> That said, I have to admit the risk of Dunning-Kruger effect here:  I'm not 
> that far into the book, and my knowledge in this area is far below my 
> aspirations.
> 
> But for those of you more familiar with Linux system programming, do I 
> misunderstand the difficulty involved?
> 
> Forking seems so common in other tools, and not having it appears to be the 
> one detail standing between where we are now and having not just FastCGI, but 
> also being able to build truly excellent application servers on par with 
> Node.js and other similar systems.
> 
> LiveCode is a great language, and if we had the ability to fork we should be 
> able to build a wide range of powerful, scalable, efficient systems, breaking 
> far beyond the limitations of CGI we're limited to now.
> 
> If all we need is a new command to wrap the Linux "fork" call, after I finish 
> Love's book I may brush up on my C skills and give it a go.
> 
> But who wants to wait for that.  Is there anyone in our community who could 
> do this now?
> 
> Do I misunderstand what's needed here?
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode